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
>> > >
>> >
>> >
>>
