harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Deakin <oliver.dea...@googlemail.com>
Subject Re: [drlvm] using the harmony launcher
Date Mon, 17 Jul 2006 10:38:13 GMT
Andrey Chernyshev wrote:
> On 7/13/06, Oliver Deakin <oliver.deakin@googlemail.com> wrote:
>> Andrey Chernyshev wrote:
>> <SNIP!>
>>
>>
>> or:
>> launcher calls CreateJavaVM()
>> CreateJavaVM() passes call to create_vm()
>> create_vm() makes its usual calls and returns. A flag is set to
>> indicate that VMStart still needs to be run.
>> create_vm() and CreateJavaVM() both exit, returning control to the
>> launcher
>> launcher makes a call to run some Java code (possibly main method)
>> drlvm picks up flag indicating VMStart needs to be executed and runs
>> it before the specified class
>>
>> The first approach seems better to me, since it gets all of the vm
>> initialization
>> completed within the CreateJavaVM() call.
>
> I also like the first approach, it would be strange behavior for JNI
> CallXMethod to run the calls in a separate thread if some special flag
> is found.
>
>
>>
>> Does this answer your question? Any other ideas?
>
> I don't think there is an issue with not running of certain parts of
> VMStart: one can divide it into 3 different parts:
> - initialization;
> - running main() method of the user app (in a separate thread)
> - shutdown.
>
> The code for VMStart's init() and shutdown() is equally run regardless
> of whether drlvm is started with it's own or classlib launcher. The
> difference is only in running the user app main() method. Classlib
> launcher calls it directly, through JNI, while the drlvm's launcher
> wraps it into the run() method and always runs in a separate thread.
> I suspect there could be some difference in the classloader's used for
> the user app code, perhaps the drlvm classloading experts could give
> some more details.

If we separate initialisation and execution of the main() method in VMStart
so that CreateJavaVM works, is there actually a need to keep the
main() method execution in there? I can't think of a reason to launch
the main() method in a separate thread (perhaps, as you suggest, some
drlvm experts can help with this one) - if there is no reason to do
this, then I would probably suggest either altering the drlvm launcher
to use a more conventional launcher approach (CreateJavaVM followed
by CallStaticMethod) or abandoning the drlvm launcher in favour
of the classlib one. Either way, I think the start() method in VMStart
could probably be removed.

>
> Thanks,
> Andrey.
>
>>
>>
>> >
>> > (2)
>> > If I pass a wrong app class name to the classlib launcher, drlvm
>> > reports class not found exception and then is crashed. This happens
>> > because the classlib launcher, once it fails to run the app class,
>> > reports an exception (with ExceptionDescribe) but doesn't clear it
>> > (doesn't call ExceptionClear). Then it immediately goes with
>> > DestroyJavaVM those current implementation in drlvm doesn't expect
>> > that there is some pending exception object in the TLS.
>> > Eventually, destroy_vm fails with assert in the class loading code
>> > while resolving VMStart class (VMStart holds the Java part of the
>> > shutdown method), because it mistakenly picks up the ClassNotFound
>> > exception object. It is remaining from unsuccessful attempt of
>> > classlib launcher to run the app's class main method.
>> >
>> > The question is, who's responsibility should be to clear the exception
>> > object in that case? I tend to think that classlib launcher should be
>> > doing this once it takes the responsibility to process the possible
>> > exceptions while running the app main class.
>>
>> Although the classlib launcher should probably tidy up after itself and
>> call ExceptionClear, I don't believe that there is a spec requirement to
>> clear pending exceptions before calling DestroyJavaVM. Therefore
>> any launcher could call DestroyJavaVM with an exception pending,
>> and drlvm would throw a ClassNotFound.
>> IMHO drlvm should handle the fact that an exception already exists
>> on entering DestroyJavaVM, and clear it before trying to resolve
>> the VMStart class.
>
> Yes, this sounds reasonable. Then, what should be the expected
> behavior for DestroyVM in case it finds pending exception, should it
> silently ignore it, or report a warning or what? JNI spec doesn't seem
> to specify these details.

Agreed, the JNI spec isn't too clear on this matter.
In JNI, handling of uncaught exceptions is expected to be done
by the developer (ie using ExceptionOccurred, ExceptionDescribe,
ExceptionClear) rather than the VM. This leads me to think that if
any exceptions have not been cleared by the JNI code before
DestroyJavaVM() is called, then the developer will expect the VM
to just silently ignore them and carry on shutting down.

So, IMHO one of the first things that should be done after entering
DestroyJavaVM is to check for pending exceptions, and clear them
if they're going to interfere with the shutdown sequence.

I've just created a simple launcher that:
  - creates a Java VM
  - invokes the main method of a class that throws a RuntimeException
  - calls DestroyJavaVM without clearing the pending exception
Both the RI and IBM VMs exit without any complaints, so I think that
drlvm should match this behaviour also.

Regards,
Oliver

>
>>
>> >
>> > (3)
>> > CreateJavaVM can only be called once for now – many internal data
>> > structures in DRLVM are kept as global variables (jni_env, java_vm,
>> > Global_Env e.t.c.). Therefore, it will be hard to organize the
>> > multiple instances of JavaVM unless all these things are encapsulated
>> > somewhere (into JNIEnv?).
>> >
>> > (4)
>> > Launcher wants the vm dll in the "default" directory unless the option
>> > is specified. Should we realign the drlvm build output and move all
>> > dll's into the "default" subdir?
>>
>> yup, or put it into a deploy/jdk/jre/bin/drlvm directory and use the
>> launcher
>> options to specify its location.
>>
>> >
>> > (5)
>> > What to do with the "_org.apache.harmony.vmi.portlib" option that
>> > launcher is offering to VM?
>>
>> This passes the classlib port library function table to the VM. I think
>> this just makes the classlib port library available to the VM for it to
>> use/query if it wishes. I think it is fine for the drlvm to ignore this
>> option
>> if it wants to.
>>
>> Regards,
>> Oliver
>>
>> >
>> > Most likely there are more issues that I'm overlooking at the moment.
>> > Please consider the suggested patch is a workaround to make the things
>> > working, I'm wondering if there is a more graceful way to do this.
>> >
>> > Thanks,
>> > Andrey.
>> >
>> >
>> > On 7/11/06, Andrey Chernyshev <a.y.chernyshev@gmail.com> wrote:
>> >> OK, so I'm going to add CreateJavaVM into vm\vmcore\src\jni\jni.cpp
>> >> and also add implementation into DestroyVM (stub is already seem 
>> to be
>> >> present there) based on destroy_vm(). Then we'll see how it works 
>> with
>> >> the launcher.
>> >>
>> >> Thanks,
>> >> Andrey.
>> >>
>> >>
>> >> On 7/11/06, Geir Magnusson Jr <geir@pobox.com> wrote:
>> >> > This has been my thinking - even if not perfect, lets get it 
>> working
>> >> > using the launcher and then fix as required. It's arguable if that
>> >> > "brokenness" matters at this point, and I think that there's 
>> plenty to
>> >> > be gained from having it work via the launcher.
>> >> >
>> >> > geir
>> >> >
>> >> > Rana Dasgupta wrote:
>> >> > > create_vm() looks quite close/complete to being a complete
>> >> prototype for
>> >> > > CreateJavaVM,
>> >> > > but I think more work is needed in DestroyVM which prototypes
>> >> DestroyJavaVM
>> >> > > for functional completeness. It is non waiting on user threads,
>> >> it does not
>> >> > > send the corresponding JVMTI shutdown events, I also don't know
>> >> if it
>> >> > > handles shutdown hooks cleanly ( but these "may" not be critical
>> >> right now
>> >> > > for hooking up to the launcher ). What do you think?
>> >> > >
>> >> > > When I ran a non trivial test.. upto 32 threads instantiating
a
>> >> very large
>> >> > > number of objects with -XcleanupOnExit which uses
>> >> DestroyVM, it
>> >> > > exited cleanly. Maybe OK to hookup and fix bugs as we go.
>> >> > >
>> >> > > Thanks,
>> >> > > Rana
>> >> > >
>> >> > >
>> >> > > On 7/10/06, Andrey Chernyshev <a.y.chernyshev@gmail.com>
wrote:
>> >> > >
>> >> > >> >Yes, it seems like the launcher will need at least
>> >> JNI_CreateJavaVM
>> >> > >> >and DestroyJavaVM functions.
>> >> > >>
>> >> > >> >I couldn't find implementation for CreateJavaVM in drlvm

>> codebase.
>> >> > >> >Perhaps create_vm() function in vm\vmcore\src\init\vm_main.cpp
>> >> can be
>> >> > >> >adopted for that purpose?
>> >> > >> >Is there are any tricks and caveats one should be aware
of 
>> before
>> >> > >> >trying to produce CreateJavaVM from it?
>> >> > >>
>> >> > >> >I've also seen a prototype for DestroyJavaVM in
>> >> > >> >vm\vmcore\src\init\vm.cpp - comment says it needs to be
>> >> improved to
>> >> > >> >wait till all Java threads are completed.
>> >> > >>
>> >> > >> >Any more ideas what needs to be done to implement those?
>> >> > >>
>> >> > >> >Thanks,
>> >> > >> >Andrey.
>> >> > >>
>> >> > >>
>> >> > >>
>> >> ---------------------------------------------------------------------
>> >> > >> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> >> > >> To unsubscribe, e-mail:
>> >> harmony-dev-unsubscribe@incubator.apache.org
>> >> > >> For additional commands, e-mail:
>> >> harmony-dev-help@incubator.apache.org
>> >> > >>
>> >> > >>
>> >> > >
>> >> >
>> >> > 
>> ---------------------------------------------------------------------
>> >> > Terms of use : http://incubator.apache.org/harmony/mailing.html
>> >> > To unsubscribe, e-mail: 
>> harmony-dev-unsubscribe@incubator.apache.org
>> >> > For additional commands, e-mail: 
>> harmony-dev-help@incubator.apache.org
>> >> >
>> >> >
>> >>
>> >>
>> >> --
>> >> Andrey Chernyshev
>> >> Intel Middleware Products Division
>> >>
>> >
>> >
>>
>> -- 
>> Oliver Deakin
>> IBM United Kingdom Limited
>>
>>
>
>

-- 
Oliver Deakin
IBM United Kingdom Limited


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message