GC question

[Andreas Huber]

On Thu, 5 Nov 1998 13:26:28 -0700 (MST), Godmar Back wrote:

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

As I understand stack annotations would not prevent me from having to
find out the boundaries of one thread's stack from another thread since
it is not possible to access to the base/stack pointers. And even if it
were possible, I don't want to rely on the compiler generating
traversable stack frames.

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

I thought it could be as simple as assigning two pointers on method
entry and assigning one pointer on method exit (linking and unlinking a
node from a linked list). The overhead should be marginal. Of course
exception unwinding would be a little bit more complicated, but not
much. I think the overhead would be more than compensated by not having
the gc scan the entire active stack.

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

I'm not sure I understand, could you please elaborate?

Andreas