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 <[EMAIL PROTECTED]>:
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 <[EMAIL PROTECTED]>: > 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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/[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] > > > > > > > > > -- > > With best regards, > > Alexei, > > ESSD, Intel > > > > > -- > http://xiao-feng.blogspot.com
