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

[Etienne G. <gag...@uq...>]

Chris,

Your messages are too long.  I'm sincerely sorry, but I have to ask to su=
mmarize.
I'll try to answer the summary as well as I can.

Etienne

Chris Pickett wrote:
> Hi Etienne,
>=20
> 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 =

> the same height again, the method has returned, when in fact that metho=
d=20
> 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.
>=20
> So ... my questions are ...
>=20
> 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?
>=20
> 2) Do all calls to _svmf_interpreter() end in INTERNAL_CALL_END (it=20
> appears this way from invoke_interface.c)?
>=20
> 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=
,=20
> 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?
>=20
> 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?
>=20
> 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 th=
e=20
> call stack returns you are back where you started?
>=20
> 6) Do you see any reason, if I take care of things like described above=
,=20
> 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 i=
n=20
> each of these (native methods might call JNI functions that start=20
> speculative threads)?
>=20
> 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).
>=20
> Cheers,
> Chris
>=20
>=20
>=20
> Chris Pickett wrote:
>=20
>>
>>
>> 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=20
>>>> stack values or control flow without going through the=20
>>>> exception_handler: in interpreter.c or going through=20
>>>> _svmf_stop_the_world?  If so, where does 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:
>>        <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 wil=
l
>>> 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 =

>> or not.  I had changed _svmf_stop_the_world() in thread.c to:
>>
>>     /* visit all threads */
>>     for (...)
>>       {
>>         jboolean succeeded;
>>               <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=
=20
>> ...
>=20
>=20
>=20
>=20
>=20


--=20
Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/