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]
