Hi chunrong,
In some special cases when there are no exception handler in the same method
Jitrino.OPT can eliminate null checks and rely on hardware NPE handling.
In your case :
0x2aaac15e6d61: movslq (%rbx),%rdi ; Read Vtable from managed_null in
typical cases, error if GC is not aware
the %rdi but not %rbx is NULL. So reading vtable from %rbx looks ok here.
On 3/14/07, chunrong lai <[EMAIL PROTECTED]> wrote:
hi, colleagues:
In our 64bits GC testing. I see that the -Xem:opt generates assemblies
to read vtable from managed_null.
0x2aaac15e6d53: xor %edi,%edi
0x2aaac15e6d55: movslq %edi,%rdi
0x2aaac15e6d58: cmp %rbx,%rdi ; compare the object with NULL
0x2aaac15e6d5b: je 0x2aaac15e6ec4
0x2aaac15e6d61: movslq (%rbx),%rdi ; Read Vtable from managed_null in
typical cases, error if GC is not aware
0x2aaac15e6d64: mov $0x2aaaafbfeff8,%rax ;vtable_base
0x2aaac15e6d6e: add %rax,%rdi ;uncompress the vtable
0x2aaac15e6d71: mov $0x2aaaafbff900,%rax ;"java.lang.string"
0x2aaac15e6d7b: cmp %rdi,%rax ;Compare the vtable
0x2aaac15e6d7e: mov $0x0,%edi
0x2aaac15e6d83: sete %dil
The managed_null is set by GC. But I do not know it should be a valid
object.
I also see there is a check with NULL before the vtable getting.
However
I did not see check with managed_null there.
May I know some details, or the assumption of the JIT, for the code
generation?
thanks and best regards,
chunrong
--
Mikhail Fursov
