You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Tim Ellison <t....@gmail.com> on 2006/09/14 14:31:09 UTC
[vmi] Extending the VMI to allow setting a default portlib
At present, the Harmony launcher creates and passes an instance of the
portlib to the VM as it is being created (via an
_org.apache.harmony.vmi.portlib init arg). This is good because allows
the launcher to define functions used for memory alloc, file IO, etc. early.
However, we also need to work with regular applications that are
embedding the JVM, and don't know/want to set up this argument for us.
In such a case the classlib should use a default portlib (and possibly
JVM subsequently if it wants).
I propose that we retain support for the init arg, but make it optional,
and that we extend the VMI [1] to allow setting the portlib struct where
it has not been previously defined. The portlib struct can only be
defined once, subsequent attempts to set the portlib would return an
error. Of course, you can still modify the struct to redefine the
functions it contains.
The new VMI function would be:
vmiError(JNICALL * SetPortLibrary)
(VMInterface * vmi, HyPortLibrary * portlib);
then the early logic in JNI_OnLoad for luniglob.c [2] would become:
(a) if vmInterface->GetPortLibrary(vmi) is not NULL then continue
(b) otherwise create new portlib, and vmi->SetPortlib(vmi, portlib).
and the corresponding JNI_OnUnload would destroy the portlib iff it had
been created in step (b).
[1]
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/native/include/shared/vmi.h?revision=442941&view=markup
[2]
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/native/luni/shared/luniglob.c?revision=442941&view=markup
Comments?
Regards,
Tim
--
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
Re: [vmi] Extending the VMI to allow setting a default portlib
Posted by Oliver Deakin <ol...@googlemail.com>.
Thanks for resurrecting this Paulex, and for offering to take up the
task. It's had no objections for 6 months, so it should be ok ;) but
obviously if anyone sees any problems with this then please speak up.
Regards,
Oliver
Yang Paulex wrote:
> Sorry to reactivate this from the long past, if no objections, I'd
> like to
> implement Tim's original proposals in classlib part (i.e., create default
> portlib if necessary in JNI_OnLoad of luniglob.c, and extend VMI to add
> SetPortLibrary). I think it brings flexibility and makes API between
> classlib and VM more clear. I considered this will do no direct harm to
> current Harmony compatible VM like DRLVM, IBM VME or BEA JRockit, but I'm
> open to comments before doing that.
>
> 2006/9/18, Oliver Deakin <ol...@googlemail.com>:
>>
>> Tim Ellison wrote:
>> > Geir Magnusson Jr. wrote:
>> >
>> >> Tim Ellison wrote:
>> >>
>> >>> At present, the Harmony launcher creates and passes an instance
>> of the
>> >>> portlib to the VM as it is being created (via an
>> >>> _org.apache.harmony.vmi.portlib init arg). This is good because
>> allows
>> >>> the launcher to define functions used for memory alloc, file IO,
>> etc.
>> >>> early.
>> >>>
>> >>> However, we also need to work with regular applications that are
>> >>> embedding the JVM, and don't know/want to set up this argument
>> for us.
>> >>> In such a case the classlib should use a default portlib (and
>> possibly
>> >>> JVM subsequently if it wants).
>> >>>
>> >> This seems backwards to me. Wouldn't we want the VM use the default
>> >> portlib and give that to the classlib?
>> >>
>> >
>> > VMs that want to use the portlib can do that today anyway (e.g. drlvm
>> > was creating the portlib itself), so this would allow setting the
>> > portlib by the classlib where the VM doesn't care.
>> >
>> > So today, the launcher creates a portlib and passes it in as a VM
>> > property, and the VM stores the struct ptr in the VMI.
>> >
>> > I'm suggesting that we allow any one of:
>> > - VM takes the version passed in via the launcher property
>> > - VM creates a default version and puts it in VMI
>> > - classlib creates a default version and puts it in VMI
>> >
>>
>> This makes sense to me - it gives the most flexibility for when the port
>> library
>> is created. If the launcher doesnt do it, fall back to the VM. If the VM
>> doesnt do it, fall back to the classlib default. It seems sensible to
>> have
>> a failsafe in place, even if we never have to use it.
>>
>> Regards,
>> Oliver
>>
>> > Regards,
>> > Tim
>> >
>> >
>> >>> I propose that we retain support for the init arg, but make it
>> optional,
>> >>> and that we extend the VMI [1] to allow setting the portlib struct
>> where
>> >>> it has not been previously defined. The portlib struct can only be
>> >>> defined once, subsequent attempts to set the portlib would return an
>> >>> error. Of course, you can still modify the struct to redefine the
>> >>> functions it contains.
>> >>>
>> >>> The new VMI function would be:
>> >>> vmiError(JNICALL * SetPortLibrary)
>> >>> (VMInterface * vmi, HyPortLibrary * portlib);
>> >>>
>> >>> then the early logic in JNI_OnLoad for luniglob.c [2] would become:
>> >>> (a) if vmInterface->GetPortLibrary(vmi) is not NULL then continue
>> >>> (b) otherwise create new portlib, and vmi->SetPortlib(vmi,
>> portlib).
>> >>>
>> >>> and the corresponding JNI_OnUnload would destroy the portlib iff it
>> had
>> >>> been created in step (b).
>> >>>
>> >>>
>> >>> [1]
>> >>>
>> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/native/include/shared/vmi.h?revision=442941&view=markup
>>
>> >>>
>> >>> [2]
>> >>>
>> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/native/luni/shared/luniglob.c?revision=442941&view=markup
>>
>> >>>
>> >>>
>> >>> Comments?
>> >>>
>> >>> Regards,
>> >>> Tim
>> >>>
>> >>>
>> >> ---------------------------------------------------------------------
>> >> 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
>>
>>
>
>
--
Oliver Deakin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: [vmi] Extending the VMI to allow setting a default portlib
Posted by Yang Paulex <pa...@gmail.com>.
Sorry to reactivate this from the long past, if no objections, I'd like to
implement Tim's original proposals in classlib part (i.e., create default
portlib if necessary in JNI_OnLoad of luniglob.c, and extend VMI to add
SetPortLibrary). I think it brings flexibility and makes API between
classlib and VM more clear. I considered this will do no direct harm to
current Harmony compatible VM like DRLVM, IBM VME or BEA JRockit, but I'm
open to comments before doing that.
2006/9/18, Oliver Deakin <ol...@googlemail.com>:
>
> Tim Ellison wrote:
> > Geir Magnusson Jr. wrote:
> >
> >> Tim Ellison wrote:
> >>
> >>> At present, the Harmony launcher creates and passes an instance of the
> >>> portlib to the VM as it is being created (via an
> >>> _org.apache.harmony.vmi.portlib init arg). This is good because
> allows
> >>> the launcher to define functions used for memory alloc, file IO, etc.
> >>> early.
> >>>
> >>> However, we also need to work with regular applications that are
> >>> embedding the JVM, and don't know/want to set up this argument for us.
> >>> In such a case the classlib should use a default portlib (and possibly
> >>> JVM subsequently if it wants).
> >>>
> >> This seems backwards to me. Wouldn't we want the VM use the default
> >> portlib and give that to the classlib?
> >>
> >
> > VMs that want to use the portlib can do that today anyway (e.g. drlvm
> > was creating the portlib itself), so this would allow setting the
> > portlib by the classlib where the VM doesn't care.
> >
> > So today, the launcher creates a portlib and passes it in as a VM
> > property, and the VM stores the struct ptr in the VMI.
> >
> > I'm suggesting that we allow any one of:
> > - VM takes the version passed in via the launcher property
> > - VM creates a default version and puts it in VMI
> > - classlib creates a default version and puts it in VMI
> >
>
> This makes sense to me - it gives the most flexibility for when the port
> library
> is created. If the launcher doesnt do it, fall back to the VM. If the VM
> doesnt do it, fall back to the classlib default. It seems sensible to have
> a failsafe in place, even if we never have to use it.
>
> Regards,
> Oliver
>
> > Regards,
> > Tim
> >
> >
> >>> I propose that we retain support for the init arg, but make it
> optional,
> >>> and that we extend the VMI [1] to allow setting the portlib struct
> where
> >>> it has not been previously defined. The portlib struct can only be
> >>> defined once, subsequent attempts to set the portlib would return an
> >>> error. Of course, you can still modify the struct to redefine the
> >>> functions it contains.
> >>>
> >>> The new VMI function would be:
> >>> vmiError(JNICALL * SetPortLibrary)
> >>> (VMInterface * vmi, HyPortLibrary * portlib);
> >>>
> >>> then the early logic in JNI_OnLoad for luniglob.c [2] would become:
> >>> (a) if vmInterface->GetPortLibrary(vmi) is not NULL then continue
> >>> (b) otherwise create new portlib, and vmi->SetPortlib(vmi, portlib).
> >>>
> >>> and the corresponding JNI_OnUnload would destroy the portlib iff it
> had
> >>> been created in step (b).
> >>>
> >>>
> >>> [1]
> >>>
> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/native/include/shared/vmi.h?revision=442941&view=markup
> >>>
> >>> [2]
> >>>
> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/native/luni/shared/luniglob.c?revision=442941&view=markup
> >>>
> >>>
> >>> Comments?
> >>>
> >>> Regards,
> >>> Tim
> >>>
> >>>
> >> ---------------------------------------------------------------------
> >> 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
>
>
--
Paulex Yang
China Software Development laboratory
IBM
Re: [vmi] Extending the VMI to allow setting a default portlib
Posted by Oliver Deakin <ol...@googlemail.com>.
Tim Ellison wrote:
> Geir Magnusson Jr. wrote:
>
>> Tim Ellison wrote:
>>
>>> At present, the Harmony launcher creates and passes an instance of the
>>> portlib to the VM as it is being created (via an
>>> _org.apache.harmony.vmi.portlib init arg). This is good because allows
>>> the launcher to define functions used for memory alloc, file IO, etc.
>>> early.
>>>
>>> However, we also need to work with regular applications that are
>>> embedding the JVM, and don't know/want to set up this argument for us.
>>> In such a case the classlib should use a default portlib (and possibly
>>> JVM subsequently if it wants).
>>>
>> This seems backwards to me. Wouldn't we want the VM use the default
>> portlib and give that to the classlib?
>>
>
> VMs that want to use the portlib can do that today anyway (e.g. drlvm
> was creating the portlib itself), so this would allow setting the
> portlib by the classlib where the VM doesn't care.
>
> So today, the launcher creates a portlib and passes it in as a VM
> property, and the VM stores the struct ptr in the VMI.
>
> I'm suggesting that we allow any one of:
> - VM takes the version passed in via the launcher property
> - VM creates a default version and puts it in VMI
> - classlib creates a default version and puts it in VMI
>
This makes sense to me - it gives the most flexibility for when the port
library
is created. If the launcher doesnt do it, fall back to the VM. If the VM
doesnt do it, fall back to the classlib default. It seems sensible to have
a failsafe in place, even if we never have to use it.
Regards,
Oliver
> Regards,
> Tim
>
>
>>> I propose that we retain support for the init arg, but make it optional,
>>> and that we extend the VMI [1] to allow setting the portlib struct where
>>> it has not been previously defined. The portlib struct can only be
>>> defined once, subsequent attempts to set the portlib would return an
>>> error. Of course, you can still modify the struct to redefine the
>>> functions it contains.
>>>
>>> The new VMI function would be:
>>> vmiError(JNICALL * SetPortLibrary)
>>> (VMInterface * vmi, HyPortLibrary * portlib);
>>>
>>> then the early logic in JNI_OnLoad for luniglob.c [2] would become:
>>> (a) if vmInterface->GetPortLibrary(vmi) is not NULL then continue
>>> (b) otherwise create new portlib, and vmi->SetPortlib(vmi, portlib).
>>>
>>> and the corresponding JNI_OnUnload would destroy the portlib iff it had
>>> been created in step (b).
>>>
>>>
>>> [1]
>>> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/native/include/shared/vmi.h?revision=442941&view=markup
>>>
>>> [2]
>>> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/native/luni/shared/luniglob.c?revision=442941&view=markup
>>>
>>>
>>> Comments?
>>>
>>> Regards,
>>> Tim
>>>
>>>
>> ---------------------------------------------------------------------
>> 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
Re: [vmi] Extending the VMI to allow setting a default portlib
Posted by Alexey Varlamov <al...@gmail.com>.
+1
2006/9/15, Tim Ellison <t....@gmail.com>:
> Geir Magnusson Jr. wrote:
> >
> > Tim Ellison wrote:
> >> At present, the Harmony launcher creates and passes an instance of the
> >> portlib to the VM as it is being created (via an
> >> _org.apache.harmony.vmi.portlib init arg). This is good because allows
> >> the launcher to define functions used for memory alloc, file IO, etc.
> >> early.
> >>
> >> However, we also need to work with regular applications that are
> >> embedding the JVM, and don't know/want to set up this argument for us.
> >> In such a case the classlib should use a default portlib (and possibly
> >> JVM subsequently if it wants).
> >
> > This seems backwards to me. Wouldn't we want the VM use the default
> > portlib and give that to the classlib?
>
> VMs that want to use the portlib can do that today anyway (e.g. drlvm
> was creating the portlib itself), so this would allow setting the
> portlib by the classlib where the VM doesn't care.
>
> So today, the launcher creates a portlib and passes it in as a VM
> property, and the VM stores the struct ptr in the VMI.
>
> I'm suggesting that we allow any one of:
> - VM takes the version passed in via the launcher property
> - VM creates a default version and puts it in VMI
> - classlib creates a default version and puts it in VMI
>
> Regards,
> Tim
>
> >> I propose that we retain support for the init arg, but make it optional,
> >> and that we extend the VMI [1] to allow setting the portlib struct where
> >> it has not been previously defined. The portlib struct can only be
> >> defined once, subsequent attempts to set the portlib would return an
> >> error. Of course, you can still modify the struct to redefine the
> >> functions it contains.
> >>
> >> The new VMI function would be:
> >> vmiError(JNICALL * SetPortLibrary)
> >> (VMInterface * vmi, HyPortLibrary * portlib);
> >>
> >> then the early logic in JNI_OnLoad for luniglob.c [2] would become:
> >> (a) if vmInterface->GetPortLibrary(vmi) is not NULL then continue
> >> (b) otherwise create new portlib, and vmi->SetPortlib(vmi, portlib).
> >>
> >> and the corresponding JNI_OnUnload would destroy the portlib iff it had
> >> been created in step (b).
> >>
> >>
> >> [1]
> >> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/native/include/shared/vmi.h?revision=442941&view=markup
> >>
> >> [2]
> >> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/native/luni/shared/luniglob.c?revision=442941&view=markup
> >>
> >>
> >> Comments?
> >>
> >> Regards,
> >> Tim
> >>
> >
> > ---------------------------------------------------------------------
> > 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
> >
> >
>
> --
>
> 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
>
>
---------------------------------------------------------------------
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
Re: [vmi] Extending the VMI to allow setting a default portlib
Posted by Tim Ellison <t....@gmail.com>.
Geir Magnusson Jr. wrote:
>
> Tim Ellison wrote:
>> At present, the Harmony launcher creates and passes an instance of the
>> portlib to the VM as it is being created (via an
>> _org.apache.harmony.vmi.portlib init arg). This is good because allows
>> the launcher to define functions used for memory alloc, file IO, etc.
>> early.
>>
>> However, we also need to work with regular applications that are
>> embedding the JVM, and don't know/want to set up this argument for us.
>> In such a case the classlib should use a default portlib (and possibly
>> JVM subsequently if it wants).
>
> This seems backwards to me. Wouldn't we want the VM use the default
> portlib and give that to the classlib?
VMs that want to use the portlib can do that today anyway (e.g. drlvm
was creating the portlib itself), so this would allow setting the
portlib by the classlib where the VM doesn't care.
So today, the launcher creates a portlib and passes it in as a VM
property, and the VM stores the struct ptr in the VMI.
I'm suggesting that we allow any one of:
- VM takes the version passed in via the launcher property
- VM creates a default version and puts it in VMI
- classlib creates a default version and puts it in VMI
Regards,
Tim
>> I propose that we retain support for the init arg, but make it optional,
>> and that we extend the VMI [1] to allow setting the portlib struct where
>> it has not been previously defined. The portlib struct can only be
>> defined once, subsequent attempts to set the portlib would return an
>> error. Of course, you can still modify the struct to redefine the
>> functions it contains.
>>
>> The new VMI function would be:
>> vmiError(JNICALL * SetPortLibrary)
>> (VMInterface * vmi, HyPortLibrary * portlib);
>>
>> then the early logic in JNI_OnLoad for luniglob.c [2] would become:
>> (a) if vmInterface->GetPortLibrary(vmi) is not NULL then continue
>> (b) otherwise create new portlib, and vmi->SetPortlib(vmi, portlib).
>>
>> and the corresponding JNI_OnUnload would destroy the portlib iff it had
>> been created in step (b).
>>
>>
>> [1]
>> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/native/include/shared/vmi.h?revision=442941&view=markup
>>
>> [2]
>> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/native/luni/shared/luniglob.c?revision=442941&view=markup
>>
>>
>> Comments?
>>
>> Regards,
>> Tim
>>
>
> ---------------------------------------------------------------------
> 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
>
>
--
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
Re: [vmi] Extending the VMI to allow setting a default portlib
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Tim Ellison wrote:
> At present, the Harmony launcher creates and passes an instance of the
> portlib to the VM as it is being created (via an
> _org.apache.harmony.vmi.portlib init arg). This is good because allows
> the launcher to define functions used for memory alloc, file IO, etc. early.
>
> However, we also need to work with regular applications that are
> embedding the JVM, and don't know/want to set up this argument for us.
> In such a case the classlib should use a default portlib (and possibly
> JVM subsequently if it wants).
This seems backwards to me. Wouldn't we want the VM use the default
portlib and give that to the classlib?
>
> I propose that we retain support for the init arg, but make it optional,
> and that we extend the VMI [1] to allow setting the portlib struct where
> it has not been previously defined. The portlib struct can only be
> defined once, subsequent attempts to set the portlib would return an
> error. Of course, you can still modify the struct to redefine the
> functions it contains.
>
> The new VMI function would be:
> vmiError(JNICALL * SetPortLibrary)
> (VMInterface * vmi, HyPortLibrary * portlib);
>
> then the early logic in JNI_OnLoad for luniglob.c [2] would become:
> (a) if vmInterface->GetPortLibrary(vmi) is not NULL then continue
> (b) otherwise create new portlib, and vmi->SetPortlib(vmi, portlib).
>
> and the corresponding JNI_OnUnload would destroy the portlib iff it had
> been created in step (b).
>
>
> [1]
> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/native/include/shared/vmi.h?revision=442941&view=markup
> [2]
> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni/src/main/native/luni/shared/luniglob.c?revision=442941&view=markup
>
> Comments?
>
> Regards,
> Tim
>
---------------------------------------------------------------------
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