Re: RFR: 8351969: Add Public Identifiers to the JDK built-in Catalog [v2]
On Tue, 18 Mar 2025 19:55:39 GMT, Joe Wang wrote: >> src/java.xml/share/classes/jdk/xml/internal/jdkcatalog/w3c/dtd/schema10/XMLSchema.dtd >> line 8: >> >>> 6: >>> >>> 7: >>> >>> 8: >>> >> >> The other XML comments use the multi-line format with a single begin >> What is the meaning of ""? >> Is "REC" a typo? >> The comment seems unnecessarily apologetic. It should be sufficient to say: >> Note: this DTD is NOT normative, any differences from RFC XXX are >> insidential". (or similar). > > Makes sense. The question would be, would we want to modify the standard file? Likely, a number of my comments were due to comparing with the wrong XMLSchema.data version. - PR Review Comment: https://git.openjdk.org/jdk/pull/24039#discussion_r2003370242
Re: jpackage and Wix 5
Hi Davide,
jpackage should work seamlessly with WiX5. Could you run your jpackage
command with `--verbose` arg? It will provide a context for the error.
- Alexey
On 3/19/2025 6:19 AM, Davide Perini wrote:
I add some context:
I installed wix 5 using the donet command globally,
wix is in the path but when I try to run my jpackage command I get
this error:
jpackage -i ./target --type exe --main-class
org.dpsoftware.JavaFXStarter --main-jar
FireflyLuciferin-jar-with-dependencies.jar --icon
./data/img/luciferin_logo.ico
--win-menu --win-menu-group Ambilight --copyright "Davide Perini"
--name "Firefly Luciferin" --vendor DPsoftware --win-dir-chooser
--win-shortcut --win-per-user-install --win-shortcut
--win-shortcut-prompt --java-options "-XX:+UseZGC -Xms64m -Xmx1024m"
java.io.IOException: Command [wix.exe, build, -nologo, -pdbtype, none,
-intermediatefolder,
C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\wixobj,
-ext, WixToolset.Util.wixext, -arch, x64, -ext, WixToolset.UI
.wixext, -b,
C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config,
-loc,
C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config\MsiInstallerStrings_de.wxl,
-loc, C:\Users\SBLANT~1\AppData\
Local\Temp\jdk.jpackage95160440034084538\config\MsiInstallerStrings_en.wxl,
-loc,
C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config\MsiInstallerStrings_ja.wxl,
-loc, C:\Users\SBLANT~1\AppData\Local\Temp\j
dk.jpackage95160440034084538\config\MsiInstallerStrings_zh_CN.wxl,
-culture, en-us, -d, JpAppDescription=Firefly Luciferin, -d,
JpStartMenuShortcutPrompt=yes, -d, JpDesktopShortcutPrompt=yes, -d,
JpProductCode=e0be8901-8911-3da4
-83e2-2c15892e1623, -d, JpAppName=Firefly Luciferin, -d,
JpAllowDowngrades=yes, -d,
JpIcon=C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\images\win-msi.image\Firefly
Luciferin\Firefly Luciferin.exe, -d, JpAp
pSizeKb=409283, -d, JpAppVersion=1.0, -d,
JpAfterInstallDirDlg=ShortcutPromptDlg, -d, JpAllowUpgrades=yes, -d,
JpProductUpgradeCode=2b8902a1-d85a-3650-9b08-d990b365e5e9, -d,
JpAppVendor=DPsoftware, -d, JpConfigDir=C:\Users\SBLAN
T~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config,
C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config\main.wxs,
C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config\bundle.wx
f,
C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config\ui.wxf,
C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config\ShortcutPromptDlg.wxs,
C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpack
age95160440034084538\config\InstallDirNotEmptyDlg.wxs, -out,
C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\wixobj\a.msi]
in
C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\images\win-msi.image\Firefly
Luciferin exited with 144 code
Il 19/03/2025 10:12, Davide Perini ha scritto:
Hi there,
I'm using jpackage along with Wix3.
The command I use to generate my .exe is:
jpackage -i ../../target --type exe --main-class
org.dpsoftware.JavaFXStarter --main-jar
FireflyLuciferin-jar-with-dependencies.jar --icon
../../data/img/java_fast_screen_capture_logo.ico --win-menu
--win-menu-group Luciferin --copyright "Davide Perini" --name
"Firefly Luciferin" --vendor DPsoftware --win-dir-chooser
--win-shortcut --win-per-user-install --win-upgrade-uuid myuuid
--app-version "${{steps.get-id.outputs.id}}" --win-shortcut
--win-shortcut-prompt --java-options "-XX:+UseZGC
-XX:+UseStringDeduplication -Xms64m -Xmx1024m
--add-modules=jdk.incubator.vector"
How can I move it to Wix5 using Java 24?
Is there a guide/documentation that help in migrating from Wix 3 to
Wix 5?
Thanks
Davide
Re: RFR: 8351969: Add Public Identifiers to the JDK built-in Catalog [v3]
On Wed, 19 Mar 2025 00:43:28 GMT, Joe Wang wrote: >> Add public identifiers to the JDK built-in Catalog; Replace the incorrect >> Schema 1.1 DTD files (note the Public Identifier at line 2) with the correct >> Schema 1.0 DTDs. The JDK built-in Catalog contains Schema 1.0 files only. >> >> DTD files: the Schema 1.1 files, XMLSchema.dtd and datatypes.dtd, were >> removed and replaced with those of Schema 1.0. These files were downloaded >> from w3.org without modification. The file names were unfortunately the >> same, which (with the Diffs) made it look like they were modified though >> they were not. > > Joe Wang has updated the pull request incrementally with one additional > commit since the last revision: > > replace JDK Catalog in the java.xml module with public API The .dtds look fine. Thanks for the update to the test. - Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24039#pullrequestreview-2698536636
Re: RFR: 8351969: Add Public Identifiers to the JDK built-in Catalog [v2]
On Tue, 18 Mar 2025 18:27:56 GMT, Roger Riggs wrote: >> Joe Wang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> update the test: change variables and etc. > > src/java.xml/share/classes/jdk/xml/internal/jdkcatalog/w3c/dtd/schema10/XMLSchema.dtd > line 20: > >> 18: >> 19: >> 20:
Re: RFR: 8347712: IllegalStateException on multithreaded ZipFile access with non-UTF8 charset [v2]
On Thu, 13 Mar 2025 11:03:00 GMT, Jaikiran Pai wrote: >> Hello Jaikiran, >> >> I'm not convinced dropping `zipCoderForPos` is a step forward: >> >> * `zipCoderForPos` included a short-circuit optimization logic which skipped >> reading the CENFLG field in the case where the opening charset was UTF-8 >> (which it commonly is, and always for JarFile). This optimization seems lost >> in the currrent state of this PR and could impact lookup performance. It >> would be strange to repeat this optimization at all call sites. >> * The only thing differing between callsites seems to be which ZipCoder to >> use as a "fallback" when it's not UTF-8. This ZipCoder instance can easilly >> be passed in as a parameter, and will de-duplicate logic at the call sites. >> * The only "cumbersome" call site seems to be `initCEN`, caused by the lazy >> initialization of the non-UTF-8 ZipCoder. But that lazy initialization seems >> questionable: First, ZipCoder is already lazy in the way it initializes >> encoders and decoders. An unused ZipCoder is just a thin wrapper around a >> Charset and should not incur significant cost until it gets used. Second, >> the `ZipFile` constructor actually constructs a `ZipCoder` instance, would >> it not be better to just pass this down to initCEN as a parameter? That >> would avoid the cost of initializing encoders and decoders twice for the >> common case of single-threaded `ZipFile` access, once for initCEN, then >> again on the first lookup. >> >> Here's a patch for a quick implementation of the above on top of your PR. >> (Code speeks better than words some times :-) >> >> This retains the CENFLG optimization, simplifies logic at call sites and >> prevents duplicated initialization of ZipCoder beteween initCEN and lookups: >> >> >> Index: src/java.base/share/classes/java/util/zip/ZipFile.java >> IDEA additional info: >> Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP >> <+>UTF-8 >> === >> diff --git a/src/java.base/share/classes/java/util/zip/ZipFile.java >> b/src/java.base/share/classes/java/util/zip/ZipFile.java >> --- a/src/java.base/share/classes/java/util/zip/ZipFile.java (revision >> 935b04ed00522aa92105292baa0693c55b1356ae) >> +++ b/src/java.base/share/classes/java/util/zip/ZipFile.java (date >> 1741800197915) >> @@ -201,8 +201,8 @@ >> this.fileName = file.getName(); >> long t0 = System.nanoTime(); >> >> -this.res = new CleanableResource(this, charset, file, mode); >> this.zipCoder = ZipCoder.get(charset); >> +this.res = new CleanableResource(this... > > Hello Eirik, > >> zipCoderForPos included a short-circuit optimization logic which skipped >> reading the CENFLG field in the case where the opening charset was UTF-8 >> (which it commonly is, and always for JarFile). This optimization seems lost >> in the currrent state of this PR > > That's a good point. I'll update this PR shortly, borrowing from your > proposed diff/patch. Hello Eirik, I have now updated the PR to borrow a major part of the diff that you provided. This now brings back the `zipCoderFor()` method and at the same time, we don't end up holding on to the `ZipCoder` in the the `Source` class, which is expected to be thread safe. - PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r2003488113
Re: RFR: 8347712: IllegalStateException on multithreaded ZipFile access with non-UTF8 charset [v4]
On Thu, 13 Mar 2025 19:31:31 GMT, Eirik Bjørsnøs wrote:
>> Jaikiran Pai has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> add code comment
>
> test/jdk/java/util/zip/ZipFile/ZipFileSharedSourceTest.java line 78:
>
>> 76:
>> 77: /**
>> 78: * Creates multiple instances of java.util.zip.ZipFile with the
>> given {@code entryNameCharset}
>
> This comment could be interpreted as saying that the construction of the
> ZipFile instances happens up-front, on the main test thread. However, looking
> at the actual code, the construction of the ZipFile instance AND the
> enumeration happens concurrently.
>
> Perhaps we could trim the "how" part here, and instad just say that the test
> verifies that concurrent construction and enumeration of
> java.util.zip.ZipFile instances backed by a the same ZIP file does not cause
> unexpected encoding-related concurrency failures?
I've now updated the test method comment to clarify what the test does.
> test/jdk/java/util/zip/ZipFile/ZipFileSharedSourceTest.java line 86:
>
>> 84: @ParameterizedTest
>> 85: @MethodSource("charsets")
>> 86: void testMultipleZipFileInstances(final Charset
>> entryNameCommentCharset) throws Exception {
>
> The Charset parameter could be renamed to `charset`.
Done.
> test/jdk/java/util/zip/ZipFile/ZipFileSharedSourceTest.java line 111:
>
>> 109: private final CountDownLatch startLatch;
>> 110:
>> 111: private ZipEntryIteratingTask(final Path file, final Charset
>> entryNameCharset,
>
> The Charset parameter/field could be renamed to `charset`.
Done.
> test/jdk/java/util/zip/ZipFile/ZipFileSharedSourceTest.java line 127:
>
>> 125: try (final ZipFile zf = new ZipFile(this.file.toFile(),
>> this.entryNameCharset)) {
>> 126: final var entries = zf.entries();
>> 127: while (entries.hasMoreElements()) {
>
> I think it would be good to include a call to `ZipFile::getEntry` here as
> well, since that exercises a separate code path.
Done. The updated PR now does a `ZipFile.getEntry()` call too.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r2003489767
PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r2003491140
PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r2003490799
PR Review Comment: https://git.openjdk.org/jdk/pull/23986#discussion_r2003490505
Re: RFR: 8319447: Improve performance of delayed task handling [v11]
On Fri, 14 Mar 2025 09:36:43 GMT, Doug Lea wrote: >> (Copied from https://bugs.openjdk.org/browse/JDK-8319447) >> >> The problems addressed by this CR/PR are that ScheduledThreadPoolExecutor is >> both ill-suited for many (if not most) of its applications, and is a >> performance bottleneck (as seen especially in Loom and CompletableFuture >> usages). After considering many options over the years, the approach taken >> here is to connect (lazily, only if used) a form of ScheduledExecutorService >> (DelayScheduler) to any ForkJoinPool (including the commonPool), which can >> then use more efficient and scalable techniques to request and trigger >> delayed actions, periodic actions, and cancellations, as well as coordinate >> shutdown and termination mechanics (see the internal documentation in >> DelayScheduler.java for algotihmic details). This speeds up some Loom >> operations by almost an order of magnitude (and similarly for >> CompletableFuture). Further incremental improvements may be possible, but >> delay scheduling overhead is now unlikely to be a common performance concern. >> >> We also introduce method submitWithTimeout to schedule a timeout that >> cancels or otherwise completes a submitted task that takes too long. Support >> for this very common usage was missing from the ScheduledExecutorService >> API, and workarounds that users have tried are wasteful, often leaky, and >> error-prone. This cannot be added to the ScheduledExecutorService interface >> because it relies on ForkJoinTask methods (such as completeExceptionally) to >> be available in user-supplied timeout actions. The need to allow a pluggable >> handler reflects experience with the similar CompletableFuture.orTimeout, >> which users have found not to be flexible enough, so might be subject of >> future improvements. >> >> A DelayScheduler is optionally (on first use of a scheduling method) >> constructed and started as part of a ForkJoinPool, not any other kind of >> ExecutorService. It doesn't make sense to do so with the other j.u.c pool >> implementation ThreadPoolExecutor. ScheduledThreadPoolExecutor already >> extends it in incompatible ways (which is why we can't just improve or >> replace STPE internals). However, as discussed in internal documentation, >> the implementation isolates calls and callbacks in a way that could be >> extracted out into (package-private) interfaces if another j.u.c pool type >> is introduced. >> >> Only one of the policy controls in ScheduledThreadPoolExecutor applies to >> ForkJoinPools with DelaySchedulers: new method cancelDelayedTasksOnShutdown >> controls whether quiescent shutdown sh... > > Doug Lea has updated the pull request incrementally with one additional > commit since the last revision: > > Use TC_MASK in accord with https://bugs.openjdk.org/browse/JDK-8330017 > (Unnecessarily for now.) Not related to delayed task handling performance but related to the TC_MASK cleanup: as noted in the review of the TC masking fix [1], RC is not always masked accurately (though it's harmless), so maybe such cleanup could be made here as well. [1] https://github.com/openjdk/jdk/pull/24034#issuecomment-2729780512 - PR Comment: https://git.openjdk.org/jdk/pull/23702#issuecomment-2736326165
Re: jpackage and Wix 5
I add some context:
I installed wix 5 using the donet command globally,
wix is in the path but when I try to run my jpackage command I get this
error:
jpackage -i ./target --type exe --main-class
org.dpsoftware.JavaFXStarter --main-jar
FireflyLuciferin-jar-with-dependencies.jar --icon
./data/img/luciferin_logo.ico
--win-menu --win-menu-group Ambilight --copyright "Davide Perini"
--name "Firefly Luciferin" --vendor DPsoftware --win-dir-chooser
--win-shortcut --win-per-user-install --win-shortcut
--win-shortcut-prompt --java-options "-XX:+UseZGC -Xms64m -Xmx1024m"
java.io.IOException: Command [wix.exe, build, -nologo, -pdbtype, none,
-intermediatefolder,
C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\wixobj,
-ext, WixToolset.Util.wixext, -arch, x64, -ext, WixToolset.UI
.wixext, -b,
C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config,
-loc,
C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config\MsiInstallerStrings_de.wxl,
-loc, C:\Users\SBLANT~1\AppData\
Local\Temp\jdk.jpackage95160440034084538\config\MsiInstallerStrings_en.wxl,
-loc,
C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config\MsiInstallerStrings_ja.wxl,
-loc, C:\Users\SBLANT~1\AppData\Local\Temp\j
dk.jpackage95160440034084538\config\MsiInstallerStrings_zh_CN.wxl,
-culture, en-us, -d, JpAppDescription=Firefly Luciferin, -d,
JpStartMenuShortcutPrompt=yes, -d, JpDesktopShortcutPrompt=yes, -d,
JpProductCode=e0be8901-8911-3da4
-83e2-2c15892e1623, -d, JpAppName=Firefly Luciferin, -d,
JpAllowDowngrades=yes, -d,
JpIcon=C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\images\win-msi.image\Firefly
Luciferin\Firefly Luciferin.exe, -d, JpAp
pSizeKb=409283, -d, JpAppVersion=1.0, -d,
JpAfterInstallDirDlg=ShortcutPromptDlg, -d, JpAllowUpgrades=yes, -d,
JpProductUpgradeCode=2b8902a1-d85a-3650-9b08-d990b365e5e9, -d,
JpAppVendor=DPsoftware, -d, JpConfigDir=C:\Users\SBLAN
T~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config,
C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config\main.wxs,
C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config\bundle.wx
f,
C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config\ui.wxf,
C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\config\ShortcutPromptDlg.wxs,
C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpack
age95160440034084538\config\InstallDirNotEmptyDlg.wxs, -out,
C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\wixobj\a.msi]
in
C:\Users\SBLANT~1\AppData\Local\Temp\jdk.jpackage95160440034084538\images\win-msi.image\Firefly
Luciferin exited with 144 code
Il 19/03/2025 10:12, Davide Perini ha scritto:
Hi there,
I'm using jpackage along with Wix3.
The command I use to generate my .exe is:
jpackage -i ../../target --type exe --main-class
org.dpsoftware.JavaFXStarter --main-jar
FireflyLuciferin-jar-with-dependencies.jar --icon
../../data/img/java_fast_screen_capture_logo.ico --win-menu
--win-menu-group Luciferin --copyright "Davide Perini" --name "Firefly
Luciferin" --vendor DPsoftware --win-dir-chooser --win-shortcut
--win-per-user-install --win-upgrade-uuid myuuid --app-version
"${{steps.get-id.outputs.id}}" --win-shortcut --win-shortcut-prompt
--java-options "-XX:+UseZGC -XX:+UseStringDeduplication -Xms64m
-Xmx1024m --add-modules=jdk.incubator.vector"
How can I move it to Wix5 using Java 24?
Is there a guide/documentation that help in migrating from Wix 3 to Wix 5?
Thanks
Davide
Re: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v7]
> Implement JEP 502. > > The PR passes tier1-tier3 tests. Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 249 commits: - Fix comments on doc issues - Create separate reentry prevention method and add tests - Merge branch 'master' into implement-jep502 - Merge branch 'master' into implement-jep502 - Clean up exception messages and fix comments - Rename field - Rename method and fix comment - Rework reenterant logic - Use acquire semantics for reading rather than volatile semantics - Add missing null check - ... and 239 more: https://git.openjdk.org/jdk/compare/fcc2a242...4c0dadfb - Changes: https://git.openjdk.org/jdk/pull/23972/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23972&range=06 Stats: 4050 lines in 30 files changed: 4019 ins; 18 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/23972.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23972/head:pull/23972 PR: https://git.openjdk.org/jdk/pull/23972
Re: RFR: 8351565: Implement JEP 502: Stable Values (Preview) [v6]
On Thu, 13 Mar 2025 15:49:37 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/java/lang/StableValue.java line 45: >> >>> 43: >>> 44: /** >>> 45: * A stable value is a shallowly immutable holder of deferred content. >> >> Is this terminology a leftover from previous JEP iterations? The JEP now >> says: >>> stable values, which are objects that hold immutable data. > > Maybe: `A stable value in an holder for shallowly immutable content`. I've updated the text. Let me know what you think - PR Review Comment: https://git.openjdk.org/jdk/pull/23972#discussion_r2004617953
Re: RFR: 8352016: Improve java/lang/RuntimeTests/RuntimeExitLogTest.java
On Fri, 14 Mar 2025 09:17:06 GMT, KIRIYAMA Takuya wrote:
> The current test program for the logging feature added in JDK-8301627 does
> not fully check some important cases.
>
> Issue Details:
> The test does not properly check cases where logging might not happen due to
> different logging levels. (e.g. ALL, TRACE, WARNING, etc.)
> The check for the logged stack trace is not enough, as it does not confirm
> enough details in the output.
>
> Fix Details:
> Added more test cases to check behavior under different logging levels.
> Improved the stack trace check by verifying more details in the logged output.
> These changes make the test more complete and ensure that the logging feature
> works as expected.
> Also, any existing test cases prior to this pull request are retained.
>
> The test was verified in the following OS environments, and it passed
> successfully in both environments.
> - Windows Server 2022 Standard 21H2
> - Red Hat Enterprise Linux release 9.2 (Plow)
>
> Could you please review this fix?
Out of curiosity, what raised this as an issue that needed more tests?
Was there a failure of some implementation that caused a bug?
test/jdk/java/lang/RuntimeTests/ExitLogging-FINE.properties line 2:
> 1:
> 2: # java.lang. Runtime logging level to console to FINE
Extra space before Runtime.
Please fix in all .properties files.
test/jdk/java/lang/RuntimeTests/ExitLogging-FINER.properties line 8:
> 6:
> 7: java.util.logging.ConsoleHandler.level = ALL
> 8: java.lang.Runtime.level = FINER
It is a waste of resources to test every combination of logger levels.
This is not a test of the filtering mechanism built into the logger; it is a
test that the message is logged when the logger level is set to DEBUG or finer.
Only two test cases are needed for that.
test/jdk/java/lang/RuntimeTests/RuntimeExitLogTest.java line 78:
> 76: "java\\.lang\\.Throwable: Runtime\\.exit\\(" + status +
> "\\)\\n" +
> 77: "\\s+at
> java\\.base/java\\.lang\\.Shutdown\\.logRuntimeExit\\(Shutdown\\.java:\\d+\\)\\n"
> +
> 78: "\\s+at(?: .+)";
Testing the exact logging message is too brittle/too exact.
It should only be testing for the specific variable information that is unique
to the case under test.
It becomes burdensome to update tests when some small change occurs in a
message.
-
PR Comment: https://git.openjdk.org/jdk/pull/24050#issuecomment-2737976829
PR Review Comment: https://git.openjdk.org/jdk/pull/24050#discussion_r2004182051
PR Review Comment: https://git.openjdk.org/jdk/pull/24050#discussion_r2004204027
PR Review Comment: https://git.openjdk.org/jdk/pull/24050#discussion_r2004191748
Re: RFR: 8351996: Behavioral updates for ClassValue::remove [v2]
> The recent patch #23866 makes calling `ClassValue::remove()` from > `ClassValue::computeValue()` end up in infinite loops while fixing the stale > value risk from the method. > > The proposed fix is to preserve the stale value risk fix, and update the > remove-from-compute behavior from the original designated no-op behavior to > throwing an exception, as the original behavior conflicts with the stale > value fix. > > The implementation track the owner thread in promises (accessed in locked > section); as a result, we can fail-fast on recursive removals from > `computeValue`. I did not choose to use `ThreadTracker` as it is designed for > single tracker and multiple threads, while this case here sees often just one > thread, and the threads outlive the promise objects. > > Also updated the API specs for `remove` to more concisely describe the memory > effects. Please review the associated CSR as well. Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Use identity of thread, some optimizations for single thread case - Merge branch 'master' of https://github.com/openjdk/jdk into fix/classvalue-compute-remove - Track threads on the promise for cheap reentrancy checks - 8351996: Alternative way to ensure no stale values for ClassValue::remove - Changes: - all: https://git.openjdk.org/jdk/pull/24043/files - new: https://git.openjdk.org/jdk/pull/24043/files/70bf2368..74851320 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24043&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24043&range=00-01 Stats: 14260 lines in 293 files changed: 7595 ins; 4232 del; 2433 mod Patch: https://git.openjdk.org/jdk/pull/24043.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24043/head:pull/24043 PR: https://git.openjdk.org/jdk/pull/24043
Re: RFR: 8352276: Skip jtreg tests using native executable with libjvm.so/libjli.so dependencies on static JDK
On Wed, 19 Mar 2025 09:20:33 GMT, Alan Bateman wrote: > can't rule anything in or out right now +1 @AlanBateman @dholmes-ora Does it look reasonable to not run these tests on static JDK for now? - PR Comment: https://git.openjdk.org/jdk/pull/24103#issuecomment-2738148828
Re: RFR: 8352176: Automate setting up environment for mac signing tests
On Mon, 17 Mar 2025 19:51:36 GMT, Alexey Semenyuk wrote:
> Automate setting up an environment for mac signing tests: create keychain(s),
> self-signing certificates, and register them in the system.
>
> To set up the environment, run `make test-only
> TEST=test/jdk/tools/jpackage/macosx/base/SigningBase.java
> JTREG=JAVA_OPTIONS=-Djpackage.test.SignEnv=setup` command.
>
> The above command will create "jpackagerTest.keychain" keychain, one private
> RSA key, and four self-signed certificates using this key:
> | Certificate common name (CN) | Usage |
> |--|-|
> | Developer ID Application: jpackage.openjdk.java.net|Code sign|
> | Developer ID Installer: jpackage.openjdk.java.net|.pkg sign|
> | Developer ID Application: jpackage.openjdk.java.net (ö)|Code sign|
> | Developer ID Installer: jpackage.openjdk.java.net (ö)|.pkg sign|
>
> Certificates will be added to the list of trusted certificates using a
> sequence of `security add-trusted-cert...` commands (one command per
> certificate). This step will require user interaction to enter the user
> account password as many times as the number of created certificates (four).
> A user will be presented with the "Trust certificate" dialog describing which
> certificate is about to be added to the list of trusted certificates before
> the dialog prompting the user password pops up:
> src="https://github.com/user-attachments/assets/a67d0966-2dea-4bc6-93a6-f52dad599898";
> />
>
> When the user presses the "OK" button on the "Trust certificate" dialog, the
> dialog prompting the user password will pop up:
> src="https://github.com/user-attachments/assets/1d1f022d-54ac-4a7e-8d0a-9bfe65c76b49";
> />
>
> Suppose the user presses the "Cancel" button on the "Trust certificate"
> dialog. In that case, the dialog prompting the user password will NOT pop up,
> and the whole sequence of adding certificates to the list of trusted
> certificates will abort.
>
> If the user presses the "Cancel" button on the dialog prompting the user
> password, it will be dismissed, and the user will start over with the same
> "Trust certificate" dialog.
>
> Every "Trust certificate" dialog has a one-minute timeout. If the dialog is
> automatically dismissed because of the timeout expiration, adding
> certificates to the list of trusted certificates will abort.
>
> To tear down the environment, run `make test-only
> TEST=test/jdk/tools/jpackage/macosx/base/SigningBase.java
> JTREG=JAVA_OPTIONS=-Djpackage.test.SignEnv=teardown` command. This command
> will unlink and delete...
test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacSign.java line 336:
> 334:
> 335: private String validatedName() {
> 336: return
> Optional.ofNullable(name).orElse("jpackagerTest.keychain");
`jpackagerTest.keychain` -> `jpackageTest.keychain`. Without 'r'.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/24087#discussion_r2004661374
RFR: 8352437: -XX:+AOTClassLinking is not compatible with --add-export
`-XX:+AOTClassLinking` requires the CDS archived full module graph (FMG). - Before this PR, when `--add-export` is specified, FMG is disabled, so AOT caches created with `-XX:+AOTClassLinking` cannot be loaded. - After this PR, if the exact same `--add-export` flags as specified across the training/assembly/production phases, the FMG can be used, so we can use so AOT caches created with `-XX:+AOTClassLinking`. The change itself is straight-forward: just remember the `--add-export` flags specified during AOT cache creation, and check the exact same ones are used during the production run. I did a fair amount of refactoring to change the "exact options specified" checks in modules.cpp, so more such options can be easily added in the future (we need to handle `--add-reads` and `--add-opens` in future RFEs). (Note: this PR depends on #24122 ) - Depends on: https://git.openjdk.org/jdk/pull/24122 Commit messages: - Fixed whitespaces - clean up - 8352437: -XX:+AOTClassLinking is not compatible with --add-export Changes: https://git.openjdk.org/jdk/pull/24124/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24124&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8352437 Stats: 575 lines in 16 files changed: 457 ins; 65 del; 53 mod Patch: https://git.openjdk.org/jdk/pull/24124.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24124/head:pull/24124 PR: https://git.openjdk.org/jdk/pull/24124
Re: RFR: 8351933: Inaccurate masking of TC subfield decrement in ForkJoinPool [v2]
On Tue, 18 Mar 2025 09:11:00 GMT, Dmitry Chuyko wrote: >> Please review a tiny fix in the ForkJoinPool. Since JDK 9 (JDK-8134852 [1]) >> in one case when TC subfield in ctl field is decremented, the applied >> masking (UMASK, upper bits) may not preserve neighbor RC subfield sometimes. >> In JDKs prior to 19 FJP may stop executing tasks, which requires a long >> running application restart [2]. Since 19 it is even harder to reproduce >> because of the separate parallelism field. >> >> The fix is to replace 'UMASK & (c - TC_UNIT)' with '(c & RC_MASK) | ((c - >> TC_UNIT) & TC_MASK)' which preserves the RC part of the compareAndSetCtl() >> candidate argument. On 17u and 11u that repairs known tests and >> applications. This PR is for the mainline, and I intend to backport it to >> 21u, 17u and 11u. >> >> [1] https://bugs.openjdk.org/browse/JDK-8134852 >> [2] https://bugs.openjdk.org/browse/JDK-8330017 > > Dmitry Chuyko has updated the pull request incrementally with one additional > commit since the last revision: > > Aligned with JDK-8319447 Marked as reviewed by alanb (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/24034#pullrequestreview-2698006904
Integrated: 8351933: Inaccurate masking of TC subfield decrement in ForkJoinPool
On Thu, 13 Mar 2025 13:34:51 GMT, Dmitry Chuyko wrote: > Please review a tiny fix in the ForkJoinPool. Since JDK 9 (JDK-8134852 [1]) > in one case when TC subfield in ctl field is decremented, the applied masking > (UMASK, upper bits) may not preserve neighbor RC subfield sometimes. In JDKs > prior to 19 FJP may stop executing tasks, which requires a long running > application restart [2]. Since 19 it is even harder to reproduce because of > the separate parallelism field. > > The fix is to replace 'UMASK & (c - TC_UNIT)' with '(c & RC_MASK) | ((c - > TC_UNIT) & TC_MASK)' which preserves the RC part of the compareAndSetCtl() > candidate argument. On 17u and 11u that repairs known tests and applications. > This PR is for the mainline, and I intend to backport it to 21u, 17u and 11u. > > [1] https://bugs.openjdk.org/browse/JDK-8134852 > [2] https://bugs.openjdk.org/browse/JDK-8330017 This pull request has now been integrated. Changeset: fed34e46 Author:Dmitry Chuyko URL: https://git.openjdk.org/jdk/commit/fed34e46b89bc9b0462d9b5f5e5ab5516fe18c6e Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8351933: Inaccurate masking of TC subfield decrement in ForkJoinPool Reviewed-by: dl, alanb, liach - PR: https://git.openjdk.org/jdk/pull/24034
Re: RFR: 8351933: Inaccurate masking of TC subfield decrement in ForkJoinPool [v2]
On Tue, 18 Mar 2025 09:11:00 GMT, Dmitry Chuyko wrote: >> Please review a tiny fix in the ForkJoinPool. Since JDK 9 (JDK-8134852 [1]) >> in one case when TC subfield in ctl field is decremented, the applied >> masking (UMASK, upper bits) may not preserve neighbor RC subfield sometimes. >> In JDKs prior to 19 FJP may stop executing tasks, which requires a long >> running application restart [2]. Since 19 it is even harder to reproduce >> because of the separate parallelism field. >> >> The fix is to replace 'UMASK & (c - TC_UNIT)' with '(c & RC_MASK) | ((c - >> TC_UNIT) & TC_MASK)' which preserves the RC part of the compareAndSetCtl() >> candidate argument. On 17u and 11u that repairs known tests and >> applications. This PR is for the mainline, and I intend to backport it to >> 21u, 17u and 11u. >> >> [1] https://bugs.openjdk.org/browse/JDK-8134852 >> [2] https://bugs.openjdk.org/browse/JDK-8330017 > > Dmitry Chuyko has updated the pull request incrementally with one additional > commit since the last revision: > > Aligned with JDK-8319447 Thanks for reviews! - PR Comment: https://git.openjdk.org/jdk/pull/24034#issuecomment-2736311757
RFR: 8351843: change open/test/jdk/com/sun/net/httpserver/simpleserver/RootDirPermissionsTest.java to a manual test
8351843: change open/test/jdk/com/sun/net/httpserver/simpleserver/RootDirPermissionsTest.java to a manual test - Commit messages: - 8351843:change open/test/jdk/com/sun/net/httpserver/simpleserver/RootDirPermissionsTest.java to a manual test Changes: https://git.openjdk.org/jdk/pull/24113/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24113&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351843 Stats: 4 lines in 2 files changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/24113.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24113/head:pull/24113 PR: https://git.openjdk.org/jdk/pull/24113
Re: RFR: 8342486: Implement JEP draft: Structured Concurrency (Fifth Preview) [v6]
> Changes for [JEP draft: Structured Concurrency (Fifth > Preview)](https://openjdk.org/jeps/8340343). The JEP isn't on the technical > roadmap yet. The proposal is to re-preview the API with some changes, > specifically: > > - A > [StructuredTaskScope](https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html) > is now opened with a static factory method instead of a constructor. Once > opened, the API usage is unchanged: fork subtasks individually, join them as > a unit, process outcome, and close. > - In conjunction with moving to using a static open method, policy and > desired outcome is now selected by specifying a Joiner to the open method > rather than extending STS. A Joiner handles subtask completion and produces > the result for join to return. Joiner.onComplete is the equivalent of > overriding handleComplete previously. This change means that the subclasses > ShutdownOnFailure and ShutdownOnSuccess are removed, replaced by factory > methods on Joiner to get an equivalent Joiner. > - The join method is changed to return the result or throw > STS.FailedException, replacing the need for an API in subclasses to obtain > the outcome. This removes the hazard that was forgetting to call > throwIfFailed to propagate exceptions. > - Configuration that was provided with parameters for the constructor is > changed so that can be provided by a configuration function. > - joinUntil is replaced by allowing a timeout be configured by the > configuration function. This allows the timeout to apply the scope rather > than the join method. > > The underlying implementation is unchanged except that ThreadFlock.shutdown > and wakeup methods are no longer confined. The STS API implementation moves > to non-public StructuedTaskScopeImpl because STS is now an interface. A > non-public Joiners class is added with the built-in Joiner implementations. Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - Sync up from loom repo - Merge branch 'master' into JDK-8342486 - Merge branch 'master' into JDK-8342486 - Fix link - Merge branch 'master' into JDK-8342486 - Sync up impl/tests form loom repo - Merge branch 'master' into JDK-8342486 - Pull latest API docs + impl from loom repo - Merge branch 'master' into JDK-8342486 - Sync up from loom repo - ... and 1 more: https://git.openjdk.org/jdk/compare/38499b3f...92827f9a - Changes: https://git.openjdk.org/jdk/pull/21934/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21934&range=05 Stats: 4080 lines in 14 files changed: 1874 ins; 1458 del; 748 mod Patch: https://git.openjdk.org/jdk/pull/21934.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21934/head:pull/21934 PR: https://git.openjdk.org/jdk/pull/21934
Re: RFR: 8352044: Add --with-import-jvms to configure
On Tue, 18 Mar 2025 12:31:27 GMT, Magnus Ihse Bursie wrote: > And to be absolutely clear: this PR is just about adding new functionality > that was not present before. Sure but I think it's also an attractive nuisance. The VM is very tightly coupled to java.base and a few other core modules. I don't think the build should be supporting grabbing libjvm from another build or another location. Point taken that tools to build and test the JDK need to come from somewhere but it's not as tightly coupled as we have with the proposal here. For the folks targeting embedded/small environments then I think the right thing is to publish the packaged modules (JMOD files) for the target platform and then use `jlink` to create the run-image with the right VM + small set of modules that are appropriate for the target environment. - PR Comment: https://git.openjdk.org/jdk/pull/24063#issuecomment-2735829450
jpackage and Wix 5
Hi there,
I'm using jpackage along with Wix3.
The command I use to generate my .exe is:
jpackage -i ../../target --type exe --main-class
org.dpsoftware.JavaFXStarter --main-jar
FireflyLuciferin-jar-with-dependencies.jar --icon
../../data/img/java_fast_screen_capture_logo.ico --win-menu
--win-menu-group Luciferin --copyright "Davide Perini" --name "Firefly
Luciferin" --vendor DPsoftware --win-dir-chooser --win-shortcut
--win-per-user-install --win-upgrade-uuid myuuid --app-version
"${{steps.get-id.outputs.id}}" --win-shortcut --win-shortcut-prompt
--java-options "-XX:+UseZGC -XX:+UseStringDeduplication -Xms64m
-Xmx1024m --add-modules=jdk.incubator.vector"
How can I move it to Wix5 using Java 24?
Is there a guide/documentation that help in migrating from Wix 3 to Wix
5?
Thanks
Davide
Re: RFR: 8342382: Implementation of JEP G1: Improve Application Throughput with a More Efficient Write-Barrier [v25]
> Hi all, > > please review this change that implements (currently Draft) JEP: G1: > Improve Application Throughput with a More Efficient Write-Barrier. > > The reason for posting this early is that this is a large change, and the JEP > process is already taking very long with no end in sight but we would like to > have this ready by JDK 25. > > ### Current situation > > With this change, G1 will reduce the post write barrier to much more resemble > Parallel GC's as described in the JEP. The reason is that G1 lacks in > throughput compared to Parallel/Serial GC due to larger barrier. > > The main reason for the current barrier is how g1 implements concurrent > refinement: > * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers > (dirty card queues - dcq) containing the location of dirtied cards. > Refinement threads pick up their contents to re-refine. The barrier needs to > enqueue card locations. > * For correctness dirty card updates requires fine-grained synchronization > between mutator and refinement threads, > * Finally there is generic code to avoid dirtying cards altogether (filters), > to avoid executing the synchronization and the enqueuing as much as possible. > > These tasks require the current barrier to look as follows for an assignment > `x.a = y` in pseudo code: > > > // Filtering > if (region(@x.a) == region(y)) goto done; // same region check > if (y == null) goto done; // null value check > if (card(@x.a) == young_card) goto done; // write to young gen check > StoreLoad;// synchronize > if (card(@x.a) == dirty_card) goto done; > > *card(@x.a) = dirty > > // Card tracking > enqueue(card-address(@x.a)) into thread-local-dcq; > if (thread-local-dcq is not full) goto done; > > call runtime to move thread-local-dcq into dcqs > > done: > > > Overall this post-write barrier alone is in the range of 40-50 total > instructions, compared to three or four(!) for parallel and serial gc. > > The large size of the inlined barrier not only has a large code footprint, > but also prevents some compiler optimizations like loop unrolling or inlining. > > There are several papers showing that this barrier alone can decrease > throughput by 10-20% > ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is > corroborated by some benchmarks (see links). > > The main idea for this change is to not use fine-grained synchronization > between refinement and mutator threads, but coarse grained based on > atomically switching card tables. Mutators only work on the "primary" card > table, refinement threads on a se... Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: * fix IR code generation tests that change due to barrier cost changes - Changes: - all: https://git.openjdk.org/jdk/pull/23739/files - new: https://git.openjdk.org/jdk/pull/23739/files/c833bc83..f419556e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=24 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=23-24 Stats: 5 lines in 2 files changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/23739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739 PR: https://git.openjdk.org/jdk/pull/23739
Re: RFR: 8352276: Skip jtreg tests using native executable with libjvm.so/libjli.so dependencies on static JDK
On Wed, 19 Mar 2025 02:02:56 GMT, Jiangli Zhou wrote: >> Please review this PR that adds `@requires !jdk.static` to tests, thanks. >> >> - runtime/StackGap/TestStackGap.java >> - runtime/StackGuardPages/TestStackGuardPages.java >> - runtime/TLS/TestTLS.java >> - runtime/jni/daemonDestroy/TestDaemonDestroy.java >> - runtime/jni/getCreatedJavaVMs/TestGetCreatedJavaVMs.java >> - jdk/java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java >> - jdk/jni/nullCaller/NullCallerTest.java >> - jdk/tools/launcher/JniInvocationTest.java >> >> These tests use native executables that have dependencies on `libjvm.so`, >> `libjli.so`, etc. Static JDK does not provide the separate JDK/VM shared >> libraries, hence cannot support the specific testing mode. > > I filed https://bugs.openjdk.org/browse/JDK-8352305. > @jianglizhou shouldn't these native executables be built differently to work > with the static JDK? Otherwise how does a user create a native executable > that launches the JVM? Right now, jlink creating a modular run-time image, can generate a launch script in the image bin directory. If/when support for creating a static image comes then it will generate a native executable that runs the application. Configuration that is provided at launch time may need to be provided at link time. In that world then it's not clear if there is a real need for custom launcher code. As Jiangli says, we haven't discussed this yet, so can't rule anything in or out right now. - PR Comment: https://git.openjdk.org/jdk/pull/24103#issuecomment-2735857307
Re: RFR: 8351565: Implement JEP 502: Stable Values (Preview)
On Sun, 16 Mar 2025 03:30:46 GMT, John Rose wrote: > This might seem to contradict my previous assertion > that StableValue, being mutex based, must not > use lock-free idioms. That comment applies > specifically to the update operation that takes > a lambda. Other operations, such as reading > a SV, or hopefully poking a value at a SV can be, > and should be, composed of lock-free operations. > Why take a lock when it?s just a one-word read > or write? The important thing is that the lambda-accepting operation uses a mutex, so that the lambda (which might be a potentially expensive operation) is only invoked once. While other operations might in principle be lock-free, I'm not completely against pushing a very simple first iteration that is clearly and obviously correct. Once all the tests etc. are in place, it should be possible to improve the implementation further and remove locking where we can? (I think the interplay between the lambda-accepting set and a regular set will make it a bit tricky to go partially lock free) - PR Comment: https://git.openjdk.org/jdk/pull/23972#issuecomment-2737258754
Re: RFR: 8351969: Add Public Identifiers to the JDK built-in Catalog [v3]
On Wed, 19 Mar 2025 00:43:28 GMT, Joe Wang wrote: >> Add public identifiers to the JDK built-in Catalog; Replace the incorrect >> Schema 1.1 DTD files (note the Public Identifier at line 2) with the correct >> Schema 1.0 DTDs. The JDK built-in Catalog contains Schema 1.0 files only. >> >> DTD files: the Schema 1.1 files, XMLSchema.dtd and datatypes.dtd, were >> removed and replaced with those of Schema 1.0. These files were downloaded >> from w3.org without modification. The file names were unfortunately the >> same, which (with the Diffs) made it look like they were modified though >> they were not. > > Joe Wang has updated the pull request incrementally with one additional > commit since the last revision: > > replace JDK Catalog in the java.xml module with public API Thanks all for the reviews! - PR Comment: https://git.openjdk.org/jdk/pull/24039#issuecomment-2737323255
Integrated: 8351969: Add Public Identifiers to the JDK built-in Catalog
On Thu, 13 Mar 2025 19:01:03 GMT, Joe Wang wrote: > Add public identifiers to the JDK built-in Catalog; Replace the incorrect > Schema 1.1 DTD files (note the Public Identifier at line 2) with the correct > Schema 1.0 DTDs. The JDK built-in Catalog contains Schema 1.0 files only. > > DTD files: the Schema 1.1 files, XMLSchema.dtd and datatypes.dtd, were > removed and replaced with those of Schema 1.0. These files were downloaded > from w3.org without modification. The file names were unfortunately the same, > which (with the Diffs) made it look like they were modified though they were > not. This pull request has now been integrated. Changeset: 8e999b83 Author:Joe Wang URL: https://git.openjdk.org/jdk/commit/8e999b83a42a163800a5895268943e7077a4b7cc Stats: 285 lines in 4 files changed: 51 ins; 142 del; 92 mod 8351969: Add Public Identifiers to the JDK built-in Catalog Reviewed-by: rriggs, lancea, iris, naoto - PR: https://git.openjdk.org/jdk/pull/24039
Re: RFR: 8346948: Update CLDR to Version 47.0 [v2]
> Upgrading the CLDR to version 47.0. A corresponding CSR has also been drafted. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Copyright year/bugid update - Changes: - all: https://git.openjdk.org/jdk/pull/24120/files - new: https://git.openjdk.org/jdk/pull/24120/files/3606a05e..03863f07 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24120&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24120&range=00-01 Stats: 4 lines in 3 files changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/24120.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24120/head:pull/24120 PR: https://git.openjdk.org/jdk/pull/24120
Re: RFR: 8352044: Add --with-import-jvms to configure
On Wed, 19 Mar 2025 09:11:05 GMT, Alan Bateman wrote: > For the folks targeting embedded/small environments then I think the right > thing is to publish the packaged modules (JMOD files) for the target platform > and then use `jlink` to create the run-image with the right VM + small set of > modules that are appropriate for the target environment. Just to make sure I'm understanding you correctly. Are you proposing that instead of building a single JDK distribution with multiple JVMs, they would build a separate JDK for each alternative JVM configuration and publish java.base.jmod from each of them for end users to pick from when generating their run-images? - PR Comment: https://git.openjdk.org/jdk/pull/24063#issuecomment-2736507794
Re: RFR: 8342382: Implementation of JEP G1: Improve Application Throughput with a More Efficient Write-Barrier [v25]
On Wed, 19 Mar 2025 13:17:19 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that implements (currently Draft) JEP: G1: >> Improve Application Throughput with a More Efficient Write-Barrier. >> >> The reason for posting this early is that this is a large change, and the >> JEP process is already taking very long with no end in sight but we would >> like to have this ready by JDK 25. >> >> ### Current situation >> >> With this change, G1 will reduce the post write barrier to much more >> resemble Parallel GC's as described in the JEP. The reason is that G1 lacks >> in throughput compared to Parallel/Serial GC due to larger barrier. >> >> The main reason for the current barrier is how g1 implements concurrent >> refinement: >> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of >> buffers (dirty card queues - dcq) containing the location of dirtied cards. >> Refinement threads pick up their contents to re-refine. The barrier needs to >> enqueue card locations. >> * For correctness dirty card updates requires fine-grained synchronization >> between mutator and refinement threads, >> * Finally there is generic code to avoid dirtying cards altogether >> (filters), to avoid executing the synchronization and the enqueuing as much >> as possible. >> >> These tasks require the current barrier to look as follows for an assignment >> `x.a = y` in pseudo code: >> >> >> // Filtering >> if (region(@x.a) == region(y)) goto done; // same region check >> if (y == null) goto done; // null value check >> if (card(@x.a) == young_card) goto done; // write to young gen check >> StoreLoad;// synchronize >> if (card(@x.a) == dirty_card) goto done; >> >> *card(@x.a) = dirty >> >> // Card tracking >> enqueue(card-address(@x.a)) into thread-local-dcq; >> if (thread-local-dcq is not full) goto done; >> >> call runtime to move thread-local-dcq into dcqs >> >> done: >> >> >> Overall this post-write barrier alone is in the range of 40-50 total >> instructions, compared to three or four(!) for parallel and serial gc. >> >> The large size of the inlined barrier not only has a large code footprint, >> but also prevents some compiler optimizations like loop unrolling or >> inlining. >> >> There are several papers showing that this barrier alone can decrease >> throughput by 10-20% >> ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is >> corroborated by some benchmarks (see links). >> >> The main idea for this change is to not use fine-grained synchronization >> between refinement and mutator threads, but coarse grained based on >> atomically switching c... > > Thomas Schatzl has updated the pull request incrementally with one additional > commit since the last revision: > > * fix IR code generation tests that change due to barrier cost changes Commit https://github.com/openjdk/jdk/pull/23739/commits/f419556e9177ecf9fbf22e606dd6c1b850f4330f fixes the failing compiler tests that check whether the compiler emits the correct object graph. Occurs after merging with mainline that significantly reduces total barrier cost calculation. - PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-2736639357
