harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Beyer" <ndbe...@apache.org>
Subject Re: [drlvm][class loading] erroneous entry due to different signature
Date Sat, 26 Apr 2008 21:24:37 GMT
Just so I understand, the resolution is that the assertion was incorrect. Is
that correct?

-Nathan

On Sat, Apr 26, 2008 at 5:33 AM, Alexei Fedotov <alexei.fedotov@gmail.com>
wrote:

> 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
> <alexei.fedotov@gmail.com> wrote:
> > Sorry, not so easy.
> >
> >  On Sat, Apr 26, 2008 at 11:44 AM, Alexei Fedotov
> >
> >
> > <alexei.fedotov@gmail.com> 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
> >  >
> >  >
> >  > <alexei.fedotov@gmail.com> 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
> >  >  >  <alexei.fedotov@gmail.com> 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
> >  >  >  >
> >  >  >  >
> >  >  >  > <stepan.mishura@gmail.com> wrote:
> >  >  >  >  > On 4/24/08, Alexei Fedotov <alexei.fedotov@gmail.com>
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
> >  >  >  >  >  > <stepan.mishura@gmail.com> wrote:
> >  >  >  >  >  > > On 4/24/08, Alexei Fedotov <alexei.fedotov@gmail.com>
> wrote:
> >  >  >  >  >  > >
> >  >  >  >  >  > > > Stenan,
> >  >  >  >  >  > >  > Sorry. I have fixed VTS verifier test failures:
> >  >  >  >  >  > >  >
> http://people.apache.org/~smishura/r650380/Windows_x86/vtsvm/junit/index.html<http://people.apache.org/%7Esmishura/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
> >  >  >  >  >  > >  > <stepan.mishura@gmail.com> wrote:
> >  >  >  >  >  > >  > > Hi Alexei,
> >  >  >  >  >  > >  > >
> >  >  >  >  >  > >  > >
> >  >  >  >  >  > >  > >  On 4/24/08, Alexei Fedotov <
> alexei.fedotov@gmail.com> 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
> >  >  >  >  >  > >  > >  > <stepan.mishura@gmail.com>
wrote:
> >  >  >  >  >  > >  > >  > > On 4/22/08, Tim Ellison
<
> t.p.ellison@gmail.com> 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<http://people.apache.org/%7Emloenko/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 <t.p.ellison@gmail.com>
> >  >  >  >  >  > >  > >  > >  > 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message