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 15:11:40 GMT
2007/3/14, Alexei Fedotov <alexei.fedotov@gmail.com>:
> Hello Mikhail,
>
> It's really nice to see that you are interested in bytecode
> verification. I like an idea of your algorithm. BTW, is it possible to
> make your verifier compatible with RI?

Yes. That would cost ~50 lines of code, performance impact close to zero,
but the code transparency and readability would be worse.

Since the difference is in the dead code processing I suspect that
it's OK not to fix that. At least until we have a solid reason for that :)

>
> Have you taken a look at subroutine markup algortim suggested few
> weeks ago (http://wiki.apache.org/harmony/Subroutine_Verification)? Do
> you think it is correct and worth to be implemented?

I looked at that, and I need more time to provide any feedback

Thanks,
Mikhail


>
> Thank you in advance for review and feedback,
> Alexei
>
> On 3/14/07, Mikhail Loenko <mloenko@gmail.com> 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
> >
>
>
> --
> With best regards,
> Alexei,
> ESSD, Intel
>

Mime
View raw message