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

8273801: Handle VMTYPE for "core" VM variant #5525

Closed
wants to merge 1 commit into from

Conversation

@shipilev
Copy link
Contributor

@shipilev shipilev commented Sep 15, 2021

Building with --with-jvm-variants=core currently produces a binary that replies an odd version:

$ build/linux-x86_64-core-fastdebug/images/jdk/bin/java -version
openjdk version "18-internal" 2022-03-15
OpenJDK Runtime Environment (fastdebug build 18-internal+0-adhoc.shade.jdk)
OpenJDK 64-Bit  VM (fastdebug build 18-internal+0-adhoc.shade.jdk, interpreted mode)

It should actually say "OpenJDK 64-Bit Core VM", I think. Build just misses a simple definition of VMTYPE for core variant.

After the patch:

$ build/linux-x86_64-core-fastdebug/images/jdk/bin/java -client -version
openjdk version "18-internal" 2022-03-15
OpenJDK Runtime Environment (fastdebug build 18-internal+0-adhoc.shade.jdk)
OpenJDK 64-Bit Core VM (fastdebug build 18-internal+0-adhoc.shade.jdk, interpreted mode)

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/5525/head:pull/5525
$ git checkout pull/5525

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 5525

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

Using diff file

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

@bridgekeeper
Copy link

@bridgekeeper bridgekeeper bot commented Sep 15, 2021

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

Loading

@openjdk openjdk bot added the rfr label Sep 15, 2021
@openjdk
Copy link

@openjdk openjdk bot commented Sep 15, 2021

@shipilev The following label will be automatically applied to this pull request:

  • build

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

Loading

@openjdk openjdk bot added the build label Sep 15, 2021
@mlbridge
Copy link

@mlbridge mlbridge bot commented Sep 15, 2021

Webrevs

Loading

Copy link
Member

@dholmes-ora dholmes-ora left a comment

Trivially fine.

But perhaps we should be looking to remove "core" going forward?

Thanks.
David

Loading

@openjdk
Copy link

@openjdk openjdk bot commented Sep 15, 2021

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

8273801: Handle VMTYPE for "core" VM variant

Reviewed-by: dholmes, 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 5 new commits pushed to the master branch:

  • 8290424: 8272771: frame::pd_ps() is not implemented on any platform
  • a3ca770: 8272815: jpackage --type rpm produces an error: Invalid or unsupported type: [null]
  • 8132bfd: 8273559: Shenandoah: Shenandoah should support multi-threaded heap dump
  • f531b5c: 8273514: java/util/DoubleStreamSums/CompensatedSums.java failure
  • 4c673df: 8273656: Improve java.lang.invoke.MethodType.parameterList() and its usage

Please see this link for an up-to-date comparison between the source branch of this pull request and the master branch.
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this 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.

Loading

@openjdk openjdk bot added the ready label Sep 15, 2021
@shipilev
Copy link
Contributor Author

@shipilev shipilev commented Sep 15, 2021

But perhaps we should be looking to remove "core" going forward?

Yes, we should consider it. @magicus told me that somebody wanted for "core" to remain, the last time the removal was suggested. I guess is it somewhat useful in porting work: producing the builds where only template interpreter is implemented.

Loading

@mlbridge
Copy link

@mlbridge mlbridge bot commented Sep 15, 2021

Mailing list message from David Holmes on build-dev:

On 15/09/2021 11:34 pm, Aleksey Shipilev wrote:

On Wed, 15 Sep 2021 12:45:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

But perhaps we should be looking to remove "core" going forward?

Yes, we should consider it. @magicus [told me](https://github.com//pull/5440#discussion_r705464312) that somebody wanted for "core" to remain, the last time the removal was suggested. I guess is it somewhat useful in porting work: producing the builds where only template interpreter is implemented.

Good point - I hadn't considered that. But I wonder whether it is
actually still functional? If so and we want to keep it we should
probably build it regularly.

David

Loading

@shipilev
Copy link
Contributor Author

@shipilev shipilev commented Sep 16, 2021

Good point - I hadn't considered that. But I wonder whether it is
actually still functional? If so and we want to keep it we should
probably build it regularly.

Given that newer build system can accept --with-jvm-features=-compiler1,-compiler2, I'd question the need for core to begin with. But that's for another day.

Loading

@shipilev
Copy link
Contributor Author

@shipilev shipilev commented Sep 16, 2021

/integrate

Loading

@openjdk
Copy link

@openjdk openjdk bot commented Sep 16, 2021

Going to push as commit 181292d.
Since your change was applied there have been 14 commits pushed to the master branch:

  • 09ecb11: 8273806: compiler/cpuflags/TestSSE4Disabled.java should test for CPU feature explicitly
  • 99cfc16: 8273805: gc/g1/TestGCLogMessages.java test should handle non-JFR configs
  • 1c5de8b: 8273807: Zero: Drop incorrect test block from compiler/startup/NumCompilerThreadsCheck.java
  • 46af82e: 8273804: Platform.isTieredSupported should handle the no-compiler case
  • 2d13fb2: 8273803: Zero: Handle "zero" variant in CommandLineOptionTest.java
  • d4546b6: 8273526: Extend the OSContainer API pids controller with pids.current
  • 74ffe12: 8273575: memory leak in appendBootClassPath(), paths must be deallocated
  • cbffecc: 8273832: gc/shenandoah/TestJcmdHeapDump.java does not have a @requires vm.gc.shenandoah
  • 7b2beb6: 8273823: Problemlist gc/stringdedup tests timing out on ZGC
  • 8290424: 8272771: frame::pd_ps() is not implemented on any platform
  • ... and 4 more: https://git.openjdk.java.net/jdk/compare/8fbcc8239a3fc04e56ebbd287c7bb5db731977b7...master

Your commit was automatically rebased without conflicts.

Loading

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

@openjdk openjdk bot commented Sep 16, 2021

@shipilev Pushed as commit 181292d.

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

Loading

@dholmes-ora
Copy link
Member

@dholmes-ora dholmes-ora commented Sep 16, 2021

Begs the question ... if there is no C1 and no C2 then what is the name of the directory where libjvm.so lives?

Loading

@shipilev shipilev deleted the JDK-8273801-core-version branch Sep 20, 2021
@magicus
Copy link
Member

@magicus magicus commented Sep 20, 2021

@dholmes-ora If you are building server, then it is called server regardless of what JVM features you enable or disable.

The way the build system works is that a "JVM variant" is a set of enabled JVM features with a given name. You can roll your own JVM variant by starting with custom, which has an empty initial set of features enabled. (But currently, you cannot change the name from the configure command line.)

If core is built only when porting to new platforms, we could emulate that behavior by allowing the user to change the JVM variant name as well, like configure --with-jvm-variant=server --with-jvm-features=-compiler1,-compiler2 --with-jvm-name=core or something like that. (And just generate VMTYPE dynamically using Sentence Case). I think this can be seriously considered. But I suspect I should try to dug out from my mailbox archives whom it was last told me they needed/wanted core.

Loading

@mlbridge
Copy link

@mlbridge mlbridge bot commented Sep 21, 2021

Mailing list message from David Holmes on build-dev:

On 20/09/2021 9:43 pm, Magnus Ihse Bursie wrote:

On Thu, 16 Sep 2021 12:02:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

Building with --with-jvm-variants=core currently produces a binary that replies an odd version:

$ build/linux-x86_64-core-fastdebug/images/jdk/bin/java -version
openjdk version "18-internal" 2022-03-15
OpenJDK Runtime Environment (fastdebug build 18-internal+0-adhoc.shade.jdk)
OpenJDK 64-Bit VM (fastdebug build 18-internal+0-adhoc.shade.jdk, interpreted mode)

It should actually say "OpenJDK 64-Bit Core VM", I think. Build just misses a simple definition of `VMTYPE` for core variant.

After the patch:

$ build/linux-x86_64-core-fastdebug/images/jdk/bin/java -client -version
openjdk version "18-internal" 2022-03-15
OpenJDK Runtime Environment (fastdebug build 18-internal+0-adhoc.shade.jdk)
OpenJDK 64-Bit Core VM (fastdebug build 18-internal+0-adhoc.shade.jdk, interpreted mode)

Begs the question ... if there is no C1 and no C2 then what is the name of the directory where libjvm.so lives?

@dholmes-ora If you are building `server`, then it is called `server` regardless of what JVM features you enable or disable.

Doh! Of course. The variant determines the name.

Thanks,
David

Loading

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