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 <[EMAIL PROTECTED]>:
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/[EMAIL PROTECTED] [2] http://issues.apache.org/jira/browse/HARMONY-3363 [3] http://mail-archives.apache.org/mod_mbox/harmony-dev/200703.mbox/[EMAIL PROTECTED] [4] http://mail-archives.apache.org/mod_mbox/harmony-dev/200703.mbox/[EMAIL PROTECTED]
