You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Alexei Fedotov <al...@gmail.com> on 2008/04/26 07:57:05 UTC
[drlvm][class loading] erroneous entry due to different signature
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
<al...@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
>
>
> <st...@gmail.com> wrote:
> > On 4/24/08, Alexei Fedotov <al...@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
> > > <st...@gmail.com> wrote:
> > > > On 4/24/08, Alexei Fedotov <al...@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
> > > > > <st...@gmail.com> wrote:
> > > > > > Hi Alexei,
> > > > > >
> > > > > >
> > > > > > On 4/24/08, Alexei Fedotov <al...@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
> > > > > > > <st...@gmail.com> wrote:
> > > > > > > > On 4/22/08, Tim Ellison <t....@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....@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
Re: [drlvm][class loading] erroneous entry due to different signature
Posted by Alexei Fedotov <al...@gmail.com>.
Alexey,
Yes, my initial evaluation was incorrect.
I read the test by means of jcf-dump and have missed an exception
range which followed the code.
Thanks.
On Tue, Apr 29, 2008 at 10:37 AM, Alexey Varlamov
<al...@gmail.com> wrote:
> Err - so your initial evaluation was not truly correct, right?
> The test expects NoSuchMethodError rather than "RI tolerates these two
> mismatches and runs without exception" which was very confusing.
>
> Regards,
> Alexey
>
> 2008/4/28, Alexei Fedotov <al...@gmail.com>:
>
>
> > Nathan, yes, your understanding is correct. I deleted an assertion and
> > the test started producing NoSuchMethodError. BTW, thanks to your
> > question, I have fixed class NoSuchMethodException to
> > NoSuchMethodError in an explanatory comment in the patch.
> >
> > On Sun, Apr 27, 2008 at 1:24 AM, Nathan Beyer <nd...@apache.org> wrote:
> > > 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 <al...@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
> > > > <al...@gmail.com> wrote:
> > > > > Sorry, not so easy.
> > > > >
> > > > > On Sat, Apr 26, 2008 at 11:44 AM, Alexei Fedotov
> > > > >
> > > > >
> > > > > <al...@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
> > > > > >
> > > > > >
> > > > > > <al...@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
> > > > > > > <al...@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
> > > > > > > >
> > > > > > > >
> > > > > > > > <st...@gmail.com> wrote:
> > > > > > > > > On 4/24/08, Alexei Fedotov <al...@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
> > > > > > > > > > <st...@gmail.com> wrote:
> > > > > > > > > > > On 4/24/08, Alexei Fedotov <al...@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
> > > > > > > > > > > > <st...@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
> > > > > > > > > > > > > > <st...@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....@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
> > > >
> > >
> >
> >
> >
> > --
> > With best regards,
> > Alexei
> >
>
--
With best regards,
Alexei
Re: [drlvm][class loading] erroneous entry due to different signature
Posted by Alexey Varlamov <al...@gmail.com>.
Err - so your initial evaluation was not truly correct, right?
The test expects NoSuchMethodError rather than "RI tolerates these two
mismatches and runs without exception" which was very confusing.
Regards,
Alexey
2008/4/28, Alexei Fedotov <al...@gmail.com>:
> Nathan, yes, your understanding is correct. I deleted an assertion and
> the test started producing NoSuchMethodError. BTW, thanks to your
> question, I have fixed class NoSuchMethodException to
> NoSuchMethodError in an explanatory comment in the patch.
>
> On Sun, Apr 27, 2008 at 1:24 AM, Nathan Beyer <nd...@apache.org> wrote:
> > 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 <al...@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
> > > <al...@gmail.com> wrote:
> > > > Sorry, not so easy.
> > > >
> > > > On Sat, Apr 26, 2008 at 11:44 AM, Alexei Fedotov
> > > >
> > > >
> > > > <al...@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
> > > > >
> > > > >
> > > > > <al...@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
> > > > > > <al...@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
> > > > > > >
> > > > > > >
> > > > > > > <st...@gmail.com> wrote:
> > > > > > > > On 4/24/08, Alexei Fedotov <al...@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
> > > > > > > > > <st...@gmail.com> wrote:
> > > > > > > > > > On 4/24/08, Alexei Fedotov <al...@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
> > > > > > > > > > > <st...@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
> > > > > > > > > > > > > <st...@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....@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
> > >
> >
>
>
>
> --
> With best regards,
> Alexei
>
Re: [drlvm][class loading] erroneous entry due to different signature
Posted by Alexei Fedotov <al...@gmail.com>.
Nathan, yes, your understanding is correct. I deleted an assertion and
the test started producing NoSuchMethodError. BTW, thanks to your
question, I have fixed class NoSuchMethodException to
NoSuchMethodError in an explanatory comment in the patch.
On Sun, Apr 27, 2008 at 1:24 AM, Nathan Beyer <nd...@apache.org> wrote:
> 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 <al...@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
> > <al...@gmail.com> wrote:
> > > Sorry, not so easy.
> > >
> > > On Sat, Apr 26, 2008 at 11:44 AM, Alexei Fedotov
> > >
> > >
> > > <al...@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
> > > >
> > > >
> > > > <al...@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
> > > > > <al...@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
> > > > > >
> > > > > >
> > > > > > <st...@gmail.com> wrote:
> > > > > > > On 4/24/08, Alexei Fedotov <al...@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
> > > > > > > > <st...@gmail.com> wrote:
> > > > > > > > > On 4/24/08, Alexei Fedotov <al...@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
> > > > > > > > > > <st...@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
> > > > > > > > > > > > <st...@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....@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
> >
>
--
With best regards,
Alexei
Re: [drlvm][class loading] erroneous entry due to different signature
Posted by Nathan Beyer <nd...@apache.org>.
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 <al...@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
> <al...@gmail.com> wrote:
> > Sorry, not so easy.
> >
> > On Sat, Apr 26, 2008 at 11:44 AM, Alexei Fedotov
> >
> >
> > <al...@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
> > >
> > >
> > > <al...@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
> > > > <al...@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
> > > > >
> > > > >
> > > > > <st...@gmail.com> wrote:
> > > > > > On 4/24/08, Alexei Fedotov <al...@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
> > > > > > > <st...@gmail.com> wrote:
> > > > > > > > On 4/24/08, Alexei Fedotov <al...@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
> > > > > > > > > <st...@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
> > > > > > > > > > > <st...@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....@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
>
Re: [drlvm][class loading] erroneous entry due to different signature
Posted by Alexei Fedotov <al...@gmail.com>.
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
<al...@gmail.com> wrote:
> Sorry, not so easy.
>
> On Sat, Apr 26, 2008 at 11:44 AM, Alexei Fedotov
>
>
> <al...@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
> >
> >
> > <al...@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
> > > <al...@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
> > > >
> > > >
> > > > <st...@gmail.com> wrote:
> > > > > On 4/24/08, Alexei Fedotov <al...@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
> > > > > > <st...@gmail.com> wrote:
> > > > > > > On 4/24/08, Alexei Fedotov <al...@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
> > > > > > > > <st...@gmail.com> wrote:
> > > > > > > > > Hi Alexei,
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On 4/24/08, Alexei Fedotov <al...@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
> > > > > > > > > > <st...@gmail.com> wrote:
> > > > > > > > > > > On 4/22/08, Tim Ellison <t....@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....@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
Re: [drlvm][class loading] erroneous entry due to different signature
Posted by Alexei Fedotov <al...@gmail.com>.
Sorry, not so easy.
On Sat, Apr 26, 2008 at 11:44 AM, Alexei Fedotov
<al...@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
>
>
> <al...@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
> > <al...@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
> > >
> > >
> > > <st...@gmail.com> wrote:
> > > > On 4/24/08, Alexei Fedotov <al...@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
> > > > > <st...@gmail.com> wrote:
> > > > > > On 4/24/08, Alexei Fedotov <al...@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
> > > > > > > <st...@gmail.com> wrote:
> > > > > > > > Hi Alexei,
> > > > > > > >
> > > > > > > >
> > > > > > > > On 4/24/08, Alexei Fedotov <al...@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
> > > > > > > > > <st...@gmail.com> wrote:
> > > > > > > > > > On 4/22/08, Tim Ellison <t....@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....@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
Re: [drlvm][class loading] erroneous entry due to different signature
Posted by Alexei Fedotov <al...@gmail.com>.
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
<al...@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
> <al...@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
> >
> >
> > <st...@gmail.com> wrote:
> > > On 4/24/08, Alexei Fedotov <al...@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
> > > > <st...@gmail.com> wrote:
> > > > > On 4/24/08, Alexei Fedotov <al...@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
> > > > > > <st...@gmail.com> wrote:
> > > > > > > Hi Alexei,
> > > > > > >
> > > > > > >
> > > > > > > On 4/24/08, Alexei Fedotov <al...@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
> > > > > > > > <st...@gmail.com> wrote:
> > > > > > > > > On 4/22/08, Tim Ellison <t....@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....@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