2007/3/15, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
Did you try on the RI? (v5)?
I reduced the list to remove classes that fail on RI, the results are following: -Xverify: RI 2578 BEA 1937 Harmony 2172 Alt verifier 1593 -noverify: RI 1250 BEA 594 Harmony 1203 Alt verifier 1203 The difference is RI 1328 BEA 1343 Harmony 969 Alt verifier 391 Thanks, Mikhail
On Mar 15, 2007, at 2:51 AM, Mikhail Loenko wrote: > 2007/3/14, Mikhail Loenko <[EMAIL PROTECTED]>: >> 2007/3/14, Vladimir Beliaev <[EMAIL PROTECTED]>: >> > Mikhail, >> > >> > interesting... >> > >> > >> 4183 - passed on DRLVM >> > >> 4234 - passed on DRLVM with alternative bytecode verifier >> > >> > Is there any information related to passing other workloads? >> Like "using >> > JVMTI-based debugging & profiling..."? >> > >> > > It takes the original Java Class File containing no additional >> > information. >> > >> > How does it fit to JVMTI features like CLASS_FILE_LOAD_HOOK >> > (http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/ >> jvmti.html#ClassFileLoadHook) >> > >> > or Redefine Classes >> > (http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/ >> jvmti.html#RedefineClasses) >> >> this is about something different. What I was talking about is >> that no special >> attributes like StackMaps are necessary for the verification. >> >> > >> > > The approach results in significant performance and memory >> footprint >> > > advantage over regular verification. >> > >> > Particular data (gain, platform, drlvm configuration) is really >> > interesting :) >> > >> > Could you share it? Like for Eclipse starting time? >> >> Sure. I'm going to measure e.g. verification tine for all the >> Harmony classes >> and publish the results. Not sure if I could compare Eclipse >> starting time: >> on my machine it starts instantly on both verifiers > > I did some measurements. I took all the classes in Harmony JRE and > passed > them thru a microbenchmark. Something like that: > > long total = System.currentTimeMillis(); > for (int i=0; i<cnt; i++) { > cl = kl.defineKlass(clsNames[i], clsBytes[i]); > cl.getConstructors(); > } > total = System.currentTimeMillis() - total; > > Each new class was loaded by a new custom classloader (because of that > both RI and Harmony failed to load some of the classes - I removed > them from the list). > > For fair comparision I've also removed classes that contain jsr > instructions. > Finally I've got 7350 classes, I loaded them with BEA 1.5, Harmony- > pure, and > Harmony + alt verifier > > The results are: > with -Xverify option: > BEA 1.5: 2734 > Harmony alt verifier : 1734 > Harmony pure: 2344 > > with -noverify option: > BEA 1.5: 813 > Harmony alt verifier : 1297 > Harmony pure: 1297 > > So the differences are: > BEA 1.5 1.9 sec > Alt verifier: 0.4 sec > Harmony pure: 1.0 sec > > Thanks, > Mikhail > > >> >> Thanks, >> Mikhail >> >> >> > >> > Thanks >> > Vladimir Beliaev >> > >> > Mikhail Loenko wrote: >> > > 2007/3/14, Petrashkova, Vera Y <[EMAIL PROTECTED]>: >> > >> >> > >> Here are the results of VTS tests running: >> > >> 4320 VTS tests were run >> > >> 4183 - passed on DRLVM >> > >> 4234 - passed on DRLVM with alternative bytecode verifier >> > > >> > > Thanks, Vera! >> > > >> > > So, some words about the contribution (H-3363) >> > > >> > > As you probably know classic implementation of verifier requires >> > > complex time and memory consuming dataflow analysis that >> generates a >> > > proof of type safety. >> > > >> > > Some alternative approaches, for example CLDC verifier, >> require the >> > > class file to be annotated with the proof of type safety. To >> make sure >> > > the byte code is valid, verifier just validates the proof. That >> > > validation is fast and does not require much memory. >> > > >> > > The contributed verifier is a new verification approach based on >> > > Constraint Propagation. It takes the original Java Class File >> > > containing no additional information. For that class file it >> neither >> > > generates a direct proof of its validness nor validates any >> existing >> > > proof. >> > > >> > > Instead it generates a proof that a proof of validness does >> exist :) >> > > >> > > The approach results in significant performance and memory >> footprint >> > > advantage over regular verification. >> > > >> > > I'm finishing a document describing new verification in more >> details >> > > and going to put it into the Harmony docs >> > > >> > > Thanks, >> > > Mikhail >> > > >> > >> > >>
