MethodHandle.vmentry offset problem on 64-bit

John Rose John.Rose at Sun.COM
Wed Sep 2 10:47:28 PDT 2009


On Sep 2, 2009, at 7:44 AM, Christian Thalinger wrote:

> I'm currently porting the interpreter to x86_64 and there is a problem
> that took me almost two days to find: it's the MethodHandle.vmentry
> field-type change.
>
> For whatever reason on 64-bit it calculates the offset to 24, which
> actually should be 16, and that results to this:
>
> sun.dyn.DirectMethodHandle
> - klass: 'sun/dyn/DirectMethodHandle'
> - ---- fields (total size 6 words):
> - private 'vmentry' 'J' @24  4329412000 (20d95a0 1)
> - protected 'vmtarget' 'Ljava/lang/Object;' @24  ### BAD OOP
> 0x1020d95a0 ### (20d95a0 1)
> - private 'type' 'Ljava/dyn/MethodType;' @32  a 'java/dyn/ 
> MethodType' =
> (II)I (5040e38 1)
> - private final 'vmindex' 'I' @40  -2 (fffffffe)
>
> Nice, isn't it? :-)

I didn't know we had unions in Java!  :-)

> So, there is a problem somewhere in
> ClassFileParser::java_dyn_MethodHandle_fix_pre and the attached patch
> fix it.  But I'm very sure this is not correct as the field should
> really be a double field and not a word field.  What is the "correct"
> fix for this problem?

The MH.vmentry fields needs to be an unmanaged void* field, which  
means (as far as Java is concerned) either I or J (not L).

The current implementation of sun.dyn.MHI patches the type this way.   
I'm surprised that the layout logic fails after that.  Probably the  
patching is inconsistent somehow.

But in the longer run, this doesn't matter, since MHI has to go away.   
This is the bug:
   6839872  remove implementation inheritance from JSR 292 APIs

The vmentry field needs to disappear from Java code and get  
automagically installed on java.dyn.MethodHandle, the same way the  
hidden klassOop field gets installed on java.lang.Class.

-- John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090902/b2bc9421/attachment.html 


More information about the mlvm-dev mailing list