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 Thu, 13 Jul 2006 08:58:44 GMT
Andrey Chernyshev wrote:
> With some changes I was able to run the DRLVM with classlib's
> launcher. Here is what I did (you can see the experimental patch at
> http://issues.apache.org/jira/browse/HARMONY-857):
> - I have added JNI_CreateJavaVM declaration to jni.h (guess it will be
> the most appropriate place for it);
> - Added a simple implementations for JNI_CreateJavaVM and
> DestroyJavaVM based on the existing create_vm and detroy_vm functions
> in the vmcore/init submodule.
> - To make vmcore/init functions visible for vmcore/jni code, I have
> moved vmcore/init/init.h to vmcore/include;
> - In parse_arguments.cpp, I had to silently ignore the option
> "_org.apache.harmony.vmi.portlib" which is passed by the launcher to
> VM for some reason, causing the DRLVM to complain about "unknown
> option". What is the purpose of that option, should I process it
> differently?
> After all, I was able to run the DRLVM under classlib's launcher on
> Windows with a command like:
> Java.exe -vm:vmcore -vmdir:. Hello
> and even was able to run Eclipse IDE with it. VM seems to exit cleanly
> and didn't report any error messages.

Good work!

> Some of the remaining issues / observations are:
> (1)
> DRLVM startup is organized a bit differently compared to the classlib
> launcher startup, namely – the DRLVM after creating VM runs a special
> class called VMStart which is, in it's turn, asynchronously calling
> the main() method of the user application in a separate thread.
> When we go with the classlib's launcher, the main() method is executed
> in the same thread where the JavaVM is created.
> What are the caveats with that?

I've had a look in the drlvm code, and I see what you mean - run_java_main
is expecting to receive the class name as a parameter, then launch the
VMStart class before running main().

It is standard practice for a Java launcher to call CreateJavaVM(),
then carry out a findClass() and CallStaticObjectMethod() on the specified
class and main method. However, the launcher does not necessarily have to
run the main method first - anyone could write a custom launcher that
calls a static "runme()" method first, or something similar, so the VM
not expect main() to be the first method called when launched from the
invocation API.

So, if I understand the drlvm code right, the call sequence on startup using
the drlvm launcher is:

drlvm launcher calls vm_main()
vm_main() calls create_vm() (which is essentially CreateJavaVM)
create_vm() completes and returns
vm_main() calls run_main()
run_main() calls run_java_main()
run_java_main() creates the VMStart class and executes its start() method
run_java_main() creates the specified class and runs its main() method

When drlvm is launched using a generic launcher (such as the classlib
launcher) the sequence would probably need to be either:

launcher calls CreateJavaVM()
CreateJavaVM() passes call to create_vm()
create_vm() makes its usual calls, but also executes required VMStart
create_vm() and CreateJavaVM() both exit, returning control to the

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 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
completed within the CreateJavaVM() call.

Does this answer your question? Any other ideas?

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

> (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
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
if it wants to.


> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message