> For many years, concurrency-interest was the mailing list to discuss
> j.u.concurrent and related topics. The mailing list was hosted on a
> server maintained by Prof. Doug Lea. Sadly, the mailing list didn't
> survive an OS upgrade and has been unavailable for some time.
>
> A new mailing li
I appreciate your patience in correcting my misunderstandings; thanks, David.
On Sat, Jun 28, 2025 at 5:53 AM David Holmes wrote:
>
> On 28/06/2025 4:03 am, Pavel Rappo wrote:
> > David,
> >
> > Having re-read your replies multiple times, I think I now understand
&g
ation-interruption is the iterative search for a thread to
notify.
Is my mental model accurate?
[^1]: https://docs.oracle.com/javase/specs/jls/se24/html/jls-17.html#jls-17.2.4
On Fri, Jun 27, 2025 at 1:11 PM Pavel Rappo wrote:
>
> So, Object.wait() guarantees to throw InterruptedException i
So, Object.wait() guarantees to throw InterruptedException if the
interrupt status is set upon entrance, yes? Could this be added to
javadoc?
On Fri, Jun 27, 2025 at 12:59 PM David Holmes wrote:
>
> On 27/06/2025 5:58 pm, Pavel Rappo wrote:
> > David,
> >
> > As you c
.html#jls-17.2.4
On Fri, Jun 27, 2025 at 3:47 AM David Holmes wrote:
>
> Hi Pavel,
>
> On 27/06/2025 8:23 am, Pavel Rappo wrote:
> > Here's an interesting behaviour. A thread that has been blocked in
> > Object.wait is interrupted. But instead of throwing an
>
Here's an interesting behaviour. A thread that has been blocked in
Object.wait is interrupted. But instead of throwing an
InterruptedException, Object.wait returns normally with the thread's
interrupt status set.
This behaviour is not mentioned in javadoc, yet I witnessed it.
Granted, I could only
On Fri, 20 Jun 2025 15:54:49 GMT, Doug Lea wrote:
>> This collects miscellaneous open issues that can be resolved with
>> documentation updates; each indicated by adding JDK issue numbers
>
> Doug Lea has updated the pull request incrementally with one additional
> commit since the last revisio
On Fri, 20 Jun 2025 13:50:08 GMT, Doug Lea wrote:
>> src/java.base/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java
>> line 86:
>>
>>> 84: * }
>>> 85: * // ... and so on
>>> 86: * }}
>>
>> I wonder if this should be convert to a `{@snippet ..}` and have it hand
On Thu, 19 Jun 2025 10:51:35 GMT, Doug Lea wrote:
>> @pavelrappo Indeed, "Reactive Streams" would be better. Perhaps something
>> like this:
>>
>> Suggestion:
>>
>> * fully conform to the Reactive Streams specification.
>
> Thanks; done.
Nit of a nit: would it make sense to also change "reac
On Wed, 18 Jun 2025 17:51:20 GMT, Doug Lea wrote:
> This collects miscellaneous open issues that can be resolved with
> documentation updates; each indicated by adding JDK issue numbers
src/java.base/share/classes/java/util/concurrent/Flow.java line 64:
> 62: * control required in most implem
On Wed, 18 Jun 2025 17:51:20 GMT, Doug Lea wrote:
> This collects miscellaneous open issues that can be resolved with
> documentation updates; each indicated by adding JDK issue numbers
src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 143:
> 141: * that take too long. T
e.LocalDate,java.time.LocalDate)
>
> And here is the dictionary definition.
>
> a space of time between events or states
>
> https://www.merriam-webster.com/dictionary/interval
>
>
> On Wed, Jun 18, 2025, 7:30 AM Pavel Rappo wrote:
>>
>> Hello, I have two q
Hello, I have two questions on java.time API.
The first one is about documentation for java.time.Period. When I get
back to the API after a long period (no pun intended) of not using it,
it takes me a while to recall that Period does __NOT__ model an
interval between two specific points in time, s
> For many years, concurrency-interest was the mailing list to discuss
> j.u.concurrent and related topics. The mailing list was hosted on a
> server maintained by Prof. Doug Lea. Sadly, the mailing list didn't
> survive an OS upgrade and has been unavailable for some time.
>
> A new mailing li
On Fri, 20 Dec 2024 10:21:34 GMT, Nizar Benalla wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [054c644e](https://github.com/openjdk/jdk/commit/054c644ea6ea38e54abc81e231977106d04bb69e)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The commit be
On Thu, 19 Dec 2024 16:48:33 GMT, Nizar Benalla wrote:
> Please review this doc-only patch to fix an issue that causes the
> cmp-baseline build to fail.
>
> The snippet in `LabelTrget.java` showed a highly rare non deterministism in
> javadoc snippet generation, which will be fixed in
> [JDK-
On Thu, 5 Dec 2024 22:36:12 GMT, Justin Lu wrote:
> Please review this PR which contains the open L10n drop changes for RDP1.
>
> I recommend viewing the improved diffs which are built out by Jon's tool
> here: https://cr.openjdk.org/~jlu/output/. As always, I can not confirm the
> correctnes
On Tue, 29 Oct 2024 13:26:37 GMT, Pavel Rappo wrote:
> Prepare for JDK 25.
This pull request has now been integrated.
Changeset: 5cc150c6
Author: Pavel Rappo
URL:
https://git.openjdk.org/jdk/commit/5cc150c63632c3ab8bf23d94f941d3b6db45d55c
Stats: 6176 lines in 98 files chan
> Prepare for JDK 25.
Pavel Rappo has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains 14 commits:
- Merge branch 'master' into 8342979
- Update --release 24 symbol information for JDK 24 build 26
The macOS/AArch64
> Prepare for JDK 25.
Pavel Rappo has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains 13 commits:
- Update --release 24 symbol information for JDK 24 build 26
The macOS/AArch64 build 26 was taken from https://jdk.java.net
> Prepare for JDK 25.
Pavel Rappo 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 11 additional commits since the
last revision:
- Update --rele
> Prepare for JDK 25.
Pavel Rappo 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 nine additional commits since
the last revision:
- Upd
> Prepare for JDK 25.
Pavel Rappo 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 seven additional commits since
the last revision:
- Upd
> Prepare for JDK 25.
Pavel Rappo 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 five additional commits since
the last revision:
- Upd
> Prepare for JDK 25.
Pavel Rappo has updated the pull request incrementally with one additional
commit since the last revision:
Update --release 24 symbol information for JDK 24 build 21
The macOS/AArch64 build 21 was taken from https://jdk.java.net/24/
-
Changes:
-
> Prepare for JDK 25.
Pavel Rappo has updated the pull request incrementally with one additional
commit since the last revision:
Add forgotten .jcheck/conf
-
Changes:
- all: https://git.openjdk.org/jdk/pull/21763/files
- new: https://git.openjdk.org/jdk/pull/21763/fi
Prepare for JDK 25.
-
Commit messages:
- Initial commit
Changes: https://git.openjdk.org/jdk/pull/21763/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21763&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8342979
Stats: 96 lines in 36 files changed: 49 ins; 3 del;
On Mon, 23 Sep 2024 21:03:08 GMT, Maurizio Cimadamore
wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix javadoc test failure
>
> test/langtools/jdk/javadoc/doclet/testRestricted/TestRestricted.java line 4
On Mon, 30 Sep 2024 10:36:55 GMT, Hannes Wallnöfer wrote:
>> Thanks for the HTML tip; will add an id to the dfn tag.
>
> Adding the `id` attribute to the `dfn` tag is an improvement over the ` name=...>` tag, but the embedded `{@index ...}` tag already generates a
> `span` tag with a very simila
On Mon, 30 Sep 2024 02:10:09 GMT, Joe Darcy wrote:
>> The is the initial version of a PR to defined an anchor point and index term
>> of "wrapper classes."
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Respond to review fee
On Sat, 28 Sep 2024 15:02:50 GMT, Joe Darcy wrote:
>> The is the initial version of a PR to defined an anchor point and index term
>> of "wrapper classes."
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Respond to review fee
On Sat, 28 Sep 2024 15:02:50 GMT, Joe Darcy wrote:
>> The is the initial version of a PR to defined an anchor point and index term
>> of "wrapper classes."
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Respond to review fee
On Sat, 28 Sep 2024 00:56:02 GMT, Joe Darcy wrote:
>> src/java.base/share/classes/java/lang/package-info.java line 63:
>>
>>> 61: * security policies.
>>> 62: *
>>> 63: * Class {@link Throwable} encompasses objects that may be thrown
>>
>> We already have a link to `Class` in this doc commen
On Thu, 26 Sep 2024 23:46:04 GMT, Joe Darcy wrote:
> The is the initial version of a PR to defined an anchor point and index term
> of "wrapper classes."
src/java.base/share/classes/java/lang/package-info.java line 36:
> 34: * The {@index "wrapper classes"} {@link Boolean},
> 35: * {@link Ch
On Fri, 13 Sep 2024 13:07:03 GMT, Chen Liang wrote:
> This patch only captures one-line returns without extra sentences. Is it
> possible for us to handle slightly more complex documentations like
> `ParameterizedType::getActualTypeArguments`?
Sure, it is possible. However, there's a tradeoff
On Fri, 13 Sep 2024 02:47:18 GMT, Joe Darcy wrote:
> Candidates for this refactoring were found programmatically; the program to
> find candidates is in a comment on the bug.
Thanks, Joe. This looks good, especially considering that the change was
produced with the help of a quick-and-dirty, r
On Fri, 13 Sep 2024 07:29:00 GMT, ExE Boss wrote:
> The old version of the doc comments had a `.` at the end of the first
> sentence:
The new version has it too, but in the final, generated form:
https://docs.oracle.com/en/java/javase/22/docs/specs/javadoc/doc-comment-spec.html#return
`{@retu
On Mon, 9 Sep 2024 18:37:47 GMT, Joe Darcy wrote:
> Use index and definition tags in AnnotatedElement.
Marked as reviewed by prappo (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/20919#pullrequestreview-2293347006
On Thu, 5 Sep 2024 21:46:34 GMT, Pavel Rappo wrote:
> This fixes some of the recently discovered [issues] with the block variants
> of the specification tags. While reviewing, please check the proposed changes
> against the actual specifications. Since the specifications for JDK 23 a
man. If you have some time, consider performing similar checks for inline
> `@jls` and `@jvms` tags in your area. Thanks.
>
> [issues]: https://bugs.openjdk.org/browse/JDK-8339558
> [JLS]: https://docs.oracle.com/javase/specs/jls/se22/html/index.html
> [JVMS]: https://docs.oracle.com/java
On Fri, 6 Sep 2024 09:16:28 GMT, Pavel Rappo wrote:
>> This fixes some of the recently discovered [issues] with the block variants
>> of the specification tags. While reviewing, please check the proposed
>> changes against the actual specifications. Since the specifications
On Fri, 6 Sep 2024 09:16:28 GMT, Pavel Rappo wrote:
>> This fixes some of the recently discovered [issues] with the block variants
>> of the specification tags. While reviewing, please check the proposed
>> changes against the actual specifications. Since the specifications
man. If you have some time, consider performing similar checks for inline
> `@jls` and `@jvms` tags in your area. Thanks.
>
> [issues]: https://bugs.openjdk.org/browse/JDK-8339558
> [JLS]: https://docs.oracle.com/javase/specs/jls/se22/html/index.html
> [JVMS]: https://docs.oracle.com/java
On Fri, 6 Sep 2024 06:26:47 GMT, Athijegannathan Sundararajan
wrote:
> fixed spelling to be consistent with the rest of the man page.
I'm not an expert here, but I remember vividly that "dependence" might not be a
misspelling/typo in the world of modules. There are semantic differences which
On Thu, 5 Sep 2024 22:08:13 GMT, Chen Liang wrote:
> > possibly for later, a separate pass might be to review and make consistent
> > the use of `{@code }` in the tags, such as in `The ... Attribute`
>
>
>
> For example, the addition `@jls 15.20.2 The instanceof Operator` in this
> patch doe
This fixes some of the recently discovered [issues] with the block variants of
the specification tags. While reviewing, please check the proposed changes
against the actual specifications. Since the specifications for JDK 23 are not
yet available in the HTML format, you can use the specification
On Thu, 11 Jan 2024 09:38:50 GMT, Alan Bateman wrote:
>> src/java.base/share/classes/java/lang/reflect/Modifier.java line 238:
>>
>>> 236: * modifiers of a class or member, source-level modifiers that do
>>> 237: * not not have a constant in the this class should be
>>> 238: * inc
On Wed, 13 Sep 2023 17:38:28 GMT, Justin Lu wrote:
>> JDK .properties files still use ISO-8859-1 encoding with escape sequences.
>> It would improve readability to see the native characters instead of escape
>> sequences (especially for the L10n process). The majority of files changed
>> are l
On Wed, 14 Aug 2024 13:38:34 GMT, Pavel Rappo wrote:
> This PR fixes a few trivial grammar issues and typos in documentation.
>
> The main issue is the use of the word "timeout". To my mind, timeout, a
> duration, is not the same as deadline, which is a point in time
On Fri, 16 Aug 2024 12:10:32 GMT, Doug Lea wrote:
> It would also be OK to just drop that "s" -> InterruptedException.
True, but there are other similar cases in that same file, maybe it's okay to
leave it like that. Similar cases: ForkJoinTasks, Futures, CountedCompleters,
InterruptibleTasks,
On Fri, 16 Aug 2024 12:15:47 GMT, Doug Lea wrote:
> The overall inconsistency addressed here is that sometime "timeout" refers to
> a duration, and sometimes an event. Which is pretty common, but reworking
> docs to only mean duration seems reasonable.
Am I correct reading your comment as an e
On Thu, 15 Aug 2024 15:29:22 GMT, Alexey Ivanov wrote:
>> Pavel Rappo has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix grammatical tense
>
> src/java.base/share/classes/java/util/concurrent/ForkJoi
On Thu, 15 Aug 2024 04:07:19 GMT, David Holmes wrote:
>> I admit I had doubts about the sequence of tenses too. That's a pretty
>> complex sentence, and I'm a non-native English speaker. It's hard to
>> re-tense it while retaining its conditional nature.
>
> Use "elapsed" here to match "complet
23882a18c7ff666fe6f68b3fa2cfe4/src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java#L1019-L1036
>
>
> @DougLea, thoughts?
Pavel Rappo has updated the pull request incrementally with one additional
commit since the last revision:
Fix grammatical tense
-
Changes:
On Wed, 14 Aug 2024 21:03:05 GMT, Kevin Bourrillion wrote:
>> This PR fixes a few trivial grammar issues and typos in documentation.
>>
>> The main issue is the use of the word "timeout". To my mind, timeout, a
>> duration, is not the same as deadline, which is a point in time, an instant,
>>
This PR fixes a few trivial grammar issues and typos in documentation.
The main issue is the use of the word "timeout". To my mind, timeout, a
duration, is not the same as deadline, which is a point in time, an instant,
which allows "before" and "after". While one can think of timeout as of an
On Thu, 18 Jul 2024 20:51:48 GMT, Naoto Sato wrote:
>> Proposing a new overload method for `Process#waitFor()` which takes a
>> `Duration` for the timeout value. This will reduce the possibility for
>> making mistakes with the `TimeUnit` in the other overload method. A
>> corresponding CSR has
On Fri, 12 Jul 2024 23:38:31 GMT, Chen Liang wrote:
> Please review the backport of #20145 onto jdk23, fixing 2 unnecessary and
> erroneous links in the doc files.
Marked as reviewed by prappo (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/20166#pullrequestreview-217806
On Thu, 11 Jul 2024 09:36:02 GMT, Pavel Rappo wrote:
> Was reading Process' documentation the other day and spotted a markup typo.
> Please review this utmost trivial fix.
This pull request has now been integrated.
Changeset: 6fcd49f9
Author:Pavel Rappo
URL:
Was reading Process' documentation the other day and spotted a markup typo.
Please review this utmost trivial fix.
-
Commit messages:
- Initial commit
Changes: https://git.openjdk.org/jdk/pull/20133/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20133&range=00
Issue: ht
On Mon, 8 Jul 2024 19:12:37 GMT, Joe Darcy wrote:
> PS There are cases where cyclic structures are not supported, such as in
> java.util.Set:
There are algorithms that also don't support that:
/**
* Returns a hash code based on the "deep contents" of the specified
* array. If th
On Mon, 8 Jul 2024 19:01:04 GMT, Joe Darcy wrote:
> One tricky part of the implementation was making sure the stack trace output
> did cycle detection since there were various ways exceptions could end up
> referring to each other.
Yes, the tricky part was to "Guard against malicious overrides
On Mon, 8 Jul 2024 09:33:54 GMT, Jaikiran Pai wrote:
>> Make well-behaved implementation expectations of Object.{toString, hashCode}
>> explicit.
>
> src/java.base/share/classes/java/lang/Object.java line 101:
>
>> 99: * implementation should not use excessive memory or time for its
>> 100
On Sun, 7 Jul 2024 20:20:30 GMT, Joe Darcy wrote:
> Make well-behaved implementation expectations of Object.{toString, hashCode}
> explicit.
Looks good.
-
Marked as reviewed by prappo (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/20063#pullrequestreview-2162781503
> The commit being backported was authored by Pavel Rappo on 20 Jun 2024 and
> was reviewed by Naoto Sato.
>
> Thanks!
Marked as reviewed by prappo (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/19847#pullrequestreview-2135235884
On Mon, 10 Jun 2024 12:29:32 GMT, Pavel Rappo wrote:
> Please review this fix for an intermittent test failure.
>
> On some configurations, the default `expect` timeout of 10 seconds is
> insufficient. It is increased to 20; it's hard to imagine a configuration for
>
t-of-band, that test timeouts should be scaled with
> `test.timeout.factor`. I propose to integrate this PR first and then
> separately update all the affected tests to scale their `expect` timeouts.
Pavel Rappo has updated the pull request with a new target base due to a merge
or a r
t-of-band, that test timeouts should be scaled with
> `test.timeout.factor`. I propose to integrate this PR first and then
> separately update all the affected tests to scale their `expect` timeouts.
Pavel Rappo has updated the pull request with a new target base due to a merge
or a r
On Thu, 13 Jun 2024 06:47:07 GMT, Jaikiran Pai wrote:
> in the past on systems that Matthias has run into similar issues, it was
> observed that those systems run with a very high `-concurrency` value (which
> implies too many test processes running at the same time) which could cause
> slowne
On Tue, 11 Jun 2024 09:01:49 GMT, Pavel Rappo wrote:
>> Please review this fix for an intermittent test failure.
>>
>> On some configurations, the default `expect` timeout of 10 seconds is
>> insufficient. It is increased to 20; it's hard to imagine a configuration
t-of-band, that test timeouts should be scaled with
> `test.timeout.factor`. I propose to integrate this PR first and then
> separately update all the affected tests to scale their `expect` timeouts.
Pavel Rappo has updated the pull request incrementally with one additional
commit s
On Mon, 10 Jun 2024 21:58:29 GMT, Damon Nguyen wrote:
>> This issue is responsible for updating the translations of all the
>> localize(able) resources in the JDK. Primarily, the changes between JDK 22
>> RDP 1 and the integration of the JDK 23 RDP 1 L10n drop will be translated.
>>
>> The tra
t-of-band, that test timeouts should be scaled with
> `test.timeout.factor`. I propose to integrate this PR first and then
> separately update all the affected tests to scale their `expect` timeouts.
Pavel Rappo has updated the pull request incrementally with one additional
commit si
Please review this fix for an intermittent test failure.
On some configurations, the default `expect` timeout of 10 seconds is
insufficient. It is increased to 20; it's hard to imagine a configuration for
which that new value would still be insufficient, but we'll see.
Aside from that, test-gen
On Thu, 6 Jun 2024 21:49:35 GMT, Naoto Sato wrote:
>> 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
On Thu, 6 Jun 2024 17:08:50 GMT, Naoto Sato wrote:
>> test/jdk/java/io/Console/restoreEcho.exp line 57:
>>
>>> 55: test "$rpprompt" "$rpinput" "-echo" "$rpexpected"
>>> 56: # See if the initialEcho is restored with `stty -a`
>>> 57: expect " $initialEcho "
>>
>> If you leave out those whitespac
On Thu, 6 Jun 2024 17:51:50 GMT, Naoto Sato wrote:
> Turned out that removing the classpath ends up not finding the test class:
>
> ```
> Error: Could not find or load main class RestoreEchoTest
> Caused by: java.lang.ClassNotFoundException: RestoreEchoTest
> ];
> ```
Hm... this is surprising.
On Wed, 5 Jun 2024 17:48:25 GMT, Naoto Sato wrote:
>> 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
On Thu, 30 May 2024 18:10:14 GMT, Naoto Sato wrote:
>> Claes has described the issue well. Like I said, `break` short-circuits the
>> search. If a module can provide more than one console provider, the
>> suggested stream-less replacement is **not** equivalent.
>>
>> If a module can provide mo
On Mon, 27 May 2024 16:28:31 GMT, Pavel Rappo wrote:
> Please review this PR, which supersedes a now withdrawn
> https://github.com/openjdk/jdk/pull/14831.
>
> This PR replaces `ArraysSupport.vectorizedHashCode` with a set of more
> user-friendly methods. Here's a summ
On Thu, 30 May 2024 08:34:59 GMT, Claes Redestad wrote:
>> @cl4es, do you want me to delete that test file altogether?
>
> I thought you verified that the non-constant type test still provoke a crash
> (on x86) if you back out the code changes in
> https://github.com/openjdk/jdk/commit/969f6a37
On Thu, 30 May 2024 07:44:24 GMT, Claes Redestad wrote:
>> Right. Since `findAny` is after the module name matching, there is at most 1
>> match. In the case we didn't find any, the final `orElse(null)` eventually
>> returns null. So the refactored code is semantically the same.
>
> It's only s
On Wed, 29 May 2024 21:27:30 GMT, Chen Liang wrote:
>> There is an initialization code in `Console` class that searches for the
>> Console implementations. Refactoring the init code not to use lambda/stream
>> would reduce the (initial) number of loaded classes by about 100 for
>> java.base im
On Wed, 29 May 2024 15:50:05 GMT, Pavel Rappo wrote:
>> @cl4es, here are some results from my machine (macosx-aarch64):
>>
>> Name (size) Cnt BaseError TestError
>> Unit Change
>> ArraysHashCode.bytes1
On Wed, 29 May 2024 12:53:42 GMT, Pavel Rappo wrote:
>> src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 252:
>>
>>> 250: return switch (length) {
>>> 251: case 0 -> initialValue;
>>> 252: case
On Wed, 29 May 2024 12:44:45 GMT, Pavel Rappo wrote:
>> I don't care as long as microbenchmarks don't get a hiccup.
>
> @cl4es, here are some results from my machine (macosx-aarch64):
>
> Name (size) Cnt BaseError Te
t side, since the method
> is now private, it's no longer callable by clients of `ArraysSupport`, thus a
> problem of an inaccurate name is less severe.
>
> - Made the `ArraysSupport.utf16HashCode` method private
>
> - Moved tiny cases (i.e. 0, 1, 2) to `ArraysSupport`
Pa
On Tue, 28 May 2024 16:56:18 GMT, Naoto Sato wrote:
>> 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
On Tue, 28 May 2024 19:13:50 GMT, Jorn Vernee wrote:
>> Pavel Rappo has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix incorrect utf16 hashCode adaptation
>
> src/java.base/share/classes/jdk/internal/ut
On Tue, 28 May 2024 20:40:30 GMT, Claes Redestad wrote:
>> src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 275:
>>
>>> 273: return switch (length) {
>>> 274: case 0 -> initialValue;
>>> 275: case 1 -> 31 * initialValue + (a[fromIndex] & 0xff)
On Wed, 29 May 2024 03:21:27 GMT, Chen Liang wrote:
>> Pavel Rappo has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix incorrect utf16 hashCode adaptation
>
> src/java.base/share/classes/jdk/internal/ut
On Tue, 28 May 2024 20:21:34 GMT, Claes Redestad wrote:
>> test/hotspot/jtreg/compiler/intrinsics/TestArraysHashCode.java line 88:
>>
>>> 86: private static int testIntrinsic(byte[] bytes, int type)
>>> 87: throws InvocationTargetException, IllegalAccessException {
>>> 88:
On Tue, 28 May 2024 22:08:06 GMT, Pavel Rappo wrote:
>> Yes, should be `2` (`a` is semantically a `char[]`). This typo likely pass
>> functional testing since `1` can never happen in practice, and the default
>> case should work for any value. There might be a String
On Tue, 28 May 2024 20:38:21 GMT, Claes Redestad wrote:
>> src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 301:
>>
>>> 299: return switch (length) {
>>> 300: case 0 -> initialValue;
>>> 301: case 1 -> 31 * initialValue + JLA.getUTF16Char(a,
t side, since the method
> is now private, it's no longer callable by clients of `ArraysSupport`, thus a
> problem of an inaccurate name is less severe.
>
> - Made the `ArraysSupport.utf16HashCode` method private
>
> - Moved tiny cases (i.e. 0, 1, 2) to `ArraysSupport`
Pavel Ra
Please review this PR, which supersedes a now withdrawn
https://github.com/openjdk/jdk/pull/14831.
This PR replaces `ArraysSupport.vectorizedHashCode` with a set of more
user-friendly methods. Here's a summary:
- Made the operand constants (i.e. `T_BOOLEAN` and friends) and the
`vectorizedHash
On Tue, 11 Jul 2023 16:35:51 GMT, Pavel Rappo wrote:
> This PR adds an internal method to calculate hash code from the provided
> integer array, offset and length into that array, and the initial hash code
> value.
>
> Current options for calculating a hash code for int[] are i
On Sun, 26 May 2024 07:24:16 GMT, SendaoYan wrote:
>> Hi all,
>> When there is no `/usr/bin/expect` in system, `throw new SkippedException`
>> will not make the jvm exit in `@BeforeAll` junit stage, thus this will cause
>> this testcase run failed. So I make change from `throw new SkippedExce
On Mon, 6 May 2024 21:45:12 GMT, Pavel Rappo wrote:
> Please review this PR which introduces the `java.io.IO` top-level class and
> three methods to `java.io.Console` for [Implicitly Declared Classes and
> Instance Main Methods (Third Preview)].
>
> This PR has been obtaine
te [draft
> PR].
>
> [Implicitly Declared Classes and Instance Main Methods (Third Preview)]:
> https://bugs.openjdk.org/browse/JDK-8323335
> [draft PR]: https://github.com/openjdk/jdk/pull/18921
Pavel Rappo has updated the pull request with a new target base due to a merge
or a rebase. Th
1 - 100 of 465 matches
Mail list logo
