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
