harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov" <alexei.fedo...@gmail.com>
Subject Re: [drlvm][verifier] Please review HARMONY-3862
Date Tue, 10 Jul 2007 06:52:01 GMT
Nina,
My algorithm inlines subroutines, so it is important for it to know to
which subroutince each basic block belongs to. For this case I believe
the algorithm may assume that questionable parts of subroutines belong
to the subroutine which is upper in the caller chain.

Anyway, Mikhail volunteered to check in his new verifier which doesn't
inline subroutines, so I believe we just need to wait a bit until this
happen and recheck.

Thanks.



On 7/10/07, Nina Rinskaya <nina.rinskaya@gmail.com> wrote:
> Alexei and all,
>
> It looks that we finally should get back to the issue because Eclipse
> compiler people say it can be not Eclipse compiler, but Harmony verifier
> issue. Here is the comment from
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=194398#c7:
>
> "It seems that it is legal to return to a higher level in the subroutines
> call
> chain.
> From the JVMS (2nd edition):
> http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.html#9308
>
> "Each instance of type returnAddress can be returned to at most once. If a
> ret
> instruction returns to a point in the subroutine call chain above the ret
> instruction corresponding to a given instance of type returnAddress, then
> that
> instance can never be used as a return address."
>
> This would mean that as long as the ret instruction is executed only once,
> this
> is fined. It would be a verify error if the ret 3 could be executed after
> the
> ret 1 has been executed.
>
> So I would close this one as WONTFIX since the code generation is actually
> fine
> and it seems that the Harmony bytecode verifier is too strict."
>
> Should we re-open the issue and investigate it?
>
> Thanks.
>
> --
> Nina
>
>
> On 7/9/07, Alexei Fedotov <alexei.fedotov@gmail.com> wrote:
> >
> > Nina,
> >
> > It was nothing was to be sorry about. :-) I was just trying to
> > understand your concern myself. I believe we should pay attention to
> > the difference if it prevents any applications from running. There are
> > too much arbitrary differences to pay attention to each of them.
> >
> > For example, Sun's verifier is shipped in a form of DLL which allows
> > BEA to use it . We don't ship our verifier in a form of DLL. This is a
> > difference, but we don't file JIRA issue about it.
> >
> > From the other side behavior difference might be serious if it impacts
> > something seriously. If you think this incompatibility has a serious
> > impact, just indicate the impact and the incompatibility will be
> > addressed.
> >
> > Thanks.
> >
> > On 7/9/07, Nina Rinskaya <nina.rinskaya@gmail.com> wrote:
> > > Alexei,
> > >
> > > Sorry for misleading you. I agree that it's ok to forget about the issue
> > > because there is the Eclipse compiler bug describing this issue. I was
> > just
> > > confused by Harmony and Sun verifiers behavior difference, but it's not
> > a
> > > Harmony issue.
> > >
> > > --
> > > Nina
> > >
> > > On 7/6/07, Alexei Fedotov <alexei.fedotov@gmail.com> wrote:
> > > >
> > > > Nina,
> > > >
> > > > > but also Sun's verifier bug
> > > > Mmm, I'm not sure I follow. Isn't it enough to have a bug against
> > > > Eclipse compiler to forget about this issue?
> > > >
> > > > Thank you, Alexei
> > > >
> > > >
> > > > On 7/6/07, Nina Rinskaya <nina.rinskaya@gmail.com> wrote:
> > > > > Alexei,
> > > > >
> > > > > I'm just not sure how we track compatibility issues if there is a
> > > > difference
> > > > > in Harmony and RI behavior. Is it now proven that it's not only
> > Eclipse
> > > > > Compiler, but also Sun's verifier bug? If yes, I agree that it's
not
> > > > > necessary to reopen the issue.
> > > > >
> > > > > --
> > > > > Nina
> > > > >
> > > > > On 7/6/07, Alexei Fedotov <alexei.fedotov@gmail.com> wrote:
> > > > > >
> > > > > > Nina,
> > > > > >
> > > > > > Eclipse bug owner confirmed that this was an issue with the
> > compiler.
> > > > > > Why do you want to reopen the issue against DRLVM?
> > > > > >
> > > > > > Thanks.
> > > > > >
> > > > > > On 7/6/07, Nina Rinskaya <nina.rinskaya@gmail.com> wrote:
> > > > > > > Hi all,
> > > > > > >
> > > > > > > I'm writing this just to bring your attention to
> > > > > > > http://issues.apache.org/jira/browse/HARMONY-3862 and ask
> > > > drlvm/verifier
> > > > > > > people to see whether it's necessary to reopen it.
> > > > > > >
> > > > > > > It says about VerifyError trown by Harmony when running
a class
> > > > compiled
> > > > > > by
> > > > > > > Eclipse Compiler. It was closed as 'Cannot Reproduced',
but it
> > is
> > > > > > actually
> > > > > > > reproduced (see HARMONY-3862 comments). It looks that it's
not
> > > > Harmony
> > > > > > > issue, but Eclipse compiler issue (I opened the bug against
> > Eclipse
> > > > > > > compiler: https://bugs.eclipse.org/bugs/show_bug.cgi?id=194398),
> > and
> > > > RI
> > > > > > > issue (it should also throw VerifyError, but it doesn't).
But
> > still
> > > > we
> > > > > > have
> > > > > > > different behavior on RI and Harmony implementations.
> > > > > > >
> > > > > > > So could someone take care of this issue and probably reopen
it
> > as
> > > > > > > compatibility issue if it makes sense? Thanks!
> > > > > > >
> > > > > > > --
> > > > > > > Nina
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > With best regards,
> > > > > > Alexei,
> > > > > > ESSD, Intel
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > With best regards,
> > > > Alexei,
> > > > ESSD, Intel
> > > >
> > >
> >
> >
> > --
> > With best regards,
> > Alexei,
> > ESSD, Intel
> >
>


-- 
With best regards,
Alexei,
ESSD, Intel

Mime
View raw message