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/11/16 14:10:53 UTC
Re: [jira] Created: (HARMONY-2201) [classlib][luni] Add creation
of stub jvm.dll to luni module
Oliver Deakin (JIRA) wrote:
> [classlib][luni] Add creation of stub jvm.dll to luni module
> ------------------------------------------------------------
>
> Key: HARMONY-2201
> URL: http://issues.apache.org/jira/browse/HARMONY-2201
> Project: Harmony
> Issue Type: Improvement
> Components: Classlib
> Reporter: Oliver Deakin
> Priority: Minor
>
>
> It is standard practise when writing a VM launcher to link against
> invocation API providing libraries called jvm.dll/libjvm.so. The RI and
> J9 VMs both follow the convention of placing a jvm.lib file (on Windows)
> into <jdk>/lib, and the actual jvm.dll/libjvm.so in the appropriate
> place under jre/bin. Harmony differs from this convention in two ways:
>
> 1) There is no jvm.lib provided in the deploy/jdk/lib directory. This
> means that any Windows user writing a custom launcher will not be able
> to make calls to our invocation API. It makes sense in this case to
> create a stubbed set of invocation API natives to build a jvm.lib in the
> appropriate place. We currently do something similar to create a stubbed
> vmi.lib for linking against.
>
> 2) The libraries providing the invocation API are currently called
> harmonyvm.dll/libharmonyvm.so. I would suggest that these are renamed to
> jvm.dll/libjvm.so to follow the conventional naming scheme.
This seems like an eminently reasonable suggestion.
Anyone object? If not I'll hack the jvm.lib and make the launcher look
for both names to allow for a transition.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [jira] Created: (HARMONY-2201) [classlib][luni] Add creation
of stub jvm.dll to luni module
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
ok...
Tim Ellison wrote:
> Geir Magnusson Jr. wrote:
>> My thinking is that we should support the convention, but we're also
>> trying to create another convention with VMI.
>>
>> Would the vmi.dll be usable by other implementors?
>
> Not really, since implementers have to hold on to our VMI function
> struct from the JavaVM / JNIEnv, and we can't write that portably
> (across implementations).
>
> Regards,
> Tim
>
Re: [jira] Created: (HARMONY-2201) [classlib][luni] Add creation
of stub jvm.dll to luni module
Posted by Tim Ellison <t....@gmail.com>.
Geir Magnusson Jr. wrote:
> My thinking is that we should support the convention, but we're also
> trying to create another convention with VMI.
>
> Would the vmi.dll be usable by other implementors?
Not really, since implementers have to hold on to our VMI function
struct from the JavaVM / JNIEnv, and we can't write that portably
(across implementations).
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [jira] Created: (HARMONY-2201) [classlib][luni] Add creation
of stub jvm.dll to luni module
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
My thinking is that we should support the convention, but we're also
trying to create another convention with VMI.
Would the vmi.dll be usable by other implementors?
geir
Tim Ellison wrote:
> Geir Magnusson Jr. wrote:
>> We are doing this to conform to some convention, right? If the
>> covention for jvm.dll is a standard invocation API, why would we also
>> bundle in the harmony-specific VMI API?
>
> No, take a look at the exports from a jvm.dll, it is the standard
> invocation API + vm-specific APIs. I suggest we do the same (though in
> our case it is the two additional Harmony-specific VMI functions).
>
>> Why not keep that separate and try to push that forward as a convention
>> as well?
>
> Why try create another convention when there is one in use in the wild?
>
> Regards,
> Tim
>
Re: [jira] Created: (HARMONY-2201) [classlib][luni] Add creation of stub jvm.dll to luni module
Posted by Alexey Varlamov <al...@gmail.com>.
+1 for common jvm.lib.
I'm already asked myself looking at drlvm's vmi impl - why do we need
this as separate lib, and could not find any compelling reason. On the
contrary, we would need to provide extra interface vm->vmi for
completing VMLS in DRLVM if we keep those libs separate.
2006/11/17, Tim Ellison <t....@gmail.com>:
> Geir Magnusson Jr. wrote:
> > We are doing this to conform to some convention, right? If the
> > covention for jvm.dll is a standard invocation API, why would we also
> > bundle in the harmony-specific VMI API?
>
> No, take a look at the exports from a jvm.dll, it is the standard
> invocation API + vm-specific APIs. I suggest we do the same (though in
> our case it is the two additional Harmony-specific VMI functions).
>
> > Why not keep that separate and try to push that forward as a convention
> > as well?
>
> Why try create another convention when there is one in use in the wild?
>
> Regards,
> Tim
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
Re: [jira] Created: (HARMONY-2201) [classlib][luni] Add creation
of stub jvm.dll to luni module
Posted by Tim Ellison <t....@gmail.com>.
Geir Magnusson Jr. wrote:
> We are doing this to conform to some convention, right? If the
> covention for jvm.dll is a standard invocation API, why would we also
> bundle in the harmony-specific VMI API?
No, take a look at the exports from a jvm.dll, it is the standard
invocation API + vm-specific APIs. I suggest we do the same (though in
our case it is the two additional Harmony-specific VMI functions).
> Why not keep that separate and try to push that forward as a convention
> as well?
Why try create another convention when there is one in use in the wild?
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [jira] Created: (HARMONY-2201) [classlib][luni] Add creation
of stub jvm.dll to luni module
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Tim Ellison wrote:
> Geir Magnusson Jr. wrote:
>> Tim Ellison wrote:
>>> Now I've written all that, I it's clear that we should roll the VMI
>>> functions into the jvm.dll too, and get rid of vmi.dll. The jvm.dll
>>> would export both sets of functions, i.e.
>>> JNI_CreateJavaVM
>>> JNI_GetCreatedJavaVMs
>>> JNI_GetDefaultJavaVMInitArgs
>>> VMI_GetVMIFromJNIEnv
>>> VMI_GetVMIFromJavaVM
>>>
>>> What do you thing?
>> Why? What's wrong with both? Seems clearer to separate, and prevents
>> charges of "vendor lock in" :)
>
> You'll have to explain that comment to me.
>
> Today, to use the VM a program has to load a particular implementation
> of harmonyvm.dll, and our classlib code links against vmi.lib and uses a
> particular vmi.dll.
>
> I'm proposing that to use the VM any program can link against jvm.lib
> but has to load a particular implementation of jvm.dll; and our classlib
> code also links against jvm.lib and uses the same jvm.dll.
>
> How is the second scenario harmony-specific and not the first?
We are doing this to conform to some convention, right? If the
covention for jvm.dll is a standard invocation API, why would we also
bundle in the harmony-specific VMI API?
Why not keep that separate and try to push that forward as a convention
as well?
geir
Re: [jira] Created: (HARMONY-2201) [classlib][luni] Add creation
of stub jvm.dll to luni module
Posted by Tim Ellison <t....@gmail.com>.
Geir Magnusson Jr. wrote:
> Tim Ellison wrote:
>> Now I've written all that, I it's clear that we should roll the VMI
>> functions into the jvm.dll too, and get rid of vmi.dll. The jvm.dll
>> would export both sets of functions, i.e.
>> JNI_CreateJavaVM
>> JNI_GetCreatedJavaVMs
>> JNI_GetDefaultJavaVMInitArgs
>> VMI_GetVMIFromJNIEnv
>> VMI_GetVMIFromJavaVM
>>
>> What do you thing?
>
> Why? What's wrong with both? Seems clearer to separate, and prevents
> charges of "vendor lock in" :)
You'll have to explain that comment to me.
Today, to use the VM a program has to load a particular implementation
of harmonyvm.dll, and our classlib code links against vmi.lib and uses a
particular vmi.dll.
I'm proposing that to use the VM any program can link against jvm.lib
but has to load a particular implementation of jvm.dll; and our classlib
code also links against jvm.lib and uses the same jvm.dll.
How is the second scenario harmony-specific and not the first?
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [jira] Created: (HARMONY-2201) [classlib][luni] Add creation
of stub jvm.dll to luni module
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Tim Ellison wrote:
> Mikhail Loenko wrote:
>> Is this lib VM-specific?
>
> No, er, yes, er, ... let me try to explain.
>
> In the jre/bin/<vm> sub directories we have harmonyvm.dll's (which are
> VM-specific), but we use the name and function export convention to code
> against any compliant impl. The RI others call their equivalent jvm.dll
> so the proposal is that we do the same for Harmony's convention because...
>
> ...we currently don't provide a harmonyvm.lib to link against in our
> jdk/lib directory, and apps that embed the VM would expect to have that.
Yeah - I just had to work around that w/ my embedding eperiment.
>
> The idea would be to create a stub (like we do for the vmi.lib) and
> leave the concrete code in the vm-specific subdirs. Again, calling this
> jvm.lib means we look and feel just like the RI which helps users. If
> users really want to hard link against a particular VM-impl then we can
> provide non-stub jvm.lib's in the vm-specific subdirectories (again like
> the vmi.lib).
>
> Now I've written all that, I it's clear that we should roll the VMI
> functions into the jvm.dll too, and get rid of vmi.dll. The jvm.dll
> would export both sets of functions, i.e.
> JNI_CreateJavaVM
> JNI_GetCreatedJavaVMs
> JNI_GetDefaultJavaVMInitArgs
> VMI_GetVMIFromJNIEnv
> VMI_GetVMIFromJavaVM
>
> What do you thing?
Why? What's wrong with both? Seems clearer to separate, and prevents
charges of "vendor lock in" :)
>
>> Are we going to have one more VM-specific lib in the common dir?
>
> Do you mean threadlib? It's destined to become common code.
>
> Regards,
> Tim
>
>> 2006/11/16, Tim Ellison <t....@gmail.com>:
>>> Oliver Deakin (JIRA) wrote:
>>>> [classlib][luni] Add creation of stub jvm.dll to luni module
>>>> ------------------------------------------------------------
>>>>
>>>> Key: HARMONY-2201
>>>> URL: http://issues.apache.org/jira/browse/HARMONY-2201
>>>> Project: Harmony
>>>> Issue Type: Improvement
>>>> Components: Classlib
>>>> Reporter: Oliver Deakin
>>>> Priority: Minor
>>>>
>>>>
>>>> It is standard practise when writing a VM launcher to link against
>>>> invocation API providing libraries called jvm.dll/libjvm.so. The RI and
>>>> J9 VMs both follow the convention of placing a jvm.lib file (on
>>> Windows)
>>>> into <jdk>/lib, and the actual jvm.dll/libjvm.so in the appropriate
>>>> place under jre/bin. Harmony differs from this convention in two ways:
>>>>
>>>> 1) There is no jvm.lib provided in the deploy/jdk/lib directory. This
>>>> means that any Windows user writing a custom launcher will not be able
>>>> to make calls to our invocation API. It makes sense in this case to
>>>> create a stubbed set of invocation API natives to build a jvm.lib in
>>> the
>>>> appropriate place. We currently do something similar to create a
>>> stubbed
>>>> vmi.lib for linking against.
>>>>
>>>> 2) The libraries providing the invocation API are currently called
>>>> harmonyvm.dll/libharmonyvm.so. I would suggest that these are
>>> renamed to
>>>> jvm.dll/libjvm.so to follow the conventional naming scheme.
>>>
>>> This seems like an eminently reasonable suggestion.
>>> Anyone object? If not I'll hack the jvm.lib and make the launcher look
>>> for both names to allow for a transition.
>>>
>>> Regards,
>>> Tim
>>>
>>> --
>>>
>>> Tim Ellison (t.p.ellison@gmail.com)
>>> IBM Java technology centre, UK.
>>>
>
Re: [jira] Created: (HARMONY-2201) [classlib][luni] Add creation of stub jvm.dll to luni module
Posted by Mikhail Loenko <ml...@gmail.com>.
2006/11/16, Tim Ellison <t....@gmail.com>:
> Mikhail Loenko wrote:
> > Is this lib VM-specific?
>
> No, er, yes, er, ... let me try to explain.
>
> In the jre/bin/<vm> sub directories we have harmonyvm.dll's (which are
> VM-specific), but we use the name and function export convention to code
> against any compliant impl. The RI others call their equivalent jvm.dll
> so the proposal is that we do the same for Harmony's convention because...
>
> ...we currently don't provide a harmonyvm.lib to link against in our
> jdk/lib directory, and apps that embed the VM would expect to have that.
>
> The idea would be to create a stub (like we do for the vmi.lib) and
> leave the concrete code in the vm-specific subdirs. Again, calling this
> jvm.lib means we look and feel just like the RI which helps users. If
> users really want to hard link against a particular VM-impl then we can
> provide non-stub jvm.lib's in the vm-specific subdirectories (again like
> the vmi.lib).
>
> Now I've written all that, I it's clear that we should roll the VMI
> functions into the jvm.dll too, and get rid of vmi.dll. The jvm.dll
> would export both sets of functions, i.e.
> JNI_CreateJavaVM
> JNI_GetCreatedJavaVMs
> JNI_GetDefaultJavaVMInitArgs
> VMI_GetVMIFromJNIEnv
> VMI_GetVMIFromJavaVM
>
> What do you thing?
if the stub is the same for each VM then +1 from me
Thanks,
Mikhail
>
> > Are we going to have one more VM-specific lib in the common dir?
>
> Do you mean threadlib? It's destined to become common code.
>
> Regards,
> Tim
>
> > 2006/11/16, Tim Ellison <t....@gmail.com>:
> >> Oliver Deakin (JIRA) wrote:
> >> > [classlib][luni] Add creation of stub jvm.dll to luni module
> >> > ------------------------------------------------------------
> >> >
> >> > Key: HARMONY-2201
> >> > URL: http://issues.apache.org/jira/browse/HARMONY-2201
> >> > Project: Harmony
> >> > Issue Type: Improvement
> >> > Components: Classlib
> >> > Reporter: Oliver Deakin
> >> > Priority: Minor
> >> >
> >> >
> >> > It is standard practise when writing a VM launcher to link against
> >> > invocation API providing libraries called jvm.dll/libjvm.so. The RI and
> >> > J9 VMs both follow the convention of placing a jvm.lib file (on
> >> Windows)
> >> > into <jdk>/lib, and the actual jvm.dll/libjvm.so in the appropriate
> >> > place under jre/bin. Harmony differs from this convention in two ways:
> >> >
> >> > 1) There is no jvm.lib provided in the deploy/jdk/lib directory. This
> >> > means that any Windows user writing a custom launcher will not be able
> >> > to make calls to our invocation API. It makes sense in this case to
> >> > create a stubbed set of invocation API natives to build a jvm.lib in
> >> the
> >> > appropriate place. We currently do something similar to create a
> >> stubbed
> >> > vmi.lib for linking against.
> >> >
> >> > 2) The libraries providing the invocation API are currently called
> >> > harmonyvm.dll/libharmonyvm.so. I would suggest that these are
> >> renamed to
> >> > jvm.dll/libjvm.so to follow the conventional naming scheme.
> >>
> >>
> >> This seems like an eminently reasonable suggestion.
> >> Anyone object? If not I'll hack the jvm.lib and make the launcher look
> >> for both names to allow for a transition.
> >>
> >> Regards,
> >> Tim
> >>
> >> --
> >>
> >> Tim Ellison (t.p.ellison@gmail.com)
> >> IBM Java technology centre, UK.
> >>
> >
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
Re: [jira] Created: (HARMONY-2201) [classlib][luni] Add creation
of stub jvm.dll to luni module
Posted by Tim Ellison <t....@gmail.com>.
Mikhail Loenko wrote:
> Is this lib VM-specific?
No, er, yes, er, ... let me try to explain.
In the jre/bin/<vm> sub directories we have harmonyvm.dll's (which are
VM-specific), but we use the name and function export convention to code
against any compliant impl. The RI others call their equivalent jvm.dll
so the proposal is that we do the same for Harmony's convention because...
...we currently don't provide a harmonyvm.lib to link against in our
jdk/lib directory, and apps that embed the VM would expect to have that.
The idea would be to create a stub (like we do for the vmi.lib) and
leave the concrete code in the vm-specific subdirs. Again, calling this
jvm.lib means we look and feel just like the RI which helps users. If
users really want to hard link against a particular VM-impl then we can
provide non-stub jvm.lib's in the vm-specific subdirectories (again like
the vmi.lib).
Now I've written all that, I it's clear that we should roll the VMI
functions into the jvm.dll too, and get rid of vmi.dll. The jvm.dll
would export both sets of functions, i.e.
JNI_CreateJavaVM
JNI_GetCreatedJavaVMs
JNI_GetDefaultJavaVMInitArgs
VMI_GetVMIFromJNIEnv
VMI_GetVMIFromJavaVM
What do you thing?
> Are we going to have one more VM-specific lib in the common dir?
Do you mean threadlib? It's destined to become common code.
Regards,
Tim
> 2006/11/16, Tim Ellison <t....@gmail.com>:
>> Oliver Deakin (JIRA) wrote:
>> > [classlib][luni] Add creation of stub jvm.dll to luni module
>> > ------------------------------------------------------------
>> >
>> > Key: HARMONY-2201
>> > URL: http://issues.apache.org/jira/browse/HARMONY-2201
>> > Project: Harmony
>> > Issue Type: Improvement
>> > Components: Classlib
>> > Reporter: Oliver Deakin
>> > Priority: Minor
>> >
>> >
>> > It is standard practise when writing a VM launcher to link against
>> > invocation API providing libraries called jvm.dll/libjvm.so. The RI and
>> > J9 VMs both follow the convention of placing a jvm.lib file (on
>> Windows)
>> > into <jdk>/lib, and the actual jvm.dll/libjvm.so in the appropriate
>> > place under jre/bin. Harmony differs from this convention in two ways:
>> >
>> > 1) There is no jvm.lib provided in the deploy/jdk/lib directory. This
>> > means that any Windows user writing a custom launcher will not be able
>> > to make calls to our invocation API. It makes sense in this case to
>> > create a stubbed set of invocation API natives to build a jvm.lib in
>> the
>> > appropriate place. We currently do something similar to create a
>> stubbed
>> > vmi.lib for linking against.
>> >
>> > 2) The libraries providing the invocation API are currently called
>> > harmonyvm.dll/libharmonyvm.so. I would suggest that these are
>> renamed to
>> > jvm.dll/libjvm.so to follow the conventional naming scheme.
>>
>>
>> This seems like an eminently reasonable suggestion.
>> Anyone object? If not I'll hack the jvm.lib and make the launcher look
>> for both names to allow for a transition.
>>
>> Regards,
>> Tim
>>
>> --
>>
>> Tim Ellison (t.p.ellison@gmail.com)
>> IBM Java technology centre, UK.
>>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [jira] Created: (HARMONY-2201) [classlib][luni] Add creation of stub jvm.dll to luni module
Posted by Mikhail Loenko <ml...@gmail.com>.
Is this lib VM-specific?
Are we going to have one more VM-specific lib in the common dir?
Thanks,
Mikhail
2006/11/16, Tim Ellison <t....@gmail.com>:
> Oliver Deakin (JIRA) wrote:
> > [classlib][luni] Add creation of stub jvm.dll to luni module
> > ------------------------------------------------------------
> >
> > Key: HARMONY-2201
> > URL: http://issues.apache.org/jira/browse/HARMONY-2201
> > Project: Harmony
> > Issue Type: Improvement
> > Components: Classlib
> > Reporter: Oliver Deakin
> > Priority: Minor
> >
> >
> > It is standard practise when writing a VM launcher to link against
> > invocation API providing libraries called jvm.dll/libjvm.so. The RI and
> > J9 VMs both follow the convention of placing a jvm.lib file (on Windows)
> > into <jdk>/lib, and the actual jvm.dll/libjvm.so in the appropriate
> > place under jre/bin. Harmony differs from this convention in two ways:
> >
> > 1) There is no jvm.lib provided in the deploy/jdk/lib directory. This
> > means that any Windows user writing a custom launcher will not be able
> > to make calls to our invocation API. It makes sense in this case to
> > create a stubbed set of invocation API natives to build a jvm.lib in the
> > appropriate place. We currently do something similar to create a stubbed
> > vmi.lib for linking against.
> >
> > 2) The libraries providing the invocation API are currently called
> > harmonyvm.dll/libharmonyvm.so. I would suggest that these are renamed to
> > jvm.dll/libjvm.so to follow the conventional naming scheme.
>
>
> This seems like an eminently reasonable suggestion.
> Anyone object? If not I'll hack the jvm.lib and make the launcher look
> for both names to allow for a transition.
>
> Regards,
> Tim
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
Re: [jira] Created: (HARMONY-2201) [classlib][luni] Add creation
of stub jvm.dll to luni module
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
I dont' care, but as you said, have it search for both for now...
Tim Ellison wrote:
> Oliver Deakin (JIRA) wrote:
>> [classlib][luni] Add creation of stub jvm.dll to luni module
>> ------------------------------------------------------------
>>
>> Key: HARMONY-2201
>> URL: http://issues.apache.org/jira/browse/HARMONY-2201
>> Project: Harmony
>> Issue Type: Improvement
>> Components: Classlib
>> Reporter: Oliver Deakin
>> Priority: Minor
>>
>>
>> It is standard practise when writing a VM launcher to link against
>> invocation API providing libraries called jvm.dll/libjvm.so. The RI and
>> J9 VMs both follow the convention of placing a jvm.lib file (on Windows)
>> into <jdk>/lib, and the actual jvm.dll/libjvm.so in the appropriate
>> place under jre/bin. Harmony differs from this convention in two ways:
>>
>> 1) There is no jvm.lib provided in the deploy/jdk/lib directory. This
>> means that any Windows user writing a custom launcher will not be able
>> to make calls to our invocation API. It makes sense in this case to
>> create a stubbed set of invocation API natives to build a jvm.lib in the
>> appropriate place. We currently do something similar to create a stubbed
>> vmi.lib for linking against.
>>
>> 2) The libraries providing the invocation API are currently called
>> harmonyvm.dll/libharmonyvm.so. I would suggest that these are renamed to
>> jvm.dll/libjvm.so to follow the conventional naming scheme.
>
>
> This seems like an eminently reasonable suggestion.
> Anyone object? If not I'll hack the jvm.lib and make the launcher look
> for both names to allow for a transition.
>
> Regards,
> Tim
>