ECperf is a standard EJB benchmark that we run on BEA's Weblogic. When we run against 1.4.0 beta-refresh with C2, we start getting (after a few minutes) a number of errors from the object input streams in use. A typical stack trace looks like this:

Caused by: java.io.StreamCorruptedException:
        at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1224)
        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:297)
        at weblogic.rmi.internal.CBVInputStream.readObjectInternal(CBVInputStrea
m.java:196)
        at weblogic.rmi.internal.CBVInputStream.readObject(CBVInputStream.java:1
87)
        at weblogic.rmi.internal.CBVInputStream.readObject(CBVInputStream.java:1
74)
        at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteR
ef.java:250)
        ... 13 more

These errors do not occur when using C1 or -Xint. They also do not occur immediately during the run; the objects in question have certainly been transferred over the object streams earlier in the run without a problem. In addition, it's not always the same object that triggers the error. In general, once the first of these errors occur, all the input streams that Weblogic uses seem to be reading corrupt data.

ECperf is a rather complicated application to set up (it requires three full tiers); the setup within the Performance Group can certainly be used to track this down (contact scott.oaks@east for more info).