harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Loenko" <mloe...@gmail.com>
Subject Re: [drlvm] verifier discussion
Date Fri, 06 Jul 2007 11:46:01 GMT
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
>

Mime
View raw message