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

Reply via email to