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
