harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Astapchuk <alex.astapc...@gmail.com>
Subject Re: [drlvm] Using JNI methods in VM's components.
Date Fri, 20 Oct 2006 11:13:08 GMT
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 <pmcfirst@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 <mike.fursov@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


Mime
View raw message