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