Skip to content
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

8264806: Remove the experimental JIT compiler #3421

Closed
wants to merge 12 commits into from

Conversation

@vnkozlov
Copy link
Contributor

@vnkozlov vnkozlov commented Apr 9, 2021

As part of JEP 410 remove code related to Java-based JIT compiler (Graal) from JDK:

  • jdk.internal.vm.compiler — the Graal compiler
  • jdk.internal.vm.compiler.management — Graal's MBean
  • test/hotspot/jtreg/compiler/graalunit — Graal's unit tests

Remove Graal related code in makefiles.

Note, next two module-info.java files are preserved so that the JVMCI module jdk.internal.vm.ci continues to build:

src/jdk.internal.vm.compiler/share/classes/module-info.java
src/jdk.internal.vm.compiler.management/share/classes/module-info.java

@AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it.

Tested hs-tier1-4


Progress

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed

Issue

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/3421/head:pull/3421
$ git checkout pull/3421

Update a local copy of the PR:
$ git checkout pull/3421
$ git pull https://git.openjdk.java.net/jdk pull/3421/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 3421

View PR using the GUI difftool:
$ git pr show -t 3421

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/3421.diff

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Apr 9, 2021

👋 Welcome back kvn! A progress list of the required criteria for merging this PR into pr/3398 will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk openjdk bot added the rfr label Apr 9, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Apr 9, 2021

@vnkozlov The following labels will be automatically applied to this pull request:

  • build
  • compiler
  • core-libs
  • hotspot

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

@mlbridge
Copy link

@mlbridge mlbridge bot commented Apr 9, 2021

Webrevs

@@ -1,57 +0,0 @@
#

This comment has been minimized.

@erikj79

erikj79 Apr 9, 2021
Member

This file should not be removed. This outout image is this makefile produces is used as input to the separate GraalVM build.

@@ -441,11 +441,6 @@ $(eval $(call SetupTarget, exploded-image-optimize, \
buildtools-modules, \
))

$(eval $(call SetupTarget, graal-builder-image, \

This comment has been minimized.

@erikj79

erikj79 Apr 9, 2021
Member

Same as above, this needs to stay.

@@ -892,10 +890,6 @@ DOCS_OUTPUTDIR := $(DOCS_JDK_IMAGE_DIR)
STATIC_LIBS_IMAGE_SUBDIR := static-libs
STATIC_LIBS_IMAGE_DIR := $(IMAGES_OUTPUTDIR)/$(STATIC_LIBS_IMAGE_SUBDIR)

# Graal builder image

This comment has been minimized.

@erikj79

erikj79 Apr 9, 2021
Member

Like above, this needs to stay.

@vnkozlov
Copy link
Contributor Author

@vnkozlov vnkozlov commented Apr 9, 2021

Thankyou, @erikj79, for review. I restored code as you asked.
For some reasons incremental webrev shows update only in Cdiffs.

@vnkozlov
Copy link
Contributor Author

@vnkozlov vnkozlov commented Apr 9, 2021

/label remove compiler

@openjdk openjdk bot removed the compiler label Apr 9, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Apr 9, 2021

@vnkozlov
The compiler label was successfully removed.

@vnkozlov
Copy link
Contributor Author

@vnkozlov vnkozlov commented Apr 9, 2021

/label add hotspot-compiler

@openjdk
Copy link

@openjdk openjdk bot commented Apr 9, 2021

@vnkozlov
The hotspot-compiler label was successfully added.

@iignatev
Copy link
Member

@iignatev iignatev commented Apr 10, 2021

none of the full webrevs seem to render even the list of changed files? is it just me?

Copy link
Member

@iignatev iignatev left a comment

should we remove sun.hotspot.code.Compiler::isGraalEnabled method and update a few of its users accordingly?
what about vm.graal.enabled @requires property?

@vnkozlov
Copy link
Contributor Author

@vnkozlov vnkozlov commented Apr 10, 2021

should we remove sun.hotspot.code.Compiler::isGraalEnabled method and update a few of its users accordingly?
what about vm.graal.enabled @requires property?

Thank you, @iignatev for looking on changes.

I forgot to mention that Compiler::isGraalEnabled() returns always false now. Because 94 tests uses @requires !vm.graal.enabled I don't want to include them in these changes which are already very big. I am not sure if I should modify tests if GraalVM group wants to run all these tests.

Unfortunately changes in Compiler.java are listed the last on Files changed tab and GitHub has trouble to load these big changes - it takes time to see them. Here Compiler.java chnges for review:

diff --git a/test/lib/sun/hotspot/code/Compiler.java b/test/lib/sun/hotspot/code/Compiler.java
index 99122bd93b8..71288ae4482 100644
--- a/test/lib/sun/hotspot/code/Compiler.java
+++ b/test/lib/sun/hotspot/code/Compiler.java
@@ -60,33 +60,10 @@ public class Compiler {
     /**
      * Check if Graal is used as JIT compiler.
      *
-     * Graal is enabled if following conditions are true:
-     * - we are not in Interpreter mode
-     * - UseJVMCICompiler flag is true
-     * - jvmci.Compiler variable is equal to 'graal'
-     * - TieredCompilation is not used or TieredStopAtLevel is greater than 3
-     * No need to check client mode because it set UseJVMCICompiler to false.
-     *
-     * @return true if Graal is used as JIT compiler.
+     * @return false because Graal is removed from JDK.
      */
     public static boolean isGraalEnabled() {
-        Boolean useCompiler = WB.getBooleanVMFlag("UseCompiler");
-        if (useCompiler == null || !useCompiler) {
-            return false;
-        }
-        Boolean useJvmciComp = WB.getBooleanVMFlag("UseJVMCICompiler");
-        if (useJvmciComp == null || !useJvmciComp) {
-            return false;
-        }
-
-        Boolean tieredCompilation = WB.getBooleanVMFlag("TieredCompilation");
-        Long compLevel = WB.getIntxVMFlag("TieredStopAtLevel");
-        // if TieredCompilation is enabled and compilation level is <= 3 then no Graal is used
-        if (tieredCompilation != null && tieredCompilation &&
-            compLevel != null && compLevel <= 3) {
-            return false;
-        }
-        return true;
+        return false;
     }
@vnkozlov
Copy link
Contributor Author

@vnkozlov vnkozlov commented Apr 10, 2021

@iignatev If you think that I should clean tests anyway I will file follow up RFE to do that.

@iignatev
Copy link
Member

@iignatev iignatev commented Apr 10, 2021

should we remove sun.hotspot.code.Compiler::isGraalEnabled method and update a few of its users accordingly?
what about vm.graal.enabled @requires property?

Thank you, @iignatev for looking on changes.

I forgot to mention that Compiler::isGraalEnabled() returns always false now. Because 94 tests uses @requires !vm.graal.enabled I don't want to include them in these changes which are already very big. I am not sure if I should modify tests if GraalVM group wants to run all these tests.

If you think that I should clean tests anyway I will file follow up RFE to do that.

changing Compiler::isGraalEnabled() to always return false effectively makes these tests unrunnable for GraalVM group (unless they are to keep the modified sun/hotspot/code/Compiler and/or requires/VMProps in their forks). on top of that, I foresee that there will be more tests incompatible w/ Graal yet given it won't be run/tested in OpenJDK, these tests won't be marked and hence will fail when run w/ Graal. so Graal people will have to either do marking themselves (I guess in both upstream and their fork) or maintain a list of inapplicable tests in a format that works best for their setup.

that's to say, I think we should clean up the tests, yet I totally agree there is no need to do it as part of this PR. we can discuss how to do it better for both OpenJDK and GraalVM folks in the follow-up RFE.

@vnkozlov
Copy link
Contributor Author

@vnkozlov vnkozlov commented Apr 10, 2021

Thank you, Igor. I filed https://bugs.openjdk.java.net/browse/JDK-8265032

@dougxc
Copy link
Member

@dougxc dougxc commented Apr 11, 2021

We would definitely like to be able to continue testing of GraalVM with the JDK set of jtreg tests. So keeping Compiler::isGraalEnabled() working like it does today is important.

MODULES_FILTER += jdk.internal.vm.compiler.management
endif
# Filter out Graal specific modules
MODULES_FILTER += jdk.internal.vm.compiler

This comment has been minimized.

@erikj79

erikj79 Apr 12, 2021
Member

If we are unconditionally filtering out these modules, then why leave the module-info.java files in at all?

This comment has been minimized.

@vnkozlov

vnkozlov Apr 12, 2021
Author Contributor

We filter out because we can't build Graal anymore. But we need these module-info.java files because JVMCI's module-info.java references them:
https://github.com/openjdk/jdk/blob/master/src/jdk.internal.vm.ci/share/classes/module-info.java#L26

Otherwise we can't build JVMCI which we continue to support.

I filed followup RFE to implement Alan's suggestion to use Module API which will allow to remove these files later:
https://bugs.openjdk.java.net/browse/JDK-8265091

This comment has been minimized.

@erikj79

erikj79 Apr 12, 2021
Member

Right, I thought I saw something about modules that Alan commented on, but couldn't find it. All good then.

Copy link
Member

@erikj79 erikj79 left a comment

Build changes look good.

MODULES_FILTER += jdk.internal.vm.compiler.management
endif
# Filter out Graal specific modules
MODULES_FILTER += jdk.internal.vm.compiler

This comment has been minimized.

@erikj79

erikj79 Apr 12, 2021
Member

Right, I thought I saw something about modules that Alan commented on, but couldn't find it. All good then.

@vnkozlov
Copy link
Contributor Author

@vnkozlov vnkozlov commented Apr 12, 2021

@dougxc I restored Compiler::isGraalEnabled().

@dougxc
Copy link
Member

@dougxc dougxc commented Apr 13, 2021

@dougxc I restored Compiler::isGraalEnabled().

Thanks. I guess this should really be named isJVMCICompilerEnabled now and the vm.graal.enabled predicate renamed to vm.jvmcicompiler.enabled but maybe that's too big a change (or can be done later).

@vnkozlov
Copy link
Contributor Author

@vnkozlov vnkozlov commented Apr 13, 2021

@dougxc
Renaming should be done separately. May be use RFE I filed: https://bugs.openjdk.java.net/browse/JDK-8265032

Do you approve these Graal removal changes?

@dougxc
Copy link
Member

@dougxc dougxc commented Apr 13, 2021

Approved.

@openjdk-notifier openjdk-notifier bot changed the base branch from pr/3398 to master Apr 27, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Apr 27, 2021

@vnkozlov this pull request can not be integrated into master due to one or more merge conflicts. To resolve these merge conflicts and update this pull request you can run the following commands in the local repository for your personal fork:

git checkout JDK-8264806
git fetch https://git.openjdk.java.net/jdk master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push
@openjdk
Copy link

@openjdk openjdk bot commented Apr 27, 2021

⚠️ @vnkozlov This pull request contains merges that bring in commits not present in the target repository. Since this is not a "merge style" pull request, these changes will be squashed when this pull request in integrated. If this is your intention, then please ignore this message. If you want to preserve the commit structure, you must change the title of this pull request to Merge <project>:<branch> where <project> is the name of another project in the OpenJDK organization (for example Merge jdk:master).

@openjdk
Copy link

@openjdk openjdk bot commented Apr 27, 2021

@vnkozlov 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:

8264806: Remove the experimental JIT compiler

Reviewed-by: iignatyev, erikj

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 master branch. If another commit should be pushed before you perform the /integrate command, your PR will be automatically rebased. If you prefer to avoid any potential automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

@openjdk openjdk bot added ready and removed merge-conflict labels Apr 27, 2021
@vnkozlov
Copy link
Contributor Author

@vnkozlov vnkozlov commented Apr 27, 2021

/integrate

@openjdk openjdk bot closed this Apr 27, 2021
@openjdk openjdk bot added integrated and removed ready rfr labels Apr 27, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Apr 27, 2021

@vnkozlov Since your change was applied there has been 1 commit pushed to the master branch:

  • 7db9330: 8196300: java/awt/TextArea/TextAreaScrolling/TextAreaScrolling.java times out

Your commit was automatically rebased without conflicts.

Pushed as commit 4785e11.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

@vnkozlov vnkozlov deleted the vnkozlov:JDK-8264806 branch Apr 27, 2021
@iignatev
Copy link
Member

@iignatev iignatev commented Apr 27, 2021

I guess this should really be named isJVMCICompilerEnabled now and the vm.graal.enabled predicate renamed to vm.jvmcicompiler.enabled but maybe that's too big a change (or can be done later).

@dougxc, I don't think that we should (or even can) rename it to vm.jvmcicompiler.enabled. although the value of the property is indeed true whenever a jvmci compiler is enabled, it is used to filter out tests that are incompatible with a particular compiler -- graal. so what we can do is to change requires/VMProps.java to set vm.graal.enabled only if the jvmci compiler is indeed graal, but on the other hand, we haven't heard anyone complaining that the test coverage for their jvmci compiler has been reduced, so I don't see much of the benefit here.

-- Igor

@dougxc
Copy link
Member

@dougxc dougxc commented Apr 27, 2021

I guess this should really be named isJVMCICompilerEnabled now and the vm.graal.enabled predicate renamed to vm.jvmcicompiler.enabled but maybe that's too big a change (or can be done later).

@dougxc, I don't think that we should (or even can) rename it to vm.jvmcicompiler.enabled. although the value of the property is indeed true whenever a jvmci compiler is enabled, it is used to filter out tests that are incompatible with a particular compiler -- graal. so what we can do is to change requires/VMProps.java to set vm.graal.enabled only if the jvmci compiler is indeed graal, but on the other hand, we haven't heard anyone complaining that the test coverage for their jvmci compiler has been reduced, so I don't see much of the benefit here.

-- Igor

Yes, we should just it as is until a second JVMCI compiler shows up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
4 participants