Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "TPTP-AG-20080205"

m (Minutes)
 
(3 intermediate revisions by one other user not shown)
Line 25: Line 25:
  
 
* Overview:  
 
* Overview:  
** Java 6 introduced a class file format (e.g. 60) and a new attribute (StackMapTable) for verifying the possible values (including type information) of the operand-stack and the local variable table at the beginning of each basic-block/instruction.
+
** Java 6 introduced a class file format (e.g. 50.0) and a new attribute (StackMapTable) for verifying the possible values (including type information) of the operand-stack and the local variable table at the beginning of each basic-block/instruction.
 
** Generated during compilation and used during class load to verify the type-safety of the code.  
 
** Generated during compilation and used during class load to verify the type-safety of the code.  
 
** The TPTP BCI engine changes the byte code of a class so its needs to recalculate this attribute based on the new control/data flow after the BCI.
 
** The TPTP BCI engine changes the byte code of a class so its needs to recalculate this attribute based on the new control/data flow after the BCI.
Line 37: Line 37:
  
 
* Design:
 
* Design:
 +
** Diagram: <br/>[[Image:figure_1.JPG|Participating Modules, Interfaces and dependencies]]
 
** Check-in the static binary library (verifier.lib or 'verifier') provided by the Apache Harmony project to CVS (as part of the BCI component) and use it in the TPTP build process.   
 
** Check-in the static binary library (verifier.lib or 'verifier') provided by the Apache Harmony project to CVS (as part of the BCI component) and use it in the TPTP build process.   
 
** Since the library is static, there is no need to ship with the product.
 
** Since the library is static, there is no need to ship with the product.
 
** The verifier and BCI classes need to communicate through a set of abstract interfaces, defined in the Apache Harmony project.
 
** The verifier and BCI classes need to communicate through a set of abstract interfaces, defined in the Apache Harmony project.
 
** TPTP will implement these abstract interfaces in the BCI engine.
 
** TPTP will implement these abstract interfaces in the BCI engine.
** The TPTP BCI engine has access to ~85% of the necessary information at run-time for the implementation of these abstract interfaces.   
+
** When the verifier runs, it requires method and class information. 
 
+
** The TPTP BCI engine at run-time has access to ~85% of this necessary information from the class file.   
[[Image:figure_1.JPG|Participating Modules, Interfaces and dependencies]]
+
** Problem: The TPTP BCI engine at run-time does not accesses to ~15% of this necessary information since it instruments one class file at a time and this information can only be resolved by walking the inheritance chain, for example, is class A is a superclass of class B, is class B is a super class of class C, and etc..
 
+
** Solution: The TPTP BCI engine would use JNI/JVMTI to load the class hierarchy and resolve the ~15% of this necessary information.
** Challenge: When the verifier runs, it requires method and class information available in the class file.  However, there is other information not available in the class file or from TPTP BCI engine.  Uses JNI/JVMTI to resolve this information (is class A is a superclass of class B, is class B is a superclass of class C, and etc., so you need to walk the inheritance chain since the ProbeInstrumentator.exe instruments one class file at a time).  ProbeKit Agent and JVMTI run in the JVM so no problem, ProbeInstrumentator.exe must create a JVM instance.
+
** This is not an issue for the ProbeKit Agent and JVMTI since they run in a JVM.
 
+
** However, the ProbeInstrumenter.exe does not require a JVM so this solution would require it to create a JVM instance.
Question: What is the importance ProbeInstrumentor.exe to IBM?  Web application environment and problem determination with customer support.
+
** The ProbeInstrumenter.exe is important to IBM for static instrumentation and deployment to web application servers or customers for problem determination.
 
+
** In addition, the ProbeInstrumenter.exe would require access to all dependencies of the classes being instrumented.
Make ProbeInstrumentor.exe a Java application.
+
** One possible solution would be to make ProbeInstrumenter.exe a Java application.
 
+
** One concern mentioned is compatibility between vendors and versions of JDKs/JREs (e.g. compiling against Sun VM and running against an IBM (or JRockit) VM?
What happens when compiling against Sun VM and running against an IBM VM (or JRocket)?
+
** Not a concern since only class and method signatures are used.
 
+
** Another concern is the situation where JNI/JVMTI is needed but not available, for example instrumenting using dynamic Probekit classes loaded before the JVM fully initializes the JNI/JVMTI interfaces.
Only uses class and method signatures.
+
** There is a list of Sun, IBM, and JRockit classes (1.5) that applies (IBM loads the most classes before initializing JNI).
 
+
** Need to determine how to handle this situation, for example, documentation or maintaining the hierarchy of classes. 
Will need the classes/JARs for all of the dependencies.
+
** The remainder of this work can be completed in I6.
 
+
What happens when you need JNI/JVMTI but it is not available?  Dynamic Probekit for example, since the classes are loaded before JNI is loaded. We have the list for Sun, IBM, and JRocket for 1.5IBM loads the most classes before initializing JNI.  
+
 
+
The remainder of this work can be completed in I6.
+
  
 
== Questions/Answers ==
 
== Questions/Answers ==
  
 
* '''Q:''' What is the arrangement/agreement with the Apache Harmony project?  For example, coordinated design/implementation, synchronized release schedules, contacts, implementation split, etc.  For TPTP to benefit from this arrangement, we would need to modularize the code in the Harmony project and then request Eclipse legal approval for that module.
 
* '''Q:''' What is the arrangement/agreement with the Apache Harmony project?  For example, coordinated design/implementation, synchronized release schedules, contacts, implementation split, etc.  For TPTP to benefit from this arrangement, we would need to modularize the code in the Harmony project and then request Eclipse legal approval for that module.
* '''A:''' The Apache Harmony project  
+
* '''A:''' The Apache Harmony project will complete the implementation of the verifier as make it available as part of the Harmony download.  TPTP will pick builds of the verifier for integration into CVS/builds.
  
 
* '''Q:''' Have you contact the Eclipse JDT Team about using their solution.  This code would be relatively easy to access and under the same license.
 
* '''Q:''' Have you contact the Eclipse JDT Team about using their solution.  This code would be relatively easy to access and under the same license.

Latest revision as of 04:15, 6 February 2008

Date

  • February 5, 2008

Attendees

  • Present:
  • Paul Slauenwhite
  • Joel Cayne
  • Asaf Yaffe
  • Alexander Alexeev
  • Chris Elford
  • Mikhail Loenko
  • Vasily Levchenko
  • Joe Toomey

Topic

Minutes

  • Overview:
    • Java 6 introduced a class file format (e.g. 50.0) and a new attribute (StackMapTable) for verifying the possible values (including type information) of the operand-stack and the local variable table at the beginning of each basic-block/instruction.
    • Generated during compilation and used during class load to verify the type-safety of the code.
    • The TPTP BCI engine changes the byte code of a class so its needs to recalculate this attribute based on the new control/data flow after the BCI.
    • The current implementation of Java 6 is backward compatible since it uses the old verification scheme (does not require the attribute) when the attribute is missing/invalid.
    • However, this backward compatibility is not guaranteed post-Java 1.6.
    • Apache Harmony has a implemented a verifier that TPTP can uses to recalculate the attribute after the BCI.
  • Requirements:
    • Regenerate the attribute correctly.
    • Maintain backward compatibility (disabling regeneration) for instrumented older class file formats (e.g. <50).
  • Design:
    • Diagram:
      Participating Modules, Interfaces and dependencies
    • Check-in the static binary library (verifier.lib or 'verifier') provided by the Apache Harmony project to CVS (as part of the BCI component) and use it in the TPTP build process.
    • Since the library is static, there is no need to ship with the product.
    • The verifier and BCI classes need to communicate through a set of abstract interfaces, defined in the Apache Harmony project.
    • TPTP will implement these abstract interfaces in the BCI engine.
    • When the verifier runs, it requires method and class information.
    • The TPTP BCI engine at run-time has access to ~85% of this necessary information from the class file.
    • Problem: The TPTP BCI engine at run-time does not accesses to ~15% of this necessary information since it instruments one class file at a time and this information can only be resolved by walking the inheritance chain, for example, is class A is a superclass of class B, is class B is a super class of class C, and etc..
    • Solution: The TPTP BCI engine would use JNI/JVMTI to load the class hierarchy and resolve the ~15% of this necessary information.
    • This is not an issue for the ProbeKit Agent and JVMTI since they run in a JVM.
    • However, the ProbeInstrumenter.exe does not require a JVM so this solution would require it to create a JVM instance.
    • The ProbeInstrumenter.exe is important to IBM for static instrumentation and deployment to web application servers or customers for problem determination.
    • In addition, the ProbeInstrumenter.exe would require access to all dependencies of the classes being instrumented.
    • One possible solution would be to make ProbeInstrumenter.exe a Java application.
    • One concern mentioned is compatibility between vendors and versions of JDKs/JREs (e.g. compiling against Sun VM and running against an IBM (or JRockit) VM?
    • Not a concern since only class and method signatures are used.
    • Another concern is the situation where JNI/JVMTI is needed but not available, for example instrumenting using dynamic Probekit classes loaded before the JVM fully initializes the JNI/JVMTI interfaces.
    • There is a list of Sun, IBM, and JRockit classes (1.5) that applies (IBM loads the most classes before initializing JNI).
    • Need to determine how to handle this situation, for example, documentation or maintaining the hierarchy of classes.
    • The remainder of this work can be completed in I6.

Questions/Answers

  • Q: What is the arrangement/agreement with the Apache Harmony project? For example, coordinated design/implementation, synchronized release schedules, contacts, implementation split, etc. For TPTP to benefit from this arrangement, we would need to modularize the code in the Harmony project and then request Eclipse legal approval for that module.
  • A: The Apache Harmony project will complete the implementation of the verifier as make it available as part of the Harmony download. TPTP will pick builds of the verifier for integration into CVS/builds.
  • Q: Have you contact the Eclipse JDT Team about using their solution. This code would be relatively easy to access and under the same license.
  • A: Asaf spent some time looking at the JDT source code. It seems that the StackMapTable computation implementation is built into the compilation process and cannot be easily decoupled (for example, the process heavily depends on many data structures and types used by the Java compiler). Things are different in Harmony, where the verification process is quite modular and depends only on abstract interfaces which can be easily implemented on top of the Probekit BCI engine.
  • Q: TPTP should redistribute the binaries for the Harmony module to keep the component separate and reduce built and support costs.
  • A: The Apache Harmony Verification code will be consumed by TPTP as a binary static library which will be linked with the Probekit BCI engine code.
  • Q: Does Apache Harmony support the same platforms as TPTP?
  • A: Apache Harmony currently supports 32/64 bit Windows and Linux. In this sense, it supports the same platforms currently supported by the TPTP JVMTI-based collectors (including the new JVMTI-based Probekit).

Action Items

Back to the top