harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Fursov" <mike.fur...@gmail.com>
Subject Re: [drlvm] Calling native methods from Java code: implementation details
Date Tue, 24 Oct 2006 14:09:31 GMT
On 10/23/06, Pavel Afremov <pavel.n.afremov@gmail.com> wrote:
> Mikhail could you summarize all issues which should be clarified and
> possible solutions for these issues?

Ok, I'm going to summarize our discussion. Correct me if I missed something.

Problem 1A:  How JIT will know if a Java method must be replaced with a
direct native call.
Solution: Check if the class implements special marker interface or have an
annotation. The class must be loaded by bootstrap classloader.

Problem 1B: How JIT will know which VM helper must be replaced with a
fast-path Java version.
Solution: Check if predefined VM property is set. Get the name of the class
from the property. Initiate the resolution and initialization of the class
with fast-path helper.

Problem 2: How JIT will get the address of the native method to generate a
direct call?
Here we have 2 solutions:
Solution 2.1: Every component must have C method to return address for a
given Java method 'void* get_direct_address(Method_Handle)'. The name of the
component is stored as annotation for the method.
Solution 2.2:  Every class with a method to be replaced with direct native
call must have a JNI method: 'static native long get_address(int id). JIT
asks VM to get the address for a given method handle. VM gets the id from
the method annotations and calls the JNI method to derive the address.

Problem 3: How JIT will know which calling convention to use?
Solution 3: Use method's annotation again.

The current status:
Today we need only solution for 1B problem. I've implemented the first
fast-path vmhelper and inlined it using the solution described above. The
patch depends on JIRA1942 and JIRA1949. I'm going to commit the patch after
these JIRAs are accepted.

We have multiple solution for the problem 2. We can postpone the decision
for a awhile. The problem is not critical for the vmhelper inlining task .

Mikhail Fursov

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message