harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "chunrong lai" <chunrong...@gmail.com>
Subject Re: [drlvm][opt][gc]does jitrino require the managed_null to be a valid object in 64bits running
Date Wed, 14 Mar 2007 12:41:33 GMT
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 <mike.fursov@gmail.com> 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 <chunronglai@gmail.com> 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message