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 Thu, 15 Mar 2007 11:18:46 GMT
Did you try on the RI?  (v5)?

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