JDK-8358580 : Rethink how classes are kept alive in training data
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 26
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2025-06-04
  • Updated: 2025-07-22
  • Resolved: 2025-07-11
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 26
26 b07Fixed
Related Reports
Relates :  
JDK-8358003 - KlassTrainingData initializer reads garbage holder
Relates :  
JDK-8231269 - CompileTask::is_unloaded is slow due to JNIHandles type checks
Description
There's been a suggestion from [~coleenp] to use OopStorage directly instead of global handles to keep the classes alive.

I'm attaching one of the prossible implementations that I did.
Comments
Changeset: 59bec29c Branch: master Author: Igor Veresov <iveresov@openjdk.org> Date: 2025-07-11 18:07:13 +0000 URL: https://git.openjdk.org/jdk/commit/59bec29c35361b7b256a2d435ced3458b0c5ea58
11-07-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/26233 Date: 2025-07-10 02:37:05 +0000
10-07-2025
Alternatively, we use the new utility class from JDK-8231269 that serves the same need. It would be even better that way, because that utility class does not hold on to klass mirrors for classes we know are not going away. Plus, it is supposed to care of life of handle lifecycle better. All of this can be done after JDK 25.
04-06-2025