New CML options to store classes from all class loaders into shared cache

[hangshao0]

Issue or pull request number: issue: https://github.com/eclipse-openj9/openj9/issues/19323 PR: https://github.com/eclipse-openj9/openj9/pull/19442

Overview: New -XX command line options to control classes sharing from all class loaders.

Release target: Eclipse OpenJ9 0.46.0

Applies to the following JDK versions: All versions

Applies to the following platforms: All platforms

For new command line options:

• Option name and syntax: -XX:+ShareOrphans Enable class sharing from all class loaders. This option automatically turns on -Xshareclasses.

  1. For classes from class loaders which are aware of the OpenJ9 shared class API, they are shared as normal rom classes, which is the same behaviour as turning on -Xshareclasses.
  2. For classes from class loaders which are unaware of the OpenJ9 shared class API, the JVM won't have their class/module path information. They are shared as orphan rom classes. They can be shared with other JVMs after extra comparisons.

  -XX:-ShareOrphans Disable sharing class as orphans from class loader which is unaware of the OpenJ9 shared class API. This is the default mode.

• Purpose: Improve startup performance and lower memory footprint by sharing more classes.
• Restrictions:
  1. Sharing classes as orphans requires more comparison on the classes by the JVM. The comparison itself have negative performance impact. However, it can be offset by the benefits of more AOT generated for the cached class.
  2. More cached classes will result in more methods being AOT compiled. The relative advantage of orphan sharing decreases when there are fewer CPUs. With more CPUs, the compilation threads can compile those additional methods in parallel with the application threads, while with fewer CPUs, extra compilation activity will hinder application threads.
  3. There is a known problem with the class comparison that it may not detect removal of method access modifiers. (e.g. change of a method from public to package-private).
  4. There is a know problem that java.lang.StackTraceElement.getClassLoaderName() could return null for classes stored in the shared cache. (Known problems iii and iv are fixed in 0.47)

[Sreekala-Gopakumar]

@hangshao0 - What was the problem because of which this new option had to be added?

[pshipton]

It's not a fix for a problem, it's a new feature which may result in better startup performance, as per https://github.com/eclipse-openj9/openj9/issues/19323 By storing additional classes in the cache, AOT can be created and used on these classes, which may result in better startup performance.

[pshipton]

There is a known problem with using the option, fixed via https://github.com/eclipse-openj9/openj9/pull/19833. We should consider holding back the documentation until 0.47 which includes the fix, or mention the problem in the release notes. @hangshao0 what is your preference?

[hangshao0]

We could mention the problem in the release notes.

[hangshao0]

Updated the Restrictions section with known problems.

[Sreekala-Gopakumar]

We could mention the problem in the release notes.

@pshipton @hangshao0 - So that means I should document this new option but mention the problem in the Release notes, isn't it?

[hangshao0]

So that means I should document this new option but mention the problem in the Release notes, isn't it?

Yes.

[Sreekala-Gopakumar]

@hangshao0 - Could you please check the following content and let me know if any changes should be made. Thanks!

-XX:[+|-]ShareOrphans

This option enables or disables sharing of orphan class from class loader that is unaware of the OpenJ9 shared class API.

Syntax

    -XX:[+|-]ShareOrphans

Setting	Effect	Default
-XX:+ShareOrphans	Enable
-XX:-ShareOrphans	Disable	:fontawesome-solid-check:{: .yes aria-hidden="true"}yes

Explanation

In the previous versions, OpenJ9 stored only bootstrap classes and hidden classes in the shared classes cache by default, that is -Xshareclasses is not specified by default. When -Xshareclasses was specified, only those class loaders that implemented the OpenJ9's public shared classes cache APIs (and its child class loaders) could store classes to the shared classes cache. Classes from custom class loaders that did not implement shared classes cache APIs has no class path information. Because the shared classes cache didn't have the class path information, these classes were not stored to the shared classes cache.

You can enable class sharing from all class loaders, irrespective of whether the class loader implements the OpenJ9's public shared classes cache API, with the -XX:+ShareOrphans option. This option automatically turns on -Xshareclasses. When the class sharing from all class loaders is enabled, the following is the sharing behavior:

• For classes from class loaders that implement the OpenJ9 shared class API, they are shared as normal rom classes, which is same as turning on -Xshareclasses.

• For classes from class loaders that do not implement the OpenJ9 shared class API, the VM won't have their class or module path information. They are shared as orphan rom classes with other VMs after extra comparisons.

Storing additional classes in the cache makes more classes available for Ahead-of-Time (AOT) compilation and therefore might improve startup performance.

You can disable sharing class as orphans from class loader that does not implement the OpenJ9 shared class API with the -XX:-ShareOrphans option. This option is the default mode.

:fontawesome-solid-triangle-exclamation:{: .warn aria-hidden="true"} Restrictions:

• Sharing classes as orphans requires more comparison on the classes by the VM. The comparison itself has a negative performance impact. However, the benefits of more AOT generated for the cached class offset the negative impact.
• More cached classes result in more AOT-compiled methods. The relative advantage of orphan sharing decreases when the CPUs are less. With more CPUs, the compilation threads can compile those additional methods in parallel with the application threads, while with fewer CPUs, extra compilation activity will hinder application threads.
• The class comparison might not detect the removal of method access modifiers. For example, a change of a method from public to package-private.
• java.lang.StackTraceElement.getClassLoaderName() might return null for classes that are stored in the shared cache.

[hangshao0]

Classes from custom class loaders that did not implement shared classes cache APIs has no class path information. Because the shared classes cache didn't have the class path information, these classes were not stored to the shared classes cache.

"Classes from custom class loaders ... has no class path information". These classes do have class path information, it is just the JVM does not know such information (The class loader does not implement the shared class cache APIs to pass such info to the JVM). It is better to say sth like "For classes from custom class loaders that did not implement shared classes cache APIs, JVM does not have their module path or class path information and they were not stored to the shared classes cache."

the benefits of more AOT generated for the cached class offset the negative impact. More cached classes result in more AOT-compiled methods.

This feature makes more classes available for AOT compilation. The final result might vary depending on the applications. So it is better to say sth like "could offset the negative impact", "usually result in more AOT-compiled methods"