Mikhail, You wrote: > The time flies when > you are having fun :) I'm volunteering to do all the necessary updates. For me this is an important point which gives you a carte blanche. :-) Good luck. Alexei On 7/6/07, Vladimir Beliaev wrote: > 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 : > > > > 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 : > > > 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 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 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 > > > -- With best regards, Alexei, ESSD, Intel