harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [DRLVM] contribution of alternative bytecode verifier
Date Mon, 19 Mar 2007 04:11:43 GMT
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
>> >> > 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 <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 (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
>> >> > >
>> >> >
>> >> >
>> >>
>>
>>


Mime
View raw message