GC question

[Godmar Back]

> 
> On Thu, 5 Nov 1998 10:06:56 -0700 (MST), Godmar Back wrote:
> 
> >> 
> >> 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?)
> 
> Yes, that's what I meant. Looking through the source I see that method
> locals are allocated using alloca(). I thought I could just allocate
> two more words containing the size and a link to the callers locals.
> This list would be rooted in jthread_t. The locals would be unlinked
> before returning to the caller and in case of an exception.
> TwalkThread() could then traverse the list calling walkConservative()
> for each node. As a side effect, counting the frames would also work.
> This, of course, only works if native methods and the VM cooperate.
> 

 This solution incurs run-time overhead.

This was pointed out earlier on this list in the context of introducing
stack annotations to tell jit and intrp methods apart in Senthil Kumar's
project to mix jit and intrp.

Ideally, we would like a solution that does not require a running thread
to execute any additional instructions when entering and leaving a frame.

Of course, if somebody would come and say: for this set of applications,
doing so introduces that much overhead, but gc-time and overall run-time
decreases by that much, then we would be able to judge whether it's
worth it.  I personally feel the overhead might be less than one would
expect.

The first question, however, should be whether it's really
necessary.  I hope the answer to that question is no, given JNI native
methods and support by the JIT compiler.  I might be wrong, though.

	- Godmar