Hello, Mikhail,
> So the differences are:
> BEA 1.5 1.9 sec
> Alt verifier: 0.4 sec
> Harmony pure: 1.0 sec
Interesting... I see that proposed benchmark is pretty correct (for
comparison of BEA & Harmony).
So, waiting for documentation you are preparing :)
Thank you
Vladimir Beliaev
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
> >
>
>
