harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Fursov" <mike.fur...@gmail.com>
Subject Re: [drlvm] Calling native methods from Java code: implementation details
Date Fri, 20 Oct 2006 06:35:56 GMT
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