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

8313562: hsperfdata should export module path and "launcher" metadata #19287

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

larry-cable
Copy link
Contributor

@larry-cable larry-cable commented May 17, 2024

hsperfdata should expose module metadata if available.


Progress

  • Change must be properly reviewed (1 review required, with at least 1 Reviewer)
  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue

Warning

 ⚠️ Found leading lowercase letter in issue title for 8313562: hsperfdata should export module path and "launcher" metadata

Issue

  • JDK-8313562: hsperfdata should export module path and "launcher" metadata (Enhancement - P4)

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/19287/head:pull/19287
$ git checkout pull/19287

Update a local copy of the PR:
$ git checkout pull/19287
$ git pull https://git.openjdk.org/jdk.git pull/19287/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 19287

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/19287.diff

Webrev

Link to Webrev Comment

@larry-cable
Copy link
Contributor Author

/integrate

@bridgekeeper
Copy link

bridgekeeper bot commented May 17, 2024

👋 Welcome back larry-cable! 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.

@openjdk
Copy link

openjdk bot commented May 17, 2024

@larry-cable 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:

8313562: hsperfdata should export module path and "launcher" metadata

Reviewed-by: dholmes, kevinw

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 50 new commits pushed to the master branch:

  • 2a37764: 8333743: Change .jcheck/conf branches property to match valid branches
  • 75dc2f8: 8330182: Start of release updates for JDK 24
  • 054362a: 8332550: [macos] Voice Over: java.awt.IllegalComponentStateException: component must be showing on the screen to determine its location
  • 9b436d0: 8333674: Disable CollectorPolicy.young_min_ergo_vm for PPC64
  • 487c477: 8333647: C2 SuperWord: some additional PopulateIndex tests
  • d02cb74: 8333270: HandlersOnComplexResetUpdate and HandlersOnComplexUpdate tests fail with "Unexpected reference" if timeoutFactor is less than 1/3
  • 02f2404: 8333560: -Xlint:restricted does not work with --release
  • 606df44: 8332670: C1 clone intrinsic needs memory barriers
  • 33fd6ae: 8333622: ubsan: relocInfo_x86.cpp:101:56: runtime error: pointer index expression with base (-1) overflowed
  • 8de5d20: 8332865: ubsan: os::attempt_reserve_memory_between reports overflow
  • ... and 40 more: https://git.openjdk.org/jdk/compare/244f6ac222fa98fba4fb99bf5bccd36e3e6c5de1...master

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.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@dholmes-ora, @kevinjwalls) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

@openjdk openjdk bot added the rfr Pull request is ready for review label May 17, 2024
@openjdk
Copy link

openjdk bot commented May 17, 2024

@larry-cable This pull request has not yet been marked as ready for integration.

@openjdk
Copy link

openjdk bot commented May 17, 2024

@larry-cable The following label will be automatically applied to this pull request:

  • hotspot-runtime

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.

@openjdk openjdk bot added the hotspot-runtime hotspot-runtime-dev@openjdk.org label May 17, 2024
@mlbridge
Copy link

mlbridge bot commented May 17, 2024

Webrevs

Comment on lines 263 to 266

add_property_constant(JAVA_PROPERTY, "jdk.module.path", CHECK);
add_property_constant(JAVA_PROPERTY, "jdk.module.upgrade.path", CHECK);
add_property_constant(JAVA_PROPERTY, "jdk.module.main", CHECK);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are not "java" properties - do we need to add a "jdk" namespace?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

correct @dholmes-ora however a couple of points to note:

  • these properties are listed in the javadoc for System::getProperties also "jdk.debug" is a pre-existing property also present in the JAVA_PROPERTY NS ... which somewhat sets an awkward precedent...

happy to add a new JDK_PROPERTY NS but given the pre-existence of "jdk.debug" not clear to me that such would not introduce an arbitrary inconsistency

thoughts?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure what the list of system properties in System.get_properties has to do with this. That list includes a bunch of properties in the java namespace and a bunch not.

The pre-existence of jdk.debug is unfortunate and, I think, a mistake. As you can see from the JBS issue description the original intent was to have java.vm.debug but it got changed to jdk.debug:

https://bugs.openjdk.org/browse/JDK-8139986

I think the question that needs to be answered is why do these different namespaces even exist? AFAICT the SUN_* namespace is used for internal/implementation things and arguably if we could have we might have renamed that to JDK_*. But the reality is that we are dealing with an archaic part of the system that really reflects an age long past and could do with some modernization.

So I guess for the sake of moving forward we can ignore the namespace for now and just flag these as "Java" properties.

@larry-cable
Copy link
Contributor Author

larry-cable commented May 20, 2024 via email

@larry-cable
Copy link
Contributor Author

larry-cable commented May 20, 2024 via email

@openjdk openjdk bot added the ready Pull request is ready to be integrated label May 21, 2024
@larry-cable
Copy link
Contributor Author

/integrate

@openjdk openjdk bot added the sponsor Pull request is ready to be sponsored label Jun 4, 2024
@openjdk
Copy link

openjdk bot commented Jun 4, 2024

@larry-cable
Your change (at version cd1d3f3) is now ready to be sponsored by a Committer.

@openjdk openjdk bot removed the sponsor Pull request is ready to be sponsored label Jun 5, 2024
Copy link
Contributor

@kevinjwalls kevinjwalls left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The update is good, yes those can be nulls 8-)

Do you see a compiler warning for the if being all on one line, in line 239 of statSampler.cpp? I do, locally, and I need to use if () { } to avoid a build failure.

Then running with: --module-path=/foo
I see:

jcmd 14540 PerfCounter.print | grep -i modu
java.property.jdk.module.path="/foo"
java.rt.vmArgs="--module-path=/foo"
jdk.module.finder.modulepath.modules=0
jdk.module.finder.modulepath.scanTime=10411013

JDK-8313562 doesn't specify what information will be included and what perfdata names will be, but I think this is what was intended.

Maybe a (C) update while you're there, and it's done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hotspot-runtime hotspot-runtime-dev@openjdk.org ready Pull request is ready to be integrated rfr Pull request is ready for review
3 participants