04-26-2016, 07:47 PM
NiLSPACE: The stable RAM approach is closer to a minimum than a maximum at the moment. If the non-unloadable chunks require more memory than the ram limit, we will use it.
The ideal scenario is that cuberite uses exactly enough memory to fill RAM, without the system having to page either cuberite or any other application. For Dedicated servers, we can approximate this with the stable RAM approach, by setting the MAX to a significant proportion of RAM. For systems with other programs, cuberite would have to adjust its RAM in proportion to other applications requests. With the current saving architecture that is not achievable without OS support. So we have the options of the current/unload ASAP strategy. Both of these are focused primarily on minimizing our impact on other applications, and can leave significant amounts of memory unused. By comparison, The Stable RAM approach allocates a fixed amount of RAM as ours, and leaves the other applictions to the rest.
The ideal scenario is that cuberite uses exactly enough memory to fill RAM, without the system having to page either cuberite or any other application. For Dedicated servers, we can approximate this with the stable RAM approach, by setting the MAX to a significant proportion of RAM. For systems with other programs, cuberite would have to adjust its RAM in proportion to other applications requests. With the current saving architecture that is not achievable without OS support. So we have the options of the current/unload ASAP strategy. Both of these are focused primarily on minimizing our impact on other applications, and can leave significant amounts of memory unused. By comparison, The Stable RAM approach allocates a fixed amount of RAM as ours, and leaves the other applictions to the rest.