harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Loenko" <mloe...@gmail.com>
Subject Re: [DRLVM] contribution of alternative bytecode verifier
Date Fri, 16 Mar 2007 06:37:51 GMT
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