harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Beliaev" <vladimir.k.beli...@gmail.com>
Subject Re: [drlvm] verifier discussion
Date Thu, 05 Jul 2007 08:38:54 GMT
> 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message