-
Notifications
You must be signed in to change notification settings - Fork 101
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
8271959: [lworld] Convert Optional and VBS classes to value class #816
Conversation
Make copies of classes to be made value classes in src/java.base/valhalla/classes Modify Main.gmk to trigger Valhalla builds of classes Modify Modules.gmk to conditionally override java.base classes with Valhalla/classes Modify hotspot arguments.cpp to force --patch-module with overriddden classes if --enable-preview
👋 Welcome back rriggs! A progress list of the required criteria for merging this PR into |
Are these changes part of JEP 402? Will java.lang.Integer etc. replaced in a similar way? |
I think that's unlikely, at least as sketched here. The wrapper types are used before the module system is initialized. |
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.
There are two major ways you could approach this.
- Define new top level targets for compiling the value classes and the subsequent jar files.
- Modify make/CompileJavaModules.gmk to add a second optional compilation and jar file generation which would be part of the top level -java target.
You went with option 1. Both have pros and cons, so it kind of depends on what you expect to need to do, as a developer. Do you think you need the fine granular top level target support for selective building?
Another aspect is that if you reuse the CompileJavaModules.gmk and run it again with a different outputdir, I think you will be rebuilding quite a lot of things unnecessarily. My understanding is that you only really need the value classes from the this second round of compilation.
Override classes reside in <module>/valueclasses/classes They are compiled separately after the regular module build. Only the class files compiled from <module>/valueclasses/.. are inserted into a jar file The jar file is placed in lib/valueclasses/<module>-valueclasses.jar The jar is included in the module's jmod The Hotspot arguments.cpp is hard coded to patch the java.base module when the --enable-preview option is selected.
for per module jar files with names like <module>-valueclasses.jar.. For each jar add the equivalent of --patch-module <module>=<jar>.
value classes when --enable-preview
…re classes edited to remove super() and change "class" to "value class". See Modules.gmk for the list of classes. Add test for 16 classes in java.util and java.time to check they are value classes when --enable-preview and otherwise identity classes.
and --enable-preview together. Only a single --patch-module for a given module is legal. The --patch-module options are accumulated in a list, rejecting duplicates. If the --enable-preview is present, jar files for each module with value classes are appended to the path for the respective module. Finally, a property is defined for each module that communicates the module and path to ModuleBootstrap.
Remove "super()" from java.time classes (not needed and also not allowed for value classes)
Cleanup memory allocation in arguments to use the heap (not stack) Add test for duplication of --patch-module other than java.base
@RogerRiggs 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 4 new commits pushed to the
Please see this link for an up-to-date comparison between the source branch of this pull request and the ➡️ To integrate this PR with the above commit message to the |
The initial set of value classes (listed in
|
Webrevs
|
/labels core-libs, build, hotspot |
@RogerRiggs Unknown command |
@RogerRiggs |
@RogerRiggs Available commands:
|
@RogerRiggs Usage: |
… the launcher instead of ExceptionInInitilizer.
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.
Mostly seems reasonable - though I'm not that familiar with the existing module patching logic. One issue with tracking patch_mod_javabase
.
…-modules. Other review comment cleanup.
@erikj79 When you have time can you look at the build changes. Thanks |
A side note: the change to remove the call to |
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.
Except for some minor cosmetics, the build changes are looking really good.
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.
Sorry for the delay (I don't get email notifications for this PR).
The hotspot changes are looking good.
One minor nit.
if (strcmp(module_name, JAVA_BASE_NAME) == 0) { | ||
vm_exit_during_initialization("Cannot specify " JAVA_BASE_NAME " more than once to --patch-module"); | ||
} else { | ||
vm_exit_during_initialization("Cannot specify a module more than once to --patch-module", module_name); | ||
} |
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.
This just reduces to:
else {
vm_exit_during_initialization(err_msg("Cannot specify %s more than once to --patch-module", module_name));
}
or even:
vm_exit_during_initialization("Cannot specify a module more than once to --patch-module", module_name);
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.
Right, for some reason there are several tests that expect different error messages due to the prior implementation split between hotspot argument parsing and ModuleBootstrap.
I couldn't see clearly far enough in the EA/Preview/release cycle to be sure of the final disposition and so punted on correcting everything everywhere.
Eventually, the provision to replace some classes with value classes unnecessary. The classes will become permanent.
But that can only happen after the feature is no-longer preview and is fully integrated.
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.
LGTM
/integrate |
Going to push as commit 4f71167.
Your commit was automatically rebased without conflicts. |
@RogerRiggs Pushed as commit 4f71167. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
Make copies of classes to be made value classes in src/java.base/valueclasses/classes
Modify CompileJavaModules.gmk to trigger builds of values classes and construct a .jar for each module.
Add the jar files to $JAVA_HOME/lib/valueclasses/<module>-valueclasses.jar
Modify hotspot arguments.cpp to scan for patch jar files when --enable-preview and -XX:+EnableValhalla.
For each jar, the equivalent of --patch-module = is added and the system properties
jdk.module.patch.<n>
include jar file paths.Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/valhalla pull/816/head:pull/816
$ git checkout pull/816
Update a local copy of the PR:
$ git checkout pull/816
$ git pull https://git.openjdk.org/valhalla pull/816/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 816
View PR using the GUI difftool:
$ git pr show -t 816
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/valhalla/pull/816.diff