[0.9] Release focus areas

[DanHeidinga]

The Eclipse Project Handbook suggests that as the project nears the completion of the v0.8.0 release, we should be planning the major focus areas for the next release:

The plan should lay out in broad terms what the goals are for the release. As plans are a valuable means for the community to get involved with your project, the plan should be created at the beginning of the release cycle. By establishing the plan early, you give prospective contributors help in determining how they can most usefully contribute, and adopters can prepare their own development schedule and themes. Plans can change during the release cycle.

https://www.eclipse.org/projects/handbook/#release

This is an opportunity to highlight the areas that will be progressing over the next ~3 months given the intended quarterly release cycle.

Committers, please add a brief description of the areas you and/or your teams expect to be focusing on to https://github.com/eclipse/openj9/issues/1381  Please take the opportunity to highlight to the community what you're doing now, what you plan to be doing for the next release, and why this items are important for the future of OpenJ9.

[fjeremic]

@DanHeidinga we should provide a template for future release focus areas with the kind of information that should be filled out to give some sort of structure. I'll go first.

Focus areas of the Z JIT code generator team

The Z JIT codegen team will predominantly be focused on performance in the next several months. In particular we are measuring that there is significant overhead that can be trimmed in JNI paths on our platform. In addition we expect more compile time improvements to be delivered.

JNI performance

We will be working to address JNI overhead on the platform. Specifically the use of TR_Helper linkage for for some of the calls out to the VM that have to be made in the JNI call out sequence can be changed to C-helper calls. In the non-C-helper calls we are currently preserving every single register off to the stack which is a huge overhead. There are only a handful of live registers from the JIT JNI thunk which may need to be preserved. We expect significant improvements to the call overhead in this area.

Things are particularly bad on the z/OS front because there are double the number of helper calls compared to Linux on Z. We will be working on addressing both platforms to a more respectable state.

JProfiling enablement

With the introduction of the TR::xbitpermute IL we have the ability to use the z14 VBPERM instruction to accelerate this IL and speed up our hashing function used as part of the JProfiling infrastructure. This work is currently ongoing.

On the performance side we are working towards enabling JProfiling for profiled compilations in hopes of deprecating the method profiling split that currently happens with JitProfiling. We've identified this to be a major contributor to high compile time overhead which will be reduced once we've made this switch. We are currently in the midst of performance investigations and addressing the various degradation that occur when this option is enabled.

Thus far we've identified some problems with recompilations not being triggered properly due to loops in methods. We are addressing this currently. Although this is not Z codegen specific work much of the initial performance evaluation is being done on Z.

String compression

Currently String compression is disabled by default in Java 9 onward. We are working towards getting this feature enabled. While we are functionally there we do have some performance concerns at the moment. Many of these reside with our interaction with the OpenJDK JCL classes which have implemented String compression in a much different way.

Currently we are at a disadvantage due to the coder field being present in Java 10 which effectively increases the size of OpenJ9 String objects to 24 bytes (header + value + count + hashCode + coder == 20 but on 64-bit we align to 8-byte boundary so 24 bytes). We are currently prototyping a change to remove one of the fields to get back to a 16-byte String object.

While working on this change we've identified several performance opportunities in the existing implementations which will both improve throughput and reduce footprint further. Our goal is to get to a more respectable throughput and footprint state before we can think about enabling this feature by default.

Compile time performance

It has been identified that several Z specific paths are responsible for quite a lot of compile time. Specifically code dealing with sign extension optimizations and handling of HPRs is currently sub-par. We will be working on improvements in this area to further shed compile time off our warm compiles.

Some of this work will be blocked by tooling not being available. Ubuntu 18.04 is slated to be released on April 26th, 2018. This version comes with kernel 4.15 which has a ton of fixes for perf call graph support for getting backtraces of JIT compilation threads for compile time performance investigations. It is likely much of the compile time performance work will be happening after we get the new kernel installed.

[pshipton]

On today's community hangout @mstoodle proposed calling the next release 0.9.0 (and the following 0.10.0) since using 0.8.1 would indicate a patch release, but the number of features going in (new platforms such as Windows and AIX, DDR, support for OpenJDK 10) don't correspond to a patch release. Given no objections in the call, I'm making the changes to call the next release 0.9.0

[SueChaplain]

Issue #1759 raised for the 0.9.0 release notes, where we will capture the new platforms/support/fixed issues and new issues. Please add comments there.

[fjeremic]

Hi everyone,

I have some updates on our progress to our focus areas posted previously in #1381 (comment):

JNI performance

@gacholio has been independenctly making advances in this area through a mirage of PRs with a new Atomic-free JNI implementation (#1762, #1687, #1680, #1651, #1605, #1567, #1559, #1535). On the Z side of things @NigelYiboYu has been making strides into eliminating helper call dependencies. We are just about ready to open up a PR to start reviewing these changes. I do not envision this will be ready for the 0.9 release.

JProfiling enablement

Support for TR::xbitpermute IL on Z has been delivered in eclipse-omr/omr#2330. There has been improvements delivered in the area of JProfiling in #1442, #1246, and there is ongoing work happening in #1601.

String compression

This change is being finalized and I expect a PR to be up in the next day or two pending some further testing. I will update this comment to reference the PR once it is available. The work has been happening in my personal branch https://github.com/fjeremic/openj9/tree/remove-string-count-good. We are very close completion here and I do expect this to land in the 0.9 release.

Compile time performance

Tomorrow is the release of Ubuntu 18.04. We'll be upgrading some of our development machines to this version to pick up the 4.14 kernel level with the fixes to perf. Once this is done the work here can start. I don't expect much progress in this ahrea for this release but we will try our best!

[pshipton]

Closing since content for 0.9.0 is finalized.