Michael J. Mahon wrote:
David Schmenk wrote:Eric wrote:On Nov 29, 2:54 am, mdj <mdj....@gmail.com> wrote:Yeah. I'm interested to see how you manage the heap - with so little space it could potentially thrash really badly. The p-system got around this problem by 'disposing' the dispose procedure and simply having a stack instead, but for Java that's not an option.NanoVM combines the stack and heap management in a way that allows for a sliding boundary between the two. This seems obvious to C programmers, but many OOP compiler writers used fixed size stack and heap regions. A sliding boundary lets the heap breathe a little between collections. The routine that allocates stack space can force a garbage collection if it doesn't have enough room on the stack. Likewise, the heap allocator can force a collection if it needs more space. The trick is to avoid abritrary to timed collections. You only collect when you must collect. It will still thrash somewhat, of course. This is the "pay me now or pay me later" debate. A heavier allocator is slow but it saves on CPU cycles needed for collections. The trick is to find the optimum tradeoff. On a small machine I think you need more smarts in the allocator. Traditional JVM and .NET CLRs opt for faster allocators and timed background collectors that tend to be heavy. EricI am allocating stack space piecewise in predefined chunks from the heap. Activation frames will be allocated from these chunks until it is full, then allocate another chunk and link to it. Having multiple threads and one stack wasn't a workable solution. Now they can be allocated dynamically, managed like anything else in the heap, and even swapped if they don't contain the current activation frame.I will have a background thread that runs garbage collection and calls finalize methods.The trick will be to arrange allocation so that you don't have 100 chunks, each with one or two active frames... This kind of fragmentation would prevent effective chunk swapping, since a working set would be too large. -michael NadaPong: Network game demo for Apple II computers! Home page: http://members.aol.com/MJMahon/ "The wastebasket is our most important design tool--and it's seriously underused."
I have decided that there will be some limits to the number of local variables and the depth of the evaluation stack. This should keep the frame size manageable. A maximum of 64 local variables per method should keep things in check. If I have a chunk size of around 1K, that should allow for enough frames without cluttering things up. Of course the chunk size will be configurable. Perhaps 4K would work better. 32 bit data types chew memory up pretty fast.
I think this approach will be the best trade-off between allocating each activation frame from the heap and a statically allocated call/frame stack.
Dave...