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
_______________________________________________
mlvm-dev mailing list
[email protected]
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
