The issue is resolved in HARMONY-5797. Pavel, could you please take a look?
[1] https://issues.apache.org/jira/browse/HARMONY-5797
On Sat, Apr 26, 2008 at 1:14 PM, Alexei Fedotov
<[EMAIL PROTECTED]> wrote:
> Sorry, not so easy.
>
> On Sat, Apr 26, 2008 at 11:44 AM, Alexei Fedotov
>
>
> <[EMAIL PROTECTED]> wrote:
> > For a java guru the following code demonstrates the problem. The
> > following works perfectly on Sun's VM (though it does not compile
> > well):
> >
> > public class T1 implements I {
> > public void t(int p) {
> > }
> >
> > public static void main(String args[]) {
> > (new T1()).t(0);
> > }
> > }
> >
> > interface I {
> > void t(Object p);
> > }
> >
> > This might be a way to convert an integer to a direct reference. :-)
> >
> >
> > On Sat, Apr 26, 2008 at 9:57 AM, Alexei Fedotov
> >
> >
> > <[EMAIL PROTECTED]> wrote:
> > > 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
> > >
> >
> >
> >
> > --
> > With best regards,
> > Alexei
> >
>
>
>
> --
> With best regards,
> Alexei
>
--
With best regards,
Alexei
