Asaf, Mikhail, and Alex A. will host a technical and legal discussion on enhancement Support Java 6 Class File Format Changes (148629), focusing on the Apache Harmony verifier and related IBM JVM issues.
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:
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).
