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, 19 Jul 2006 19:26:35 GMT
On 7/17/06, Oliver Deakin <oliver.deakin@googlemail.com> wrote:
> 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.

OK, I have added a simple check into the DestroyJavaVM method which
does processing of the pending exceptions in HARMONY-927.

Thanks,
Andrey.


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


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