GC question

[Godmar Back]

 Hi Andreas,

> 
> Is it really necessary to scan the entire (active) stack of a thread or
> would it be sufficient to scan the part of the stack that contains the
> method locals? IOW, what would the gc find if it scanned the entire
> stack? Does the VM itself rely on the memory it allocates being gc'd or
> is it disciplined enough to free memory it no longer uses?

As for the first question, whether it be sufficient: yes and no.
If a thread is executing java code, scanning the parts that contain
the method locals is sufficient.  In fact, given enough information
about the layout of these regions (i.e., which locals contain references,
which contain primitive types), it is even possible to not having to
guess at all, but have accurate information where pointers to objects
are located.  Such gc is known as precise or accurate gc, and the
layout information is called a stack map.  

The problem, however, comes about if a stack enters native methods.
This is where your second question leads to.
For these methods, the information about the layout of their local
stack frames is not known a priori.  Native methods are hence the
main reason that the gc conservatively scans the stack.

JNI is the way out of this dilemma: with JNI, native methods are
forced to cooperate.  It is guaranteed that the objects passed to
them are pinned for the duration of the call; for other objects,
it is the responsibility of the JNI method to inform the gc of what
it is doing.

As for the third question, whether the VM frees memory explicitly
or relies on the gc, the answer is it depends.  The VM can choose
between different allocation methods, depending on whether it
wants to free itself or rely on the gc.  In Kaffe, these two methods
are gc_malloc and gc_malloc_fixed.  Note that explicit freeing often
requires some kind of finalizer, especially if the time at which
a given piece of memory is deallocated depends on when a corres-
ponding Java object is freed (see Thread for an example).

> 
> The reason I'm asking this is that I'm trying to figure out a way to
> make the gc work with native threads that don't allow a thread to
> inspect another thread's stack.
>

The answer is two-fold:  
a) convert all native methods to JNI.  This is on the TODO list anyway.
   Note, however, that there is a performance trade-off that is to be
   explored.
b) Make the gc precise as described.

However, your statement: "that don't allow inspection of another
thread's stack" seems a bit too strong.  Even if you have the information
I mentioned, the collector thread would still have to inspect another
thread's stack to read the actual references from there.
Maybe what you mean is that you're unable to obtain the stack pointer
of another thread (as would be the case if you used standard pthreads?)

	- Godmar