On the 0x316 day of Apache Harmony Mikhail Loenko wrote:
> nesting is OK, the question is if you call one sub2 from sub1, can you return
> from sub1 if sub2 is on the top
Ah, I see, in this example we "ret" to the "wrong" return address and
"return" immediately. I think:
1. it is a truly weird example :)
2. but rather legal:
a) you can "return" from finally blocks doing no "ret" beforehand
b) "ret" instructions are restricted in the way that each "ret"
instruction can only return to a single point in the program
c) no other relevant pieces that I could find
so I am +1 to allow this kind of weird code
> 17 Jul 2007 11:25:07 +0400, Egor Pasko <[EMAIL PROTECTED]>:
> > On the 0x316 day of Apache Harmony Mikhail Loenko wrote:
> > > Well...
> > >
> > > The test in the bug passes on RI as well as the following (looking
> > > weird) construction:
> > >
> > > public static void main(java.lang.String[]);
> > > Code:
> > > 0: jsr 4
> > > 3: return
> > >
> > > 4: astore 1
> > > 6: jsr 10
> > > 9: ret 0
> > >
> > > 10: astore 0
> > > 12: ret 1
> > >
> > > }
> > >
> > > I think I saw in the spec that a ret from non-top subroutine is illegal.
> > > But now I can't find this statement.
> > >
> > > So, I can easily (by removing the code) fix the new verifier to pass
> > > both the test from the bug and the construction above.
> > >
> > > Comments, objections?
> >
> > soubroutines in fact can be nested, this is how nested finally blocks
> > were supposed to be compiled.
> >
> > > Thanks,
> > > Mikhail
> > >
> > > 2007/7/17, Mikhail Loenko <[EMAIL PROTECTED]>:
> > > > Hmmm. I was using a wrong compiler. When I took 3.2.1 it prints
> > > > VerifyError.
> > > >
> > > > Looking...
> > > >
> > > > Thanks,
> > > > Mikhail
> > > >
> > > > 2007/7/17, Mikhail Loenko <[EMAIL PROTECTED]>:
> > > > > Harmony now prints SUCCESS on the test case from 3862.
> > > > > Nina, please let me know if there are outstanding issues.
> > > > >
> > > > > Thanks,
> > > > > Mikhail
> > > > >
> > > > > 2007/7/15, Mikhail Loenko <[EMAIL PROTECTED]>:
> > > > > > 2007/7/10, Alexei Fedotov <[EMAIL PROTECTED]>:
> > > > > > > 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.
> > > > > >
> > > > > > I'm going to finish in a few days
> > > > > >
> > > > > > Thanks,
> > > > > > Mikhail
> > > > > >
> > > > > > >
> > > > > > > Thanks.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 7/10/07, Nina Rinskaya <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> > --
> > Egor Pasko
> >
> >
>
--
Egor Pasko
