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 01:04:43 GMT

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.


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

View raw message