harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrey Chernyshev" <a.y.chernys...@gmail.com>
Subject Re: [drlvm] using the harmony launcher
Date Wed, 12 Jul 2006 20:01:08 GMT
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.

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?

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

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

(5)
What to do with the "_org.apache.harmony.vmi.portlib" option that
launcher is offering to VM?

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
>


-- 
Andrey Chernyshev
Intel Middleware Products Division

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