8355608: Async UL should take the file lock of stream when outputting #24874
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
With the introduction of JDK-8349755, it is not entirely clear any longer that the Async UL has exclusive access to the files which are being logged to in the JVM. We should take the file lock for the stream being logged to for safety's sake.
If, for example, an unattached thread logs, then it will do so without the help of the Async UL thread.
This is expected to very rarely, if ever, happen. Since taking an uncontested mutex is very cheap, I expect this to have a negligible performance impact.
Testing: GHA, tier1
Cheers,
Johan
Progress
Issue
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/24874/head:pull/24874
$ git checkout pull/24874
Update a local copy of the PR:
$ git checkout pull/24874
$ git pull https://git.openjdk.org/jdk.git pull/24874/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 24874
View PR using the GUI difftool:
$ git pr show -t 24874
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/24874.diff
Using Webrev
Link to Webrev Comment