Initialization of libgraal includes copying the jdk.internal.misc.VM.savedProps from the Java heap into the libgraal Native Image heap. Currently this is done with an upcall to jdk.internal.vm.VMSupport.serializeSavedPropertiesToByteArray which is somewhat inefficient for the following reasons:
1. It happens early in the VM lifecycle so most of the Java code executed by the upcall will be running in the interpreter.
2. serializeSavedPropertiesToByteArray uses java.util.Properties.store() which does more than is necessary for copying the system properties.
3. The Java heap byte array returned by serializeSavedPropertiesToByteArray is copied into a C heap byte array which is then copied into a libgraal heap byte array.
4. The libgraal byte arrays is deserialized via Properties.load into a Map.
A better solution would be to directly read Arguments::system_properties() via Unsafe to create the final Map. This has fewer properties than VM.savedProps but this is acceptable as JVMCI and Graal are primarily interested in command-line set properties in terms of configuration. The few other properties such as os.name, os.arch and java.specification.version can be manually added after reading Arguments::system_properties().
1. It happens early in the VM lifecycle so most of the Java code executed by the upcall will be running in the interpreter.
2. serializeSavedPropertiesToByteArray uses java.util.Properties.store() which does more than is necessary for copying the system properties.
3. The Java heap byte array returned by serializeSavedPropertiesToByteArray is copied into a C heap byte array which is then copied into a libgraal heap byte array.
4. The libgraal byte arrays is deserialized via Properties.load into a Map.
A better solution would be to directly read Arguments::system_properties() via Unsafe to create the final Map. This has fewer properties than VM.savedProps but this is acceptable as JVMCI and Graal are primarily interested in command-line set properties in terms of configuration. The few other properties such as os.name, os.arch and java.specification.version can be manually added after reading Arguments::system_properties().
- duplicates
-
JDK-8309277 [JVMCI] do not use system properties for querying OS name and arch
-
- Closed
-
- relates to
-
JDK-8342295 compiler/jvmci/TestJVMCISavedProperties.java fails due to garbage in output
-
- Resolved
-