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] Calling native methods from Java code: implementation details
Date Fri, 20 Oct 2006 11:28:50 GMT
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
View raw message