harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [drlvm] verifier discussion
Date Thu, 05 Jul 2007 09:25:16 GMT
The suggestion to make the verifier a pluggable component sounds
reasonable to me. Hopefully it's not a huge effort.

Thanks,
xiaofeng

On 7/5/07, Vladimir Beliaev <vladimir.k.beliaev@gmail.com> wrote:
> > I suggest that we switch default implementation for Harmony
>
> *Let's do not rash here..*. I have several points to show *the switching
> requires more preparation work to be done by promoter (Mikhail)*:
>
> 1. *the alternative verifier should be easily tuned off (pluggable) if it
> shows the problem or for comparison with current verifier*. So integration
> of alternative verifier should be coupled with "making verifier to be
> pluggable component" (this would allow the command line switching like Xiao
> Fend had done for GC_GEN).
>
> 2. alternative verifier passed VTS which is good, *one needs to be sure that
> there is no regression for pretty long workloads list which are announced as
> supported for passed M2* I believe the regression (after switching to
> alternative verified) is not allowed. This is one more "pro" for making
> verifier to be pluggable. We have such an expirience with GC - first GC_GEN
> was kept as "alternative" and Xiao Feng has fixed a pretty huge number of
> bugs - and finally he made GC_GEN to be default.
>
> 3. about performance comparison.
>
>    3.1 *one needs to show the real performance benefit of switching to
> alternative verifier*. I mean the benefit on SPECs may be really minor, so
> it worth not using significant time on testing "pretty long workloads list"
> + fixing bugs in alternative verifier.
>
>    3.2 *the accurate performance comparison must list the classes / methods
> processed*. I think now (because I know a bit more now about verifier) that
> using '-Xverify' & '-noverify' is not quite accurate way. The current
> verifier may do more checks then alternative ones (it is known it is more
> strict then it is required by specification). And it may worth simplifying
> the existing verifier instead of integrating the completely new one.
>
> *Hope all the above is resonable. I based the notes on experience with
> switching on GC_GEN which community has already.*
>
> Thanks
> Vladimir Beliaev
>
>
> 2007/7/5, Mikhail Loenko <mloenko@gmail.com>:
> >
> > 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
> >
>


-- 
http://xiao-feng.blogspot.com

Mime
View raw message