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] verifier discussion
Date Fri, 06 Jul 2007 13:19:38 GMT
Mikhail,
You wrote:

> The time flies when
> you are having fun :) I'm volunteering to do all the necessary updates.

For me this is an important point which gives you a carte blanche. :-)
Good luck.
Alexei


On 7/6/07, Vladimir Beliaev <vladimir.k.beliaev@gmail.com> wrote:
> I'm ok with opportunity to pick 1 of 2 verifiers on a build time... The rest
> of points seems to be resonable for me.
>
> Thanks
> Vladimir Beliaev
>
> 2007/7/6, Mikhail Loenko <mloenko@gmail.com>:
> >
> > Thank you all for your comments!
> >
> > Here I combined my responses to all the comments.
> >
> > Java6 verification can be obtained from both implementations basically
> > by removing the code :). Since legacy apps will exist some (I guess
> > long) time, we will need pre- Java 6 verifier, so working on its
> > quality and performance makes sense IMHO.
> >
> > I don't think that time and efforts are an issue. The time flies when
> > you are having fun :) I'm volunteering to do all the necessary
> > updates.
> >
> > I tested the patch on most of the scenarios that are in BTI2,
> > including TPTP tests, so I don't expect significant problems here, and
> > sure we may want to decide to switch back later like we did it with
> > our first attempt to switch to GCv5.
> >
> > As for moving this functionality to dll, I'm not sure it's the right
> > thing to do. We had several examples in Harmony when we had
> > alternative implementations of the same thing. In most of the cases
> > (e.g. Crypto, Math, RMI) we had a build switch, and only in case of GC
> > we had a runtime switch.
> >
> > GC is special because it was easy to identify where the bug is by
> > switching GC in runtime. Since almost all the verifier bugs can be
> > easily identified by "VerifyError" or by using "-noverify" option, I
> > think a build switch is enough here.
> >
> > The SPECs do not spend much time in verification, but I observe
> > Eclipse start time improvement on my laptop.
> >
> > Please let me know if it sounds reasonable
> >
> > Thanks,
> > Mikhail
> >
> > 2007/7/5, Xiao-Feng Li <xiaofeng.li@gmail.com>:
> > > It's a wise choice for Java6 to decouple the type inferencing from
> > > online type checking. To decide which verifier to use, we probably
> > > need know which design is better for the type checking transition.
> > >
> > > Thanks,
> > > xiaofeng
> > >
> > > On 7/5/07, Alexei Fedotov <alexei.fedotov@gmail.com> wrote:
> > > > Mikhail,
> > > >
> > > > Your verifier implemented very interesting algorithm.
> > > >
> > > > * We already started moving into Java 6.0 direction, and Java 6.0
> > > > suggested a different verification scheme [1]. I see implementing this
> > > > scheme as more important task than switching between two old
> > > > verifiers.
> > > >
> > > > * When a new scheme is implemented the legacy scheme won't be used
> > > > often, this means performance considerations are of less importance
> > > > compared to minimal risk considerations and ease of bug fixing. Any
> > > > switching comes at the cost of risk and increase in maintenance
> > > > efforts.
> > > >
> > > > * The legacy scheme is to be completely removed from specification
> > > > soon, so the new verifier should be separate from the old code. I
> > > > found it more productive to decide which verifier code base should be
> > > > a base for new development.
> > > >
> > > > What do you think?
> > > >
> > > > [1] New Java SE 6 Feature: Type Checking Verifier,
> > > > https://jdk.dev.java.net/verifier.html
> > > >
> > > >
> > > > On 7/5/07, Mikhail Loenko <mloenko@gmail.com> wrote:
> > > > > We have passed code and feature freeze recently and have a momentum
> > for
> > > > > bigger changes in the code.
> > > > >
> > > > > We have recently accepted [1] a contribution of an alternative
> > implementation of
> > > > > bytecode verifier [2]
> > > > >
> > > > > New implementation demonstrated pretty nice testing [3] and
> > > > > performance results [4].
> > > > >
> > > > > Though many bugs in current implementation were fixed and it now
> > also
> > > > > demonstrate good testing results, the performance difference remains
> > the same.
> > > > >
> > > > > I suggest that we switch default implementation for Harmony
> > > > >
> > > > > Thanks,
> > > > > Mikhail
> > > > >
> > > > > [1]
> > http://mail-archives.apache.org/mod_mbox/harmony-dev/200706.mbox/%3c906dd82e0706040145o1173ce6dqcc671777c5b413c6@mail.gmail.com%3e
> > > > >
> > > > > [2] http://issues.apache.org/jira/browse/HARMONY-3363
> > > > >
> > > > > [3]
> > http://mail-archives.apache.org/mod_mbox/harmony-dev/200703.mbox/%3c8E389A5F2FEABA4CB1DEC35A25CB39CEB48212@mssmsx411%3e
> > > > >
> > > > > [4]
> > http://mail-archives.apache.org/mod_mbox/harmony-dev/200703.mbox/%3c906dd82e0703152337n133fafd8t8275ed9277c00204@mail.gmail.com%3e
> > > > >
> > > >
> > > >
> > > > --
> > > > With best regards,
> > > > Alexei,
> > > > ESSD, Intel
> > > >
> > >
> > >
> > > --
> > > http://xiao-feng.blogspot.com
> >
>


-- 
With best regards,
Alexei,
ESSD, Intel

Mime
View raw message