nice
On Mar 16, 2007, at 2:37 AM, Mikhail Loenko wrote:
> 2007/3/15, Geir Magnusson Jr. <geir@pobox.com>:
>> 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 <mloenko@gmail.com>:
>> >> 2007/3/14, Vladimir Beliaev <vladimir.k.beliaev@gmail.com>:
>> >> > 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
>> >> > JVMTIbased 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 <vera.y.petrashkova@intel.com>:
>> >> > >>
>> >> > >> 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 (H3363)
>> >> > >
>> >> > > 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
>> >> > >
>> >> >
>> >> >
>> >>
>>
>>
