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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
>> >
>> > Gregory,
>> >
>> > Gregory Shimansky:
>> > > On Thursday 19 October 2006 09:21 Alex Astapchuk wrote:
>> > >> Mikhail Fursov wrote:
>> > >>> On 10/19/06, Alex Astapchuk <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
>> > For additional commands, e-mail:
[EMAIL PROTECTED]
>> >
>> >
>>
>>
>> --
>> Mikhail Fursov
>>
>>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
