Memory management in HydraVM

>  
> Hello list,
>
> until now, i never examined how OS-specific routines sqAllocateMemory,
> sqGrowMemoryBy .. working,
> and in Hydra everything worked just well, without problems so far for
> two images..
>
> Eventually, i tried to find a way how to deallocate the heap for an
> interpreter which is no longer running (if image quits, or fatal error
> in interpreter, or even on C exception) and found that i can't free
> memory for specific interpreter instance, because sqReleaseMemory()
> having no arguments. :)
>
> And by getting deeper, i found that memory management must be
> completely redesigned, because Hydra will unable to work with
> Interpreters > 2..4.
> For all platforms, if it supports virtual memory management, an
> sqAllocateMemory() function reserves a huge chunk of address space for
> a potentially big object memory heap, while reserving initially small
> amount of physical memory (enough to fit image in it + some extra
> space).
> This approach works well for single image, but not for multiple :(
>
> For instance, in win32 port, there is a constant which defines a total
> amount of address space reserved for a single heap:
> #define MAX_VIRTUAL_MEMORY 512*1024*1024
> which means that first image heap takes 512Mb address space,
> second one - another 512Mb
> and if i remember correctly, in win32 process not allowed to reserve
> more than 2Gb address space, which means that when we try to run 3rd
> or 4th image, we having high probability that OS will reject to
> allocate any more address space. In any way, even if limit is 4Gb (max
> 32 bit address space), we still have a maximum number of about 8
> interpreters.
> Not mentioning the address space used for C heap, kernel, many .dlls
> etc etc. and inevitable address space segregation.
>
> Also, i found that sqGrowMemoryBy(), sqShrinkMemoryBy(),
> sqMemoryExtraBytesLeft() using static variables, and there is high
> risk that if VM will use them in both direction (grow/shrink), it
> could lead to crash.
> This, of course can be fixed easily, by holding a memory state for
> each instance of interpreter separately, but this is not a cure for a
> problem with address space.
>
> It looks like, that Hydra will require a sophisticated virtual memory
> management (since Hydra runs only on systems which supporting threads,
> i think we can assume that OS gives us the way to manage virtual
> memory as well).
>
> I'd like to hear your advice, what strategy works best for it? Also,
> if you know about any tech-docs describing such strategies or
> libraries which enable to manage virtual memory efficiently - let me
> know.
> Shall the memory manager give small address space regions for each
> interpreter instance, and then if some image tends to grow bigger -
> relocate it into a different memory space with higher number of pages
> reserved for it?
> Is it safe to relocate an object memory when it is in working state
> (not running, because we obviously will request a relocation of object
> memory when current heap size will become too small to fit object
> memory in it)?
> The C code (in primitives/plugins) does not holding direct object
> pointers - thanks that we having a moving GC :) So i think it is
> doable..
>

>
> Hi Igor -
>
> The main reason for reserving a large chunk of address space is to avoid the
> C allocator to interfere with our need of continuous address space. This
> doesn't that the address space has to be used by a single image.
>
> Since all of the object memory are relocatable, it is easy to see that if
> necessary an object memory could be relocated to a different location. I
> always thought that a Hydra memory managing scheme should work like here:
>
> As a base rule, recursively divide the address space for any new object
> memory. Meaning that with 512MB address space the first image starts at 0,
> the second at 256k the third 128, the fourth at 384 etc. Obviously, if that
> memory is already occupied you move on to the next smaller chunk (i.e., if
> the first image needs more than 256 MB you try 384 next, if that's taken you
> try 448 and so on). Assuming that there is enough base memory to load the
> image (i.e., you aren't trying to load an image into a fragmented space that
> doesn't have sufficient memory at the given location) you will be able to
> load and start that image.
>
> If an image happens to need more space than currently reserved, move the
> adjacent image away. The idea is that you only need to lock and move one
> image (instead of all interpreters) if this is the only one you'll be
> relocating. If there is no space to move the adjacent image, then some
> heuristics needs to be found to figure out what to do. In the early stages I
> would just fail the allocation and give up.
>
> I think the above should work well for most cases. It will deal with one of
> the most important cases: One big master image and many small worker images.
> As the big image grows it will move the smaller images out of the way.
>