Re: RFR: 8286294 : ForkJoinPool.commonPool().close() spins [v4]
On Sat, 7 May 2022 11:29:32 GMT, Doug Lea wrote:
>> Changes ForkJoinPool.close spec and code to trap close as a no-op if called
>> on common pool
>
> Doug Lea has updated the pull request incrementally with three additional
> commits since the last revision:
>
> - Accommodate restrictive SecurityManagers
> - merge with loom updates
>Merge remote-tracking branch 'refs/remotes/origin/JDK-8286294' into
> JDK-8286294
> - Fix testLazySubmit; enable suite
src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3533:
> 3531:
> 3532: /**
> 3533: * Unless this is the {@link #commonPool()}, initiates an orderly
clearer everywhere is
{@linkplain #commonPool common pool}
src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3536:
> 3534: * shutdown in which previously submitted tasks are executed, but
> 3535: * no new tasks will be accepted, and waits until all tasks have
> 3536: * completed execution and the executor has terminated.
slightly clearer is
s/executor/pool/
src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3548:
> 3546: *
> 3547: * @throws SecurityException if a security manager exists and
> 3548: * shutting down this ExecutorService may manipulate
clearer and more consistent is
s/this ExecutorService/this pool/
src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3565:
> 3563: while (!terminated) {
> 3564: try {
> 3565: terminated = awaitTermination(1L,
> TimeUnit.DAYS);
I would use untimed wait
-
PR: https://git.openjdk.java.net/jdk/pull/8577
Re: RFR: JDK-6725221 Standardize obtaining boolean properties with defaults
On Sun, 8 May 2022 02:22:08 GMT, Phil Race wrote: > I did wonder why it has security-libs as the sub-category and if the intent > was not what we see here. I suspect the JBS issue was initially created to to look at the usages of getProperty in the security code but it has been extended. The issue is that it changes the meaning of the empty value case in at least two places so each one will require careful attention. - PR: https://git.openjdk.java.net/jdk/pull/8559
Deprecating java.util.Date, java.util.Calendar and java.text.DateFormat and their subclasses
The java.time package was released in Java 8, far back in 2014, more than 8 years ago. It has been a long time since then. Before that, we had the dreadful infamous java.util.Date, java.util.Calendar, java.text.DateFormat and their subclasses java.sql.Date, java.sql.Time, java.sql.Timestamp, java.util.GregorianCalendar, java.text.SimpleDateFormat and a few other lesser-known obscure cases. There are plenty of reasons to avoid using Date, Calendar, DateFormat and their subclasses, otherwise there would be few to no reasons for java.time to be conceived. Applications and libraries which used or relied on those legacy classes already had plenty of time to move on and provide java.time.* alternatives. No skilled java programmer uses the legacy classes in new applications except when integrating with legacy APIs. Using those classes nowadays should be considered at least a bad programming practice, if not something worse (source of bugs, security issues, etc). Novices, unskilled, careless and lazy programmers who should know better still happily continue to use the legacy classes, pissing off those who are more enlightened. So, my proposal is pretty simple: It is time to put a @Deprecated in all of those (not for removal, though). First, let's deprecate all of them. Second, any method in the JDK returning or receiving any of those as a parameter should be equally deprecated. If there is no replacement method using the relevant classes or interfaces in the java.time package, one should be created (which is something probably pretty straightforward). If any of those methods is abstract or is part of an interface, then we have a small problem, and it should be solved on a case-by-case analysis, preferentially by providing a default implementation. I'm sure that some cases should still exist, but I doubt that any of them would be a showstopper. The negative impact is expected to be very small. Popular products like Spring and Jakarta either already moved on and provided java.time.* alternatives to their APIs or could do that quickly and easily. Anyone who is left behind, would only get some [deserved] deprecation warnings. On the positive impact side, more than just discouraging the usage of the ugly and annoying API of Date, Calendar and DateFormat for people who should know better, those classes are a frequent source of bugs that are hard do track and to debug due to their mutability and thread unsafety. Thus, we are already way past the time to make the compiler give a warning to anyone still using them. What do you think?
Re: RFR: JDK-6725221 Standardize obtaining boolean properties with defaults
On Thu, 5 May 2022 16:49:07 GMT, Mark Powers wrote: > JDK-6725221 Standardize obtaining boolean properties with defaults I did wonder why it has security-libs as the sub-category and if the intent was not what we see here. - PR: https://git.openjdk.java.net/jdk/pull/8559
Re: RFR: 8286294 : ForkJoinPool.commonPool().close() spins [v4]
On Sat, 7 May 2022 11:29:32 GMT, Doug Lea wrote:
>> Changes ForkJoinPool.close spec and code to trap close as a no-op if called
>> on common pool
>
> Doug Lea has updated the pull request incrementally with three additional
> commits since the last revision:
>
> - Accommodate restrictive SecurityManagers
> - merge with loom updates
>Merge remote-tracking branch 'refs/remotes/origin/JDK-8286294' into
> JDK-8286294
> - Fix testLazySubmit; enable suite
Here's a suggested strengthening of testCloseCommonPool:
- close should have "no effect", not just "not terminate".
- the submitted task will be run by the pool ... eventually (which suggests
that closing the common pool maybe should quiesce the pool before returning)
- I might merge this with testCommonPoolShutDown
/**
* Implicitly closing common pool using try-with-resources has no effect.
*/
public void testCloseCommonPool() {
ForkJoinTask f = new FibAction(8);
ForkJoinPool pool;
try (ForkJoinPool p = pool = ForkJoinPool.commonPool()) {
p.execute(f);
}
assertFalse(pool.isShutdown());
assertFalse(pool.isTerminating());
assertFalse(pool.isTerminated());
String prop = System.getProperty(
"java.util.concurrent.ForkJoinPool.common.parallelism");
if (! "0".equals(prop)) {
f.join();
checkCompletedNormally(f);
}
}
-
PR: https://git.openjdk.java.net/jdk/pull/8577
Re: RFR: 8286294 : ForkJoinPool.commonPool().close() spins [v4]
On Sat, 7 May 2022 11:29:32 GMT, Doug Lea wrote: >> Changes ForkJoinPool.close spec and code to trap close as a no-op if called >> on common pool > > Doug Lea has updated the pull request incrementally with three additional > commits since the last revision: > > - Accommodate restrictive SecurityManagers > - merge with loom updates >Merge remote-tracking branch 'refs/remotes/origin/JDK-8286294' into > JDK-8286294 > - Fix testLazySubmit; enable suite testAdaptInterruptible_Callable_toString belongs in ForkJoinTaskTest.java. Oh wait, it's already there, commented out! Why not fix it there? - PR: https://git.openjdk.java.net/jdk/pull/8577
Re: RFR: 8283689: Update the foreign linker VM implementation [v4]
On Sat, 7 May 2022 12:51:12 GMT, Jorn Vernee wrote: >> Hi, >> >> This PR updates the VM implementation of the foreign linker, by bringing >> over commits from the panama-foreign repo. >> >> This is split off from the main JEP integration for 19, since we have >> limited resources to handle this. As such, this PR might fall over to 20. >> >> I've written up an overview of the Linker architecture here: >> http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful >> to read that first. >> >> This patch moves from the "legacy" implementation, to what is currently >> implemented in the panama-foreign repo, except for replacing the use of >> method handle combinators with ASM. That will come in a later path. To >> recap. This PR contains the following changes: >> >> 1. VM stubs for downcalls are now generated up front, instead of lazily by >> C2 [1]. >> 2. the VM support for upcalls/downcalls now support all possible call >> shapes. And VM stubs and Java code implementing the buffered invocation >> strategy has been removed [2], [3], [4], [5]. >> 3. The existing C2 intrinsification support for the `linkToNative` method >> handle linker was no longer needed and has been removed [6] (support might >> be re-added in another form later). >> 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now >> implements RuntimeBlob directly. Binding to java classes has been rewritten >> to use javaClasses.h/cpp (this wasn't previously possible due to these java >> classes being in an incubator module) [7], [8], [9]. >> >> While the patch mostly consists of VM changes, there are also some Java >> changes to support (2). >> >> The original commit structure has been mostly retained, so it might be >> useful to look at a specific commit, or the corresponding patch in the >> [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) >> repo as well. I've also left some inline comments to explain some of the >> changes, which will hopefully make reviewing easier. >> >> Testing: Tier1-4 >> >> Thanks, >> Jorn >> >> [1]: >> https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 >> [2]: >> https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 >> [3]: >> https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 >> [4]: >> https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 >> [5]: >> https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 >> [6]: >> https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a >> [7]: >> https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 >> [8]: >> https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f >> [9]: >> https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 > > Jorn Vernee has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains 90 commits: > > - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 > - Merge branch 'master' into JEP-19-VM-IMPL2 > - 8284161: Implementation of Virtual Threads (Preview) > >Co-authored-by: Ron Pressler >Co-authored-by: Alan Bateman >Co-authored-by: Erik Österlund >Co-authored-by: Andrew Haley >Co-authored-by: Rickard Bäckman >Co-authored-by: Markus Grönlund >Co-authored-by: Leonid Mesnik >Co-authored-by: Serguei Spitsyn >Co-authored-by: Chris Plummer >Co-authored-by: Coleen Phillimore >Co-authored-by: Robbin Ehn >Co-authored-by: Stefan Karlsson >Co-authored-by: Thomas Schatzl >Co-authored-by: Sergey Kuksenko >Reviewed-by: lancea, eosterlund, rehn, sspitsyn, stefank, tschatzl, > dfuchs, lmesnik, dcubed, kevinw, amenkov, dlong, mchung, psandoz, bpb, > coleenp, smarks, egahlin, mseledtsov, coffeys, darcy > - 8282218: C1: Missing side effects of dynamic class loading during constant > linkage > >Reviewed-by: thartmann, kvn > - 8286342: ProblemList compiler/c2/irTests/TestEnumFinalFold.java > >Reviewed-by: mikael > - 8286263: compiler/c1/TestPinnedIntrinsics.java failed with > "RuntimeException: testCurrentTimeMillis failed with -3" > >Reviewed-by: thartmann, kvn > - 8285295: Need better testing for IdentityHashMap > >Reviewed-by: jpai, lancea > - 8286190: Add test to verify constant folding for Enum fields > >Reviewed-by: kvn, thartmann > - 8286154: Fix 3rd party notices in test files > >Reviewed-by: darcy, joehw, iris > - 8286291: G1: Remove unused segment allocator printouts > >Reviewed-by: ayang, iwalulya > - ... and 80 more: > https://git.openjdk.java.net/jdk/compare/f823bf84...5cef96f7 I brought in the changes from master after the Virtual Threads integration,
Re: RFR: 8283689: Update the foreign linker VM implementation [v6]
> Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over > commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited > resources to handle this. As such, this PR might fall over to 20. > > I've written up an overview of the Linker architecture here: > http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful > to read that first. > > This patch moves from the "legacy" implementation, to what is currently > implemented in the panama-foreign repo, except for replacing the use of > method handle combinators with ASM. That will come in a later path. To recap. > This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 > [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. > And VM stubs and Java code implementing the buffered invocation strategy has > been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method > handle linker was no longer needed and has been removed [6] (support might be > re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now > implements RuntimeBlob directly. Binding to java classes has been rewritten > to use javaClasses.h/cpp (this wasn't previously possible due to these java > classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java > changes to support (2). > > The original commit structure has been mostly retained, so it might be useful > to look at a specific commit, or the corresponding patch in the > [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) > repo as well. I've also left some inline comments to explain some of the > changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: > https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: > https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: > https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: > https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: > https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: > https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: > https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: > https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: > https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 Jorn Vernee has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains 20 new commits since the last revision: - Remove unneeded ComputeMoveOrder - Remove comment about native calls in lcm.cpp - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64 Reviewed-by: jvernee, mcimadamore - Update riscv and arm stubs - Remove spurious ProblemList change - Pass pointer to LogStream - Polish - Replace TraceNativeInvokers flag with unified logging - Fix other platforms, take 2 - Fix other platforms - ... and 10 more: https://git.openjdk.java.net/jdk/compare/f195789f...e84e3379 - Changes: - all: https://git.openjdk.java.net/jdk/pull/7959/files - new: https://git.openjdk.java.net/jdk/pull/7959/files/f195789f..e84e3379 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7959=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7959=04-05 Stats: 222764 lines in 3783 files changed: 157991 ins; 17628 del; 47145 mod Patch: https://git.openjdk.java.net/jdk/pull/7959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959 PR: https://git.openjdk.java.net/jdk/pull/7959
Re: RFR: 8283689: Update the foreign linker VM implementation [v5]
> Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over > commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited > resources to handle this. As such, this PR might fall over to 20. > > I've written up an overview of the Linker architecture here: > http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful > to read that first. > > This patch moves from the "legacy" implementation, to what is currently > implemented in the panama-foreign repo, except for replacing the use of > method handle combinators with ASM. That will come in a later path. To recap. > This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 > [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. > And VM stubs and Java code implementing the buffered invocation strategy has > been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method > handle linker was no longer needed and has been removed [6] (support might be > re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now > implements RuntimeBlob directly. Binding to java classes has been rewritten > to use javaClasses.h/cpp (this wasn't previously possible due to these java > classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java > changes to support (2). > > The original commit structure has been mostly retained, so it might be useful > to look at a specific commit, or the corresponding patch in the > [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) > repo as well. I've also left some inline comments to explain some of the > changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: > https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: > https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: > https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: > https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: > https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: > https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: > https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: > https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: > https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Revert "Merge branch 'master' into JEP-19-VM-IMPL2" This reverts commit 98864b62749f3a482dbb0516a987f38904142042, reversing changes made to a7b9f131c4cc5fbec81811941e5c3e164838a88d. - Changes: - all: https://git.openjdk.java.net/jdk/pull/7959/files - new: https://git.openjdk.java.net/jdk/pull/7959/files/5cef96f7..f195789f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7959=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7959=03-04 Stats: 332953 lines in 4896 files changed: 22818 ins; 256179 del; 53956 mod Patch: https://git.openjdk.java.net/jdk/pull/7959.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7959/head:pull/7959 PR: https://git.openjdk.java.net/jdk/pull/7959
Re: RFR: 8283689: Update the foreign linker VM implementation [v4]
> Hi, > > This PR updates the VM implementation of the foreign linker, by bringing over > commits from the panama-foreign repo. > > This is split off from the main JEP integration for 19, since we have limited > resources to handle this. As such, this PR might fall over to 20. > > I've written up an overview of the Linker architecture here: > http://cr.openjdk.java.net/~jvernee/docs/FL_Overview.html it might be useful > to read that first. > > This patch moves from the "legacy" implementation, to what is currently > implemented in the panama-foreign repo, except for replacing the use of > method handle combinators with ASM. That will come in a later path. To recap. > This PR contains the following changes: > > 1. VM stubs for downcalls are now generated up front, instead of lazily by C2 > [1]. > 2. the VM support for upcalls/downcalls now support all possible call shapes. > And VM stubs and Java code implementing the buffered invocation strategy has > been removed [2], [3], [4], [5]. > 3. The existing C2 intrinsification support for the `linkToNative` method > handle linker was no longer needed and has been removed [6] (support might be > re-added in another form later). > 4. Some other cleanups, such as: OptimizedEntryBlob (for upcalls) now > implements RuntimeBlob directly. Binding to java classes has been rewritten > to use javaClasses.h/cpp (this wasn't previously possible due to these java > classes being in an incubator module) [7], [8], [9]. > > While the patch mostly consists of VM changes, there are also some Java > changes to support (2). > > The original commit structure has been mostly retained, so it might be useful > to look at a specific commit, or the corresponding patch in the > [panama-foreign](https://github.com/openjdk/panama-foreign/pulls?q=is%3Apr) > repo as well. I've also left some inline comments to explain some of the > changes, which will hopefully make reviewing easier. > > Testing: Tier1-4 > > Thanks, > Jorn > > [1]: > https://github.com/openjdk/jdk/pull/7959/commits/048b88156814579dca1f70742061ad24942fd358 > [2]: > https://github.com/openjdk/jdk/pull/7959/commits/2fbbef472b4c2b4fee5ede2f18cd81ab61e88f49 > [3]: > https://github.com/openjdk/jdk/pull/7959/commits/8a957a4ed9cc8d1f708ea8777212eb51ab403dc3 > [4]: > https://github.com/openjdk/jdk/pull/7959/commits/35ba1d964f1de4a77345dc58debe0565db4b0ff3 > [5]: > https://github.com/openjdk/jdk/pull/7959/commits/4e72aae22920300c5ffa16fed805b62ed9092120 > [6]: > https://github.com/openjdk/jdk/pull/7959/commits/08e22e1b468c5c8f0cfd7135c72849944068aa7a > [7]: > https://github.com/openjdk/jdk/pull/7959/commits/451cd9edf54016c182dab21a8b26bd8b609fc062 > [8]: > https://github.com/openjdk/jdk/pull/7959/commits/4c851d2795afafec3a3ab17f4142ee098692068f > [9]: > https://github.com/openjdk/jdk/pull/7959/commits/d025377799424f31512dca2ffe95491cd5ae22f9 Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 90 commits: - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2 - Merge branch 'master' into JEP-19-VM-IMPL2 - 8284161: Implementation of Virtual Threads (Preview) Co-authored-by: Ron Pressler Co-authored-by: Alan Bateman Co-authored-by: Erik Österlund Co-authored-by: Andrew Haley Co-authored-by: Rickard Bäckman Co-authored-by: Markus Grönlund Co-authored-by: Leonid Mesnik Co-authored-by: Serguei Spitsyn Co-authored-by: Chris Plummer Co-authored-by: Coleen Phillimore Co-authored-by: Robbin Ehn Co-authored-by: Stefan Karlsson Co-authored-by: Thomas Schatzl Co-authored-by: Sergey Kuksenko Reviewed-by: lancea, eosterlund, rehn, sspitsyn, stefank, tschatzl, dfuchs, lmesnik, dcubed, kevinw, amenkov, dlong, mchung, psandoz, bpb, coleenp, smarks, egahlin, mseledtsov, coffeys, darcy - 8282218: C1: Missing side effects of dynamic class loading during constant linkage Reviewed-by: thartmann, kvn - 8286342: ProblemList compiler/c2/irTests/TestEnumFinalFold.java Reviewed-by: mikael - 8286263: compiler/c1/TestPinnedIntrinsics.java failed with "RuntimeException: testCurrentTimeMillis failed with -3" Reviewed-by: thartmann, kvn - 8285295: Need better testing for IdentityHashMap Reviewed-by: jpai, lancea - 8286190: Add test to verify constant folding for Enum fields Reviewed-by: kvn, thartmann - 8286154: Fix 3rd party notices in test files Reviewed-by: darcy, joehw, iris - 8286291: G1: Remove unused segment allocator printouts Reviewed-by: ayang, iwalulya - ... and 80 more: https://git.openjdk.java.net/jdk/compare/f823bf84...5cef96f7 - Changes: https://git.openjdk.java.net/jdk/pull/7959/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7959=03 Stats: 117182 lines in 1482 files changed: 100895 ins; 8432 del; 7855 mod Patch: https://git.openjdk.java.net/jdk/pull/7959.diff Fetch: git fetch
Re: RFR: 8262889: Compiler implementation for Record Patterns [v3]
> 8262889: Compiler implementation for Record Patterns > > A first version of a patch that introduces record patterns into javac as a > preview feature. For the specification, please see: > http://cr.openjdk.java.net/~gbierman/jep427+405/jep427+405-20220426/specs/patterns-switch-record-patterns-jls.html > > There are two notable tricky parts: > -in the parser, it was necessary to improve the `analyzePattern` method to > handle nested/record patterns, while still keeping error recovery reasonable > -in the `TransPatterns`, the desugaring of the record patterns is very > straightforward - effectivelly the record patterns are desugared into > guards/conditions. This will likely be improved in some future version/preview > > `MatchException` has been extended to cover additional cases related to > record patterns. Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision: - Fixing guards after record patterns. - Raw types are not allowed in record patterns. - Changes: - all: https://git.openjdk.java.net/jdk/pull/8516/files - new: https://git.openjdk.java.net/jdk/pull/8516/files/90b37c3a..0e384fb3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8516=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8516=01-02 Stats: 191 lines in 11 files changed: 157 ins; 22 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/8516.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8516/head:pull/8516 PR: https://git.openjdk.java.net/jdk/pull/8516
Re: RFR: 8286294 : ForkJoinPool.commonPool().close() spins [v4]
> Changes ForkJoinPool.close spec and code to trap close as a no-op if called > on common pool Doug Lea has updated the pull request incrementally with three additional commits since the last revision: - Accommodate restrictive SecurityManagers - merge with loom updates Merge remote-tracking branch 'refs/remotes/origin/JDK-8286294' into JDK-8286294 - Fix testLazySubmit; enable suite - Changes: - all: https://git.openjdk.java.net/jdk/pull/8577/files - new: https://git.openjdk.java.net/jdk/pull/8577/files/c276385c..9a0d27f4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8577=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8577=02-03 Stats: 21 lines in 1 file changed: 12 ins; 4 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8577.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8577/head:pull/8577 PR: https://git.openjdk.java.net/jdk/pull/8577
Re: RFR: 8286294 : ForkJoinPool.commonPool().close() spins [v3]
> Changes ForkJoinPool.close spec and code to trap close as a no-op if called > on common pool Doug Lea 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 three additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8286294 - Fix doc types - Override close as explicit no-op for common pool - Changes: - all: https://git.openjdk.java.net/jdk/pull/8577/files - new: https://git.openjdk.java.net/jdk/pull/8577/files/5ceb0794..c276385c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8577=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8577=01-02 Stats: 103528 lines in 1259 files changed: 93903 ins; 4285 del; 5340 mod Patch: https://git.openjdk.java.net/jdk/pull/8577.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8577/head:pull/8577 PR: https://git.openjdk.java.net/jdk/pull/8577
Integrated: 8284161: Implementation of Virtual Threads (Preview)
On Fri, 8 Apr 2022 13:43:39 GMT, Alan Bateman wrote: > This is the implementation of JEP 425: Virtual Threads (Preview). > > 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 > can add additional labels, if required, as the PR progresses. > > 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 Extent Locals. This is to > make life a bit easier and avoid having to separate VM changes and juggle > branches at this time. This pull request has now been integrated. Changeset: 9583e365 Author:Alan Bateman URL: https://git.openjdk.java.net/jdk/commit/9583e3657e43cc1c6f2101a64534564db2a9bd84 Stats: 99468 lines in 1133 files changed: 91198 ins; 3598 del; 4672 mod 8284161: Implementation of Virtual Threads (Preview) Co-authored-by: Ron Pressler Co-authored-by: Alan Bateman Co-authored-by: Erik Österlund Co-authored-by: Andrew Haley Co-authored-by: Rickard Bäckman Co-authored-by: Markus Grönlund Co-authored-by: Leonid Mesnik Co-authored-by: Serguei Spitsyn Co-authored-by: Chris Plummer Co-authored-by: Coleen Phillimore Co-authored-by: Robbin Ehn Co-authored-by: Stefan Karlsson Co-authored-by: Thomas Schatzl Co-authored-by: Sergey Kuksenko Reviewed-by: lancea, eosterlund, rehn, sspitsyn, stefank, tschatzl, dfuchs, lmesnik, dcubed, kevinw, amenkov, dlong, mchung, psandoz, bpb, coleenp, smarks, egahlin, mseledtsov, coffeys, darcy - PR: https://git.openjdk.java.net/jdk/pull/8166
Re: RFR: 8285517: System.getenv() returns unexpected value if environment variable has non ASCII character [v2]
On Mon, 2 May 2022 15:00:07 GMT, Roger Riggs wrote: >> Ichiroh Takiguchi has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8285517: System.getenv() returns unexpected value if environment variable >> has non ASCII character > > Can you clarify the use of different charset properties for the > ProcessEnvironment vs the CommandLine strings? > > They are used to decode or encode strings in the APIs to native functions > respectively. > If I understand `native.encoding` was introduced to reflect the default > encoding of file contents, while `sun.jnu.encoding` is used to encode > filenames. > > I think I would have expected to see `sun.jnu.encoding` to be used in all > contexts when encoding/decoding strings to the native representations. > (Assuming its not required for backward compatibility). Hello @RogerRiggs . When I executed the new testcase with JDK18.0.1, I got following errors: ERROR: argument EUC_JP_TEXT is: Actual: \u7FB2\u221A\uFFFD Expected: \u6F22\u5B57 ERROR: Variable EUC_JP_TEXT is encoded by: Actual: \xE6\xBC\xA2\xE5\xAD\x97 Expected: \xB4\xC1\xBB\xFA ERROR: Value EUC_JP_TEXT is encoded by: Actual: \xE6\xBC\xA2\xE5\xAD\x97 Expected: \xB4\xC1\xBB\xFA The new testcase verifies internal byte data for EUC_JP_TEXT environment variable and value. - PR: https://git.openjdk.java.net/jdk/pull/8378
Re: RFR: 8285517: System.getenv() returns unexpected value if environment variable has non ASCII character [v5]
On Fri, 6 May 2022 15:13:38 GMT, Roger Riggs wrote:
>> Ichiroh Takiguchi has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8285517: System.getenv() returns unexpected value if environment variable
>> has non ASCII character
>
> test/jdk/java/lang/ProcessBuilder/Basic.java line 606:
>
>> 604: ? Charset.forName(jnuEncoding, Charset.defaultCharset())
>> 605: : Charset.defaultCharset();
>> 606: if (new String(tested.getBytes(cs), cs).equals(tested)) {
>
> Isn't it always true that the round trip encoding to bytes and back (using
> the same Charset) to a string is equal()?
> And if it is always true, then the if(...) can be removed.
Above code is related to following code:
https://github.com/openjdk/jdk/blob/5212535a276a92d96ca20bdcfccfbce956febdb1/test/jdk/java/lang/ProcessBuilder/Basic.java#L1569-L1570
If `Charset.defaultCharset()` is `UTF-8`, this code is not skipped.
I think this code will be skipped on JDK17 on C locale.
-
PR: https://git.openjdk.java.net/jdk/pull/8378
Re: RFR: 8285517: System.getenv() returns unexpected value if environment variable has non ASCII character [v6]
> On JDK19 with Linux ja_JP.eucjp locale, > System.getenv() returns unexpected value if environment variable has Japanese > EUC characters. > It seems this issue happens because of JEP 400. > Arguments for ProcessBuilder have same kind of issue. Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision: 8285517: System.getenv() returns unexpected value if environment variable has non ASCII character - Changes: - all: https://git.openjdk.java.net/jdk/pull/8378/files - new: https://git.openjdk.java.net/jdk/pull/8378/files/5bd8492f..994a7fd0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8378=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8378=04-05 Stats: 82 lines in 1 file changed: 47 ins; 12 del; 23 mod Patch: https://git.openjdk.java.net/jdk/pull/8378.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8378/head:pull/8378 PR: https://git.openjdk.java.net/jdk/pull/8378
Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v14]
> This is the implementation of JEP 425: Virtual Threads (Preview). > > 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 > can add additional labels, if required, as the PR progresses. > > 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 Extent 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 pull request now contains 23 commits: - Refresh 4e99b5185eef9398c4cc4e90544de4a3153d61a9 - Merge with 5212535a276a92d96ca20bdcfccfbce956febdb1 - Refresh 6ace49bf42e5504c69fa11c564e8e865c0a95fb3 - Merge with 9425ab2b43b649bd591706bfc820e9c8795a6fdf - Refresh 12aa09ce7efd48425cc080d0b8761aca0f3e215f - Merge with 1bb4de2e2868a539846ec48dd43fd623c2ba69a5 - Refresh d77f7a49af75bcc5b20686805ff82a93a20dde05 - Merge with 4b2c82200fdc01de868cf414e40a4d891e753f89 - Refresh 6091080db743ece5f1b2111fcc35a5f2179a403a - Merge with cfcba1fccc8e3e6a68e1cb1826b70e076d5d83c4 - ... and 13 more: https://git.openjdk.java.net/jdk/compare/5212535a...df43e6fc - Changes: https://git.openjdk.java.net/jdk/pull/8166/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8166=13 Stats: 99468 lines in 1133 files changed: 91198 ins; 3598 del; 4672 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
