Skip to content

Conversation

@david-beaumont
Copy link
Contributor

@david-beaumont david-beaumont commented Dec 18, 2025

Tidying up syncrhonization around shared image.


Progress

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

Issue

  • JDK-8362252: [lworld] Possible synchronization issue in jdk/internal/jimage/ImageReader.java (Bug - P4)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 1828

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/valhalla/pull/1828.diff

Using Webrev

Link to Webrev Comment

@bridgekeeper
Copy link

bridgekeeper bot commented Dec 18, 2025

👋 Welcome back david-beaumont! A progress list of the required criteria for merging this PR into lworld 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 Dec 18, 2025

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

@openjdk openjdk bot added the rfr Pull request is ready for review label Dec 18, 2025
@mlbridge
Copy link

mlbridge bot commented Dec 18, 2025

Webrevs


synchronized (OPEN_FILES) {
ReaderKey key = new ReaderKey(imagePath, previewMode);
SharedImageReader reader = OPEN_FILES.get(key);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I changed the name of this for clarity. It's a bit confusing to have two "image reader" instances in scope with one called "image" and one called just "reader".

throw new IOException("image file not found in open list");
}
}
super.close();
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I will double check if moving this outside the synchronization of OPEN_FILES is an issue.
The underlying BasicImageReader using a file channel, which is close (with locking) in this close() method.
The vague worry I have is that now the outter OPEN_FILES lock isn't held, we can get a race where the same file has a file channel being closed as a new one is being opened, and I'm not 100% sure I know if that's safe.
Moving this back into the OPEN_FILES lock is possible, but leaves this code doing more work with the locks held, which I'm inclined to avoid if possible.

sharedReader = new SharedImageReader(imagePath, byteOrder, previewMode);
OPEN_FILES.put(key, sharedReader);
} else if (sharedReader.getByteOrder() != byteOrder) {
throw new IOException("\"" + sharedReader.getName() + "\" is not an image file");
Copy link
Collaborator

Choose a reason for hiding this comment

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

Its pre-existing, but ...
Testing the byteOrder and then throwing an exception that says it is not an Image file doesn't make sense.

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

Labels

rfr Pull request is ready for review

Development

Successfully merging this pull request may close these issues.

2 participants