On Fri, 31 May 2024 09:01:38 GMT, MaxXing wrote:
> This patch changes the algorithm of `Node::dominates` to make the result more
> precise, and allows the iterators of `ConcurrentHashMap` to be scalar
> replaced.
>
> The previous algorithm will return a conservative result when encountering a
On Wed, 8 May 2024 08:30:39 GMT, Raffaello Giulietti
wrote:
>> Move all random generators mandated in package `java.util.random` and
>> currently implemented in module `jdk.random` to module `java.base`, and
>> remove module `jdk.random`.
>
> Raffaello Giulietti has updated the pull request
On Wed, 5 Jun 2024 04:41:48 GMT, David Alayachew wrote:
> Hey, I'm just curious -- why was the solution to remove an entire module? I
> understand the point of moving the relevant code over to `java.base`, but I
> don't understand why removing the random module made sense.
With the
On Wed, 8 May 2024 08:30:39 GMT, Raffaello Giulietti
wrote:
>> Move all random generators mandated in package `java.util.random` and
>> currently implemented in module `jdk.random` to module `java.base`, and
>> remove module `jdk.random`.
>
> Raffaello Giulietti has updated the pull request
> ### Performance regression of DecimalFormat.format
> From the output of perf, we can see the hottest regions contain atomic
> instructions. But when run with JDK 11, there is no such problem. The reason
> is the removed biased locking.
> The DecimalFormat uses StringBuffer everywhere, and
On Tue, 4 Jun 2024 21:17:43 GMT, Joe Wang wrote:
> Fix a broken link.
This pull request has now been integrated.
Changeset: 9db7c950
Author:Joe Wang
URL:
https://git.openjdk.org/jdk/commit/9db7c950190853513f4c2afa0efa9a4ff72b60d7
Stats: 2 lines in 1 file changed: 0 ins; 0 del;
On Tue, 4 Jun 2024 21:17:43 GMT, Joe Wang wrote:
> Fix a broken link.
Thanks all!
-
PR Comment: https://git.openjdk.org/jdk/pull/19551#issuecomment-2148759156
On Fri, 31 May 2024 14:34:16 GMT, Sonia Zaldana Calles
wrote:
>> Sonia Zaldana Calles has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Decreasing diff size addressing unnecessary changes
>
> Hi all,
>
> I think there's some consensus
On Tue, 4 Jun 2024 19:44:57 GMT, Naoto Sato wrote:
> Also it would be helpful to compare the performance without biased locking in
> JDK11.
If run in JDK11 without biased locking, the performance is as same as run in
current JDK.
-
PR Comment:
On Tue, 4 Jun 2024 02:32:28 GMT, lingjun-cg wrote:
> Run the below benchmark test ,it show the average time of new
> DecimalFormat() increase 18% when compare to jdk 11.
>
> the result with jdk 11:
>
> Benchmark Mode CntScore Error Units
>
> Run the below benchmark test ,it show the average time of new
> DecimalFormat() increase 18% when compare to jdk 11.
>
> the result with jdk 11:
>
> Benchmark Mode CntScore Error Units
> JmhDecimalFormat.testNewOnly avgt 50 248.300 ? 5.158 ns/op
>
On Mon, 3 Jun 2024 17:26:52 GMT, Nizar Benalla wrote:
> Can I please get a review for this small change? The motivation is that javac
> does not recognize `package.html` files.
>
> The conversion was simple, I used a script to rename the files, append "*" on
> the left and remove some HTML
On Tue, 4 Jun 2024 07:47:46 GMT, SendaoYan wrote:
> Hi all,
> This PR several extra empty spaces and extra empty lines in several
> Makefiles. It's trivial fix, no risk.
>
> Thanks.
@altrisi As trivial and low-effort as this seems, this is actually fixing some
technical debt for legacy
On Tue, 4 Jun 2024 09:07:44 GMT, lingjun-cg wrote:
>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic
>> instructions. But when run with JDK 11, there is no such problem. The
>> reason is the removed biased locking.
On Tue, 4 Jun 2024 02:32:28 GMT, lingjun-cg wrote:
> Run the below benchmark test ,it show the average time of new
> DecimalFormat() increase 18% when compare to jdk 11.
>
> the result with jdk 11:
>
> Benchmark Mode CntScore Error Units
>
On Tue, 4 Jun 2024 21:17:43 GMT, Joe Wang wrote:
> Fix a broken link.
Marked as reviewed by naoto (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/19551#pullrequestreview-2097510057
> This test intends to verify the behavior of JdkConsole for the java.base
> module, wrt restoring the echo. The test assumes the internal methods that
> sets/gets the echo status of the platform.
Naoto Sato has updated the pull request with a new target base due to a merge
or a rebase. The
On Tue, 4 Jun 2024 21:17:43 GMT, Joe Wang wrote:
> Fix a broken link.
Marked as reviewed by iris (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/19551#pullrequestreview-2097432388
On Tue, 4 Jun 2024 21:17:43 GMT, Joe Wang wrote:
> Fix a broken link.
Marked as reviewed by lancea (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/19551#pullrequestreview-2097429096
Fix a broken link.
-
Commit messages:
- 8332750: Broken link in CatalogFeatures.html
Changes: https://git.openjdk.org/jdk/pull/19551/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=19551=00
Issue: https://bugs.openjdk.org/browse/JDK-8332750
Stats: 2 lines in 1 file
On Tue, 4 Jun 2024 20:44:30 GMT, Nizar Benalla wrote:
>> This checker checks the values of the `@since` tag found in the
>> documentation comment for an element against the release in which the
>> element first appeared.
>>
>> Real since value of an API element is computed as the oldest
On Mon, 27 May 2024 12:04:20 GMT, Nizar Benalla wrote:
>> This checker checks the values of the `@since` tag found in the
>> documentation comment for an element against the release in which the
>> element first appeared.
>>
>> Real since value of an API element is computed as the oldest
> This checker checks the values of the `@since` tag found in the documentation
> comment for an element against the release in which the element first
> appeared.
>
> Real since value of an API element is computed as the oldest release in which
> the given API element was introduced. That is:
> Please review this PR which handles incorrect CompactNumberFormat integer
> only parsing when there is no suffix.
>
> See the following snippet,
>
>
> var fmt = NumberFormat.getCompactNumberInstance(Locale.US,
> NumberFormat.Style.SHORT)
> fmt.setParseIntegerOnly(true)
> fmt.parse("5K") //
On Tue, 4 Jun 2024 02:32:28 GMT, lingjun-cg wrote:
> Run the below benchmark test ,it show the average time of new
> DecimalFormat() increase 18% when compare to jdk 11.
>
> the result with jdk 11:
>
> Benchmark Mode CntScore Error Units
>
On Tue, 4 Jun 2024 19:41:15 GMT, Doug Lea wrote:
>> src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java
>> line 103:
>>
>>> 101: private static final long serialVersionUID = 8673264195747942595L;
>>> 102:
>>> 103: private static final Object[] EMPTY_ELEMENTDATA
> Improve `java/util/concurrent/CopyOnWriteArrayList` by eliminating needless
> cloning of Object[0] instances. This cloning is intended to prevent callers
> from changing array contents, but many `CopyOnWriteArrayList`s are allocated
> to size zero, or are otherwise maintained empty, so
On Tue, 4 Jun 2024 09:07:44 GMT, lingjun-cg wrote:
>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic
>> instructions. But when run with JDK 11, there is no such problem. The
>> reason is the removed biased locking.
On Tue, 4 Jun 2024 13:03:45 GMT, Viktor Klang wrote:
>> Improve `java/util/concurrent/CopyOnWriteArrayList` by eliminating needless
>> cloning of Object[0] instances. This cloning is intended to prevent callers
>> from changing array contents, but many `CopyOnWriteArrayList`s are allocated
>>
On Tue, 4 Jun 2024 02:32:28 GMT, lingjun-cg wrote:
> Run the below benchmark test ,it show the average time of new
> DecimalFormat() increase 18% when compare to jdk 11.
>
> the result with jdk 11:
>
> Benchmark Mode CntScore Error Units
>
On Tue, 4 Jun 2024 09:07:44 GMT, lingjun-cg wrote:
>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic
>> instructions. But when run with JDK 11, there is no such problem. The
>> reason is the removed biased locking.
> This test intends to verify the behavior of JdkConsole for the java.base
> module, wrt restoring the echo. The test assumes the internal methods that
> sets/gets the echo status of the platform.
Naoto Sato has updated the pull request incrementally with one additional
commit since the last
> This change fixes a zip64 bug in the launcher that is prevent it from reading
> the manifest of jars where the 'relative offset of local header' field in the
> central directory entry is >4GB. As described in APPNOTE.TXT 4.5.3, the
> offset is too large to be stored in the central directory
This change fixes a bug preventing javac from emitting
'compiler.warn.sun.proprietary' diagnostics if `--system` is set to a
non-default value. The diagnostics are currently emitted for values of
`--release`, and for the default value of `--system`.
The is a redo of
> This change overrides mutator methods in the implementation returned by
> `Map.of().entrySet()` to throw `UnsupportedOperationException`.
Liam Miller-Cushon has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated changes
On Mon, 3 Jun 2024 22:32:54 GMT, Justin Lu wrote:
> Please review this PR which handles incorrect CompactNumberFormat integer
> only parsing when there is no suffix.
>
> See the following snippet,
>
>
> var fmt = NumberFormat.getCompactNumberInstance(Locale.US,
> NumberFormat.Style.SHORT)
>
On Fri, 31 May 2024 13:04:03 GMT, David M. Lloyd wrote:
> The new method additions ClassReader.readEntryOrNull(int, Class) and
> ConstantPool.entryByIndex(int, Class) have incorrect since tags; they should
> be `@since 23`.
This pull request has now been integrated.
Changeset: b101dcb6
On Thu, 29 Feb 2024 09:45:35 GMT, Nizar Benalla wrote:
> I added `@since` tags for methods/constructors that do not match the `@since`
> of the enclosing class.
>
> The `write` method already existed in `PrintStream` in earlier versions and
> instances of it could always call this method,
On Tue, 4 Jun 2024 15:17:33 GMT, Daniel Fuchs wrote:
>> HandlersOnComplexResetUpdate and HandlersOnComplexUpdate tests verify that
>> loggers are GC'ed (or not GC'ed) after a reset or an update. For that they
>> poll a ReferenceQueue in a loop. The number of iteration is adjusted
>> according
On Thu, 30 May 2024 13:50:33 GMT, Jan Lahoda wrote:
> Consider these two programs:
>
>
> public class SystemPrint {
> public static void main(String... args) {
> System.err.println("Hello!");
> }
> }
>
> and:
>
> public class IOPrint {
> public static void main(String...
On Sun, 2 Jun 2024 17:41:55 GMT, Alan Bateman wrote:
> (Doing that would of course mean that several existing jlink tests would need
> some changes, either to `@requires` or to remove the checks for the `jmods`
> directory)
I've added a couple of `@requires jlink.packagedModules` (new with
+1 for not deprecating the method that takes Clock. It would give
existing users unnecessary warnings.
Naoto
On 6/4/24 12:17 AM, Stephen Colebourne wrote:
On Mon, 3 Jun 2024 at 22:25, Kurt Alfred Kluever wrote:
It feels a bit strange that you can't pass an `InstantSource` to
On Mon, 3 Jun 2024 19:10:22 GMT, Alan Bateman wrote:
> > Does that proposal sound good?
>
> That table is useful, I think it's right. No change to default behavior. If
> someone configures with --enable-runtime-image then they get a JDK run-time
> image that supports jlink (with some
> Please review this patch which adds a jlink mode to the JDK which doesn't
> need the packaged modules being present. A.k.a run-time image based jlink.
> Fundamentally this patch adds an option to use `jlink` even though your JDK
> install might not come with the packaged modules (directory
On Fri, 31 May 2024 14:34:16 GMT, Sonia Zaldana Calles
wrote:
>> Sonia Zaldana Calles has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Decreasing diff size addressing unnecessary changes
>
> Hi all,
>
> I think there's some consensus
> Hi folks,
>
> This PR aims to fix
> [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581).
>
> I think the regression got introduced in
> [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458).
>
> In the issue linked above,
>
On Tue, 4 Jun 2024 13:17:11 GMT, Thomas Stuefe wrote:
> Curious, why tier 1 to 3 specifically? Is there anything specific in tier 3
> you want to have tested?
I think just prudent to run more tests when touching the launcher as it has
options that aren't tested much in tier1. Shouldn't be an
On Tue, 4 Jun 2024 12:59:54 GMT, Jaikiran Pai wrote:
> I'll file follow up issue(s) and also trigger CI testing of this PR.
Thanks, the regressions fixed here are important to fix. It's unfortunate there
the original changes weren't changes weren't caught by tests. There is a good
test
On Mon, 13 May 2024 20:39:14 GMT, Nizar Benalla wrote:
>> I added `@since` tags for methods/constructors that do not match the
>> `@since` of the enclosing class.
>>
>> The `write` method already existed in `PrintStream` in earlier versions and
>> instances of it could always call this
On Tue, 4 Jun 2024 13:34:30 GMT, Sonia Zaldana Calles
wrote:
>> Hi folks,
>>
>> This PR aims to fix
>> [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581).
>>
>> I think the regression got introduced in
>> [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458).
>>
>> In the
On Tue, 4 Jun 2024 07:47:46 GMT, SendaoYan wrote:
> Hi all,
> This PR several extra empty spaces and extra empty lines in several
> Makefiles. It's trivial fix, no risk.
>
> Thanks.
Thanks for the review.
Thanks all for the review.
-
PR Comment:
On Tue, 4 Jun 2024 07:47:46 GMT, SendaoYan wrote:
> Hi all,
> This PR several extra empty spaces and extra empty lines in several
> Makefiles. It's trivial fix, no risk.
>
> Thanks.
Looks good! Somehow the integrate command did not work.
-
Marked as reviewed by chagedorn
On Thu, 30 May 2024 13:50:33 GMT, Jan Lahoda wrote:
> Consider these two programs:
>
>
> public class SystemPrint {
> public static void main(String... args) {
> System.err.println("Hello!");
> }
> }
>
> and:
>
> public class IOPrint {
> public static void main(String...
On Sat, 1 Jun 2024 05:20:24 GMT, Jaikiran Pai wrote:
>> Daniel Fuchs has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Review feedback: use Reference::refersTo consistently
>
>
> HandlersOnComplexResetUpdate and HandlersOnComplexUpdate tests verify that
> loggers are GC'ed (or not GC'ed) after a reset or an update. For that they
> poll a ReferenceQueue in a loop. The number of iteration is adjusted
> according to the jtreg timeout factor. However, the logic in the
On Tue, 4 Jun 2024 01:07:15 GMT, Alexander Matveev wrote:
>> Alexey Semenyuk has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> EOLs restored
>
> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_de.wxl
>
On Mon, 3 Jun 2024 16:47:20 GMT, jengebr wrote:
> Improve `java/util/concurrent/CopyOnWriteArrayList` by eliminating needless
> cloning of Object[0] instances. This cloning is intended to prevent callers
> from changing array contents, but many `CopyOnWriteArrayList`s are allocated
> to size
On Fri, 31 May 2024 14:34:16 GMT, Sonia Zaldana Calles
wrote:
>> Sonia Zaldana Calles has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Decreasing diff size addressing unnecessary changes
>
> Hi all,
>
> I think there's some consensus
On Tue, 4 Jun 2024 07:47:46 GMT, SendaoYan wrote:
> Hi all,
> This PR several extra empty spaces and extra empty lines in several
> Makefiles. It's trivial fix, no risk.
>
> Thanks.
Marked as reviewed by erikj (Reviewer).
-
PR Review:
On Tue, 4 Jun 2024 12:49:18 GMT, Alexey Semenyuk wrote:
> We already have [JDK-8263466](https://bugs.openjdk.org/browse/JDK-8263466) to
> find the original crash.
Thanks, just making sure the issue that there is an issue tracking it as it's a
bit unsettling that a re-run may be hiding
On Tue, 4 Jun 2024 07:47:46 GMT, SendaoYan wrote:
> Hi all,
> This PR several extra empty spaces and extra empty lines in several
> Makefiles. It's trivial fix, no risk.
>
> Thanks.
> /label build
Thanks.
-
PR Comment:
On Tue, 4 Jun 2024 06:43:12 GMT, Alan Bateman wrote:
> If I read JDK-8269403 correctly then there is an issue somewhere that hasn't
> been diagnosed.
Correct.
> A workaround has been put in to "re-run" when there is a crash, thus hiding
> the issue.
Correct.
> Are there follow-up issues
On Mon, 3 Jun 2024 18:48:48 GMT, Doug Lea wrote:
> The jmh benchmark checks only the empty case, you need to also show lack of
> impact on non-empty cases.
After removing `toArray`, I think this is covered. Can you please confirm?
> Assuming you demonstrate this, it seems basically OK, (Deja
On Fri, 31 May 2024 14:34:16 GMT, Sonia Zaldana Calles
wrote:
> Hi all,
>
> I think there's some consensus that we need some follow up cleanup issues for
> the JNI spec, renaming constants, fixing return codes, etc.
>
> Seeing how that grows the scope of the issue quite a bit, I'd like to
On Fri, 31 May 2024 14:05:07 GMT, Alexey Semenyuk wrote:
> Fix MainClassTest class to use HelloApp.AppOutputVerifier class to run app
> launcher instead of raw Executor. This makes MainClassTest test run app
> launchers with retries. This change addresses the primary issue.
>
> Fix
On Tue, 4 Jun 2024 02:38:51 GMT, Alexander Matveev wrote:
> I assume WiX5 will just work if installed instead of WiX4?
Correct.
> Do you think it will make sense to introduce Wix5 ToolsetType in case if we
> need to do something different between 4 and 5?
They claim WiX5 is backward
On Tue, 4 Jun 2024 02:32:28 GMT, lingjun-cg wrote:
> Run the below benchmark test ,it show the average time of new
> DecimalFormat() increase 18% when compare to jdk 11.
>
> the result with jdk 11:
>
> Benchmark Mode CntScore Error Units
>
On Tue, 4 Jun 2024 09:07:44 GMT, lingjun-cg wrote:
>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic
>> instructions. But when run with JDK 11, there is no such problem. The
>> reason is the removed biased locking.
On Tue, 4 Jun 2024 09:07:44 GMT, lingjun-cg wrote:
>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic
>> instructions. But when run with JDK 11, there is no such problem. The
>> reason is the removed biased locking.
On Mon, 13 May 2024 20:39:14 GMT, Nizar Benalla wrote:
>> I added `@since` tags for methods/constructors that do not match the
>> `@since` of the enclosing class.
>>
>> The `write` method already existed in `PrintStream` in earlier versions and
>> instances of it could always call this
On Mon, 13 May 2024 20:39:14 GMT, Nizar Benalla wrote:
>> I added `@since` tags for methods/constructors that do not match the
>> `@since` of the enclosing class.
>>
>> The `write` method already existed in `PrintStream` in earlier versions and
>> instances of it could always call this
On Mon, 13 May 2024 20:39:14 GMT, Nizar Benalla wrote:
>> I added `@since` tags for methods/constructors that do not match the
>> `@since` of the enclosing class.
>>
>> The `write` method already existed in `PrintStream` in earlier versions and
>> instances of it could always call this
On Mon, 13 May 2024 20:39:14 GMT, Nizar Benalla wrote:
>> I added `@since` tags for methods/constructors that do not match the
>> `@since` of the enclosing class.
>>
>> The `write` method already existed in `PrintStream` in earlier versions and
>> instances of it could always call this
On Mon, 13 May 2024 20:39:14 GMT, Nizar Benalla wrote:
>> I added `@since` tags for methods/constructors that do not match the
>> `@since` of the enclosing class.
>>
>> The `write` method already existed in `PrintStream` in earlier versions and
>> instances of it could always call this
On Mon, 13 May 2024 20:39:14 GMT, Nizar Benalla wrote:
>> I added `@since` tags for methods/constructors that do not match the
>> `@since` of the enclosing class.
>>
>> The `write` method already existed in `PrintStream` in earlier versions and
>> instances of it could always call this
On Mon, 13 May 2024 20:39:14 GMT, Nizar Benalla wrote:
>> I added `@since` tags for methods/constructors that do not match the
>> `@since` of the enclosing class.
>>
>> The `write` method already existed in `PrintStream` in earlier versions and
>> instances of it could always call this
On Mon, 3 Jun 2024 19:10:22 GMT, Alan Bateman wrote:
> I've read through most of the changes now. Overall I think it's looking good,
> just a few terminology and minor points that I'll add as comments.
@AlanBateman I don't see those comments. Should I?
-
PR Comment:
On Mon, 3 Jun 2024 17:28:09 GMT, Severin Gehwolf wrote:
> Please review this PR which adds test support for systemd slices so that bugs
> like [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) can be
> verified. The added test, `SystemdMemoryAwarenessTest` currently passes on
>
Please review this PR which adds test support for systemd slices so that bugs
like [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) can be
verified. The added test, `SystemdMemoryAwarenessTest` currently passes on
cgroups v1 and fails on cgroups v2 due to the way how
On Tue, 4 Jun 2024 09:04:30 GMT, Magnus Ihse Bursie wrote:
> > Does that proposal sound good?
>
> What you basically is saying is that the default value of `packaged-modules`
> should be `! runtime-link-image` (i.e. the inverse)?
Yes. **default** of the `packaged-modules` value being the key.
On Tue, 4 Jun 2024 08:58:38 GMT, lingjun-cg wrote:
> > > > Hi, I think you can add the jmh test case.
> > >
> > >
> > > [#19513
> > > (comment)](https://github.com/openjdk/jdk/pull/19513#issue-2330131051)
> > > already contains the test case.
> >
> >
> > I mean it can be added as a test
> ### Performance regression of DecimalFormat.format
> From the output of perf, we can see the hottest regions contain atomic
> instructions. But when run with JDK 11, there is no such problem. The reason
> is the removed biased locking.
> The DecimalFormat uses StringBuffer everywhere, and
On Mon, 3 Jun 2024 19:10:22 GMT, Alan Bateman wrote:
> Does that proposal sound good?
What you basically is saying is that the default value of `packaged-modules`
should be `! runtime-link-image` (i.e. the inverse)?
-
PR Comment:
On Tue, 4 Jun 2024 07:54:56 GMT, kuaiwei wrote:
> > > Hi, I think you can add the jmh test case.
> >
> >
> > [#19513
> > (comment)](https://github.com/openjdk/jdk/pull/19513#issue-2330131051)
> > already contains the test case.
>
> I mean it can be added as a test case in test/micro and be
On Tue, 4 Jun 2024 02:18:49 GMT, lingjun-cg wrote:
>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic
>> instructions. But when run with JDK 11, there is no such problem. The
>> reason is the removed biased locking.
On Tue, 4 Jun 2024 07:21:15 GMT, kuaiwei wrote:
> Hi, I think you can add the jmh test case.
https://github.com/openjdk/jdk/pull/19513#issue-2330131051 already contains the
test case.
-
PR Comment: https://git.openjdk.org/jdk/pull/19513#issuecomment-2146844849
Hi all,
This PR several extra empty spaces and extra empty lines in several
Makefiles. It's trivial fix, no risk.
Thanks.
-
Commit messages:
- 8333477: Delete extra empty spaces in Makefiles
Changes: https://git.openjdk.org/jdk/pull/19537/files
Webrev:
On Tue, 4 Jun 2024 02:18:49 GMT, lingjun-cg wrote:
>> ### Performance regression of DecimalFormat.format
>> From the output of perf, we can see the hottest regions contain atomic
>> instructions. But when run with JDK 11, there is no such problem. The
>> reason is the removed biased locking.
On Mon, 3 Jun 2024 at 22:25, Kurt Alfred Kluever wrote:
> It feels a bit strange that you can't pass an `InstantSource` to
> `Instant.now(...)`, but you _can_ pass a `Clock` (which of course has a
> "useless" `ZoneId` when creating an `Instant`). Therefore, I'd like to
> propose one of the
On Mon, 3 Jun 2024 14:38:03 GMT, Alexey Semenyuk wrote:
>> I am yet to see anything that actually explains the cause of the `dlerror`
>> crash here ???
>
> @dholmes-ora there is no fix for the cause of the `dlerror` crash in this PR.
> The PR fixes jpackage tests to rerun a launcher if it
90 matches
Mail list logo
