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
