Support OpenJDK/OracleJDK Compiler Directive File Format and Options

[sirinath]

Please support OpenJDK/OracleJDK Compiler Directive file format and options.

[pshipton]

This seems unlikely to ever happen. @mpirvu @fjeremic for comment.

[fjeremic]

The OpenJ9 compiler directives are not publicly exposed, i.e. in that you won't find them on our documentation website, and for good reason. The JIT should be rather transparent to the end user, and oftentimes adding JIT control options will have negative effects in terms of performance. For example in your link controlling inlining of specific methods can quickly blow up the icache/code cache. Controlling optimization levels can tank startup performance and compile time CPU consumption.

Unless there is a very specific use case for these directives I do not think we will invest into supporting this particular format.

[sirinath]

There a quite a few projects in high-performance java and finance with use this functionality extensively.

Controlling optimization levels can tank startup performance and compile time CPU consumption.

The objective is to cut down the warm-up time of JVM before going live.

[sirinath]

Ideally, this data file can be generated in 2 ways using profile guided optimisation:

• by profiling library
• by the JVM running under a flag
• or mix of both

[fjeremic]

The data file in particular is not something we have at the moment, but the functionality can be replicated via command line options. For example:

To control inlining of method A into method B:

-Xjit:{A}(tryToInline={B})

To control the optimization level for all methods in java/lang package to cold:

-Xjit:{java/lang*}(optLevel=cold)

[sirinath]

Great! Hence can the same file format be supported so it can be shared between JVM implementation?

[fjeremic]

Great! Hence can the same file format be supported so it can be shared between JVM implementation?

@dsouzai @mpirvu thoughts? Could be an intern type item.

[mpirvu]

Even if we provide the same file 'format' the content will be different due to the different JVM technology. For instance in the link provided I see references to C1 and C2 compilers. These translate very roughly to our cold and warm optimization levels, but are not the same. What I am trying to say is that porting such a file from a HotSpot to OpenJ9 and expecting similar results is not realistic.
I second @fjeremic opinion that controlling the JIT compiler can lead to unexpected results, unless you know exactly how these directives interact with each other. As an example, I have seen quite a few times people trying to warmup their JVM by compiling every method at 'scorching' from the very first invocation with -Xjit:optLevel=scorching,count=0 and being shocked by the poor performance. What they don't know is that 'optLevel=...' disables speculative optimizations based on the class hierarchy table (and other opts as well) and that 'count=0' hinders inliner a great deal because of many unresolved references and lack of interpreter profiling information.
@sirinath While in the future we may start working on supporting the same file format for JIT directives (provided we get an intern), maybe it's better to understand what you are trying to achieve so that we can suggest appropriate OpenJ9 options.
For instance, for trading applications I am going to guess that determinism is the most important thing and JIT compilation could interfere with that. In that case, perhaps using the -Xshareclasses technology together with -Xtune:virtualized achieves that goal.

[sirinath]

Maybe the starting point would b to try to create a studentized portable version of the format working with the OpenJDK team. Perhaps this format should take account of the fact there are differences in the VMs there are options to loosely specify parameters in a VM independent way.

What they don't know is that 'optLevel=...' disables speculative optimizations based on the class hierarchy table (and other opts as well) ...

Any command line should ideally not disable any optimisation unless it is an explicit switch parameter to turn it on or off.

... and that 'count=0' hinders inliner a great deal because of many unresolved references and lack of interpreter profiling information.

While profiling information is collected it can be optimised. Also, there can be an option to save profiling information and internal metadata to be used in the next invocation of the application.

Ideally, the use of any option should not handicap the VM unless it is an explicit turn off or on.

[0xdaryl]

This feature seems interesting for precision testing of compiler features and in problem diagnostic scenarios, but not something to be used in production. We take great care in choosing public options such that their behaviour is clearly defined and documented and so that they are included in testing modes for nightly and release builds across all platforms and operating systems to validate their expected behaviour.

Allowing internal compiler options to be used in production scenarios not only may enable features that are incompatible or detrimental to one another, but it gives OpenJ9 less freedom to deprecate or alter such options if there are production dependencies on them. Hence, if such a compiler directives feature were to be supported with OpenJ9 I doubt we would allow its use in a production setting.

OpenJ9 provides a number of features to significantly improve startup and warmup performance of an application (e.g., shared classes with AOT as @mpirvu mentions above). If there are situations where, for example, shared classes is not providing the performance you'd expect it should we are certainly interested in hearing about them so that we can suggest a suitable configuration or fix a problem in the code base if it comes to that.