Return-Path: 
 <harmony-dev-return-10361-apmail-incubator-harmony-dev-archive=incubator.apache.org@incubator.apache.org>
Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org
Received: (qmail 60277 invoked from network); 17 Jul 2006 16:16:06 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 17 Jul 2006 16:16:06 -0000
Received: (qmail 53311 invoked by uid 500); 17 Jul 2006 16:16:03 -0000
Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org
Received: (qmail 53191 invoked by uid 500); 17 Jul 2006 16:16:03 -0000
Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:harmony-dev-help@incubator.apache.org>
List-Unsubscribe: <mailto:harmony-dev-unsubscribe@incubator.apache.org>
List-Post: <mailto:harmony-dev@incubator.apache.org>
List-Id: <harmony-dev.incubator.apache.org>
Reply-To: harmony-dev@incubator.apache.org
Delivered-To: mailing list harmony-dev@incubator.apache.org
Received: (qmail 53174 invoked by uid 99); 17 Jul 2006 16:16:03 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 17 Jul 2006 09:16:03 -0700
X-ASF-Spam-Status: No, hits=1.2 required=10.0
	tests=RCVD_IN_SORBS_WEB,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (asf.osuosl.org: domain of oliver.deakin@googlemail.com
 designates 64.233.182.184 as permitted sender)
Received: from [64.233.182.184] (HELO nf-out-0910.google.com) (64.233.182.184)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 17 Jul 2006 09:16:02 -0700
Received: by nf-out-0910.google.com with SMTP id c2so4914nfe
        for <harmony-dev@incubator.apache.org>;
 Mon, 17 Jul 2006 09:15:40 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=googlemail.com;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=Hm/8yUIbFKdkoMMMvgCcV0+7kiDcwbTb2wNMSIwAh4KaEMKKf/EV9lB4zCNe6iQL4OySB04jA4IshzBD1VjzP4r5n+pg0j28KZkenSVZZ0xkc1TnU8jU4xi/HBNheWJbm8rAka6CyeD+G/chUt/FnR5OgDZvSBm6auC1Jufg8r8=
Received: by 10.49.55.13 with SMTP id h13mr2105219nfk;
        Mon, 17 Jul 2006 09:15:40 -0700 (PDT)
Received: from ?9.20.183.162? ( [195.212.29.67])
        by mx.gmail.com with ESMTP id a23sm2532734nfc.2006.07.17.09.15.39;
        Mon, 17 Jul 2006 09:15:39 -0700 (PDT)
Message-ID: <44BBB7AA.4070105@googlemail.com>
Date: Mon, 17 Jul 2006 17:15:38 +0100
From: Oliver Deakin <oliver.deakin@googlemail.com>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: [drlvm] using the harmony launcher
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>
In-Reply-To: <6928c5160607141338w12bf3a1dxad59f75e59c8961a@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

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.

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