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
> Shema 1.0 DTDs.
Thanks for review. Updated the test.
-
PR Comment: https:
Hey Stuart,
Thanks for the response. Just to confirm, you are saying that IO.println
would have a method that takes in StringTemplates? Or is it a case of
calling join on our tenplates, and the IO API remains unchanged?
Either way, StringTemplates are going to have a rippling effect on the Java
e
On Fri, 14 Mar 2025 18:31:38 GMT, Roger Riggs wrote:
> Cleanup the single use of JavaLangAccess.exit() it is no longer necessary;
> System.exit() can be called directly.
Marked as reviewed by liach (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/24066#pullrequestreview-2
On Fri, 14 Mar 2025 17:58:50 GMT, Magnus Ihse Bursie wrote:
>> This change copies `libjvm.so` _and_ sibling `.jsa` files, right?
>>
>> If so, then one thing is missing: regenerating CDS archives that have
>> opinions on `modules` filesizes/dates for fingerprinting their CDS archives.
>> My fra
On Fri, 14 Mar 2025 18:31:38 GMT, Roger Riggs wrote:
> Cleanup the single use of JavaLangAccess.exit() it is no longer necessary;
> System.exit() can be called directly.
There are other non-recoverable errors that occur in the runtime that throw
InternalError or AssertionError instead of calli
On Fri, 14 Mar 2025 18:31:38 GMT, Roger Riggs wrote:
> Cleanup the single use of JavaLangAccess.exit() it is no longer necessary;
> System.exit() can be called directly.
Looks fine.
-
Marked as reviewed by rgiulietti (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/24066#p
On Fri, 14 Mar 2025 17:57:31 GMT, Magnus Ihse Bursie wrote:
> No, it doesn't -- only libjvm.so. .jsa files complicate the situation. Hm.
Aha. Importing CDS archives without regenerating them is futile, IIRC: they
would never load properly, CDS would get disabled, and we would just carry dead
w
On Fri, 14 Mar 2025 16:32:39 GMT, Aleksey Shipilev wrote:
> This change copies `libjvm.so` _and_ sibling `.jsa` files, right?
No, it doesn't -- only libjvm.so. .jsa files complicate the situation. Hm.
Maybe we should point to an import JVM directory, and copy it with all its
files, and not jus
On Fri, 14 Mar 2025 15:41:56 GMT, Joachim Kern wrote:
> After "JDK-8339480: Build static-jdk image with a statically linked launcher"
> AIX was not able to build the new target. Therefore with "JDK-8345590 AIX
> 'make all' fails after JDK-8339480" the new target was disabled again.
>
> Now wit
> 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
On Fri, 14 Mar 2025 15:49:44 GMT, Magnus Ihse Bursie wrote:
> We should allow pre-built JVMs to be included in a build, so they are just
> copied into place, and the jvm.cfg file properly updated.
This change copies `libjvm.so` _and_ sibling `.jsa` files, right?
If so, then one thing is missin
We should allow pre-built JVMs to be included in a build, so they are just
copied into place, and the jvm.cfg file properly updated.
-
Commit messages:
- 8352044: Add --with-import-jvms to configure
Changes: https://git.openjdk.org/jdk/pull/24063/files
Webrev: https://webrevs.ope
After "JDK-8339480: Build static-jdk image with a statically linked launcher"
AIX was not able to build the new target. Therefore with "JDK-8345590 AIX 'make
all' fails after JDK-8339480" the new target was disabled again.
Now with this change we can enable the statically linked launcher target
On Fri, 14 Mar 2025 13:55:26 GMT, Magnus Ihse Bursie wrote:
>> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JRTArchive.java line
>> 226:
>>
>>> 224: if (Files.exists(strippedPath)) {
>>> 225: path = strippedPath;
>>> 226:
> 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
On Fri, 14 Mar 2025 13:38:51 GMT, Alan Bateman wrote:
>> Alternative approach to #24012
>>
>> This keeps the current handling of *.pdb vs *.stripped.pdb which allows
>> debugging at the cost of a little hack in jlink. Maybe the code in jlink can
>> be improved, e.g. make it more conditional.
>
On Fri, 14 Mar 2025 12:29:22 GMT, Christoph Langer wrote:
> Alternative approach to #24012
>
> This keeps the current handling of *.pdb vs *.stripped.pdb which allows
> debugging at the cost of a little hack in jlink. Maybe the code in jlink can
> be improved, e.g. make it more conditional.
>
On Fri, 14 Mar 2025 11:15:26 GMT, Matthias Baesken wrote:
> On Linux there are some special settings for LIBVERIFY_OPTIMIZATION that are
> most likely not needed any more and could be removed.
> The removal (on Linux) brings the lib optimization level de facto from LOW to
> HIGH.
Example lib s
On Fri, 14 Mar 2025 11:34:08 GMT, Magnus Ihse Bursie wrote:
> What testing have you run?
I put it into our testing queue, this runs jtreg tier 1 - 4 and some more stuff
over the weekend on all our platforms.
-
PR Comment: https://git.openjdk.org/jdk/pull/24054#issuecomment-2724577
Alternative approach to #24012
This keeps the current handling of *.pdb vs *.stripped.pdb which allows
debugging at the cost of a little hack in jlink.
-
Commit messages:
- JDK-8351842
Changes: https://git.openjdk.org/jdk/pull/24057/files
Webrev: https://webrevs.openjdk.org/?rep
The test `testEcoFriendly()` checks if the launcher pollutes the
`LD_LIBRARY_PATH` environment variable.
Because aix and musl intentionally pollute the `LD_LIBRARY_PATH`, it does not
make sense to make this test somehow passing with crude workarounds, which even
do not work in any case. So we sk
On Fri, 14 Mar 2025 11:15:26 GMT, Matthias Baesken wrote:
> On Linux there are some special settings for LIBVERIFY_OPTIMIZATION that are
> most likely not needed any more and could be removed.
> The removal (on Linux) brings the lib optimization level de facto from LOW to
> HIGH.
In addition t
On Fri, 14 Mar 2025 11:15:26 GMT, Matthias Baesken wrote:
> On Linux there are some special settings for LIBVERIFY_OPTIMIZATION that are
> most likely not needed any more and could be removed.
> The removal (on Linux) brings the lib optimization level de facto from LOW to
> HIGH.
What testing
On Linux there are some special settings for LIBVERIFY_OPTIMIZATION that are
most likely not needed any more and could be removed.
The removal (on Linux) brings the lib optimization level de facto from LOW to
HIGH.
-
Commit messages:
- JDK-8352015
Changes: https://git.openjdk.org/
> (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
25 matches
Mail list logo
