JDK-8221477 : Inject os/cpu-specific constants into Unsafe from JVM
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 13
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-03-26
  • Updated: 2021-01-25
  • Resolved: 2019-04-05
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 13
13 b16Fixed
Related Reports
Relates :  
JDK-8223660 - jtreg: Decouple Unsafe from RTM tests
Relates :  
JDK-8207851 - JEP 352: Non-Volatile Mapped Byte Buffers
Description
Initialize Unsafe os/cpu-specific constants using injection instead of native callouts
Comments
Fix Request (11u): Backporting this patch makes it easier to port changes in touched files (like thread.cpp and unsafe). Original change preceded JEP 352 but it is valuable in itself as it unifies fields initialization in Unsafe. Testing: tier1, tier2. Original patch mostly applies cleanly except 3 deletions which have different context. 11u RFR: https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-January/004698.html
20-01-2021
The current class loading order shows: [0.061s][info][class,load] java.lang.Object source: shared objects file ... [0.067s][info ][class,load] java.lang.Thread source: shared objects file [0.067s][info ][class,load] java.lang.Thread$UncaughtExceptionHandler source: shared objects file [0.067s][info ][class,load] java.lang.ThreadGroup source: shared objects file .. [0.069s][info ][class,load] java.lang.Appendable source: shared objects file [0.069s][info ][class,load] java.lang.AbstractStringBuilder source: shared objects file [0.070s][info ][class,load] java.lang.StringBuffer source: shared objects file [0.070s][info ][class,load] java.lang.StringBuilder source: shared objects file [0.077s][info ][class,load] jdk.internal.misc.Unsafe source: shared objects file So I don't see any reason why the new UnsafeConstants class can't just be placed at the end of BASIC_JAVA_CLASSES_DO_PART2. Then in systemDictionary.hpp just position it immediately before Unsafe: 180 do_klass(internal_Unsafe_klass, jdk_internal_misc_Unsafe The current class initialization sequence shows: [0.085s][info][class,init] 0 Initializing 'java/lang/Object' (0x0000000800006430) ... [0.085s][info][class,init] 8 Initializing 'java/lang/Class' (0x00000008003ba0e8) [0.086s][info][class,init] 9 Initializing 'java/lang/ThreadGroup'(no method) (0x00000008003b3cc8) [0.086s][info][class,init] 10 Initializing 'java/lang/Thread' (0x0000000800142518) ... [0.086s][info][class,init] 13 Initializing 'java/lang/Module' (0x000000080040ce78) ... [0.089s][info][class,init] 44 Initializing 'jdk/internal/misc/Unsafe' (0x00000008003d1100) ... [0.091s][info][class,init] 56 Initializing 'java/lang/reflect/Method'(no method) (0x0000000800407248) If we look at the VM initialization sequence we have: 3613 initialize_class(vmSymbols::java_lang_ThreadGroup(), CHECK); 3614 Handle thread_group = create_initial_thread_group(CHECK); 3615 Universe::set_main_thread_group(thread_group()); 3616 initialize_class(vmSymbols::java_lang_Thread(), CHECK); ... 3625 initialize_class(vmSymbols::java_lang_Module(), CHECK); ... 3628 initialize_class(vmSymbols::java_lang_reflect_Method(), CHECK); So Unsafe is being initialized indirectly as part of the initialization of j.l.r.Method; after the initialization of Module, so I suggest that initializing UnsafeConstants should be placed after line 3625.
01-04-2019
There are several static final hw/os-specific constants employed in class Unsafe that are initialized by calling native methods during class initialization. It would be better to initialize these fields by injecting values during JVM startup as is done with the String field COMPACT_STRINGS. This is also an enabling change for the JEP proposed in JDK-8207851 which requires the size of a cache line to be made available to class Unsafe.
26-03-2019