On 10/23/06, Pavel Afremov <[EMAIL PROTECTED]> 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
