nesting is OK, the question is if you call one sub2 from sub1, can you return from sub1 if sub2 is on the top
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
