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 Wed, 14 Mar 2007 13:15:10 GMT
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

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