harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "chunrong lai" <chunrong...@gmail.com>
Subject Re: Enable the MACRO _DEBUG_CHECK_NULL_
Date Wed, 12 Nov 2008 14:31:16 GMT
hi, Mikhail:
    Thanks for the reply.
    I'd like to delay the MACRO enabling because it is too difficult for me
to maintain and choose from two version of RT helpers.
     In my understanding the problem of HARMONY-6013 comes from (2),  the
checknull is replaced with the hardware exception check (does the
optimization always happen if 'checknull' op is not in a try-catch block).
Unfortunately the hardware exception check is inprecise or incompatible with
the Java exception check/catch in this time. It just call the stub/helper
directly and the helper just crashed if without NPE checking code inside.
Does it make sense?



On Wed, Nov 12, 2008 at 7:16 PM, Mikhail Fursov <mike.fursov@gmail.com>wrote:

> Chunrong,
> Here are simple rules for JIT for checknull operation:
> 1) JIT in HIR can delete checknull only if it can prove (has tauSafe
> operand) that another check for the same SSA opnd was performed in
> dominated
> code.
> 2) JIT in LIR can replace checknull with hardware exception check only if
> 'checknull' op is not in a try-catch block.
>
> For the method in HARMONY-6013 JIT can eliminate checknull before the
> monenter helper call only if "void sync()" is not inlined. If it's inlined
> the monenter instruction is placed into the try-catch block of the parent
> method.
> It means that monenter helper that is called from JIT must have a check for
> NULLs.
> From the performance POV it could be worth to having two kinds of monenter
> helpers: one with a check for null and another without.
>
> Hope it helps.
> MIkhail
>
>
> On Wed, Nov 12, 2008 at 3:53 PM, chunrong lai <chunronglai@gmail.com>
> wrote:
>
> > Thanks.
> > Mikhail, can you kindly help to advice on this?
> >
> > On Wed, Nov 12, 2008 at 5:24 PM, Alexei Fedotov <
> alexei.fedotov@gmail.com
> > >wrote:
> >
> > > I wonder if may get Mikhail advice on this.
> > >
> > > On Wed, Nov 12, 2008 at 12:08 PM, chunrong lai <chunronglai@gmail.com>
> > > wrote:
> > > > hi, colleagues:
> > > >     I am asking for the support of other committers to enable the
> MACRO
> > > > _DEBUG_CHECK_NULL_ (in include/jit_runtime_support.h), because of the
> > > rule
> > > > of M8 code frozen period.
> > > >     I need the MACRO to enable the test case as in HARMONY-6013,
> which
> > > > throws uncaught NullPointerException. The exception comes with the
> stub
> > > of
> > > > vm_rt_monitor_enter.  We had not met the reported exception because
> we
> > > > originally have two null checkings with that. The first one is just
> > > before
> > > > the stub. The second is inside the stub.
> > > >     Now we find that the first null checking before the stub will be
> > > > removed after some aggressive optimizations. Also a commit r659128
> > moved
> > > the
> > > > null checking (and exception throwing) codes inside the stub into the
> > > > regions guarded by the disabled macro  MACRO _DEBUG_CHECK_NULL_ . As
> > the
> > > > result drlvm just fails in running such test cases.
> > > >     Buqi is checking JIT codes to prepare another patch. But I am not
> > > sure
> > > > if we should wait and include the patch in M8. Or we can just try
> that
> > > after
> > > > code unfrozen.
> > > >
> > >
> > >
> > >
> > > --
> > > С уважением,
> > > Алексей Федотов,
> > > Телеком Экспресс
> > >
> >
>
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message