Hi Mikhail, Thank you for the prompt reply. This information is encouraging!
Here are the answers to your questions: IsStackMapTableAttributeValid(): the original idea behind this function is to optimize the process and do not compute the StackMapTable if not necessary. However, after considering your options, it seems that only option 3 makes sense and hence we will not gain any performance benefit (because we effectively run full verification). I also think that the TPTP instrumentation engine has enough knowledge to know if a computation is really needed. Therefore, lets consider option 3 (for completeness) but I think this function is not required for TPTP. RecomputeStackMapTableAttribute(): - subroutines: we can assume there are no subroutines (jsr/ret instructions). Java 6 classes should not have them in the first place. Our instrumentation engine may use these instructions (e.g., some probe injections in Probekit use jsr/ret), but we can update the engine. - dead-code: while our instrumentation engine does not add "dead-code", I assume that the code we instrument may contain dead code. We should further discuss what are the best ways of handling this case (dead-code removal, "nop-ing" the dead code, etc). - extending the constant pool: no problem. We have the necessary functionality to arbitrarily modify the constant pool. Exposing this functionality to the verifier seems like a simple thing to do. Best regards, Asaf ----- Original Message ---- From: Mikhail Loenko <[EMAIL PROTECTED]> To: [email protected] Sent: Tuesday, October 30, 2007 5:51:23 PM Subject: Re: [drlvm][verifier] Using the Harmony verifier code for computing the StackMapTable attribute Hi Asaf! Welcome to Harmony dev forum :) I beleive current implementation of Harmony verifier [1] already covers most of what's necessary for you. It contains both old-style (Java5) verification and new-style (StackMapTable attribute based) one. So, it seems like a lightweigh extension to what Harmony already has would be enough. So, I have some questions. IsStackMapTableAttributeValid() - this seems to be the same as a full (or partial) new-style verification of a method. The following three ways are easiest to implement given current Harmony verifier design 1) check only structure of the attribute 2) the structure PLUS content except assignability of not-loaded classes (i.e. make a full verification WITHOUT checking assignability of not-loaded classes) 3) load missing classes and make a full verification Will anything from above suit your needs? RecomputeStackMapTableAttribute() Can the method byte-codes contain subroutines? Dead (unreachable) code? as a result of stackmaptable calculation it might be necessary to extend constant pool of the class. Is it acceptable in your environment? Thanks, Mikhail [1] http://svn.apache.org/viewvc/harmony/enhanced/drlvm/trunk/vm/vmcore/src/verifier-3363/ 2007/10/30, Asaf Yaffe <[EMAIL PROTECTED]>: > Hi, > > My name is Asaf Yaffe and I am a committer on the Eclipse Test and Performance Tool Platform (TPTP) Java Profiler project. We are currently working on updating our Binary Code Instrumentation (BCI) engine to support the new Java 6 class file format (version 50.0) and the new StackMapTable attribute. When the BCI engine modifies the byte-codes of a method, it must recompute the StackMapTable attribute to successfully pass the Java 6 verifier. The current implementation of Java 6 gracefully "falls-back" to the old verification scheme (which does not depend on the StackMapTable attribute) in face of a missing/invalid StackMapTable attribute. This may not be the case in future Java versions, and tool writers are encouraged to update their BCI-based tools (see here for more information: https://jdk.dev.java.net/verifier.html). > > Instead of developing StackMapTable calculation for the BCI engine, we would like to explore the option of reusing code from the Harmony byte-code verifier to recompute the StackMapTable of a method from its byte-codes. Ideally, we would like to have a stand-alone library (provided in source or binary form – exact distribution model should be discussed) which exports two APIs: > - IsStackMapTableAttributeValid(): given the method byte-codes and StackMapTable, checks whether the StackMapTable is valid. > - RecomputeStackMapTableAttribute(): given the method byte-codes, produces a new valid StackMapTable that can be used by the Java 6 verifier of any Java 6-compliant JVM. > > With best regards, > > Asaf Yaffe > Eclipse TPTP Committer, JVMTI Profiler component. > > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
