You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Mikhail Fursov <mi...@gmail.com> on 2006/10/20 09:00:14 UTC
[drlvm] Using JNI methods in VM's components.
All,
AFAIK today I can't add JNI method to a component (em library, gc library,
jit library) and call the method from Java.
Is there any reason why do we have this limitation?
I have only the one, but IMO very serious reason why to allow it: a part of
a component could be written in Java.
The example is EMThreadSupport.java class. This class is a part of the
kernel classes but this is wrong.
I can't extend its functionality without modification of VM-EM native
interface.
?
--
Mikhail Fursov
Re: [drlvm] Using JNI methods in VM's components.
Posted by Mikhail Fursov <mi...@gmail.com>.
On 10/20/06, Ivan Volosyuk <iv...@gmail.com> wrote:
>
> One thing to care about is to take correct corresponding jar file for
> each gc library. How this can be solved?
>
This is one of the main problems in helpers fast-path inlining task!
I thought about the following: GC sets system variable "gc.helper_class" if
it wants JIT to use java helpers.
JIT runs the resolution if the property is set.
Is it ok?
--
Mikhail Fursov
Re: [drlvm] Using JNI methods in VM's components.
Posted by Ivan Volosyuk <iv...@gmail.com>.
One thing to care about is to take correct corresponding jar file for
each gc library. How this can be solved?
--
Ivan
On 10/20/06, Gregory Shimansky <gs...@gmail.com> wrote:
> Alex Astapchuk wrote:
> > Mikhail Fursov :
> >> On 10/20/06, Alex Astapchuk <al...@gmail.com> wrote:
> >>>
> >>> Yeap.
> >>> The following addresse both your issues.
> >>>
> >>>
> >>> class GCv5Magics {
> >>> static {
> >>> String gcPath = System.getProperty("vm.gc_dll");
> >>> if (gcPath == null) {
> >>> System.load(gcPath);
> >>> }
> >>> else {
> >>> System.loadLibrary("gc.dll");
> >>> }
> >>> }
> >>> }
> >>>
> >>>
> >> I like this approach! :)
> >
> >
> > You will like it even more with a patch (already posted) ;-)
>
> I like this way too. I didn't know about System.load method, it fits
> perfectly here. One small correction, it should be
> System.loadLibrary("gc") without ".dll".
>
> --
> Gregory Shimansky, Intel Middleware Products Division
--
Ivan
Intel Enterprise Solutions Software 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
Re: [drlvm] Using JNI methods in VM's components.
Posted by Gregory Shimansky <gs...@gmail.com>.
Alex Astapchuk wrote:
> Mikhail Fursov :
>> On 10/20/06, Alex Astapchuk <al...@gmail.com> wrote:
>>>
>>> Yeap.
>>> The following addresse both your issues.
>>>
>>>
>>> class GCv5Magics {
>>> static {
>>> String gcPath = System.getProperty("vm.gc_dll");
>>> if (gcPath == null) {
>>> System.load(gcPath);
>>> }
>>> else {
>>> System.loadLibrary("gc.dll");
>>> }
>>> }
>>> }
>>>
>>>
>> I like this approach! :)
>
>
> You will like it even more with a patch (already posted) ;-)
I like this way too. I didn't know about System.load method, it fits
perfectly here. One small correction, it should be
System.loadLibrary("gc") without ".dll".
--
Gregory Shimansky, 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
Re: [drlvm] Using JNI methods in VM's components.
Posted by Alex Astapchuk <al...@gmail.com>.
Mikhail Fursov :
> On 10/20/06, Alex Astapchuk <al...@gmail.com> wrote:
>>
>> Yeap.
>> The following addresse both your issues.
>>
>>
>> class GCv5Magics {
>> static {
>> String gcPath = System.getProperty("vm.gc_dll");
>> if (gcPath == null) {
>> System.load(gcPath);
>> }
>> else {
>> System.loadLibrary("gc.dll");
>> }
>> }
>> }
>>
>>
> I like this approach! :)
You will like it even more with a patch (already posted) ;-)
--
Thanks,
Alex
---------------------------------------------------------------------
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: [drlvm] Using JNI methods in VM's components.
Posted by Mikhail Fursov <mi...@gmail.com>.
On 10/20/06, Alex Astapchuk <al...@gmail.com> wrote:
>
> Yeap.
> The following addresse both your issues.
>
>
> class GCv5Magics {
> static {
> String gcPath = System.getProperty("vm.gc_dll");
> if (gcPath == null) {
> System.load(gcPath);
> }
> else {
> System.loadLibrary("gc.dll");
> }
> }
> }
>
>
I like this approach! :)
Pavel ?
--
Mikhail Fursov
Re: [drlvm] Using JNI methods in VM's components.
Posted by Alex Astapchuk <al...@gmail.com>.
Alex Astapchuk :
> Mikhail Fursov :
>> Pavel,
>> I do this workaround for my local needs.
>> The problem in your solution is dll name: gcv5
>> I can built my own version of GC - gcv5_plus_some_features and put it
>> into
>> any directory I want (-Dvm.gc_dll ?)
>> Should I fix the Java sources in this case?
>>
>> The possible solution could be to set up system property: "-
>> Dgcv5.my_current_location" and read it from Java, but I see 2 problems:
>> 1) A component (GC) must know its library name
>> 2) "java.library.path" must be modified before the load and restored
>> after
>> the load, because System.loadLibrary is not able to load library with
>> fully
>> qualified path.
>>
>> Any other ideas?
>
> Yeap.
> The following addresse both your issues.
>
>
> class GCv5Magics {
> static {
> String gcPath = System.getProperty("vm.gc_dll");
> if (gcPath == null) {
... and the patch already exists... :-)
if (gcPath != null) {
> System.load(gcPath);
> }
> else {
> System.loadLibrary("gc.dll");
System.loadLibrary("gc");
> }
> }
> }
>
>
--
Thanks,
Alex
---------------------------------------------------------------------
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: [drlvm] Using JNI methods in VM's components.
Posted by Alex Astapchuk <al...@gmail.com>.
Mikhail Fursov :
> Pavel,
> I do this workaround for my local needs.
> The problem in your solution is dll name: gcv5
> I can built my own version of GC - gcv5_plus_some_features and put it into
> any directory I want (-Dvm.gc_dll ?)
> Should I fix the Java sources in this case?
>
> The possible solution could be to set up system property: "-
> Dgcv5.my_current_location" and read it from Java, but I see 2 problems:
> 1) A component (GC) must know its library name
> 2) "java.library.path" must be modified before the load and restored after
> the load, because System.loadLibrary is not able to load library with fully
> qualified path.
>
> Any other ideas?
Yeap.
The following addresse both your issues.
class GCv5Magics {
static {
String gcPath = System.getProperty("vm.gc_dll");
if (gcPath == null) {
System.load(gcPath);
}
else {
System.loadLibrary("gc.dll");
}
}
}
--
Thanks,
Alex
>
> On 10/20/06, Pavel Pervov <pm...@gmail.com> wrote:
>>
>> Mikhail,
>>
>> You certainly can. Just add System.loadLibrary(<component name>) to the
>> static initialization block of a class, which declares that method and
>> call
>> <clinit> for such class.
>>
>> Example.
>> ----------------------
>> Component: gcv5.dll
>> Class, implementing fast path magics: GCv5Magics
>> Class source:
>> class GCv5Magics {
>> static {
>> System.loadLibrary("gcv5.dll");
>> }
>> // ... the rest of magics for GC v5
>> }
>>
>> Regards,
>> Pavel.
>>
>> P.S. <clinit> is not called for such classes now, but magics are all
>> something new to add to VM.
>>
>> On 10/20/06, Mikhail Fursov <mi...@gmail.com> wrote:
>> >
>> > All,
>> > AFAIK today I can't add JNI method to a component (em library, gc
>> library,
>> > jit library) and call the method from Java.
>> > Is there any reason why do we have this limitation?
>> >
>> > I have only the one, but IMO very serious reason why to allow it: a
>> part
>> > of
>> > a component could be written in Java.
>> >
>> > The example is EMThreadSupport.java class. This class is a part of the
>> > kernel classes but this is wrong.
>> > I can't extend its functionality without modification of VM-EM native
>> > interface.
>> > ?
>> >
>> > --
>> > Mikhail Fursov
>> >
>> >
>>
>>
>
>
---------------------------------------------------------------------
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: [drlvm] Using JNI methods in VM's components.
Posted by Pavel Pervov <pm...@gmail.com>.
Mikhail.
If you make your own version of GC (presumably, modifying it's sources), you
surely can modify one string in Java file too.
More interesting is the fact that the library can reside anywhere in the
system. As loading and initializing components happens at early stage
of starting VM - there is only one thread at that time, and we can safely
change any system properties (restoring it afterwards) before calling to
component's helpers class static initializer, your idea of changing "
java.library.path" will do the trick.
Also, it is not only GC, which can be replaced at start time. Which means,
this interface (to load helpers JAR file for a particular component) should
be available through VM Core for other components.
Regards,
Pavel.
On 10/20/06, Mikhail Fursov <mi...@gmail.com> wrote:
>
> Pavel,
> I do this workaround for my local needs.
> The problem in your solution is dll name: gcv5
> I can built my own version of GC - gcv5_plus_some_features and put it into
> any directory I want (-Dvm.gc_dll ?)
> Should I fix the Java sources in this case?
>
> The possible solution could be to set up system property: "-
> Dgcv5.my_current_location" and read it from Java, but I see 2 problems:
> 1) A component (GC) must know its library name
> 2) "java.library.path" must be modified before the load and restored after
> the load, because System.loadLibrary is not able to load library with
> fully
> qualified path.
>
> Any other ideas?
>
> On 10/20/06, Pavel Pervov <pm...@gmail.com> wrote:
> >
> > Mikhail,
> >
> > You certainly can. Just add System.loadLibrary(<component name>) to the
> > static initialization block of a class, which declares that method and
> > call
> > <clinit> for such class.
> >
> > Example.
> > ----------------------
> > Component: gcv5.dll
> > Class, implementing fast path magics: GCv5Magics
> > Class source:
> > class GCv5Magics {
> > static {
> > System.loadLibrary("gcv5.dll");
> > }
> > // ... the rest of magics for GC v5
> > }
> >
> > Regards,
> > Pavel.
> >
> > P.S. <clinit> is not called for such classes now, but magics are all
> > something new to add to VM.
> >
> > On 10/20/06, Mikhail Fursov <mi...@gmail.com> wrote:
> > >
> > > All,
> > > AFAIK today I can't add JNI method to a component (em library, gc
> > library,
> > > jit library) and call the method from Java.
> > > Is there any reason why do we have this limitation?
> > >
> > > I have only the one, but IMO very serious reason why to allow it: a
> part
> > > of
> > > a component could be written in Java.
> > >
> > > The example is EMThreadSupport.java class. This class is a part of the
> > > kernel classes but this is wrong.
> > > I can't extend its functionality without modification of VM-EM native
> > > interface.
> > > ?
> > >
> > > --
> > > Mikhail Fursov
> > >
> > >
> >
> >
>
>
> --
> Mikhail Fursov
>
>
Re: [drlvm] Using JNI methods in VM's components.
Posted by Mikhail Fursov <mi...@gmail.com>.
Pavel,
I do this workaround for my local needs.
The problem in your solution is dll name: gcv5
I can built my own version of GC - gcv5_plus_some_features and put it into
any directory I want (-Dvm.gc_dll ?)
Should I fix the Java sources in this case?
The possible solution could be to set up system property: "-
Dgcv5.my_current_location" and read it from Java, but I see 2 problems:
1) A component (GC) must know its library name
2) "java.library.path" must be modified before the load and restored after
the load, because System.loadLibrary is not able to load library with fully
qualified path.
Any other ideas?
On 10/20/06, Pavel Pervov <pm...@gmail.com> wrote:
>
> Mikhail,
>
> You certainly can. Just add System.loadLibrary(<component name>) to the
> static initialization block of a class, which declares that method and
> call
> <clinit> for such class.
>
> Example.
> ----------------------
> Component: gcv5.dll
> Class, implementing fast path magics: GCv5Magics
> Class source:
> class GCv5Magics {
> static {
> System.loadLibrary("gcv5.dll");
> }
> // ... the rest of magics for GC v5
> }
>
> Regards,
> Pavel.
>
> P.S. <clinit> is not called for such classes now, but magics are all
> something new to add to VM.
>
> On 10/20/06, Mikhail Fursov <mi...@gmail.com> wrote:
> >
> > All,
> > AFAIK today I can't add JNI method to a component (em library, gc
> library,
> > jit library) and call the method from Java.
> > Is there any reason why do we have this limitation?
> >
> > I have only the one, but IMO very serious reason why to allow it: a part
> > of
> > a component could be written in Java.
> >
> > The example is EMThreadSupport.java class. This class is a part of the
> > kernel classes but this is wrong.
> > I can't extend its functionality without modification of VM-EM native
> > interface.
> > ?
> >
> > --
> > Mikhail Fursov
> >
> >
>
>
--
Mikhail Fursov
Re: [drlvm] Using JNI methods in VM's components.
Posted by Pavel Pervov <pm...@gmail.com>.
Mikhail,
You certainly can. Just add System.loadLibrary(<component name>) to the
static initialization block of a class, which declares that method and call
<clinit> for such class.
Example.
----------------------
Component: gcv5.dll
Class, implementing fast path magics: GCv5Magics
Class source:
class GCv5Magics {
static {
System.loadLibrary("gcv5.dll");
}
// ... the rest of magics for GC v5
}
Regards,
Pavel.
P.S. <clinit> is not called for such classes now, but magics are all
something new to add to VM.
On 10/20/06, Mikhail Fursov <mi...@gmail.com> wrote:
>
> All,
> AFAIK today I can't add JNI method to a component (em library, gc library,
> jit library) and call the method from Java.
> Is there any reason why do we have this limitation?
>
> I have only the one, but IMO very serious reason why to allow it: a part
> of
> a component could be written in Java.
>
> The example is EMThreadSupport.java class. This class is a part of the
> kernel classes but this is wrong.
> I can't extend its functionality without modification of VM-EM native
> interface.
> ?
>
> --
> Mikhail Fursov
>
>