Hi Mikhail, All class_*, method_* and field_* functions from the class interface can be mapped to an implementation within the TPTP BCI engine. The main issue is with the Class Loader functions (cl_*): generally, these functions can be implemented using JNI. However, some classes are being instrumented during the JVM bootstrapping, where JNI is not yet available. Therefore, we cannot guarantee that class loading functionality will always be available, and we will need to somehow work around this limitation. One option, for example, is not to do any byte-code modifications until the JVM is initialized, and then use RedefineClasses to instrument bootstrap classes.
Please let me know if there are any other issues, and what do you think should be the next steps. Best regards, Asaf ----- Original Message ---- From: Mikhail Loenko <[EMAIL PROTECTED]> To: [email protected] Sent: Thursday, November 1, 2007 7:38:21 AM Subject: Re: [drlvm][verifier] Using the Harmony verifier code for computing the StackMapTable attribute Hi Asaf see some questions below 2007/10/31, Asaf Yaffe <[EMAIL PROTECTED]>: > 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). I need to think about that... > - 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. Currently verifier uses the following list of functions from the class_interface: cl_get_class cl_load_class cl_acquire_lock cl_release_lock cl_get_verify_data_ptr cl_set_verify_data_ptr class_get_class_loader class_get_cp_class_name_index class_get_cp_descriptor_index class_get_cp_name_index class_get_cp_ref_class_index class_get_cp_ref_name_and_type_index class_get_cp_size class_get_cp_tag class_get_cp_utf8_bytes class_get_method class_get_method_number class_get_name class_get_super_class class_get_version class_is_interface_ class_is_same_package class_resolve_method class_resolve_nonstatic_field field_is_protected method_get_bytecode method_get_code_length method_get_descriptor method_get_exc_handler_info method_get_exc_handler_number method_get_max_local method_get_max_stack method_get_name method_get_stackmaptable method_is_protected method_is_static The description of what these functions do can be found here[1] Please let me know whether there is a necessary functionality to implement thse interface functions and whether they can be invoked at the moment when recompute of stackmap attribute happens Thanks, Mikhail [1] http://svn.apache.org/viewvc/harmony/enhanced/drlvm/trunk/vm/vmcore/include/class_interface.h?view=markup > > 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 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
