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] Calling native methods from Java code: implementation details
Date Fri, 20 Oct 2006 10:49:38 GMT
My alternative follows:

1) Each component which exports magics, provides JAR file with class
implementing these magics. Class name is described in (e.g.) Main-Class
attribute of JAR's manifest.
2) The class contains java fast path for helper, and a pair of native
methods: one for fast-slow path, and one for slow-slow path.
3) Fast-slow path helper can have any (supported) calling convention.
4) Slow-slow path helper will be called through JNI - it is regular native
method.

The example follows:
----------------------
package org.apache.harmony.vm.helpers;
// Annotations follow here, which describe which method is which helper,
// and which is fast-path, fast-slow path, slow-slow path
class GCv6Helpers {
    // fast-path allocation here
    public static Address alloc(Address class, int size) {
        // ...
    }
    // annotation, describing calling convention for fast-slow path
    public static native Address slow_alloc(Address class, int size);
    public static native Address jni_alloc(Address class, int size);
}

Now, if JIT supports magics, it'll process GCv6Magics::alloc in a special
way and generate call to slow_alloc in annotated calling convention. If JIT
does not support magics at all, it'll call jni_alloc in usual way - as
regular call to native Java method.

Yes, my idea suggests to change helper retrieval interface for JIT, but we
already started to make significant changes to architecture - let's just
make them more generic.

Regards,
    Pavel.

P.S. IMHO, this approach combines strong sides of Mikhail's and Pavel's
ideas, as it use standard mechanisms of resolution and search of methods in
loaded classes.

On 10/20/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
>
> Yes, this thread is not about JNI. I'll start another thread related to
> JNI
> calls from VM components.
>
> BTW here is another solution how to find an address of the direct native
> method.
> May be it's not the best, but it does not requires any calls from JIT
> during
> the compilation (neither Java nor VM calls)
>
> class IHaveNatives {
>    public static final long myNativeAddress = jni_getAddress("myNative")
>
>    // call to be replaced with direct native call
>    public static void myNative() {throws new RuntimeException("not
> implemented")};
>
>   // the way to obtain an address for a method
>   private static native jni_getAddress(String directNativeCallName);
> }
>
>
> Solution: To find an address of the native call JIT can access to the
> final
> variable.
>
> On 10/20/06, Alex Astapchuk <alex.astapchuk@gmail.com> wrote:
> >
> > Gregory,
> >
> > Gregory Shimansky:
> > > On Thursday 19 October 2006 09:21 Alex Astapchuk wrote:
> > >> Mikhail Fursov wrote:
> > >>> On 10/19/06, Alex Astapchuk <alex.astapchuk@gmail.com> wrote:
> > >>>> Pavel,
> > >>>>
> > >>>> One more note.
> > >>>>
> > >>>>> b) About call of java method during compilation time. Jit now
make
> > >>>> class loading during compilation.
> > >>>>
> > >>>>> It means that Jit make call of java method.
> > >>>>> So I don't think that it's the other case.
> > >>>> It is different.
> > >>>> The JIT itself does not call Java code.
> > >>>> All what JIT does is calling VM's resolve_{anything}. It's VM who
> may
> > >>>> execute the Java code during the resolution.
> > >>>>
> > >>>> The JIT itself neither has a way to call an arbitrary Java method
> > during
> > >>>> the compilation, neither has an access to JNI functionality.
> > >>> Sounds reasonable. And this solution joins mine and Pavel's
> proposals:
> > >>> JIT calls a VM method to resolve native address for direct call. JIT
> > does
> > >>> not
> > >> I would also add that we can not use any Java-based resolution
> schemes
> > >> at all.
> > >> (Here I mean anything that implies execution of managed code during
> > >> compilation in order to resolve the things).
> > >>
> > >> Doing so we would dig a huuuuge grave for ourselves: we'll get a
> number
> > >> of dead lock issues, as such a scheme will add a sporadic and random
> > >> locks inside a normal Java control flow. Exactly the same issue as we
> > >> had with mixing native and Java locks in the same control flow.
> > >
> > > I didn't read the beginning of this thread (it is huge!) so forgive my
> >
> > Well, ok, here is its content in short: in previous series of the thread
> > we were talking about a very special native methods. It has nothing to
> > do with regular Java or JNI methods.
> >
> > > ignorance. Do you mean normal Java method resolution which is done for
> > all
> > > methods native and Java, or do you mean some special "native helper
> > address
> > > resolution" where you a priori know that method is native and normal
> > Java
> > > resolution was successfully done for it already?
> > >
> > > I think in this case "native helper address resolution" would not
> > perform any
> > > Java calls, it would be a simple lookup through native libraries
> loaded
> > by
> >
> > Pavel's proposal was *to perform* the Java or JNI call.
> >
> > > the class loader which was used to load the class which owns the
> method
> > where
> > > you want to inline a helper.
> >
> > The helpers we are talking about may have nothing to do neither with
> > ClassLoading machinery, nor with a libraries already loaded by Java.
> >
> >
> > --
> > 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
> >
> >
>
>
> --
> Mikhail Fursov
>
>

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