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 >
