C2 performs very badly on the following test program:

import oracle.sql.NUMBER;

public class OracleTest {
    public static void main(String[] args) {

        byte[] b = new byte[1];
        b[0] = 0x41;
        NUMBER.isValid(b);

        long then = System.currentTimeMillis();
        for (int i = 0; i < 100000; i++) {
            NUMBER.isValid(b);
        }
        long now = System.currentTimeMillis();
        System.out.println("TOOK " + (now - then) + " milliseconds");

        then = System.currentTimeMillis();
        for (int i = 0; i < 100000; i++) {
            NUMBER.isValid(b);
        }
        now = System.currentTimeMillis();
        System.out.println("TOOK " + (now - then) + " milliseconds");
    }
}

Running this with C1 and C2 shows C2 is 3 orders of magnitude slower, and C2
gets worse the longer it runs (e.g. the second time through the loop):

% cd /home/sdo/OracleTest
% setenv CLASSPATH ./classes12.zip:.
% java -version
java version "1.4.0-beta_refresh"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta_refresh-b68)
Java HotSpot(TM) Client VM (build 1.4.0-beta_refresh-b68, mixed mode)
% java -client OracleTest
TOOK 35 milliseconds
TOOK 10 milliseconds
% java -server OracleTest
TOOK 16137 milliseconds
TOOK 25773 milliseconds

This has a big impact on ECperf runs: when this bug is triggered, ECperf will spend almost all of its time in oracle.sql.NUMBER._isPositive (which is a
trivial static method called by the isValid() method).

Triggering this bug is somewhat subtle: slightly peturbing the test case will make it not trigger, and triggering it ECperf seems to be non-deterministic.

The test case requires the Oracle JDBC drivers (classes12.zip); the test case and the drivers can be found in /home/sdo/OracleTest for .eng domain users.