Integrated: 8240903: Add test to check that jmod hashes are reproducible
On Fri, 25 Mar 2022 01:50:04 GMT, Dongbo He wrote: > This creates a regression test for > [JDK-8240734](https://bugs.openjdk.java.net/browse/JDK-8240734). This was > once blocked > by a time stamp issue which has been resolved by: [JDK-8276766 > ](https://bugs.openjdk.java.net/browse/JDK-8276766) > > We found the issue can be produced stably with at least 64 modules. > Note that we need to add the --date jmod option to avoid the timestamp issue. > > Testing: > Added test case fails without fix for JDK-8240734, and passes otherwise. > Tested with tier2 on linux x86. This pull request has now been integrated. Changeset: 96952834 Author:Dongbo He Committer: Fei Yang URL: https://git.openjdk.java.net/jdk/commit/9695283458c273c2a4121f88a2a971ad4f297d5b Stats: 135 lines in 1 file changed: 135 ins; 0 del; 0 mod 8240903: Add test to check that jmod hashes are reproducible Reviewed-by: alanb - PR: https://git.openjdk.java.net/jdk/pull/7948
Re: RFR: 8240903: Add test to check that jmod hashes are reproducible [v5]
On Wed, 30 Mar 2022 01:55:30 GMT, Dongbo He wrote: >> This creates a regression test for >> [JDK-8240734](https://bugs.openjdk.java.net/browse/JDK-8240734). This was >> once blocked >> by a time stamp issue which has been resolved by: [JDK-8276766 >> ](https://bugs.openjdk.java.net/browse/JDK-8276766) >> >> We found the issue can be produced stably with at least 64 modules. >> Note that we need to add the --date jmod option to avoid the timestamp issue. >> >> Testing: >> Added test case fails without fix for JDK-8240734, and passes otherwise. >> Tested with tier2 on linux x86. > > Dongbo He 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 six additional commits since > the last revision: > > - Merge branch 'master' into 8240903 > - Delete extra blank links > - Change shell test io java test > - Get date by 'date +%Y-%m-%dT%H:%M:%S%:z' > - Update Copyright > - 8240903: Add a regression test for JDK-8240734 Thank you for your review, Alan. - PR: https://git.openjdk.java.net/jdk/pull/7948
Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2]
On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which >> JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the >> loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and >> require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems >> (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for >> zero and some of the other ports. Additional ports can be contributed via >> PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels >> have been trimmed down for now to hotspot, serviceability and core-libs. >> We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from >> Doug Lea's CVS. These changes will probably be proposed and integrated in >> advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support >> the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to >> make life a bit easier and avoid having to separate VM changes and juggle >> branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional > commit since the last revision: > > Refresh src/java.base/share/classes/jdk/internal/vm/annotation/ChangesCurrentThread.java line 35: > 33: * disables inlining for the method to which it is applied unless the > 34: * method being unlined into is also annotated ChangesCurrentThread. > 35: Suggestion: * method being inlined into is also annotated ChangesCurrentThread. * - PR: https://git.openjdk.java.net/jdk/pull/8166
Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2]
On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in the HotSpot VM are disabled by default and
>> require running with `--enable-preview` to enable.
>>
>> The patch has support for x64 and aarch64 on the usual operating systems
>> (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for
>> zero and some of the other ports. Additional ports can be contributed via
>> PRs against the fibers branch in the loom repo.
>>
>> There are changes in many areas. To reduce notifications/mails, the labels
>> have been trimmed down for now to hotspot, serviceability and core-libs.
>> We'll add the complete set of labels when the PR is further along.
>>
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from
>> Doug Lea's CVS. These changes will probably be proposed and integrated in
>> advance of this PR.
>>
>> The changes include some non-exposed and low-level infrastructure to support
>> the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to
>> make life a bit easier and avoid having to separate VM changes and juggle
>> branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Refresh
src/java.base/share/classes/jdk/internal/vm/ThreadContainers.java line 184:
> 182: * with the Thread API.
> 183: */
> 184: private static class RootContainer extends ThreadContainer {
This implementation could be clearer if split out into two, and the value
assigned to `INSTANCE` is selected based on the system property. Something to
consider later perhaps.
-
PR: https://git.openjdk.java.net/jdk/pull/8166
Re: RFR: 8282274: Compiler implementation for Pattern Matching for switch (Third Preview) [v3]
On Tue, 12 Apr 2022 13:18:14 GMT, Jan Lahoda wrote: >> This is a (preliminary) patch for javac implementation for the third preview >> of pattern matching for switch (type patterns in switches). >> >> Draft JLS: >> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html >> >> The changes are: >> -there are no guarded patterns anymore, guards are not bound to the >> CaseElement (JLS 15.28) >> -a new contextual keyword `when` is used to add a guard, instead of `&&` >> -`null` selector value is handled on switch level (if a switch has `case >> null`, it is used, otherwise a NPE is thrown), rather than on pattern >> matching level. >> -total patterns are allowed in `instanceof` >> -`java.lang.MatchException` is added for the case where a switch is >> exhaustive (due to sealed types) at compile-time, but not at runtime. >> >> Feedback is welcome! >> >> Thanks! > > Jan Lahoda has updated the pull request incrementally with one additional > commit since the last revision: > > Cleanup. `java.lang.MatchException` should probably also be thrown by non‑`enum` enhanced `switch` statements[^1], to match non‑`enum` `switch` expressions[^2]. [^1]: https://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html#jls-14.11.3 [^2]: https://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html#jls-15.28.2 - PR: https://git.openjdk.java.net/jdk/pull/8182
Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2]
On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in the HotSpot VM are disabled by default and
>> require running with `--enable-preview` to enable.
>>
>> The patch has support for x64 and aarch64 on the usual operating systems
>> (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for
>> zero and some of the other ports. Additional ports can be contributed via
>> PRs against the fibers branch in the loom repo.
>>
>> There are changes in many areas. To reduce notifications/mails, the labels
>> have been trimmed down for now to hotspot, serviceability and core-libs.
>> We'll add the complete set of labels when the PR is further along.
>>
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from
>> Doug Lea's CVS. These changes will probably be proposed and integrated in
>> advance of this PR.
>>
>> The changes include some non-exposed and low-level infrastructure to support
>> the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to
>> make life a bit easier and avoid having to separate VM changes and juggle
>> branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Refresh
src/java.base/share/classes/jdk/internal/vm/Continuation.java line 474:
> 472: private void processNmethods(int before, int after) {
> 473:
> 474: }
Unused field and method?
-
PR: https://git.openjdk.java.net/jdk/pull/8166
Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2]
On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in the HotSpot VM are disabled by default and
>> require running with `--enable-preview` to enable.
>>
>> The patch has support for x64 and aarch64 on the usual operating systems
>> (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for
>> zero and some of the other ports. Additional ports can be contributed via
>> PRs against the fibers branch in the loom repo.
>>
>> There are changes in many areas. To reduce notifications/mails, the labels
>> have been trimmed down for now to hotspot, serviceability and core-libs.
>> We'll add the complete set of labels when the PR is further along.
>>
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from
>> Doug Lea's CVS. These changes will probably be proposed and integrated in
>> advance of this PR.
>>
>> The changes include some non-exposed and low-level infrastructure to support
>> the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to
>> make life a bit easier and avoid having to separate VM changes and juggle
>> branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Refresh
src/java.base/share/classes/jdk/internal/vm/Continuation.java line 264:
> 262: } finally {
> 263: fence();
> 264: StackChunk c = tail;
`c` is not used
src/java.base/share/classes/jdk/internal/vm/Continuation.java line 310:
> 308:
> 309: @IntrinsicCandidate
> 310: private static int doYield() { throw new Error("Intrinsic not
> installed"); };
Suggestion:
private static int doYield() { throw new Error("Intrinsic not installed"); }
-
PR: https://git.openjdk.java.net/jdk/pull/8166
Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2]
On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which >> JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the >> loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and >> require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems >> (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for >> zero and some of the other ports. Additional ports can be contributed via >> PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels >> have been trimmed down for now to hotspot, serviceability and core-libs. >> We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from >> Doug Lea's CVS. These changes will probably be proposed and integrated in >> advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support >> the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to >> make life a bit easier and avoid having to separate VM changes and juggle >> branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional > commit since the last revision: > > Refresh src/java.base/share/classes/jdk/internal/vm/Continuation.java line 115: > 113: } > 114: > 115: private Runnable target; Can be final? (Does not appear to be updated by the VM, or via unsafe by some other class) - PR: https://git.openjdk.java.net/jdk/pull/8166
Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2]
On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in the HotSpot VM are disabled by default and
>> require running with `--enable-preview` to enable.
>>
>> The patch has support for x64 and aarch64 on the usual operating systems
>> (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for
>> zero and some of the other ports. Additional ports can be contributed via
>> PRs against the fibers branch in the loom repo.
>>
>> There are changes in many areas. To reduce notifications/mails, the labels
>> have been trimmed down for now to hotspot, serviceability and core-libs.
>> We'll add the complete set of labels when the PR is further along.
>>
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from
>> Doug Lea's CVS. These changes will probably be proposed and integrated in
>> advance of this PR.
>>
>> The changes include some non-exposed and low-level infrastructure to support
>> the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to
>> make life a bit easier and avoid having to separate VM changes and juggle
>> branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Refresh
src/java.base/share/classes/jdk/internal/vm/Continuation.java line 94:
> 92: default:
> 93: throw new AssertionError("Unknown pinned reason: " +
> reason);
> 94: }
Suggestion:
return switch (reason) {
case 2 -> Pinned.CRITICAL_SECTION;
case 3 -> Pinned.NATIVE;
case 4 -> Pinned.MONITOR;
default -> throw new AssertionError("Unknown pinned reason: " +
reason);
};
-
PR: https://git.openjdk.java.net/jdk/pull/8166
Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2]
On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in the HotSpot VM are disabled by default and
>> require running with `--enable-preview` to enable.
>>
>> The patch has support for x64 and aarch64 on the usual operating systems
>> (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for
>> zero and some of the other ports. Additional ports can be contributed via
>> PRs against the fibers branch in the loom repo.
>>
>> There are changes in many areas. To reduce notifications/mails, the labels
>> have been trimmed down for now to hotspot, serviceability and core-libs.
>> We'll add the complete set of labels when the PR is further along.
>>
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from
>> Doug Lea's CVS. These changes will probably be proposed and integrated in
>> advance of this PR.
>>
>> The changes include some non-exposed and low-level infrastructure to support
>> the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to
>> make life a bit easier and avoid having to separate VM changes and juggle
>> branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Refresh
src/java.base/share/classes/jdk/internal/misc/ThreadTracker.java line 59:
> 57: && this.thread == other.thread;
> 58: }
> 59: }
Suggestion:
private record ThreadRef(Thread thread) {
@Override
public int hashCode() {
return Long.hashCode(thread.threadId());
}
@Override
public boolean equals(Object obj) {
return (obj instanceof ThreadRef other)
&& this.thread == other.thread;
}
}
-
PR: https://git.openjdk.java.net/jdk/pull/8166
Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2]
On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which >> JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the >> loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and >> require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems >> (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for >> zero and some of the other ports. Additional ports can be contributed via >> PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels >> have been trimmed down for now to hotspot, serviceability and core-libs. >> We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from >> Doug Lea's CVS. These changes will probably be proposed and integrated in >> advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support >> the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to >> make life a bit easier and avoid having to separate VM changes and juggle >> branches at this time. > > Alan Bateman has updated the pull request incrementally with one additional > commit since the last revision: > > Refresh src/java.base/share/classes/jdk/internal/misc/ThreadFlock.java line 262: > 260: * @return the thread, started > 261: * @throws IllegalStateException if this flock is shutdown or closed > 262: * @throws jdk.incubator.concurrent.StructureViolationException if > the current Suggestion: * @throws WrongThreadException if the current thread is not the owner or a thread * contained in the flock * @throws jdk.incubator.concurrent.StructureViolationException if the current - PR: https://git.openjdk.java.net/jdk/pull/8166
Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2]
On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in the HotSpot VM are disabled by default and
>> require running with `--enable-preview` to enable.
>>
>> The patch has support for x64 and aarch64 on the usual operating systems
>> (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for
>> zero and some of the other ports. Additional ports can be contributed via
>> PRs against the fibers branch in the loom repo.
>>
>> There are changes in many areas. To reduce notifications/mails, the labels
>> have been trimmed down for now to hotspot, serviceability and core-libs.
>> We'll add the complete set of labels when the PR is further along.
>>
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from
>> Doug Lea's CVS. These changes will probably be proposed and integrated in
>> advance of this PR.
>>
>> The changes include some non-exposed and low-level infrastructure to support
>> the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to
>> make life a bit easier and avoid having to separate VM changes and juggle
>> branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Refresh
src/java.base/share/classes/jdk/internal/misc/InternalLock.java line 46:
> 44: } else {
> 45: CAN_USE_INTERNAL_LOCK = true;
> 46: }
Suggestion:
CAN_USE_INTERNAL_LOCK = Boolean.getBoolean("jdk.io.useMonitors");
-
PR: https://git.openjdk.java.net/jdk/pull/8166
Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2]
On Wed, 13 Apr 2022 14:21:20 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in the HotSpot VM are disabled by default and
>> require running with `--enable-preview` to enable.
>>
>> The patch has support for x64 and aarch64 on the usual operating systems
>> (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for
>> zero and some of the other ports. Additional ports can be contributed via
>> PRs against the fibers branch in the loom repo.
>>
>> There are changes in many areas. To reduce notifications/mails, the labels
>> have been trimmed down for now to hotspot, serviceability and core-libs.
>> We'll add the complete set of labels when the PR is further along.
>>
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from
>> Doug Lea's CVS. These changes will probably be proposed and integrated in
>> advance of this PR.
>>
>> The changes include some non-exposed and low-level infrastructure to support
>> the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to
>> make life a bit easier and avoid having to separate VM changes and juggle
>> branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Refresh
src/java.base/share/classes/jdk/internal/misc/Blocker.java line 118:
> 116: static long beginCompensatedBlock(ForkJoinPool pool) {
> 117: try {
> 118: return (long) beginCompensatedBlock.invoke(pool);
Suggestion:
return (long) beginCompensatedBlock.invokeExact(pool);
src/java.base/share/classes/jdk/internal/misc/Blocker.java line 126:
> 124: static void endCompensatedBlock(ForkJoinPool pool, long post) {
> 125: try {
> 126: endCompensatedBlock.invoke(pool, post);
Suggestion:
endCompensatedBlock.invokeExact(pool, post);
-
PR: https://git.openjdk.java.net/jdk/pull/8166
Re: RFR: 8284922: Fix some doc-comment issues on methods with package access in JDK API
On Fri, 15 Apr 2022 19:34:33 GMT, Pavel Rappo wrote: > People rarely include JDK elements with package access in a javadoc run. That > is why bugs in those elements' doc comments tend to remain unnoticed. > > There are many more bugs in the doc comments of the JDK elements with the > package access than are addressed by this PR; I only included the simplest > ones. Marked as reviewed by bpb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8267
Re: RFR: 8284922: Fix some doc-comment issues on methods with package access in JDK API
On Fri, 15 Apr 2022 19:34:33 GMT, Pavel Rappo wrote: > People rarely include JDK elements with package access in a javadoc run. That > is why bugs in those elements' doc comments tend to remain unnoticed. > > There are many more bugs in the doc comments of the JDK elements with the > package access than are addressed by this PR; I only included the simplest > ones. Marked as reviewed by iris (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8267
Re: RFR: 8284922: Fix some doc-comment issues on methods with package access in JDK API
On Fri, 15 Apr 2022 19:34:33 GMT, Pavel Rappo wrote: > People rarely include JDK elements with package access in a javadoc run. That > is why bugs in those elements' doc comments tend to remain unnoticed. > > There are many more bugs in the doc comments of the JDK elements with the > package access than are addressed by this PR; I only included the simplest > ones. Looks fine. - Marked as reviewed by darcy (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8267
RFR: 8284922: Fix some doc-comment issues on methods with package access in JDK API
People rarely include JDK elements with package access in a javadoc run. That is why bugs in those elements' doc comments tend to remain unnoticed. There are many more bugs in the doc comments of the JDK elements with the package access than are addressed by this PR; I only included the simplest ones. - Commit messages: - Update copyright years - Initial commit Changes: https://git.openjdk.java.net/jdk/pull/8267/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8267=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284922 Stats: 6 lines in 3 files changed: 1 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8267.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8267/head:pull/8267 PR: https://git.openjdk.java.net/jdk/pull/8267
Re: RFR: 8284638: store skip buffers in InputStream Object [v7]
> @jmehrens what about this then? > I think it safe now(actually this mechanism is learned from Reader) XenoAmess has updated the pull request incrementally with one additional commit since the last revision: change to liach operation. - Changes: - all: https://git.openjdk.java.net/jdk/pull/5872/files - new: https://git.openjdk.java.net/jdk/pull/5872/files/1f6e0eb7..9854f523 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=5872=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk=5872=05-06 Stats: 22 lines in 2 files changed: 14 ins; 5 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/5872.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/5872/head:pull/5872 PR: https://git.openjdk.java.net/jdk/pull/5872
Re: RFR: 8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate [v7]
> Supporting `IsoFields` temporal fields in chronologies that are similar to > ISO chronology. Corresponding CSR has also been drafted. Naoto Sato 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 15 additional commits since the last revision: - Revert to use the default method - Merge branch 'master' into JDK-8279185 - Removed unnecessary package names - Modified class desc of `IsoFields` - abstract class -> top level interface - interface -> abstract class - Merge branch 'master' into JDK-8279185 - Removed the method - Merge branch 'master' into JDK-8279185 - Changed to use a type to determine ISO based or not - ... and 5 more: https://git.openjdk.java.net/jdk/compare/0cddf702...82339ec6 - Changes: - all: https://git.openjdk.java.net/jdk/pull/7683/files - new: https://git.openjdk.java.net/jdk/pull/7683/files/474dc85a..82339ec6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7683=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7683=05-06 Stats: 13771 lines in 299 files changed: 10278 ins; 2309 del; 1184 mod Patch: https://git.openjdk.java.net/jdk/pull/7683.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7683/head:pull/7683 PR: https://git.openjdk.java.net/jdk/pull/7683
Re: RFR: 8284893: Fix typos in java.base
On Thu, 14 Apr 2022 20:16:21 GMT, Bradford Wetmore wrote: >> I ran `codespell` on the `src/java.base` directory, and accepted those >> changes where it indeed discovered real typos. >> >> (Due to false positives this can unfortunately not be run automatically) >> >> The majority of fixes are in comments. A handful is in strings, one in a >> local variable name, and a couple in parameter declarations. >> >> Annoyingly, there are several instances of "childs" (instead of "children") >> in the source code, but they were not local and I dared not change them. >> Someone braver than me might take a stab at it, perhaps.. > > src/java.base/share/classes/sun/security/provider/certpath/AdjacencyList.java > line 128: > >> 126: // Each time this method is called, we're examining a new list >> 127: // from the global list. So, we have to start by getting the >> list >> 128: // that contains the set of Vertices we're considering. > > The class being affected is a Vertex, so either change to vertices, or leave > as is... Agree, suggest changing it to "vertices". - PR: https://git.openjdk.java.net/jdk/pull/8250
Re: RFR: 8282274: Compiler implementation for Pattern Matching for switch (Third Preview) [v3]
On Tue, 12 Apr 2022 13:18:14 GMT, Jan Lahoda wrote: >> This is a (preliminary) patch for javac implementation for the third preview >> of pattern matching for switch (type patterns in switches). >> >> Draft JLS: >> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html >> >> The changes are: >> -there are no guarded patterns anymore, guards are not bound to the >> CaseElement (JLS 15.28) >> -a new contextual keyword `when` is used to add a guard, instead of `&&` >> -`null` selector value is handled on switch level (if a switch has `case >> null`, it is used, otherwise a NPE is thrown), rather than on pattern >> matching level. >> -total patterns are allowed in `instanceof` >> -`java.lang.MatchException` is added for the case where a switch is >> exhaustive (due to sealed types) at compile-time, but not at runtime. >> >> Feedback is welcome! >> >> Thanks! > > Jan Lahoda has updated the pull request incrementally with one additional > commit since the last revision: > > Cleanup. the patch doesn't apply cleanly on the master repo probably need to rebase? - PR: https://git.openjdk.java.net/jdk/pull/8182
Re: RFR: 8282274: Compiler implementation for Pattern Matching for switch (Third Preview) [v3]
On Tue, 12 Apr 2022 13:18:14 GMT, Jan Lahoda wrote:
>> This is a (preliminary) patch for javac implementation for the third preview
>> of pattern matching for switch (type patterns in switches).
>>
>> Draft JLS:
>> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html
>>
>> The changes are:
>> -there are no guarded patterns anymore, guards are not bound to the
>> CaseElement (JLS 15.28)
>> -a new contextual keyword `when` is used to add a guard, instead of `&&`
>> -`null` selector value is handled on switch level (if a switch has `case
>> null`, it is used, otherwise a NPE is thrown), rather than on pattern
>> matching level.
>> -total patterns are allowed in `instanceof`
>> -`java.lang.MatchException` is added for the case where a switch is
>> exhaustive (due to sealed types) at compile-time, but not at runtime.
>>
>> Feedback is welcome!
>>
>> Thanks!
>
> Jan Lahoda has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Cleanup.
Looks good - I like how moving the guard from pattern to an expression inside a
switch made the code simpler to reason about, and also simplified the compiler
API. I left some comments in the javadoc of MatchException.
src/java.base/share/classes/java/lang/MatchException.java line 33:
> 31: * Thrown to indicate an unexpected failure in pattern matching.
> 32: *
> 33: * MatchException may be thrown when an exhaustive pattern matching
> language construct
Maybe wrap with `{@code}`
src/java.base/share/classes/java/lang/MatchException.java line 34:
> 32: *
> 33: * MatchException may be thrown when an exhaustive pattern matching
> language construct
> 34: * (such as a switch expression) encounters a match target that does not
> match any of the provided
Is the term "match target" defined somewhere? In general, it would be good
quoting relevant sections of the JLS, and using consistent terminology
src/java.base/share/classes/java/lang/MatchException.java line 37:
> 35: * patterns at runtime. This can currently arise from the following case:
> 36: *
> 37: * Separate compilation anomalies, where a sealed interface has a
> different
Why a list if there's only one case? I know we have plans to expand this to
cover nulls in records patterns, but right now the javadoc should stand on its
own
src/java.base/share/classes/java/lang/MatchException.java line 52:
> 50:
> 51: /**
> 52: * Constructs an {@code MatchException} with no detail message.
double space before "message" ?
src/java.base/share/classes/java/lang/MatchException.java line 73:
> 71: *
> 72: * @param cause the cause (which is saved for later retrieval by the
> 73: * {@link #getCause()} method). (A {@code null} value is
double space before "(A" ?
src/java.base/share/classes/java/lang/MatchException.java line 88:
> 86: * by the {@link #getMessage()} method).
> 87: * @param cause the cause (which is saved for later retrieval by the
> 88: * {@link #getCause()} method). (A {@code null} value is
Same here, double space before "(A"
-
PR: https://git.openjdk.java.net/jdk/pull/8182
Re: RFR: 8282274: Compiler implementation for Pattern Matching for switch (Third Preview) [v3]
On Tue, 12 Apr 2022 13:18:14 GMT, Jan Lahoda wrote: >> This is a (preliminary) patch for javac implementation for the third preview >> of pattern matching for switch (type patterns in switches). >> >> Draft JLS: >> http://cr.openjdk.java.net/~gbierman/PatternSwitchPlusRecordPatterns/PatternSwitchPlusRecordPatterns-20220407/specs/patterns-switch-jls.html >> >> The changes are: >> -there are no guarded patterns anymore, guards are not bound to the >> CaseElement (JLS 15.28) >> -a new contextual keyword `when` is used to add a guard, instead of `&&` >> -`null` selector value is handled on switch level (if a switch has `case >> null`, it is used, otherwise a NPE is thrown), rather than on pattern >> matching level. >> -total patterns are allowed in `instanceof` >> -`java.lang.MatchException` is added for the case where a switch is >> exhaustive (due to sealed types) at compile-time, but not at runtime. >> >> Feedback is welcome! >> >> Thanks! > > Jan Lahoda has updated the pull request incrementally with one additional > commit since the last revision: > > Cleanup. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1779: > 1777: //binding pattern > 1778: attribExpr(pat, switchEnv); > 1779: var primary = TreeInfo.primaryPatternType(pat); general comment: the handleSwitch method is getting more and more complex, please consider refactoring it, probably splitting it, for example different subrutines handling different case kinds. Of course this probably should be done as a separate effort. - PR: https://git.openjdk.java.net/jdk/pull/8182
Integrated: 8280915: Better parallelization for AbstractSpliterator and IteratorSpliterator when size is unknown
On Sat, 29 Jan 2022 16:31:43 GMT, Tagir F. Valeev wrote: > See the bug description for details. > > I propose a simple solution. Let's allow ArraySpliterator to be non-SIZED and > report artificial estimatedSize(), much bigger than the real one. This will > allow AbstractSpliterator and IteratorSpliterator to produce prefix whose > size is comparable to Long.MAX_VALUE (say, starting with Long.MAX_VALUE/2), > and this will enable further splitting of the prefix. This change will > drastically improve parallel streaming for affected streams of size <= 1024 > and significantly improve for streams of size 1025..2. The cost is > higher-grained splitting for huge streams of unknown size. This might add a > minor overhead for such scenarios which, I believe, is completely tolerable. > > No public API changes are necessary, sequential processing should not be > affected, except an extra field in ArraySpliterator which increases a > footprint by 8 bytes. > > I added a simple test using an artificial collector to ensure that at least > two non-empty parts are created when parallelizing Stream.iterate source. > More testing ideas are welcome. This pull request has now been integrated. Changeset: 4cc8eccf Author:Tagir F. Valeev URL: https://git.openjdk.java.net/jdk/commit/4cc8eccfcadf5d3edc31809ead2dd6554c7cca4b Stats: 212 lines in 3 files changed: 178 ins; 0 del; 34 mod 8280915: Better parallelization for AbstractSpliterator and IteratorSpliterator when size is unknown Reviewed-by: psandoz - PR: https://git.openjdk.java.net/jdk/pull/7279
Re: RFR: 8178355: IdentityHashMap uses identity-based comparison for values everywhere except remove(K,V) and replace(K,V,V)
On Fri, 15 Apr 2022 13:53:59 GMT, ExE Boss wrote:
>> Explicitly implement `remove` and `replace` in `IdentityHashMap` to compare
>> values by identity. Updated API documentation of these two methods
>> ([Preview](https://cr.openjdk.java.net/~liach/8178355/IdentityHashMap.html#remove(java.lang.Object,java.lang.Object)))
>> to mention such behavior.
>
> test/jdk/java/util/IdentityHashMap/DefaultRemoveReplace.java line 36:
>
>> 34: final String key = "key";
>> 35: final String internedValue = "value";
>> 36: final String constructedValue = new String(new char[]{'v', 'a',
>> 'l', 'u', 'e'});
>
> Using:
> Suggestion:
>
> final String constructedValue = new String(internedValue);
>
> will allow the internal `String.value` array to be shared:
>
I know. This is just to get rid of intellij idea's warning.
-
PR: https://git.openjdk.java.net/jdk/pull/8259
Re: RFR: 8178355: IdentityHashMap uses identity-based comparison for values everywhere except remove(K,V) and replace(K,V,V)
On Fri, 15 Apr 2022 05:58:32 GMT, liach wrote:
> Explicitly implement `remove` and `replace` in `IdentityHashMap` to compare
> values by identity. Updated API documentation of these two methods
> ([Preview](https://cr.openjdk.java.net/~liach/8178355/IdentityHashMap.html#remove(java.lang.Object,java.lang.Object)))
> to mention such behavior.
test/jdk/java/util/IdentityHashMap/DefaultRemoveReplace.java line 36:
> 34: final String key = "key";
> 35: final String internedValue = "value";
> 36: final String constructedValue = new String(new char[]{'v', 'a',
> 'l', 'u', 'e'});
Using:
Suggestion:
final String constructedValue = new String(internedValue);
will allow the internal `String.value` array to be shared:
-
PR: https://git.openjdk.java.net/jdk/pull/8259
Re: RFR: 8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable
On Mon, 21 Feb 2022 12:16:53 GMT, Andrey Turbanov wrote: >> I've stared at the javadoc for Class.isAssignableFrom and Class.isInstance >> and if a non-null instance is used to get a non-null class they are PROBABLY >> the same but it is far from clear. The implementations of both are at least >> native and may be instrinsicified. The doc for Class.isAssignableFrom cites >> JLS 5.1.4 which in what I found is about primitives so I suspect it is >> woefully out of date >> https://docs.oracle.com/javase/specs/jls/se17/html/jls-5.html#jls-5.1.4 >> >> What client tests have you run that touch the code you are changing ? >> >> In short I see insufficient value in the changes here and would prefer you >> drop the client part so I don't have to worry about it. > >>In short I see insufficient value in the changes here and would prefer you >>drop the client part so I don't have to worry about it. > > I think, usage of `isInstance` is much clear for most java developers. > Everyone knows about java _instanceof_ operator. And `isInstance` method > javadoc is very straight forward: `This method is the dynamic equivalent of > the Java language instanceof operator.` > > Method `isAssignableFrom` is opposite: it brings unnecessary complexity in > the code. And it's easy to confuse orders of parameters. Even JBS confirms > that: > 1. [Wrong isAssignableFrom test when adding Principal to Subject > ](https://bugs.openjdk.java.net/browse/JDK-8034820) > 2. [isAssignableFrom checks in KeyFactorySpi.engineGetKeySpec appear to be > backwards](https://bugs.openjdk.java.net/browse/JDK-8254717) > 3. [isAssignableFrom checks in AlgorithmParametersSpi.engineGetParameterSpec > appear to be backwards](https://bugs.openjdk.java.net/browse/JDK-8279800) > > So, it gives all 3 points to prefer isInstance method: it's shorter, it's > clearer for most java developers, it's faster. > @turbanoff > > Method `isAssignableFrom` is opposite: it brings unnecessary complexity in > > the code. And it's easy to confuse orders of parameters. Even JBS confirms > > that: > > Maybe we should add `Class::isSubclassOf(Class that)` that performs > `that.isAssignableFrom(this)`: I have opened [JI‑9073064](https://bugs.openjdk.java.net/browse/JI-9073064 "[JI‑9073064] Add the method `Class::isSublassOf(Class)` to `java.lang.Class` that does the inverse of `Class::isAssignableFrom`") for this. - PR: https://git.openjdk.java.net/jdk/pull/7061
Re: RFR: 8240903: Add test to check that jmod hashes are reproducible [v5]
On Wed, 30 Mar 2022 01:55:30 GMT, Dongbo He wrote: >> This creates a regression test for >> [JDK-8240734](https://bugs.openjdk.java.net/browse/JDK-8240734). This was >> once blocked >> by a time stamp issue which has been resolved by: [JDK-8276766 >> ](https://bugs.openjdk.java.net/browse/JDK-8276766) >> >> We found the issue can be produced stably with at least 64 modules. >> Note that we need to add the --date jmod option to avoid the timestamp issue. >> >> Testing: >> Added test case fails without fix for JDK-8240734, and passes otherwise. >> Tested with tier2 on linux x86. > > Dongbo He 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 six additional commits since > the last revision: > > - Merge branch 'master' into 8240903 > - Delete extra blank links > - Change shell test io java test > - Get date by 'date +%Y-%m-%dT%H:%M:%S%:z' > - Update Copyright > - 8240903: Add a regression test for JDK-8240734 Marked as reviewed by alanb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/7948
Re: RFR: 8284893: Fix typos in java.base
On Thu, 14 Apr 2022 19:07:09 GMT, Magnus Ihse Bursie wrote: > I ran `codespell` on the `src/java.base` directory, and accepted those > changes where it indeed discovered real typos. > > (Due to false positives this can unfortunately not be run automatically) > > The majority of fixes are in comments. A handful is in strings, one in a > local variable name, and a couple in parameter declarations. > > Annoyingly, there are several instances of "childs" (instead of "children") > in the source code, but they were not local and I dared not change them. > Someone braver than me might take a stab at it, perhaps.. I skimmed through the changes to src/java.base and they look okay except for the changes to 3rd party code that I think should be dropped from this patch. src/java.base/share/native/libzip/zlib/inftrees.h line 65: > 63:1444, which is the sum of 852 for literal/length codes and 592 for > distance > 64:codes. These values were found by exhaustive searches using the > program > 65:examples/enough.c found in the zlib distribution. The arguments to > that This is 3rd party code so should be dropped from the patch as we want as few changes to this code has possible. src/java.base/windows/native/libnio/ch/wepoll.c line 894: > 892: * error code when the once-callback returns FALSE. We return -1 > here to > 893: * indicate that global initialization failed; the failing init > function is > 894: * responsible for setting `errno` and calling `SetLastError()`. */ This is also 3rd party code so should be dropped from this patch. - PR: https://git.openjdk.java.net/jdk/pull/8250
Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3]
On Fri, 15 Apr 2022 12:31:24 GMT, Andrey Turbanov wrote: > method seems unused now It's used by the SL API, which will follow later. I realize this may sound complicated but it avoids more complicated splits. - PR: https://git.openjdk.java.net/jdk/pull/8166
Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2]
On Thu, 14 Apr 2022 21:39:17 GMT, Paul Sandoz wrote:
>> Alan Bateman has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Refresh
>
> src/java.base/share/classes/java/lang/Thread.java line 862:
>
>> 860: * @param start the starting value of the counter
>> 861: * @return this builder
>> 862: * @throws IllegalArgumentException if count is negative
>
> Suggestion:
>
> * @throws IllegalArgumentException if start is negative
Thanks, I think that dates from when the param was renamed.
> src/java.base/share/classes/java/lang/VirtualThread.java line 65:
>
>> 63: * system.
>> 64: */
>> 65: class VirtualThread extends Thread {
>
> Suggestion:
>
> final class VirtualThread extends Thread {
okay.
> src/java.base/share/classes/java/lang/VirtualThread.java line 94:
>
>> 92: * RUNNING -> PARKING // Thread attempts to park
>> 93: * PARKING -> PARKED // yield successful, thread is parked
>> 94: * PARKING -> PINNED // yield failed, thread is pinned
>
> Suggestion:
>
> * PARKING -> PARKED // parking successful, thread is parked
> * PARKING -> PINNED // parking failed, thread is pinned
The comment was about cont.yield, will change it to make it clearer.
-
PR: https://git.openjdk.java.net/jdk/pull/8166
Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3]
On Fri, 15 Apr 2022 11:45:01 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in the HotSpot VM are disabled by default and
>> require running with `--enable-preview` to enable.
>>
>> The patch has support for x64 and aarch64 on the usual operating systems
>> (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for
>> zero and some of the other ports. Additional ports can be contributed via
>> PRs against the fibers branch in the loom repo.
>>
>> There are changes in many areas. To reduce notifications/mails, the labels
>> have been trimmed down for now to hotspot, serviceability and core-libs.
>> We'll add the complete set of labels when the PR is further along.
>>
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from
>> Doug Lea's CVS. These changes will probably be proposed and integrated in
>> advance of this PR.
>>
>> The changes include some non-exposed and low-level infrastructure to support
>> the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to
>> make life a bit easier and avoid having to separate VM changes and juggle
>> branches at this time.
>
> Alan Bateman 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:
>
> - Refresh
> - Refresh
> - Merge with jdk-19+18
> - Refresh
> - Initial push
src/java.base/share/classes/jdk/internal/access/JavaUtilConcurrentTLRAccess.java
line 29:
> 27:
> 28: public interface JavaUtilConcurrentTLRAccess {
> 29: int nextSecondaryThreadLocalRandomSeed();
method seems unused now
-
PR: https://git.openjdk.java.net/jdk/pull/8166
Re: RFR: 8284893: Fix typos in java.base
On Fri, 15 Apr 2022 11:25:09 GMT, Pavel Rappo wrote: >> I ran `codespell` on the `src/java.base` directory, and accepted those >> changes where it indeed discovered real typos. >> >> (Due to false positives this can unfortunately not be run automatically) >> >> The majority of fixes are in comments. A handful is in strings, one in a >> local variable name, and a couple in parameter declarations. >> >> Annoyingly, there are several instances of "childs" (instead of "children") >> in the source code, but they were not local and I dared not change them. >> Someone braver than me might take a stab at it, perhaps.. > > src/java.base/share/legal/icu.md line 310: > >> 308: # list of conditions and the following disclaimer. Redistributions in >> binary >> 309: # form must reproduce the above copyright notice, this list of >> conditions and >> 310: # the following disclaimer in the documentation and/or the materials > > I think it's a mistype of "other", not "the"; look at the similar text below. Should be addressed on the ICU side. - PR: https://git.openjdk.java.net/jdk/pull/8250
Re: RFR: 8284893: Fix typos in java.base
On Thu, 14 Apr 2022 19:07:09 GMT, Magnus Ihse Bursie wrote: > I ran `codespell` on the `src/java.base` directory, and accepted those > changes where it indeed discovered real typos. > > (Due to false positives this can unfortunately not be run automatically) > > The majority of fixes are in comments. A handful is in strings, one in a > local variable name, and a couple in parameter declarations. > > Annoyingly, there are several instances of "childs" (instead of "children") > in the source code, but they were not local and I dared not change them. > Someone braver than me might take a stab at it, perhaps.. src/java.base/share/legal/icu.md line 310: > 308: # list of conditions and the following disclaimer. Redistributions in > binary > 309: # form must reproduce the above copyright notice, this list of > conditions and > 310: # the following disclaimer in the documentation and/or the materials I think it's a mistype of "other", not "the"; look at the similar text below. src/java.base/share/native/libzip/zlib/ChangeLog line 99: > 97: - Simplify contrib/vstudio/vc10 with 'd' suffix > 98: - Add TOP support to win32/Makefile.msc > 99: - Support i686 and amd64 assembler builds in CMakeLists.txt Similarly to Naoto's comment on ICU: shouldn't we leave this as is? If anybody cares enough about this typo, they could file a bug against zlib directly. src/java.base/share/native/libzip/zlib/README line 67: > 65: when compiled with cc. > 66: > 67: - On Digital Unix 4.0D (formerly OSF/1) on AlphaServer, the cc option > -std1 is Same as above. - PR: https://git.openjdk.java.net/jdk/pull/8250
Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v3]
> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which > JDK version to target. > > We will refresh this PR periodically to pick up changes and fixes from the > loom repo. > > Most of the new mechanisms in the HotSpot VM are disabled by default and > require running with `--enable-preview` to enable. > > The patch has support for x64 and aarch64 on the usual operating systems > (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero > and some of the other ports. Additional ports can be contributed via PRs > against the fibers branch in the loom repo. > > There are changes in many areas. To reduce notifications/mails, the labels > have been trimmed down for now to hotspot, serviceability and core-libs. > We'll add the complete set of labels when the PR is further along. > > The changes include a refresh of java.util.concurrent and ForkJoinPool from > Doug Lea's CVS. These changes will probably be proposed and integrated in > advance of this PR. > > The changes include some non-exposed and low-level infrastructure to support > the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to > make life a bit easier and avoid having to separate VM changes and juggle > branches at this time. Alan Bateman 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: - Refresh - Refresh - Merge with jdk-19+18 - Refresh - Initial push - Changes: - all: https://git.openjdk.java.net/jdk/pull/8166/files - new: https://git.openjdk.java.net/jdk/pull/8166/files/0e12c206..f53f0d4e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8166=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8166=01-02 Stats: 148912 lines in 1502 files changed: 104901 ins; 9917 del; 34094 mod Patch: https://git.openjdk.java.net/jdk/pull/8166.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166 PR: https://git.openjdk.java.net/jdk/pull/8166
Integrated: JDK-8284874: Add comment to ProcessHandle/OnExitTest to describe zombie problem
On Thu, 14 Apr 2022 09:32:46 GMT, Thomas Stuefe wrote: > ProcessHandle/OnExitTest is vulnerable to misconfigured systems that do not > reap zombies in a timely fashion. > [JDK-8284282](https://bugs.openjdk.java.net/browse/JDK-8284282) describes > this problem in detail. > > Until we figure out a way to fix that (if at all - see comments in JBS), let > us have a clarifying comment in the test itself. This pull request has now been integrated. Changeset: bb7c97bd Author:Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/bb7c97bddfe88cb3261706f5e272fd0418e5238c Stats: 19 lines in 1 file changed: 18 ins; 0 del; 1 mod 8284874: Add comment to ProcessHandle/OnExitTest to describe zombie problem Reviewed-by: rriggs - PR: https://git.openjdk.java.net/jdk/pull/8240
Re: RFR: JDK-8284874: Add comment to ProcessHandle/OnExitTest to describe zombie problem [v3]
On Thu, 14 Apr 2022 18:29:21 GMT, Thomas Stuefe wrote: >> ProcessHandle/OnExitTest is vulnerable to misconfigured systems that do not >> reap zombies in a timely fashion. >> [JDK-8284282](https://bugs.openjdk.java.net/browse/JDK-8284282) describes >> this problem in detail. >> >> Until we figure out a way to fix that (if at all - see comments in JBS), let >> us have a clarifying comment in the test itself. > > Thomas Stuefe has updated the pull request incrementally with one additional > commit since the last revision: > > fix copyright Thanks Roger! - PR: https://git.openjdk.java.net/jdk/pull/8240
Re: RFR: 8284893: Fix typos in java.base
On Thu, 14 Apr 2022 19:07:09 GMT, Magnus Ihse Bursie wrote: > I ran `codespell` on the `src/java.base` directory, and accepted those > changes where it indeed discovered real typos. > > (Due to false positives this can unfortunately not be run automatically) > > The majority of fixes are in comments. A handful is in strings, one in a > local variable name, and a couple in parameter declarations. > > Annoyingly, there are several instances of "childs" (instead of "children") > in the source code, but they were not local and I dared not change them. > Someone braver than me might take a stab at it, perhaps.. Shouldn't copyright year be updated too? - PR: https://git.openjdk.java.net/jdk/pull/8250
RFR: 8178355: IdentityHashMap uses identity-based comparison for values everywhere except remove(K,V) and replace(K,V,V)
Explicitly implement `remove` and `replace` in `IdentityHashMap` to compare values by identity. Updated API documentation of these two methods to mention such behavior. - Commit messages: - Fix indent - 8178355: IdentityHashMap uses identity-based comparison for values everywhere except remove(K,V) and replace(K,V,V) Changes: https://git.openjdk.java.net/jdk/pull/8259/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8259=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8178355 Stats: 165 lines in 2 files changed: 132 ins; 32 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8259.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8259/head:pull/8259 PR: https://git.openjdk.java.net/jdk/pull/8259
