harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robin Garner <robin.gar...@anu.edu.au>
Subject Re: [drlvm] Calling native methods from Java code: implementation details
Date Mon, 30 Oct 2006 04:52:36 GMT
I thought moxie already had an implementation of fast native calls ? 
Perhaps you could look at that ?


Mikhail Fursov wrote:
> 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 .

View raw message