Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] Add documentation for tr.jit options #70

Closed
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
46 changes: 46 additions & 0 deletions doc/jit.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,46 @@
# Testarossa JIT (tr.jit) compiler

Testarossa JIT compiler is a highly performant dynamic compiler that powers OpenJ9 - an enterprise-grade Java Virtual Machine (JVM). It's characteristic features are to compress the application code for improved runtime performance by exploiting the exact host CPU model and apply profiling on the runtime behavior of the generated code, feed it back to the optimizer to further refine it. The compiler provides a wide range of command line options to (i) trace the actions of the compilation and the compiled code, and (ii) control the compiler behavior.

While care is taken at the design itself to derive optimal performance under default configurations for the most common workloads, these command line options help to derive insight into the efficiency of the compiler for a given workload, and fine tune the compilation behavior for maximizing the runtime performance / throughput.


This page contains the full list of compiler options that are classified into: (i) optimization control knob options (which generally takes the form of enable | disable syntax), (ii) trace options (which generally take the form of traceXXX syntax), and (iii) debug options (which generally helps to manually control the execution on a specific compilation / compiled code event) and (iv) Environment variables that influences the behavior of JVMs that are spawned within that environment.
Copy link
Contributor

@mgaudet mgaudet Sep 19, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tend to agree with Andrew, that detail should probably not live in this document; doubly so since a good chunk of this would end up reproducing the Testarossa Problem Determination Guide from OMR

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 to creating a problem determination guide or linking to the IBM J9 documentation given that there's existing documentation for many of the components there.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To clarify, the PD is not the main intent of this document. Excerpt from #33:

  • Users to gain insight into the (so far) under-documented tr jit features, take advantage of it by applying fine grained compiler customizations based on the specific environment and workload.
  • Community members to better acquiant with the optimizations, hack around with the code with ease, get upto speed for large scale collaboration.

However, I have now linked the section with the PD guide from Eclipse OMR page.


If you are looking for troubleshooting a specific problem at hand that has a perceived scope within the JIT compiler or the compiled code, refer to the [Compiler Problem Determination guide] under Eclipse OMR project.

For most part of the documentation, this below code will be used.

```java
public class Foo {
public static void main(String args[]) {
new Foo().run(Integer.parseInt(args[0]));
}
public void run(int count) {
for(int i=0; i<count; i++)
System.out.println("hello jit world!");
}
}
```

## Control options

### Disable JIT
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I almost think it would be best to document -Xtrace first :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks - sure, I will try to place a one liner for Xtrace. I will keep it minimal as:

  • -Xtrace usage in this document will be limited,
  • the limited usage of it here will be mostly intuitive to the readers.

Usage: -Xint
Side effect: Performance will be impacted severely, so use only for problem determination, not recommended in production.

Example usage:
Run with method trace ON to see that the method gets compiled
```trace
bash$ java -Xtrace:print=mt,methods={Foo.run*} Foo 300000 > /dev/null
10:36:02.432*0x2118200 mt.0 > Foo.run(I)V bytecode method, this = 0xfff90558
10:36:03.109 0x2118200 mt.7 < Foo.run(I)V compiled method
```

With -Xint in place, see that the method is always interpreted. Please note that a single method is used for demonstration purpose only, this flag disables the JIT compiler globally for all the methods.
```trace
bash$ java -Xtrace:print=mt,methods={Foo.run*} -Xint Foo 300000 > /dev/null
10:36:18.404*0x145a200 mt.0 > Foo.run(I)V bytecode method, this = 0xfff81bd0
10:36:32.084 0x145a200 mt.6 < Foo.run(I)V bytecode method
```
[Compiler Problem Determination guide]: https://github.com/eclipse/omr/blob/master/doc/compiler/ProblemDetermination.md