Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: neutral (herse.apache.org: 216.86.168.178 is neither permitted
 nor denied by domain of geir@pobox.com)
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <906dd82e0703140406w4bfbb79en1dd5b8f906f5e599@mail.gmail.com>
References: <906dd82e0703140406w4bfbb79en1dd5b8f906f5e599@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <A4F0BAE4-EFC5-4FEE-A64F-EEE656A2BABB@pobox.com>
Content-Transfer-Encoding: 7bit
From: "Geir Magnusson Jr." <geir@pobox.com>
Subject: Re: [DRLVM] contribution of alternative bytecode verifier
Date: Thu, 15 Mar 2007 07:19:07 -0400
To: dev@harmony.apache.org

THis is great - it will be interesting to see what/if the TCK says  
about it.

geir

On Mar 14, 2007, at 7:06 AM, 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