Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of alexey.v.varlamov@gmail.com
 designates 66.249.82.202 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=nizLtW+lD4bpsBg2bTsL+LotzPmLDYrBOvm0V2Gdu5/66HV5/ouoQkxmKY/V4YuhEf9uBme8nNIhomYeXkn9fso5M8fKFunF6C7MXRzmCKhUk62Vew08MQuyQJWo4eu5Xg1E+09GxdMQmRzMXT6Af68np1E+jaVkm55ylibtzJA=
Message-ID: <f944d83d0607170152n114d5517gf9269feb04f87261@mail.gmail.com>
Date: Mon, 17 Jul 2006 15:52:10 +0700
From: "Alexey Varlamov" <alexey.v.varlamov@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [drlvm] using the harmony launcher
In-Reply-To: <6928c5160607141338w12bf3a1dxad59f75e59c8961a@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=WINDOWS-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <A1516037-7F46-4702-B515-C9644BE01F25@pobox.com>
	 <12385bbd0607100844v362dae5ev7bb26036d31a6449@mail.gmail.com>
	 <12385bbd0607100845p86f0c57j98b1b7440eefa008@mail.gmail.com>
	 <6928c5160607100922n1e42323cl63a68e3690526d56@mail.gmail.com>
	 <51d555c70607101941r494d8dcdodd7a3752056b2cf7@mail.gmail.com>
	 <44B34475.8010807@pobox.com>
	 <6928c5160607110217g55e73b4bwfc3df2ffe65a1e70@mail.gmail.com>
	 <6928c5160607121301i65796027vdc2e24fd33456f79@mail.gmail.com>
	 <44B6116F.5080609@gmail.com>
	 <6928c5160607141338w12bf3a1dxad59f75e59c8961a@mail.gmail.com>

2006/7/15, Andrey Chernyshev <a.y.chernyshev@gmail.com>:
> On 7/13/06, Tim Ellison <t.p.ellison@gmail.com> wrote:
> > 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 b=
e
> > > the most appropriate place for it);
> >
> > The existing jni.h in the HDK's jdk/include directory already has those
> > definitions.  The JNI function definitions are, of course, required by
> > the class library / tooling code.  We should probably just share one
> > copy of that file.
> >
> > > - 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?
> >
> > (see below)
> >
> > > 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
> >
> > Cool, they should be -X options, I'll change it in the launcher when
> > next in there.
> >
> > > and even was able to run Eclipse IDE with it. VM seems to exit cleanl=
y
> > > 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 =96 the DRLVM after creating VM runs a speci=
al
> > > class called VMStart which is, in it's turn, asynchronously calling
> > > the main() method of the user application in a separate thread.
> >
> > That's an interesting design choice.  So it always runs the
> > VMStart#start() method as soon as the VM is created?  So how do you
> > implement JNI_CreateJavaVM (which must not do that)?
>
> With the classlib launcher,  JNI_CreateJavaVM calls only initialize()
> method from VMStrart right now. The VMStart.start() is never called,
> so the main() method of the user app is invoked directly by the
> launcher. I do think this is the right way to start applications, at
> least this is what JNI spec suggests.
> However, I'd like to understand if we can just replace the current
> main() invocation scheme via VMstrat#start() in drlvm with a direct
> call to main() from the classlib launcher, or we actually need to do
> something more special about that.

If I grok it right, the current design with VMStart.start() was aimed
for 2 points:
1) Unify the way Java threads are created/attached. That is, the main
app thread only executes VM internal tasks (initialization &
shutdown), and delegates actual work to newly spawned Java threads.
2) Simplify or provide cleaner shutdown sequence. The main thread just
hooks up for Java thread termination events and checks if a died
thread was the last non-daemon one, then triggers shutdown process.

So, if my guess is correct, to depart from this schema painlessly we
need to ensure that correct provisions are taken for attaching the
main thread and move VMStart.shutdown() functionality to
DestroyJavaVM.

--
Alexey Varlamov
> >
> > Our tools etc. will have custom launchers that run different classes in
> > the o.a.h.tools package.
> >
> > > When we go with the classlib's launcher, the main() method is execute=
d
> > > in the same thread where the JavaVM is created.
> > > What are the caveats with that?
> >
> > Don't know, as you say the primordial thread does the JNI_CreateJavaVM
> > then goes on to CallStaticVoidMethod on the target's main().
> >
> > > (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.
> >
> > We can fix this in the launcher if you want, but cannot promise that
> > everyone else using the invocation API will do this for you.
> >
> > > 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 exceptio=
n
> > > 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.
> >
> > Ok, but I'd advise that the Destroy is made more robust too.
>
> I agree with that.
>
> >
> > > (3)
> > > CreateJavaVM can only be called once for now =96 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?).
> >
> > Too bad.
> >
> > > (4)
> > > Launcher wants the vm dll in the "default" directory unless the optio=
n
> > > is specified. Should we realign the drlvm build output and move all
> > > dll's into the "default" subdir?
> >
> > I'll let the different Harmony VM folk argue about who should be the
> > default ;-)  I agree that it should no longer be the IBM VME.
> >
> > > (5)
> > > What to do with the "_org.apache.harmony.vmi.portlib" option that
> > > launcher is offering to VM?
> >
> > So the laucher creates the portlib function table so it can do OS thing=
s
> > (like write NLS messages, and open the VM DLLs etc), it then passes the
> > portlib in to the VM as this argument.
>
> How the string "_org.apache.harmony.vmi.portlib" which is passed to VM
> as an argument maps to a function table created by launcher? On VM
> side, I guess I'm getting only that string from the launcher about the
> portlib, nothing else...
>
> >
> > You can choose to ignore it, but since you are required to return a
> > portlib from the VMI's GetPortLibrary call, you might as well just
> > remember it.
> >
> > It would be more polite to remember the one you were given so that the
> > caller can install their own portlib functions and have them back again
> > onthe VMI calls.
>
> So it sounds like the launcher creates portlib, passes it to VM and
> then expects it to be returned back from VM. What's the purpose of
> doing that?
> Shall we consider the portlib as a part of classlib or VM? If the
> classlib is responsible for instantiation of the portlib,  then why
> the classlib should be expecting to get it once again from VM? I'm
> sure there must be some tricks there which I'm not getting yet...
>
> Thanks,
> Andrey.
>
> >
> > > Most likely there are more issues that I'm overlooking at the moment.
> > > Please consider the suggested patch is a workaround to make the thing=
s
> > > working, I'm wondering if there is a more graceful way to do this.
> >
> > Good work Andrey, keep sending the questions and patches!
> >
> > Regards,
> > Tim
> >
> >
> > > 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 wi=
th
> > >> 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 worki=
ng
> > >> > using the launcher and then fix as required.  It's arguable if tha=
t
> > >> > "brokenness" matters at this point, and I think that there's plent=
y 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_CreateJ=
avaVM
> > >> > >> >and DestroyJavaVM functions.
> > >> > >>
> > >> > >> >I couldn't find implementation for CreateJavaVM in drlvm codeb=
ase.
> > >> > >> >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 bef=
ore
> > >> > >> >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 improv=
ed 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.apach=
e.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.o=
rg
> > >> > For additional commands, e-mail: harmony-dev-help@incubator.apache=
.org
> > >> >
> > >> >
> > >>
> > >>
> > >> --
> > >> Andrey Chernyshev
> > >> Intel Middleware Products Division
> > >>
> > >
> > >
> >
> > --
> >
> > Tim Ellison (t.p.ellison@gmail.com)
> > IBM Java technology centre, UK.
> >
> > ---------------------------------------------------------------------
> > 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
>
>

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