Sorry I should have post the full sequence of my question as below. It's
about compressed ptr support, especially about the managed_null (HEAP_NULL)
processing. The code sequence firstly invokes a method that returns an obj
reference, then it compares if the obj's type is expected.
0x2aaac15e6d40: callq 0x2aaac15e6f00 ;method call that returns obj ref
; here it
returns HEAP_NULL
0x2aaac15e6d50: mov %rax,%rbx ; keep the return value
0x2aaac15e6d53: xor %edi,%edi ; get a NULL
0x2aaac15e6d55: movslq %edi,%rdi ; NULL in rdi
0x2aaac15e6d58: cmp %rbx,%rdi ; Compare returned obj reference with NULL
0x2aaac15e6d5b: je 0x2aaac15e6ec4 ; goto NULL ptr processing
0x2aaac15e6d61: movslq (%rbx),%rdi ; read compressed vt from the obj;
; which is
HEAP_NULL, dangerous(error) to me
0x2aaac15e6d64: mov $0x2aaaafbfeff8,%rax ; get vtable base
0x2aaac15e6d6e: add %rax,%rdi ; add to vt to uncompress the vtable
0x2aaac15e6d71: mov $0x2aaaafbff900,%rax ; compare with a target type vt
My question is:
1. why the returned obj ref (should be compressed) is compared with NULL,
instead of HEAP_NULL? In compressed-ptr mode, NULL is actually meaningless
as a reference
2. Since the returned ref is HEAP_NULL (the compressed mode of NULL), we
can't deference it. If it depends on NPE for the exception catching,
HEAP_NULL is not NULL.
The code would be ok if the return value for the first call is not a
compressed ptr. But that would be inconsistent.
On 3/14/07, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
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
