[Vm-dev] Memory management in HydraVM

[Igor Stasenko]

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..

-- 
Best regards,
Igor Stasenko AKA sig.