Hi.
On First question I think that alternative 1 is better. It's allow to avoid
creating of "special" or "magic" registration subsystem which should
provide addresses for "magic" native call.
On the Second question I agree with Pavel P. Null should be OK.
On Third question, I think no additional actions is required. All dll's or
so's for DRL VM must be in jre/bin directory and classes jar's must be
jre/lib directory. Both should be loaded by as the others in these
directories now. It's the first part of "third" question. The second part
or "fourth" question is "How to understand that this class contains magic
native functions?". I prefer answer by extends a special empty interface.
It's can provide opportunity writing libraries with fast native calls in
future. Also it's match with java security. DRL VM can control what
component can use "Magic" and what not via SecurityManager.
Mikhail could you summarize all issues which should be clarified and
possible solutions for these issues?
Thanks.
Pavel Afremov.
On 10/20/06, Pavel Pervov <[EMAIL PROTECTED]> wrote:
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]
>
>
