harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Fedotov" <alexei.fedo...@gmail.com>
Subject Re: [drlvm][class loading] erroneous entry due to different signature
Date Sat, 26 Apr 2008 10:33:49 GMT
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
>  >  >  >  >  > >  >
>  >  >  >  >  > >
>  >  >  >  >  > >  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
>  >  >  >  >  > >  > >  > >
>  >  >  >  >  > >  > >  > >  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
View raw message