Cool! Do I understand correct that VTS tests [1] that currently fail because of unimplemented subroutine verification will now pass?
I'm going to run the DRLVM VTS to check how it impacts the pass rate Thanks, Vera [1] http://issues.apache.org/jira/browse/HARMONY-3206 >---------- Forwarded message ---------- >From: Mikhail Loenko (JIRA) <[EMAIL PROTECTED]> >Date: 12.03.2007 16:55 >Subject: [jira] Created: (HARMONY-3363) [DRLVM] contribution of >alternative bytecode verifier >To: [EMAIL PROTECTED] > > >[DRLVM] contribution of alternative bytecode verifier >----------------------------------------------------- > > Key: HARMONY-3363 > URL: https://issues.apache.org/jira/browse/HARMONY-3363 > Project: Harmony > Issue Type: New Feature > Components: Contributions > Reporter: Mikhail Loenko > > >This is contribution of experimental bytecode verifier on behalf of Intel. > >"Experimental" means that there is no formal proof currently available >of its equivalence to the step-by-step verification algorithm >described in the spec. > >The only known difference to the conventional verifier is dead code >verification: RI makes stricter checks against dead code. >Since it's about dead code, this difference does not affect vulnerability > >Comparing to the current Harmony verifier, this one is supposed to be >complete (Harmony currently does not support jsr/ret verification) and >much faster > >So, I'm attaching 3 files: > >The first one: Verifier_bulk.zip is a bulk contribution on behalf of >Intel for archiving purposes. It contains the legal files as well > >The second one: Verifier_patch is my fix to the bugs that I found >while the first archive was coming thru legal > >The third archive Verifier_patched.zip is a merge for previous two. >It's an up-to-date version for all the engineering purposes > >To try it out one should replace the current 'verifier' directory in >vm with the new one and rebuild > >-- >This message is automatically generated by JIRA. >- >You can reply to this email to add a comment to the issue online.
