GC

[James Kevin Doyle]

> 
> PMJI, but I think we have to reconsider the memory management in a not-so-far
> future. I did some tests and found that some programs (e.g. the notorious
> javac) sometimes spend most of their time collecting garbage.
> 
> During the last years, I wrote two garbage collectors for C++ and therefor have
> some background on that. What might be even more interesting than the GC
> mechanism itself is an allocation scheme which always knows where to get new
> memory (without traversing lists to look for free slots). Most generation
> scavenging collectors/allocators do. The whole idea is to make the allocation
> process equally efficient as ordinary stack utilization. To my knowledge, some
> ML implementations rely on this (even stack frames are heap objects). The
> downside usually is an (at least) "two-halves" memory layout which roughly
> doubles the amount of initially required memory (however, inactive areas can be
> paged out).
> 

What we are working on at UMass is a generational copying collector
for Java (based on our GC for Smalltalk and ML) that allows
incremental collection; only the generations being copied need to be
"doubled" as mentioned above.  The oldest, and largest, generation is
collected incrementally in a series of units (this is our Mature
Object Space algorithm).

Allocation is fast (advancing an allocation pointer in a nursery),
write barriers are fast (marking a bit in a card table), and the part
of collection requiring mutator threads to stop work (where all
changes to the heap are caught up with and objects are fixed to point
to new copies) will be minimal.

We deal with the stack by having stack maps for each program-counter
value in each method, indicating where pointers are for that method's
stack frame at that particular bytecode.  Objects are dealt with using
object maps for each class that indicate where the pointer fields in
an object are.  Our object overhead is minimal; they need no gc-mark
info, only a pointer to class, and additional lock/hash/forwarding
fields.

Just thought I'd point out one way of handling memory management in Java.

Jim Doyle
jdoyle at cs.umass.edu