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

TPTP-AG-20080205

Revision as of 13:22, 5 February 2008 by Paulslau.ca.ibm.com (Talk | contribs)

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. 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.
    • 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:
    • 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.
    • The TPTP BCI engine has access to ~85% of the necessary information at run-time for the implementation of these abstract interfaces.

Participating Modules, Interfaces and dependencies

    • 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.

Question: What is the importance ProbeInstrumentor.exe to IBM? Web application environment and problem determination with customer support.

Make ProbeInstrumentor.exe a Java application.

What happens when compiling against Sun VM and running against an IBM VM (or JRocket)?

Only uses class and method signatures.

Will need the classes/JARs for all of the dependencies.

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.5. IBM loads the most classes before initializing JNI.

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
  • 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