harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Fursov" <mike.fur...@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 13:23:59 GMT
>x2aaac15e6d40: callq  0x2aaac15e6f00  ;method call that returns obj ref

If the method above returns reference (and not magic-type) then HEAP_NULL
must be used for NPE check.
Can you file a JIRA with a test? IMO the problem you found is very important
and is easy to fix.


On 3/14/07, chunrong lai <chunronglai@gmail.com> wrote:
>
> 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
> >
>



-- 
Mikhail Fursov

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