Re: [Sablevm-developer] adventures in not understanding the java stack

[Chris P. <chr...@ma...>]

Hi Etienne,

I looked into bootstrapping and class loading (tracing execution with=20
M-. and M-* in etags) and realized that the problems I'm having are due=20
to my assumption that when the env->stack.current_frame offset reaches=20
the same height again, the method has returned, when in fact that method =

may have called _svmf_interpreter() somewhere along the line, and=20
although the height of the current_frame in the Java stack may be=20
correct, the height in the C stack is incorrect.

So ... my questions are ...

1) Does the indented stuff below (sorry Greg for the "AOL-style" email)=20
make sense w.r.t. exceptions and GC?  In other words, have I identified=20
the unique entry points for exceptions and GC correctly, and am I=20
correct to assume that GC or exceptions as caused by native code will=20
pass through these points?

2) Do all calls to _svmf_interpreter() end in INTERNAL_CALL_END (it=20
appears this way from invoke_interface.c)?

3) If I keep track of _svmf_interpreter() call depth and Java call=20
depth, abort speculative children on GC or exceptions in the parent=20
non-speculative thread, and abort speculative children on global=20
memory-writing (Java heap or not) instructions in the speculative child, =

am I correct to assume that the "speculative" stack obtained after=20
jumping over a method call will not differ from the actual stack when=20
that point is reached non-speculatively?

4) Can I furthermore assert that the next instruction to be executed=20
after a method call has completed, in the absence of an exception being=20
thrown in the call, is the next instruction in the code array?

5) Do calls to _svmf_interpreter() enter and exit cleanly?  In other=20
words, am I right to assume that there is nothing like a Java exception=20
that can occur to screw up control flow, and that when the height of the =

call stack returns you are back where you started?

6) Do you see any reason, if I take care of things like described above, =

that I would need to worry about non-speculatively executing native=20
methods, class initializers, or finalizers, possibly with speculative=20
children before starting or possibly forking new speculative children in =

each of these (native methods might call JNI functions that start=20
speculative threads)?

If the answer to any of these is "no" or "maybe", I don't need a long=20
explanation as much as pointers to the relevant code (I can ask=20
questions later if I don't understand it).

Cheers,
Chris



Chris Pickett wrote:

>
>
> David B=E9langer wrote:
>
>>On Sat, Jan 17, 2004 at 12:21:30AM -0500, Chris Pickett wrote:
>> =20
>>
>>>So ... can somebody explain (3) for me?  Can native code affect stack =

>>>values or control flow without going through the exception_handler: in=
=20
>>>interpreter.c or going through _svmf_stop_the_world?  If so, where doe=
s=20
>>>it do it?
>>>   =20
>>>
>>
>>Look at NATIVE_STATIC_METHOD and NATIVE_NONSTATIC_METHOD.
>>
>>All the code to unwind the stack is in _svmf_interpreter.  Though the
>>exception object is built by the native method or one of the
>>method/function it calls.
>>
>> =20
>>
> that's what i thought.  i had changed _svmf_interpreter() to:
>
>     athrow_handler:
>     ...
>     abstractmethoderror_handler:
>     exception_handler:
>   =20
>     <my code to flag exceptions / kill speculative children is here>
>
>     <normal exception handler stuff>
>
> and i don't understand how an exception can be thrown natively or=20
> non-natively without passing by "exception_handler:" in=20
> _svmf_interpreter ...
>
>>GC is usually trigger by creating new instance and not enough memory.
>>There is also a native method that forces gc.
>>Java_java_lang_Runtime_gc.  There is a single gc entry point that will
>>stop all threads (except the current one) before doing the actual gc.
>>Look in gc_copying.c.
>>
>> =20
>>
>
> okay, i had assumed that _svmf_stop_the_world was always called and=20
> always visited all threads for each gc, whether gc is called natively=20
> or not.  I had changed _svmf_stop_the_world() in thread.c to:
>
>     /* visit all threads */
>     for (...)
>       {
>         jboolean succeeded;
>      =20
>         <my code to flag gc is here>
>
>         if (current =3D=3D env)
>         ...
>       }
>
> and I still don't understand how GC could be called without passing=20
> through this code for each thread.  after looking at=20
> Java_java_lang_Runtime_gc, i see that it calls=20
> _svmf_copy_gc_no_exception(), which in turn calls _svmf_stop_the_world =
=2E..