harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Pervov" <pmcfi...@gmail.com>
Subject Re: [drlvm] Using JNI methods in VM's components.
Date Fri, 20 Oct 2006 11:03:23 GMT
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 <mike.fursov@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 <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
> > >
> > >
> >
> >
>
>
> --
> Mikhail Fursov
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message