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 20:02:54 GMT
On 7/17/06, Oliver Deakin <oliver.deakin@googlemail.com> wrote:
> Andrey Chernyshev wrote:
> > On 7/13/06, Tim Ellison <t.p.ellison@gmail.com> wrote:
> >> Andrey Chernyshev wrote:
> >> <snip>
> >>
> >>
> >> > (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?
> >>
> >> 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 things
> >> (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...
>
> The _org.apache.harmony.vmi.portlib option is passed to the VM
> as a JavaVMOption struct (defined in jni.h) that looks like:
>
> typedef struct JavaVMOption
> {
>   char *optionString;
>   void *extraInfo;
> } JavaVMOption;
>
> When the launcher passes the _org.apache.harmony.vmi.portlib option
> to the VM it sets optionString to be "_org.apache.harmony.vmi.portlib"
> and extraInfo to be the pointer to the port library. We can see this in
> modules/luni/src/main/native/launcher/shared/main.c:
>
>   options[j].optionString = portLibOptionStr;
>   options[j].extraInfo = portLibrary;
>
> So, on the VM side, once you find the JavaVMOption that has
> optionString=="_org.apache.harmony.vmi.portlib", then its extraInfo
> field will contain the relevant port library pointer.
>
>
> >
> >>
> >> 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?
>
> Kind of... Remember that the launcher isn't technically part of the
> class library native code (it really should be completely separate
> from classlib - what happened to the plan to move it out of classlib?).
> So what actually happens is that the launcher creates a port library
> and passes it to the VM. The VM stores this portlib pointer away
> somewhere for future use.
> One of the VMI functions provided by the VM is GetPortLibrary()
> (the VMInterfaceFunctions struct is declared in
> modules/luni/src/main/native/include/shared/vmi.h). So when the
> Harmony classlib natives call this function they expect to receive
> a pointer to an HyPortLibrary from the VM- since the VM has
> already been given one by the launcher, it can just return that one.
>
> > 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...
>
> I hope that what Ive described above might clarify things slightly -
> that the portlib is created by the launcher, which isn't really part
> of the classlib, then passed to the VM to be given to the classlib
> upon request in the future.

Thanks Oliver, this does clarify a lot. I'll see if I could change
drlvm's vmi impl such that it transfers the original portlib pointer
obtained from the launcher.
BTW: are we expecting to have the multiple instances of the port
library? Can't it be a singleton those instance is simply obtained via
GetPortLibrary() function exported in hyprt.dll or whatever? I'm
wondering if we really need to pass the pointer throughout the
different parts of a the system.

Thanks,
Andrey.


>
> Regards,
> Oliver
>
> >
> > 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 things
> >> > 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
> >> 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
> >> >>
> >> >
> >> >
> >>
> >> --
> >>
> >> 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
> >>
> >>
> >
> >
>
> --
> 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