harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Harmony Wiki] Update of "Subroutine Verification" by AlexeiFedotov
Date Fri, 15 Feb 2008 14:41:38 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Harmony Wiki" for change notification.

The following page has been changed by AlexeiFedotov:
http://wiki.apache.org/harmony/Subroutine_Verification

------------------------------------------------------------------------------
  === Motivation and Problem Statement ===
  
- The ''bytecode verification'' is an important part of Java security and is checked by TCK.
To pass TCK, we need to support any aspect of the verification including the ''subroutine
verification''.
+ The ''bytecode verification'' is an important part of Java security and is checked by TCK.
While modern compilers do not generate subroutines, to pass TCK, we need to support any aspect
of the verification including the ''subroutine verification''.
  
+ We created a modular [http://svn.apache.org/viewvc/harmony/enhanced/drlvm/archive/vm/verifier/
subroutine inliner], which then reused the data flow analysis for programs without subroutines.
Inlining approach allows supporting a bigger subset of type-safe programs [3], for example,
the programs generated by bytecode optimizers. While our solution is compatible with specification,
it can be easily tuned and extended to different safe program sets.
- Currently, DRLVM contains a bytecode verifier, which does not support the subroutine verification.
The verifier implementation remembers only one stack map for each instruction, while stack
maps for subroutine instructions depend on a calling context and may differ for stack elements
and local variables the subroutine does not touch.
- 
- Taking into account that modern Java compilers generating code without subroutines, we choose
to create a module for a simple data flow analysis to inline subroutines and reuse existing
data flow algorithm. Also, inlining is considered by research community [3] as less restrictive
appproach for supporting a bigger subset of type-safe programs in future, for example, generated
by bytecode optimizers.
  
  === Definitions ===
  

Mime
View raw message