8368960: Adjust java UL logging in the build

[MBaesken]

In the build process, unwanted UL error/warning messages can pollute stdout and influence the build process/results.

An example is the polluted blocked.certs file from https://bugs.openjdk.org/browse/JDK-8357691 .

---

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

Issue

• JDK-8368960: Adjust java UL logging in the build (Bug - P4)

Reviewers

• Erik Joelsson (@erikj79 - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 27588

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

Using diff file

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

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back mbaesken! 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]

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

8368960: Adjust java UL logging in the build

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

• 3d113af: 8369051: More small Float16 refactorings
• 5fccabf: 8368670: Deadlock in JFR on event register + class load
• 1a03a1f: 8369033: Remove dead code in training data
• ... and 21 more: https://git.openjdk.org/jdk/compare/6c2d383492d194eb8a604a58a0336c371cbb1ea5...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.

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

[openjdk]

@MBaesken 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.

[mlbridge]

Webrevs

• 02: Full - Incremental (498d70f3)
• 01: Full - Incremental (d674a86f)
• 00: Full (74351b4e)

[dholmes-ora]

@MBaesken I thought the aim was to redirect log warnings/errors to stderr, not to disable logging completely.

[MBaesken]

I thought the aim was to redirect log warnings/errors to stderr, not to disable logging completely.

Yeah I considered this too.
But not sure about it ; bring the UL messages (warnings/errors etc.) really a benefit in the build itself ?
But I am open to set some other UL command line flags keeping messages .

[erikj79]

I thought the aim was to redirect log warnings/errors to stderr, not to disable logging completely.

Yeah I considered this too. But not sure about it ; bring the UL messages (warnings/errors etc.) really a benefit in the build itself ? But I am open to set some other UL command line flags keeping messages .

If it's possible to redirect it to stderr, I think that would be preferred. It would make us aware of misconfigured tool command lines.

In the case of the original warning you saw that triggered this, I think we need to actually fix our usage of CDS in the boot JDK. The current implementation was introduced back when the JDK didn't ship with a default CDS archive. Now that it does, we don't actually need to create one in configure. It would be interesting to see if there is any performance difference using the default archive.

[MBaesken]

If it's possible to redirect it to stderr, I think that would be preferred. It would make us aware of misconfigured tool command lines.

I adjusted the settings, please comment if this is better.

[MBaesken]

In the case of the original warning you saw that triggered this, I think we need to actually fix our usage of CDS in the boot JDK

So do you think we can just kick out this archive dumping + Xshare=something setting from configure ?

[erikj79]

In the case of the original warning you saw that triggered this, I think we need to actually fix our usage of CDS in the boot JDK

So do you think we can just kick out this archive dumping + Xshare=something setting from configure ?

Yes, I think we can, but I would like to see it verified to not cause a regression in build performance before we do.

[dholmes-ora]

This is not sufficient you have to disable the warnings on stdout, not just enable them on stderr.