harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Beliaev <vladimir.k.beli...@gmail.com>
Subject Re: [DRLVM] contribution of alternative bytecode verifier
Date Wed, 14 Mar 2007 12:09:16 GMT
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)

 > 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?

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