-
Notifications
You must be signed in to change notification settings - Fork 6.1k
8359380: Rework deferral profile logic after JDK-8346465 #26179
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
base: master
Are you sure you want to change the base?
Conversation
👋 Welcome back serb! A progress list of the required criteria for merging this PR into |
❗ This change is not yet ready to be integrated. |
* @summary Verifies profile properties are the same before/after activation | ||
* @bug 8256321 8359380 | ||
* @summary Verifies built-in profile properties are the same before and after | ||
* activation and in copies of built-in profiles |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The test compared data from the lightweight object with the actual data used after the profile is fully loaded. Since we now always use the lightweight object, I had to create a copy of the standard profile to make sure the actual profile data is used.
@honkar-jdk please take a look |
The ICC_Profile class has special logic to postpone actual data loading for as long as possible. To support this we use a lightweight object that stores commonly used metadata such as the number of components that can be accessed without triggering full profile loading. But we currently discard this object once the profile is used for color conversion since the application might modify the profile data in a way that becomes inconsistent with what was previously cached.
After JDK-8346465 all standard ICC profiles bundled with the JDK are now immutable. This means the deferral logic can be simplified: we no longer need to drop the lightweight metadata object since the underlying data is guaranteed to remain unchanged.
This patch includes two changes:
We stop discarding the deferred metadata object. It will now used consistently removing the need for a special flag to identify standard profiles.
While implementing the logic above I noticed a workaround introduced for JDK-8272860 no longer applies. This workaround relied on getNumComponents() triggering header profile loading which no longer happens for standard profiles. Initially(at the moment the JDK-8272860 was filed) this caused test failures but due to unrelated changes all those tests now pass. To ensure this issue is still caught in the future, I’ve added a new test case that specifically verifies this behavior.
Progress
Issue
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/26179/head:pull/26179
$ git checkout pull/26179
Update a local copy of the PR:
$ git checkout pull/26179
$ git pull https://git.openjdk.org/jdk.git pull/26179/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 26179
View PR using the GUI difftool:
$ git pr show -t 26179
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/26179.diff
Using Webrev
Link to Webrev Comment