-
Notifications
You must be signed in to change notification settings - Fork 5.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8309390: [JVMCI] improve copying system properties into libgraal #14291
Conversation
👋 Welcome back dnsimon! A progress list of the required criteria for merging this PR into |
cf1be09
to
d636421
Compare
@@ -59,7 +59,7 @@ public static boolean isBadIoTmpdir() { | |||
* Note: Build-defined properties such as versions and vendor information | |||
* are initialized by VersionProps.java-template. | |||
* | |||
* @return a Properties instance initialized with all of the properties |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I took the liberty of correcting this javadoc to reflect the code.
Webrevs
|
I don't really love the hard code parsing of the HashMap. What properties are actually required for JVMCI? It seems to me that the contents of Arguments::system_properties() should contain all the properties we want to advertise to JVMCI. That would have avoid having to decode them after they've been converted into Java objects. |
I tired this but unfortunately, Graal relies on some properties that are only initialized in Java:
That code is reading the "java.specification.version" property which is initialized in |
HotSpot sets |
@dougxc Please do not rebase or force-push to an active PR as it invalidates existing review comments. Note for future reference, the bots always squash all changes into a single commit automatically as part of the integration. See OpenJDK Developers’ Guide for more information. |
Ok, I've pushed a change with your suggestion Tom and it seems to work. It assumes |
@@ -57,7 +57,7 @@ | |||
jvmci_method, \ | |||
jvmci_constructor) \ | |||
start_class(Services, jdk_vm_ci_services_Services) \ | |||
jvmci_method(CallStaticVoidMethod, GetStaticMethodID, call_static, void, Services, initializeSavedProperties, byte_array_void_signature, (JVMCIObject serializedProperties)) \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The final arg for the jvmci_method
macro is never used so I removed it everywhere.
@dougxc Please do not rebase or force-push to an active PR as it invalidates existing review comments. Note for future reference, the bots always squash all changes into a single commit automatically as part of the integration. See OpenJDK Developers’ Guide for more information. |
for (long prop = systemProperties; prop != 0; prop = unsafe.getLong(prop + nextOffset)) { | ||
String key = toJavaString(unsafe, unsafe.getLong(prop + keyOffset)); | ||
long valueAddress = unsafe.getLong(prop + valueOffset); | ||
if (valueAddress != 0) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the lazy value construction really necessary? It seems like it requires quite a bit of extra machinery.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In big apps, I image there can be quite some large system property values (e.g. java.class.path
) so we don't want to pay memory overhead per libgraal isolate for such properties as they're ignored by libgraal.
I realized I can reduce the extra machinery based on the fact that SystemProperties
is unmodifiable: 6c346d3
The only method that still eager converts the string is SystemProperties.values()
but that's fine as it's not used by JVMCI or Graal.
I think the trade off is now acceptable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes I like this trade off a bit better.
@dougxc This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been no new commits pushed to the ➡️ To integrate this PR with the above commit message to the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
VM changes seems fine. They are JVMCI specific.
Thanks for the reviews! /integrate |
Going to push as commit c0aa6bf.
Your commit was automatically rebased without conflicts. |
This PR reduces the amount of code executed during libgraal initialization. This not only improves VM startup overall but all fixes a number of JDK test failures that are caused by Java code executing "too early". For example,
java/util/Locale/CompatWarning.java
can fail ifsun.util.locale.provider.LocaleProviderAdapter
is initialized before theCheckWarning
handler is registered.Instead of serializing
VM.savedProps
viaVMSupport.serializeSavedPropertiesToByteArray
, thejdk.vm.ci.services.Services
class now directly readsArguments::system_properties()
usingUnsafe
. Furthermore, the value of a system property is lazily converted to aString
from a C string pointer.Times
The basic benchmarking below shows that this change brings the time for a nop Java app with eager libgraal initialization (2) down to almost the same time as lazy libgraal initialization (1). The latter typically means no libgraal initialization happens as a top tier JIT compilation is never scheduled in such a short running app.
(1) Baseline (no options):
(2) Eagerly initialize libgraal (with PR):
(3) Eagerly initialize libgraal (without PR):
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/14291/head:pull/14291
$ git checkout pull/14291
Update a local copy of the PR:
$ git checkout pull/14291
$ git pull https://git.openjdk.org/jdk.git pull/14291/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 14291
View PR using the GUI difftool:
$ git pr show -t 14291
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/14291.diff
Webrev
Link to Webrev Comment