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 12:47:45 GMT
Prerequisite: each component carries its own helpers (which means no
"allocation helper" in VM Core, for example).

Yes, simple JIT will call helper as regular JNI method.

I missed several issues in my original message.

First: "how to get address of helper?"
Answer:
Two choices:
1) each component must provide "static native long getHelperAddress(int)" in
its helper class. JIT will make a call to this function as regular JNICALL
(stdcall on Windows, cdecl on Linux). Function prototype can be typedef'ed
as "typedef (JNICALL*)(JNIEnv*, jint)". The issue I see here is naming: each
component has its own helpers class name. So, the name for native method to
call will be <package name>_<class name>_getHelperAddress.
2) add regular (OPEN) interface function to each component which will
provide such mapping (as it is now done by VM).

Second: "what should be passed as JNIEnv to getHelperAddress?"
Answer:
NULL. Component should not use JNIEnv pointer in this call.

Third: "how to retrieve helpers class for a particular component?"
Answer:
Two choices again:
1) component modifies boot class path on initialization and exports
<component type>.helpers_class system property. Then VM loads this class and
JIT uses this class' name to retrieve fast path helpers.
2) component exports <component type>.helpers_jar system property on
initialization, then VM adds this JAR to boot class path, extracts the
manifest from it, retrieve Helpers-Class attribute from the manifest, and
exports it as <component type>.helpers_class. Then VM loads this class and
JIT uses this class' name to retrieve fast path helpers.
I, personally, prefer second choice here.

Anything else?..

Pavel.

On 10/20/06, Alex Astapchuk <alex.astapchuk@gmail.com> wrote:

> Pavel Pervov :
> > 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.
> ...
> > 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.
>
>
> Helpers are neither called as JNI methods nor they are called through
> the JNI.
>
> Or do you propose to make a code for the helpers as the JNI methods?
> How would the 'jni_alloc(Address class, int size);' look like in the C
> code?
>
>
>
> --
> Thanks,
>   Alex
>
>
>
> >
> > 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
> >>
> >>
> >
>
>
>
>
> ---------------------------------------------------------------------
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message