Hello Java and class loading gurus, The JIT reported an assertion due to an error flag on the following entry.
25=org.apache.harmony.vts.test.vm.jvms.instructions.invokeReturn.invokeinterface.invokeinterface07.invokeinterface0703.invokeinterface0703pInterface name_and_type: 24=<virtualMethod (short)int> Well, the corresponding interface defined a method with (int)int signature, which does not match (short)int. Later the interface method (int)int is called as (short)int: invokeinterface #2=<InterfaceMethod org.apache.harmony.vts.test.vm.jvms.instructions.invokeReturn.invokeinterface.invokeinterface07.invokeinterface0703.invokeinterface0703pInterface.virtualMethod (short)int> nargs:2 >From the other side the test runs smoothly on RI and our VM in release mode. Why RI tolerates these two mismatches and runs without exception? Should we implement automatic int to short conversion for interfaces? Thanks. On Thu, Apr 24, 2008 at 9:58 AM, Alexei Fedotov <[EMAIL PROTECTED]> wrote: > Correct. 15 tests passed. As for your suggestion of adding a > regression test, I'm not yet convinced we should duplicate VTS tests > as regression tests. > > BTW, I have evaluated the other problem a bit. The problem is due to > the virtual method constant pool entry resolution. Does this ring a > bell? > > #2: InterfaceMethodref class: > > 25=org.apache.harmony.vts.test.vm.jvms.instructions.invokeReturn.invokeinterface.invokeinterface07.invokeinterface0703.invokeinterface0703pInterface > name_and_type: 24=<virtualMethod (short)int> > > This is still a regression, but probably an older one (since all your > runs use a release build). > > On Thu, Apr 24, 2008 at 9:29 AM, Stepan Mishura > > > <[EMAIL PROTECTED]> wrote: > > On 4/24/08, Alexei Fedotov <[EMAIL PROTECTED]> wrote: > > > > > I ran the tests locally and they passed. > > > > So you applied your fix and all these 15 failed tests passed. Correct? > > > > > > > Though, a number of other > > > tests failed, I assumed, due to assertions absent in your release > > > build. > > > > > > > Hmm, you assumed that tests results for debug and release builds are > > different but this also IMHO may mean other regressions in verifier. > > > > BTW, I don't see any regression test in the patch. Does it make sense > > to create it and add it to DRLVM reg. test suite? > > > > Thanks, > > > > > > Stepan. > > > > > On Thu, Apr 24, 2008 at 9:01 AM, Stepan Mishura > > > <[EMAIL PROTECTED]> wrote: > > > > On 4/24/08, Alexei Fedotov <[EMAIL PROTECTED]> wrote: > > > > > > > > > Stenan, > > > > > Sorry. I have fixed VTS verifier test failures: > > > > > > http://people.apache.org/~smishura/r650380/Windows_x86/vtsvm/junit/index.html > > > > > > > > > > > > > So all 15 tests failed because of this bug. Correct? > > > > > > > > -Stepan. > > > > > > > > > > > > > > > > > On Thu, Apr 24, 2008 at 6:57 AM, Stepan Mishura > > > > > <[EMAIL PROTECTED]> wrote: > > > > > > Hi Alexei, > > > > > > > > > > > > > > > > > > On 4/24/08, Alexei Fedotov <[EMAIL PROTECTED]> wrote: > > > > > > > Hello Stepan, > > > > > > > > > > > > > > I have fixed more verifier failures, see > > > > > > > > > > > > Which failures did you fix? HARMONY-5785 description doesn't > mention any. > > > > > > > > > > > > -Stepan. > > > > > > > > > > > > > > > > > > > > > > > > > https://issues.apache.org/jira/browse/HARMONY-5785 > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > On Wed, Apr 23, 2008 at 7:28 AM, Stepan Mishura > > > > > > > <[EMAIL PROTECTED]> wrote: > > > > > > > > On 4/22/08, Tim Ellison <[EMAIL PROTECTED]> wrote: > > > > > > > > > Alexei Fedotov wrote: > > > > > > > > > > As far as I understand Eclipse IP committee needs a > revision number to > > > > > > > > > > be supplied (no binaries involved). > > > > > > > > > > > > > > > > > > > > > > > > > > > > Apologies, I missed that point in the discussions around > compiler level etc. > > > > > > > > > If it is simply a well-defined revision of the verifier > code then that is > > > > > > > > > quite different. > > > > > > > > > > > > > > > > > > > The favour Vasily is asking about > > > > > > > > > > is providing him with a slightly tested revision. This > would suppress > > > > > > > > > > a normal work of committers for one day. Is it > something we cannot > > > > > > > > > > afford? > > > > > > > > > > > > > > > > > > > > > > > > > > > > Of course, in that area of the code I think it is quite > reasonable. It > > > > > > > > > would not prevent people working in the other areas of > Harmony (such as GC, > > > > > > > > > JIT, and class library). > > > > > > > > > > > > > > > > > > > > > > > > > OK, freezing only verifier code can be a compromise in > this case. > > > > > > > > But I think it makes sense for other areas to ask people > not commit > > > > > > > > risky changes (i.e. make feature freeze and commit only > bug fixes) - > > > > > > > > it will help with detection and resolution of possible > verifier > > > > > > > > regressions. I believe that this acceptable too. > > > > > > > > > > > > > > > > Could I ask all folks interesting in M5.5_Eclipse_TPTP > release to look > > > > > > > > through tests failures to understand if there are > regressions in the > > > > > > > > verifier or not? > > > > > > > > > > > > > > > > Tests results for r650380 are almost ready [1] (testing > the next > > > > > > > > r650564 snapshot will be launched in 2-3 hours). If there > are no > > > > > > > > regressions then I think r650380 (or r650564) can be > promoted as > > > > > > > > M5.5_Eclipse_TPTP. If you find verifier regression please > let > > > > > > > > everybody know ASAP - it should be fixed quickly. > > > > > > > > > > > > > > > > [1] > http://people.apache.org/~mloenko/snapshot_testing/script/r650380/index.html > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Stepan. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Of course, we cannot prevent the revision number of the > entire repository > > > > > > > > > changing over time, but you could nominate a givne > revision number for the > > > > > > > > > verifier code to be taken by Eclipse. > > > > > > > > > > > > > > > > > > Did I understand this right? > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > Tim > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Apr 22, 2008 at 3:07 PM, Tim Ellison <[EMAIL > PROTECTED]> > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > I'm really not convinced this is a good idea for > Harmony, and my > > > > > > > > > concerns > > > > > > > > > > > are in two parts: > > > > > > > > > > > > > > > > > > > > > > 1) Our schedule should not be dictated by an > external project, > > > > > > > > > especially > > > > > > > > > > > when it is their process that seems to be setting > the artificial time > > > > > > > > > limit. > > > > > > > > > > > Why not show some flexibility to meet our dates? > > > > > > > > > > > > > > > > > > > > > > 2) Our principle delivery mechanism is source code. > While we make > > > > > > > > > binaries > > > > > > > > > > > available as a convenience we should not encourage > dependents to put > > > > > > > > > > > dependencies on our build tools. They should take > source and compile it > > > > > > > > > > > themselves for their own environment. > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > Tim > > > > > > > > > > > > > > > > > > > > > > Vasily Levchenko wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > $subj. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > With best regards, > > > > > > > Alexei > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > With best regards, > > > > > Alexei > > > > > > > > > > > > > > > > > > > > > -- > > > With best regards, > > > Alexei > > > > > > > > > -- > With best regards, > Alexei > -- With best regards, Alexei
