From duke at openjdk.java.net Mon Nov 1 17:06:51 2021 From: duke at openjdk.java.net (duke) Date: Mon, 1 Nov 2021 17:06:51 GMT Subject: git: openjdk/loom: fibers: 91 new changesets Message-ID: <3d2e2525-c89a-4e5f-a521-4c5463918d96@openjdk.java.net> Changeset: 043cde22 Author: Daniel Jelinski Committer: Daniel Fuchs Date: 2021-10-20 14:06:08 +0000 URL: https://git.openjdk.java.net/loom/commit/043cde22d4d6bd975e75daa9ad52770cf79df934 8275319: java.net.NetworkInterface throws java.lang.Error instead of SocketException Reviewed-by: alanb, dfuchs ! src/java.base/windows/native/libnet/NetworkInterface.c ! src/java.base/windows/native/libnet/NetworkInterface_winXP.c Changeset: 35e5bb5f Author: Jaikiran Pai Date: 2021-10-20 15:10:28 +0000 URL: https://git.openjdk.java.net/loom/commit/35e5bb5f59c01a1b07893780fa73f93c2abab653 8269336: Malformed jdk.serialFilter incorrectly handled Reviewed-by: rriggs ! src/java.base/share/classes/java/io/ObjectInputFilter.java + test/jdk/java/io/Serializable/serialFilter/InvalidGlobalFilterTest.java Changeset: 7e28bdd1 Author: Thomas Schatzl Date: 2021-10-20 15:33:50 +0000 URL: https://git.openjdk.java.net/loom/commit/7e28bdd1eb8276a5f78802febc9bd6f1cf597f55 8275055: Improve HeapRegionRemSet::split_card() Reviewed-by: sjohanss, ayang + src/hotspot/share/gc/g1/g1CardSetContainers.cpp ! src/hotspot/share/gc/g1/g1CardSetContainers.hpp ! src/hotspot/share/gc/g1/g1CardSetContainers.inline.hpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/heapRegionRemSet.cpp ! src/hotspot/share/gc/g1/heapRegionRemSet.hpp ! src/hotspot/share/gc/g1/heapRegionRemSet.inline.hpp Changeset: bbc60611 Author: Harold Seigel Date: 2021-10-20 15:48:43 +0000 URL: https://git.openjdk.java.net/loom/commit/bbc606117fcd8b48fc8f830c50cf7eb573da1c4c 8272614: Unused parameters in MethodHandleNatives linking methods Reviewed-by: dholmes, lfoltan ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/java.base/share/classes/java/lang/invoke/MethodHandleNatives.java Changeset: 46b5bfbc Author: Alexander Zvegintsev Date: 2021-10-20 16:44:47 +0000 URL: https://git.openjdk.java.net/loom/commit/46b5bfbc38f14607f0db686a42f1fa96d2f61891 8233648: [TESTBUG] DefaultMenuBarTest.java failing on macos Reviewed-by: pbansal, serb, psadhukhan, prr ! test/jdk/ProblemList.txt ! test/jdk/com/apple/eawt/DefaultMenuBar/DefaultMenuBarTest.java Changeset: 0021a2f4 Author: Mikhailo Seledtsov Date: 2021-10-20 18:16:58 +0000 URL: https://git.openjdk.java.net/loom/commit/0021a2f462eab38b1a4c5c38736dfc7735f3c00a 8275449: Add linux-aarch64-zero build profile Reviewed-by: erikj ! make/autoconf/lib-ffi.m4 ! make/conf/jib-profiles.js Changeset: 913f9281 Author: Markus Karg Committer: Brian Burkhalter Date: 2021-10-20 18:30:52 +0000 URL: https://git.openjdk.java.net/loom/commit/913f9281ada7ebb670ed93a088d28afeaa635eb7 8273507: Convert test/jdk/java/nio/channels/Channels/TransferTo.java to TestNG test Reviewed-by: shade, bpb ! test/jdk/java/nio/channels/Channels/TransferTo.java Changeset: d1e3ca4e Author: Alisen Chung Committer: Phil Race Date: 2021-10-20 18:51:00 +0000 URL: https://git.openjdk.java.net/loom/commit/d1e3ca4ee35bf4c2ce9b6dae2518f533f36a98dd 8233558: [TESTBUG] WindowOwnedByEmbeddedFrameTest.java fails on macos Reviewed-by: serb, kizune, prr ! test/jdk/ProblemList.txt ! test/jdk/java/awt/Window/WindowOwnedByEmbeddedFrameTest/WindowOwnedByEmbeddedFrameTest.java Changeset: cea3f010 Author: Igor Ignatyev Date: 2021-10-20 19:24:46 +0000 URL: https://git.openjdk.java.net/loom/commit/cea3f010460c4b45e76bfac8a5b193c49fdd274a 8275666: serviceability/jvmti/GetObjectSizeClass.java shouldn't have vm.flagless Reviewed-by: lmesnik ! test/hotspot/jtreg/serviceability/jvmti/GetObjectSizeClass.java Changeset: af7c56b8 Author: vamsi-parasa Committer: Sandhya Viswanathan Date: 2021-10-20 22:40:51 +0000 URL: https://git.openjdk.java.net/loom/commit/af7c56b85bb2828a9d68f9e1c753a4adfa7ebb4f 8275167: x86 intrinsic for unsignedMultiplyHigh Reviewed-by: kvn, sviswanathan ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/classes.hpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/library_call.hpp ! src/hotspot/share/opto/mulnode.cpp ! src/hotspot/share/opto/mulnode.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/java.base/share/classes/java/lang/Math.java ! test/micro/org/openjdk/bench/java/lang/MathBench.java Changeset: c7a80e60 Author: Hamlin Li Date: 2021-10-21 01:16:10 +0000 URL: https://git.openjdk.java.net/loom/commit/c7a80e60e2e201b573d4653fa978df527addc8a6 8275607: G1: G1CardSetAllocator::drop_all needs to call G1SegmentedArray::drop_all Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1CardSetMemory.cpp Changeset: a120937e Author: Hamlin Li Date: 2021-10-21 01:17:52 +0000 URL: https://git.openjdk.java.net/loom/commit/a120937e8194a897ed4af9e7a2e33beb857987e5 8274988: G1: refine G1SegmentedArrayAllocOptions and G1CardSetAllocOptions Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1CardSetMemory.hpp ! src/hotspot/share/gc/g1/g1SegmentedArray.hpp Changeset: 09f5235c Author: Stefan Karlsson Date: 2021-10-21 07:47:10 +0000 URL: https://git.openjdk.java.net/loom/commit/09f5235c65de546640d5f923fa9369e28643c6ed 8275405: Linking error for classes with lambda template parameters and virtual functions Reviewed-by: ihse, pliden ! make/hotspot/lib/JvmMapfile.gmk Changeset: 0c3eaea1 Author: Alexander Zuev Date: 2021-10-21 09:51:18 +0000 URL: https://git.openjdk.java.net/loom/commit/0c3eaea11c83b3ee63d80de85d58a1cb6f870fd3 8168388: GetMousePositionTest fails with the message "Mouse position should not be null" Reviewed-by: psadhukhan, serb ! test/jdk/ProblemList.txt ! test/jdk/java/awt/Mouse/GetMousePositionTest/GetMousePositionWithOverlay.java Changeset: c41ce6d1 Author: Markus Gr?nlund Date: 2021-10-21 10:12:19 +0000 URL: https://git.openjdk.java.net/loom/commit/c41ce6d159e59a8c05dbeacde2d2612b58733d46 8275415: Prepare Leak Profiler for Lilliput Reviewed-by: rkennke ! src/hotspot/share/jfr/leakprofiler/chains/edgeStore.cpp ! src/hotspot/share/jfr/leakprofiler/chains/edgeStore.hpp ! src/hotspot/share/jfr/leakprofiler/checkpoint/eventEmitter.cpp Changeset: 819d2df8 Author: Coleen Phillimore Date: 2021-10-21 11:28:22 +0000 URL: https://git.openjdk.java.net/loom/commit/819d2df8b01e04bcc89a0a995e21b68799f890be 8274794: Print all owned locks in hs_err file Reviewed-by: stuefe, dholmes ! src/hotspot/share/runtime/mutex.cpp ! src/hotspot/share/runtime/mutex.hpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp ! src/hotspot/share/utilities/vmError.cpp ! test/hotspot/jtreg/runtime/ErrorHandling/ErrorFileOverwriteTest.java + test/hotspot/jtreg/runtime/ErrorHandling/ErrorFileScanner.java + test/hotspot/jtreg/runtime/ErrorHandling/TestErrorFileMutex.java Changeset: cd07b3ca Author: Coleen Phillimore Date: 2021-10-21 11:46:24 +0000 URL: https://git.openjdk.java.net/loom/commit/cd07b3cab00e6656e73a29f82210e2dedf26df8c 8257534: misc tests failed with "NoClassDefFoundError: Could not initialize class java.util.concurrent.ThreadLocalRandom" Reviewed-by: hseigel ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/gp/GarbageUtils.java Changeset: 60cb27dc Author: Kim Barrett Date: 2021-10-21 13:28:25 +0000 URL: https://git.openjdk.java.net/loom/commit/60cb27dcda475a66e329359ac1ee3ffcde95c657 8275426: PretouchTask num_chunks calculation can overflow Reviewed-by: ayang, tschatzl ! src/hotspot/share/gc/shared/pretouchTask.cpp Changeset: 45ce06c9 Author: Evan Whelan Committer: Sean Coffey Date: 2021-10-21 13:33:21 +0000 URL: https://git.openjdk.java.net/loom/commit/45ce06c9f3e9bee7d4bda313c38f0f0e8786a4db 8274779: HttpURLConnection: HttpClient and HttpsClient incorrectly check request method when set to POST Reviewed-by: dfuchs, coffeys, vtewari, michaelm ! src/java.base/share/classes/sun/net/www/http/HttpClient.java ! src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java + test/jdk/sun/net/www/http/RequestMethodCheck/RequestMethodEquality.java + test/jdk/sun/net/www/http/RequestMethodCheck/java.base/sun/net/www/http/HttpClientAccess.java Changeset: e39bdc9d Author: Harold Seigel Date: 2021-10-21 13:50:32 +0000 URL: https://git.openjdk.java.net/loom/commit/e39bdc9ddb7ba50160d07a27e6038cdea6a594a8 8274714: Incorrect verifier protected access error message Reviewed-by: dholmes, coleenp ! src/hotspot/share/classfile/verifier.cpp + test/hotspot/jtreg/runtime/verifier/PutfieldProtectedTest.java + test/hotspot/jtreg/runtime/verifier/putfieldProtected.jasm Changeset: d589b664 Author: Weijun Wang Date: 2021-10-21 14:04:48 +0000 URL: https://git.openjdk.java.net/loom/commit/d589b664cc809aea39ec094e99b1898df1bf3c19 8270380: Change the default value of the java.security.manager system property to disallow Reviewed-by: lancea, mullan, rriggs ! src/java.base/share/classes/java/lang/SecurityManager.java ! src/java.base/share/classes/java/lang/System.java ! test/jdk/java/lang/System/AllowSecurityManager.java ! test/jdk/java/lang/System/SecurityManagerWarnings.java ! test/jdk/sun/security/pkcs11/KeyStore/Basic.java ! test/jdk/sun/security/pkcs11/Provider/MultipleLogins.sh Changeset: 3b0ce23b Author: Christian Hagedorn Date: 2021-10-21 14:05:45 +0000 URL: https://git.openjdk.java.net/loom/commit/3b0ce23bcd827d0998fe9b43e5b0220c915dab21 8274888: Dump "-DReproduce=true" to the test VM command line output Reviewed-by: thartmann, kvn ! test/hotspot/jtreg/compiler/lib/ir_framework/driver/TestVMProcess.java Changeset: 3cb241a9 Author: Joe Darcy Date: 2021-10-21 15:25:10 +0000 URL: https://git.openjdk.java.net/loom/commit/3cb241a91fd2cc6b0b3b333288028694e60f723f 8275686: Suppress warnings on non-serializable non-transient instance fields in java.rmi Reviewed-by: bpb, iris, rriggs ! src/java.rmi/share/classes/sun/rmi/server/UnicastRef.java Changeset: 0761a4b9 Author: Joe Darcy Date: 2021-10-21 15:26:07 +0000 URL: https://git.openjdk.java.net/loom/commit/0761a4b915217abb08ef9b5c1a60878aedf5572c 8275688: Suppress warnings on non-serializable non-transient instance fields in DualPivotQuicksort Reviewed-by: rriggs ! src/java.base/share/classes/java/util/DualPivotQuicksort.java Changeset: af146501 Author: Mikhailo Seledtsov Date: 2021-10-21 15:31:03 +0000 URL: https://git.openjdk.java.net/loom/commit/af14650127de47058b958be411503584c0ba6323 8275569: Add linux-aarch64 to test-make profiles Reviewed-by: ihse ! make/conf/jib-profiles.js Changeset: bef8cf1b Author: Albert Mingkun Yang Date: 2021-10-21 15:49:21 +0000 URL: https://git.openjdk.java.net/loom/commit/bef8cf1ba14d3846977942844f341f5c5a1f44c4 8275714: G1: remove unused variable in G1Policy::transfer_survivors_to_cset Reviewed-by: tschatzl ! src/hotspot/share/gc/g1/g1Policy.cpp Changeset: 49f9d803 Author: Sean Mullan Date: 2021-10-21 17:28:40 +0000 URL: https://git.openjdk.java.net/loom/commit/49f9d8031e9c678e20dcfc1ba06758b511a26b07 8243585: AlgorithmChecker::check throws confusing exception when it rejects the signer key Reviewed-by: ascarpino ! src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.java ! src/java.base/share/classes/sun/security/provider/certpath/CertPathConstraintsParameters.java ! src/java.base/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java ! src/java.base/share/classes/sun/security/util/AlgorithmDecomposer.java ! src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java ! test/jdk/sun/security/ssl/SSLContextImpl/TrustTrustedCert.java ! test/jdk/sun/security/tools/jarsigner/CheckSignerCertChain.java ! test/jdk/sun/security/tools/jarsigner/Warning.java Changeset: 7dd82374 Author: Yumin Qi Date: 2021-10-21 18:30:21 +0000 URL: https://git.openjdk.java.net/loom/commit/7dd823740f7bfc55f456a5c8c199475cc85dfea3 8275084: CDS warning when building with LOG=debug Reviewed-by: dholmes, iklam ! src/hotspot/share/cds/classListWriter.cpp Changeset: 0961de47 Author: Dean Long Date: 2021-10-21 19:02:38 +0000 URL: https://git.openjdk.java.net/loom/commit/0961de47de1bf4379089e010978bcb4708fde767 8275347: ciReplay: staticfield lines not properly terminated Reviewed-by: neliasso, chagedorn ! src/hotspot/share/ci/ciInstanceKlass.cpp ! src/hotspot/share/ci/ciReplay.cpp ! test/hotspot/jtreg/compiler/ciReplay/CiReplayBase.java Changeset: 4e9dd4bd Author: Andrey Turbanov Committer: Mandy Chung Date: 2021-10-21 20:52:31 +0000 URL: https://git.openjdk.java.net/loom/commit/4e9dd4bddb888717d774147d4ba1acecc750629c 8275384: Change nested classes in jdk.jconsole to static nested classes Reviewed-by: alanb, sspitsyn, mchung ! src/jdk.jconsole/share/classes/sun/tools/jconsole/MaximizableInternalFrame.java ! src/jdk.jconsole/share/classes/sun/tools/jconsole/MemoryTab.java ! src/jdk.jconsole/share/classes/sun/tools/jconsole/ThreadTab.java ! src/jdk.jconsole/share/classes/sun/tools/jconsole/inspector/XMBeanAttributes.java ! src/jdk.jconsole/share/classes/sun/tools/jconsole/inspector/XMBeanNotifications.java Changeset: 6a466fe7 Author: Joe Darcy Date: 2021-10-21 21:11:01 +0000 URL: https://git.openjdk.java.net/loom/commit/6a466fe7ae281967d1cc4c8029b306f2d66567c9 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type Reviewed-by: erikj, sspitsyn, jlahoda, vromero, rriggs, smarks ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties ! src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/OptionException.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/ConstantPool.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/InternalError.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/JavapTask.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsTask.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/MultiReleaseException.java + test/langtools/tools/javac/diags/examples/ImproperSPF.java ! test/langtools/tools/javac/diags/examples/ImproperSVUID.java + test/langtools/tools/javac/diags/examples/IneffectualSerialEnum.java + test/langtools/tools/javac/diags/examples/IneffectualSerialExtern.java + test/langtools/tools/javac/diags/examples/IneffectualSerialRecord.java + test/langtools/tools/javac/diags/examples/SerialInterfaceMethodsAndFields.java + test/langtools/tools/javac/diags/examples/SerialMissingNoArgCtor.java + test/langtools/tools/javac/diags/examples/SerialNonPrivateMethod.java + test/langtools/tools/javac/warnings/Serial/CtorAccess.java + test/langtools/tools/javac/warnings/Serial/CtorAccess.out + test/langtools/tools/javac/warnings/Serial/DeepNestingSuppression.java + test/langtools/tools/javac/warnings/Serial/DeepNestingSuppression.out + test/langtools/tools/javac/warnings/Serial/EnumSerial.java + test/langtools/tools/javac/warnings/Serial/EnumSerial.out + test/langtools/tools/javac/warnings/Serial/Extern.java + test/langtools/tools/javac/warnings/Serial/Extern.out + test/langtools/tools/javac/warnings/Serial/ImproperReturnTypes.java + test/langtools/tools/javac/warnings/Serial/ImproperReturnTypes.out + test/langtools/tools/javac/warnings/Serial/ImproperSerialPF.java + test/langtools/tools/javac/warnings/Serial/ImproperSerialPF.out + test/langtools/tools/javac/warnings/Serial/InstanceField.java + test/langtools/tools/javac/warnings/Serial/InstanceField.out + test/langtools/tools/javac/warnings/Serial/InterfaceFields.java + test/langtools/tools/javac/warnings/Serial/InterfaceFields.out + test/langtools/tools/javac/warnings/Serial/InterfaceNonPrivateMethods.java + test/langtools/tools/javac/warnings/Serial/InterfaceNonPrivateMethods.out + test/langtools/tools/javac/warnings/Serial/RecordSerial.java + test/langtools/tools/javac/warnings/Serial/RecordSerial.out + test/langtools/tools/javac/warnings/Serial/SerialMethodArity.java + test/langtools/tools/javac/warnings/Serial/SerialMethodArity.out + test/langtools/tools/javac/warnings/Serial/SerialMethodMods.java + test/langtools/tools/javac/warnings/Serial/SerialMethodMods.out + test/langtools/tools/javac/warnings/Serial/SerialMethodThrows.java + test/langtools/tools/javac/warnings/Serial/SerialMethodThrows.out Changeset: c978ca87 Author: Sergey Bylokhov Date: 2021-10-22 03:05:16 +0000 URL: https://git.openjdk.java.net/loom/commit/c978ca87de2d9152345dfd85983278c42bb28cd3 8275344: -Xcheck:jni produces some warnings in the LCMS.c Reviewed-by: azvegint, prr, kizune ! src/java.desktop/share/native/liblcms/LCMS.c ! test/jdk/java/awt/color/ICC_ColorSpace/MTTransformReplacedProfile.java Changeset: fab3d6c6 Author: David Holmes Date: 2021-10-22 04:47:53 +0000 URL: https://git.openjdk.java.net/loom/commit/fab3d6c6122b2ce23dfa12db489923d8261f8f35 8275761: Backout: JDK-8274794 Print all owned locks in hs_err file Reviewed-by: mikael ! src/hotspot/share/runtime/mutex.cpp ! src/hotspot/share/runtime/mutex.hpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp ! src/hotspot/share/utilities/vmError.cpp ! test/hotspot/jtreg/runtime/ErrorHandling/ErrorFileOverwriteTest.java - test/hotspot/jtreg/runtime/ErrorHandling/ErrorFileScanner.java - test/hotspot/jtreg/runtime/ErrorHandling/TestErrorFileMutex.java Changeset: 1efe946d Author: Stefan Karlsson Date: 2021-10-22 08:20:43 +0000 URL: https://git.openjdk.java.net/loom/commit/1efe946db77e38507511a9c898b8b59fe9ba1aeb 8275712: Hashtable literal_size functions are broken Reviewed-by: coleenp, zgu ! src/hotspot/share/classfile/stringTable.cpp ! src/hotspot/share/utilities/hashtable.cpp Changeset: b2128a96 Author: Andy Herrick Date: 2021-10-22 12:17:45 +0000 URL: https://git.openjdk.java.net/loom/commit/b2128a96670daeca93aca84ee7613b2b337ddfa4 8263155: Allow additional contents for DMG Reviewed-by: asemenyuk, almatvee ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacDmgBundler.java ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/DMGsetup.scpt ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/DeployParams.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/StandardBundlerParam.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/ValidOptions.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacHelper.java + test/jdk/tools/jpackage/macosx/DmgContentTest.java Changeset: dd622e55 Author: Albert Mingkun Yang Date: 2021-10-22 12:47:35 +0000 URL: https://git.openjdk.java.net/loom/commit/dd622e55c01966f8b2deddaba09164a0a302df2e 8275783: G1: fix incorrect region type documentation in HeapRegionType Reviewed-by: tschatzl ! src/hotspot/share/gc/g1/heapRegionType.hpp Changeset: 4e647aa5 Author: Albert Mingkun Yang Date: 2021-10-22 13:01:24 +0000 URL: https://git.openjdk.java.net/loom/commit/4e647aa584cf12dae76e81e203ad4f1ebc08c1a2 8275416: G1: remove unnecessary make_referent_alive in precleaning phase Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/shared/referenceProcessor.cpp ! src/hotspot/share/gc/shared/referenceProcessor.hpp Changeset: 4dec8fc4 Author: Doug Simon Date: 2021-10-22 16:20:31 +0000 URL: https://git.openjdk.java.net/loom/commit/4dec8fc4cc2b1762fba554d0401da8be0d6d1166 8275645: [JVMCI] avoid unaligned volatile reads on AArch64 Reviewed-by: kvn, never ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/CompilerToVM.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstantReflectionProvider.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMemoryAccessProviderImpl.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotObjectConstantImpl.java ! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.hotspot.test/src/jdk/vm/ci/hotspot/test/MemoryAccessProviderData.java Changeset: 88bbf3c2 Author: Wu Yan Committer: Naoto Sato Date: 2021-10-22 16:23:25 +0000 URL: https://git.openjdk.java.net/loom/commit/88bbf3c2e6ac9f6d88cbb361cfbb4c16bb8eafc1 8273111: Default timezone should return zone ID if /etc/localtime is valid but not canonicalization on linux Co-authored-by: Sun Jianye Reviewed-by: naoto, mli ! src/java.base/unix/native/libjava/TimeZone_md.c ! src/java.base/unix/native/libjava/canonicalize_md.c + src/java.base/unix/native/libjava/path_util.c = src/java.base/unix/native/libjava/path_util.h Changeset: 6523c558 Author: Phil Race Date: 2021-10-22 17:22:12 +0000 URL: https://git.openjdk.java.net/loom/commit/6523c558d92dedf350576126960dee6cff8f6067 8198336: java/awt/FontMetrics/FontCrash.java fails in headless mode Reviewed-by: serb ! src/java.desktop/share/classes/java/awt/Component.java ! src/java.desktop/share/classes/sun/font/SunFontManager.java ! src/java.desktop/windows/classes/sun/awt/windows/WToolkit.java ! test/jdk/ProblemList.txt - test/jdk/java/awt/FontMetrics/FontCrash.java Changeset: fec470f2 Author: Hai-May Chao Date: 2021-10-22 20:53:38 +0000 URL: https://git.openjdk.java.net/loom/commit/fec470f262d1df581f2a5fc2f0bdfea66757a8ad 8272163: Add -version option to keytool and jarsigner Reviewed-by: weijun ! src/java.base/share/classes/sun/security/tools/keytool/Main.java ! src/java.base/share/classes/sun/security/tools/keytool/Resources.java ! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java ! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java + test/jdk/sun/security/tools/jarsigner/VersionTest.java + test/jdk/sun/security/tools/keytool/VersionTest.java Changeset: c94dc2ab Author: Igor Ignatyev Date: 2021-10-23 03:59:55 +0000 URL: https://git.openjdk.java.net/loom/commit/c94dc2ab60f0548afa868e41a0b87a68030e0cac 8272854: split runtime/CommandLine/PrintTouchedMethods.java test Reviewed-by: iklam ! test/hotspot/jtreg/runtime/CommandLine/PrintTouchedMethods.java + test/hotspot/jtreg/runtime/CommandLine/PrintTouchedMethodsJcmd.java Changeset: 5bbe4cae Author: Sergey Tsypanov Committer: Stuart Marks Date: 2021-10-23 21:07:58 +0000 URL: https://git.openjdk.java.net/loom/commit/5bbe4cae8746765d2ce965b06fd1e5cf512326ae 8275293: A change done with JDK-8268764 mismatches the java.rmi.server.ObjID.hashCode spec Reviewed-by: rriggs, smarks ! src/java.rmi/share/classes/java/rmi/server/ObjID.java Changeset: 5dab76b9 Author: Hamlin Li Date: 2021-10-25 01:03:51 +0000 URL: https://git.openjdk.java.net/loom/commit/5dab76b939e381312ce5c89b9aebca628238a387 8275381: G1: refactor 2 constructors of G1CardSetConfiguration Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1CardSet.cpp ! src/hotspot/share/gc/g1/g1CardSet.hpp ! test/hotspot/gtest/gc/g1/test_g1CardSet.cpp Changeset: 1da5e6b0 Author: Christian Hagedorn Date: 2021-10-25 07:25:19 +0000 URL: https://git.openjdk.java.net/loom/commit/1da5e6b0e2c284c5dd295a0d48cc1c6c2fecf5b5 8275104: IR framework does not handle client VM builds correctly Reviewed-by: kvn, thartmann ! test/hotspot/jtreg/compiler/lib/ir_framework/flag/FlagVM.java ! test/hotspot/jtreg/compiler/lib/ir_framework/test/TestVM.java ! test/hotspot/jtreg/testlibrary_tests/ir_framework/examples/IRExample.java ! test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestCompLevels.java ! test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestDIgnoreCompilerControls.java ! test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestIRMatching.java ! test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestSanity.java ! test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestWithHelperClasses.java Changeset: f6232982 Author: Alexey Bakhtin Committer: Yuri Nesterenko Date: 2021-10-25 08:00:40 +0000 URL: https://git.openjdk.java.net/loom/commit/f6232982b91cb2314e96ddbde3984836a810a556 8271199: Mutual TLS handshake fails signing client certificate with custom sensitive PKCS11 key Reviewed-by: xuelei, valeriep ! src/java.base/share/classes/sun/security/rsa/RSAPSSSignature.java ! src/java.base/share/classes/sun/security/rsa/RSAPrivateCrtKeyImpl.java Changeset: 0bcc1749 Author: Stefan Karlsson Date: 2021-10-25 09:07:51 +0000 URL: https://git.openjdk.java.net/loom/commit/0bcc1749eaea20cb983a983073ad33d305681879 8275717: Reimplement STATIC_ASSERT to use static_assert Reviewed-by: stuefe, eosterlund, kbarrett ! src/hotspot/share/utilities/debug.hpp Changeset: 7f94302c Author: Albert Mingkun Yang Date: 2021-10-25 13:18:20 +0000 URL: https://git.openjdk.java.net/loom/commit/7f94302ceca001ded89ba9a653bf176ef90b16cd 8275511: G1: Rename needs_remset_update to remset_is_tracked in G1HeapRegionAttr Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp ! src/hotspot/share/gc/g1/g1CollectionSet.cpp ! src/hotspot/share/gc/g1/g1HeapRegionAttr.hpp ! src/hotspot/share/gc/g1/g1ParScanThreadState.inline.hpp ! src/hotspot/share/gc/g1/g1RemSet.cpp Changeset: f143d2a8 Author: Jaikiran Pai Date: 2021-10-25 14:24:05 +0000 URL: https://git.openjdk.java.net/loom/commit/f143d2a88e1972cdce9eb6f61c2eb9754cb89251 8268595: java/io/Serializable/serialFilter/GlobalFilterTest.java#id1 failed in timeout Reviewed-by: chegar, rriggs ! test/jdk/java/io/Serializable/serialFilter/GlobalFilterTest.java Changeset: f610ef0d Author: Alexander Zvegintsev Date: 2021-10-25 14:27:17 +0000 URL: https://git.openjdk.java.net/loom/commit/f610ef0dbc17cd3066da799a02f7f5e977261d44 8196440: Regression automated Test 'java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java' fails Reviewed-by: serb, psadhukhan ! test/jdk/ProblemList.txt ! test/jdk/java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java Changeset: 7cf68b19 Author: Alexander Zvegintsev Date: 2021-10-25 14:34:36 +0000 URL: https://git.openjdk.java.net/loom/commit/7cf68b1901cc6f8ab30f8f8496de10f4017bfc58 8202932: java/awt/Component/NativeInLightShow/NativeInLightShow.java fails Reviewed-by: serb ! test/jdk/ProblemList.txt ! test/jdk/java/awt/Component/NativeInLightShow/NativeInLightShow.java Changeset: 3221a14f Author: Artem Semenov Committer: Anton Tarasov Date: 2021-10-25 16:26:43 +0000 URL: https://git.openjdk.java.net/loom/commit/3221a14f9eaf002d91597d84efdb125704710a4c 8273678: TableAccessibility and TableRowAccessibility miss autorelease Reviewed-by: ant, kizune, pbansal ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessible.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ColumnAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TableAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TableAccessibility.m ! test/jdk/java/awt/a11y/AccessibleJTableTest.java Changeset: 89671aa1 Author: Igor Veresov Date: 2021-10-25 17:03:57 +0000 URL: https://git.openjdk.java.net/loom/commit/89671aa164ea500954b0d5caa5ce6190dfbc0d4e 8273712: C2: Add mechanism for rejecting inlining of low frequency call sites and deprecate MinInliningThreshold. Reviewed-by: kvn, rbackman ! src/hotspot/share/compiler/compilationPolicy.hpp ! src/hotspot/share/opto/bytecodeInfo.cpp ! src/hotspot/share/opto/parse.hpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp ! test/hotspot/jtreg/compiler/intrinsics/string/TestStringIntrinsics2.java Changeset: 97d3280e Author: Clive Verghese Committer: Paul Hohensee Date: 2021-10-25 18:33:57 +0000 URL: https://git.openjdk.java.net/loom/commit/97d3280eb4735f5b84cd4a9a1286e35c1c48113a 8275536: Add test to check that File::lastModified returns same time stamp as Files.getLastModifiedTime Reviewed-by: alanb, bpb + test/jdk/java/io/File/LastModifiedTest.java Changeset: 337a9b73 Author: Harold Seigel Date: 2021-10-25 19:44:25 +0000 URL: https://git.openjdk.java.net/loom/commit/337a9b73a75981d14eb4125e4354edda8d541361 8269853: Prefetch::read should accept pointer to const Reviewed-by: coleenp ! src/hotspot/os_cpu/aix_ppc/prefetch_aix_ppc.inline.hpp ! src/hotspot/os_cpu/bsd_aarch64/prefetch_bsd_aarch64.inline.hpp ! src/hotspot/os_cpu/bsd_x86/prefetch_bsd_x86.inline.hpp ! src/hotspot/os_cpu/bsd_zero/prefetch_bsd_zero.inline.hpp ! src/hotspot/os_cpu/linux_aarch64/prefetch_linux_aarch64.inline.hpp ! src/hotspot/os_cpu/linux_arm/prefetch_linux_arm.inline.hpp ! src/hotspot/os_cpu/linux_ppc/prefetch_linux_ppc.inline.hpp ! src/hotspot/os_cpu/linux_s390/prefetch_linux_s390.inline.hpp ! src/hotspot/os_cpu/linux_x86/prefetch_linux_x86.inline.hpp ! src/hotspot/os_cpu/linux_zero/prefetch_linux_zero.inline.hpp ! src/hotspot/os_cpu/windows_aarch64/prefetch_windows_aarch64.inline.hpp ! src/hotspot/os_cpu/windows_x86/prefetch_windows_x86.inline.hpp ! src/hotspot/share/runtime/prefetch.hpp Changeset: 43619458 Author: Weijun Wang Date: 2021-10-26 02:39:05 +0000 URL: https://git.openjdk.java.net/loom/commit/43619458d183bbbaec745887314ddcf7a8aa4136 8185844: MSCAPI doesn't list aliases correctly Reviewed-by: valeriep ! src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/CKeyStore.java + test/jdk/sun/security/mscapi/SetDupNameEntry.java Changeset: 10e1610f Author: Weijun Wang Date: 2021-10-26 02:45:23 +0000 URL: https://git.openjdk.java.net/loom/commit/10e1610f7b99f42f834478528df7ecfb4320aec1 8251134: Unwrapping a key with a Private Key generated by Microsoft CNG fails Reviewed-by: valeriep ! src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/CKeyStore.java ! src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/CRSACipher.java ! src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp + test/jdk/sun/security/mscapi/CngCipher.java Changeset: 3ff085e2 Author: Thomas Stuefe Date: 2021-10-26 04:52:01 +0000 URL: https://git.openjdk.java.net/loom/commit/3ff085e2967508ad312c9d32fa908807aefe69ee 8275582: Don't purge metaspace mapping lists Reviewed-by: coleenp, lkorinth ! src/hotspot/share/memory/metaspace/chunkManager.cpp ! src/hotspot/share/memory/metaspace/internalStats.hpp ! src/hotspot/share/memory/metaspace/rootChunkArea.cpp ! src/hotspot/share/memory/metaspace/rootChunkArea.hpp ! src/hotspot/share/memory/metaspace/virtualSpaceList.cpp ! src/hotspot/share/memory/metaspace/virtualSpaceList.hpp ! src/hotspot/share/memory/metaspace/virtualSpaceNode.cpp ! src/hotspot/share/memory/metaspace/virtualSpaceNode.hpp ! test/hotspot/jtreg/runtime/Metaspace/elastic/MetaspaceTestWithThreads.java Changeset: 174f553f Author: Harold Seigel Date: 2021-10-26 12:05:09 +0000 URL: https://git.openjdk.java.net/loom/commit/174f553f7e3dbc91662ba51bc3813a4be0ee97c4 8275869: Problem list applications/jcstress/copy.java on Linux-aarch64 Reviewed-by: lfoltan, dholmes ! test/hotspot/jtreg/ProblemList.txt Changeset: 4961373a Author: Julia Boes Date: 2021-10-26 12:17:47 +0000 URL: https://git.openjdk.java.net/loom/commit/4961373a676126cd557f92a2e7bbc8c66b2976b1 8275137: jdk.unsupported/sun.reflect.ReflectionFactory.readObjectNoDataForSerialization uses wrong signature Reviewed-by: dfuchs ! src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java ! src/jdk.unsupported/share/classes/sun/reflect/ReflectionFactory.java ! test/jdk/sun/reflect/ReflectionFactory/ReflectionFactoryTest.java Changeset: 63e0f344 Author: Naoto Sato Date: 2021-10-26 12:32:49 +0000 URL: https://git.openjdk.java.net/loom/commit/63e0f344e9a2da135c76caff11e437dfc40408a6 8275767: JDK source code contains redundant boolean operations in jdk.charsets Reviewed-by: lancea, rriggs, iris ! src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM964.java.template ! src/jdk.charsets/share/classes/sun/nio/cs/ext/SimpleEUCEncoder.java.template Changeset: 4be88d54 Author: Jatin Bhateja Date: 2021-10-26 12:34:56 +0000 URL: https://git.openjdk.java.net/loom/commit/4be88d5482d45e22eb756a6e2ad19ebd7110639a 8275047: Optimize existing fill stubs for AVX-512 target Reviewed-by: kvn, redestad ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/stubRoutines_x86.hpp ! src/hotspot/cpu/x86/vm_version_x86.cpp ! test/micro/org/openjdk/bench/java/util/ArraysFill.java Changeset: 7ca053de Author: Harold Seigel Date: 2021-10-26 12:37:54 +0000 URL: https://git.openjdk.java.net/loom/commit/7ca053de218bf76ea06bbeed860d142db381ca53 8251904: vmTestbase/nsk/sysdict/vm/stress/btree/btree010/btree010.java fails with ClassNotFoundException: nsk.sysdict.share.BTree0LLRLRLRRLR Reviewed-by: dholmes, lmesnik ! test/hotspot/jtreg/vmTestbase/nsk/sysdict/share/BTreeTest.java ! test/hotspot/jtreg/vmTestbase/nsk/sysdict/share/SysDictTest.java Changeset: 71d593ed Author: Coleen Phillimore Date: 2021-10-26 14:33:22 +0000 URL: https://git.openjdk.java.net/loom/commit/71d593ede6e1d0a50798d4ba6bfbd78aa65ae7d8 8275162: Use varargs in 'def' macros in mutexLocker.cpp Reviewed-by: dholmes, pchilanomate ! src/hotspot/share/runtime/mutexLocker.cpp Changeset: b98ed550 Author: Anton Tarasov Date: 2021-10-26 15:23:43 +0000 URL: https://git.openjdk.java.net/loom/commit/b98ed55060b5f3b7832ec28064b04577e3725cc2 8275819: [TableRowAccessibility accessibilityChildren] method is ineffective Reviewed-by: pbansal, kizune ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TableRowAccessibility.m Changeset: c9dec2f9 Author: Andrey Turbanov Committer: Weijun Wang Date: 2021-10-26 15:25:23 +0000 URL: https://git.openjdk.java.net/loom/commit/c9dec2f9849f98048f32ccef4e5573ce21204fbb 8273299: Unnecessary Vector usage in java.security.jgss Reviewed-by: weijun ! src/java.security.jgss/share/classes/sun/security/jgss/GSSCredentialImpl.java ! src/java.security.jgss/share/classes/sun/security/krb5/PrincipalName.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/Authenticator.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/AuthorizationData.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/EncAPRepPart.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/HostAddresses.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/KDCReqBody.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/KRBCred.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/KrbCredInfo.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/LastReq.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/PAData.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java Changeset: 7c88a59b Author: Anton Tarasov Date: 2021-10-26 15:26:45 +0000 URL: https://git.openjdk.java.net/loom/commit/7c88a59b7bca50061f120a1cf2c1d4457a1d741b 8275809: crash in [CommonComponentAccessibility getCAccessible:withEnv:] Reviewed-by: kizune, pbansal ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m Changeset: 574f8903 Author: Anton Tarasov Date: 2021-10-26 15:47:17 +0000 URL: https://git.openjdk.java.net/loom/commit/574f8903ee1f74bdf7154d670d96c36d94b38b4d 8275720: CommonComponentAccessibility.createWithParent isWrapped causes mem leak Reviewed-by: kizune, pbansal ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CellAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CellAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ComponentWrapperAccessibility.h + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ComponentWrapperAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ListRowAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ListRowAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/OutlineRowAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TableRowAccessibility.m Changeset: 82f4aacb Author: Roland Westrelin Date: 2021-10-26 15:53:37 +0000 URL: https://git.openjdk.java.net/loom/commit/82f4aacb42e60e9cd00e199703a869e7ad4465ff 8259609: C2: optimize long range checks in long counted loops Co-authored-by: John R Rose Reviewed-by: thartmann, jrose ! src/hotspot/share/opto/addnode.cpp ! src/hotspot/share/opto/loopPredicate.cpp ! src/hotspot/share/opto/loopTransform.cpp ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/loopnode.hpp ! src/hotspot/share/opto/loopopts.cpp ! src/hotspot/share/opto/mulnode.hpp ! src/hotspot/share/opto/node.hpp ! src/hotspot/share/opto/phaseX.cpp ! src/hotspot/share/opto/subnode.hpp + test/hotspot/jtreg/compiler/c2/irTests/TestLongRangeChecks.java + test/hotspot/jtreg/compiler/rangechecks/TestLongRangeCheck.java + test/hotspot/jtreg/compiler/rangechecks/TestRCMinInt.java Changeset: e5cd2692 Author: Calvin Cheung Date: 2021-10-26 16:26:57 +0000 URL: https://git.openjdk.java.net/loom/commit/e5cd2692da6327c6fde954f86595a08fe5edf43f 8274944: AppCDS dump causes SEGV in VM thread while adjusting lambda proxy class info Reviewed-by: minqi, dholmes ! src/hotspot/share/cds/dynamicArchive.cpp ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/classfile/systemDictionaryShared.hpp ! test/hotspot/jtreg/TEST.groups + test/hotspot/jtreg/runtime/cds/appcds/LambdaContainsOldInf.java + test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/LambdaContainsOldInf.java + test/hotspot/jtreg/runtime/cds/appcds/test-classes/LambdaContainsOldInfApp.java + test/hotspot/jtreg/runtime/cds/appcds/test-classes/OldProvider.jasm Changeset: 19f76c21 Author: Andrey Turbanov Committer: Daniel Fuchs Date: 2021-10-26 16:40:55 +0000 URL: https://git.openjdk.java.net/loom/commit/19f76c215dbe9528dde10acd744be54618ea5e4c 8275079: Remove unnecessary conversion to String in java.net.http Reviewed-by: dfuchs ! src/java.net.http/share/classes/jdk/internal/net/http/AuthenticationFilter.java ! src/java.net.http/share/classes/jdk/internal/net/http/Http1AsyncReceiver.java ! src/java.net.http/share/classes/jdk/internal/net/http/Http1Request.java ! src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java ! src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java ! src/java.net.http/share/classes/jdk/internal/net/http/HttpRequestImpl.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/Demand.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/SSLFlowDelegate.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/SubscriberWrapper.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java ! src/java.net.http/share/classes/jdk/internal/net/http/frame/ErrorFrame.java ! src/java.net.http/share/classes/jdk/internal/net/http/frame/Http2Frame.java ! src/java.net.http/share/classes/jdk/internal/net/http/frame/SettingsFrame.java Changeset: f1f5e269 Author: Ji?? Van?k Committer: Magnus Ihse Bursie Date: 2021-10-26 16:54:55 +0000 URL: https://git.openjdk.java.net/loom/commit/f1f5e2690cb93c07eb8be96a4cbfbf140e8a15e0 8275872: Sync J2DBench run and analyze Makefile targets with build.xml Reviewed-by: ihse, andrew ! src/demo/share/java2d/J2DBench/Makefile Changeset: 2448b3f5 Author: Doug Simon Date: 2021-10-26 18:50:21 +0000 URL: https://git.openjdk.java.net/loom/commit/2448b3f5f96ec4d9ea8fe9dae32a0aab725fb4ad 8275874: [JVMCI] only support aligned reads in c2v_readFieldValue Reviewed-by: never, shade ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/CompilerToVM.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/MemoryAccessProvider.java ! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.hotspot.test/src/jdk/vm/ci/hotspot/test/MemoryAccessProviderData.java ! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.hotspot.test/src/jdk/vm/ci/hotspot/test/MemoryAccessProviderTest.java Changeset: 7addcd7c Author: Daniel D. Daugherty Date: 2021-10-26 22:03:18 +0000 URL: https://git.openjdk.java.net/loom/commit/7addcd7cfb73652841c65c54e84b6ebffcbd664e 8276034: ProblemList gtest dll_address_to_function_and_library_name on macosx-x64 Reviewed-by: prr ! test/hotspot/gtest/runtime/test_os.cpp Changeset: b0d1e4ff Author: Yi Yang Date: 2021-10-27 01:21:12 +0000 URL: https://git.openjdk.java.net/loom/commit/b0d1e4ff4d3806851fe998717822e8e52987357c 8273585: String.charAt performance degrades due to JDK-8268698 Reviewed-by: roland, kvn ! src/hotspot/share/opto/loopnode.cpp Changeset: d98b7c25 Author: Alexander Zvegintsev Date: 2021-10-27 01:58:11 +0000 URL: https://git.openjdk.java.net/loom/commit/d98b7c25910d38ac644838f59cb41ecd131c87a9 8202926: Test java/awt/Focus/WindowUpdateFocusabilityTest/WindowUpdateFocusabilityTest.html fails Reviewed-by: serb ! test/jdk/ProblemList.txt Changeset: 9f75d5ce Author: Wang Huang Committer: Ningsheng Jian Date: 2021-10-27 05:32:50 +0000 URL: https://git.openjdk.java.net/loom/commit/9f75d5ce500886b32175cc541939b7f0eee190ca 8259948: Aarch64: Add cast nodes for Aarch64 Neon backend Co-authored-by: Wang Huang Co-authored-by: Wu Yan Co-authored-by: Miao Zhuojun Reviewed-by: aph, eliu, njian ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/aarch64_neon.ad ! src/hotspot/cpu/aarch64/aarch64_neon_ad.m4 ! src/hotspot/cpu/aarch64/assembler_aarch64.hpp ! test/hotspot/gtest/aarch64/aarch64-asmtest.py ! test/hotspot/gtest/aarch64/asmtest.out.h Changeset: 9e831bcc Author: Albert Mingkun Yang Date: 2021-10-27 08:24:44 +0000 URL: https://git.openjdk.java.net/loom/commit/9e831bccd2fc90681b32d1504eca753462afc6f6 8275886: G1: remove obsolete comment in HeapRegion::setup_heap_region_size Reviewed-by: mli, tschatzl ! src/hotspot/share/gc/g1/heapRegion.cpp Changeset: 2f979ecb Author: Jayathirth D V Date: 2021-10-27 09:29:37 +0000 URL: https://git.openjdk.java.net/loom/commit/2f979ecb5b642d04ad280687de76a6ee46818b35 8213120: java/awt/TextArea/AutoScrollOnSelectAndAppend/AutoScrollOnSelectAndAppend.java fails on mac10.13 Reviewed-by: psadhukhan ! test/jdk/ProblemList.txt ! test/jdk/java/awt/TextArea/AutoScrollOnSelectAndAppend/AutoScrollOnSelectAndAppend.java Changeset: 6c05cc9d Author: Claes Redestad Date: 2021-10-27 10:07:46 +0000 URL: https://git.openjdk.java.net/loom/commit/6c05cc9d15fb6014b8293a66ef132f3461badca1 8275863: Use encodeASCII for ASCII-compatible DoubleByte encodings Reviewed-by: naoto, rriggs, alanb ! src/java.base/share/classes/module-info.java ! src/java.base/share/classes/sun/nio/cs/DoubleByte.java ! src/java.base/share/classes/sun/nio/cs/HKSCS.java ! src/java.base/share/lib/security/default.policy ! src/jdk.charsets/share/classes/sun/nio/cs/ext/EUC_JP.java.template Changeset: b3f45f86 Author: Jayathirth D V Date: 2021-10-27 10:21:28 +0000 URL: https://git.openjdk.java.net/loom/commit/b3f45f868d9c91d630a118e43cef54cdb3216fd0 8275689: [TESTBUG] Use color tolerance only for XRender in BlitRotateClippedArea test Reviewed-by: serb ! test/jdk/java/awt/image/DrawImage/BlitRotateClippedArea.java Changeset: 485d6586 Author: Prasanta Sadhukhan Date: 2021-10-27 10:24:21 +0000 URL: https://git.openjdk.java.net/loom/commit/485d65865ea8af3f7275e9aa8b75057326486a4d 8275851: Deproblemlist open/test/jdk/javax/swing/JComponent/6683775/bug6683775.java Reviewed-by: serb ! test/jdk/ProblemList.txt ! test/jdk/javax/swing/JComponent/6683775/bug6683775.java Changeset: 40606021 Author: Coleen Phillimore Date: 2021-10-27 12:09:46 +0000 URL: https://git.openjdk.java.net/loom/commit/40606021ee6b7d18674e36b3f6249f1ca8a7647e 8275800: Redefinition leaks MethodData::_extra_data_lock Reviewed-by: sspitsyn, dholmes ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/oops/klass.cpp ! src/hotspot/share/oops/klass.hpp ! src/hotspot/share/prims/jvmtiRedefineClasses.cpp Changeset: a2927333 Author: Tobias Hartmann Date: 2021-10-27 12:27:43 +0000 URL: https://git.openjdk.java.net/loom/commit/a29273336bae75e8d185fa7f7c789acbec50a619 8275975: Remove dead code in ciInstanceKlass Reviewed-by: chagedorn, kvn ! src/hotspot/share/ci/ciArrayKlass.hpp ! src/hotspot/share/ci/ciInstanceKlass.cpp ! src/hotspot/share/ci/ciInstanceKlass.hpp Changeset: 168081ef Author: Naoto Sato Date: 2021-10-27 12:39:46 +0000 URL: https://git.openjdk.java.net/loom/commit/168081efc8af1f5d1d7524246eb4a0675bd49ae0 8270490: Charset.forName() taking fallback default value Reviewed-by: joehw, rriggs, serb, dfuchs ! src/java.base/share/classes/java/io/Console.java ! src/java.base/share/classes/java/nio/charset/Charset.java + test/jdk/java/nio/charset/Charset/ForName.java Changeset: 93be099c Author: Stefan Karlsson Date: 2021-10-27 13:23:24 +0000 URL: https://git.openjdk.java.net/loom/commit/93be099ccb73c88532866ae6d0c288c12a592cc4 4718400: Many quantities are held as signed that should be unsigned Reviewed-by: coleenp, rbackman, dholmes ! src/hotspot/share/cds/heapShared.cpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/classfile/javaClasses.inline.hpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/g1/g1ConcurrentMarkBitMap.inline.hpp ! src/hotspot/share/gc/g1/g1ConcurrentMarkObjArrayProcessor.cpp ! src/hotspot/share/gc/g1/g1ConcurrentMarkObjArrayProcessor.inline.hpp ! src/hotspot/share/gc/g1/g1RegionMarkStatsCache.cpp ! src/hotspot/share/gc/g1/g1YoungCollector.cpp ! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp ! src/hotspot/share/gc/g1/heapRegion.inline.hpp ! src/hotspot/share/gc/parallel/parMarkBitMap.hpp ! src/hotspot/share/gc/parallel/parMarkBitMap.inline.hpp ! src/hotspot/share/gc/parallel/psClosure.inline.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.inline.hpp ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/serial/markSweep.hpp ! src/hotspot/share/gc/serial/markSweep.inline.hpp ! src/hotspot/share/gc/shared/cardTableBarrierSet.cpp ! src/hotspot/share/gc/shared/collectedHeap.hpp ! src/hotspot/share/gc/shared/collectedHeap.inline.hpp ! src/hotspot/share/gc/shared/genCollectedHeap.cpp ! src/hotspot/share/gc/shared/generation.cpp ! src/hotspot/share/gc/shared/memAllocator.cpp ! src/hotspot/share/gc/shared/space.cpp ! src/hotspot/share/gc/shared/space.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp ! src/hotspot/share/gc/z/zCollectedHeap.cpp ! src/hotspot/share/gc/z/zCollectedHeap.hpp ! src/hotspot/share/jfr/leakprofiler/chains/edgeUtils.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/memory/heapInspection.hpp ! src/hotspot/share/oops/arrayKlass.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/oops/instanceMirrorKlass.cpp ! src/hotspot/share/oops/instanceMirrorKlass.hpp ! src/hotspot/share/oops/klass.hpp ! src/hotspot/share/oops/objArrayKlass.cpp ! src/hotspot/share/oops/objArrayKlass.hpp ! src/hotspot/share/oops/objArrayOop.hpp ! src/hotspot/share/oops/oop.hpp ! src/hotspot/share/oops/oop.inline.hpp ! src/hotspot/share/oops/typeArrayKlass.cpp ! src/hotspot/share/oops/typeArrayKlass.hpp ! src/hotspot/share/oops/typeArrayOop.hpp ! src/hotspot/share/oops/typeArrayOop.inline.hpp ! src/hotspot/share/opto/runtime.cpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/runtime/deoptimization.cpp Changeset: 809488bf Author: Thomas Stuefe Date: 2021-10-27 13:40:51 +0000 URL: https://git.openjdk.java.net/loom/commit/809488bf38c250db3c263f200e5eb1a269059c3d 8276046: codestrings.validate_vm gtest fails on ppc64, s390 Reviewed-by: shade, mdoerr ! test/hotspot/gtest/code/test_codestrings.cpp Changeset: e6fa5fa3 Author: Daniel D. Daugherty Date: 2021-10-27 14:24:02 +0000 URL: https://git.openjdk.java.net/loom/commit/e6fa5fa37e73cd952fb93cc57091775b748ace9a 8276063: ProblemList gtest dll_address_to_function_and_library_name on macosx-generic Reviewed-by: tschatzl ! test/hotspot/gtest/runtime/test_os.cpp Changeset: 9a3e9542 Author: Andrey Turbanov Committer: Naoto Sato Date: 2021-10-27 16:18:12 +0000 URL: https://git.openjdk.java.net/loom/commit/9a3e9542997860de79d07a4411b1007e9cd5c348 8274879: Replace uses of StringBuffer with StringBuilder within java.base classes Reviewed-by: naoto ! src/java.base/share/classes/java/io/FilePermission.java ! src/java.base/share/classes/java/net/SocketPermission.java ! src/java.base/share/classes/java/net/URL.java ! src/java.base/share/classes/java/text/AttributedString.java ! src/java.base/share/classes/java/text/ChoiceFormat.java ! src/java.base/share/classes/java/text/CompactNumberFormat.java ! src/java.base/share/classes/java/text/DecimalFormat.java ! src/java.base/share/classes/java/text/RBTableBuilder.java ! src/java.base/share/classes/sun/security/util/Debug.java ! src/java.base/share/classes/sun/util/calendar/JulianCalendar.java ! src/java.base/share/classes/sun/util/calendar/LocalGregorianCalendar.java Changeset: f3696610 Author: Ron Pressler Date: 2021-11-01 16:59:07 +0000 URL: https://git.openjdk.java.net/loom/commit/f3696610d28303c9db5856cd4f613e6e97ebac5e Merge branch 'master' into fibers ! make/conf/jib-profiles.js ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/stubRoutines_x86.hpp ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/os_cpu/bsd_aarch64/prefetch_bsd_aarch64.inline.hpp ! src/hotspot/os_cpu/bsd_x86/prefetch_bsd_x86.inline.hpp ! src/hotspot/os_cpu/linux_aarch64/prefetch_linux_aarch64.inline.hpp ! src/hotspot/os_cpu/linux_x86/prefetch_linux_x86.inline.hpp ! src/hotspot/os_cpu/windows_aarch64/prefetch_windows_aarch64.inline.hpp ! src/hotspot/os_cpu/windows_x86/prefetch_windows_x86.inline.hpp ! src/hotspot/share/cds/heapShared.cpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/classfile/javaClasses.inline.hpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/gc/g1/g1CardSetContainers.hpp ! src/hotspot/share/gc/g1/g1CardSetContainers.inline.hpp ! src/hotspot/share/gc/g1/g1CardSetMemory.hpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/serial/markSweep.hpp ! src/hotspot/share/gc/serial/markSweep.inline.hpp ! src/hotspot/share/gc/shared/collectedHeap.hpp ! src/hotspot/share/gc/shared/genCollectedHeap.cpp ! src/hotspot/share/gc/shared/generation.cpp ! src/hotspot/share/gc/shared/memAllocator.cpp ! src/hotspot/share/gc/shared/memAllocator.hpp ! src/hotspot/share/gc/shared/space.cpp ! src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp ! src/hotspot/share/gc/z/zCollectedHeap.cpp ! src/hotspot/share/gc/z/zCollectedHeap.hpp ! src/hotspot/share/jfr/leakprofiler/checkpoint/eventEmitter.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/oops/instanceStackChunkKlass.cpp ! src/hotspot/share/oops/instanceStackChunkKlass.hpp ! src/hotspot/share/oops/instanceStackChunkKlass.inline.hpp ! src/hotspot/share/oops/klass.cpp ! src/hotspot/share/oops/klass.hpp ! src/hotspot/share/oops/objArrayOop.hpp ! src/hotspot/share/oops/oop.hpp ! src/hotspot/share/oops/oop.inline.hpp ! src/hotspot/share/oops/stackChunkOop.inline.hpp ! src/hotspot/share/oops/typeArrayOop.hpp ! src/hotspot/share/opto/bytecodeInfo.cpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/library_call.hpp ! src/hotspot/share/opto/runtime.cpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/continuation.cpp ! src/hotspot/share/runtime/deoptimization.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/prefetch.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/java.base/share/classes/java/lang/SecurityManager.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/net/URL.java ! src/java.base/share/classes/java/nio/charset/Charset.java ! src/java.base/share/classes/module-info.java ! src/java.base/share/classes/sun/net/www/http/HttpClient.java ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/TEST.groups ! test/jdk/ProblemList.txt ! make/conf/jib-profiles.js ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/stubRoutines_x86.hpp ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/os_cpu/bsd_aarch64/prefetch_bsd_aarch64.inline.hpp ! src/hotspot/os_cpu/bsd_x86/prefetch_bsd_x86.inline.hpp ! src/hotspot/os_cpu/linux_aarch64/prefetch_linux_aarch64.inline.hpp ! src/hotspot/os_cpu/linux_x86/prefetch_linux_x86.inline.hpp ! src/hotspot/os_cpu/windows_aarch64/prefetch_windows_aarch64.inline.hpp ! src/hotspot/os_cpu/windows_x86/prefetch_windows_x86.inline.hpp ! src/hotspot/share/cds/heapShared.cpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/classfile/javaClasses.inline.hpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/gc/g1/g1CardSetContainers.hpp ! src/hotspot/share/gc/g1/g1CardSetContainers.inline.hpp ! src/hotspot/share/gc/g1/g1CardSetMemory.hpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/serial/markSweep.hpp ! src/hotspot/share/gc/serial/markSweep.inline.hpp ! src/hotspot/share/gc/shared/collectedHeap.hpp ! src/hotspot/share/gc/shared/genCollectedHeap.cpp ! src/hotspot/share/gc/shared/generation.cpp ! src/hotspot/share/gc/shared/memAllocator.cpp ! src/hotspot/share/gc/shared/memAllocator.hpp ! src/hotspot/share/gc/shared/space.cpp ! src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp ! src/hotspot/share/gc/z/zCollectedHeap.cpp ! src/hotspot/share/gc/z/zCollectedHeap.hpp ! src/hotspot/share/jfr/leakprofiler/checkpoint/eventEmitter.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp + src/hotspot/share/oops/instanceStackChunkKlass.cpp + src/hotspot/share/oops/instanceStackChunkKlass.hpp + src/hotspot/share/oops/instanceStackChunkKlass.inline.hpp ! src/hotspot/share/oops/klass.cpp ! src/hotspot/share/oops/klass.hpp ! src/hotspot/share/oops/objArrayOop.hpp ! src/hotspot/share/oops/oop.hpp ! src/hotspot/share/oops/oop.inline.hpp + src/hotspot/share/oops/stackChunkOop.inline.hpp ! src/hotspot/share/oops/typeArrayOop.hpp ! src/hotspot/share/opto/bytecodeInfo.cpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/library_call.hpp ! src/hotspot/share/opto/runtime.cpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/runtime/arguments.cpp + src/hotspot/share/runtime/continuation.cpp ! src/hotspot/share/runtime/deoptimization.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/prefetch.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/java.base/share/classes/java/lang/SecurityManager.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/net/URL.java ! src/java.base/share/classes/java/nio/charset/Charset.java ! src/java.base/share/classes/module-info.java ! src/java.base/share/classes/sun/net/www/http/HttpClient.java ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/TEST.groups ! test/jdk/ProblemList.txt Changeset: 09676890 Author: Ron Pressler Date: 2021-11-01 16:59:58 +0000 URL: https://git.openjdk.java.net/loom/commit/096768900a780a88fd821cea43ee783c8cf24c80 Merge remote-tracking branch 'origin/fibers' into fibers ! test/hotspot/jtreg/ProblemList.txt ! test/jdk/ProblemList.txt ! test/hotspot/jtreg/ProblemList.txt ! test/jdk/ProblemList.txt From duke at openjdk.java.net Mon Nov 1 17:12:01 2021 From: duke at openjdk.java.net (duke) Date: Mon, 1 Nov 2021 17:12:01 GMT Subject: git: openjdk/loom: master: 89 new changesets Message-ID: <3e426096-f3f7-4dd6-aefb-3b2ab52c1f04@openjdk.java.net> Changeset: 043cde22 Author: Daniel Jelinski Committer: Daniel Fuchs Date: 2021-10-20 14:06:08 +0000 URL: https://git.openjdk.java.net/loom/commit/043cde22d4d6bd975e75daa9ad52770cf79df934 8275319: java.net.NetworkInterface throws java.lang.Error instead of SocketException Reviewed-by: alanb, dfuchs ! src/java.base/windows/native/libnet/NetworkInterface.c ! src/java.base/windows/native/libnet/NetworkInterface_winXP.c Changeset: 35e5bb5f Author: Jaikiran Pai Date: 2021-10-20 15:10:28 +0000 URL: https://git.openjdk.java.net/loom/commit/35e5bb5f59c01a1b07893780fa73f93c2abab653 8269336: Malformed jdk.serialFilter incorrectly handled Reviewed-by: rriggs ! src/java.base/share/classes/java/io/ObjectInputFilter.java + test/jdk/java/io/Serializable/serialFilter/InvalidGlobalFilterTest.java Changeset: 7e28bdd1 Author: Thomas Schatzl Date: 2021-10-20 15:33:50 +0000 URL: https://git.openjdk.java.net/loom/commit/7e28bdd1eb8276a5f78802febc9bd6f1cf597f55 8275055: Improve HeapRegionRemSet::split_card() Reviewed-by: sjohanss, ayang + src/hotspot/share/gc/g1/g1CardSetContainers.cpp ! src/hotspot/share/gc/g1/g1CardSetContainers.hpp ! src/hotspot/share/gc/g1/g1CardSetContainers.inline.hpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/heapRegionRemSet.cpp ! src/hotspot/share/gc/g1/heapRegionRemSet.hpp ! src/hotspot/share/gc/g1/heapRegionRemSet.inline.hpp Changeset: bbc60611 Author: Harold Seigel Date: 2021-10-20 15:48:43 +0000 URL: https://git.openjdk.java.net/loom/commit/bbc606117fcd8b48fc8f830c50cf7eb573da1c4c 8272614: Unused parameters in MethodHandleNatives linking methods Reviewed-by: dholmes, lfoltan ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/vmSymbols.hpp ! src/java.base/share/classes/java/lang/invoke/MethodHandleNatives.java Changeset: 46b5bfbc Author: Alexander Zvegintsev Date: 2021-10-20 16:44:47 +0000 URL: https://git.openjdk.java.net/loom/commit/46b5bfbc38f14607f0db686a42f1fa96d2f61891 8233648: [TESTBUG] DefaultMenuBarTest.java failing on macos Reviewed-by: pbansal, serb, psadhukhan, prr ! test/jdk/ProblemList.txt ! test/jdk/com/apple/eawt/DefaultMenuBar/DefaultMenuBarTest.java Changeset: 0021a2f4 Author: Mikhailo Seledtsov Date: 2021-10-20 18:16:58 +0000 URL: https://git.openjdk.java.net/loom/commit/0021a2f462eab38b1a4c5c38736dfc7735f3c00a 8275449: Add linux-aarch64-zero build profile Reviewed-by: erikj ! make/autoconf/lib-ffi.m4 ! make/conf/jib-profiles.js Changeset: 913f9281 Author: Markus Karg Committer: Brian Burkhalter Date: 2021-10-20 18:30:52 +0000 URL: https://git.openjdk.java.net/loom/commit/913f9281ada7ebb670ed93a088d28afeaa635eb7 8273507: Convert test/jdk/java/nio/channels/Channels/TransferTo.java to TestNG test Reviewed-by: shade, bpb ! test/jdk/java/nio/channels/Channels/TransferTo.java Changeset: d1e3ca4e Author: Alisen Chung Committer: Phil Race Date: 2021-10-20 18:51:00 +0000 URL: https://git.openjdk.java.net/loom/commit/d1e3ca4ee35bf4c2ce9b6dae2518f533f36a98dd 8233558: [TESTBUG] WindowOwnedByEmbeddedFrameTest.java fails on macos Reviewed-by: serb, kizune, prr ! test/jdk/ProblemList.txt ! test/jdk/java/awt/Window/WindowOwnedByEmbeddedFrameTest/WindowOwnedByEmbeddedFrameTest.java Changeset: cea3f010 Author: Igor Ignatyev Date: 2021-10-20 19:24:46 +0000 URL: https://git.openjdk.java.net/loom/commit/cea3f010460c4b45e76bfac8a5b193c49fdd274a 8275666: serviceability/jvmti/GetObjectSizeClass.java shouldn't have vm.flagless Reviewed-by: lmesnik ! test/hotspot/jtreg/serviceability/jvmti/GetObjectSizeClass.java Changeset: af7c56b8 Author: vamsi-parasa Committer: Sandhya Viswanathan Date: 2021-10-20 22:40:51 +0000 URL: https://git.openjdk.java.net/loom/commit/af7c56b85bb2828a9d68f9e1c753a4adfa7ebb4f 8275167: x86 intrinsic for unsignedMultiplyHigh Reviewed-by: kvn, sviswanathan ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/classes.hpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/library_call.hpp ! src/hotspot/share/opto/mulnode.cpp ! src/hotspot/share/opto/mulnode.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/java.base/share/classes/java/lang/Math.java ! test/micro/org/openjdk/bench/java/lang/MathBench.java Changeset: c7a80e60 Author: Hamlin Li Date: 2021-10-21 01:16:10 +0000 URL: https://git.openjdk.java.net/loom/commit/c7a80e60e2e201b573d4653fa978df527addc8a6 8275607: G1: G1CardSetAllocator::drop_all needs to call G1SegmentedArray::drop_all Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1CardSetMemory.cpp Changeset: a120937e Author: Hamlin Li Date: 2021-10-21 01:17:52 +0000 URL: https://git.openjdk.java.net/loom/commit/a120937e8194a897ed4af9e7a2e33beb857987e5 8274988: G1: refine G1SegmentedArrayAllocOptions and G1CardSetAllocOptions Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1CardSetMemory.hpp ! src/hotspot/share/gc/g1/g1SegmentedArray.hpp Changeset: 09f5235c Author: Stefan Karlsson Date: 2021-10-21 07:47:10 +0000 URL: https://git.openjdk.java.net/loom/commit/09f5235c65de546640d5f923fa9369e28643c6ed 8275405: Linking error for classes with lambda template parameters and virtual functions Reviewed-by: ihse, pliden ! make/hotspot/lib/JvmMapfile.gmk Changeset: 0c3eaea1 Author: Alexander Zuev Date: 2021-10-21 09:51:18 +0000 URL: https://git.openjdk.java.net/loom/commit/0c3eaea11c83b3ee63d80de85d58a1cb6f870fd3 8168388: GetMousePositionTest fails with the message "Mouse position should not be null" Reviewed-by: psadhukhan, serb ! test/jdk/ProblemList.txt ! test/jdk/java/awt/Mouse/GetMousePositionTest/GetMousePositionWithOverlay.java Changeset: c41ce6d1 Author: Markus Gr?nlund Date: 2021-10-21 10:12:19 +0000 URL: https://git.openjdk.java.net/loom/commit/c41ce6d159e59a8c05dbeacde2d2612b58733d46 8275415: Prepare Leak Profiler for Lilliput Reviewed-by: rkennke ! src/hotspot/share/jfr/leakprofiler/chains/edgeStore.cpp ! src/hotspot/share/jfr/leakprofiler/chains/edgeStore.hpp ! src/hotspot/share/jfr/leakprofiler/checkpoint/eventEmitter.cpp Changeset: 819d2df8 Author: Coleen Phillimore Date: 2021-10-21 11:28:22 +0000 URL: https://git.openjdk.java.net/loom/commit/819d2df8b01e04bcc89a0a995e21b68799f890be 8274794: Print all owned locks in hs_err file Reviewed-by: stuefe, dholmes ! src/hotspot/share/runtime/mutex.cpp ! src/hotspot/share/runtime/mutex.hpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp ! src/hotspot/share/utilities/vmError.cpp ! test/hotspot/jtreg/runtime/ErrorHandling/ErrorFileOverwriteTest.java + test/hotspot/jtreg/runtime/ErrorHandling/ErrorFileScanner.java + test/hotspot/jtreg/runtime/ErrorHandling/TestErrorFileMutex.java Changeset: cd07b3ca Author: Coleen Phillimore Date: 2021-10-21 11:46:24 +0000 URL: https://git.openjdk.java.net/loom/commit/cd07b3cab00e6656e73a29f82210e2dedf26df8c 8257534: misc tests failed with "NoClassDefFoundError: Could not initialize class java.util.concurrent.ThreadLocalRandom" Reviewed-by: hseigel ! test/hotspot/jtreg/vmTestbase/nsk/share/gc/gp/GarbageUtils.java Changeset: 60cb27dc Author: Kim Barrett Date: 2021-10-21 13:28:25 +0000 URL: https://git.openjdk.java.net/loom/commit/60cb27dcda475a66e329359ac1ee3ffcde95c657 8275426: PretouchTask num_chunks calculation can overflow Reviewed-by: ayang, tschatzl ! src/hotspot/share/gc/shared/pretouchTask.cpp Changeset: 45ce06c9 Author: Evan Whelan Committer: Sean Coffey Date: 2021-10-21 13:33:21 +0000 URL: https://git.openjdk.java.net/loom/commit/45ce06c9f3e9bee7d4bda313c38f0f0e8786a4db 8274779: HttpURLConnection: HttpClient and HttpsClient incorrectly check request method when set to POST Reviewed-by: dfuchs, coffeys, vtewari, michaelm ! src/java.base/share/classes/sun/net/www/http/HttpClient.java ! src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java + test/jdk/sun/net/www/http/RequestMethodCheck/RequestMethodEquality.java + test/jdk/sun/net/www/http/RequestMethodCheck/java.base/sun/net/www/http/HttpClientAccess.java Changeset: e39bdc9d Author: Harold Seigel Date: 2021-10-21 13:50:32 +0000 URL: https://git.openjdk.java.net/loom/commit/e39bdc9ddb7ba50160d07a27e6038cdea6a594a8 8274714: Incorrect verifier protected access error message Reviewed-by: dholmes, coleenp ! src/hotspot/share/classfile/verifier.cpp + test/hotspot/jtreg/runtime/verifier/PutfieldProtectedTest.java + test/hotspot/jtreg/runtime/verifier/putfieldProtected.jasm Changeset: d589b664 Author: Weijun Wang Date: 2021-10-21 14:04:48 +0000 URL: https://git.openjdk.java.net/loom/commit/d589b664cc809aea39ec094e99b1898df1bf3c19 8270380: Change the default value of the java.security.manager system property to disallow Reviewed-by: lancea, mullan, rriggs ! src/java.base/share/classes/java/lang/SecurityManager.java ! src/java.base/share/classes/java/lang/System.java ! test/jdk/java/lang/System/AllowSecurityManager.java ! test/jdk/java/lang/System/SecurityManagerWarnings.java ! test/jdk/sun/security/pkcs11/KeyStore/Basic.java ! test/jdk/sun/security/pkcs11/Provider/MultipleLogins.sh Changeset: 3b0ce23b Author: Christian Hagedorn Date: 2021-10-21 14:05:45 +0000 URL: https://git.openjdk.java.net/loom/commit/3b0ce23bcd827d0998fe9b43e5b0220c915dab21 8274888: Dump "-DReproduce=true" to the test VM command line output Reviewed-by: thartmann, kvn ! test/hotspot/jtreg/compiler/lib/ir_framework/driver/TestVMProcess.java Changeset: 3cb241a9 Author: Joe Darcy Date: 2021-10-21 15:25:10 +0000 URL: https://git.openjdk.java.net/loom/commit/3cb241a91fd2cc6b0b3b333288028694e60f723f 8275686: Suppress warnings on non-serializable non-transient instance fields in java.rmi Reviewed-by: bpb, iris, rriggs ! src/java.rmi/share/classes/sun/rmi/server/UnicastRef.java Changeset: 0761a4b9 Author: Joe Darcy Date: 2021-10-21 15:26:07 +0000 URL: https://git.openjdk.java.net/loom/commit/0761a4b915217abb08ef9b5c1a60878aedf5572c 8275688: Suppress warnings on non-serializable non-transient instance fields in DualPivotQuicksort Reviewed-by: rriggs ! src/java.base/share/classes/java/util/DualPivotQuicksort.java Changeset: af146501 Author: Mikhailo Seledtsov Date: 2021-10-21 15:31:03 +0000 URL: https://git.openjdk.java.net/loom/commit/af14650127de47058b958be411503584c0ba6323 8275569: Add linux-aarch64 to test-make profiles Reviewed-by: ihse ! make/conf/jib-profiles.js Changeset: bef8cf1b Author: Albert Mingkun Yang Date: 2021-10-21 15:49:21 +0000 URL: https://git.openjdk.java.net/loom/commit/bef8cf1ba14d3846977942844f341f5c5a1f44c4 8275714: G1: remove unused variable in G1Policy::transfer_survivors_to_cset Reviewed-by: tschatzl ! src/hotspot/share/gc/g1/g1Policy.cpp Changeset: 49f9d803 Author: Sean Mullan Date: 2021-10-21 17:28:40 +0000 URL: https://git.openjdk.java.net/loom/commit/49f9d8031e9c678e20dcfc1ba06758b511a26b07 8243585: AlgorithmChecker::check throws confusing exception when it rejects the signer key Reviewed-by: ascarpino ! src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.java ! src/java.base/share/classes/sun/security/provider/certpath/CertPathConstraintsParameters.java ! src/java.base/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java ! src/java.base/share/classes/sun/security/util/AlgorithmDecomposer.java ! src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java ! test/jdk/sun/security/ssl/SSLContextImpl/TrustTrustedCert.java ! test/jdk/sun/security/tools/jarsigner/CheckSignerCertChain.java ! test/jdk/sun/security/tools/jarsigner/Warning.java Changeset: 7dd82374 Author: Yumin Qi Date: 2021-10-21 18:30:21 +0000 URL: https://git.openjdk.java.net/loom/commit/7dd823740f7bfc55f456a5c8c199475cc85dfea3 8275084: CDS warning when building with LOG=debug Reviewed-by: dholmes, iklam ! src/hotspot/share/cds/classListWriter.cpp Changeset: 0961de47 Author: Dean Long Date: 2021-10-21 19:02:38 +0000 URL: https://git.openjdk.java.net/loom/commit/0961de47de1bf4379089e010978bcb4708fde767 8275347: ciReplay: staticfield lines not properly terminated Reviewed-by: neliasso, chagedorn ! src/hotspot/share/ci/ciInstanceKlass.cpp ! src/hotspot/share/ci/ciReplay.cpp ! test/hotspot/jtreg/compiler/ciReplay/CiReplayBase.java Changeset: 4e9dd4bd Author: Andrey Turbanov Committer: Mandy Chung Date: 2021-10-21 20:52:31 +0000 URL: https://git.openjdk.java.net/loom/commit/4e9dd4bddb888717d774147d4ba1acecc750629c 8275384: Change nested classes in jdk.jconsole to static nested classes Reviewed-by: alanb, sspitsyn, mchung ! src/jdk.jconsole/share/classes/sun/tools/jconsole/MaximizableInternalFrame.java ! src/jdk.jconsole/share/classes/sun/tools/jconsole/MemoryTab.java ! src/jdk.jconsole/share/classes/sun/tools/jconsole/ThreadTab.java ! src/jdk.jconsole/share/classes/sun/tools/jconsole/inspector/XMBeanAttributes.java ! src/jdk.jconsole/share/classes/sun/tools/jconsole/inspector/XMBeanNotifications.java Changeset: 6a466fe7 Author: Joe Darcy Date: 2021-10-21 21:11:01 +0000 URL: https://git.openjdk.java.net/loom/commit/6a466fe7ae281967d1cc4c8029b306f2d66567c9 8202056: Expand serial warning to check for bad overloads of serial-related methods and ineffectual fields 8160675: Issue lint warning for non-serializable non-transient instance fields in serializable type Reviewed-by: erikj, sspitsyn, jlahoda, vromero, rriggs, smarks ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties ! src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/OptionException.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/ConstantPool.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/InternalError.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/JavapTask.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsTask.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/MultiReleaseException.java + test/langtools/tools/javac/diags/examples/ImproperSPF.java ! test/langtools/tools/javac/diags/examples/ImproperSVUID.java + test/langtools/tools/javac/diags/examples/IneffectualSerialEnum.java + test/langtools/tools/javac/diags/examples/IneffectualSerialExtern.java + test/langtools/tools/javac/diags/examples/IneffectualSerialRecord.java + test/langtools/tools/javac/diags/examples/SerialInterfaceMethodsAndFields.java + test/langtools/tools/javac/diags/examples/SerialMissingNoArgCtor.java + test/langtools/tools/javac/diags/examples/SerialNonPrivateMethod.java + test/langtools/tools/javac/warnings/Serial/CtorAccess.java + test/langtools/tools/javac/warnings/Serial/CtorAccess.out + test/langtools/tools/javac/warnings/Serial/DeepNestingSuppression.java + test/langtools/tools/javac/warnings/Serial/DeepNestingSuppression.out + test/langtools/tools/javac/warnings/Serial/EnumSerial.java + test/langtools/tools/javac/warnings/Serial/EnumSerial.out + test/langtools/tools/javac/warnings/Serial/Extern.java + test/langtools/tools/javac/warnings/Serial/Extern.out + test/langtools/tools/javac/warnings/Serial/ImproperReturnTypes.java + test/langtools/tools/javac/warnings/Serial/ImproperReturnTypes.out + test/langtools/tools/javac/warnings/Serial/ImproperSerialPF.java + test/langtools/tools/javac/warnings/Serial/ImproperSerialPF.out + test/langtools/tools/javac/warnings/Serial/InstanceField.java + test/langtools/tools/javac/warnings/Serial/InstanceField.out + test/langtools/tools/javac/warnings/Serial/InterfaceFields.java + test/langtools/tools/javac/warnings/Serial/InterfaceFields.out + test/langtools/tools/javac/warnings/Serial/InterfaceNonPrivateMethods.java + test/langtools/tools/javac/warnings/Serial/InterfaceNonPrivateMethods.out + test/langtools/tools/javac/warnings/Serial/RecordSerial.java + test/langtools/tools/javac/warnings/Serial/RecordSerial.out + test/langtools/tools/javac/warnings/Serial/SerialMethodArity.java + test/langtools/tools/javac/warnings/Serial/SerialMethodArity.out + test/langtools/tools/javac/warnings/Serial/SerialMethodMods.java + test/langtools/tools/javac/warnings/Serial/SerialMethodMods.out + test/langtools/tools/javac/warnings/Serial/SerialMethodThrows.java + test/langtools/tools/javac/warnings/Serial/SerialMethodThrows.out Changeset: c978ca87 Author: Sergey Bylokhov Date: 2021-10-22 03:05:16 +0000 URL: https://git.openjdk.java.net/loom/commit/c978ca87de2d9152345dfd85983278c42bb28cd3 8275344: -Xcheck:jni produces some warnings in the LCMS.c Reviewed-by: azvegint, prr, kizune ! src/java.desktop/share/native/liblcms/LCMS.c ! test/jdk/java/awt/color/ICC_ColorSpace/MTTransformReplacedProfile.java Changeset: fab3d6c6 Author: David Holmes Date: 2021-10-22 04:47:53 +0000 URL: https://git.openjdk.java.net/loom/commit/fab3d6c6122b2ce23dfa12db489923d8261f8f35 8275761: Backout: JDK-8274794 Print all owned locks in hs_err file Reviewed-by: mikael ! src/hotspot/share/runtime/mutex.cpp ! src/hotspot/share/runtime/mutex.hpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp ! src/hotspot/share/utilities/vmError.cpp ! test/hotspot/jtreg/runtime/ErrorHandling/ErrorFileOverwriteTest.java - test/hotspot/jtreg/runtime/ErrorHandling/ErrorFileScanner.java - test/hotspot/jtreg/runtime/ErrorHandling/TestErrorFileMutex.java Changeset: 1efe946d Author: Stefan Karlsson Date: 2021-10-22 08:20:43 +0000 URL: https://git.openjdk.java.net/loom/commit/1efe946db77e38507511a9c898b8b59fe9ba1aeb 8275712: Hashtable literal_size functions are broken Reviewed-by: coleenp, zgu ! src/hotspot/share/classfile/stringTable.cpp ! src/hotspot/share/utilities/hashtable.cpp Changeset: b2128a96 Author: Andy Herrick Date: 2021-10-22 12:17:45 +0000 URL: https://git.openjdk.java.net/loom/commit/b2128a96670daeca93aca84ee7613b2b337ddfa4 8263155: Allow additional contents for DMG Reviewed-by: asemenyuk, almatvee ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacDmgBundler.java ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/DMGsetup.scpt ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/DeployParams.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/StandardBundlerParam.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/ValidOptions.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacHelper.java + test/jdk/tools/jpackage/macosx/DmgContentTest.java Changeset: dd622e55 Author: Albert Mingkun Yang Date: 2021-10-22 12:47:35 +0000 URL: https://git.openjdk.java.net/loom/commit/dd622e55c01966f8b2deddaba09164a0a302df2e 8275783: G1: fix incorrect region type documentation in HeapRegionType Reviewed-by: tschatzl ! src/hotspot/share/gc/g1/heapRegionType.hpp Changeset: 4e647aa5 Author: Albert Mingkun Yang Date: 2021-10-22 13:01:24 +0000 URL: https://git.openjdk.java.net/loom/commit/4e647aa584cf12dae76e81e203ad4f1ebc08c1a2 8275416: G1: remove unnecessary make_referent_alive in precleaning phase Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/shared/referenceProcessor.cpp ! src/hotspot/share/gc/shared/referenceProcessor.hpp Changeset: 4dec8fc4 Author: Doug Simon Date: 2021-10-22 16:20:31 +0000 URL: https://git.openjdk.java.net/loom/commit/4dec8fc4cc2b1762fba554d0401da8be0d6d1166 8275645: [JVMCI] avoid unaligned volatile reads on AArch64 Reviewed-by: kvn, never ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/CompilerToVM.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotConstantReflectionProvider.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMemoryAccessProviderImpl.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotObjectConstantImpl.java ! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.hotspot.test/src/jdk/vm/ci/hotspot/test/MemoryAccessProviderData.java Changeset: 88bbf3c2 Author: Wu Yan Committer: Naoto Sato Date: 2021-10-22 16:23:25 +0000 URL: https://git.openjdk.java.net/loom/commit/88bbf3c2e6ac9f6d88cbb361cfbb4c16bb8eafc1 8273111: Default timezone should return zone ID if /etc/localtime is valid but not canonicalization on linux Co-authored-by: Sun Jianye Reviewed-by: naoto, mli ! src/java.base/unix/native/libjava/TimeZone_md.c ! src/java.base/unix/native/libjava/canonicalize_md.c + src/java.base/unix/native/libjava/path_util.c = src/java.base/unix/native/libjava/path_util.h Changeset: 6523c558 Author: Phil Race Date: 2021-10-22 17:22:12 +0000 URL: https://git.openjdk.java.net/loom/commit/6523c558d92dedf350576126960dee6cff8f6067 8198336: java/awt/FontMetrics/FontCrash.java fails in headless mode Reviewed-by: serb ! src/java.desktop/share/classes/java/awt/Component.java ! src/java.desktop/share/classes/sun/font/SunFontManager.java ! src/java.desktop/windows/classes/sun/awt/windows/WToolkit.java ! test/jdk/ProblemList.txt - test/jdk/java/awt/FontMetrics/FontCrash.java Changeset: fec470f2 Author: Hai-May Chao Date: 2021-10-22 20:53:38 +0000 URL: https://git.openjdk.java.net/loom/commit/fec470f262d1df581f2a5fc2f0bdfea66757a8ad 8272163: Add -version option to keytool and jarsigner Reviewed-by: weijun ! src/java.base/share/classes/sun/security/tools/keytool/Main.java ! src/java.base/share/classes/sun/security/tools/keytool/Resources.java ! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java ! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java + test/jdk/sun/security/tools/jarsigner/VersionTest.java + test/jdk/sun/security/tools/keytool/VersionTest.java Changeset: c94dc2ab Author: Igor Ignatyev Date: 2021-10-23 03:59:55 +0000 URL: https://git.openjdk.java.net/loom/commit/c94dc2ab60f0548afa868e41a0b87a68030e0cac 8272854: split runtime/CommandLine/PrintTouchedMethods.java test Reviewed-by: iklam ! test/hotspot/jtreg/runtime/CommandLine/PrintTouchedMethods.java + test/hotspot/jtreg/runtime/CommandLine/PrintTouchedMethodsJcmd.java Changeset: 5bbe4cae Author: Sergey Tsypanov Committer: Stuart Marks Date: 2021-10-23 21:07:58 +0000 URL: https://git.openjdk.java.net/loom/commit/5bbe4cae8746765d2ce965b06fd1e5cf512326ae 8275293: A change done with JDK-8268764 mismatches the java.rmi.server.ObjID.hashCode spec Reviewed-by: rriggs, smarks ! src/java.rmi/share/classes/java/rmi/server/ObjID.java Changeset: 5dab76b9 Author: Hamlin Li Date: 2021-10-25 01:03:51 +0000 URL: https://git.openjdk.java.net/loom/commit/5dab76b939e381312ce5c89b9aebca628238a387 8275381: G1: refactor 2 constructors of G1CardSetConfiguration Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1CardSet.cpp ! src/hotspot/share/gc/g1/g1CardSet.hpp ! test/hotspot/gtest/gc/g1/test_g1CardSet.cpp Changeset: 1da5e6b0 Author: Christian Hagedorn Date: 2021-10-25 07:25:19 +0000 URL: https://git.openjdk.java.net/loom/commit/1da5e6b0e2c284c5dd295a0d48cc1c6c2fecf5b5 8275104: IR framework does not handle client VM builds correctly Reviewed-by: kvn, thartmann ! test/hotspot/jtreg/compiler/lib/ir_framework/flag/FlagVM.java ! test/hotspot/jtreg/compiler/lib/ir_framework/test/TestVM.java ! test/hotspot/jtreg/testlibrary_tests/ir_framework/examples/IRExample.java ! test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestCompLevels.java ! test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestDIgnoreCompilerControls.java ! test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestIRMatching.java ! test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestSanity.java ! test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestWithHelperClasses.java Changeset: f6232982 Author: Alexey Bakhtin Committer: Yuri Nesterenko Date: 2021-10-25 08:00:40 +0000 URL: https://git.openjdk.java.net/loom/commit/f6232982b91cb2314e96ddbde3984836a810a556 8271199: Mutual TLS handshake fails signing client certificate with custom sensitive PKCS11 key Reviewed-by: xuelei, valeriep ! src/java.base/share/classes/sun/security/rsa/RSAPSSSignature.java ! src/java.base/share/classes/sun/security/rsa/RSAPrivateCrtKeyImpl.java Changeset: 0bcc1749 Author: Stefan Karlsson Date: 2021-10-25 09:07:51 +0000 URL: https://git.openjdk.java.net/loom/commit/0bcc1749eaea20cb983a983073ad33d305681879 8275717: Reimplement STATIC_ASSERT to use static_assert Reviewed-by: stuefe, eosterlund, kbarrett ! src/hotspot/share/utilities/debug.hpp Changeset: 7f94302c Author: Albert Mingkun Yang Date: 2021-10-25 13:18:20 +0000 URL: https://git.openjdk.java.net/loom/commit/7f94302ceca001ded89ba9a653bf176ef90b16cd 8275511: G1: Rename needs_remset_update to remset_is_tracked in G1HeapRegionAttr Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp ! src/hotspot/share/gc/g1/g1CollectionSet.cpp ! src/hotspot/share/gc/g1/g1HeapRegionAttr.hpp ! src/hotspot/share/gc/g1/g1ParScanThreadState.inline.hpp ! src/hotspot/share/gc/g1/g1RemSet.cpp Changeset: f143d2a8 Author: Jaikiran Pai Date: 2021-10-25 14:24:05 +0000 URL: https://git.openjdk.java.net/loom/commit/f143d2a88e1972cdce9eb6f61c2eb9754cb89251 8268595: java/io/Serializable/serialFilter/GlobalFilterTest.java#id1 failed in timeout Reviewed-by: chegar, rriggs ! test/jdk/java/io/Serializable/serialFilter/GlobalFilterTest.java Changeset: f610ef0d Author: Alexander Zvegintsev Date: 2021-10-25 14:27:17 +0000 URL: https://git.openjdk.java.net/loom/commit/f610ef0dbc17cd3066da799a02f7f5e977261d44 8196440: Regression automated Test 'java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java' fails Reviewed-by: serb, psadhukhan ! test/jdk/ProblemList.txt ! test/jdk/java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest.java Changeset: 7cf68b19 Author: Alexander Zvegintsev Date: 2021-10-25 14:34:36 +0000 URL: https://git.openjdk.java.net/loom/commit/7cf68b1901cc6f8ab30f8f8496de10f4017bfc58 8202932: java/awt/Component/NativeInLightShow/NativeInLightShow.java fails Reviewed-by: serb ! test/jdk/ProblemList.txt ! test/jdk/java/awt/Component/NativeInLightShow/NativeInLightShow.java Changeset: 3221a14f Author: Artem Semenov Committer: Anton Tarasov Date: 2021-10-25 16:26:43 +0000 URL: https://git.openjdk.java.net/loom/commit/3221a14f9eaf002d91597d84efdb125704710a4c 8273678: TableAccessibility and TableRowAccessibility miss autorelease Reviewed-by: ant, kizune, pbansal ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessible.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ColumnAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TableAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TableAccessibility.m ! test/jdk/java/awt/a11y/AccessibleJTableTest.java Changeset: 89671aa1 Author: Igor Veresov Date: 2021-10-25 17:03:57 +0000 URL: https://git.openjdk.java.net/loom/commit/89671aa164ea500954b0d5caa5ce6190dfbc0d4e 8273712: C2: Add mechanism for rejecting inlining of low frequency call sites and deprecate MinInliningThreshold. Reviewed-by: kvn, rbackman ! src/hotspot/share/compiler/compilationPolicy.hpp ! src/hotspot/share/opto/bytecodeInfo.cpp ! src/hotspot/share/opto/parse.hpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp ! test/hotspot/jtreg/compiler/intrinsics/string/TestStringIntrinsics2.java Changeset: 97d3280e Author: Clive Verghese Committer: Paul Hohensee Date: 2021-10-25 18:33:57 +0000 URL: https://git.openjdk.java.net/loom/commit/97d3280eb4735f5b84cd4a9a1286e35c1c48113a 8275536: Add test to check that File::lastModified returns same time stamp as Files.getLastModifiedTime Reviewed-by: alanb, bpb + test/jdk/java/io/File/LastModifiedTest.java Changeset: 337a9b73 Author: Harold Seigel Date: 2021-10-25 19:44:25 +0000 URL: https://git.openjdk.java.net/loom/commit/337a9b73a75981d14eb4125e4354edda8d541361 8269853: Prefetch::read should accept pointer to const Reviewed-by: coleenp ! src/hotspot/os_cpu/aix_ppc/prefetch_aix_ppc.inline.hpp ! src/hotspot/os_cpu/bsd_aarch64/prefetch_bsd_aarch64.inline.hpp ! src/hotspot/os_cpu/bsd_x86/prefetch_bsd_x86.inline.hpp ! src/hotspot/os_cpu/bsd_zero/prefetch_bsd_zero.inline.hpp ! src/hotspot/os_cpu/linux_aarch64/prefetch_linux_aarch64.inline.hpp ! src/hotspot/os_cpu/linux_arm/prefetch_linux_arm.inline.hpp ! src/hotspot/os_cpu/linux_ppc/prefetch_linux_ppc.inline.hpp ! src/hotspot/os_cpu/linux_s390/prefetch_linux_s390.inline.hpp ! src/hotspot/os_cpu/linux_x86/prefetch_linux_x86.inline.hpp ! src/hotspot/os_cpu/linux_zero/prefetch_linux_zero.inline.hpp ! src/hotspot/os_cpu/windows_aarch64/prefetch_windows_aarch64.inline.hpp ! src/hotspot/os_cpu/windows_x86/prefetch_windows_x86.inline.hpp ! src/hotspot/share/runtime/prefetch.hpp Changeset: 43619458 Author: Weijun Wang Date: 2021-10-26 02:39:05 +0000 URL: https://git.openjdk.java.net/loom/commit/43619458d183bbbaec745887314ddcf7a8aa4136 8185844: MSCAPI doesn't list aliases correctly Reviewed-by: valeriep ! src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/CKeyStore.java + test/jdk/sun/security/mscapi/SetDupNameEntry.java Changeset: 10e1610f Author: Weijun Wang Date: 2021-10-26 02:45:23 +0000 URL: https://git.openjdk.java.net/loom/commit/10e1610f7b99f42f834478528df7ecfb4320aec1 8251134: Unwrapping a key with a Private Key generated by Microsoft CNG fails Reviewed-by: valeriep ! src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/CKeyStore.java ! src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/CRSACipher.java ! src/jdk.crypto.mscapi/windows/native/libsunmscapi/security.cpp + test/jdk/sun/security/mscapi/CngCipher.java Changeset: 3ff085e2 Author: Thomas Stuefe Date: 2021-10-26 04:52:01 +0000 URL: https://git.openjdk.java.net/loom/commit/3ff085e2967508ad312c9d32fa908807aefe69ee 8275582: Don't purge metaspace mapping lists Reviewed-by: coleenp, lkorinth ! src/hotspot/share/memory/metaspace/chunkManager.cpp ! src/hotspot/share/memory/metaspace/internalStats.hpp ! src/hotspot/share/memory/metaspace/rootChunkArea.cpp ! src/hotspot/share/memory/metaspace/rootChunkArea.hpp ! src/hotspot/share/memory/metaspace/virtualSpaceList.cpp ! src/hotspot/share/memory/metaspace/virtualSpaceList.hpp ! src/hotspot/share/memory/metaspace/virtualSpaceNode.cpp ! src/hotspot/share/memory/metaspace/virtualSpaceNode.hpp ! test/hotspot/jtreg/runtime/Metaspace/elastic/MetaspaceTestWithThreads.java Changeset: 174f553f Author: Harold Seigel Date: 2021-10-26 12:05:09 +0000 URL: https://git.openjdk.java.net/loom/commit/174f553f7e3dbc91662ba51bc3813a4be0ee97c4 8275869: Problem list applications/jcstress/copy.java on Linux-aarch64 Reviewed-by: lfoltan, dholmes ! test/hotspot/jtreg/ProblemList.txt Changeset: 4961373a Author: Julia Boes Date: 2021-10-26 12:17:47 +0000 URL: https://git.openjdk.java.net/loom/commit/4961373a676126cd557f92a2e7bbc8c66b2976b1 8275137: jdk.unsupported/sun.reflect.ReflectionFactory.readObjectNoDataForSerialization uses wrong signature Reviewed-by: dfuchs ! src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java ! src/jdk.unsupported/share/classes/sun/reflect/ReflectionFactory.java ! test/jdk/sun/reflect/ReflectionFactory/ReflectionFactoryTest.java Changeset: 63e0f344 Author: Naoto Sato Date: 2021-10-26 12:32:49 +0000 URL: https://git.openjdk.java.net/loom/commit/63e0f344e9a2da135c76caff11e437dfc40408a6 8275767: JDK source code contains redundant boolean operations in jdk.charsets Reviewed-by: lancea, rriggs, iris ! src/jdk.charsets/share/classes/sun/nio/cs/ext/IBM964.java.template ! src/jdk.charsets/share/classes/sun/nio/cs/ext/SimpleEUCEncoder.java.template Changeset: 4be88d54 Author: Jatin Bhateja Date: 2021-10-26 12:34:56 +0000 URL: https://git.openjdk.java.net/loom/commit/4be88d5482d45e22eb756a6e2ad19ebd7110639a 8275047: Optimize existing fill stubs for AVX-512 target Reviewed-by: kvn, redestad ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/stubRoutines_x86.hpp ! src/hotspot/cpu/x86/vm_version_x86.cpp ! test/micro/org/openjdk/bench/java/util/ArraysFill.java Changeset: 7ca053de Author: Harold Seigel Date: 2021-10-26 12:37:54 +0000 URL: https://git.openjdk.java.net/loom/commit/7ca053de218bf76ea06bbeed860d142db381ca53 8251904: vmTestbase/nsk/sysdict/vm/stress/btree/btree010/btree010.java fails with ClassNotFoundException: nsk.sysdict.share.BTree0LLRLRLRRLR Reviewed-by: dholmes, lmesnik ! test/hotspot/jtreg/vmTestbase/nsk/sysdict/share/BTreeTest.java ! test/hotspot/jtreg/vmTestbase/nsk/sysdict/share/SysDictTest.java Changeset: 71d593ed Author: Coleen Phillimore Date: 2021-10-26 14:33:22 +0000 URL: https://git.openjdk.java.net/loom/commit/71d593ede6e1d0a50798d4ba6bfbd78aa65ae7d8 8275162: Use varargs in 'def' macros in mutexLocker.cpp Reviewed-by: dholmes, pchilanomate ! src/hotspot/share/runtime/mutexLocker.cpp Changeset: b98ed550 Author: Anton Tarasov Date: 2021-10-26 15:23:43 +0000 URL: https://git.openjdk.java.net/loom/commit/b98ed55060b5f3b7832ec28064b04577e3725cc2 8275819: [TableRowAccessibility accessibilityChildren] method is ineffective Reviewed-by: pbansal, kizune ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TableRowAccessibility.m Changeset: c9dec2f9 Author: Andrey Turbanov Committer: Weijun Wang Date: 2021-10-26 15:25:23 +0000 URL: https://git.openjdk.java.net/loom/commit/c9dec2f9849f98048f32ccef4e5573ce21204fbb 8273299: Unnecessary Vector usage in java.security.jgss Reviewed-by: weijun ! src/java.security.jgss/share/classes/sun/security/jgss/GSSCredentialImpl.java ! src/java.security.jgss/share/classes/sun/security/krb5/PrincipalName.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/Authenticator.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/AuthorizationData.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/EncAPRepPart.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/HostAddresses.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/KDCReqBody.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/KRBCred.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/KrbCredInfo.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/LastReq.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/PAData.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java Changeset: 7c88a59b Author: Anton Tarasov Date: 2021-10-26 15:26:45 +0000 URL: https://git.openjdk.java.net/loom/commit/7c88a59b7bca50061f120a1cf2c1d4457a1d741b 8275809: crash in [CommonComponentAccessibility getCAccessible:withEnv:] Reviewed-by: kizune, pbansal ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m Changeset: 574f8903 Author: Anton Tarasov Date: 2021-10-26 15:47:17 +0000 URL: https://git.openjdk.java.net/loom/commit/574f8903ee1f74bdf7154d670d96c36d94b38b4d 8275720: CommonComponentAccessibility.createWithParent isWrapped causes mem leak Reviewed-by: kizune, pbansal ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CellAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CellAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ComponentWrapperAccessibility.h + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ComponentWrapperAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ListRowAccessibility.h ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ListRowAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/OutlineRowAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TableRowAccessibility.m Changeset: 82f4aacb Author: Roland Westrelin Date: 2021-10-26 15:53:37 +0000 URL: https://git.openjdk.java.net/loom/commit/82f4aacb42e60e9cd00e199703a869e7ad4465ff 8259609: C2: optimize long range checks in long counted loops Co-authored-by: John R Rose Reviewed-by: thartmann, jrose ! src/hotspot/share/opto/addnode.cpp ! src/hotspot/share/opto/loopPredicate.cpp ! src/hotspot/share/opto/loopTransform.cpp ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/loopnode.hpp ! src/hotspot/share/opto/loopopts.cpp ! src/hotspot/share/opto/mulnode.hpp ! src/hotspot/share/opto/node.hpp ! src/hotspot/share/opto/phaseX.cpp ! src/hotspot/share/opto/subnode.hpp + test/hotspot/jtreg/compiler/c2/irTests/TestLongRangeChecks.java + test/hotspot/jtreg/compiler/rangechecks/TestLongRangeCheck.java + test/hotspot/jtreg/compiler/rangechecks/TestRCMinInt.java Changeset: e5cd2692 Author: Calvin Cheung Date: 2021-10-26 16:26:57 +0000 URL: https://git.openjdk.java.net/loom/commit/e5cd2692da6327c6fde954f86595a08fe5edf43f 8274944: AppCDS dump causes SEGV in VM thread while adjusting lambda proxy class info Reviewed-by: minqi, dholmes ! src/hotspot/share/cds/dynamicArchive.cpp ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/classfile/systemDictionaryShared.hpp ! test/hotspot/jtreg/TEST.groups + test/hotspot/jtreg/runtime/cds/appcds/LambdaContainsOldInf.java + test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/LambdaContainsOldInf.java + test/hotspot/jtreg/runtime/cds/appcds/test-classes/LambdaContainsOldInfApp.java + test/hotspot/jtreg/runtime/cds/appcds/test-classes/OldProvider.jasm Changeset: 19f76c21 Author: Andrey Turbanov Committer: Daniel Fuchs Date: 2021-10-26 16:40:55 +0000 URL: https://git.openjdk.java.net/loom/commit/19f76c215dbe9528dde10acd744be54618ea5e4c 8275079: Remove unnecessary conversion to String in java.net.http Reviewed-by: dfuchs ! src/java.net.http/share/classes/jdk/internal/net/http/AuthenticationFilter.java ! src/java.net.http/share/classes/jdk/internal/net/http/Http1AsyncReceiver.java ! src/java.net.http/share/classes/jdk/internal/net/http/Http1Request.java ! src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java ! src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java ! src/java.net.http/share/classes/jdk/internal/net/http/HttpRequestImpl.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/Demand.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/SSLFlowDelegate.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/SubscriberWrapper.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java ! src/java.net.http/share/classes/jdk/internal/net/http/frame/ErrorFrame.java ! src/java.net.http/share/classes/jdk/internal/net/http/frame/Http2Frame.java ! src/java.net.http/share/classes/jdk/internal/net/http/frame/SettingsFrame.java Changeset: f1f5e269 Author: Ji?? Van?k Committer: Magnus Ihse Bursie Date: 2021-10-26 16:54:55 +0000 URL: https://git.openjdk.java.net/loom/commit/f1f5e2690cb93c07eb8be96a4cbfbf140e8a15e0 8275872: Sync J2DBench run and analyze Makefile targets with build.xml Reviewed-by: ihse, andrew ! src/demo/share/java2d/J2DBench/Makefile Changeset: 2448b3f5 Author: Doug Simon Date: 2021-10-26 18:50:21 +0000 URL: https://git.openjdk.java.net/loom/commit/2448b3f5f96ec4d9ea8fe9dae32a0aab725fb4ad 8275874: [JVMCI] only support aligned reads in c2v_readFieldValue Reviewed-by: never, shade ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/CompilerToVM.java ! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/MemoryAccessProvider.java ! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.hotspot.test/src/jdk/vm/ci/hotspot/test/MemoryAccessProviderData.java ! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.hotspot.test/src/jdk/vm/ci/hotspot/test/MemoryAccessProviderTest.java Changeset: 7addcd7c Author: Daniel D. Daugherty Date: 2021-10-26 22:03:18 +0000 URL: https://git.openjdk.java.net/loom/commit/7addcd7cfb73652841c65c54e84b6ebffcbd664e 8276034: ProblemList gtest dll_address_to_function_and_library_name on macosx-x64 Reviewed-by: prr ! test/hotspot/gtest/runtime/test_os.cpp Changeset: b0d1e4ff Author: Yi Yang Date: 2021-10-27 01:21:12 +0000 URL: https://git.openjdk.java.net/loom/commit/b0d1e4ff4d3806851fe998717822e8e52987357c 8273585: String.charAt performance degrades due to JDK-8268698 Reviewed-by: roland, kvn ! src/hotspot/share/opto/loopnode.cpp Changeset: d98b7c25 Author: Alexander Zvegintsev Date: 2021-10-27 01:58:11 +0000 URL: https://git.openjdk.java.net/loom/commit/d98b7c25910d38ac644838f59cb41ecd131c87a9 8202926: Test java/awt/Focus/WindowUpdateFocusabilityTest/WindowUpdateFocusabilityTest.html fails Reviewed-by: serb ! test/jdk/ProblemList.txt Changeset: 9f75d5ce Author: Wang Huang Committer: Ningsheng Jian Date: 2021-10-27 05:32:50 +0000 URL: https://git.openjdk.java.net/loom/commit/9f75d5ce500886b32175cc541939b7f0eee190ca 8259948: Aarch64: Add cast nodes for Aarch64 Neon backend Co-authored-by: Wang Huang Co-authored-by: Wu Yan Co-authored-by: Miao Zhuojun Reviewed-by: aph, eliu, njian ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/aarch64_neon.ad ! src/hotspot/cpu/aarch64/aarch64_neon_ad.m4 ! src/hotspot/cpu/aarch64/assembler_aarch64.hpp ! test/hotspot/gtest/aarch64/aarch64-asmtest.py ! test/hotspot/gtest/aarch64/asmtest.out.h Changeset: 9e831bcc Author: Albert Mingkun Yang Date: 2021-10-27 08:24:44 +0000 URL: https://git.openjdk.java.net/loom/commit/9e831bccd2fc90681b32d1504eca753462afc6f6 8275886: G1: remove obsolete comment in HeapRegion::setup_heap_region_size Reviewed-by: mli, tschatzl ! src/hotspot/share/gc/g1/heapRegion.cpp Changeset: 2f979ecb Author: Jayathirth D V Date: 2021-10-27 09:29:37 +0000 URL: https://git.openjdk.java.net/loom/commit/2f979ecb5b642d04ad280687de76a6ee46818b35 8213120: java/awt/TextArea/AutoScrollOnSelectAndAppend/AutoScrollOnSelectAndAppend.java fails on mac10.13 Reviewed-by: psadhukhan ! test/jdk/ProblemList.txt ! test/jdk/java/awt/TextArea/AutoScrollOnSelectAndAppend/AutoScrollOnSelectAndAppend.java Changeset: 6c05cc9d Author: Claes Redestad Date: 2021-10-27 10:07:46 +0000 URL: https://git.openjdk.java.net/loom/commit/6c05cc9d15fb6014b8293a66ef132f3461badca1 8275863: Use encodeASCII for ASCII-compatible DoubleByte encodings Reviewed-by: naoto, rriggs, alanb ! src/java.base/share/classes/module-info.java ! src/java.base/share/classes/sun/nio/cs/DoubleByte.java ! src/java.base/share/classes/sun/nio/cs/HKSCS.java ! src/java.base/share/lib/security/default.policy ! src/jdk.charsets/share/classes/sun/nio/cs/ext/EUC_JP.java.template Changeset: b3f45f86 Author: Jayathirth D V Date: 2021-10-27 10:21:28 +0000 URL: https://git.openjdk.java.net/loom/commit/b3f45f868d9c91d630a118e43cef54cdb3216fd0 8275689: [TESTBUG] Use color tolerance only for XRender in BlitRotateClippedArea test Reviewed-by: serb ! test/jdk/java/awt/image/DrawImage/BlitRotateClippedArea.java Changeset: 485d6586 Author: Prasanta Sadhukhan Date: 2021-10-27 10:24:21 +0000 URL: https://git.openjdk.java.net/loom/commit/485d65865ea8af3f7275e9aa8b75057326486a4d 8275851: Deproblemlist open/test/jdk/javax/swing/JComponent/6683775/bug6683775.java Reviewed-by: serb ! test/jdk/ProblemList.txt ! test/jdk/javax/swing/JComponent/6683775/bug6683775.java Changeset: 40606021 Author: Coleen Phillimore Date: 2021-10-27 12:09:46 +0000 URL: https://git.openjdk.java.net/loom/commit/40606021ee6b7d18674e36b3f6249f1ca8a7647e 8275800: Redefinition leaks MethodData::_extra_data_lock Reviewed-by: sspitsyn, dholmes ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/oops/klass.cpp ! src/hotspot/share/oops/klass.hpp ! src/hotspot/share/prims/jvmtiRedefineClasses.cpp Changeset: a2927333 Author: Tobias Hartmann Date: 2021-10-27 12:27:43 +0000 URL: https://git.openjdk.java.net/loom/commit/a29273336bae75e8d185fa7f7c789acbec50a619 8275975: Remove dead code in ciInstanceKlass Reviewed-by: chagedorn, kvn ! src/hotspot/share/ci/ciArrayKlass.hpp ! src/hotspot/share/ci/ciInstanceKlass.cpp ! src/hotspot/share/ci/ciInstanceKlass.hpp Changeset: 168081ef Author: Naoto Sato Date: 2021-10-27 12:39:46 +0000 URL: https://git.openjdk.java.net/loom/commit/168081efc8af1f5d1d7524246eb4a0675bd49ae0 8270490: Charset.forName() taking fallback default value Reviewed-by: joehw, rriggs, serb, dfuchs ! src/java.base/share/classes/java/io/Console.java ! src/java.base/share/classes/java/nio/charset/Charset.java + test/jdk/java/nio/charset/Charset/ForName.java Changeset: 93be099c Author: Stefan Karlsson Date: 2021-10-27 13:23:24 +0000 URL: https://git.openjdk.java.net/loom/commit/93be099ccb73c88532866ae6d0c288c12a592cc4 4718400: Many quantities are held as signed that should be unsigned Reviewed-by: coleenp, rbackman, dholmes ! src/hotspot/share/cds/heapShared.cpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/classfile/javaClasses.inline.hpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/g1/g1ConcurrentMarkBitMap.inline.hpp ! src/hotspot/share/gc/g1/g1ConcurrentMarkObjArrayProcessor.cpp ! src/hotspot/share/gc/g1/g1ConcurrentMarkObjArrayProcessor.inline.hpp ! src/hotspot/share/gc/g1/g1RegionMarkStatsCache.cpp ! src/hotspot/share/gc/g1/g1YoungCollector.cpp ! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp ! src/hotspot/share/gc/g1/heapRegion.inline.hpp ! src/hotspot/share/gc/parallel/parMarkBitMap.hpp ! src/hotspot/share/gc/parallel/parMarkBitMap.inline.hpp ! src/hotspot/share/gc/parallel/psClosure.inline.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.inline.hpp ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/serial/markSweep.hpp ! src/hotspot/share/gc/serial/markSweep.inline.hpp ! src/hotspot/share/gc/shared/cardTableBarrierSet.cpp ! src/hotspot/share/gc/shared/collectedHeap.hpp ! src/hotspot/share/gc/shared/collectedHeap.inline.hpp ! src/hotspot/share/gc/shared/genCollectedHeap.cpp ! src/hotspot/share/gc/shared/generation.cpp ! src/hotspot/share/gc/shared/memAllocator.cpp ! src/hotspot/share/gc/shared/space.cpp ! src/hotspot/share/gc/shared/space.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp ! src/hotspot/share/gc/z/zCollectedHeap.cpp ! src/hotspot/share/gc/z/zCollectedHeap.hpp ! src/hotspot/share/jfr/leakprofiler/chains/edgeUtils.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/memory/heapInspection.hpp ! src/hotspot/share/oops/arrayKlass.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/oops/instanceMirrorKlass.cpp ! src/hotspot/share/oops/instanceMirrorKlass.hpp ! src/hotspot/share/oops/klass.hpp ! src/hotspot/share/oops/objArrayKlass.cpp ! src/hotspot/share/oops/objArrayKlass.hpp ! src/hotspot/share/oops/objArrayOop.hpp ! src/hotspot/share/oops/oop.hpp ! src/hotspot/share/oops/oop.inline.hpp ! src/hotspot/share/oops/typeArrayKlass.cpp ! src/hotspot/share/oops/typeArrayKlass.hpp ! src/hotspot/share/oops/typeArrayOop.hpp ! src/hotspot/share/oops/typeArrayOop.inline.hpp ! src/hotspot/share/opto/runtime.cpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/runtime/deoptimization.cpp Changeset: 809488bf Author: Thomas Stuefe Date: 2021-10-27 13:40:51 +0000 URL: https://git.openjdk.java.net/loom/commit/809488bf38c250db3c263f200e5eb1a269059c3d 8276046: codestrings.validate_vm gtest fails on ppc64, s390 Reviewed-by: shade, mdoerr ! test/hotspot/gtest/code/test_codestrings.cpp Changeset: e6fa5fa3 Author: Daniel D. Daugherty Date: 2021-10-27 14:24:02 +0000 URL: https://git.openjdk.java.net/loom/commit/e6fa5fa37e73cd952fb93cc57091775b748ace9a 8276063: ProblemList gtest dll_address_to_function_and_library_name on macosx-generic Reviewed-by: tschatzl ! test/hotspot/gtest/runtime/test_os.cpp Changeset: 9a3e9542 Author: Andrey Turbanov Committer: Naoto Sato Date: 2021-10-27 16:18:12 +0000 URL: https://git.openjdk.java.net/loom/commit/9a3e9542997860de79d07a4411b1007e9cd5c348 8274879: Replace uses of StringBuffer with StringBuilder within java.base classes Reviewed-by: naoto ! src/java.base/share/classes/java/io/FilePermission.java ! src/java.base/share/classes/java/net/SocketPermission.java ! src/java.base/share/classes/java/net/URL.java ! src/java.base/share/classes/java/text/AttributedString.java ! src/java.base/share/classes/java/text/ChoiceFormat.java ! src/java.base/share/classes/java/text/CompactNumberFormat.java ! src/java.base/share/classes/java/text/DecimalFormat.java ! src/java.base/share/classes/java/text/RBTableBuilder.java ! src/java.base/share/classes/sun/security/util/Debug.java ! src/java.base/share/classes/sun/util/calendar/JulianCalendar.java ! src/java.base/share/classes/sun/util/calendar/LocalGregorianCalendar.java From duke at openjdk.java.net Mon Nov 1 17:56:18 2021 From: duke at openjdk.java.net (duke) Date: Mon, 1 Nov 2021 17:56:18 GMT Subject: git: openjdk/loom: fibers: Add a test for virtual cleaner threads Message-ID: Changeset: 067b2965 Author: Ron Pressler Date: 2021-11-01 17:55:35 +0000 URL: https://git.openjdk.java.net/loom/commit/067b29651f8902c667a2e34020fe1bad1d017241 Add a test for virtual cleaner threads ! test/jdk/java/lang/ref/CleanerTest.java From duke at openjdk.java.net Mon Nov 1 20:09:11 2021 From: duke at openjdk.java.net (duke) Date: Mon, 1 Nov 2021 20:09:11 GMT Subject: git: openjdk/loom: fibers: 2 new changesets Message-ID: Changeset: c87d2e06 Author: lmesnik Date: 2021-11-01 13:06:37 +0000 URL: https://git.openjdk.java.net/loom/commit/c87d2e06ebd0df36c869d97e56a0cb373b950bde serviceability/jvmti/thread/GetFrameCount/framecnt01/framecnt01.java fixed to wait until vthread is parked ! test/hotspot/jtreg/serviceability/jvmti/thread/GetFrameCount/framecnt01/framecnt01.java Changeset: 400db840 Author: lmesnik Date: 2021-11-01 13:07:48 +0000 URL: https://git.openjdk.java.net/loom/commit/400db840d1487a7ae3e565c7b70a013a2164b3fd Merge branch 'fibers' of https://github.com/openjdk/loom into fibers From duke at openjdk.java.net Tue Nov 2 06:21:03 2021 From: duke at openjdk.java.net (duke) Date: Tue, 2 Nov 2021 06:21:03 GMT Subject: git: openjdk/loom: fibers: 19 new changesets Message-ID: <4ff92511-7d4a-44c1-ae0b-bc725213b869@openjdk.java.net> Changeset: d9b0138d Author: Thomas Stuefe Date: 2021-10-28 05:29:58 +0000 URL: https://git.openjdk.java.net/loom/commit/d9b0138d7d02ceddc5d9c73908177f0b0d2e7c54 8275704: Metaspace::contains() should be threadsafe Reviewed-by: coleenp, dholmes ! src/hotspot/share/memory/metaspace/virtualSpaceList.cpp ! src/hotspot/share/memory/metaspace/virtualSpaceList.hpp Changeset: 1750a6e2 Author: Per Liden Date: 2021-10-28 05:44:32 +0000 URL: https://git.openjdk.java.net/loom/commit/1750a6e2c06960b734f646018fc99b336bd966a5 8276055: ZGC: Defragment address space Reviewed-by: eosterlund, stefank ! src/hotspot/share/gc/z/zMemory.cpp ! src/hotspot/share/gc/z/zMemory.hpp ! src/hotspot/share/gc/z/zPageAllocator.cpp ! src/hotspot/share/gc/z/zPageAllocator.hpp ! src/hotspot/share/gc/z/zPhysicalMemory.cpp ! src/hotspot/share/gc/z/zVirtualMemory.cpp ! src/hotspot/share/gc/z/zVirtualMemory.hpp ! src/hotspot/share/gc/z/zVirtualMemory.inline.hpp Changeset: a2f2d8fc Author: Aleksey Shipilev Date: 2021-10-28 08:27:44 +0000 URL: https://git.openjdk.java.net/loom/commit/a2f2d8fcf511de2754a76a5d9f9acdfef462919b 8276057: Update JMH devkit to 1.33 Reviewed-by: aph, redestad, erikj ! make/devkit/createJMHBundle.sh Changeset: 593401fe Author: Andrey Turbanov Committer: Aleksei Efimov Date: 2021-10-28 08:42:10 +0000 URL: https://git.openjdk.java.net/loom/commit/593401fe8b38bbb8d331a862818fe077af157fcb 8276042: Remove unused local variables in java.naming Reviewed-by: aefimov, dfuchs, vtewari ! src/java.naming/share/classes/com/sun/jndi/ldap/Filter.java ! src/java.naming/share/classes/com/sun/jndi/ldap/LdapCtx.java ! src/java.naming/share/classes/com/sun/jndi/ldap/sasl/SaslOutputStream.java ! src/java.naming/share/classes/com/sun/jndi/toolkit/ctx/Continuation.java ! src/java.naming/share/classes/com/sun/jndi/toolkit/ctx/PartialCompositeContext.java Changeset: d88b89f8 Author: Per Liden Date: 2021-10-28 10:10:05 +0000 URL: https://git.openjdk.java.net/loom/commit/d88b89f89643dd97092b1debf98e871f873e8f9c 8276067: ZGC: Remove unused function alloc_high_address_at_most() Reviewed-by: eosterlund, stefank ! src/hotspot/share/gc/z/zMemory.cpp ! src/hotspot/share/gc/z/zMemory.hpp Changeset: 7c996d57 Author: Hannes Walln?fer Date: 2021-10-28 10:41:49 +0000 URL: https://git.openjdk.java.net/loom/commit/7c996d572cc10045b7f6bc301916dcbd349b6ef4 8269401: Merge "Exceptions" and "Errors" into "Exception Classes" Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllClassesIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Contents.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HelpWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlIds.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SummaryListWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_ja.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_zh_CN.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/SummaryAPIListBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/TypeElementCatalog.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java ! test/langtools/jdk/javadoc/doclet/testDeprecatedDocs/TestDeprecatedDocs.java ! test/langtools/jdk/javadoc/doclet/testHtmlTableTags/TestHtmlTableTags.java ! test/langtools/jdk/javadoc/doclet/testModules/TestModules.java ! test/langtools/jdk/javadoc/doclet/testNewApiList/TestNewApiList.java ! test/langtools/jdk/javadoc/doclet/testSearch/TestSearch.java ! test/langtools/jdk/javadoc/doclet/testSystemPropertyTaglet/TestSystemPropertyTaglet.java ! test/langtools/jdk/javadoc/tool/CheckResourceKeys.java Changeset: bec977c7 Author: Coleen Phillimore Date: 2021-10-28 11:57:21 +0000 URL: https://git.openjdk.java.net/loom/commit/bec977c778a35ea48a45db662f1feaeab79308b2 8275917: Some locks shouldn't allow_vm_block Reviewed-by: dholmes, pchilanomate ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/runtime/mutexLocker.cpp Changeset: a343fa87 Author: Volker Simonis Date: 2021-10-28 12:40:30 +0000 URL: https://git.openjdk.java.net/loom/commit/a343fa8766bb12188881319f06b1d93161cf1619 8275865: Print deoptimization statistics in product builds Reviewed-by: thartmann, kvn ! src/hotspot/share/runtime/java.cpp + test/hotspot/jtreg/runtime/logging/DeoptStats.java Changeset: 85d8cd85 Author: Thomas Schatzl Date: 2021-10-28 12:58:03 +0000 URL: https://git.openjdk.java.net/loom/commit/85d8cd85665d92d67bbc88399baaa8fe7eba14a6 8276100: Remove G1SegmentedArray constructor name parameter Reviewed-by: ayang ! src/hotspot/share/gc/g1/g1CardSetMemory.cpp ! src/hotspot/share/gc/g1/g1SegmentedArray.hpp ! src/hotspot/share/gc/g1/g1SegmentedArray.inline.hpp Changeset: abe52aea Author: Ludvig Janiuk Committer: Jonathan Gibbons Date: 2021-10-28 14:40:53 +0000 URL: https://git.openjdk.java.net/loom/commit/abe52aea23d6025737666dfc2b265fdf1aae14bb 8275518: accessibility issue in Inet6Address docs Reviewed-by: ihse, jjg ! src/java.base/share/classes/java/net/Inet6Address.java Changeset: 309acbf0 Author: Mandy Chung Date: 2021-10-28 15:27:26 +0000 URL: https://git.openjdk.java.net/loom/commit/309acbf0e86a0d248294503fccc7a936fa0a846e 8275703: System.loadLibrary fails on Big Sur for libraries hidden from filesystem Reviewed-by: dholmes, alanb, mcimadamore ! make/test/JtregNativeJdk.gmk ! src/hotspot/share/include/jvm.h ! src/hotspot/share/prims/jvm.cpp ! src/java.base/macosx/classes/jdk/internal/loader/ClassLoaderHelper.java ! src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java ! src/java.base/share/native/libjava/NativeLibraries.c ! src/java.base/unix/classes/jdk/internal/loader/ClassLoaderHelper.java ! src/java.base/windows/classes/jdk/internal/loader/ClassLoaderHelper.java + test/jdk/java/lang/RuntimeTests/loadLibrary/exeLibraryCache/LibraryFromCache.java + test/jdk/java/lang/RuntimeTests/loadLibrary/exeLibraryCache/exeLibraryCache.c Changeset: c92f2305 Author: Prasanta Sadhukhan Date: 2021-10-28 15:37:15 +0000 URL: https://git.openjdk.java.net/loom/commit/c92f23055724d2df462f64fc51e57f5a13f679bb 8276110: Problemlist javax/swing/JMenu/4515762/bug4515762.java for macos12 Reviewed-by: azvegint ! test/jdk/ProblemList.txt Changeset: cb989cf3 Author: Andrew Haley Date: 2021-10-28 15:51:29 +0000 URL: https://git.openjdk.java.net/loom/commit/cb989cf3a182ee07fe127b4536e7ff4213f31eaf 8275052: AArch64: Severe AES/GCM slowdown on MacOS for short blocks Reviewed-by: ngasson, adinn ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp ! src/hotspot/os_cpu/bsd_aarch64/vm_version_bsd_aarch64.cpp Changeset: 63b9f8c0 Author: Mitsuru Kariya Committer: Lance Andersen Date: 2021-10-28 15:56:17 +0000 URL: https://git.openjdk.java.net/loom/commit/63b9f8c0da2ed3634002f0f67b18555826aeddc4 8153490: Cannot setBytes() if incoming buffer's length is bigger than number of elements we want to insert. Reviewed-by: lancea ! src/java.sql.rowset/share/classes/javax/sql/rowset/serial/SerialBlob.java ! src/java.sql.rowset/share/classes/javax/sql/rowset/serial/SerialClob.java ! test/jdk/javax/sql/testng/test/rowset/serial/SerialBlobTests.java ! test/jdk/javax/sql/testng/test/rowset/serial/SerialClobTests.java Changeset: 6d8fa8f6 Author: Aleksey Shipilev Date: 2021-10-28 17:13:08 +0000 URL: https://git.openjdk.java.net/loom/commit/6d8fa8f6632a78dc79786cb102ba20f6834ad3f4 8255286: Implement ParametersTypeData::print_data_on fully Reviewed-by: dholmes ! src/hotspot/share/oops/methodData.cpp Changeset: 5a768f75 Author: Aleksey Shipilev Date: 2021-10-28 17:32:39 +0000 URL: https://git.openjdk.java.net/loom/commit/5a768f75c9cb013edbf6c61e79820bd180cad4ba 8276054: JMH benchmarks for Fences Reviewed-by: redestad + test/micro/org/openjdk/bench/vm/fences/Multiple.java + test/micro/org/openjdk/bench/vm/fences/MultipleWithLoads.java + test/micro/org/openjdk/bench/vm/fences/MultipleWithStores.java + test/micro/org/openjdk/bench/vm/fences/SafePublishing.java + test/micro/org/openjdk/bench/vm/fences/Single.java Changeset: c6339cb8 Author: Mandy Chung Date: 2021-10-28 18:32:50 +0000 URL: https://git.openjdk.java.net/loom/commit/c6339cb8a255d387bb182ad20dd69f3d460cf1ed 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle 8013527: calling MethodHandles.lookup on itself leads to errors Co-authored-by: Peter Levart Co-authored-by: Claes Redestad Co-authored-by: Mandy Chung Reviewed-by: mcimadamore, plevart, egahlin, redestad, cjplummer, alanb ! make/jdk/src/classes/build/tools/classlist/HelloClasslist.java ! src/hotspot/share/ci/ciField.cpp ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/reflect/Constructor.java ! src/java.base/share/classes/java/lang/reflect/Field.java ! src/java.base/share/classes/java/lang/reflect/Method.java ! src/java.base/share/classes/jdk/internal/access/JavaLangInvokeAccess.java ! src/java.base/share/classes/jdk/internal/access/SharedSecrets.java ! src/java.base/share/classes/jdk/internal/misc/VM.java + src/java.base/share/classes/jdk/internal/reflect/AccessorUtils.java + src/java.base/share/classes/jdk/internal/reflect/CallerSensitiveAdapter.java + src/java.base/share/classes/jdk/internal/reflect/CsMethodAccessorAdapter.java ! src/java.base/share/classes/jdk/internal/reflect/DelegatingConstructorAccessorImpl.java ! src/java.base/share/classes/jdk/internal/reflect/DelegatingMethodAccessorImpl.java + src/java.base/share/classes/jdk/internal/reflect/DirectConstructorHandleAccessor.java + src/java.base/share/classes/jdk/internal/reflect/DirectMethodHandleAccessor.java ! src/java.base/share/classes/jdk/internal/reflect/FieldAccessorImpl.java ! src/java.base/share/classes/jdk/internal/reflect/MethodAccessor.java ! src/java.base/share/classes/jdk/internal/reflect/MethodAccessorGenerator.java ! src/java.base/share/classes/jdk/internal/reflect/MethodAccessorImpl.java + src/java.base/share/classes/jdk/internal/reflect/MethodHandleAccessorFactory.java + src/java.base/share/classes/jdk/internal/reflect/MethodHandleBooleanFieldAccessorImpl.java + src/java.base/share/classes/jdk/internal/reflect/MethodHandleByteFieldAccessorImpl.java + src/java.base/share/classes/jdk/internal/reflect/MethodHandleCharacterFieldAccessorImpl.java + src/java.base/share/classes/jdk/internal/reflect/MethodHandleDoubleFieldAccessorImpl.java + src/java.base/share/classes/jdk/internal/reflect/MethodHandleFieldAccessorImpl.java + src/java.base/share/classes/jdk/internal/reflect/MethodHandleFloatFieldAccessorImpl.java + src/java.base/share/classes/jdk/internal/reflect/MethodHandleIntegerFieldAccessorImpl.java + src/java.base/share/classes/jdk/internal/reflect/MethodHandleLongFieldAccessorImpl.java + src/java.base/share/classes/jdk/internal/reflect/MethodHandleObjectFieldAccessorImpl.java + src/java.base/share/classes/jdk/internal/reflect/MethodHandleShortFieldAccessorImpl.java ! src/java.base/share/classes/jdk/internal/reflect/NativeConstructorAccessorImpl.java ! src/java.base/share/classes/jdk/internal/reflect/NativeMethodAccessorImpl.java ! src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java ! src/java.base/share/classes/jdk/internal/reflect/UnsafeFieldAccessorImpl.java ! src/java.base/share/classes/jdk/internal/reflect/UnsafeStaticFieldAccessorImpl.java ! src/java.base/share/native/libjava/NativeAccessors.c ! src/java.logging/share/classes/java/util/logging/Logger.java ! src/java.sql/share/classes/java/sql/DriverManager.java ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/serviceability/dcmd/vm/ShowReflectionTargetTest.java ! test/jdk/com/sun/jdi/EATests.java ! test/jdk/java/lang/StackWalker/DumpStackTest.java ! test/jdk/java/lang/StackWalker/NativeMethod.java ! test/jdk/java/lang/StackWalker/VerifyStackTrace.java + test/jdk/java/lang/StackWalker/libnativeMethod.c + test/jdk/java/lang/invoke/CallerSensitiveMethodHandle.java + test/jdk/java/lang/invoke/MethodHandleInvokeUOE.java = test/jdk/java/lang/invoke/callerSensitive/CallerSensitiveAccess.java + test/jdk/java/lang/invoke/callerSensitive/Main.java + test/jdk/java/lang/invoke/callerSensitive/csm/jdk/test/MethodInvokeTest.java + test/jdk/java/lang/invoke/callerSensitive/csm/module-info.java + test/jdk/java/lang/invoke/callerSensitive/src/java.base/java/util/CSM.java + test/jdk/java/lang/invoke/lookup/ChainedLookupTest.java ! test/jdk/java/lang/invoke/lookup/ReflectiveLookupTest.java ! test/jdk/java/lang/invoke/lookup/java.base/java/lang/LookupTest.java + test/jdk/java/lang/reflect/ChainedReflection.java ! test/jdk/java/lang/reflect/Field/TestFieldReflectValueOf.java + test/jdk/java/lang/reflect/Method/MethodArityLimit.java + test/jdk/java/lang/reflect/MethodHandleAccessorsTest.java + test/jdk/java/lang/reflect/callerCache/CustomLoaderTest.java + test/jdk/java/lang/reflect/callerCache/ReflectTest.java + test/jdk/java/lang/reflect/classInitialization/ExceptionInClassInitialization.java + test/jdk/java/lang/reflect/classInitialization/Initializer.java + test/jdk/java/lang/reflect/classInitialization/Test.java ! test/jdk/jdk/internal/reflect/CallerSensitive/CheckCSMs.java ! test/jdk/jdk/internal/reflect/Reflection/GetCallerClass.java ! test/jdk/jdk/internal/reflect/Reflection/GetCallerClassTest.java ! test/jdk/jdk/jfr/api/consumer/TestHiddenMethod.java ! test/langtools/jdk/jshell/ExceptionsTest.java ! test/micro/org/openjdk/bench/java/lang/reflect/ReflectionColdstartBenchmark.java ! test/micro/org/openjdk/bench/java/lang/reflect/ReflectionSpeedBenchmark.java Changeset: a1b27004 Author: Alan Bateman Date: 2021-11-01 20:41:04 +0000 URL: https://git.openjdk.java.net/loom/commit/a1b27004cfa92ce880da1f13e8369acefa3a975e Merge with c6339cb8a255d387bb182ad20dd69f3d460cf1ed ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/include/jvm.h ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/runtime/java.cpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/java.base/share/classes/jdk/internal/access/JavaLangInvokeAccess.java ! src/java.base/share/classes/jdk/internal/access/SharedSecrets.java ! test/hotspot/jtreg/ProblemList.txt ! test/jdk/ProblemList.txt ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/include/jvm.h ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/runtime/java.cpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/java.base/share/classes/jdk/internal/access/JavaLangInvokeAccess.java ! src/java.base/share/classes/jdk/internal/access/SharedSecrets.java ! test/hotspot/jtreg/ProblemList.txt ! test/jdk/ProblemList.txt Changeset: 84cd3e0d Author: Alan Bateman Date: 2021-11-02 06:16:29 +0000 URL: https://git.openjdk.java.net/loom/commit/84cd3e0de318465ec3b2e7c292d1158240dbb16a Merge From duke at openjdk.java.net Tue Nov 2 06:22:04 2021 From: duke at openjdk.java.net (duke) Date: Tue, 2 Nov 2021 06:22:04 GMT Subject: git: openjdk/loom: master: 17 new changesets Message-ID: <4d74fb32-38ca-4e07-8f9d-f983163149cd@openjdk.java.net> Changeset: d9b0138d Author: Thomas Stuefe Date: 2021-10-28 05:29:58 +0000 URL: https://git.openjdk.java.net/loom/commit/d9b0138d7d02ceddc5d9c73908177f0b0d2e7c54 8275704: Metaspace::contains() should be threadsafe Reviewed-by: coleenp, dholmes ! src/hotspot/share/memory/metaspace/virtualSpaceList.cpp ! src/hotspot/share/memory/metaspace/virtualSpaceList.hpp Changeset: 1750a6e2 Author: Per Liden Date: 2021-10-28 05:44:32 +0000 URL: https://git.openjdk.java.net/loom/commit/1750a6e2c06960b734f646018fc99b336bd966a5 8276055: ZGC: Defragment address space Reviewed-by: eosterlund, stefank ! src/hotspot/share/gc/z/zMemory.cpp ! src/hotspot/share/gc/z/zMemory.hpp ! src/hotspot/share/gc/z/zPageAllocator.cpp ! src/hotspot/share/gc/z/zPageAllocator.hpp ! src/hotspot/share/gc/z/zPhysicalMemory.cpp ! src/hotspot/share/gc/z/zVirtualMemory.cpp ! src/hotspot/share/gc/z/zVirtualMemory.hpp ! src/hotspot/share/gc/z/zVirtualMemory.inline.hpp Changeset: a2f2d8fc Author: Aleksey Shipilev Date: 2021-10-28 08:27:44 +0000 URL: https://git.openjdk.java.net/loom/commit/a2f2d8fcf511de2754a76a5d9f9acdfef462919b 8276057: Update JMH devkit to 1.33 Reviewed-by: aph, redestad, erikj ! make/devkit/createJMHBundle.sh Changeset: 593401fe Author: Andrey Turbanov Committer: Aleksei Efimov Date: 2021-10-28 08:42:10 +0000 URL: https://git.openjdk.java.net/loom/commit/593401fe8b38bbb8d331a862818fe077af157fcb 8276042: Remove unused local variables in java.naming Reviewed-by: aefimov, dfuchs, vtewari ! src/java.naming/share/classes/com/sun/jndi/ldap/Filter.java ! src/java.naming/share/classes/com/sun/jndi/ldap/LdapCtx.java ! src/java.naming/share/classes/com/sun/jndi/ldap/sasl/SaslOutputStream.java ! src/java.naming/share/classes/com/sun/jndi/toolkit/ctx/Continuation.java ! src/java.naming/share/classes/com/sun/jndi/toolkit/ctx/PartialCompositeContext.java Changeset: d88b89f8 Author: Per Liden Date: 2021-10-28 10:10:05 +0000 URL: https://git.openjdk.java.net/loom/commit/d88b89f89643dd97092b1debf98e871f873e8f9c 8276067: ZGC: Remove unused function alloc_high_address_at_most() Reviewed-by: eosterlund, stefank ! src/hotspot/share/gc/z/zMemory.cpp ! src/hotspot/share/gc/z/zMemory.hpp Changeset: 7c996d57 Author: Hannes Walln?fer Date: 2021-10-28 10:41:49 +0000 URL: https://git.openjdk.java.net/loom/commit/7c996d572cc10045b7f6bc301916dcbd349b6ef4 8269401: Merge "Exceptions" and "Errors" into "Exception Classes" Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllClassesIndexWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Contents.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HelpWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlIds.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SummaryListWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_ja.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_zh_CN.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/SummaryAPIListBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/TypeElementCatalog.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java ! test/langtools/jdk/javadoc/doclet/testDeprecatedDocs/TestDeprecatedDocs.java ! test/langtools/jdk/javadoc/doclet/testHtmlTableTags/TestHtmlTableTags.java ! test/langtools/jdk/javadoc/doclet/testModules/TestModules.java ! test/langtools/jdk/javadoc/doclet/testNewApiList/TestNewApiList.java ! test/langtools/jdk/javadoc/doclet/testSearch/TestSearch.java ! test/langtools/jdk/javadoc/doclet/testSystemPropertyTaglet/TestSystemPropertyTaglet.java ! test/langtools/jdk/javadoc/tool/CheckResourceKeys.java Changeset: bec977c7 Author: Coleen Phillimore Date: 2021-10-28 11:57:21 +0000 URL: https://git.openjdk.java.net/loom/commit/bec977c778a35ea48a45db662f1feaeab79308b2 8275917: Some locks shouldn't allow_vm_block Reviewed-by: dholmes, pchilanomate ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/runtime/mutexLocker.cpp Changeset: a343fa87 Author: Volker Simonis Date: 2021-10-28 12:40:30 +0000 URL: https://git.openjdk.java.net/loom/commit/a343fa8766bb12188881319f06b1d93161cf1619 8275865: Print deoptimization statistics in product builds Reviewed-by: thartmann, kvn ! src/hotspot/share/runtime/java.cpp + test/hotspot/jtreg/runtime/logging/DeoptStats.java Changeset: 85d8cd85 Author: Thomas Schatzl Date: 2021-10-28 12:58:03 +0000 URL: https://git.openjdk.java.net/loom/commit/85d8cd85665d92d67bbc88399baaa8fe7eba14a6 8276100: Remove G1SegmentedArray constructor name parameter Reviewed-by: ayang ! src/hotspot/share/gc/g1/g1CardSetMemory.cpp ! src/hotspot/share/gc/g1/g1SegmentedArray.hpp ! src/hotspot/share/gc/g1/g1SegmentedArray.inline.hpp Changeset: abe52aea Author: Ludvig Janiuk Committer: Jonathan Gibbons Date: 2021-10-28 14:40:53 +0000 URL: https://git.openjdk.java.net/loom/commit/abe52aea23d6025737666dfc2b265fdf1aae14bb 8275518: accessibility issue in Inet6Address docs Reviewed-by: ihse, jjg ! src/java.base/share/classes/java/net/Inet6Address.java Changeset: 309acbf0 Author: Mandy Chung Date: 2021-10-28 15:27:26 +0000 URL: https://git.openjdk.java.net/loom/commit/309acbf0e86a0d248294503fccc7a936fa0a846e 8275703: System.loadLibrary fails on Big Sur for libraries hidden from filesystem Reviewed-by: dholmes, alanb, mcimadamore ! make/test/JtregNativeJdk.gmk ! src/hotspot/share/include/jvm.h ! src/hotspot/share/prims/jvm.cpp ! src/java.base/macosx/classes/jdk/internal/loader/ClassLoaderHelper.java ! src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java ! src/java.base/share/native/libjava/NativeLibraries.c ! src/java.base/unix/classes/jdk/internal/loader/ClassLoaderHelper.java ! src/java.base/windows/classes/jdk/internal/loader/ClassLoaderHelper.java + test/jdk/java/lang/RuntimeTests/loadLibrary/exeLibraryCache/LibraryFromCache.java + test/jdk/java/lang/RuntimeTests/loadLibrary/exeLibraryCache/exeLibraryCache.c Changeset: c92f2305 Author: Prasanta Sadhukhan Date: 2021-10-28 15:37:15 +0000 URL: https://git.openjdk.java.net/loom/commit/c92f23055724d2df462f64fc51e57f5a13f679bb 8276110: Problemlist javax/swing/JMenu/4515762/bug4515762.java for macos12 Reviewed-by: azvegint ! test/jdk/ProblemList.txt Changeset: cb989cf3 Author: Andrew Haley Date: 2021-10-28 15:51:29 +0000 URL: https://git.openjdk.java.net/loom/commit/cb989cf3a182ee07fe127b4536e7ff4213f31eaf 8275052: AArch64: Severe AES/GCM slowdown on MacOS for short blocks Reviewed-by: ngasson, adinn ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp ! src/hotspot/os_cpu/bsd_aarch64/vm_version_bsd_aarch64.cpp Changeset: 63b9f8c0 Author: Mitsuru Kariya Committer: Lance Andersen Date: 2021-10-28 15:56:17 +0000 URL: https://git.openjdk.java.net/loom/commit/63b9f8c0da2ed3634002f0f67b18555826aeddc4 8153490: Cannot setBytes() if incoming buffer's length is bigger than number of elements we want to insert. Reviewed-by: lancea ! src/java.sql.rowset/share/classes/javax/sql/rowset/serial/SerialBlob.java ! src/java.sql.rowset/share/classes/javax/sql/rowset/serial/SerialClob.java ! test/jdk/javax/sql/testng/test/rowset/serial/SerialBlobTests.java ! test/jdk/javax/sql/testng/test/rowset/serial/SerialClobTests.java Changeset: 6d8fa8f6 Author: Aleksey Shipilev Date: 2021-10-28 17:13:08 +0000 URL: https://git.openjdk.java.net/loom/commit/6d8fa8f6632a78dc79786cb102ba20f6834ad3f4 8255286: Implement ParametersTypeData::print_data_on fully Reviewed-by: dholmes ! src/hotspot/share/oops/methodData.cpp Changeset: 5a768f75 Author: Aleksey Shipilev Date: 2021-10-28 17:32:39 +0000 URL: https://git.openjdk.java.net/loom/commit/5a768f75c9cb013edbf6c61e79820bd180cad4ba 8276054: JMH benchmarks for Fences Reviewed-by: redestad + test/micro/org/openjdk/bench/vm/fences/Multiple.java + test/micro/org/openjdk/bench/vm/fences/MultipleWithLoads.java + test/micro/org/openjdk/bench/vm/fences/MultipleWithStores.java + test/micro/org/openjdk/bench/vm/fences/SafePublishing.java + test/micro/org/openjdk/bench/vm/fences/Single.java Changeset: c6339cb8 Author: Mandy Chung Date: 2021-10-28 18:32:50 +0000 URL: https://git.openjdk.java.net/loom/commit/c6339cb8a255d387bb182ad20dd69f3d460cf1ed 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle 8013527: calling MethodHandles.lookup on itself leads to errors Co-authored-by: Peter Levart Co-authored-by: Claes Redestad Co-authored-by: Mandy Chung Reviewed-by: mcimadamore, plevart, egahlin, redestad, cjplummer, alanb ! make/jdk/src/classes/build/tools/classlist/HelloClasslist.java ! src/hotspot/share/ci/ciField.cpp ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/java/lang/ClassLoader.java ! src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/reflect/Constructor.java ! src/java.base/share/classes/java/lang/reflect/Field.java ! src/java.base/share/classes/java/lang/reflect/Method.java ! src/java.base/share/classes/jdk/internal/access/JavaLangInvokeAccess.java ! src/java.base/share/classes/jdk/internal/access/SharedSecrets.java ! src/java.base/share/classes/jdk/internal/misc/VM.java + src/java.base/share/classes/jdk/internal/reflect/AccessorUtils.java + src/java.base/share/classes/jdk/internal/reflect/CallerSensitiveAdapter.java + src/java.base/share/classes/jdk/internal/reflect/CsMethodAccessorAdapter.java ! src/java.base/share/classes/jdk/internal/reflect/DelegatingConstructorAccessorImpl.java ! src/java.base/share/classes/jdk/internal/reflect/DelegatingMethodAccessorImpl.java + src/java.base/share/classes/jdk/internal/reflect/DirectConstructorHandleAccessor.java + src/java.base/share/classes/jdk/internal/reflect/DirectMethodHandleAccessor.java ! src/java.base/share/classes/jdk/internal/reflect/FieldAccessorImpl.java ! src/java.base/share/classes/jdk/internal/reflect/MethodAccessor.java ! src/java.base/share/classes/jdk/internal/reflect/MethodAccessorGenerator.java ! src/java.base/share/classes/jdk/internal/reflect/MethodAccessorImpl.java + src/java.base/share/classes/jdk/internal/reflect/MethodHandleAccessorFactory.java + src/java.base/share/classes/jdk/internal/reflect/MethodHandleBooleanFieldAccessorImpl.java + src/java.base/share/classes/jdk/internal/reflect/MethodHandleByteFieldAccessorImpl.java + src/java.base/share/classes/jdk/internal/reflect/MethodHandleCharacterFieldAccessorImpl.java + src/java.base/share/classes/jdk/internal/reflect/MethodHandleDoubleFieldAccessorImpl.java + src/java.base/share/classes/jdk/internal/reflect/MethodHandleFieldAccessorImpl.java + src/java.base/share/classes/jdk/internal/reflect/MethodHandleFloatFieldAccessorImpl.java + src/java.base/share/classes/jdk/internal/reflect/MethodHandleIntegerFieldAccessorImpl.java + src/java.base/share/classes/jdk/internal/reflect/MethodHandleLongFieldAccessorImpl.java + src/java.base/share/classes/jdk/internal/reflect/MethodHandleObjectFieldAccessorImpl.java + src/java.base/share/classes/jdk/internal/reflect/MethodHandleShortFieldAccessorImpl.java ! src/java.base/share/classes/jdk/internal/reflect/NativeConstructorAccessorImpl.java ! src/java.base/share/classes/jdk/internal/reflect/NativeMethodAccessorImpl.java ! src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java ! src/java.base/share/classes/jdk/internal/reflect/UnsafeFieldAccessorImpl.java ! src/java.base/share/classes/jdk/internal/reflect/UnsafeStaticFieldAccessorImpl.java ! src/java.base/share/native/libjava/NativeAccessors.c ! src/java.logging/share/classes/java/util/logging/Logger.java ! src/java.sql/share/classes/java/sql/DriverManager.java ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/serviceability/dcmd/vm/ShowReflectionTargetTest.java ! test/jdk/com/sun/jdi/EATests.java ! test/jdk/java/lang/StackWalker/DumpStackTest.java ! test/jdk/java/lang/StackWalker/NativeMethod.java ! test/jdk/java/lang/StackWalker/VerifyStackTrace.java + test/jdk/java/lang/StackWalker/libnativeMethod.c + test/jdk/java/lang/invoke/CallerSensitiveMethodHandle.java + test/jdk/java/lang/invoke/MethodHandleInvokeUOE.java = test/jdk/java/lang/invoke/callerSensitive/CallerSensitiveAccess.java + test/jdk/java/lang/invoke/callerSensitive/Main.java + test/jdk/java/lang/invoke/callerSensitive/csm/jdk/test/MethodInvokeTest.java + test/jdk/java/lang/invoke/callerSensitive/csm/module-info.java + test/jdk/java/lang/invoke/callerSensitive/src/java.base/java/util/CSM.java + test/jdk/java/lang/invoke/lookup/ChainedLookupTest.java ! test/jdk/java/lang/invoke/lookup/ReflectiveLookupTest.java ! test/jdk/java/lang/invoke/lookup/java.base/java/lang/LookupTest.java + test/jdk/java/lang/reflect/ChainedReflection.java ! test/jdk/java/lang/reflect/Field/TestFieldReflectValueOf.java + test/jdk/java/lang/reflect/Method/MethodArityLimit.java + test/jdk/java/lang/reflect/MethodHandleAccessorsTest.java + test/jdk/java/lang/reflect/callerCache/CustomLoaderTest.java + test/jdk/java/lang/reflect/callerCache/ReflectTest.java + test/jdk/java/lang/reflect/classInitialization/ExceptionInClassInitialization.java + test/jdk/java/lang/reflect/classInitialization/Initializer.java + test/jdk/java/lang/reflect/classInitialization/Test.java ! test/jdk/jdk/internal/reflect/CallerSensitive/CheckCSMs.java ! test/jdk/jdk/internal/reflect/Reflection/GetCallerClass.java ! test/jdk/jdk/internal/reflect/Reflection/GetCallerClassTest.java ! test/jdk/jdk/jfr/api/consumer/TestHiddenMethod.java ! test/langtools/jdk/jshell/ExceptionsTest.java ! test/micro/org/openjdk/bench/java/lang/reflect/ReflectionColdstartBenchmark.java ! test/micro/org/openjdk/bench/java/lang/reflect/ReflectionSpeedBenchmark.java From duke at openjdk.java.net Tue Nov 2 17:45:59 2021 From: duke at openjdk.java.net (duke) Date: Tue, 2 Nov 2021 17:45:59 GMT Subject: git: openjdk/loom: fibers: 3 new changesets Message-ID: <78899d57-374e-45c3-8848-d28f7c12e3a9@openjdk.java.net> Changeset: 6e36b7b7 Author: lmesnik Date: 2021-11-02 10:09:46 +0000 URL: https://git.openjdk.java.net/loom/commit/6e36b7b7063a63eed2807d53d0940bf9c76df0c2 Added logging to gc.metaspace.TestPerfCountersAndMemoryPools ! test/hotspot/jtreg/gc/metaspace/TestPerfCountersAndMemoryPools.java Changeset: 1c98e694 Author: lmesnik Date: 2021-11-02 10:09:54 +0000 URL: https://git.openjdk.java.net/loom/commit/1c98e69425b517b391d30271f7fe9d61ff7485d0 Merge branch 'fibers' of https://github.com/openjdk/loom into fibers Changeset: b086daae Author: lmesnik Date: 2021-11-02 10:45:04 +0000 URL: https://git.openjdk.java.net/loom/commit/b086daae66c4d0a2769ea525c8b3ed35b6824ba2 Added @build ClassFileInstaller InMemoryJavaCompiler as workaround to serviceability/jvmti/RedefineClasses/* tests ! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/ClassVersionAfterRedefine.java ! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineAddLambdaExpression.java ! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineDoubleDelete.java ! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineFinalizer.java ! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineInterfaceCall.java ! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineInterfaceMethods.java ! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRunningMethodsWithBacktrace.java ! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRunningMethodsWithResolutionErrors.java ! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineSubtractLambdaExpression.java ! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/TestAddDeleteMethods.java ! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/TestMultipleClasses.java ! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/TestRedefineCondy.java From duke at openjdk.java.net Tue Nov 2 20:10:17 2021 From: duke at openjdk.java.net (duke) Date: Tue, 2 Nov 2021 20:10:17 GMT Subject: git: openjdk/loom: fibers: 2 new changesets Message-ID: Changeset: a065ea41 Author: Chris Plummer Date: 2021-11-02 20:07:24 +0000 URL: https://git.openjdk.java.net/loom/commit/a065ea41f7d96cfbeccaaf4631f7b39a8cf4d2df Problem list a couple of SA tests failing with ZGC ! test/hotspot/jtreg/ProblemList-zgc.txt Changeset: 7b7e39b4 Author: Chris Plummer Date: 2021-11-02 20:08:07 +0000 URL: https://git.openjdk.java.net/loom/commit/7b7e39b4f6befe5626361a93275faf730ecee367 Merge branch 'fibers' of https://github.com/openjdk/loom into fibers From duke at openjdk.java.net Wed Nov 3 08:30:19 2021 From: duke at openjdk.java.net (duke) Date: Wed, 3 Nov 2021 08:30:19 GMT Subject: git: openjdk/loom: fibers: Fix chunk bitmap verification Message-ID: <92e53a13-bf62-487f-ae95-d09577b3b1ea@openjdk.java.net> Changeset: 661035a0 Author: Ron Pressler Date: 2021-11-02 22:52:46 +0000 URL: https://git.openjdk.java.net/loom/commit/661035a095a5ede7bb047ee3432db9e3d8bca51f Fix chunk bitmap verification ! src/hotspot/share/oops/instanceStackChunkKlass.cpp From duke at openjdk.java.net Wed Nov 3 12:54:14 2021 From: duke at openjdk.java.net (duke) Date: Wed, 3 Nov 2021 12:54:14 GMT Subject: git: openjdk/loom: fibers: Handle cases in bounded oop iteration where the bounds fall outside the chunk Message-ID: Changeset: 5f85dd66 Author: Ron Pressler Date: 2021-11-03 12:53:12 +0000 URL: https://git.openjdk.java.net/loom/commit/5f85dd66259cc6508460a0f62fc091fba830226e Handle cases in bounded oop iteration where the bounds fall outside the chunk ! src/hotspot/share/oops/instanceStackChunkKlass.inline.hpp From duke at openjdk.java.net Wed Nov 3 12:58:42 2021 From: duke at openjdk.java.net (duke) Date: Wed, 3 Nov 2021 12:58:42 GMT Subject: git: openjdk/loom: fibers: 4 new changesets Message-ID: <96b85b3f-64ee-44b4-8963-6486f903c11e@openjdk.java.net> Changeset: fb419f3b Author: Alan Bateman Date: 2021-11-01 09:20:54 +0000 URL: https://git.openjdk.java.net/loom/commit/fb419f3be7c7b15278f7e1c19d813fd6c6489d1c Improve javadoc ! src/java.base/share/classes/java/lang/Thread.java ! src/java.base/share/classes/java/lang/ThreadGroup.java Changeset: 7d7c90e7 Author: Alan Bateman Date: 2021-11-02 06:59:14 +0000 URL: https://git.openjdk.java.net/loom/commit/7d7c90e784518ff489c8185423082399ce874341 Left over excludelist - test/hotspot/jtreg/ProblemList-graal.txt Changeset: 13fb58a7 Author: Alan Bateman Date: 2021-11-03 07:03:42 +0000 URL: https://git.openjdk.java.net/loom/commit/13fb58a72f4ce4a85f15c66461a2b141fc8f514e appcds tests fail with wrapper ! test/hotspot/jtreg/ProblemList-vthread.txt ! test/jdk/ProblemList.txt Changeset: cf0b1bf8 Author: Alan Bateman Date: 2021-11-03 09:08:02 +0000 URL: https://git.openjdk.java.net/loom/commit/cf0b1bf8769ab6c088f6cc965ce3d8cb2aa44c2c More cleanup/refactoring ! src/java.base/share/classes/java/lang/Thread.java ! src/java.base/share/classes/java/lang/VirtualThread.java ! src/java.base/share/classes/jdk/internal/vm/SharedThreadContainer.java ! src/java.base/share/classes/jdk/internal/vm/StackableScope.java ! src/java.base/share/classes/jdk/internal/vm/ThreadContainer.java ! src/java.base/share/classes/jdk/internal/vm/ThreadContainers.java From duke at openjdk.java.net Wed Nov 3 15:38:48 2021 From: duke at openjdk.java.net (duke) Date: Wed, 3 Nov 2021 15:38:48 GMT Subject: git: openjdk/loom: fibers: Exclude the fuzzer from the wrapper tests Message-ID: <07753007-10b4-4763-9d5d-88ea68363a66@openjdk.java.net> Changeset: 774342ca Author: Ron Pressler Date: 2021-11-03 15:37:20 +0000 URL: https://git.openjdk.java.net/loom/commit/774342cae79e8c2bbd24d722400ae68a918c022f Exclude the fuzzer from the wrapper tests ! test/jdk/ProblemList-vthread.txt From duke at openjdk.java.net Wed Nov 3 21:40:48 2021 From: duke at openjdk.java.net (duke) Date: Wed, 3 Nov 2021 21:40:48 GMT Subject: git: openjdk/loom: fibers: corrected JVMTI GetThreadState for unattached carrier threads Message-ID: <59b0ea90-595d-473f-9245-5bb90b3fd598@openjdk.java.net> Changeset: 698cfaba Author: Serguei Spitsyn Date: 2021-11-03 21:39:48 +0000 URL: https://git.openjdk.java.net/loom/commit/698cfaba6b3f63b493149c6583ce22e753c5b829 corrected JVMTI GetThreadState for unattached carrier threads ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! test/hotspot/jtreg/serviceability/jvmti/thread/GetThreadState/thrstat02/libthrstat02.cpp ! test/lib/jdk/test/lib/jvmti/jvmti_common.h From duke at openjdk.java.net Wed Nov 3 21:47:11 2021 From: duke at openjdk.java.net (duke) Date: Wed, 3 Nov 2021 21:47:11 GMT Subject: git: openjdk/loom: fibers: fix bug in JVMTI extension function GetVirtualThread Message-ID: <5139eabb-ab2b-4f88-ae2e-e2aac1919cc1@openjdk.java.net> Changeset: c7bc1dbf Author: Serguei Spitsyn Date: 2021-11-03 21:46:05 +0000 URL: https://git.openjdk.java.net/loom/commit/c7bc1dbfe13ea6f9dc4c5fa2ce7898a49b254e8d fix bug in JVMTI extension function GetVirtualThread ! src/hotspot/share/prims/jvmtiExtensions.cpp From duke at openjdk.java.net Thu Nov 4 03:51:52 2021 From: duke at openjdk.java.net (duke) Date: Thu, 4 Nov 2021 03:51:52 GMT Subject: git: openjdk/loom: fibers: serviceability/jvmti/thread/GetAllThreads/allthr01/allthr01.java fixed Message-ID: Changeset: e17e35f5 Author: lmesnik Date: 2021-11-03 21:51:35 +0000 URL: https://git.openjdk.java.net/loom/commit/e17e35f5646a03bf4bf15d4f2d08f717f73c75f4 serviceability/jvmti/thread/GetAllThreads/allthr01/allthr01.java fixed ! test/hotspot/jtreg/serviceability/jvmti/thread/GetAllThreads/allthr01/allthr01.java ! test/hotspot/jtreg/serviceability/jvmti/thread/GetAllThreads/allthr01/liballthr01.cpp From duke at openjdk.java.net Thu Nov 4 03:54:18 2021 From: duke at openjdk.java.net (duke) Date: Thu, 4 Nov 2021 03:54:18 GMT Subject: git: openjdk/loom: fibers: vthread/RedefineClasses/RedefineRunningMethods.java fixed to pre-build jdk.test.lib.helpers.ClassFileInstaller jdk.test.lib.compiler.InMemoryJavaCompiler Message-ID: Changeset: 6f654144 Author: lmesnik Date: 2021-11-03 21:52:07 +0000 URL: https://git.openjdk.java.net/loom/commit/6f6541448dca1f5d228b2975023979bfa80f26fe vthread/RedefineClasses/RedefineRunningMethods.java fixed to pre-build jdk.test.lib.helpers.ClassFileInstaller jdk.test.lib.compiler.InMemoryJavaCompiler ! test/hotspot/jtreg/serviceability/jvmti/vthread/RedefineClasses/RedefineRunningMethods.java From duke at openjdk.java.net Thu Nov 4 05:09:28 2021 From: duke at openjdk.java.net (duke) Date: Thu, 4 Nov 2021 05:09:28 GMT Subject: git: openjdk/loom: fibers: Make VirtualThread-unparke unexpected thread. Message-ID: <7b754ebd-0d12-4848-9b11-112c2c12b43c@openjdk.java.net> Changeset: 09e54604 Author: lmesnik Date: 2021-11-03 23:09:07 +0000 URL: https://git.openjdk.java.net/loom/commit/09e546044fb62c9ce237b6ceea13dff461472c13 Make VirtualThread-unparke unexpected thread. ! test/hotspot/jtreg/serviceability/jvmti/thread/GetAllThreads/allthr01/liballthr01.cpp ! test/lib/jdk/test/lib/jvmti/jvmti_common.h From duke at openjdk.java.net Thu Nov 4 09:19:26 2021 From: duke at openjdk.java.net (Miao Zheng) Date: Thu, 4 Nov 2021 09:19:26 GMT Subject: RFR: Ensure compensate when ForkJoinWorkerThread is pinned In-Reply-To: References: Message-ID: On Fri, 29 Oct 2021 08:16:15 GMT, Miao Zheng wrote: > Hello, > We have a test case about Loom, it can pass before; > The test case can be seen on this PR; > > But it cannot pass after this patch: > > commit de90a43c7a5f0b28bd0af9271de210475808ca0c > Author: Alan Bateman > Date: Wed Sep 1 09:22:23 2021 +0100 > > Replace lock/condition objects to simplify pinned park > > > Actually, this modify cause the test fail, because getCondition.await() will call tryCompensate() of ForkJoinPool eventually: > > + private void parkOnCarrierThread(long nanos) { > > - if (!parkPermit) { > - // wait to be signalled or interrupted > - getCondition().await(); > > + if (!parkPermit) { > + U.park(false, nanos); > } > ``` > If ForkJoinWorkerThread are all pinned, how to make vt work correct? > > Thanks? > > Miao @pron thank you for your answer, I got it. ------------- PR: https://git.openjdk.java.net/loom/pull/80 From duke at openjdk.java.net Thu Nov 4 09:19:26 2021 From: duke at openjdk.java.net (Miao Zheng) Date: Thu, 4 Nov 2021 09:19:26 GMT Subject: Withdrawn: Ensure compensate when ForkJoinWorkerThread is pinned In-Reply-To: References: Message-ID: On Fri, 29 Oct 2021 08:16:15 GMT, Miao Zheng wrote: > Hello, > We have a test case about Loom, it can pass before; > The test case can be seen on this PR; > > But it cannot pass after this patch: > > commit de90a43c7a5f0b28bd0af9271de210475808ca0c > Author: Alan Bateman > Date: Wed Sep 1 09:22:23 2021 +0100 > > Replace lock/condition objects to simplify pinned park > > > Actually, this modify cause the test fail, because getCondition.await() will call tryCompensate() of ForkJoinPool eventually: > > + private void parkOnCarrierThread(long nanos) { > > - if (!parkPermit) { > - // wait to be signalled or interrupted > - getCondition().await(); > > + if (!parkPermit) { > + U.park(false, nanos); > } > ``` > If ForkJoinWorkerThread are all pinned, how to make vt work correct? > > Thanks? > > Miao This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/loom/pull/80 From duke at openjdk.java.net Thu Nov 4 11:18:06 2021 From: duke at openjdk.java.net (duke) Date: Thu, 4 Nov 2021 11:18:06 GMT Subject: git: openjdk/loom: fibers: 53 new changesets Message-ID: <90edc546-0dda-4f36-9c84-4095ec75a11a@openjdk.java.net> Changeset: 48f3fcab Author: Joe Darcy Date: 2021-10-28 22:11:03 +0000 URL: https://git.openjdk.java.net/loom/commit/48f3fcab518ccea4dbbc856132f82407f7974028 8275308: Add valueOf(Runtime.Version) factory to SourceVersion Reviewed-by: jjg ! src/java.compiler/share/classes/javax/lang/model/SourceVersion.java ! test/langtools/tools/javac/processing/model/TestSourceVersion.java Changeset: 21da2183 Author: Mandy Chung Date: 2021-10-28 22:24:56 +0000 URL: https://git.openjdk.java.net/loom/commit/21da2183875feca3dbf4f1bd875b268a7fc8d560 8274848: LambdaMetaFactory::metafactory on REF_invokeSpecial impl method has incorrect behavior Reviewed-by: psandoz, dlsmith ! src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java + test/jdk/java/lang/invoke/lambda/invokeSpecial/InvokeSpecialMethodTest.java Changeset: de93b1d0 Author: Hai-May Chao Date: 2021-10-28 23:04:34 +0000 URL: https://git.openjdk.java.net/loom/commit/de93b1d0e83a9428dae4a9609996fe7b7e9b4932 8257722: Improve "keytool -printcert -jarfile" output Reviewed-by: weijun ! src/java.base/share/classes/sun/security/tools/keytool/Main.java ! src/java.base/share/classes/sun/security/tools/keytool/Resources.java ! test/jdk/sun/security/tools/jarsigner/TimestampCheck.java ! test/jdk/sun/security/tools/keytool/ReadJar.java Changeset: c9e65f8e Author: Thomas Stuefe Date: 2021-10-29 03:48:45 +0000 URL: https://git.openjdk.java.net/loom/commit/c9e65f8ef926c3796867558afa536770eed71cd6 8275440: Remove VirtualSpaceList::is_full() Reviewed-by: coleenp ! src/hotspot/share/memory/metaspace/virtualSpaceList.cpp ! src/hotspot/share/memory/metaspace/virtualSpaceList.hpp ! test/hotspot/gtest/metaspace/test_chunkManager_stress.cpp Changeset: 157e1d50 Author: Thomas Stuefe Date: 2021-10-29 04:26:56 +0000 URL: https://git.openjdk.java.net/loom/commit/157e1d5073e221dab084422389f68eea53974f4c 8275856: Remove MetaspaceHandleDeallocations debug switch Reviewed-by: coleenp, iklam ! src/hotspot/share/memory/metaspace/metaspaceArena.cpp ! src/hotspot/share/memory/metaspace/metaspaceSettings.cpp ! src/hotspot/share/memory/metaspace/metaspaceSettings.hpp ! src/hotspot/share/runtime/globals.hpp ! test/hotspot/gtest/metaspace/test_metaspacearena.cpp Changeset: e922023e Author: Tobias Holenstein Committer: Aleksey Shipilev Date: 2021-10-29 06:16:38 +0000 URL: https://git.openjdk.java.net/loom/commit/e922023ec9a74e694a8180e678be19bc2720c346 8275909: [JVMCI] c2v_readFieldValue use long instead of jlong for the offset parameter Reviewed-by: chagedorn, dnsimon, shade ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp Changeset: 24cf4800 Author: Albert Mingkun Yang Date: 2021-10-29 09:06:36 +0000 URL: https://git.openjdk.java.net/loom/commit/24cf48000ac154eac67b617e2a63557f21032907 8276047: G1: refactor G1CardSetArrayLocker Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/g1/g1CardSetContainers.hpp ! src/hotspot/share/gc/g1/g1CardSetContainers.inline.hpp Changeset: e89b2c04 Author: Thomas Stuefe Date: 2021-10-29 09:44:48 +0000 URL: https://git.openjdk.java.net/loom/commit/e89b2c040c68aebf6a099602bc0e04f963e89c84 8276086: Increase size of metaspace mappings Reviewed-by: goetz, mdoerr ! src/hotspot/share/memory/metaspace/metaspaceSettings.hpp ! test/hotspot/gtest/metaspace/test_metaspace_misc.cpp Changeset: 15fd8a30 Author: Aleksey Shipilev Date: 2021-10-29 10:26:06 +0000 URL: https://git.openjdk.java.net/loom/commit/15fd8a300b503fada7611004b5cb1bda6ecc292e 8276102: JDK-8245095 integration reverted JDK-8247980 Reviewed-by: dfuchs, redestad ! test/jdk/TEST.ROOT Changeset: c0cda1db Author: Ilarion Nakonechnyy Committer: Weijun Wang Date: 2021-10-29 11:37:45 +0000 URL: https://git.openjdk.java.net/loom/commit/c0cda1db4fe74b86faa12136336bdf98c96758d2 8273026: Slow LoginContext.login() on multi threading application Reviewed-by: weijun ! src/java.base/share/classes/javax/security/auth/login/LoginContext.java ! test/jdk/javax/security/auth/spi/Loader.java ! test/jdk/javax/security/auth/spi/SecondLoginModule.java Changeset: 4c3491bf Author: Alexander Zuev Date: 2021-10-29 11:44:12 +0000 URL: https://git.openjdk.java.net/loom/commit/4c3491bfa5f296b80c56a37cb4fffd6497323ac2 8017175: [TESTBUG] javax/swing/JPopupMenu/4634626/bug4634626.java sometimes failed on mac Reviewed-by: serb ! test/jdk/ProblemList.txt ! test/jdk/javax/swing/JPopupMenu/4634626/bug4634626.java Changeset: 8cc59509 Author: Sean Mullan Date: 2021-10-29 12:42:33 +0000 URL: https://git.openjdk.java.net/loom/commit/8cc59509fe7c01c9032275798ccd1531eb8f2e9f 8251468: X509Certificate.get{Subject,Issuer}AlternativeNames and getExtendedKeyUsage do not throw CertificateParsingException if extension is unparseable Reviewed-by: weijun ! src/java.base/share/classes/sun/security/x509/CertificateExtensions.java + src/java.base/share/classes/sun/security/x509/UnparseableExtension.java ! src/java.base/share/classes/sun/security/x509/X509CertImpl.java + test/jdk/java/security/cert/X509Certificate/GetUnparseableExtensions.java Changeset: a1ec4f96 Author: Alexander Zvegintsev Date: 2021-10-29 13:05:22 +0000 URL: https://git.openjdk.java.net/loom/commit/a1ec4f961841fe0b580c32b37c77e3906ba66966 6854300: [TEST_BUG] java/awt/event/MouseEvent/SpuriousExitEnter/SpuriousExitEnter_3.java fails in jdk6u14 & jdk7 Reviewed-by: serb ! test/jdk/ProblemList.txt ! test/jdk/java/awt/event/MouseEvent/SpuriousExitEnter/SpuriousExitEnter_3.java Changeset: d6d82f52 Author: Thomas Stuefe Date: 2021-10-29 13:54:27 +0000 URL: https://git.openjdk.java.net/loom/commit/d6d82f52d4a4fac037ee9424503f8b7f11a61c40 8275608: runtime/Metaspace/elastic/TestMetaspaceAllocationMT2 too slow Reviewed-by: mbaesken, shade ! test/hotspot/jtreg/runtime/Metaspace/elastic/MetaspaceTestArena.java ! test/hotspot/jtreg/runtime/Metaspace/elastic/MetaspaceTestManyArenasManyThreads.java ! test/hotspot/jtreg/runtime/Metaspace/elastic/MetaspaceTestWithThreads.java ! test/hotspot/jtreg/runtime/Metaspace/elastic/RandomAllocator.java ! test/hotspot/jtreg/runtime/Metaspace/elastic/RandomAllocatorThread.java Changeset: 5facaa24 Author: Brian Burkhalter Date: 2021-10-29 16:12:19 +0000 URL: https://git.openjdk.java.net/loom/commit/5facaa243aef6ad00cf71a047d0325710ce1f0a8 8276128: (bf) Remove unused constant ARRAY_BASE_OFFSET from Direct-X-Buffer Reviewed-by: lancea, iris, alanb ! src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template Changeset: 13265f99 Author: Brian Burkhalter Date: 2021-10-29 16:13:23 +0000 URL: https://git.openjdk.java.net/loom/commit/13265f9901ab8334bbe1e7a571a9c5f386275dbf 8274750: java/io/File/GetXSpace.java failed: '/dev': 191488 != 190976 Reviewed-by: rriggs, naoto ! test/jdk/java/io/File/GetXSpace.java Changeset: cef9db9a Author: Yumin Qi Date: 2021-10-29 16:15:35 +0000 URL: https://git.openjdk.java.net/loom/commit/cef9db9a69061d51630e40b94ceba4b4bf03a0ce 8276039: Remove unnecessary qualifications of java_lang_Class:: Reviewed-by: mikael, iklam ! src/hotspot/share/classfile/javaClasses.cpp Changeset: fe6a2020 Author: Jakob Cornell Committer: Chris Plummer Date: 2021-10-29 17:50:19 +0000 URL: https://git.openjdk.java.net/loom/commit/fe6a2020873fe1eb8d4236dc1db3008f485f3195 8271356: Modify jdb to treat an empty command as a repeat of the previous command Reviewed-by: cjplummer, iklam ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/Commands.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_zh_CN.java + test/hotspot/jtreg/vmTestbase/nsk/jdb/list/list003/list003.java + test/hotspot/jtreg/vmTestbase/nsk/jdb/list/list003/list003a.java + test/hotspot/jtreg/vmTestbase/nsk/jdb/repeat/repeat001/repeat001.java + test/hotspot/jtreg/vmTestbase/nsk/jdb/repeat/repeat001/repeat001a.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jdb/JdbCommand.java Changeset: 5021a12c Author: Igor Veresov Date: 2021-10-29 18:03:10 +0000 URL: https://git.openjdk.java.net/loom/commit/5021a12ceada3192e81e2c06b556e7c80cd6cf31 8274855: vectorapi tests failing with assert(!vbox->is_Phi()) failed Reviewed-by: kvn ! src/hotspot/share/opto/vector.cpp ! test/hotspot/jtreg/ProblemList-Xcomp.txt Changeset: 5bbc8d3c Author: Alex Menkov Date: 2021-10-29 21:38:24 +0000 URL: https://git.openjdk.java.net/loom/commit/5bbc8d3cb2ce487b367ee1a621d78699c9b30100 8274621: NullPointerException because listenAddress[0] is null Reviewed-by: sspitsyn, lmesnik, cjplummer ! test/lib/jdk/test/lib/process/ProcessTools.java Changeset: 68756782 Author: Sergey Bylokhov Date: 2021-10-30 09:03:27 +0000 URL: https://git.openjdk.java.net/loom/commit/687567822a5380fb7d8c5b54ae548b2a5c848187 8273831: PrintServiceLookup spawns 2 threads in the current classloader, getting orphaned Reviewed-by: aivanov ! src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java ! src/java.desktop/windows/classes/sun/print/PrintServiceLookupProvider.java + test/jdk/javax/print/PrintServiceLookup/FlushCustomClassLoader.java Changeset: b7104ba9 Author: Alexander Zuev Date: 2021-10-30 10:01:05 +0000 URL: https://git.openjdk.java.net/loom/commit/b7104ba9a9006ab65e08ea9d7db22e72611ed07c 8196017: java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails Reviewed-by: serb ! test/jdk/ProblemList.txt ! test/jdk/java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java Changeset: bf2e9ee9 Author: Man Cao Date: 2021-10-31 04:58:16 +0000 URL: https://git.openjdk.java.net/loom/commit/bf2e9ee9d321ed289466b2410f12ad10504d01a2 8275080: G1CollectedHeap::expand() returns the wrong value Co-authored-by: Jonathan Joo Reviewed-by: tschatzl, kbarrett ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp Changeset: 158831e4 Author: Thomas Stuefe Date: 2021-11-01 05:13:55 +0000 URL: https://git.openjdk.java.net/loom/commit/158831e4c3fa637905fda6f28e9adf8e957b9e55 8274320: os::fork_and_exec() should be using posix_spawn Reviewed-by: mdoerr, dholmes ! src/hotspot/os/posix/os_posix.cpp ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/share/runtime/os.hpp ! src/hotspot/share/utilities/vmError.cpp Changeset: 5bb1992b Author: Christian Hagedorn Date: 2021-11-01 08:22:59 +0000 URL: https://git.openjdk.java.net/loom/commit/5bb1992b8408a0d196b1afa308bc00d007458dbd 8275868: ciReplay: Inlining fails with "unloaded signature classes" due to wrong protection domains Reviewed-by: kvn, dlong, thartmann ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciReplay.cpp ! test/hotspot/jtreg/compiler/ciReplay/CiReplayBase.java + test/hotspot/jtreg/compiler/ciReplay/DumpReplayBase.java + test/hotspot/jtreg/compiler/ciReplay/TestInliningProtectionDomain.java Changeset: dbf5100d Author: Zhengyu Gu Date: 2021-11-01 12:17:16 +0000 URL: https://git.openjdk.java.net/loom/commit/dbf5100dd705fbe4a3aeae49405ca541d581f106 8276201: Shenandoah: Race results degenerated GC to enter wrong entry point Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.cpp Changeset: 89ade1d7 Author: Aleksey Shipilev Date: 2021-11-01 12:30:43 +0000 URL: https://git.openjdk.java.net/loom/commit/89ade1d7e88ee005c3fd2136d84e298d94f9a67c 8273416: C2: assert(false) failed: bad AD file after JDK-8252372 with UseSSE={0,1} Reviewed-by: kvn, roland ! src/hotspot/cpu/x86/x86_32.ad ! src/hotspot/share/opto/castnode.hpp Changeset: 4ac8403f Author: Erik Gahlin Date: 2021-11-01 12:33:10 +0000 URL: https://git.openjdk.java.net/loom/commit/4ac8403f9a4cedcb5d56bcd34a6bbfa51d67ca18 8276218: JFR: Clean up jdk.jfr.dcmd Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/AbstractDCmd.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/DCmdStart.java Changeset: f55e68c9 Author: Patricio Chilano Mateo Date: 2021-11-01 15:27:39 +0000 URL: https://git.openjdk.java.net/loom/commit/f55e68c92924bb70471a4851f616d4c3065ffa92 8275950: Use only _thread_in_vm in ~ThreadBlockInVMPreprocess() Reviewed-by: dholmes, dcubed ! src/hotspot/share/runtime/interfaceSupport.inline.hpp ! src/hotspot/share/runtime/safepoint.cpp ! src/hotspot/share/runtime/safepoint.hpp Changeset: c8abe354 Author: Leo Korinth Date: 2021-11-01 15:37:00 +0000 URL: https://git.openjdk.java.net/loom/commit/c8abe354c1ddc988ff54b9a96a4a825e2aa70f4b 8276121: G1: Remove unused and uninitialized _g1h in g1SATBMarkQueueSet.hpp Reviewed-by: ayang, tschatzl ! src/hotspot/share/gc/g1/g1SATBMarkQueueSet.hpp Changeset: e265f838 Author: Thomas Schatzl Date: 2021-11-01 16:48:13 +0000 URL: https://git.openjdk.java.net/loom/commit/e265f83858b84451258677f130f98be5375a417a 8276107: Preventive collections trigger before maxing out heap Reviewed-by: sjohanss, ayang ! src/hotspot/share/gc/g1/g1Policy.cpp Changeset: 97715440 Author: Patrick Concannon Date: 2021-11-01 17:11:20 +0000 URL: https://git.openjdk.java.net/loom/commit/977154400be786c500f36ba14188bff79db57075 8260428: Drop support for pre JDK 1.4 DatagramSocketImpl implementations Reviewed-by: alanb, dfuchs, vtewari ! src/java.base/share/classes/java/net/DatagramSocketImpl.java ! src/java.base/share/classes/java/net/NetMulticastSocket.java + test/jdk/java/net/DatagramSocket/OldDatagramSocketImplTest.java Changeset: 99b7b95e Author: Zhengyu Gu Date: 2021-11-01 19:38:49 +0000 URL: https://git.openjdk.java.net/loom/commit/99b7b95e014da6e491ba7adfd21de53d6ae166fe 8276205: Shenandoah: CodeCache_lock should always be held for initializing code cache iteration Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp Changeset: 47e7a425 Author: Alisen Chung Committer: Alexander Zuev Date: 2021-11-01 22:29:40 +0000 URL: https://git.openjdk.java.net/loom/commit/47e7a42594f1c36f71cdf4d383080bf8d616b7e7 8262945: [macos] Regression Manual Test for Key Events Fails Reviewed-by: prr, kizune ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTEvent.m Changeset: 2eafa036 Author: Pavel Rappo Date: 2021-11-01 22:50:43 +0000 URL: https://git.openjdk.java.net/loom/commit/2eafa036c03d3e8f3dba8f67dd37b484874dc3d3 8276234: Trivially clean up locale-related code Reviewed-by: redestad, naoto, iris ! src/java.base/share/classes/java/time/chrono/JapaneseChronology.java ! src/java.base/share/classes/sun/util/locale/BaseLocale.java ! src/java.base/share/classes/sun/util/resources/LocaleData.java Changeset: acceffcb Author: Phil Race Date: 2021-11-02 02:49:56 +0000 URL: https://git.openjdk.java.net/loom/commit/acceffcbf73aa4416c487f890f3ca65e55e47164 8273704: DrawStringWithInfiniteXform.java failed : drawString with InfiniteXform transform takes long time Reviewed-by: serb, psadhukhan ! test/jdk/java/awt/FontClass/DrawStringWithInfiniteXform.java Changeset: 0488ebdf Author: Aleksey Shipilev Date: 2021-11-02 06:38:26 +0000 URL: https://git.openjdk.java.net/loom/commit/0488ebdf14dacfa79d98de16ed949c813dd88701 8276105: C2: Conv(D|F)2(I|L)Nodes::Ideal should handle rounding correctly Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/convertnode.cpp Changeset: 9bf31652 Author: Masanori Yano Committer: Alan Bateman Date: 2021-11-02 06:44:48 +0000 URL: https://git.openjdk.java.net/loom/commit/9bf31652cbe8eb2699babe5e52e62ea1f1578588 8276164: RandomAccessFile#write method could throw IndexOutOfBoundsException that is not described in javadoc Reviewed-by: alanb ! src/java.base/share/classes/java/io/DataOutput.java ! src/java.base/share/classes/java/io/RandomAccessFile.java Changeset: 92be9d8c Author: Ludvig Janiuk Committer: Sean Coffey Date: 2021-11-02 09:46:37 +0000 URL: https://git.openjdk.java.net/loom/commit/92be9d8c535274eea4edd06273e6d7811f6bb113 8276236: Table headers missing in Formatter api docs Reviewed-by: coffeys, iris ! src/java.base/share/classes/java/util/Formatter.java Changeset: b7a06be9 Author: Aleksey Shipilev Date: 2021-11-02 10:26:21 +0000 URL: https://git.openjdk.java.net/loom/commit/b7a06be98d3057dac4adbb7f4071ac62cf88fe52 8252990: Intrinsify Unsafe.storeStoreFence Reviewed-by: dholmes, thartmann, whuang ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/arm/arm.ad ! src/hotspot/cpu/ppc/ppc.ad ! src/hotspot/cpu/s390/s390.ad ! src/hotspot/cpu/x86/x86_32.ad ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/share/adlc/formssel.cpp ! src/hotspot/share/c1/c1_Compiler.cpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/classes.hpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/opto/memnode.hpp ! src/java.base/share/classes/jdk/internal/misc/Unsafe.java Changeset: 9971a2ca Author: Severin Gehwolf Date: 2021-11-02 10:39:41 +0000 URL: https://git.openjdk.java.net/loom/commit/9971a2cab3892a17f3fd39243df5ecfff5b9f108 8275735: [linux] Remove deprecated Metrics api (kernel memory limit) Reviewed-by: hseigel, mchung ! src/java.base/linux/classes/jdk/internal/platform/CgroupV1Metrics.java ! src/java.base/linux/classes/jdk/internal/platform/CgroupV1MetricsImpl.java ! src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1Subsystem.java ! test/jdk/jdk/internal/platform/docker/MetricsMemoryTester.java ! test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java ! test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV1.java Changeset: 8630f55e Author: Hannes Walln?fer Date: 2021-11-02 12:10:47 +0000 URL: https://git.openjdk.java.net/loom/commit/8630f55ed7a0483ec5dcb13a7f53b52bc4ab6fc6 8275406: Add copy-to-clipboard feature to snippet UI Reviewed-by: erikj, jjg ! make/CompileInterimLangtools.gmk ! make/modules/jdk.javadoc/Java.gmk ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlAttr.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/copy.svg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/script.js ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocPaths.java ! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java ! test/langtools/jdk/javadoc/lib/javadoc/tester/LinkChecker.java ! test/langtools/jdk/javadoc/tool/api/basic/APITest.java Changeset: 5b4e3986 Author: Yoshiki Sato Committer: Sean Coffey Date: 2021-11-02 13:02:51 +0000 URL: https://git.openjdk.java.net/loom/commit/5b4e39863dbc0d61e91675261dd6887f704ab868 8275766: (tz) Update Timezone Data to 2021e 8275849: TestZoneInfo310.java fails with tzdata2021e Reviewed-by: naoto, iris, erikj, coffeys ! make/data/tzdata/VERSION ! make/data/tzdata/asia ! make/data/tzdata/australasia ! make/data/tzdata/europe ! make/data/tzdata/northamerica ! src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java Changeset: b889f2a8 Author: Thomas Stuefe Date: 2021-11-02 13:04:09 +0000 URL: https://git.openjdk.java.net/loom/commit/b889f2a88a5e182d2424b741d8fedf2c784442f1 8276175: codestrings.validate_vm gtest still broken on ppc64 after JDK-8276046 Reviewed-by: mdoerr ! test/hotspot/gtest/code/test_codestrings.cpp Changeset: cd778f5b Author: Alexander Zuev Date: 2021-11-02 13:23:18 +0000 URL: https://git.openjdk.java.net/loom/commit/cd778f5b049d52b68ab5872aad5f81e86e1718f7 8202667: java/awt/Debug/DumpOnKey/DumpOnKey.java times out on Windows Reviewed-by: prr ! test/jdk/ProblemList.txt ! test/jdk/java/awt/Debug/DumpOnKey/DumpOnKey.java Changeset: 495c828a Author: Naoto Sato Date: 2021-11-02 16:08:11 +0000 URL: https://git.openjdk.java.net/loom/commit/495c828ae95205885b091dde795b517ba332a2b1 8276188: Clarify "default charset" descriptions in String class Reviewed-by: iris, joehw ! src/java.base/share/classes/java/lang/String.java Changeset: fa4ce824 Author: Brian Burkhalter Date: 2021-11-02 16:27:56 +0000 URL: https://git.openjdk.java.net/loom/commit/fa4ce824a39264e765b8236ee58b1f28faa371e0 8276260: (se) Remove java/nio/channels/Selector/Wakeup.java from ProblemList (win) Reviewed-by: alanb ! test/jdk/ProblemList.txt Changeset: 8fc16f16 Author: Evgeny Astigeevich Committer: Paul Hohensee Date: 2021-11-02 16:32:04 +0000 URL: https://git.openjdk.java.net/loom/commit/8fc16f1605b396bfb9265a97bc126d435d6d5951 8275729: Qualified method names in CodeHeap Analytics Reviewed-by: yyang, thartmann ! src/hotspot/share/code/codeHeapState.cpp + test/hotspot/jtreg/serviceability/dcmd/compiler/CodeHeapAnalyticsMethodNames.java Changeset: 01105d69 Author: Daniel D. Daugherty Date: 2021-11-02 16:50:47 +0000 URL: https://git.openjdk.java.net/loom/commit/01105d6985b39d4064b9066eab3612da5a401685 8276367: ProblemList vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineWithoutBytecodeCorruption/TestDescription.java Reviewed-by: bpb ! test/hotspot/jtreg/ProblemList.txt Changeset: 6a04899b Author: Markus Karg Committer: Lance Andersen Date: 2021-11-02 18:06:14 +0000 URL: https://git.openjdk.java.net/loom/commit/6a04899ba1a62f52f7e28cc2ed72bdca115e6562 8275840: Add test to java/nio/channels/Channels/TransferTo.java to test transfer sizes > 2GB Reviewed-by: lancea ! test/jdk/java/nio/channels/Channels/TransferTo.java Changeset: bb92fb02 Author: Alex Menkov Date: 2021-11-02 21:57:16 +0000 URL: https://git.openjdk.java.net/loom/commit/bb92fb02ca8c5795989065a9037748dc39ed77db 8274930: sun/tools/jps/TestJps.java can fail with long VM arguments string Reviewed-by: sspitsyn, lmesnik ! test/jdk/sun/tools/jps/JpsHelper.java Changeset: 2b02b6f5 Author: Guoxiong Li Date: 2021-11-03 01:57:52 +0000 URL: https://git.openjdk.java.net/loom/commit/2b02b6f513b062261195ca1edd059d16abb7bec6 8274942: AssertionError at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155) Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java + test/langtools/tools/javac/annotations/typeAnnotations/NestTypeAnnotation.java Changeset: 9bc97650 Author: Alan Bateman Date: 2021-11-04 09:46:19 +0000 URL: https://git.openjdk.java.net/loom/commit/9bc976506369f921f1d54821cd4344f95ababf8f Merge with jdk-18+22 ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/x86/x86_32.ad ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/share/c1/c1_Compiler.cpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/gc/g1/g1CardSetContainers.hpp ! src/hotspot/share/gc/g1/g1CardSetContainers.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/interfaceSupport.inline.hpp ! src/hotspot/share/runtime/safepoint.cpp ! src/hotspot/share/runtime/safepoint.hpp ! src/hotspot/share/utilities/vmError.cpp ! src/java.base/share/classes/java/io/RandomAccessFile.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java ! test/hotspot/jtreg/ProblemList.txt ! test/jdk/ProblemList.txt ! test/lib/jdk/test/lib/process/ProcessTools.java ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/x86/x86_32.ad ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/share/c1/c1_Compiler.cpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/gc/g1/g1CardSetContainers.hpp ! src/hotspot/share/gc/g1/g1CardSetContainers.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/interfaceSupport.inline.hpp ! src/hotspot/share/runtime/safepoint.cpp ! src/hotspot/share/runtime/safepoint.hpp ! src/hotspot/share/utilities/vmError.cpp ! src/java.base/share/classes/java/io/RandomAccessFile.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java ! test/hotspot/jtreg/ProblemList.txt ! test/jdk/ProblemList.txt ! test/lib/jdk/test/lib/process/ProcessTools.java From duke at openjdk.java.net Thu Nov 4 11:21:12 2021 From: duke at openjdk.java.net (duke) Date: Thu, 4 Nov 2021 11:21:12 GMT Subject: git: openjdk/loom: master: 52 new changesets Message-ID: <43fb285b-f263-41dd-a460-321d3083f5f7@openjdk.java.net> Changeset: 48f3fcab Author: Joe Darcy Date: 2021-10-28 22:11:03 +0000 URL: https://git.openjdk.java.net/loom/commit/48f3fcab518ccea4dbbc856132f82407f7974028 8275308: Add valueOf(Runtime.Version) factory to SourceVersion Reviewed-by: jjg ! src/java.compiler/share/classes/javax/lang/model/SourceVersion.java ! test/langtools/tools/javac/processing/model/TestSourceVersion.java Changeset: 21da2183 Author: Mandy Chung Date: 2021-10-28 22:24:56 +0000 URL: https://git.openjdk.java.net/loom/commit/21da2183875feca3dbf4f1bd875b268a7fc8d560 8274848: LambdaMetaFactory::metafactory on REF_invokeSpecial impl method has incorrect behavior Reviewed-by: psandoz, dlsmith ! src/java.base/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java + test/jdk/java/lang/invoke/lambda/invokeSpecial/InvokeSpecialMethodTest.java Changeset: de93b1d0 Author: Hai-May Chao Date: 2021-10-28 23:04:34 +0000 URL: https://git.openjdk.java.net/loom/commit/de93b1d0e83a9428dae4a9609996fe7b7e9b4932 8257722: Improve "keytool -printcert -jarfile" output Reviewed-by: weijun ! src/java.base/share/classes/sun/security/tools/keytool/Main.java ! src/java.base/share/classes/sun/security/tools/keytool/Resources.java ! test/jdk/sun/security/tools/jarsigner/TimestampCheck.java ! test/jdk/sun/security/tools/keytool/ReadJar.java Changeset: c9e65f8e Author: Thomas Stuefe Date: 2021-10-29 03:48:45 +0000 URL: https://git.openjdk.java.net/loom/commit/c9e65f8ef926c3796867558afa536770eed71cd6 8275440: Remove VirtualSpaceList::is_full() Reviewed-by: coleenp ! src/hotspot/share/memory/metaspace/virtualSpaceList.cpp ! src/hotspot/share/memory/metaspace/virtualSpaceList.hpp ! test/hotspot/gtest/metaspace/test_chunkManager_stress.cpp Changeset: 157e1d50 Author: Thomas Stuefe Date: 2021-10-29 04:26:56 +0000 URL: https://git.openjdk.java.net/loom/commit/157e1d5073e221dab084422389f68eea53974f4c 8275856: Remove MetaspaceHandleDeallocations debug switch Reviewed-by: coleenp, iklam ! src/hotspot/share/memory/metaspace/metaspaceArena.cpp ! src/hotspot/share/memory/metaspace/metaspaceSettings.cpp ! src/hotspot/share/memory/metaspace/metaspaceSettings.hpp ! src/hotspot/share/runtime/globals.hpp ! test/hotspot/gtest/metaspace/test_metaspacearena.cpp Changeset: e922023e Author: Tobias Holenstein Committer: Aleksey Shipilev Date: 2021-10-29 06:16:38 +0000 URL: https://git.openjdk.java.net/loom/commit/e922023ec9a74e694a8180e678be19bc2720c346 8275909: [JVMCI] c2v_readFieldValue use long instead of jlong for the offset parameter Reviewed-by: chagedorn, dnsimon, shade ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp Changeset: 24cf4800 Author: Albert Mingkun Yang Date: 2021-10-29 09:06:36 +0000 URL: https://git.openjdk.java.net/loom/commit/24cf48000ac154eac67b617e2a63557f21032907 8276047: G1: refactor G1CardSetArrayLocker Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/g1/g1CardSetContainers.hpp ! src/hotspot/share/gc/g1/g1CardSetContainers.inline.hpp Changeset: e89b2c04 Author: Thomas Stuefe Date: 2021-10-29 09:44:48 +0000 URL: https://git.openjdk.java.net/loom/commit/e89b2c040c68aebf6a099602bc0e04f963e89c84 8276086: Increase size of metaspace mappings Reviewed-by: goetz, mdoerr ! src/hotspot/share/memory/metaspace/metaspaceSettings.hpp ! test/hotspot/gtest/metaspace/test_metaspace_misc.cpp Changeset: 15fd8a30 Author: Aleksey Shipilev Date: 2021-10-29 10:26:06 +0000 URL: https://git.openjdk.java.net/loom/commit/15fd8a300b503fada7611004b5cb1bda6ecc292e 8276102: JDK-8245095 integration reverted JDK-8247980 Reviewed-by: dfuchs, redestad ! test/jdk/TEST.ROOT Changeset: c0cda1db Author: Ilarion Nakonechnyy Committer: Weijun Wang Date: 2021-10-29 11:37:45 +0000 URL: https://git.openjdk.java.net/loom/commit/c0cda1db4fe74b86faa12136336bdf98c96758d2 8273026: Slow LoginContext.login() on multi threading application Reviewed-by: weijun ! src/java.base/share/classes/javax/security/auth/login/LoginContext.java ! test/jdk/javax/security/auth/spi/Loader.java ! test/jdk/javax/security/auth/spi/SecondLoginModule.java Changeset: 4c3491bf Author: Alexander Zuev Date: 2021-10-29 11:44:12 +0000 URL: https://git.openjdk.java.net/loom/commit/4c3491bfa5f296b80c56a37cb4fffd6497323ac2 8017175: [TESTBUG] javax/swing/JPopupMenu/4634626/bug4634626.java sometimes failed on mac Reviewed-by: serb ! test/jdk/ProblemList.txt ! test/jdk/javax/swing/JPopupMenu/4634626/bug4634626.java Changeset: 8cc59509 Author: Sean Mullan Date: 2021-10-29 12:42:33 +0000 URL: https://git.openjdk.java.net/loom/commit/8cc59509fe7c01c9032275798ccd1531eb8f2e9f 8251468: X509Certificate.get{Subject,Issuer}AlternativeNames and getExtendedKeyUsage do not throw CertificateParsingException if extension is unparseable Reviewed-by: weijun ! src/java.base/share/classes/sun/security/x509/CertificateExtensions.java + src/java.base/share/classes/sun/security/x509/UnparseableExtension.java ! src/java.base/share/classes/sun/security/x509/X509CertImpl.java + test/jdk/java/security/cert/X509Certificate/GetUnparseableExtensions.java Changeset: a1ec4f96 Author: Alexander Zvegintsev Date: 2021-10-29 13:05:22 +0000 URL: https://git.openjdk.java.net/loom/commit/a1ec4f961841fe0b580c32b37c77e3906ba66966 6854300: [TEST_BUG] java/awt/event/MouseEvent/SpuriousExitEnter/SpuriousExitEnter_3.java fails in jdk6u14 & jdk7 Reviewed-by: serb ! test/jdk/ProblemList.txt ! test/jdk/java/awt/event/MouseEvent/SpuriousExitEnter/SpuriousExitEnter_3.java Changeset: d6d82f52 Author: Thomas Stuefe Date: 2021-10-29 13:54:27 +0000 URL: https://git.openjdk.java.net/loom/commit/d6d82f52d4a4fac037ee9424503f8b7f11a61c40 8275608: runtime/Metaspace/elastic/TestMetaspaceAllocationMT2 too slow Reviewed-by: mbaesken, shade ! test/hotspot/jtreg/runtime/Metaspace/elastic/MetaspaceTestArena.java ! test/hotspot/jtreg/runtime/Metaspace/elastic/MetaspaceTestManyArenasManyThreads.java ! test/hotspot/jtreg/runtime/Metaspace/elastic/MetaspaceTestWithThreads.java ! test/hotspot/jtreg/runtime/Metaspace/elastic/RandomAllocator.java ! test/hotspot/jtreg/runtime/Metaspace/elastic/RandomAllocatorThread.java Changeset: 5facaa24 Author: Brian Burkhalter Date: 2021-10-29 16:12:19 +0000 URL: https://git.openjdk.java.net/loom/commit/5facaa243aef6ad00cf71a047d0325710ce1f0a8 8276128: (bf) Remove unused constant ARRAY_BASE_OFFSET from Direct-X-Buffer Reviewed-by: lancea, iris, alanb ! src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template Changeset: 13265f99 Author: Brian Burkhalter Date: 2021-10-29 16:13:23 +0000 URL: https://git.openjdk.java.net/loom/commit/13265f9901ab8334bbe1e7a571a9c5f386275dbf 8274750: java/io/File/GetXSpace.java failed: '/dev': 191488 != 190976 Reviewed-by: rriggs, naoto ! test/jdk/java/io/File/GetXSpace.java Changeset: cef9db9a Author: Yumin Qi Date: 2021-10-29 16:15:35 +0000 URL: https://git.openjdk.java.net/loom/commit/cef9db9a69061d51630e40b94ceba4b4bf03a0ce 8276039: Remove unnecessary qualifications of java_lang_Class:: Reviewed-by: mikael, iklam ! src/hotspot/share/classfile/javaClasses.cpp Changeset: fe6a2020 Author: Jakob Cornell Committer: Chris Plummer Date: 2021-10-29 17:50:19 +0000 URL: https://git.openjdk.java.net/loom/commit/fe6a2020873fe1eb8d4236dc1db3008f485f3195 8271356: Modify jdb to treat an empty command as a repeat of the previous command Reviewed-by: cjplummer, iklam ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/Commands.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTY.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_zh_CN.java + test/hotspot/jtreg/vmTestbase/nsk/jdb/list/list003/list003.java + test/hotspot/jtreg/vmTestbase/nsk/jdb/list/list003/list003a.java + test/hotspot/jtreg/vmTestbase/nsk/jdb/repeat/repeat001/repeat001.java + test/hotspot/jtreg/vmTestbase/nsk/jdb/repeat/repeat001/repeat001a.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jdb/JdbCommand.java Changeset: 5021a12c Author: Igor Veresov Date: 2021-10-29 18:03:10 +0000 URL: https://git.openjdk.java.net/loom/commit/5021a12ceada3192e81e2c06b556e7c80cd6cf31 8274855: vectorapi tests failing with assert(!vbox->is_Phi()) failed Reviewed-by: kvn ! src/hotspot/share/opto/vector.cpp ! test/hotspot/jtreg/ProblemList-Xcomp.txt Changeset: 5bbc8d3c Author: Alex Menkov Date: 2021-10-29 21:38:24 +0000 URL: https://git.openjdk.java.net/loom/commit/5bbc8d3cb2ce487b367ee1a621d78699c9b30100 8274621: NullPointerException because listenAddress[0] is null Reviewed-by: sspitsyn, lmesnik, cjplummer ! test/lib/jdk/test/lib/process/ProcessTools.java Changeset: 68756782 Author: Sergey Bylokhov Date: 2021-10-30 09:03:27 +0000 URL: https://git.openjdk.java.net/loom/commit/687567822a5380fb7d8c5b54ae548b2a5c848187 8273831: PrintServiceLookup spawns 2 threads in the current classloader, getting orphaned Reviewed-by: aivanov ! src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java ! src/java.desktop/windows/classes/sun/print/PrintServiceLookupProvider.java + test/jdk/javax/print/PrintServiceLookup/FlushCustomClassLoader.java Changeset: b7104ba9 Author: Alexander Zuev Date: 2021-10-30 10:01:05 +0000 URL: https://git.openjdk.java.net/loom/commit/b7104ba9a9006ab65e08ea9d7db22e72611ed07c 8196017: java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java fails Reviewed-by: serb ! test/jdk/ProblemList.txt ! test/jdk/java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java Changeset: bf2e9ee9 Author: Man Cao Date: 2021-10-31 04:58:16 +0000 URL: https://git.openjdk.java.net/loom/commit/bf2e9ee9d321ed289466b2410f12ad10504d01a2 8275080: G1CollectedHeap::expand() returns the wrong value Co-authored-by: Jonathan Joo Reviewed-by: tschatzl, kbarrett ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp Changeset: 158831e4 Author: Thomas Stuefe Date: 2021-11-01 05:13:55 +0000 URL: https://git.openjdk.java.net/loom/commit/158831e4c3fa637905fda6f28e9adf8e957b9e55 8274320: os::fork_and_exec() should be using posix_spawn Reviewed-by: mdoerr, dholmes ! src/hotspot/os/posix/os_posix.cpp ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/share/runtime/os.hpp ! src/hotspot/share/utilities/vmError.cpp Changeset: 5bb1992b Author: Christian Hagedorn Date: 2021-11-01 08:22:59 +0000 URL: https://git.openjdk.java.net/loom/commit/5bb1992b8408a0d196b1afa308bc00d007458dbd 8275868: ciReplay: Inlining fails with "unloaded signature classes" due to wrong protection domains Reviewed-by: kvn, dlong, thartmann ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciReplay.cpp ! test/hotspot/jtreg/compiler/ciReplay/CiReplayBase.java + test/hotspot/jtreg/compiler/ciReplay/DumpReplayBase.java + test/hotspot/jtreg/compiler/ciReplay/TestInliningProtectionDomain.java Changeset: dbf5100d Author: Zhengyu Gu Date: 2021-11-01 12:17:16 +0000 URL: https://git.openjdk.java.net/loom/commit/dbf5100dd705fbe4a3aeae49405ca541d581f106 8276201: Shenandoah: Race results degenerated GC to enter wrong entry point Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.cpp Changeset: 89ade1d7 Author: Aleksey Shipilev Date: 2021-11-01 12:30:43 +0000 URL: https://git.openjdk.java.net/loom/commit/89ade1d7e88ee005c3fd2136d84e298d94f9a67c 8273416: C2: assert(false) failed: bad AD file after JDK-8252372 with UseSSE={0,1} Reviewed-by: kvn, roland ! src/hotspot/cpu/x86/x86_32.ad ! src/hotspot/share/opto/castnode.hpp Changeset: 4ac8403f Author: Erik Gahlin Date: 2021-11-01 12:33:10 +0000 URL: https://git.openjdk.java.net/loom/commit/4ac8403f9a4cedcb5d56bcd34a6bbfa51d67ca18 8276218: JFR: Clean up jdk.jfr.dcmd Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/AbstractDCmd.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/DCmdStart.java Changeset: f55e68c9 Author: Patricio Chilano Mateo Date: 2021-11-01 15:27:39 +0000 URL: https://git.openjdk.java.net/loom/commit/f55e68c92924bb70471a4851f616d4c3065ffa92 8275950: Use only _thread_in_vm in ~ThreadBlockInVMPreprocess() Reviewed-by: dholmes, dcubed ! src/hotspot/share/runtime/interfaceSupport.inline.hpp ! src/hotspot/share/runtime/safepoint.cpp ! src/hotspot/share/runtime/safepoint.hpp Changeset: c8abe354 Author: Leo Korinth Date: 2021-11-01 15:37:00 +0000 URL: https://git.openjdk.java.net/loom/commit/c8abe354c1ddc988ff54b9a96a4a825e2aa70f4b 8276121: G1: Remove unused and uninitialized _g1h in g1SATBMarkQueueSet.hpp Reviewed-by: ayang, tschatzl ! src/hotspot/share/gc/g1/g1SATBMarkQueueSet.hpp Changeset: e265f838 Author: Thomas Schatzl Date: 2021-11-01 16:48:13 +0000 URL: https://git.openjdk.java.net/loom/commit/e265f83858b84451258677f130f98be5375a417a 8276107: Preventive collections trigger before maxing out heap Reviewed-by: sjohanss, ayang ! src/hotspot/share/gc/g1/g1Policy.cpp Changeset: 97715440 Author: Patrick Concannon Date: 2021-11-01 17:11:20 +0000 URL: https://git.openjdk.java.net/loom/commit/977154400be786c500f36ba14188bff79db57075 8260428: Drop support for pre JDK 1.4 DatagramSocketImpl implementations Reviewed-by: alanb, dfuchs, vtewari ! src/java.base/share/classes/java/net/DatagramSocketImpl.java ! src/java.base/share/classes/java/net/NetMulticastSocket.java + test/jdk/java/net/DatagramSocket/OldDatagramSocketImplTest.java Changeset: 99b7b95e Author: Zhengyu Gu Date: 2021-11-01 19:38:49 +0000 URL: https://git.openjdk.java.net/loom/commit/99b7b95e014da6e491ba7adfd21de53d6ae166fe 8276205: Shenandoah: CodeCache_lock should always be held for initializing code cache iteration Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp Changeset: 47e7a425 Author: Alisen Chung Committer: Alexander Zuev Date: 2021-11-01 22:29:40 +0000 URL: https://git.openjdk.java.net/loom/commit/47e7a42594f1c36f71cdf4d383080bf8d616b7e7 8262945: [macos] Regression Manual Test for Key Events Fails Reviewed-by: prr, kizune ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTEvent.m Changeset: 2eafa036 Author: Pavel Rappo Date: 2021-11-01 22:50:43 +0000 URL: https://git.openjdk.java.net/loom/commit/2eafa036c03d3e8f3dba8f67dd37b484874dc3d3 8276234: Trivially clean up locale-related code Reviewed-by: redestad, naoto, iris ! src/java.base/share/classes/java/time/chrono/JapaneseChronology.java ! src/java.base/share/classes/sun/util/locale/BaseLocale.java ! src/java.base/share/classes/sun/util/resources/LocaleData.java Changeset: acceffcb Author: Phil Race Date: 2021-11-02 02:49:56 +0000 URL: https://git.openjdk.java.net/loom/commit/acceffcbf73aa4416c487f890f3ca65e55e47164 8273704: DrawStringWithInfiniteXform.java failed : drawString with InfiniteXform transform takes long time Reviewed-by: serb, psadhukhan ! test/jdk/java/awt/FontClass/DrawStringWithInfiniteXform.java Changeset: 0488ebdf Author: Aleksey Shipilev Date: 2021-11-02 06:38:26 +0000 URL: https://git.openjdk.java.net/loom/commit/0488ebdf14dacfa79d98de16ed949c813dd88701 8276105: C2: Conv(D|F)2(I|L)Nodes::Ideal should handle rounding correctly Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/convertnode.cpp Changeset: 9bf31652 Author: Masanori Yano Committer: Alan Bateman Date: 2021-11-02 06:44:48 +0000 URL: https://git.openjdk.java.net/loom/commit/9bf31652cbe8eb2699babe5e52e62ea1f1578588 8276164: RandomAccessFile#write method could throw IndexOutOfBoundsException that is not described in javadoc Reviewed-by: alanb ! src/java.base/share/classes/java/io/DataOutput.java ! src/java.base/share/classes/java/io/RandomAccessFile.java Changeset: 92be9d8c Author: Ludvig Janiuk Committer: Sean Coffey Date: 2021-11-02 09:46:37 +0000 URL: https://git.openjdk.java.net/loom/commit/92be9d8c535274eea4edd06273e6d7811f6bb113 8276236: Table headers missing in Formatter api docs Reviewed-by: coffeys, iris ! src/java.base/share/classes/java/util/Formatter.java Changeset: b7a06be9 Author: Aleksey Shipilev Date: 2021-11-02 10:26:21 +0000 URL: https://git.openjdk.java.net/loom/commit/b7a06be98d3057dac4adbb7f4071ac62cf88fe52 8252990: Intrinsify Unsafe.storeStoreFence Reviewed-by: dholmes, thartmann, whuang ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/arm/arm.ad ! src/hotspot/cpu/ppc/ppc.ad ! src/hotspot/cpu/s390/s390.ad ! src/hotspot/cpu/x86/x86_32.ad ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/share/adlc/formssel.cpp ! src/hotspot/share/c1/c1_Compiler.cpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/classes.hpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/opto/memnode.hpp ! src/java.base/share/classes/jdk/internal/misc/Unsafe.java Changeset: 9971a2ca Author: Severin Gehwolf Date: 2021-11-02 10:39:41 +0000 URL: https://git.openjdk.java.net/loom/commit/9971a2cab3892a17f3fd39243df5ecfff5b9f108 8275735: [linux] Remove deprecated Metrics api (kernel memory limit) Reviewed-by: hseigel, mchung ! src/java.base/linux/classes/jdk/internal/platform/CgroupV1Metrics.java ! src/java.base/linux/classes/jdk/internal/platform/CgroupV1MetricsImpl.java ! src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1Subsystem.java ! test/jdk/jdk/internal/platform/docker/MetricsMemoryTester.java ! test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetrics.java ! test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV1.java Changeset: 8630f55e Author: Hannes Walln?fer Date: 2021-11-02 12:10:47 +0000 URL: https://git.openjdk.java.net/loom/commit/8630f55ed7a0483ec5dcb13a7f53b52bc4ab6fc6 8275406: Add copy-to-clipboard feature to snippet UI Reviewed-by: erikj, jjg ! make/CompileInterimLangtools.gmk ! make/modules/jdk.javadoc/Java.gmk ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlAttr.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/copy.svg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/script.js ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocPaths.java ! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java ! test/langtools/jdk/javadoc/lib/javadoc/tester/LinkChecker.java ! test/langtools/jdk/javadoc/tool/api/basic/APITest.java Changeset: 5b4e3986 Author: Yoshiki Sato Committer: Sean Coffey Date: 2021-11-02 13:02:51 +0000 URL: https://git.openjdk.java.net/loom/commit/5b4e39863dbc0d61e91675261dd6887f704ab868 8275766: (tz) Update Timezone Data to 2021e 8275849: TestZoneInfo310.java fails with tzdata2021e Reviewed-by: naoto, iris, erikj, coffeys ! make/data/tzdata/VERSION ! make/data/tzdata/asia ! make/data/tzdata/australasia ! make/data/tzdata/europe ! make/data/tzdata/northamerica ! src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java Changeset: b889f2a8 Author: Thomas Stuefe Date: 2021-11-02 13:04:09 +0000 URL: https://git.openjdk.java.net/loom/commit/b889f2a88a5e182d2424b741d8fedf2c784442f1 8276175: codestrings.validate_vm gtest still broken on ppc64 after JDK-8276046 Reviewed-by: mdoerr ! test/hotspot/gtest/code/test_codestrings.cpp Changeset: cd778f5b Author: Alexander Zuev Date: 2021-11-02 13:23:18 +0000 URL: https://git.openjdk.java.net/loom/commit/cd778f5b049d52b68ab5872aad5f81e86e1718f7 8202667: java/awt/Debug/DumpOnKey/DumpOnKey.java times out on Windows Reviewed-by: prr ! test/jdk/ProblemList.txt ! test/jdk/java/awt/Debug/DumpOnKey/DumpOnKey.java Changeset: 495c828a Author: Naoto Sato Date: 2021-11-02 16:08:11 +0000 URL: https://git.openjdk.java.net/loom/commit/495c828ae95205885b091dde795b517ba332a2b1 8276188: Clarify "default charset" descriptions in String class Reviewed-by: iris, joehw ! src/java.base/share/classes/java/lang/String.java Changeset: fa4ce824 Author: Brian Burkhalter Date: 2021-11-02 16:27:56 +0000 URL: https://git.openjdk.java.net/loom/commit/fa4ce824a39264e765b8236ee58b1f28faa371e0 8276260: (se) Remove java/nio/channels/Selector/Wakeup.java from ProblemList (win) Reviewed-by: alanb ! test/jdk/ProblemList.txt Changeset: 8fc16f16 Author: Evgeny Astigeevich Committer: Paul Hohensee Date: 2021-11-02 16:32:04 +0000 URL: https://git.openjdk.java.net/loom/commit/8fc16f1605b396bfb9265a97bc126d435d6d5951 8275729: Qualified method names in CodeHeap Analytics Reviewed-by: yyang, thartmann ! src/hotspot/share/code/codeHeapState.cpp + test/hotspot/jtreg/serviceability/dcmd/compiler/CodeHeapAnalyticsMethodNames.java Changeset: 01105d69 Author: Daniel D. Daugherty Date: 2021-11-02 16:50:47 +0000 URL: https://git.openjdk.java.net/loom/commit/01105d6985b39d4064b9066eab3612da5a401685 8276367: ProblemList vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineWithoutBytecodeCorruption/TestDescription.java Reviewed-by: bpb ! test/hotspot/jtreg/ProblemList.txt Changeset: 6a04899b Author: Markus Karg Committer: Lance Andersen Date: 2021-11-02 18:06:14 +0000 URL: https://git.openjdk.java.net/loom/commit/6a04899ba1a62f52f7e28cc2ed72bdca115e6562 8275840: Add test to java/nio/channels/Channels/TransferTo.java to test transfer sizes > 2GB Reviewed-by: lancea ! test/jdk/java/nio/channels/Channels/TransferTo.java Changeset: bb92fb02 Author: Alex Menkov Date: 2021-11-02 21:57:16 +0000 URL: https://git.openjdk.java.net/loom/commit/bb92fb02ca8c5795989065a9037748dc39ed77db 8274930: sun/tools/jps/TestJps.java can fail with long VM arguments string Reviewed-by: sspitsyn, lmesnik ! test/jdk/sun/tools/jps/JpsHelper.java Changeset: 2b02b6f5 Author: Guoxiong Li Date: 2021-11-03 01:57:52 +0000 URL: https://git.openjdk.java.net/loom/commit/2b02b6f513b062261195ca1edd059d16abb7bec6 8274942: AssertionError at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155) Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java + test/langtools/tools/javac/annotations/typeAnnotations/NestTypeAnnotation.java From duke at openjdk.java.net Fri Nov 5 02:09:05 2021 From: duke at openjdk.java.net (duke) Date: Fri, 5 Nov 2021 02:09:05 GMT Subject: git: openjdk/loom: fibers: problemlist updated. Message-ID: <56b18953-b2f2-41f0-a028-317db1f54b10@openjdk.java.net> Changeset: d5ffef4b Author: lmesnik Date: 2021-11-04 20:08:32 +0000 URL: https://git.openjdk.java.net/loom/commit/d5ffef4bc3986426bbbae2c7f8cc8ef5f382c3d1 problemlist updated. ! test/hotspot/jtreg/ProblemList-vthread.txt From duke at openjdk.java.net Fri Nov 5 03:15:08 2021 From: duke at openjdk.java.net (duke) Date: Fri, 5 Nov 2021 03:15:08 GMT Subject: git: openjdk/loom: fibers: framecnt01.java fixed to be more stable. Message-ID: <95b473af-26db-4541-966b-05a98dd2c8ee@openjdk.java.net> Changeset: ccf6d236 Author: lmesnik Date: 2021-11-04 21:14:26 +0000 URL: https://git.openjdk.java.net/loom/commit/ccf6d236c88eefad769de685bff2c27396e936b1 framecnt01.java fixed to be more stable. ! test/hotspot/jtreg/serviceability/jvmti/thread/GetFrameCount/framecnt01/framecnt01.java From duke at openjdk.java.net Fri Nov 5 11:16:44 2021 From: duke at openjdk.java.net (duke) Date: Fri, 5 Nov 2021 11:16:44 GMT Subject: git: openjdk/loom: fibers: 4 new changesets Message-ID: Changeset: 70e04cb2 Author: Alan Bateman Date: 2021-11-03 19:13:38 +0000 URL: https://git.openjdk.java.net/loom/commit/70e04cb2b8de32b0e0b9dfef4481cf2c546092b9 Delay loading Thread ! src/java.base/share/classes/java/lang/Thread.java Changeset: baa7b451 Author: Alan Bateman Date: 2021-11-04 17:10:07 +0000 URL: https://git.openjdk.java.net/loom/commit/baa7b4511992e27c283cee058ee8b93e2e849cb4 Delay creating gates ! src/java.base/share/classes/java/net/URL.java ! src/java.base/share/classes/java/nio/charset/Charset.java Changeset: 91a498f4 Author: Alan Bateman Date: 2021-11-04 17:10:39 +0000 URL: https://git.openjdk.java.net/loom/commit/91a498f43c4658013edc353d359710c077351fc3 Delay ReferenceHandler to afer initPhase1 ! src/java.base/share/classes/java/lang/ref/NativeReferenceQueue.java ! src/java.base/share/classes/java/lang/ref/Reference.java ! src/java.base/share/classes/java/lang/ref/ReferenceQueue.java Changeset: 12bc1b9b Author: Alan Bateman Date: 2021-11-05 11:13:22 +0000 URL: https://git.openjdk.java.net/loom/commit/12bc1b9b6774aa4e10ff7a45c7eaaed3bf378280 Update ProblemList with JBS issues ! test/hotspot/jtreg/ProblemList.txt From duke at openjdk.java.net Fri Nov 5 13:11:32 2021 From: duke at openjdk.java.net (duke) Date: Fri, 5 Nov 2021 13:11:32 GMT Subject: git: openjdk/loom: fibers: Add WXWrite in signal handling Message-ID: <43a8fd77-7e0d-4a3d-b9da-27e2eb68565f@openjdk.java.net> Changeset: f22b88b6 Author: Ron Pressler Date: 2021-11-05 13:10:05 +0000 URL: https://git.openjdk.java.net/loom/commit/f22b88b6d939f2d3390ae41e6d64a05a0d406a2a Add WXWrite in signal handling ! src/hotspot/os/posix/signals_posix.cpp From duke at openjdk.java.net Fri Nov 5 13:47:46 2021 From: duke at openjdk.java.net (duke) Date: Fri, 5 Nov 2021 13:47:46 GMT Subject: git: openjdk/loom: fibers: improved jvmtiVTMTDisabler sync to make Suspend/Resume monopolists Message-ID: <42b1a30b-e78c-4871-92b7-c5dade4bea4a@openjdk.java.net> Changeset: 3725b990 Author: Serguei Spitsyn Date: 2021-11-05 13:46:55 +0000 URL: https://git.openjdk.java.net/loom/commit/3725b990221d380e686c7cc42e82700a13562a2e improved jvmtiVTMTDisabler sync to make Suspend/Resume monopolists ! src/hotspot/share/prims/jvmtiEnv.cpp ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! src/hotspot/share/prims/jvmtiEnvBase.hpp ! src/hotspot/share/prims/jvmtiThreadState.cpp ! src/hotspot/share/prims/jvmtiThreadState.hpp ! src/hotspot/share/runtime/thread.cpp ! test/hotspot/jtreg/serviceability/jvmti/SuspendWithCurrentThread/libSuspendWithCurrentThread.cpp ! test/hotspot/jtreg/serviceability/jvmti/stress/StackTrace/Suspended/libGetStackTraceSuspendedStress.cpp From eric at kolotyluk.net Fri Nov 5 23:46:15 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Fri, 5 Nov 2021 16:46:15 -0700 Subject: Java Micro-benchmark Harness Message-ID: Has anyone gotten JMH to work with JDK-18 + Loom? I tried but JMH doesn't like Version 62 Classfiles... I have tried to contact the JMH people, but there seem to be no channels open to me. Cheers, Eric From shade at redhat.com Sat Nov 6 07:15:59 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Sat, 6 Nov 2021 08:15:59 +0100 Subject: Java Micro-benchmark Harness In-Reply-To: References: Message-ID: <3e35bc5c-4b6e-92d0-c6dc-51ea07aceafb@redhat.com> On 11/6/21 12:46 AM, Eric Kolotyluk wrote: > Has anyone gotten JMH to work with JDK-18 + Loom? > I tried but JMH doesn't like Version 62 Classfiles... JMH should work with whatever classfiles, provided you have actually set appropriate source/target in the benchmark project. Please provide MCVE if you want more help. > I have tried to contact the JMH people, but there seem to be no channels > open to me. Odd. I don't see any messages either on StackOverflow or jmh-dev@ from you. Which channels did you try? -- Thanks, -Aleksey From Alan.Bateman at oracle.com Sat Nov 6 08:18:28 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 6 Nov 2021 08:18:28 +0000 Subject: Java Micro-benchmark Harness In-Reply-To: <3e35bc5c-4b6e-92d0-c6dc-51ea07aceafb@redhat.com> References: <3e35bc5c-4b6e-92d0-c6dc-51ea07aceafb@redhat.com> Message-ID: On 06/11/2021 07:15, Aleksey Shipilev wrote: > On 11/6/21 12:46 AM, Eric Kolotyluk wrote: >> Has anyone gotten JMH to work with JDK-18 + Loom? >> I tried but JMH doesn't like Version 62 Classfiles... > > JMH should work with whatever classfiles, provided you have actually > set appropriate source/target in the benchmark project. Please provide > MCVE if you want more help. Just to add that I'm not aware of any issues using JMH with the loom repo. Once you upgrade to a version that works with JDK 18 EA builds then it should work with a build of the loom repo too. -Alan From duke at openjdk.java.net Sat Nov 6 08:50:27 2021 From: duke at openjdk.java.net (duke) Date: Sat, 6 Nov 2021 08:50:27 GMT Subject: git: openjdk/loom: fibers: refactor self suspension in SuspendThread and SuspendThreadList Message-ID: <5e400cec-4022-4f4c-a004-0407e191ce81@openjdk.java.net> Changeset: 7a79fbe0 Author: Serguei Spitsyn Date: 2021-11-06 08:48:59 +0000 URL: https://git.openjdk.java.net/loom/commit/7a79fbe0abf48cb188e5aa6c26ca86a94a225f36 refactor self suspension in SuspendThread and SuspendThreadList ! src/hotspot/share/prims/jvmtiEnv.cpp ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! src/hotspot/share/prims/jvmtiThreadState.cpp ! src/hotspot/share/prims/jvmtiThreadState.hpp From duke at openjdk.java.net Sat Nov 6 09:25:05 2021 From: duke at openjdk.java.net (duke) Date: Sat, 6 Nov 2021 09:25:05 GMT Subject: git: openjdk/loom: fibers: Exclude InvalidGlobalFilterTest from running with wrapper Message-ID: Changeset: 3ca70794 Author: Alan Bateman Date: 2021-11-06 09:16:26 +0000 URL: https://git.openjdk.java.net/loom/commit/3ca70794a883fae83f5e8800f6f0a564ea2da1ed Exclude InvalidGlobalFilterTest from running with wrapper ! test/jdk/ProblemList-vthread.txt From duke at openjdk.java.net Sat Nov 6 13:12:07 2021 From: duke at openjdk.java.net (duke) Date: Sat, 6 Nov 2021 13:12:07 GMT Subject: git: openjdk/loom: fibers: fix self suspend logic in SuspendAllVirualThreads Message-ID: Changeset: dc9f3fb4 Author: Serguei Spitsyn Date: 2021-11-06 13:11:10 +0000 URL: https://git.openjdk.java.net/loom/commit/dc9f3fb4d4889cdc58daacda31a7305fb1ce00d7 fix self suspend logic in SuspendAllVirualThreads ! src/hotspot/share/prims/jvmtiEnv.cpp ! test/hotspot/jtreg/serviceability/jvmti/vthread/SelfSuspendDisablerTest/SelfSuspendDisablerTest.java ! test/hotspot/jtreg/serviceability/jvmti/vthread/SelfSuspendDisablerTest/libSelfSuspendDisablerTest.cpp From duke at openjdk.java.net Sat Nov 6 16:16:04 2021 From: duke at openjdk.java.net (duke) Date: Sat, 6 Nov 2021 16:16:04 GMT Subject: git: openjdk/loom: fibers: Fix windows build Message-ID: Changeset: 968aeb9a Author: Alan Bateman Date: 2021-11-06 16:15:27 +0000 URL: https://git.openjdk.java.net/loom/commit/968aeb9a6e5142071282cbeeb913e8c58a53adeb Fix windows build ! test/hotspot/jtreg/serviceability/jvmti/vthread/SelfSuspendDisablerTest/libSelfSuspendDisablerTest.cpp From eric at kolotyluk.net Sat Nov 6 19:24:50 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Sat, 6 Nov 2021 12:24:50 -0700 Subject: Java Micro-benchmark Harness In-Reply-To: References: <3e35bc5c-4b6e-92d0-c6dc-51ea07aceafb@redhat.com> Message-ID: Okay, found the problem, while my Maven Project was specifying JDK-18, my command line was still using JDK-17... sorry about not checking correctly... things seem to be running correctly now. ... Aleksey, I tried subscribing to jmh-dev, but never got back acknowledgment, so I cannot post there yet. Does someone need to approve my subscription? I have not posted to StackOverflow yet about JMH. I did post earlier to loom-dev, but none of my posts from my Microsoft Mail client seem to go through there, so now I am posting via Gmail. According to the JMH home page, they say to get support via JDK Bug System (which I don't have access to) or "submit the bug report at 'Issues' here" but it looks like Issues has been disabled for this GitHub project. Thanks for your replies, everyone... Cheers, Eric On Sat, Nov 6, 2021 at 1:18 AM Alan Bateman wrote: > On 06/11/2021 07:15, Aleksey Shipilev wrote: > > On 11/6/21 12:46 AM, Eric Kolotyluk wrote: > >> Has anyone gotten JMH to work with JDK-18 + Loom? > >> I tried but JMH doesn't like Version 62 Classfiles... > > > > JMH should work with whatever classfiles, provided you have actually > > set appropriate source/target in the benchmark project. Please provide > > MCVE if you want more help. > Just to add that I'm not aware of any issues using JMH with the loom > repo. Once you upgrade to a version that works with JDK 18 EA builds > then it should work with a build of the loom repo too. > > -Alan > From duke at openjdk.java.net Mon Nov 8 09:03:43 2021 From: duke at openjdk.java.net (duke) Date: Mon, 8 Nov 2021 09:03:43 GMT Subject: git: openjdk/loom: fibers: 6 new changesets Message-ID: Changeset: 59135f9c Author: Alan Bateman Date: 2021-11-06 16:32:10 +0000 URL: https://git.openjdk.java.net/loom/commit/59135f9c6a46991c8ca155241f02e598635c452b Restore from main line ! src/java.base/share/classes/java/nio/charset/Charset.java ! src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java ! src/java.base/share/classes/jdk/internal/math/FormattedFloatingDecimal.java Changeset: 82ee515e Author: Alan Bateman Date: 2021-11-07 16:07:23 +0000 URL: https://git.openjdk.java.net/loom/commit/82ee515e1875f99a18aa0c2ba2ddb3a0229b543a Test needs to compile/run with --enable-preview ! test/jdk/java/lang/instrument/ParallelTransformerLoaderTest.java Changeset: 0438ba27 Author: Alan Bateman Date: 2021-11-07 17:14:45 +0000 URL: https://git.openjdk.java.net/loom/commit/0438ba27c47d5894aadfc7ca3a5a7aa39600dcc1 Exclude SA tests, not in sync with hotspot ! test/hotspot/jtreg/ProblemList.txt Changeset: f6f76923 Author: Alan Bateman Date: 2021-11-07 19:07:10 +0000 URL: https://git.openjdk.java.net/loom/commit/f6f769235ba8a3cd59994ec856f4a40748ba4882 Another SA test failing ! test/hotspot/jtreg/ProblemList.txt Changeset: 5db32e26 Author: Alan Bateman Date: 2021-11-07 19:47:54 +0000 URL: https://git.openjdk.java.net/loom/commit/5db32e26119f04a4b7b8c046e7db7c5aee435de0 Improve init ! src/java.base/share/classes/java/util/concurrent/Executors.java ! src/java.base/share/classes/java/util/concurrent/ThreadPerTaskExecutor.java ! src/java.base/share/classes/jdk/internal/vm/SharedThreadContainer.java Changeset: d865bc83 Author: Alan Bateman Date: 2021-11-08 08:11:30 +0000 URL: https://git.openjdk.java.net/loom/commit/d865bc8306dde7322854c321846baa1b12a0b36c Parking test failing with jtreg wrapper ! test/jdk/java/lang/Thread/virtual/Parking.java From eric at kolotyluk.net Mon Nov 8 17:02:16 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Mon, 8 Nov 2021 09:02:16 -0800 Subject: Interesting Benchmarks Message-ID: Ron, based on your advice, in my loom-lab project I finally did some benchmarks with JMH, focusing on 'throughput'. The units are in milliseconds. Benchmark Mode Cnt Score PrimeThreads.platformPrimesTo_1000 avgt 25 131.536 ? 2.860 PrimeThreads.platformPrimesTo_10_000 avgt 25 1132.570 ? 88.749 PrimeThreads.platformPrimesTo_10_000_000 avgt 25 113223.001 ? 95938.331 PrimeThreads.virtualPrimesTo_1000 avgt 25 32.998 ? 9.349 PrimeThreads.virtualPrimesTo_10_000 avgt 25 58.174 ? 0.742 PrimeThreads.virtualPrimesTo_10_000_000 avgt 25 34989.439 ? 1354.511 Benchmark tested throughput ratio PrimeThreads.platformPrimesTo_1000 500 3.801 0.251 PrimeThreads.platformPrimesTo_10_000 5,000 4.415 0.051 PrimeThreads.platformPrimesTo_10_000_000 5,000,000 4.416 0.031 PrimeThreads.virtualPrimesTo_1000 500 15.152 3.986 PrimeThreads.virtualPrimesTo_10_000 5,000 85.947 19.467 PrimeThreads.virtualPrimesTo_10_000_000 5,000,000 142.900 32.360 In a test of 5,000,000 threads running, Virtual Threads have 32 times the throughput of Platform Threads, for this particular application. I would not have thought it possible to run 5,000,000 Platform Threads. Given the fans on my system were generally running at full, I think Project Loom also deserves some bragging rights on saving energy. It would be interesting to benchmark again with my power meter to see how many Joules were consumed for Virtual Threads vs Platform Threads. Thanks again for helping clarify my thinking, I will try to devise some synthetic benchmarks that are based on just thread performance, without calculating prime numbers. Cheers, Eric From ignazb at gmail.com Mon Nov 8 20:50:47 2021 From: ignazb at gmail.com (Ignaz Birnstingl) Date: Mon, 08 Nov 2021 21:50:47 +0100 Subject: Interesting Benchmarks In-Reply-To: References: Message-ID: Hi Eric, > I would > not have thought it possible to run 5,000,000 Platform Threads. As far as I can tell by looking at your code you didn't. I think you submit the tasks sequentially to an ExecutorService created with Executors.newThreadPerTaskExecutor(). This causes many tasks (=threads) to end before the last one is submitted. I would suggest you use a different (thread caching) ExecutorService for platform threads. Otherwise you are mainly measuring thread creation time of virtual threads vs platform threads. Ignaz From eric at kolotyluk.net Tue Nov 9 04:19:56 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Mon, 8 Nov 2021 20:19:56 -0800 Subject: Interesting Benchmarks In-Reply-To: References: Message-ID: Thanks for the insights Ignaz... Yes, I am using Executors.newThreadPerTaskExecutor(threadFactory), but I am new to this API. At this point, I don't really care if I did have 5,000,000 Platform Threads running, only wanted to compare the throughput of Platform Threads to Virtual Threads. If you are suggesting this was not a good experiment, I want to correct that. I can see now some more mistakes I made, so will have to rerun the benchmarks again. Cheers, Eric On Mon, Nov 8, 2021 at 12:50 PM Ignaz Birnstingl wrote: > Hi Eric, > > > I would > > not have thought it possible to run 5,000,000 Platform Threads. > > As far as I can tell by looking at your code you didn't. I think you > submit the tasks sequentially to an ExecutorService created with > Executors.newThreadPerTaskExecutor(). This causes many tasks (=threads) > to > end before the last one is submitted. > > I would suggest you use a different (thread caching) ExecutorService for > platform threads. Otherwise you are mainly measuring thread creation time > of virtual threads vs platform threads. > > Ignaz > From coleenp at openjdk.java.net Tue Nov 9 13:31:10 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 9 Nov 2021 13:31:10 GMT Subject: RFR: Add flag to prevent multiple deopts on the same nmethod. Message-ID: I added a flag to prevent the same nmethod from being optimized multiple times. It might be better to have a new MarkForDeoptimizationStatus enum but wasn't sure how that would interact with the deoptimize_update state. Maybe that's better. I also don't know why the sweeper is so slow to get rid of these entries. This makes ctw_2 test run in an hour on my machine, just like mainline jdk/jdk (machine is slow!) in fastdebug. ------------- Commit messages: - Add flag to prevent multiple deopts on the same nmethod. Changes: https://git.openjdk.java.net/loom/pull/81/files Webrev: https://webrevs.openjdk.java.net/?repo=loom&pr=81&range=00 Stats: 13 lines in 4 files changed: 10 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/loom/pull/81.diff Fetch: git fetch https://git.openjdk.java.net/loom pull/81/head:pull/81 PR: https://git.openjdk.java.net/loom/pull/81 From rpressler at openjdk.java.net Tue Nov 9 15:47:53 2021 From: rpressler at openjdk.java.net (Ron Pressler) Date: Tue, 9 Nov 2021 15:47:53 GMT Subject: RFR: Add flag to prevent multiple deopts on the same nmethod. In-Reply-To: References: Message-ID: On Tue, 9 Nov 2021 13:25:50 GMT, Coleen Phillimore wrote: > I added a flag to prevent the same nmethod from being optimized multiple times. It might be better to have a new MarkForDeoptimizationStatus enum but wasn't sure how that would interact with the deoptimize_update state. Advice welcome. > I also don't know why the sweeper is so slow to get rid of these entries. > This makes ctw_2 test run in an hour on my machine, just like mainline jdk/jdk (machine is slow!) in fastdebug. Seems fine to me, although I agree that adding another value to `MarkForDeoptimizationStatus` would look cleaner and make more sense if it were possible. I don't know the answer to that. ------------- Marked as reviewed by rpressler (Lead). PR: https://git.openjdk.java.net/loom/pull/81 From duke at openjdk.java.net Tue Nov 9 16:30:23 2021 From: duke at openjdk.java.net (duke) Date: Tue, 9 Nov 2021 16:30:23 GMT Subject: git: openjdk/loom: fibers: 2 new changesets Message-ID: Changeset: a183d45c Author: Alan Bateman Date: 2021-11-09 12:28:59 +0000 URL: https://git.openjdk.java.net/loom/commit/a183d45c39957706a0a9c29f4786febd788de6d7 Intermittent test failures with -Xcomp/-XX:-TieredCompilation ! test/jdk/java/lang/Thread/virtual/JfrEvents.java ! test/jdk/java/lang/Thread/virtual/Parking.java ! test/jdk/java/lang/Thread/virtual/ThreadAPI.java Changeset: 4809d7f5 Author: Alan Bateman Date: 2021-11-09 15:46:22 +0000 URL: https://git.openjdk.java.net/loom/commit/4809d7f5cbf111991f3d9ed8ca4e7fc6b0759fa8 Remove spurious empty line ! test/jdk/com/sun/management/HotSpotDiagnosticMXBean/DumpThreads.java From coleenp at openjdk.java.net Tue Nov 9 18:21:06 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 9 Nov 2021 18:21:06 GMT Subject: RFR: Add flag to prevent multiple deopts on the same nmethod. [v2] In-Reply-To: References: Message-ID: > I added a flag to prevent the same nmethod from being optimized multiple times. It might be better to have a new MarkForDeoptimizationStatus enum but wasn't sure how that would interact with the deoptimize_update state. Advice welcome. > I also don't know why the sweeper is so slow to get rid of these entries. > This makes ctw_2 test run in an hour on my machine, just like mainline jdk/jdk (machine is slow!) in fastdebug. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: This is better imo. ------------- Changes: - all: https://git.openjdk.java.net/loom/pull/81/files - new: https://git.openjdk.java.net/loom/pull/81/files/5dfd79e1..cb8b8925 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=loom&pr=81&range=01 - incr: https://webrevs.openjdk.java.net/?repo=loom&pr=81&range=00-01 Stats: 9 lines in 2 files changed: 3 ins; 2 del; 4 mod Patch: https://git.openjdk.java.net/loom/pull/81.diff Fetch: git fetch https://git.openjdk.java.net/loom pull/81/head:pull/81 PR: https://git.openjdk.java.net/loom/pull/81 From coleenp at openjdk.java.net Tue Nov 9 18:21:08 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 9 Nov 2021 18:21:08 GMT Subject: RFR: Add flag to prevent multiple deopts on the same nmethod. In-Reply-To: References: Message-ID: On Tue, 9 Nov 2021 13:25:50 GMT, Coleen Phillimore wrote: > I added a flag to prevent the same nmethod from being optimized multiple times. It might be better to have a new MarkForDeoptimizationStatus enum but wasn't sure how that would interact with the deoptimize_update state. Advice welcome. > I also don't know why the sweeper is so slow to get rid of these entries. > This makes ctw_2 test run in an hour on my machine, just like mainline jdk/jdk (machine is slow!) in fastdebug. I had a look again and can add the flag to MarkForDeoptimizationStatus which I left as a u1. ------------- PR: https://git.openjdk.java.net/loom/pull/81 From rpressler at openjdk.java.net Tue Nov 9 18:33:50 2021 From: rpressler at openjdk.java.net (Ron Pressler) Date: Tue, 9 Nov 2021 18:33:50 GMT Subject: RFR: Add flag to prevent multiple deopts on the same nmethod. [v2] In-Reply-To: References: Message-ID: On Tue, 9 Nov 2021 18:21:06 GMT, Coleen Phillimore wrote: >> I added a flag to prevent the same nmethod from being optimized multiple times. It might be better to have a new MarkForDeoptimizationStatus enum but wasn't sure how that would interact with the deoptimize_update state. Advice welcome. >> I also don't know why the sweeper is so slow to get rid of these entries. >> This makes ctw_2 test run in an hour on my machine, just like mainline jdk/jdk (machine is slow!) in fastdebug. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > This is better imo. Marked as reviewed by rpressler (Lead). ------------- PR: https://git.openjdk.java.net/loom/pull/81 From coleenp at openjdk.java.net Tue Nov 9 20:22:37 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 9 Nov 2021 20:22:37 GMT Subject: RFR: Add flag to prevent multiple deopts on the same nmethod. [v3] In-Reply-To: References: Message-ID: > I added a flag to prevent the same nmethod from being optimized multiple times. It might be better to have a new MarkForDeoptimizationStatus enum but wasn't sure how that would interact with the deoptimize_update state. Advice welcome. > I also don't know why the sweeper is so slow to get rid of these entries. > This makes ctw_2 test run in an hour on my machine, just like mainline jdk/jdk (machine is slow!) in fastdebug. Coleen Phillimore 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 'fibers' into ctw - This is better imo. - Add flag to prevent multiple deopts on the same nmethod. ------------- Changes: - all: https://git.openjdk.java.net/loom/pull/81/files - new: https://git.openjdk.java.net/loom/pull/81/files/cb8b8925..0d998c61 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=loom&pr=81&range=02 - incr: https://webrevs.openjdk.java.net/?repo=loom&pr=81&range=01-02 Stats: 21948 lines in 709 files changed: 16317 ins; 2922 del; 2709 mod Patch: https://git.openjdk.java.net/loom/pull/81.diff Fetch: git fetch https://git.openjdk.java.net/loom pull/81/head:pull/81 PR: https://git.openjdk.java.net/loom/pull/81 From eric at kolotyluk.net Tue Nov 9 21:20:31 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Tue, 9 Nov 2021 13:20:31 -0800 Subject: Interesting Benchmarks In-Reply-To: References: Message-ID: Okay, after correcting some code mistakes, my latest benchmarks are * Benchmark tested throughput ratio * PrimeThreads.platformPrimesTo_1000 500 4.098 0.274 * PrimeThreads.platformPrimesTo_10_000 5,000 5.068 0.054 * PrimeThreads.platformPrimesTo_10_000_000 5,000,000 4.791 0.032 * PrimeThreads.virtualPrimesTo_1000 500 14.961 3.651 * PrimeThreads.virtualPrimesTo_10_000 5,000 93.500 18.449 * PrimeThreads.virtualPrimesTo_10_000_000 5,000,000 151.248 31.569 This is based on public static void futurePrimes22(long limit, ThreadFactory threadFactory) { try (var executorService = Executors.newThreadPerTaskExecutor(threadFactory)) { var tasks = LongStream.iterate(3, x -> x < limit, x -> x + 2) .mapToObj(candidate -> { return executorService.submit(() -> isPrime(candidate, 10, 30) ? candidate : null); }).collect(Collectors.toList()); var result = tasks.stream().filter(x -> { try { return x.get() != null; } catch (InterruptedException e) { e.printStackTrace(); } catch (ExecutionException e) { e.printStackTrace(); } return false; }); } } and static boolean isPrime(long candidate, long minimumLag, long maximumLag) { BinaryOperator lag = (minimum, maximum) -> { if (minimum <= 0 || maximum <= 0) return 0L; var approx = (long) Math.nextUp(Math.sqrt(maximum - minimum)); try { var approximateLag = minimum + approx; Thread.sleep(approximateLag); return approximateLag; } catch (InterruptedException e) { e.printStackTrace(); } finally { return 0L; } }; lag.apply(minimumLag, maximumLag); // Simulate network request overhead if (candidate == 2) return true; if ((candidate & 1) == 0) return false; // filter out even numbers var limit = (long) Math.nextUp(Math.sqrt(candidate)); for (long divisor = 3; divisor <= limit; divisor += 2) { // Thread.onSpinWait(); // If you think this will help, it likely won't if (candidate % divisor == 0) return false; } lag.apply(minimumLag, maximumLag); // Simulate network response overhead return true; } where I vary limit and threadFactory. So, I am trying to understand Ignaz's observation that I would not be launching 5,000,000 threads at once because I am using newThreadPerTaskExecutor(), because I want to be able to explain this to others. Given that the first thing isPrime() does is call threadSleep() for 10 to 30 ms, wouldn't that give newThreadPerTaskExecutor() a chance to ramp up a lot of threads? Is there something that limits the number of threads that will be started? Is 10 - 30 ms too short to start that many threads? Sorry if I seem a little naive, but I want to understand. Cheers, Eric On Mon, Nov 8, 2021 at 8:19 PM Eric Kolotyluk wrote: > Thanks for the insights Ignaz... > > Yes, I am using Executors.newThreadPerTaskExecutor(threadFactory), but I > am new to this API. At this point, I don't really care if I did have > 5,000,000 Platform Threads running, only wanted to compare the throughput > of Platform Threads to Virtual Threads. If you are suggesting this was not > a good experiment, I want to correct that. > > I can see now some more mistakes I made, so will have to rerun the > benchmarks again. > > Cheers, Eric > > > > > > On Mon, Nov 8, 2021 at 12:50 PM Ignaz Birnstingl wrote: > >> Hi Eric, >> >> > I would >> > not have thought it possible to run 5,000,000 Platform Threads. >> >> As far as I can tell by looking at your code you didn't. I think you >> submit the tasks sequentially to an ExecutorService created with >> Executors.newThreadPerTaskExecutor(). This causes many tasks (=threads) >> to >> end before the last one is submitted. >> >> I would suggest you use a different (thread caching) ExecutorService for >> platform threads. Otherwise you are mainly measuring thread creation >> time >> of virtual threads vs platform threads. >> >> Ignaz >> > From rbackman at openjdk.java.net Tue Nov 9 21:38:53 2021 From: rbackman at openjdk.java.net (Rickard =?UTF-8?B?QsOkY2ttYW4=?=) Date: Tue, 9 Nov 2021 21:38:53 GMT Subject: RFR: Add flag to prevent multiple deopts on the same nmethod. [v3] In-Reply-To: References: Message-ID: <0qd6SMxCK-87IicSbV9m6vLouMLtyZnK9JfOwQGtTjc=.689b54cf-b2c4-4708-9889-e12e77db34c2@github.com> On Tue, 9 Nov 2021 20:22:37 GMT, Coleen Phillimore wrote: >> I added a flag to prevent the same nmethod from being optimized multiple times. It might be better to have a new MarkForDeoptimizationStatus enum but wasn't sure how that would interact with the deoptimize_update state. Advice welcome. >> I also don't know why the sweeper is so slow to get rid of these entries. >> This makes ctw_2 test run in an hour on my machine, just like mainline jdk/jdk (machine is slow!) in fastdebug. > > Coleen Phillimore 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 'fibers' into ctw > - This is better imo. > - Add flag to prevent multiple deopts on the same nmethod. Looks good. ------------- Marked as reviewed by rbackman (Committer). PR: https://git.openjdk.java.net/loom/pull/81 From coleenp at openjdk.java.net Wed Nov 10 14:23:27 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 10 Nov 2021 14:23:27 GMT Subject: RFR: Add flag to prevent multiple deopts on the same nmethod. [v4] In-Reply-To: References: Message-ID: > I added a flag to prevent the same nmethod from being optimized multiple times. It might be better to have a new MarkForDeoptimizationStatus enum but wasn't sure how that would interact with the deoptimize_update state. Advice welcome. > I also don't know why the sweeper is so slow to get rid of these entries. > This makes ctw_2 test run in an hour on my machine, just like mainline jdk/jdk (machine is slow!) in fastdebug. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: CodeCache::mark_all_nmethods_for_deoptimization does try to make the state go backwards. ------------- Changes: - all: https://git.openjdk.java.net/loom/pull/81/files - new: https://git.openjdk.java.net/loom/pull/81/files/0d998c61..2865436f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=loom&pr=81&range=03 - incr: https://webrevs.openjdk.java.net/?repo=loom&pr=81&range=02-03 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/loom/pull/81.diff Fetch: git fetch https://git.openjdk.java.net/loom pull/81/head:pull/81 PR: https://git.openjdk.java.net/loom/pull/81 From duke at openjdk.java.net Wed Nov 10 16:40:58 2021 From: duke at openjdk.java.net (duke) Date: Wed, 10 Nov 2021 16:40:58 GMT Subject: git: openjdk/loom: fibers: 4 new changesets Message-ID: Changeset: 88d69ed8 Author: Alan Bateman Date: 2021-11-10 12:26:51 +0000 URL: https://git.openjdk.java.net/loom/commit/88d69ed896237c4f8fdba5a93fa6734262dab52f Cleanup ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/lang/Thread.java ! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java ! src/java.base/share/classes/jdk/internal/vm/StackableScope.java Changeset: 413ad24c Author: Alan Bateman Date: 2021-11-10 15:03:28 +0000 URL: https://git.openjdk.java.net/loom/commit/413ad24ce86085412970f0450437c31a49c719f4 Ensure that resultNow/exceptionNow handle completing state ! src/java.base/share/classes/java/util/concurrent/FutureTask.java Changeset: 635a0aa9 Author: Alan Bateman Date: 2021-11-10 15:20:07 +0000 URL: https://git.openjdk.java.net/loom/commit/635a0aa96e2e06edcac4c6c269cd7c2abad93bb5 Leftover import ! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java Changeset: a5f47ffd Author: Alan Bateman Date: 2021-11-10 15:31:57 +0000 URL: https://git.openjdk.java.net/loom/commit/a5f47ffd1c157f2109ec38a7ad421b09eebc3bfb TaskSession (name TBD) prototype ! src/java.base/share/classes/java/lang/ScopeLocal.java + src/java.base/share/classes/java/lang/StructureViolationException.java + src/java.base/share/classes/java/util/concurrent/TaskSession.java ! src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java + src/java.base/share/classes/jdk/internal/misc/ThreadFlock.java ! test/jdk/TEST.groups + test/jdk/java/util/concurrent/TaskSession/TaskSessionTest.java + test/jdk/jdk/internal/misc/ThreadFlock/ThreadFlockTest.java From ignazb at gmail.com Wed Nov 10 20:16:11 2021 From: ignazb at gmail.com (Ignaz Birnstingl) Date: Wed, 10 Nov 2021 21:16:11 +0100 Subject: Interesting Benchmarks In-Reply-To: References: Message-ID: Hi Eric, here are my thoughts: Creating platform threads is an expensive operation. Your benchmarks show this very well. I would guess that starting a single platform thread costs somewhere between 10?s to 1ms. So spinning up platform threads that run for ~30ms before terminating means that at most 30000 platform threads would run in parallel. You could easily check that by using two AtomicIntegers in your isPrime() method: One keeps a count of currently running tasks. You increment it in the beginning of isPrime() and decrement it in the end of isPrime(). The other one would hold the maximum of the first one after incrementation. I would guess that the maximum of platform threads running in parallel is much lower than for virtual threads. If you want to compare the throughput of the solutions it would probably make sense to pass in the ExecutorService you want to use to your futurePrimes22() method instead of creating it in there. Then you could compare Executors.newCachedThreadPool() vs. Executors.newFixedThreadPool() (with different numbers) and Executors.newVirtualThreadExecutor(). Ignaz From coleenp at openjdk.java.net Wed Nov 10 22:05:54 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 10 Nov 2021 22:05:54 GMT Subject: Withdrawn: Add flag to prevent multiple deopts on the same nmethod. In-Reply-To: References: Message-ID: On Tue, 9 Nov 2021 13:25:50 GMT, Coleen Phillimore wrote: > I added a flag to prevent the same nmethod from being optimized multiple times. It might be better to have a new MarkForDeoptimizationStatus enum but wasn't sure how that would interact with the deoptimize_update state. Advice welcome. > I also don't know why the sweeper is so slow to get rid of these entries. > This makes ctw_2 test run in an hour on my machine, just like mainline jdk/jdk (machine is slow!) in fastdebug. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/loom/pull/81 From coleenp at openjdk.java.net Wed Nov 10 22:05:54 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 10 Nov 2021 22:05:54 GMT Subject: RFR: Add flag to prevent multiple deopts on the same nmethod. [v4] In-Reply-To: References: Message-ID: On Wed, 10 Nov 2021 14:23:27 GMT, Coleen Phillimore wrote: >> I added a flag to prevent the same nmethod from being optimized multiple times. It might be better to have a new MarkForDeoptimizationStatus enum but wasn't sure how that would interact with the deoptimize_update state. Advice welcome. >> I also don't know why the sweeper is so slow to get rid of these entries. >> This makes ctw_2 test run in an hour on my machine, just like mainline jdk/jdk (machine is slow!) in fastdebug. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > CodeCache::mark_all_nmethods_for_deoptimization does try to make the state go backwards. Erik has a different change that's going into mainline first. ------------- PR: https://git.openjdk.java.net/loom/pull/81 From eric at kolotyluk.net Fri Nov 12 14:32:50 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Fri, 12 Nov 2021 06:32:50 -0800 Subject: Interesting Benchmarks In-Reply-To: References: Message-ID: Okay, more learning... Using JMH for what I am doing is completely wrong ?? I started using it without understanding it. I am not sure if it can do what I want? When I started using AtomicLong based on Ignaz suggestion, I discovered that JMH was calling my code many more times than I thought, which was wrong. I will have to try to understand JMH better... Mostly with this project, I am learning how wrong my assumptions were, but I am learning to correct them. * Prime numbers to 1,000 to 10,000 to 10,000,000 * tasks op/ms ratio tasks op/ms ratio tasks op/ms ratio * virtualCachedThreadPool 499 6.329 3.224 3711 34.722 1.625 3103283 115.452 0.834 * virtualThreadPerTaskExecutor 499 8.772 2.599 4906 65.789 3.894 3454111 138.765 31.616 * platformCachedThreadPool 256 1.953 0.310 828 21.367 0.615 3690 138.378 1.198 * platformThreadPerTaskExecutor 149 3.356 0.385 140 4.766 0.072 186 4.389 0.032 Here are my latest benchmarks 1. My prime numbers simulated a network using Thread.sleep() 2. Initially I tested with .newFixedThreadPool() and .newSingleThreadExecutor, but did not find the results interesting, just predictably slow 3. I used AtomicLong to keep track of the number and maximum number of tasks spawned by each ExecutorService 4. platformCachedThreadPool and platformThreadPerTaskExecutor are very good at restricting the number of tasks spawned 5. When designing an application, it's important to benchmark CachedThreadPool vs. ThreadPerTaskExecutor 6. The ratios compare Virtual Threads with Platform Threads - in one case, Platform Threads did better??? Will keep working to understand better... Cheers, Eric On Wed, Nov 10, 2021 at 12:16 PM Ignaz Birnstingl wrote: > Hi Eric, > > here are my thoughts: > > Creating platform threads is an expensive operation. Your benchmarks show > this very well. I would guess that starting a single platform thread > costs > somewhere between 10?s to 1ms. So spinning up platform threads that run > for ~30ms before terminating means that at most 30000 platform threads > would run in parallel. You could easily check that by using two > AtomicIntegers in your isPrime() method: One keeps a count of currently > running tasks. You increment it in the beginning of isPrime() and > decrement it in the end of isPrime(). The other one would hold the > maximum > of the first one after incrementation. I would guess that the maximum of > platform threads running in parallel is much lower than for virtual > threads. > > If you want to compare the throughput of the solutions it would probably > make sense to pass in the ExecutorService you want to use to your > futurePrimes22() method instead of creating it in there. > Then you could compare Executors.newCachedThreadPool() vs. > Executors.newFixedThreadPool() (with different numbers) and > Executors.newVirtualThreadExecutor(). > > Ignaz > From duke at openjdk.java.net Mon Nov 15 15:29:54 2021 From: duke at openjdk.java.net (duke) Date: Mon, 15 Nov 2021 15:29:54 GMT Subject: git: openjdk/loom: fibers: 2 new changesets Message-ID: Changeset: ded7211a Author: Alan Bateman Date: 2021-11-15 12:24:12 +0000 URL: https://git.openjdk.java.net/loom/commit/ded7211a709dee26586ef4e7cf84a5d50a2ec37f Rename prototype SC, still work in progress ! src/java.base/share/classes/java/lang/ScopeLocal.java ! src/java.base/share/classes/java/lang/StructureViolationException.java + src/java.base/share/classes/java/util/concurrent/StructuredExecutor.java - src/java.base/share/classes/java/util/concurrent/TaskSession.java + test/jdk/java/util/concurrent/StructuredExecutor/StructuredExecutorTest.java - test/jdk/java/util/concurrent/TaskSession/TaskSessionTest.java Changeset: ac7c95e5 Author: Alan Bateman Date: 2021-11-15 14:32:01 +0000 URL: https://git.openjdk.java.net/loom/commit/ac7c95e5db98a22fb2a3918cff450f9284617410 Change dumper to use instance methods ! src/java.base/share/classes/jdk/internal/vm/ThreadDumper.java From ron.pressler at oracle.com Mon Nov 15 20:21:45 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Mon, 15 Nov 2021 20:21:45 +0000 Subject: A new build and a new structured concurrency API Message-ID: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> Hi. We have just published a new Early Access build of Project Loom over on https://jdk.java.net/loom/ The build is based on jdk-18+22, and now requires the --enable-preview flag to use Loom features (when compiling, remember to also add `--release 18`). The main new feature in this build is a new API for structured concurrency, called StructuredExecutor. To learn more about its motivation, capabilities, and use, please read this JEP draft [1] and the Javadoc [2]. Pay special attention to the new methods added to Future, resultNow and exceptionNow [3], and how they complement StructuredExecutor. One of the most exciting capabilities of StructuredExecutor is the new structured thread-dump mentioned in the JEP draft. Another new feature is the ability to use virtual threads as Cleaner threads [4]. We have also published a draft JEP for virtual threads [5]. The JEPs, like the project, are still a work in progress. As always, we appreciate feedback on these features from those who try them. Please, download the new EA and tell us about your experience. -- Ron [1]: http://openjdk.java.net/jeps/8277129 [2]: https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredExecutor.html [3]: https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/Future.html [4]: https://download.java.net/java/early_access/loom/docs/api/java.base/java/lang/ref/Cleaner.html [5]: http://openjdk.java.net/jeps/8277131 From eric at kolotyluk.net Mon Nov 15 21:18:34 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Mon, 15 Nov 2021 13:18:34 -0800 Subject: A new build and a new structured concurrency API In-Reply-To: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> Message-ID: When I tried recompiling my project I get [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile) on project laboratory: Fatal error compiling: error: *invalid flag: --release 18* -> [Help 1] I downloaded the latest release openjdk-18-loom+5-274_windows-x64_bin.zip and installed it, but no luck, and I downloaded openjdk-18-ea+23_windows-x64_bin.zip, but no luck. $ "${JAVA_HOME}/bin/java" -version openjdk version "18-ea" 2022-03-15 OpenJDK Runtime Environment (build 18-ea+23-1525) OpenJDK 64-Bit Server VM (build 18-ea+23-1525, mixed mode, sharing) $ "${JAVA_HOME}/bin/java" -version openjdk version "18-loom" 2022-03-15 OpenJDK Runtime Environment (build 18-loom+5-274) OpenJDK 64-Bit Server VM (build 18-loom+5-274, mixed mode, sharing) org.apache.maven.plugins maven-compiler-plugin 3.8.1 --enable-preview --release 18 C:/Program Files (Open)/jdk-18/bin/javac 18 18 18 Is there some other JDK I need? Cheers, Eric On Mon, Nov 15, 2021 at 12:22 PM Ron Pressler wrote: > Hi. > > We have just published a new Early Access build of Project Loom over on > https://jdk.java.net/loom/ > > The build is based on jdk-18+22, and now requires the --enable-preview > flag to > use Loom features (when compiling, remember to also add `--release 18`). > > The main new feature in this build is a new API for structured concurrency, > called StructuredExecutor. To learn more about its motivation, > capabilities, > and use, please read this JEP draft [1] and the Javadoc [2]. Pay special > attention to the new methods added to Future, resultNow and exceptionNow > [3], and how they complement StructuredExecutor. One of the most exciting > capabilities of StructuredExecutor is the new structured thread-dump > mentioned > in the JEP draft. > > Another new feature is the ability to use virtual threads as Cleaner > threads > [4]. We have also published a draft JEP for virtual threads [5]. The JEPs, > like > the project, are still a work in progress. > > As always, we appreciate feedback on these features from those who try > them. > Please, download the new EA and tell us about your experience. > > -- Ron > > [1]: http://openjdk.java.net/jeps/8277129 > [2]: > https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredExecutor.html > [3]: > https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/Future.html > [4]: > https://download.java.net/java/early_access/loom/docs/api/java.base/java/lang/ref/Cleaner.html > [5]: http://openjdk.java.net/jeps/8277131 > > From forax at univ-mlv.fr Mon Nov 15 21:39:21 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 15 Nov 2021 22:39:21 +0100 (CET) Subject: A new build and a new structured concurrency API In-Reply-To: References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> Message-ID: <1563932421.748869.1637012361197.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "Eric Kolotyluk" > To: "Ron Pressler" > Cc: "loom-dev" > Sent: Lundi 15 Novembre 2021 22:18:34 > Subject: Re: A new build and a new structured concurrency API Hi Eric, > When I tried recompiling my project I get > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile > (default-compile) on project > laboratory: Fatal error compiling: error: *invalid flag: --release 18* -> > [Help 1] > > I downloaded the latest release openjdk-18-loom+5-274_windows-x64_bin.zip > and installed it, but no luck, and I downloaded > openjdk-18-ea+23_windows-x64_bin.zip, but no luck. > > $ "${JAVA_HOME}/bin/java" -version > openjdk version "18-ea" 2022-03-15 > OpenJDK Runtime Environment (build 18-ea+23-1525) > OpenJDK 64-Bit Server VM (build 18-ea+23-1525, mixed mode, sharing) > > $ "${JAVA_HOME}/bin/java" -version > openjdk version "18-loom" 2022-03-15 > OpenJDK Runtime Environment (build 18-loom+5-274) > OpenJDK 64-Bit Server VM (build 18-loom+5-274, mixed mode, sharing) > > > org.apache.maven.plugins > maven-compiler-plugin > 3.8.1 > > > --enable-preview > --release 18 > C:/Program Files (Open)/jdk-18/bin/javac > > 18 > 18 > 18 > > > > Is there some other JDK I need? I believe it's a Maven issue, release has its own tag in configuration, something like: 18 18 18 --enable-preview should work. > > Cheers, Eric regards, R?mi > > > > On Mon, Nov 15, 2021 at 12:22 PM Ron Pressler > wrote: > >> Hi. >> >> We have just published a new Early Access build of Project Loom over on >> https://jdk.java.net/loom/ >> >> The build is based on jdk-18+22, and now requires the --enable-preview >> flag to >> use Loom features (when compiling, remember to also add `--release 18`). >> >> The main new feature in this build is a new API for structured concurrency, >> called StructuredExecutor. To learn more about its motivation, >> capabilities, >> and use, please read this JEP draft [1] and the Javadoc [2]. Pay special >> attention to the new methods added to Future, resultNow and exceptionNow >> [3], and how they complement StructuredExecutor. One of the most exciting >> capabilities of StructuredExecutor is the new structured thread-dump >> mentioned >> in the JEP draft. >> >> Another new feature is the ability to use virtual threads as Cleaner >> threads >> [4]. We have also published a draft JEP for virtual threads [5]. The JEPs, >> like >> the project, are still a work in progress. >> >> As always, we appreciate feedback on these features from those who try >> them. >> Please, download the new EA and tell us about your experience. >> >> -- Ron >> >> [1]: http://openjdk.java.net/jeps/8277129 >> [2]: >> https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredExecutor.html >> [3]: >> https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/Future.html >> [4]: >> https://download.java.net/java/early_access/loom/docs/api/java.base/java/lang/ref/Cleaner.html >> [5]: http://openjdk.java.net/jeps/8277131 >> From mike.rettig at gmail.com Mon Nov 15 22:01:17 2021 From: mike.rettig at gmail.com (Mike Rettig) Date: Mon, 15 Nov 2021 16:01:17 -0600 Subject: A new build and a new structured concurrency API In-Reply-To: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> Message-ID: >From the JEP: "It is not a goal to propose a new task/thread cancellation mechanism to supersede the existing interruption mechanism. This might be addressed by a future JEP." I think the cancellation mechanism needs to be addressed first. The "correct" way to handle thread interrupts is already unclear in many cases. Requiring it to mean "cancel" when used with structured concurrency is going to be difficult for developers. The interrupt api lacks explicitness and usage is inconsistent. >From the current tutorial from Oracle : https://docs.oracle.com/javase/tutorial/essential/concurrency/interrupt.html "An *interrupt* is an indication to a thread that it should stop what it is doing and do something else. It's up to the programmer to decide exactly how a thread responds to an interrupt, but it is very common for the thread to terminate." I've tried to use interrupts for cancelling. Interrupt handling code is often buried in third party code. To use interrupts I had to find and verify that all the interrupts were handled "correctly". It gets even trickier when code paths reach points that should no longer be cancelled. Rather than using interrupts, it is usually a much better approach to create explicit api's that support cancels (e.g. cancel a long running network operation by closing the socket). Mike On Mon, Nov 15, 2021 at 2:22 PM Ron Pressler wrote: > Hi. > > We have just published a new Early Access build of Project Loom over on > https://jdk.java.net/loom/ > > The build is based on jdk-18+22, and now requires the --enable-preview > flag to > use Loom features (when compiling, remember to also add `--release 18`). > > The main new feature in this build is a new API for structured concurrency, > called StructuredExecutor. To learn more about its motivation, > capabilities, > and use, please read this JEP draft [1] and the Javadoc [2]. Pay special > attention to the new methods added to Future, resultNow and exceptionNow > [3], and how they complement StructuredExecutor. One of the most exciting > capabilities of StructuredExecutor is the new structured thread-dump > mentioned > in the JEP draft. > > Another new feature is the ability to use virtual threads as Cleaner > threads > [4]. We have also published a draft JEP for virtual threads [5]. The JEPs, > like > the project, are still a work in progress. > > As always, we appreciate feedback on these features from those who try > them. > Please, download the new EA and tell us about your experience. > > -- Ron > > [1]: http://openjdk.java.net/jeps/8277129 > [2]: > https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredExecutor.html > [3]: > https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/Future.html > [4]: > https://download.java.net/java/early_access/loom/docs/api/java.base/java/lang/ref/Cleaner.html > [5]: http://openjdk.java.net/jeps/8277131 > > From eric at kolotyluk.net Mon Nov 15 22:59:53 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Mon, 15 Nov 2021 14:59:53 -0800 Subject: A new build and a new structured concurrency API In-Reply-To: <0BD2810A-59B5-4D5D-B2E9-9F0609E0F8DA@hxcore.ol> References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <1563932421.748869.1637012361197.JavaMail.zimbra@u-pem.fr> <0BD2810A-59B5-4D5D-B2E9-9F0609E0F8DA@hxcore.ol> Message-ID: Okay, my next problem is that IntelliJ keeps complaining C:\Users\ERIC\Documents\git\loom-lab\laboratory\src\main\java\net\kolotyluk\loom\Experiment00.java:4:28 java: java.util.concurrent.StructuredExecutor is a preview API and is disabled by default. (use --enable-preview to enable preview APIs) But I can find no way to convince IntelliJ to move forward. I have checked both Setting and Project Structure, and put " --enable-preview " everywhere I can think of. Is anyone else using IntelliJ with Loom? Cheers, Eric On Mon, Nov 15, 2021 at 1:52 PM Eric Kolotyluk wrote: > Thanks R?mi, that helped... and it?s release > openjdk-18-loom+5-274_windows-x64_bin.zip that works. > > > > I must have found an old Maven example from somewhere. > > > > Cheers, Eric > > > > *From: *Remi Forax > *Sent: *November 15, 2021 1:39 PM > *To: *Eric Kolotyluk > *Cc: *Ron Pressler ; loom-dev > > *Subject: *Re: A new build and a new structured concurrency API > > > > > > > > ----- Original Message ----- > > > From: "Eric Kolotyluk" > > > To: "Ron Pressler" > > > Cc: "loom-dev" > > > Sent: Lundi 15 Novembre 2021 22:18:34 > > > Subject: Re: A new build and a new structured concurrency API > > > > Hi Eric, > > > > > > > When I tried recompiling my project I get > > > > > > [ERROR] Failed to execute goal > > > org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile > > > (default-compile) on project > > > laboratory: Fatal error compiling: error: *invalid flag: --release 18* -> > > > [Help 1] > > > > > > I downloaded the latest release openjdk-18-loom+5-274_windows-x64_bin.zip > > > and installed it, but no luck, and I downloaded > > > openjdk-18-ea+23_windows-x64_bin.zip, but no luck. > > > > > > $ "${JAVA_HOME}/bin/java" -version > > > openjdk version "18-ea" 2022-03-15 > > > OpenJDK Runtime Environment (build 18-ea+23-1525) > > > OpenJDK 64-Bit Server VM (build 18-ea+23-1525, mixed mode, sharing) > > > > > > $ "${JAVA_HOME}/bin/java" -version > > > openjdk version "18-loom" 2022-03-15 > > > OpenJDK Runtime Environment (build 18-loom+5-274) > > > OpenJDK 64-Bit Server VM (build 18-loom+5-274, mixed mode, sharing) > > > > > > > > > org.apache.maven.plugins > > > maven-compiler-plugin > > > 3.8.1 > > > > > > > > > --enable-preview > > > --release 18 > > > C:/Program Files > (Open)/jdk-18/bin/javac > > > > > > 18 > > > 18 > > > 18 > > > > > > > > > > > > Is there some other JDK I need? > > > > I believe it's a Maven issue, release has its own tag in configuration, > > something like: > > > > > > 18 > > 18 > > 18 > > --enable-preview > > > > > > should work. > > > > > > > > Cheers, Eric > > > > regards, > > R?mi > > > > > > > > > > > > > > On Mon, Nov 15, 2021 at 12:22 PM Ron Pressler > > > wrote: > > > > > >> Hi. > > >> > > >> We have just published a new Early Access build of Project Loom over on > > >> https://jdk.java.net/loom/ > > >> > > >> The build is based on jdk-18+22, and now requires the --enable-preview > > >> flag to > > >> use Loom features (when compiling, remember to also add `--release 18`). > > >> > > >> The main new feature in this build is a new API for structured > concurrency, > > >> called StructuredExecutor. To learn more about its motivation, > > >> capabilities, > > >> and use, please read this JEP draft [1] and the Javadoc [2]. Pay special > > >> attention to the new methods added to Future, resultNow and exceptionNow > > >> [3], and how they complement StructuredExecutor. One of the most > exciting > > >> capabilities of StructuredExecutor is the new structured thread-dump > > >> mentioned > > >> in the JEP draft. > > >> > > >> Another new feature is the ability to use virtual threads as Cleaner > > >> threads > > >> [4]. We have also published a draft JEP for virtual threads [5]. The > JEPs, > > >> like > > >> the project, are still a work in progress. > > >> > > >> As always, we appreciate feedback on these features from those who try > > >> them. > > >> Please, download the new EA and tell us about your experience. > > >> > > >> -- Ron > > >> > > >> [1]: http://openjdk.java.net/jeps/8277129 > > >> [2]: > > >> > https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredExecutor.html > > >> [3]: > > >> > https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/Future.html > > >> [4]: > > >> > https://download.java.net/java/early_access/loom/docs/api/java.base/java/lang/ref/Cleaner.html > > >> [5]: http://openjdk.java.net/jeps/8277131 > > >> > > > From ron.pressler at oracle.com Mon Nov 15 23:20:08 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Mon, 15 Nov 2021 23:20:08 +0000 Subject: [External] : Re: A new build and a new structured concurrency API In-Reply-To: References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> Message-ID: <52DBCC77-AE82-4EAB-A140-06D8E5921D03@oracle.com> > On 15 Nov 2021, at 22:01, Mike Rettig wrote: > > > I think the cancellation mechanism needs to be addressed first. The "correct" way to handle thread interrupts is already unclear in many cases. Requiring it to mean "cancel" when used with structured concurrency is going to be difficult for developers. > Cancellation is mentioned in the non-goals section of the JEP precisely because we acknowledge there?s a problem that will be addressed by *other* work. Interruption is the only cancellation mechanism we currently have in the JDK, and it is already supported by most blocking APIs. We believe that we?ll be able to offer an alternative that could be compatible with interruption (and, therefore, not require an API change here), but that alternative will be offered separately. For the moment, reporting on your experience with this JEP would be helpful. ? Ron From eric at kolotyluk.net Mon Nov 15 23:33:52 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Mon, 15 Nov 2021 15:33:52 -0800 Subject: [External] : Re: A new build and a new structured concurrency API In-Reply-To: <52DBCC77-AE82-4EAB-A140-06D8E5921D03@oracle.com> References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <52DBCC77-AE82-4EAB-A140-06D8E5921D03@oracle.com> Message-ID: Okay, I was able to trick IntelliJ into running my uber-jar, but still can just run code via normal methods... try (var executorService = StructuredExecutor.open("", Thread.ofVirtual().factory())) { IntStream.range(0, 15).forEach(item -> { System.out.println("item = " + item + ", Thread ID = " + Thread.currentThread()); executorService.fork(() -> { System.out.println("\ttask = " + item + ", Thread ID = " + Thread.currentThread()); return null; }); }); } Exception in thread "main" java.lang.IllegalStateException: Owner did not invoke join or joinUntil at java.base/java.util.concurrent.StructuredExecutor.close(StructuredExecutor.java:622) at net.kolotyluk.loom.Experiment00.main(Experiment00.java:28) So, what is the rationale behind explicitly requiring 'join' or 'joinUntil'? Why can't close() at the end of the try-block implicitly deal with that? Cheers, Eric From mike.rettig at gmail.com Tue Nov 16 00:33:27 2021 From: mike.rettig at gmail.com (Mike Rettig) Date: Mon, 15 Nov 2021 18:33:27 -0600 Subject: [External] : Re: A new build and a new structured concurrency API In-Reply-To: <52DBCC77-AE82-4EAB-A140-06D8E5921D03@oracle.com> References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <52DBCC77-AE82-4EAB-A140-06D8E5921D03@oracle.com> Message-ID: >> StructuredExecutor.open(String name, ThreadFactory factory) Does it require a thread per task? Why not create a new interface called TaskExecutor that could be backed by a virtual thread per task, a platform thread per task, or a thread pool? >>Task TaskExecutor.new Task(Runnable r) Task can be an interface that provides the basic start, join, and interrupt methods. Since it is a new interface it could add task specific methods like cancel. Mike On Mon, Nov 15, 2021 at 5:20 PM Ron Pressler wrote: > > > > On 15 Nov 2021, at 22:01, Mike Rettig wrote: > > > > > > I think the cancellation mechanism needs to be addressed first. The > "correct" way to handle thread interrupts is already unclear in many cases. > Requiring it to mean "cancel" when used with structured concurrency is > going to be difficult for developers. > > > > Cancellation is mentioned in the non-goals section of the JEP precisely > because we acknowledge there?s a problem > that will be addressed by *other* work. Interruption is the only > cancellation mechanism we currently have in the JDK, > and it is already supported by most blocking APIs. We believe that we?ll > be able to offer an alternative that could be > compatible with interruption (and, therefore, not require an API change > here), but that alternative will be offered > separately. For the moment, reporting on your experience with this JEP > would be helpful. > > ? Ron > > From ron.pressler at oracle.com Tue Nov 16 00:52:59 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Tue, 16 Nov 2021 00:52:59 +0000 Subject: [External] : Re: A new build and a new structured concurrency API In-Reply-To: References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <52DBCC77-AE82-4EAB-A140-06D8E5921D03@oracle.com> Message-ID: > On 15 Nov 2021, at 23:33, Eric Kolotyluk wrote: > > So, what is the rationale behind explicitly requiring 'join' or 'joinUntil'? Why can't close() at the end of the try-block implicitly deal with that? > > Cheers, Eric That?s a good question! The rational is to deal with a current limitation of AutoCloseable ? it cannot distinguish between the case where the try block terminates normally or exceptionally. This means that the implicit close would either have to cancel all tasks and then wait or just wait, regardless of whether an exception has been thrown. If we choose the former, there can be situations where a piece of code would just happen to work because the tasks happened to complete before close managed to cancel them, concealing a bug. If we chose the latter, an exception in the owner would result in all tasks still being waited for, which could also be confusing. Requiring an explicit join avoids these problems. If the language is changed to make AutoCloseable more flexible, this requirement might be removed. ? Ron From eric at kolotyluk.net Tue Nov 16 00:55:30 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Mon, 15 Nov 2021 16:55:30 -0800 Subject: [External] : Re: A new build and a new structured concurrency API In-Reply-To: References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <52DBCC77-AE82-4EAB-A140-06D8E5921D03@oracle.com> Message-ID: I wanted to comment on https://bugs.openjdk.java.net/browse/JDK-8277129 but I don't have login credentials. Looking at the JEP I am still trying to understand why close() throws an exception if join() has not been called. It's rather unsatisfying to just be told it must be called without some rationale. Intuitively, I feel that exiting a try-with-resources block should just take care of business, and should be part of Structured Concurrency. In the current implementation, it seems like the StructuredExecutor adds its own boundaries that don't play well with the try-with-resources pattern. Is this situation because canceling and exception handling have not been fully worked out? Cheers, Eric On Mon, Nov 15, 2021 at 3:33 PM Eric Kolotyluk wrote: > Okay, I was able to trick IntelliJ into running my uber-jar, but still can > just run code via normal methods... > > try (var executorService = StructuredExecutor.open("", Thread.ofVirtual().factory())) { > IntStream.range(0, 15).forEach(item -> { > System.out.println("item = " + item + ", Thread ID = " + Thread.currentThread()); > executorService.fork(() -> { > System.out.println("\ttask = " + item + ", Thread ID = " + Thread.currentThread()); > return null; > }); > }); > } > > Exception in thread "main" java.lang.IllegalStateException: Owner did not > invoke join or joinUntil > at > java.base/java.util.concurrent.StructuredExecutor.close(StructuredExecutor.java:622) > at net.kolotyluk.loom.Experiment00.main(Experiment00.java:28) > > So, what is the rationale behind explicitly requiring 'join' or > 'joinUntil'? Why can't close() at the end of the try-block implicitly deal > with that? > > Cheers, Eric > From eric at kolotyluk.net Tue Nov 16 00:58:03 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Mon, 15 Nov 2021 16:58:03 -0800 Subject: [External] : Re: A new build and a new structured concurrency API In-Reply-To: References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <52DBCC77-AE82-4EAB-A140-06D8E5921D03@oracle.com> Message-ID: Okay, that makes more sense and satisfies my suspicions. Thanks... For now, I can live with it, but this would be valuable insight to add to the JEP. Cheers, Eric On Mon, Nov 15, 2021 at 4:53 PM Ron Pressler wrote: > > > > On 15 Nov 2021, at 23:33, Eric Kolotyluk wrote: > > > > So, what is the rationale behind explicitly requiring 'join' or > 'joinUntil'? Why can't close() at the end of the try-block implicitly deal > with that? > > > > Cheers, Eric > > > That?s a good question! > The rational is to deal with a current limitation of AutoCloseable ? it > cannot distinguish between the case where the try block > terminates normally or exceptionally. This means that the implicit close > would either have to cancel all tasks and then wait or > just wait, regardless of whether an exception has been thrown. If we > choose the former, there can be situations where a piece > of code would just happen to work because the tasks happened to complete > before close managed to cancel them, concealing a bug. > If we chose the latter, an exception in the owner would result in all > tasks still being waited for, which could also be confusing. > > Requiring an explicit join avoids these problems. If the language is > changed to make AutoCloseable more flexible, this requirement > might be removed. > > ? Ron From ron.pressler at oracle.com Tue Nov 16 01:01:15 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Tue, 16 Nov 2021 01:01:15 +0000 Subject: [External] : Re: A new build and a new structured concurrency API In-Reply-To: References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <52DBCC77-AE82-4EAB-A140-06D8E5921D03@oracle.com> Message-ID: > On 16 Nov 2021, at 00:33, Mike Rettig wrote: > > > >> StructuredExecutor.open(String name, ThreadFactory factory) > > Does it require a thread per task? Why not create a new interface called TaskExecutor that could be backed by a virtual thread per task, a platform thread per task, or a thread pool? > The only difference between what you?re suggesting and what we have here is the thread pool. That?s an option that loses the goals described in the JEP of representation relationships among threads while gaining nothing. > > Task can be an interface that provides the basic start, join, and interrupt methods. Since it is a new interface it could add task specific methods like cancel. > This API does have a cancellation method called shutdown (there?s a reason why it isn?t named "cancel"). The issue with interruption isn?t how to trigger it, but how to respond to it, and it would have to work will all existing code that is already built around interruption. What would be helpful is if you could provide feedback on your experience with the proposed feature ? what you tried, what worked well, what didn?t ? rather than ask for a different one. ? Ron From ron.pressler at oracle.com Tue Nov 16 01:15:53 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Tue, 16 Nov 2021 01:15:53 +0000 Subject: [External] : Re: A new build and a new structured concurrency API In-Reply-To: References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <52DBCC77-AE82-4EAB-A140-06D8E5921D03@oracle.com> Message-ID: There are other reasons as well. In most situations, you?ll want to do things like handle exceptions and process results after the join. Requiring it in *all* cases is, therefore, not onerous and also serves as a reminder. I should point out that there are many possible designs here, and we opted for one that offers a balance between providing the benefits of structured concurrency ? clear cancellation and error handling policy, clear expression of the relationship among tasks ? and offering something that would be familiar to Java programmers. Some other designs ? like close doing more work ? or even using things other than TwR were clever and powerful, but were judged to be too foreign for inclusion in the JDK, and not the right tool to teach people about the principles of structured concurrency. We figured that requiring the call to join in all situations might be a small annoyance when writing such code for a day or so, but the resulting code would read more like code people already see. ? Ron > On 16 Nov 2021, at 00:58, Eric Kolotyluk wrote: > > Okay, that makes more sense and satisfies my suspicions. Thanks... > > For now, I can live with it, but this would be valuable insight to add to the JEP. > > Cheers, Eric > > On Mon, Nov 15, 2021 at 4:53 PM Ron Pressler wrote: > > > > On 15 Nov 2021, at 23:33, Eric Kolotyluk wrote: > > > > So, what is the rationale behind explicitly requiring 'join' or 'joinUntil'? Why can't close() at the end of the try-block implicitly deal with that? > > > > Cheers, Eric > > > That?s a good question! > The rational is to deal with a current limitation of AutoCloseable ? it cannot distinguish between the case where the try block > terminates normally or exceptionally. This means that the implicit close would either have to cancel all tasks and then wait or > just wait, regardless of whether an exception has been thrown. If we choose the former, there can be situations where a piece > of code would just happen to work because the tasks happened to complete before close managed to cancel them, concealing a bug. > If we chose the latter, an exception in the owner would result in all tasks still being waited for, which could also be confusing. > > Requiring an explicit join avoids these problems. If the language is changed to make AutoCloseable more flexible, this requirement > might be removed. > > ? Ron From chris.plummer at oracle.com Tue Nov 16 02:26:48 2021 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 15 Nov 2021 18:26:48 -0800 Subject: A new build and a new structured concurrency API In-Reply-To: References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <1563932421.748869.1637012361197.JavaMail.zimbra@u-pem.fr> <0BD2810A-59B5-4D5D-B2E9-9F0609E0F8DA@hxcore.ol> Message-ID: Under Settings -> Java Compiler, make sure you add --enable-preview to "Additional command line parameters". Under Project Structure -> Project Settings, make sure you choose "X - Experimental Features". Note my IntelliJ is a bit out of date. I assume at some point "18 (Preview) - Virtual Threads" will be made an option. Chris On 11/15/21 2:59 PM, Eric Kolotyluk wrote: > Okay, my next problem is that IntelliJ keeps complaining > > C:\Users\ERIC\Documents\git\loom-lab\laboratory\src\main\java\net\kolotyluk\loom\Experiment00.java:4:28 > java: java.util.concurrent.StructuredExecutor is a preview API and is > disabled by default. > (use --enable-preview to enable preview APIs) > > But I can find no way to convince IntelliJ to move forward. I have checked > both Setting and Project Structure, and put " --enable-preview " everywhere > I can think of. Is anyone else using IntelliJ with Loom? > > Cheers, Eric > > On Mon, Nov 15, 2021 at 1:52 PM Eric Kolotyluk wrote: > > From eric at kolotyluk.net Tue Nov 16 03:33:37 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Mon, 15 Nov 2021 19:33:37 -0800 Subject: [External] : RE: A new build and a new structured concurrency API In-Reply-To: <2d37aa0d-b9a6-3abe-0074-7c5cb08b7db0@oracle.com> References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <1563932421.748869.1637012361197.JavaMail.zimbra@u-pem.fr> <0BD2810A-59B5-4D5D-B2E9-9F0609E0F8DA@hxcore.ol> <96FC8B04-361F-4BDA-B1CD-319267D79BD8@hxcore.ol> <2d37aa0d-b9a6-3abe-0074-7c5cb08b7db0@oracle.com> Message-ID: I always run from IntelliJ because it's easier. [image: image.png] Normally I "Run" from the source tree, but IntelliJ seems broken now, so I reported it as a defect to JetBrains. In this case, laboratory.jar is an uber-jar created via the shade-plugin, and generated by clicking the "package" goal in the Maven Lifecycle tab on the right-hand side of the IntelliJ GUI. In this case, in the IntelliJ Run->Edit Configurations... I edited the configuration under JAR Application to put the "--enable-preview" in. It's not as convenient as running from the source tree, but I hate using the command line... When I try using "17 (Preview)"I get... java: invalid source release 17 with --enable-preview (preview language features are only supported for release 18) Cheers, Eric On Mon, Nov 15, 2021 at 6:52 PM Chris Plummer wrote: > How are you launching your app? I've never launched from Intellij. I only > use it to compile and then to attach to an already running program. When > launching you also need --enable-preview. If I haven't setup Intellij to do > that, I would never have noticed. Trying it now... Yep, similar problem to > yours, although for me I get an UnsupportedClassVersionErrror, and it says > "Preview features are not enabled for Main. Try running with > --enable-preview." > > I just found a work around. Instead of "X - Experimental Features", choose > "17 (Preview)". That seems to get --enabled-previewed added. I've been on > "X - Experimental Features" for 2 years now, because at one time it was > needed, but all the new APIs got "preview" tags recently, so it looks like > "17 (Preview)" works even though we are on 18. > > Chris > > On 11/15/21 6:37 PM, Eric Kolotyluk wrote: > > Yes, I did all those things before, but no luck. > > > > So far I used the shade-plugin to build an uber-jar, and on the JAR > Application run configuration I have added ?--enable-preview? to ?VM > options:? and that seems to work, but there is nothing I can do in the > Application run configuration to make it work. > > > > Seems like a defect in IntelliJ somehow... > > > > Cheers, Eric > > > > *From: *Chris Plummer > *Sent: *November 15, 2021 6:26 PM > *To: *Eric Kolotyluk ; Remi Forax ; > loom-dev ; Ron Pressler > > *Subject: *Re: A new build and a new structured concurrency API > > > > Under Settings -> Java Compiler, make sure you add --enable-preview to > > "Additional command line parameters". > > > > Under Project Structure -> Project Settings, make sure you choose "X - > > Experimental Features". Note my IntelliJ is a bit out of date. I assume > > at some point "18 (Preview) - Virtual Threads" will be made an option. > > > > Chris > > > > On 11/15/21 2:59 PM, Eric Kolotyluk wrote: > > > Okay, my next problem is that IntelliJ keeps complaining > > > > > > > C:\Users\ERIC\Documents\git\loom-lab\laboratory\src\main\java\net\kolotyluk\loom\Experiment00.java:4:28 > > > java: java.util.concurrent.StructuredExecutor is a preview API and is > > > disabled by default. > > > (use --enable-preview to enable preview APIs) > > > > > > But I can find no way to convince IntelliJ to move forward. I have > checked > > > both Setting and Project Structure, and put " --enable-preview " > everywhere > > > I can think of. Is anyone else using IntelliJ with Loom? > > > > > > Cheers, Eric > > > > > > On Mon, Nov 15, 2021 at 1:52 PM Eric Kolotyluk > wrote: > > > > > > > > > > > From eric at kolotyluk.net Tue Nov 16 04:10:51 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Mon, 15 Nov 2021 20:10:51 -0800 Subject: [External] : RE: A new build and a new structured concurrency API In-Reply-To: <92c45169-17ea-2596-898e-51abee0aaff5@oracle.com> References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <1563932421.748869.1637012361197.JavaMail.zimbra@u-pem.fr> <0BD2810A-59B5-4D5D-B2E9-9F0609E0F8DA@hxcore.ol> <96FC8B04-361F-4BDA-B1CD-319267D79BD8@hxcore.ol> <2d37aa0d-b9a6-3abe-0074-7c5cb08b7db0@oracle.com> <92c45169-17ea-2596-898e-51abee0aaff5@oracle.com> Message-ID: [image: image.png] [image: image.png] Hard to say if it's the version of IntelliJ, or trying to get all the right combination of Settings and Project Structure correct. Cheers, Eric On Mon, Nov 15, 2021 at 7:45 PM Chris Plummer wrote: > java: invalid source release 17 with --enable-preview > (preview language features are only supported for release 18) > > Yeah, I think my version is a bit old, and that may be working out to may > advantage right now. Max version it knows about is 17, but that doesn't > prevent me from setting the Project SDK to my JDK 18 build. What is the > latest version you can choose from "Project language level"? > > I will also point out that I very frequently (over the past 2 years) have > had java versioning related issues with Intellij when either the JDK moves > to a new version or I have upgraded Intellij. It's done weird things like > build against the default JDK libraries rather than the Project SDK. Often > I've had to clear out Intellij settings and start from scratch with a clean > install, and usually I have to use the beta version of Intellij. Right now > I'm on 2021.2 Beta built on July 13, 2021. > > Chris > > > On 11/15/21 7:33 PM, Eric Kolotyluk wrote: > > I always run from IntelliJ because it's easier. > [image: image.png] > > Normally I "Run" from the source tree, but IntelliJ seems broken now, so I > reported it as a defect to JetBrains. > > In this case, laboratory.jar is an uber-jar created via the shade-plugin, > and generated by clicking the "package" goal in the Maven Lifecycle tab on > the right-hand side of the IntelliJ GUI. In this case, in the IntelliJ > Run->Edit Configurations... I edited the configuration under JAR > Application to put the "--enable-preview" in. > > It's not as convenient as running from the source tree, but I hate using > the command line... > > When I try using "17 (Preview)"I get... > > java: invalid source release 17 with --enable-preview > (preview language features are only supported for release 18) > > Cheers, Eric > > > On Mon, Nov 15, 2021 at 6:52 PM Chris Plummer > wrote: > >> How are you launching your app? I've never launched from Intellij. I only >> use it to compile and then to attach to an already running program. When >> launching you also need --enable-preview. If I haven't setup Intellij to do >> that, I would never have noticed. Trying it now... Yep, similar problem to >> yours, although for me I get an UnsupportedClassVersionErrror, and it says >> "Preview features are not enabled for Main. Try running with >> --enable-preview." >> >> I just found a work around. Instead of "X - Experimental Features", >> choose "17 (Preview)". That seems to get --enabled-previewed added. I've >> been on "X - Experimental Features" for 2 years now, because at one time it >> was needed, but all the new APIs got "preview" tags recently, so it looks >> like "17 (Preview)" works even though we are on 18. >> >> Chris >> >> On 11/15/21 6:37 PM, Eric Kolotyluk wrote: >> >> Yes, I did all those things before, but no luck. >> >> >> >> So far I used the shade-plugin to build an uber-jar, and on the JAR >> Application run configuration I have added ?--enable-preview? to ?VM >> options:? and that seems to work, but there is nothing I can do in the >> Application run configuration to make it work. >> >> >> >> Seems like a defect in IntelliJ somehow... >> >> >> >> Cheers, Eric >> >> >> >> *From: *Chris Plummer >> *Sent: *November 15, 2021 6:26 PM >> *To: *Eric Kolotyluk ; Remi Forax ; >> loom-dev ; Ron Pressler >> >> *Subject: *Re: A new build and a new structured concurrency API >> >> >> >> Under Settings -> Java Compiler, make sure you add --enable-preview to >> >> "Additional command line parameters". >> >> >> >> Under Project Structure -> Project Settings, make sure you choose "X - >> >> Experimental Features". Note my IntelliJ is a bit out of date. I assume >> >> at some point "18 (Preview) - Virtual Threads" will be made an option. >> >> >> >> Chris >> >> >> >> On 11/15/21 2:59 PM, Eric Kolotyluk wrote: >> >> > Okay, my next problem is that IntelliJ keeps complaining >> >> > >> >> > >> C:\Users\ERIC\Documents\git\loom-lab\laboratory\src\main\java\net\kolotyluk\loom\Experiment00.java:4:28 >> >> > java: java.util.concurrent.StructuredExecutor is a preview API and is >> >> > disabled by default. >> >> > (use --enable-preview to enable preview APIs) >> >> > >> >> > But I can find no way to convince IntelliJ to move forward. I have >> checked >> >> > both Setting and Project Structure, and put " --enable-preview " >> everywhere >> >> > I can think of. Is anyone else using IntelliJ with Loom? >> >> > >> >> > Cheers, Eric >> >> > >> >> > On Mon, Nov 15, 2021 at 1:52 PM Eric Kolotyluk >> wrote: >> >> > >> >> > >> >> >> >> >> > From sormuras at gmail.com Tue Nov 16 04:49:39 2021 From: sormuras at gmail.com (Christian Stein) Date: Tue, 16 Nov 2021 05:49:39 +0100 Subject: [External] : RE: A new build and a new structured concurrency API In-Reply-To: References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <1563932421.748869.1637012361197.JavaMail.zimbra@u-pem.fr> <0BD2810A-59B5-4D5D-B2E9-9F0609E0F8DA@hxcore.ol> <96FC8B04-361F-4BDA-B1CD-319267D79BD8@hxcore.ol> <2d37aa0d-b9a6-3abe-0074-7c5cb08b7db0@oracle.com> <92c45169-17ea-2596-898e-51abee0aaff5@oracle.com> Message-ID: On Tue, Nov 16, 2021 at 5:11 AM Eric Kolotyluk wrote: > > Hard to say if it's the version of IntelliJ, or trying to get all the right > combination of Settings and Project Structure correct. > > Works for this IDEA-based project: https://github.com/sormuras/junit5-looming using IDEA 2021.3 Beta CE from last week. Here [0] are the changes I configured to enable preview features when compiling and running in addition to the update of the sole API change this project uses. Ron, Alan, I am fixing the build on GitHub at the moment in order to generate new numbers for the timings table... HTH, Christian [0]: https://github.com/sormuras/junit5-looming/commit/25054c25b966015dbd1e7ab4fac49e5063f75520 From forax at univ-mlv.fr Tue Nov 16 08:34:44 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 16 Nov 2021 09:34:44 +0100 (CET) Subject: A new build and a new structured concurrency API In-Reply-To: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> Message-ID: <1214048618.837344.1637051684264.JavaMail.zimbra@u-pem.fr> Hi Ron, I like the idea of StructuredExecutor + Handler but i think that given that each Handler (a completion policy?) has it's own semantics, the API should be twisted a bit. When we have, String result; try (var executor = StructuredExecutor.open()) { var handler = new ShutdownOnSuccess(); executor.fork(() -> fetch(left), handler); executor.fork(() -> fetch(right), handler); executor.join(); result = handler.result(e -> new WebApplicationException(e)); } I notice several points, - i don't like too much the fact that the handler is independent on the executor (not constructed with an executor) because it means that a user can create a handler store it in a static final and try to use it after. The lifercycle of the Handler should be coupled with the lifecycle on the executor. - depending on the Handler, the API we want is slightly different, by example for a ShutdownOnSuccess, it would be cool to also propagate the type of the exception but it does noyt make a lot of sense to do that in case of a ShutdownOnFailure. - join() and result() should be one method, again this is more true with a ShutdownOnSuccess than with a ShutdownOnFailure. So i think it's better to move the operations fork() and join() on the Handler so the API can be tweaked to be specific to the completion policy. By examples, for ShutdownOnSucess int value; try(var executor = StructuredExecutor.open()) { var shutdownOnSuccess = new ShutdownOnSuccess(executor); //shutdownOnSuccess.fork(() -> 3); shutdownOnSuccess.fork(() -> { throw new IOException(); }); value = shutdownOnSuccess.race(); } System.out.println(value); If we change fork() to take a functional interface like this public interface CallableWithException { V call() throws X; } So the method race(), which is join() + Handler.result() can be declared to throw X. for ShutdownOnFailure, we may keep the classical fork/join API given that we can access the values using the futures try(var executor = StructuredExecutor.open()) { var shutdownOnFailure = new ShutdownOnFailure(executor); var future1 = shutdownOnFailure.fork(() -> 3); var future2 = shutdownOnFailure.fork(() -> 4); shutdownOnFailure.join(); value = future1.get() + future2.get(); } System.out.println(value); regards, R?mi ----- Original Message ----- > From: "Ron Pressler" > To: "loom-dev" > Sent: Lundi 15 Novembre 2021 21:21:45 > Subject: A new build and a new structured concurrency API > Hi. > > We have just published a new Early Access build of Project Loom over on > https://jdk.java.net/loom/ > > The build is based on jdk-18+22, and now requires the --enable-preview flag to > use Loom features (when compiling, remember to also add `--release 18`). > > The main new feature in this build is a new API for structured concurrency, > called StructuredExecutor. To learn more about its motivation, capabilities, > and use, please read this JEP draft [1] and the Javadoc [2]. Pay special > attention to the new methods added to Future, resultNow and exceptionNow > [3], and how they complement StructuredExecutor. One of the most exciting > capabilities of StructuredExecutor is the new structured thread-dump mentioned > in the JEP draft. > > Another new feature is the ability to use virtual threads as Cleaner threads > [4]. We have also published a draft JEP for virtual threads [5]. The JEPs, like > the project, are still a work in progress. > > As always, we appreciate feedback on these features from those who try them. > Please, download the new EA and tell us about your experience. > > -- Ron > > [1]: http://openjdk.java.net/jeps/8277129 > [2]: > https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredExecutor.html > [3]: > https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/Future.html > [4]: > https://download.java.net/java/early_access/loom/docs/api/java.base/java/lang/ref/Cleaner.html > [5]: http://openjdk.java.net/jeps/8277131 From ron.pressler at oracle.com Tue Nov 16 11:28:01 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Tue, 16 Nov 2021 11:28:01 +0000 Subject: [External] : Re: A new build and a new structured concurrency API In-Reply-To: <1214048618.837344.1637051684264.JavaMail.zimbra@u-pem.fr> References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <1214048618.837344.1637051684264.JavaMail.zimbra@u-pem.fr> Message-ID: <516F9EF5-5B32-4D6C-92DA-2FC46D4DCE60@oracle.com> Hi R?mi! Let me first respond generally, and then specifically. Generally, what we realised when designing this API is that the design space for structured concurrency is large, and there is no one right way to do it. That is why the JEP draft says ?it is not a goal to provide a definitive structured concurrency API for Java.? StructuredExecutor is not meant to be *the* structured concurrency API, but *a* structured concurrency API. The plan, as you can tell from the draft, is to expose a lower-level API that would allow third-party libraries, or even the JDK at a later point, to add other SC constructs. We?ve played with various designs, including ones very similar to what you?re proposing (including generifying over exception types in fork) and even cleverer and/or more opinionated ones, but settled on something that is a compromise between SC power and familiarity and explicitness, with the intent of allowing external libraries to offer cleverer alternatives. The nice thing about SC is that its use is very local. You can use one construct in one method, and a different one in another. More specifically, you can bring your own policy handler that calls join, but I?d rather decide on whether or not we want to do that in this API, or regarding passing the executor in the constructor (and keep in mind that different forks in the same session might employ different policies) only after we get feedback on actual use. I think we?re at the point where we shouldn?t hypothesise about the relative value in alternatives, but rather get some feedback about real problems people encounter with what we have here first. ? Ron > On 16 Nov 2021, at 08:34, Remi Forax wrote: > > Hi Ron, > I like the idea of StructuredExecutor + Handler but i think that given that each Handler (a completion policy?) has it's own semantics, > the API should be twisted a bit. > > When we have, > String result; > try (var executor = StructuredExecutor.open()) { > var handler = new ShutdownOnSuccess(); > > executor.fork(() -> fetch(left), handler); > executor.fork(() -> fetch(right), handler); > > executor.join(); > > result = handler.result(e -> new WebApplicationException(e)); > } > > > I notice several points, > - i don't like too much the fact that the handler is independent on the executor (not constructed with an executor) because it means that a user can create a handler store it in a static final and try to use it after. The lifercycle of the Handler should be coupled with the lifecycle on the executor. > - depending on the Handler, the API we want is slightly different, by example for a ShutdownOnSuccess, it would be cool to also propagate the type of the exception but it does noyt make a lot of sense to do that in case of a ShutdownOnFailure. > - join() and result() should be one method, again this is more true with a ShutdownOnSuccess than with a ShutdownOnFailure. > > So i think it's better to move the operations fork() and join() on the Handler so the API can be tweaked to be specific to the completion policy. > > By examples, for ShutdownOnSucess > > int value; > try(var executor = StructuredExecutor.open()) { > var shutdownOnSuccess = new ShutdownOnSuccess(executor); > //shutdownOnSuccess.fork(() -> 3); > shutdownOnSuccess.fork(() -> { throw new IOException(); }); > value = shutdownOnSuccess.race(); > } > System.out.println(value); > > If we change fork() to take a functional interface like this > public interface CallableWithException { > V call() throws X; > } > > So the method race(), which is join() + Handler.result() can be declared to throw X. > > > for ShutdownOnFailure, we may keep the classical fork/join API given that we can access the values using the futures > > try(var executor = StructuredExecutor.open()) { > var shutdownOnFailure = new ShutdownOnFailure(executor); > var future1 = shutdownOnFailure.fork(() -> 3); > var future2 = shutdownOnFailure.fork(() -> 4); > shutdownOnFailure.join(); > value = future1.get() + future2.get(); > } > System.out.println(value); > > regards, > R?mi > > ----- Original Message ----- >> From: "Ron Pressler" >> To: "loom-dev" >> Sent: Lundi 15 Novembre 2021 21:21:45 >> Subject: A new build and a new structured concurrency API > >> Hi. >> >> We have just published a new Early Access build of Project Loom over on >> https://urldefense.com/v3/__https://jdk.java.net/loom/__;!!ACWV5N9M2RV99hQ!aO7oShDxIUNAf-o50JOJP2nRtzk8neuNPy4apg3wV_-5Jmy189ds_8sVUBMhByQ71w$ >> >> The build is based on jdk-18+22, and now requires the --enable-preview flag to >> use Loom features (when compiling, remember to also add `--release 18`). >> >> The main new feature in this build is a new API for structured concurrency, >> called StructuredExecutor. To learn more about its motivation, capabilities, >> and use, please read this JEP draft [1] and the Javadoc [2]. Pay special >> attention to the new methods added to Future, resultNow and exceptionNow >> [3], and how they complement StructuredExecutor. One of the most exciting >> capabilities of StructuredExecutor is the new structured thread-dump mentioned >> in the JEP draft. >> >> Another new feature is the ability to use virtual threads as Cleaner threads >> [4]. We have also published a draft JEP for virtual threads [5]. The JEPs, like >> the project, are still a work in progress. >> >> As always, we appreciate feedback on these features from those who try them. >> Please, download the new EA and tell us about your experience. >> >> -- Ron >> >> [1]: http://openjdk.java.net/jeps/8277129 >> [2]: >> https://urldefense.com/v3/__https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredExecutor.html__;!!ACWV5N9M2RV99hQ!aO7oShDxIUNAf-o50JOJP2nRtzk8neuNPy4apg3wV_-5Jmy189ds_8sVUBPEUQSvYg$ >> [3]: >> https://urldefense.com/v3/__https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/Future.html__;!!ACWV5N9M2RV99hQ!aO7oShDxIUNAf-o50JOJP2nRtzk8neuNPy4apg3wV_-5Jmy189ds_8sVUBNG3V2AMg$ >> [4]: >> https://urldefense.com/v3/__https://download.java.net/java/early_access/loom/docs/api/java.base/java/lang/ref/Cleaner.html__;!!ACWV5N9M2RV99hQ!aO7oShDxIUNAf-o50JOJP2nRtzk8neuNPy4apg3wV_-5Jmy189ds_8sVUBMQpeQZxg$ >> [5]: http://openjdk.java.net/jeps/8277131 From Alan.Bateman at oracle.com Tue Nov 16 11:36:38 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 16 Nov 2021 11:36:38 +0000 Subject: A new build and a new structured concurrency API In-Reply-To: References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> Message-ID: On 15/11/2021 22:01, Mike Rettig wrote: > : > > I've tried to use interrupts for cancelling. Interrupt handling code is > often buried in third party code. To use interrupts I had to find and > verify that all the interrupts were handled "correctly". It gets even > trickier when code paths reach points that should no longer be cancelled. > Rather than using interrupts, it is usually a much better approach to > create explicit api's that support cancels (e.g. cancel a long running > network operation by closing the socket). As Ron said, cancellation is an area that requires further exploration, it's not this JEP. Prototypes to date did introduce a set-once cancel status and a means to poll it. Also worked through the relationship between the two mechanism so that cancellation caused the thread to be interrupted, the equivalent of Future::cancel(true), and necessary to work with existing code that does cause blocking calls to wakeup. One of the main concerns is of course having two similar mechanisms in the API. That would have hard to explain to developers, esp. new developers, and one of the reasons why we have to be cautious. You mention cancelling network operations by closing the socket. That is the InterruptibleChannel semantics where interrupting a thread blocked on a channels causes the channel to be closed and an exception to be thrown. This has been extended to the legacy Socket APIs, more details on that are in the draft JEP for Virtual Threads. There will of course be libraries that do not respond to Thread interrupt but that wouldn't change with a new cancel mechanism. -Alan. From ron.pressler at oracle.com Tue Nov 16 12:20:37 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Tue, 16 Nov 2021 12:20:37 +0000 Subject: [External] : Re: A new build and a new structured concurrency API In-Reply-To: <516F9EF5-5B32-4D6C-92DA-2FC46D4DCE60@oracle.com> References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <1214048618.837344.1637051684264.JavaMail.zimbra@u-pem.fr> <516F9EF5-5B32-4D6C-92DA-2FC46D4DCE60@oracle.com> Message-ID: <8E58DD1B-BC22-473A-86F0-D1004BB09CAB@oracle.com> P.S. Another interesting thing you may notice is that if exceptions are handled centrally by the handler after joining (whether explicitly or implicitly), returning Future is overkill; a Supplier would suffice (that would throw, say, an IllegalStateException on get if there is no result). There, too, we?ve opted for familiarity (and, perhaps, being a little less opinionated), at least until we get further feedback. ? Ron > On 16 Nov 2021, at 11:28, Ron Pressler wrote: > > Hi R?mi! > > Let me first respond generally, and then specifically. > > Generally, what we realised when designing this API is that the design space for structured concurrency is large, and there is no one right way to do it. That is why the JEP draft says ?it is not a goal to provide a definitive structured concurrency API for Java.? StructuredExecutor is not meant to be *the* structured concurrency API, but *a* structured concurrency API. The plan, as you can tell from the draft, is to expose a lower-level API that would allow third-party libraries, or even the JDK at a later point, to add other SC constructs. We?ve played with various designs, including ones very similar to what you?re proposing (including generifying over exception types in fork) and even cleverer and/or more opinionated ones, but settled on something that is a compromise between SC power and familiarity and explicitness, with the intent of allowing external libraries to offer cleverer alternatives. The nice thing about SC is that its use is very local. You can use one construct in one method, and a different one in another. > > More specifically, you can bring your own policy handler that calls join, but I?d rather decide on whether or not we want to do that in this API, or regarding passing the executor in the constructor (and keep in mind that different forks in the same session might employ different policies) only after we get feedback on actual use. I think we?re at the point where we shouldn?t hypothesise about the relative value in alternatives, but rather get some feedback about real problems people encounter with what we have here first. > > ? Ron > > >> On 16 Nov 2021, at 08:34, Remi Forax wrote: >> >> Hi Ron, >> I like the idea of StructuredExecutor + Handler but i think that given that each Handler (a completion policy?) has it's own semantics, >> the API should be twisted a bit. >> >> When we have, >> String result; >> try (var executor = StructuredExecutor.open()) { >> var handler = new ShutdownOnSuccess(); >> >> executor.fork(() -> fetch(left), handler); >> executor.fork(() -> fetch(right), handler); >> >> executor.join(); >> >> result = handler.result(e -> new WebApplicationException(e)); >> } >> >> >> I notice several points, >> - i don't like too much the fact that the handler is independent on the executor (not constructed with an executor) because it means that a user can create a handler store it in a static final and try to use it after. The lifercycle of the Handler should be coupled with the lifecycle on the executor. >> - depending on the Handler, the API we want is slightly different, by example for a ShutdownOnSuccess, it would be cool to also propagate the type of the exception but it does noyt make a lot of sense to do that in case of a ShutdownOnFailure. >> - join() and result() should be one method, again this is more true with a ShutdownOnSuccess than with a ShutdownOnFailure. >> >> So i think it's better to move the operations fork() and join() on the Handler so the API can be tweaked to be specific to the completion policy. >> >> By examples, for ShutdownOnSucess >> >> int value; >> try(var executor = StructuredExecutor.open()) { >> var shutdownOnSuccess = new ShutdownOnSuccess(executor); >> //shutdownOnSuccess.fork(() -> 3); >> shutdownOnSuccess.fork(() -> { throw new IOException(); }); >> value = shutdownOnSuccess.race(); >> } >> System.out.println(value); >> >> If we change fork() to take a functional interface like this >> public interface CallableWithException { >> V call() throws X; >> } >> >> So the method race(), which is join() + Handler.result() can be declared to throw X. >> >> >> for ShutdownOnFailure, we may keep the classical fork/join API given that we can access the values using the futures >> >> try(var executor = StructuredExecutor.open()) { >> var shutdownOnFailure = new ShutdownOnFailure(executor); >> var future1 = shutdownOnFailure.fork(() -> 3); >> var future2 = shutdownOnFailure.fork(() -> 4); >> shutdownOnFailure.join(); >> value = future1.get() + future2.get(); >> } >> System.out.println(value); >> >> regards, >> R?mi >> >> ----- Original Message ----- >>> From: "Ron Pressler" >>> To: "loom-dev" >>> Sent: Lundi 15 Novembre 2021 21:21:45 >>> Subject: A new build and a new structured concurrency API >> >>> Hi. >>> >>> We have just published a new Early Access build of Project Loom over on >>> https://urldefense.com/v3/__https://jdk.java.net/loom/__;!!ACWV5N9M2RV99hQ!aO7oShDxIUNAf-o50JOJP2nRtzk8neuNPy4apg3wV_-5Jmy189ds_8sVUBMhByQ71w$ >>> >>> The build is based on jdk-18+22, and now requires the --enable-preview flag to >>> use Loom features (when compiling, remember to also add `--release 18`). >>> >>> The main new feature in this build is a new API for structured concurrency, >>> called StructuredExecutor. To learn more about its motivation, capabilities, >>> and use, please read this JEP draft [1] and the Javadoc [2]. Pay special >>> attention to the new methods added to Future, resultNow and exceptionNow >>> [3], and how they complement StructuredExecutor. One of the most exciting >>> capabilities of StructuredExecutor is the new structured thread-dump mentioned >>> in the JEP draft. >>> >>> Another new feature is the ability to use virtual threads as Cleaner threads >>> [4]. We have also published a draft JEP for virtual threads [5]. The JEPs, like >>> the project, are still a work in progress. >>> >>> As always, we appreciate feedback on these features from those who try them. >>> Please, download the new EA and tell us about your experience. >>> >>> -- Ron >>> >>> [1]: http://openjdk.java.net/jeps/8277129 >>> [2]: >>> https://urldefense.com/v3/__https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredExecutor.html__;!!ACWV5N9M2RV99hQ!aO7oShDxIUNAf-o50JOJP2nRtzk8neuNPy4apg3wV_-5Jmy189ds_8sVUBPEUQSvYg$ >>> [3]: >>> https://urldefense.com/v3/__https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/Future.html__;!!ACWV5N9M2RV99hQ!aO7oShDxIUNAf-o50JOJP2nRtzk8neuNPy4apg3wV_-5Jmy189ds_8sVUBNG3V2AMg$ >>> [4]: >>> https://urldefense.com/v3/__https://download.java.net/java/early_access/loom/docs/api/java.base/java/lang/ref/Cleaner.html__;!!ACWV5N9M2RV99hQ!aO7oShDxIUNAf-o50JOJP2nRtzk8neuNPy4apg3wV_-5Jmy189ds_8sVUBMQpeQZxg$ >>> [5]: http://openjdk.java.net/jeps/8277131 > From forax at univ-mlv.fr Tue Nov 16 13:51:33 2021 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Tue, 16 Nov 2021 14:51:33 +0100 (CET) Subject: [External] : Re: A new build and a new structured concurrency API In-Reply-To: <516F9EF5-5B32-4D6C-92DA-2FC46D4DCE60@oracle.com> References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <1214048618.837344.1637051684264.JavaMail.zimbra@u-pem.fr> <516F9EF5-5B32-4D6C-92DA-2FC46D4DCE60@oracle.com> Message-ID: <84131670.1210987.1637070693091.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "Ron Pressler" > To: "Remi Forax" > Cc: "loom-dev" > Sent: Mardi 16 Novembre 2021 12:28:01 > Subject: Re: [External] : Re: A new build and a new structured concurrency API > Hi R?mi! > > Let me first respond generally, and then specifically. > > Generally, what we realised when designing this API is that the design space for > structured concurrency is large, and there is no one right way to do it. That > is why the JEP draft says ?it is not a goal to provide a definitive structured > concurrency API for Java.? StructuredExecutor is not meant to be *the* > structured concurrency API, but *a* structured concurrency API. The plan, as > you can tell from the draft, is to expose a lower-level API that would allow > third-party libraries, or even the JDK at a later point, to add other SC > constructs. We?ve played with various designs, including ones very similar to > what you?re proposing (including generifying over exception types in fork) and > even cleverer and/or more opinionated ones, but settled on something that is a > compromise between SC power and familiarity and explicitness, with the intent > of allowing external libraries to offer cleverer alternatives. The nice thing > about SC is that its use is very local. You can use one construct in one > method, and a different one in another. > > More specifically, you can bring your own policy handler that calls join, but > I?d rather decide on whether or not we want to do that in this API, or > regarding passing the executor in the constructor (and keep in mind that > different forks in the same session might employ different policies) only after > we get feedback on actual use. I think we?re at the point where we shouldn?t > hypothesise about the relative value in alternatives, but rather get some > feedback about real problems people encounter with what we have here first. I've decided to focus on the high-level API first. I agree that separating the low-level API and allow anyone to create more high level APIs is a good design. For me the low-level API which is almost synonymous of StructuredExecutor. Do we agree that ShutdownOnSuccess/ShutdownOnFailure are examples of the kind of high level APIs that can be written ? I believe that passing the StructuredExecutor at construction helps to solve several issues. As i said, it ties a little more the lifecycle of the Handler policies to the lifecycle of the StructuredExecutor. It also allows to avoid to have a method accept() to be part of the public API (see below). There is also no problem to use several policies with each one taking the same StructuredExecutor. It's less flexible than the current API because you can share a policy handler between several different StructuredExecutors but i see that more as something bug prone than as a feature. Currently, the API is creates from two parts, StructuredExecutor.fork(Callable, BiConsumer) and BiConsumer.accept(StructuredExecutor, Future) For me, this handshake should be secret and not part of the public API given that - StructuredExecutor.fork(Callable, BiConsumer) should not be part of the public API because users should either use the variant without a BiConsumer or use the BiConsumer/Handler API which can be better tailored to the use case the policy handler want to solve - BiConsumer.accept(StructuredExecutor, Future) should not be part of the public API because users don't care at all about how this is implemented. By example with a SPI, that make StructuredExecutor.fork(Callable, BiConsumer) non visible in StructuredExecutor public class StructuredExecutorSPI { public static Future fork(StructuredExecutor executor, Callable callable, Consumer> completerConsumer) { return ... } } ShutdownOnSuccess can be written like this: public class ShutdownOnSuccess { private final StructuredExecutor executor; public ShutdownOnSuccess(StructuredExecutor executor) { this.executor = executor; } public Future fork(CallableWithException task) { return StructuredExecutorSPI.fork(executor, task::call, future -> { // do something with the executor and the future }); } ... } regards, R?mi > > ? Ron > > >> On 16 Nov 2021, at 08:34, Remi Forax wrote: >> >> Hi Ron, >> I like the idea of StructuredExecutor + Handler but i think that given that each >> Handler (a completion policy?) has it's own semantics, >> the API should be twisted a bit. >> >> When we have, >> String result; >> try (var executor = StructuredExecutor.open()) { >> var handler = new ShutdownOnSuccess(); >> >> executor.fork(() -> fetch(left), handler); >> executor.fork(() -> fetch(right), handler); >> >> executor.join(); >> >> result = handler.result(e -> new WebApplicationException(e)); >> } >> >> >> I notice several points, >> - i don't like too much the fact that the handler is independent on the executor >> (not constructed with an executor) because it means that a user can create a >> handler store it in a static final and try to use it after. The lifercycle of >> the Handler should be coupled with the lifecycle on the executor. >> - depending on the Handler, the API we want is slightly different, by example >> for a ShutdownOnSuccess, it would be cool to also propagate the type of the >> exception but it does noyt make a lot of sense to do that in case of a >> ShutdownOnFailure. >> - join() and result() should be one method, again this is more true with a >> ShutdownOnSuccess than with a ShutdownOnFailure. >> >> So i think it's better to move the operations fork() and join() on the Handler >> so the API can be tweaked to be specific to the completion policy. >> >> By examples, for ShutdownOnSucess >> >> int value; >> try(var executor = StructuredExecutor.open()) { >> var shutdownOnSuccess = new ShutdownOnSuccess(executor); >> //shutdownOnSuccess.fork(() -> 3); >> shutdownOnSuccess.fork(() -> { throw new IOException(); }); >> value = shutdownOnSuccess.race(); >> } >> System.out.println(value); >> >> If we change fork() to take a functional interface like this >> public interface CallableWithException { >> V call() throws X; >> } >> >> So the method race(), which is join() + Handler.result() can be declared to >> throw X. >> >> >> for ShutdownOnFailure, we may keep the classical fork/join API given that we can >> access the values using the futures >> >> try(var executor = StructuredExecutor.open()) { >> var shutdownOnFailure = new ShutdownOnFailure(executor); >> var future1 = shutdownOnFailure.fork(() -> 3); >> var future2 = shutdownOnFailure.fork(() -> 4); >> shutdownOnFailure.join(); >> value = future1.get() + future2.get(); >> } >> System.out.println(value); >> >> regards, >> R?mi >> >> ----- Original Message ----- >>> From: "Ron Pressler" >>> To: "loom-dev" >>> Sent: Lundi 15 Novembre 2021 21:21:45 >>> Subject: A new build and a new structured concurrency API >> >>> Hi. >>> >>> We have just published a new Early Access build of Project Loom over on >>> https://urldefense.com/v3/__https://jdk.java.net/loom/__;!!ACWV5N9M2RV99hQ!aO7oShDxIUNAf-o50JOJP2nRtzk8neuNPy4apg3wV_-5Jmy189ds_8sVUBMhByQ71w$ >>> >>> The build is based on jdk-18+22, and now requires the --enable-preview flag to >>> use Loom features (when compiling, remember to also add `--release 18`). >>> >>> The main new feature in this build is a new API for structured concurrency, >>> called StructuredExecutor. To learn more about its motivation, capabilities, >>> and use, please read this JEP draft [1] and the Javadoc [2]. Pay special >>> attention to the new methods added to Future, resultNow and exceptionNow >>> [3], and how they complement StructuredExecutor. One of the most exciting >>> capabilities of StructuredExecutor is the new structured thread-dump mentioned >>> in the JEP draft. >>> >>> Another new feature is the ability to use virtual threads as Cleaner threads >>> [4]. We have also published a draft JEP for virtual threads [5]. The JEPs, like >>> the project, are still a work in progress. >>> >>> As always, we appreciate feedback on these features from those who try them. >>> Please, download the new EA and tell us about your experience. >>> >>> -- Ron >>> >>> [1]: http://openjdk.java.net/jeps/8277129 >>> [2]: >>> https://urldefense.com/v3/__https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredExecutor.html__;!!ACWV5N9M2RV99hQ!aO7oShDxIUNAf-o50JOJP2nRtzk8neuNPy4apg3wV_-5Jmy189ds_8sVUBPEUQSvYg$ >>> [3]: >>> https://urldefense.com/v3/__https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/Future.html__;!!ACWV5N9M2RV99hQ!aO7oShDxIUNAf-o50JOJP2nRtzk8neuNPy4apg3wV_-5Jmy189ds_8sVUBNG3V2AMg$ >>> [4]: >>> https://urldefense.com/v3/__https://download.java.net/java/early_access/loom/docs/api/java.base/java/lang/ref/Cleaner.html__;!!ACWV5N9M2RV99hQ!aO7oShDxIUNAf-o50JOJP2nRtzk8neuNPy4apg3wV_-5Jmy189ds_8sVUBMQpeQZxg$ > >> [5]: http://openjdk.java.net/jeps/8277131 From duke at openjdk.java.net Tue Nov 16 14:20:40 2021 From: duke at openjdk.java.net (duke) Date: Tue, 16 Nov 2021 14:20:40 GMT Subject: git: openjdk/loom: fibers: Remove getContinuationScopeName from StackWalker Message-ID: <450a862f-cdce-4f08-b3d7-8ede9984f806@openjdk.java.net> Changeset: 29922075 Author: Ron Pressler Date: 2021-11-16 14:19:38 +0000 URL: https://git.openjdk.java.net/loom/commit/29922075b8fab820d7f2d200cf30c43b7e4e4cf9 Remove getContinuationScopeName from StackWalker ! src/java.base/share/classes/java/lang/StackFrameInfo.java ! src/java.base/share/classes/java/lang/StackWalker.java ! test/jdk/jdk/internal/vm/Continuation/java.base/java/lang/StackWalkerHelper.java From forax at univ-mlv.fr Tue Nov 16 14:21:45 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 16 Nov 2021 15:21:45 +0100 (CET) Subject: [External] : Re: A new build and a new structured concurrency API In-Reply-To: <84131670.1210987.1637070693091.JavaMail.zimbra@u-pem.fr> References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <1214048618.837344.1637051684264.JavaMail.zimbra@u-pem.fr> <516F9EF5-5B32-4D6C-92DA-2FC46D4DCE60@oracle.com> <84131670.1210987.1637070693091.JavaMail.zimbra@u-pem.fr> Message-ID: <638177387.1235804.1637072505957.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "Remi Forax" > To: "Ron Pressler" > Cc: "loom-dev" > Sent: Mardi 16 Novembre 2021 14:51:33 > Subject: Re: [External] : Re: A new build and a new structured concurrency API > ----- Original Message ----- >> From: "Ron Pressler" >> To: "Remi Forax" >> Cc: "loom-dev" >> Sent: Mardi 16 Novembre 2021 12:28:01 >> Subject: Re: [External] : Re: A new build and a new structured concurrency API > >> Hi R?mi! >> >> Let me first respond generally, and then specifically. >> >> Generally, what we realised when designing this API is that the design space for >> structured concurrency is large, and there is no one right way to do it. That >> is why the JEP draft says ?it is not a goal to provide a definitive structured >> concurrency API for Java.? StructuredExecutor is not meant to be *the* >> structured concurrency API, but *a* structured concurrency API. The plan, as >> you can tell from the draft, is to expose a lower-level API that would allow >> third-party libraries, or even the JDK at a later point, to add other SC >> constructs. We?ve played with various designs, including ones very similar to >> what you?re proposing (including generifying over exception types in fork) and >> even cleverer and/or more opinionated ones, but settled on something that is a >> compromise between SC power and familiarity and explicitness, with the intent >> of allowing external libraries to offer cleverer alternatives. The nice thing >> about SC is that its use is very local. You can use one construct in one >> method, and a different one in another. >> >> More specifically, you can bring your own policy handler that calls join, but >> I?d rather decide on whether or not we want to do that in this API, or >> regarding passing the executor in the constructor (and keep in mind that >> different forks in the same session might employ different policies) only after >> we get feedback on actual use. I think we?re at the point where we shouldn?t >> hypothesise about the relative value in alternatives, but rather get some >> feedback about real problems people encounter with what we have here first. > > I've decided to focus on the high-level API first. > I agree that separating the low-level API and allow anyone to create more high > level APIs is a good design. > For me the low-level API which is almost synonymous of StructuredExecutor. > > Do we agree that ShutdownOnSuccess/ShutdownOnFailure are examples of the kind of > high level APIs that can be written ? > > I believe that passing the StructuredExecutor at construction helps to solve > several issues. > As i said, it ties a little more the lifecycle of the Handler policies to the > lifecycle of the StructuredExecutor. > It also allows to avoid to have a method accept() to be part of the public API > (see below). > There is also no problem to use several policies with each one taking the same > StructuredExecutor. > It's less flexible than the current API because you can share a policy handler > between several different StructuredExecutors but i see that more as something > bug prone than as a feature. > > Currently, the API is creates from two parts, > StructuredExecutor.fork(Callable, BiConsumer) > and > BiConsumer.accept(StructuredExecutor, Future) > > For me, this handshake should be secret and not part of the public API given > that > - StructuredExecutor.fork(Callable, BiConsumer) should not be part of the public > API because users should either use the variant without a BiConsumer or use the > BiConsumer/Handler API which can be better tailored to the use case the policy > handler want to solve > - BiConsumer.accept(StructuredExecutor, Future) should not be part of the public > API because users don't care at all about how this is implemented. > > By example with a SPI, that make StructuredExecutor.fork(Callable, BiConsumer) > non visible in StructuredExecutor > public class StructuredExecutorSPI { > public static Future fork(StructuredExecutor executor, Callable V> callable, Consumer> completerConsumer) { > return ... > } > } > > > ShutdownOnSuccess can be written like this: > > public class ShutdownOnSuccess { > private final StructuredExecutor executor; > > public ShutdownOnSuccess(StructuredExecutor executor) { > this.executor = executor; > } > > public Future fork(CallableWithException task) { > return StructuredExecutorSPI.fork(executor, task::call, future -> { > // do something with the executor and the future > }); > } > > ... > } Thinking a little bit more, using a SPI is an overkill here, having a method fork inside StructuredExecutor that takes a Callable and a Consumer of Future is not that bad. > > regards, > R?mi > >> >> ? Ron R?mi >> >> >>> On 16 Nov 2021, at 08:34, Remi Forax wrote: >>> >>> Hi Ron, >>> I like the idea of StructuredExecutor + Handler but i think that given that each >>> Handler (a completion policy?) has it's own semantics, >>> the API should be twisted a bit. >>> >>> When we have, >>> String result; >>> try (var executor = StructuredExecutor.open()) { >>> var handler = new ShutdownOnSuccess(); >>> >>> executor.fork(() -> fetch(left), handler); >>> executor.fork(() -> fetch(right), handler); >>> >>> executor.join(); >>> >>> result = handler.result(e -> new WebApplicationException(e)); >>> } >>> >>> >>> I notice several points, >>> - i don't like too much the fact that the handler is independent on the executor >>> (not constructed with an executor) because it means that a user can create a >>> handler store it in a static final and try to use it after. The lifercycle of >>> the Handler should be coupled with the lifecycle on the executor. >>> - depending on the Handler, the API we want is slightly different, by example >>> for a ShutdownOnSuccess, it would be cool to also propagate the type of the >>> exception but it does noyt make a lot of sense to do that in case of a >>> ShutdownOnFailure. >>> - join() and result() should be one method, again this is more true with a >>> ShutdownOnSuccess than with a ShutdownOnFailure. >>> >>> So i think it's better to move the operations fork() and join() on the Handler >>> so the API can be tweaked to be specific to the completion policy. >>> >>> By examples, for ShutdownOnSucess >>> >>> int value; >>> try(var executor = StructuredExecutor.open()) { >>> var shutdownOnSuccess = new ShutdownOnSuccess(executor); >>> //shutdownOnSuccess.fork(() -> 3); >>> shutdownOnSuccess.fork(() -> { throw new IOException(); }); >>> value = shutdownOnSuccess.race(); >>> } >>> System.out.println(value); >>> >>> If we change fork() to take a functional interface like this >>> public interface CallableWithException { >>> V call() throws X; >>> } >>> >>> So the method race(), which is join() + Handler.result() can be declared to >>> throw X. >>> >>> >>> for ShutdownOnFailure, we may keep the classical fork/join API given that we can >>> access the values using the futures >>> >>> try(var executor = StructuredExecutor.open()) { >>> var shutdownOnFailure = new ShutdownOnFailure(executor); >>> var future1 = shutdownOnFailure.fork(() -> 3); >>> var future2 = shutdownOnFailure.fork(() -> 4); >>> shutdownOnFailure.join(); >>> value = future1.get() + future2.get(); >>> } >>> System.out.println(value); >>> >>> regards, >>> R?mi >>> >>> ----- Original Message ----- >>>> From: "Ron Pressler" >>>> To: "loom-dev" >>>> Sent: Lundi 15 Novembre 2021 21:21:45 >>>> Subject: A new build and a new structured concurrency API >>> >>>> Hi. >>>> >>>> We have just published a new Early Access build of Project Loom over on >>>> https://urldefense.com/v3/__https://jdk.java.net/loom/__;!!ACWV5N9M2RV99hQ!aO7oShDxIUNAf-o50JOJP2nRtzk8neuNPy4apg3wV_-5Jmy189ds_8sVUBMhByQ71w$ >>>> >>>> The build is based on jdk-18+22, and now requires the --enable-preview flag to >>>> use Loom features (when compiling, remember to also add `--release 18`). >>>> >>>> The main new feature in this build is a new API for structured concurrency, >>>> called StructuredExecutor. To learn more about its motivation, capabilities, >>>> and use, please read this JEP draft [1] and the Javadoc [2]. Pay special >>>> attention to the new methods added to Future, resultNow and exceptionNow >>>> [3], and how they complement StructuredExecutor. One of the most exciting >>>> capabilities of StructuredExecutor is the new structured thread-dump mentioned >>>> in the JEP draft. >>>> >>>> Another new feature is the ability to use virtual threads as Cleaner threads >>>> [4]. We have also published a draft JEP for virtual threads [5]. The JEPs, like >>>> the project, are still a work in progress. >>>> >>>> As always, we appreciate feedback on these features from those who try them. >>>> Please, download the new EA and tell us about your experience. >>>> >>>> -- Ron >>>> >>>> [1]: http://openjdk.java.net/jeps/8277129 >>>> [2]: >>>> https://urldefense.com/v3/__https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredExecutor.html__;!!ACWV5N9M2RV99hQ!aO7oShDxIUNAf-o50JOJP2nRtzk8neuNPy4apg3wV_-5Jmy189ds_8sVUBPEUQSvYg$ >>>> [3]: >>>> https://urldefense.com/v3/__https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/Future.html__;!!ACWV5N9M2RV99hQ!aO7oShDxIUNAf-o50JOJP2nRtzk8neuNPy4apg3wV_-5Jmy189ds_8sVUBNG3V2AMg$ >>>> [4]: >>>> https://urldefense.com/v3/__https://download.java.net/java/early_access/loom/docs/api/java.base/java/lang/ref/Cleaner.html__;!!ACWV5N9M2RV99hQ!aO7oShDxIUNAf-o50JOJP2nRtzk8neuNPy4apg3wV_-5Jmy189ds_8sVUBMQpeQZxg$ > > >> [5]: http://openjdk.java.net/jeps/8277131 From Alan.Bateman at oracle.com Tue Nov 16 14:26:13 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 16 Nov 2021 14:26:13 +0000 Subject: [External] : Re: A new build and a new structured concurrency API In-Reply-To: <84131670.1210987.1637070693091.JavaMail.zimbra@u-pem.fr> References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <1214048618.837344.1637051684264.JavaMail.zimbra@u-pem.fr> <516F9EF5-5B32-4D6C-92DA-2FC46D4DCE60@oracle.com> <84131670.1210987.1637070693091.JavaMail.zimbra@u-pem.fr> Message-ID: <6842bfd8-7dff-bb84-6026-cd270d7dd7da@oracle.com> On 16/11/2021 13:51, forax at univ-mlv.fr wrote: > : > I've decided to focus on the high-level API first. > I agree that separating the low-level API and allow anyone to create more high level APIs is a good design. > For me the low-level API which is almost synonymous of StructuredExecutor. > > Do we agree that ShutdownOnSuccess/ShutdownOnFailure are examples of the kind of high level APIs that can be written ? > > I believe that passing the StructuredExecutor at construction helps to solve several issues. > As i said, it ties a little more the lifecycle of the Handler policies to the lifecycle of the StructuredExecutor. > It also allows to avoid to have a method accept() to be part of the public API (see below). > There is also no problem to use several policies with each one taking the same StructuredExecutor. > It's less flexible than the current API because you can share a policy handler between several different StructuredExecutors but i see that more as something bug prone than as a feature. > > Currently, the API is creates from two parts, > StructuredExecutor.fork(Callable, BiConsumer) > and > BiConsumer.accept(StructuredExecutor, Future) > > For me, this handshake should be secret and not part of the public API given that > - StructuredExecutor.fork(Callable, BiConsumer) should not be part of the public API because users should either use the variant without a BiConsumer or use the BiConsumer/Handler API which can be better tailored to the use case the policy handler want to solve > - BiConsumer.accept(StructuredExecutor, Future) should not be part of the public API because users don't care at all about how this is implemented. > > By example with a SPI, that make StructuredExecutor.fork(Callable, BiConsumer) non visible in StructuredExecutor > public class StructuredExecutorSPI { > public static Future fork(StructuredExecutor executor, Callable callable, Consumer> completerConsumer) { > return ... > } > } > > > ShutdownOnSuccess can be written like this: > > public class ShutdownOnSuccess { > private final StructuredExecutor executor; > > public ShutdownOnSuccess(StructuredExecutor executor) { > this.executor = executor; > } > > public Future fork(CallableWithException task) { > return StructuredExecutorSPI.fork(executor, task::call, future -> { > // do something with the executor and the future > }); > } > > ... > } You've addressed a potential misuse but your sketch means that 4 classes define a fork method. We've been trying to keep it simple with the fork methods in one place. Where you need something other than ShutdownOnXXX then it's easy to implement a BiConsumer without needing to introduce another interface/class for implementations. I've no doubt that the API will go through several iterations. I think we need to some usage before doing another iteration. -Alan. From kasperni at gmail.com Tue Nov 16 14:33:58 2021 From: kasperni at gmail.com (Kasper Nielsen) Date: Tue, 16 Nov 2021 14:33:58 +0000 Subject: [External] : Re: A new build and a new structured concurrency API In-Reply-To: References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <52DBCC77-AE82-4EAB-A140-06D8E5921D03@oracle.com> Message-ID: > > > If the language is changed to make AutoCloseable more flexible, this > requirement > might be removed. > > ? Ron Adding something like default close(Throwable cause) { close(); } to AutoClosable would also be beneficial for people working with databases. Right now a lot of transactional code looks like this: try (Transaction transaction = Transaction.start()) { ... do transactional work transaction.commit(); } catch (Throwable e) { transaction.rollback(); } Which could be reduced to try (Transaction transaction = Transaction.start()) { ... do transactional work } If the Transaction instance could be notified that it was closed exceptionally. /Kasper From ron.pressler at oracle.com Tue Nov 16 15:00:40 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Tue, 16 Nov 2021 15:00:40 +0000 Subject: [External] : Re: A new build and a new structured concurrency API In-Reply-To: References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <52DBCC77-AE82-4EAB-A140-06D8E5921D03@oracle.com> Message-ID: Absolutely, we just didn?t want to tie this feature to language changes. But I would hope to see this and possibly other improvements to try-with-resources. ? Ron On 16 Nov 2021, at 14:33, Kasper Nielsen > wrote: If the language is changed to make AutoCloseable more flexible, this requirement might be removed. ? Ron Adding something like default close(Throwable cause) { close(); } to AutoClosable would also be beneficial for people working with databases. Right now a lot of transactional code looks like this: try (Transaction transaction = Transaction.start()) { ... do transactional work transaction.commit(); } catch (Throwable e) { transaction.rollback(); } Which could be reduced to try (Transaction transaction = Transaction.start()) { ... do transactional work } If the Transaction instance could be notified that it was closed exceptionally. /Kasper From forax at univ-mlv.fr Tue Nov 16 15:10:38 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 16 Nov 2021 15:10:38 +0000 Subject: [External] : Re: A new build and a new structured concurrency API In-Reply-To: <6842bfd8-7dff-bb84-6026-cd270d7dd7da@oracle.com> References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <1214048618.837344.1637051684264.JavaMail.zimbra@u-pem.fr> <516F9EF5-5B32-4D6C-92DA-2FC46D4DCE60@oracle.com> <84131670.1210987.1637070693091.JavaMail.zimbra@u-pem.fr> <6842bfd8-7dff-bb84-6026-cd270d7dd7da@oracle.com> Message-ID: On November 16, 2021 2:26:13 PM UTC, Alan Bateman wrote: >On 16/11/2021 13:51, forax at univ-mlv.fr wrote: >> : >> I've decided to focus on the high-level API first. >> I agree that separating the low-level API and allow anyone to create more high level APIs is a good design. >> For me the low-level API which is almost synonymous of StructuredExecutor. >> >> Do we agree that ShutdownOnSuccess/ShutdownOnFailure are examples of the kind of high level APIs that can be written ? >> >> I believe that passing the StructuredExecutor at construction helps to solve several issues. >> As i said, it ties a little more the lifecycle of the Handler policies to the lifecycle of the StructuredExecutor. >> It also allows to avoid to have a method accept() to be part of the public API (see below). >> There is also no problem to use several policies with each one taking the same StructuredExecutor. >> It's less flexible than the current API because you can share a policy handler between several different StructuredExecutors but i see that more as something bug prone than as a feature. >> >> Currently, the API is creates from two parts, >> StructuredExecutor.fork(Callable, BiConsumer) >> and >> BiConsumer.accept(StructuredExecutor, Future) >> >> For me, this handshake should be secret and not part of the public API given that >> - StructuredExecutor.fork(Callable, BiConsumer) should not be part of the public API because users should either use the variant without a BiConsumer or use the BiConsumer/Handler API which can be better tailored to the use case the policy handler want to solve >> - BiConsumer.accept(StructuredExecutor, Future) should not be part of the public API because users don't care at all about how this is implemented. >> >> By example with a SPI, that make StructuredExecutor.fork(Callable, BiConsumer) non visible in StructuredExecutor >> public class StructuredExecutorSPI { >> public static Future fork(StructuredExecutor executor, Callable callable, Consumer> completerConsumer) { >> return ... >> } >> } >> >> >> ShutdownOnSuccess can be written like this: >> >> public class ShutdownOnSuccess { >> private final StructuredExecutor executor; >> >> public ShutdownOnSuccess(StructuredExecutor executor) { >> this.executor = executor; >> } >> >> public Future fork(CallableWithException task) { >> return StructuredExecutorSPI.fork(executor, task::call, future -> { >> // do something with the executor and the future >> }); >> } >> >> ... >> } >You've addressed a potential misuse but your sketch means that 4 classes >define a fork method. We've been trying to keep it simple with the fork >methods in one place. Where you need something other than ShutdownOnXXX >then it's easy to implement a BiConsumer without needing to introduce >another interface/class for implementations. > >I've no doubt that the API will go through several iterations. I think >we need to some usage before doing another iteration. as I said, the SPI is too much. But do you agree that the method accept in ShutdownOn* should be hidden / not part of the public API ? > >-Alan. Remi > > > > > > > -- Envoy? de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma bri?vet?. From ron.pressler at oracle.com Tue Nov 16 15:29:16 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Tue, 16 Nov 2021 15:29:16 +0000 Subject: [External] : Re: A new build and a new structured concurrency API In-Reply-To: References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <1214048618.837344.1637051684264.JavaMail.zimbra@u-pem.fr> <516F9EF5-5B32-4D6C-92DA-2FC46D4DCE60@oracle.com> <84131670.1210987.1637070693091.JavaMail.zimbra@u-pem.fr> <6842bfd8-7dff-bb84-6026-cd270d7dd7da@oracle.com> Message-ID: On 16 Nov 2021, at 15:10, Remi Forax > wrote: But do you agree that the method accept in ShutdownOn* should be hidden / not part of the public API ? I certainly see the aesthetic appeal, but it?s hard for me to see how much added complexity this is worth without more feedback on use. From eric at kolotyluk.net Tue Nov 16 16:39:39 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Tue, 16 Nov 2021 08:39:39 -0800 Subject: Reflections on Structured Concurrency Message-ID: Just thinking out loud here... When I first started playing with Project Loom, I was under the impression that Structured Concurrency was already well defined, but now I am learning differently. I had just assumed that try-with-resources was enough to implement it, but now I appreciate things are not so simple. For example, I wrongly assumed that exception handling would "just work," but thinking about why we need to call join() before calling close(), I now appreciate the exception handling issues better. I now have more insight into the limitations of Java try-catch-finally... Before try-with-resources, it really ticked me off having to catch I/O Exceptions in the finally-block... Years ago when I started using Akka/Scala, there was an emerging pattern for Structure Concurrency, and today we have Part 1: Actor Architecture which structurally looks very much like what Project Loom is proposing. Now Akka Actors are very different from Virtual Threads, indeed I hope they are refactored someday to use Virtual Threads, but the goal of "goto-less" structure is similar to what I read in Structured Concurrency JEP . The "goto" story in the JEP is really a great metaphor. In the early days of Akka, there was some astonishing Actor Spaghetti Code that made it hard to reason clearly, and even today I have a hard time wrapping my head around Akka's best practices in the Actor Hierarchy. It was very clarifying when Ron said, *"Generally, what we realized when designing this API is that the design space for structured concurrency is large, and there is no one right way to do it."* My sense is eventually there will emerge some better designs, but we're just not there yet, so it's exciting to see how people reason about this... As a developer, I don't want to have to think too much, I want things to be as intuitive as possible, and I want the default to be that the design is as safe as possible. I appreciate designs that protect me from my own stupidity. Rather, I appreciate designs that let me save my intelligence for unique problems by dealing well with boilerplate problems. As an architect and designer, I know how things are rarely as simple as people want them to be. While I have done a lot of Reactive Design and Implementation via Akka/Scala, I am tired of writing and reading code where the intent is obscured by a non-blocking, functional style... especially the constant "non-blocking" anxiety worrying about things that can be latent and subtle. Being able to write and read better code that focuses on the intent of the solution is the main appeal that Project Loom has for me. Years ago I played around with Delimited Continuations in Scala when it became popular. It seriously hurt my brain. So, I will continue to play around in my loom-lab project, trying to catch up with my understanding of Project Loom, trying to learn the new opportunities to use it. Cheers, Eric From mike.rettig at gmail.com Tue Nov 16 17:20:16 2021 From: mike.rettig at gmail.com (Mike Rettig) Date: Tue, 16 Nov 2021 11:20:16 -0600 Subject: [External] : Re: A new build and a new structured concurrency API In-Reply-To: References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <52DBCC77-AE82-4EAB-A140-06D8E5921D03@oracle.com> Message-ID: The full interface I would like to see would look more like this: interface TaskExecutor{ Task newVoidTask(T t); //TODO add tasks that return values... } This allows developers to define their own domain specific tasks and decide how the tasks execute asynchronously. The runtime can coordinate the tasks and provide visibility to the tooling. Type safety can be enforced and domain specific methods can be added for complex task coordination. Providing a type safe, pluggable api would open up a whole new world of possibilities. An api based on Runnable, Callback, and the thread api is a great default implementation, but is too limiting for complex scenarios. Mike On Mon, Nov 15, 2021 at 6:33 PM Mike Rettig wrote: > > >> StructuredExecutor.open(String > > name, ThreadFactory > > factory) > > Does it require a thread per task? Why not create a new interface called > TaskExecutor that could be backed by a virtual thread per task, a platform > thread per task, or a thread pool? > > >>Task TaskExecutor.new > > Task(Runnable > > r) > > Task can be an interface that provides the basic start, join, and > interrupt methods. Since it is a new interface it could add task specific > methods like cancel. > > > Mike > > > On Mon, Nov 15, 2021 at 5:20 PM Ron Pressler > wrote: > >> >> >> > On 15 Nov 2021, at 22:01, Mike Rettig wrote: >> > >> > >> > I think the cancellation mechanism needs to be addressed first. The >> "correct" way to handle thread interrupts is already unclear in many cases. >> Requiring it to mean "cancel" when used with structured concurrency is >> going to be difficult for developers. >> > >> >> Cancellation is mentioned in the non-goals section of the JEP precisely >> because we acknowledge there?s a problem >> that will be addressed by *other* work. Interruption is the only >> cancellation mechanism we currently have in the JDK, >> and it is already supported by most blocking APIs. We believe that we?ll >> be able to offer an alternative that could be >> compatible with interruption (and, therefore, not require an API change >> here), but that alternative will be offered >> separately. For the moment, reporting on your experience with this JEP >> would be helpful. >> >> ? Ron >> >> From brian.goetz at oracle.com Tue Nov 16 18:01:57 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 16 Nov 2021 13:01:57 -0500 Subject: Reflections on Structured Concurrency In-Reply-To: References: Message-ID: Indeed, this was very much on our mind in designing StructuredExecutor.? It is not the ultimate answer for structured concurrency -- since we (and other language communities) are still searching for that -- but it is a practical on-ramp, which encourages you towards safe idioms and away from unsafe ones. Structured concurrency allows you to get to global properties of a computation from the sum of local properties.? If a structured computation spawns another structured computation, we can derive safety and lifetime properties for the whole thing by looking only at the relationship between a parent and its immediate children.? StructuredExecutor hopefully makes it easier for each layer of the computation to follow the rules. On 11/16/2021 11:39 AM, Eric Kolotyluk wrote: > As a developer, I don't want to have to think too much, I want things to be > as intuitive as possible, and I want the default to be that the design is > as safe as possible. I appreciate designs that protect me from my own > stupidity. Rather, I appreciate designs that let me save my intelligence > for unique problems by dealing well with boilerplate problems. As an > architect and designer, I know how things are rarely as simple as people > want them to be. From eric at kolotyluk.net Tue Nov 16 20:08:12 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Tue, 16 Nov 2021 12:08:12 -0800 Subject: =?UTF-8?Q?Some_=27il=2Dloom=2Dinating=27_Humor_from_a_Family_Perspecti?= =?UTF-8?Q?ve_=F0=9F=98=89?= Message-ID: I apologize if my humor might offend some people, but it's really just a humorous metaphor I could not resist sharing... With StructuredExecutor, the Thread that it is created on, and the session opened, well these are like the parents of all the sibling tasks that are spawned with fork(). I started coming up with a metaphor for join() and close(), but frankly, the more I explored it, the more depressing it seemed. Maybe join() is like coming together for family dinner, and close() is just like saying goodnight... not a perfect metaphor, but a more pleasant one. I was just trying to see the 'parallels' in concurrent programming (pun intended). Cheers, Eric From ron.pressler at oracle.com Tue Nov 16 23:05:57 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Tue, 16 Nov 2021 23:05:57 +0000 Subject: A new build and a new structured concurrency API In-Reply-To: References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <52DBCC77-AE82-4EAB-A140-06D8E5921D03@oracle.com> Message-ID: <9EA969E9-07A0-4672-B877-2334457D319B@oracle.com> > On 16 Nov 2021, at 17:20, Mike Rettig wrote: > > The full interface I would like to see would look more like this: > > interface TaskExecutor{ > Task newVoidTask(T t); > //TODO add tasks that return values... > } > > This allows developers to define their own domain specific tasks and decide how the tasks execute asynchronously. The runtime can coordinate the tasks and provide visibility to the tooling. Type safety can be enforced and domain specific methods can be added for complex task coordination. > > Providing a type safe, pluggable api would open up a whole new world of possibilities. An api based on Runnable, Callback, and the thread api is a great default implementation, but is too limiting for complex scenarios. > > Mike I fail to understand what this has to do with the structured concurrency JEP on the one hand, and why is it not exactly what the ExecutorService interface is. What problem are you trying to solve? What is the complex scenario that you?d like help with? ? Ron From eric at kolotyluk.net Tue Nov 16 23:05:50 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Tue, 16 Nov 2021 15:05:50 -0800 Subject: Forking Aesthetics Message-ID: This may seem picky, but right now I have something like var completionHandler = new StructuredExecutor.ShutdownOnFailure(); IntStream.range(0, 15).forEach(item -> { System.out.printf("item = %d, Thread ID = %s\n", item, Thread.currentThread()); executorService.fork(() -> { System.out.printf("\ttask = %d, Thread ID = %s\n", item, Thread.currentThread()); return null; }, completionHandler); but I don't like having to tack-on completionHandler as the second argument to fork()... I don't like the aesthetics because I would rather things just end with the inline Callable, aka Lambda. I would rather that the task (i.e. Callable) always be the last argument for aesthetic and readability reasons. I can imagine many other designs, but will not suggest any unless asked because I don't understand the gestalt of the team's design principles yet. Cheers, Eric From ron.pressler at oracle.com Tue Nov 16 23:18:48 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Tue, 16 Nov 2021 23:18:48 +0000 Subject: Forking Aesthetics In-Reply-To: References: Message-ID: <3CE52D4D-7AC5-455C-91FC-1D066FC7FF84@oracle.com> > On 16 Nov 2021, at 23:05, Eric Kolotyluk wrote: > > but I don't like having to tack-on completionHandler as the second argument > to fork()... I don't like the aesthetics because I would rather things just > end with the inline Callable, aka Lambda. Thank you! That?s good feedback and we?ll take it into consideration. ? Ron From dreamlike.vertx at gmail.com Wed Nov 17 11:13:15 2021 From: dreamlike.vertx at gmail.com (dreamlike_ocean lei) Date: Wed, 17 Nov 2021 19:13:15 +0800 Subject: loom ea based jdk18 feedback Message-ID: 1, continuation api If the low-level continuation api can be exposed, then in reactive programming, asynchronous operations can be simplified like this val scope = ContinuationScope("vertx") fun launch(runnable: Runnable){ Continuation(scope){ runnable.run() }.run() } fun Future.getAwait():T{ val c = Continuation.getCurrentContinuation(scope)?: throw IllegalStateException() onComplete { c.run() } Continuation.yield(scope) if (succeeded()){ return result() }else{ throw cause() } } In fact, this code works very well on the loom ea built on jdk17 But on the loom ea built on jdk18, due to the migration of this api from java.lang to jdk.internal.vm, I cannot access this api, and this code cannot improve the asynchronous operation well. Loom Proposal.md (java.net) mentioned "The motivation for adding continuations to the Java platform is for the implementation of fibers, but continuations have some other interesting uses, and so it is a secondary goal of this project to provide continuations as a public API" I really hope I can directly access this api in the future version 1. Virtual thread custom scheduler The loom ea built on jdk17 allows the scheduler of the virtual thread to be specified in this way, which can help us bridge the world of nio and bio in the netty-based reactive framework Thread.ofVirtual().scheduler(eventloop()).start() However, the loom ea built on jdk18 removed this api, which resulted in me having to use the default scheduler (fork/join pool) to schedule, and then submit it to the evenltoop task queue. This is an avoidable cross Thread overhead. I hope you can consider reopening the api of the custom scheduler in the future version translated by Google translate From ron.pressler at oracle.com Wed Nov 17 15:38:17 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Wed, 17 Nov 2021 15:38:17 +0000 Subject: loom ea based jdk18 feedback In-Reply-To: References: Message-ID: > On 17 Nov 2021, at 11:13, dreamlike_ocean lei wrote: > > 1, continuation api > > > I really hope I can directly access this api in the future version The Continuation class is fundamentally unsafe, and using it might result in miscompilation, as the JIT compiler bases some optimisations on the assumption that the current thread cannot change. So there is currently no way of exposing this particular class (which is mostly of interest for research). However, in the future, the JDK could conceivably add safe abstractions built on top of Continuation other than virtual threads, that would probably be confined to a single thread. Custom schedulers will be able to give you what I believe you want. > > Virtual thread custom scheduler > > > I hope you can consider reopening the api of the custom scheduler in the > future version That is an API we would very much like to have, but we haven?t had time to review yet. I don?t know yet whether or not it will make it in time for the first release. Note that this is a very specialised API for internal, sophisticated, use by frameworks, only, and should rarely if ever be used by user code. Naturally, we prioritise the user-facing APIs. ? Ron From eric at kolotyluk.net Wed Nov 17 15:47:27 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Wed, 17 Nov 2021 07:47:27 -0800 Subject: Fwd: [YouTrack, Commented] Issue IDEA-282632: Application Run Configuration does not respect "--enable-preview" VM Option with JDK-18 In-Reply-To: <0102017d2d19fc81-a8fce351-a239-474d-a1ea-cab0b76d7d88-000000@eu-west-1.amazonses.com> References: <0102017d2d19fc81-a8fce351-a239-474d-a1ea-cab0b76d7d88-000000@eu-west-1.amazonses.com> Message-ID: So, I will have to wait until later for JetBrains to address this... In the meantime, I am not blocked, just inconvenienced. The workaround is 1. mvn package - This seems to bypass the IntelliJ build so I don't get the compile error 2. Invoke Run from Project Explorer - target/laboratory.jar - as built using the maven shade plugin Anyway, requiring "--enable-preview" at this point in Project Loom has caused some minor inconvenience with IntelliJ IDEA. In particular, when I want to test different classes, I have to edit the pom.xml to change the . The problem did not actually happen on the Application Run Configuration, it happens on the IntelliJ Java Compiler Settings. Cheers, Eric ---------- Forwarded message --------- From: Olga Klisho Date: Wed, Nov 17, 2021 at 12:53 AM Subject: [YouTrack, Commented] Issue IDEA-282632: Application Run Configuration does not respect "--enable-preview" VM Option with JDK-18 To: Eric Kolotyluk Bug was updated by Olga Klisho in project IntelliJ IDEA at 17 Nov 2021 11:50. IDEA-282632 Application Run Configuration does not respect "--enable-preview" VM Option with JDK-18 Created by you [image: Olga Klisho] @Eric Kolotyluk hello, 18JDK is not yet released, the support of 18JDK (preview) will appear only in 2022.1. View Reply Resolved Issue was resolved. State Submitted ? Answered This message was sent by YouTrack ? powerful project management for all your teams by JetBrains. You ( *kolotyluk*) received this message because you subscribe to @mentions in issue descriptions and comments and notification events for the *Star* tag. To unsubscribe, you can mute notifications for this issue or edit your notification preferences . [@mention: @Mention in a comment] [tag: Star] YouTrack 2021.4.32239 From o.myhre at gmail.com Wed Nov 17 15:51:18 2021 From: o.myhre at gmail.com (=?UTF-8?Q?=C3=98ystein_Myhre_Andersen?=) Date: Wed, 17 Nov 2021 16:51:18 +0100 Subject: loom ea based jdk18 feedback In-Reply-To: References: Message-ID: The Continuation API in a single thread is exactly what I want in my implementation of Simula's Quasi Parallel Systems. I have used it in an experimental implementation and it works well. The performance of great simulation models is excellent. - ?ystein On Wed, Nov 17, 2021 at 4:38 PM Ron Pressler wrote: > > > > On 17 Nov 2021, at 11:13, dreamlike_ocean lei > wrote: > > > > 1, continuation api > > > > > > I really hope I can directly access this api in the future version > > The Continuation class is fundamentally unsafe, and using it might result > in miscompilation, as the JIT compiler bases some optimisations on the > assumption that the current thread cannot change. So there is currently no > way of exposing this particular class (which is mostly of interest for > research). However, in the future, the JDK could conceivably add safe > abstractions built on top of Continuation other than virtual threads, that > would probably be confined to a single thread. Custom schedulers will be > able to give you what I believe you want. > > > > > Virtual thread custom scheduler > > > > > > I hope you can consider reopening the api of the custom scheduler in the > > future version > > That is an API we would very much like to have, but we haven?t had time to > review yet. I don?t know yet whether or not it will make it in time for the > first release. Note that this is a very specialised API for internal, > sophisticated, use by frameworks, only, and should rarely if ever be used > by user code. Naturally, we prioritise the user-facing APIs. > > > ? Ron > > > > From pedro.lamarao at prodist.com.br Wed Nov 17 16:14:12 2021 From: pedro.lamarao at prodist.com.br (=?UTF-8?Q?Pedro_Lamar=C3=A3o?=) Date: Wed, 17 Nov 2021 13:14:12 -0300 Subject: A new build and a new structured concurrency API In-Reply-To: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> Message-ID: Hello all, Thanks for your hard work! Loom shows great promise! I have made the experiment of writing an application immediately after reading the documentation you linked. The result is here: https://github.com/pedrolamarao/sandbox-loom-wget I think there is great improvement in the most basic usability, even before error propagation and cancellation. In this exercise, I made an interesting mistake: because I am used to initializing ThreadFactory from Thread:::new, my first attempt to use virtual threads initialized ThreadFactory with Thread::startVirtualThread. IDE code completion suggested it, probably because of the matching signature, and I didn't think twice about it. When the test failed with "thread already started" it took me a while to figure out what was the problem. Regards, Pedro. Em seg., 15 de nov. de 2021 ?s 17:23, Ron Pressler escreveu: > Hi. > > We have just published a new Early Access build of Project Loom over on > https://jdk.java.net/loom/ > > The build is based on jdk-18+22, and now requires the --enable-preview > flag to > use Loom features (when compiling, remember to also add `--release 18`). > > The main new feature in this build is a new API for structured concurrency, > called StructuredExecutor. To learn more about its motivation, > capabilities, > and use, please read this JEP draft [1] and the Javadoc [2]. Pay special > attention to the new methods added to Future, resultNow and exceptionNow > [3], and how they complement StructuredExecutor. One of the most exciting > capabilities of StructuredExecutor is the new structured thread-dump > mentioned > in the JEP draft. > > Another new feature is the ability to use virtual threads as Cleaner > threads > [4]. We have also published a draft JEP for virtual threads [5]. The JEPs, > like > the project, are still a work in progress. > > As always, we appreciate feedback on these features from those who try > them. > Please, download the new EA and tell us about your experience. > > -- Ron > > [1]: http://openjdk.java.net/jeps/8277129 > [2]: > https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredExecutor.html > [3]: > https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/Future.html > [4]: > https://download.java.net/java/early_access/loom/docs/api/java.base/java/lang/ref/Cleaner.html > [5]: http://openjdk.java.net/jeps/8277131 > > -- Pedro Lamar?o https://www.prodist.com.br Securing Critical Systems Tel: +55 11 4380-6585 Antes de imprimir esta mensagem e seus anexos, certifique-se que seja realmente necess?rio. Proteger o meio ambiente ? nosso dever. Before printing this e-mail or attachments, be sure it is necessary. It is in our hands to protect the environment. From Alan.Bateman at oracle.com Wed Nov 17 16:48:36 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 17 Nov 2021 16:48:36 +0000 Subject: A new build and a new structured concurrency API In-Reply-To: References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> Message-ID: On 17/11/2021 16:14, Pedro Lamar?o wrote: > Hello all, > > Thanks for your hard work! Loom shows great promise! > > I have made the experiment of writing an application immediately after > reading the documentation you linked. > The result is here: https://github.com/pedrolamarao/sandbox-loom-wget > I think there is great improvement in the most basic usability, even before > error propagation and cancellation. > > In this exercise, I made an interesting mistake: > because I am used to initializing ThreadFactory from Thread:::new, > my first attempt to use virtual threads initialized ThreadFactory with > Thread::startVirtualThread. > IDE code completion suggested it, probably because of the matching > signature, and I didn't think twice about it. > When the test failed with "thread already started" it took me a while to > figure out what was the problem. Testing it out with something real, in this case a web crawler, is a great way to provide feedback. Can you say a few words about the exception handling? Don't you have cases where you should abort rather than record exceptions when traversing the links in a document? ThreadFactory::newThread is supposed to return a newly created but not started Thread. The javadoc could be a bit clearer on that. I can see how you ended up returning a started Thread. -Alan From oleksandr.otenko at gmail.com Wed Nov 17 21:48:07 2021 From: oleksandr.otenko at gmail.com (Alex Otenko) Date: Wed, 17 Nov 2021 21:48:07 +0000 Subject: A new build and a new structured concurrency API In-Reply-To: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> Message-ID: Thanks for the great update. I am trying to comprehend the implications of fork with onComplete. The docs say onComplete may not be invoked at all. What is being saved here, compared to cancel() that guarantees onComplete will be invoked. The other thing that seems odd is that onComplete is entirely side-effecting: it has no communication with the task that got completed (the task can't delegate responsibility for anything), and no communication with the consumer of Future (onComplete can't delegate responsibility for anything). Like, I borrow a connection - who's going to return it and how? I'd expect someone to have one last glance at the context of the Callable to clean up. Alex On Mon, 15 Nov 2021, 20:22 Ron Pressler, wrote: > Hi. > > We have just published a new Early Access build of Project Loom over on > https://jdk.java.net/loom/ > > The build is based on jdk-18+22, and now requires the --enable-preview > flag to > use Loom features (when compiling, remember to also add `--release 18`). > > The main new feature in this build is a new API for structured concurrency, > called StructuredExecutor. To learn more about its motivation, > capabilities, > and use, please read this JEP draft [1] and the Javadoc [2]. Pay special > attention to the new methods added to Future, resultNow and exceptionNow > [3], and how they complement StructuredExecutor. One of the most exciting > capabilities of StructuredExecutor is the new structured thread-dump > mentioned > in the JEP draft. > > Another new feature is the ability to use virtual threads as Cleaner > threads > [4]. We have also published a draft JEP for virtual threads [5]. The JEPs, > like > the project, are still a work in progress. > > As always, we appreciate feedback on these features from those who try > them. > Please, download the new EA and tell us about your experience. > > -- Ron > > [1]: http://openjdk.java.net/jeps/8277129 > [2]: > https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredExecutor.html > [3]: > https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/Future.html > [4]: > https://download.java.net/java/early_access/loom/docs/api/java.base/java/lang/ref/Cleaner.html > [5]: http://openjdk.java.net/jeps/8277131 > > From forax at univ-mlv.fr Wed Nov 17 22:20:46 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 17 Nov 2021 23:20:46 +0100 (CET) Subject: A new build and a new structured concurrency API In-Reply-To: References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> Message-ID: <1723526522.2124595.1637187646078.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "Alex Otenko" > To: "Ron Pressler" > Cc: "loom-dev" > Sent: Mercredi 17 Novembre 2021 22:48:07 > Subject: Re: A new build and a new structured concurrency API > Thanks for the great update. > > I am trying to comprehend the implications of fork with onComplete. Hi Alex, > > The docs say onComplete may not be invoked at all. What is being saved > here, compared to cancel() that guarantees onComplete will be invoked. >From the doc, onComplete() is not called if the structured executor is already shutdown. > > The other thing that seems odd is that onComplete is entirely > side-effecting: it has no communication with the task that got completed > (the task can't delegate responsibility for anything), and no communication > with the consumer of Future (onComplete can't delegate responsibility for > anything). Like, I borrow a connection - who's going to return it and how? > I'd expect someone to have one last glance at the context of the Callable > to clean up. onComplete takes a BiConsumer which is a functional interface so the lambda can capture any context, the same way a Callable can capture the same context. > > Alex regards, R?mi > > On Mon, 15 Nov 2021, 20:22 Ron Pressler, wrote: > >> Hi. >> >> We have just published a new Early Access build of Project Loom over on >> https://jdk.java.net/loom/ >> >> The build is based on jdk-18+22, and now requires the --enable-preview >> flag to >> use Loom features (when compiling, remember to also add `--release 18`). >> >> The main new feature in this build is a new API for structured concurrency, >> called StructuredExecutor. To learn more about its motivation, >> capabilities, >> and use, please read this JEP draft [1] and the Javadoc [2]. Pay special >> attention to the new methods added to Future, resultNow and exceptionNow >> [3], and how they complement StructuredExecutor. One of the most exciting >> capabilities of StructuredExecutor is the new structured thread-dump >> mentioned >> in the JEP draft. >> >> Another new feature is the ability to use virtual threads as Cleaner >> threads >> [4]. We have also published a draft JEP for virtual threads [5]. The JEPs, >> like >> the project, are still a work in progress. >> >> As always, we appreciate feedback on these features from those who try >> them. >> Please, download the new EA and tell us about your experience. >> >> -- Ron >> >> [1]: http://openjdk.java.net/jeps/8277129 >> [2]: >> https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredExecutor.html >> [3]: >> https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/Future.html >> [4]: >> https://download.java.net/java/early_access/loom/docs/api/java.base/java/lang/ref/Cleaner.html >> [5]: http://openjdk.java.net/jeps/8277131 >> From oleksandr.otenko at gmail.com Wed Nov 17 22:41:38 2021 From: oleksandr.otenko at gmail.com (Alex Otenko) Date: Wed, 17 Nov 2021 22:41:38 +0000 Subject: A new build and a new structured concurrency API In-Reply-To: <1723526522.2124595.1637187646078.JavaMail.zimbra@u-pem.fr> References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <1723526522.2124595.1637187646078.JavaMail.zimbra@u-pem.fr> Message-ID: Hi Remi, Yes, from the docs onComplete is not always invoked, and I wonder what is being saved. Yes, lambdas can capture the things from outside syntactic scope, but can't share things between themselves. Hence the question. Say, if I borrow a connection inside Callable, onComplete seems like the right place to release it. No? If that's not the purpose, what does onComplete achieve that can't be done in, say, finally clause of Callable? Alex On Wed, 17 Nov 2021, 22:20 Remi Forax, wrote: > ----- Original Message ----- > > From: "Alex Otenko" > > To: "Ron Pressler" > > Cc: "loom-dev" > > Sent: Mercredi 17 Novembre 2021 22:48:07 > > Subject: Re: A new build and a new structured concurrency API > > > Thanks for the great update. > > > > I am trying to comprehend the implications of fork with onComplete. > > Hi Alex, > > > > > The docs say onComplete may not be invoked at all. What is being saved > > here, compared to cancel() that guarantees onComplete will be invoked. > > From the doc, onComplete() is not called if the structured executor is > already shutdown. > > > > > The other thing that seems odd is that onComplete is entirely > > side-effecting: it has no communication with the task that got completed > > (the task can't delegate responsibility for anything), and no > communication > > with the consumer of Future (onComplete can't delegate responsibility for > > anything). Like, I borrow a connection - who's going to return it and > how? > > I'd expect someone to have one last glance at the context of the Callable > > to clean up. > > onComplete takes a BiConsumer which is a functional interface so the > lambda can capture any context, > the same way a Callable can capture the same context. > > > > > Alex > > regards, > R?mi > > > > > On Mon, 15 Nov 2021, 20:22 Ron Pressler, > wrote: > > > >> Hi. > >> > >> We have just published a new Early Access build of Project Loom over on > >> https://jdk.java.net/loom/ > >> > >> The build is based on jdk-18+22, and now requires the --enable-preview > >> flag to > >> use Loom features (when compiling, remember to also add `--release 18`). > >> > >> The main new feature in this build is a new API for structured > concurrency, > >> called StructuredExecutor. To learn more about its motivation, > >> capabilities, > >> and use, please read this JEP draft [1] and the Javadoc [2]. Pay special > >> attention to the new methods added to Future, resultNow and exceptionNow > >> [3], and how they complement StructuredExecutor. One of the most > exciting > >> capabilities of StructuredExecutor is the new structured thread-dump > >> mentioned > >> in the JEP draft. > >> > >> Another new feature is the ability to use virtual threads as Cleaner > >> threads > >> [4]. We have also published a draft JEP for virtual threads [5]. The > JEPs, > >> like > >> the project, are still a work in progress. > >> > >> As always, we appreciate feedback on these features from those who try > >> them. > >> Please, download the new EA and tell us about your experience. > >> > >> -- Ron > >> > >> [1]: http://openjdk.java.net/jeps/8277129 > >> [2]: > >> > https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredExecutor.html > >> [3]: > >> > https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/Future.html > >> [4]: > >> > https://download.java.net/java/early_access/loom/docs/api/java.base/java/lang/ref/Cleaner.html > >> [5]: http://openjdk.java.net/jeps/8277131 > >> > From eric at kolotyluk.net Wed Nov 17 23:25:59 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Wed, 17 Nov 2021 15:25:59 -0800 Subject: loom-lab Message-ID: https://kolotyluk.github.io/loom-lab/site/apidocs/net/kolotyluk/loom/Experiment00.html Is one of the early JavaDoc pages I am working on. I would appreciate any feedback on what I could improve or fix in my understanding and explanation of Project Loom. Cheers, Eric From ron.pressler at oracle.com Wed Nov 17 23:28:28 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Wed, 17 Nov 2021 23:28:28 +0000 Subject: [External] : Re: A new build and a new structured concurrency API In-Reply-To: References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> Message-ID: <09553679-68C7-430C-8E1A-6E31FB7B515F@oracle.com> > On 17 Nov 2021, at 21:48, Alex Otenko wrote: > > Thanks for the great update. > > I am trying to comprehend the implications of fork with onComplete. > > The docs say onComplete may not be invoked at all. What is being saved here, compared to cancel() that guarantees onComplete will be invoked. > > The other thing that seems odd is that onComplete is entirely side-effecting: it has no communication with the task that got completed (the task can't delegate responsibility for anything), and no communication with the consumer of Future (onComplete can't delegate responsibility for anything). Like, I borrow a connection - who's going to return it and how? I'd expect someone to have one last glance at the context of the Callable to clean up. > Completion handlers allows you to factor out policies for the common and simple cases where you need to collect results or shutdown the executor session based on the task?s success or failure. A call to shutdown indicates that the computation is done ? either successfully or unsuccessfully ? and so there?s no point in processing further results. In more complicated ? and, we believe, much rarer ? cases, like the connection example in the javadoc, the completion handler is, indeed, insufficient, and you?d want to do cleanup processing inside the task and possibly call shutdown directly (shutdown is the concurrent analogue to a break statement in sequential loop). ? Ron From lomakin.andrey at gmail.com Thu Nov 18 06:33:00 2021 From: lomakin.andrey at gmail.com (Andrey Lomakin) Date: Thu, 18 Nov 2021 08:33:00 +0200 Subject: Implementation of AsynchronousFileChannel using io_uring API Message-ID: Hi guys. The article described the state of the project Loom announced plans to implement AsynchronousFileChannel using io_uring API. Unfortunately, I did not find any further information about the state of this implementation. Could you provide an update on whether such implementation was completed? -- Best regards, Andrey Lomakin. From lomakin.andrey at gmail.com Thu Nov 18 06:44:04 2021 From: lomakin.andrey at gmail.com (Andrey Lomakin) Date: Thu, 18 Nov 2021 08:44:04 +0200 Subject: Implementation of concurrency primitives Message-ID: Good morning, guys. I am considering creating an application that will use a thread-per-core approach. Data mostly will not be shared between cores and I am going to use a single thread executor to schedule fibres. My question is may I use my own concurrency primitives which do not inject memory barriers unlike the standard concurrency primitives to achieve maximum performance and if that is not possible could you explain why? -- Best regards, Andrey Lomakin. From cristian.lorenzetto at gmail.com Thu Nov 18 07:16:16 2021 From: cristian.lorenzetto at gmail.com (Cristian Lorenzetto) Date: Thu, 18 Nov 2021 08:16:16 +0100 Subject: Implementation of concurrency primitives In-Reply-To: References: Message-ID: Interesting question, but i suspect it is not possible realize a custom manager for that but you can use cpu affinity flag Il giorno gio 18 nov 2021 alle ore 07:44 Andrey Lomakin < lomakin.andrey at gmail.com> ha scritto: > Good morning, guys. > > I am considering creating an application that will use a > thread-per-core approach. Data mostly will not be shared between cores and > I am going to use a single thread executor to schedule fibres. > > My question is may I use my own concurrency primitives which do not inject > memory barriers unlike the standard concurrency primitives to > achieve maximum performance and if that is not possible could you explain > why? > > -- > Best regards, > Andrey Lomakin. > From Alan.Bateman at oracle.com Thu Nov 18 07:28:56 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 18 Nov 2021 07:28:56 +0000 Subject: A new build and a new structured concurrency API In-Reply-To: References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> Message-ID: <7b681d7b-5e79-2831-9131-705973bb62ca@oracle.com> On 17/11/2021 21:48, Alex Otenko wrote: > : > > The docs say onComplete may not be invoked at all. What is being saved > here, compared to cancel() that guarantees onComplete will be invoked. I see R?mi and Ron have replied pointing out that your question is about when the executor is shutdown. Just to add that isn't an anomaly with cancel, it's just that the javadoc isn't clear. So if you are using Future objects and you invoke a cancel method after the executor is shutdown then it's not going to run the onComplete operation. -Alan From forax at univ-mlv.fr Thu Nov 18 07:37:37 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 18 Nov 2021 08:37:37 +0100 (CET) Subject: [External] : Re: A new build and a new structured concurrency API In-Reply-To: <09553679-68C7-430C-8E1A-6E31FB7B515F@oracle.com> References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <09553679-68C7-430C-8E1A-6E31FB7B515F@oracle.com> Message-ID: <1470737836.2159863.1637221057596.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "Ron Pressler" > To: "Alex Otenko" > Cc: "loom-dev" > Sent: Jeudi 18 Novembre 2021 00:28:28 > Subject: Re: [External] : Re: A new build and a new structured concurrency API >> On 17 Nov 2021, at 21:48, Alex Otenko wrote: >> >> Thanks for the great update. >> >> I am trying to comprehend the implications of fork with onComplete. >> >> The docs say onComplete may not be invoked at all. What is being saved here, >> compared to cancel() that guarantees onComplete will be invoked. >> >> The other thing that seems odd is that onComplete is entirely side-effecting: it >> has no communication with the task that got completed (the task can't delegate >> responsibility for anything), and no communication with the consumer of Future >> (onComplete can't delegate responsibility for anything). Like, I borrow a >> connection - who's going to return it and how? I'd expect someone to have one >> last glance at the context of the Callable to clean up. >> > > Completion handlers allows you to factor out policies for the common and simple > cases where you need to collect results or shutdown the executor session based > on the task?s success or failure. A call to shutdown indicates that the > computation is done ? either successfully or unsuccessfully ? and so there?s no > point in processing further results. In more complicated ? and, we believe, > much rarer ? cases, like the connection example in the javadoc, the completion > handler is, indeed, insufficient, and you?d want to do cleanup processing > inside the task and possibly call shutdown directly (shutdown is the concurrent > analogue to a break statement in sequential loop). This remember me something which is to use a Stream of Future as an API to see the result of tasks. The onComplete() push a result into the stream, a user can use short-circuit operations like findFirst() or limit(), the shutdown() is called when the stream is closed. Something like int sum; try(var executor = StructuredExecutor.open()) { var streamHandler = new StreamHandler(executor); streamHandler.fork(() -> 2); streamHandler.fork(...); try(Stream> futures = streamHandler.futureStream()) { sum = futures .mapToInt(future -> future.resultOrElseThrow(e -> new WebApplication(e))) .sum(); } // executor.shutdown() } // executor.close() > > ? Ron R?mi From lomakin.andrey at gmail.com Thu Nov 18 08:00:35 2021 From: lomakin.andrey at gmail.com (Andrey Lomakin) Date: Thu, 18 Nov 2021 10:00:35 +0200 Subject: Implementation of concurrency primitives In-Reply-To: References: Message-ID: Probably I need to add that the application uses disk intensively, that is why I am interested in the usage of virtual threads. On Thu, Nov 18, 2021 at 9:59 AM Andrey Lomakin wrote: > Hi Cristian. > Sure I would like to use CPU affinity at the end. > But my primary concern is memory barriers or more widely thread safety. > > I mean the following, could I use for example HashMap instead of > ConcurrentHashMap in such cases or more widely speaking, could I use data > structures that were not designed to be thread-safe because I use > cooperative multitasking and know that execution of methods > will not be interrupted and in nutshell, all execution is running inside > of the single thread, so that is a single-threaded application in nutshell > with means to exchange data using threadsafe queues for example. > > On Thu, Nov 18, 2021 at 9:16 AM Cristian Lorenzetto < > cristian.lorenzetto at gmail.com> wrote: > >> Interesting question, but i suspect it is not possible realize a custom >> manager for that but you can use cpu affinity flag >> >> Il giorno gio 18 nov 2021 alle ore 07:44 Andrey Lomakin < >> lomakin.andrey at gmail.com> ha scritto: >> >>> Good morning, guys. >>> >>> I am considering creating an application that will use a >>> thread-per-core approach. Data mostly will not be shared between cores >>> and >>> I am going to use a single thread executor to schedule fibres. >>> >>> My question is may I use my own concurrency primitives which do not >>> inject >>> memory barriers unlike the standard concurrency primitives to >>> achieve maximum performance and if that is not possible could you explain >>> why? >>> >>> -- >>> Best regards, >>> Andrey Lomakin. >>> >> > > -- > Best regards, > Andrey Lomakin. > > -- Best regards, Andrey Lomakin. From Alan.Bateman at oracle.com Thu Nov 18 08:02:22 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 18 Nov 2021 08:02:22 +0000 Subject: Implementation of AsynchronousFileChannel using io_uring API In-Reply-To: References: Message-ID: <4c162e4c-8c77-223c-4d5d-98b55ed1e9fb@oracle.com> On 18/11/2021 06:33, Andrey Lomakin wrote: > Hi guys. > The article described the state of the project Loom announced plans to > implement AsynchronousFileChannel using io_uring API. > Unfortunately, I did not find any further information about the state of > this implementation. > Could you provide an update on whether such implementation was completed? I suspect this is the "State of Loom", May 2020 edition, is that right? For buffered file I/O it outlines two phases, short term to compensate for the pinning, later to make use of OS mechanism where possible. So yes, the intention is to come back to an io_uring implementation of FileChannel and java.io, just not in the first release. AsynchronousFileChannel provides an async API so not directly interesting to this project. It could potentially be re-implemented using io_uring, independent of this project. The draft JEP for virtual threads [1] has a work-in-progress summary of the core of a possible first release. -Alan [1] https://openjdk.java.net/jeps/8277131 From lomakin.andrey at gmail.com Thu Nov 18 07:59:16 2021 From: lomakin.andrey at gmail.com (Andrey Lomakin) Date: Thu, 18 Nov 2021 09:59:16 +0200 Subject: Implementation of concurrency primitives In-Reply-To: References: Message-ID: Hi Cristian. Sure I would like to use CPU affinity at the end. But my primary concern is memory barriers or more widely thread safety. I mean the following, could I use for example HashMap instead of ConcurrentHashMap in such cases or more widely speaking, could I use data structures that were not designed to be thread-safe because I use cooperative multitasking and know that execution of methods will not be interrupted and in nutshell, all execution is running inside of the single thread, so that is a single-threaded application in nutshell with means to exchange data using threadsafe queues for example. On Thu, Nov 18, 2021 at 9:16 AM Cristian Lorenzetto < cristian.lorenzetto at gmail.com> wrote: > Interesting question, but i suspect it is not possible realize a custom > manager for that but you can use cpu affinity flag > > Il giorno gio 18 nov 2021 alle ore 07:44 Andrey Lomakin < > lomakin.andrey at gmail.com> ha scritto: > >> Good morning, guys. >> >> I am considering creating an application that will use a >> thread-per-core approach. Data mostly will not be shared between cores and >> I am going to use a single thread executor to schedule fibres. >> >> My question is may I use my own concurrency primitives which do not inject >> memory barriers unlike the standard concurrency primitives to >> achieve maximum performance and if that is not possible could you explain >> why? >> >> -- >> Best regards, >> Andrey Lomakin. >> > -- Best regards, Andrey Lomakin. From lomakin.andrey at gmail.com Thu Nov 18 08:08:02 2021 From: lomakin.andrey at gmail.com (Andrey Lomakin) Date: Thu, 18 Nov 2021 10:08:02 +0200 Subject: Implementation of AsynchronousFileChannel using io_uring API In-Reply-To: <4c162e4c-8c77-223c-4d5d-98b55ed1e9fb@oracle.com> References: <4c162e4c-8c77-223c-4d5d-98b55ed1e9fb@oracle.com> Message-ID: Hi Alan. Thank you for providing the update. I am not so interested in whether it will be Async or classic file channel as the fact that implementation will not suffer from thread pinning and will use OS mechanics as much as possible. Looking forward to seeing those changes in upcoming releases :-) On Thu, Nov 18, 2021 at 10:02 AM Alan Bateman wrote: > On 18/11/2021 06:33, Andrey Lomakin wrote: > > Hi guys. > > The article described the state of the project Loom announced plans to > > implement AsynchronousFileChannel using io_uring API. > > Unfortunately, I did not find any further information about the state of > > this implementation. > > Could you provide an update on whether such implementation was completed? > I suspect this is the "State of Loom", May 2020 edition, is that right? > For buffered file I/O it outlines two phases, short term to compensate > for the pinning, later to make use of OS mechanism where possible. So > yes, the intention is to come back to an io_uring implementation of > FileChannel and java.io, just not in the first release. > AsynchronousFileChannel provides an async API so not directly > interesting to this project. It could potentially be re-implemented > using io_uring, independent of this project. The draft JEP for virtual > threads [1] has a work-in-progress summary of the core of a possible > first release. > > -Alan > > [1] https://openjdk.java.net/jeps/8277131 > -- Best regards, Andrey Lomakin. From lomakin.andrey at gmail.com Thu Nov 18 08:16:23 2021 From: lomakin.andrey at gmail.com (Andrey Lomakin) Date: Thu, 18 Nov 2021 10:16:23 +0200 Subject: Implementation of AsynchronousFileChannel using io_uring API In-Reply-To: References: <4c162e4c-8c77-223c-4d5d-98b55ed1e9fb@oracle.com> Message-ID: Alan, would you mind answering the additional questions. Does the current version of Loom project prevent thread pining if I use FileChannel? On Thu, Nov 18, 2021 at 10:08 AM Andrey Lomakin wrote: > Hi Alan. > Thank you for providing the update. > > I am not so interested in whether it will be Async or classic file channel > as the fact that implementation will not suffer from thread pinning and > will use OS mechanics as much as possible. > Looking forward to seeing those changes in upcoming releases :-) > > > > On Thu, Nov 18, 2021 at 10:02 AM Alan Bateman > wrote: > >> On 18/11/2021 06:33, Andrey Lomakin wrote: >> > Hi guys. >> > The article described the state of the project Loom announced plans to >> > implement AsynchronousFileChannel using io_uring API. >> > Unfortunately, I did not find any further information about the state of >> > this implementation. >> > Could you provide an update on whether such implementation was >> completed? >> I suspect this is the "State of Loom", May 2020 edition, is that right? >> For buffered file I/O it outlines two phases, short term to compensate >> for the pinning, later to make use of OS mechanism where possible. So >> yes, the intention is to come back to an io_uring implementation of >> FileChannel and java.io, just not in the first release. >> AsynchronousFileChannel provides an async API so not directly >> interesting to this project. It could potentially be re-implemented >> using io_uring, independent of this project. The draft JEP for virtual >> threads [1] has a work-in-progress summary of the core of a possible >> first release. >> >> -Alan >> >> [1] https://openjdk.java.net/jeps/8277131 >> > > > -- > Best regards, > Andrey Lomakin. > > -- Best regards, Andrey Lomakin. From cristian.lorenzetto at gmail.com Thu Nov 18 08:29:59 2021 From: cristian.lorenzetto at gmail.com (Cristian Lorenzetto) Date: Thu, 18 Nov 2021 09:29:59 +0100 Subject: Implementation of concurrency primitives In-Reply-To: References: Message-ID: I had a idea similar in the past ... but the problem is many librariies (also basic code) in java is using synchnorized blocks for example.... My project was , using instrumentation , to remove synchronized code for adapting it to fibers ... Il giorno gio 18 nov 2021 alle ore 08:59 Andrey Lomakin < lomakin.andrey at gmail.com> ha scritto: > Hi Cristian. > Sure I would like to use CPU affinity at the end. > But my primary concern is memory barriers or more widely thread safety. > > I mean the following, could I use for example HashMap instead of > ConcurrentHashMap in such cases or more widely speaking, could I use data > structures that were not designed to be thread-safe because I use > cooperative multitasking and know that execution of methods > will not be interrupted and in nutshell, all execution is running inside > of the single thread, so that is a single-threaded application in nutshell > with means to exchange data using threadsafe queues for example. > > On Thu, Nov 18, 2021 at 9:16 AM Cristian Lorenzetto < > cristian.lorenzetto at gmail.com> wrote: > >> Interesting question, but i suspect it is not possible realize a custom >> manager for that but you can use cpu affinity flag >> >> Il giorno gio 18 nov 2021 alle ore 07:44 Andrey Lomakin < >> lomakin.andrey at gmail.com> ha scritto: >> >>> Good morning, guys. >>> >>> I am considering creating an application that will use a >>> thread-per-core approach. Data mostly will not be shared between cores >>> and >>> I am going to use a single thread executor to schedule fibres. >>> >>> My question is may I use my own concurrency primitives which do not >>> inject >>> memory barriers unlike the standard concurrency primitives to >>> achieve maximum performance and if that is not possible could you explain >>> why? >>> >>> -- >>> Best regards, >>> Andrey Lomakin. >>> >> > > -- > Best regards, > Andrey Lomakin. > > From lomakin.andrey at gmail.com Thu Nov 18 08:44:25 2021 From: lomakin.andrey at gmail.com (Andrey Lomakin) Date: Thu, 18 Nov 2021 10:44:25 +0200 Subject: Implementation of concurrency primitives In-Reply-To: References: Message-ID: I see :-) The current version of my project is using only JDK API, at least the part which requires syncrhonization. On Thu, Nov 18, 2021 at 10:30 AM Cristian Lorenzetto < cristian.lorenzetto at gmail.com> wrote: > I had a idea similar in the past ... but the problem is many librariies > (also basic code) in java is using synchnorized blocks for example.... > My project was , using instrumentation , to remove synchronized code for > adapting it to fibers ... > > Il giorno gio 18 nov 2021 alle ore 08:59 Andrey Lomakin < > lomakin.andrey at gmail.com> ha scritto: > >> Hi Cristian. >> Sure I would like to use CPU affinity at the end. >> But my primary concern is memory barriers or more widely thread safety. >> >> I mean the following, could I use for example HashMap instead of >> ConcurrentHashMap in such cases or more widely speaking, could I use data >> structures that were not designed to be thread-safe because I use >> cooperative multitasking and know that execution of methods >> will not be interrupted and in nutshell, all execution is running inside >> of the single thread, so that is a single-threaded application in nutshell >> with means to exchange data using threadsafe queues for example. >> >> On Thu, Nov 18, 2021 at 9:16 AM Cristian Lorenzetto < >> cristian.lorenzetto at gmail.com> wrote: >> >>> Interesting question, but i suspect it is not possible realize a custom >>> manager for that but you can use cpu affinity flag >>> >>> Il giorno gio 18 nov 2021 alle ore 07:44 Andrey Lomakin < >>> lomakin.andrey at gmail.com> ha scritto: >>> >>>> Good morning, guys. >>>> >>>> I am considering creating an application that will use a >>>> thread-per-core approach. Data mostly will not be shared between cores >>>> and >>>> I am going to use a single thread executor to schedule fibres. >>>> >>>> My question is may I use my own concurrency primitives which do not >>>> inject >>>> memory barriers unlike the standard concurrency primitives to >>>> achieve maximum performance and if that is not possible could you >>>> explain >>>> why? >>>> >>>> -- >>>> Best regards, >>>> Andrey Lomakin. >>>> >>> >> >> -- >> Best regards, >> Andrey Lomakin. >> >> -- Best regards, Andrey Lomakin. From Alan.Bateman at oracle.com Thu Nov 18 09:24:32 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 18 Nov 2021 09:24:32 +0000 Subject: Implementation of concurrency primitives In-Reply-To: References: Message-ID: <167108d9-95c3-762a-7772-444412d93938@oracle.com> On 18/11/2021 06:44, Andrey Lomakin wrote: > Good morning, guys. > > I am considering creating an application that will use a > thread-per-core approach. Data mostly will not be shared between cores and > I am going to use a single thread executor to schedule fibres. > > My question is may I use my own concurrency primitives which do not inject > memory barriers unlike the standard concurrency primitives to > achieve maximum performance and if that is not possible could you explain > why? I don't see how this could be reliable in general as APIs and library code that you use could execute code that is pre-empted, it could happen anywhere. Also just to say, for now anyway, there isn't an API exposed that allows you to set your own scheduler. That is something that the project will have to come back to in the future. -Alan From oleksandr.otenko at gmail.com Thu Nov 18 09:36:25 2021 From: oleksandr.otenko at gmail.com (Alex Otenko) Date: Thu, 18 Nov 2021 09:36:25 +0000 Subject: A new build and a new structured concurrency API In-Reply-To: <7b681d7b-5e79-2831-9131-705973bb62ca@oracle.com> References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <7b681d7b-5e79-2831-9131-705973bb62ca@oracle.com> Message-ID: I still fail to see what you win by not invoking onComplete. I see a lot of problems from indeterminism in other similar contexts. Alex On Thu, 18 Nov 2021, 07:29 Alan Bateman, wrote: > On 17/11/2021 21:48, Alex Otenko wrote: > > : > > > > The docs say onComplete may not be invoked at all. What is being saved > > here, compared to cancel() that guarantees onComplete will be invoked. > I see R?mi and Ron have replied pointing out that your question is about > when the executor is shutdown. Just to add that isn't an anomaly with > cancel, it's just that the javadoc isn't clear. So if you are using > Future objects and you invoke a cancel method after the executor is > shutdown then it's not going to run the onComplete operation. > > -Alan > From forax at univ-mlv.fr Thu Nov 18 09:45:46 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 18 Nov 2021 10:45:46 +0100 (CET) Subject: A new build and a new structured concurrency API In-Reply-To: References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <7b681d7b-5e79-2831-9131-705973bb62ca@oracle.com> Message-ID: <871106267.2267099.1637228746116.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "Alex Otenko" > To: "Alan Bateman" > Cc: "loom-dev" > Sent: Jeudi 18 Novembre 2021 10:36:25 > Subject: Re: A new build and a new structured concurrency API > I still fail to see what you win by not invoking onComplete. I see a lot of > problems from indeterminism in other similar contexts. If shutdown has been called, there is no point of trying to complete the parts of the computation that was still running. > > Alex R?mi > > On Thu, 18 Nov 2021, 07:29 Alan Bateman, wrote: > >> On 17/11/2021 21:48, Alex Otenko wrote: >> > : >> > >> > The docs say onComplete may not be invoked at all. What is being saved >> > here, compared to cancel() that guarantees onComplete will be invoked. >> I see R?mi and Ron have replied pointing out that your question is about >> when the executor is shutdown. Just to add that isn't an anomaly with >> cancel, it's just that the javadoc isn't clear. So if you are using >> Future objects and you invoke a cancel method after the executor is >> shutdown then it's not going to run the onComplete operation. >> >> -Alan From oleksandr.otenko at gmail.com Thu Nov 18 09:55:56 2021 From: oleksandr.otenko at gmail.com (Alex Otenko) Date: Thu, 18 Nov 2021 09:55:56 +0000 Subject: A new build and a new structured concurrency API In-Reply-To: <871106267.2267099.1637228746116.JavaMail.zimbra@u-pem.fr> References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <7b681d7b-5e79-2831-9131-705973bb62ca@oracle.com> <871106267.2267099.1637228746116.JavaMail.zimbra@u-pem.fr> Message-ID: What do you mean - no point? I think that requires a proof that there really is no point. Which is going to be hard to do because all of the interactions are side-effecting, so you are setting up to prove there is never any problem from the absence of those side effects. Alex On Thu, 18 Nov 2021, 09:50 Remi Forax, wrote: > ----- Original Message ----- > > From: "Alex Otenko" > > To: "Alan Bateman" > > Cc: "loom-dev" > > Sent: Jeudi 18 Novembre 2021 10:36:25 > > Subject: Re: A new build and a new structured concurrency API > > > I still fail to see what you win by not invoking onComplete. I see a lot > of > > problems from indeterminism in other similar contexts. > > If shutdown has been called, there is no point of trying to complete the > parts of the computation that was still running. > > > > > Alex > > R?mi > > > > > On Thu, 18 Nov 2021, 07:29 Alan Bateman, > wrote: > > > >> On 17/11/2021 21:48, Alex Otenko wrote: > >> > : > >> > > >> > The docs say onComplete may not be invoked at all. What is being saved > >> > here, compared to cancel() that guarantees onComplete will be invoked. > >> I see R?mi and Ron have replied pointing out that your question is about > >> when the executor is shutdown. Just to add that isn't an anomaly with > >> cancel, it's just that the javadoc isn't clear. So if you are using > >> Future objects and you invoke a cancel method after the executor is > >> shutdown then it's not going to run the onComplete operation. > >> > >> -Alan > From Alan.Bateman at oracle.com Thu Nov 18 09:58:49 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 18 Nov 2021 09:58:49 +0000 Subject: A new build and a new structured concurrency API In-Reply-To: References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <7b681d7b-5e79-2831-9131-705973bb62ca@oracle.com> Message-ID: <90cfdec6-0223-e995-4d35-aaa7ee2c774f@oracle.com> On 18/11/2021 09:36, Alex Otenko wrote: > I still fail to see what you win by not invoking onComplete. I see a > lot of problems from indeterminism in other similar contexts. It would be useful for the discussion to outline your example where it useful to continue to collect results after the executor is shutdown. As Ron says, the shutdown method in this API is to say that you are done and no longer interested in any more results. All remaining threads are interrupted. I read your mail about borrowing a connection but that sounds like try-finally in the task, nothing to do with notification of completed task. -Alan From oleksandr.otenko at gmail.com Thu Nov 18 10:02:40 2021 From: oleksandr.otenko at gmail.com (Alex Otenko) Date: Thu, 18 Nov 2021 10:02:40 +0000 Subject: [External] : Re: A new build and a new structured concurrency API In-Reply-To: <09553679-68C7-430C-8E1A-6E31FB7B515F@oracle.com> References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <09553679-68C7-430C-8E1A-6E31FB7B515F@oracle.com> Message-ID: I see why break may be an analogue, but don't see why it is the right one. Right now the tasks finish in one of four ways: Success with a value Failure with Exception Someone aborted, a subclass of Failure Shutdown And it is ok to use onComplete for three cases, but not the last? So now really all handling is spread across two sites, predictably requiring more code and more complexity in interactions with the other three termination conditions. Alex On Wed, 17 Nov 2021, 23:28 Ron Pressler, wrote: > > > > On 17 Nov 2021, at 21:48, Alex Otenko > wrote: > > > > Thanks for the great update. > > > > I am trying to comprehend the implications of fork with onComplete. > > > > The docs say onComplete may not be invoked at all. What is being saved > here, compared to cancel() that guarantees onComplete will be invoked. > > > > The other thing that seems odd is that onComplete is entirely > side-effecting: it has no communication with the task that got completed > (the task can't delegate responsibility for anything), and no communication > with the consumer of Future (onComplete can't delegate responsibility for > anything). Like, I borrow a connection - who's going to return it and how? > I'd expect someone to have one last glance at the context of the Callable > to clean up. > > > > Completion handlers allows you to factor out policies for the common and > simple cases where you need to collect results or shutdown the executor > session based on the task?s success or failure. A call to shutdown > indicates that the computation is done ? either successfully or > unsuccessfully ? and so there?s no point in processing further results. In > more complicated ? and, we believe, much rarer ? cases, like the connection > example in the javadoc, the completion handler is, indeed, insufficient, > and you?d want to do cleanup processing inside the task and possibly call > shutdown directly (shutdown is the concurrent analogue to a break statement > in sequential loop). > > ? Ron From oleksandr.otenko at gmail.com Thu Nov 18 10:09:00 2021 From: oleksandr.otenko at gmail.com (Alex Otenko) Date: Thu, 18 Nov 2021 10:09:00 +0000 Subject: A new build and a new structured concurrency API In-Reply-To: <90cfdec6-0223-e995-4d35-aaa7ee2c774f@oracle.com> References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <7b681d7b-5e79-2831-9131-705973bb62ca@oracle.com> <90cfdec6-0223-e995-4d35-aaa7ee2c774f@oracle.com> Message-ID: Right, maybe I missed it, but it would be great to start with the documentation of what cancellation means, and what makes shutdown different from it. In particular, these things like finally clause - if it gets executed in both cases, then the examples I had in mind are solved. But that brings more questions - like, does this mean the task may catch cancellations and shutdowns? Through some catch statement that's a bit too broad? Alex On Thu, 18 Nov 2021, 09:59 Alan Bateman, wrote: > On 18/11/2021 09:36, Alex Otenko wrote: > > I still fail to see what you win by not invoking onComplete. I see a > > lot of problems from indeterminism in other similar contexts. > > It would be useful for the discussion to outline your example where it > useful to continue to collect results after the executor is shutdown. As > Ron says, the shutdown method in this API is to say that you are done > and no longer interested in any more results. All remaining threads are > interrupted. I read your mail about borrowing a connection but that > sounds like try-finally in the task, nothing to do with notification of > completed task. > > -Alan > From forax at univ-mlv.fr Thu Nov 18 10:09:56 2021 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 18 Nov 2021 11:09:56 +0100 (CET) Subject: A new build and a new structured concurrency API In-Reply-To: References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <7b681d7b-5e79-2831-9131-705973bb62ca@oracle.com> <871106267.2267099.1637228746116.JavaMail.zimbra@u-pem.fr> Message-ID: <1003827734.2292500.1637230196959.JavaMail.zimbra@u-pem.fr> > From: "Alex Otenko" > To: "Remi Forax" > Cc: "Alan Bateman" , "loom-dev" > > Sent: Jeudi 18 Novembre 2021 10:55:56 > Subject: Re: A new build and a new structured concurrency API > What do you mean - no point? I think that requires a proof that there really is > no point. Which is going to be hard to do because all of the interactions are > side-effecting, so you are setting up to prove there is never any problem from > the absence of those side effects. >From the javadoc of StructuredExecutor "StructuredExecutor defines the [ https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredExecutor.html#shutdown() | shutdown ] method to shut down an executor without closing it. Shutdown is useful for cases where a sub-task completes with a result (or exception) and the results of other unfinished tasks are no longer needed." So by definition, if you are using shudown() or Handler that uses shutdown(), it means that you are not interested in the result of the computation of the unfinished tasks. > Alex R?mi > On Thu, 18 Nov 2021, 09:50 Remi Forax, < [ mailto:forax at univ-mlv.fr | > forax at univ-mlv.fr ] > wrote: >> ----- Original Message ----- >>> From: "Alex Otenko" < [ mailto:oleksandr.otenko at gmail.com | >> > oleksandr.otenko at gmail.com ] > >>> To: "Alan Bateman" < [ mailto:Alan.Bateman at oracle.com | Alan.Bateman at oracle.com >> > ] > >>> Cc: "loom-dev" < [ mailto:loom-dev at openjdk.java.net | loom-dev at openjdk.java.net >> > ] > >> > Sent: Jeudi 18 Novembre 2021 10:36:25 >> > Subject: Re: A new build and a new structured concurrency API >> > I still fail to see what you win by not invoking onComplete. I see a lot of >> > problems from indeterminism in other similar contexts. >> If shutdown has been called, there is no point of trying to complete the parts >> of the computation that was still running. >> > Alex >> R?mi >>> On Thu, 18 Nov 2021, 07:29 Alan Bateman, < [ mailto:Alan.Bateman at oracle.com | >> > Alan.Bateman at oracle.com ] > wrote: >> >> On 17/11/2021 21:48, Alex Otenko wrote: >> >> > : >> >> > The docs say onComplete may not be invoked at all. What is being saved >> >> > here, compared to cancel() that guarantees onComplete will be invoked. >> >> I see R?mi and Ron have replied pointing out that your question is about >> >> when the executor is shutdown. Just to add that isn't an anomaly with >> >> cancel, it's just that the javadoc isn't clear. So if you are using >> >> Future objects and you invoke a cancel method after the executor is >> >> shutdown then it's not going to run the onComplete operation. >> >> -Alan From oleksandr.otenko at gmail.com Thu Nov 18 10:18:17 2021 From: oleksandr.otenko at gmail.com (Alex Otenko) Date: Thu, 18 Nov 2021 10:18:17 +0000 Subject: A new build and a new structured concurrency API In-Reply-To: References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <7b681d7b-5e79-2831-9131-705973bb62ca@oracle.com> <90cfdec6-0223-e995-4d35-aaa7ee2c774f@oracle.com> Message-ID: In particular I assumed the onComplete is there exactly because the intention is that finally doesn't suffice. Now, if finally is heeded, the role of onComplete is puzzling. Alex On Thu, 18 Nov 2021, 10:09 Alex Otenko, wrote: > Right, maybe I missed it, but it would be great to start with the > documentation of what cancellation means, and what makes shutdown different > from it. > > In particular, these things like finally clause - if it gets executed in > both cases, then the examples I had in mind are solved. But that brings > more questions - like, does this mean the task may catch cancellations and > shutdowns? Through some catch statement that's a bit too broad? > > Alex > > On Thu, 18 Nov 2021, 09:59 Alan Bateman, wrote: > >> On 18/11/2021 09:36, Alex Otenko wrote: >> > I still fail to see what you win by not invoking onComplete. I see a >> > lot of problems from indeterminism in other similar contexts. >> >> It would be useful for the discussion to outline your example where it >> useful to continue to collect results after the executor is shutdown. As >> Ron says, the shutdown method in this API is to say that you are done >> and no longer interested in any more results. All remaining threads are >> interrupted. I read your mail about borrowing a connection but that >> sounds like try-finally in the task, nothing to do with notification of >> completed task. >> >> -Alan >> > From oleksandr.otenko at gmail.com Thu Nov 18 10:24:31 2021 From: oleksandr.otenko at gmail.com (Alex Otenko) Date: Thu, 18 Nov 2021 10:24:31 +0000 Subject: A new build and a new structured concurrency API In-Reply-To: <1003827734.2292500.1637230196959.JavaMail.zimbra@u-pem.fr> References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <7b681d7b-5e79-2831-9131-705973bb62ca@oracle.com> <871106267.2267099.1637228746116.JavaMail.zimbra@u-pem.fr> <1003827734.2292500.1637230196959.JavaMail.zimbra@u-pem.fr> Message-ID: Does this result in the unfinished Futures being Done and Cancelled? Alex On Thu, 18 Nov 2021, 10:15 , wrote: > > > ------------------------------ > > *From: *"Alex Otenko" > *To: *"Remi Forax" > *Cc: *"Alan Bateman" , "loom-dev" < > loom-dev at openjdk.java.net> > *Sent: *Jeudi 18 Novembre 2021 10:55:56 > *Subject: *Re: A new build and a new structured concurrency API > > What do you mean - no point? I think that requires a proof that there > really is no point. Which is going to be hard to do because all of the > interactions are side-effecting, so you are setting up to prove there is > never any problem from the absence of those side effects. > > > From the javadoc of StructuredExecutor > "StructuredExecutor defines the shutdown > > method to shut down an executor without closing it. Shutdown is useful for > cases where a sub-task completes with a result (or exception) and the > results of other unfinished tasks are no longer needed." > > So by definition, if you are using shudown() or Handler that uses > shutdown(), it means that you are not interested in the result of the > computation of the unfinished tasks. > > > Alex > > > R?mi > > > On Thu, 18 Nov 2021, 09:50 Remi Forax, wrote: > >> ----- Original Message ----- >> > From: "Alex Otenko" >> > To: "Alan Bateman" >> > Cc: "loom-dev" >> > Sent: Jeudi 18 Novembre 2021 10:36:25 >> > Subject: Re: A new build and a new structured concurrency API >> >> > I still fail to see what you win by not invoking onComplete. I see a >> lot of >> > problems from indeterminism in other similar contexts. >> >> If shutdown has been called, there is no point of trying to complete the >> parts of the computation that was still running. >> >> > >> > Alex >> >> R?mi >> >> > >> > On Thu, 18 Nov 2021, 07:29 Alan Bateman, >> wrote: >> > >> >> On 17/11/2021 21:48, Alex Otenko wrote: >> >> > : >> >> > >> >> > The docs say onComplete may not be invoked at all. What is being >> saved >> >> > here, compared to cancel() that guarantees onComplete will be >> invoked. >> >> I see R?mi and Ron have replied pointing out that your question is >> about >> >> when the executor is shutdown. Just to add that isn't an anomaly with >> >> cancel, it's just that the javadoc isn't clear. So if you are using >> >> Future objects and you invoke a cancel method after the executor is >> >> shutdown then it's not going to run the onComplete operation. >> >> >> >> -Alan >> > > From Alan.Bateman at oracle.com Thu Nov 18 11:31:24 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 18 Nov 2021 11:31:24 +0000 Subject: [External] : Re: A new build and a new structured concurrency API In-Reply-To: References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <09553679-68C7-430C-8E1A-6E31FB7B515F@oracle.com> Message-ID: <8fa31bea-cf3f-617d-13d3-1f211f9e7ba4@oracle.com> On 18/11/2021 10:02, Alex Otenko wrote: > I see why break may be an analogue, but don't see why it is the right one. > > Right now the tasks finish in one of four ways: > > Success with a value > Failure with Exception > Someone aborted, a subclass of Failure > Shutdown > > And it is ok to use onComplete for three cases, but not the last? So now > really all handling is spread across two sites, predictably requiring more > code and more complexity in interactions with the other three termination > conditions. A task completes with a result, an exception, or it is cancelled. This will be familiar to everyone that uses Future::get. This project has not introduced any new states or ways for a task to complete. When using the 2-arg fork method then the onComplete operation is invoked when the task completes, irrespective of whether it completed with a result, exception, or was cancelled. The shutdown method is on StructuredExecutor, not Future. The javadoc tries to be clear that it is for cases where you've got an interesting result and are no longer interested in the results of other tasks. The shutdown method closes the front door to prevent new threads from starting. It also interrupts the threads that are running the tasks that haven't completed yet. It also tries to make it clear that when shutdown completes that are tasks are "done" (it links to Future::isDone). You shouldn't need to use Future::get with this API but if you were then you should see that Future::get wakes up when SE::shutdown is called. -Alan From cristian.lorenzetto at gmail.com Thu Nov 18 13:00:34 2021 From: cristian.lorenzetto at gmail.com (Cristian Lorenzetto) Date: Thu, 18 Nov 2021 14:00:34 +0100 Subject: Implementation of concurrency primitives In-Reply-To: References: Message-ID: also jdk api are containing inside many synchronized blocks.... unfortunatelly :( Il giorno gio 18 nov 2021 alle ore 09:44 Andrey Lomakin < lomakin.andrey at gmail.com> ha scritto: > I see :-) > The current version of my project is using only JDK API, at least the part > which requires syncrhonization. > > On Thu, Nov 18, 2021 at 10:30 AM Cristian Lorenzetto < > cristian.lorenzetto at gmail.com> wrote: > >> I had a idea similar in the past ... but the problem is many librariies >> (also basic code) in java is using synchnorized blocks for example.... >> My project was , using instrumentation , to remove synchronized code for >> adapting it to fibers ... >> >> Il giorno gio 18 nov 2021 alle ore 08:59 Andrey Lomakin < >> lomakin.andrey at gmail.com> ha scritto: >> >>> Hi Cristian. >>> Sure I would like to use CPU affinity at the end. >>> But my primary concern is memory barriers or more widely thread safety. >>> >>> I mean the following, could I use for example HashMap instead of >>> ConcurrentHashMap in such cases or more widely speaking, could I use data >>> structures that were not designed to be thread-safe because I use >>> cooperative multitasking and know that execution of methods >>> will not be interrupted and in nutshell, all execution is running inside >>> of the single thread, so that is a single-threaded application in nutshell >>> with means to exchange data using threadsafe queues for example. >>> >>> On Thu, Nov 18, 2021 at 9:16 AM Cristian Lorenzetto < >>> cristian.lorenzetto at gmail.com> wrote: >>> >>>> Interesting question, but i suspect it is not possible realize a custom >>>> manager for that but you can use cpu affinity flag >>>> >>>> Il giorno gio 18 nov 2021 alle ore 07:44 Andrey Lomakin < >>>> lomakin.andrey at gmail.com> ha scritto: >>>> >>>>> Good morning, guys. >>>>> >>>>> I am considering creating an application that will use a >>>>> thread-per-core approach. Data mostly will not be shared between cores >>>>> and >>>>> I am going to use a single thread executor to schedule fibres. >>>>> >>>>> My question is may I use my own concurrency primitives which do not >>>>> inject >>>>> memory barriers unlike the standard concurrency primitives to >>>>> achieve maximum performance and if that is not possible could you >>>>> explain >>>>> why? >>>>> >>>>> -- >>>>> Best regards, >>>>> Andrey Lomakin. >>>>> >>>> >>> >>> -- >>> Best regards, >>> Andrey Lomakin. >>> >>> > > -- > Best regards, > Andrey Lomakin. > > From jonross at gmail.com Thu Nov 18 05:40:51 2021 From: jonross at gmail.com (Jon Ross) Date: Wed, 17 Nov 2021 21:40:51 -0800 Subject: loom ea based jdk18 feedback Message-ID: I'm new to loom, but have worked with coroutines/continuations / async-await in other languages (JVM & non-JVM), mostly as a library/framework writer, so I'm used to suspending/resuming fibers. > So there is currently no way of exposing this particular class (which is mostly of interest for research). Is there another way to suspend/resume a fiber? I assume the JDK itself making use of this ability when it encounters blocking IO? None of the docs I found so far cover this case, and it isn't obvious in the API how to do it. > Note that this is a very specialised API for internal, sophisticated, use by frameworks, only, and should rarely if ever be used by user code. Naturally, we prioritise the user-facing APIs. Assuming you are talking about what I'm asking about: I would agree, but I would postulate (without any data at all) that most users use the threading and IO model of their chosen framework, more than using the JDK's user-facing APIs directly. I apologize in advance if I'm misunderstood the meaning of this thread. I'm new to loom so this might be likely. -Jon From ron.pressler at oracle.com Thu Nov 18 13:31:38 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Thu, 18 Nov 2021 13:31:38 +0000 Subject: loom ea based jdk18 feedback In-Reply-To: References: Message-ID: Hi. > On 18 Nov 2021, at 05:40, Jon Ross wrote: > >> So there is currently no way of exposing this particular class (which is mostly of interest for research). > > Is there another way to suspend/resume a fiber? Virtual threads are threads, and so all the usual ways of suspending and resuming threads apply. > >> Note that this is a very specialised API for internal, sophisticated, use by frameworks, only, and should rarely if ever be used by user code. Naturally, we prioritise the user-facing APIs. > > Assuming you are talking about what I'm asking about: I would agree, > but I would postulate (without any data at all) that most users use > the threading and IO model of their chosen framework, more than using > the JDK's user-facing APIs directly. I apologize in advance if I'm > misunderstood the meaning of this thread. I'm new to loom so this > might be likely. > The frameworks can use all kinds of threads provided by the JDK however they like. What is currently missing is their ability to control how virtual threads are implemented internally, just as they can?t control how platform threads are implemented internally. We will add that extra level of control once we?ve had time to properly evaluate it. ? Ron From ron.pressler at oracle.com Thu Nov 18 13:36:41 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Thu, 18 Nov 2021 13:36:41 +0000 Subject: Compensate when Pinned In-Reply-To: References: Message-ID: <580F7B77-A86C-4455-92C9-5F6588B67A75@oracle.com> Sorry, this message was stuck in the mailing-list's queue. This matter has been addressed. > On 28 Oct 2021, at 04:00, emoryzheng(??) wrote: > > Hello, > We have a test case about Loom, it can pass before; > The test case can be seen on attach file; > > But it cannot pass after this patch: > ``` > commit de90a43c7a5f0b28bd0af9271de210475808ca0c > Author: Alan Bateman > Date: Wed Sep 1 09:22:23 2021 +0100 > > Replace lock/condition objects to simplify pinned park > ``` > > Actually, this modify cause the test fail, because getCondition.await() will call tryCompensate() of ForkJoinPool eventually: > + private void parkOnCarrierThread(long nanos) { > ??? > - if (!parkPermit) { > - // wait to be signalled or interrupted > - getCondition().await(); > ??? > + if (!parkPermit) { > + U.park(false, nanos); > } > > If there are 4 ForkJoinWorkerThread, and they are all pinned, how to make vt work correct? > > Thanks? > > Miao From forax at univ-mlv.fr Thu Nov 18 16:03:41 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 18 Nov 2021 17:03:41 +0100 (CET) Subject: loom ea based jdk18 feedback In-Reply-To: References: Message-ID: <735552441.2571033.1637251421244.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "?ystein Myhre Andersen" > To: "Ron Pressler" > Cc: "dreamlike_ocean lei" , "loom-dev" > Sent: Mercredi 17 Novembre 2021 16:51:18 > Subject: Re: loom ea based jdk18 feedback > The Continuation API in a single thread is exactly what I want in my > implementation of Simula's Quasi Parallel Systems. > I have used it in an experimental implementation and it works well. > The performance of great simulation models is excellent. > > - ?ystein You can implement an API similar to the Continuation API on top of the virtual thread API. The only guarantee that you are loosing is that the platform thread can be different each time you call run(). The continuation can jump to another platform thread but given that the thread that run the continuation and the continuation can not run at the same time, the code can be thread-safe (you also have to not botch the memory effects when you switch back and forth, i hope my code is correct on that point). Obviously, it's heavier and if you have things like ThreadLocal in the mix, it will not work well, but if you start the thread that control the Continuation and the virtual thread on the same executor, it should not be too bad. regards, R?mi [1] https://github.com/forax/loom-fiber/blob/master/src/main/java/fr/umlv/loom/continuation/Continuation.java > > On Wed, Nov 17, 2021 at 4:38 PM Ron Pressler > wrote: > >> >> >> > On 17 Nov 2021, at 11:13, dreamlike_ocean lei >> wrote: >> > >> > 1, continuation api >> > >> > >> > I really hope I can directly access this api in the future version >> >> The Continuation class is fundamentally unsafe, and using it might result >> in miscompilation, as the JIT compiler bases some optimisations on the >> assumption that the current thread cannot change. So there is currently no >> way of exposing this particular class (which is mostly of interest for >> research). However, in the future, the JDK could conceivably add safe >> abstractions built on top of Continuation other than virtual threads, that >> would probably be confined to a single thread. Custom schedulers will be >> able to give you what I believe you want. >> >> > >> > Virtual thread custom scheduler >> > >> > >> > I hope you can consider reopening the api of the custom scheduler in the >> > future version >> >> That is an API we would very much like to have, but we haven?t had time to >> review yet. I don?t know yet whether or not it will make it in time for the >> first release. Note that this is a very specialised API for internal, >> sophisticated, use by frameworks, only, and should rarely if ever be used >> by user code. Naturally, we prioritise the user-facing APIs. >> >> >> ? Ron >> >> >> From oleksandr.otenko at gmail.com Thu Nov 18 16:43:36 2021 From: oleksandr.otenko at gmail.com (Alex Otenko) Date: Thu, 18 Nov 2021 16:43:36 +0000 Subject: [External] : Re: A new build and a new structured concurrency API In-Reply-To: <8fa31bea-cf3f-617d-13d3-1f211f9e7ba4@oracle.com> References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <09553679-68C7-430C-8E1A-6E31FB7B515F@oracle.com> <8fa31bea-cf3f-617d-13d3-1f211f9e7ba4@oracle.com> Message-ID: Yes, that's the behaviour that I expect, hence the question. Since shutdown makes the Futures behave like a cancel was called, why is onComplete singled out, and doesn't behave like when the Future got cancelled - i.e. is not guaranteed to be invoked on shutdown, even though guaranteed to be invoked on Future.cancel Alex On Thu, 18 Nov 2021, 11:31 Alan Bateman, wrote: > On 18/11/2021 10:02, Alex Otenko wrote: > > I see why break may be an analogue, but don't see why it is the right > one. > > > > Right now the tasks finish in one of four ways: > > > > Success with a value > > Failure with Exception > > Someone aborted, a subclass of Failure > > Shutdown > > > > And it is ok to use onComplete for three cases, but not the last? So now > > really all handling is spread across two sites, predictably requiring > more > > code and more complexity in interactions with the other three termination > > conditions. > A task completes with a result, an exception, or it is cancelled. This > will be familiar to everyone that uses Future::get. This project has not > introduced any new states or ways for a task to complete. When using the > 2-arg fork method then the onComplete operation is invoked when the task > completes, irrespective of whether it completed with a result, > exception, or was cancelled. > > The shutdown method is on StructuredExecutor, not Future. The javadoc > tries to be clear that it is for cases where you've got an interesting > result and are no longer interested in the results of other tasks. The > shutdown method closes the front door to prevent new threads from > starting. It also interrupts the threads that are running the tasks that > haven't completed yet. It also tries to make it clear that when shutdown > completes that are tasks are "done" (it links to Future::isDone). You > shouldn't need to use Future::get with this API but if you were then you > should see that Future::get wakes up when SE::shutdown is called. > > -Alan > > > > > From Alan.Bateman at oracle.com Thu Nov 18 17:11:53 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 18 Nov 2021 17:11:53 +0000 Subject: [External] : Re: A new build and a new structured concurrency API In-Reply-To: References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <09553679-68C7-430C-8E1A-6E31FB7B515F@oracle.com> <8fa31bea-cf3f-617d-13d3-1f211f9e7ba4@oracle.com> Message-ID: <198dd3e4-a8fd-d84c-32ad-c0d79084c9c0@oracle.com> On 18/11/2021 16:43, Alex Otenko wrote: > Yes, that's the behaviour that I expect, hence the question. Since > shutdown makes the Futures behave like a cancel was called, why is > onComplete singled out, and doesn't behave like when the Future got > cancelled - i.e. is not guaranteed to be invoked on shutdown, even > though guaranteed to be invoked on Future.cancel That's not the intention. If you invoke Future.cancel after the executor is shutdown then it should return false, the onComplete operation won't be called. We'll try to make the javadoc a bit clearer on this point. -Alan From pedro.lamarao at prodist.com.br Thu Nov 18 17:15:33 2021 From: pedro.lamarao at prodist.com.br (=?UTF-8?Q?Pedro_Lamar=C3=A3o?=) Date: Thu, 18 Nov 2021 14:15:33 -0300 Subject: [External] : Re: A new build and a new structured concurrency API In-Reply-To: References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <09553679-68C7-430C-8E1A-6E31FB7B515F@oracle.com> <8fa31bea-cf3f-617d-13d3-1f211f9e7ba4@oracle.com> Message-ID: When I think about a "fork/join" type of problem, I get unsure about what "task abandonment notification" could look like, since you cannot know in advance how many tasks you would have forked in the next partitioning. Pedro. Em qui., 18 de nov. de 2021 ?s 13:45, Alex Otenko < oleksandr.otenko at gmail.com> escreveu: > Yes, that's the behaviour that I expect, hence the question. Since shutdown > makes the Futures behave like a cancel was called, why is onComplete > singled out, and doesn't behave like when the Future got cancelled - i.e. > is not guaranteed to be invoked on shutdown, even though guaranteed to be > invoked on Future.cancel > > Alex > > On Thu, 18 Nov 2021, 11:31 Alan Bateman, wrote: > > > On 18/11/2021 10:02, Alex Otenko wrote: > > > I see why break may be an analogue, but don't see why it is the right > > one. > > > > > > Right now the tasks finish in one of four ways: > > > > > > Success with a value > > > Failure with Exception > > > Someone aborted, a subclass of Failure > > > Shutdown > > > > > > And it is ok to use onComplete for three cases, but not the last? So > now > > > really all handling is spread across two sites, predictably requiring > > more > > > code and more complexity in interactions with the other three > termination > > > conditions. > > A task completes with a result, an exception, or it is cancelled. This > > will be familiar to everyone that uses Future::get. This project has not > > introduced any new states or ways for a task to complete. When using the > > 2-arg fork method then the onComplete operation is invoked when the task > > completes, irrespective of whether it completed with a result, > > exception, or was cancelled. > > > > The shutdown method is on StructuredExecutor, not Future. The javadoc > > tries to be clear that it is for cases where you've got an interesting > > result and are no longer interested in the results of other tasks. The > > shutdown method closes the front door to prevent new threads from > > starting. It also interrupts the threads that are running the tasks that > > haven't completed yet. It also tries to make it clear that when shutdown > > completes that are tasks are "done" (it links to Future::isDone). You > > shouldn't need to use Future::get with this API but if you were then you > > should see that Future::get wakes up when SE::shutdown is called. > > > > -Alan > > > > > > > > > > > -- Pedro Lamar?o https://www.prodist.com.br Securing Critical Systems Tel: +55 11 4380-6585 Antes de imprimir esta mensagem e seus anexos, certifique-se que seja realmente necess?rio. Proteger o meio ambiente ? nosso dever. Before printing this e-mail or attachments, be sure it is necessary. It is in our hands to protect the environment. From eric at kolotyluk.net Thu Nov 18 17:32:05 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Thu, 18 Nov 2021 09:32:05 -0800 Subject: Thread vs Tasks Message-ID: Sorry if this is repeated, but for some reason, posting from Microsoft Windows 10 Mail does not seem to get to the list, but Gmail does? From StructuredExecutor.html#fork(java.util.concurrent.Callable,java.util.function.BiConsumer) "Starts a new thread in this executor to run the given task and an operation to run when the task completes." In my mind, I am trying to separate the concept of Thread vs Task. Is this saying that there is always a 1:1 correspondence between Thread and Task, that StructuredExecutor only spawns Threads? I was under the impression with Executor operations, such as ForkJoinPool, that there was a 1:many relationship between Worker Threads and Tasks, where each worker could handle many Tasks. Am I misunderstanding this? Indeed, it may be that for Virtual Threads it makes sense to implement a 1:1 relationship, but StructuredExecutor also supports Platform Threads, and such a 1:1 relationship might be horrible. Cheers, Eric From jonross at gmail.com Thu Nov 18 17:51:27 2021 From: jonross at gmail.com (Jon Ross) Date: Thu, 18 Nov 2021 09:51:27 -0800 Subject: loom ea based jdk18 feedback In-Reply-To: References: Message-ID: On Thu, Nov 18, 2021 at 5:31 AM Ron Pressler wrote: > > > The frameworks can use all kinds of threads provided by the JDK however they like. What is currently missing is their ability > to control how virtual threads are implemented internally, just as they can?t control how platform threads are implemented internally. > We will add that extra level of control once we?ve had time to properly evaluate it. This seems odd to me. It's a concept entirely defined and implemented by the JVM, yet it's opaque to the JVM? I'm unaware of any OS the JVM supports that has fibers, and even if it did, you'd likely just use the JVM's version to avoid mapping issues you allude to. The "All Your Blocking Are Belong to Us" section of the doc seems to imply that the JVM itself is controlling virtual threads to do exactly what I would like to do. Why do only the cool kids get to have fun? How useful would Loom be if the blocking calls in the JVM didn't have access to this feature? If you do back-end / web / network-heavy work, then it's hard for me to see how Loom benefits you w/o the JVM's blocking APIs' ability to suspend/.resume. Please correct me if you think loom provides value in this context. If you do agree, then Loom has little benefit to any app/lib that does IO outside of the JVM's APIs. I'd put netty in this camp. Most deployments use their native sockets implementation (also non-socket-based things like io_uring). If netty doesn't benefit from loom, that would be a bummer. Who's it for, if not netty? To be myopic, my field makes extensive use of IO the JVM is not aware of (not netty). I think this feature is a requirement for my use case, or I'm don't understand something fundamental. Thanks for your time, -Jon From brian.goetz at oracle.com Thu Nov 18 18:01:33 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 18 Nov 2021 18:01:33 +0000 Subject: loom ea based jdk18 feedback In-Reply-To: References: Message-ID: Let me see if I can put this in context. There?s a sub-feature that we all can imagine, and which seems broadly reasonable, that is not available yet. This sub-feature will take additional time to develop, beyond that of getting virtual threads and related to a ship-ready state. Therefore, our choices are: - Ship the first version of Loom without it, or - Delay the first version of Loom until we can support it. You?re arguing that Loom is useless, at least to you, if it doesn?t include this feature. That seems like a bit of an overstatement, but you do get to have your own opinion about what?s useful to you. But it seems a dramatic overstatement to say ?Loom is useless to *everybody* if it doesn?t have this feature.? And yet, that seems exactly what you are saying ? that the only reasonable choice is to hold Loom until this sub-feature is ready. What Ron is saying is that this sub-feature is indeed useful, and that we?d like to deliver it, but we?re not in a position to deliver it immediately, and we?d rather deliver the rest of Loom in the meantime, because Loom *is* broadly useful even without it. > On Nov 18, 2021, at 12:51 PM, Jon Ross wrote: > > On Thu, Nov 18, 2021 at 5:31 AM Ron Pressler wrote: >> >> >> The frameworks can use all kinds of threads provided by the JDK however they like. What is currently missing is their ability >> to control how virtual threads are implemented internally, just as they can?t control how platform threads are implemented internally. >> We will add that extra level of control once we?ve had time to properly evaluate it. > > This seems odd to me. It's a concept entirely defined and implemented > by the JVM, yet it's opaque to the JVM? I'm unaware of any OS the JVM > supports that has fibers, and even if it did, you'd likely just use > the JVM's version to avoid mapping issues you allude to. The "All Your > Blocking Are Belong to Us" section of the doc seems to imply that the > JVM itself is controlling virtual threads to do exactly what I would > like to do. Why do only the cool kids get to have fun? > > How useful would Loom be if the blocking calls in the JVM didn't have > access to this feature? If you do back-end / web / network-heavy > work, then it's hard for me to see how Loom benefits you w/o the JVM's > blocking APIs' ability to suspend/.resume. Please correct me if you > think loom provides value in this context. > > If you do agree, then Loom has little benefit to any app/lib that does > IO outside of the JVM's APIs. I'd put netty in this camp. Most > deployments use their native sockets implementation (also > non-socket-based things like io_uring). If netty doesn't benefit from > loom, that would be a bummer. Who's it for, if not netty? > > To be myopic, my field makes extensive use of IO the JVM is not aware > of (not netty). I think this feature is a requirement for my use case, > or I'm don't understand something fundamental. > > Thanks for your time, > -Jon From eric at kolotyluk.net Thu Nov 18 19:00:07 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Thu, 18 Nov 2021 11:00:07 -0800 Subject: loom ea based jdk18 feedback In-Reply-To: References: Message-ID: Please ship Loom ASAP. In its current form, it may not be perfect, but it's truly valuable. On Thu, Nov 18, 2021 at 10:02 AM Brian Goetz wrote: > Let me see if I can put this in context. > > There?s a sub-feature that we all can imagine, and which seems broadly > reasonable, that is not available yet. > > This sub-feature will take additional time to develop, beyond that of > getting virtual threads and related to a ship-ready state. Therefore, our > choices are: > > - Ship the first version of Loom without it, or > - Delay the first version of Loom until we can support it. > > You?re arguing that Loom is useless, at least to you, if it doesn?t > include this feature. That seems like a bit of an overstatement, but you > do get to have your own opinion about what?s useful to you. But it seems a > dramatic overstatement to say ?Loom is useless to *everybody* if it doesn?t > have this feature.? And yet, that seems exactly what you are saying ? that > the only reasonable choice is to hold Loom until this sub-feature is > ready. > > What Ron is saying is that this sub-feature is indeed useful, and that > we?d like to deliver it, but we?re not in a position to deliver it > immediately, and we?d rather deliver the rest of Loom in the meantime, > because Loom *is* broadly useful even without it. > > > > > > > On Nov 18, 2021, at 12:51 PM, Jon Ross wrote: > > > > On Thu, Nov 18, 2021 at 5:31 AM Ron Pressler > wrote: > >> > >> > >> The frameworks can use all kinds of threads provided by the JDK however > they like. What is currently missing is their ability > >> to control how virtual threads are implemented internally, just as they > can?t control how platform threads are implemented internally. > >> We will add that extra level of control once we?ve had time to properly > evaluate it. > > > > This seems odd to me. It's a concept entirely defined and implemented > > by the JVM, yet it's opaque to the JVM? I'm unaware of any OS the JVM > > supports that has fibers, and even if it did, you'd likely just use > > the JVM's version to avoid mapping issues you allude to. The "All Your > > Blocking Are Belong to Us" section of the doc seems to imply that the > > JVM itself is controlling virtual threads to do exactly what I would > > like to do. Why do only the cool kids get to have fun? > > > > How useful would Loom be if the blocking calls in the JVM didn't have > > access to this feature? If you do back-end / web / network-heavy > > work, then it's hard for me to see how Loom benefits you w/o the JVM's > > blocking APIs' ability to suspend/.resume. Please correct me if you > > think loom provides value in this context. > > > > If you do agree, then Loom has little benefit to any app/lib that does > > IO outside of the JVM's APIs. I'd put netty in this camp. Most > > deployments use their native sockets implementation (also > > non-socket-based things like io_uring). If netty doesn't benefit from > > loom, that would be a bummer. Who's it for, if not netty? > > > > To be myopic, my field makes extensive use of IO the JVM is not aware > > of (not netty). I think this feature is a requirement for my use case, > > or I'm don't understand something fundamental. > > > > Thanks for your time, > > -Jon > > From forax at univ-mlv.fr Thu Nov 18 19:22:42 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 18 Nov 2021 20:22:42 +0100 (CET) Subject: Virtual threads and executor ? Message-ID: <1200540038.2654931.1637263362471.JavaMail.zimbra@u-pem.fr> In the latest refresh of loom, a user can not set the executor anymore. That's an issue because existing codes tend to use an executor so the refactoring to introduce virtual threads is now harder. The other issue I have is that i can not create a virtual thread on a non-daemon thread anymore, so i have a code of a proxy that terminates too early when using virtual threads. What is the rational behind not letting a user to specify an Executor when creating a virtual thread ? regards, R?mi From Alan.Bateman at oracle.com Thu Nov 18 19:28:22 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 18 Nov 2021 19:28:22 +0000 Subject: loom ea based jdk18 feedback In-Reply-To: References: Message-ID: <62f8873b-95e0-d43d-5f32-68c1cec5993a@oracle.com> On 18/11/2021 17:51, Jon Ross wrote: > : > This seems odd to me. It's a concept entirely defined and implemented > by the JVM, yet it's opaque to the JVM? I'm unaware of any OS the JVM > supports that has fibers, and even if it did, you'd likely just use > the JVM's version to avoid mapping issues you allude to. The "All Your > Blocking Are Belong to Us" section of the doc seems to imply that the > JVM itself is controlling virtual threads to do exactly what I would > like to do. Why do only the cool kids get to have fun? This thread has got a bit confusing. Ron's message was about not exposing a way to use a custom scheduler in the first release. It sounds like you are asking about changing a library that does blocking I/O operations outside of the JDK to play nicely with virtual threads so they release the underlying thread to do other work. Is that right? If so, then the primitives you are looking for are LockSupport.park and unpark. -Alan From pedro.lamarao at prodist.com.br Thu Nov 18 19:43:18 2021 From: pedro.lamarao at prodist.com.br (=?UTF-8?Q?Pedro_Lamar=C3=A3o?=) Date: Thu, 18 Nov 2021 16:43:18 -0300 Subject: A new build and a new structured concurrency API In-Reply-To: References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> Message-ID: Em qua., 17 de nov. de 2021 ?s 13:49, Alan Bateman escreveu: > Can you say a few words about the exception handling? Don't you have > cases where you should abort rather than record exceptions when > traversing the links in a document? > Yes, for example the "fail fast" case common to quick turnaround cycles: test, fix, repeat. I have put another few hours on the project to change it into a "fail fast" broken link test tool. The "thread" and "executor" variant are most certainly broken: a few hours does not seem enough to do "fail fast" with threads of executors. Using StructuredExecutor.ShutdownOnFailure from the docs was easy. The general idea seems to be that of a "context" or "controller" object which must be passed around. In this exercise, using lambdas allowed capturing the handler, so passing the handler around was easy. I wonder what would be the impact if one had to create task classes. .....or maybe reusing the StructuredExecutor is not the point, should one create an "inner" StructuredExecutor instead? Atte. Pedro. From ignazb at gmail.com Thu Nov 18 20:09:31 2021 From: ignazb at gmail.com (Ignaz Birnstingl) Date: Thu, 18 Nov 2021 21:09:31 +0100 Subject: A new build and a new structured concurrency API In-Reply-To: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> Message-ID: Hi Ron, regarding the StructuredExecutor: The design of this API seems to be very VirtualThreads-specific. Did you consider using an ExecutorService instead of - or in addition to - a ThreadFactory for dealing with tasks? I could see these benefits: (a) With an ExecutorService you could regulate the concurrency level by using a thread pooling ExecutorService - or use a ThreadPerTaskExecutorService like what is done with the ThreadFactory API. (b) If the whole structured thread dump thing would be moved to ExecutorService, older applications which use ExecutorServices could benefit from it, too. I'm not sure if this is technically possible, though. Ignaz From brian.goetz at oracle.com Thu Nov 18 20:13:28 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 18 Nov 2021 20:13:28 +0000 Subject: A new build and a new structured concurrency API In-Reply-To: References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> Message-ID: Yes, we did. The ES abstraction felt too weighed down by the assumption that threads are a long-lived entity and needed to be structured into services (with independent lifecycles) to own them. Your second concern (b) is already sorted; the ES implementations in the JDK already get their threads grouped in the serviceability view. > On Nov 18, 2021, at 3:09 PM, Ignaz Birnstingl wrote: > > Hi Ron, > > regarding the StructuredExecutor: > The design of this API seems to be very VirtualThreads-specific. Did you consider using an ExecutorService instead of - or in addition to - a ThreadFactory for dealing with tasks? > I could see these benefits: > (a) With an ExecutorService you could regulate the concurrency level by using a thread pooling ExecutorService - or use a ThreadPerTaskExecutorService like what is done with the ThreadFactory API. > (b) If the whole structured thread dump thing would be moved to ExecutorService, older applications which use ExecutorServices could benefit from it, too. I'm not sure if this is technically possible, though. > > Ignaz From eric at kolotyluk.net Thu Nov 18 20:18:57 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Thu, 18 Nov 2021 12:18:57 -0800 Subject: Meaning and Usage of Tasks Message-ID: Reading some of the documentation I am getting confused about the meaning of a 'Task' and wrote about this earlier in Threads vs Tasks... Initially, these were just Runnable, and then could also be Callable (which is better). Is it interesting to note in StructuredExecutor there are different signatures for .execute(Runnable) .fork(Callable) And I appreciate the distinction because calling .submit(Runnable | Callable) can blur things, but can also see that .submit() may be more attractive to some. Also, Callable can throw a Checked Exception, whereas Runnable cannot. Can someone please explain the reason for this design change? I especially appreciate that both Runnable and Callable can be expressed with Lambda expressions, especially coming from a background of Akka/Scala, where Actors .spawn() other Actors, and can use Lambda expressions. However, in Akka Typed we often use forms such as object GreeterMain { final case class SayHello(name: String) def apply(): Behavior[SayHello] = Behaviors.setup { context => val greeter = context.spawn(Greeter(), "greeter") Behaviors.receiveMessage { message => val replyTo = context.spawn(GreeterBot(max = 3), message.name) greeter ! Greeter.Greet(message.name, replyTo) Behaviors.same } }} where the Behaviors.setup { context => ... is a Lambda that takes a 'context' Now I am not advocating adopting the Akka style, but it makes me wonder what it would look like if we had capabilities like structuredExecutor.spawn( () => {task implementation} ) structuredExecutor.spawn( context => {task implementation} ) structuredExecutor.spawn( (context, thingy) => {task implementation} ) . . . and so on, where context is something not available in the session because the structuredExecutor is available to the task implementation. I am just thinking out loud here, where not all Tasks need the context, thingy, etc., but some may benefit from them. More importantly, is there some concept of Task that goes beyond Callable, that cannot be satisfied by adding more features to Callable? I am pretty sure the Loom Architects have already walked down this path so I would like to know if they could share their thoughts on this. I am not hung up on a single .spawn() for multiple task types, but I like the name because it brings a sense of 'family' to concurrent programming. ?? In my mind, a Task is *not *a Thread, it is something else that can be executed on a Thread, but it should always be implementable by a Lambda. Cheers, Eric From ron.pressler at oracle.com Thu Nov 18 20:46:44 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Thu, 18 Nov 2021 20:46:44 +0000 Subject: [External] : Re: A new build and a new structured concurrency API In-Reply-To: References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> Message-ID: <1CFDBCE2-BE6F-407D-A554-39FFC36B3633@oracle.com> Hi. The problem is that tasks are not observable entities. You can?t get a ?task dump?, and so the relationships among tasks are reflected in their threads, but currently this can only be done if the thread is tied to a single task. As older applications would need to be changed somewhat, anyway, to enjoy structured concurrency (as even the ExecutorService API were to support structure, it would need to be changed to do so, and so the use-sites would need to be changed as well), they might as well use the new mechanism and spawn a virtual thread per task. As Brian says, the existing thread pools are also grouped in the new thread dump, but because their use is unstructured, you won?t get the full structured hierarchy (as it isn?t defined). We might consider adding a manual way to create a hierarchy of threads even without structure. ? Ron > On 18 Nov 2021, at 20:09, Ignaz Birnstingl wrote: > > Hi Ron, > > regarding the StructuredExecutor: > The design of this API seems to be very VirtualThreads-specific. Did you consider using an ExecutorService instead of - or in addition to - a ThreadFactory for dealing with tasks? > I could see these benefits: > (a) With an ExecutorService you could regulate the concurrency level by using a thread pooling ExecutorService - or use a ThreadPerTaskExecutorService like what is done with the ThreadFactory API. > (b) If the whole structured thread dump thing would be moved to ExecutorService, older applications which use ExecutorServices could benefit from it, too. I'm not sure if this is technically possible, though. > > Ignaz From ron.pressler at oracle.com Thu Nov 18 20:50:39 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Thu, 18 Nov 2021 20:50:39 +0000 Subject: Thread vs Tasks In-Reply-To: References: Message-ID: <18AFE77A-4087-47DC-B879-7C00763D8303@oracle.com> It?s up to you what kind of threads you?d like to use, but the default is, indeed virtual, as that makes more sense in more situations, and yes, StructuredExecutor will spawn a new thread for every task (the unstructured analogous mechanism is Executors.newThreadPerTaskExecutor [1]). This is because this mechanism is meant to assist not only in code organisation, but also in observability, and tasks are not observable entities. The hierarchical structure created by StructuredExecutor is, therefore, reified in the threads, and you can observe it with the new thread dump mechanism mentioned in the JEP. ? Ron [1]: https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/Executors.html#newThreadPerTaskExecutor(java.util.concurrent.ThreadFactory) > On 18 Nov 2021, at 17:32, Eric Kolotyluk wrote: > > Sorry if this is repeated, but for some reason, posting from Microsoft > Windows 10 Mail does not seem to get to the list, but Gmail does? > > From > StructuredExecutor.html#fork(java.util.concurrent.Callable,java.util.function.BiConsumer) > > > > > "Starts a new thread in this executor to run the given task and an > operation to run when the task completes." > > > > In my mind, I am trying to separate the concept of Thread vs Task. Is this > saying that there is always a 1:1 correspondence between Thread and Task, > that StructuredExecutor only spawns Threads? > > > > I was under the impression with Executor operations, such as ForkJoinPool, > that there was a 1:many relationship between Worker Threads and Tasks, > where each worker could handle many Tasks. Am I misunderstanding this? > > > > Indeed, it may be that for Virtual Threads it makes sense to implement a > 1:1 relationship, but StructuredExecutor also supports Platform Threads, > and such a 1:1 relationship might be horrible. > > > > Cheers, Eric From ron.pressler at oracle.com Thu Nov 18 20:53:31 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Thu, 18 Nov 2021 20:53:31 +0000 Subject: Virtual threads and executor ? In-Reply-To: <1200540038.2654931.1637263362471.JavaMail.zimbra@u-pem.fr> References: <1200540038.2654931.1637263362471.JavaMail.zimbra@u-pem.fr> Message-ID: The rationale is simple: that mechanism is much less mature than others because we?ve focused on higher-priority items that are relevant to more people, and so, while we?re working on it, we don?t want to hold up the rest of the features in the project, so we took it out until we feel comfortable enough with its design and operation. ? Ron > On 18 Nov 2021, at 19:22, Remi Forax wrote: > > In the latest refresh of loom, a user can not set the executor anymore. > That's an issue because existing codes tend to use an executor so the refactoring to introduce virtual threads is now harder. > The other issue I have is that i can not create a virtual thread on a non-daemon thread anymore, so i have a code of a proxy that terminates too early when using virtual threads. > > What is the rational behind not letting a user to specify an Executor when creating a virtual thread ? > > regards, > R?mi From ron.pressler at oracle.com Thu Nov 18 21:06:33 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Thu, 18 Nov 2021 21:06:33 +0000 Subject: Meaning and Usage of Tasks In-Reply-To: References: Message-ID: <34A87C94-9518-4E51-9F9E-9BBC7296D335@oracle.com> You bring up multiple points, so let me try and address them. A task is, indeed, not a thread, and, as you say, I would simply consider it to be some computation, usually expressible as a lambda expression/method reference. Because StructuredExecutor spawns a new thread for each forked task, we might sometimes use the terms interchangeably, but only in this context. As to the method names and signatures, the execute method is there simply so that StructuredExecutor could implement the Executor interface that declares it. You?ll find something similar in ExecutorService, where there?s a method called executor, that takes a Runnable and returns void, and methods called submit, which take a Callable and return a Future. StructuredExecutor.fork is analogous to ExecutorService.submit. Now, ExecutorService also has an override of submit that takes a Runnable (and returns a Future), in addition to the void execute method. We could certainly add a similar override of fork, but it didn?t seem particularly urgent at this point in time. You can always turn a Runnable into a Callable with the Executors.callable [1] helper method. If you find this to be too much of an inconvenience, please let us know. ? Ron [1]: https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/Executors.html#callable(java.lang.Runnable) > On 18 Nov 2021, at 20:18, Eric Kolotyluk wrote: > > Reading some of the documentation I am getting confused about the meaning > of a 'Task' and wrote about this earlier in Threads vs Tasks... > > Initially, these were just Runnable, and then could also be Callable (which > is better). Is it interesting to note in StructuredExecutor there are > different signatures for > > .execute(Runnable) > .fork(Callable) > > And I appreciate the distinction because calling .submit(Runnable | > Callable) can blur things, but can also see that .submit() may be more > attractive to some. Also, Callable can throw a Checked Exception, whereas > Runnable cannot. Can someone please explain the reason for this design > change? > > I especially appreciate that both Runnable and Callable can be expressed > with Lambda expressions, especially coming from a background of Akka/Scala, > where Actors .spawn() other Actors, and can use Lambda expressions. > However, in Akka Typed we often use forms such as > > object GreeterMain { > > final case class SayHello(name: String) > > def apply(): Behavior[SayHello] = > Behaviors.setup { context => > val greeter = context.spawn(Greeter(), "greeter") > > Behaviors.receiveMessage { message => > val replyTo = context.spawn(GreeterBot(max = 3), message.name) > greeter ! Greeter.Greet(message.name, replyTo) > Behaviors.same > } > }} > > where the Behaviors.setup { context => ... is a Lambda that takes a > 'context' > > Now I am not advocating adopting the Akka style, but it makes me wonder > what it would look like if we had capabilities like > > structuredExecutor.spawn( () => {task implementation} ) > structuredExecutor.spawn( context => {task implementation} ) > structuredExecutor.spawn( (context, thingy) => {task implementation} ) > . . . > > and so on, where context is something not available in the session because > the structuredExecutor is available to the task implementation. I am just > thinking out loud here, where not all Tasks need the context, thingy, etc., > but some may benefit from them. More importantly, is there some concept of > Task that goes beyond Callable, that cannot be satisfied by adding more > features to Callable? > > I am pretty sure the Loom Architects have already walked down this path so > I would like to know if they could share their thoughts on this. > > I am not hung up on a single .spawn() for multiple task types, but I like > the name because it brings a sense of 'family' to concurrent programming. ?? > > In my mind, a Task is *not *a Thread, it is something else that can be > executed on a Thread, but it should always be implementable by a Lambda. > > Cheers, Eric From jonross at gmail.com Thu Nov 18 21:13:12 2021 From: jonross at gmail.com (Jon Ross) Date: Thu, 18 Nov 2021 13:13:12 -0800 Subject: loom ea based jdk18 feedback In-Reply-To: <62f8873b-95e0-d43d-5f32-68c1cec5993a@oracle.com> References: <62f8873b-95e0-d43d-5f32-68c1cec5993a@oracle.com> Message-ID: On Thu, Nov 18, 2021 at 11:28 AM Alan Bateman wrote: > > On 18/11/2021 17:51, Jon Ross wrote: > > : > This thread has got a bit confusing. Ron's message was about not > exposing a way to use a custom scheduler in the first release. It sounds > like you are asking about changing a library that does blocking I/O > operations outside of the JDK to play nicely with virtual threads so > they release the underlying thread to do other work. Is that right? If > so, then the primitives you are looking for are LockSupport.park and unpark. > Thank you Alen for the disambiguation. I apologize if I muddled things up. I will need to experiment a bit, but park/unpark does look like what I am looking for, but I think I might need the custom scheduler as well. For virtual threads, when you unpark, what determines which OS thread will the virtual thread be run on? The Executor in sope? Something else? The pathological case is a single-OS-threaded app that only wants to use the main() OS thread. Does unpark of virtual thread work in this case? Does it run the unpark'd code on the thread that called unpark() and unpark returns when the virtual thread is parked again? Or are they running in parallel w/ the JVM task "switching" on a single OS thread? or other? Is it possible to have os-thread control w/o the custom scheduler? -Jon From eric at kolotyluk.net Thu Nov 18 22:13:09 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Thu, 18 Nov 2021 14:13:09 -0800 Subject: Thread vs Tasks In-Reply-To: <18AFE77A-4087-47DC-B879-7C00763D8303@oracle.com> References: <18AFE77A-4087-47DC-B879-7C00763D8303@oracle.com> Message-ID: Sorry, forgot to reply to all thought Tasks were observable and manageable via their Futures? Okay, if StructuredExecutor is like ThreadPerTaskExecutor, then that makes sense to me. This allows for the possibility of other types of StructuredExecutor in the future... Instead of creating a new type of Executor, why not create another object that is passed to the Executor as a parameter, the way the ThreadFactory is passed. For example, via a SessionFactory, where one of the Session types is StructuredSession, then all Executors could be extended with Structured Concurrency. Then we could have something like var virtualThreadFactory = Thread.ofVirtual.factory() var structuredSession = Executors.newStructuredSession(. . .) var structuredExecutor = Executors.newThreadPerTaskExecutor(virtualTheadFactory, structuredSession) In this way, Structured Concurrency is more applicable to more contexts... not that you need to implement it for all contexts now... maybe just .newThreadPerTaskExecutor() for now... Also, .fork() and .join() would be session methods, not executor methods... This introduced two new concepts, Sessions, and Structured Sessions... Just thinking out loud again... Cheers, Eric From ron.pressler at oracle.com Thu Nov 18 22:53:02 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Thu, 18 Nov 2021 22:53:02 +0000 Subject: [External] : Re: Thread vs Tasks In-Reply-To: References: <18AFE77A-4087-47DC-B879-7C00763D8303@oracle.com> Message-ID: <2BBEF2A8-2E30-4B1B-B48C-ED4351585D90@oracle.com> By ?observable? I mean observable by tooling, i.e. something that directly recorded, accessed, or manipulated by debuggers, profilers and troubleshooting tools. Threads are already a central entity for those tools; futures are not. Because structure for us means not only clearer, more correct code, but observability, and because the hierarchy is reified in *threads* so that it can be observed by tools, things that don?t spawn a thread per task can?t currently provide the structure we?re seeking. Also, using a thread-per-task is almost always safer and more correct than a shared thread pool, and switching to a construct that does it is no more work than switching to using other kinds of structured APIs. But rather than do a random walk through the large solution space, we always try to focus on the *problem* (and that?s the way most JEPs are structured). That is why the most powerful, helpful, and wise feedback takes the form, ?I used this thing and ran into this problem.? Pinpointing and clarifying a problem is often harder than picking a solution. Focus on that: what problem did you run into when using StructuredExecutor that prompted you to look for other solutions? Thoughts of the kind, ?but wouldn?t be even cooler if?? are perfectly fine, but the real leaps are made when we identify real problems and solve them. ? Ron On 18 Nov 2021, at 22:13, Eric Kolotyluk > wrote: Sorry, forgot to reply to all thought Tasks were observable and manageable via their Futures? Okay, if StructuredExecutor is like ThreadPerTaskExecutor, then that makes sense to me. This allows for the possibility of other types of StructuredExecutor in the future... Instead of creating a new type of Executor, why not create another object that is passed to the Executor as a parameter, the way the ThreadFactory is passed. For example, via a SessionFactory, where one of the Session types is StructuredSession, then all Executors could be extended with Structured Concurrency. Then we could have something like var virtualThreadFactory = Thread.ofVirtual.factory() var structuredSession = Executors.newStructuredSession(. . .) var structuredExecutor = Executors.newThreadPerTaskExecutor(virtualTheadFactory, structuredSession) In this way, Structured Concurrency is more applicable to more contexts... not that you need to implement it for all contexts now... maybe just .newThreadPerTaskExecutor() for now... Also, .fork() and .join() would be session methods, not executor methods... This introduced two new concepts, Sessions, and Structured Sessions... Just thinking out loud again... Cheers, Eric From eric at kolotyluk.net Thu Nov 18 23:27:54 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Thu, 18 Nov 2021 15:27:54 -0800 Subject: [External] : Re: Thread vs Tasks In-Reply-To: <2BBEF2A8-2E30-4B1B-B48C-ED4351585D90@oracle.com> References: <18AFE77A-4087-47DC-B879-7C00763D8303@oracle.com> <2BBEF2A8-2E30-4B1B-B48C-ED4351585D90@oracle.com> Message-ID: Ah, thanks for the explanation of observable. Here are the problems I ran into 1. Understanding the JavaDoc for StructuredExecutor, as I had to ask questions here, that could have been addressed by clearer documentation. I would be happy to offer to revise the documentation. 2. Understanding the ontology and taxonomy of Project Loom, and Java Concurrency as a whole. Sometimes this is expressed in documentation, but often it can be revealed in design. Again, I had a problem figuring this out, and I still have a long way to go. 3. My ?but wouldn?t be even cooler if?? was an attempt to see a problem down the road that might affect me... 4. StructuredExecutor introduces "sessions" which in this case is a non-overlapping sequence of phases Open -> Forking -> Joining -> Error handling and other housekeeping -> Closed. This is very new and different and it took me a while to really appreciate it by trying to document it myself, but in the Loom design and documentation, it does not reveal itself to me easily. Overall, I think sessions are a really great concept where Structured Sessions are one of several types that could be useful. 5. Structure Concurrency introduces new concepts, that might apply elsewhere, but are localized to StructureExecutor. Granted, in the beginning, this is more a Proof of Concept or Proof of Technology and may change later as a preview feature. Again, I don't want to dissuade the path you are on, so this is more of what I would like to see in the future. Cheers, Eric On Thu, Nov 18, 2021 at 2:53 PM Ron Pressler wrote: > By ?observable? I mean observable by tooling, i.e. something that directly > recorded, accessed, or manipulated by debuggers, profilers and > troubleshooting tools. Threads are already a central entity for those > tools; futures are not. Because structure for us means not only clearer, > more correct code, but observability, and because the hierarchy is reified > in *threads* so that it can be observed by tools, things that don?t spawn a > thread per task can?t currently provide the structure we?re seeking. > > Also, using a thread-per-task is almost always safer and more correct than > a shared thread pool, and switching to a construct that does it is no more > work than switching to using other kinds of structured APIs. > > But rather than do a random walk through the large solution space, we > always try to focus on the *problem* (and that?s the way most JEPs are > structured). That is why the most powerful, helpful, and wise feedback > takes the form, ?I used this thing and ran into this problem.? Pinpointing > and clarifying a problem is often harder than picking a solution. Focus on > that: what problem did you run into when using StructuredExecutor that > prompted you to look for other solutions? > > Thoughts of the kind, ?but wouldn?t be even cooler if?? are perfectly > fine, but the real leaps are made when we identify real problems and solve > them. > > ? Ron > > On 18 Nov 2021, at 22:13, Eric Kolotyluk wrote: > > Sorry, forgot to reply to all > > thought Tasks were observable and manageable via their Futures? > > Okay, if StructuredExecutor is like ThreadPerTaskExecutor, then that makes > sense to me. This allows for the possibility of other types of > StructuredExecutor in the future... > > Instead of creating a new type of Executor, why not create another object > that is passed to the Executor as a parameter, the way the ThreadFactory is > passed. For example, via a SessionFactory, where one of the Session types > is StructuredSession, then all Executors could be extended with Structured > Concurrency. > > Then we could have something like > > var virtualThreadFactory = Thread.ofVirtual.factory() > var structuredSession = Executors.newStructuredSession(. . .) > var structuredExecutor = > Executors.newThreadPerTaskExecutor(virtualTheadFactory, structuredSession) > > In this way, Structured Concurrency is more applicable to more contexts... > not that you need to implement it for all contexts now... maybe just > .newThreadPerTaskExecutor() for now... > > Also, .fork() and .join() would be session methods, not executor methods... > > This introduced two new concepts, Sessions, and Structured Sessions... > > Just thinking out loud again... > > Cheers, Eric > > > From ignazb at gmail.com Fri Nov 19 08:19:37 2021 From: ignazb at gmail.com (Ignaz Birnstingl) Date: Fri, 19 Nov 2021 09:19:37 +0100 Subject: [External] : Re: A new build and a new structured concurrency API In-Reply-To: <1CFDBCE2-BE6F-407D-A554-39FFC36B3633@oracle.com> References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <1CFDBCE2-BE6F-407D-A554-39FFC36B3633@oracle.com> Message-ID: Hi, > The problem is that tasks are not observable entities. You can?t get a > ?task dump?, and so the relationships among tasks are reflected in their > threads, but currently this can only be done if the thread is tied to a > single task. But at any given time an ExecutorService's worker thread _is_ tied to a single task, or am I missing something? The only exception that comes to mind is a direct executor [1]. > As older applications would need to be changed somewhat, anyway, to > enjoy structured concurrency (as even the ExecutorService API were to > support structure, it would need to be changed to do so, and so the > use-sites would need to be changed as well), they might as well use the > new mechanism and spawn a virtual thread per task. Ok I think this was a misunderstanding. I thought that instead of doing try (var s = StructuredExecutor.open("foo", VirtualThread::new)) ... you would do try (var s = StructuredExecutor.open("foo", Executors. newVirtualThreadPerTaskExecutor())) ... but you could also do // Limit parallelism to 5 try (var s = StructuredExecutor.open("foo", Executors. newFixedThreadPool(5))) ... -- Ignaz [1] https://guava.dev/releases/19.0/api/docs/com/google/common/util/concurrent/MoreExecutors.html#directExecutor() From oleksandr.otenko at gmail.com Fri Nov 19 09:00:51 2021 From: oleksandr.otenko at gmail.com (Alex Otenko) Date: Fri, 19 Nov 2021 09:00:51 +0000 Subject: [External] : Re: A new build and a new structured concurrency API In-Reply-To: <198dd3e4-a8fd-d84c-32ad-c0d79084c9c0@oracle.com> References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <09553679-68C7-430C-8E1A-6E31FB7B515F@oracle.com> <8fa31bea-cf3f-617d-13d3-1f211f9e7ba4@oracle.com> <198dd3e4-a8fd-d84c-32ad-c0d79084c9c0@oracle.com> Message-ID: I think I understand what problem onComplete is solving. Basically, everything you want can be done in finally clause of the task, except cancel all - because that's going to kill the task that calls it. "Cancel all except me" is hard to implement. So you want something like a finally, but which gets invoked after the task's Future has settled. Yes, if you limit the functionality of onComplete to conditionally cancel all, then there is no need to invoke it after having cancelled all once - after all, can't un-cancel, and we limit its purpose to just cancellation of all, no other aggregation, clean up or introspection of the finished tasks. Alex On Thu, 18 Nov 2021, 17:12 Alan Bateman, wrote: > On 18/11/2021 16:43, Alex Otenko wrote: > > Yes, that's the behaviour that I expect, hence the question. Since > > shutdown makes the Futures behave like a cancel was called, why is > > onComplete singled out, and doesn't behave like when the Future got > > cancelled - i.e. is not guaranteed to be invoked on shutdown, even > > though guaranteed to be invoked on Future.cancel > > That's not the intention. If you invoke Future.cancel after the executor > is shutdown then it should return false, the onComplete operation won't > be called. We'll try to make the javadoc a bit clearer on this point. > > -Alan > > > From ron.pressler at oracle.com Fri Nov 19 09:30:07 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Fri, 19 Nov 2021 09:30:07 +0000 Subject: [External] : Re: A new build and a new structured concurrency API In-Reply-To: References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <09553679-68C7-430C-8E1A-6E31FB7B515F@oracle.com> <8fa31bea-cf3f-617d-13d3-1f211f9e7ba4@oracle.com> <198dd3e4-a8fd-d84c-32ad-c0d79084c9c0@oracle.com> Message-ID: <257223B2-DBAE-4165-B356-FEB0535D11EA@oracle.com> You *can* use a finally clause instead of onComplete. It?s even more general. The purpose of the completion handler parameter is to perform the role you say in a way that?s nicely factored out into a ?policy object.? It?s a convenience mechanism, not an essential one. ? Ron > On 19 Nov 2021, at 09:00, Alex Otenko wrote: > > I think I understand what problem onComplete is solving. > > Basically, everything you want can be done in finally clause of the task, > except cancel all - because that's going to kill the task that calls it. > "Cancel all except me" is hard to implement. So you want something like a > finally, but which gets invoked after the task's Future has settled. > > Yes, if you limit the functionality of onComplete to conditionally cancel > all, then there is no need to invoke it after having cancelled all once - > after all, can't un-cancel, and we limit its purpose to just cancellation > of all, no other aggregation, clean up or introspection of the finished > tasks. > > Alex From ron.pressler at oracle.com Fri Nov 19 09:37:36 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Fri, 19 Nov 2021 09:37:36 +0000 Subject: [External] : Re: A new build and a new structured concurrency API In-Reply-To: References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <1CFDBCE2-BE6F-407D-A554-39FFC36B3633@oracle.com> Message-ID: <71EF4111-29D7-4E4D-AA4F-0B66F166D6AF@oracle.com> > On 19 Nov 2021, at 08:19, Ignaz Birnstingl wrote: > > Hi, > >> The problem is that tasks are not observable entities. You can?t get a ?task dump?, and so the relationships among tasks are reflected in their threads, but currently this can only be done if the thread is tied to a single task. > > But at any given time an ExecutorService's worker thread _is_ tied to a single task, or am I missing something? The only exception that comes to mind is a direct executor [1]. That would mean that the thread hierarchy would constantly change; one moment thread A would be B?s parent, and the next it would be it?s child. I?m not saying we rule that out, but we?d rather start with something simpler and stabler. But my question is, what problem that you ran into with StructuredExecutor are you trying to solve? > > but you could also do > > // Limit parallelism to 5 > try (var s = StructuredExecutor.open("foo", Executors. > newFixedThreadPool(5))) ? > Ah, so if the problem is limiting concurrency, the solution isn?t a thread pool; limiting concurrency isn?t thread pool?s main purpose, and we use them for that purpose only because we use them, anyway, so we might as well use them for that. What we really want to do when we limit concurrency is limit concurrent access to a particular resource ? say, the database. A much better way to do that is to employ a semaphore guarding the access to the resource. This way, it can be accessed from any thread, and still limit concurrency. I would ask that, instead of trying to think of ways of making StructuredExecutor better, you focus on what *problems* you run into when you?re using StructuredExecutor. ? Ron From Alan.Bateman at oracle.com Fri Nov 19 11:04:02 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 19 Nov 2021 11:04:02 +0000 Subject: loom ea based jdk18 feedback In-Reply-To: References: <62f8873b-95e0-d43d-5f32-68c1cec5993a@oracle.com> Message-ID: On 18/11/2021 21:13, Jon Ross wrote: > : > Thank you Alen for the disambiguation. I apologize if I muddled things up. > > I will need to experiment a bit, but park/unpark does look like what I > am looking for, but I think I might need the custom scheduler as well. > > For virtual threads, when you unpark, what determines which OS thread > will the virtual thread be run on? The Executor in sope? Something > else? > > The pathological case is a single-OS-threaded app that only wants to > use the main() OS thread. Does unpark of virtual thread work in this > case? Does it run the unpark'd code on the thread that called > unpark() and unpark returns when the virtual thread is parked again? > Or are they running in parallel w/ the JVM task "switching" on a > single OS thread? or other? Is it possible to have os-thread control > w/o the custom scheduler? If you are doing your own implementation of blocking I/O outside of the JDK then park/unpark should be sufficient. Unpark will queue the virtual thread to the scheduler so it continues on one of its thread. If you really want to restrict the scheduler to 1 thread then run with -Djdk.defaultScheduler.maxPoolSize=1. You are in very advanced territory if want fine control on the OS threads, this isn't a priority for this project right now but we will come back to it. -Alan From oleksandr.otenko at gmail.com Fri Nov 19 13:12:34 2021 From: oleksandr.otenko at gmail.com (Alex Otenko) Date: Fri, 19 Nov 2021 13:12:34 +0000 Subject: [External] : Re: A new build and a new structured concurrency API In-Reply-To: <257223B2-DBAE-4165-B356-FEB0535D11EA@oracle.com> References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <09553679-68C7-430C-8E1A-6E31FB7B515F@oracle.com> <8fa31bea-cf3f-617d-13d3-1f211f9e7ba4@oracle.com> <198dd3e4-a8fd-d84c-32ad-c0d79084c9c0@oracle.com> <257223B2-DBAE-4165-B356-FEB0535D11EA@oracle.com> Message-ID: Thanks. Can this be taken literally to mean that a task could shutdown() in finally to achieve exactly the same effect, and that won't cancel its own Future? (I.e. that if called from inside a task, there is a notion of "me", and "cancel all except me" is doable) Alex On Fri, 19 Nov 2021, 09:30 Ron Pressler, wrote: > You *can* use a finally clause instead of onComplete. It?s even more > general. The purpose of the completion handler parameter is to perform the > role you say in a way that?s nicely factored out into a ?policy object.? > It?s a convenience mechanism, not an essential one. > > ? Ron > > > On 19 Nov 2021, at 09:00, Alex Otenko > wrote: > > > > I think I understand what problem onComplete is solving. > > > > Basically, everything you want can be done in finally clause of the task, > > except cancel all - because that's going to kill the task that calls it. > > "Cancel all except me" is hard to implement. So you want something like a > > finally, but which gets invoked after the task's Future has settled. > > > > Yes, if you limit the functionality of onComplete to conditionally cancel > > all, then there is no need to invoke it after having cancelled all once - > > after all, can't un-cancel, and we limit its purpose to just cancellation > > of all, no other aggregation, clean up or introspection of the finished > > tasks. > > > > Alex > > From ron.pressler at oracle.com Fri Nov 19 13:54:05 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Fri, 19 Nov 2021 13:54:05 +0000 Subject: [External] : Re: A new build and a new structured concurrency API In-Reply-To: References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <09553679-68C7-430C-8E1A-6E31FB7B515F@oracle.com> <8fa31bea-cf3f-617d-13d3-1f211f9e7ba4@oracle.com> <198dd3e4-a8fd-d84c-32ad-c0d79084c9c0@oracle.com> <257223B2-DBAE-4165-B356-FEB0535D11EA@oracle.com> Message-ID: <1175F4A9-F995-4F30-B9A3-4DAC1C3BAD49@oracle.com> Yes, you can certainly call shutdown manually rather than use the completion handler. It will not interrupt its own thread. What happens to the future is more subtle, but advanced uses that prefer to call shutdown manually rather than in the completion handler won?t be interested in the future either. Regardless, in most situations you should just use the handlers. Is there a particular problem you?ve run into or are you just asking out of curiosity to understand the finer points of the mechanism? ? Ron On 19 Nov 2021, at 13:12, Alex Otenko > wrote: Thanks. Can this be taken literally to mean that a task could shutdown() in finally to achieve exactly the same effect, and that won't cancel its own Future? (I.e. that if called from inside a task, there is a notion of "me", and "cancel all except me" is doable) Alex On Fri, 19 Nov 2021, 09:30 Ron Pressler, > wrote: You *can* use a finally clause instead of onComplete. It?s even more general. The purpose of the completion handler parameter is to perform the role you say in a way that?s nicely factored out into a ?policy object.? It?s a convenience mechanism, not an essential one. ? Ron > On 19 Nov 2021, at 09:00, Alex Otenko > wrote: > > I think I understand what problem onComplete is solving. > > Basically, everything you want can be done in finally clause of the task, > except cancel all - because that's going to kill the task that calls it. > "Cancel all except me" is hard to implement. So you want something like a > finally, but which gets invoked after the task's Future has settled. > > Yes, if you limit the functionality of onComplete to conditionally cancel > all, then there is no need to invoke it after having cancelled all once - > after all, can't un-cancel, and we limit its purpose to just cancellation > of all, no other aggregation, clean up or introspection of the finished > tasks. > > Alex From oleksandr.otenko at gmail.com Fri Nov 19 14:39:11 2021 From: oleksandr.otenko at gmail.com (Alex Otenko) Date: Fri, 19 Nov 2021 14:39:11 +0000 Subject: [External] : Re: A new build and a new structured concurrency API In-Reply-To: <1175F4A9-F995-4F30-B9A3-4DAC1C3BAD49@oracle.com> References: <6EE1CAE9-C89D-47B9-9065-D21957A6ADC9@oracle.com> <09553679-68C7-430C-8E1A-6E31FB7B515F@oracle.com> <8fa31bea-cf3f-617d-13d3-1f211f9e7ba4@oracle.com> <198dd3e4-a8fd-d84c-32ad-c0d79084c9c0@oracle.com> <257223B2-DBAE-4165-B356-FEB0535D11EA@oracle.com> <1175F4A9-F995-4F30-B9A3-4DAC1C3BAD49@oracle.com> Message-ID: No problems so far, exploring the mechanism to understand the edge cases to be aware of, and what would be considered misuse of the API. This particular clause caught my eye because I have had trouble with complexity explosion with similar absence of notifications on cancellations in other APIs, so needed to know what makes it OK here. Alex On Fri, 19 Nov 2021, 13:54 Ron Pressler, wrote: > Yes, you can certainly call shutdown manually rather than use the > completion handler. It will not interrupt its own thread. What happens to > the future is more subtle, but advanced uses that prefer to call shutdown > manually rather than in the completion handler won?t be interested in the > future either. > > Regardless, in most situations you should just use the handlers. > > Is there a particular problem you?ve run into or are you just asking out > of curiosity to understand the finer points of the mechanism? > > ? Ron > > On 19 Nov 2021, at 13:12, Alex Otenko wrote: > > Thanks. Can this be taken literally to mean that a task could shutdown() > in finally to achieve exactly the same effect, and that won't cancel its > own Future? (I.e. that if called from inside a task, there is a notion of > "me", and "cancel all except me" is doable) > > Alex > > On Fri, 19 Nov 2021, 09:30 Ron Pressler, wrote: > >> You *can* use a finally clause instead of onComplete. It?s even more >> general. The purpose of the completion handler parameter is to perform the >> role you say in a way that?s nicely factored out into a ?policy object.? >> It?s a convenience mechanism, not an essential one. >> >> ? Ron >> >> > On 19 Nov 2021, at 09:00, Alex Otenko >> wrote: >> > >> > I think I understand what problem onComplete is solving. >> > >> > Basically, everything you want can be done in finally clause of the >> task, >> > except cancel all - because that's going to kill the task that calls it. >> > "Cancel all except me" is hard to implement. So you want something like >> a >> > finally, but which gets invoked after the task's Future has settled. >> > >> > Yes, if you limit the functionality of onComplete to conditionally >> cancel >> > all, then there is no need to invoke it after having cancelled all once >> - >> > after all, can't un-cancel, and we limit its purpose to just >> cancellation >> > of all, no other aggregation, clean up or introspection of the finished >> > tasks. >> > >> > Alex >> >> > From forax at univ-mlv.fr Fri Nov 19 18:26:15 2021 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 19 Nov 2021 19:26:15 +0100 (CET) Subject: Virtual threads and executor ? In-Reply-To: References: <1200540038.2654931.1637263362471.JavaMail.zimbra@u-pem.fr> Message-ID: <1726154913.3175687.1637346375316.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "Ron Pressler" > To: "Remi Forax" > Cc: "loom-dev" > Sent: Jeudi 18 Novembre 2021 21:53:31 > Subject: Re: Virtual threads and executor ? > The rationale is simple: that mechanism is much less mature than others because > we?ve focused on higher-priority items that are relevant to more people, and > so, while we?re working on it, we don?t want to hold up the rest of the > features in the project, so we took it out until we feel comfortable enough > with its design and operation. I'm not sure to understand what design really encompass here given that a virtual already take an executor. For me, this decision will hamper the adoption of Loom, because it's now harder to use virtual thread where previously platform thread were used, you can not simply swap the executors to use a virtual thread executor. Anyway as an exercise i've re-implemented ExecutorService on top of StructuredExecutor, (obviously the implementation is quite awful [1]) but the code of my proxy now works ! > > ? Ron R?mi [1] https://github.com/forax/loom-fiber/blob/master/src/main/java/fr/umlv/loom/executor/VirtualThreadExecutor.java > >> On 18 Nov 2021, at 19:22, Remi Forax wrote: >> >> In the latest refresh of loom, a user can not set the executor anymore. >> That's an issue because existing codes tend to use an executor so the >> refactoring to introduce virtual threads is now harder. >> The other issue I have is that i can not create a virtual thread on a non-daemon >> thread anymore, so i have a code of a proxy that terminates too early when >> using virtual threads. >> >> What is the rational behind not letting a user to specify an Executor when >> creating a virtual thread ? >> >> regards, > > R?mi From ron.pressler at oracle.com Fri Nov 19 18:34:21 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Fri, 19 Nov 2021 18:34:21 +0000 Subject: [External] : Re: Virtual threads and executor ? In-Reply-To: <1726154913.3175687.1637346375316.JavaMail.zimbra@u-pem.fr> References: <1200540038.2654931.1637263362471.JavaMail.zimbra@u-pem.fr> <1726154913.3175687.1637346375316.JavaMail.zimbra@u-pem.fr> Message-ID: <9AF004AB-64CF-40C7-A225-607A47E3F0F1@oracle.com> > On 19 Nov 2021, at 18:26, forax at univ-mlv.fr wrote: > > ----- Original Message ----- >> From: "Ron Pressler" >> To: "Remi Forax" >> Cc: "loom-dev" >> Sent: Jeudi 18 Novembre 2021 21:53:31 >> Subject: Re: Virtual threads and executor ? > >> The rationale is simple: that mechanism is much less mature than others because >> we?ve focused on higher-priority items that are relevant to more people, and >> so, while we?re working on it, we don?t want to hold up the rest of the >> features in the project, so we took it out until we feel comfortable enough >> with its design and operation. > > I'm not sure to understand what design really encompass here given that a virtual already take an executor. > > For me, this decision will hamper the adoption of Loom, because it's now harder to use virtual thread where previously platform thread were used, > you can not simply swap the executors to use a virtual thread executor. Oh, I don?t think we?re talking about the same thing. To migrate to virtual threads, start by replacing existing ExecutorServices with Executors.newVirtualThreadPerTaskExecutor/newThreadPerTaskExecutor. All that?s there. I thought you were talking about the super-advanced feature of custom schedulers, which are still not mature enough, and don?t aid in migration. ? Ron From mbazos at gmail.com Fri Nov 19 19:15:11 2021 From: mbazos at gmail.com (Michael Bazos) Date: Fri, 19 Nov 2021 14:15:11 -0500 Subject: Questions on Build 18-loom+5-274 (2021/11/15) Message-ID: I started doing some experimenting with project loom an observed a few things and wasn't sure how to explain them or why it was happening: 1. I noticed when using Executors.newVirtualThreadPerTaskExecutor() submitting tasks and then calling 'shutdown()' on the executor service, the virtual thread per task executor does not wait for tasks to finish. This seems to behave a little differently than the OS based thread pool executors. I assume this is intended but just wanted to know why. 2. Playing with StructuredExecutor I can see the example of using it with try-with-resources which is clean and looks nice. I was surprised to see `isShutdown()` as private on the StructuredExecutor. I am just wondering if a client didn't use try-with-resources there would be some value in allowing a client to know if the executor is shutdown or not. My best guess is the intention here is to minimize what is exposed from the API. 3. My final question which is semi related to Question 2 I haven't done any benchmarking myself yet but I know creating OS based executor thread pools can be considered an "expensive" operation. Obviously this is very different when doing this with virtual thread task executor. Does using virtual thread task executor mean this is cheap to create and shutdown? Typically in client code you wouldn't want to create/destroy task executors during the lifecycle of an application. Also I did some tests and I couldn't believe how many virtual threads I could spin up on my machine versus OS threads. Seems like memory would be the limit but the difference was ~3000 OS threads vs ~5 million+ virtual threads. When I have time going to integrate the early loom builds into some real applications to see how it behaves. I very much look forward to not having to worry about configuring thread pools in the future, very excited and keep up the good work! Mike From jonross at gmail.com Fri Nov 19 19:40:09 2021 From: jonross at gmail.com (Jon Ross) Date: Fri, 19 Nov 2021 11:40:09 -0800 Subject: loom ea based jdk18 feedback In-Reply-To: References: <62f8873b-95e0-d43d-5f32-68c1cec5993a@oracle.com> Message-ID: On Fri, Nov 19, 2021 at 3:04 AM Alan Bateman wrote: > > On 18/11/2021 21:13, Jon Ross wrote: > If you are doing your own implementation of blocking I/O outside of the > JDK then park/unpark should be sufficient. Unpark will queue the virtual > thread to the scheduler so it continues on one of its thread. If you > really want to restrict the scheduler to 1 thread then run with > -Djdk.defaultScheduler.maxPoolSize=1. You are in very advanced territory > if want fine control on the OS threads, this isn't a priority for this > project right now but we will come back to it. Yes, having control over OS threads is a requirement for me. So is controlling how/when virtual threads run. I will come back to loom another time. The rest of this email is entirely for your benefit because you are actively soliciting feedback. You are free to do with this what you will, including completely ignoring it. I am not (as some others in this thread have claimed) arguing, or advocating that you do anything different. This is entirely an offer to help you understand a customer's POV of loom for their specific use case. I am not asking for anything at all, not even for you to care about my use case. I guess the TL:DR is that I don't think this is very "advanced territory". I come from a FinTech background. Most of the frameworks in the java low-latency FinTech space (LMAX, the OpenHFT stuff, Real Logic / SBE, Nasdaq, etc) use some custom alternative to NIO. From a simple JNI epoll implementation to more exotic APIs that are not BSD socket-based. They can fallback to NIO for local testing, but are rarely deployed using NIO. The event-loop IO API is the only IO used. The "tasks" are short-lived, and always return to the same event-loop to wait on the next thing. Everything is callback-based. These frameworks are fairly obsessed with avoiding context switches, as a context switch is a material % of a tasks' budgeted work time. I don't think loom will get much adoption in this space as it exists today. I do not think this claim is an "overstatement" or hyperbolic. Stackless coroutines work great for these types of frameworks. In C++/Rust/Zig/Scala(macro)/Kotlin the compiler is hiding the callback, so the required control still exists, and it moves the API from callbacks to something that looks synchronous but isn't. I think this is the main benefit of any type of fiber/coroutine for these types of things. Clean up the API. The cost over callbacks is small (0 to 10s of nanos), and the event-loop is a bit more complex to write, but the resulting API is so much nicer to use. Again, not advocating that you move to a stackless model. Just pointing out it works well for this use case. The low-latency FinTech market is pretty niche, and I think you can safely ignore it. I don't t think JVM languages are used for the majority of this market but are surprisingly well represented. What I would be a little more concerned about if I was you, is that the FinTech model is not so dissimilar to netty, (except compulsive obsession w/ avoiding context switches). They also are typically deployed on custom JNI networking layers. The newer ones aren't BSD sockets based. Their API also offers fairly fine-grain control over OS-Thread usage (I don't know how many use it). Netty is the defacto scheduler for the frameworks that use it. I'd think netty would have similar issues as FinTech w/ loom. Have you worked with them yet? Maybe you've already arrived at a good solution for netty? I'm sure you're aware, but netty underpins almost every back-end java framework. I would think that early netty adoption would be important to you? Unless you consider loom an alternative to netty? These are all rhetorical questions I would be asking myself if I was you. I'm not asking for, or expecting an answer to any of these. ok. done. Thanks for reading. good luck. -Jon -Jon From Alan.Bateman at oracle.com Fri Nov 19 20:03:20 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 19 Nov 2021 20:03:20 +0000 Subject: Questions on Build 18-loom+5-274 (2021/11/15) In-Reply-To: References: Message-ID: <8fca5fb4-955c-c02d-53fa-87dc4cce8184@oracle.com> On 19/11/2021 19:15, Michael Bazos wrote: > I started doing some experimenting with project loom an observed a few > things and wasn't sure how to explain them or why it was happening: > > 1. I noticed when using Executors.newVirtualThreadPerTaskExecutor() > submitting tasks and then calling 'shutdown()' on the executor service, the > virtual thread per task executor does not wait for tasks to finish. This > seems to behave a little differently than the OS based thread pool > executors. I assume this is intended but just wanted to know why. ExecutorService::shutdown is specified to not wait so the behavior you observe is correct. You can use awaitTermination, or the new close method, to wait for termination. Are you sure you've observed the shutdown of other ExecutorService implementation wait, just curious. > 2. Playing with StructuredExecutor I can see the example of using it > with try-with-resources which is clean and looks nice. I was surprised to > see `isShutdown()` as private on the StructuredExecutor. I am just > wondering if a client didn't use try-with-resources there would be some > value in allowing a client to know if the executor is shutdown or not. My > best guess is the intention here is to minimize what is exposed from the > API. If there is a case for exposing the state then it could be done. > 3. My final question which is semi related to Question 2 I haven't done > any benchmarking myself yet but I know creating OS based executor thread > pools can be considered an "expensive" operation. Obviously this is very > different when doing this with virtual thread task executor. Does using > virtual thread task executor mean this is cheap to create and shutdown? > Typically in client code you wouldn't want to create/destroy task executors > during the lifecycle of an application. The intention is that this should be very cheap to create and close. > Also I did some tests and I couldn't believe how many virtual threads I > could spin up on my machine versus OS threads. Seems like memory would be > the limit but the difference was ~3000 OS threads vs ~5 million+ virtual > threads. > > When I have time going to integrate the early loom builds into some real > applications to see how it behaves. I very much look forward to not having > to worry about configuring thread pools in the future, very excited and > keep up the good work! > Good, please let me know how you get on. -Alan From ron.pressler at oracle.com Fri Nov 19 20:14:15 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Fri, 19 Nov 2021 20:14:15 +0000 Subject: loom ea based jdk18 feedback In-Reply-To: References: <62f8873b-95e0-d43d-5f32-68c1cec5993a@oracle.com> Message-ID: <037D502F-4497-4F7E-B72C-2E7915288A78@oracle.com> Hi. A Jewish mother gives her son two ties for his birthday. When she sees him wearing one of them to dinner that night, she says, ?Hmm, I see you don?t like the other one." When we need to do multiple things, we usually do one first. Whenever that happens, some always complain why we didn?t do the other first. Of course, we can hold off on release until they?re both done, but that means that no one will get what they want any sooner. In this case the choice is simple. The feature that addresses finer-grained control over virtual thread scheduling is very important, which is exactly why we?re working on it. There?s no need to doubt if we?ve pondered the points you raise, because the code clearly shows that we have. But however popular this advanced feature is, it still helps a *smaller* number of people than those who can benefit from virtual threads without it. Therefore, we can either do the thing that helps more people first, or not help them until we can help the smaller, though still very important, group, too. The former option dominates the latter so clearly, that I have no doubt that no one would have chosen differently, which makes *me* wonder, do the people who respond with ?but do my thing first? actually want us, the stewards of Java, to do what?s best for the Java ecosystem at large or do they want us to do what helps *them*? But that?s just a rhetorical question I?d ask myself if I were you. ? Ron > On 19 Nov 2021, at 19:40, Jon Ross wrote: > > On Fri, Nov 19, 2021 at 3:04 AM Alan Bateman wrote: >> >> On 18/11/2021 21:13, Jon Ross wrote: >> If you are doing your own implementation of blocking I/O outside of the >> JDK then park/unpark should be sufficient. Unpark will queue the virtual >> thread to the scheduler so it continues on one of its thread. If you >> really want to restrict the scheduler to 1 thread then run with >> -Djdk.defaultScheduler.maxPoolSize=1. You are in very advanced territory >> if want fine control on the OS threads, this isn't a priority for this >> project right now but we will come back to it. > > Yes, having control over OS threads is a requirement for me. So is > controlling how/when virtual threads run. I will come back to loom > another time. > > The rest of this email is entirely for your benefit because you are > actively soliciting feedback. You are free to do with this what you > will, including completely ignoring it. I am not (as some others in > this thread have claimed) arguing, or advocating that you do anything > different. This is entirely an offer to help you understand a > customer's POV of loom for their specific use case. I am not asking > for anything at all, not even for you to care about my use case. > > I guess the TL:DR is that I don't think this is very "advanced territory". > > I come from a FinTech background. Most of the frameworks in the java > low-latency FinTech space (LMAX, the OpenHFT stuff, Real Logic / SBE, > Nasdaq, etc) use some custom alternative to NIO. From a simple JNI > epoll implementation to more exotic APIs that are not BSD > socket-based. They can fallback to NIO for local testing, but are > rarely deployed using NIO. The event-loop IO API is the only IO used. > The "tasks" are short-lived, and always return to the same event-loop > to wait on the next thing. Everything is callback-based. These > frameworks are fairly obsessed with avoiding context switches, as a > context switch is a material % of a tasks' budgeted work time. I don't > think loom will get much adoption in this space as it exists today. I > do not think this claim is an "overstatement" or hyperbolic. > Stackless coroutines work great for these types of frameworks. In > C++/Rust/Zig/Scala(macro)/Kotlin the compiler is hiding the callback, > so the required control still exists, and it moves the API from > callbacks to something that looks synchronous but isn't. I think this > is the main benefit of any type of fiber/coroutine for these types of > things. Clean up the API. The cost over callbacks is small (0 to 10s > of nanos), and the event-loop is a bit more complex to write, but the > resulting API is so much nicer to use. Again, not advocating that you > move to a stackless model. Just pointing out it works well for this > use case. > The low-latency FinTech market is pretty niche, and I think you can > safely ignore it. I don't t think JVM languages are used for the > majority of this market but are surprisingly well represented. > > What I would be a little more concerned about if I was you, is that > the FinTech model is not so dissimilar to netty, (except compulsive > obsession w/ avoiding context switches). They also are typically > deployed on custom JNI networking layers. The newer ones aren't BSD > sockets based. Their API also offers fairly fine-grain control over > OS-Thread usage (I don't know how many use it). Netty is the defacto > scheduler for the frameworks that use it. I'd think netty would have > similar issues as FinTech w/ loom. Have you worked with them yet? > Maybe you've already arrived at a good solution for netty? I'm sure > you're aware, but netty underpins almost every back-end java > framework. I would think that early netty adoption would be important > to you? Unless you consider loom an alternative to netty? These are > all rhetorical questions I would be asking myself if I was you. I'm > not asking for, or expecting an answer to any of these. > > ok. done. > Thanks for reading. good luck. > > -Jon > > > -Jon From eric at kolotyluk.net Fri Nov 19 20:34:16 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Fri, 19 Nov 2021 12:34:16 -0800 Subject: [External] : Re: Meaning and Usage of Tasks In-Reply-To: References: <34A87C94-9518-4E51-9F9E-9BBC7296D335@oracle.com> Message-ID: For try (var structuredExecutor = StructuredExecutor.open("Experiment00", virtualThreadFactory)) { var completionHandler = new StructuredExecutor.ShutdownOnFailure(); var futureResults = IntStream.range(0, 15).mapToObj(item -> { System.out.printf("item = %d, Thread ID = %s\n", item, Thread.currentThread()); return structuredExecutor.fork(() -> { System.out.printf("\ttask = %d, Thread ID = %s\n", item, Thread.currentThread()); return item; }, completionHandler); }); } a satisfying experience in the future for me would be to see something like task = 0, Thread ID = Experiment00/VirtualThread[#15]@CarrierThread[#5] task = 1, Thread ID = Experiment00/VirtualThread[#22]@CarrierThread[#6] task = 2, Thread ID = Experiment00/VirtualThread[#28]@CarrierThread[#7] task = 3, Thread ID = Experiment00/VirtualThread[#30]@CarrierThread[#7] Some useful variations might be task = a, Thread ID = .../Experiment00/VirtualThread[#15]@CarrierThread[#5] task = b, Thread ID = .../Experiment00/VirtualThread[#22]@CarrierThread[#6] task = c, Thread ID = .../Experiment00/VirtualThread[#28]@CarrierThread[#7] task = d, Thread ID = .../Experiment00/VirtualThread[#30]@CarrierThread[#7] indicating that these threads have a parent, that can be *observed *through some other API, such as Thread.getParent() task = a, Thread ID = Experiment00/VirtualThread[#15]/... at CarrierThread[#5] task = b, Thread ID = Experiment00/VirtualThread[#22]/... at CarrierThread[#6] task = c, Thread ID = Experiment00/VirtualThread[#28]/... at CarrierThread[#7] task = d, Thread ID = Experiment00/VirtualThread[#30]/... at CarrierThread[#7] indicating that these threads have children, that can be *observed *through some other API, such as Thread.getChildren() While I initially imagined a fuller thread path, that could quickly produce unreadable signatures for .toString(), so the above is something compact but useful in terms of understanding the structure of Structured Concurrency at a glance. Of course, other people might have better ideas of a good thread signature for .toString(). Cheers, Eric On Fri, Nov 19, 2021 at 10:31 AM Ron Pressler wrote: > It means that at the time toString was called, each of those two threads > were on that carrier (obviously, not at the same time). I?m not sure how > helpful this is, and there?s a good chance we?ll remove that string. > > ? Ron > > On 19 Nov 2021, at 15:48, Eric Kolotyluk wrote: > > " The toString method on a virtual thread will print the underlying > ForkJoinPool worker, but that?s not a new thread." > > Okay, that seems really profound. In my experiment, when I .fork() a > number of tasks, and each prints out Thread.currentThread(), I get > something like > > task = 0, Thread ID = VirtualThread[#15]/runnable at ForkJoinPool-1-worker-1 > task = 1, Thread ID = VirtualThread[#22]/runnable at ForkJoinPool-1-worker-6 > task = 2, Thread ID = VirtualThread[#28]/runnable at ForkJoinPool-1-worker-11 > task = 3, Thread ID = VirtualThread[#30]/runnable at ForkJoinPool-1-worker-11 > > What does this mean precisely? > > For the first one, I took this to mean VirtualThread[#15] is running in a > Carrier Thread called runnable at ForkJoinPool-1-worker-1 > > For VirtualThread[#28] and VirtualThread[#30], these both seem to be > running in the same Carrier Thread runnable at ForkJoinPool-1-worker-1 > > Am I interpreting this wrong? How should I interpret it? > > Cheers, Eric > > > On Fri, Nov 19, 2021 at 5:14 AM Ron Pressler > wrote: > >> It will create a new thread depending on the ThreadFactory. If the >> factory creates virtual threads, it will spawn a virtual thread per task; >> if it?s platform ? platform. The toString method on a virtual thread will >> print the underlying ForkJoinPool worker, but that?s not a new thread. >> >> On 18 Nov 2021, at 21:44, Eric Kolotyluk wrote: >> >> So, in the case of >> >> var platformThreadFactory = Thread.ofPlatform().factory(); >> >> var structuredExecutor = StructuredExecutor.open("Experiment00", platformThreadFactory)) >> >> You say "Because StructuredExecutor spawns a new thread for each forked >> task," it also creates a Platform Thread per task? Is this a property of >> .fork() or of StructuredExecutor? >> >> When I print out the Thread signature I see >> >> VirtualThread[#36]/runnable at ForkJoinPool-1-worker-11 >> >> Which I find confusing, and I hope is improved in the future to be >> clearer in the relationship between threads and tasks. >> >> No, not an inconvenience at the moment, but I just want to understand >> better so that I can explain it to others, or ask better questions. >> >> Cheers, Eric >> >> >> On Thu, Nov 18, 2021 at 1:06 PM Ron Pressler >> wrote: >> >>> You bring up multiple points, so let me try and address them. >>> >>> A task is, indeed, not a thread, and, as you say, I would simply >>> consider it to be some computation, usually expressible as a lambda >>> expression/method reference. Because StructuredExecutor spawns a new thread >>> for each forked task, we might sometimes use the terms interchangeably, but >>> only in this context. >>> >>> As to the method names and signatures, the execute method is there >>> simply so that StructuredExecutor could implement the Executor interface >>> that declares it. You?ll find something similar in ExecutorService, where >>> there?s a method called executor, that takes a Runnable and returns void, >>> and methods called submit, which take a Callable and return a Future. >>> StructuredExecutor.fork is analogous to ExecutorService.submit. Now, >>> ExecutorService also has an override of submit that takes a Runnable (and >>> returns a Future), in addition to the void execute method. We could >>> certainly add a similar override of fork, but it didn?t seem particularly >>> urgent at this point in time. You can always turn a Runnable into a >>> Callable with the Executors.callable [1] helper method. If you find this to >>> be too much of an inconvenience, please let us know. >>> >>> ? Ron >>> >>> [1]: >>> https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/Executors.html#callable(java.lang.Runnable) >>> >>> >>> > On 18 Nov 2021, at 20:18, Eric Kolotyluk wrote: >>> > >>> > Reading some of the documentation I am getting confused about the >>> meaning >>> > of a 'Task' and wrote about this earlier in Threads vs Tasks... >>> > >>> > Initially, these were just Runnable, and then could also be Callable >>> (which >>> > is better). Is it interesting to note in StructuredExecutor there are >>> > different signatures for >>> > >>> > .execute(Runnable) >>> > .fork(Callable) >>> > >>> > And I appreciate the distinction because calling .submit(Runnable | >>> > Callable) can blur things, but can also see that .submit() may be more >>> > attractive to some. Also, Callable can throw a Checked Exception, >>> whereas >>> > Runnable cannot. Can someone please explain the reason for this design >>> > change? >>> > >>> > I especially appreciate that both Runnable and Callable can be >>> expressed >>> > with Lambda expressions, especially coming from a background of >>> Akka/Scala, >>> > where Actors .spawn() other Actors, and can use Lambda expressions. >>> > However, in Akka Typed we often use forms such as >>> > >>> > object GreeterMain { >>> > >>> > final case class SayHello(name: String) >>> > >>> > def apply(): Behavior[SayHello] = >>> > Behaviors.setup { context => >>> > val greeter = context.spawn(Greeter(), "greeter") >>> > >>> > Behaviors.receiveMessage { message => >>> > val replyTo = context.spawn(GreeterBot(max = 3), message.name >>> >>> ) >>> > greeter ! Greeter.Greet(message.name >>> , >>> replyTo) >>> > Behaviors.same >>> > } >>> > }} >>> > >>> > where the Behaviors.setup { context => ... is a Lambda that takes a >>> > 'context' >>> > >>> > Now I am not advocating adopting the Akka style, but it makes me wonder >>> > what it would look like if we had capabilities like >>> > >>> > structuredExecutor.spawn( () => {task implementation} ) >>> > structuredExecutor.spawn( context => {task implementation} ) >>> > structuredExecutor.spawn( (context, thingy) => {task implementation} ) >>> > . . . >>> > >>> > and so on, where context is something not available in the session >>> because >>> > the structuredExecutor is available to the task implementation. I am >>> just >>> > thinking out loud here, where not all Tasks need the context, thingy, >>> etc., >>> > but some may benefit from them. More importantly, is there some >>> concept of >>> > Task that goes beyond Callable, that cannot be satisfied by adding more >>> > features to Callable? >>> > >>> > I am pretty sure the Loom Architects have already walked down this >>> path so >>> > I would like to know if they could share their thoughts on this. >>> > >>> > I am not hung up on a single .spawn() for multiple task types, but I >>> like >>> > the name because it brings a sense of 'family' to concurrent >>> programming. ?? >>> > >>> > In my mind, a Task is *not *a Thread, it is something else that can be >>> > executed on a Thread, but it should always be implementable by a >>> Lambda. >>> > >>> > Cheers, Eric >>> >>> >> > From ron.pressler at oracle.com Fri Nov 19 20:38:58 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Fri, 19 Nov 2021 20:38:58 +0000 Subject: [External] : Re: Meaning and Usage of Tasks In-Reply-To: References: <34A87C94-9518-4E51-9F9E-9BBC7296D335@oracle.com> Message-ID: <2740231A-D89B-499F-8163-6A93175BB9B3@oracle.com> If you read the structured concurrency JEP draft, you?ll see some sections that are still in progress that address the points you made. Stay tuned. Please try the new hierarchical JEP draft to see how some of those new APIs, which are still undocumented in the JEP, are used. ? Ron On 19 Nov 2021, at 20:34, Eric Kolotyluk > wrote: For try (var structuredExecutor = StructuredExecutor.open("Experiment00", virtualThreadFactory)) { var completionHandler = new StructuredExecutor.ShutdownOnFailure(); var futureResults = IntStream.range(0, 15).mapToObj(item -> { System.out.printf("item = %d, Thread ID = %s\n", item, Thread.currentThread()); return structuredExecutor.fork(() -> { System.out.printf("\ttask = %d, Thread ID = %s\n", item, Thread.currentThread()); return item; }, completionHandler); }); } a satisfying experience in the future for me would be to see something like task = 0, Thread ID = Experiment00/VirtualThread[#15]@CarrierThread[#5] task = 1, Thread ID = Experiment00/VirtualThread[#22]@CarrierThread[#6] task = 2, Thread ID = Experiment00/VirtualThread[#28]@CarrierThread[#7] task = 3, Thread ID = Experiment00/VirtualThread[#30]@CarrierThread[#7] Some useful variations might be task = a, Thread ID = .../Experiment00/VirtualThread[#15]@CarrierThread[#5] task = b, Thread ID = .../Experiment00/VirtualThread[#22]@CarrierThread[#6] task = c, Thread ID = .../Experiment00/VirtualThread[#28]@CarrierThread[#7] task = d, Thread ID = .../Experiment00/VirtualThread[#30]@CarrierThread[#7] indicating that these threads have a parent, that can be observed through some other API, such as Thread.getParent() task = a, Thread ID = Experiment00/VirtualThread[#15]/... at CarrierThread[#5] task = b, Thread ID = Experiment00/VirtualThread[#22]/... at CarrierThread[#6] task = c, Thread ID = Experiment00/VirtualThread[#28]/... at CarrierThread[#7] task = d, Thread ID = Experiment00/VirtualThread[#30]/... at CarrierThread[#7] indicating that these threads have children, that can be observed through some other API, such as Thread.getChildren() While I initially imagined a fuller thread path, that could quickly produce unreadable signatures for .toString(), so the above is something compact but useful in terms of understanding the structure of Structured Concurrency at a glance. Of course, other people might have better ideas of a good thread signature for .toString(). Cheers, Eric On Fri, Nov 19, 2021 at 10:31 AM Ron Pressler > wrote: It means that at the time toString was called, each of those two threads were on that carrier (obviously, not at the same time). I?m not sure how helpful this is, and there?s a good chance we?ll remove that string. ? Ron On 19 Nov 2021, at 15:48, Eric Kolotyluk > wrote: " The toString method on a virtual thread will print the underlying ForkJoinPool worker, but that?s not a new thread." Okay, that seems really profound. In my experiment, when I .fork() a number of tasks, and each prints out Thread.currentThread(), I get something like task = 0, Thread ID = VirtualThread[#15]/runnable at ForkJoinPool-1-worker-1 task = 1, Thread ID = VirtualThread[#22]/runnable at ForkJoinPool-1-worker-6 task = 2, Thread ID = VirtualThread[#28]/runnable at ForkJoinPool-1-worker-11 task = 3, Thread ID = VirtualThread[#30]/runnable at ForkJoinPool-1-worker-11 What does this mean precisely? For the first one, I took this to mean VirtualThread[#15] is running in a Carrier Thread called runnable at ForkJoinPool-1-worker-1 For VirtualThread[#28] and VirtualThread[#30], these both seem to be running in the same Carrier Thread runnable at ForkJoinPool-1-worker-1 Am I interpreting this wrong? How should I interpret it? Cheers, Eric On Fri, Nov 19, 2021 at 5:14 AM Ron Pressler > wrote: It will create a new thread depending on the ThreadFactory. If the factory creates virtual threads, it will spawn a virtual thread per task; if it?s platform ? platform. The toString method on a virtual thread will print the underlying ForkJoinPool worker, but that?s not a new thread. On 18 Nov 2021, at 21:44, Eric Kolotyluk > wrote: So, in the case of var platformThreadFactory = Thread.ofPlatform().factory(); var structuredExecutor = StructuredExecutor.open("Experiment00", platformThreadFactory)) You say "Because StructuredExecutor spawns a new thread for each forked task," it also creates a Platform Thread per task? Is this a property of .fork() or of StructuredExecutor? When I print out the Thread signature I see VirtualThread[#36]/runnable at ForkJoinPool-1-worker-11 Which I find confusing, and I hope is improved in the future to be clearer in the relationship between threads and tasks. No, not an inconvenience at the moment, but I just want to understand better so that I can explain it to others, or ask better questions. Cheers, Eric On Thu, Nov 18, 2021 at 1:06 PM Ron Pressler > wrote: You bring up multiple points, so let me try and address them. A task is, indeed, not a thread, and, as you say, I would simply consider it to be some computation, usually expressible as a lambda expression/method reference. Because StructuredExecutor spawns a new thread for each forked task, we might sometimes use the terms interchangeably, but only in this context. As to the method names and signatures, the execute method is there simply so that StructuredExecutor could implement the Executor interface that declares it. You?ll find something similar in ExecutorService, where there?s a method called executor, that takes a Runnable and returns void, and methods called submit, which take a Callable and return a Future. StructuredExecutor.fork is analogous to ExecutorService.submit. Now, ExecutorService also has an override of submit that takes a Runnable (and returns a Future), in addition to the void execute method. We could certainly add a similar override of fork, but it didn?t seem particularly urgent at this point in time. You can always turn a Runnable into a Callable with the Executors.callable [1] helper method. If you find this to be too much of an inconvenience, please let us know. ? Ron [1]: https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/Executors.html#callable(java.lang.Runnable) > On 18 Nov 2021, at 20:18, Eric Kolotyluk > wrote: > > Reading some of the documentation I am getting confused about the meaning > of a 'Task' and wrote about this earlier in Threads vs Tasks... > > Initially, these were just Runnable, and then could also be Callable (which > is better). Is it interesting to note in StructuredExecutor there are > different signatures for > > .execute(Runnable) > .fork(Callable) > > And I appreciate the distinction because calling .submit(Runnable | > Callable) can blur things, but can also see that .submit() may be more > attractive to some. Also, Callable can throw a Checked Exception, whereas > Runnable cannot. Can someone please explain the reason for this design > change? > > I especially appreciate that both Runnable and Callable can be expressed > with Lambda expressions, especially coming from a background of Akka/Scala, > where Actors .spawn() other Actors, and can use Lambda expressions. > However, in Akka Typed we often use forms such as > > object GreeterMain { > > final case class SayHello(name: String) > > def apply(): Behavior[SayHello] = > Behaviors.setup { context => > val greeter = context.spawn(Greeter(), "greeter") > > Behaviors.receiveMessage { message => > val replyTo = context.spawn(GreeterBot(max = 3), message.name) > greeter ! Greeter.Greet(message.name, replyTo) > Behaviors.same > } > }} > > where the Behaviors.setup { context => ... is a Lambda that takes a > 'context' > > Now I am not advocating adopting the Akka style, but it makes me wonder > what it would look like if we had capabilities like > > structuredExecutor.spawn( () => {task implementation} ) > structuredExecutor.spawn( context => {task implementation} ) > structuredExecutor.spawn( (context, thingy) => {task implementation} ) > . . . > > and so on, where context is something not available in the session because > the structuredExecutor is available to the task implementation. I am just > thinking out loud here, where not all Tasks need the context, thingy, etc., > but some may benefit from them. More importantly, is there some concept of > Task that goes beyond Callable, that cannot be satisfied by adding more > features to Callable? > > I am pretty sure the Loom Architects have already walked down this path so > I would like to know if they could share their thoughts on this. > > I am not hung up on a single .spawn() for multiple task types, but I like > the name because it brings a sense of 'family' to concurrent programming. ?? > > In my mind, a Task is *not *a Thread, it is something else that can be > executed on a Thread, but it should always be implementable by a Lambda. > > Cheers, Eric From eric at kolotyluk.net Fri Nov 19 20:44:20 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Fri, 19 Nov 2021 12:44:20 -0800 Subject: [External] : Re: Meaning and Usage of Tasks In-Reply-To: <2740231A-D89B-499F-8163-6A93175BB9B3@oracle.com> References: <34A87C94-9518-4E51-9F9E-9BBC7296D335@oracle.com> <2740231A-D89B-499F-8163-6A93175BB9B3@oracle.com> Message-ID: Yes, I have been reading the JEP and understand things are very much still in progress. Looking forward to seeing what develops Do you mean Re-implement ThreadGroup JEP ? Cheeers, Eric On Fri, Nov 19, 2021 at 12:39 PM Ron Pressler wrote: > If you read the structured concurrency JEP draft, you?ll see some sections > that are still in progress that address the points you made. Stay tuned. > Please try the new hierarchical JEP draft to see how some of those new > APIs, which are still undocumented in the JEP, are used. > > ? Ron > > On 19 Nov 2021, at 20:34, Eric Kolotyluk wrote: > > For > > try (var structuredExecutor = StructuredExecutor.open("Experiment00", virtualThreadFactory)) { > var completionHandler = new StructuredExecutor.ShutdownOnFailure(); > var futureResults = IntStream.range(0, 15).mapToObj(item -> { > System.out.printf("item = %d, Thread ID = %s\n", item, Thread.currentThread()); > return structuredExecutor.fork(() -> { > System.out.printf("\ttask = %d, Thread ID = %s\n", item, Thread.currentThread()); > return item; > }, completionHandler); > }); > } > > a satisfying experience in the future for me would be to see something > like > > task = 0, Thread ID = Experiment00/VirtualThread[#15]@CarrierThread[#5] > task = 1, Thread ID = Experiment00/VirtualThread[#22]@CarrierThread[#6] > task = 2, Thread ID = Experiment00/VirtualThread[#28]@CarrierThread[#7] > task = 3, Thread ID = Experiment00/VirtualThread[#30]@CarrierThread[#7] > > Some useful variations might be > > task = a, Thread ID = .../Experiment00/VirtualThread[#15]@CarrierThread[#5] > task = b, Thread ID = .../Experiment00/VirtualThread[#22]@CarrierThread[#6] > task = c, Thread ID = .../Experiment00/VirtualThread[#28]@CarrierThread[#7] > task = d, Thread ID = .../Experiment00/VirtualThread[#30]@CarrierThread[#7] > > indicating that these threads have a parent, that can be * observed *through > some other API, such as Thread.getParent() > > task = a, Thread ID = Experiment00/VirtualThread[#15]/... at CarrierThread[#5] > task = b, Thread ID = Experiment00/VirtualThread[#22]/... at CarrierThread[#6] > task = c, Thread ID = Experiment00/VirtualThread[#28]/... at CarrierThread[#7] > task = d, Thread ID = Experiment00/VirtualThread[#30]/... at CarrierThread[#7] > > indicating that these threads have children, that can be * observed *through > some other API, such as Thread.getChildren() > > While I initially imagined a fuller thread path, that could quickly > produce unreadable signatures for .toString(), so the above is something > compact but useful in terms of understanding the structure of Structured > Concurrency at a glance. > > Of course, other people might have better ideas of a good thread signature > for .toString(). > > Cheers, Eric > > On Fri, Nov 19, 2021 at 10:31 AM Ron Pressler > wrote: > >> It means that at the time toString was called, each of those two threads >> were on that carrier (obviously, not at the same time). I?m not sure how >> helpful this is, and there?s a good chance we?ll remove that string. >> >> ? Ron >> >> On 19 Nov 2021, at 15:48, Eric Kolotyluk wrote: >> >> " The toString method on a virtual thread will print the underlying >> ForkJoinPool worker, but that?s not a new thread." >> >> Okay, that seems really profound. In my experiment, when I .fork() a >> number of tasks, and each prints out Thread.currentThread(), I get >> something like >> >> task = 0, Thread ID = VirtualThread[#15]/runnable at ForkJoinPool-1-worker-1 >> task = 1, Thread ID = VirtualThread[#22]/runnable at ForkJoinPool-1-worker-6 >> task = 2, Thread ID = VirtualThread[#28]/runnable at ForkJoinPool-1-worker-11 >> task = 3, Thread ID = VirtualThread[#30]/runnable at ForkJoinPool-1-worker-11 >> >> What does this mean precisely? >> >> For the first one, I took this to mean VirtualThread[#15] is running in a >> Carrier Thread called runnable at ForkJoinPool-1-worker-1 >> >> For VirtualThread[#28] and VirtualThread[#30], these both seem to be >> running in the same Carrier Thread runnable at ForkJoinPool-1-worker-1 >> >> Am I interpreting this wrong? How should I interpret it? >> >> Cheers, Eric >> >> >> On Fri, Nov 19, 2021 at 5:14 AM Ron Pressler >> wrote: >> >>> It will create a new thread depending on the ThreadFactory. If the >>> factory creates virtual threads, it will spawn a virtual thread per task; >>> if it?s platform ? platform. The toString method on a virtual thread will >>> print the underlying ForkJoinPool worker, but that?s not a new thread. >>> >>> On 18 Nov 2021, at 21:44, Eric Kolotyluk wrote: >>> >>> So, in the case of >>> >>> var platformThreadFactory = Thread.ofPlatform().factory(); >>> >>> var structuredExecutor = StructuredExecutor.open("Experiment00", platformThreadFactory)) >>> >>> You say "Because StructuredExecutor spawns a new thread for each forked >>> task," it also creates a Platform Thread per task? Is this a property of >>> .fork() or of StructuredExecutor? >>> >>> When I print out the Thread signature I see >>> >>> VirtualThread[#36]/runnable at ForkJoinPool-1-worker-11 >>> >>> Which I find confusing, and I hope is improved in the future to be >>> clearer in the relationship between threads and tasks. >>> >>> No, not an inconvenience at the moment, but I just want to understand >>> better so that I can explain it to others, or ask better questions. >>> >>> Cheers, Eric >>> >>> >>> On Thu, Nov 18, 2021 at 1:06 PM Ron Pressler >>> wrote: >>> >>>> You bring up multiple points, so let me try and address them. >>>> >>>> A task is, indeed, not a thread, and, as you say, I would simply >>>> consider it to be some computation, usually expressible as a lambda >>>> expression/method reference. Because StructuredExecutor spawns a new thread >>>> for each forked task, we might sometimes use the terms interchangeably, but >>>> only in this context. >>>> >>>> As to the method names and signatures, the execute method is there >>>> simply so that StructuredExecutor could implement the Executor interface >>>> that declares it. You?ll find something similar in ExecutorService, where >>>> there?s a method called executor, that takes a Runnable and returns void, >>>> and methods called submit, which take a Callable and return a Future. >>>> StructuredExecutor.fork is analogous to ExecutorService.submit. Now, >>>> ExecutorService also has an override of submit that takes a Runnable (and >>>> returns a Future), in addition to the void execute method. We could >>>> certainly add a similar override of fork, but it didn?t seem particularly >>>> urgent at this point in time. You can always turn a Runnable into a >>>> Callable with the Executors.callable [1] helper method. If you find this to >>>> be too much of an inconvenience, please let us know. >>>> >>>> ? Ron >>>> >>>> [1]: >>>> https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/Executors.html#callable(java.lang.Runnable) >>>> >>>> >>>> > On 18 Nov 2021, at 20:18, Eric Kolotyluk wrote: >>>> > >>>> > Reading some of the documentation I am getting confused about the >>>> meaning >>>> > of a 'Task' and wrote about this earlier in Threads vs Tasks... >>>> > >>>> > Initially, these were just Runnable, and then could also be Callable >>>> (which >>>> > is better). Is it interesting to note in StructuredExecutor there are >>>> > different signatures for >>>> > >>>> > .execute(Runnable) >>>> > .fork(Callable) >>>> > >>>> > And I appreciate the distinction because calling .submit(Runnable | >>>> > Callable) can blur things, but can also see that .submit() may be more >>>> > attractive to some. Also, Callable can throw a Checked Exception, >>>> whereas >>>> > Runnable cannot. Can someone please explain the reason for this design >>>> > change? >>>> > >>>> > I especially appreciate that both Runnable and Callable can be >>>> expressed >>>> > with Lambda expressions, especially coming from a background of >>>> Akka/Scala, >>>> > where Actors .spawn() other Actors, and can use Lambda expressions. >>>> > However, in Akka Typed we often use forms such as >>>> > >>>> > object GreeterMain { >>>> > >>>> > final case class SayHello(name: String) >>>> > >>>> > def apply(): Behavior[SayHello] = >>>> > Behaviors.setup { context => >>>> > val greeter = context.spawn(Greeter(), "greeter") >>>> > >>>> > Behaviors.receiveMessage { message => >>>> > val replyTo = context.spawn(GreeterBot(max = 3), message.name >>>> >>>> ) >>>> > greeter ! Greeter.Greet(message.name >>>> , >>>> replyTo) >>>> > Behaviors.same >>>> > } >>>> > }} >>>> > >>>> > where the Behaviors.setup { context => ... is a Lambda that takes a >>>> > 'context' >>>> > >>>> > Now I am not advocating adopting the Akka style, but it makes me >>>> wonder >>>> > what it would look like if we had capabilities like >>>> > >>>> > structuredExecutor.spawn( () => {task implementation} ) >>>> > structuredExecutor.spawn( context => {task implementation} ) >>>> > structuredExecutor.spawn( (context, thingy) => {task implementation} ) >>>> > . . . >>>> > >>>> > and so on, where context is something not available in the session >>>> because >>>> > the structuredExecutor is available to the task implementation. I am >>>> just >>>> > thinking out loud here, where not all Tasks need the context, thingy, >>>> etc., >>>> > but some may benefit from them. More importantly, is there some >>>> concept of >>>> > Task that goes beyond Callable, that cannot be satisfied by adding >>>> more >>>> > features to Callable? >>>> > >>>> > I am pretty sure the Loom Architects have already walked down this >>>> path so >>>> > I would like to know if they could share their thoughts on this. >>>> > >>>> > I am not hung up on a single .spawn() for multiple task types, but I >>>> like >>>> > the name because it brings a sense of 'family' to concurrent >>>> programming. ?? >>>> > >>>> > In my mind, a Task is *not *a Thread, it is something else that can be >>>> > executed on a Thread, but it should always be implementable by a >>>> Lambda. >>>> > >>>> > Cheers, Eric >>>> >>>> >>> >> > From ron.pressler at oracle.com Fri Nov 19 20:52:44 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Fri, 19 Nov 2021 20:52:44 +0000 Subject: [External] : Re: Meaning and Usage of Tasks In-Reply-To: References: <34A87C94-9518-4E51-9F9E-9BBC7296D335@oracle.com> <2740231A-D89B-499F-8163-6A93175BB9B3@oracle.com> Message-ID: > On 19 Nov 2021, at 20:44, Eric Kolotyluk wrote: > > Do you mean Re-implement ThreadGroup JEP? > It?s related, but I mean the last few sections in the structured concurrency JEP draft, marked ?work in progress,? plus, of course, the new thread dump mentioned there, which is already in the build and you can ? and should! ? try. ? Ron From jonross at gmail.com Fri Nov 19 22:08:53 2021 From: jonross at gmail.com (Jon Ross) Date: Fri, 19 Nov 2021 14:08:53 -0800 Subject: loom ea based jdk18 feedback In-Reply-To: <037D502F-4497-4F7E-B72C-2E7915288A78@oracle.com> References: <62f8873b-95e0-d43d-5f32-68c1cec5993a@oracle.com> <037D502F-4497-4F7E-B72C-2E7915288A78@oracle.com> Message-ID: I think that is all very reasonable. I like your analogy. I'm going to start using it. The end bit a very disingenuous reading of my points. I was very clear that I'm not asking to "do my thing first". In fact, I was very clear that I'm not asking for anything at all. Yet I'm accused of it (again). I am/was legitimately trying to give you a POV is that slightly unique from the normal use case, on the off chance you hadn't encountered it yet, If there is anything I want from you, it's just that you understand my use case. I'm not asking that you do anything about it. Just to be aware of it. That is all. My attempt has just been met w/ hostility (except for Alan, who was actually helpful). I've been told that my need for the feature isn't real. Now I'm being told that I have a problem w/ your stewardship of java (thanks for putting words in my mouth). straw-man after straw-man. Why do you bother asking for feedback, if you're going to respond to it so negatively? I would prefer a steward of java who is curious about their users, and generous with their ability to listen (even they've heard it 100 times before). You seem to be neither of those. Clearly, this conversation (to the extent it ever was one) is past the point of usefulness. From Alan.Bateman at oracle.com Sat Nov 20 07:32:29 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 20 Nov 2021 07:32:29 +0000 Subject: [External] : Re: Meaning and Usage of Tasks In-Reply-To: References: <34A87C94-9518-4E51-9F9E-9BBC7296D335@oracle.com> <2740231A-D89B-499F-8163-6A93175BB9B3@oracle.com> Message-ID: <0def50df-73ec-65c8-30f5-d865c1904747@oracle.com> On 19/11/2021 20:44, Eric Kolotyluk wrote: > : > > Do you mean Re-implement ThreadGroup JEP > ? > The proposal in that draft has been distilled down to one section in the Virtual Threads JEP. So we should probably close the TG draft JEP to avoid giving the impression that it is a separate effort. Thanks for the reminder about it. -Alan From forax at univ-mlv.fr Sat Nov 20 12:26:54 2021 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Sat, 20 Nov 2021 13:26:54 +0100 (CET) Subject: [External] : Re: Virtual threads and executor ? In-Reply-To: <9AF004AB-64CF-40C7-A225-607A47E3F0F1@oracle.com> References: <1200540038.2654931.1637263362471.JavaMail.zimbra@u-pem.fr> <1726154913.3175687.1637346375316.JavaMail.zimbra@u-pem.fr> <9AF004AB-64CF-40C7-A225-607A47E3F0F1@oracle.com> Message-ID: <74931705.3269942.1637411214187.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "Ron Pressler" > To: "Remi Forax" > Cc: "loom-dev" > Sent: Vendredi 19 Novembre 2021 19:34:21 > Subject: Re: [External] : Re: Virtual threads and executor ? >> On 19 Nov 2021, at 18:26, forax at univ-mlv.fr wrote: >> >> ----- Original Message ----- >>> From: "Ron Pressler" >>> To: "Remi Forax" >>> Cc: "loom-dev" >>> Sent: Jeudi 18 Novembre 2021 21:53:31 >>> Subject: Re: Virtual threads and executor ? >> >>> The rationale is simple: that mechanism is much less mature than others because >>> we?ve focused on higher-priority items that are relevant to more people, and >>> so, while we?re working on it, we don?t want to hold up the rest of the >>> features in the project, so we took it out until we feel comfortable enough >>> with its design and operation. >> >> I'm not sure to understand what design really encompass here given that a >> virtual already take an executor. >> >> For me, this decision will hamper the adoption of Loom, because it's now harder >> to use virtual thread where previously platform thread were used, >> you can not simply swap the executors to use a virtual thread executor. > > Oh, I don?t think we?re talking about the same thing. To migrate to virtual > threads, start by replacing existing ExecutorServices with > Executors.newVirtualThreadPerTaskExecutor/newThreadPerTaskExecutor. All that?s > there. The problem with Executors.newVirtualThreadPerTaskExecutor() is that you can not specify an underlying executor, all the virtual threads has to run on the default common fork/join pool but the common F/J pool is not good in all use cases (you can even specify another pool when using a parallel stream), it's just a good default. I am all good with not having an API promising too much, but this limitation makes the integration of loom to existing libraries/stack unnecessary hard IMO. > > I thought you were talking about the super-advanced feature of custom > schedulers, which are still not mature enough, and don?t aid in migration. > > ? Ron R?mi From duke at openjdk.java.net Sat Nov 20 13:12:05 2021 From: duke at openjdk.java.net (duke) Date: Sat, 20 Nov 2021 13:12:05 GMT Subject: git: openjdk/loom: fibers: 114 new changesets Message-ID: <2ef0522a-7ae9-410c-a9b9-5279b7426cd9@openjdk.java.net> Changeset: 87b926eb Author: sunguoyun Committer: Igor Veresov Date: 2021-11-03 05:51:18 +0000 URL: https://git.openjdk.java.net/loom/commit/87b926ebb7f1e341da858f7a9892377586abc026 8275086: compiler/c2/irTests/TestPostParseCallDevirtualization.java fails when compiler1 is disabled Reviewed-by: iveresov ! test/hotspot/jtreg/compiler/c2/irTests/TestPostParseCallDevirtualization.java Changeset: 7439b59b Author: Christian Hagedorn Date: 2021-11-03 08:44:03 +0000 URL: https://git.openjdk.java.net/loom/commit/7439b59b5a6816269b16d210ef10779fc9def8e2 8276044: ciReplay: C1 does not dump a replay file when using DumpReplay as compile command option Reviewed-by: kvn, thartmann, dlong ! src/hotspot/share/c1/c1_Compilation.cpp ! test/hotspot/jtreg/compiler/ciReplay/CiReplayBase.java + test/hotspot/jtreg/compiler/ciReplay/TestDumpReplayCommandLine.java Changeset: 465d350d Author: Aleksey Shipilev Date: 2021-11-03 09:06:21 +0000 URL: https://git.openjdk.java.net/loom/commit/465d350d0b3cac277a58b9f8ece196c1cde68e80 8276157: C2: Compiler stack overflow during escape analysis on Linux x86_32 Reviewed-by: kvn, thartmann ! src/hotspot/os_cpu/linux_x86/globals_linux_x86.hpp Changeset: 61506336 Author: Pavel Rappo Date: 2021-11-03 10:07:48 +0000 URL: https://git.openjdk.java.net/loom/commit/615063364ab6bdd3fa83401745e05b45e13eacdb 8276348: Use blessed modifier order in java.base Reviewed-by: dfuchs, darcy, iris, rriggs, martin ! src/java.base/share/classes/java/io/ObjectInputFilter.java ! src/java.base/share/classes/java/io/ObjectStreamClass.java ! src/java.base/share/classes/java/lang/Object.java ! src/java.base/share/classes/java/lang/Process.java ! src/java.base/share/classes/java/lang/StackStreamFactory.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/lang/WeakPairMap.java ! src/java.base/share/classes/java/lang/invoke/AbstractConstantGroup.java ! src/java.base/share/classes/java/lang/invoke/CallSite.java ! src/java.base/share/classes/java/net/InetAddress.java ! src/java.base/share/classes/java/security/Provider.java ! src/java.base/share/classes/java/util/ImmutableCollections.java ! src/java.base/share/classes/jdk/internal/icu/util/CodePointTrie.java ! src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java ! src/java.base/share/classes/jdk/internal/jimage/NativeImageBuffer.java ! src/java.base/share/classes/jdk/internal/logger/SimpleConsoleLogger.java ! src/java.base/share/classes/jdk/internal/module/ModuleReferences.java ! src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java ! src/java.base/share/classes/sun/security/jca/ProviderList.java ! src/java.base/share/classes/sun/security/rsa/RSAPrivateKeyImpl.java ! src/java.base/share/classes/sun/security/ssl/SSLHandshake.java Changeset: a316c06e Author: Zhengyu Gu Date: 2021-11-03 12:08:37 +0000 URL: https://git.openjdk.java.net/loom/commit/a316c06e03e06b86ceca376cf20dcb9c526905f5 8275730: Relax memory constraint on MultiThreadedRefCounter Reviewed-by: mgronlun, minqi ! src/hotspot/share/jfr/utilities/jfrRefCountPointer.hpp Changeset: be1ca2bd Author: Hamlin Li Date: 2021-11-03 12:39:15 +0000 URL: https://git.openjdk.java.net/loom/commit/be1ca2bd201170b0d280030a2aae4c8d1da9f4af 8276298: G1: Remove unused G1SegmentedArrayBufferList::add Reviewed-by: tschatzl ! src/hotspot/share/gc/g1/g1SegmentedArray.hpp Changeset: 87318460 Author: Daniel D. Daugherty Date: 2021-11-03 15:02:20 +0000 URL: https://git.openjdk.java.net/loom/commit/87318460012d3fa1a8d3e8749d7a20328b27b826 8276556: ProblemList java/nio/channels/FileChannel/LargeGatheringWrite.java on windows-x64 Reviewed-by: alanb ! test/jdk/ProblemList.txt Changeset: 61cb4bc6 Author: Tobias Holenstein Committer: Christian Hagedorn Date: 2021-11-03 15:31:50 +0000 URL: https://git.openjdk.java.net/loom/commit/61cb4bc6b0252536364a86f38ff2e5c8c7ab610b 8276036: The value of full_count in the message of insufficient codecache is wrong Reviewed-by: kvn, dlong, thartmann, chagedorn ! src/hotspot/share/code/codeCache.cpp Changeset: 724bf3be Author: Aleksey Shipilev Date: 2021-11-03 15:41:26 +0000 URL: https://git.openjdk.java.net/loom/commit/724bf3be1458f7da502f8772be6151bed826b4f7 8275604: Zero: Reformat opclabels_data Reviewed-by: adinn, zgu ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp Changeset: 0ef8cbe3 Author: Phil Race Date: 2021-11-03 16:22:42 +0000 URL: https://git.openjdk.java.net/loom/commit/0ef8cbe32540814d4c0be9c7b0f78486408657a7 8276385: Re-run blessed-modifier-order script on java.desktop and jdk.accessibility Reviewed-by: serb ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/BaselineTIFFTagSet.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifGPSTagSet.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifInteroperabilityTagSet.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifParentTIFFTagSet.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifTIFFTagSet.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/FaxTIFFTagSet.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/GeoTIFFTagSet.java ! src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java ! src/java.desktop/share/classes/sun/java2d/loops/DrawGlyphListColor.java ! src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java ! src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/AWTEventMonitor.java ! src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/AccessibilityEventMonitor.java ! src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/AccessibilityListenerList.java ! src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/EventID.java ! src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/EventQueueMonitor.java ! src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/SwingEventMonitor.java ! src/jdk.accessibility/windows/classes/com/sun/java/accessibility/internal/AccessBridge.java Changeset: 7115892f Author: Daniel Fuchs Date: 2021-11-03 16:23:57 +0000 URL: https://git.openjdk.java.net/loom/commit/7115892f96a5a57ce9d37602038b787d19da5d81 8276401: Use blessed modifier order in java.net.http Reviewed-by: prappo, rriggs ! src/java.net.http/share/classes/jdk/internal/net/http/Http1Exchange.java ! src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java ! src/java.net.http/share/classes/jdk/internal/net/http/Http2ClientImpl.java ! src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java ! src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java ! src/java.net.http/share/classes/jdk/internal/net/http/HttpConnection.java ! src/java.net.http/share/classes/jdk/internal/net/http/ResponseSubscribers.java ! src/java.net.http/share/classes/jdk/internal/net/http/SocketTube.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/DebugLogger.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/FlowTube.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/MinimalFuture.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/SSLTube.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/SequentialScheduler.java Changeset: 684edbb4 Author: Brian Burkhalter Date: 2021-11-03 16:55:23 +0000 URL: https://git.openjdk.java.net/loom/commit/684edbb4c884cbc3e05118e4bc9808b5d5b71a74 8273922: (fs) UserDefinedFileAttributeView doesn't handle file names that are just under the MAX_PATH limit (win) Reviewed-by: alanb ! src/java.base/windows/classes/sun/nio/fs/WindowsUserDefinedFileAttributeView.java ! test/jdk/java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java Changeset: c7f070f5 Author: Jakob Cornell Committer: Chris Plummer Date: 2021-11-03 18:18:16 +0000 URL: https://git.openjdk.java.net/loom/commit/c7f070f5f17dad661cc3296f2e3cd7a1cd5fc742 8276208: vmTestbase/nsk/jdb/repeat/repeat001/repeat001.java fails with "AssertionError: Unexpected output" Reviewed-by: cjplummer, iklam ! test/hotspot/jtreg/vmTestbase/nsk/jdb/list/list003/list003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdb/repeat/repeat001/repeat001.java Changeset: 32895ac6 Author: Ivan ?ipka Committer: Mark Sheppard Date: 2021-11-03 19:30:12 +0000 URL: https://git.openjdk.java.net/loom/commit/32895ac60949ccceb0a3d25c73ec5e3a00c29593 8275650: Problemlist java/io/File/createTempFile/SpecialTempFile.java for Windows 11 Reviewed-by: bpb, msheppar + out ! test/jdk/ProblemList.txt Changeset: f3320d2f Author: Joe Darcy Date: 2021-11-03 21:20:09 +0000 URL: https://git.openjdk.java.net/loom/commit/f3320d2fbd28349fa5eab3ea0da0ff0a3ef54c62 8276588: Change "ccc" to "CSR" in HotSpot sources Reviewed-by: dcubed, kbarrett ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/runtime/globals.hpp Changeset: 0ab910d6 Author: Jie Fu Date: 2021-11-03 22:45:50 +0000 URL: https://git.openjdk.java.net/loom/commit/0ab910d626a05106e1366438aeb5b16e16374c2f 8276066: Reset LoopPercentProfileLimit for x86 due to suboptimal performance Reviewed-by: thartmann, kvn ! src/hotspot/cpu/x86/c2_globals_x86.hpp + test/micro/org/openjdk/bench/vm/compiler/LoopUnroll.java Changeset: ce8c7670 Author: Claes Redestad Date: 2021-11-03 22:57:13 +0000 URL: https://git.openjdk.java.net/loom/commit/ce8c76700ba854f43c48d32b068b30e7d78d9d1e 8276220: Reduce excessive allocations in DateTimeFormatter Reviewed-by: scolebourne, naoto ! src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/java.base/share/classes/java/time/format/DateTimePrintContext.java ! test/jdk/java/time/test/java/time/format/TestFractionPrinterParser.java + test/micro/org/openjdk/bench/java/time/format/DateTimeFormatterBench.java Changeset: 603bba28 Author: Yumin Qi Date: 2021-11-03 23:16:15 +0000 URL: https://git.openjdk.java.net/loom/commit/603bba282a089928fd23f8da23a7c1b2d52944ef 8271420: Extend CDS custom loader support to Windows platform Reviewed-by: iklam, ccheung ! src/hotspot/share/cds/classListParser.cpp ! test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/LoaderConstraintsTest.java ! test/hotspot/jtreg/runtime/cds/appcds/test-classes/CustomAppLoader.java ! test/lib/jdk/test/lib/Platform.java Changeset: 558ee40a Author: Yasumasa Suenaga Date: 2021-11-04 04:34:07 +0000 URL: https://git.openjdk.java.net/loom/commit/558ee40a4ac158e5be8269c87b7e18af77dd14c5 8276615: Update CR number of some tests in ProblemList-zgc.txt Reviewed-by: dholmes ! test/hotspot/jtreg/ProblemList-zgc.txt Changeset: fb0be81f Author: Aleksey Shipilev Date: 2021-11-04 08:03:51 +0000 URL: https://git.openjdk.java.net/loom/commit/fb0be81f0148d9aea73321a0c2bd83b2e477d952 8276096: Simplify Unsafe.{load|store}Fence fallbacks by delegating to fullFence Reviewed-by: psandoz, aph, dholmes ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/prims/unsafe.cpp ! src/java.base/share/classes/jdk/internal/misc/Unsafe.java Changeset: 9eadcbb4 Author: Aleksey Shipilev Date: 2021-11-04 08:08:07 +0000 URL: https://git.openjdk.java.net/loom/commit/9eadcbb47e902f42d933ba68e24f2bfb0ee20915 8276217: Harmonize StrictMath intrinsics handling Reviewed-by: aph, kvn ! src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp ! src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp ! src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp ! src/hotspot/cpu/s390/c1_LIRGenerator_s390.cpp ! src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp ! src/hotspot/share/c1/c1_Compiler.cpp ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/classfile/vmIntrinsics.cpp ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/interpreter/abstractInterpreter.cpp ! src/hotspot/share/interpreter/abstractInterpreter.hpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/library_call.cpp Changeset: a1f4c428 Author: Christian Hagedorn Date: 2021-11-04 08:53:37 +0000 URL: https://git.openjdk.java.net/loom/commit/a1f4c428ba1b78a4e18afb87c94a5c731a5aa706 8276227: ciReplay: SIGSEGV if classfile for replay compilation is not present after JDK-8275868 Reviewed-by: kvn, thartmann, dlong ! src/hotspot/share/ci/ciReplay.cpp + test/hotspot/jtreg/compiler/ciReplay/TestNoClassFile.java Changeset: c62b3476 Author: Aleksey Shipilev Date: 2021-11-04 09:03:21 +0000 URL: https://git.openjdk.java.net/loom/commit/c62b3476ce12cea633abead0d6376ea0a05f92f9 8276623: JDK-8275650 accidentally pushed "out" file Reviewed-by: tschatzl, dholmes - out Changeset: 3613ce7c Author: Aleksey Shipilev Date: 2021-11-04 10:23:11 +0000 URL: https://git.openjdk.java.net/loom/commit/3613ce7c7d5bc8b7d603e1cf6a123588339aed3f 8275586: Zero: Simplify interpreter initialization Reviewed-by: aph, adinn ! src/hotspot/cpu/zero/vm_version_zero.cpp ! src/hotspot/cpu/zero/zeroInterpreter_zero.cpp ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp Changeset: ee499632 Author: Julia Boes Date: 2021-11-04 11:31:51 +0000 URL: https://git.openjdk.java.net/loom/commit/ee499632586eabb3dab209645d5b9c781a09034b 8275534: com.sun.net.httpserver.BasicAuthenticator should check whether "realm" is a quoted string Reviewed-by: michaelm, dfuchs ! src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java ! src/jdk.httpserver/share/classes/com/sun/net/httpserver/BasicAuthenticator.java ! src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java + src/jdk.httpserver/share/classes/sun/net/httpserver/Utils.java + test/jdk/com/sun/net/httpserver/BasicAuthenticatorRealm.java ! test/jdk/com/sun/net/httpserver/bugs/BasicAuthenticatorExceptionCheck.java Changeset: 7de653e4 Author: Hamlin Li Date: 2021-11-04 12:31:27 +0000 URL: https://git.openjdk.java.net/loom/commit/7de653e428ee38339ec38533659b23a52e275f3f 8276301: G1: Refine implementation of G1CardSetFreePool::memory_sizes() Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1CardSetMemory.cpp ! src/hotspot/share/gc/g1/g1CardSetMemory.hpp Changeset: 19075b3f Author: Hannes Walln?fer Date: 2021-11-04 13:06:24 +0000 URL: https://git.openjdk.java.net/loom/commit/19075b3f6b21f6d3b0624ef8e835b3cfc53228de 8275788: Create code element with suitable attributes for code snippets Reviewed-by: prappo ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SnippetTaglet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletWriter.java ! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java Changeset: a6fa6ed1 Author: Per Liden Date: 2021-11-04 13:47:59 +0000 URL: https://git.openjdk.java.net/loom/commit/a6fa6ed1edc6f473a7fea1fa00edd467ab778983 8268779: ZGC: runtime/InternalApi/ThreadCpuTimesDeadlock.java#id1 failed with "OutOfMemoryError: Java heap space" Reviewed-by: eosterlund, stefank ! src/hotspot/share/gc/z/zDriver.cpp Changeset: 5acff753 Author: Evgeny Astigeevich Committer: Vladimir Kozlov Date: 2021-11-04 15:01:26 +0000 URL: https://git.openjdk.java.net/loom/commit/5acff75379a4ad0acfcfc6a64fcc4b588ef048c7 8276429: CodeHeapState::print_names() fails with "assert(klass->is_loader_alive()) failed: must be alive" Reviewed-by: kvn ! src/hotspot/share/code/codeHeapState.cpp Changeset: 49b7b2ea Author: Magnus Ihse Bursie Date: 2021-11-04 15:06:08 +0000 URL: https://git.openjdk.java.net/loom/commit/49b7b2ea0971fe99567bdbd962d63b90ff2eeefd 8276640: Use blessed modifier order in jfr code Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/internal/FilePurger.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/JVM.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformRecorder.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/PrivateAccess.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java Changeset: afb502e2 Author: Aleksey Shipilev Date: 2021-11-04 15:41:39 +0000 URL: https://git.openjdk.java.net/loom/commit/afb502e28a81183cef76a7e60fc052e8cad3afe3 8276550: Use SHA256 hash in build.tools.depend.Depend Reviewed-by: adinn, aph, andrew, ihse ! make/jdk/src/classes/build/tools/depend/Depend.java Changeset: bf4ddf9c Author: Pavel Rappo Date: 2021-11-04 15:51:37 +0000 URL: https://git.openjdk.java.net/loom/commit/bf4ddf9cb7408db321e7fd73600a5a9a85ca49eb 8276338: Minor improve of wording for String.to(Lower|Upper)Case Reviewed-by: rriggs, naoto ! src/java.base/share/classes/java/lang/String.java Changeset: b57715a1 Author: Pavel Rappo Date: 2021-11-04 15:56:19 +0000 URL: https://git.openjdk.java.net/loom/commit/b57715a117d9b7f79fcf4fec3b8f369b6aa42598 8276573: Use blessed modifier order in jdk.javadoc Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/DeprecatedListWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Attribute.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/MarkupParser.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/DocLint.java Changeset: 7bb21733 Author: Brian Burkhalter Date: 2021-11-04 16:33:08 +0000 URL: https://git.openjdk.java.net/loom/commit/7bb2173383bc1c0d55564d31303a547957d87a15 8276199: java/nio/channels/FileChannel/LargeGatheringWrite.java fails to terminate correctly Reviewed-by: alanb ! test/jdk/ProblemList.txt ! test/jdk/java/nio/channels/FileChannel/LargeGatheringWrite.java Changeset: 1533b819 Author: Magnus Ihse Bursie Date: 2021-11-04 17:02:42 +0000 URL: https://git.openjdk.java.net/loom/commit/1533b8191bed9d65ab4af03945584d8b2276d828 8276629: Use blessed modifier order in core-libs code Reviewed-by: dholmes, aefimov, dfuchs, mchung, iris ! src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java ! src/java.naming/share/classes/com/sun/jndi/ldap/LdapClient.java ! src/java.naming/share/classes/com/sun/jndi/ldap/LdapCtx.java ! src/java.rmi/share/classes/java/rmi/server/LoaderHandler.java ! src/java.rmi/share/classes/java/rmi/server/RMISocketFactory.java ! src/java.rmi/share/classes/java/rmi/server/RemoteObject.java ! src/java.rmi/share/classes/java/rmi/server/RemoteRef.java ! src/java.rmi/share/classes/java/rmi/server/RemoteStub.java ! src/java.rmi/share/classes/sun/rmi/log/ReliableLog.java ! src/java.rmi/share/classes/sun/rmi/transport/ObjectTable.java ! src/java.rmi/share/classes/sun/rmi/transport/Target.java ! src/java.sql.rowset/share/classes/javax/sql/rowset/RowSetProvider.java ! src/jdk.dynalink/share/classes/jdk/dynalink/BiClassValue.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/Annotation.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/ConstantPool.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/Dependencies.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/StackMapTable_attribute.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/JavapTask.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsTask.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Module.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Profile.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginStack.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageResourcesTree.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/PluginRepository.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ResourceFilter.java ! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java ! src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsContext.java ! src/jdk.naming.rmi/share/classes/com/sun/jndi/rmi/registry/RegistryContextFactory.java Changeset: 99d4b07c Author: Ludvig Janiuk Committer: Mandy Chung Date: 2021-11-04 17:26:18 +0000 URL: https://git.openjdk.java.net/loom/commit/99d4b07cddec05428e4d578ba6f494f51b92e841 8276649: MethodHandles.Lookup docs: replace the table in the cross-module access check section with list Reviewed-by: mchung ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java Changeset: 2b5a32c7 Author: Zhengyu Gu Date: 2021-11-04 19:40:22 +0000 URL: https://git.openjdk.java.net/loom/commit/2b5a32c73f22c69d7ccedac761af1dbb4a7f297d 8275718: Relax memory constraint on exception counter updates Reviewed-by: dholmes, minqi ! src/hotspot/share/utilities/exceptions.cpp Changeset: 81203efe Author: Magnus Ihse Bursie Date: 2021-11-04 19:44:05 +0000 URL: https://git.openjdk.java.net/loom/commit/81203efe411320ff4e390605f980d14e7f70252f 8276655: Use blessed modifier order in SCTP Reviewed-by: alanb, dfuchs ! src/jdk.sctp/unix/classes/sun/nio/ch/sctp/AssociationChange.java ! src/jdk.sctp/unix/classes/sun/nio/ch/sctp/PeerAddrChange.java Changeset: dcf36f87 Author: Dean Long Date: 2021-11-04 19:52:27 +0000 URL: https://git.openjdk.java.net/loom/commit/dcf36f87f87d52490c1f0434c2fca99fc8fd90a2 8275670: ciReplay: java.lang.NoClassDefFoundError when trying to load java/lang/invoke/LambdaForm$MH Reviewed-by: kvn, chagedorn ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciEnv.hpp + test/hotspot/jtreg/compiler/ciReplay/TestLambdas.java Changeset: 7e87f946 Author: Ludvig Janiuk Committer: Mandy Chung Date: 2021-11-04 20:46:23 +0000 URL: https://git.openjdk.java.net/loom/commit/7e87f946cedf93f19c38fd596039a16394c03ea4 8276652: Missing row headers in MethodHandles.Lookup docs Reviewed-by: mchung ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java Changeset: 8ec80c4b Author: Ludvig Janiuk Committer: Naoto Sato Date: 2021-11-04 21:06:03 +0000 URL: https://git.openjdk.java.net/loom/commit/8ec80c4bc1c3169963137b5a16a1b787540a3589 8276653: Missing row headers in j.l.Character docs Reviewed-by: naoto ! src/java.base/share/classes/java/lang/Character.java Changeset: 7b1916ef Author: Alisen Chung Committer: Phil Race Date: 2021-11-04 21:53:29 +0000 URL: https://git.openjdk.java.net/loom/commit/7b1916efda95a46439cf42e006593361d12a8823 8233557: [TESTBUG] DoubleClickTitleBarTest.java fails on macOs Reviewed-by: prr ! test/jdk/ProblemList.txt Changeset: e21b5c7b Author: Mandy Chung Date: 2021-11-04 23:51:18 +0000 URL: https://git.openjdk.java.net/loom/commit/e21b5c7b3781430ecf568e7f5c89ef3391e06d9e 8276650: GenGraphs does not produce deterministic output Reviewed-by: iris ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleDotGraph.java ! test/langtools/tools/jdeps/modules/DotFileTest.java Changeset: 9ad4d3d0 Author: Sandhya Viswanathan Date: 2021-11-05 03:30:09 +0000 URL: https://git.openjdk.java.net/loom/commit/9ad4d3d06bb356436d69af07726ef6727c500f59 8276025: Hotspot's libsvml.so may conflict with user dependency Reviewed-by: kvn, erikj, psandoz, ihse ! make/modules/jdk.incubator.vector/Lib.gmk ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp = src/jdk.incubator.vector/linux/native/libjsvml/globals_vectorApiSupport_linux.S.inc + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_acos_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_asin_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_atan2_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_atan_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_cbrt_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_cos_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_cosh_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_exp_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_expm1_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_hypot_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_log10_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_log1p_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_log_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_pow_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_sin_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_sinh_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_tan_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_tanh_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_acos_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_asin_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_atan2_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_atan_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_cbrt_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_cos_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_cosh_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_exp_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_expm1_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_hypot_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_log10_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_log1p_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_log_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_pow_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_sin_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_sinh_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_tan_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_tanh_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_acos_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_asin_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_atan2_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_atan_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_cbrt_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_cosh_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_exp_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_expm1_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_log10_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_s_atan_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_s_cbrt_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_s_exp_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_s_expm1_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_s_log10_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_s_log1p_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_s_log_linux_x86.S = src/jdk.incubator.vector/windows/native/libjsvml/globals_vectorApiSupport_windows.S.inc + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_acos_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_asin_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_atan2_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_atan_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_cbrt_windows_x86.S = src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_cos_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_cosh_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_exp_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_expm1_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_hypot_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_log10_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_log1p_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_log_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_pow_windows_x86.S = src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_sin_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_sinh_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_tan_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_tanh_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_acos_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_asin_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_atan2_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_atan_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_cbrt_windows_x86.S = src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_cos_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_cosh_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_exp_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_expm1_windows_x86.S = src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_hypot_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_log10_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_log1p_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_log_windows_x86.S = src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_pow_windows_x86.S = src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_sin_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_sinh_windows_x86.S = src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_tan_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_tanh_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_acos_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_asin_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_atan2_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_atan_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_cbrt_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_cosh_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_exp_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_expm1_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_hypot_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_log10_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_log1p_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_log_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_pow_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_sinh_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_tan_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_tanh_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_acos_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_asin_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_atan2_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_atan_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_cbrt_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_cosh_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_exp_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_expm1_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_log10_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_log1p_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_log_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_sinh_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_tanh_windows_x86.S ! test/jdk/jdk/incubator/vector/ImageTest.java = test/jdk/jdk/incubator/vector/LoadJsvmlTest.java Changeset: 396132ff Author: Jaikiran Pai Date: 2021-11-05 03:44:45 +0000 URL: https://git.openjdk.java.net/loom/commit/396132ff1e56463ad195cac5c9ac8e2eac5a16e8 8275509: ModuleDescriptor.hashCode isn't reproducible across builds Reviewed-by: alanb, ihse ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java + test/jdk/java/lang/module/ModuleDescriptorHashCodeTest.java Changeset: 8e17ce00 Author: Ioi Lam Date: 2021-11-05 04:37:01 +0000 URL: https://git.openjdk.java.net/loom/commit/8e17ce00316a765bbedefc34dc5898ba4f3f2144 8275185: Remove dead code and clean up jvmstat LocalVmManager Reviewed-by: cjplummer, redestad, kevinw ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalVmManager.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/PerfDataFile.java Changeset: 7281861e Author: Thomas Stuefe Date: 2021-11-05 05:15:53 +0000 URL: https://git.openjdk.java.net/loom/commit/7281861e0662e6c51507066a1f12673a236c7491 8272065: jcmd cannot rely on the old core reflection implementation which will be changed after JEP 416 Reviewed-by: mchung, coleenp, dholmes ! src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp ! src/hotspot/share/memory/heapInspection.cpp ! src/hotspot/share/memory/metaspace/printMetaspaceInfoKlassClosure.cpp - src/hotspot/share/oops/reflectionAccessorImplKlassHelper.cpp - src/hotspot/share/oops/reflectionAccessorImplKlassHelper.hpp ! test/hotspot/jtreg/serviceability/dcmd/vm/ClassLoaderHierarchyTest.java ! test/hotspot/jtreg/serviceability/dcmd/vm/ClassLoaderStatsTest.java - test/hotspot/jtreg/serviceability/dcmd/vm/ShowReflectionTargetTest.java Changeset: 96c396b7 Author: Ningsheng Jian Date: 2021-11-05 07:45:54 +0000 URL: https://git.openjdk.java.net/loom/commit/96c396b701e290fc3e1124b1c862b41e02e9c1d9 8276151: AArch64: Incorrect result for double to int vector conversion Reviewed-by: aph, psandoz ! src/hotspot/cpu/aarch64/aarch64_neon.ad ! src/hotspot/cpu/aarch64/aarch64_neon_ad.m4 ! test/hotspot/jtreg/compiler/vectorapi/VectorCastShape128Test.java ! test/hotspot/jtreg/compiler/vectorapi/VectorCastShape64Test.java Changeset: 323d2017 Author: Leo Korinth Date: 2021-11-05 09:25:21 +0000 URL: https://git.openjdk.java.net/loom/commit/323d2017959dc96d25eaa1aad6404586099c237e 8275506: Rename allocated_on_stack to allocated_on_stack_or_embedded Reviewed-by: stuefe ! src/hotspot/share/asm/codeBuffer.cpp ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/memory/allocation.cpp ! src/hotspot/share/memory/allocation.hpp ! src/hotspot/share/utilities/growableArray.cpp ! test/hotspot/gtest/utilities/test_growableArray.cpp Changeset: 3c0faa73 Author: Leo Korinth Date: 2021-11-05 09:42:26 +0000 URL: https://git.openjdk.java.net/loom/commit/3c0faa73522bd004b66cb9e477f43e15a29842e6 8276173: Clean up and remove unneeded casts in HeapDumper Reviewed-by: coleenp, hseigel ! src/hotspot/share/services/heapDumper.cpp Changeset: d95299a4 Author: Patrick Concannon Date: 2021-11-05 10:39:37 +0000 URL: https://git.openjdk.java.net/loom/commit/d95299a4d751449816ad2a88359f1e48e9608246 8276634: Remove `usePlainDatagramSocketImpl` option from the test DatagramChannel/SendReceiveMaxSize.java Reviewed-by: dfuchs, alanb, vtewari ! test/jdk/java/nio/channels/DatagramChannel/ChangingAddress.java ! test/jdk/java/nio/channels/DatagramChannel/SendReceiveMaxSize.java Changeset: 0616d868 Author: Magnus Ihse Bursie Date: 2021-11-05 12:05:22 +0000 URL: https://git.openjdk.java.net/loom/commit/0616d868c7cd5010f017b315fa1cf6cc1617ce29 8276635: Use blessed modifier order in compiler code Reviewed-by: darcy ! src/java.compiler/share/classes/javax/tools/Diagnostic.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JRTIndex.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/StringConcat.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Dependencies.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/GraphUtils.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Name.java ! src/jdk.jartool/share/classes/sun/tools/jar/GNUStyleOptions.java Changeset: b9331360 Author: Magnus Ihse Bursie Date: 2021-11-05 12:06:39 +0000 URL: https://git.openjdk.java.net/loom/commit/b9331360f50afe5b4549d7003d4932ebc54a3c71 8276641: Use blessed modifier order in jshell Reviewed-by: iris ! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/AnsiWriter.java ! src/jdk.internal.le/windows/classes/jdk/internal/org/jline/terminal/impl/jna/win/WindowsAnsiWriter.java ! src/jdk.jshell/share/classes/jdk/jshell/Key.java ! src/jdk.jshell/share/classes/jdk/jshell/MemoryFileManager.java ! src/jdk.jshell/share/classes/jdk/jshell/spi/ExecutionControl.java Changeset: 7023b3f8 Author: Magnus Ihse Bursie Date: 2021-11-05 12:07:58 +0000 URL: https://git.openjdk.java.net/loom/commit/7023b3f8a120dda97bc27fdf130c05c1bd7a730b 8276628: Use blessed modifier order in serviceability code Reviewed-by: dholmes, lmesnik, cjplummer ! src/java.management/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java ! src/java.management/share/classes/com/sun/jmx/mbeanserver/Introspector.java ! src/java.management/share/classes/com/sun/jmx/mbeanserver/MBeanServerDelegateImpl.java ! src/java.management/share/classes/com/sun/jmx/mbeanserver/MXBeanProxy.java ! src/java.management/share/classes/com/sun/jmx/remote/internal/ClientNotifForwarder.java ! src/java.management/share/classes/com/sun/jmx/remote/security/HashedPasswordManager.java ! src/java.management/share/classes/javax/management/MBeanServerFactory.java ! src/java.management/share/classes/javax/management/ObjectName.java ! src/java.management/share/classes/javax/management/modelmbean/RequiredModelMBean.java ! src/java.management/share/classes/javax/management/timer/Timer.java ! src/java.management/share/classes/sun/management/ClassLoadingImpl.java ! src/java.management/share/classes/sun/management/NotificationEmitterSupport.java ! src/java.management/share/classes/sun/management/VMManagementImpl.java ! src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java ! src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java ! src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/compiler/OopMapValue.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/aarch64/BsdAARCH64CFrame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/amd64/BsdAMD64CFrame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/x86/BsdX86CFrame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/LinuxDebuggerLocal.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/aarch64/LinuxAARCH64CFrame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/amd64/LinuxAMD64CFrame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64CFrame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/x86/LinuxX86CFrame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1CollectedHeap.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1HeapRegionTable.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1MonitoringSupport.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/HeapRegion.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/HeapRegionManager.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/HeapRegionSetBase.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/GenCollectedHeap.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shenandoah/ShenandoahHeap.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shenandoah/ShenandoahHeapRegion.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZAttachedArrayForForwarding.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZForwarding.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZForwardingEntry.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZForwardingTable.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZGlobals.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZGlobalsForVMStructs.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZGranuleMapForForwarding.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZGranuleMapForPageTable.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZPage.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZPageAllocator.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZPageTable.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZRelocate.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZVirtualMemory.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/DataLayout.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/DefaultMetadataVisitor.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Metadata.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/MethodData.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ParametersTypeData.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/SpeculativeTrapData.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/CallRuntimeNode.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/CallStaticJavaNode.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/Node.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/InstanceConstructor.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/jcore/ByteCodeRewriter.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/tree/CTypeTreeNodeAdapter.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/AbstractHeapGraphWriter.java ! src/jdk.jcmd/share/classes/sun/tools/jinfo/JInfo.java ! src/jdk.jconsole/share/classes/sun/tools/jconsole/inspector/XOpenTypeViewer.java ! src/jdk.jdi/share/classes/com/sun/jdi/Bootstrap.java ! src/jdk.jdi/share/classes/com/sun/jdi/connect/spi/TransportService.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/expr/ExpressionParser.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/Env.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/VMConnection.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/AbstractLauncher.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ClassTypeImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ConcreteMethodImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/InterfaceTypeImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/InvokableTypeImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/Packet.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/PrimitiveValueImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/RawCommandLineLauncher.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ReferenceTypeImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/TargetVM.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ThreadReferenceImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/TypeComponentImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java ! src/jdk.management.agent/share/classes/jdk/internal/agent/Agent.java ! src/jdk.management.agent/share/classes/sun/management/jdp/JdpJmxPacket.java ! src/jdk.management/share/classes/com/sun/management/internal/DiagnosticCommandImpl.java ! src/jdk.management/share/classes/com/sun/management/internal/GarbageCollectorExtImpl.java ! src/jdk.management/share/classes/com/sun/management/internal/PlatformMBeanProviderImpl.java Changeset: c393ee8f Author: Magnus Ihse Bursie Date: 2021-11-05 14:09:58 +0000 URL: https://git.openjdk.java.net/loom/commit/c393ee8f598850379266bdba1f55af94744dbad1 8276632: Use blessed modifier order in security-libs code Reviewed-by: mullan ! src/java.security.jgss/share/classes/sun/security/jgss/ProviderList.java ! src/java.security.jgss/share/classes/sun/security/jgss/TokenTracker.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! src/java.smartcardio/share/classes/javax/smartcardio/CardNotPresentException.java ! src/java.smartcardio/share/classes/javax/smartcardio/CardPermission.java ! src/java.smartcardio/share/classes/javax/smartcardio/TerminalFactory.java ! src/java.smartcardio/share/classes/sun/security/smartcardio/ChannelImpl.java ! src/java.smartcardio/share/classes/sun/security/smartcardio/PCSC.java ! src/java.smartcardio/unix/classes/sun/security/smartcardio/PlatformPCSC.java ! src/java.smartcardio/windows/classes/sun/security/smartcardio/PlatformPCSC.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Secmod.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/Constants.java ! src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/CKey.java ! src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/CRSACipher.java ! src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/CSignature.java Changeset: a74a839a Author: Vladimir Kozlov Date: 2021-11-05 16:07:25 +0000 URL: https://git.openjdk.java.net/loom/commit/a74a839af02446d322d77c6e546e652ec6ad5d73 8276571: C2: pass compilation options as structure Reviewed-by: shade, chagedorn ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/runtime/vmStructs.cpp Changeset: 92d21763 Author: Daniel D. Daugherty Date: 2021-11-05 17:04:39 +0000 URL: https://git.openjdk.java.net/loom/commit/92d2176362954a7093894057748056610eeafe4b 8273967: gtest os.dll_address_to_function_and_library_name_vm fails on macOS12 Reviewed-by: stuefe, gziemski ! src/hotspot/os/bsd/decoder_machO.cpp ! src/hotspot/os/bsd/os_bsd.cpp ! src/hotspot/share/runtime/os.cpp ! test/hotspot/gtest/runtime/test_os.cpp Changeset: b01f1073 Author: Brian Burkhalter Date: 2021-11-05 17:25:06 +0000 URL: https://git.openjdk.java.net/loom/commit/b01f1073f9691c40fc15b7ed67ae2e019ff729ea 8276252: java/nio/channels/Channels/TransferTo.java failed with OOM java heap space error Reviewed-by: lancea ! test/jdk/java/nio/channels/Channels/TransferTo.java Changeset: a4724332 Author: Andrew John Hughes Date: 2021-11-05 21:05:42 +0000 URL: https://git.openjdk.java.net/loom/commit/a4724332098cd8bff44ee27e9190fd28fa5c1865 8276572: Fake libsyslookup.so library causes tooling issues Reviewed-by: shade, mcimadamore ! src/jdk.incubator.foreign/share/native/libsyslookup/syslookup.c Changeset: 0e0dd33f Author: Kim Barrett Date: 2021-11-05 21:20:51 +0000 URL: https://git.openjdk.java.net/loom/commit/0e0dd33fff9922a086968cfa6ccd27727f979c83 8276129: PretouchTask should page-align the chunk size Reviewed-by: stefank, tschatzl ! src/hotspot/share/gc/shared/pretouchTask.cpp Changeset: 59c3dcc7 Author: Magnus Ihse Bursie Date: 2021-11-05 21:21:38 +0000 URL: https://git.openjdk.java.net/loom/commit/59c3dcc761ac7a9eab1517743cbb77e5526ca6f3 8276746: Add section on reproducible builds in building.md Reviewed-by: erikj, sgehwolf, aleonard ! doc/building.html ! doc/building.md Changeset: ed7ecca4 Author: Hamlin Li Date: 2021-11-05 23:24:45 +0000 URL: https://git.openjdk.java.net/loom/commit/ed7ecca401e5f4c3c07dc98e05a21396c6cdf594 8254739: G1: Optimize evacuation failure for regions with few failed objects Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1CardSetMemory.cpp ! src/hotspot/share/gc/g1/g1CardSetMemory.hpp ! src/hotspot/share/gc/g1/g1EvacFailure.cpp + src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.cpp + src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.hpp ! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp ! src/hotspot/share/gc/g1/g1SegmentedArray.hpp ! src/hotspot/share/gc/g1/g1SegmentedArray.inline.hpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegion.hpp ! src/hotspot/share/gc/g1/heapRegion.inline.hpp ! test/hotspot/gtest/gc/g1/test_freeRegionList.cpp Changeset: c7095b20 Author: Anirvan Sarkar Committer: Joe Wang Date: 2021-11-06 00:41:44 +0000 URL: https://git.openjdk.java.net/loom/commit/c7095b20d956e154d9863a7928d26285f1a0a0ac 8276207: Properties.loadFromXML/storeToXML works incorrectly for supplementary characters Reviewed-by: joehw ! src/java.base/share/classes/jdk/internal/util/xml/impl/Parser.java ! src/java.base/share/classes/jdk/internal/util/xml/impl/XMLStreamWriterImpl.java ! test/jdk/java/util/Properties/LoadAndStoreXML.java Changeset: 2653cfbf Author: Jaikiran Pai Date: 2021-11-06 03:36:46 +0000 URL: https://git.openjdk.java.net/loom/commit/2653cfbf0f316183ea23dd234896b44f7dd6eae0 8276688: Remove JLinkReproducibleXXXTest from ProblemList.txt Reviewed-by: alanb, mchung ! test/jdk/ProblemList.txt Changeset: 88491549 Author: Ioi Lam Date: 2021-11-07 21:38:59 +0000 URL: https://git.openjdk.java.net/loom/commit/884915496f7bfe754279f1644603131c64f192b3 8275846: read_base_archive_name() could read past the end of buffer Reviewed-by: ccheung, stuefe ! src/hotspot/share/cds/filemap.cpp ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/ArchiveConsistency.java Changeset: 44047f84 Author: Yi Yang Date: 2021-11-08 02:18:40 +0000 URL: https://git.openjdk.java.net/loom/commit/44047f849fad157dac5df788aa5a2c1838e4aaf7 8274328: C2: Redundant CFG edges fixup in block ordering Reviewed-by: thartmann, kvn ! src/hotspot/share/opto/block.cpp ! src/hotspot/share/opto/block.hpp Changeset: 3934fe54 Author: Nick Gasson Date: 2021-11-08 06:40:49 +0000 URL: https://git.openjdk.java.net/loom/commit/3934fe54b4c3e51add6d3fe1f145e5aebfe3b2fc 8275847: Scheduling fails with "too many D-U pinch points" on small method Reviewed-by: thartmann, kvn ! src/hotspot/cpu/x86/vmreg_x86.hpp ! src/hotspot/share/opto/buildOopMap.cpp ! src/hotspot/share/opto/output.cpp + test/hotspot/jtreg/compiler/c2/irTests/TestScheduleSmallMethod.java Changeset: fc0fe256 Author: Christian Stein Committer: Aleksey Shipilev Date: 2021-11-08 08:09:51 +0000 URL: https://git.openjdk.java.net/loom/commit/fc0fe256793b33430c1247e0c091150a091da3c4 8273235: tools/launcher/HelpFlagsTest.java Fails on Windows 32bit Reviewed-by: shade ! test/jdk/tools/launcher/HelpFlagsTest.java Changeset: d8b0dee6 Author: Ludvig Janiuk Committer: Claes Redestad Date: 2021-11-08 09:44:44 +0000 URL: https://git.openjdk.java.net/loom/commit/d8b0dee65e7e074d81eecf451542f79747ea7c78 8276239: Better tables in java.util.random package summary Reviewed-by: jlaskey ! src/java.base/share/classes/java/util/random/package-info.java Changeset: 0395e4ef Author: Hannes Walln?fer Date: 2021-11-08 11:35:26 +0000 URL: https://git.openjdk.java.net/loom/commit/0395e4ef8ced8385cc2c9b3bea4c6f4490c62d2b 8276768: Snippet copy feature should use button instead of link Reviewed-by: prappo ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/script.js ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css ! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java ! test/langtools/jdk/javadoc/lib/javadoc/tester/LinkChecker.java Changeset: 54481394 Author: Christian Hagedorn Date: 2021-11-08 12:47:58 +0000 URL: https://git.openjdk.java.net/loom/commit/54481394a3b7d36b2326e22e4aa910a3e8041b5c 8271056: C2: "assert(no_dead_loop) failed: dead loop detected" due to cmoving identity Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/cfgnode.cpp + test/hotspot/jtreg/compiler/c2/TestDeadDataLoopCmoveIdentity.java Changeset: ff6863c9 Author: Thomas Schatzl Date: 2021-11-08 12:59:00 +0000 URL: https://git.openjdk.java.net/loom/commit/ff6863c98dbd15c4f3920402eb0991727d1a380c 8276540: Howl Full CardSet container iteration marks too many cards Reviewed-by: ayang, sjohanss ! src/hotspot/share/gc/g1/g1CardSetContainers.inline.hpp Changeset: 4c14eddf Author: Jan Lahoda Date: 2021-11-08 13:19:51 +0000 URL: https://git.openjdk.java.net/loom/commit/4c14eddf41f1d9984417dc5ac6aba6f268b31029 8274734: the method jdk.jshell.SourceCodeAnalysis documentation not working Reviewed-by: vromero ! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java + test/langtools/jdk/jshell/MultipleDocumentationTest.java Changeset: fa754b8f Author: Jan Lahoda Date: 2021-11-08 13:20:44 +0000 URL: https://git.openjdk.java.net/loom/commit/fa754b8ffda0ae16cda03d896260870ff8fb6ae9 8276149: jshell throws EOF error when throwing exception inside switch expression Reviewed-by: vromero ! src/jdk.jshell/share/classes/jdk/jshell/CompletenessAnalyzer.java ! test/langtools/jdk/jshell/CompletenessTest.java Changeset: 0c2d00bf Author: Jan Lahoda Date: 2021-11-08 13:21:40 +0000 URL: https://git.openjdk.java.net/loom/commit/0c2d00bff7b96cca53820aadfdaf09c840a2a33a 8275097: Wrong span of the 'default' tag Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! test/langtools/tools/javac/parser/JavacParserTest.java ! test/langtools/tools/javac/patterns/SwitchErrors.out Changeset: cc2cac13 Author: Petr Portnov Committer: Roger Riggs Date: 2021-11-08 13:22:37 +0000 URL: https://git.openjdk.java.net/loom/commit/cc2cac130cc28730a30d2e1d76bcb6ec8bc0b580 8274686: java.util.UUID#hashCode() should use Long.hashCode() Reviewed-by: rriggs ! src/java.base/share/classes/java/util/UUID.java Changeset: 71c4b195 Author: Andy Herrick Date: 2021-11-08 13:45:23 +0000 URL: https://git.openjdk.java.net/loom/commit/71c4b195178029f5414fa45d2c5ac70a1d2536e5 8276562: Fix to JDK-8263155 left out the help text changes Reviewed-by: asemenyuk, almatvee ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/CLIHelp.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_ja.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_zh_CN.properties Changeset: c815c5cb Author: Denghui Dong Date: 2021-11-08 14:30:54 +0000 URL: https://git.openjdk.java.net/loom/commit/c815c5cbbb0b6a2aebd0a38cb930c74bd665d082 8276209: Some call sites doesn't pass the parameter 'size' to SharedRuntime::dtrace_object_alloc(_base) Reviewed-by: dholmes, coleenp ! src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp ! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp ! src/hotspot/cpu/arm/templateTable_arm.cpp ! src/hotspot/cpu/ppc/c1_Runtime1_ppc.cpp ! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp ! src/hotspot/cpu/s390/c1_Runtime1_s390.cpp ! src/hotspot/cpu/s390/templateTable_s390.cpp ! src/hotspot/cpu/x86/c1_Runtime1_x86.cpp ! src/hotspot/cpu/x86/templateTable_x86.cpp ! src/hotspot/share/gc/shared/memAllocator.cpp ! src/hotspot/share/opto/macro.cpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp Changeset: ea23e733 Author: Daniel D. Daugherty Date: 2021-11-08 14:45:04 +0000 URL: https://git.openjdk.java.net/loom/commit/ea23e7333e03abb4aca3e9f3854bab418a4b70e2 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes Reviewed-by: coleenp, sspitsyn, dholmes, rehn ! src/hotspot/share/prims/jvmtiEnv.cpp ! src/hotspot/share/prims/jvmtiEventController.cpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/handshake.cpp ! src/hotspot/share/runtime/handshake.hpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp Changeset: 7320b77b Author: Thomas Schatzl Date: 2021-11-08 15:00:31 +0000 URL: https://git.openjdk.java.net/loom/commit/7320b77b3e451932ee8befa7af4b80593725761e 8276548: Use range based visitor for Howl-Full cards Reviewed-by: ayang, sjohanss ! src/hotspot/share/gc/g1/g1CardSetContainers.inline.hpp ! src/hotspot/share/gc/g1/g1RemSet.cpp Changeset: 75adf54b Author: Aleksey Shipilev Date: 2021-11-08 15:35:27 +0000 URL: https://git.openjdk.java.net/loom/commit/75adf54bdcc5e06fb8e8ca499a2f326d70b65f76 8276306: jdk/jshell/CustomInputToolBuilder.java fails intermittently on storage acquisition Reviewed-by: jlahoda ! test/langtools/jdk/jshell/CustomInputToolBuilder.java Changeset: 7e73bca0 Author: Roger Riggs Date: 2021-11-08 16:39:07 +0000 URL: https://git.openjdk.java.net/loom/commit/7e73bca0b7a34af9fb73780491951539815651b4 8276408: Deprecate Runtime.exec methods with a single string command line argument Reviewed-by: alanb ! src/java.base/share/classes/java/lang/Runtime.java ! test/jdk/java/lang/ProcessBuilder/Zombies.java ! test/jdk/java/lang/RuntimeTests/exec/BadEnvp.java ! test/jdk/java/lang/RuntimeTests/exec/ExecWithDir.java ! test/jdk/java/lang/RuntimeTests/exec/SetCwd.java Changeset: e383d263 Author: Jonathan Gibbons Date: 2021-11-08 19:13:22 +0000 URL: https://git.openjdk.java.net/loom/commit/e383d263610c7b4d4be2dce599a9043b8f76cd64 8275199: Bogus warning generated for serializable records Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ClassBuilder.java ! test/langtools/jdk/javadoc/doclet/testRecordTypes/TestRecordTypes.java = test/langtools/jdk/javadoc/doclet/testRecordTypes/jdk17/element-list Changeset: 905e3e88 Author: Eamonn McManus Date: 2021-11-08 19:57:44 +0000 URL: https://git.openjdk.java.net/loom/commit/905e3e88137d46f90de7034e9fc324e97af873a6 8231490: Ugly racy writes to ZipUtils.defaultBuf Reviewed-by: lancea ! src/java.base/share/classes/java/util/zip/Inflater.java Changeset: 14d66bd4 Author: Andrew Leonard Date: 2021-11-08 20:37:24 +0000 URL: https://git.openjdk.java.net/loom/commit/14d66bd438dfa1feeafaca39be8f79a91e2968e9 8276654: element-list order is non deterministic Reviewed-by: ihse ! make/modules/jdk.javadoc/Gendata.gmk Changeset: a7dedb5f Author: Joe Darcy Date: 2021-11-08 22:19:55 +0000 URL: https://git.openjdk.java.net/loom/commit/a7dedb5f4761a7d0bc4db658d96d369b13b80620 8276772: Refine javax.lang.model docs Reviewed-by: iris, vromero ! src/java.compiler/share/classes/javax/lang/model/SourceVersion.java ! src/java.compiler/share/classes/javax/lang/model/element/AnnotationMirror.java ! src/java.compiler/share/classes/javax/lang/model/element/Element.java ! src/java.compiler/share/classes/javax/lang/model/element/ElementVisitor.java ! src/java.compiler/share/classes/javax/lang/model/element/RecordComponentElement.java ! src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java ! src/java.compiler/share/classes/javax/lang/model/type/NoType.java ! src/java.compiler/share/classes/javax/lang/model/type/NullType.java ! src/java.compiler/share/classes/javax/lang/model/type/PrimitiveType.java ! src/java.compiler/share/classes/javax/lang/model/util/Elements.java Changeset: 38e6d5d6 Author: Bradford Wetmore Date: 2021-11-09 01:11:18 +0000 URL: https://git.openjdk.java.net/loom/commit/38e6d5d6ed967f68e6ac1bfaa285efa16577c790 8276677: Malformed Javadoc inline tags in JDK source in javax/net/ssl Reviewed-by: jnimeh ! src/java.base/share/classes/javax/net/ssl/SSLEngine.java ! src/java.base/share/classes/javax/net/ssl/SSLSocket.java Changeset: 8747882e Author: Ioi Lam Date: 2021-11-09 07:18:06 +0000 URL: https://git.openjdk.java.net/loom/commit/8747882e4cb3af58062923bf830f9de877bdb03d 8276790: Rename GenericCDSFileMapHeader::_base_archive_path_offset Reviewed-by: dholmes, ccheung ! src/hotspot/share/cds/cdsConstants.cpp ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/cds/filemap.hpp ! src/hotspot/share/include/cds.h ! test/hotspot/jtreg/runtime/cds/appcds/SharedArchiveConsistency.java ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/ArchiveConsistency.java ! test/lib/jdk/test/lib/cds/CDSArchiveUtils.java Changeset: 945f4085 Author: Stefan Johansson Date: 2021-11-09 11:11:23 +0000 URL: https://git.openjdk.java.net/loom/commit/945f4085e5c51f37c2048bb221a1521895ba28c6 8276098: Do precise BOT updates in G1 evacuation phase Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1AllocRegion.cpp ! src/hotspot/share/gc/g1/g1AllocRegion.hpp ! src/hotspot/share/gc/g1/g1AllocRegion.inline.hpp ! src/hotspot/share/gc/g1/g1Allocator.cpp ! src/hotspot/share/gc/g1/g1Allocator.hpp ! src/hotspot/share/gc/g1/g1Allocator.inline.hpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.hpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.inline.hpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegion.hpp ! src/hotspot/share/gc/g1/heapRegion.inline.hpp ! src/hotspot/share/gc/shared/plab.hpp Changeset: 5c7f77c8 Author: Thomas Schatzl Date: 2021-11-09 13:07:42 +0000 URL: https://git.openjdk.java.net/loom/commit/5c7f77c82404976a6ca1d54b40f1969eac10d63b 8276850: Remove outdated comment in HeapRegionManager::par_iterate Reviewed-by: ayang, sjohanss ! src/hotspot/share/gc/g1/heapRegionManager.cpp Changeset: 4bd5bfd8 Author: Thomas Stuefe Date: 2021-11-09 14:12:40 +0000 URL: https://git.openjdk.java.net/loom/commit/4bd5bfd8e2624715ebfa6e4c49172361389fbc98 8276731: Metaspace chunks are uncommitted twice Reviewed-by: shade, coleenp ! src/hotspot/share/memory/metaspace/chunkManager.cpp Changeset: e1985947 Author: Masanori Yano Committer: Alan Bateman Date: 2021-11-09 14:28:07 +0000 URL: https://git.openjdk.java.net/loom/commit/e198594753b0b0653256923586c7f4ec9e3cfac3 8250678: ModuleDescriptor.Version parsing treats empty segments inconsistently Reviewed-by: mchung, alanb ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java ! test/jdk/java/lang/module/VersionTest.java Changeset: c27afb31 Author: Weijun Wang Date: 2021-11-09 14:46:32 +0000 URL: https://git.openjdk.java.net/loom/commit/c27afb313b77d19e7ace7101c6f21aa5b2c56505 8276863: Remove test/jdk/sun/security/ec/ECDSAJavaVerify.java Reviewed-by: ascarpino - test/jdk/sun/security/ec/ECDSAJavaVerify.java Changeset: f65db88b Author: Yasumasa Suenaga Date: 2021-11-09 14:54:42 +0000 URL: https://git.openjdk.java.net/loom/commit/f65db88b74911e5896d2ff536c4ac97e7f62d98b 8276841: Add support for Visual Studio 2022 Reviewed-by: erikj, ihse ! make/autoconf/toolchain_microsoft.m4 Changeset: e35abe32 Author: Hannes Walln?fer Date: 2021-11-09 15:05:07 +0000 URL: https://git.openjdk.java.net/loom/commit/e35abe3235ab38985a19545e76c58260ec97c718 8256208: Javadoc's generated overview does not show classes of unnamed package Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlConfiguration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageIndexWriter.java ! test/langtools/jdk/javadoc/doclet/testUnnamedPackage/TestUnnamedPackage.java = test/langtools/jdk/javadoc/doclet/testUnnamedPackage/src1/pkg/D.java + test/langtools/jdk/javadoc/doclet/testUnnamedPackage/src1/pkg/package.html Changeset: 93692ea0 Author: Andrey Turbanov Committer: Chris Plummer Date: 2021-11-09 16:58:43 +0000 URL: https://git.openjdk.java.net/loom/commit/93692ea0a9bc437309b808f511c771a79dcdfb9a 8274395: Use enhanced-for instead of plain 'for' in jdk.internal.jvmstat Reviewed-by: cjplummer, amenkov, sspitsyn ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/HostIdentifier.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/VmIdentifier.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfDataBufferImpl.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalMonitoredVm.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalVmManager.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/MonitoredHostProvider.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v2_0/TypeCode.java Changeset: daf77ebf Author: Leo Korinth Date: 2021-11-09 17:50:16 +0000 URL: https://git.openjdk.java.net/loom/commit/daf77ebfc4ca6d537ef55acbd62b908b5575ad08 8276337: Use override specifier in HeapDumper Reviewed-by: stuefe, dholmes ! src/hotspot/share/services/heapDumper.cpp Changeset: dde959df Author: Brian Burkhalter Date: 2021-11-09 19:17:59 +0000 URL: https://git.openjdk.java.net/loom/commit/dde959dfcef01897fdf51f820d414402e6309b8d 8276808: java/nio/channels/Channels/TransferTo.java timed out Reviewed-by: lancea, shade ! test/jdk/java/nio/channels/Channels/TransferTo.java Changeset: a60e9125 Author: Pankaj Bansal Date: 2021-11-09 20:10:20 +0000 URL: https://git.openjdk.java.net/loom/commit/a60e91259ba83d2a525b612b2c7a1fd7934b88a2 8198626: java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.html fails on mac Reviewed-by: serb ! test/jdk/ProblemList.txt ! test/jdk/java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.java Changeset: 055de6f5 Author: Hannes Walln?fer Date: 2021-11-09 20:11:18 +0000 URL: https://git.openjdk.java.net/loom/commit/055de6f566208b168818be1dc3ad29cdb9caa1cf 8223358: Incorrect HTML structure in annotation pages Reviewed-by: jjg + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeMemberWriterImpl.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlIds.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Navigation.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SummaryListWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/WriterFactoryImpl.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/AnnotationTypeMemberWriter.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/AnnotationTypeOptionalMemberWriter.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/AnnotationTypeRequiredMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/WriterFactory.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AbstractMemberBuilder.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AnnotationTypeMemberBuilder.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AnnotationTypeOptionalMemberBuilder.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/BuilderFactory.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ClassBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/VisibleMemberTable.java ! test/langtools/jdk/javadoc/doclet/testAnnotationTypes/TestAnnotationTypes.java ! test/langtools/jdk/javadoc/doclet/testAnnotationTypes/pkg/AnnotationType.java Changeset: f9024d06 Author: Hannes Walln?fer Date: 2021-11-09 20:17:25 +0000 URL: https://git.openjdk.java.net/loom/commit/f9024d0606e39863b590f0d7c949d569f8bf8abd 8230130: javadoc search result dialog shows cut off headers for long results Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css Changeset: d7012fbd Author: Roger Riggs Date: 2021-11-09 20:43:51 +0000 URL: https://git.openjdk.java.net/loom/commit/d7012fbd604fc1a54a2d7364a6ca4a32f47ffc7c 8276880: Remove java/lang/RuntimeTests/exec/ExecWithDir as unnecessary Reviewed-by: alanb - test/jdk/java/lang/RuntimeTests/exec/ExecWithDir.java Changeset: 06992208 Author: Rickard B?ckman Date: 2021-11-09 21:38:12 +0000 URL: https://git.openjdk.java.net/loom/commit/0699220830a457959b784b35af125b70f43fa3b0 8268882: C2: assert(n->outcnt() != 0 || C->top() == n || n->is_Proj()) failed: No dead instructions after post-alloc Reviewed-by: neliasso, chagedorn, kvn ! src/hotspot/share/opto/postaloc.cpp Changeset: c8b0ee6b Author: Hamlin Li Date: 2021-11-10 01:12:43 +0000 URL: https://git.openjdk.java.net/loom/commit/c8b0ee6b8a0c1bca8f8357e786f24c8cb6dd7310 8276833: G1: Make G1EvacFailureRegions::par_iterate const Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1EvacFailureRegions.cpp ! src/hotspot/share/gc/g1/g1EvacFailureRegions.hpp Changeset: c1e41fe3 Author: Hamlin Li Date: 2021-11-10 01:13:30 +0000 URL: https://git.openjdk.java.net/loom/commit/c1e41fe38bbbae12e1f73d2cd63c7afffc19475b 8276842: G1: Only calculate size in bytes from words when needed Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1EvacFailure.cpp Changeset: 8822d41f Author: Jamil Nimeh Date: 2021-11-10 01:24:33 +0000 URL: https://git.openjdk.java.net/loom/commit/8822d41fdcc2c2d568badd72635dc587d21dbd63 8274736: Concurrent read/close of SSLSockets causes SSLSessions to be invalidated unnecessarily Reviewed-by: xuelei, wetmore ! src/java.base/share/classes/sun/security/ssl/TransportContext.java ! test/jdk/javax/net/ssl/templates/SSLSocketTemplate.java + test/jdk/sun/security/ssl/SSLSessionImpl/NoInvalidateSocketException.java Changeset: e91e9d85 Author: Hamlin Li Date: 2021-11-10 01:26:35 +0000 URL: https://git.openjdk.java.net/loom/commit/e91e9d853272ea8f5ce490f2f0c971fd40795d74 8276721: G1: Refine G1EvacFailureObjectsSet::iterate Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1EvacFailure.cpp ! src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.cpp ! src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.hpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegion.hpp Changeset: 403f3185 Author: Anirvan Sarkar Committer: Christoph Langer Date: 2021-11-10 05:51:39 +0000 URL: https://git.openjdk.java.net/loom/commit/403f3185f0988dcf6ef4e857d6659533bfa2943f 8276854: Windows GHA builds fail due to broken Cygwin Reviewed-by: clanger ! .github/workflows/submit.yml Changeset: fd0a25e6 Author: Aleksey Shipilev Date: 2021-11-10 07:59:01 +0000 URL: https://git.openjdk.java.net/loom/commit/fd0a25e62b2c8abc3a419c2e80abbcf11c9e882f 8276805: java/awt/print/PrinterJob/CheckPrivilege.java fails due to disabled SecurityManager Reviewed-by: serb, aivanov ! test/jdk/java/awt/print/PrinterJob/CheckPrivilege.java Changeset: e01d6d00 Author: Prasanta Sadhukhan Date: 2021-11-10 08:34:07 +0000 URL: https://git.openjdk.java.net/loom/commit/e01d6d00bc4ab5ca0d38f8894a78e6d911e0fe93 8276679: Malformed Javadoc inline tags in JDK source in javax/swing Reviewed-by: aivanov, pbansal ! src/java.desktop/share/classes/javax/swing/JTree.java ! src/java.desktop/share/classes/javax/swing/SwingUtilities.java ! src/java.desktop/share/classes/javax/swing/event/HyperlinkEvent.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java Changeset: 0f463a7b Author: Aleksey Shipilev Date: 2021-11-10 09:50:27 +0000 URL: https://git.openjdk.java.net/loom/commit/0f463a7bf73791eda9404882ff63daf9040399bb 8276845: (fs) java/nio/file/spi/SetDefaultProvider.java fails on x86_32 Reviewed-by: alanb ! test/jdk/java/nio/file/spi/TestProvider.java Changeset: a3f710ef Author: Aleksey Shipilev Date: 2021-11-10 10:45:51 +0000 URL: https://git.openjdk.java.net/loom/commit/a3f710efbe7dcef18477a96fd306bec19f181f8b 8276215: Intrinsics matchers should handle native method flags better Reviewed-by: dholmes, kvn ! src/hotspot/share/classfile/vmIntrinsics.cpp ! src/hotspot/share/classfile/vmIntrinsics.hpp Changeset: 8226aa92 Author: Alan Bateman Date: 2021-11-20 07:50:47 +0000 URL: https://git.openjdk.java.net/loom/commit/8226aa92b5de327b95e5f8531e7df08e339f5c45 Merge with jdk-18+23 ! src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp ! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp ! src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp ! src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp ! src/hotspot/cpu/s390/c1_LIRGenerator_s390.cpp ! src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp ! src/hotspot/cpu/x86/c1_Runtime1_x86.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/templateTable_x86.cpp ! src/hotspot/share/c1/c1_Compilation.cpp ! src/hotspot/share/c1/c1_Compiler.cpp ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciEnv.hpp ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/classfile/vmIntrinsics.cpp ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/code/codeCache.cpp ! src/hotspot/share/gc/g1/g1CardSetContainers.inline.hpp ! src/hotspot/share/gc/g1/g1CardSetMemory.hpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1EvacFailureRegions.cpp ! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp ! src/hotspot/share/gc/shared/memAllocator.cpp ! src/hotspot/share/gc/z/zDriver.cpp ! src/hotspot/share/interpreter/abstractInterpreter.cpp ! src/hotspot/share/interpreter/abstractInterpreter.hpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/opto/buildOopMap.cpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/macro.cpp ! src/hotspot/share/opto/output.cpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/prims/jvmtiEnv.cpp ! src/hotspot/share/prims/jvmtiEventController.cpp ! src/hotspot/share/prims/jvmtiExtensions.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/handshake.cpp ! src/hotspot/share/runtime/handshake.hpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/services/heapDumper.cpp ! src/java.base/share/classes/java/lang/Object.java ! src/java.base/share/classes/java/lang/StackStreamFactory.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/net/InetAddress.java ! src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java ! src/java.base/share/classes/sun/security/ssl/TransportContext.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Metadata.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ThreadReferenceImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/JVM.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java ! test/hotspot/jtreg/ProblemList-zgc.txt ! test/jdk/ProblemList.txt ! src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp ! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp ! src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp ! src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp ! src/hotspot/cpu/s390/c1_LIRGenerator_s390.cpp ! src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp ! src/hotspot/cpu/x86/c1_Runtime1_x86.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/templateTable_x86.cpp ! src/hotspot/share/c1/c1_Compilation.cpp ! src/hotspot/share/c1/c1_Compiler.cpp ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciEnv.hpp ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/classfile/vmIntrinsics.cpp ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/code/codeCache.cpp ! src/hotspot/share/gc/g1/g1CardSetContainers.inline.hpp ! src/hotspot/share/gc/g1/g1CardSetMemory.hpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1EvacFailureRegions.cpp ! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp ! src/hotspot/share/gc/shared/memAllocator.cpp ! src/hotspot/share/gc/z/zDriver.cpp ! src/hotspot/share/interpreter/abstractInterpreter.cpp ! src/hotspot/share/interpreter/abstractInterpreter.hpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/opto/buildOopMap.cpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/macro.cpp ! src/hotspot/share/opto/output.cpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/prims/jvmtiEnv.cpp ! src/hotspot/share/prims/jvmtiEventController.cpp ! src/hotspot/share/prims/jvmtiExtensions.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/handshake.cpp ! src/hotspot/share/runtime/handshake.hpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/services/heapDumper.cpp ! src/java.base/share/classes/java/lang/Object.java ! src/java.base/share/classes/java/lang/StackStreamFactory.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/net/InetAddress.java ! src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java ! src/java.base/share/classes/sun/security/ssl/TransportContext.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Metadata.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ThreadReferenceImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/JVM.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java ! test/hotspot/jtreg/ProblemList-zgc.txt ! test/jdk/ProblemList.txt Changeset: cb8fa304 Author: Alan Bateman Date: 2021-11-20 13:03:40 +0000 URL: https://git.openjdk.java.net/loom/commit/cb8fa3045d88716ef4e2c52c0766746d1ce93a56 Temporary use of TLH until async_get_stack_trace updated to keep thread alive ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/prims/jvm.cpp From duke at openjdk.java.net Sat Nov 20 13:18:40 2021 From: duke at openjdk.java.net (duke) Date: Sat, 20 Nov 2021 13:18:40 GMT Subject: git: openjdk/loom: master: 112 new changesets Message-ID: <3ad92c58-a7c5-4665-a68d-e3bbd142bb78@openjdk.java.net> Changeset: 87b926eb Author: sunguoyun Committer: Igor Veresov Date: 2021-11-03 05:51:18 +0000 URL: https://git.openjdk.java.net/loom/commit/87b926ebb7f1e341da858f7a9892377586abc026 8275086: compiler/c2/irTests/TestPostParseCallDevirtualization.java fails when compiler1 is disabled Reviewed-by: iveresov ! test/hotspot/jtreg/compiler/c2/irTests/TestPostParseCallDevirtualization.java Changeset: 7439b59b Author: Christian Hagedorn Date: 2021-11-03 08:44:03 +0000 URL: https://git.openjdk.java.net/loom/commit/7439b59b5a6816269b16d210ef10779fc9def8e2 8276044: ciReplay: C1 does not dump a replay file when using DumpReplay as compile command option Reviewed-by: kvn, thartmann, dlong ! src/hotspot/share/c1/c1_Compilation.cpp ! test/hotspot/jtreg/compiler/ciReplay/CiReplayBase.java + test/hotspot/jtreg/compiler/ciReplay/TestDumpReplayCommandLine.java Changeset: 465d350d Author: Aleksey Shipilev Date: 2021-11-03 09:06:21 +0000 URL: https://git.openjdk.java.net/loom/commit/465d350d0b3cac277a58b9f8ece196c1cde68e80 8276157: C2: Compiler stack overflow during escape analysis on Linux x86_32 Reviewed-by: kvn, thartmann ! src/hotspot/os_cpu/linux_x86/globals_linux_x86.hpp Changeset: 61506336 Author: Pavel Rappo Date: 2021-11-03 10:07:48 +0000 URL: https://git.openjdk.java.net/loom/commit/615063364ab6bdd3fa83401745e05b45e13eacdb 8276348: Use blessed modifier order in java.base Reviewed-by: dfuchs, darcy, iris, rriggs, martin ! src/java.base/share/classes/java/io/ObjectInputFilter.java ! src/java.base/share/classes/java/io/ObjectStreamClass.java ! src/java.base/share/classes/java/lang/Object.java ! src/java.base/share/classes/java/lang/Process.java ! src/java.base/share/classes/java/lang/StackStreamFactory.java ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/classes/java/lang/WeakPairMap.java ! src/java.base/share/classes/java/lang/invoke/AbstractConstantGroup.java ! src/java.base/share/classes/java/lang/invoke/CallSite.java ! src/java.base/share/classes/java/net/InetAddress.java ! src/java.base/share/classes/java/security/Provider.java ! src/java.base/share/classes/java/util/ImmutableCollections.java ! src/java.base/share/classes/jdk/internal/icu/util/CodePointTrie.java ! src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java ! src/java.base/share/classes/jdk/internal/jimage/NativeImageBuffer.java ! src/java.base/share/classes/jdk/internal/logger/SimpleConsoleLogger.java ! src/java.base/share/classes/jdk/internal/module/ModuleReferences.java ! src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java ! src/java.base/share/classes/sun/security/jca/ProviderList.java ! src/java.base/share/classes/sun/security/rsa/RSAPrivateKeyImpl.java ! src/java.base/share/classes/sun/security/ssl/SSLHandshake.java Changeset: a316c06e Author: Zhengyu Gu Date: 2021-11-03 12:08:37 +0000 URL: https://git.openjdk.java.net/loom/commit/a316c06e03e06b86ceca376cf20dcb9c526905f5 8275730: Relax memory constraint on MultiThreadedRefCounter Reviewed-by: mgronlun, minqi ! src/hotspot/share/jfr/utilities/jfrRefCountPointer.hpp Changeset: be1ca2bd Author: Hamlin Li Date: 2021-11-03 12:39:15 +0000 URL: https://git.openjdk.java.net/loom/commit/be1ca2bd201170b0d280030a2aae4c8d1da9f4af 8276298: G1: Remove unused G1SegmentedArrayBufferList::add Reviewed-by: tschatzl ! src/hotspot/share/gc/g1/g1SegmentedArray.hpp Changeset: 87318460 Author: Daniel D. Daugherty Date: 2021-11-03 15:02:20 +0000 URL: https://git.openjdk.java.net/loom/commit/87318460012d3fa1a8d3e8749d7a20328b27b826 8276556: ProblemList java/nio/channels/FileChannel/LargeGatheringWrite.java on windows-x64 Reviewed-by: alanb ! test/jdk/ProblemList.txt Changeset: 61cb4bc6 Author: Tobias Holenstein Committer: Christian Hagedorn Date: 2021-11-03 15:31:50 +0000 URL: https://git.openjdk.java.net/loom/commit/61cb4bc6b0252536364a86f38ff2e5c8c7ab610b 8276036: The value of full_count in the message of insufficient codecache is wrong Reviewed-by: kvn, dlong, thartmann, chagedorn ! src/hotspot/share/code/codeCache.cpp Changeset: 724bf3be Author: Aleksey Shipilev Date: 2021-11-03 15:41:26 +0000 URL: https://git.openjdk.java.net/loom/commit/724bf3be1458f7da502f8772be6151bed826b4f7 8275604: Zero: Reformat opclabels_data Reviewed-by: adinn, zgu ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp Changeset: 0ef8cbe3 Author: Phil Race Date: 2021-11-03 16:22:42 +0000 URL: https://git.openjdk.java.net/loom/commit/0ef8cbe32540814d4c0be9c7b0f78486408657a7 8276385: Re-run blessed-modifier-order script on java.desktop and jdk.accessibility Reviewed-by: serb ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/BaselineTIFFTagSet.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifGPSTagSet.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifInteroperabilityTagSet.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifParentTIFFTagSet.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/ExifTIFFTagSet.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/FaxTIFFTagSet.java ! src/java.desktop/share/classes/javax/imageio/plugins/tiff/GeoTIFFTagSet.java ! src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java ! src/java.desktop/share/classes/sun/java2d/loops/DrawGlyphListColor.java ! src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java ! src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/AWTEventMonitor.java ! src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/AccessibilityEventMonitor.java ! src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/AccessibilityListenerList.java ! src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/EventID.java ! src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/EventQueueMonitor.java ! src/jdk.accessibility/share/classes/com/sun/java/accessibility/util/SwingEventMonitor.java ! src/jdk.accessibility/windows/classes/com/sun/java/accessibility/internal/AccessBridge.java Changeset: 7115892f Author: Daniel Fuchs Date: 2021-11-03 16:23:57 +0000 URL: https://git.openjdk.java.net/loom/commit/7115892f96a5a57ce9d37602038b787d19da5d81 8276401: Use blessed modifier order in java.net.http Reviewed-by: prappo, rriggs ! src/java.net.http/share/classes/jdk/internal/net/http/Http1Exchange.java ! src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java ! src/java.net.http/share/classes/jdk/internal/net/http/Http2ClientImpl.java ! src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java ! src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java ! src/java.net.http/share/classes/jdk/internal/net/http/HttpConnection.java ! src/java.net.http/share/classes/jdk/internal/net/http/ResponseSubscribers.java ! src/java.net.http/share/classes/jdk/internal/net/http/SocketTube.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/DebugLogger.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/FlowTube.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/MinimalFuture.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/SSLTube.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/SequentialScheduler.java Changeset: 684edbb4 Author: Brian Burkhalter Date: 2021-11-03 16:55:23 +0000 URL: https://git.openjdk.java.net/loom/commit/684edbb4c884cbc3e05118e4bc9808b5d5b71a74 8273922: (fs) UserDefinedFileAttributeView doesn't handle file names that are just under the MAX_PATH limit (win) Reviewed-by: alanb ! src/java.base/windows/classes/sun/nio/fs/WindowsUserDefinedFileAttributeView.java ! test/jdk/java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java Changeset: c7f070f5 Author: Jakob Cornell Committer: Chris Plummer Date: 2021-11-03 18:18:16 +0000 URL: https://git.openjdk.java.net/loom/commit/c7f070f5f17dad661cc3296f2e3cd7a1cd5fc742 8276208: vmTestbase/nsk/jdb/repeat/repeat001/repeat001.java fails with "AssertionError: Unexpected output" Reviewed-by: cjplummer, iklam ! test/hotspot/jtreg/vmTestbase/nsk/jdb/list/list003/list003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdb/repeat/repeat001/repeat001.java Changeset: 32895ac6 Author: Ivan ?ipka Committer: Mark Sheppard Date: 2021-11-03 19:30:12 +0000 URL: https://git.openjdk.java.net/loom/commit/32895ac60949ccceb0a3d25c73ec5e3a00c29593 8275650: Problemlist java/io/File/createTempFile/SpecialTempFile.java for Windows 11 Reviewed-by: bpb, msheppar + out ! test/jdk/ProblemList.txt Changeset: f3320d2f Author: Joe Darcy Date: 2021-11-03 21:20:09 +0000 URL: https://git.openjdk.java.net/loom/commit/f3320d2fbd28349fa5eab3ea0da0ff0a3ef54c62 8276588: Change "ccc" to "CSR" in HotSpot sources Reviewed-by: dcubed, kbarrett ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/runtime/globals.hpp Changeset: 0ab910d6 Author: Jie Fu Date: 2021-11-03 22:45:50 +0000 URL: https://git.openjdk.java.net/loom/commit/0ab910d626a05106e1366438aeb5b16e16374c2f 8276066: Reset LoopPercentProfileLimit for x86 due to suboptimal performance Reviewed-by: thartmann, kvn ! src/hotspot/cpu/x86/c2_globals_x86.hpp + test/micro/org/openjdk/bench/vm/compiler/LoopUnroll.java Changeset: ce8c7670 Author: Claes Redestad Date: 2021-11-03 22:57:13 +0000 URL: https://git.openjdk.java.net/loom/commit/ce8c76700ba854f43c48d32b068b30e7d78d9d1e 8276220: Reduce excessive allocations in DateTimeFormatter Reviewed-by: scolebourne, naoto ! src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/java.base/share/classes/java/time/format/DateTimePrintContext.java ! test/jdk/java/time/test/java/time/format/TestFractionPrinterParser.java + test/micro/org/openjdk/bench/java/time/format/DateTimeFormatterBench.java Changeset: 603bba28 Author: Yumin Qi Date: 2021-11-03 23:16:15 +0000 URL: https://git.openjdk.java.net/loom/commit/603bba282a089928fd23f8da23a7c1b2d52944ef 8271420: Extend CDS custom loader support to Windows platform Reviewed-by: iklam, ccheung ! src/hotspot/share/cds/classListParser.cpp ! test/hotspot/jtreg/runtime/cds/appcds/loaderConstraints/LoaderConstraintsTest.java ! test/hotspot/jtreg/runtime/cds/appcds/test-classes/CustomAppLoader.java ! test/lib/jdk/test/lib/Platform.java Changeset: 558ee40a Author: Yasumasa Suenaga Date: 2021-11-04 04:34:07 +0000 URL: https://git.openjdk.java.net/loom/commit/558ee40a4ac158e5be8269c87b7e18af77dd14c5 8276615: Update CR number of some tests in ProblemList-zgc.txt Reviewed-by: dholmes ! test/hotspot/jtreg/ProblemList-zgc.txt Changeset: fb0be81f Author: Aleksey Shipilev Date: 2021-11-04 08:03:51 +0000 URL: https://git.openjdk.java.net/loom/commit/fb0be81f0148d9aea73321a0c2bd83b2e477d952 8276096: Simplify Unsafe.{load|store}Fence fallbacks by delegating to fullFence Reviewed-by: psandoz, aph, dholmes ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/prims/unsafe.cpp ! src/java.base/share/classes/jdk/internal/misc/Unsafe.java Changeset: 9eadcbb4 Author: Aleksey Shipilev Date: 2021-11-04 08:08:07 +0000 URL: https://git.openjdk.java.net/loom/commit/9eadcbb47e902f42d933ba68e24f2bfb0ee20915 8276217: Harmonize StrictMath intrinsics handling Reviewed-by: aph, kvn ! src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp ! src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp ! src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp ! src/hotspot/cpu/s390/c1_LIRGenerator_s390.cpp ! src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp ! src/hotspot/share/c1/c1_Compiler.cpp ! src/hotspot/share/c1/c1_GraphBuilder.cpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/classfile/vmIntrinsics.cpp ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/interpreter/abstractInterpreter.cpp ! src/hotspot/share/interpreter/abstractInterpreter.hpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/library_call.cpp Changeset: a1f4c428 Author: Christian Hagedorn Date: 2021-11-04 08:53:37 +0000 URL: https://git.openjdk.java.net/loom/commit/a1f4c428ba1b78a4e18afb87c94a5c731a5aa706 8276227: ciReplay: SIGSEGV if classfile for replay compilation is not present after JDK-8275868 Reviewed-by: kvn, thartmann, dlong ! src/hotspot/share/ci/ciReplay.cpp + test/hotspot/jtreg/compiler/ciReplay/TestNoClassFile.java Changeset: c62b3476 Author: Aleksey Shipilev Date: 2021-11-04 09:03:21 +0000 URL: https://git.openjdk.java.net/loom/commit/c62b3476ce12cea633abead0d6376ea0a05f92f9 8276623: JDK-8275650 accidentally pushed "out" file Reviewed-by: tschatzl, dholmes - out Changeset: 3613ce7c Author: Aleksey Shipilev Date: 2021-11-04 10:23:11 +0000 URL: https://git.openjdk.java.net/loom/commit/3613ce7c7d5bc8b7d603e1cf6a123588339aed3f 8275586: Zero: Simplify interpreter initialization Reviewed-by: aph, adinn ! src/hotspot/cpu/zero/vm_version_zero.cpp ! src/hotspot/cpu/zero/zeroInterpreter_zero.cpp ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp Changeset: ee499632 Author: Julia Boes Date: 2021-11-04 11:31:51 +0000 URL: https://git.openjdk.java.net/loom/commit/ee499632586eabb3dab209645d5b9c781a09034b 8275534: com.sun.net.httpserver.BasicAuthenticator should check whether "realm" is a quoted string Reviewed-by: michaelm, dfuchs ! src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java ! src/jdk.httpserver/share/classes/com/sun/net/httpserver/BasicAuthenticator.java ! src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java + src/jdk.httpserver/share/classes/sun/net/httpserver/Utils.java + test/jdk/com/sun/net/httpserver/BasicAuthenticatorRealm.java ! test/jdk/com/sun/net/httpserver/bugs/BasicAuthenticatorExceptionCheck.java Changeset: 7de653e4 Author: Hamlin Li Date: 2021-11-04 12:31:27 +0000 URL: https://git.openjdk.java.net/loom/commit/7de653e428ee38339ec38533659b23a52e275f3f 8276301: G1: Refine implementation of G1CardSetFreePool::memory_sizes() Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1CardSetMemory.cpp ! src/hotspot/share/gc/g1/g1CardSetMemory.hpp Changeset: 19075b3f Author: Hannes Walln?fer Date: 2021-11-04 13:06:24 +0000 URL: https://git.openjdk.java.net/loom/commit/19075b3f6b21f6d3b0624ef8e835b3cfc53228de 8275788: Create code element with suitable attributes for code snippets Reviewed-by: prappo ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SnippetTaglet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/TagletWriter.java ! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java Changeset: a6fa6ed1 Author: Per Liden Date: 2021-11-04 13:47:59 +0000 URL: https://git.openjdk.java.net/loom/commit/a6fa6ed1edc6f473a7fea1fa00edd467ab778983 8268779: ZGC: runtime/InternalApi/ThreadCpuTimesDeadlock.java#id1 failed with "OutOfMemoryError: Java heap space" Reviewed-by: eosterlund, stefank ! src/hotspot/share/gc/z/zDriver.cpp Changeset: 5acff753 Author: Evgeny Astigeevich Committer: Vladimir Kozlov Date: 2021-11-04 15:01:26 +0000 URL: https://git.openjdk.java.net/loom/commit/5acff75379a4ad0acfcfc6a64fcc4b588ef048c7 8276429: CodeHeapState::print_names() fails with "assert(klass->is_loader_alive()) failed: must be alive" Reviewed-by: kvn ! src/hotspot/share/code/codeHeapState.cpp Changeset: 49b7b2ea Author: Magnus Ihse Bursie Date: 2021-11-04 15:06:08 +0000 URL: https://git.openjdk.java.net/loom/commit/49b7b2ea0971fe99567bdbd962d63b90ff2eeefd 8276640: Use blessed modifier order in jfr code Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/internal/FilePurger.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/JVM.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformRecorder.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/PrivateAccess.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java Changeset: afb502e2 Author: Aleksey Shipilev Date: 2021-11-04 15:41:39 +0000 URL: https://git.openjdk.java.net/loom/commit/afb502e28a81183cef76a7e60fc052e8cad3afe3 8276550: Use SHA256 hash in build.tools.depend.Depend Reviewed-by: adinn, aph, andrew, ihse ! make/jdk/src/classes/build/tools/depend/Depend.java Changeset: bf4ddf9c Author: Pavel Rappo Date: 2021-11-04 15:51:37 +0000 URL: https://git.openjdk.java.net/loom/commit/bf4ddf9cb7408db321e7fd73600a5a9a85ca49eb 8276338: Minor improve of wording for String.to(Lower|Upper)Case Reviewed-by: rriggs, naoto ! src/java.base/share/classes/java/lang/String.java Changeset: b57715a1 Author: Pavel Rappo Date: 2021-11-04 15:56:19 +0000 URL: https://git.openjdk.java.net/loom/commit/b57715a117d9b7f79fcf4fec3b8f369b6aa42598 8276573: Use blessed modifier order in jdk.javadoc Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/DeprecatedListWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Attribute.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/MarkupParser.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/DocLint.java Changeset: 7bb21733 Author: Brian Burkhalter Date: 2021-11-04 16:33:08 +0000 URL: https://git.openjdk.java.net/loom/commit/7bb2173383bc1c0d55564d31303a547957d87a15 8276199: java/nio/channels/FileChannel/LargeGatheringWrite.java fails to terminate correctly Reviewed-by: alanb ! test/jdk/ProblemList.txt ! test/jdk/java/nio/channels/FileChannel/LargeGatheringWrite.java Changeset: 1533b819 Author: Magnus Ihse Bursie Date: 2021-11-04 17:02:42 +0000 URL: https://git.openjdk.java.net/loom/commit/1533b8191bed9d65ab4af03945584d8b2276d828 8276629: Use blessed modifier order in core-libs code Reviewed-by: dholmes, aefimov, dfuchs, mchung, iris ! src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java ! src/java.naming/share/classes/com/sun/jndi/ldap/LdapClient.java ! src/java.naming/share/classes/com/sun/jndi/ldap/LdapCtx.java ! src/java.rmi/share/classes/java/rmi/server/LoaderHandler.java ! src/java.rmi/share/classes/java/rmi/server/RMISocketFactory.java ! src/java.rmi/share/classes/java/rmi/server/RemoteObject.java ! src/java.rmi/share/classes/java/rmi/server/RemoteRef.java ! src/java.rmi/share/classes/java/rmi/server/RemoteStub.java ! src/java.rmi/share/classes/sun/rmi/log/ReliableLog.java ! src/java.rmi/share/classes/sun/rmi/transport/ObjectTable.java ! src/java.rmi/share/classes/sun/rmi/transport/Target.java ! src/java.sql.rowset/share/classes/javax/sql/rowset/RowSetProvider.java ! src/jdk.dynalink/share/classes/jdk/dynalink/BiClassValue.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/Annotation.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/ConstantPool.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/Dependencies.java ! src/jdk.jdeps/share/classes/com/sun/tools/classfile/StackMapTable_attribute.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/JavapTask.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/JdepsTask.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Module.java ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/Profile.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginStack.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageResourcesTree.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/PluginRepository.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ResourceFilter.java ! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java ! src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsContext.java ! src/jdk.naming.rmi/share/classes/com/sun/jndi/rmi/registry/RegistryContextFactory.java Changeset: 99d4b07c Author: Ludvig Janiuk Committer: Mandy Chung Date: 2021-11-04 17:26:18 +0000 URL: https://git.openjdk.java.net/loom/commit/99d4b07cddec05428e4d578ba6f494f51b92e841 8276649: MethodHandles.Lookup docs: replace the table in the cross-module access check section with list Reviewed-by: mchung ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java Changeset: 2b5a32c7 Author: Zhengyu Gu Date: 2021-11-04 19:40:22 +0000 URL: https://git.openjdk.java.net/loom/commit/2b5a32c73f22c69d7ccedac761af1dbb4a7f297d 8275718: Relax memory constraint on exception counter updates Reviewed-by: dholmes, minqi ! src/hotspot/share/utilities/exceptions.cpp Changeset: 81203efe Author: Magnus Ihse Bursie Date: 2021-11-04 19:44:05 +0000 URL: https://git.openjdk.java.net/loom/commit/81203efe411320ff4e390605f980d14e7f70252f 8276655: Use blessed modifier order in SCTP Reviewed-by: alanb, dfuchs ! src/jdk.sctp/unix/classes/sun/nio/ch/sctp/AssociationChange.java ! src/jdk.sctp/unix/classes/sun/nio/ch/sctp/PeerAddrChange.java Changeset: dcf36f87 Author: Dean Long Date: 2021-11-04 19:52:27 +0000 URL: https://git.openjdk.java.net/loom/commit/dcf36f87f87d52490c1f0434c2fca99fc8fd90a2 8275670: ciReplay: java.lang.NoClassDefFoundError when trying to load java/lang/invoke/LambdaForm$MH Reviewed-by: kvn, chagedorn ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciEnv.hpp + test/hotspot/jtreg/compiler/ciReplay/TestLambdas.java Changeset: 7e87f946 Author: Ludvig Janiuk Committer: Mandy Chung Date: 2021-11-04 20:46:23 +0000 URL: https://git.openjdk.java.net/loom/commit/7e87f946cedf93f19c38fd596039a16394c03ea4 8276652: Missing row headers in MethodHandles.Lookup docs Reviewed-by: mchung ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java Changeset: 8ec80c4b Author: Ludvig Janiuk Committer: Naoto Sato Date: 2021-11-04 21:06:03 +0000 URL: https://git.openjdk.java.net/loom/commit/8ec80c4bc1c3169963137b5a16a1b787540a3589 8276653: Missing row headers in j.l.Character docs Reviewed-by: naoto ! src/java.base/share/classes/java/lang/Character.java Changeset: 7b1916ef Author: Alisen Chung Committer: Phil Race Date: 2021-11-04 21:53:29 +0000 URL: https://git.openjdk.java.net/loom/commit/7b1916efda95a46439cf42e006593361d12a8823 8233557: [TESTBUG] DoubleClickTitleBarTest.java fails on macOs Reviewed-by: prr ! test/jdk/ProblemList.txt Changeset: e21b5c7b Author: Mandy Chung Date: 2021-11-04 23:51:18 +0000 URL: https://git.openjdk.java.net/loom/commit/e21b5c7b3781430ecf568e7f5c89ef3391e06d9e 8276650: GenGraphs does not produce deterministic output Reviewed-by: iris ! src/jdk.jdeps/share/classes/com/sun/tools/jdeps/ModuleDotGraph.java ! test/langtools/tools/jdeps/modules/DotFileTest.java Changeset: 9ad4d3d0 Author: Sandhya Viswanathan Date: 2021-11-05 03:30:09 +0000 URL: https://git.openjdk.java.net/loom/commit/9ad4d3d06bb356436d69af07726ef6727c500f59 8276025: Hotspot's libsvml.so may conflict with user dependency Reviewed-by: kvn, erikj, psandoz, ihse ! make/modules/jdk.incubator.vector/Lib.gmk ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp = src/jdk.incubator.vector/linux/native/libjsvml/globals_vectorApiSupport_linux.S.inc + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_acos_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_asin_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_atan2_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_atan_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_cbrt_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_cos_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_cosh_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_exp_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_expm1_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_hypot_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_log10_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_log1p_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_log_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_pow_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_sin_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_sinh_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_tan_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_d_tanh_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_acos_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_asin_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_atan2_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_atan_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_cbrt_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_cos_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_cosh_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_exp_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_expm1_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_hypot_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_log10_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_log1p_linux_x86.S + src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_log_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_pow_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_sin_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_sinh_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_tan_linux_x86.S = src/jdk.incubator.vector/linux/native/libjsvml/jsvml_s_tanh_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_acos_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_asin_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_atan2_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_atan_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_cbrt_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_cosh_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_exp_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_expm1_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_d_log10_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_s_atan_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_s_cbrt_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_s_exp_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_s_expm1_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_s_log10_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_s_log1p_linux_x86.S - src/jdk.incubator.vector/linux/native/libsvml/svml_s_log_linux_x86.S = src/jdk.incubator.vector/windows/native/libjsvml/globals_vectorApiSupport_windows.S.inc + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_acos_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_asin_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_atan2_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_atan_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_cbrt_windows_x86.S = src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_cos_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_cosh_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_exp_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_expm1_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_hypot_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_log10_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_log1p_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_log_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_pow_windows_x86.S = src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_sin_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_sinh_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_tan_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_d_tanh_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_acos_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_asin_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_atan2_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_atan_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_cbrt_windows_x86.S = src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_cos_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_cosh_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_exp_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_expm1_windows_x86.S = src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_hypot_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_log10_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_log1p_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_log_windows_x86.S = src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_pow_windows_x86.S = src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_sin_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_sinh_windows_x86.S = src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_tan_windows_x86.S + src/jdk.incubator.vector/windows/native/libjsvml/jsvml_s_tanh_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_acos_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_asin_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_atan2_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_atan_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_cbrt_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_cosh_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_exp_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_expm1_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_hypot_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_log10_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_log1p_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_log_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_pow_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_sinh_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_tan_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_d_tanh_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_acos_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_asin_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_atan2_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_atan_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_cbrt_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_cosh_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_exp_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_expm1_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_log10_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_log1p_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_log_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_sinh_windows_x86.S - src/jdk.incubator.vector/windows/native/libsvml/svml_s_tanh_windows_x86.S ! test/jdk/jdk/incubator/vector/ImageTest.java = test/jdk/jdk/incubator/vector/LoadJsvmlTest.java Changeset: 396132ff Author: Jaikiran Pai Date: 2021-11-05 03:44:45 +0000 URL: https://git.openjdk.java.net/loom/commit/396132ff1e56463ad195cac5c9ac8e2eac5a16e8 8275509: ModuleDescriptor.hashCode isn't reproducible across builds Reviewed-by: alanb, ihse ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java + test/jdk/java/lang/module/ModuleDescriptorHashCodeTest.java Changeset: 8e17ce00 Author: Ioi Lam Date: 2021-11-05 04:37:01 +0000 URL: https://git.openjdk.java.net/loom/commit/8e17ce00316a765bbedefc34dc5898ba4f3f2144 8275185: Remove dead code and clean up jvmstat LocalVmManager Reviewed-by: cjplummer, redestad, kevinw ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalVmManager.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/PerfDataFile.java Changeset: 7281861e Author: Thomas Stuefe Date: 2021-11-05 05:15:53 +0000 URL: https://git.openjdk.java.net/loom/commit/7281861e0662e6c51507066a1f12673a236c7491 8272065: jcmd cannot rely on the old core reflection implementation which will be changed after JEP 416 Reviewed-by: mchung, coleenp, dholmes ! src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp ! src/hotspot/share/memory/heapInspection.cpp ! src/hotspot/share/memory/metaspace/printMetaspaceInfoKlassClosure.cpp - src/hotspot/share/oops/reflectionAccessorImplKlassHelper.cpp - src/hotspot/share/oops/reflectionAccessorImplKlassHelper.hpp ! test/hotspot/jtreg/serviceability/dcmd/vm/ClassLoaderHierarchyTest.java ! test/hotspot/jtreg/serviceability/dcmd/vm/ClassLoaderStatsTest.java - test/hotspot/jtreg/serviceability/dcmd/vm/ShowReflectionTargetTest.java Changeset: 96c396b7 Author: Ningsheng Jian Date: 2021-11-05 07:45:54 +0000 URL: https://git.openjdk.java.net/loom/commit/96c396b701e290fc3e1124b1c862b41e02e9c1d9 8276151: AArch64: Incorrect result for double to int vector conversion Reviewed-by: aph, psandoz ! src/hotspot/cpu/aarch64/aarch64_neon.ad ! src/hotspot/cpu/aarch64/aarch64_neon_ad.m4 ! test/hotspot/jtreg/compiler/vectorapi/VectorCastShape128Test.java ! test/hotspot/jtreg/compiler/vectorapi/VectorCastShape64Test.java Changeset: 323d2017 Author: Leo Korinth Date: 2021-11-05 09:25:21 +0000 URL: https://git.openjdk.java.net/loom/commit/323d2017959dc96d25eaa1aad6404586099c237e 8275506: Rename allocated_on_stack to allocated_on_stack_or_embedded Reviewed-by: stuefe ! src/hotspot/share/asm/codeBuffer.cpp ! src/hotspot/share/classfile/classFileParser.cpp ! src/hotspot/share/memory/allocation.cpp ! src/hotspot/share/memory/allocation.hpp ! src/hotspot/share/utilities/growableArray.cpp ! test/hotspot/gtest/utilities/test_growableArray.cpp Changeset: 3c0faa73 Author: Leo Korinth Date: 2021-11-05 09:42:26 +0000 URL: https://git.openjdk.java.net/loom/commit/3c0faa73522bd004b66cb9e477f43e15a29842e6 8276173: Clean up and remove unneeded casts in HeapDumper Reviewed-by: coleenp, hseigel ! src/hotspot/share/services/heapDumper.cpp Changeset: d95299a4 Author: Patrick Concannon Date: 2021-11-05 10:39:37 +0000 URL: https://git.openjdk.java.net/loom/commit/d95299a4d751449816ad2a88359f1e48e9608246 8276634: Remove `usePlainDatagramSocketImpl` option from the test DatagramChannel/SendReceiveMaxSize.java Reviewed-by: dfuchs, alanb, vtewari ! test/jdk/java/nio/channels/DatagramChannel/ChangingAddress.java ! test/jdk/java/nio/channels/DatagramChannel/SendReceiveMaxSize.java Changeset: 0616d868 Author: Magnus Ihse Bursie Date: 2021-11-05 12:05:22 +0000 URL: https://git.openjdk.java.net/loom/commit/0616d868c7cd5010f017b315fa1cf6cc1617ce29 8276635: Use blessed modifier order in compiler code Reviewed-by: darcy ! src/java.compiler/share/classes/javax/tools/Diagnostic.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JRTIndex.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/file/Locations.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/StringConcat.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Dependencies.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/GraphUtils.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Name.java ! src/jdk.jartool/share/classes/sun/tools/jar/GNUStyleOptions.java Changeset: b9331360 Author: Magnus Ihse Bursie Date: 2021-11-05 12:06:39 +0000 URL: https://git.openjdk.java.net/loom/commit/b9331360f50afe5b4549d7003d4932ebc54a3c71 8276641: Use blessed modifier order in jshell Reviewed-by: iris ! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/AnsiWriter.java ! src/jdk.internal.le/windows/classes/jdk/internal/org/jline/terminal/impl/jna/win/WindowsAnsiWriter.java ! src/jdk.jshell/share/classes/jdk/jshell/Key.java ! src/jdk.jshell/share/classes/jdk/jshell/MemoryFileManager.java ! src/jdk.jshell/share/classes/jdk/jshell/spi/ExecutionControl.java Changeset: 7023b3f8 Author: Magnus Ihse Bursie Date: 2021-11-05 12:07:58 +0000 URL: https://git.openjdk.java.net/loom/commit/7023b3f8a120dda97bc27fdf130c05c1bd7a730b 8276628: Use blessed modifier order in serviceability code Reviewed-by: dholmes, lmesnik, cjplummer ! src/java.management/share/classes/com/sun/jmx/mbeanserver/DefaultMXBeanMappingFactory.java ! src/java.management/share/classes/com/sun/jmx/mbeanserver/Introspector.java ! src/java.management/share/classes/com/sun/jmx/mbeanserver/MBeanServerDelegateImpl.java ! src/java.management/share/classes/com/sun/jmx/mbeanserver/MXBeanProxy.java ! src/java.management/share/classes/com/sun/jmx/remote/internal/ClientNotifForwarder.java ! src/java.management/share/classes/com/sun/jmx/remote/security/HashedPasswordManager.java ! src/java.management/share/classes/javax/management/MBeanServerFactory.java ! src/java.management/share/classes/javax/management/ObjectName.java ! src/java.management/share/classes/javax/management/modelmbean/RequiredModelMBean.java ! src/java.management/share/classes/javax/management/timer/Timer.java ! src/java.management/share/classes/sun/management/ClassLoadingImpl.java ! src/java.management/share/classes/sun/management/NotificationEmitterSupport.java ! src/java.management/share/classes/sun/management/VMManagementImpl.java ! src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java ! src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java ! src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/compiler/OopMapValue.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/aarch64/BsdAARCH64CFrame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/amd64/BsdAMD64CFrame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/x86/BsdX86CFrame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/LinuxDebuggerLocal.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/aarch64/LinuxAARCH64CFrame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/amd64/LinuxAMD64CFrame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/ppc64/LinuxPPC64CFrame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/x86/LinuxX86CFrame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1CollectedHeap.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1HeapRegionTable.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1MonitoringSupport.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/HeapRegion.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/HeapRegionManager.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/HeapRegionSetBase.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/GenCollectedHeap.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shenandoah/ShenandoahHeap.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shenandoah/ShenandoahHeapRegion.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZAttachedArrayForForwarding.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZForwarding.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZForwardingEntry.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZForwardingTable.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZGlobals.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZGlobalsForVMStructs.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZGranuleMapForForwarding.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZGranuleMapForPageTable.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZPage.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZPageAllocator.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZPageTable.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZRelocate.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/z/ZVirtualMemory.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/DataLayout.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/DefaultMetadataVisitor.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Metadata.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/MethodData.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/ParametersTypeData.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/SpeculativeTrapData.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/CallRuntimeNode.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/CallStaticJavaNode.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/opto/Node.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/InstanceConstructor.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/jcore/ByteCodeRewriter.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/tree/CTypeTreeNodeAdapter.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/AbstractHeapGraphWriter.java ! src/jdk.jcmd/share/classes/sun/tools/jinfo/JInfo.java ! src/jdk.jconsole/share/classes/sun/tools/jconsole/inspector/XOpenTypeViewer.java ! src/jdk.jdi/share/classes/com/sun/jdi/Bootstrap.java ! src/jdk.jdi/share/classes/com/sun/jdi/connect/spi/TransportService.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/expr/ExpressionParser.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/Env.java ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/VMConnection.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/AbstractLauncher.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ClassTypeImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ConcreteMethodImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/InterfaceTypeImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/InvokableTypeImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/Packet.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/PrimitiveValueImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/RawCommandLineLauncher.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ReferenceTypeImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/TargetVM.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ThreadReferenceImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/TypeComponentImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineImpl.java ! src/jdk.management.agent/share/classes/jdk/internal/agent/Agent.java ! src/jdk.management.agent/share/classes/sun/management/jdp/JdpJmxPacket.java ! src/jdk.management/share/classes/com/sun/management/internal/DiagnosticCommandImpl.java ! src/jdk.management/share/classes/com/sun/management/internal/GarbageCollectorExtImpl.java ! src/jdk.management/share/classes/com/sun/management/internal/PlatformMBeanProviderImpl.java Changeset: c393ee8f Author: Magnus Ihse Bursie Date: 2021-11-05 14:09:58 +0000 URL: https://git.openjdk.java.net/loom/commit/c393ee8f598850379266bdba1f55af94744dbad1 8276632: Use blessed modifier order in security-libs code Reviewed-by: mullan ! src/java.security.jgss/share/classes/sun/security/jgss/ProviderList.java ! src/java.security.jgss/share/classes/sun/security/jgss/TokenTracker.java ! src/java.security.jgss/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! src/java.smartcardio/share/classes/javax/smartcardio/CardNotPresentException.java ! src/java.smartcardio/share/classes/javax/smartcardio/CardPermission.java ! src/java.smartcardio/share/classes/javax/smartcardio/TerminalFactory.java ! src/java.smartcardio/share/classes/sun/security/smartcardio/ChannelImpl.java ! src/java.smartcardio/share/classes/sun/security/smartcardio/PCSC.java ! src/java.smartcardio/unix/classes/sun/security/smartcardio/PlatformPCSC.java ! src/java.smartcardio/windows/classes/sun/security/smartcardio/PlatformPCSC.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Secmod.java ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/Constants.java ! src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/CKey.java ! src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/CRSACipher.java ! src/jdk.crypto.mscapi/windows/classes/sun/security/mscapi/CSignature.java Changeset: a74a839a Author: Vladimir Kozlov Date: 2021-11-05 16:07:25 +0000 URL: https://git.openjdk.java.net/loom/commit/a74a839af02446d322d77c6e546e652ec6ad5d73 8276571: C2: pass compilation options as structure Reviewed-by: shade, chagedorn ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/runtime/vmStructs.cpp Changeset: 92d21763 Author: Daniel D. Daugherty Date: 2021-11-05 17:04:39 +0000 URL: https://git.openjdk.java.net/loom/commit/92d2176362954a7093894057748056610eeafe4b 8273967: gtest os.dll_address_to_function_and_library_name_vm fails on macOS12 Reviewed-by: stuefe, gziemski ! src/hotspot/os/bsd/decoder_machO.cpp ! src/hotspot/os/bsd/os_bsd.cpp ! src/hotspot/share/runtime/os.cpp ! test/hotspot/gtest/runtime/test_os.cpp Changeset: b01f1073 Author: Brian Burkhalter Date: 2021-11-05 17:25:06 +0000 URL: https://git.openjdk.java.net/loom/commit/b01f1073f9691c40fc15b7ed67ae2e019ff729ea 8276252: java/nio/channels/Channels/TransferTo.java failed with OOM java heap space error Reviewed-by: lancea ! test/jdk/java/nio/channels/Channels/TransferTo.java Changeset: a4724332 Author: Andrew John Hughes Date: 2021-11-05 21:05:42 +0000 URL: https://git.openjdk.java.net/loom/commit/a4724332098cd8bff44ee27e9190fd28fa5c1865 8276572: Fake libsyslookup.so library causes tooling issues Reviewed-by: shade, mcimadamore ! src/jdk.incubator.foreign/share/native/libsyslookup/syslookup.c Changeset: 0e0dd33f Author: Kim Barrett Date: 2021-11-05 21:20:51 +0000 URL: https://git.openjdk.java.net/loom/commit/0e0dd33fff9922a086968cfa6ccd27727f979c83 8276129: PretouchTask should page-align the chunk size Reviewed-by: stefank, tschatzl ! src/hotspot/share/gc/shared/pretouchTask.cpp Changeset: 59c3dcc7 Author: Magnus Ihse Bursie Date: 2021-11-05 21:21:38 +0000 URL: https://git.openjdk.java.net/loom/commit/59c3dcc761ac7a9eab1517743cbb77e5526ca6f3 8276746: Add section on reproducible builds in building.md Reviewed-by: erikj, sgehwolf, aleonard ! doc/building.html ! doc/building.md Changeset: ed7ecca4 Author: Hamlin Li Date: 2021-11-05 23:24:45 +0000 URL: https://git.openjdk.java.net/loom/commit/ed7ecca401e5f4c3c07dc98e05a21396c6cdf594 8254739: G1: Optimize evacuation failure for regions with few failed objects Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1CardSetMemory.cpp ! src/hotspot/share/gc/g1/g1CardSetMemory.hpp ! src/hotspot/share/gc/g1/g1EvacFailure.cpp + src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.cpp + src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.hpp ! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp ! src/hotspot/share/gc/g1/g1SegmentedArray.hpp ! src/hotspot/share/gc/g1/g1SegmentedArray.inline.hpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegion.hpp ! src/hotspot/share/gc/g1/heapRegion.inline.hpp ! test/hotspot/gtest/gc/g1/test_freeRegionList.cpp Changeset: c7095b20 Author: Anirvan Sarkar Committer: Joe Wang Date: 2021-11-06 00:41:44 +0000 URL: https://git.openjdk.java.net/loom/commit/c7095b20d956e154d9863a7928d26285f1a0a0ac 8276207: Properties.loadFromXML/storeToXML works incorrectly for supplementary characters Reviewed-by: joehw ! src/java.base/share/classes/jdk/internal/util/xml/impl/Parser.java ! src/java.base/share/classes/jdk/internal/util/xml/impl/XMLStreamWriterImpl.java ! test/jdk/java/util/Properties/LoadAndStoreXML.java Changeset: 2653cfbf Author: Jaikiran Pai Date: 2021-11-06 03:36:46 +0000 URL: https://git.openjdk.java.net/loom/commit/2653cfbf0f316183ea23dd234896b44f7dd6eae0 8276688: Remove JLinkReproducibleXXXTest from ProblemList.txt Reviewed-by: alanb, mchung ! test/jdk/ProblemList.txt Changeset: 88491549 Author: Ioi Lam Date: 2021-11-07 21:38:59 +0000 URL: https://git.openjdk.java.net/loom/commit/884915496f7bfe754279f1644603131c64f192b3 8275846: read_base_archive_name() could read past the end of buffer Reviewed-by: ccheung, stuefe ! src/hotspot/share/cds/filemap.cpp ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/ArchiveConsistency.java Changeset: 44047f84 Author: Yi Yang Date: 2021-11-08 02:18:40 +0000 URL: https://git.openjdk.java.net/loom/commit/44047f849fad157dac5df788aa5a2c1838e4aaf7 8274328: C2: Redundant CFG edges fixup in block ordering Reviewed-by: thartmann, kvn ! src/hotspot/share/opto/block.cpp ! src/hotspot/share/opto/block.hpp Changeset: 3934fe54 Author: Nick Gasson Date: 2021-11-08 06:40:49 +0000 URL: https://git.openjdk.java.net/loom/commit/3934fe54b4c3e51add6d3fe1f145e5aebfe3b2fc 8275847: Scheduling fails with "too many D-U pinch points" on small method Reviewed-by: thartmann, kvn ! src/hotspot/cpu/x86/vmreg_x86.hpp ! src/hotspot/share/opto/buildOopMap.cpp ! src/hotspot/share/opto/output.cpp + test/hotspot/jtreg/compiler/c2/irTests/TestScheduleSmallMethod.java Changeset: fc0fe256 Author: Christian Stein Committer: Aleksey Shipilev Date: 2021-11-08 08:09:51 +0000 URL: https://git.openjdk.java.net/loom/commit/fc0fe256793b33430c1247e0c091150a091da3c4 8273235: tools/launcher/HelpFlagsTest.java Fails on Windows 32bit Reviewed-by: shade ! test/jdk/tools/launcher/HelpFlagsTest.java Changeset: d8b0dee6 Author: Ludvig Janiuk Committer: Claes Redestad Date: 2021-11-08 09:44:44 +0000 URL: https://git.openjdk.java.net/loom/commit/d8b0dee65e7e074d81eecf451542f79747ea7c78 8276239: Better tables in java.util.random package summary Reviewed-by: jlaskey ! src/java.base/share/classes/java/util/random/package-info.java Changeset: 0395e4ef Author: Hannes Walln?fer Date: 2021-11-08 11:35:26 +0000 URL: https://git.openjdk.java.net/loom/commit/0395e4ef8ced8385cc2c9b3bea4c6f4490c62d2b 8276768: Snippet copy feature should use button instead of link Reviewed-by: prappo ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/script.js ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css ! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java ! test/langtools/jdk/javadoc/lib/javadoc/tester/LinkChecker.java Changeset: 54481394 Author: Christian Hagedorn Date: 2021-11-08 12:47:58 +0000 URL: https://git.openjdk.java.net/loom/commit/54481394a3b7d36b2326e22e4aa910a3e8041b5c 8271056: C2: "assert(no_dead_loop) failed: dead loop detected" due to cmoving identity Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/cfgnode.cpp + test/hotspot/jtreg/compiler/c2/TestDeadDataLoopCmoveIdentity.java Changeset: ff6863c9 Author: Thomas Schatzl Date: 2021-11-08 12:59:00 +0000 URL: https://git.openjdk.java.net/loom/commit/ff6863c98dbd15c4f3920402eb0991727d1a380c 8276540: Howl Full CardSet container iteration marks too many cards Reviewed-by: ayang, sjohanss ! src/hotspot/share/gc/g1/g1CardSetContainers.inline.hpp Changeset: 4c14eddf Author: Jan Lahoda Date: 2021-11-08 13:19:51 +0000 URL: https://git.openjdk.java.net/loom/commit/4c14eddf41f1d9984417dc5ac6aba6f268b31029 8274734: the method jdk.jshell.SourceCodeAnalysis documentation not working Reviewed-by: vromero ! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java + test/langtools/jdk/jshell/MultipleDocumentationTest.java Changeset: fa754b8f Author: Jan Lahoda Date: 2021-11-08 13:20:44 +0000 URL: https://git.openjdk.java.net/loom/commit/fa754b8ffda0ae16cda03d896260870ff8fb6ae9 8276149: jshell throws EOF error when throwing exception inside switch expression Reviewed-by: vromero ! src/jdk.jshell/share/classes/jdk/jshell/CompletenessAnalyzer.java ! test/langtools/jdk/jshell/CompletenessTest.java Changeset: 0c2d00bf Author: Jan Lahoda Date: 2021-11-08 13:21:40 +0000 URL: https://git.openjdk.java.net/loom/commit/0c2d00bff7b96cca53820aadfdaf09c840a2a33a 8275097: Wrong span of the 'default' tag Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java ! test/langtools/tools/javac/parser/JavacParserTest.java ! test/langtools/tools/javac/patterns/SwitchErrors.out Changeset: cc2cac13 Author: Petr Portnov Committer: Roger Riggs Date: 2021-11-08 13:22:37 +0000 URL: https://git.openjdk.java.net/loom/commit/cc2cac130cc28730a30d2e1d76bcb6ec8bc0b580 8274686: java.util.UUID#hashCode() should use Long.hashCode() Reviewed-by: rriggs ! src/java.base/share/classes/java/util/UUID.java Changeset: 71c4b195 Author: Andy Herrick Date: 2021-11-08 13:45:23 +0000 URL: https://git.openjdk.java.net/loom/commit/71c4b195178029f5414fa45d2c5ac70a1d2536e5 8276562: Fix to JDK-8263155 left out the help text changes Reviewed-by: asemenyuk, almatvee ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/CLIHelp.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_ja.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_zh_CN.properties Changeset: c815c5cb Author: Denghui Dong Date: 2021-11-08 14:30:54 +0000 URL: https://git.openjdk.java.net/loom/commit/c815c5cbbb0b6a2aebd0a38cb930c74bd665d082 8276209: Some call sites doesn't pass the parameter 'size' to SharedRuntime::dtrace_object_alloc(_base) Reviewed-by: dholmes, coleenp ! src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp ! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp ! src/hotspot/cpu/arm/templateTable_arm.cpp ! src/hotspot/cpu/ppc/c1_Runtime1_ppc.cpp ! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp ! src/hotspot/cpu/s390/c1_Runtime1_s390.cpp ! src/hotspot/cpu/s390/templateTable_s390.cpp ! src/hotspot/cpu/x86/c1_Runtime1_x86.cpp ! src/hotspot/cpu/x86/templateTable_x86.cpp ! src/hotspot/share/gc/shared/memAllocator.cpp ! src/hotspot/share/opto/macro.cpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp Changeset: ea23e733 Author: Daniel D. Daugherty Date: 2021-11-08 14:45:04 +0000 URL: https://git.openjdk.java.net/loom/commit/ea23e7333e03abb4aca3e9f3854bab418a4b70e2 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes Reviewed-by: coleenp, sspitsyn, dholmes, rehn ! src/hotspot/share/prims/jvmtiEnv.cpp ! src/hotspot/share/prims/jvmtiEventController.cpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/handshake.cpp ! src/hotspot/share/runtime/handshake.hpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp Changeset: 7320b77b Author: Thomas Schatzl Date: 2021-11-08 15:00:31 +0000 URL: https://git.openjdk.java.net/loom/commit/7320b77b3e451932ee8befa7af4b80593725761e 8276548: Use range based visitor for Howl-Full cards Reviewed-by: ayang, sjohanss ! src/hotspot/share/gc/g1/g1CardSetContainers.inline.hpp ! src/hotspot/share/gc/g1/g1RemSet.cpp Changeset: 75adf54b Author: Aleksey Shipilev Date: 2021-11-08 15:35:27 +0000 URL: https://git.openjdk.java.net/loom/commit/75adf54bdcc5e06fb8e8ca499a2f326d70b65f76 8276306: jdk/jshell/CustomInputToolBuilder.java fails intermittently on storage acquisition Reviewed-by: jlahoda ! test/langtools/jdk/jshell/CustomInputToolBuilder.java Changeset: 7e73bca0 Author: Roger Riggs Date: 2021-11-08 16:39:07 +0000 URL: https://git.openjdk.java.net/loom/commit/7e73bca0b7a34af9fb73780491951539815651b4 8276408: Deprecate Runtime.exec methods with a single string command line argument Reviewed-by: alanb ! src/java.base/share/classes/java/lang/Runtime.java ! test/jdk/java/lang/ProcessBuilder/Zombies.java ! test/jdk/java/lang/RuntimeTests/exec/BadEnvp.java ! test/jdk/java/lang/RuntimeTests/exec/ExecWithDir.java ! test/jdk/java/lang/RuntimeTests/exec/SetCwd.java Changeset: e383d263 Author: Jonathan Gibbons Date: 2021-11-08 19:13:22 +0000 URL: https://git.openjdk.java.net/loom/commit/e383d263610c7b4d4be2dce599a9043b8f76cd64 8275199: Bogus warning generated for serializable records Reviewed-by: hannesw ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ClassBuilder.java ! test/langtools/jdk/javadoc/doclet/testRecordTypes/TestRecordTypes.java = test/langtools/jdk/javadoc/doclet/testRecordTypes/jdk17/element-list Changeset: 905e3e88 Author: Eamonn McManus Date: 2021-11-08 19:57:44 +0000 URL: https://git.openjdk.java.net/loom/commit/905e3e88137d46f90de7034e9fc324e97af873a6 8231490: Ugly racy writes to ZipUtils.defaultBuf Reviewed-by: lancea ! src/java.base/share/classes/java/util/zip/Inflater.java Changeset: 14d66bd4 Author: Andrew Leonard Date: 2021-11-08 20:37:24 +0000 URL: https://git.openjdk.java.net/loom/commit/14d66bd438dfa1feeafaca39be8f79a91e2968e9 8276654: element-list order is non deterministic Reviewed-by: ihse ! make/modules/jdk.javadoc/Gendata.gmk Changeset: a7dedb5f Author: Joe Darcy Date: 2021-11-08 22:19:55 +0000 URL: https://git.openjdk.java.net/loom/commit/a7dedb5f4761a7d0bc4db658d96d369b13b80620 8276772: Refine javax.lang.model docs Reviewed-by: iris, vromero ! src/java.compiler/share/classes/javax/lang/model/SourceVersion.java ! src/java.compiler/share/classes/javax/lang/model/element/AnnotationMirror.java ! src/java.compiler/share/classes/javax/lang/model/element/Element.java ! src/java.compiler/share/classes/javax/lang/model/element/ElementVisitor.java ! src/java.compiler/share/classes/javax/lang/model/element/RecordComponentElement.java ! src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java ! src/java.compiler/share/classes/javax/lang/model/type/NoType.java ! src/java.compiler/share/classes/javax/lang/model/type/NullType.java ! src/java.compiler/share/classes/javax/lang/model/type/PrimitiveType.java ! src/java.compiler/share/classes/javax/lang/model/util/Elements.java Changeset: 38e6d5d6 Author: Bradford Wetmore Date: 2021-11-09 01:11:18 +0000 URL: https://git.openjdk.java.net/loom/commit/38e6d5d6ed967f68e6ac1bfaa285efa16577c790 8276677: Malformed Javadoc inline tags in JDK source in javax/net/ssl Reviewed-by: jnimeh ! src/java.base/share/classes/javax/net/ssl/SSLEngine.java ! src/java.base/share/classes/javax/net/ssl/SSLSocket.java Changeset: 8747882e Author: Ioi Lam Date: 2021-11-09 07:18:06 +0000 URL: https://git.openjdk.java.net/loom/commit/8747882e4cb3af58062923bf830f9de877bdb03d 8276790: Rename GenericCDSFileMapHeader::_base_archive_path_offset Reviewed-by: dholmes, ccheung ! src/hotspot/share/cds/cdsConstants.cpp ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/cds/filemap.hpp ! src/hotspot/share/include/cds.h ! test/hotspot/jtreg/runtime/cds/appcds/SharedArchiveConsistency.java ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/ArchiveConsistency.java ! test/lib/jdk/test/lib/cds/CDSArchiveUtils.java Changeset: 945f4085 Author: Stefan Johansson Date: 2021-11-09 11:11:23 +0000 URL: https://git.openjdk.java.net/loom/commit/945f4085e5c51f37c2048bb221a1521895ba28c6 8276098: Do precise BOT updates in G1 evacuation phase Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1AllocRegion.cpp ! src/hotspot/share/gc/g1/g1AllocRegion.hpp ! src/hotspot/share/gc/g1/g1AllocRegion.inline.hpp ! src/hotspot/share/gc/g1/g1Allocator.cpp ! src/hotspot/share/gc/g1/g1Allocator.hpp ! src/hotspot/share/gc/g1/g1Allocator.inline.hpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.hpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.inline.hpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegion.hpp ! src/hotspot/share/gc/g1/heapRegion.inline.hpp ! src/hotspot/share/gc/shared/plab.hpp Changeset: 5c7f77c8 Author: Thomas Schatzl Date: 2021-11-09 13:07:42 +0000 URL: https://git.openjdk.java.net/loom/commit/5c7f77c82404976a6ca1d54b40f1969eac10d63b 8276850: Remove outdated comment in HeapRegionManager::par_iterate Reviewed-by: ayang, sjohanss ! src/hotspot/share/gc/g1/heapRegionManager.cpp Changeset: 4bd5bfd8 Author: Thomas Stuefe Date: 2021-11-09 14:12:40 +0000 URL: https://git.openjdk.java.net/loom/commit/4bd5bfd8e2624715ebfa6e4c49172361389fbc98 8276731: Metaspace chunks are uncommitted twice Reviewed-by: shade, coleenp ! src/hotspot/share/memory/metaspace/chunkManager.cpp Changeset: e1985947 Author: Masanori Yano Committer: Alan Bateman Date: 2021-11-09 14:28:07 +0000 URL: https://git.openjdk.java.net/loom/commit/e198594753b0b0653256923586c7f4ec9e3cfac3 8250678: ModuleDescriptor.Version parsing treats empty segments inconsistently Reviewed-by: mchung, alanb ! src/java.base/share/classes/java/lang/module/ModuleDescriptor.java ! test/jdk/java/lang/module/VersionTest.java Changeset: c27afb31 Author: Weijun Wang Date: 2021-11-09 14:46:32 +0000 URL: https://git.openjdk.java.net/loom/commit/c27afb313b77d19e7ace7101c6f21aa5b2c56505 8276863: Remove test/jdk/sun/security/ec/ECDSAJavaVerify.java Reviewed-by: ascarpino - test/jdk/sun/security/ec/ECDSAJavaVerify.java Changeset: f65db88b Author: Yasumasa Suenaga Date: 2021-11-09 14:54:42 +0000 URL: https://git.openjdk.java.net/loom/commit/f65db88b74911e5896d2ff536c4ac97e7f62d98b 8276841: Add support for Visual Studio 2022 Reviewed-by: erikj, ihse ! make/autoconf/toolchain_microsoft.m4 Changeset: e35abe32 Author: Hannes Walln?fer Date: 2021-11-09 15:05:07 +0000 URL: https://git.openjdk.java.net/loom/commit/e35abe3235ab38985a19545e76c58260ec97c718 8256208: Javadoc's generated overview does not show classes of unnamed package Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlConfiguration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageIndexWriter.java ! test/langtools/jdk/javadoc/doclet/testUnnamedPackage/TestUnnamedPackage.java = test/langtools/jdk/javadoc/doclet/testUnnamedPackage/src1/pkg/D.java + test/langtools/jdk/javadoc/doclet/testUnnamedPackage/src1/pkg/package.html Changeset: 93692ea0 Author: Andrey Turbanov Committer: Chris Plummer Date: 2021-11-09 16:58:43 +0000 URL: https://git.openjdk.java.net/loom/commit/93692ea0a9bc437309b808f511c771a79dcdfb9a 8274395: Use enhanced-for instead of plain 'for' in jdk.internal.jvmstat Reviewed-by: cjplummer, amenkov, sspitsyn ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/HostIdentifier.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/VmIdentifier.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/PerfDataBufferImpl.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalMonitoredVm.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/LocalVmManager.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/local/MonitoredHostProvider.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v2_0/TypeCode.java Changeset: daf77ebf Author: Leo Korinth Date: 2021-11-09 17:50:16 +0000 URL: https://git.openjdk.java.net/loom/commit/daf77ebfc4ca6d537ef55acbd62b908b5575ad08 8276337: Use override specifier in HeapDumper Reviewed-by: stuefe, dholmes ! src/hotspot/share/services/heapDumper.cpp Changeset: dde959df Author: Brian Burkhalter Date: 2021-11-09 19:17:59 +0000 URL: https://git.openjdk.java.net/loom/commit/dde959dfcef01897fdf51f820d414402e6309b8d 8276808: java/nio/channels/Channels/TransferTo.java timed out Reviewed-by: lancea, shade ! test/jdk/java/nio/channels/Channels/TransferTo.java Changeset: a60e9125 Author: Pankaj Bansal Date: 2021-11-09 20:10:20 +0000 URL: https://git.openjdk.java.net/loom/commit/a60e91259ba83d2a525b612b2c7a1fd7934b88a2 8198626: java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.html fails on mac Reviewed-by: serb ! test/jdk/ProblemList.txt ! test/jdk/java/awt/KeyboardFocusmanager/TypeAhead/TestDialogTypeAhead.java Changeset: 055de6f5 Author: Hannes Walln?fer Date: 2021-11-09 20:11:18 +0000 URL: https://git.openjdk.java.net/loom/commit/055de6f566208b168818be1dc3ad29cdb9caa1cf 8223358: Incorrect HTML structure in annotation pages Reviewed-by: jjg + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeMemberWriterImpl.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlIds.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Navigation.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SummaryListWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/WriterFactoryImpl.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/AnnotationTypeMemberWriter.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/AnnotationTypeOptionalMemberWriter.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/AnnotationTypeRequiredMemberWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/WriterFactory.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AbstractMemberBuilder.java + src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AnnotationTypeMemberBuilder.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AnnotationTypeOptionalMemberBuilder.java - src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/BuilderFactory.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ClassBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/VisibleMemberTable.java ! test/langtools/jdk/javadoc/doclet/testAnnotationTypes/TestAnnotationTypes.java ! test/langtools/jdk/javadoc/doclet/testAnnotationTypes/pkg/AnnotationType.java Changeset: f9024d06 Author: Hannes Walln?fer Date: 2021-11-09 20:17:25 +0000 URL: https://git.openjdk.java.net/loom/commit/f9024d0606e39863b590f0d7c949d569f8bf8abd 8230130: javadoc search result dialog shows cut off headers for long results Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css Changeset: d7012fbd Author: Roger Riggs Date: 2021-11-09 20:43:51 +0000 URL: https://git.openjdk.java.net/loom/commit/d7012fbd604fc1a54a2d7364a6ca4a32f47ffc7c 8276880: Remove java/lang/RuntimeTests/exec/ExecWithDir as unnecessary Reviewed-by: alanb - test/jdk/java/lang/RuntimeTests/exec/ExecWithDir.java Changeset: 06992208 Author: Rickard B?ckman Date: 2021-11-09 21:38:12 +0000 URL: https://git.openjdk.java.net/loom/commit/0699220830a457959b784b35af125b70f43fa3b0 8268882: C2: assert(n->outcnt() != 0 || C->top() == n || n->is_Proj()) failed: No dead instructions after post-alloc Reviewed-by: neliasso, chagedorn, kvn ! src/hotspot/share/opto/postaloc.cpp Changeset: c8b0ee6b Author: Hamlin Li Date: 2021-11-10 01:12:43 +0000 URL: https://git.openjdk.java.net/loom/commit/c8b0ee6b8a0c1bca8f8357e786f24c8cb6dd7310 8276833: G1: Make G1EvacFailureRegions::par_iterate const Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1EvacFailureRegions.cpp ! src/hotspot/share/gc/g1/g1EvacFailureRegions.hpp Changeset: c1e41fe3 Author: Hamlin Li Date: 2021-11-10 01:13:30 +0000 URL: https://git.openjdk.java.net/loom/commit/c1e41fe38bbbae12e1f73d2cd63c7afffc19475b 8276842: G1: Only calculate size in bytes from words when needed Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1EvacFailure.cpp Changeset: 8822d41f Author: Jamil Nimeh Date: 2021-11-10 01:24:33 +0000 URL: https://git.openjdk.java.net/loom/commit/8822d41fdcc2c2d568badd72635dc587d21dbd63 8274736: Concurrent read/close of SSLSockets causes SSLSessions to be invalidated unnecessarily Reviewed-by: xuelei, wetmore ! src/java.base/share/classes/sun/security/ssl/TransportContext.java ! test/jdk/javax/net/ssl/templates/SSLSocketTemplate.java + test/jdk/sun/security/ssl/SSLSessionImpl/NoInvalidateSocketException.java Changeset: e91e9d85 Author: Hamlin Li Date: 2021-11-10 01:26:35 +0000 URL: https://git.openjdk.java.net/loom/commit/e91e9d853272ea8f5ce490f2f0c971fd40795d74 8276721: G1: Refine G1EvacFailureObjectsSet::iterate Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1EvacFailure.cpp ! src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.cpp ! src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.hpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegion.hpp Changeset: 403f3185 Author: Anirvan Sarkar Committer: Christoph Langer Date: 2021-11-10 05:51:39 +0000 URL: https://git.openjdk.java.net/loom/commit/403f3185f0988dcf6ef4e857d6659533bfa2943f 8276854: Windows GHA builds fail due to broken Cygwin Reviewed-by: clanger ! .github/workflows/submit.yml Changeset: fd0a25e6 Author: Aleksey Shipilev Date: 2021-11-10 07:59:01 +0000 URL: https://git.openjdk.java.net/loom/commit/fd0a25e62b2c8abc3a419c2e80abbcf11c9e882f 8276805: java/awt/print/PrinterJob/CheckPrivilege.java fails due to disabled SecurityManager Reviewed-by: serb, aivanov ! test/jdk/java/awt/print/PrinterJob/CheckPrivilege.java Changeset: e01d6d00 Author: Prasanta Sadhukhan Date: 2021-11-10 08:34:07 +0000 URL: https://git.openjdk.java.net/loom/commit/e01d6d00bc4ab5ca0d38f8894a78e6d911e0fe93 8276679: Malformed Javadoc inline tags in JDK source in javax/swing Reviewed-by: aivanov, pbansal ! src/java.desktop/share/classes/javax/swing/JTree.java ! src/java.desktop/share/classes/javax/swing/SwingUtilities.java ! src/java.desktop/share/classes/javax/swing/event/HyperlinkEvent.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java Changeset: 0f463a7b Author: Aleksey Shipilev Date: 2021-11-10 09:50:27 +0000 URL: https://git.openjdk.java.net/loom/commit/0f463a7bf73791eda9404882ff63daf9040399bb 8276845: (fs) java/nio/file/spi/SetDefaultProvider.java fails on x86_32 Reviewed-by: alanb ! test/jdk/java/nio/file/spi/TestProvider.java Changeset: a3f710ef Author: Aleksey Shipilev Date: 2021-11-10 10:45:51 +0000 URL: https://git.openjdk.java.net/loom/commit/a3f710efbe7dcef18477a96fd306bec19f181f8b 8276215: Intrinsics matchers should handle native method flags better Reviewed-by: dholmes, kvn ! src/hotspot/share/classfile/vmIntrinsics.cpp ! src/hotspot/share/classfile/vmIntrinsics.hpp From forax at univ-mlv.fr Sat Nov 20 13:57:23 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 20 Nov 2021 14:57:23 +0100 (CET) Subject: try-with-resources vs structured concurrency Message-ID: <1521056674.3280613.1637416643873.JavaMail.zimbra@u-pem.fr> Playing with the StructuredExecutor, i've trouble to write the correct code when i use a structured executor inside a structured executor, so in several tests, I wrote something like this try(var executor = StructuredExecutor.open()) { try(var executor2 = StructuredExecutor.open()) { var handler = new StructuredExecutor.ShutdownOnSuccess(); executor2.fork(() -> 3, handler); executor2.fork(() -> 7, handler); executor.join(); // <--- oops System.out.println(handler.result()); } executor.join(); } sadly, there is no way in Java to hide a local variable with another one try(var executor = StructuredExecutor.open()) { try(var executor = StructuredExecutor.open()) { // reuse executor here even if this is what we want here. R?mi From oleksandr.otenko at gmail.com Sat Nov 20 16:43:47 2021 From: oleksandr.otenko at gmail.com (Alex Otenko) Date: Sat, 20 Nov 2021 16:43:47 +0000 Subject: Future.resultNow / exceptionNow Message-ID: Is there a strong opinion about Future.resultNow and exceptionNow throwing IllegalStateException? It seems there will likely be boilerplate try-catching, as there is no safe way to inquire in what way the Future is isDone. Returning Optional seems a nicer alternative. Alex From forax at univ-mlv.fr Sat Nov 20 16:51:57 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 20 Nov 2021 17:51:57 +0100 (CET) Subject: Future.resultNow / exceptionNow In-Reply-To: References: Message-ID: <761502459.3303733.1637427117229.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "Alex Otenko" > To: "loom-dev" > Sent: Samedi 20 Novembre 2021 17:43:47 > Subject: Future.resultNow / exceptionNow > Is there a strong opinion about Future.resultNow and exceptionNow throwing > IllegalStateException? It seems there will likely be boilerplate > try-catching, as there is no safe way to inquire in what way the Future is > isDone. > > Returning Optional seems a nicer alternative. Hi Alex, the idea of resultNow()/exceptionNow() is that it should be called when you have the guarantee that isDone is true, like after a call to StructuredExecutor.join()/joinUntil(). So it should throw a ISE because it means that you have not use resultNow()/exceptionNow() correctly, by example because you have forgotten to do call StructuredExecutor.join() first. > > Alex regards, R?mi From Alan.Bateman at oracle.com Sat Nov 20 17:31:58 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 20 Nov 2021 17:31:58 +0000 Subject: [External] : Re: Virtual threads and executor ? In-Reply-To: <74931705.3269942.1637411214187.JavaMail.zimbra@u-pem.fr> References: <1200540038.2654931.1637263362471.JavaMail.zimbra@u-pem.fr> <1726154913.3175687.1637346375316.JavaMail.zimbra@u-pem.fr> <9AF004AB-64CF-40C7-A225-607A47E3F0F1@oracle.com> <74931705.3269942.1637411214187.JavaMail.zimbra@u-pem.fr> Message-ID: On 20/11/2021 12:26, forax at univ-mlv.fr wrote: > : > The problem with Executors.newVirtualThreadPerTaskExecutor() is that you can not specify an underlying executor, all the virtual threads has to run on the default common fork/join pool but the common F/J pool is not good in all use cases (you can even specify another pool when using a parallel stream), it's just a good default. > > I am all good with not having an API promising too much, but this limitation makes the integration of loom to existing libraries/stack unnecessary hard IMO. > I suspect you know this but just to say that virtual thread doesn't use the common pool. The FJP instance for virtual threads is configured differently, the main difference is that it is configured in async mode (FIFO). -Alan. From Alan.Bateman at oracle.com Sat Nov 20 17:32:24 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 20 Nov 2021 17:32:24 +0000 Subject: Future.resultNow / exceptionNow In-Reply-To: <761502459.3303733.1637427117229.JavaMail.zimbra@u-pem.fr> References: <761502459.3303733.1637427117229.JavaMail.zimbra@u-pem.fr> Message-ID: <866f2f83-c981-c3e2-b41c-2a727e874b51@oracle.com> On 20/11/2021 16:51, Remi Forax wrote: > : > Hi Alex, the idea of resultNow()/exceptionNow() is that it should be called when you have the guarantee that isDone is true, > like after a call to StructuredExecutor.join()/joinUntil(). > > So it should throw a ISE because it means that you have not use resultNow()/exceptionNow() correctly, by example because you have forgotten to do call StructuredExecutor.join() first. Also just to say that it makes it easy to have Futures be elements in streams: filter on the state, map with resultNow. Also works nicely with switch. -Alan From brian.goetz at oracle.com Sat Nov 20 17:41:08 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Sat, 20 Nov 2021 12:41:08 -0500 Subject: Future.resultNow / exceptionNow In-Reply-To: References: Message-ID: <593b0c08-6564-d92a-4344-d85ab1c2df0b@oracle.com> That would kind of defeat the purpose.? If you follow the discipline of structured concurrency, where the parent always waits for the child to complete (StructuredExecutor offers methods and patterns for guaranteeing this), then you will know with confidence that the future is complete, and it is safe to just ask for the result. Throwing ISE means you made a coding error (i.e., you forgot to wait for the children), like dereferencing an object reference without knowing it was non-null, indexing into an array without knowing the bounds, or calling Optional::get without knowing the Optional holds a value. Catching ISE here would be like blindly wrapping every dereference with "catch NPE", or every array access with "catch AIOOBE". On 11/20/2021 11:43 AM, Alex Otenko wrote: > Is there a strong opinion about Future.resultNow and exceptionNow throwing > IllegalStateException? It seems there will likely be boilerplate > try-catching, as there is no safe way to inquire in what way the Future is > isDone. > > Returning Optional seems a nicer alternative. > > Alex From duke at openjdk.java.net Sat Nov 20 18:56:48 2021 From: duke at openjdk.java.net (duke) Date: Sat, 20 Nov 2021 18:56:48 GMT Subject: git: openjdk/loom: fibers: 86 new changesets Message-ID: Changeset: a0b84453 Author: Aleksey Shipilev Date: 2021-11-10 11:27:13 +0000 URL: https://git.openjdk.java.net/loom/commit/a0b84453b087ff368a32b93729c5b30fda22ed48 8276846: JDK-8273416 is incomplete for UseSSE=1 Reviewed-by: neliasso, kvn ! src/hotspot/cpu/x86/x86_32.ad Changeset: 0f23c6a9 Author: Sergey Tsypanov Committer: Claes Redestad Date: 2021-11-10 12:46:30 +0000 URL: https://git.openjdk.java.net/loom/commit/0f23c6a9feb3657eb20ff5988a9e2ffca2108af1 8276926: Use String.valueOf() when initializing File.separator and File.pathSeparator Reviewed-by: redestad, jlaskey ! src/java.base/share/classes/java/io/File.java Changeset: 55b36c6f Author: Harold Seigel Date: 2021-11-10 13:11:16 +0000 URL: https://git.openjdk.java.net/loom/commit/55b36c6f3bb7eb066daaf41f9eba46633afedf08 8276825: hotspot/runtime/SelectionResolution test errors Reviewed-by: dholmes, shade ! test/hotspot/jtreg/runtime/SelectionResolution/classes/selectionresolution/ClassBuilder.java ! test/hotspot/jtreg/runtime/SelectionResolution/classes/selectionresolution/Clazz.java ! test/hotspot/jtreg/runtime/SelectionResolution/classes/selectionresolution/TestBuilder.java Changeset: 38ec3a16 Author: Yasumasa Suenaga Date: 2021-11-10 14:33:02 +0000 URL: https://git.openjdk.java.net/loom/commit/38ec3a16d722d740d0b2128c6f6c2d1eab7a7c08 8276672: Cannot build hsdis on WSL Co-authored-by: Magnus Ihse Bursie Co-authored-by: Yasumasa Suenaga Reviewed-by: ihse, erikj ! make/Hsdis.gmk Changeset: f561d3c1 Author: Aleksey Shipilev Date: 2021-11-10 14:41:33 +0000 URL: https://git.openjdk.java.net/loom/commit/f561d3c1942ce901fa77c907839032f76feb6998 8276864: Update boot JDKs to 17.0.1 in GHA Reviewed-by: erikj, ihse ! make/conf/test-dependencies Changeset: ce3ed65a Author: Jonathan Gibbons Date: 2021-11-10 15:24:27 +0000 URL: https://git.openjdk.java.net/loom/commit/ce3ed65ac3411a533052a8c01231f7e540803afb 8273154: Provide a JavadocTester method for non-overlapping, unordered output matching Reviewed-by: prappo ! test/langtools/jdk/javadoc/lib/javadoc/tester/JavadocTester.java + test/langtools/jdk/javadoc/testJavadocTester/TestJavadocTester.java Changeset: a5c160c7 Author: Weijun Wang Date: 2021-11-10 19:35:17 +0000 URL: https://git.openjdk.java.net/loom/commit/a5c160c711a3f66db18c75973f4efdea63332863 8267108: Alternate Subject.getSubject and doAs APIs that do not depend on Security Manager APIs Reviewed-by: mullan ! src/java.base/share/classes/javax/security/auth/Subject.java ! src/java.security.jgss/share/classes/sun/security/jgss/GSSUtil.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Context.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5InitCredential.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Util.java ! test/jdk/com/sun/security/sasl/gsskerb/AuthOnly.java ! test/jdk/com/sun/security/sasl/gsskerb/ConfSecurityLayer.java ! test/jdk/com/sun/security/sasl/gsskerb/NoSecurityLayer.java ! test/jdk/java/security/AccessController/PreserveCombiner.java + test/jdk/javax/security/auth/Subject/CurrentSubject.java ! test/jdk/javax/security/auth/Subject/DoAs.java + test/jdk/javax/security/auth/Subject/Exceptions.java + test/jdk/javax/security/auth/Subject/FromACC.java ! test/jdk/javax/security/auth/Subject/Synch.java ! test/jdk/sun/security/krb5/KrbCredSubKey.java ! test/jdk/sun/security/krb5/ServiceCredsCombination.java ! test/jdk/sun/security/krb5/auto/Context.java ! test/jdk/sun/security/krb5/auto/HttpNegotiateServer.java ! test/jdk/sun/security/krb5/auto/LongLife.java Changeset: 67c2714b Author: Coleen Phillimore Date: 2021-11-10 19:45:09 +0000 URL: https://git.openjdk.java.net/loom/commit/67c2714ba2c9658e07153a6f50391c896e4caebc 8276889: Improve compatibility discussion in instanceKlass.cpp Reviewed-by: hseigel ! src/hotspot/share/oops/instanceKlass.cpp Changeset: 2374abda Author: Alisen Chung Committer: Alexey Ivanov Date: 2021-11-10 20:08:13 +0000 URL: https://git.openjdk.java.net/loom/commit/2374abda19213d615a72c83f584ea61d5bbba4a3 8276678: Malformed Javadoc inline tags in JDK source in com/sun/beans/decoder/DocumentHandler.java Reviewed-by: serb, aivanov ! src/java.desktop/share/classes/com/sun/beans/decoder/DocumentHandler.java Changeset: df02daa6 Author: Ioi Lam Date: 2021-11-10 20:22:41 +0000 URL: https://git.openjdk.java.net/loom/commit/df02daa6f9df801a7e0b6203fd6411d8a62bb277 8269986: Remove +3 from Symbol::identity_hash() Reviewed-by: coleenp ! src/hotspot/share/oops/symbol.hpp Changeset: 0c409cac Author: Naoto Sato Date: 2021-11-10 20:52:11 +0000 URL: https://git.openjdk.java.net/loom/commit/0c409cac789f1b1d21e09a65db36bb6c72c569db 8276186: Require getAvailableLocales() methods to include Locale.ROOT Reviewed-by: prappo, smarks, iris ! src/java.base/share/classes/java/text/BreakIterator.java ! src/java.base/share/classes/java/text/Collator.java ! src/java.base/share/classes/java/text/DateFormat.java ! src/java.base/share/classes/java/text/DateFormatSymbols.java ! src/java.base/share/classes/java/text/DecimalFormatSymbols.java ! src/java.base/share/classes/java/text/NumberFormat.java ! src/java.base/share/classes/java/time/format/DecimalStyle.java ! src/java.base/share/classes/java/util/Calendar.java ! src/java.base/share/classes/java/util/Locale.java + test/jdk/java/util/Locale/RequiredAvailableLocalesTest.java Changeset: bce35ac1 Author: Naoto Sato Date: 2021-11-10 20:53:23 +0000 URL: https://git.openjdk.java.net/loom/commit/bce35ac1d6c4115148468a3240ad459074e0b79e 8276775: ZonedDateTime/OffsetDateTime.toString return invalid ISO-8601 for years <= 1893 Reviewed-by: lancea, iris, bpb, scolebourne, rriggs ! src/java.base/share/classes/java/time/OffsetDateTime.java ! src/java.base/share/classes/java/time/ZonedDateTime.java Changeset: 73e6d7d7 Author: Zhengyu Gu Date: 2021-11-11 00:14:52 +0000 URL: https://git.openjdk.java.net/loom/commit/73e6d7d74d2ddd27f11775944c6fc4fb5268106d 8276801: gc/stress/CriticalNativeStress.java fails intermittently with Shenandoah Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp ! src/hotspot/share/gc/shenandoah/shenandoahNMethod.cpp Changeset: e27a67a9 Author: Jesper Wilhelmsson Date: 2021-11-11 01:14:30 +0000 URL: https://git.openjdk.java.net/loom/commit/e27a67a91647e584411a9ef57c0a028ab37af19b 8276930: Update ProblemList Reviewed-by: kevinw, dholmes ! test/jdk/ProblemList.txt Changeset: ad3be04d Author: Yoshiki Sato Committer: Naoto Sato Date: 2021-11-11 01:39:06 +0000 URL: https://git.openjdk.java.net/loom/commit/ad3be04d2ac84836e393d696ff03ddfe72779094 8276536: Update TimeZoneNames files to follow the changes made by JDK-8275766 Reviewed-by: naoto, coffeys ! src/java.base/share/classes/sun/util/resources/TimeZoneNames.java ! src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_de.java ! src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_es.java ! src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_fr.java ! src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_it.java ! src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_ja.java ! src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_ko.java ! src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_pt_BR.java ! src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_sv.java ! src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_zh_CN.java ! src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_zh_TW.java Changeset: 08e0fd67 Author: Hamlin Li Date: 2021-11-11 05:52:58 +0000 URL: https://git.openjdk.java.net/loom/commit/08e0fd6757ef15b71df0e86afd01211a6e48bd09 8276835: G1: make G1EvacFailureObjectsSet::record inline Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.cpp ! src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.hpp + src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.inline.hpp ! src/hotspot/share/gc/g1/heapRegion.inline.hpp Changeset: 91bb0d65 Author: Aleksey Shipilev Date: 2021-11-11 07:07:58 +0000 URL: https://git.openjdk.java.net/loom/commit/91bb0d658bce010e74b248b56f0fa5b8a79e8802 8276796: gc/TestSystemGC.java large pages subtest fails with ZGC Reviewed-by: pliden, stefank ! test/hotspot/jtreg/gc/TestSystemGC.java Changeset: 7a140af2 Author: Christian Hagedorn Date: 2021-11-11 08:03:01 +0000 URL: https://git.openjdk.java.net/loom/commit/7a140af25362556ebe86147dcd74413e0044edc0 8276546: [IR Framework] Whitelist and ignore CompileThreshold Reviewed-by: kvn, neliasso ! test/hotspot/jtreg/compiler/lib/ir_framework/TestFramework.java ! test/hotspot/jtreg/compiler/lib/ir_framework/driver/TestVMProcess.java + test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestCompileThreshold.java Changeset: 9862cd07 Author: Hannes Walln?fer Date: 2021-11-11 09:13:49 +0000 URL: https://git.openjdk.java.net/loom/commit/9862cd07c162fcc9cd5cbdd0aab564f446f9256c 8275786: New javadoc option to add script files to generated documentation Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlConfiguration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlOptions.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Head.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocPaths.java ! test/langtools/jdk/javadoc/doclet/testHelpOption/TestHelpOption.java ! test/langtools/jdk/javadoc/doclet/testOptions/TestOptions.java + test/langtools/jdk/javadoc/doclet/testOptions/additional-script-1.js + test/langtools/jdk/javadoc/doclet/testOptions/additional-script-2.js ! test/langtools/jdk/javadoc/tool/CheckManPageOptions.java Changeset: aea09677 Author: casparcwang Committer: Hui Shi Date: 2021-11-11 10:39:09 +0000 URL: https://git.openjdk.java.net/loom/commit/aea096770e74b9c0e1556467705ffdd6cf843d9d 8275854: C2: assert(stride_con != 0) failed: missed some peephole opt Co-authored-by: Roland Westrelin Reviewed-by: thartmann, roland, kvn ! src/hotspot/share/opto/ifnode.cpp + test/hotspot/jtreg/compiler/loopopts/TestLoopEndNodeEliminate.java Changeset: c29cab8a Author: Tobias Hartmann Date: 2021-11-11 13:09:05 +0000 URL: https://git.openjdk.java.net/loom/commit/c29cab8ab475055e02e4300f212907ff2db955ab 8276112: Inconsistent scalar replacement debug info at safepoints Reviewed-by: kvn, chagedorn ! src/hotspot/share/opto/callGenerator.cpp ! src/hotspot/share/opto/macro.hpp ! test/hotspot/jtreg/compiler/eliminateAutobox/TestIdentityWithEliminateBoxInDebugInfo.java + test/hotspot/jtreg/compiler/eliminateAutobox/TestSafepointDebugInfo.java Changeset: 2ca4ff87 Author: Aleksei Efimov Date: 2021-11-11 14:33:58 +0000 URL: https://git.openjdk.java.net/loom/commit/2ca4ff87b7c31d56542bbdcea70e828be33f4e97 8244202: Implementation of JEP 418: Internet-Address Resolution SPI Co-authored-by: Chris Hegarty Co-authored-by: Daniel Fuchs Co-authored-by: Alan Bateman Reviewed-by: dfuchs, alanb, michaelm, chegar ! src/java.base/share/classes/java/lang/RuntimePermission.java ! src/java.base/share/classes/java/net/Inet4AddressImpl.java ! src/java.base/share/classes/java/net/Inet6AddressImpl.java ! src/java.base/share/classes/java/net/InetAddress.java ! src/java.base/share/classes/java/net/InetAddressImpl.java ! src/java.base/share/classes/java/net/doc-files/net-properties.html + src/java.base/share/classes/java/net/spi/InetAddressResolver.java + src/java.base/share/classes/java/net/spi/InetAddressResolverProvider.java ! src/java.base/share/classes/java/net/spi/package-info.java ! src/java.base/share/classes/jdk/internal/access/JavaNetInetAddressAccess.java ! src/java.base/share/classes/module-info.java + src/java.base/share/classes/sun/net/ResolverProviderConfiguration.java ! src/java.base/share/native/libnet/InetAddress.c ! src/java.base/share/native/libnet/net_util.c ! src/java.base/share/native/libnet/net_util.h ! src/java.base/unix/native/libnet/Inet4AddressImpl.c ! src/java.base/unix/native/libnet/Inet6AddressImpl.c ! src/java.base/windows/native/libnet/Inet6AddressImpl.c + test/jdk/java/net/spi/InetAddressResolverProvider/AddressesCachingTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/BootstrapResolverUsageTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/BuiltInResolverTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/EmptyResultsStreamTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/ForeverCache.props + test/jdk/java/net/spi/InetAddressResolverProvider/InetAddressUsageInGetProviderTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/LookupPolicyMappingTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/LookupPolicyOfTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/NeverCache.props + test/jdk/java/net/spi/InetAddressResolverProvider/ProviderGetExceptionTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/ResolutionWithExceptionTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/ResolvePermissionTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/ReverseLookupDelegationTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/RuntimePermissionTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/addresses.txt + test/jdk/java/net/spi/InetAddressResolverProvider/lib/test.library/module-info.java + test/jdk/java/net/spi/InetAddressResolverProvider/lib/test.library/testlib/ResolutionRegistry.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/bootstrapUsage/bootstrap.usage.provider/impl/WithBootstrapResolverUsageProvider.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/bootstrapUsage/bootstrap.usage.provider/module-info.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/delegating/delegating.provider/impl/DelegatingProviderImpl.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/delegating/delegating.provider/module-info.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/empty/empty.results.provider/impl/EmptyResultsProviderImpl.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/empty/empty.results.provider/module-info.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/faulty/faulty.provider/impl/FaultyResolverProviderGetImpl.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/faulty/faulty.provider/module-info.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/recursive/recursive.init.provider/impl/InetAddressUsageInGetProviderImpl.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/recursive/recursive.init.provider/module-info.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/simple/simple.provider/impl/SimpleResolverProviderImpl.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/simple/simple.provider/module-info.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/throwing/throwing.lookups.provider/impl/ThrowingLookupsProviderImpl.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/throwing/throwing.lookups.provider/module-info.java + test/jdk/java/net/spi/InetAddressResolverProvider/serviceProviderOriginType/classpath/ClasspathProviderTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/serviceProviderOriginType/classpath/ClasspathResolverProviderImpl.java + test/jdk/java/net/spi/InetAddressResolverProvider/serviceProviderOriginType/classpath/META-INF/services/java.net.spi.InetAddressResolverProvider + test/jdk/java/net/spi/InetAddressResolverProvider/serviceProviderOriginType/classpath/addresses.txt + test/jdk/java/net/spi/InetAddressResolverProvider/serviceProviderOriginType/module/ModularProviderTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/serviceProviderOriginType/module/addresses.txt ! test/lib/jdk/test/lib/net/IPSupport.java Changeset: 5e98f993 Author: Ludvig Janiuk Committer: Alexey Ivanov Date: 2021-11-11 16:46:52 +0000 URL: https://git.openjdk.java.net/loom/commit/5e98f993b3cd68bb8564ea904f322235f55c4a7c 8276800: Fix table headers in NumericShaper.html Reviewed-by: naoto, aivanov ! src/java.desktop/share/classes/java/awt/font/NumericShaper.java Changeset: 6f35eede Author: Alexander Zvegintsev Date: 2021-11-11 16:53:27 +0000 URL: https://git.openjdk.java.net/loom/commit/6f35eede4576b6252544f553c3651312b024e7ea 8079267: [TEST_BUG] Test java/awt/Frame/MiscUndecorated/RepaintTest.java fails Reviewed-by: serb ! test/jdk/ProblemList.txt ! test/jdk/java/awt/Frame/MiscUndecorated/RepaintTest.java Changeset: 8aae88b0 Author: Alan Bateman Date: 2021-11-11 19:07:09 +0000 URL: https://git.openjdk.java.net/loom/commit/8aae88b0fc4acb76ef140f120712403cf4b04a46 8276763: java/nio/channels/SocketChannel/AdaptorStreams.java fails with "SocketTimeoutException: Read timed out" Reviewed-by: dfuchs ! test/jdk/java/nio/channels/SocketChannel/AdaptorStreams.java Changeset: b0d7a9da Author: Lance Andersen Date: 2021-11-11 19:09:17 +0000 URL: https://git.openjdk.java.net/loom/commit/b0d7a9daa6ceb1959bc701043fe3f0397d2ba6f7 8276994: java/nio/channels/Channels/TransferTo.java leaves multi-GB files in /tmp Reviewed-by: alanb ! test/jdk/java/nio/channels/Channels/TransferTo.java Changeset: 0ca0acf6 Author: Claes Redestad Date: 2021-11-11 20:36:46 +0000 URL: https://git.openjdk.java.net/loom/commit/0ca0acf63cb5cec4c62a9948956a04822d6f74a5 8276947: Clarify how DateTimeFormatterBuilder.appendFraction handles value ranges Reviewed-by: rriggs, naoto ! src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java Changeset: 3445e50b Author: David Holmes Date: 2021-11-11 22:10:18 +0000 URL: https://git.openjdk.java.net/loom/commit/3445e50bd573857660908a964886f94714315f4c 8276265: jcmd man page is outdated Reviewed-by: stuefe, cjplummer ! src/jdk.jcmd/share/man/jcmd.1 Changeset: 6954b98f Author: Evgeny Astigeevich Committer: Paul Hohensee Date: 2021-11-11 22:23:35 +0000 URL: https://git.openjdk.java.net/loom/commit/6954b98f8faf29b6c2d13687a7a94e83302bdd85 8186670: Implement _onSpinWait() intrinsic for AArch64 Reviewed-by: phh, aph ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/globals_aarch64.hpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp + src/hotspot/cpu/aarch64/spin_wait_aarch64.hpp ! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp ! src/hotspot/cpu/aarch64/vm_version_aarch64.hpp + test/hotspot/jtreg/compiler/onSpinWait/TestOnSpinWaitAArch64.java + test/hotspot/jtreg/compiler/onSpinWait/TestOnSpinWaitNoneAArch64.java + test/micro/org/openjdk/bench/java/lang/ThreadOnSpinWait.java + test/micro/org/openjdk/bench/java/lang/ThreadOnSpinWaitProducerConsumer.java + test/micro/org/openjdk/bench/java/lang/ThreadOnSpinWaitSharedCounter.java Changeset: 1e941ded Author: Andrey Turbanov Committer: Roger Riggs Date: 2021-11-11 22:26:45 +0000 URL: https://git.openjdk.java.net/loom/commit/1e941dedad0ff6282ca4c1d2d71512974c97fc5e 8275197: Remove unused fields in ThaiBuddhistChronology Reviewed-by: naoto, rriggs, iris ! src/java.base/share/classes/java/time/chrono/ThaiBuddhistChronology.java Changeset: 6b833db3 Author: Per Liden Date: 2021-11-12 08:19:03 +0000 URL: https://git.openjdk.java.net/loom/commit/6b833db3f9cace8fbb09bb803ba31208e37a4622 8275329: ZGC: vmTestbase/gc/gctests/SoftReference/soft004/soft004.java fails with assert(_phases->length() <= 1000) failed: Too many recored phases? Reviewed-by: stefank, eosterlund ! src/hotspot/share/gc/shared/gcTimer.cpp Changeset: 710f4964 Author: Nils Eliasson Date: 2021-11-12 10:08:26 +0000 URL: https://git.openjdk.java.net/loom/commit/710f496456d642c3e98d230270598f0b2dc75aba 8273277: C2: Move conditional negation into rc_predicate Reviewed-by: thartmann, chagedorn, kvn ! src/hotspot/share/opto/loopPredicate.cpp ! src/hotspot/share/opto/loopTransform.cpp ! src/hotspot/share/opto/loopnode.hpp + test/hotspot/jtreg/compiler/loopopts/TestSkeletonPredicateNegation.java ! test/hotspot/jtreg/vmTestbase/jit/t/t105/t105.java Changeset: 13deb384 Author: Julia Boes Date: 2021-11-12 12:05:45 +0000 URL: https://git.openjdk.java.net/loom/commit/13deb38433444a196af5e22e9b29bea6a9a15400 8276848: sun.net.httpserver.simpleserver.CommandLinePositiveTest: test does not specify port Reviewed-by: dfuchs + test/jdk/com/sun/net/httpserver/simpleserver/CommandLinePortNotSpecifiedTest.java ! test/jdk/com/sun/net/httpserver/simpleserver/CommandLinePositiveTest.java Changeset: c4b44329 Author: Magnus Ihse Bursie Date: 2021-11-12 14:08:43 +0000 URL: https://git.openjdk.java.net/loom/commit/c4b44329c1d250f790ca82dd419cdf3330da16f5 8277012: Use blessed modifier order in src/utils Reviewed-by: dholmes, stuefe ! src/utils/IdealGraphVisualizer/Bytecodes/src/main/java/com/sun/hotspot/igv/bytecodes/BytecodeViewTopComponent.java ! src/utils/IdealGraphVisualizer/ControlFlow/src/main/java/com/sun/hotspot/igv/controlflow/ControlFlowTopComponent.java ! src/utils/IdealGraphVisualizer/Data/src/main/java/com/sun/hotspot/igv/data/serialization/BinaryParser.java ! src/utils/IdealGraphVisualizer/FilterWindow/src/main/java/com/sun/hotspot/igv/filterwindow/FilterTopComponent.java ! src/utils/IdealGraphVisualizer/Settings/src/main/java/com/sun/hotspot/igv/settings/Settings.java ! src/utils/LogCompilation/src/main/java/com/sun/hotspot/tools/compiler/BasicLogEvent.java ! src/utils/LogCompilation/src/main/java/com/sun/hotspot/tools/compiler/LogCleanupReader.java ! src/utils/LogCompilation/src/main/java/com/sun/hotspot/tools/compiler/LogParser.java ! src/utils/src/build/tools/commentchecker/CommentChecker.java ! src/utils/src/build/tools/dirdiff/DirDiff.java Changeset: 51a5731d Author: Magnus Ihse Bursie Date: 2021-11-12 14:12:37 +0000 URL: https://git.openjdk.java.net/loom/commit/51a5731d6dc4b6f6feac920a4b8b49c15fd6b34f 8277016: Use blessed modifier order in jdk.httpserver Reviewed-by: dfuchs ! src/jdk.httpserver/share/classes/sun/net/httpserver/ChunkedInputStream.java ! src/jdk.httpserver/share/classes/sun/net/httpserver/ChunkedOutputStream.java ! src/jdk.httpserver/share/classes/sun/net/httpserver/Request.java ! src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java ! src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/SimpleFileServerImpl.java Changeset: aeba6530 Author: Andrew Leonard Date: 2021-11-12 14:43:54 +0000 URL: https://git.openjdk.java.net/loom/commit/aeba65303479130d9bab74484accad5d7d116a40 8276743: Make openjdk build Zip Archive generation "reproducible" Reviewed-by: erikj, ihse ! make/Main.gmk ! make/ToolsJdk.gmk ! make/common/ZipArchive.gmk + make/jdk/src/classes/build/tools/makezipreproducible/MakeZipReproducible.java Changeset: 3b2585c0 Author: Coleen Phillimore Date: 2021-11-12 16:17:15 +0000 URL: https://git.openjdk.java.net/loom/commit/3b2585c02bd9d66cc2c8b2d5c16e9a48f4280d07 8276658: Clean up JNI local handles code Reviewed-by: dholmes, pchilanomate ! src/hotspot/share/ci/ciInstanceKlass.cpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/compiler/compileBroker.hpp ! src/hotspot/share/gc/shared/concurrentGCThread.cpp ! src/hotspot/share/jfr/dcmd/jfrDcmds.cpp ! src/hotspot/share/jfr/jni/jfrJavaSupport.cpp ! src/hotspot/share/jvmci/jvmciCodeInstaller.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.hpp ! src/hotspot/share/prims/jni.cpp ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! src/hotspot/share/prims/jvmtiExport.cpp ! src/hotspot/share/runtime/jniHandles.cpp ! src/hotspot/share/runtime/jniHandles.hpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp ! src/hotspot/share/runtime/nonJavaThread.cpp ! src/hotspot/share/runtime/os.cpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/runtime/vmThread.cpp ! src/hotspot/share/runtime/vmThread.hpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaThread.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Thread.java Changeset: 5a2452c8 Author: Andrey Turbanov Committer: Daniel Fuchs Date: 2021-11-12 16:30:56 +0000 URL: https://git.openjdk.java.net/loom/commit/5a2452c80e64b8b7a1799caa1a8a6e9e6a7dab6d 8274835: Remove unnecessary castings in java.base Reviewed-by: mullan, naoto, lancea, bpb ! src/java.base/share/classes/java/io/SequenceInputStream.java ! src/java.base/share/classes/java/lang/ClassValue.java ! src/java.base/share/classes/java/lang/Enum.java ! src/java.base/share/classes/java/lang/StackTraceElement.java ! src/java.base/share/classes/java/security/Signature.java ! src/java.base/share/classes/java/util/GregorianCalendar.java ! src/java.base/share/classes/java/util/HashSet.java ! src/java.base/share/classes/java/util/stream/ReferencePipeline.java ! src/java.base/share/classes/sun/net/www/MimeTable.java ! src/java.base/share/classes/sun/net/www/protocol/http/AuthCacheImpl.java ! src/java.base/share/classes/sun/security/provider/DSAPublicKey.java ! src/java.base/share/classes/sun/security/provider/certpath/PKIX.java ! src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java ! src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java ! src/java.base/share/classes/sun/util/calendar/Era.java Changeset: 0d2980cd Author: Coleen Phillimore Date: 2021-11-12 17:03:33 +0000 URL: https://git.openjdk.java.net/loom/commit/0d2980cdd1486b0689a71fc107a1d4c100bd3025 8258192: Obsolete the CriticalJNINatives flag Reviewed-by: mdoerr, shade ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp ! src/hotspot/cpu/arm/sharedRuntime_arm.cpp ! src/hotspot/cpu/arm/vm_version_arm_32.cpp ! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp ! src/hotspot/cpu/s390/sharedRuntime_s390.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/cpu/zero/sharedRuntime_zero.cpp ! src/hotspot/cpu/zero/vm_version_zero.cpp ! src/hotspot/share/prims/nativeLookup.cpp ! src/hotspot/share/prims/nativeLookup.hpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp ! test/hotspot/jtreg/TEST.groups - test/hotspot/jtreg/compiler/runtime/criticalnatives/argumentcorruption/CheckLongArgs.java - test/hotspot/jtreg/compiler/runtime/criticalnatives/argumentcorruption/libCNCheckLongArgs.c - test/hotspot/jtreg/compiler/runtime/criticalnatives/lookup/LookUp.java - test/hotspot/jtreg/compiler/runtime/criticalnatives/lookup/libCNLookUp.c - test/hotspot/jtreg/gc/CriticalNative.java - test/hotspot/jtreg/gc/CriticalNativeArgs.java - test/hotspot/jtreg/gc/libCriticalNative.c - test/hotspot/jtreg/gc/stress/CriticalNativeStress.java Changeset: b85500e5 Author: Lance Andersen Date: 2021-11-12 17:12:13 +0000 URL: https://git.openjdk.java.net/loom/commit/b85500e52479c48b02a96b28fddefa2b25d5d9bd 8276123: ZipFile::getEntry will not return a file entry when there is a directory entry of the same name within a Zip File Reviewed-by: redestad, alanb ! src/java.base/share/classes/java/util/zip/ZipFile.java + test/jdk/java/util/zip/ZipFile/ZipFileDuplicateEntryTest.java Changeset: 74f3e69d Author: Daniel D. Daugherty Date: 2021-11-12 18:46:39 +0000 URL: https://git.openjdk.java.net/loom/commit/74f3e69dc888685558408e663df5d32cb906991f 8277071: [BACKOUT] JDK-8276743 Make openjdk build Zip Archive generation "reproducible" Reviewed-by: erikj ! make/Main.gmk ! make/ToolsJdk.gmk ! make/common/ZipArchive.gmk - make/jdk/src/classes/build/tools/makezipreproducible/MakeZipReproducible.java Changeset: 176d21d6 Author: Daniel D. Daugherty Date: 2021-11-12 19:06:01 +0000 URL: https://git.openjdk.java.net/loom/commit/176d21d6c525f8fd9592db5b4975308ea0001856 8276824: refactor Thread::is_JavaThread_protected Reviewed-by: coleenp, rehn, dholmes ! src/hotspot/share/runtime/handshake.cpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp Changeset: 8c5f0304 Author: Man Cao Date: 2021-11-12 22:34:10 +0000 URL: https://git.openjdk.java.net/loom/commit/8c5f03049196e66a4f8411bdd853b287134e7ce5 8276453: Undefined behavior in C1 LIR_OprDesc causes SEGV in fastdebug build Co-authored-by: Chuck Rasbold Co-authored-by: James Y Knight Reviewed-by: kvn, dlong ! src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp ! src/hotspot/cpu/aarch64/c1_FrameMap_aarch64.cpp ! src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/z/zBarrierSetAssembler_aarch64.hpp ! src/hotspot/cpu/arm/c1_CodeStubs_arm.cpp ! src/hotspot/cpu/arm/c1_FrameMap_arm.cpp ! src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp ! src/hotspot/cpu/ppc/c1_CodeStubs_ppc.cpp ! src/hotspot/cpu/ppc/c1_FrameMap_ppc.cpp ! src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp ! src/hotspot/cpu/ppc/gc/z/zBarrierSetAssembler_ppc.hpp ! src/hotspot/cpu/s390/c1_CodeStubs_s390.cpp ! src/hotspot/cpu/s390/c1_FrameMap_s390.cpp ! src/hotspot/cpu/x86/c1_CodeStubs_x86.cpp ! src/hotspot/cpu/x86/c1_FrameMap_x86.cpp ! src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp ! src/hotspot/cpu/x86/gc/z/zBarrierSetAssembler_x86.hpp ! src/hotspot/share/c1/c1_Compilation.hpp ! src/hotspot/share/c1/c1_FrameMap.hpp ! src/hotspot/share/c1/c1_Instruction.hpp ! src/hotspot/share/c1/c1_LIR.cpp ! src/hotspot/share/c1/c1_LIR.hpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/c1/c1_LIRGenerator.hpp ! src/hotspot/share/gc/g1/c1/g1BarrierSetC1.cpp ! src/hotspot/share/gc/g1/c1/g1BarrierSetC1.hpp ! src/hotspot/share/gc/shared/c1/barrierSetC1.hpp ! src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.cpp ! src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.hpp ! src/hotspot/share/gc/shared/c1/modRefBarrierSetC1.hpp Changeset: 296780c7 Author: Thomas Stuefe Date: 2021-11-15 06:47:15 +0000 URL: https://git.openjdk.java.net/loom/commit/296780c7ae5c129d24997007600f428b697d3365 8276983: Small fixes to DumpAllocStat::print_stats Reviewed-by: dholmes, iklam ! src/hotspot/share/cds/dumpAllocStats.cpp Changeset: ca2efb73 Author: Richard Reingruber Date: 2021-11-15 07:02:22 +0000 URL: https://git.openjdk.java.net/loom/commit/ca2efb73f59112d9be2ec29db405deb4c58dd435 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend Reviewed-by: cjplummer, sspitsyn, rschmelter ! src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c + test/jdk/com/sun/jdi/ResumeAfterThreadResumeCallTest.java Changeset: b231f5ba Author: Hamlin Li Date: 2021-11-15 10:08:14 +0000 URL: https://git.openjdk.java.net/loom/commit/b231f5baa94c7104324cd206c1081b35fd27164c 8276921: G1: Remove redundant failed evacuation regions calculation in RemoveSelfForwardPtrHRClosure Reviewed-by: ayang, tschatzl ! src/hotspot/share/gc/g1/g1EvacFailure.cpp ! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp Changeset: fdcd16a3 Author: Pavel Rappo Date: 2021-11-15 11:25:23 +0000 URL: https://git.openjdk.java.net/loom/commit/fdcd16a38fb9a14a819d68682f9666ebfe7285db 8277048: Tiny improvements to the specification text for java.util.Properties.load Reviewed-by: rriggs, iris, naoto ! src/java.base/share/classes/java/util/Properties.java Changeset: 02f79008 Author: Albert Mingkun Yang Date: 2021-11-15 12:46:38 +0000 URL: https://git.openjdk.java.net/loom/commit/02f79008828b3dcce3bd6492efaa43e99376c0c5 8276932: G1: Annotate methods with override explicitly in g1CollectedHeap.hpp Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp Changeset: 35a831d5 Author: Thomas Schatzl Date: 2021-11-15 14:34:19 +0000 URL: https://git.openjdk.java.net/loom/commit/35a831d5a755de8f3c71653bd0a37190adddb8ae 8272170: Missing memory barrier when checking active state for regions Reviewed-by: sjohanss, ayang ! src/hotspot/share/gc/g1/g1CommittedRegionMap.inline.hpp Changeset: 7fc344dc Author: Hannes Walln?fer Date: 2021-11-15 15:53:43 +0000 URL: https://git.openjdk.java.net/loom/commit/7fc344dc96008f277dacf5518b28447f3a598cde 8277028: Use service type documentation as fallback for @provides Reviewed-by: prappo ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java ! test/langtools/jdk/javadoc/doclet/testModules/TestModuleServices.java Changeset: 9046077f Author: Alexey Semenyuk Date: 2021-11-15 17:57:06 +0000 URL: https://git.openjdk.java.net/loom/commit/9046077fe6ce7bb042fbd0fa1a80537cb4a60581 8276084: Linux DEB Bundler: release number in outputted .deb file should be optional Reviewed-by: almatvee, herrick ! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxDebBundler.java ! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxPackageBundler.java ! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxRpmBundler.java ! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/resources/template.control ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/LinuxHelper.java ! test/jdk/tools/jpackage/linux/LinuxResourceTest.java ! test/jdk/tools/jpackage/linux/ReleaseTest.java Changeset: fe45835f Author: Alexey Semenyuk Date: 2021-11-15 17:57:58 +0000 URL: https://git.openjdk.java.net/loom/commit/fe45835f7cebfccd4544ae19d88bdc7f07560fbe 8274856: Failing jpackage tests with fastdebug/release build Reviewed-by: almatvee, herrick ! src/jdk.jpackage/linux/native/applauncher/LinuxLauncher.c ! src/jdk.jpackage/linux/native/libapplauncher/LinuxLauncherLib.cpp ! src/jdk.jpackage/share/native/applauncher/AppLauncher.cpp ! src/jdk.jpackage/share/native/applauncher/JvmLauncher.cpp ! src/jdk.jpackage/share/native/applauncher/JvmLauncher.h ! src/jdk.jpackage/share/native/applauncher/JvmLauncherLib.c ! src/jdk.jpackage/unix/native/common/UnixSysInfo.cpp ! src/jdk.jpackage/windows/native/applauncher/WinLauncher.cpp Changeset: 1830b8da Author: Thomas Schatzl Date: 2021-11-15 18:09:32 +0000 URL: https://git.openjdk.java.net/loom/commit/1830b8da9028af430ee4791f310b5fc9cb1ff37d 8275056: Virtualize G1CardSet containers over heap region Reviewed-by: sjohanss, ayang ! src/hotspot/share/gc/g1/g1CardSet.cpp ! src/hotspot/share/gc/g1/g1CardSet.hpp ! src/hotspot/share/gc/g1/g1CardSet.inline.hpp ! src/hotspot/share/gc/g1/g1RemSet.cpp ! src/hotspot/share/gc/g1/g1_globals.hpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegionBounds.hpp ! src/hotspot/share/gc/g1/heapRegionBounds.inline.hpp ! src/hotspot/share/gc/g1/heapRegionRemSet.cpp ! src/hotspot/share/gc/g1/heapRegionRemSet.inline.hpp ! test/hotspot/gtest/gc/g1/test_g1CardSet.cpp ! test/hotspot/jtreg/gc/arguments/TestG1HeapRegionSize.java Changeset: db0c8d52 Author: Andrey Turbanov Committer: Chris Plummer Date: 2021-11-15 19:14:17 +0000 URL: https://git.openjdk.java.net/loom/commit/db0c8d522704d2e12bce4ebeb9297b57e3789f4f 8274232: Cleanup unnecessary null comparison before instanceof check in jdk.jdi Reviewed-by: cjplummer, sspitsyn ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/Commands.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/BooleanValueImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ByteValueImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/CharValueImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ConnectorImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/DoubleValueImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/FieldImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/FloatValueImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/IntegerValueImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/LocalVariableImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/LocationImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/LongValueImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/MethodImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/MirrorImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ReferenceTypeImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ShortValueImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/StackFrameImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/TypeImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/VoidValueImpl.java Changeset: 7a870418 Author: Andrey Turbanov Committer: Chris Plummer Date: 2021-11-15 19:18:35 +0000 URL: https://git.openjdk.java.net/loom/commit/7a870418a3e8de3b290ba71cbe4ca7979ec029f9 8275385: Change nested classes in jdk.jdi to static nested classes Reviewed-by: sspitsyn, amenkov, cjplummer ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/Commands.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ConnectorImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/SDE.java Changeset: 9326eb14 Author: Dean Long Date: 2021-11-15 21:09:23 +0000 URL: https://git.openjdk.java.net/loom/commit/9326eb14617bf08e3376f854fc022e11d1ef34dd 8276095: ciReplay: replay failure due to incomplete ciMethodData information Reviewed-by: chagedorn, kvn ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciMethodData.cpp ! src/hotspot/share/ci/ciMethodData.hpp ! src/hotspot/share/ci/ciReplay.cpp ! src/hotspot/share/ci/ciReplay.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ci/ciMethodData.java ! test/hotspot/jtreg/compiler/ciReplay/TestLambdas.java Changeset: a59c9b2a Author: Paul Sandoz Date: 2021-11-15 21:48:38 +0000 URL: https://git.openjdk.java.net/loom/commit/a59c9b2ac277d6ff6be1700d91ff389f137e61ca 8271515: Integration of JEP 417: Vector API (Third Incubator) Co-authored-by: Sandhya Viswanathan Co-authored-by: Jatin Bhateja Co-authored-by: Ningsheng Jian Co-authored-by: Xiaohong Gong Co-authored-by: Eric Liu Co-authored-by: Jie Fu Co-authored-by: Vladimir Ivanov Co-authored-by: John R Rose Co-authored-by: Paul Sandoz Co-authored-by: Rado Smogura Reviewed-by: kvn, sviswanathan, ngasson ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/aarch64_sve.ad ! src/hotspot/cpu/aarch64/aarch64_sve_ad.m4 ! src/hotspot/cpu/aarch64/assembler_aarch64.hpp ! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/gc/z/zBarrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/register_aarch64.cpp ! src/hotspot/cpu/aarch64/register_aarch64.hpp ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/arm/arm.ad ! src/hotspot/cpu/ppc/ppc.ad ! src/hotspot/cpu/s390/s390.ad ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/cpu/x86/assembler_x86.hpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.hpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/stubGenerator_x86_32.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/stubRoutines_x86.cpp ! src/hotspot/cpu/x86/stubRoutines_x86.hpp ! src/hotspot/cpu/x86/vm_version_x86.hpp ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/share/adlc/forms.cpp ! src/hotspot/share/adlc/formssel.cpp ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/cfgnode.cpp ! src/hotspot/share/opto/cfgnode.hpp ! src/hotspot/share/opto/chaitin.cpp ! src/hotspot/share/opto/chaitin.hpp ! src/hotspot/share/opto/classes.hpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/lcm.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/library_call.hpp ! src/hotspot/share/opto/matcher.cpp ! src/hotspot/share/opto/matcher.hpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/opto/node.hpp ! src/hotspot/share/opto/postaloc.cpp ! src/hotspot/share/opto/regmask.cpp ! src/hotspot/share/opto/type.cpp ! src/hotspot/share/opto/type.hpp ! src/hotspot/share/opto/vector.cpp ! src/hotspot/share/opto/vectorIntrinsics.cpp ! src/hotspot/share/opto/vectornode.cpp ! src/hotspot/share/opto/vectornode.hpp ! src/hotspot/share/prims/vectorSupport.cpp ! src/hotspot/share/prims/vectorSupport.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/utilities/growableArray.hpp ! src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template ! src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractMask.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMask.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-VectorBits.java.template ! src/jdk.incubator.vector/windows/native/libjsvml/globals_vectorApiSupport_windows.S.inc ! test/hotspot/gtest/aarch64/aarch64-asmtest.py ! test/hotspot/gtest/aarch64/asmtest.out.h + test/hotspot/jtreg/compiler/vectorapi/VectorMaskCastTest.java + test/hotspot/jtreg/compiler/vectorapi/VectorMaskLoadStoreTest.java + test/hotspot/jtreg/compiler/vectorapi/VectorMemoryAlias.java Changeset: bd92674b Author: Calvin Cheung Date: 2021-11-16 02:34:36 +0000 URL: https://git.openjdk.java.net/loom/commit/bd92674be563ad291990216b7cdf061c498f5dd3 8276184: Exclude lambda proxy class from the CDS archive if its caller class is excluded Reviewed-by: iklam, dholmes ! src/hotspot/share/cds/dynamicArchive.cpp ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/classfile/systemDictionaryShared.hpp ! src/hotspot/share/oops/instanceKlass.cpp ! test/hotspot/jtreg/runtime/cds/appcds/LambdaContainsOldInf.java ! test/hotspot/jtreg/runtime/cds/appcds/SignedJar.java ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/LambdaContainsOldInf.java + test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/LambdaForOldInfInBaseArchive.java + test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/OldClassInBaseArchive.java + test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/RedefineCallerClassTest.java + test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/test-classes/RedefineCallerClass.java ! test/hotspot/jtreg/runtime/cds/appcds/test-classes/Hello.java ! test/hotspot/jtreg/runtime/cds/appcds/test-classes/LambdaContainsOldInfApp.java Changeset: e4362007 Author: Aleksey Shipilev Date: 2021-11-16 07:32:34 +0000 URL: https://git.openjdk.java.net/loom/commit/e4362007da8e40c076493364df91cf85960a03e7 8008243: Zero: Implement fast bytecodes Reviewed-by: rkennke, coleenp ! src/hotspot/cpu/zero/zeroInterpreter_zero.cpp ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.hpp ! src/hotspot/share/prims/jvmtiManageCapabilities.cpp Changeset: 7719a74c Author: Thomas Stuefe Date: 2021-11-16 07:49:43 +0000 URL: https://git.openjdk.java.net/loom/commit/7719a74cec8c47fd036226b520a5fce7887386da 8277172: Remove stray comment mentioning instr_size_for_decode_klass_not_null on x64 Reviewed-by: dholmes ! src/hotspot/cpu/x86/macroAssembler_x86.cpp Changeset: 1d79cfd3 Author: Stefan Johansson Date: 2021-11-16 08:27:34 +0000 URL: https://git.openjdk.java.net/loom/commit/1d79cfd3a16a71ec1bf93a0748e806b21a717b52 8276229: Stop allowing implicit updates in G1BlockOffsetTable Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1BlockOffsetTable.cpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.hpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.inline.hpp ! src/hotspot/share/gc/g1/heapRegion.inline.hpp Changeset: b8d33a2a Author: Thomas Stuefe Date: 2021-11-16 09:49:03 +0000 URL: https://git.openjdk.java.net/loom/commit/b8d33a2a4e4ac1be322644102e8f09ce1435b4fb 8277029: JMM GetDiagnosticXXXInfo APIs should verify output array sizes Reviewed-by: dholmes, sspitsyn ! src/hotspot/share/include/jmm.h ! src/hotspot/share/services/management.cpp ! src/jdk.management/share/native/libmanagement_ext/DiagnosticCommandImpl.c Changeset: 20f3872d Author: Andrey Turbanov Committer: Serguei Spitsyn Date: 2021-11-16 11:13:24 +0000 URL: https://git.openjdk.java.net/loom/commit/20f3872d1cd6257ab9c76bb998f8dc2d07bc1724 8274261: Use enhanced-for instead of plain 'for' in jdk.jcmd Reviewed-by: sspitsyn, cjplummer ! src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java ! src/jdk.jcmd/share/classes/sun/tools/jstat/Arguments.java ! src/jdk.jcmd/share/classes/sun/tools/jstat/ColumnFormat.java ! src/jdk.jcmd/share/classes/sun/tools/jstat/OptionFormat.java ! src/jdk.jcmd/share/classes/sun/tools/jstat/Parser.java ! src/jdk.jcmd/share/classes/sun/tools/jstat/RawOutputFormatter.java Changeset: a9cb8bdb Author: Andrey Turbanov Committer: Serguei Spitsyn Date: 2021-11-16 11:14:37 +0000 URL: https://git.openjdk.java.net/loom/commit/a9cb8bdbaac7241959805c491b6d13b6e14f8966 8274168: Avoid String.compareTo == 0 to check String equality in java.management Reviewed-by: sspitsyn, dfuchs, cjplummer, dholmes ! src/java.management/share/classes/javax/management/BinaryRelQueryExp.java ! src/java.management/share/classes/javax/management/loading/MLet.java Changeset: 0bc26837 Author: Andrey Turbanov Committer: Serguei Spitsyn Date: 2021-11-16 11:15:52 +0000 URL: https://git.openjdk.java.net/loom/commit/0bc268377ed5d2dd15bdd7283a77b59ad505e2b7 8274190: Use String.equals instead of String.compareTo in jdk.internal.jvmstat Reviewed-by: cjplummer, sspitsyn ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/HostIdentifier.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/MonitoredHost.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/MonitoredVmUtil.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/VmIdentifier.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/AliasFileParser.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/PerfDataBuffer.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v1_0/PerfDataBuffer.java Changeset: 9629627e Author: Andrey Turbanov Committer: Serguei Spitsyn Date: 2021-11-16 11:17:08 +0000 URL: https://git.openjdk.java.net/loom/commit/9629627e2c8021c254517ac5463cc66723175fd9 8274163: Use String.equals instead of String.compareTo in jdk.jcmd Reviewed-by: cjplummer, amenkov, sspitsyn ! src/jdk.jcmd/share/classes/sun/tools/jps/Arguments.java ! src/jdk.jcmd/share/classes/sun/tools/jstat/Arguments.java ! src/jdk.jcmd/share/classes/sun/tools/jstat/OptionLister.java ! src/jdk.jcmd/share/classes/sun/tools/jstat/Parser.java Changeset: c06df25a Author: Andrey Turbanov Committer: Serguei Spitsyn Date: 2021-11-16 11:18:10 +0000 URL: https://git.openjdk.java.net/loom/commit/c06df25a4fb76ee65d3fa99ec0579ca4a406c345 8274662: Replace 'while' cycles with iterator with enhanced-for in jdk.hotspot.agent Reviewed-by: amenkov, cjplummer, sspitsyn ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/DeadlockDetector.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/FindInHeapPanel.java Changeset: 1c45c8a0 Author: Andrey Turbanov Committer: Serguei Spitsyn Date: 2021-11-16 11:19:01 +0000 URL: https://git.openjdk.java.net/loom/commit/1c45c8a08287e2d8d7574eaa773850b7f0b33207 8274757: Cleanup unnecessary calls to Throwable.initCause() in java.management module Reviewed-by: dfuchs, sspitsyn ! src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java ! src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnector.java ! src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectorServer.java ! src/java.management/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java ! src/java.management/share/classes/com/sun/jmx/remote/internal/ArrayNotificationBuffer.java ! src/java.management/share/classes/com/sun/jmx/remote/internal/ClientNotifForwarder.java ! src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java ! src/java.management/share/classes/com/sun/jmx/remote/security/JMXPluggableAuthenticator.java ! src/java.management/share/classes/javax/management/openmbean/OpenMBeanAttributeInfoSupport.java ! src/java.management/share/classes/javax/management/remote/JMXConnectorFactory.java Changeset: 7906eb05 Author: Hamlin Li Date: 2021-11-16 11:37:37 +0000 URL: https://git.openjdk.java.net/loom/commit/7906eb050d4675092536048e8e21334767e397e6 8277119: Add asserts in GenericTaskQueueSet methods Reviewed-by: tschatzl ! src/hotspot/share/gc/shared/taskqueue.hpp ! src/hotspot/share/gc/shared/taskqueue.inline.hpp Changeset: 9a9a157a Author: Jayathirth D V Date: 2021-11-16 13:18:56 +0000 URL: https://git.openjdk.java.net/loom/commit/9a9a157a7d45cbfb016d4427931e1d5345210f7a 8276905: Use appropriate macosx_version_minimum value while compiling metal shaders Reviewed-by: ihse, kcr, erikj, prr ! make/modules/java.desktop/lib/Awt2dLibraries.gmk Changeset: f3eb5014 Author: MeryKitty Committer: Tobias Hartmann Date: 2021-11-16 14:09:53 +0000 URL: https://git.openjdk.java.net/loom/commit/f3eb5014aa75af4463308f52f2bc6e9fcd2da36c 8276162: Optimise unsigned comparison pattern Reviewed-by: thartmann, kvn ! src/hotspot/share/opto/subnode.cpp + test/hotspot/jtreg/compiler/c2/irTests/TestUnsignedComparison.java + test/micro/org/openjdk/bench/vm/compiler/UnsignedComparison.java Changeset: d5e47d6b Author: Yasumasa Suenaga Date: 2021-11-16 14:47:42 +0000 URL: https://git.openjdk.java.net/loom/commit/d5e47d6b84514edde23a8baff8c2274e5b3ca6bb 8277089: Use system binutils to build hsdis Reviewed-by: ihse ! make/autoconf/jdk-options.m4 ! src/utils/hsdis/README ! src/utils/hsdis/hsdis.c Changeset: e5ffdf91 Author: Dean Long Date: 2021-11-16 17:25:38 +0000 URL: https://git.openjdk.java.net/loom/commit/e5ffdf9120c14b38e4c8794888d2002e2686ebfc 8276231: ciReplay: SIGSEGV when replay compiling lambdas Reviewed-by: iveresov, chagedorn ! src/hotspot/share/ci/ciReplay.cpp Changeset: b0a463fa Author: Alexander Zuev Date: 2021-11-16 19:01:53 +0000 URL: https://git.openjdk.java.net/loom/commit/b0a463fa59a1c3c554f48267525729bf89a2c5be 8169468: NoResizeEventOnDMChangeTest.java fails because FS Window didn't receive all resizes! Reviewed-by: serb ! test/jdk/ProblemList.txt ! test/jdk/java/awt/FullScreen/NoResizeEventOnDMChangeTest/NoResizeEventOnDMChangeTest.java Changeset: cddc6ce4 Author: Daniel Jelinski Committer: Xue-Lei Andrew Fan Date: 2021-11-16 20:34:15 +0000 URL: https://git.openjdk.java.net/loom/commit/cddc6ce44695cba4614c3405eb2b194d7c76489b 8275811: Incorrect instance to dispose Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/ssl/InputRecord.java ! src/java.base/share/classes/sun/security/ssl/OutputRecord.java ! src/java.base/share/classes/sun/security/ssl/SSLEngineOutputRecord.java ! src/java.base/share/classes/sun/security/ssl/SSLSocketOutputRecord.java Changeset: 8ed384cf Author: Roger Riggs Date: 2021-11-16 20:53:49 +0000 URL: https://git.openjdk.java.net/loom/commit/8ed384cfb655d97ba452033e06d18ca38e5fc9b0 8276609: Document setting property `jdk.serialFilter` to an invalid value throws `ExceptionInInitializerError` Reviewed-by: dfuchs, lancea ! src/java.base/share/classes/java/io/ObjectInputFilter.java Changeset: a77d8ddf Author: Ioi Lam Date: 2021-11-16 21:03:33 +0000 URL: https://git.openjdk.java.net/loom/commit/a77d8ddf11fba33007a4f5c0468d69de23f10f6a 8276787: Improve warning messages for -XX:+RecordDynamicDumpInfo Reviewed-by: ccheung, stuefe ! src/hotspot/share/cds/dynamicArchive.cpp ! src/hotspot/share/cds/dynamicArchive.hpp ! src/hotspot/share/memory/metaspace.cpp ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/arguments.hpp ! src/hotspot/share/runtime/java.cpp ! src/hotspot/share/runtime/thread.cpp ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/SharedArchiveFileOption.java ! test/lib/jdk/test/lib/cds/CDSTestUtils.java Changeset: 23e5117a Author: Jaikiran Pai Date: 2021-11-17 03:20:40 +0000 URL: https://git.openjdk.java.net/loom/commit/23e5117a55b3f3d0e3d26bf2d481f4ad1c99af57 8276559: (httpclient) Consider adding an HttpRequest.Builder.HEAD method to build a HEAD request. Reviewed-by: cstein, dfuchs ! src/java.net.http/share/classes/java/net/http/HttpRequest.java ! src/java.net.http/share/classes/jdk/internal/net/http/HttpRequestBuilderImpl.java ! test/jdk/java/net/httpclient/HeadTest.java ! test/jdk/java/net/httpclient/HttpRequestBuilderTest.java ! test/jdk/java/net/httpclient/HttpRequestNewBuilderTest.java ! test/jdk/java/net/httpclient/RequestBuilderTest.java Changeset: 08f65a59 Author: Fairoz Matte Committer: Jayathirth D V Date: 2021-11-17 06:13:26 +0000 URL: https://git.openjdk.java.net/loom/commit/08f65a59a7bd387974d94253ec7093524a3e92f1 8277313: Validate header failed for test/jdk/java/net/httpclient/HeadTest.java Reviewed-by: jdv ! test/jdk/java/net/httpclient/HeadTest.java Changeset: 9aa30de4 Author: Faye Gao Committer: Tobias Hartmann Date: 2021-11-17 08:19:46 +0000 URL: https://git.openjdk.java.net/loom/commit/9aa30de4bb55357ddf0900e6103062f02e85753b 8275317: AArch64: Support some type conversion vectorization in SLP Reviewed-by: thartmann, ngasson ! src/hotspot/share/opto/superword.cpp ! src/hotspot/share/opto/vectornode.cpp ! test/hotspot/jtreg/compiler/codegen/TestIntFloatVect.java ! test/hotspot/jtreg/compiler/codegen/TestLongDoubleVect.java ! test/micro/org/openjdk/bench/vm/compiler/TypeVectorOperations.java Changeset: e9934e12 Author: Albert Mingkun Yang Date: 2021-11-17 09:59:55 +0000 URL: https://git.openjdk.java.net/loom/commit/e9934e1243929514e147ecdd3cefa74168ed0500 8277221: G1: Remove methods without implementations in G1CollectedHeap Reviewed-by: tschatzl ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp Changeset: 2af9e597 Author: Kevin Walls Date: 2021-11-17 11:59:52 +0000 URL: https://git.openjdk.java.net/loom/commit/2af9e5976fdf94afc7dbe5ad7827553818057bae 8276139: TestJpsHostName.java not reliable, better to expand HostIdentifierCreate.java test Reviewed-by: jiefu, sspitsyn ! test/jdk/sun/jvmstat/monitor/HostIdentifier/HostIdentifierCreate.java ! test/jdk/sun/jvmstat/monitor/HostIdentifier/testcases - test/jdk/sun/tools/jps/TestJpsHostName.java Changeset: 9f2f46ee Author: Harold Seigel Date: 2021-11-17 14:25:17 +0000 URL: https://git.openjdk.java.net/loom/commit/9f2f46ee4576d9cd0190530949e5e50f796a6bdc 8275037: Test vmTestbase/nsk/sysdict/vm/stress/btree/btree011/btree011.java crashes with memory exhaustion on Windows Reviewed-by: coleenp ! test/hotspot/jtreg/vmTestbase/nsk/sysdict/share/GenClassesBuilder.java ! test/hotspot/jtreg/vmTestbase/nsk/sysdict/share/SysDictTest.java Changeset: 8f5a8f74 Author: Alexander Zuev Date: 2021-11-17 17:36:53 +0000 URL: https://git.openjdk.java.net/loom/commit/8f5a8f740b62c27cc244debe57aaa2975f84a694 8264293: Create implementation for NSAccessibilityMenu protocol peer 8264296: Create implementation for NSAccessibilityPopUpButton protocol peer 8264295: Create implementation for NSAccessibilityMenuItem protocol peer 8264294: Create implementation for NSAccessibilityMenuBar protocol peer Reviewed-by: pbansal, ant ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/MenuAccessibility.h + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/MenuAccessibility.m + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/MenuBarAccessibility.h + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/MenuBarAccessibility.m + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/MenuItemAccessibility.h + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/MenuItemAccessibility.m Changeset: b6876649 Author: Alex Kasko Committer: Zhengyu Gu Date: 2021-11-17 17:48:07 +0000 URL: https://git.openjdk.java.net/loom/commit/b6876649a82bed508d817ccbde1600d00937e4b2 8277159: Fix java/nio/file/FileStore/Basic.java test by ignoring /run/user/* mount points Reviewed-by: bpb, shade ! test/jdk/java/nio/file/FileStore/Basic.java Changeset: 2c309834 Author: Alan Bateman Date: 2021-11-20 16:40:18 +0000 URL: https://git.openjdk.java.net/loom/commit/2c30983476a47aabcaa923c34da2de5c11a261fa Merge with jdk-18+24 ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp ! src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/cpu/x86/assembler_x86.hpp ! src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_32.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/stubRoutines_x86.hpp ! src/hotspot/cpu/x86/vm_version_x86.hpp ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/cpu/x86/x86_32.ad ! src/hotspot/share/c1/c1_Compilation.hpp ! src/hotspot/share/c1/c1_LIR.cpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/c1/c1_LIRGenerator.hpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/jfr/jni/jfrJavaSupport.cpp ! src/hotspot/share/jvmci/jvmciCodeInstaller.cpp ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/library_call.hpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/prims/jni.cpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! src/hotspot/share/prims/jvmtiExport.cpp ! src/hotspot/share/prims/jvmtiManageCapabilities.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/arguments.hpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/handshake.cpp ! src/hotspot/share/runtime/java.cpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/java.base/share/classes/java/lang/StackTraceElement.java ! src/java.base/share/classes/java/net/InetAddress.java ! src/java.base/share/classes/module-info.java ! src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java ! src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnector.java ! src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c ! test/hotspot/jtreg/TEST.groups ! test/jdk/ProblemList.txt ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp ! src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/cpu/x86/assembler_x86.hpp ! src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_32.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/stubRoutines_x86.hpp ! src/hotspot/cpu/x86/vm_version_x86.hpp ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/cpu/x86/x86_32.ad ! src/hotspot/share/c1/c1_Compilation.hpp ! src/hotspot/share/c1/c1_LIR.cpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/c1/c1_LIRGenerator.hpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp ! src/hotspot/share/jfr/jni/jfrJavaSupport.cpp ! src/hotspot/share/jvmci/jvmciCodeInstaller.cpp ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/library_call.hpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/prims/jni.cpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! src/hotspot/share/prims/jvmtiExport.cpp ! src/hotspot/share/prims/jvmtiManageCapabilities.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/arguments.hpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/handshake.cpp ! src/hotspot/share/runtime/java.cpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/java.base/share/classes/java/lang/StackTraceElement.java ! src/java.base/share/classes/java/net/InetAddress.java ! src/java.base/share/classes/module-info.java ! src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java ! src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnector.java ! src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c ! test/hotspot/jtreg/TEST.groups ! test/jdk/ProblemList.txt From duke at openjdk.java.net Sat Nov 20 19:01:48 2021 From: duke at openjdk.java.net (duke) Date: Sat, 20 Nov 2021 19:01:48 GMT Subject: git: openjdk/loom: master: 85 new changesets Message-ID: <35eac7ee-914a-4d53-a8a8-3758453c06e6@openjdk.java.net> Changeset: a0b84453 Author: Aleksey Shipilev Date: 2021-11-10 11:27:13 +0000 URL: https://git.openjdk.java.net/loom/commit/a0b84453b087ff368a32b93729c5b30fda22ed48 8276846: JDK-8273416 is incomplete for UseSSE=1 Reviewed-by: neliasso, kvn ! src/hotspot/cpu/x86/x86_32.ad Changeset: 0f23c6a9 Author: Sergey Tsypanov Committer: Claes Redestad Date: 2021-11-10 12:46:30 +0000 URL: https://git.openjdk.java.net/loom/commit/0f23c6a9feb3657eb20ff5988a9e2ffca2108af1 8276926: Use String.valueOf() when initializing File.separator and File.pathSeparator Reviewed-by: redestad, jlaskey ! src/java.base/share/classes/java/io/File.java Changeset: 55b36c6f Author: Harold Seigel Date: 2021-11-10 13:11:16 +0000 URL: https://git.openjdk.java.net/loom/commit/55b36c6f3bb7eb066daaf41f9eba46633afedf08 8276825: hotspot/runtime/SelectionResolution test errors Reviewed-by: dholmes, shade ! test/hotspot/jtreg/runtime/SelectionResolution/classes/selectionresolution/ClassBuilder.java ! test/hotspot/jtreg/runtime/SelectionResolution/classes/selectionresolution/Clazz.java ! test/hotspot/jtreg/runtime/SelectionResolution/classes/selectionresolution/TestBuilder.java Changeset: 38ec3a16 Author: Yasumasa Suenaga Date: 2021-11-10 14:33:02 +0000 URL: https://git.openjdk.java.net/loom/commit/38ec3a16d722d740d0b2128c6f6c2d1eab7a7c08 8276672: Cannot build hsdis on WSL Co-authored-by: Magnus Ihse Bursie Co-authored-by: Yasumasa Suenaga Reviewed-by: ihse, erikj ! make/Hsdis.gmk Changeset: f561d3c1 Author: Aleksey Shipilev Date: 2021-11-10 14:41:33 +0000 URL: https://git.openjdk.java.net/loom/commit/f561d3c1942ce901fa77c907839032f76feb6998 8276864: Update boot JDKs to 17.0.1 in GHA Reviewed-by: erikj, ihse ! make/conf/test-dependencies Changeset: ce3ed65a Author: Jonathan Gibbons Date: 2021-11-10 15:24:27 +0000 URL: https://git.openjdk.java.net/loom/commit/ce3ed65ac3411a533052a8c01231f7e540803afb 8273154: Provide a JavadocTester method for non-overlapping, unordered output matching Reviewed-by: prappo ! test/langtools/jdk/javadoc/lib/javadoc/tester/JavadocTester.java + test/langtools/jdk/javadoc/testJavadocTester/TestJavadocTester.java Changeset: a5c160c7 Author: Weijun Wang Date: 2021-11-10 19:35:17 +0000 URL: https://git.openjdk.java.net/loom/commit/a5c160c711a3f66db18c75973f4efdea63332863 8267108: Alternate Subject.getSubject and doAs APIs that do not depend on Security Manager APIs Reviewed-by: mullan ! src/java.base/share/classes/javax/security/auth/Subject.java ! src/java.security.jgss/share/classes/sun/security/jgss/GSSUtil.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Context.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5InitCredential.java ! src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Util.java ! test/jdk/com/sun/security/sasl/gsskerb/AuthOnly.java ! test/jdk/com/sun/security/sasl/gsskerb/ConfSecurityLayer.java ! test/jdk/com/sun/security/sasl/gsskerb/NoSecurityLayer.java ! test/jdk/java/security/AccessController/PreserveCombiner.java + test/jdk/javax/security/auth/Subject/CurrentSubject.java ! test/jdk/javax/security/auth/Subject/DoAs.java + test/jdk/javax/security/auth/Subject/Exceptions.java + test/jdk/javax/security/auth/Subject/FromACC.java ! test/jdk/javax/security/auth/Subject/Synch.java ! test/jdk/sun/security/krb5/KrbCredSubKey.java ! test/jdk/sun/security/krb5/ServiceCredsCombination.java ! test/jdk/sun/security/krb5/auto/Context.java ! test/jdk/sun/security/krb5/auto/HttpNegotiateServer.java ! test/jdk/sun/security/krb5/auto/LongLife.java Changeset: 67c2714b Author: Coleen Phillimore Date: 2021-11-10 19:45:09 +0000 URL: https://git.openjdk.java.net/loom/commit/67c2714ba2c9658e07153a6f50391c896e4caebc 8276889: Improve compatibility discussion in instanceKlass.cpp Reviewed-by: hseigel ! src/hotspot/share/oops/instanceKlass.cpp Changeset: 2374abda Author: Alisen Chung Committer: Alexey Ivanov Date: 2021-11-10 20:08:13 +0000 URL: https://git.openjdk.java.net/loom/commit/2374abda19213d615a72c83f584ea61d5bbba4a3 8276678: Malformed Javadoc inline tags in JDK source in com/sun/beans/decoder/DocumentHandler.java Reviewed-by: serb, aivanov ! src/java.desktop/share/classes/com/sun/beans/decoder/DocumentHandler.java Changeset: df02daa6 Author: Ioi Lam Date: 2021-11-10 20:22:41 +0000 URL: https://git.openjdk.java.net/loom/commit/df02daa6f9df801a7e0b6203fd6411d8a62bb277 8269986: Remove +3 from Symbol::identity_hash() Reviewed-by: coleenp ! src/hotspot/share/oops/symbol.hpp Changeset: 0c409cac Author: Naoto Sato Date: 2021-11-10 20:52:11 +0000 URL: https://git.openjdk.java.net/loom/commit/0c409cac789f1b1d21e09a65db36bb6c72c569db 8276186: Require getAvailableLocales() methods to include Locale.ROOT Reviewed-by: prappo, smarks, iris ! src/java.base/share/classes/java/text/BreakIterator.java ! src/java.base/share/classes/java/text/Collator.java ! src/java.base/share/classes/java/text/DateFormat.java ! src/java.base/share/classes/java/text/DateFormatSymbols.java ! src/java.base/share/classes/java/text/DecimalFormatSymbols.java ! src/java.base/share/classes/java/text/NumberFormat.java ! src/java.base/share/classes/java/time/format/DecimalStyle.java ! src/java.base/share/classes/java/util/Calendar.java ! src/java.base/share/classes/java/util/Locale.java + test/jdk/java/util/Locale/RequiredAvailableLocalesTest.java Changeset: bce35ac1 Author: Naoto Sato Date: 2021-11-10 20:53:23 +0000 URL: https://git.openjdk.java.net/loom/commit/bce35ac1d6c4115148468a3240ad459074e0b79e 8276775: ZonedDateTime/OffsetDateTime.toString return invalid ISO-8601 for years <= 1893 Reviewed-by: lancea, iris, bpb, scolebourne, rriggs ! src/java.base/share/classes/java/time/OffsetDateTime.java ! src/java.base/share/classes/java/time/ZonedDateTime.java Changeset: 73e6d7d7 Author: Zhengyu Gu Date: 2021-11-11 00:14:52 +0000 URL: https://git.openjdk.java.net/loom/commit/73e6d7d74d2ddd27f11775944c6fc4fb5268106d 8276801: gc/stress/CriticalNativeStress.java fails intermittently with Shenandoah Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp ! src/hotspot/share/gc/shenandoah/shenandoahNMethod.cpp Changeset: e27a67a9 Author: Jesper Wilhelmsson Date: 2021-11-11 01:14:30 +0000 URL: https://git.openjdk.java.net/loom/commit/e27a67a91647e584411a9ef57c0a028ab37af19b 8276930: Update ProblemList Reviewed-by: kevinw, dholmes ! test/jdk/ProblemList.txt Changeset: ad3be04d Author: Yoshiki Sato Committer: Naoto Sato Date: 2021-11-11 01:39:06 +0000 URL: https://git.openjdk.java.net/loom/commit/ad3be04d2ac84836e393d696ff03ddfe72779094 8276536: Update TimeZoneNames files to follow the changes made by JDK-8275766 Reviewed-by: naoto, coffeys ! src/java.base/share/classes/sun/util/resources/TimeZoneNames.java ! src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_de.java ! src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_es.java ! src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_fr.java ! src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_it.java ! src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_ja.java ! src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_ko.java ! src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_pt_BR.java ! src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_sv.java ! src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_zh_CN.java ! src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_zh_TW.java Changeset: 08e0fd67 Author: Hamlin Li Date: 2021-11-11 05:52:58 +0000 URL: https://git.openjdk.java.net/loom/commit/08e0fd6757ef15b71df0e86afd01211a6e48bd09 8276835: G1: make G1EvacFailureObjectsSet::record inline Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.cpp ! src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.hpp + src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.inline.hpp ! src/hotspot/share/gc/g1/heapRegion.inline.hpp Changeset: 91bb0d65 Author: Aleksey Shipilev Date: 2021-11-11 07:07:58 +0000 URL: https://git.openjdk.java.net/loom/commit/91bb0d658bce010e74b248b56f0fa5b8a79e8802 8276796: gc/TestSystemGC.java large pages subtest fails with ZGC Reviewed-by: pliden, stefank ! test/hotspot/jtreg/gc/TestSystemGC.java Changeset: 7a140af2 Author: Christian Hagedorn Date: 2021-11-11 08:03:01 +0000 URL: https://git.openjdk.java.net/loom/commit/7a140af25362556ebe86147dcd74413e0044edc0 8276546: [IR Framework] Whitelist and ignore CompileThreshold Reviewed-by: kvn, neliasso ! test/hotspot/jtreg/compiler/lib/ir_framework/TestFramework.java ! test/hotspot/jtreg/compiler/lib/ir_framework/driver/TestVMProcess.java + test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestCompileThreshold.java Changeset: 9862cd07 Author: Hannes Walln?fer Date: 2021-11-11 09:13:49 +0000 URL: https://git.openjdk.java.net/loom/commit/9862cd07c162fcc9cd5cbdd0aab564f446f9256c 8275786: New javadoc option to add script files to generated documentation Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlConfiguration.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlOptions.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Head.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocPaths.java ! test/langtools/jdk/javadoc/doclet/testHelpOption/TestHelpOption.java ! test/langtools/jdk/javadoc/doclet/testOptions/TestOptions.java + test/langtools/jdk/javadoc/doclet/testOptions/additional-script-1.js + test/langtools/jdk/javadoc/doclet/testOptions/additional-script-2.js ! test/langtools/jdk/javadoc/tool/CheckManPageOptions.java Changeset: aea09677 Author: casparcwang Committer: Hui Shi Date: 2021-11-11 10:39:09 +0000 URL: https://git.openjdk.java.net/loom/commit/aea096770e74b9c0e1556467705ffdd6cf843d9d 8275854: C2: assert(stride_con != 0) failed: missed some peephole opt Co-authored-by: Roland Westrelin Reviewed-by: thartmann, roland, kvn ! src/hotspot/share/opto/ifnode.cpp + test/hotspot/jtreg/compiler/loopopts/TestLoopEndNodeEliminate.java Changeset: c29cab8a Author: Tobias Hartmann Date: 2021-11-11 13:09:05 +0000 URL: https://git.openjdk.java.net/loom/commit/c29cab8ab475055e02e4300f212907ff2db955ab 8276112: Inconsistent scalar replacement debug info at safepoints Reviewed-by: kvn, chagedorn ! src/hotspot/share/opto/callGenerator.cpp ! src/hotspot/share/opto/macro.hpp ! test/hotspot/jtreg/compiler/eliminateAutobox/TestIdentityWithEliminateBoxInDebugInfo.java + test/hotspot/jtreg/compiler/eliminateAutobox/TestSafepointDebugInfo.java Changeset: 2ca4ff87 Author: Aleksei Efimov Date: 2021-11-11 14:33:58 +0000 URL: https://git.openjdk.java.net/loom/commit/2ca4ff87b7c31d56542bbdcea70e828be33f4e97 8244202: Implementation of JEP 418: Internet-Address Resolution SPI Co-authored-by: Chris Hegarty Co-authored-by: Daniel Fuchs Co-authored-by: Alan Bateman Reviewed-by: dfuchs, alanb, michaelm, chegar ! src/java.base/share/classes/java/lang/RuntimePermission.java ! src/java.base/share/classes/java/net/Inet4AddressImpl.java ! src/java.base/share/classes/java/net/Inet6AddressImpl.java ! src/java.base/share/classes/java/net/InetAddress.java ! src/java.base/share/classes/java/net/InetAddressImpl.java ! src/java.base/share/classes/java/net/doc-files/net-properties.html + src/java.base/share/classes/java/net/spi/InetAddressResolver.java + src/java.base/share/classes/java/net/spi/InetAddressResolverProvider.java ! src/java.base/share/classes/java/net/spi/package-info.java ! src/java.base/share/classes/jdk/internal/access/JavaNetInetAddressAccess.java ! src/java.base/share/classes/module-info.java + src/java.base/share/classes/sun/net/ResolverProviderConfiguration.java ! src/java.base/share/native/libnet/InetAddress.c ! src/java.base/share/native/libnet/net_util.c ! src/java.base/share/native/libnet/net_util.h ! src/java.base/unix/native/libnet/Inet4AddressImpl.c ! src/java.base/unix/native/libnet/Inet6AddressImpl.c ! src/java.base/windows/native/libnet/Inet6AddressImpl.c + test/jdk/java/net/spi/InetAddressResolverProvider/AddressesCachingTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/BootstrapResolverUsageTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/BuiltInResolverTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/EmptyResultsStreamTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/ForeverCache.props + test/jdk/java/net/spi/InetAddressResolverProvider/InetAddressUsageInGetProviderTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/LookupPolicyMappingTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/LookupPolicyOfTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/NeverCache.props + test/jdk/java/net/spi/InetAddressResolverProvider/ProviderGetExceptionTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/ResolutionWithExceptionTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/ResolvePermissionTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/ReverseLookupDelegationTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/RuntimePermissionTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/addresses.txt + test/jdk/java/net/spi/InetAddressResolverProvider/lib/test.library/module-info.java + test/jdk/java/net/spi/InetAddressResolverProvider/lib/test.library/testlib/ResolutionRegistry.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/bootstrapUsage/bootstrap.usage.provider/impl/WithBootstrapResolverUsageProvider.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/bootstrapUsage/bootstrap.usage.provider/module-info.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/delegating/delegating.provider/impl/DelegatingProviderImpl.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/delegating/delegating.provider/module-info.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/empty/empty.results.provider/impl/EmptyResultsProviderImpl.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/empty/empty.results.provider/module-info.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/faulty/faulty.provider/impl/FaultyResolverProviderGetImpl.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/faulty/faulty.provider/module-info.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/recursive/recursive.init.provider/impl/InetAddressUsageInGetProviderImpl.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/recursive/recursive.init.provider/module-info.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/simple/simple.provider/impl/SimpleResolverProviderImpl.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/simple/simple.provider/module-info.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/throwing/throwing.lookups.provider/impl/ThrowingLookupsProviderImpl.java + test/jdk/java/net/spi/InetAddressResolverProvider/providers/throwing/throwing.lookups.provider/module-info.java + test/jdk/java/net/spi/InetAddressResolverProvider/serviceProviderOriginType/classpath/ClasspathProviderTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/serviceProviderOriginType/classpath/ClasspathResolverProviderImpl.java + test/jdk/java/net/spi/InetAddressResolverProvider/serviceProviderOriginType/classpath/META-INF/services/java.net.spi.InetAddressResolverProvider + test/jdk/java/net/spi/InetAddressResolverProvider/serviceProviderOriginType/classpath/addresses.txt + test/jdk/java/net/spi/InetAddressResolverProvider/serviceProviderOriginType/module/ModularProviderTest.java + test/jdk/java/net/spi/InetAddressResolverProvider/serviceProviderOriginType/module/addresses.txt ! test/lib/jdk/test/lib/net/IPSupport.java Changeset: 5e98f993 Author: Ludvig Janiuk Committer: Alexey Ivanov Date: 2021-11-11 16:46:52 +0000 URL: https://git.openjdk.java.net/loom/commit/5e98f993b3cd68bb8564ea904f322235f55c4a7c 8276800: Fix table headers in NumericShaper.html Reviewed-by: naoto, aivanov ! src/java.desktop/share/classes/java/awt/font/NumericShaper.java Changeset: 6f35eede Author: Alexander Zvegintsev Date: 2021-11-11 16:53:27 +0000 URL: https://git.openjdk.java.net/loom/commit/6f35eede4576b6252544f553c3651312b024e7ea 8079267: [TEST_BUG] Test java/awt/Frame/MiscUndecorated/RepaintTest.java fails Reviewed-by: serb ! test/jdk/ProblemList.txt ! test/jdk/java/awt/Frame/MiscUndecorated/RepaintTest.java Changeset: 8aae88b0 Author: Alan Bateman Date: 2021-11-11 19:07:09 +0000 URL: https://git.openjdk.java.net/loom/commit/8aae88b0fc4acb76ef140f120712403cf4b04a46 8276763: java/nio/channels/SocketChannel/AdaptorStreams.java fails with "SocketTimeoutException: Read timed out" Reviewed-by: dfuchs ! test/jdk/java/nio/channels/SocketChannel/AdaptorStreams.java Changeset: b0d7a9da Author: Lance Andersen Date: 2021-11-11 19:09:17 +0000 URL: https://git.openjdk.java.net/loom/commit/b0d7a9daa6ceb1959bc701043fe3f0397d2ba6f7 8276994: java/nio/channels/Channels/TransferTo.java leaves multi-GB files in /tmp Reviewed-by: alanb ! test/jdk/java/nio/channels/Channels/TransferTo.java Changeset: 0ca0acf6 Author: Claes Redestad Date: 2021-11-11 20:36:46 +0000 URL: https://git.openjdk.java.net/loom/commit/0ca0acf63cb5cec4c62a9948956a04822d6f74a5 8276947: Clarify how DateTimeFormatterBuilder.appendFraction handles value ranges Reviewed-by: rriggs, naoto ! src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java Changeset: 3445e50b Author: David Holmes Date: 2021-11-11 22:10:18 +0000 URL: https://git.openjdk.java.net/loom/commit/3445e50bd573857660908a964886f94714315f4c 8276265: jcmd man page is outdated Reviewed-by: stuefe, cjplummer ! src/jdk.jcmd/share/man/jcmd.1 Changeset: 6954b98f Author: Evgeny Astigeevich Committer: Paul Hohensee Date: 2021-11-11 22:23:35 +0000 URL: https://git.openjdk.java.net/loom/commit/6954b98f8faf29b6c2d13687a7a94e83302bdd85 8186670: Implement _onSpinWait() intrinsic for AArch64 Reviewed-by: phh, aph ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/globals_aarch64.hpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp + src/hotspot/cpu/aarch64/spin_wait_aarch64.hpp ! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp ! src/hotspot/cpu/aarch64/vm_version_aarch64.hpp + test/hotspot/jtreg/compiler/onSpinWait/TestOnSpinWaitAArch64.java + test/hotspot/jtreg/compiler/onSpinWait/TestOnSpinWaitNoneAArch64.java + test/micro/org/openjdk/bench/java/lang/ThreadOnSpinWait.java + test/micro/org/openjdk/bench/java/lang/ThreadOnSpinWaitProducerConsumer.java + test/micro/org/openjdk/bench/java/lang/ThreadOnSpinWaitSharedCounter.java Changeset: 1e941ded Author: Andrey Turbanov Committer: Roger Riggs Date: 2021-11-11 22:26:45 +0000 URL: https://git.openjdk.java.net/loom/commit/1e941dedad0ff6282ca4c1d2d71512974c97fc5e 8275197: Remove unused fields in ThaiBuddhistChronology Reviewed-by: naoto, rriggs, iris ! src/java.base/share/classes/java/time/chrono/ThaiBuddhistChronology.java Changeset: 6b833db3 Author: Per Liden Date: 2021-11-12 08:19:03 +0000 URL: https://git.openjdk.java.net/loom/commit/6b833db3f9cace8fbb09bb803ba31208e37a4622 8275329: ZGC: vmTestbase/gc/gctests/SoftReference/soft004/soft004.java fails with assert(_phases->length() <= 1000) failed: Too many recored phases? Reviewed-by: stefank, eosterlund ! src/hotspot/share/gc/shared/gcTimer.cpp Changeset: 710f4964 Author: Nils Eliasson Date: 2021-11-12 10:08:26 +0000 URL: https://git.openjdk.java.net/loom/commit/710f496456d642c3e98d230270598f0b2dc75aba 8273277: C2: Move conditional negation into rc_predicate Reviewed-by: thartmann, chagedorn, kvn ! src/hotspot/share/opto/loopPredicate.cpp ! src/hotspot/share/opto/loopTransform.cpp ! src/hotspot/share/opto/loopnode.hpp + test/hotspot/jtreg/compiler/loopopts/TestSkeletonPredicateNegation.java ! test/hotspot/jtreg/vmTestbase/jit/t/t105/t105.java Changeset: 13deb384 Author: Julia Boes Date: 2021-11-12 12:05:45 +0000 URL: https://git.openjdk.java.net/loom/commit/13deb38433444a196af5e22e9b29bea6a9a15400 8276848: sun.net.httpserver.simpleserver.CommandLinePositiveTest: test does not specify port Reviewed-by: dfuchs + test/jdk/com/sun/net/httpserver/simpleserver/CommandLinePortNotSpecifiedTest.java ! test/jdk/com/sun/net/httpserver/simpleserver/CommandLinePositiveTest.java Changeset: c4b44329 Author: Magnus Ihse Bursie Date: 2021-11-12 14:08:43 +0000 URL: https://git.openjdk.java.net/loom/commit/c4b44329c1d250f790ca82dd419cdf3330da16f5 8277012: Use blessed modifier order in src/utils Reviewed-by: dholmes, stuefe ! src/utils/IdealGraphVisualizer/Bytecodes/src/main/java/com/sun/hotspot/igv/bytecodes/BytecodeViewTopComponent.java ! src/utils/IdealGraphVisualizer/ControlFlow/src/main/java/com/sun/hotspot/igv/controlflow/ControlFlowTopComponent.java ! src/utils/IdealGraphVisualizer/Data/src/main/java/com/sun/hotspot/igv/data/serialization/BinaryParser.java ! src/utils/IdealGraphVisualizer/FilterWindow/src/main/java/com/sun/hotspot/igv/filterwindow/FilterTopComponent.java ! src/utils/IdealGraphVisualizer/Settings/src/main/java/com/sun/hotspot/igv/settings/Settings.java ! src/utils/LogCompilation/src/main/java/com/sun/hotspot/tools/compiler/BasicLogEvent.java ! src/utils/LogCompilation/src/main/java/com/sun/hotspot/tools/compiler/LogCleanupReader.java ! src/utils/LogCompilation/src/main/java/com/sun/hotspot/tools/compiler/LogParser.java ! src/utils/src/build/tools/commentchecker/CommentChecker.java ! src/utils/src/build/tools/dirdiff/DirDiff.java Changeset: 51a5731d Author: Magnus Ihse Bursie Date: 2021-11-12 14:12:37 +0000 URL: https://git.openjdk.java.net/loom/commit/51a5731d6dc4b6f6feac920a4b8b49c15fd6b34f 8277016: Use blessed modifier order in jdk.httpserver Reviewed-by: dfuchs ! src/jdk.httpserver/share/classes/sun/net/httpserver/ChunkedInputStream.java ! src/jdk.httpserver/share/classes/sun/net/httpserver/ChunkedOutputStream.java ! src/jdk.httpserver/share/classes/sun/net/httpserver/Request.java ! src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java ! src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/SimpleFileServerImpl.java Changeset: aeba6530 Author: Andrew Leonard Date: 2021-11-12 14:43:54 +0000 URL: https://git.openjdk.java.net/loom/commit/aeba65303479130d9bab74484accad5d7d116a40 8276743: Make openjdk build Zip Archive generation "reproducible" Reviewed-by: erikj, ihse ! make/Main.gmk ! make/ToolsJdk.gmk ! make/common/ZipArchive.gmk + make/jdk/src/classes/build/tools/makezipreproducible/MakeZipReproducible.java Changeset: 3b2585c0 Author: Coleen Phillimore Date: 2021-11-12 16:17:15 +0000 URL: https://git.openjdk.java.net/loom/commit/3b2585c02bd9d66cc2c8b2d5c16e9a48f4280d07 8276658: Clean up JNI local handles code Reviewed-by: dholmes, pchilanomate ! src/hotspot/share/ci/ciInstanceKlass.cpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/compiler/compileBroker.hpp ! src/hotspot/share/gc/shared/concurrentGCThread.cpp ! src/hotspot/share/jfr/dcmd/jfrDcmds.cpp ! src/hotspot/share/jfr/jni/jfrJavaSupport.cpp ! src/hotspot/share/jvmci/jvmciCodeInstaller.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.hpp ! src/hotspot/share/prims/jni.cpp ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! src/hotspot/share/prims/jvmtiExport.cpp ! src/hotspot/share/runtime/jniHandles.cpp ! src/hotspot/share/runtime/jniHandles.hpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp ! src/hotspot/share/runtime/nonJavaThread.cpp ! src/hotspot/share/runtime/os.cpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/runtime/vmThread.cpp ! src/hotspot/share/runtime/vmThread.hpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaThread.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Thread.java Changeset: 5a2452c8 Author: Andrey Turbanov Committer: Daniel Fuchs Date: 2021-11-12 16:30:56 +0000 URL: https://git.openjdk.java.net/loom/commit/5a2452c80e64b8b7a1799caa1a8a6e9e6a7dab6d 8274835: Remove unnecessary castings in java.base Reviewed-by: mullan, naoto, lancea, bpb ! src/java.base/share/classes/java/io/SequenceInputStream.java ! src/java.base/share/classes/java/lang/ClassValue.java ! src/java.base/share/classes/java/lang/Enum.java ! src/java.base/share/classes/java/lang/StackTraceElement.java ! src/java.base/share/classes/java/security/Signature.java ! src/java.base/share/classes/java/util/GregorianCalendar.java ! src/java.base/share/classes/java/util/HashSet.java ! src/java.base/share/classes/java/util/stream/ReferencePipeline.java ! src/java.base/share/classes/sun/net/www/MimeTable.java ! src/java.base/share/classes/sun/net/www/protocol/http/AuthCacheImpl.java ! src/java.base/share/classes/sun/security/provider/DSAPublicKey.java ! src/java.base/share/classes/sun/security/provider/certpath/PKIX.java ! src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java ! src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java ! src/java.base/share/classes/sun/util/calendar/Era.java Changeset: 0d2980cd Author: Coleen Phillimore Date: 2021-11-12 17:03:33 +0000 URL: https://git.openjdk.java.net/loom/commit/0d2980cdd1486b0689a71fc107a1d4c100bd3025 8258192: Obsolete the CriticalJNINatives flag Reviewed-by: mdoerr, shade ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp ! src/hotspot/cpu/arm/sharedRuntime_arm.cpp ! src/hotspot/cpu/arm/vm_version_arm_32.cpp ! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp ! src/hotspot/cpu/s390/sharedRuntime_s390.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/cpu/zero/sharedRuntime_zero.cpp ! src/hotspot/cpu/zero/vm_version_zero.cpp ! src/hotspot/share/prims/nativeLookup.cpp ! src/hotspot/share/prims/nativeLookup.hpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp ! test/hotspot/jtreg/TEST.groups - test/hotspot/jtreg/compiler/runtime/criticalnatives/argumentcorruption/CheckLongArgs.java - test/hotspot/jtreg/compiler/runtime/criticalnatives/argumentcorruption/libCNCheckLongArgs.c - test/hotspot/jtreg/compiler/runtime/criticalnatives/lookup/LookUp.java - test/hotspot/jtreg/compiler/runtime/criticalnatives/lookup/libCNLookUp.c - test/hotspot/jtreg/gc/CriticalNative.java - test/hotspot/jtreg/gc/CriticalNativeArgs.java - test/hotspot/jtreg/gc/libCriticalNative.c - test/hotspot/jtreg/gc/stress/CriticalNativeStress.java Changeset: b85500e5 Author: Lance Andersen Date: 2021-11-12 17:12:13 +0000 URL: https://git.openjdk.java.net/loom/commit/b85500e52479c48b02a96b28fddefa2b25d5d9bd 8276123: ZipFile::getEntry will not return a file entry when there is a directory entry of the same name within a Zip File Reviewed-by: redestad, alanb ! src/java.base/share/classes/java/util/zip/ZipFile.java + test/jdk/java/util/zip/ZipFile/ZipFileDuplicateEntryTest.java Changeset: 74f3e69d Author: Daniel D. Daugherty Date: 2021-11-12 18:46:39 +0000 URL: https://git.openjdk.java.net/loom/commit/74f3e69dc888685558408e663df5d32cb906991f 8277071: [BACKOUT] JDK-8276743 Make openjdk build Zip Archive generation "reproducible" Reviewed-by: erikj ! make/Main.gmk ! make/ToolsJdk.gmk ! make/common/ZipArchive.gmk - make/jdk/src/classes/build/tools/makezipreproducible/MakeZipReproducible.java Changeset: 176d21d6 Author: Daniel D. Daugherty Date: 2021-11-12 19:06:01 +0000 URL: https://git.openjdk.java.net/loom/commit/176d21d6c525f8fd9592db5b4975308ea0001856 8276824: refactor Thread::is_JavaThread_protected Reviewed-by: coleenp, rehn, dholmes ! src/hotspot/share/runtime/handshake.cpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp Changeset: 8c5f0304 Author: Man Cao Date: 2021-11-12 22:34:10 +0000 URL: https://git.openjdk.java.net/loom/commit/8c5f03049196e66a4f8411bdd853b287134e7ce5 8276453: Undefined behavior in C1 LIR_OprDesc causes SEGV in fastdebug build Co-authored-by: Chuck Rasbold Co-authored-by: James Y Knight Reviewed-by: kvn, dlong ! src/hotspot/cpu/aarch64/c1_CodeStubs_aarch64.cpp ! src/hotspot/cpu/aarch64/c1_FrameMap_aarch64.cpp ! src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp ! src/hotspot/cpu/aarch64/gc/z/zBarrierSetAssembler_aarch64.hpp ! src/hotspot/cpu/arm/c1_CodeStubs_arm.cpp ! src/hotspot/cpu/arm/c1_FrameMap_arm.cpp ! src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp ! src/hotspot/cpu/ppc/c1_CodeStubs_ppc.cpp ! src/hotspot/cpu/ppc/c1_FrameMap_ppc.cpp ! src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp ! src/hotspot/cpu/ppc/gc/z/zBarrierSetAssembler_ppc.hpp ! src/hotspot/cpu/s390/c1_CodeStubs_s390.cpp ! src/hotspot/cpu/s390/c1_FrameMap_s390.cpp ! src/hotspot/cpu/x86/c1_CodeStubs_x86.cpp ! src/hotspot/cpu/x86/c1_FrameMap_x86.cpp ! src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp ! src/hotspot/cpu/x86/gc/z/zBarrierSetAssembler_x86.hpp ! src/hotspot/share/c1/c1_Compilation.hpp ! src/hotspot/share/c1/c1_FrameMap.hpp ! src/hotspot/share/c1/c1_Instruction.hpp ! src/hotspot/share/c1/c1_LIR.cpp ! src/hotspot/share/c1/c1_LIR.hpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/c1/c1_LIRGenerator.hpp ! src/hotspot/share/gc/g1/c1/g1BarrierSetC1.cpp ! src/hotspot/share/gc/g1/c1/g1BarrierSetC1.hpp ! src/hotspot/share/gc/shared/c1/barrierSetC1.hpp ! src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.cpp ! src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.hpp ! src/hotspot/share/gc/shared/c1/modRefBarrierSetC1.hpp Changeset: 296780c7 Author: Thomas Stuefe Date: 2021-11-15 06:47:15 +0000 URL: https://git.openjdk.java.net/loom/commit/296780c7ae5c129d24997007600f428b697d3365 8276983: Small fixes to DumpAllocStat::print_stats Reviewed-by: dholmes, iklam ! src/hotspot/share/cds/dumpAllocStats.cpp Changeset: ca2efb73 Author: Richard Reingruber Date: 2021-11-15 07:02:22 +0000 URL: https://git.openjdk.java.net/loom/commit/ca2efb73f59112d9be2ec29db405deb4c58dd435 8274687: JDWP deadlocks if some Java thread reaches wait in blockOnDebuggerSuspend Reviewed-by: cjplummer, sspitsyn, rschmelter ! src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c + test/jdk/com/sun/jdi/ResumeAfterThreadResumeCallTest.java Changeset: b231f5ba Author: Hamlin Li Date: 2021-11-15 10:08:14 +0000 URL: https://git.openjdk.java.net/loom/commit/b231f5baa94c7104324cd206c1081b35fd27164c 8276921: G1: Remove redundant failed evacuation regions calculation in RemoveSelfForwardPtrHRClosure Reviewed-by: ayang, tschatzl ! src/hotspot/share/gc/g1/g1EvacFailure.cpp ! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp Changeset: fdcd16a3 Author: Pavel Rappo Date: 2021-11-15 11:25:23 +0000 URL: https://git.openjdk.java.net/loom/commit/fdcd16a38fb9a14a819d68682f9666ebfe7285db 8277048: Tiny improvements to the specification text for java.util.Properties.load Reviewed-by: rriggs, iris, naoto ! src/java.base/share/classes/java/util/Properties.java Changeset: 02f79008 Author: Albert Mingkun Yang Date: 2021-11-15 12:46:38 +0000 URL: https://git.openjdk.java.net/loom/commit/02f79008828b3dcce3bd6492efaa43e99376c0c5 8276932: G1: Annotate methods with override explicitly in g1CollectedHeap.hpp Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp Changeset: 35a831d5 Author: Thomas Schatzl Date: 2021-11-15 14:34:19 +0000 URL: https://git.openjdk.java.net/loom/commit/35a831d5a755de8f3c71653bd0a37190adddb8ae 8272170: Missing memory barrier when checking active state for regions Reviewed-by: sjohanss, ayang ! src/hotspot/share/gc/g1/g1CommittedRegionMap.inline.hpp Changeset: 7fc344dc Author: Hannes Walln?fer Date: 2021-11-15 15:53:43 +0000 URL: https://git.openjdk.java.net/loom/commit/7fc344dc96008f277dacf5518b28447f3a598cde 8277028: Use service type documentation as fallback for @provides Reviewed-by: prappo ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java ! test/langtools/jdk/javadoc/doclet/testModules/TestModuleServices.java Changeset: 9046077f Author: Alexey Semenyuk Date: 2021-11-15 17:57:06 +0000 URL: https://git.openjdk.java.net/loom/commit/9046077fe6ce7bb042fbd0fa1a80537cb4a60581 8276084: Linux DEB Bundler: release number in outputted .deb file should be optional Reviewed-by: almatvee, herrick ! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxDebBundler.java ! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxPackageBundler.java ! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxRpmBundler.java ! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/resources/template.control ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/LinuxHelper.java ! test/jdk/tools/jpackage/linux/LinuxResourceTest.java ! test/jdk/tools/jpackage/linux/ReleaseTest.java Changeset: fe45835f Author: Alexey Semenyuk Date: 2021-11-15 17:57:58 +0000 URL: https://git.openjdk.java.net/loom/commit/fe45835f7cebfccd4544ae19d88bdc7f07560fbe 8274856: Failing jpackage tests with fastdebug/release build Reviewed-by: almatvee, herrick ! src/jdk.jpackage/linux/native/applauncher/LinuxLauncher.c ! src/jdk.jpackage/linux/native/libapplauncher/LinuxLauncherLib.cpp ! src/jdk.jpackage/share/native/applauncher/AppLauncher.cpp ! src/jdk.jpackage/share/native/applauncher/JvmLauncher.cpp ! src/jdk.jpackage/share/native/applauncher/JvmLauncher.h ! src/jdk.jpackage/share/native/applauncher/JvmLauncherLib.c ! src/jdk.jpackage/unix/native/common/UnixSysInfo.cpp ! src/jdk.jpackage/windows/native/applauncher/WinLauncher.cpp Changeset: 1830b8da Author: Thomas Schatzl Date: 2021-11-15 18:09:32 +0000 URL: https://git.openjdk.java.net/loom/commit/1830b8da9028af430ee4791f310b5fc9cb1ff37d 8275056: Virtualize G1CardSet containers over heap region Reviewed-by: sjohanss, ayang ! src/hotspot/share/gc/g1/g1CardSet.cpp ! src/hotspot/share/gc/g1/g1CardSet.hpp ! src/hotspot/share/gc/g1/g1CardSet.inline.hpp ! src/hotspot/share/gc/g1/g1RemSet.cpp ! src/hotspot/share/gc/g1/g1_globals.hpp ! src/hotspot/share/gc/g1/heapRegion.cpp ! src/hotspot/share/gc/g1/heapRegionBounds.hpp ! src/hotspot/share/gc/g1/heapRegionBounds.inline.hpp ! src/hotspot/share/gc/g1/heapRegionRemSet.cpp ! src/hotspot/share/gc/g1/heapRegionRemSet.inline.hpp ! test/hotspot/gtest/gc/g1/test_g1CardSet.cpp ! test/hotspot/jtreg/gc/arguments/TestG1HeapRegionSize.java Changeset: db0c8d52 Author: Andrey Turbanov Committer: Chris Plummer Date: 2021-11-15 19:14:17 +0000 URL: https://git.openjdk.java.net/loom/commit/db0c8d522704d2e12bce4ebeb9297b57e3789f4f 8274232: Cleanup unnecessary null comparison before instanceof check in jdk.jdi Reviewed-by: cjplummer, sspitsyn ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/Commands.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/BooleanValueImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ByteValueImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/CharValueImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ConnectorImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/DoubleValueImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/FieldImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/FloatValueImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/IntegerValueImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/LocalVariableImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/LocationImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/LongValueImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/MethodImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/MirrorImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ObjectReferenceImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ReferenceTypeImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ShortValueImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/StackFrameImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/TypeImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/VoidValueImpl.java Changeset: 7a870418 Author: Andrey Turbanov Committer: Chris Plummer Date: 2021-11-15 19:18:35 +0000 URL: https://git.openjdk.java.net/loom/commit/7a870418a3e8de3b290ba71cbe4ca7979ec029f9 8275385: Change nested classes in jdk.jdi to static nested classes Reviewed-by: sspitsyn, amenkov, cjplummer ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/Commands.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ConnectorImpl.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/SDE.java Changeset: 9326eb14 Author: Dean Long Date: 2021-11-15 21:09:23 +0000 URL: https://git.openjdk.java.net/loom/commit/9326eb14617bf08e3376f854fc022e11d1ef34dd 8276095: ciReplay: replay failure due to incomplete ciMethodData information Reviewed-by: chagedorn, kvn ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciMethodData.cpp ! src/hotspot/share/ci/ciMethodData.hpp ! src/hotspot/share/ci/ciReplay.cpp ! src/hotspot/share/ci/ciReplay.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ci/ciMethodData.java ! test/hotspot/jtreg/compiler/ciReplay/TestLambdas.java Changeset: a59c9b2a Author: Paul Sandoz Date: 2021-11-15 21:48:38 +0000 URL: https://git.openjdk.java.net/loom/commit/a59c9b2ac277d6ff6be1700d91ff389f137e61ca 8271515: Integration of JEP 417: Vector API (Third Incubator) Co-authored-by: Sandhya Viswanathan Co-authored-by: Jatin Bhateja Co-authored-by: Ningsheng Jian Co-authored-by: Xiaohong Gong Co-authored-by: Eric Liu Co-authored-by: Jie Fu Co-authored-by: Vladimir Ivanov Co-authored-by: John R Rose Co-authored-by: Paul Sandoz Co-authored-by: Rado Smogura Reviewed-by: kvn, sviswanathan, ngasson ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/aarch64_sve.ad ! src/hotspot/cpu/aarch64/aarch64_sve_ad.m4 ! src/hotspot/cpu/aarch64/assembler_aarch64.hpp ! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/gc/z/zBarrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/register_aarch64.cpp ! src/hotspot/cpu/aarch64/register_aarch64.hpp ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/arm/arm.ad ! src/hotspot/cpu/ppc/ppc.ad ! src/hotspot/cpu/s390/s390.ad ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/cpu/x86/assembler_x86.hpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.hpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/stubGenerator_x86_32.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/stubRoutines_x86.cpp ! src/hotspot/cpu/x86/stubRoutines_x86.hpp ! src/hotspot/cpu/x86/vm_version_x86.hpp ! src/hotspot/cpu/x86/x86.ad ! src/hotspot/share/adlc/forms.cpp ! src/hotspot/share/adlc/formssel.cpp ! src/hotspot/share/classfile/vmIntrinsics.hpp ! src/hotspot/share/opto/c2compiler.cpp ! src/hotspot/share/opto/cfgnode.cpp ! src/hotspot/share/opto/cfgnode.hpp ! src/hotspot/share/opto/chaitin.cpp ! src/hotspot/share/opto/chaitin.hpp ! src/hotspot/share/opto/classes.hpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/lcm.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/library_call.hpp ! src/hotspot/share/opto/matcher.cpp ! src/hotspot/share/opto/matcher.hpp ! src/hotspot/share/opto/memnode.cpp ! src/hotspot/share/opto/node.hpp ! src/hotspot/share/opto/postaloc.cpp ! src/hotspot/share/opto/regmask.cpp ! src/hotspot/share/opto/type.cpp ! src/hotspot/share/opto/type.hpp ! src/hotspot/share/opto/vector.cpp ! src/hotspot/share/opto/vectorIntrinsics.cpp ! src/hotspot/share/opto/vectornode.cpp ! src/hotspot/share/opto/vectornode.hpp ! src/hotspot/share/prims/vectorSupport.cpp ! src/hotspot/share/prims/vectorSupport.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/utilities/growableArray.hpp ! src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template ! src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractMask.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short128Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short256Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short512Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short64Vector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortMaxVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortVector.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMask.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-VectorBits.java.template ! src/jdk.incubator.vector/windows/native/libjsvml/globals_vectorApiSupport_windows.S.inc ! test/hotspot/gtest/aarch64/aarch64-asmtest.py ! test/hotspot/gtest/aarch64/asmtest.out.h + test/hotspot/jtreg/compiler/vectorapi/VectorMaskCastTest.java + test/hotspot/jtreg/compiler/vectorapi/VectorMaskLoadStoreTest.java + test/hotspot/jtreg/compiler/vectorapi/VectorMemoryAlias.java Changeset: bd92674b Author: Calvin Cheung Date: 2021-11-16 02:34:36 +0000 URL: https://git.openjdk.java.net/loom/commit/bd92674be563ad291990216b7cdf061c498f5dd3 8276184: Exclude lambda proxy class from the CDS archive if its caller class is excluded Reviewed-by: iklam, dholmes ! src/hotspot/share/cds/dynamicArchive.cpp ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/classfile/systemDictionaryShared.hpp ! src/hotspot/share/oops/instanceKlass.cpp ! test/hotspot/jtreg/runtime/cds/appcds/LambdaContainsOldInf.java ! test/hotspot/jtreg/runtime/cds/appcds/SignedJar.java ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/LambdaContainsOldInf.java + test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/LambdaForOldInfInBaseArchive.java + test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/OldClassInBaseArchive.java + test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/RedefineCallerClassTest.java + test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/test-classes/RedefineCallerClass.java ! test/hotspot/jtreg/runtime/cds/appcds/test-classes/Hello.java ! test/hotspot/jtreg/runtime/cds/appcds/test-classes/LambdaContainsOldInfApp.java Changeset: e4362007 Author: Aleksey Shipilev Date: 2021-11-16 07:32:34 +0000 URL: https://git.openjdk.java.net/loom/commit/e4362007da8e40c076493364df91cf85960a03e7 8008243: Zero: Implement fast bytecodes Reviewed-by: rkennke, coleenp ! src/hotspot/cpu/zero/zeroInterpreter_zero.cpp ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.hpp ! src/hotspot/share/prims/jvmtiManageCapabilities.cpp Changeset: 7719a74c Author: Thomas Stuefe Date: 2021-11-16 07:49:43 +0000 URL: https://git.openjdk.java.net/loom/commit/7719a74cec8c47fd036226b520a5fce7887386da 8277172: Remove stray comment mentioning instr_size_for_decode_klass_not_null on x64 Reviewed-by: dholmes ! src/hotspot/cpu/x86/macroAssembler_x86.cpp Changeset: 1d79cfd3 Author: Stefan Johansson Date: 2021-11-16 08:27:34 +0000 URL: https://git.openjdk.java.net/loom/commit/1d79cfd3a16a71ec1bf93a0748e806b21a717b52 8276229: Stop allowing implicit updates in G1BlockOffsetTable Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1BlockOffsetTable.cpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.hpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.inline.hpp ! src/hotspot/share/gc/g1/heapRegion.inline.hpp Changeset: b8d33a2a Author: Thomas Stuefe Date: 2021-11-16 09:49:03 +0000 URL: https://git.openjdk.java.net/loom/commit/b8d33a2a4e4ac1be322644102e8f09ce1435b4fb 8277029: JMM GetDiagnosticXXXInfo APIs should verify output array sizes Reviewed-by: dholmes, sspitsyn ! src/hotspot/share/include/jmm.h ! src/hotspot/share/services/management.cpp ! src/jdk.management/share/native/libmanagement_ext/DiagnosticCommandImpl.c Changeset: 20f3872d Author: Andrey Turbanov Committer: Serguei Spitsyn Date: 2021-11-16 11:13:24 +0000 URL: https://git.openjdk.java.net/loom/commit/20f3872d1cd6257ab9c76bb998f8dc2d07bc1724 8274261: Use enhanced-for instead of plain 'for' in jdk.jcmd Reviewed-by: sspitsyn, cjplummer ! src/jdk.jcmd/share/classes/sun/tools/jmap/JMap.java ! src/jdk.jcmd/share/classes/sun/tools/jstat/Arguments.java ! src/jdk.jcmd/share/classes/sun/tools/jstat/ColumnFormat.java ! src/jdk.jcmd/share/classes/sun/tools/jstat/OptionFormat.java ! src/jdk.jcmd/share/classes/sun/tools/jstat/Parser.java ! src/jdk.jcmd/share/classes/sun/tools/jstat/RawOutputFormatter.java Changeset: a9cb8bdb Author: Andrey Turbanov Committer: Serguei Spitsyn Date: 2021-11-16 11:14:37 +0000 URL: https://git.openjdk.java.net/loom/commit/a9cb8bdbaac7241959805c491b6d13b6e14f8966 8274168: Avoid String.compareTo == 0 to check String equality in java.management Reviewed-by: sspitsyn, dfuchs, cjplummer, dholmes ! src/java.management/share/classes/javax/management/BinaryRelQueryExp.java ! src/java.management/share/classes/javax/management/loading/MLet.java Changeset: 0bc26837 Author: Andrey Turbanov Committer: Serguei Spitsyn Date: 2021-11-16 11:15:52 +0000 URL: https://git.openjdk.java.net/loom/commit/0bc268377ed5d2dd15bdd7283a77b59ad505e2b7 8274190: Use String.equals instead of String.compareTo in jdk.internal.jvmstat Reviewed-by: cjplummer, sspitsyn ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/HostIdentifier.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/MonitoredHost.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/MonitoredVmUtil.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/monitor/VmIdentifier.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/AliasFileParser.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/protocol/file/PerfDataBuffer.java ! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v1_0/PerfDataBuffer.java Changeset: 9629627e Author: Andrey Turbanov Committer: Serguei Spitsyn Date: 2021-11-16 11:17:08 +0000 URL: https://git.openjdk.java.net/loom/commit/9629627e2c8021c254517ac5463cc66723175fd9 8274163: Use String.equals instead of String.compareTo in jdk.jcmd Reviewed-by: cjplummer, amenkov, sspitsyn ! src/jdk.jcmd/share/classes/sun/tools/jps/Arguments.java ! src/jdk.jcmd/share/classes/sun/tools/jstat/Arguments.java ! src/jdk.jcmd/share/classes/sun/tools/jstat/OptionLister.java ! src/jdk.jcmd/share/classes/sun/tools/jstat/Parser.java Changeset: c06df25a Author: Andrey Turbanov Committer: Serguei Spitsyn Date: 2021-11-16 11:18:10 +0000 URL: https://git.openjdk.java.net/loom/commit/c06df25a4fb76ee65d3fa99ec0579ca4a406c345 8274662: Replace 'while' cycles with iterator with enhanced-for in jdk.hotspot.agent Reviewed-by: amenkov, cjplummer, sspitsyn ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/DeadlockDetector.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/FindInHeapPanel.java Changeset: 1c45c8a0 Author: Andrey Turbanov Committer: Serguei Spitsyn Date: 2021-11-16 11:19:01 +0000 URL: https://git.openjdk.java.net/loom/commit/1c45c8a08287e2d8d7574eaa773850b7f0b33207 8274757: Cleanup unnecessary calls to Throwable.initCause() in java.management module Reviewed-by: dfuchs, sspitsyn ! src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java ! src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnector.java ! src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectorServer.java ! src/java.management/share/classes/com/sun/jmx/interceptor/DefaultMBeanServerInterceptor.java ! src/java.management/share/classes/com/sun/jmx/remote/internal/ArrayNotificationBuffer.java ! src/java.management/share/classes/com/sun/jmx/remote/internal/ClientNotifForwarder.java ! src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java ! src/java.management/share/classes/com/sun/jmx/remote/security/JMXPluggableAuthenticator.java ! src/java.management/share/classes/javax/management/openmbean/OpenMBeanAttributeInfoSupport.java ! src/java.management/share/classes/javax/management/remote/JMXConnectorFactory.java Changeset: 7906eb05 Author: Hamlin Li Date: 2021-11-16 11:37:37 +0000 URL: https://git.openjdk.java.net/loom/commit/7906eb050d4675092536048e8e21334767e397e6 8277119: Add asserts in GenericTaskQueueSet methods Reviewed-by: tschatzl ! src/hotspot/share/gc/shared/taskqueue.hpp ! src/hotspot/share/gc/shared/taskqueue.inline.hpp Changeset: 9a9a157a Author: Jayathirth D V Date: 2021-11-16 13:18:56 +0000 URL: https://git.openjdk.java.net/loom/commit/9a9a157a7d45cbfb016d4427931e1d5345210f7a 8276905: Use appropriate macosx_version_minimum value while compiling metal shaders Reviewed-by: ihse, kcr, erikj, prr ! make/modules/java.desktop/lib/Awt2dLibraries.gmk Changeset: f3eb5014 Author: MeryKitty Committer: Tobias Hartmann Date: 2021-11-16 14:09:53 +0000 URL: https://git.openjdk.java.net/loom/commit/f3eb5014aa75af4463308f52f2bc6e9fcd2da36c 8276162: Optimise unsigned comparison pattern Reviewed-by: thartmann, kvn ! src/hotspot/share/opto/subnode.cpp + test/hotspot/jtreg/compiler/c2/irTests/TestUnsignedComparison.java + test/micro/org/openjdk/bench/vm/compiler/UnsignedComparison.java Changeset: d5e47d6b Author: Yasumasa Suenaga Date: 2021-11-16 14:47:42 +0000 URL: https://git.openjdk.java.net/loom/commit/d5e47d6b84514edde23a8baff8c2274e5b3ca6bb 8277089: Use system binutils to build hsdis Reviewed-by: ihse ! make/autoconf/jdk-options.m4 ! src/utils/hsdis/README ! src/utils/hsdis/hsdis.c Changeset: e5ffdf91 Author: Dean Long Date: 2021-11-16 17:25:38 +0000 URL: https://git.openjdk.java.net/loom/commit/e5ffdf9120c14b38e4c8794888d2002e2686ebfc 8276231: ciReplay: SIGSEGV when replay compiling lambdas Reviewed-by: iveresov, chagedorn ! src/hotspot/share/ci/ciReplay.cpp Changeset: b0a463fa Author: Alexander Zuev Date: 2021-11-16 19:01:53 +0000 URL: https://git.openjdk.java.net/loom/commit/b0a463fa59a1c3c554f48267525729bf89a2c5be 8169468: NoResizeEventOnDMChangeTest.java fails because FS Window didn't receive all resizes! Reviewed-by: serb ! test/jdk/ProblemList.txt ! test/jdk/java/awt/FullScreen/NoResizeEventOnDMChangeTest/NoResizeEventOnDMChangeTest.java Changeset: cddc6ce4 Author: Daniel Jelinski Committer: Xue-Lei Andrew Fan Date: 2021-11-16 20:34:15 +0000 URL: https://git.openjdk.java.net/loom/commit/cddc6ce44695cba4614c3405eb2b194d7c76489b 8275811: Incorrect instance to dispose Reviewed-by: xuelei ! src/java.base/share/classes/sun/security/ssl/InputRecord.java ! src/java.base/share/classes/sun/security/ssl/OutputRecord.java ! src/java.base/share/classes/sun/security/ssl/SSLEngineOutputRecord.java ! src/java.base/share/classes/sun/security/ssl/SSLSocketOutputRecord.java Changeset: 8ed384cf Author: Roger Riggs Date: 2021-11-16 20:53:49 +0000 URL: https://git.openjdk.java.net/loom/commit/8ed384cfb655d97ba452033e06d18ca38e5fc9b0 8276609: Document setting property `jdk.serialFilter` to an invalid value throws `ExceptionInInitializerError` Reviewed-by: dfuchs, lancea ! src/java.base/share/classes/java/io/ObjectInputFilter.java Changeset: a77d8ddf Author: Ioi Lam Date: 2021-11-16 21:03:33 +0000 URL: https://git.openjdk.java.net/loom/commit/a77d8ddf11fba33007a4f5c0468d69de23f10f6a 8276787: Improve warning messages for -XX:+RecordDynamicDumpInfo Reviewed-by: ccheung, stuefe ! src/hotspot/share/cds/dynamicArchive.cpp ! src/hotspot/share/cds/dynamicArchive.hpp ! src/hotspot/share/memory/metaspace.cpp ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/arguments.hpp ! src/hotspot/share/runtime/java.cpp ! src/hotspot/share/runtime/thread.cpp ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/SharedArchiveFileOption.java ! test/lib/jdk/test/lib/cds/CDSTestUtils.java Changeset: 23e5117a Author: Jaikiran Pai Date: 2021-11-17 03:20:40 +0000 URL: https://git.openjdk.java.net/loom/commit/23e5117a55b3f3d0e3d26bf2d481f4ad1c99af57 8276559: (httpclient) Consider adding an HttpRequest.Builder.HEAD method to build a HEAD request. Reviewed-by: cstein, dfuchs ! src/java.net.http/share/classes/java/net/http/HttpRequest.java ! src/java.net.http/share/classes/jdk/internal/net/http/HttpRequestBuilderImpl.java ! test/jdk/java/net/httpclient/HeadTest.java ! test/jdk/java/net/httpclient/HttpRequestBuilderTest.java ! test/jdk/java/net/httpclient/HttpRequestNewBuilderTest.java ! test/jdk/java/net/httpclient/RequestBuilderTest.java Changeset: 08f65a59 Author: Fairoz Matte Committer: Jayathirth D V Date: 2021-11-17 06:13:26 +0000 URL: https://git.openjdk.java.net/loom/commit/08f65a59a7bd387974d94253ec7093524a3e92f1 8277313: Validate header failed for test/jdk/java/net/httpclient/HeadTest.java Reviewed-by: jdv ! test/jdk/java/net/httpclient/HeadTest.java Changeset: 9aa30de4 Author: Faye Gao Committer: Tobias Hartmann Date: 2021-11-17 08:19:46 +0000 URL: https://git.openjdk.java.net/loom/commit/9aa30de4bb55357ddf0900e6103062f02e85753b 8275317: AArch64: Support some type conversion vectorization in SLP Reviewed-by: thartmann, ngasson ! src/hotspot/share/opto/superword.cpp ! src/hotspot/share/opto/vectornode.cpp ! test/hotspot/jtreg/compiler/codegen/TestIntFloatVect.java ! test/hotspot/jtreg/compiler/codegen/TestLongDoubleVect.java ! test/micro/org/openjdk/bench/vm/compiler/TypeVectorOperations.java Changeset: e9934e12 Author: Albert Mingkun Yang Date: 2021-11-17 09:59:55 +0000 URL: https://git.openjdk.java.net/loom/commit/e9934e1243929514e147ecdd3cefa74168ed0500 8277221: G1: Remove methods without implementations in G1CollectedHeap Reviewed-by: tschatzl ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp Changeset: 2af9e597 Author: Kevin Walls Date: 2021-11-17 11:59:52 +0000 URL: https://git.openjdk.java.net/loom/commit/2af9e5976fdf94afc7dbe5ad7827553818057bae 8276139: TestJpsHostName.java not reliable, better to expand HostIdentifierCreate.java test Reviewed-by: jiefu, sspitsyn ! test/jdk/sun/jvmstat/monitor/HostIdentifier/HostIdentifierCreate.java ! test/jdk/sun/jvmstat/monitor/HostIdentifier/testcases - test/jdk/sun/tools/jps/TestJpsHostName.java Changeset: 9f2f46ee Author: Harold Seigel Date: 2021-11-17 14:25:17 +0000 URL: https://git.openjdk.java.net/loom/commit/9f2f46ee4576d9cd0190530949e5e50f796a6bdc 8275037: Test vmTestbase/nsk/sysdict/vm/stress/btree/btree011/btree011.java crashes with memory exhaustion on Windows Reviewed-by: coleenp ! test/hotspot/jtreg/vmTestbase/nsk/sysdict/share/GenClassesBuilder.java ! test/hotspot/jtreg/vmTestbase/nsk/sysdict/share/SysDictTest.java Changeset: 8f5a8f74 Author: Alexander Zuev Date: 2021-11-17 17:36:53 +0000 URL: https://git.openjdk.java.net/loom/commit/8f5a8f740b62c27cc244debe57aaa2975f84a694 8264293: Create implementation for NSAccessibilityMenu protocol peer 8264296: Create implementation for NSAccessibilityPopUpButton protocol peer 8264295: Create implementation for NSAccessibilityMenuItem protocol peer 8264294: Create implementation for NSAccessibilityMenuBar protocol peer Reviewed-by: pbansal, ant ! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m ! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/MenuAccessibility.h + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/MenuAccessibility.m + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/MenuBarAccessibility.h + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/MenuBarAccessibility.m + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/MenuItemAccessibility.h + src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/MenuItemAccessibility.m Changeset: b6876649 Author: Alex Kasko Committer: Zhengyu Gu Date: 2021-11-17 17:48:07 +0000 URL: https://git.openjdk.java.net/loom/commit/b6876649a82bed508d817ccbde1600d00937e4b2 8277159: Fix java/nio/file/FileStore/Basic.java test by ignoring /run/user/* mount points Reviewed-by: bpb, shade ! test/jdk/java/nio/file/FileStore/Basic.java From forax at univ-mlv.fr Sat Nov 20 19:14:23 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 20 Nov 2021 20:14:23 +0100 (CET) Subject: Future.resultNow() Message-ID: <36319248.3362024.1637435663298.JavaMail.zimbra@u-pem.fr> If a callable throws an exception, Future.resultNow() throws an ISE but forget to set the resulting exception as the cause of the ISE. regards, R?mi From forax at univ-mlv.fr Sat Nov 20 19:17:51 2021 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Sat, 20 Nov 2021 20:17:51 +0100 (CET) Subject: [External] : Re: Virtual threads and executor ? In-Reply-To: References: <1200540038.2654931.1637263362471.JavaMail.zimbra@u-pem.fr> <1726154913.3175687.1637346375316.JavaMail.zimbra@u-pem.fr> <9AF004AB-64CF-40C7-A225-607A47E3F0F1@oracle.com> <74931705.3269942.1637411214187.JavaMail.zimbra@u-pem.fr> Message-ID: <37933949.3362209.1637435871837.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "Alan Bateman" > To: "Remi Forax" > Cc: "loom-dev" > Sent: Samedi 20 Novembre 2021 18:31:58 > Subject: Re: [External] : Re: Virtual threads and executor ? > On 20/11/2021 12:26, forax at univ-mlv.fr wrote: >> : >> The problem with Executors.newVirtualThreadPerTaskExecutor() is that you can not >> specify an underlying executor, all the virtual threads has to run on the >> default common fork/join pool but the common F/J pool is not good in all use >> cases (you can even specify another pool when using a parallel stream), it's >> just a good default. >> >> I am all good with not having an API promising too much, but this limitation >> makes the integration of loom to existing libraries/stack unnecessary hard IMO. >> > I suspect you know this but just to say that virtual thread doesn't use > the common pool. The FJP instance for virtual threads is configured > differently, the main difference is that it is configured in async mode > (FIFO). I've seen that when i read the source but i totally forgot about it. The default F/J pool for the virtual thread is different from the common F/J pool, thanks for the remainder. > > -Alan. R?mi From oleksandr.otenko at gmail.com Sat Nov 20 20:10:59 2021 From: oleksandr.otenko at gmail.com (Alex Otenko) Date: Sat, 20 Nov 2021 20:10:59 +0000 Subject: Future.resultNow() In-Reply-To: <36319248.3362024.1637435663298.JavaMail.zimbra@u-pem.fr> References: <36319248.3362024.1637435663298.JavaMail.zimbra@u-pem.fr> Message-ID: I wouldn't expect it to contain the exact cause (why the cause, and not the cause of the cause of the cause), and expect exceptionNow to be the source of truth. Alex On Sat, 20 Nov 2021, 19:14 Remi Forax, wrote: > If a callable throws an exception, Future.resultNow() throws an ISE but > forget to set the resulting exception as the cause of the ISE. > > regards, > R?mi > From oleksandr.otenko at gmail.com Sat Nov 20 20:05:32 2021 From: oleksandr.otenko at gmail.com (Alex Otenko) Date: Sat, 20 Nov 2021 20:05:32 +0000 Subject: Future.resultNow / exceptionNow In-Reply-To: <593b0c08-6564-d92a-4344-d85ab1c2df0b@oracle.com> References: <593b0c08-6564-d92a-4344-d85ab1c2df0b@oracle.com> Message-ID: These are analogies. Now, I have executor.join, or made sure isDone is true, but still future.resultNow will throw. I don't know what a good analogy is. Maybe throwing some runtime exception after checking array index or reference is non-null. A good example with Optional is not get() without checks, but x.orElse(y) without checks. Maybe you could cure it with more documentation but it feels a bit like Queue.poll or Map.get throwing because data is not available. Alex On Sat, 20 Nov 2021, 17:41 Brian Goetz, wrote: > That would kind of defeat the purpose. If you follow the discipline of > structured concurrency, where the parent always waits for the child to > complete (StructuredExecutor offers methods and patterns for guaranteeing > this), then you will know with confidence that the future is complete, and > it is safe to just ask for the result. Throwing ISE means you made a > coding error (i.e., you forgot to wait for the children), like > dereferencing an object reference without knowing it was non-null, indexing > into an array without knowing the bounds, or calling Optional::get without > knowing the Optional holds a value. > > Catching ISE here would be like blindly wrapping every dereference with > "catch NPE", or every array access with "catch AIOOBE". > > > > On 11/20/2021 11:43 AM, Alex Otenko wrote: > > Is there a strong opinion about Future.resultNow and exceptionNow throwing > IllegalStateException? It seems there will likely be boilerplate > try-catching, as there is no safe way to inquire in what way the Future is > isDone. > > Returning Optional seems a nicer alternative. > > Alex > > > From ron.pressler at oracle.com Sat Nov 20 20:51:24 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Sat, 20 Nov 2021 20:51:24 +0000 Subject: Future.resultNow / exceptionNow In-Reply-To: References: Message-ID: <49043D82-9514-4C77-A305-EB4A8C0F8649@oracle.com> > On 20 Nov 2021, at 16:43, Alex Otenko wrote: > > Is there a strong opinion about Future.resultNow and exceptionNow throwing > IllegalStateException? It seems there will likely be boilerplate > try-catching, as there is no safe way to inquire in what way the Future is > isDone. See the new Future.state(). But in many/most cases you would?t even need it. From forax at univ-mlv.fr Sat Nov 20 21:44:16 2021 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Sat, 20 Nov 2021 22:44:16 +0100 (CET) Subject: Future.resultNow() In-Reply-To: References: <36319248.3362024.1637435663298.JavaMail.zimbra@u-pem.fr> Message-ID: <1273210445.3373193.1637444656131.JavaMail.zimbra@u-pem.fr> > From: "Alex Otenko" > To: "Remi Forax" > Cc: "loom-dev" > Sent: Samedi 20 Novembre 2021 21:10:59 > Subject: Re: Future.resultNow() > I wouldn't expect it to contain the exact cause (why the cause, and not the > cause of the cause of the cause), and expect exceptionNow to be the source of > truth. Are you afraid that people will catch the ISE to extract the exception instead of using Future.get() and catch the ExecutionException to extract the exception ? This is a valid concern, ExecutionException is checked and ISE is not, if you provide two ways to get the same thing, i believe people will go with the method that throws an unchecked exception. So perhaps, instead of using the cause field, the error message of the ISE should contain a string version of the exception like toString() does. > Alex R?mi > On Sat, 20 Nov 2021, 19:14 Remi Forax, < [ mailto:forax at univ-mlv.fr | > forax at univ-mlv.fr ] > wrote: >> If a callable throws an exception, Future.resultNow() throws an ISE but forget >> to set the resulting exception as the cause of the ISE. >> regards, >> R?mi From oleksandr.otenko at gmail.com Sat Nov 20 21:49:01 2021 From: oleksandr.otenko at gmail.com (Alex Otenko) Date: Sat, 20 Nov 2021 21:49:01 +0000 Subject: Future.resultNow() In-Reply-To: <1273210445.3373193.1637444656131.JavaMail.zimbra@u-pem.fr> References: <36319248.3362024.1637435663298.JavaMail.zimbra@u-pem.fr> <1273210445.3373193.1637444656131.JavaMail.zimbra@u-pem.fr> Message-ID: No, I am not afraid :) I just think introspecting the chain of causes is brittle - in the sense that it relies on a specific implementation wrapping the exception in a particular way. Alex On Sat, 20 Nov 2021, 21:44 , wrote: > > > ------------------------------ > > *From: *"Alex Otenko" > *To: *"Remi Forax" > *Cc: *"loom-dev" > *Sent: *Samedi 20 Novembre 2021 21:10:59 > *Subject: *Re: Future.resultNow() > > I wouldn't expect it to contain the exact cause (why the cause, and not > the cause of the cause of the cause), and expect exceptionNow to be the > source of truth. > > > Are you afraid that people will catch the ISE to extract the exception > instead of using Future.get() and catch the ExecutionException to extract > the exception ? > This is a valid concern, ExecutionException is checked and ISE is not, if > you provide two ways to get the same thing, i believe people will go with > the method that throws an unchecked exception. > > So perhaps, instead of using the cause field, the error message of the ISE > should contain a string version of the exception like toString() does. > > > Alex > > > R?mi > > > On Sat, 20 Nov 2021, 19:14 Remi Forax, wrote: > >> If a callable throws an exception, Future.resultNow() throws an ISE but >> forget to set the resulting exception as the cause of the ISE. >> >> regards, >> R?mi >> > > From forax at univ-mlv.fr Sat Nov 20 21:57:28 2021 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Sat, 20 Nov 2021 22:57:28 +0100 (CET) Subject: Future.resultNow() In-Reply-To: References: <36319248.3362024.1637435663298.JavaMail.zimbra@u-pem.fr> <1273210445.3373193.1637444656131.JavaMail.zimbra@u-pem.fr> Message-ID: <1041679072.3373554.1637445448258.JavaMail.zimbra@u-pem.fr> > From: "Alex Otenko" > To: "Remi Forax" > Cc: "loom-dev" > Sent: Samedi 20 Novembre 2021 22:49:01 > Subject: Re: Future.resultNow() > No, I am not afraid :) > I just think introspecting the chain of causes is brittle - in the sense that it > relies on a specific implementation wrapping the exception in a particular way. As Brian said, IllegalStateException is not an exception you should ever catch like NPE or AIOOBE, it's equivalent to a ReadTheFuckingManualException, it's an error raised because the developer has misunderstood how the API works, so providing the cause (maybe as an error message) helps to fix the bug. > Alex R?mi > On Sat, 20 Nov 2021, 21:44 , < [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] > > wrote: >>> From: "Alex Otenko" < [ mailto:oleksandr.otenko at gmail.com | >>> oleksandr.otenko at gmail.com ] > >>> To: "Remi Forax" < [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] > >>> Cc: "loom-dev" < [ mailto:loom-dev at openjdk.java.net | loom-dev at openjdk.java.net >>> ] > >>> Sent: Samedi 20 Novembre 2021 21:10:59 >>> Subject: Re: Future.resultNow() >>> I wouldn't expect it to contain the exact cause (why the cause, and not the >>> cause of the cause of the cause), and expect exceptionNow to be the source of >>> truth. >> Are you afraid that people will catch the ISE to extract the exception instead >> of using Future.get() and catch the ExecutionException to extract the exception >> ? >> This is a valid concern, ExecutionException is checked and ISE is not, if you >> provide two ways to get the same thing, i believe people will go with the >> method that throws an unchecked exception. >> So perhaps, instead of using the cause field, the error message of the ISE >> should contain a string version of the exception like toString() does. >>> Alex >> R?mi >>> On Sat, 20 Nov 2021, 19:14 Remi Forax, < [ mailto:forax at univ-mlv.fr | >>> forax at univ-mlv.fr ] > wrote: >>>> If a callable throws an exception, Future.resultNow() throws an ISE but forget >>>> to set the resulting exception as the cause of the ISE. >>>> regards, >>>> R?mi From oleksandr.otenko at gmail.com Sat Nov 20 23:00:06 2021 From: oleksandr.otenko at gmail.com (Alex Otenko) Date: Sat, 20 Nov 2021 23:00:06 +0000 Subject: Future.resultNow() In-Reply-To: <1041679072.3373554.1637445448258.JavaMail.zimbra@u-pem.fr> References: <36319248.3362024.1637435663298.JavaMail.zimbra@u-pem.fr> <1273210445.3373193.1637444656131.JavaMail.zimbra@u-pem.fr> <1041679072.3373554.1637445448258.JavaMail.zimbra@u-pem.fr> Message-ID: What is the bug in this case? The exception thrown by the task, the caller not checking the task is done, or that it is done with an exception? The API owners seem to disagree with me, but I don't think any of those is a bug. I polled the task - I got no result now, I moved on. Especially since a get() would already do the right thing, including throwing the exception, a non-blocking method feels like it should be more like BlockingQueue.poll compared to BlockingQueue.take. Alex On Sat, 20 Nov 2021, 21:57 , wrote: > > > ------------------------------ > > *From: *"Alex Otenko" > *To: *"Remi Forax" > *Cc: *"loom-dev" > *Sent: *Samedi 20 Novembre 2021 22:49:01 > *Subject: *Re: Future.resultNow() > > No, I am not afraid :) > > I just think introspecting the chain of causes is brittle - in the sense > that it relies on a specific implementation wrapping the exception in a > particular way. > > > As Brian said, IllegalStateException is not an exception you should ever > catch like NPE or AIOOBE, it's equivalent to a > ReadTheFuckingManualException, > it's an error raised because the developer has misunderstood how the API > works, so providing the cause (maybe as an error message) helps to fix the > bug. > > > Alex > > > R?mi > > > On Sat, 20 Nov 2021, 21:44 , wrote: > >> >> >> ------------------------------ >> >> *From: *"Alex Otenko" >> *To: *"Remi Forax" >> *Cc: *"loom-dev" >> *Sent: *Samedi 20 Novembre 2021 21:10:59 >> *Subject: *Re: Future.resultNow() >> >> I wouldn't expect it to contain the exact cause (why the cause, and not >> the cause of the cause of the cause), and expect exceptionNow to be the >> source of truth. >> >> >> Are you afraid that people will catch the ISE to extract the exception >> instead of using Future.get() and catch the ExecutionException to extract >> the exception ? >> This is a valid concern, ExecutionException is checked and ISE is not, if >> you provide two ways to get the same thing, i believe people will go with >> the method that throws an unchecked exception. >> >> So perhaps, instead of using the cause field, the error message of the >> ISE should contain a string version of the exception like toString() does. >> >> >> Alex >> >> >> R?mi >> >> >> On Sat, 20 Nov 2021, 19:14 Remi Forax, wrote: >> >>> If a callable throws an exception, Future.resultNow() throws an ISE but >>> forget to set the resulting exception as the cause of the ISE. >>> >>> regards, >>> R?mi >>> >> > From oleksandr.otenko at gmail.com Sat Nov 20 23:10:10 2021 From: oleksandr.otenko at gmail.com (Alex Otenko) Date: Sat, 20 Nov 2021 23:10:10 +0000 Subject: Future.resultNow / exceptionNow In-Reply-To: <49043D82-9514-4C77-A305-EB4A8C0F8649@oracle.com> References: <49043D82-9514-4C77-A305-EB4A8C0F8649@oracle.com> Message-ID: Ok, state... Looking at State - it seems there are three cases when resultNow will throw. That's probably ok, as there is only one to look out for. But exceptionNow will throw in two cases, which makes the check a little inconvenient. I still think it would be nice to either not throw at all, or have a isCompletedNormally/Exceptionally. Alex On Sat, 20 Nov 2021, 20:51 Ron Pressler, wrote: > > > On 20 Nov 2021, at 16:43, Alex Otenko > wrote: > > > > Is there a strong opinion about Future.resultNow and exceptionNow > throwing > > IllegalStateException? It seems there will likely be boilerplate > > try-catching, as there is no safe way to inquire in what way the Future > is > > isDone. > > > See the new Future.state(). But in many/most cases you would?t even need > it. From oleksandr.otenko at gmail.com Sat Nov 20 23:35:43 2021 From: oleksandr.otenko at gmail.com (Alex Otenko) Date: Sat, 20 Nov 2021 23:35:43 +0000 Subject: Future.resultNow() In-Reply-To: References: <36319248.3362024.1637435663298.JavaMail.zimbra@u-pem.fr> <1273210445.3373193.1637444656131.JavaMail.zimbra@u-pem.fr> <1041679072.3373554.1637445448258.JavaMail.zimbra@u-pem.fr> Message-ID: What I mean is if you checked isDone and like the throwing behaviour, why not use get()? And if resultNow is also throwing after isDone, then what's the use case for it? Alex On Sat, 20 Nov 2021, 23:00 Alex Otenko, wrote: > What is the bug in this case? The exception thrown by the task, the caller > not checking the task is done, or that it is done with an exception? > > The API owners seem to disagree with me, but I don't think any of those is > a bug. I polled the task - I got no result now, I moved on. Especially > since a get() would already do the right thing, including throwing the > exception, a non-blocking method feels like it should be more like > BlockingQueue.poll compared to BlockingQueue.take. > > Alex > > On Sat, 20 Nov 2021, 21:57 , wrote: > >> >> >> ------------------------------ >> >> *From: *"Alex Otenko" >> *To: *"Remi Forax" >> *Cc: *"loom-dev" >> *Sent: *Samedi 20 Novembre 2021 22:49:01 >> *Subject: *Re: Future.resultNow() >> >> No, I am not afraid :) >> >> I just think introspecting the chain of causes is brittle - in the sense >> that it relies on a specific implementation wrapping the exception in a >> particular way. >> >> >> As Brian said, IllegalStateException is not an exception you should ever >> catch like NPE or AIOOBE, it's equivalent to a >> ReadTheFuckingManualException, >> it's an error raised because the developer has misunderstood how the API >> works, so providing the cause (maybe as an error message) helps to fix the >> bug. >> >> >> Alex >> >> >> R?mi >> >> >> On Sat, 20 Nov 2021, 21:44 , wrote: >> >>> >>> >>> ------------------------------ >>> >>> *From: *"Alex Otenko" >>> *To: *"Remi Forax" >>> *Cc: *"loom-dev" >>> *Sent: *Samedi 20 Novembre 2021 21:10:59 >>> *Subject: *Re: Future.resultNow() >>> >>> I wouldn't expect it to contain the exact cause (why the cause, and not >>> the cause of the cause of the cause), and expect exceptionNow to be the >>> source of truth. >>> >>> >>> Are you afraid that people will catch the ISE to extract the exception >>> instead of using Future.get() and catch the ExecutionException to extract >>> the exception ? >>> This is a valid concern, ExecutionException is checked and ISE is not, >>> if you provide two ways to get the same thing, i believe people will go >>> with the method that throws an unchecked exception. >>> >>> So perhaps, instead of using the cause field, the error message of the >>> ISE should contain a string version of the exception like toString() does. >>> >>> >>> Alex >>> >>> >>> R?mi >>> >>> >>> On Sat, 20 Nov 2021, 19:14 Remi Forax, wrote: >>> >>>> If a callable throws an exception, Future.resultNow() throws an ISE but >>>> forget to set the resulting exception as the cause of the ISE. >>>> >>>> regards, >>>> R?mi >>>> >>> >> From ron.pressler at oracle.com Sun Nov 21 11:28:04 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Sun, 21 Nov 2021 11:28:04 +0000 Subject: Future.resultNow() In-Reply-To: References: <36319248.3362024.1637435663298.JavaMail.zimbra@u-pem.fr> <1273210445.3373193.1637444656131.JavaMail.zimbra@u-pem.fr> <1041679072.3373554.1637445448258.JavaMail.zimbra@u-pem.fr> Message-ID: The checked exception thrown by resultNow always indicates a bug in the program, as resultNow must only be called when the program is in a state where it is *guaranteed* not to throw: either after checking Future.state() or after StructuredExecutor.join() followed by handling exceptions with the completion handler. That is why the exception only contains enough information to indicate the source of the bug ? stating that the task threw an exception that it was cancelled ? and not any information that could be used to correctly handle it, as there is no right way to handle it. If it?s thrown, the program is wrong: it calls the method while in an incorrect state. Calling resultNow or exceptionNow asserts that you know that at this point in the program, they will not throw. Hypothetically, they could have thrown, say, an AssertionError, except IllegalStateException is already the common practice in precisely that kind of situation. In any event, in a correct program, these methods never throw (and, in general, ISEs and similar exceptions, like IllegalMonitorStateExceptions, are never thrown in correct programs). I don?t think that wrapping the underlying exception, if there is one, would be helpful in pinpointing the bug. If the ISE tells you it?s caused by an exception, you know you need to correct the program by adding code to handle exceptions or filter them. What the original exception was is irrelevant. So, to answer R?mi?s question, yes we are afraid of precisely that, that including the original exception might lead people to try handling it. ? Ron > On 20 Nov 2021, at 23:00, Alex Otenko wrote: > > What is the bug in this case? The exception thrown by the task, the caller > not checking the task is done, or that it is done with an exception? > > The API owners seem to disagree with me, but I don't think any of those is > a bug. I polled the task - I got no result now, I moved on. Especially > since a get() would already do the right thing, including throwing the > exception, a non-blocking method feels like it should be more like > BlockingQueue.poll compared to BlockingQueue.take. > > Alex > > On Sat, 20 Nov 2021, 21:57 , wrote: > >> >> >> ------------------------------ >> >> *From: *"Alex Otenko" >> *To: *"Remi Forax" >> *Cc: *"loom-dev" >> *Sent: *Samedi 20 Novembre 2021 22:49:01 >> *Subject: *Re: Future.resultNow() >> >> No, I am not afraid :) >> >> I just think introspecting the chain of causes is brittle - in the sense >> that it relies on a specific implementation wrapping the exception in a >> particular way. >> >> >> As Brian said, IllegalStateException is not an exception you should ever >> catch like NPE or AIOOBE, it's equivalent to a >> ReadTheFuckingManualException, >> it's an error raised because the developer has misunderstood how the API >> works, so providing the cause (maybe as an error message) helps to fix the >> bug. >> >> >> Alex >> >> >> R?mi >> >> >> On Sat, 20 Nov 2021, 21:44 , wrote: >> >>> >>> >>> ------------------------------ >>> >>> *From: *"Alex Otenko" >>> *To: *"Remi Forax" >>> *Cc: *"loom-dev" >>> *Sent: *Samedi 20 Novembre 2021 21:10:59 >>> *Subject: *Re: Future.resultNow() >>> >>> I wouldn't expect it to contain the exact cause (why the cause, and not >>> the cause of the cause of the cause), and expect exceptionNow to be the >>> source of truth. >>> >>> >>> Are you afraid that people will catch the ISE to extract the exception >>> instead of using Future.get() and catch the ExecutionException to extract >>> the exception ? >>> This is a valid concern, ExecutionException is checked and ISE is not, if >>> you provide two ways to get the same thing, i believe people will go with >>> the method that throws an unchecked exception. >>> >>> So perhaps, instead of using the cause field, the error message of the >>> ISE should contain a string version of the exception like toString() does. >>> >>> >>> Alex >>> >>> >>> R?mi >>> >>> >>> On Sat, 20 Nov 2021, 19:14 Remi Forax, wrote: >>> >>>> If a callable throws an exception, Future.resultNow() throws an ISE but >>>> forget to set the resulting exception as the cause of the ISE. >>>> >>>> regards, >>>> R?mi >>>> >>> >> From ron.pressler at oracle.com Sun Nov 21 11:32:53 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Sun, 21 Nov 2021 11:32:53 +0000 Subject: [External] : Re: Future.resultNow / exceptionNow In-Reply-To: References: <49043D82-9514-4C77-A305-EB4A8C0F8649@oracle.com> Message-ID: <1DA8B0C2-0700-4872-B410-D6875B6D2987@oracle.com> Perhaps it might be better to have both resultNow and exceptionNow fail in three of the four states. Some convenience methods could be added to the State enum rather than to Future. ? Ron On 20 Nov 2021, at 23:10, Alex Otenko > wrote: Ok, state... Looking at State - it seems there are three cases when resultNow will throw. That's probably ok, as there is only one to look out for. But exceptionNow will throw in two cases, which makes the check a little inconvenient. I still think it would be nice to either not throw at all, or have a isCompletedNormally/Exceptionally. Alex On Sat, 20 Nov 2021, 20:51 Ron Pressler, > wrote: > On 20 Nov 2021, at 16:43, Alex Otenko > wrote: > > Is there a strong opinion about Future.resultNow and exceptionNow throwing > IllegalStateException? It seems there will likely be boilerplate > try-catching, as there is no safe way to inquire in what way the Future is > isDone. See the new Future.state(). But in many/most cases you would?t even need it. From ron.pressler at oracle.com Sun Nov 21 11:36:30 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Sun, 21 Nov 2021 11:36:30 +0000 Subject: [External] : Re: Future.resultNow / exceptionNow In-Reply-To: <1DA8B0C2-0700-4872-B410-D6875B6D2987@oracle.com> References: <49043D82-9514-4C77-A305-EB4A8C0F8649@oracle.com> <1DA8B0C2-0700-4872-B410-D6875B6D2987@oracle.com> Message-ID: > On 21 Nov 2021, at 11:32, Ron Pressler wrote: > > Perhaps it might be better to have both resultNow and exceptionNow fail in three of the four states. > Some convenience methods could be added to the State enum rather than to Future. > > ? Ron P.S. Still, it?s best to consider whether and which such modifications/additions are to be made after identifying actual code where they would be helpful, rather than hypothesising that they might be. Fewer things are better than more things, and so adding things should be motivated by actual problems encountered. From oleksandr.otenko at gmail.com Sun Nov 21 11:54:51 2021 From: oleksandr.otenko at gmail.com (Alex Otenko) Date: Sun, 21 Nov 2021 11:54:51 +0000 Subject: [External] : Re: Future.resultNow / exceptionNow In-Reply-To: References: <49043D82-9514-4C77-A305-EB4A8C0F8649@oracle.com> <1DA8B0C2-0700-4872-B410-D6875B6D2987@oracle.com> Message-ID: Sure. You have the advantage of trying this design with a large project like JDK perhaps :) I have only a few dummy programs trying to get to edge cases. My feedback is that throwing ISA is not to my liking. I would prefer these methods to be polling in nature, not prescribing what catches are good. For example, I agree with R?mi to the extent that the cause better be mentioned somewhere on stack trace, even though I don't think we should rely on where exactly it is. The reason for this is experience in supporting cloud deployments. The program may be broken by your standards, but I would prefer to know a bit more than just that _something_ went wrong, especially since exposing that is cheap. Alex On Sun, 21 Nov 2021, 11:36 Ron Pressler, wrote: > > > > On 21 Nov 2021, at 11:32, Ron Pressler wrote: > > > > Perhaps it might be better to have both resultNow and exceptionNow fail > in three of the four states. > > Some convenience methods could be added to the State enum rather than to > Future. > > > > ? Ron > > P.S. > > Still, it?s best to consider whether and which such > modifications/additions are to be made after identifying actual code where > they would be helpful, rather than hypothesising that they might be. Fewer > things are better than more things, and so adding things should be > motivated by actual problems encountered. From ron.pressler at oracle.com Sun Nov 21 12:51:24 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Sun, 21 Nov 2021 12:51:24 +0000 Subject: [External] : Re: Future.resultNow / exceptionNow In-Reply-To: References: <49043D82-9514-4C77-A305-EB4A8C0F8649@oracle.com> <1DA8B0C2-0700-4872-B410-D6875B6D2987@oracle.com> Message-ID: <75BEEF26-1550-404F-9F20-D7D3B771706B@oracle.com> You *do* know what went wrong, because the exception tells you the actual state of the future. It essentially says, expected state X but I?m in state Y. And as to polling, you do have that: the state method. If we only had maybeResultNow that returned an Optional, that would create a problem: code that knows what the state is ? such as the very code that uses StructuredExecutor ? would have to match on the Optional unnecessarily (or call get() which would be both more cumbersome, and, if fails, would be much less informative than the situation now). I don?t, however, see the problem that you want to solve with the feature you wish to add. ? Ron On 21 Nov 2021, at 11:54, Alex Otenko > wrote: Sure. You have the advantage of trying this design with a large project like JDK perhaps :) I have only a few dummy programs trying to get to edge cases. My feedback is that throwing ISA is not to my liking. I would prefer these methods to be polling in nature, not prescribing what catches are good. For example, I agree with R?mi to the extent that the cause better be mentioned somewhere on stack trace, even though I don't think we should rely on where exactly it is. The reason for this is experience in supporting cloud deployments. The program may be broken by your standards, but I would prefer to know a bit more than just that _something_ went wrong, especially since exposing that is cheap. Alex On Sun, 21 Nov 2021, 11:36 Ron Pressler, > wrote: > On 21 Nov 2021, at 11:32, Ron Pressler > wrote: > > Perhaps it might be better to have both resultNow and exceptionNow fail in three of the four states. > Some convenience methods could be added to the State enum rather than to Future. > > ? Ron P.S. Still, it?s best to consider whether and which such modifications/additions are to be made after identifying actual code where they would be helpful, rather than hypothesising that they might be. Fewer things are better than more things, and so adding things should be motivated by actual problems encountered. From oleksandr.otenko at gmail.com Sun Nov 21 14:00:01 2021 From: oleksandr.otenko at gmail.com (Alex Otenko) Date: Sun, 21 Nov 2021 14:00:01 +0000 Subject: [External] : Re: Future.resultNow / exceptionNow In-Reply-To: <75BEEF26-1550-404F-9F20-D7D3B771706B@oracle.com> References: <49043D82-9514-4C77-A305-EB4A8C0F8649@oracle.com> <1DA8B0C2-0700-4872-B410-D6875B6D2987@oracle.com> <75BEEF26-1550-404F-9F20-D7D3B771706B@oracle.com> Message-ID: No, you don't know what went wrong. You only know something did. So, you see the code is broken. You get to deploy two patches: one to start using a different method to observe what has lead to the problem (likely a Runtime Exception or Error - say, NPE in the task), then the fix for the actual problem. As for maybeResultNow - I haven't warmed up to the idea that throwing by resultNow is saving me from a really bad problem. I am looking at the code that joined on executor, and don't see why it is more correct for (albeit indirect) state introspection to punish me with hidden throws. I am looking at another example that polls for result, and again don't see why throwing is better for something that is like a non-blocking get. Reminds me of NIO Selector API, where almost anything can result in a bunch of Runtime Exceptions. Alex On Sun, 21 Nov 2021, 12:51 Ron Pressler, wrote: > You *do* know what went wrong, because the exception tells you the actual > state of the future. It essentially says, expected state X but I?m in state > Y. And as to polling, you do have that: the state method. > > If we only had maybeResultNow that returned an Optional, that would create > a problem: code that knows what the state is ? such as the very code that > uses StructuredExecutor ? would have to match on the Optional unnecessarily > (or call get() which would be both more cumbersome, and, if fails, would be > much less informative than the situation now). I don?t, however, see the > problem that you want to solve with the feature you wish to add. > > ? Ron > > On 21 Nov 2021, at 11:54, Alex Otenko wrote: > > Sure. You have the advantage of trying this design with a large project > like JDK perhaps :) I have only a few dummy programs trying to get to edge > cases. > > My feedback is that throwing ISA is not to my liking. I would prefer these > methods to be polling in nature, not prescribing what catches are good. > > For example, I agree with R?mi to the extent that the cause better be > mentioned somewhere on stack trace, even though I don't think we should > rely on where exactly it is. The reason for this is experience in > supporting cloud deployments. The program may be broken by your standards, > but I would prefer to know a bit more than just that _something_ went > wrong, especially since exposing that is cheap. > > > Alex > > On Sun, 21 Nov 2021, 11:36 Ron Pressler, wrote: > >> >> >> > On 21 Nov 2021, at 11:32, Ron Pressler wrote: >> > >> > Perhaps it might be better to have both resultNow and exceptionNow fail >> in three of the four states. >> > Some convenience methods could be added to the State enum rather than >> to Future. >> > >> > ? Ron >> >> P.S. >> >> Still, it?s best to consider whether and which such >> modifications/additions are to be made after identifying actual code where >> they would be helpful, rather than hypothesising that they might be. Fewer >> things are better than more things, and so adding things should be >> motivated by actual problems encountered. > > > From ron.pressler at oracle.com Sun Nov 21 14:55:54 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Sun, 21 Nov 2021 14:55:54 +0000 Subject: [External] : Re: Future.resultNow / exceptionNow In-Reply-To: References: <49043D82-9514-4C77-A305-EB4A8C0F8649@oracle.com> <1DA8B0C2-0700-4872-B410-D6875B6D2987@oracle.com> <75BEEF26-1550-404F-9F20-D7D3B771706B@oracle.com> Message-ID: > On 21 Nov 2021, at 14:00, Alex Otenko wrote: > > No, you don't know what went wrong. You only know something did. The methods must only be called when the Future is in a certain state, and the exception tells you exactly what the actual, unexpected state is. You have all the information you could ever need to fix the bug. Suppose you call resultNow without having called join first. The error you?ll get will tell you exactly that this is the bug, and that adding join is necessary. And suppose you call resultNow after join but before handling exception, the error you?ll get will tell you exactly that that?s what missing. > > So, you see the code is broken. You get to deploy two patches: one to start using a different method to observe what has lead to the problem (likely a Runtime Exception or Error - say, NPE in the task), then the fix for the actual problem. The exception tells you *which* incorrect state has led to the problem (maybe the message should include precisely which State enum value is expected and which is found). > > As for maybeResultNow - I haven't warmed up to the idea that throwing by resultNow is saving me from a really bad problem. The problem that resultNow was created to solve is that in the common case, in which you already know the state of the future and have already handled exceptions, anything other than returning the result would be an unnecessary complication. Write down that code and see for yourself. > > I am looking at the code that joined on executor, and don't see why it is more correct for (albeit indirect) state introspection to punish me with hidden throws. I don?t understand. The method for state introspection, Future.state, never fails. resultNow, which is *not* for state introspection, never punishes you. It just cannot continue when a bug in your program makes its precondition false, and it helps you by telling you what your bug is. > I am looking at another example that polls for result, and again don't see why throwing is better for something that is like a non-blocking get. The purpose of resultNow is not to be a non-blocking get (although you could write a non-blocking get with a combination of state and resultNow). The purpose of resultNow is to obtain the result in the common case, in which you already know that it?s there, and are *guaranteed* that the method will never fail. > Reminds me of NIO Selector API, where almost anything can result in a bunch of Runtime Exceptions. If we could panic, maybe we?d panic. The exception is not the point. It just indicates a bug in the program. I understand that you?d like a somewhat different feature, but please start with a motivation: take the current API and show what *problem you run into* that you?d like to solve. If your problem is unrelated to the JEP but is just about a non-blocking polling mechanism for Future, I?d still argue that having both state and resultNow is superior to a single maybeGetResult, because the former is more general: you can use it just as efficiently for polling or for obtaining the result in cases where the correct state is guaranteed. ? Ron From ron.pressler at oracle.com Sun Nov 21 15:01:43 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Sun, 21 Nov 2021 15:01:43 +0000 Subject: [External] : Re: Future.resultNow / exceptionNow In-Reply-To: References: <49043D82-9514-4C77-A305-EB4A8C0F8649@oracle.com> <1DA8B0C2-0700-4872-B410-D6875B6D2987@oracle.com> <75BEEF26-1550-404F-9F20-D7D3B771706B@oracle.com> Message-ID: > On 21 Nov 2021, at 14:55, Ron Pressler wrote: > > > >> On 21 Nov 2021, at 14:00, Alex Otenko wrote: >> >> No, you don't know what went wrong. You only know something did. > > The methods must only be called when the Future is in a certain state, and the exception tells you exactly what the actual, unexpected state is. You have all the information you could ever need to fix the bug. Suppose you call resultNow without having called join first. The error you?ll get will tell you exactly that this is the bug, and that adding join is necessary. And suppose you call resultNow after join but before handling exception, the error you?ll get will tell you exactly that that?s what missing. > >> >> So, you see the code is broken. You get to deploy two patches: one to start using a different method to observe what has lead to the problem (likely a Runtime Exception or Error - say, NPE in the task), then the fix for the actual problem. > > The exception tells you *which* incorrect state has led to the problem (maybe the message should include precisely which State enum value is expected and which is found). > >> >> As for maybeResultNow - I haven't warmed up to the idea that throwing by resultNow is saving me from a really bad problem. > > The problem that resultNow was created to solve is that in the common case, in which you already know the state of the future and have already handled exceptions, anything other than returning the result would be an unnecessary complication. Write down that code and see for yourself. > >> >> I am looking at the code that joined on executor, and don't see why it is more correct for (albeit indirect) state introspection to punish me with hidden throws. > > I don?t understand. The method for state introspection, Future.state, never fails. resultNow, which is *not* for state introspection, never punishes you. It just cannot continue when a bug in your program makes its precondition false, and it helps you by telling you what your bug is. > >> I am looking at another example that polls for result, and again don't see why throwing is better for something that is like a non-blocking get. > > The purpose of resultNow is not to be a non-blocking get (although you could write a non-blocking get with a combination of state and resultNow). The purpose of resultNow is to obtain the result in the common case, in which you already know that it?s there, and are *guaranteed* that the method will never fail. > >> Reminds me of NIO Selector API, where almost anything can result in a bunch of Runtime Exceptions. > > If we could panic, maybe we?d panic. The exception is not the point. It just indicates a bug in the program. > > I understand that you?d like a somewhat different feature, but please start with a motivation: take the current API and show what *problem you run into* that you?d like to solve. > > If your problem is unrelated to the JEP but is just about a non-blocking polling mechanism for Future, I?d still argue that having both state and resultNow is superior to a single maybeGetResult, because the former is more general: you can use it just as efficiently for polling or for obtaining the result in cases where the correct state is guaranteed. > > ? Ron P.S. I expect that in the future we?ll be able to offer a nicer way of polling that combines the call to state and xxxNow with deconstructing patterns, i.e.: switch(f) { case result(String x) -> ? case error(Throwable t) -> ? case cancelled -> ? case running -> ? } From forax at univ-mlv.fr Sun Nov 21 15:47:20 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 21 Nov 2021 16:47:20 +0100 (CET) Subject: [External] : Re: Future.resultNow / exceptionNow In-Reply-To: References: <1DA8B0C2-0700-4872-B410-D6875B6D2987@oracle.com> <75BEEF26-1550-404F-9F20-D7D3B771706B@oracle.com> Message-ID: <45035315.3492681.1637509640372.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "Ron Pressler" > To: "Alex Otenko" > Cc: "loom-dev" > Sent: Dimanche 21 Novembre 2021 16:01:43 > Subject: Re: [External] : Re: Future.resultNow / exceptionNow [...] >> >> ? Ron > > > P.S. > > I expect that in the future we?ll be able to offer a nicer way of polling that > combines the call to state and xxxNow with deconstructing patterns, i.e.: > > switch(f) { > case result(String x) -> ? > case error(Throwable t) -> ? > case cancelled -> ? > case running -> ? > } given that a Future is mutable it's more something like switch(f.stateInfo()) { case result(String x) -> ? case error(Throwable t) -> ? case cancelled -> ? case running -> ? } R?mi From oleksandr.otenko at gmail.com Sun Nov 21 15:57:02 2021 From: oleksandr.otenko at gmail.com (Alex Otenko) Date: Sun, 21 Nov 2021 15:57:02 +0000 Subject: [External] : Re: Future.resultNow / exceptionNow In-Reply-To: References: <49043D82-9514-4C77-A305-EB4A8C0F8649@oracle.com> <1DA8B0C2-0700-4872-B410-D6875B6D2987@oracle.com> <75BEEF26-1550-404F-9F20-D7D3B771706B@oracle.com> Message-ID: On Sun, 21 Nov 2021, 14:56 Ron Pressler, wrote: > > > > On 21 Nov 2021, at 14:00, Alex Otenko > wrote: > > > > No, you don't know what went wrong. You only know something did. > > The methods must only be called when the Future is in a certain state, and > the exception tells you exactly what the actual, unexpected state is. You > have all the information you could ever need to fix the bug. Suppose you > call resultNow without having called join first. The error you?ll get will > tell you exactly that this is the bug, and that adding join is necessary. > And suppose you call resultNow after join but before handling exception, > the error you?ll get will tell you exactly that that?s what missing. > No, because, to be precise, NPE un the task is the root cause. If not for it, the task never throws, and in all the testing we never discovered the missing exception handling in the code that calls resultNow. Now in production NPE got triggered. We look through the logs, and see one bug, but not the other. To fix it, you need one patch just to make the NPE discoverable. So you will lose time to resolution. > > > > So, you see the code is broken. You get to deploy two patches: one to > start using a different method to observe what has lead to the problem > (likely a Runtime Exception or Error - say, NPE in the task), then the fix > for the actual problem. > > The exception tells you *which* incorrect state has led to the problem > (maybe the message should include precisely which State enum value is > expected and which is found). > Not the full state, though, we learn just a single bit of information. > > > > As for maybeResultNow - I haven't warmed up to the idea that throwing by > resultNow is saving me from a really bad problem. > > The problem that resultNow was created to solve is that in the common > case, in which you already know the state of the future and have already > handled exceptions, anything other than returning the result would be an > unnecessary complication. Write down that code and see for yourself. > Sure. Here it is: exe.join(); Throwable th = future.exceptionNow(); if (th != null) throw rewrap(th); // here resultNow is guaranteed to be ok // but exceptionNow will throw > > > > I am looking at the code that joined on executor, and don't see why it > is more correct for (albeit indirect) state introspection to punish me with > hidden throws. > > I don?t understand. The method for state introspection, Future.state, > never fails. resultNow, which is *not* for state introspection, never > punishes you. It just cannot continue when a bug in your program makes its > precondition false, and it helps you by telling you what your bug is. > > > I am looking at another example that polls for result, and again don't > see why throwing is better for something that is like a non-blocking get. > > The purpose of resultNow is not to be a non-blocking get (although you > could write a non-blocking get with a combination of state and resultNow). > The purpose of resultNow is to obtain the result in the common case, in > which you already know that it?s there, and are *guaranteed* that the > method will never fail. > People will use it as a get() that doesn't require try-catch. > > Reminds me of NIO Selector API, where almost anything can result in a > bunch of Runtime Exceptions. > > If we could panic, maybe we?d panic. The exception is not the point. It > just indicates a bug in the program. > Well, and my contention is that you declare it a bug. What's the horrible sin of the above check? A throwing exceptionNow doesn't really save me from anything. Alex > I understand that you?d like a somewhat different feature, but please > start with a motivation: take the current API and show what *problem you > run into* that you?d like to solve. > > If your problem is unrelated to the JEP but is just about a non-blocking > polling mechanism for Future, I?d still argue that having both state and > resultNow is superior to a single maybeGetResult, because the former is > more general: you can use it just as efficiently for polling or for > obtaining the result in cases where the correct state is guaranteed. > > ? Ron From paul.bjorkstrand at gmail.com Sun Nov 21 16:53:52 2021 From: paul.bjorkstrand at gmail.com (Paul Bjorkstrand) Date: Sun, 21 Nov 2021 10:53:52 -0600 Subject: [External] : Re: Future.resultNow / exceptionNow In-Reply-To: References: <49043D82-9514-4C77-A305-EB4A8C0F8649@oracle.com> <1DA8B0C2-0700-4872-B410-D6875B6D2987@oracle.com> <75BEEF26-1550-404F-9F20-D7D3B771706B@oracle.com> Message-ID: To me, it sounds like the ask is this: "If the Future completed with an exception, why would the exception not be attached as the cause of the ISE thrown by resultNow()?" The answer Ron gave was: "The exception is not attached as the cause, because the API is being used incorrectly in the first place." I would argue that not attaching the cause is incorrect as well. I have seen many times in my career where catch blocks do not attach the cause when throwing again, which makes it rather difficult to track down the root problem. I agree that the method may have been used improperly, but I wouldn't want to hide the root cause. When you throw an exception *because of another exception* it is far better to add it as the cause, than to throw one with no cause. If you don't include the cause, you are hiding the root issue that needs to be solved. Yes, we may be using the API improperly, but are trying to teach people to use the API properly, or are you just trying to make it annoying if they _don't_ use it properly? I can't count how many times I have seen a catch-block throw a RuntimeException for a checked one, and didn't include the cause. In my book, that is a cardinal sin, akin to logging an exception like this in SLF4J: log.error("An exception happened: {}", e); Using either pattern, you lose the benefit of the stack trace and cause chain in the first place. For me, this goes beyond reducing boilerplate, and is more about good programming practices. The more information you can provide to the developer about what _exactly_ went wrong, the easier it is for that developer to find the issue. I agree, 100% with the other cases - task cancelled or thread interrupted or future not done yet - should throw as-is. All that is being asked for is, add the cause to the ISE when the future completed exceptionally. You will save people like me, hours of troubleshooting (and helping teach others to troubleshoot) errors that don't have useful stacktraces. -Paul On Sun, Nov 21, 2021 at 9:57 AM Alex Otenko wrote: > On Sun, 21 Nov 2021, 14:56 Ron Pressler, wrote: > > > > > > > > On 21 Nov 2021, at 14:00, Alex Otenko > > wrote: > > > > > > No, you don't know what went wrong. You only know something did. > > > > The methods must only be called when the Future is in a certain state, > and > > the exception tells you exactly what the actual, unexpected state is. You > > have all the information you could ever need to fix the bug. Suppose you > > call resultNow without having called join first. The error you?ll get > will > > tell you exactly that this is the bug, and that adding join is necessary. > > And suppose you call resultNow after join but before handling exception, > > the error you?ll get will tell you exactly that that?s what missing. > > > > No, because, to be precise, NPE un the task is the root cause. If not for > it, the task never throws, and in all the testing we never discovered the > missing exception handling in the code that calls resultNow. > > Now in production NPE got triggered. We look through the logs, and see one > bug, but not the other. To fix it, you need one patch just to make the NPE > discoverable. So you will lose time to resolution. > > > > > > > > > So, you see the code is broken. You get to deploy two patches: one to > > start using a different method to observe what has lead to the problem > > (likely a Runtime Exception or Error - say, NPE in the task), then the > fix > > for the actual problem. > > > > The exception tells you *which* incorrect state has led to the problem > > (maybe the message should include precisely which State enum value is > > expected and which is found). > > > > Not the full state, though, we learn just a single bit of information. > > > > > > > > > As for maybeResultNow - I haven't warmed up to the idea that throwing > by > > resultNow is saving me from a really bad problem. > > > > The problem that resultNow was created to solve is that in the common > > case, in which you already know the state of the future and have already > > handled exceptions, anything other than returning the result would be an > > unnecessary complication. Write down that code and see for yourself. > > > > Sure. Here it is: > > exe.join(); > Throwable th = future.exceptionNow(); > if (th != null) throw rewrap(th); > // here resultNow is guaranteed to be ok > // but exceptionNow will throw > > > > > > > > > I am looking at the code that joined on executor, and don't see why it > > is more correct for (albeit indirect) state introspection to punish me > with > > hidden throws. > > > > I don?t understand. The method for state introspection, Future.state, > > never fails. resultNow, which is *not* for state introspection, never > > punishes you. It just cannot continue when a bug in your program makes > its > > precondition false, and it helps you by telling you what your bug is. > > > > > I am looking at another example that polls for result, and again don't > > see why throwing is better for something that is like a non-blocking get. > > > > The purpose of resultNow is not to be a non-blocking get (although you > > could write a non-blocking get with a combination of state and > resultNow). > > The purpose of resultNow is to obtain the result in the common case, in > > which you already know that it?s there, and are *guaranteed* that the > > method will never fail. > > > > People will use it as a get() that doesn't require try-catch. > > > > > Reminds me of NIO Selector API, where almost anything can result in a > > bunch of Runtime Exceptions. > > > > If we could panic, maybe we?d panic. The exception is not the point. It > > just indicates a bug in the program. > > > > Well, and my contention is that you declare it a bug. What's the horrible > sin of the above check? A throwing exceptionNow doesn't really save me from > anything. > > > Alex > > > > I understand that you?d like a somewhat different feature, but please > > start with a motivation: take the current API and show what *problem you > > run into* that you?d like to solve. > > > > If your problem is unrelated to the JEP but is just about a non-blocking > > polling mechanism for Future, I?d still argue that having both state and > > resultNow is superior to a single maybeGetResult, because the former is > > more general: you can use it just as efficiently for polling or for > > obtaining the result in cases where the correct state is guaranteed. > > > > ? Ron > From ron.pressler at oracle.com Sun Nov 21 17:30:56 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Sun, 21 Nov 2021 17:30:56 +0000 Subject: [External] : Re: Future.resultNow / exceptionNow In-Reply-To: References: <49043D82-9514-4C77-A305-EB4A8C0F8649@oracle.com> <1DA8B0C2-0700-4872-B410-D6875B6D2987@oracle.com> <75BEEF26-1550-404F-9F20-D7D3B771706B@oracle.com> Message-ID: <2E5D142E-896E-440C-8BAC-405B7F777748@oracle.com> > On 21 Nov 2021, at 15:57, Alex Otenko wrote: > > > Sure. Here it is: > > exe.join(); > Throwable th = future.exceptionNow(); > if (th != null) throw rewrap(th); > // here resultNow is guaranteed to be ok > // but exceptionNow will throw > I am not sure what you?re showing there. That code is obviously incorrect ? it asserts something that isn?t true -- and the error will tell you why. If you want to do a check, why do you insist on using a method specifically designed to do something else rather than use the new method intended for that purpose? If you want to poll the state, do: If (future.state() == State.FAILED) throw rewrap(future.exceptionNow()); > > People will use it as a get() that doesn't require try-catch. resultNow can only be used in a state where it is the right thing to do. > > Well, and my contention is that you declare it a bug. What's the horrible sin of the above check? A throwing exceptionNow doesn't really save me from anything. The sin is the same one as in calling Lock.unlock without holding the lock. resultNow is a method that says: I know that this future has a result, so give it to me. If you do "I know that this future has a result so give it to me? but it doesn?t have a result, then you?re using this operation incorrectly. We?ve added a method that allows you to do what you want. Why do you want to do that thing not with the method we?ve added for that purpose but with the method we?ve added for a different purpose? ? Ron From eric at kolotyluk.net Sun Nov 21 17:45:13 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Sun, 21 Nov 2021 09:45:13 -0800 Subject: [External] : Re: Future.resultNow / exceptionNow In-Reply-To: References: <49043D82-9514-4C77-A305-EB4A8C0F8649@oracle.com> <1DA8B0C2-0700-4872-B410-D6875B6D2987@oracle.com> <75BEEF26-1550-404F-9F20-D7D3B771706B@oracle.com> Message-ID: I am trying to follow all the narratives... Can I conclude that resultNow() does not need to attach any failure information because the assumption is the future succeeded? In particular, the recommended best practice is something like structuredExecutor.join(); completionHandler.throwIfFailed(); var completedResults = futureResults.map(Future::resultNow).toList(); therefore, it should not be possible for any Futures to have failed. Any failures would have been detected in throwIfFailed(). Consequently, calling resultNow() on a Future that fails is "because the API is being used incorrectly in the first place." that Ron was talking about? While I can agree with all of this semantically, what concerns me is the complexity, and the potential unnecessary cognitive load this places on developers. This goes against my desire that Project Loom should be intuitive, something that @Brian Goetz seemed to support as a design goal. Cheers, Eric On Sun, Nov 21, 2021 at 8:54 AM Paul Bjorkstrand wrote: > To me, it sounds like the ask is this: > > "If the Future completed with an exception, why would the exception not > be attached as the cause of the ISE thrown by resultNow()?" > > The answer Ron gave was: > > "The exception is not attached as the cause, because the API is being used > incorrectly in the first place." > > I would argue that not attaching the cause is incorrect as well. I have > seen many times in my career where catch blocks do not attach the cause > when throwing again, which makes it rather difficult to track down the root > problem. I agree that the method may have been used improperly, but I > wouldn't want to hide the root cause. > > When you throw an exception *because of another exception* it is far better > to add it as the cause, than to throw one with no cause. If you don't > include the cause, you are hiding the root issue that needs to be solved. > Yes, we may be using the API improperly, but are trying to teach people to > use the API properly, or are you just trying to make it annoying if they > _don't_ use it properly? > > I can't count how many times I have seen a catch-block throw a > RuntimeException for a checked one, and didn't include the cause. In my > book, that is a cardinal sin, akin to logging an exception like this in > SLF4J: > log.error("An exception happened: {}", e); > Using either pattern, you lose the benefit of the stack trace and cause > chain in the first place. > > For me, this goes beyond reducing boilerplate, and is more about good > programming practices. The more information you can provide to the > developer about what _exactly_ went wrong, the easier it is for that > developer to find the issue. > > I agree, 100% with the other cases - task cancelled or thread interrupted > or future not done yet - should throw as-is. All that is being asked for > is, add the cause to the ISE when the future completed exceptionally. You > will save people like me, hours of troubleshooting (and helping teach > others to troubleshoot) errors that don't have useful stacktraces. > > -Paul > > > On Sun, Nov 21, 2021 at 9:57 AM Alex Otenko > wrote: > > > On Sun, 21 Nov 2021, 14:56 Ron Pressler, > wrote: > > > > > > > > > > > > On 21 Nov 2021, at 14:00, Alex Otenko > > > wrote: > > > > > > > > No, you don't know what went wrong. You only know something did. > > > > > > The methods must only be called when the Future is in a certain state, > > and > > > the exception tells you exactly what the actual, unexpected state is. > You > > > have all the information you could ever need to fix the bug. Suppose > you > > > call resultNow without having called join first. The error you?ll get > > will > > > tell you exactly that this is the bug, and that adding join is > necessary. > > > And suppose you call resultNow after join but before handling > exception, > > > the error you?ll get will tell you exactly that that?s what missing. > > > > > > > No, because, to be precise, NPE un the task is the root cause. If not for > > it, the task never throws, and in all the testing we never discovered the > > missing exception handling in the code that calls resultNow. > > > > Now in production NPE got triggered. We look through the logs, and see > one > > bug, but not the other. To fix it, you need one patch just to make the > NPE > > discoverable. So you will lose time to resolution. > > > > > > > > > > > > > > So, you see the code is broken. You get to deploy two patches: one to > > > start using a different method to observe what has lead to the problem > > > (likely a Runtime Exception or Error - say, NPE in the task), then the > > fix > > > for the actual problem. > > > > > > The exception tells you *which* incorrect state has led to the problem > > > (maybe the message should include precisely which State enum value is > > > expected and which is found). > > > > > > > Not the full state, though, we learn just a single bit of information. > > > > > > > > > > > > > > As for maybeResultNow - I haven't warmed up to the idea that throwing > > by > > > resultNow is saving me from a really bad problem. > > > > > > The problem that resultNow was created to solve is that in the common > > > case, in which you already know the state of the future and have > already > > > handled exceptions, anything other than returning the result would be > an > > > unnecessary complication. Write down that code and see for yourself. > > > > > > > Sure. Here it is: > > > > exe.join(); > > Throwable th = future.exceptionNow(); > > if (th != null) throw rewrap(th); > > // here resultNow is guaranteed to be ok > > // but exceptionNow will throw > > > > > > > > > > > > > > I am looking at the code that joined on executor, and don't see why > it > > > is more correct for (albeit indirect) state introspection to punish me > > with > > > hidden throws. > > > > > > I don?t understand. The method for state introspection, Future.state, > > > never fails. resultNow, which is *not* for state introspection, never > > > punishes you. It just cannot continue when a bug in your program makes > > its > > > precondition false, and it helps you by telling you what your bug is. > > > > > > > I am looking at another example that polls for result, and again > don't > > > see why throwing is better for something that is like a non-blocking > get. > > > > > > The purpose of resultNow is not to be a non-blocking get (although you > > > could write a non-blocking get with a combination of state and > > resultNow). > > > The purpose of resultNow is to obtain the result in the common case, in > > > which you already know that it?s there, and are *guaranteed* that the > > > method will never fail. > > > > > > > People will use it as a get() that doesn't require try-catch. > > > > > > > > Reminds me of NIO Selector API, where almost anything can result in a > > > bunch of Runtime Exceptions. > > > > > > If we could panic, maybe we?d panic. The exception is not the point. It > > > just indicates a bug in the program. > > > > > > > Well, and my contention is that you declare it a bug. What's the horrible > > sin of the above check? A throwing exceptionNow doesn't really save me > from > > anything. > > > > > > Alex > > > > > > > I understand that you?d like a somewhat different feature, but please > > > start with a motivation: take the current API and show what *problem > you > > > run into* that you?d like to solve. > > > > > > If your problem is unrelated to the JEP but is just about a > non-blocking > > > polling mechanism for Future, I?d still argue that having both state > and > > > resultNow is superior to a single maybeGetResult, because the former is > > > more general: you can use it just as efficiently for polling or for > > > obtaining the result in cases where the correct state is guaranteed. > > > > > > ? Ron > > > From forax at univ-mlv.fr Sun Nov 21 18:02:45 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 21 Nov 2021 19:02:45 +0100 (CET) Subject: StructuredExecutor API and wildcards Message-ID: <741489098.3519107.1637517765551.JavaMail.zimbra@u-pem.fr> I've noticed that the current API has some signatures that are not correct, either a widlcard is missing, or there is a type parameter instead of a wildcard, etc. I know that the Executor/Future has similar issues so there is perhaps a weird tradition ... sorry kidding. In StructuredExecutor: Future fork(Callable task) should be Future fork(Callable task). For all functional interface, the result should be ? extends R and the parameters should be ? super P. For the other fork(), you can see that someone struggle to get the correct signature :) Future fork(Callable task, BiConsumer> onComplete) It should be Future fork(Callable task, BiConsumer> onComplete) U does need to be named, Future can be a Future because there is no methods taking a V as parameter, but given that FutureTask has methods that takes a V, so i think it's better to keep Future invariant. In ShutdownOnFailure, usually we use Void instead of Object to represent the type of a value that can only be null, so the class should be declared class ShutdownOnFailure implements BiConsumer> { } so void accept(StructuredExecutor executor, Future future) is now void accept(StructuredExecutor executor, Future future) and void throwIfFailed(Function esf) should be void throwIfFailed(Function esf) In ShutdownOnSuccess V result(Function esf) should be V result(Function esf) throws X for ShutdownOnSuccess, i think it's better to just have a method that returns a Future instead of trying to invent another API very similar to Future. regards, R?mi From oleksandr.otenko at gmail.com Sun Nov 21 17:55:58 2021 From: oleksandr.otenko at gmail.com (Alex Otenko) Date: Sun, 21 Nov 2021 17:55:58 +0000 Subject: [External] : Re: Future.resultNow / exceptionNow In-Reply-To: <2E5D142E-896E-440C-8BAC-405B7F777748@oracle.com> References: <49043D82-9514-4C77-A305-EB4A8C0F8649@oracle.com> <1DA8B0C2-0700-4872-B410-D6875B6D2987@oracle.com> <75BEEF26-1550-404F-9F20-D7D3B771706B@oracle.com> <2E5D142E-896E-440C-8BAC-405B7F777748@oracle.com> Message-ID: I think your code is also subtly incorrect, and because it is so easy to make this mistake people will get impaled on it all the time. Your example of the state check should be if (future.state() != SUCCESS) throw... Alex On Sun, 21 Nov 2021, 17:31 Ron Pressler, wrote: > > > > On 21 Nov 2021, at 15:57, Alex Otenko > wrote: > > > > > > Sure. Here it is: > > > > exe.join(); > > Throwable th = future.exceptionNow(); > > if (th != null) throw rewrap(th); > > // here resultNow is guaranteed to be ok > > // but exceptionNow will throw > > > > I am not sure what you?re showing there. That code is obviously incorrect > ? it asserts something that isn?t true -- and the error will tell you why. > If you want to do a check, why do you insist on using a method specifically > designed to do something else rather than use the new method intended for > that purpose? If you want to poll the state, do: > > If (future.state() == State.FAILED) throw rewrap(future.exceptionNow()); > > > > > People will use it as a get() that doesn't require try-catch. > > resultNow can only be used in a state where it is the right thing to do. > > > > > Well, and my contention is that you declare it a bug. What's the > horrible sin of the above check? A throwing exceptionNow doesn't really > save me from anything. > > The sin is the same one as in calling Lock.unlock without holding the > lock. resultNow is a method that says: I know that this future has a > result, so give it to me. If you do "I know that this future has a result > so give it to me? but it doesn?t have a result, then you?re using this > operation incorrectly. > > We?ve added a method that allows you to do what you want. Why do you want > to do that thing not with the method we?ve added for that purpose but with > the method we?ve added for a different purpose? > > ? Ron From ron.pressler at oracle.com Sun Nov 21 18:10:18 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Sun, 21 Nov 2021 18:10:18 +0000 Subject: [External] : Re: Future.resultNow / exceptionNow In-Reply-To: References: <49043D82-9514-4C77-A305-EB4A8C0F8649@oracle.com> <1DA8B0C2-0700-4872-B410-D6875B6D2987@oracle.com> <75BEEF26-1550-404F-9F20-D7D3B771706B@oracle.com> <2E5D142E-896E-440C-8BAC-405B7F777748@oracle.com> Message-ID: <92CE7158-2A55-4633-B44B-B5B7D76B3BC3@oracle.com> I wrote precisely what I intended. You should only call exceptionNow if the state is FAILED (we might want to change the current behaviour). It?s just that this line shouldn?t be used in the context of the rest of your code. You should not need to poll or examine the state of futures at all when using StructuredExecutor, except in some very special circumstances: returning a partial result in the event of a timeout or cancellation. If you find yourself needing to test the state of the future, please show us when, as that?s something we?d like to avoid. ? Ron On 21 Nov 2021, at 17:55, Alex Otenko > wrote: I think your code is also subtly incorrect, and because it is so easy to make this mistake people will get impaled on it all the time. Your example of the state check should be if (future.state() != SUCCESS) throw... Alex On Sun, 21 Nov 2021, 17:31 Ron Pressler, > wrote: > On 21 Nov 2021, at 15:57, Alex Otenko > wrote: > > > Sure. Here it is: > > exe.join(); > Throwable th = future.exceptionNow(); > if (th != null) throw rewrap(th); > // here resultNow is guaranteed to be ok > // but exceptionNow will throw > I am not sure what you?re showing there. That code is obviously incorrect ? it asserts something that isn?t true -- and the error will tell you why. If you want to do a check, why do you insist on using a method specifically designed to do something else rather than use the new method intended for that purpose? If you want to poll the state, do: If (future.state() == State.FAILED) throw rewrap(future.exceptionNow()); > > People will use it as a get() that doesn't require try-catch. resultNow can only be used in a state where it is the right thing to do. > > Well, and my contention is that you declare it a bug. What's the horrible sin of the above check? A throwing exceptionNow doesn't really save me from anything. The sin is the same one as in calling Lock.unlock without holding the lock. resultNow is a method that says: I know that this future has a result, so give it to me. If you do "I know that this future has a result so give it to me? but it doesn?t have a result, then you?re using this operation incorrectly. We?ve added a method that allows you to do what you want. Why do you want to do that thing not with the method we?ve added for that purpose but with the method we?ve added for a different purpose? ? Ron From brian.goetz at oracle.com Sun Nov 21 18:49:33 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 21 Nov 2021 13:49:33 -0500 Subject: [External] : Re: Future.resultNow / exceptionNow In-Reply-To: References: <49043D82-9514-4C77-A305-EB4A8C0F8649@oracle.com> <1DA8B0C2-0700-4872-B410-D6875B6D2987@oracle.com> <75BEEF26-1550-404F-9F20-D7D3B771706B@oracle.com> Message-ID: > When you throw an exception*because of another exception* it is far better > to add it as the cause, than to throw one with no cause. If you don't > include the cause, you are hiding the root issue that needs to be solved. > Yes, we may be using the API improperly, but are trying to teach people to > use the API properly, or are you just trying to make it annoying if they > _don't_ use it properly? The API is designed to follow a simple pattern: ??? create an SE, always in a TWR header ??? fork some tasks ??? wait for them all to finish (there's a method for this) ??? (optional) deal with results and errors, if needed, in accordance with selected error-handling policy ??? implicitly close by falling out of TWR In most cases, this will fit on half a page or less of code. We don't strictly need resultNow, but if we didn't add it, people would complain that gathering results with Future is annoying (and they'd be right) because Future forces you to deal with all the possible states, often by catching exceptions, even though, if you follow the above simple pattern, you *already* know what state the Future is in.? [1] It's natural to ask "but how can I be sure", but the API is designed to be simple enough that it is *hard to get wrong*, once you learn the idiom once.? Three phases: fork tasks, wait for tasks, optionally handle results.? Given that, it will surely be annoying if there is any gratuitous unpacking friction; it will feel like needing both belt and suspenders.? Wrapping the result in Optional is less annoying than dealing with the exceptions of Future, but its still annoying, and, still unnecessary.? (And, if we did wrap it in an Optional, the same complaint about "why is the optional empty, you should wrap the exception" would come up.? At which point we've reinvented the existing Future::get API.) As Ron has suggested several times, rather than redesigning the API in a vacuum, its probably best to *go try it* and report back your experience.? Much of what comes out of Project Loom involves unlearning things we had to do before because of accidental constraints like "threads are expensive to create."? The idioms we have internalized are conditioned by the reality we used to be stuck with, but no longer are.? The natural idioms we will equilibrate to after such a big change in cost model may be slightly unintuitive at first, but give them a chance. [1] If your policy is complicated, it may require some bookkeeping to sort the succeeded from failed tasks, but that's what the handler object is for, and it's easy to write handlers even for complex policies like "abort if two red tasks succeed before three blue tasks fail". From eric at kolotyluk.net Sun Nov 21 18:57:03 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Sun, 21 Nov 2021 10:57:03 -0800 Subject: [External] : Re: Future.resultNow / exceptionNow In-Reply-To: References: <49043D82-9514-4C77-A305-EB4A8C0F8649@oracle.com> <1DA8B0C2-0700-4872-B410-D6875B6D2987@oracle.com> <75BEEF26-1550-404F-9F20-D7D3B771706B@oracle.com> Message-ID: Just to clarify... "(optional) deal with results and errors" If you want to call Future::resultNow then dealing with errors first is not optional, or you are inviting an IllegalStateException. On Sun, Nov 21, 2021 at 10:49 AM Brian Goetz wrote: > > > When you throw an exception*because of another exception* it is far > better > > to add it as the cause, than to throw one with no cause. If you don't > > include the cause, you are hiding the root issue that needs to be solved. > > Yes, we may be using the API improperly, but are trying to teach people > to > > use the API properly, or are you just trying to make it annoying if they > > _don't_ use it properly? > > The API is designed to follow a simple pattern: > > create an SE, always in a TWR header > fork some tasks > wait for them all to finish (there's a method for this) > (optional) deal with results and errors, if needed, in accordance > with selected error-handling policy > implicitly close by falling out of TWR > > In most cases, this will fit on half a page or less of code. > > We don't strictly need resultNow, but if we didn't add it, people would > complain that gathering results with Future is annoying (and they'd be > right) because Future forces you to deal with all the possible states, > often by catching exceptions, even though, if you follow the above > simple pattern, you *already* know what state the Future is in. [1] > > It's natural to ask "but how can I be sure", but the API is designed to > be simple enough that it is *hard to get wrong*, once you learn the > idiom once. Three phases: fork tasks, wait for tasks, optionally handle > results. Given that, it will surely be annoying if there is any > gratuitous unpacking friction; it will feel like needing both belt and > suspenders. Wrapping the result in Optional is less annoying than > dealing with the exceptions of Future, but its still annoying, and, > still unnecessary. (And, if we did wrap it in an Optional, the same > complaint about "why is the optional empty, you should wrap the > exception" would come up. At which point we've reinvented the existing > Future::get API.) > > As Ron has suggested several times, rather than redesigning the API in a > vacuum, its probably best to *go try it* and report back your > experience. Much of what comes out of Project Loom involves unlearning > things we had to do before because of accidental constraints like > "threads are expensive to create." The idioms we have internalized are > conditioned by the reality we used to be stuck with, but no longer are. > The natural idioms we will equilibrate to after such a big change in > cost model may be slightly unintuitive at first, but give them a chance. > > > > > > [1] If your policy is complicated, it may require some bookkeeping to > sort the succeeded from failed tasks, but that's what the handler object > is for, and it's easy to write handlers even for complex policies like > "abort if two red tasks succeed before three blue tasks fail". > > > From brian.goetz at oracle.com Sun Nov 21 19:06:15 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 21 Nov 2021 14:06:15 -0500 Subject: [External] : Re: Future.resultNow / exceptionNow In-Reply-To: References: <49043D82-9514-4C77-A305-EB4A8C0F8649@oracle.com> <1DA8B0C2-0700-4872-B410-D6875B6D2987@oracle.com> <75BEEF26-1550-404F-9F20-D7D3B771706B@oracle.com> Message-ID: On 11/21/2021 1:57 PM, Eric Kolotyluk wrote: > Just to clarify... > > "(optional) deal with results and errors" > > If you want to call Future::resultNow then dealing with errors first > is not optional, or you are inviting anIllegalStateException. I think you may have mis-parsed my sentence?? "Optional" applies to the whole sentence; for many tasks, there is no result, only side-effects, so there's no need to deal with results, so no need to call Future::resultNow (in fact, likely no need for keeping the futures at all in this case.) Again, as Ron has pleaded: PLEASE TRY IT, rather than critiquing in a vacuum; designing concurrency APIs is hard, and doubly so when new paradigms are involved.? If you are having trouble figuring out how to try it, ask questions! Cheers, -Brian > > On Sun, Nov 21, 2021 at 10:49 AM Brian Goetz > wrote: > > > > When you throw an exception*because of another exception*? it is > far better > > to add it as the cause, than to throw one with no cause. If you > don't > > include the cause, you are hiding the root issue that needs to > be solved. > > Yes, we may be using the API improperly, but are trying to teach > people to > > use the API properly, or are you just trying to make it annoying > if they > > _don't_? use it properly? > > The API is designed to follow a simple pattern: > > ???? create an SE, always in a TWR header > ???? fork some tasks > ???? wait for them all to finish (there's a method for this) > ???? (optional) deal with results and errors, if needed, in > accordance > with selected error-handling policy > ???? implicitly close by falling out of TWR > > In most cases, this will fit on half a page or less of code. > > We don't strictly need resultNow, but if we didn't add it, people > would > complain that gathering results with Future is annoying (and > they'd be > right) because Future forces you to deal with all the possible > states, > often by catching exceptions, even though, if you follow the above > simple pattern, you *already* know what state the Future is in.? [1] > > It's natural to ask "but how can I be sure", but the API is > designed to > be simple enough that it is *hard to get wrong*, once you learn the > idiom once.? Three phases: fork tasks, wait for tasks, optionally > handle > results.? Given that, it will surely be annoying if there is any > gratuitous unpacking friction; it will feel like needing both belt > and > suspenders.? Wrapping the result in Optional is less annoying than > dealing with the exceptions of Future, but its still annoying, and, > still unnecessary.? (And, if we did wrap it in an Optional, the same > complaint about "why is the optional empty, you should wrap the > exception" would come up.? At which point we've reinvented the > existing > Future::get API.) > > As Ron has suggested several times, rather than redesigning the > API in a > vacuum, its probably best to *go try it* and report back your > experience.? Much of what comes out of Project Loom involves > unlearning > things we had to do before because of accidental constraints like > "threads are expensive to create."? The idioms we have > internalized are > conditioned by the reality we used to be stuck with, but no longer > are. > The natural idioms we will equilibrate to after such a big change in > cost model may be slightly unintuitive at first, but give them a > chance. > > > > > > [1] If your policy is complicated, it may require some bookkeeping to > sort the succeeded from failed tasks, but that's what the handler > object > is for, and it's easy to write handlers even for complex policies > like > "abort if two red tasks succeed before three blue tasks fail". > > From eric at kolotyluk.net Sun Nov 21 19:17:25 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Sun, 21 Nov 2021 11:17:25 -0800 Subject: [External] : Re: Future.resultNow / exceptionNow In-Reply-To: References: <49043D82-9514-4C77-A305-EB4A8C0F8649@oracle.com> <1DA8B0C2-0700-4872-B410-D6875B6D2987@oracle.com> <75BEEF26-1550-404F-9F20-D7D3B771706B@oracle.com> Message-ID: Agreed, I did mis-parse your sentence. Agreed, "designing concurrency APIs is hard, and doubly so when new paradigms are involved" I was not critiquing so much as using an overly assertive clarification, so I will try to make the questions clearer. I am trying the new APIs and paradigms, that is what my loom-lab project is all about. I am learning more from the code experiments than the documentation, which is normal because writing documentation is hard. Cheers, Eric On Sun, Nov 21, 2021 at 11:06 AM Brian Goetz wrote: > > > On 11/21/2021 1:57 PM, Eric Kolotyluk wrote: > > Just to clarify... > > "(optional) deal with results and errors" > > If you want to call Future::resultNow then dealing with errors first is > not optional, or you are inviting an IllegalStateException. > > > I think you may have mis-parsed my sentence? "Optional" applies to the > whole sentence; for many tasks, there is no result, only side-effects, so > there's no need to deal with results, so no need to call Future::resultNow > (in fact, likely no need for keeping the futures at all in this case.) > > Again, as Ron has pleaded: PLEASE TRY IT, rather than critiquing in a > vacuum; designing concurrency APIs is hard, and doubly so when new > paradigms are involved. If you are having trouble figuring out how to try > it, ask questions! > > Cheers, > -Brian > > > > > On Sun, Nov 21, 2021 at 10:49 AM Brian Goetz > wrote: > >> >> > When you throw an exception*because of another exception* it is far >> better >> > to add it as the cause, than to throw one with no cause. If you don't >> > include the cause, you are hiding the root issue that needs to be >> solved. >> > Yes, we may be using the API improperly, but are trying to teach people >> to >> > use the API properly, or are you just trying to make it annoying if they >> > _don't_ use it properly? >> >> The API is designed to follow a simple pattern: >> >> create an SE, always in a TWR header >> fork some tasks >> wait for them all to finish (there's a method for this) >> (optional) deal with results and errors, if needed, in accordance >> with selected error-handling policy >> implicitly close by falling out of TWR >> >> In most cases, this will fit on half a page or less of code. >> >> We don't strictly need resultNow, but if we didn't add it, people would >> complain that gathering results with Future is annoying (and they'd be >> right) because Future forces you to deal with all the possible states, >> often by catching exceptions, even though, if you follow the above >> simple pattern, you *already* know what state the Future is in. [1] >> >> It's natural to ask "but how can I be sure", but the API is designed to >> be simple enough that it is *hard to get wrong*, once you learn the >> idiom once. Three phases: fork tasks, wait for tasks, optionally handle >> results. Given that, it will surely be annoying if there is any >> gratuitous unpacking friction; it will feel like needing both belt and >> suspenders. Wrapping the result in Optional is less annoying than >> dealing with the exceptions of Future, but its still annoying, and, >> still unnecessary. (And, if we did wrap it in an Optional, the same >> complaint about "why is the optional empty, you should wrap the >> exception" would come up. At which point we've reinvented the existing >> Future::get API.) >> >> As Ron has suggested several times, rather than redesigning the API in a >> vacuum, its probably best to *go try it* and report back your >> experience. Much of what comes out of Project Loom involves unlearning >> things we had to do before because of accidental constraints like >> "threads are expensive to create." The idioms we have internalized are >> conditioned by the reality we used to be stuck with, but no longer are. >> The natural idioms we will equilibrate to after such a big change in >> cost model may be slightly unintuitive at first, but give them a chance. >> >> >> >> >> >> [1] If your policy is complicated, it may require some bookkeeping to >> sort the succeeded from failed tasks, but that's what the handler object >> is for, and it's easy to write handlers even for complex policies like >> "abort if two red tasks succeed before three blue tasks fail". >> >> >> > From brian.goetz at oracle.com Sun Nov 21 19:42:26 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 21 Nov 2021 14:42:26 -0500 Subject: [External] : Re: Future.resultNow / exceptionNow In-Reply-To: References: <49043D82-9514-4C77-A305-EB4A8C0F8649@oracle.com> <1DA8B0C2-0700-4872-B410-D6875B6D2987@oracle.com> <75BEEF26-1550-404F-9F20-D7D3B771706B@oracle.com> Message-ID: <0a80c67f-8338-0a9f-aa15-63bb13790d53@oracle.com> > I am trying the new APIs and paradigms, that is what my loom-lab > project is all about. I am learning more from the code experiments > than the documentation, which is normal because writing documentation > is hard. Indeed, writing documentation is hard.? The draft APIs here already have more documentation than most do, but "more" doesn't always mean "enough", and there's no "Java Concurrency in Practice, Vol 2" (yet) that you can go buy.? This is where getting feedback from users like yourself is critical; it will teach us what we have to add to save the later adopters from the potholes that the early adopters fell into. Cheers, -Brian From eric at kolotyluk.net Sun Nov 21 19:43:23 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Sun, 21 Nov 2021 11:43:23 -0800 Subject: Virtual Threads are Better than ForkJoin Tasks That Block Message-ID: As I am trying to document my understanding of pre-loom and post-loom paradigms, am I correct in claiming *Virtual Threads are Better than ForkJoin Tasks That Block* Looking at ForkJoinTask there is a lot of complexity around designing and implementing tasks that block. ForkJoin really seems better suited to things like Parallel Streams focused on computation. I am trying to create an informal list of problems that Project Loom solves... Cheers, Eric From eric at kolotyluk.net Sun Nov 21 19:45:59 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Sun, 21 Nov 2021 11:45:59 -0800 Subject: [External] : Re: Future.resultNow / exceptionNow In-Reply-To: <0a80c67f-8338-0a9f-aa15-63bb13790d53@oracle.com> References: <49043D82-9514-4C77-A305-EB4A8C0F8649@oracle.com> <1DA8B0C2-0700-4872-B410-D6875B6D2987@oracle.com> <75BEEF26-1550-404F-9F20-D7D3B771706B@oracle.com> <0a80c67f-8338-0a9f-aa15-63bb13790d53@oracle.com> Message-ID: I would be happy to contribute to improving the documentation... is that as easy as doing a pull request, or is it harder? Cheers, Eric On Sun, Nov 21, 2021 at 11:42 AM Brian Goetz wrote: > > > > I am trying the new APIs and paradigms, that is what my loom-lab > > project is all about. I am learning more from the code experiments > > than the documentation, which is normal because writing documentation > > is hard. > > Indeed, writing documentation is hard. The draft APIs here already have > more documentation than most do, but "more" doesn't always mean > "enough", and there's no "Java Concurrency in Practice, Vol 2" (yet) > that you can go buy. This is where getting feedback from users like > yourself is critical; it will teach us what we have to add to save the > later adopters from the potholes that the early adopters fell into. > > Cheers, > -Brian > From brian.goetz at oracle.com Sun Nov 21 19:56:22 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 21 Nov 2021 14:56:22 -0500 Subject: Virtual Threads are Better than ForkJoin Tasks That Block In-Reply-To: References: Message-ID: This is a fair statement. While the FJ framework has gotten better over the years at dealing with tasks that block, it really shines in CPU-intensive, data-parallel applications.? Virtual threads shine where we have many tasks that are blocking most of the time.? (It wouldn't make sense to run a million virtual threads if they each wanted 50% of a CPU, but we can run a million virtual threads when they all spend most of their time blocking.) You could make the same statement for parallel streams: "Virtual threads are better than parallel stream pipelines that block", because the split-vs-compute heuristics for streams are tuned for data-parallel, not blocking-parallel, workloads. On 11/21/2021 2:43 PM, Eric Kolotyluk wrote: > As I am trying to document my understanding of pre-loom and post-loom > paradigms, am I correct in claiming > > *Virtual Threads are Better than ForkJoin Tasks That Block* > > Looking at ForkJoinTask > > there is a lot of complexity around designing and implementing tasks that > block. ForkJoin really seems better suited to things like Parallel Streams > focused on computation. > > I am trying to create an informal list of problems that Project Loom > solves... > > Cheers, Eric From Alan.Bateman at oracle.com Sun Nov 21 19:59:58 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 21 Nov 2021 19:59:58 +0000 Subject: [External] : Re: Future.resultNow / exceptionNow In-Reply-To: References: <1DA8B0C2-0700-4872-B410-D6875B6D2987@oracle.com> <75BEEF26-1550-404F-9F20-D7D3B771706B@oracle.com> <0a80c67f-8338-0a9f-aa15-63bb13790d53@oracle.com> Message-ID: <1fedc7d3-3f18-4e1a-6f82-be100585caa0@oracle.com> On 21/11/2021 19:45, Eric Kolotyluk wrote: > I would be happy to contribute to improving the documentation... is that as > easy as doing a pull request, or is it harder? It could be PRs but it might be easier to jot down what you think is missing or unclear, or even just the issues you ran into so we can see if improved javadoc can help. -Alan From oleksandr.otenko at gmail.com Sun Nov 21 21:27:35 2021 From: oleksandr.otenko at gmail.com (Alex Otenko) Date: Sun, 21 Nov 2021 21:27:35 +0000 Subject: [External] : Re: Future.resultNow / exceptionNow In-Reply-To: <92CE7158-2A55-4633-B44B-B5B7D76B3BC3@oracle.com> References: <49043D82-9514-4C77-A305-EB4A8C0F8649@oracle.com> <1DA8B0C2-0700-4872-B410-D6875B6D2987@oracle.com> <75BEEF26-1550-404F-9F20-D7D3B771706B@oracle.com> <2E5D142E-896E-440C-8BAC-405B7F777748@oracle.com> <92CE7158-2A55-4633-B44B-B5B7D76B3BC3@oracle.com> Message-ID: I view it the other way around. Since it is guarding resultNow, should preclude all failures, which means FAILED or CANCELLED (we already know it is not RUNNING). Looking only for FAILED is a subtle bug. Alex On Sun, 21 Nov 2021, 18:10 Ron Pressler, wrote: > I wrote precisely what I intended. You should only call exceptionNow if > the state is FAILED (we might want to change the current behaviour). It?s > just that this line shouldn?t be used in the context of the rest of your > code. You should not need to poll or examine the state of futures at all > when using StructuredExecutor, except in some very special circumstances: > returning a partial result in the event of a timeout or cancellation. > > If you find yourself needing to test the state of the future, please show > us when, as that?s something we?d like to avoid. > > ? Ron > > On 21 Nov 2021, at 17:55, Alex Otenko wrote: > > I think your code is also subtly incorrect, and because it is so easy to > make this mistake people will get impaled on it all the time. > > Your example of the state check should be > > if (future.state() != SUCCESS) throw... > > Alex > > > On Sun, 21 Nov 2021, 17:31 Ron Pressler, wrote: > >> >> >> > On 21 Nov 2021, at 15:57, Alex Otenko >> wrote: >> > >> > >> > Sure. Here it is: >> > >> > exe.join(); >> > Throwable th = future.exceptionNow(); >> > if (th != null) throw rewrap(th); >> > // here resultNow is guaranteed to be ok >> > // but exceptionNow will throw >> > >> >> I am not sure what you?re showing there. That code is obviously incorrect >> ? it asserts something that isn?t true -- and the error will tell you why. >> If you want to do a check, why do you insist on using a method specifically >> designed to do something else rather than use the new method intended for >> that purpose? If you want to poll the state, do: >> >> If (future.state() == State.FAILED) throw rewrap(future.exceptionNow()); >> >> > >> > People will use it as a get() that doesn't require try-catch. >> >> resultNow can only be used in a state where it is the right thing to do. >> >> > >> > Well, and my contention is that you declare it a bug. What's the >> horrible sin of the above check? A throwing exceptionNow doesn't really >> save me from anything. >> >> The sin is the same one as in calling Lock.unlock without holding the >> lock. resultNow is a method that says: I know that this future has a >> result, so give it to me. If you do "I know that this future has a result >> so give it to me? but it doesn?t have a result, then you?re using this >> operation incorrectly. >> >> We?ve added a method that allows you to do what you want. Why do you want >> to do that thing not with the method we?ve added for that purpose but with >> the method we?ve added for a different purpose? >> >> ? Ron > > > From duke at openjdk.java.net Mon Nov 22 06:57:34 2021 From: duke at openjdk.java.net (duke) Date: Mon, 22 Nov 2021 06:57:34 GMT Subject: git: openjdk/loom: fibers: 9 new changesets Message-ID: <0c00d1b1-af47-4829-8173-bac1841db483@openjdk.java.net> Changeset: 1666838b Author: Alan Bateman Date: 2021-11-17 14:10:17 +0000 URL: https://git.openjdk.java.net/loom/commit/1666838be260166eb40531e52281755de67fb775 Add properties for testing/tuning #pollers ! src/java.base/share/classes/sun/nio/ch/Poller.java Changeset: 1d07c7d4 Author: Alan Bateman Date: 2021-11-18 07:34:05 +0000 URL: https://git.openjdk.java.net/loom/commit/1d07c7d4915de4c90f3619d8a7515ac4fd8bb1d5 javadoc clarification ! src/java.base/share/classes/java/util/concurrent/StructuredExecutor.java Changeset: 29855c3a Author: Alan Bateman Date: 2021-11-18 20:00:41 +0000 URL: https://git.openjdk.java.net/loom/commit/29855c3a6718e0ca5d409df3d3be6f10cee1bea3 Improve javadoc ! src/java.base/share/classes/java/util/concurrent/ThreadFactory.java Changeset: 11e81c9c Author: Alan Bateman Date: 2021-11-19 11:11:00 +0000 URL: https://git.openjdk.java.net/loom/commit/11e81c9c86ef1749ba487975a855ac53224b2e43 Cleanup in prep for supporting API ! src/java.base/share/classes/java/lang/VirtualThread.java Changeset: 6a9208b3 Author: Alan Bateman Date: 2021-11-19 17:51:24 +0000 URL: https://git.openjdk.java.net/loom/commit/6a9208b3f68b3169d957fad108861d84c484f9bf Deprecate Thread::getThreadGroup ! src/java.base/share/classes/java/lang/ProcessHandleImpl.java ! src/java.base/share/classes/java/lang/Thread.java ! src/java.base/share/classes/java/lang/ThreadGroup.java ! src/java.base/share/classes/java/lang/VirtualThread.java ! src/java.base/share/classes/java/lang/ref/Finalizer.java ! src/java.base/share/classes/java/lang/ref/Reference.java ! src/java.base/share/classes/java/util/concurrent/Executors.java ! src/java.base/share/classes/jdk/internal/misc/InnocuousThread.java ! src/java.desktop/share/classes/com/sun/media/sound/AbstractLine.java ! src/java.desktop/share/classes/com/sun/media/sound/RealTimeSequencer.java ! src/java.desktop/share/classes/java/awt/EventQueue.java ! src/java.desktop/share/classes/java/beans/ThreadGroupContext.java ! src/java.desktop/share/classes/sun/awt/AppContext.java ! src/java.desktop/share/classes/sun/awt/SunToolkit.java ! src/java.desktop/share/classes/sun/awt/image/ImageFetcher.java ! src/java.desktop/share/classes/sun/awt/util/ThreadGroupUtils.java ! src/java.desktop/share/classes/sun/java2d/marlin/MarlinUtils.java ! src/java.management/share/classes/javax/management/monitor/Monitor.java ! src/java.rmi/share/classes/sun/rmi/runtime/NewThreadAction.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/AbstractLauncher.java ! src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java Changeset: 62d1c003 Author: Alan Bateman Date: 2021-11-19 20:25:30 +0000 URL: https://git.openjdk.java.net/loom/commit/62d1c003942e4b36e77feb65b4d04d7ca7d8c792 Avoid doPrivileged when SM not set ! src/java.base/share/classes/java/util/concurrent/StructuredExecutor.java Changeset: efefcb3a Author: Alan Bateman Date: 2021-11-20 15:30:52 +0000 URL: https://git.openjdk.java.net/loom/commit/efefcb3a3cae0c6cea5fcee489ba5ee87c597e16 Fix typo in test comment ! test/jdk/java/lang/Thread/virtual/ThreadAPI.java Changeset: e1a3005e Author: Alan Bateman Date: 2021-11-21 08:04:53 +0000 URL: https://git.openjdk.java.net/loom/commit/e1a3005e903c3fa047de2942dc2eafd1faac59a6 Fix inconsistent wording ! src/java.base/share/classes/java/util/concurrent/Future.java Changeset: 003dffe4 Author: Alan Bateman Date: 2021-11-21 08:43:21 +0000 URL: https://git.openjdk.java.net/loom/commit/003dffe4343d12a4af27892050871802f7d75ee4 Exclude AppCDS tests that can't load ProcessTools ! test/hotspot/jtreg/ProblemList-vthread.txt From ron.pressler at oracle.com Mon Nov 22 11:06:06 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Mon, 22 Nov 2021 11:06:06 +0000 Subject: [External] : Re: Future.resultNow / exceptionNow In-Reply-To: References: <49043D82-9514-4C77-A305-EB4A8C0F8649@oracle.com> <1DA8B0C2-0700-4872-B410-D6875B6D2987@oracle.com> <75BEEF26-1550-404F-9F20-D7D3B771706B@oracle.com> <2E5D142E-896E-440C-8BAC-405B7F777748@oracle.com> <92CE7158-2A55-4633-B44B-B5B7D76B3BC3@oracle.com> Message-ID: <7A3565FC-F7EF-410D-8777-DAD36634C471@oracle.com> > On 21 Nov 2021, at 21:27, Alex Otenko wrote: > > I view it the other way around. Since it is guarding resultNow, should preclude all failures, which means FAILED or CANCELLED (we already know it is not RUNNING). > The only thing that can guard resultNow is `if (f.state() == State.SUCCESS)`, but you?ve taken this discussion to the issue of polling futures. Let?s get back to StructuredExecutor, which should not require polling the future or guarding resultNow except in the special cases I mentioned. ? Ron From ron.pressler at oracle.com Mon Nov 22 11:20:21 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Mon, 22 Nov 2021 11:20:21 +0000 Subject: [External] : Re: Future.resultNow / exceptionNow In-Reply-To: <7A3565FC-F7EF-410D-8777-DAD36634C471@oracle.com> References: <49043D82-9514-4C77-A305-EB4A8C0F8649@oracle.com> <1DA8B0C2-0700-4872-B410-D6875B6D2987@oracle.com> <75BEEF26-1550-404F-9F20-D7D3B771706B@oracle.com> <2E5D142E-896E-440C-8BAC-405B7F777748@oracle.com> <92CE7158-2A55-4633-B44B-B5B7D76B3BC3@oracle.com> <7A3565FC-F7EF-410D-8777-DAD36634C471@oracle.com> Message-ID: Let me put this another way: if you find yourself using StructuredExecutor and calling *any* method on Future other than resultNow, *except* for the rather unusual case of returning a partial result in the event of cancellation or a timeout ? let us know. ? Ron > On 22 Nov 2021, at 11:06, Ron Pressler wrote: > > > >> On 21 Nov 2021, at 21:27, Alex Otenko wrote: >> >> I view it the other way around. Since it is guarding resultNow, should preclude all failures, which means FAILED or CANCELLED (we already know it is not RUNNING). >> > > The only thing that can guard resultNow is `if (f.state() == State.SUCCESS)`, but you?ve taken this discussion to the issue of polling futures. Let?s get back to StructuredExecutor, which should not require polling the future or guarding resultNow except in the special cases I mentioned. > > ? Ron > > From ron.pressler at oracle.com Mon Nov 22 11:24:07 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Mon, 22 Nov 2021 11:24:07 +0000 Subject: [External] : Re: Future.resultNow / exceptionNow In-Reply-To: References: <49043D82-9514-4C77-A305-EB4A8C0F8649@oracle.com> <1DA8B0C2-0700-4872-B410-D6875B6D2987@oracle.com> <75BEEF26-1550-404F-9F20-D7D3B771706B@oracle.com> Message-ID: <30B77226-A853-4A53-9AD6-0D4D45255EB7@oracle.com> On 21 Nov 2021, at 17:45, Eric Kolotyluk > wrote: I am trying to follow all the narratives... Can I conclude that resultNow() does not need to attach any failure information because the assumption is the future succeeded? When resultNow is called incorrectly and fails, it *does* attach complete failure information ? it tells you exactly why the operation failed, with all the information needed to correct the issue. It does not attach additional accidental and irrelevant failure information that does not assist in detecting and fixing the issue. ? Ron From eric at kolotyluk.net Mon Nov 22 15:44:17 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Mon, 22 Nov 2021 07:44:17 -0800 Subject: [External] : Re: Future.resultNow / exceptionNow In-Reply-To: <30B77226-A853-4A53-9AD6-0D4D45255EB7@oracle.com> References: <49043D82-9514-4C77-A305-EB4A8C0F8649@oracle.com> <1DA8B0C2-0700-4872-B410-D6875B6D2987@oracle.com> <75BEEF26-1550-404F-9F20-D7D3B771706B@oracle.com> <30B77226-A853-4A53-9AD6-0D4D45255EB7@oracle.com> Message-ID: Thank you for that precision Ron... Yes, I meant resultNow() does not need to attach deeper "cause" information about the task failure as was being discussed, and it is true that it does throw IllegalStateException, which is sufficient for the context. Cheers, Eric On Mon, Nov 22, 2021 at 3:24 AM Ron Pressler wrote: > > > On 21 Nov 2021, at 17:45, Eric Kolotyluk wrote: > > I am trying to follow all the narratives... > > Can I conclude that resultNow() does not need to attach any failure > information because the assumption is the future succeeded? > > > When resultNow is called incorrectly and fails, it *does* attach complete > failure information ? it tells you exactly why the operation failed, with > all the information needed to correct the issue. It does not attach > additional accidental and irrelevant failure information that does not > assist in detecting and fixing the issue. > > ? Ron > > From pedro.lamarao at prodist.com.br Mon Nov 22 16:12:42 2021 From: pedro.lamarao at prodist.com.br (=?UTF-8?Q?Pedro_Lamar=C3=A3o?=) Date: Mon, 22 Nov 2021 13:12:42 -0300 Subject: Future.resultNow() In-Reply-To: References: <36319248.3362024.1637435663298.JavaMail.zimbra@u-pem.fr> <1273210445.3373193.1637444656131.JavaMail.zimbra@u-pem.fr> <1041679072.3373554.1637445448258.JavaMail.zimbra@u-pem.fr> Message-ID: Em dom., 21 de nov. de 2021 ?s 08:30, Ron Pressler escreveu: > I don?t think that wrapping the underlying exception, if there is one, > would be helpful in pinpointing the bug. If the ISE tells you it?s caused > by an exception, you know you need to correct the program by adding code to > handle exceptions or filter them. What the original exception was is > irrelevant. > I agree with this point and I think that there is a misguided notion of "usability" being defended. If there is a bug that when activated triggers executing invalid code, which is another bug, it may appear that it will be economical to log these two bugs at once, but I think this is a mistake. Whenever one reads a stack trace with inner exceptions, there is a strong force towards considering the inner exception as being somehow the "true bug" and the outer exception as being merely an unfortunate accident. It is counter intuitive that the "inner exception" is a completely different bug than the "outer exception". -- Pedro Lamar?o https://www.prodist.com.br Securing Critical Systems Tel: +55 11 4380-6585 Antes de imprimir esta mensagem e seus anexos, certifique-se que seja realmente necess?rio. Proteger o meio ambiente ? nosso dever. Before printing this e-mail or attachments, be sure it is necessary. It is in our hands to protect the environment. From brian.goetz at oracle.com Mon Nov 22 16:56:15 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 22 Nov 2021 11:56:15 -0500 Subject: Future.resultNow / exceptionNow In-Reply-To: References: Message-ID: <096ea976-2c16-acf1-01c8-7b42032391fe@oracle.com> I spent some time trying to figure out how the discussion on Future::resultNow could have wandered so far afield.? I think there are two causes: 1.? (Not-SE-facing)? Future::resultNow is intended for use with structured concurrency, but it is defined in Future, which is not only not specific to SC, but for which many people bring preconceived notions based on *unstructured* use.? People imagine that it is intended to be used (or at least, OK to use) outside the context of structured concurrency, where it is imaginable that someone will call it on a Future of unknown completion status, and immediately want to try and make it safer in these cases. Our answer to this is: if you're in this situation, you're holding it wrong, and you should be using Future::get. Future::resultNow is designed for when you *already know with certainty* the status.? This happens routinely with structured concurrency, and may occasionally happen with unstructured concurrency, but the latter is not the main target here.? (A valid action item here is that the doc for Future::resultNow needs to be more emphatic about this point.) One might be tempted to respond that even with such disclaimers, it is an attractive nuisance, because it is less ceremonial than Future::get, and therefore people will want to use it when they can, so we should make it more like Future::get by adding seat belts to make it more usable in these cases too.? While that temptation is understandable, it is essentially (in different words) arguing not to include it at all because someone might misuse it.? Which is again a valid opinion, but not actually what's been discussed. 2. (SE-facing) Not realizing the interplay between the result handler and the post-join code.? I think this has unearthed an insufficiency in how we present the concepts. Implicit in each use of ES is a _policy_ for how to deal with an task completion (success or failure).? Examples of sensible policies include: ?- When any failure is encountered, the whole computation completes with failure (call this "invoke all".) ?- When any success is encountered, the whole completes successfully with the result of that task (call this "invoke any".) ?- Ignore failures; return a (possibly empty) list of all successes. ?- Ignore failures as in the previous, but if nothing succeeded, treat the whole computation as a failure. (And policies can get crazier, like "fail if a red task succeeds before any blue tasks fail on days with T in the name.") Part of using SE correctly is *knowing the completion policy* you intend to be using.? SE is a flexible tool, but you need a plan for how you intend to use it. The implementation of a completion policy is spread across two places: ?- the handler(s) passed to SE::fork ?- the code following the call to SE::join We have presented the handler as a lambda that takes the SE and a Future for the task being completed, and it might be in the simplest cases, but most of the time, the handler will be a stateful object that accumulates some state that will be interesting to the code that comes after the SE::join call.? The policy will contain a number of policy-specific outcomes, and should make it possible for the code after the join to find out which one happened. There are canned handlers for the "invoke any" and "invoke all" cases, and they accumulate state differently, and expose different accessors (because they have different sets of possible outcomes).? For the "invoke any" (ShutdownOnSuccess), the handler terminates the computation early when any task completes successfully, *and* keeps track of the first task to complete successfully (and one of the exceptions if no task completed successfully).? It is expected that after the join, you'll ask the handler for the sole completed task with ::result (which throws if there are no results.) For the "invoke all" case (ShutdownOnFailure), the handler keeps track of whether there was a failure, and if there was, its exception.? The first thing you do after joining is ask the handler if something failed; if nothing failed, then it is safe to assume that all tasks have completed successfully with a result.? Hence the example from the Javadoc: ???????? try (var executor = StructuredExecutor.open()) { ????????????? var handler = new ShutdownOnFailure(); ????????????? Future future1 = executor.fork(() -> query(left), handler); ????????????? Future future2 = executor.fork(() -> query(right), handler); ????????????? executor.joinUntil(deadline); ????????????? handler.throwIfFailed(e -> new WebApplicationException(e)); ????????????? // all tasks completed with a result ????????????? String result = Stream.of(future1, future2) ????????????????? .map(Future::resultNow) ????????????????? .collect(Collectors.join(", ", "{ ", " }")); ????????????? : ????????? } I think what might be throwing some of the folks wondering why they can call Future::resultNow here is "how am I sure that it has completed successfully"; the answer is *because the handler, which you used for all tasks, told you so." So, I think what is confusing people is that the following things may not be immediately obvious: ?- That there is a completion policy *at all* ?- That the handler is responsible for managing the state required to differentiate between the cases admitted by the completion policy ?- That after the join, you ask the handler what happened ?- That for each possible answer for a given handler type, there are known postconditions As a matter of API design, I think part of the problem is that the fork method specifies the handler as a mere BiConsumer, rather than a named type like StructuredExecutionPolicy where we can attach some specification about what a policy should do. (This is of course purely pedagogical, not conceptual; the concepts are all there, they're apparently just not as obvious as we'd like them to have been.) On 11/20/2021 11:43 AM, Alex Otenko wrote: > Is there a strong opinion about Future.resultNow and exceptionNow throwing > IllegalStateException? It seems there will likely be boilerplate > try-catching, as there is no safe way to inquire in what way the Future is > isDone. > > Returning Optional seems a nicer alternative. > > Alex From eric at kolotyluk.net Mon Nov 22 19:08:57 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Mon, 22 Nov 2021 11:08:57 -0800 Subject: Future.resultNow / exceptionNow In-Reply-To: <096ea976-2c16-acf1-01c8-7b42032391fe@oracle.com> References: <096ea976-2c16-acf1-01c8-7b42032391fe@oracle.com> Message-ID: Great analysis Brian... IMHO, part of the problem I have with the current design is there does not seem to be an appropriate separation of concerns, rather, concerns are spread around to StructuredExecutor, Future, and Completion Handlers. For example, Future has too many concerns, and resultNow() should be handled somewhere else. Earlier I suggested a consolation of concerns via a Session object with a specific API for handling Structured Concurrency and related concerns; a locus for such concerns. I imagined a StructuredConcurrencySession as the first instance, but also imagined a more generalized Session class, possibly an abstract class or interface. Those are just my fantasies, and other people will imagine differently. It is the legacy of Java to only do as much as necessary, such as Future, then do more later, such as Callable, and eventually CompletableFuture. I can live with that. On the other hand, I really appreciate that Future in Scala is completable with callbacks, and is a more elegant solution than Java. Generally, it is easier for me to reason about concurrency in Scala than Java. Structured Concurrency is a really powerful concept that introduces other powerful concepts, but the current design does not feel intuitive to me. There are too many gotchas. Cheers, Eric On Mon, Nov 22, 2021 at 8:57 AM Brian Goetz wrote: > I spent some time trying to figure out how the discussion on > Future::resultNow could have wandered so far afield. I think there are > two causes: > > 1. (Not-SE-facing) Future::resultNow is intended for use with > structured concurrency, but it is defined in Future, which is not only > not specific to SC, but for which many people bring preconceived notions > based on *unstructured* use. People imagine that it is intended to be > used (or at least, OK to use) outside the context of structured > concurrency, where it is imaginable that someone will call it on a > Future of unknown completion status, and immediately want to try and > make it safer in these cases. > > Our answer to this is: if you're in this situation, you're holding it > wrong, and you should be using Future::get. Future::resultNow is > designed for when you *already know with certainty* the status. This > happens routinely with structured concurrency, and may occasionally > happen with unstructured concurrency, but the latter is not the main > target here. (A valid action item here is that the doc for > Future::resultNow needs to be more emphatic about this point.) > > One might be tempted to respond that even with such disclaimers, it is > an attractive nuisance, because it is less ceremonial than Future::get, > and therefore people will want to use it when they can, so we should > make it more like Future::get by adding seat belts to make it more > usable in these cases too. While that temptation is understandable, it > is essentially (in different words) arguing not to include it at all > because someone might misuse it. Which is again a valid opinion, but > not actually what's been discussed. > > > 2. (SE-facing) Not realizing the interplay between the result handler > and the post-join code. I think this has unearthed an insufficiency in > how we present the concepts. > > Implicit in each use of ES is a _policy_ for how to deal with an task > completion (success or failure). Examples of sensible policies include: > > - When any failure is encountered, the whole computation completes > with failure (call this "invoke all".) > > - When any success is encountered, the whole completes successfully > with the result of that task (call this "invoke any".) > > - Ignore failures; return a (possibly empty) list of all successes. > > - Ignore failures as in the previous, but if nothing succeeded, treat > the whole computation as a failure. > > (And policies can get crazier, like "fail if a red task succeeds before > any blue tasks fail on days with T in the name.") > > Part of using SE correctly is *knowing the completion policy* you intend > to be using. SE is a flexible tool, but you need a plan for how you > intend to use it. > > The implementation of a completion policy is spread across two places: > > - the handler(s) passed to SE::fork > - the code following the call to SE::join > > We have presented the handler as a lambda that takes the SE and a Future > for the task being completed, and it might be in the simplest cases, but > most of the time, the handler will be a stateful object that accumulates > some state that will be interesting to the code that comes after the > SE::join call. The policy will contain a number of policy-specific > outcomes, and should make it possible for the code after the join to > find out which one happened. > > There are canned handlers for the "invoke any" and "invoke all" cases, > and they accumulate state differently, and expose different accessors > (because they have different sets of possible outcomes). For the > "invoke any" (ShutdownOnSuccess), the handler terminates the computation > early when any task completes successfully, *and* keeps track of the > first task to complete successfully (and one of the exceptions if no > task completed successfully). It is expected that after the join, > you'll ask the handler for the sole completed task with ::result (which > throws if there are no results.) > > For the "invoke all" case (ShutdownOnFailure), the handler keeps track > of whether there was a failure, and if there was, its exception. The > first thing you do after joining is ask the handler if something failed; > if nothing failed, then it is safe to assume that all tasks have > completed successfully with a result. Hence the example from the Javadoc: > > try (var executor = StructuredExecutor.open()) { > var handler = new ShutdownOnFailure(); > > Future future1 = executor.fork(() -> query(left), > handler); > Future future2 = executor.fork(() -> > query(right), handler); > > executor.joinUntil(deadline); > > handler.throwIfFailed(e -> new WebApplicationException(e)); > > // all tasks completed with a result > String result = Stream.of(future1, future2) > .map(Future::resultNow) > .collect(Collectors.join(", ", "{ ", " }")); > > : > } > > I think what might be throwing some of the folks wondering why they can > call Future::resultNow here is "how am I sure that it has completed > successfully"; the answer is *because the handler, which you used for > all tasks, told you so." > > > So, I think what is confusing people is that the following things may > not be immediately obvious: > > - That there is a completion policy *at all* > - That the handler is responsible for managing the state required to > differentiate between the cases admitted by the completion policy > - That after the join, you ask the handler what happened > - That for each possible answer for a given handler type, there are > known postconditions > > As a matter of API design, I think part of the problem is that the fork > method specifies the handler as a mere BiConsumer, rather than a named > type like StructuredExecutionPolicy where we can attach some > specification about what a policy should do. (This is of course purely > pedagogical, not conceptual; the concepts are all there, they're > apparently just not as obvious as we'd like them to have been.) > > > On 11/20/2021 11:43 AM, Alex Otenko wrote: > > Is there a strong opinion about Future.resultNow and exceptionNow > throwing > > IllegalStateException? It seems there will likely be boilerplate > > try-catching, as there is no safe way to inquire in what way the Future > is > > isDone. > > > > Returning Optional seems a nicer alternative. > > > > Alex > From oleksandr.otenko at gmail.com Mon Nov 22 20:50:39 2021 From: oleksandr.otenko at gmail.com (Alex Otenko) Date: Mon, 22 Nov 2021 20:50:39 +0000 Subject: Future.resultNow / exceptionNow In-Reply-To: <096ea976-2c16-acf1-01c8-7b42032391fe@oracle.com> References: <096ea976-2c16-acf1-01c8-7b42032391fe@oracle.com> Message-ID: Thank you Brian. I am in the "didn't think of a policy at all" camp, plus a layer of "exceptionNow provides a constructive proof of exception happening". The latter makes me wonder why it should throw at all - it just provides a witness, or none. This is similar to callbacks providing an exception and a result, one of them null. Having to inspect State is a bit of indirection, which would be fine, were it not for subtleties to watch out for. Similar with resultNow, just I am not suggesting to return null. Alex On Mon, 22 Nov 2021, 16:56 Brian Goetz, wrote: > I spent some time trying to figure out how the discussion on > Future::resultNow could have wandered so far afield. I think there are two > causes: > > 1. (Not-SE-facing) Future::resultNow is intended for use with structured > concurrency, but it is defined in Future, which is not only not specific to > SC, but for which many people bring preconceived notions based on > *unstructured* use. People imagine that it is intended to be used (or at > least, OK to use) outside the context of structured concurrency, where it > is imaginable that someone will call it on a Future of unknown completion > status, and immediately want to try and make it safer in these cases. > > Our answer to this is: if you're in this situation, you're holding it > wrong, and you should be using Future::get. Future::resultNow is designed > for when you *already know with certainty* the status. This happens > routinely with structured concurrency, and may occasionally happen with > unstructured concurrency, but the latter is not the main target here. (A > valid action item here is that the doc for Future::resultNow needs to be > more emphatic about this point.) > > One might be tempted to respond that even with such disclaimers, it is an > attractive nuisance, because it is less ceremonial than Future::get, and > therefore people will want to use it when they can, so we should make it > more like Future::get by adding seat belts to make it more usable in these > cases too. While that temptation is understandable, it is essentially (in > different words) arguing not to include it at all because someone might > misuse it. Which is again a valid opinion, but not actually what's been > discussed. > > > 2. (SE-facing) Not realizing the interplay between the result handler > and the post-join code. I think this has unearthed an insufficiency in how > we present the concepts. > > Implicit in each use of ES is a _policy_ for how to deal with an task > completion (success or failure). Examples of sensible policies include: > > - When any failure is encountered, the whole computation completes with > failure (call this "invoke all".) > > - When any success is encountered, the whole completes successfully with > the result of that task (call this "invoke any".) > > - Ignore failures; return a (possibly empty) list of all successes. > > - Ignore failures as in the previous, but if nothing succeeded, treat the > whole computation as a failure. > > (And policies can get crazier, like "fail if a red task succeeds before > any blue tasks fail on days with T in the name.") > > Part of using SE correctly is *knowing the completion policy* you intend > to be using. SE is a flexible tool, but you need a plan for how you intend > to use it. > > The implementation of a completion policy is spread across two places: > > - the handler(s) passed to SE::fork > - the code following the call to SE::join > > We have presented the handler as a lambda that takes the SE and a Future > for the task being completed, and it might be in the simplest cases, but > most of the time, the handler will be a stateful object that accumulates > some state that will be interesting to the code that comes after the > SE::join call. The policy will contain a number of policy-specific > outcomes, and should make it possible for the code after the join to find > out which one happened. > > There are canned handlers for the "invoke any" and "invoke all" cases, and > they accumulate state differently, and expose different accessors (because > they have different sets of possible outcomes). For the "invoke any" > (ShutdownOnSuccess), the handler terminates the computation early when any > task completes successfully, *and* keeps track of the first task to > complete successfully (and one of the exceptions if no task completed > successfully). It is expected that after the join, you'll ask the handler > for the sole completed task with ::result (which throws if there are no > results.) > > For the "invoke all" case (ShutdownOnFailure), the handler keeps track of > whether there was a failure, and if there was, its exception. The first > thing you do after joining is ask the handler if something failed; if > nothing failed, then it is safe to assume that all tasks have completed > successfully with a result. Hence the example from the Javadoc: > > try (var executor = StructuredExecutor.open()) { > var handler = new ShutdownOnFailure(); > > Future future1 = executor.fork(() -> query(left), > handler); > Future future2 = executor.fork(() -> query(right), > handler); > > executor.joinUntil(deadline); > > handler.throwIfFailed(e -> new WebApplicationException(e)); > > // all tasks completed with a result > String result = Stream.of(future1, future2) > .map(Future::resultNow) > .collect(Collectors.join(", ", "{ ", " }")); > > : > } > > I think what might be throwing some of the folks wondering why they can > call Future::resultNow here is "how am I sure that it has completed > successfully"; the answer is *because the handler, which you used for all > tasks, told you so." > > > So, I think what is confusing people is that the following things may not > be immediately obvious: > > - That there is a completion policy *at all* > - That the handler is responsible for managing the state required to > differentiate between the cases admitted by the completion policy > - That after the join, you ask the handler what happened > - That for each possible answer for a given handler type, there are known > postconditions > > As a matter of API design, I think part of the problem is that the fork > method specifies the handler as a mere BiConsumer, rather than a named type > like StructuredExecutionPolicy where we can attach some specification about > what a policy should do. (This is of course purely pedagogical, not > conceptual; the concepts are all there, they're apparently just not as > obvious as we'd like them to have been.) > > > On 11/20/2021 11:43 AM, Alex Otenko wrote: > > Is there a strong opinion about Future.resultNow and exceptionNow throwing > IllegalStateException? It seems there will likely be boilerplate > try-catching, as there is no safe way to inquire in what way the Future is > isDone. > > Returning Optional seems a nicer alternative. > > Alex > > > From paul.bjorkstrand at gmail.com Mon Nov 22 21:01:47 2021 From: paul.bjorkstrand at gmail.com (Paul Bjorkstrand) Date: Mon, 22 Nov 2021 15:01:47 -0600 Subject: Future.resultNow / exceptionNow In-Reply-To: References: <096ea976-2c16-acf1-01c8-7b42032391fe@oracle.com> Message-ID: I agree with Alex, Brian's explanation cleared up a lot of confusion for me. I think I understand now why attaching the cause is unnecessary and I suspect with a release, better documentation & examples will make the mistake I made less common. Thank you for that! While I don't have full code examples, I do have some snippets sort of documenting a bit of my journey with StructuredExecutors + some suggestions. See this Gist for the details, but I'll summarize suggestions below: https://gist.github.com/paul-bjorkstrand/43bb8335453aa1eccb982b54556d7633 Suggestions: 1. Add another built-in "handler" that is similar to ShutdownOnFailure, but only tracks the first failure, and does not shut down the executor. This is for cases when you want everything to try to complete, but want to report an error that occurred. 2. Add an overload for providing a "handler" that is used as a default for all calls of .fork() that do not provide an explicit handler. I don't have a good use case for this one, but I could see the benefit in boilerplate reduction. 3. Add a "handler" that does the same as #1 above, which can either be obtained by StructuredExecutor.handler() OR build the throwIfFailed() methods right into StructuredExecutor. Same use-cases as #1. -Paul On Mon, Nov 22, 2021 at 2:51 PM Alex Otenko wrote: > Thank you Brian. I am in the "didn't think of a policy at all" camp, plus a > layer of "exceptionNow provides a constructive proof of exception > happening". The latter makes me wonder why it should throw at all - it just > provides a witness, or none. This is similar to callbacks providing an > exception and a result, one of them null. Having to inspect State is a bit > of indirection, which would be fine, were it not for subtleties to watch > out for. > > Similar with resultNow, just I am not suggesting to return null. > > Alex > > On Mon, 22 Nov 2021, 16:56 Brian Goetz, wrote: > > > I spent some time trying to figure out how the discussion on > > Future::resultNow could have wandered so far afield. I think there are > two > > causes: > > > > 1. (Not-SE-facing) Future::resultNow is intended for use with > structured > > concurrency, but it is defined in Future, which is not only not specific > to > > SC, but for which many people bring preconceived notions based on > > *unstructured* use. People imagine that it is intended to be used (or at > > least, OK to use) outside the context of structured concurrency, where it > > is imaginable that someone will call it on a Future of unknown completion > > status, and immediately want to try and make it safer in these cases. > > > > Our answer to this is: if you're in this situation, you're holding it > > wrong, and you should be using Future::get. Future::resultNow is > designed > > for when you *already know with certainty* the status. This happens > > routinely with structured concurrency, and may occasionally happen with > > unstructured concurrency, but the latter is not the main target here. (A > > valid action item here is that the doc for Future::resultNow needs to be > > more emphatic about this point.) > > > > One might be tempted to respond that even with such disclaimers, it is an > > attractive nuisance, because it is less ceremonial than Future::get, and > > therefore people will want to use it when they can, so we should make it > > more like Future::get by adding seat belts to make it more usable in > these > > cases too. While that temptation is understandable, it is essentially > (in > > different words) arguing not to include it at all because someone might > > misuse it. Which is again a valid opinion, but not actually what's been > > discussed. > > > > > > 2. (SE-facing) Not realizing the interplay between the result handler > > and the post-join code. I think this has unearthed an insufficiency in > how > > we present the concepts. > > > > Implicit in each use of ES is a _policy_ for how to deal with an task > > completion (success or failure). Examples of sensible policies include: > > > > - When any failure is encountered, the whole computation completes with > > failure (call this "invoke all".) > > > > - When any success is encountered, the whole completes successfully with > > the result of that task (call this "invoke any".) > > > > - Ignore failures; return a (possibly empty) list of all successes. > > > > - Ignore failures as in the previous, but if nothing succeeded, treat > the > > whole computation as a failure. > > > > (And policies can get crazier, like "fail if a red task succeeds before > > any blue tasks fail on days with T in the name.") > > > > Part of using SE correctly is *knowing the completion policy* you intend > > to be using. SE is a flexible tool, but you need a plan for how you > intend > > to use it. > > > > The implementation of a completion policy is spread across two places: > > > > - the handler(s) passed to SE::fork > > - the code following the call to SE::join > > > > We have presented the handler as a lambda that takes the SE and a Future > > for the task being completed, and it might be in the simplest cases, but > > most of the time, the handler will be a stateful object that accumulates > > some state that will be interesting to the code that comes after the > > SE::join call. The policy will contain a number of policy-specific > > outcomes, and should make it possible for the code after the join to find > > out which one happened. > > > > There are canned handlers for the "invoke any" and "invoke all" cases, > and > > they accumulate state differently, and expose different accessors > (because > > they have different sets of possible outcomes). For the "invoke any" > > (ShutdownOnSuccess), the handler terminates the computation early when > any > > task completes successfully, *and* keeps track of the first task to > > complete successfully (and one of the exceptions if no task completed > > successfully). It is expected that after the join, you'll ask the > handler > > for the sole completed task with ::result (which throws if there are no > > results.) > > > > For the "invoke all" case (ShutdownOnFailure), the handler keeps track of > > whether there was a failure, and if there was, its exception. The first > > thing you do after joining is ask the handler if something failed; if > > nothing failed, then it is safe to assume that all tasks have completed > > successfully with a result. Hence the example from the Javadoc: > > > > try (var executor = StructuredExecutor.open()) { > > var handler = new ShutdownOnFailure(); > > > > Future future1 = executor.fork(() -> query(left), > > handler); > > Future future2 = executor.fork(() -> query(right), > > handler); > > > > executor.joinUntil(deadline); > > > > handler.throwIfFailed(e -> new WebApplicationException(e)); > > > > // all tasks completed with a result > > String result = Stream.of(future1, future2) > > .map(Future::resultNow) > > .collect(Collectors.join(", ", "{ ", " }")); > > > > : > > } > > > > I think what might be throwing some of the folks wondering why they can > > call Future::resultNow here is "how am I sure that it has completed > > successfully"; the answer is *because the handler, which you used for all > > tasks, told you so." > > > > > > So, I think what is confusing people is that the following things may not > > be immediately obvious: > > > > - That there is a completion policy *at all* > > - That the handler is responsible for managing the state required to > > differentiate between the cases admitted by the completion policy > > - That after the join, you ask the handler what happened > > - That for each possible answer for a given handler type, there are > known > > postconditions > > > > As a matter of API design, I think part of the problem is that the fork > > method specifies the handler as a mere BiConsumer, rather than a named > type > > like StructuredExecutionPolicy where we can attach some specification > about > > what a policy should do. (This is of course purely pedagogical, not > > conceptual; the concepts are all there, they're apparently just not as > > obvious as we'd like them to have been.) > > > > > > On 11/20/2021 11:43 AM, Alex Otenko wrote: > > > > Is there a strong opinion about Future.resultNow and exceptionNow > throwing > > IllegalStateException? It seems there will likely be boilerplate > > try-catching, as there is no safe way to inquire in what way the Future > is > > isDone. > > > > Returning Optional seems a nicer alternative. > > > > Alex > > > > > > > From brian.goetz at oracle.com Mon Nov 22 21:12:38 2021 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 22 Nov 2021 16:12:38 -0500 Subject: [External] : Re: Future.resultNow / exceptionNow In-Reply-To: References: <096ea976-2c16-acf1-01c8-7b42032391fe@oracle.com> Message-ID: <0c81a6ea-4d00-665e-065d-a599043a51df@oracle.com> > The implementation of a completion policy is spread across two places: > > ?- the handler(s) passed to SE::fork > ?- the code following the call to SE::join I'll add that it is harder to see this because the two policies we've specified -- have ad-hoc result states and APIs -- and also have methods that fuse state access with side effects.? (In other words, they're typical bespoke OO APIs.)? One could imagine a more functional approach, where all handlers had a more regularized API: ??? interface Handler { ??????? void accept(StructuredExecutor se, Future task); ??????? S state(); ??? } where S would be an algebraic data type (sum of products) representing the state.? Then we might define ShutdownOnFailure as implementing Handler where: ??? sealed interface SOFStates { ??????? record AllGood() extends SOFStates { } ??????? record GotException(Exception e) extends SOFStates { } ??? } then using it would look like: ??? try (var executor = SE.open()) { ??????? var handler = new ShutdownOnFailure(); ??????? // forking and joining ??????? switch (handler.state()) { ??????????? case AllGood _ -> return Stream.of(future1, future2)...; ??????????? case GotException(var e) -> throw new WAE(e); ?????? } ?? } I'm not suggesting that we do, or don't, redefine the handler API like this; I'm offering this as an explanation of why it might have been hard to see the relationship between the policy states and the code that follows the join.? By regularizing the policy states, we ask handler writers/users to engage in some more ceremony (declaring an ADT for their state), but regularizing their API and giving users a stronger nudge towards proper usage. From forax at univ-mlv.fr Mon Nov 22 21:36:18 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 22 Nov 2021 22:36:18 +0100 (CET) Subject: [External] : Re: Future.resultNow / exceptionNow In-Reply-To: <0c81a6ea-4d00-665e-065d-a599043a51df@oracle.com> References: <096ea976-2c16-acf1-01c8-7b42032391fe@oracle.com> <0c81a6ea-4d00-665e-065d-a599043a51df@oracle.com> Message-ID: <246827998.694169.1637616978853.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "Brian Goetz" > To: "Alex Otenko" > Cc: "loom-dev" > Sent: Lundi 22 Novembre 2021 22:12:38 > Subject: Re: [External] : Re: Future.resultNow / exceptionNow >> The implementation of a completion policy is spread across two places: >> >> ?- the handler(s) passed to SE::fork >> ?- the code following the call to SE::join > > I'll add that it is harder to see this because the two policies we've > specified -- have ad-hoc result states and APIs -- and also have methods > that fuse state access with side effects.? (In other words, they're > typical bespoke OO APIs.)? One could imagine a more functional approach, > where all handlers had a more regularized API: > > ??? interface Handler { > ??????? void accept(StructuredExecutor se, Future task); > > ??????? S state(); > ??? } > > where S would be an algebraic data type (sum of products) representing > the state.? Then we might define ShutdownOnFailure as implementing > Handler where: > > ??? sealed interface SOFStates { > ??????? record AllGood() extends SOFStates { } > ??????? record GotException(Exception e) extends SOFStates { } > ??? } > > then using it would look like: > > ??? try (var executor = SE.open()) { > ??????? var handler = new ShutdownOnFailure(); > > ??????? // forking and joining > > ??????? switch (handler.state()) { > ??????????? case AllGood _ -> return Stream.of(future1, future2)...; > ??????????? case GotException(var e) -> throw new WAE(e); > ?????? } > ?? } > > I'm not suggesting that we do, or don't, redefine the handler API like > this; I'm offering this as an explanation of why it might have been hard > to see the relationship between the policy states and the code that > follows the join.? By regularizing the policy states, we ask handler > writers/users to engage in some more ceremony (declaring an ADT for > their state), but regularizing their API and giving users a stronger > nudge towards proper usage. You can standardize the API without having the method state() at the interface level. In your example, you call ShutdownOnFailure::state() not Handler::state(). And why stop at having a method state() on the Handler and not make fork() and join() part of the Handler API too. It will be a useful simplification because you will be able to merge join() + state() into one method most of the time. And you can have a specialized version fork() by example to return a Future or not depending on the semantics of the Handler. R?mi From ron.pressler at oracle.com Mon Nov 22 21:36:50 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Mon, 22 Nov 2021 21:36:50 +0000 Subject: Future.resultNow / exceptionNow In-Reply-To: References: <096ea976-2c16-acf1-01c8-7b42032391fe@oracle.com> Message-ID: <29B7BF63-7721-4F1F-9E55-7C3E36FD8536@oracle.com> > On 22 Nov 2021, at 21:01, Paul Bjorkstrand wrote: > > While I don't have full code examples, I do have some snippets sort of > documenting a bit of my journey with StructuredExecutors + some > suggestions. See this Gist for the details, but I'll summarize suggestions > below: > https://gist.github.com/paul-bjorkstrand/43bb8335453aa1eccb982b54556d7633 Thank you! > > Suggestions: > 1. Add another built-in "handler" that is similar to ShutdownOnFailure, but > only tracks the first failure, and does not shut down the executor. This is > for cases when you want everything to try to complete, but want to report > an error that occurred. Can you give a concrete example of when you?d want that? ? Ron From oleksandr.otenko at gmail.com Mon Nov 22 21:44:02 2021 From: oleksandr.otenko at gmail.com (Alex Otenko) Date: Mon, 22 Nov 2021 21:44:02 +0000 Subject: [External] : Re: Future.resultNow / exceptionNow In-Reply-To: <7A3565FC-F7EF-410D-8777-DAD36634C471@oracle.com> References: <49043D82-9514-4C77-A305-EB4A8C0F8649@oracle.com> <1DA8B0C2-0700-4872-B410-D6875B6D2987@oracle.com> <75BEEF26-1550-404F-9F20-D7D3B771706B@oracle.com> <2E5D142E-896E-440C-8BAC-405B7F777748@oracle.com> <92CE7158-2A55-4633-B44B-B5B7D76B3BC3@oracle.com> <7A3565FC-F7EF-410D-8777-DAD36634C471@oracle.com> Message-ID: Correct, hence the fuss around state != SUCCESS for the opposite condition. As for examples of when you'd need this - I think commonly I want to start processing the responses as soon as they start arriving, not wait for them all to complete. Maybe in this brave new world things just get expressed differently, but I would need something like "wait for the first" (that's "any" semantics), process, then "wait for the next", etc. Processing like this is more efficient than waiting for all, then process all, and less complex than processing each response in the task, as there is no concurrency in sequential processing of responses. Alex On Mon, 22 Nov 2021, 11:06 Ron Pressler, wrote: > > > > On 21 Nov 2021, at 21:27, Alex Otenko > wrote: > > > > I view it the other way around. Since it is guarding resultNow, should > preclude all failures, which means FAILED or CANCELLED (we already know it > is not RUNNING). > > > > The only thing that can guard resultNow is `if (f.state() == > State.SUCCESS)`, but you?ve taken this discussion to the issue of polling > futures. Let?s get back to StructuredExecutor, which should not require > polling the future or guarding resultNow except in the special cases I > mentioned. > > ? Ron > > > From ron.pressler at oracle.com Mon Nov 22 22:56:57 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Mon, 22 Nov 2021 22:56:57 +0000 Subject: [External] : Re: Future.resultNow / exceptionNow In-Reply-To: References: <49043D82-9514-4C77-A305-EB4A8C0F8649@oracle.com> <1DA8B0C2-0700-4872-B410-D6875B6D2987@oracle.com> <75BEEF26-1550-404F-9F20-D7D3B771706B@oracle.com> <2E5D142E-896E-440C-8BAC-405B7F777748@oracle.com> <92CE7158-2A55-4633-B44B-B5B7D76B3BC3@oracle.com> <7A3565FC-F7EF-410D-8777-DAD36634C471@oracle.com> Message-ID: > On 22 Nov 2021, at 21:44, Alex Otenko wrote: > > Correct, hence the fuss around state != SUCCESS for the opposite condition. > > As for examples of when you'd need this - I think commonly I want to start processing the responses as soon as they start arriving, not wait for them all to complete. > > Maybe in this brave new world things just get expressed differently, but I would need something like "wait for the first" (that's "any" semantics), process, then "wait for the next", etc. Processing like this is more efficient than waiting for all, then process all, and less complex than processing each response in the task, as there is no concurrency in sequential processing of responses. > > Alex Have the completion handler (or the task itself) place the result into a blocking queue that you will then consume from the parent. There?s no need to poll futures. ? Ron From ron.pressler at oracle.com Mon Nov 22 23:00:27 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Mon, 22 Nov 2021 23:00:27 +0000 Subject: [External] : Re: Future.resultNow / exceptionNow In-Reply-To: References: <49043D82-9514-4C77-A305-EB4A8C0F8649@oracle.com> <1DA8B0C2-0700-4872-B410-D6875B6D2987@oracle.com> <75BEEF26-1550-404F-9F20-D7D3B771706B@oracle.com> <2E5D142E-896E-440C-8BAC-405B7F777748@oracle.com> <92CE7158-2A55-4633-B44B-B5B7D76B3BC3@oracle.com> <7A3565FC-F7EF-410D-8777-DAD36634C471@oracle.com> Message-ID: <30D4724D-D846-4FC9-9296-246D2CCE66DC@oracle.com> > On 22 Nov 2021, at 22:56, Ron Pressler wrote: > > > >> On 22 Nov 2021, at 21:44, Alex Otenko wrote: >> >> Correct, hence the fuss around state != SUCCESS for the opposite condition. >> >> As for examples of when you'd need this - I think commonly I want to start processing the responses as soon as they start arriving, not wait for them all to complete. >> >> Maybe in this brave new world things just get expressed differently, but I would need something like "wait for the first" (that's "any" semantics), process, then "wait for the next", etc. Processing like this is more efficient than waiting for all, then process all, and less complex than processing each response in the task, as there is no concurrency in sequential processing of responses. >> >> Alex > > Have the completion handler (or the task itself) place the result into a blocking queue that you will then consume from the parent. There?s no need to poll futures. > > ? Ron P.S. Just note that if you?re concerned about this level of efficiency, the ?handle results as they come on a different thread? approach introduces a scheduling event (i.e. an unpack) for each completed task rather than just a single one when relying on join. ? Ron From paul.bjorkstrand at gmail.com Mon Nov 22 23:41:58 2021 From: paul.bjorkstrand at gmail.com (Paul Bjorkstrand) Date: Mon, 22 Nov 2021 17:41:58 -0600 Subject: Future.resultNow / exceptionNow In-Reply-To: <29B7BF63-7721-4F1F-9E55-7C3E36FD8536@oracle.com> References: <096ea976-2c16-acf1-01c8-7b42032391fe@oracle.com> <29B7BF63-7721-4F1F-9E55-7C3E36FD8536@oracle.com> Message-ID: > > > > > > Suggestions: > > 1. Add another built-in "handler" that is similar to ShutdownOnFailure, > but > > only tracks the first failure, and does not shut down the executor. This > is > > for cases when you want everything to try to complete, but want to report > > an error that occurred. > > Can you give a concrete example of when you?d want that? > I don't have any for that specific case, but a similar case: allowing all to complete and reporting all exceptions (via some AggregateException that contains more than one "cause"): In the past I built a metrics-tracking system that reported data to multiple remote APIs. While it was not good if something failed, it wasn't mission critical if one or two failed from time to time, while the rest succeeded. Even though we didn't care that things failed, in terms that the application could continue running, we did need to know what those failures were so we could identify and troubleshoot the errors. In this case, we didn't care about the responses, but only cared about the errors, for logging. Thinking about it, it would be relatively simple to filter down the list of futures to those ones that completed exceptionally, but having some way to do it that didn't require a lambda with an == test in it would be convenient. Even static util methods like Future.State.isXxx, for each of the states would be helpful, so you can use State::isXxx instead of the lambda. I completely understand if we want to wait on that kind of addition until more is learned from the preview. I wish I had some project in my back pocket that I could use to test out Structured Concurrency more, but my tinkerings have me interested in learning where else it can be useful. I look forward to seeing how some of the Loom subprojects come together, specifically Scope Locals & Structured Concurrency. Great work so far! -Paul From Alan.Bateman at oracle.com Tue Nov 23 08:17:42 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 23 Nov 2021 08:17:42 +0000 Subject: Future.resultNow / exceptionNow In-Reply-To: References: <096ea976-2c16-acf1-01c8-7b42032391fe@oracle.com> <29B7BF63-7721-4F1F-9E55-7C3E36FD8536@oracle.com> Message-ID: On 22/11/2021 23:41, Paul Bjorkstrand wrote: > : > I wish I had some project in my back pocket that I could use to test out > Structured Concurrency more, but my tinkerings have me interested in > learning where else it can be useful. I look forward to seeing how some of > the Loom subprojects come together, specifically Scope Locals & Structured > Concurrency. Great work so far! They are working together so you should be able to play with this. Specifically, when you invoke fork to start thread in a structured context then it inherits the scope-locals bindings. -Alan From pedro.lamarao at gmail.com Tue Nov 23 01:49:39 2021 From: pedro.lamarao at gmail.com (=?UTF-8?Q?Pedro_Lamar=C3=A3o?=) Date: Mon, 22 Nov 2021 22:49:39 -0300 Subject: Generators Message-ID: Hello all! Thank you once more for your amazing work on Project Loom! I have been experimenting with building servers with Loom and the promise of simpler code has been fulfilled so far. I have advanced my experiments to the HTTP protocol [1]. In this experiment, I have applied Jetty's HttpParser class, which uses a state machine to implement a push parser. I understand Loom is attempting to deliver and scope is being minimized for this purpose, but, since we entered experimental terrain with StructuredExecutor... Could you be convinced to expose an experimental continuation based Generator? Doing a Generator based HttpParser would allow an HTTP server with full ease of debugability. Anyway, again, thanks again! In the early days of Loom, when Continuation was usable, I experimented with a simple DER parser and it was very, very interesting. [2] [1] https://github.com/pedrolamarao/sandbox-loom-http [2] https://github.com/pedrolamarao/loom -- Pedro Lamar?o From ron.pressler at oracle.com Tue Nov 23 12:25:01 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Tue, 23 Nov 2021 12:25:01 +0000 Subject: Generators In-Reply-To: References: Message-ID: > On 23 Nov 2021, at 01:49, Pedro Lamar?o wrote: > > Hello all! > Thank you once more for your amazing work on Project Loom! > I have been experimenting with building servers with Loom and the promise > of simpler code has been fulfilled so far. > I have advanced my experiments to the HTTP protocol [1]. > In this experiment, I have applied Jetty's HttpParser class, which uses a > state machine to implement a push parser. > I understand Loom is attempting to deliver and scope is being minimized for > this purpose, but, since we entered experimental terrain with > StructuredExecutor... > Could you be convinced to expose an experimental continuation based > Generator? Sure! It?s just a matter of priorities. > Doing a Generator based HttpParser would allow an HTTP server with > full ease of debugability. > Anyway, again, thanks again! > In the early days of Loom, when Continuation was usable, I experimented > with a simple DER parser and it was very, very interesting. [2] > > [1] https://github.com/pedrolamarao/sandbox-loom-http > > [2] https://github.com/pedrolamarao/loom > Thank you, I?ll take a look. ? Ron From mbazos at gmail.com Tue Nov 23 20:25:32 2021 From: mbazos at gmail.com (Michael Bazos) Date: Tue, 23 Nov 2021 15:25:32 -0500 Subject: Questions on Build 18-loom+5-274 (2021/11/15) In-Reply-To: <8fca5fb4-955c-c02d-53fa-87dc4cce8184@oracle.com> References: <8fca5fb4-955c-c02d-53fa-87dc4cce8184@oracle.com> Message-ID: Alan, Just wanted to let you know I took some high volume applications I work on that rely heavily on Executors and was easily able to switch to newVirtualThreadPerTaskExecutor and everything appears to be working well. Looking forward to the preview feature when it's ready. Mike On Fri, Nov 19, 2021 at 3:03 PM Alan Bateman wrote: > On 19/11/2021 19:15, Michael Bazos wrote: > > I started doing some experimenting with project loom an observed a few > > things and wasn't sure how to explain them or why it was happening: > > > > 1. I noticed when using Executors.newVirtualThreadPerTaskExecutor() > > submitting tasks and then calling 'shutdown()' on the executor > service, the > > virtual thread per task executor does not wait for tasks to finish. > This > > seems to behave a little differently than the OS based thread pool > > executors. I assume this is intended but just wanted to know why. > ExecutorService::shutdown is specified to not wait so the behavior you > observe is correct. You can use awaitTermination, or the new close > method, to wait for termination. Are you sure you've observed the > shutdown of other ExecutorService implementation wait, just curious. > > > 2. Playing with StructuredExecutor I can see the example of using it > > with try-with-resources which is clean and looks nice. I was > surprised to > > see `isShutdown()` as private on the StructuredExecutor. I am just > > wondering if a client didn't use try-with-resources there would be > some > > value in allowing a client to know if the executor is shutdown or > not. My > > best guess is the intention here is to minimize what is exposed from > the > > API. > If there is a case for exposing the state then it could be done. > > > > 3. My final question which is semi related to Question 2 I haven't > done > > any benchmarking myself yet but I know creating OS based executor > thread > > pools can be considered an "expensive" operation. Obviously this is > very > > different when doing this with virtual thread task executor. Does > using > > virtual thread task executor mean this is cheap to create and > shutdown? > > Typically in client code you wouldn't want to create/destroy task > executors > > during the lifecycle of an application. > The intention is that this should be very cheap to create and close. > > > Also I did some tests and I couldn't believe how many virtual threads I > > could spin up on my machine versus OS threads. Seems like memory would be > > the limit but the difference was ~3000 OS threads vs ~5 million+ virtual > > threads. > > > > When I have time going to integrate the early loom builds into some real > > applications to see how it behaves. I very much look forward to not > having > > to worry about configuring thread pools in the future, very excited and > > keep up the good work! > > > Good, please let me know how you get on. > > -Alan > From eric at kolotyluk.net Tue Nov 23 20:42:08 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Tue, 23 Nov 2021 12:42:08 -0800 Subject: Questions on Build 18-loom+5-274 (2021/11/15) In-Reply-To: References: <8fca5fb4-955c-c02d-53fa-87dc4cce8184@oracle.com> Message-ID: Mike, as I have discovered, StructuredExecutor.open() functions like newVirtualThreadPerTaskExecutor(), one thread per task. While initially, I experimented with newVirtualThreadPerTaskExecutor(), I now only use StructuredExecutor because it's a better solution. Cheers, Eric On Tue, Nov 23, 2021 at 12:26 PM Michael Bazos wrote: > Alan, > Just wanted to let you know I took some high volume applications I work on > that rely heavily on Executors and was easily able to switch to > newVirtualThreadPerTaskExecutor and everything appears to be working well. > Looking forward to the preview feature when it's ready. > > Mike > > On Fri, Nov 19, 2021 at 3:03 PM Alan Bateman > wrote: > > > On 19/11/2021 19:15, Michael Bazos wrote: > > > I started doing some experimenting with project loom an observed a few > > > things and wasn't sure how to explain them or why it was happening: > > > > > > 1. I noticed when using Executors.newVirtualThreadPerTaskExecutor() > > > submitting tasks and then calling 'shutdown()' on the executor > > service, the > > > virtual thread per task executor does not wait for tasks to finish. > > This > > > seems to behave a little differently than the OS based thread pool > > > executors. I assume this is intended but just wanted to know why. > > ExecutorService::shutdown is specified to not wait so the behavior you > > observe is correct. You can use awaitTermination, or the new close > > method, to wait for termination. Are you sure you've observed the > > shutdown of other ExecutorService implementation wait, just curious. > > > > > 2. Playing with StructuredExecutor I can see the example of using > it > > > with try-with-resources which is clean and looks nice. I was > > surprised to > > > see `isShutdown()` as private on the StructuredExecutor. I am just > > > wondering if a client didn't use try-with-resources there would be > > some > > > value in allowing a client to know if the executor is shutdown or > > not. My > > > best guess is the intention here is to minimize what is exposed > from > > the > > > API. > > If there is a case for exposing the state then it could be done. > > > > > > > 3. My final question which is semi related to Question 2 I haven't > > done > > > any benchmarking myself yet but I know creating OS based executor > > thread > > > pools can be considered an "expensive" operation. Obviously this is > > very > > > different when doing this with virtual thread task executor. Does > > using > > > virtual thread task executor mean this is cheap to create and > > shutdown? > > > Typically in client code you wouldn't want to create/destroy task > > executors > > > during the lifecycle of an application. > > The intention is that this should be very cheap to create and close. > > > > > Also I did some tests and I couldn't believe how many virtual threads I > > > could spin up on my machine versus OS threads. Seems like memory would > be > > > the limit but the difference was ~3000 OS threads vs ~5 million+ > virtual > > > threads. > > > > > > When I have time going to integrate the early loom builds into some > real > > > applications to see how it behaves. I very much look forward to not > > having > > > to worry about configuring thread pools in the future, very excited and > > > keep up the good work! > > > > > Good, please let me know how you get on. > > > > -Alan > > > From mbazos at gmail.com Tue Nov 23 21:38:50 2021 From: mbazos at gmail.com (Michael Bazos) Date: Tue, 23 Nov 2021 16:38:50 -0500 Subject: Questions on Build 18-loom+5-274 (2021/11/15) In-Reply-To: References: <8fca5fb4-955c-c02d-53fa-87dc4cce8184@oracle.com> Message-ID: Thanks Eric, Yeah I totally agree but when dealing with existing code I really like how Executors.newVirtualThreadPerTaskExecutor() is like a drop-in replacement. I am assuming this was considered in the design and is important to have as there is lots of code in the Java ecosystem that allows you to set a custom Executor but you might not have access to plug-in a StructuedExecutor. I also think there will need to be some education about executors, I believe it's pretty well known that creating an executor service is an "expensive" operation, but when doing this with a virtual task executor it's considered "cheap". Assuming these features from an API perspective don't change dramatically upon release I see Executors.newVirtualThreadPerTaskExecutor() being used a lot immediately and then over time code authors and such will migrate to something like StructuedExecutor. I really like the approach loom has taken to use Executor and of course re-use Thread class. I imagine this was a lot more challenging up front but I am willing to bet that doing this will pay dividends in the future once this is released. We don't always get to work on new applications so having a pathway forward for older applications is very exciting. Mike On Tue, Nov 23, 2021 at 3:42 PM Eric Kolotyluk wrote: > Mike, as I have discovered, StructuredExecutor.open() functions like > newVirtualThreadPerTaskExecutor(), one thread per task. > > While initially, I experimented with newVirtualThreadPerTaskExecutor(), I > now only use StructuredExecutor because it's a better solution. > > Cheers, Eric > > On Tue, Nov 23, 2021 at 12:26 PM Michael Bazos wrote: > >> Alan, >> Just wanted to let you know I took some high volume applications I work on >> that rely heavily on Executors and was easily able to switch to >> newVirtualThreadPerTaskExecutor and everything appears to be working well. >> Looking forward to the preview feature when it's ready. >> >> Mike >> >> On Fri, Nov 19, 2021 at 3:03 PM Alan Bateman >> wrote: >> >> > On 19/11/2021 19:15, Michael Bazos wrote: >> > > I started doing some experimenting with project loom an observed a few >> > > things and wasn't sure how to explain them or why it was happening: >> > > >> > > 1. I noticed when using >> Executors.newVirtualThreadPerTaskExecutor() >> > > submitting tasks and then calling 'shutdown()' on the executor >> > service, the >> > > virtual thread per task executor does not wait for tasks to >> finish. >> > This >> > > seems to behave a little differently than the OS based thread pool >> > > executors. I assume this is intended but just wanted to know why. >> > ExecutorService::shutdown is specified to not wait so the behavior you >> > observe is correct. You can use awaitTermination, or the new close >> > method, to wait for termination. Are you sure you've observed the >> > shutdown of other ExecutorService implementation wait, just curious. >> > >> > > 2. Playing with StructuredExecutor I can see the example of using >> it >> > > with try-with-resources which is clean and looks nice. I was >> > surprised to >> > > see `isShutdown()` as private on the StructuredExecutor. I am just >> > > wondering if a client didn't use try-with-resources there would be >> > some >> > > value in allowing a client to know if the executor is shutdown or >> > not. My >> > > best guess is the intention here is to minimize what is exposed >> from >> > the >> > > API. >> > If there is a case for exposing the state then it could be done. >> > >> > >> > > 3. My final question which is semi related to Question 2 I haven't >> > done >> > > any benchmarking myself yet but I know creating OS based executor >> > thread >> > > pools can be considered an "expensive" operation. Obviously this >> is >> > very >> > > different when doing this with virtual thread task executor. Does >> > using >> > > virtual thread task executor mean this is cheap to create and >> > shutdown? >> > > Typically in client code you wouldn't want to create/destroy task >> > executors >> > > during the lifecycle of an application. >> > The intention is that this should be very cheap to create and close. >> > >> > > Also I did some tests and I couldn't believe how many virtual threads >> I >> > > could spin up on my machine versus OS threads. Seems like memory >> would be >> > > the limit but the difference was ~3000 OS threads vs ~5 million+ >> virtual >> > > threads. >> > > >> > > When I have time going to integrate the early loom builds into some >> real >> > > applications to see how it behaves. I very much look forward to not >> > having >> > > to worry about configuring thread pools in the future, very excited >> and >> > > keep up the good work! >> > > >> > Good, please let me know how you get on. >> > >> > -Alan >> > >> > From eric at kolotyluk.net Tue Nov 23 21:55:45 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Tue, 23 Nov 2021 13:55:45 -0800 Subject: Questions on Build 18-loom+5-274 (2021/11/15) In-Reply-To: References: <8fca5fb4-955c-c02d-53fa-87dc4cce8184@oracle.com> Message-ID: Yes, indeed, dropping in Virtual Threads to replace existing Platform Threads is another key feature of Project Loom. Exploiting Structured Concurrency involves some effort in redesign and refactoring for existing projects, whereas I hope it would be the default for new designs and new projects. Agreed, switching the lexicon from Fibers to Virtual Threads to reuse the Thread API was a marvelous insight. For me, what was old is now new again. While I have a lot of experience with Reactive Systems, Functional Non-Blocking practices did result in a lot of twisted thinking. Going back to a more imperative style, being able to use Exceptions again, will make future code more readable because we don't have to write non-blocking code anymore. Blocking has now become cheaper or more affordable. Not that functional style is bad, but it can be an overused strength. Cheers, Eric On Tue, Nov 23, 2021 at 1:38 PM Michael Bazos wrote: > Thanks Eric, > Yeah I totally agree but when dealing with existing code I really like how > Executors.newVirtualThreadPerTaskExecutor() is like a drop-in replacement. > I am assuming this was considered in the design and is important to have as > there is lots of code in the Java ecosystem that allows you to set a custom > Executor but you might not have access to plug-in a StructuedExecutor. I > also think there will need to be some education about executors, I believe > it's pretty well known that creating an executor service is an "expensive" > operation, but when doing this with a virtual task executor it's considered > "cheap". > > Assuming these features from an API perspective don't change dramatically > upon release I see Executors.newVirtualThreadPerTaskExecutor() being used a > lot immediately and then over time code authors and such will migrate to > something like StructuedExecutor. > > I really like the approach loom has taken to use Executor and of course > re-use Thread class. I imagine this was a lot more challenging up front but > I am willing to bet that doing this will pay dividends in the future once > this is released. We don't always get to work on new applications so having > a pathway forward for older applications is very exciting. > > Mike > > On Tue, Nov 23, 2021 at 3:42 PM Eric Kolotyluk wrote: > >> Mike, as I have discovered, StructuredExecutor.open() functions like >> newVirtualThreadPerTaskExecutor(), one thread per task. >> >> While initially, I experimented with newVirtualThreadPerTaskExecutor(), I >> now only use StructuredExecutor because it's a better solution. >> >> Cheers, Eric >> >> On Tue, Nov 23, 2021 at 12:26 PM Michael Bazos wrote: >> >>> Alan, >>> Just wanted to let you know I took some high volume applications I work >>> on >>> that rely heavily on Executors and was easily able to switch to >>> newVirtualThreadPerTaskExecutor and everything appears to be working >>> well. >>> Looking forward to the preview feature when it's ready. >>> >>> Mike >>> >>> On Fri, Nov 19, 2021 at 3:03 PM Alan Bateman >>> wrote: >>> >>> > On 19/11/2021 19:15, Michael Bazos wrote: >>> > > I started doing some experimenting with project loom an observed a >>> few >>> > > things and wasn't sure how to explain them or why it was happening: >>> > > >>> > > 1. I noticed when using >>> Executors.newVirtualThreadPerTaskExecutor() >>> > > submitting tasks and then calling 'shutdown()' on the executor >>> > service, the >>> > > virtual thread per task executor does not wait for tasks to >>> finish. >>> > This >>> > > seems to behave a little differently than the OS based thread >>> pool >>> > > executors. I assume this is intended but just wanted to know why. >>> > ExecutorService::shutdown is specified to not wait so the behavior you >>> > observe is correct. You can use awaitTermination, or the new close >>> > method, to wait for termination. Are you sure you've observed the >>> > shutdown of other ExecutorService implementation wait, just curious. >>> > >>> > > 2. Playing with StructuredExecutor I can see the example of >>> using it >>> > > with try-with-resources which is clean and looks nice. I was >>> > surprised to >>> > > see `isShutdown()` as private on the StructuredExecutor. I am >>> just >>> > > wondering if a client didn't use try-with-resources there would >>> be >>> > some >>> > > value in allowing a client to know if the executor is shutdown or >>> > not. My >>> > > best guess is the intention here is to minimize what is exposed >>> from >>> > the >>> > > API. >>> > If there is a case for exposing the state then it could be done. >>> > >>> > >>> > > 3. My final question which is semi related to Question 2 I >>> haven't >>> > done >>> > > any benchmarking myself yet but I know creating OS based executor >>> > thread >>> > > pools can be considered an "expensive" operation. Obviously this >>> is >>> > very >>> > > different when doing this with virtual thread task executor. Does >>> > using >>> > > virtual thread task executor mean this is cheap to create and >>> > shutdown? >>> > > Typically in client code you wouldn't want to create/destroy task >>> > executors >>> > > during the lifecycle of an application. >>> > The intention is that this should be very cheap to create and close. >>> > >>> > > Also I did some tests and I couldn't believe how many virtual >>> threads I >>> > > could spin up on my machine versus OS threads. Seems like memory >>> would be >>> > > the limit but the difference was ~3000 OS threads vs ~5 million+ >>> virtual >>> > > threads. >>> > > >>> > > When I have time going to integrate the early loom builds into some >>> real >>> > > applications to see how it behaves. I very much look forward to not >>> > having >>> > > to worry about configuring thread pools in the future, very excited >>> and >>> > > keep up the good work! >>> > > >>> > Good, please let me know how you get on. >>> > >>> > -Alan >>> > >>> >> From Alan.Bateman at oracle.com Wed Nov 24 10:53:34 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 24 Nov 2021 10:53:34 +0000 Subject: Questions on Build 18-loom+5-274 (2021/11/15) In-Reply-To: References: <8fca5fb4-955c-c02d-53fa-87dc4cce8184@oracle.com> Message-ID: On 23/11/2021 20:42, Eric Kolotyluk wrote: > Mike, as I have discovered, StructuredExecutor.open() functions like > newVirtualThreadPerTaskExecutor(), one thread per task. > > While initially, I experimented with > newVirtualThreadPerTaskExecutor(), I now only use StructuredExecutor > because it's a better solution. > We can summarize this as ExecutorService for unstructured, StructuredExecutor for structured. For unstructured, an ExecutorService is "shared" (doesn't have an owner), its usually long lived and often saved in static final field. Anyone can submit tasks or shut it down. No inheritance of scope locals. For structured, StructuredExecutor is owned by the thread that creates it. It will be use try-with-resources to ensure is it closed, it would be a bug to stash one of these executors in a static field. Forking is confined to the owner and threads contained in the executor. Scope locals are inherited. -Alan. From duke at openjdk.java.net Wed Nov 24 14:19:09 2021 From: duke at openjdk.java.net (duke) Date: Wed, 24 Nov 2021 14:19:09 GMT Subject: git: openjdk/loom: fibers: 7 new changesets Message-ID: <00f03cfc-a387-48ae-9c02-7ddaf2ca96bc@openjdk.java.net> Changeset: ee459704 Author: Alan Bateman Date: 2021-11-22 12:51:42 +0000 URL: https://git.openjdk.java.net/loom/commit/ee459704388a47335db75e36056a6f9579197579 Improve javadoc ! src/java.base/share/classes/java/util/concurrent/StructuredExecutor.java Changeset: e05826b8 Author: Alan Bateman Date: 2021-11-22 19:03:01 +0000 URL: https://git.openjdk.java.net/loom/commit/e05826b8b847d7fc5500e280ebddc52060fb84ea Future::exceptionNow inconsistent ! src/java.base/share/classes/java/util/concurrent/CompletableFuture.java ! src/java.base/share/classes/java/util/concurrent/ForkJoinTask.java ! src/java.base/share/classes/java/util/concurrent/Future.java ! src/java.base/share/classes/java/util/concurrent/FutureTask.java ! test/jdk/java/util/concurrent/Future/DefaultMethods.java ! test/jdk/java/util/concurrent/StructuredExecutor/StructuredExecutorTest.java Changeset: fd06ac42 Author: Alan Bateman Date: 2021-11-23 08:08:02 +0000 URL: https://git.openjdk.java.net/loom/commit/fd06ac42aba9d2464f15442e704e4e5dc5ac6ea9 Another AppCDS test needed to be excluded due to ProcessTools ! test/hotspot/jtreg/ProblemList-vthread.txt Changeset: 7738fee3 Author: Alan Bateman Date: 2021-11-23 17:44:27 +0000 URL: https://git.openjdk.java.net/loom/commit/7738fee398a8a6db44432c2808bfa03216427ea3 Add new interface for completion handlers ! src/java.base/share/classes/java/util/concurrent/StructuredExecutor.java ! test/jdk/java/util/concurrent/StructuredExecutor/StructuredExecutorTest.java Changeset: 05f1330b Author: Alan Bateman Date: 2021-11-24 08:28:13 +0000 URL: https://git.openjdk.java.net/loom/commit/05f1330b3b3511d293656bae6947835f25b8be3c Drop extending BiConsumer for now ! src/java.base/share/classes/java/util/concurrent/StructuredExecutor.java ! test/jdk/java/util/concurrent/StructuredExecutor/StructuredExecutorTest.java Changeset: b1074156 Author: Alan Bateman Date: 2021-11-24 09:27:18 +0000 URL: https://git.openjdk.java.net/loom/commit/b10741563b6d354ca42d866cebd98e79da8bafed Restore j.u.concurrent.locks ! src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java ! src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java - src/java.base/share/classes/java/util/concurrent/locks/ForkJoinPoolHelper.java Changeset: bf0fabe9 Author: Alan Bateman Date: 2021-11-24 13:00:26 +0000 URL: https://git.openjdk.java.net/loom/commit/bf0fabe91bd26262540aa1b51a7a7827374322d4 Avoid spinning in getStackTrace when vthread is runnable-unmounted ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/java.base/share/classes/java/lang/VirtualThread.java ! test/jdk/java/lang/Thread/virtual/CustomScheduler.java + test/jdk/java/lang/Thread/virtual/StackTraceWhenRunnable.java From pedro.lamarao at prodist.com.br Wed Nov 24 14:51:58 2021 From: pedro.lamarao at prodist.com.br (=?UTF-8?Q?Pedro_Lamar=C3=A3o?=) Date: Wed, 24 Nov 2021 11:51:58 -0300 Subject: Generators In-Reply-To: References: Message-ID: Hi Ron, > Thank you, I?ll take a look. > I have updated my generator experiments by forking loom and adding code in the generators branch, java.base module, java.util.generator package: https://github.com/pedrolamarao/jdk-loom/tree/generators/src/java.base/share/classes/java/util/generator The generator-based DER parser has been updated to use a build from the above: https://github.com/pedrolamarao/loom-asn If you could provide some general feedback on this approach, that would be awesome. >From this foundation, I think it would be very easy to provide an Iterable generator. -- Pedro Lamar?o From Alan.Bateman at oracle.com Wed Nov 24 15:03:43 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 24 Nov 2021 15:03:43 +0000 Subject: Generators In-Reply-To: References: Message-ID: On 24/11/2021 14:51, Pedro Lamar?o wrote: > : > I have updated my generator experiments by forking loom > and adding code in the generators branch, java.base module, > java.util.generator package: > https://github.com/pedrolamarao/jdk-loom/tree/generators/src/java.base/share/classes/java/util/generator > The generator-based DER parser has been updated to use a build from the > above: > https://github.com/pedrolamarao/loom-asn > If you could provide some general feedback on this approach, that would be > awesome. > From this foundation, I think it would be very easy to provide an Iterable > generator. > It's great to experiment in this area. I suspect approaches along these lines will require the generator is to thread confined, it would otherwise be? unsafe to yield on one thread and then be called again on a different thread. -Alan From pedro.lamarao at prodist.com.br Wed Nov 24 15:23:34 2021 From: pedro.lamarao at prodist.com.br (=?UTF-8?Q?Pedro_Lamar=C3=A3o?=) Date: Wed, 24 Nov 2021 12:23:34 -0300 Subject: Generators In-Reply-To: References: Message-ID: Em qua., 24 de nov. de 2021 ?s 12:04, Alan Bateman escreveu: > On 24/11/2021 14:51, Pedro Lamar?o wrote: > > : > > I have updated my generator experiments by forking loom > > and adding code in the generators branch, java.base module, > > java.util.generator package: > > > https://github.com/pedrolamarao/jdk-loom/tree/generators/src/java.base/share/classes/java/util/generator > > The generator-based DER parser has been updated to use a build from the > > above: > > https://github.com/pedrolamarao/loom-asn > > If you could provide some general feedback on this approach, that would > be > > awesome. > > From this foundation, I think it would be very easy to provide an > Iterable > > generator. > > > It's great to experiment in this area. I suspect approaches along these > lines will require the generator is to thread confined, it would > otherwise be unsafe to yield on one thread and then be called again on > a different thread. > Hi Alan, would it be enough to require this by API contract and check it on the inside with IllegalStateException on violations? I'm assuming that thread in this case is the platform thread on which the Continuation was initially constructed. -- Pedro Lamar?o https://www.prodist.com.br Securing Critical Systems Tel: +55 11 4380-6585 Antes de imprimir esta mensagem e seus anexos, certifique-se que seja realmente necess?rio. Proteger o meio ambiente ? nosso dever. Before printing this e-mail or attachments, be sure it is necessary. It is in our hands to protect the environment. From ron.pressler at oracle.com Wed Nov 24 15:55:58 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Wed, 24 Nov 2021 15:55:58 +0000 Subject: Generators In-Reply-To: References: Message-ID: On 24 Nov 2021, at 15:23, Pedro Lamar?o > wrote: Hi Alan, would it be enough to require this by API contract and check it on the inside with IllegalStateException on violations? I'm assuming that thread in this case is the platform thread on which the Continuation was initially constructed. -- Pedro Lamar?o https://www.prodist.com.br Securing Critical Systems Tel: +55 11 4380-6585 The thread could be any thread ? platform or virtual. But yes, the construct would have to ensure that all calls are done on the same thread. Otherwise, we risk miscompilation (the JIT compiler works on the assumption that the current thread cannot change while executing a method; if it does, you might get strange results). ? Ron From duke at openjdk.java.net Wed Nov 24 21:09:29 2021 From: duke at openjdk.java.net (duke) Date: Wed, 24 Nov 2021 21:09:29 GMT Subject: git: openjdk/loom: fibers: virtual-thead test with wrapper excluded Message-ID: <9e5d2a5e-64e0-4fac-8a87-5f5e040457e4@openjdk.java.net> Changeset: 1ca8736d Author: lmesnik Date: 2021-11-24 13:56:56 +0000 URL: https://git.openjdk.java.net/loom/commit/1ca8736db8fd7d793371e350ef6bac3c3b2c21be virtual-thead test with wrapper excluded ! test/jdk/ProblemList-vthread.txt From raulraja at gmail.com Wed Nov 24 21:42:07 2021 From: raulraja at gmail.com (Raul Raja Martinez) Date: Wed, 24 Nov 2021 22:42:07 +0100 Subject: Access to Continuation.yield and ContinuationScope Message-ID: Hello everyone, First, thank you for LOOM and the extraordinary work done here. I'm excited to see this coming to a final release. I have been using LOOM builds up until recently, building abstractions directly on top of what used to be `java.lang.Continuation` and the `Continuation.yield` capabilities. I have noticed in the latest build these became internal in the jdk.internal.vm package. When I link against those I get errors like: java.lang.IllegalAccessError: superclass access check failed: class fx.Continuation$package$$anon$1 (in unnamed module @0x1f75bcda) cannot access class jdk.internal.vm.ContinuationScope (in module java.base) because module java.base does not export jdk.internal.vm to unnamed module @0x1f75bcda I wondered if there is a way to create and use Continuation.yield in this latest build, and if not, how would I go about implementing a use case like this currently expressed in Scala. https://gist.github.com/raulraja/5bd7ffaf4f9fc44bf99fefc14a5e640e Thank you! Raul. From duke at openjdk.java.net Wed Nov 24 23:03:29 2021 From: duke at openjdk.java.net (duke) Date: Wed, 24 Nov 2021 23:03:29 GMT Subject: git: openjdk/loom: fibers: 2 new changesets Message-ID: Changeset: a9b0103d Author: lmesnik Date: 2021-11-24 15:50:34 +0000 URL: https://git.openjdk.java.net/loom/commit/a9b0103d83a0816ee5ef70bcb3898a033091dc5d 2 jdb tests problemlisted with wrapper ! test/hotspot/jtreg/ProblemList-vthread.txt Changeset: 9bbfe5f3 Author: lmesnik Date: 2021-11-24 16:02:35 +0000 URL: https://git.openjdk.java.net/loom/commit/9bbfe5f3f8bb79e397696f5b9e4f5dec76d6ca4b +runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java excluded ! test/hotspot/jtreg/ProblemList.txt From zjx001202 at gmail.com Thu Nov 25 01:37:02 2021 From: zjx001202 at gmail.com (Glavo) Date: Thu, 25 Nov 2021 09:37:02 +0800 Subject: Access to Continuation.yield and ContinuationScope In-Reply-To: References: Message-ID: You can add the --add-opens option at runtime, like this: java --add-opens java.base/jdk.internal.vm=ALL-UNNAMED Raul Raja Martinez ?2021?11?25??? ??7:56??? > Hello everyone, > > First, thank you for LOOM and the extraordinary work done here. I'm excited > to see this coming to a final release. > > I have been using LOOM builds up until recently, building abstractions > directly on top of what used to be `java.lang.Continuation` and the > `Continuation.yield` capabilities. I have noticed in the latest build these > became internal in the jdk.internal.vm package. > > When I link against those I get errors like: > > java.lang.IllegalAccessError: superclass access check failed: class > fx.Continuation$package$$anon$1 (in unnamed module @0x1f75bcda) cannot > access class jdk.internal.vm.ContinuationScope (in module java.base) > because module java.base does not export jdk.internal.vm to unnamed module > @0x1f75bcda > > I wondered if there is a way to create and use Continuation.yield in this > latest build, and if not, how would I go about implementing a use case like > this currently expressed in Scala. > > https://gist.github.com/raulraja/5bd7ffaf4f9fc44bf99fefc14a5e640e > > Thank you! > > Raul. > From duke at openjdk.java.net Thu Nov 25 11:47:28 2021 From: duke at openjdk.java.net (duke) Date: Thu, 25 Nov 2021 11:47:28 GMT Subject: git: openjdk/loom: fibers: 68 new changesets Message-ID: Changeset: a907b2b1 Author: Coleen Phillimore Date: 2021-11-17 19:53:55 +0000 URL: https://git.openjdk.java.net/loom/commit/a907b2b144f2af27392eb7c2f9656fbb1a759618 8276177: nsk/jvmti/RedefineClasses/StressRedefineWithoutBytecodeCorruption failed with "assert(def_ik->is_being_redefined()) failed: should be being redefined to get here" Reviewed-by: hseigel, sspitsyn ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/utilities/accessFlags.hpp ! test/hotspot/jtreg/ProblemList.txt Changeset: 262d0700 Author: Weijun Wang Date: 2021-11-17 20:03:55 +0000 URL: https://git.openjdk.java.net/loom/commit/262d07001babcbe7f9acd2053aa3b7bac304cf85 8277246: Check for NonRepudiation as well when validating a TSA certificate Reviewed-by: xuelei, mullan ! src/java.base/share/classes/sun/security/validator/EndEntityChecker.java ! test/jdk/sun/security/tools/jarsigner/TimestampCheck.java Changeset: 8881f29b Author: Dean Long Date: 2021-11-17 20:18:07 +0000 URL: https://git.openjdk.java.net/loom/commit/8881f29bc83336bcbc0e8ff0cf1d2bbe55172f5c 8277310: ciReplay: @cpi MethodHandle references not resolved Reviewed-by: chagedorn, thartmann ! src/hotspot/share/ci/ciReplay.cpp Changeset: 007ad7c7 Author: Joe Darcy Date: 2021-11-17 20:23:43 +0000 URL: https://git.openjdk.java.net/loom/commit/007ad7c77c6277ce733386b4402b787d81dd41cf 8277303: Terminology mismatch between JLS17-3.9 and SE17's javax.lang.model.SourceVersion method specs Reviewed-by: iris, jjg ! src/java.compiler/share/classes/javax/lang/model/SourceVersion.java Changeset: d8c02802 Author: Dean Long Date: 2021-11-17 20:26:25 +0000 URL: https://git.openjdk.java.net/loom/commit/d8c0280273fa9f8e113088d6a43a4af076cd4f87 8277316: ciReplay: dump_replay_data is not thread-safe Reviewed-by: chagedorn, thartmann ! src/hotspot/share/ci/ciEnv.cpp Changeset: 6bb04626 Author: Sean Coffey Date: 2021-11-17 20:50:46 +0000 URL: https://git.openjdk.java.net/loom/commit/6bb04626af6574ef1e8d4b7dad0389d4b59f5d08 8277224: sun.security.pkcs.PKCS9Attributes.toString() throws NPE Reviewed-by: weijun ! src/java.base/share/classes/sun/security/pkcs/PKCS9Attributes.java ! test/jdk/sun/security/x509/AlgorithmId/NonStandardNames.java Changeset: 45a60db5 Author: Albert Mingkun Yang Date: 2021-11-17 21:02:13 +0000 URL: https://git.openjdk.java.net/loom/commit/45a60db5a0aa78fa9eb1c2899bd167c136e0fa03 8277045: G1: Remove unnecessary set_concurrency call in G1ConcurrentMark::weak_refs_work Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp Changeset: ce4471f8 Author: Daniel D. Daugherty Date: 2021-11-17 21:23:38 +0000 URL: https://git.openjdk.java.net/loom/commit/ce4471f806e51bc9f9ad746b69ba490443947110 8277346: ProblemList 7 serviceability/sa tests on macosx-x64 8277351: ProblemList runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java on macosx-x64 Reviewed-by: tschatzl, bpb ! test/hotspot/jtreg/ProblemList.txt Changeset: 29e552c0 Author: Sergey Bylokhov Date: 2021-11-17 22:21:38 +0000 URL: https://git.openjdk.java.net/loom/commit/29e552c03a2825f9526330072668a1d63ac68fd4 8272358: Some tests may fail when executed with other locales than the US Reviewed-by: aivanov ! test/langtools/jdk/jshell/ToolBasicTest.java ! test/langtools/jdk/jshell/ToolSimpleTest.java ! test/langtools/tools/javac/lambda/lambdaExecution/LambdaTranslationTest1.java ! test/langtools/tools/javac/lambda/lambdaExecution/LambdaTranslationTest2.java Changeset: 231fb61a Author: Naoto Sato Date: 2021-11-18 01:12:12 +0000 URL: https://git.openjdk.java.net/loom/commit/231fb61aaeae04787c06a4c972197943d9085627 8276970: Default charset for PrintWriter that wraps PrintStream Reviewed-by: rriggs, alanb ! src/java.base/share/classes/java/io/OutputStreamWriter.java ! src/java.base/share/classes/java/io/PrintStream.java ! src/java.base/share/classes/java/io/PrintWriter.java + test/jdk/java/io/PrintStream/InheritEncodingTest.java Changeset: b8453ebd Author: Naoto Sato Date: 2021-11-18 01:13:26 +0000 URL: https://git.openjdk.java.net/loom/commit/b8453ebdb471e08cc8d62c777f33ad52902f67d7 8275007: Java fails to start with null charset if LC_ALL is set to certain locales Reviewed-by: rriggs, iris, joehw, alanb ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/native/libjava/jni_util.c Changeset: 81938001 Author: Fei Gao Committer: Ningsheng Jian Date: 2021-11-18 02:41:27 +0000 URL: https://git.openjdk.java.net/loom/commit/81938001f9bae56c59f4e18b7756089f2cf0bf74 8274179: AArch64: Support SVE operations with encodable immediates Reviewed-by: aph, ngasson ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/aarch64_sve.ad ! src/hotspot/cpu/aarch64/aarch64_sve_ad.m4 ! src/hotspot/cpu/aarch64/assembler_aarch64.cpp ! src/hotspot/cpu/aarch64/assembler_aarch64.hpp ! test/hotspot/gtest/aarch64/aarch64-asmtest.py ! test/hotspot/gtest/aarch64/asmtest.out.h ! test/hotspot/jtreg/compiler/codegen/TestByteVect.java ! test/hotspot/jtreg/compiler/codegen/TestCharVect.java ! test/hotspot/jtreg/compiler/codegen/TestIntVect.java ! test/hotspot/jtreg/compiler/codegen/TestLongVect.java ! test/hotspot/jtreg/compiler/codegen/TestShortVect.java Changeset: 91607436 Author: Prasanta Sadhukhan Date: 2021-11-18 04:33:49 +0000 URL: https://git.openjdk.java.net/loom/commit/91607436b79126ccb999deaf38a98209dbfe6ec1 8276058: Some swing test fails on specific CI macos system Reviewed-by: prr, kizune ! test/jdk/ProblemList.txt ! test/jdk/java/awt/Dialog/MakeWindowAlwaysOnTop/MakeWindowAlwaysOnTop.java ! test/jdk/javax/swing/JButton/8151303/PressedIconTest.java ! test/jdk/javax/swing/JInternalFrame/8069348/bug8069348.java ! test/jdk/javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java Changeset: 2f4b5405 Author: Doug Simon Date: 2021-11-18 08:32:54 +0000 URL: https://git.openjdk.java.net/loom/commit/2f4b5405f0b53782f3ed5274f68b31eb968efb6d 8276314: [JVMCI] check alignment of call displacement during code installation Reviewed-by: kvn ! src/hotspot/cpu/x86/jvmciCodeInstaller_x86.cpp ! src/hotspot/cpu/x86/nativeInst_x86.cpp ! src/hotspot/cpu/x86/nativeInst_x86.hpp Changeset: db55f927 Author: Ioi Lam Date: 2021-11-18 08:49:07 +0000 URL: https://git.openjdk.java.net/loom/commit/db55f9272c0889f4ea4dee0f4aa3d9613fadb2f8 8277343: dynamicArchive/SharedArchiveFileOption.java failed: '-XX:+RecordDynamicDumpInfo is unsupported when a dynamic CDS archive is specified in -XX:SharedArchiveFile:' missing Reviewed-by: hseigel, ccheung ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/DynamicArchiveTestBase.java ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/SharedArchiveFileOption.java Changeset: 0a65e8b2 Author: Andrey Turbanov Committer: Alexey Ivanov Date: 2021-11-18 10:48:16 +0000 URL: https://git.openjdk.java.net/loom/commit/0a65e8b282fd41e57108422fbd140527d9697efd 8276794: Change nested classes in java.desktop to static nested classes Reviewed-by: serb, aivanov ! src/java.desktop/macosx/classes/com/apple/eawt/_AppEventHandler.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaFileChooserUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaFileSystemModel.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaInternalFramePaneUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaTabbedPaneCopyFromBasicUI.java ! src/java.desktop/macosx/classes/sun/java2d/metal/MTLRenderer.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/DHTMarkerSegment.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/DQTMarkerSegment.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/JFIFMarkerSegment.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/SOFMarkerSegment.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/SOSMarkerSegment.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKColorChooserPanel.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifDesktopPaneUI.java ! src/java.desktop/share/classes/com/sun/media/sound/EventDispatcher.java ! src/java.desktop/share/classes/com/sun/media/sound/RealTimeSequencer.java ! src/java.desktop/share/classes/com/sun/media/sound/SoftMainMixer.java ! src/java.desktop/share/classes/com/sun/media/sound/SunFileWriter.java ! src/java.desktop/share/classes/java/awt/CardLayout.java ! src/java.desktop/share/classes/java/awt/Component.java ! src/java.desktop/share/classes/java/awt/Polygon.java ! src/java.desktop/share/classes/java/awt/ScrollPane.java ! src/java.desktop/share/classes/java/awt/Toolkit.java ! src/java.desktop/share/classes/java/awt/print/Book.java ! src/java.desktop/share/classes/java/beans/XMLEncoder.java ! src/java.desktop/share/classes/javax/imageio/metadata/IIOMetadataFormatImpl.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterStateReasons.java ! src/java.desktop/share/classes/javax/sound/sampled/AudioInputStream.java ! src/java.desktop/share/classes/javax/swing/GroupLayout.java ! src/java.desktop/share/classes/javax/swing/JComboBox.java ! src/java.desktop/share/classes/javax/swing/JComponent.java ! src/java.desktop/share/classes/javax/swing/JTable.java ! src/java.desktop/share/classes/javax/swing/KeyboardManager.java ! src/java.desktop/share/classes/javax/swing/RepaintManager.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicDesktopPaneUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicInternalFrameTitlePane.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicPopupMenuUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalComboBoxEditor.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalIconFactory.java ! src/java.desktop/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java ! src/java.desktop/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTabbedPaneUI.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTableUI.java ! src/java.desktop/share/classes/javax/swing/text/DefaultHighlighter.java ! src/java.desktop/share/classes/javax/swing/text/ElementIterator.java ! src/java.desktop/share/classes/javax/swing/text/JTextComponent.java ! src/java.desktop/share/classes/javax/swing/text/StringContent.java ! src/java.desktop/share/classes/javax/swing/text/StyleContext.java ! src/java.desktop/share/classes/javax/swing/text/html/ImageView.java ! src/java.desktop/share/classes/javax/swing/text/html/TableView.java ! src/java.desktop/share/classes/javax/swing/text/rtf/RTFReader.java ! src/java.desktop/share/classes/javax/swing/tree/DefaultMutableTreeNode.java ! src/java.desktop/share/classes/sun/awt/PlatformFont.java ! src/java.desktop/share/classes/sun/java2d/loops/RenderCache.java ! src/java.desktop/share/classes/sun/java2d/opengl/OGLRenderer.java ! src/java.desktop/share/classes/sun/java2d/pipe/GeneralCompositePipe.java ! src/java.desktop/share/classes/sun/java2d/pipe/SpanClipRenderer.java ! src/java.desktop/share/classes/sun/print/PrintJob2D.java ! src/java.desktop/share/classes/sun/print/RasterPrinterJob.java ! src/java.desktop/share/classes/sun/print/ServiceDialog.java ! src/java.desktop/share/classes/sun/swing/plaf/synth/SynthFileChooserUI.java ! src/java.desktop/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java ! src/java.desktop/share/classes/sun/swing/table/DefaultTableCellHeaderRenderer.java ! src/java.desktop/unix/classes/sun/awt/X11/XTextAreaPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XTextFieldPeer.java ! src/java.desktop/unix/classes/sun/font/X11GB2312.java ! src/java.desktop/unix/classes/sun/font/X11GBK.java ! src/java.desktop/unix/classes/sun/font/X11KSC5601.java ! src/java.desktop/unix/classes/sun/print/IPPPrintService.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsComboBoxUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/XPStyle.java ! src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java ! src/java.desktop/windows/classes/sun/awt/windows/WScrollPanePeer.java ! src/java.desktop/windows/classes/sun/java2d/d3d/D3DRenderer.java Changeset: 77cc5088 Author: Albert Mingkun Yang Date: 2021-11-18 10:52:55 +0000 URL: https://git.openjdk.java.net/loom/commit/77cc508802899b370f1cdf592331f81efb8d9208 8277215: Remove redundancy in ReferenceProcessor constructor args Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/gc/parallel/psScavenge.cpp ! src/hotspot/share/gc/shared/referenceProcessor.cpp ! src/hotspot/share/gc/shared/referenceProcessor.hpp Changeset: 2c06bca9 Author: Erik ?sterlund Date: 2021-11-18 11:17:00 +0000 URL: https://git.openjdk.java.net/loom/commit/2c06bca98fcf9d129d6085e26c225fb26368a558 8266368: Inaccurate after_unwind hook in C2 exception handler Reviewed-by: dlong, thartmann ! src/hotspot/share/opto/runtime.cpp ! src/hotspot/share/runtime/sharedRuntime.cpp Changeset: 38345bd2 Author: Evgeny Astigeevich Committer: Volker Simonis Date: 2021-11-18 11:18:15 +0000 URL: https://git.openjdk.java.net/loom/commit/38345bd28db83371676f1685806ddc207a833879 8277137: Set OnSpinWaitInst/OnSpinWaitInstCount defaults to "isb"/1 for Arm Neoverse N1 Reviewed-by: phh, aph, ngasson ! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp + test/hotspot/jtreg/compiler/onSpinWait/TestOnSpinWaitAArch64DefaultFlags.java Changeset: b3a62b48 Author: Harold Seigel Date: 2021-11-18 13:18:37 +0000 URL: https://git.openjdk.java.net/loom/commit/b3a62b48816358ac7dadde4e7893190500ca7b79 8276795: Deprecate seldom used CDS flags Reviewed-by: dholmes, ccheung, iklam ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp ! test/hotspot/jtreg/compiler/intrinsics/klass/TestIsPrimitive.java ! test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java Changeset: a44b45fd Author: Sean Mullan Date: 2021-11-18 13:48:12 +0000 URL: https://git.openjdk.java.net/loom/commit/a44b45fdf31275a2c1e9d1d0132874a7de45f8ee 4337793: Mark non-serializable fields of java.security.cert.Certificate and CertPath Reviewed-by: valeriep, rriggs ! src/java.base/share/classes/java/security/cert/CertPath.java ! src/java.base/share/classes/java/security/cert/Certificate.java Changeset: 00c388b4 Author: Erik ?sterlund Date: 2021-11-18 14:32:59 +0000 URL: https://git.openjdk.java.net/loom/commit/00c388b4aba41d5f0874585e9c0a33c4571805f6 8259643: ZGC can return metaspace OOM prematurely Reviewed-by: stefank, pliden, stuefe ! src/hotspot/share/gc/z/zCollectedHeap.cpp ! src/hotspot/share/memory/metaspace.cpp + src/hotspot/share/memory/metaspaceCriticalAllocation.cpp + src/hotspot/share/memory/metaspaceCriticalAllocation.hpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp Changeset: d93b238f Author: Erik ?sterlund Date: 2021-11-18 14:44:58 +0000 URL: https://git.openjdk.java.net/loom/commit/d93b238f9725727ae1e2e9f203943b5ddf778f35 8277180: Intrinsify recursive ObjectMonitor locking for C2 x64 and A64 Reviewed-by: aph, ngasson ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp Changeset: 276bfcd1 Author: Prasanta Sadhukhan Date: 2021-11-18 15:17:59 +0000 URL: https://git.openjdk.java.net/loom/commit/276bfcd1a115f90dde644abef79d64bb61788c75 8277407: javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java fails to compile after JDK-8276058 Reviewed-by: dcubed ! test/jdk/javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java Changeset: 354a34ea Author: Albert Mingkun Yang Date: 2021-11-18 15:54:04 +0000 URL: https://git.openjdk.java.net/loom/commit/354a34ea2077c9372e585adb1303df604827a2e2 8277336: Improve CollectedHeap::safepoint_workers comments Reviewed-by: sjohanss, tschatzl ! src/hotspot/share/gc/shared/collectedHeap.hpp Changeset: 5d249c46 Author: Alexander Zuev Date: 2021-11-18 16:07:38 +0000 URL: https://git.openjdk.java.net/loom/commit/5d249c46abc8dfdc3acdaff41d26f3bd9ba84731 8275071: [macos] A11y cursor gets stuck when combobox is closed Reviewed-by: serb, pbansal ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessible.java Changeset: ce0f00f6 Author: Thomas Schatzl Date: 2021-11-18 16:59:41 +0000 URL: https://git.openjdk.java.net/loom/commit/ce0f00f66e78a504d5e40a25fa213325ec0af394 8276093: Improve naming in closures to iterate over card sets Reviewed-by: sjohanss, ayang ! src/hotspot/share/gc/g1/g1CardSet.cpp ! src/hotspot/share/gc/g1/g1CardSet.hpp ! src/hotspot/share/gc/g1/g1CardSet.inline.hpp ! src/hotspot/share/gc/g1/heapRegionRemSet.inline.hpp ! test/hotspot/gtest/gc/g1/test_g1CardSet.cpp Changeset: 03473b4c Author: Sergey Bylokhov Date: 2021-11-18 18:25:38 +0000 URL: https://git.openjdk.java.net/loom/commit/03473b4c271b2ec7f0ebdb0edabadf7f36816b9d 8270874: JFrame paint artifacts when dragged from standard monitor to HiDPI monitor Reviewed-by: jdv ! src/java.desktop/windows/native/libawt/windows/awt_Component.cpp ! test/jdk/java/awt/Window/WindowResizingOnDPIChanging/WindowResizingOnMovingToAnotherDisplay.java Changeset: 8db0c361 Author: Daniel D. Daugherty Date: 2021-11-18 18:40:26 +0000 URL: https://git.openjdk.java.net/loom/commit/8db0c361a39cf10d373c3d2dfa54267cf53452db 8277414: ProblemList runtime/CommandLine/VMDeprecatedOptions.java on windows-x64 Reviewed-by: mikael, iklam ! test/hotspot/jtreg/ProblemList.txt Changeset: 57eb8647 Author: Niklas Radomski Committer: Martin Doerr Date: 2021-11-18 19:00:58 +0000 URL: https://git.openjdk.java.net/loom/commit/57eb864765f38185f8db8f1d37681d6cfe2a3c73 8276927: [PPC64] Port shenandoahgc to linux on ppc64le Reviewed-by: rkennke, ihse, mdoerr ! make/autoconf/jvm-features.m4 ! make/hotspot/gensrc/GensrcAdlc.gmk ! src/hotspot/cpu/ppc/gc/shared/barrierSetAssembler_ppc.cpp + src/hotspot/cpu/ppc/gc/shenandoah/c1/shenandoahBarrierSetC1_ppc.cpp + src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp + src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.hpp + src/hotspot/cpu/ppc/gc/shenandoah/shenandoah_ppc.ad ! src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp Changeset: 36bd4a35 Author: Harold Seigel Date: 2021-11-18 20:06:13 +0000 URL: https://git.openjdk.java.net/loom/commit/36bd4a35fbee077c00c1f4240f1f02f4d7d5f656 8277404: Test VMDeprecatedOptions.java failing with Unable to create shared archive file Reviewed-by: dcubed ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java Changeset: 89b125f4 Author: Roman Kennke Date: 2021-11-18 21:32:00 +0000 URL: https://git.openjdk.java.net/loom/commit/89b125f4d4d6a467185b4b39861fd530a738e67f 8275527: Refactor forward pointer access Reviewed-by: tschatzl, stefank ! src/hotspot/share/gc/g1/g1FullGCCompactTask.cpp ! src/hotspot/share/gc/g1/g1FullGCCompactionPoint.cpp ! src/hotspot/share/gc/g1/g1FullGCOopClosures.inline.hpp ! src/hotspot/share/gc/g1/g1FullGCPrepareTask.cpp ! src/hotspot/share/gc/g1/g1OopClosures.inline.hpp ! src/hotspot/share/gc/g1/g1YoungCollector.cpp ! src/hotspot/share/gc/serial/markSweep.inline.hpp ! src/hotspot/share/gc/shared/space.cpp ! src/hotspot/share/oops/oop.inline.hpp Changeset: 839033ba Author: Man Cao Date: 2021-11-18 23:35:01 +0000 URL: https://git.openjdk.java.net/loom/commit/839033baf61ca7f10437e8e53b2114b081d97ea9 8276976: Rename LIR_OprDesc to LIR_Opr Co-authored-by: Chuck Rasbold Reviewed-by: thartmann, iveresov ! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c1_LIR_aarch64.cpp ! src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp ! src/hotspot/cpu/arm/c1_LIR_arm.cpp ! src/hotspot/cpu/ppc/c1_LIR_ppc.cpp ! src/hotspot/cpu/s390/c1_LIR_s390.cpp ! src/hotspot/cpu/x86/c1_LIR_x86.cpp ! src/hotspot/share/c1/c1_LIR.cpp ! src/hotspot/share/c1/c1_LIR.hpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/c1/c1_LIRGenerator.hpp ! src/hotspot/share/c1/c1_LinearScan.cpp ! src/hotspot/share/c1/c1_LinearScan.hpp ! src/hotspot/share/gc/g1/c1/g1BarrierSetC1.cpp Changeset: 2f0bde1a Author: Yi Yang Date: 2021-11-19 02:04:48 +0000 URL: https://git.openjdk.java.net/loom/commit/2f0bde1a658b0910304c110920a2e8ccbe4557f8 8277102: Dubious PrintCompilation output Reviewed-by: thartmann, dnsimon ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/compiler/compileTask.cpp ! src/hotspot/share/compiler/compileTask.hpp ! test/hotspot/jtreg/compiler/jvmci/compilerToVM/DisassembleCodeBlobTest.java Changeset: 47564cae Author: Tobias Hartmann Date: 2021-11-19 07:07:17 +0000 URL: https://git.openjdk.java.net/loom/commit/47564caeb0628e5c03a0e7f04093adce77d6dd3b 8275643: C2's unaryOp vector intrinsic does not properly handle LongVector.neg Reviewed-by: chagedorn, sviswanathan ! src/hotspot/share/prims/vectorSupport.cpp + test/hotspot/jtreg/compiler/vectorapi/TestLongVectorNeg.java Changeset: f34f1190 Author: Tobias Hartmann Date: 2021-11-19 07:13:05 +0000 URL: https://git.openjdk.java.net/loom/commit/f34f119080b4e8baf396fb26c21d572dd432fd91 8277213: CompileTask_lock is acquired out of order with MethodCompileQueue_lock Reviewed-by: rbackman, coleenp ! src/hotspot/share/compiler/compileTask.hpp Changeset: 2f20b0d8 Author: Jan Lahoda Date: 2021-11-19 07:49:58 +0000 URL: https://git.openjdk.java.net/loom/commit/2f20b0d8daca6bdc53b4b9e1837c428930d34236 8273039: JShell crashes when naming variable or method "abstract" or "strictfp" Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! test/langtools/jdk/jshell/ErrorRecoveryTest.java + test/langtools/tools/javac/attr/AttrRecoveryTest.java Changeset: 3a76d397 Author: Tobias Hartmann Date: 2021-11-19 08:23:45 +0000 URL: https://git.openjdk.java.net/loom/commit/3a76d397949ad22e4786476e583cc9d33c015214 8277324: C2 compilation fails with "bad AD file" on x86-32 after JDK-8276162 due to missing match rule Reviewed-by: chagedorn, roland ! src/hotspot/cpu/x86/x86_32.ad Changeset: 7a046e0f Author: Albert Mingkun Yang Date: 2021-11-19 08:31:09 +0000 URL: https://git.openjdk.java.net/loom/commit/7a046e0f765e0ad04fd52c9a882c5d90b085bc00 8277371: Remove unnecessary DefNewGeneration::ref_processor_init() Reviewed-by: stefank, tschatzl, mli ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/serial/defNewGeneration.hpp ! src/hotspot/share/gc/shared/generation.hpp Changeset: 11d819d6 Author: Hamlin Li Date: 2021-11-19 10:15:30 +0000 URL: https://git.openjdk.java.net/loom/commit/11d819d68a3ce2ae0973b496141c52aa419f90f0 8277439: G1: Correct include guard name in G1EvacFailureObjectsSet.hpp Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.hpp Changeset: b15e6f07 Author: Jie Fu Date: 2021-11-19 10:38:42 +0000 URL: https://git.openjdk.java.net/loom/commit/b15e6f076afe5ac68e9af68756860d0b25adea4b 8277449: compiler/vectorapi/TestLongVectorNeg.java fails with release VMs Reviewed-by: thartmann, chagedorn ! test/hotspot/jtreg/compiler/vectorapi/TestLongVectorNeg.java Changeset: 03debf27 Author: Daniel Fuchs Date: 2021-11-19 13:18:12 +0000 URL: https://git.openjdk.java.net/loom/commit/03debf277537135974d3f55e3a5c7cf6842ee5e0 8276774: Cookie stored in CookieHandler not sent if user headers contain cookie Reviewed-by: michaelm ! src/java.net.http/share/classes/jdk/internal/net/http/Http1Request.java ! src/java.net.http/share/classes/jdk/internal/net/http/Stream.java ! test/jdk/java/net/httpclient/CookieHeaderTest.java = test/jdk/java/net/httpclient/UserCookieTest.java Changeset: b1a1bf4e Author: Claes Redestad Date: 2021-11-19 13:25:40 +0000 URL: https://git.openjdk.java.net/loom/commit/b1a1bf4e305d6675f8f751aa8fef7013d99466f1 8277427: Update jib-profiles.js to use JMH 1.33 devkit Reviewed-by: shade, erikj ! make/conf/jib-profiles.js Changeset: a0227965 Author: Magnus Ihse Bursie Committer: Magnus Ihse Bursie Date: 2021-11-19 13:55:08 +0000 URL: https://git.openjdk.java.net/loom/commit/a0227965bb8d1d49718794d67f8a4cfeebc9bec2 8275745: Reproducible copyright headers Reviewed-by: ihse, erikj ! make/autoconf/basic_tools.m4 ! make/autoconf/jdk-options.m4 ! make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java ! make/jdk/src/classes/build/tools/cldrconverter/CopyrightHeaders.java ! make/jdk/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java ! make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java ! make/modules/java.base/Gensrc.gmk ! make/modules/jdk.localedata/Gensrc.gmk Changeset: 936f7ff4 Author: Andy Herrick Date: 2021-11-19 14:23:04 +0000 URL: https://git.openjdk.java.net/loom/commit/936f7ff49ed86adb74bb1ff10d93cb3d7f7d70a0 8276150: Quarantined jpackage apps are labeled as "damaged" Reviewed-by: almatvee ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppImageBuilder.java ! test/jdk/tools/jpackage/macosx/SigningAppImageTest.java Changeset: 03f8c0fb Author: Sean Mullan Date: 2021-11-19 14:36:07 +0000 URL: https://git.openjdk.java.net/loom/commit/03f8c0fb9363dc1bb07bed1ae0359c029caa0130 8275887: jarsigner prints invalid digest/signature algorithm warnings if keysize is weak/disabled Reviewed-by: weijun ! src/java.base/share/classes/sun/security/pkcs/SignerInfo.java ! src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.java ! src/java.base/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java ! src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java ! src/java.base/share/classes/sun/security/util/JarConstraintsParameters.java ! src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java ! src/java.base/share/classes/sun/security/util/SignatureFileVerifier.java ! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java ! test/jdk/sun/security/tools/jarsigner/TimestampCheck.java Changeset: 976c2bb0 Author: Stefan Karlsson Date: 2021-11-19 15:34:22 +0000 URL: https://git.openjdk.java.net/loom/commit/976c2bb05611cdc7b11b0918aaf50ff693507aae 8277212: GC accidentally cleans valid megamorphic vtable inline caches Reviewed-by: eosterlund, pliden, coleenp, thartmann ! src/hotspot/share/code/compiledMethod.cpp Changeset: 09e8c8c6 Author: Coleen Phillimore Date: 2021-11-19 17:48:43 +0000 URL: https://git.openjdk.java.net/loom/commit/09e8c8c64abf4178a042c79b92d7e08e54467331 8277342: vmTestbase/nsk/stress/strace/strace004.java fails with SIGSEGV in InstanceKlass::jni_id_for Reviewed-by: dholmes, hseigel ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp Changeset: 66775543 Author: Andrey Turbanov Committer: Roger Riggs Date: 2021-11-19 18:48:06 +0000 URL: https://git.openjdk.java.net/loom/commit/6677554374ade32c9f2ddaaa093064de8aebd831 8274949: Use String.contains() instead of String.indexOf() in java.base Reviewed-by: weijun, dfuchs, vtewari, lancea ! src/java.base/share/classes/java/net/HttpCookie.java ! src/java.base/share/classes/java/net/HttpURLConnection.java ! src/java.base/share/classes/java/net/SocketPermission.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtPath.java ! src/java.base/share/classes/jdk/internal/loader/URLClassPath.java ! src/java.base/share/classes/sun/net/www/http/HttpCapture.java ! src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java ! src/java.base/share/classes/sun/security/provider/PolicyFile.java ! src/java.base/share/classes/sun/security/rsa/RSAPSSSignature.java ! src/java.base/share/classes/sun/security/rsa/RSAUtil.java ! src/java.base/share/classes/sun/security/tools/keytool/Main.java ! src/java.base/share/classes/sun/security/util/Debug.java ! src/java.base/share/classes/sun/security/util/SignatureUtil.java ! src/java.base/share/classes/sun/security/x509/AlgorithmId.java ! src/java.base/share/classes/sun/util/locale/LocaleMatcher.java ! src/java.base/unix/classes/sun/net/www/protocol/jar/JarFileFactory.java ! src/java.base/windows/classes/sun/net/www/protocol/jar/JarFileFactory.java Changeset: 36b59f38 Author: Andrey Turbanov Committer: Roger Riggs Date: 2021-11-19 18:49:04 +0000 URL: https://git.openjdk.java.net/loom/commit/36b59f3814fdaa44c9c04a0e8d63d0ba56929326 8274333: Redundant null comparison after Pattern.split Reviewed-by: mullan, weijun, rriggs, iris ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/java.base/share/classes/sun/security/util/AlgorithmDecomposer.java Changeset: f609b8fd Author: Andrey Turbanov Committer: Roger Riggs Date: 2021-11-19 18:50:03 +0000 URL: https://git.openjdk.java.net/loom/commit/f609b8fd74c55f3149d8e5a6a9a9bc3598c0b961 8274946: Cleanup unnecessary calls to Throwable.initCause() in java.rmi Reviewed-by: iris, rriggs ! src/java.rmi/share/classes/java/rmi/server/RMIClassLoader.java ! src/java.rmi/share/classes/java/rmi/server/RemoteObjectInvocationHandler.java ! src/java.rmi/share/classes/javax/rmi/ssl/SslRMIClientSocketFactory.java ! src/java.rmi/share/classes/javax/rmi/ssl/SslRMIServerSocketFactory.java ! src/java.rmi/share/classes/sun/rmi/log/ReliableLog.java Changeset: e47cc81b Author: Andrey Turbanov Committer: Roger Riggs Date: 2021-11-19 18:51:13 +0000 URL: https://git.openjdk.java.net/loom/commit/e47cc81b095381266104e9137495e91fb4c225a4 8275386: Change nested classes in jdk.jlink to static nested classes Reviewed-by: alanb, rriggs, iris ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginStack.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ResourcePoolManager.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java Changeset: a3406a1d Author: Thomas Stuefe Date: 2021-11-19 19:49:57 +0000 URL: https://git.openjdk.java.net/loom/commit/a3406a1d8ab4228b06b4f2978f87275093c39468 8277092: TestMetaspaceAllocationMT2.java#ndebug-default fails with "RuntimeException: Committed seems high: NNNN expected at most MMMM" Reviewed-by: coleenp ! test/hotspot/jtreg/runtime/Metaspace/elastic/MetaspaceTestContext.java ! test/hotspot/jtreg/runtime/Metaspace/elastic/MetaspaceTestManyArenasManyThreads.java Changeset: 2d4af225 Author: Yasumasa Suenaga Date: 2021-11-19 20:24:17 +0000 URL: https://git.openjdk.java.net/loom/commit/2d4af2255feb2eaeca533424f8cba3ec0945d757 8277370: configure script cannot distinguish WSL version Reviewed-by: erikj ! make/autoconf/basic_windows.m4 Changeset: 2ab43ec2 Author: Pavel Rappo Date: 2021-11-19 20:51:22 +0000 URL: https://git.openjdk.java.net/loom/commit/2ab43ec2428edaebfe9a7fb0e716ff7141a28de0 8273544: Increase test coverage for snippets Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SnippetTaglet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Attribute.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Attributes.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Parser.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Replace.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Style.java + test/langtools/jdk/javadoc/doclet/testSnippetTag/SnippetTester.java + test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetMarkup.java + test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetPathOption.java ! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java Changeset: c79a485f Author: Daniel D. Daugherty Date: 2021-11-19 22:37:28 +0000 URL: https://git.openjdk.java.net/loom/commit/c79a485f1c3f9c0c3a79b8847fdcd50a141cd529 8277494: [BACKOUT] JDK-8276150 Quarantined jpackage apps are labeled as "damaged" Reviewed-by: asemenyuk, tschatzl ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppImageBuilder.java ! test/jdk/tools/jpackage/macosx/SigningAppImageTest.java Changeset: 1d7cef33 Author: Derek White Date: 2021-11-20 00:48:32 +0000 URL: https://git.openjdk.java.net/loom/commit/1d7cef33c5ff24695463a03c58c7ca350ec190fc 8276662: Scalability bottleneck in SymbolTable::lookup_common() Reviewed-by: redestad, dholmes, iklam, shade ! src/hotspot/share/classfile/symbolTable.cpp Changeset: 1c215f33 Author: Vishal Chand Committer: Thomas Schatzl Date: 2021-11-20 10:03:45 +0000 URL: https://git.openjdk.java.net/loom/commit/1c215f33698ba2aef4fb230475a9bd33ed3005f9 8272773: Configurable card table card size Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1Arguments.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/parallel/objectStartArray.cpp ! src/hotspot/share/gc/parallel/objectStartArray.hpp ! src/hotspot/share/gc/parallel/parallelArguments.cpp ! src/hotspot/share/gc/shared/blockOffsetTable.cpp ! src/hotspot/share/gc/shared/blockOffsetTable.hpp ! src/hotspot/share/gc/shared/cardTable.cpp ! src/hotspot/share/gc/shared/cardTable.hpp ! src/hotspot/share/gc/shared/gc_globals.hpp ! src/hotspot/share/gc/shared/genArguments.cpp ! src/hotspot/share/gc/shared/jvmFlagConstraintsGC.cpp ! src/hotspot/share/gc/shared/jvmFlagConstraintsGC.hpp Changeset: 0a9e76c4 Author: Jie Fu Date: 2021-11-20 10:12:26 +0000 URL: https://git.openjdk.java.net/loom/commit/0a9e76c4f9d966015c19e87e3eb59ceb7489459f 8277485: Zero: Fix _fast_{i,f}access_0 bytecodes handling Reviewed-by: sgehwolf, shade ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp Changeset: 4ff43010 Author: Joe Darcy Date: 2021-11-21 20:42:37 +0000 URL: https://git.openjdk.java.net/loom/commit/4ff43010bb3f92bd58f66be52a086b3d078b0cbb 8224922: Access JavaFileObject from Element(s) Co-authored-by: Jan Lahoda Reviewed-by: jjg ! src/java.compiler/share/classes/javax/annotation/processing/Filer.java ! src/java.compiler/share/classes/javax/lang/model/element/ExecutableElement.java ! src/java.compiler/share/classes/javax/lang/model/element/package-info.java ! src/java.compiler/share/classes/javax/lang/model/util/Elements.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/model/JavacElements.java + test/langtools/tools/javac/processing/model/element/TestFileObjectOf.java ! test/langtools/tools/javac/tree/NoPrivateTypesExported.java Changeset: ca31ed53 Author: TatWai Chong Date: 2021-11-22 02:31:33 +0000 URL: https://git.openjdk.java.net/loom/commit/ca31ed5335f6fa7229c94ba20d9d6031b930d69a 8275448: [REDO] AArch64: Implement string_compare intrinsic in SVE Reviewed-by: ngasson, aph ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/aarch64_sve.ad ! src/hotspot/cpu/aarch64/aarch64_sve_ad.m4 ! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/register_aarch64.hpp ! src/hotspot/cpu/aarch64/register_definitions_aarch64.cpp ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp + test/micro/org/openjdk/bench/java/lang/StringCompareToDifferentLength.java Changeset: 3f847fe8 Author: Aleksey Shipilev Date: 2021-11-22 09:09:21 +0000 URL: https://git.openjdk.java.net/loom/commit/3f847fe89a088d6921107ca887a7a1bace871bd6 8277385: Zero: Enable CompactStrings support Reviewed-by: redestad, adinn ! src/hotspot/cpu/zero/globals_zero.hpp Changeset: 8051041e Author: Albert Mingkun Yang Date: 2021-11-22 09:59:09 +0000 URL: https://git.openjdk.java.net/loom/commit/8051041eb2b3d70d4cc62b6f2726279d51e44733 8277534: Remove unused ReferenceProcessor::has_discovered_references Reviewed-by: tschatzl ! src/hotspot/share/gc/shared/referenceProcessor.cpp ! src/hotspot/share/gc/shared/referenceProcessor.hpp Changeset: 32839ba0 Author: Serguei Spitsyn Date: 2021-11-22 10:47:47 +0000 URL: https://git.openjdk.java.net/loom/commit/32839ba012f0a0a66e249cd8d12b94499d82ec0a 8266593: vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be" Reviewed-by: mdoerr, lmesnik, dcubed ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! test/hotspot/jtreg/ProblemList.txt Changeset: d427c79d Author: Hamlin Li Date: 2021-11-22 11:27:05 +0000 URL: https://git.openjdk.java.net/loom/commit/d427c79d3bd6c80b67c10d15a461f13ae7e0f84b 8277428: G1: Move and inline G1STWIsAliveClosure::do_object_b Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp ! src/hotspot/share/gc/g1/g1YoungCollector.cpp Changeset: 6b4fbaed Author: Jim Laskey Date: 2021-11-22 16:17:01 +0000 URL: https://git.openjdk.java.net/loom/commit/6b4fbaedbb782c5f028735ac1d92838895589192 8273792: JumpableGenerator.rngs() documentation refers to wrong method Co-authored-by: Guy Steele Reviewed-by: rriggs ! src/java.base/share/classes/java/util/random/RandomGenerator.java Changeset: 8683de5e Author: Jim Laskey Date: 2021-11-22 16:19:23 +0000 URL: https://git.openjdk.java.net/loom/commit/8683de5eda2d1a04f187073f969140245908f324 8274685: Documentation suggests there are ArbitrarilyJumpableGenerator when none Co-authored-by: Guy Steele Reviewed-by: rriggs ! src/java.base/share/classes/java/util/random/package-info.java Changeset: 70b2a4f3 Author: Alan Bateman Date: 2021-11-25 10:36:20 +0000 URL: https://git.openjdk.java.net/loom/commit/70b2a4f3723379ba7e36115651b2b18bd7acee5d Merge with jdk-18+25 ! make/conf/jib-profiles.js ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp ! src/hotspot/cpu/x86/nativeInst_x86.cpp ! src/hotspot/cpu/x86/nativeInst_x86.hpp ! src/hotspot/cpu/x86/x86_32.ad ! src/hotspot/share/c1/c1_LIR.cpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/c1/c1_LIRGenerator.hpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/code/compiledMethod.cpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/g1/g1FullGCCompactTask.cpp ! src/hotspot/share/gc/g1/g1FullGCCompactionPoint.cpp ! src/hotspot/share/gc/g1/g1FullGCOopClosures.inline.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/gc/parallel/psScavenge.cpp ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/serial/markSweep.inline.hpp ! src/hotspot/share/gc/shared/collectedHeap.hpp ! src/hotspot/share/gc/shared/space.cpp ! src/hotspot/share/gc/z/zCollectedHeap.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/oops/oop.inline.hpp ! src/hotspot/share/opto/runtime.cpp ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/java.base/share/classes/java/io/OutputStreamWriter.java ! src/java.base/share/classes/java/io/PrintStream.java ! src/java.base/share/classes/java/io/PrintWriter.java ! src/java.base/share/classes/java/lang/System.java ! src/java.desktop/share/classes/com/sun/media/sound/RealTimeSequencer.java ! test/hotspot/jtreg/ProblemList.txt ! test/jdk/ProblemList.txt ! make/conf/jib-profiles.js ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp ! src/hotspot/cpu/x86/nativeInst_x86.cpp ! src/hotspot/cpu/x86/nativeInst_x86.hpp ! src/hotspot/cpu/x86/x86_32.ad ! src/hotspot/share/c1/c1_LIR.cpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/c1/c1_LIRGenerator.hpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/code/compiledMethod.cpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp ! src/hotspot/share/gc/g1/g1FullGCCompactTask.cpp ! src/hotspot/share/gc/g1/g1FullGCCompactionPoint.cpp ! src/hotspot/share/gc/g1/g1FullGCOopClosures.inline.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/gc/parallel/psScavenge.cpp ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/serial/markSweep.inline.hpp ! src/hotspot/share/gc/shared/collectedHeap.hpp ! src/hotspot/share/gc/shared/space.cpp ! src/hotspot/share/gc/z/zCollectedHeap.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/oops/oop.inline.hpp ! src/hotspot/share/opto/runtime.cpp ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/java.base/share/classes/java/io/OutputStreamWriter.java ! src/java.base/share/classes/java/io/PrintStream.java ! src/java.base/share/classes/java/io/PrintWriter.java ! src/java.base/share/classes/java/lang/System.java ! src/java.desktop/share/classes/com/sun/media/sound/RealTimeSequencer.java ! test/hotspot/jtreg/ProblemList.txt ! test/jdk/ProblemList.txt From duke at openjdk.java.net Thu Nov 25 11:51:25 2021 From: duke at openjdk.java.net (duke) Date: Thu, 25 Nov 2021 11:51:25 GMT Subject: git: openjdk/loom: master: 67 new changesets Message-ID: Changeset: a907b2b1 Author: Coleen Phillimore Date: 2021-11-17 19:53:55 +0000 URL: https://git.openjdk.java.net/loom/commit/a907b2b144f2af27392eb7c2f9656fbb1a759618 8276177: nsk/jvmti/RedefineClasses/StressRedefineWithoutBytecodeCorruption failed with "assert(def_ik->is_being_redefined()) failed: should be being redefined to get here" Reviewed-by: hseigel, sspitsyn ! src/hotspot/share/oops/instanceKlass.hpp ! src/hotspot/share/utilities/accessFlags.hpp ! test/hotspot/jtreg/ProblemList.txt Changeset: 262d0700 Author: Weijun Wang Date: 2021-11-17 20:03:55 +0000 URL: https://git.openjdk.java.net/loom/commit/262d07001babcbe7f9acd2053aa3b7bac304cf85 8277246: Check for NonRepudiation as well when validating a TSA certificate Reviewed-by: xuelei, mullan ! src/java.base/share/classes/sun/security/validator/EndEntityChecker.java ! test/jdk/sun/security/tools/jarsigner/TimestampCheck.java Changeset: 8881f29b Author: Dean Long Date: 2021-11-17 20:18:07 +0000 URL: https://git.openjdk.java.net/loom/commit/8881f29bc83336bcbc0e8ff0cf1d2bbe55172f5c 8277310: ciReplay: @cpi MethodHandle references not resolved Reviewed-by: chagedorn, thartmann ! src/hotspot/share/ci/ciReplay.cpp Changeset: 007ad7c7 Author: Joe Darcy Date: 2021-11-17 20:23:43 +0000 URL: https://git.openjdk.java.net/loom/commit/007ad7c77c6277ce733386b4402b787d81dd41cf 8277303: Terminology mismatch between JLS17-3.9 and SE17's javax.lang.model.SourceVersion method specs Reviewed-by: iris, jjg ! src/java.compiler/share/classes/javax/lang/model/SourceVersion.java Changeset: d8c02802 Author: Dean Long Date: 2021-11-17 20:26:25 +0000 URL: https://git.openjdk.java.net/loom/commit/d8c0280273fa9f8e113088d6a43a4af076cd4f87 8277316: ciReplay: dump_replay_data is not thread-safe Reviewed-by: chagedorn, thartmann ! src/hotspot/share/ci/ciEnv.cpp Changeset: 6bb04626 Author: Sean Coffey Date: 2021-11-17 20:50:46 +0000 URL: https://git.openjdk.java.net/loom/commit/6bb04626af6574ef1e8d4b7dad0389d4b59f5d08 8277224: sun.security.pkcs.PKCS9Attributes.toString() throws NPE Reviewed-by: weijun ! src/java.base/share/classes/sun/security/pkcs/PKCS9Attributes.java ! test/jdk/sun/security/x509/AlgorithmId/NonStandardNames.java Changeset: 45a60db5 Author: Albert Mingkun Yang Date: 2021-11-17 21:02:13 +0000 URL: https://git.openjdk.java.net/loom/commit/45a60db5a0aa78fa9eb1c2899bd167c136e0fa03 8277045: G1: Remove unnecessary set_concurrency call in G1ConcurrentMark::weak_refs_work Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp Changeset: ce4471f8 Author: Daniel D. Daugherty Date: 2021-11-17 21:23:38 +0000 URL: https://git.openjdk.java.net/loom/commit/ce4471f806e51bc9f9ad746b69ba490443947110 8277346: ProblemList 7 serviceability/sa tests on macosx-x64 8277351: ProblemList runtime/jni/checked/TestPrimitiveArrayCriticalWithBadParam.java on macosx-x64 Reviewed-by: tschatzl, bpb ! test/hotspot/jtreg/ProblemList.txt Changeset: 29e552c0 Author: Sergey Bylokhov Date: 2021-11-17 22:21:38 +0000 URL: https://git.openjdk.java.net/loom/commit/29e552c03a2825f9526330072668a1d63ac68fd4 8272358: Some tests may fail when executed with other locales than the US Reviewed-by: aivanov ! test/langtools/jdk/jshell/ToolBasicTest.java ! test/langtools/jdk/jshell/ToolSimpleTest.java ! test/langtools/tools/javac/lambda/lambdaExecution/LambdaTranslationTest1.java ! test/langtools/tools/javac/lambda/lambdaExecution/LambdaTranslationTest2.java Changeset: 231fb61a Author: Naoto Sato Date: 2021-11-18 01:12:12 +0000 URL: https://git.openjdk.java.net/loom/commit/231fb61aaeae04787c06a4c972197943d9085627 8276970: Default charset for PrintWriter that wraps PrintStream Reviewed-by: rriggs, alanb ! src/java.base/share/classes/java/io/OutputStreamWriter.java ! src/java.base/share/classes/java/io/PrintStream.java ! src/java.base/share/classes/java/io/PrintWriter.java + test/jdk/java/io/PrintStream/InheritEncodingTest.java Changeset: b8453ebd Author: Naoto Sato Date: 2021-11-18 01:13:26 +0000 URL: https://git.openjdk.java.net/loom/commit/b8453ebdb471e08cc8d62c777f33ad52902f67d7 8275007: Java fails to start with null charset if LC_ALL is set to certain locales Reviewed-by: rriggs, iris, joehw, alanb ! src/java.base/share/classes/java/lang/System.java ! src/java.base/share/native/libjava/jni_util.c Changeset: 81938001 Author: Fei Gao Committer: Ningsheng Jian Date: 2021-11-18 02:41:27 +0000 URL: https://git.openjdk.java.net/loom/commit/81938001f9bae56c59f4e18b7756089f2cf0bf74 8274179: AArch64: Support SVE operations with encodable immediates Reviewed-by: aph, ngasson ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/aarch64_sve.ad ! src/hotspot/cpu/aarch64/aarch64_sve_ad.m4 ! src/hotspot/cpu/aarch64/assembler_aarch64.cpp ! src/hotspot/cpu/aarch64/assembler_aarch64.hpp ! test/hotspot/gtest/aarch64/aarch64-asmtest.py ! test/hotspot/gtest/aarch64/asmtest.out.h ! test/hotspot/jtreg/compiler/codegen/TestByteVect.java ! test/hotspot/jtreg/compiler/codegen/TestCharVect.java ! test/hotspot/jtreg/compiler/codegen/TestIntVect.java ! test/hotspot/jtreg/compiler/codegen/TestLongVect.java ! test/hotspot/jtreg/compiler/codegen/TestShortVect.java Changeset: 91607436 Author: Prasanta Sadhukhan Date: 2021-11-18 04:33:49 +0000 URL: https://git.openjdk.java.net/loom/commit/91607436b79126ccb999deaf38a98209dbfe6ec1 8276058: Some swing test fails on specific CI macos system Reviewed-by: prr, kizune ! test/jdk/ProblemList.txt ! test/jdk/java/awt/Dialog/MakeWindowAlwaysOnTop/MakeWindowAlwaysOnTop.java ! test/jdk/javax/swing/JButton/8151303/PressedIconTest.java ! test/jdk/javax/swing/JInternalFrame/8069348/bug8069348.java ! test/jdk/javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java Changeset: 2f4b5405 Author: Doug Simon Date: 2021-11-18 08:32:54 +0000 URL: https://git.openjdk.java.net/loom/commit/2f4b5405f0b53782f3ed5274f68b31eb968efb6d 8276314: [JVMCI] check alignment of call displacement during code installation Reviewed-by: kvn ! src/hotspot/cpu/x86/jvmciCodeInstaller_x86.cpp ! src/hotspot/cpu/x86/nativeInst_x86.cpp ! src/hotspot/cpu/x86/nativeInst_x86.hpp Changeset: db55f927 Author: Ioi Lam Date: 2021-11-18 08:49:07 +0000 URL: https://git.openjdk.java.net/loom/commit/db55f9272c0889f4ea4dee0f4aa3d9613fadb2f8 8277343: dynamicArchive/SharedArchiveFileOption.java failed: '-XX:+RecordDynamicDumpInfo is unsupported when a dynamic CDS archive is specified in -XX:SharedArchiveFile:' missing Reviewed-by: hseigel, ccheung ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/DynamicArchiveTestBase.java ! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/SharedArchiveFileOption.java Changeset: 0a65e8b2 Author: Andrey Turbanov Committer: Alexey Ivanov Date: 2021-11-18 10:48:16 +0000 URL: https://git.openjdk.java.net/loom/commit/0a65e8b282fd41e57108422fbd140527d9697efd 8276794: Change nested classes in java.desktop to static nested classes Reviewed-by: serb, aivanov ! src/java.desktop/macosx/classes/com/apple/eawt/_AppEventHandler.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaFileChooserUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaFileSystemModel.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaInternalFramePaneUI.java ! src/java.desktop/macosx/classes/com/apple/laf/AquaTabbedPaneCopyFromBasicUI.java ! src/java.desktop/macosx/classes/sun/java2d/metal/MTLRenderer.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/DHTMarkerSegment.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/DQTMarkerSegment.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/JFIFMarkerSegment.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/SOFMarkerSegment.java ! src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/SOSMarkerSegment.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKColorChooserPanel.java ! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifDesktopPaneUI.java ! src/java.desktop/share/classes/com/sun/media/sound/EventDispatcher.java ! src/java.desktop/share/classes/com/sun/media/sound/RealTimeSequencer.java ! src/java.desktop/share/classes/com/sun/media/sound/SoftMainMixer.java ! src/java.desktop/share/classes/com/sun/media/sound/SunFileWriter.java ! src/java.desktop/share/classes/java/awt/CardLayout.java ! src/java.desktop/share/classes/java/awt/Component.java ! src/java.desktop/share/classes/java/awt/Polygon.java ! src/java.desktop/share/classes/java/awt/ScrollPane.java ! src/java.desktop/share/classes/java/awt/Toolkit.java ! src/java.desktop/share/classes/java/awt/print/Book.java ! src/java.desktop/share/classes/java/beans/XMLEncoder.java ! src/java.desktop/share/classes/javax/imageio/metadata/IIOMetadataFormatImpl.java ! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterStateReasons.java ! src/java.desktop/share/classes/javax/sound/sampled/AudioInputStream.java ! src/java.desktop/share/classes/javax/swing/GroupLayout.java ! src/java.desktop/share/classes/javax/swing/JComboBox.java ! src/java.desktop/share/classes/javax/swing/JComponent.java ! src/java.desktop/share/classes/javax/swing/JTable.java ! src/java.desktop/share/classes/javax/swing/KeyboardManager.java ! src/java.desktop/share/classes/javax/swing/RepaintManager.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicDesktopPaneUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicInternalFrameTitlePane.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicPopupMenuUI.java ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalComboBoxEditor.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalIconFactory.java ! src/java.desktop/share/classes/javax/swing/plaf/nimbus/NimbusLookAndFeel.java ! src/java.desktop/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTabbedPaneUI.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTableUI.java ! src/java.desktop/share/classes/javax/swing/text/DefaultHighlighter.java ! src/java.desktop/share/classes/javax/swing/text/ElementIterator.java ! src/java.desktop/share/classes/javax/swing/text/JTextComponent.java ! src/java.desktop/share/classes/javax/swing/text/StringContent.java ! src/java.desktop/share/classes/javax/swing/text/StyleContext.java ! src/java.desktop/share/classes/javax/swing/text/html/ImageView.java ! src/java.desktop/share/classes/javax/swing/text/html/TableView.java ! src/java.desktop/share/classes/javax/swing/text/rtf/RTFReader.java ! src/java.desktop/share/classes/javax/swing/tree/DefaultMutableTreeNode.java ! src/java.desktop/share/classes/sun/awt/PlatformFont.java ! src/java.desktop/share/classes/sun/java2d/loops/RenderCache.java ! src/java.desktop/share/classes/sun/java2d/opengl/OGLRenderer.java ! src/java.desktop/share/classes/sun/java2d/pipe/GeneralCompositePipe.java ! src/java.desktop/share/classes/sun/java2d/pipe/SpanClipRenderer.java ! src/java.desktop/share/classes/sun/print/PrintJob2D.java ! src/java.desktop/share/classes/sun/print/RasterPrinterJob.java ! src/java.desktop/share/classes/sun/print/ServiceDialog.java ! src/java.desktop/share/classes/sun/swing/plaf/synth/SynthFileChooserUI.java ! src/java.desktop/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java ! src/java.desktop/share/classes/sun/swing/table/DefaultTableCellHeaderRenderer.java ! src/java.desktop/unix/classes/sun/awt/X11/XTextAreaPeer.java ! src/java.desktop/unix/classes/sun/awt/X11/XTextFieldPeer.java ! src/java.desktop/unix/classes/sun/font/X11GB2312.java ! src/java.desktop/unix/classes/sun/font/X11GBK.java ! src/java.desktop/unix/classes/sun/font/X11KSC5601.java ! src/java.desktop/unix/classes/sun/print/IPPPrintService.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsComboBoxUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java ! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/XPStyle.java ! src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java ! src/java.desktop/windows/classes/sun/awt/windows/WScrollPanePeer.java ! src/java.desktop/windows/classes/sun/java2d/d3d/D3DRenderer.java Changeset: 77cc5088 Author: Albert Mingkun Yang Date: 2021-11-18 10:52:55 +0000 URL: https://git.openjdk.java.net/loom/commit/77cc508802899b370f1cdf592331f81efb8d9208 8277215: Remove redundancy in ReferenceProcessor constructor args Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/gc/parallel/psScavenge.cpp ! src/hotspot/share/gc/shared/referenceProcessor.cpp ! src/hotspot/share/gc/shared/referenceProcessor.hpp Changeset: 2c06bca9 Author: Erik ?sterlund Date: 2021-11-18 11:17:00 +0000 URL: https://git.openjdk.java.net/loom/commit/2c06bca98fcf9d129d6085e26c225fb26368a558 8266368: Inaccurate after_unwind hook in C2 exception handler Reviewed-by: dlong, thartmann ! src/hotspot/share/opto/runtime.cpp ! src/hotspot/share/runtime/sharedRuntime.cpp Changeset: 38345bd2 Author: Evgeny Astigeevich Committer: Volker Simonis Date: 2021-11-18 11:18:15 +0000 URL: https://git.openjdk.java.net/loom/commit/38345bd28db83371676f1685806ddc207a833879 8277137: Set OnSpinWaitInst/OnSpinWaitInstCount defaults to "isb"/1 for Arm Neoverse N1 Reviewed-by: phh, aph, ngasson ! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp + test/hotspot/jtreg/compiler/onSpinWait/TestOnSpinWaitAArch64DefaultFlags.java Changeset: b3a62b48 Author: Harold Seigel Date: 2021-11-18 13:18:37 +0000 URL: https://git.openjdk.java.net/loom/commit/b3a62b48816358ac7dadde4e7893190500ca7b79 8276795: Deprecate seldom used CDS flags Reviewed-by: dholmes, ccheung, iklam ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp ! test/hotspot/jtreg/compiler/intrinsics/klass/TestIsPrimitive.java ! test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java Changeset: a44b45fd Author: Sean Mullan Date: 2021-11-18 13:48:12 +0000 URL: https://git.openjdk.java.net/loom/commit/a44b45fdf31275a2c1e9d1d0132874a7de45f8ee 4337793: Mark non-serializable fields of java.security.cert.Certificate and CertPath Reviewed-by: valeriep, rriggs ! src/java.base/share/classes/java/security/cert/CertPath.java ! src/java.base/share/classes/java/security/cert/Certificate.java Changeset: 00c388b4 Author: Erik ?sterlund Date: 2021-11-18 14:32:59 +0000 URL: https://git.openjdk.java.net/loom/commit/00c388b4aba41d5f0874585e9c0a33c4571805f6 8259643: ZGC can return metaspace OOM prematurely Reviewed-by: stefank, pliden, stuefe ! src/hotspot/share/gc/z/zCollectedHeap.cpp ! src/hotspot/share/memory/metaspace.cpp + src/hotspot/share/memory/metaspaceCriticalAllocation.cpp + src/hotspot/share/memory/metaspaceCriticalAllocation.hpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp Changeset: d93b238f Author: Erik ?sterlund Date: 2021-11-18 14:44:58 +0000 URL: https://git.openjdk.java.net/loom/commit/d93b238f9725727ae1e2e9f203943b5ddf778f35 8277180: Intrinsify recursive ObjectMonitor locking for C2 x64 and A64 Reviewed-by: aph, ngasson ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp Changeset: 276bfcd1 Author: Prasanta Sadhukhan Date: 2021-11-18 15:17:59 +0000 URL: https://git.openjdk.java.net/loom/commit/276bfcd1a115f90dde644abef79d64bb61788c75 8277407: javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java fails to compile after JDK-8276058 Reviewed-by: dcubed ! test/jdk/javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java Changeset: 354a34ea Author: Albert Mingkun Yang Date: 2021-11-18 15:54:04 +0000 URL: https://git.openjdk.java.net/loom/commit/354a34ea2077c9372e585adb1303df604827a2e2 8277336: Improve CollectedHeap::safepoint_workers comments Reviewed-by: sjohanss, tschatzl ! src/hotspot/share/gc/shared/collectedHeap.hpp Changeset: 5d249c46 Author: Alexander Zuev Date: 2021-11-18 16:07:38 +0000 URL: https://git.openjdk.java.net/loom/commit/5d249c46abc8dfdc3acdaff41d26f3bd9ba84731 8275071: [macos] A11y cursor gets stuck when combobox is closed Reviewed-by: serb, pbansal ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessible.java Changeset: ce0f00f6 Author: Thomas Schatzl Date: 2021-11-18 16:59:41 +0000 URL: https://git.openjdk.java.net/loom/commit/ce0f00f66e78a504d5e40a25fa213325ec0af394 8276093: Improve naming in closures to iterate over card sets Reviewed-by: sjohanss, ayang ! src/hotspot/share/gc/g1/g1CardSet.cpp ! src/hotspot/share/gc/g1/g1CardSet.hpp ! src/hotspot/share/gc/g1/g1CardSet.inline.hpp ! src/hotspot/share/gc/g1/heapRegionRemSet.inline.hpp ! test/hotspot/gtest/gc/g1/test_g1CardSet.cpp Changeset: 03473b4c Author: Sergey Bylokhov Date: 2021-11-18 18:25:38 +0000 URL: https://git.openjdk.java.net/loom/commit/03473b4c271b2ec7f0ebdb0edabadf7f36816b9d 8270874: JFrame paint artifacts when dragged from standard monitor to HiDPI monitor Reviewed-by: jdv ! src/java.desktop/windows/native/libawt/windows/awt_Component.cpp ! test/jdk/java/awt/Window/WindowResizingOnDPIChanging/WindowResizingOnMovingToAnotherDisplay.java Changeset: 8db0c361 Author: Daniel D. Daugherty Date: 2021-11-18 18:40:26 +0000 URL: https://git.openjdk.java.net/loom/commit/8db0c361a39cf10d373c3d2dfa54267cf53452db 8277414: ProblemList runtime/CommandLine/VMDeprecatedOptions.java on windows-x64 Reviewed-by: mikael, iklam ! test/hotspot/jtreg/ProblemList.txt Changeset: 57eb8647 Author: Niklas Radomski Committer: Martin Doerr Date: 2021-11-18 19:00:58 +0000 URL: https://git.openjdk.java.net/loom/commit/57eb864765f38185f8db8f1d37681d6cfe2a3c73 8276927: [PPC64] Port shenandoahgc to linux on ppc64le Reviewed-by: rkennke, ihse, mdoerr ! make/autoconf/jvm-features.m4 ! make/hotspot/gensrc/GensrcAdlc.gmk ! src/hotspot/cpu/ppc/gc/shared/barrierSetAssembler_ppc.cpp + src/hotspot/cpu/ppc/gc/shenandoah/c1/shenandoahBarrierSetC1_ppc.cpp + src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp + src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.hpp + src/hotspot/cpu/ppc/gc/shenandoah/shenandoah_ppc.ad ! src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp Changeset: 36bd4a35 Author: Harold Seigel Date: 2021-11-18 20:06:13 +0000 URL: https://git.openjdk.java.net/loom/commit/36bd4a35fbee077c00c1f4240f1f02f4d7d5f656 8277404: Test VMDeprecatedOptions.java failing with Unable to create shared archive file Reviewed-by: dcubed ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java Changeset: 89b125f4 Author: Roman Kennke Date: 2021-11-18 21:32:00 +0000 URL: https://git.openjdk.java.net/loom/commit/89b125f4d4d6a467185b4b39861fd530a738e67f 8275527: Refactor forward pointer access Reviewed-by: tschatzl, stefank ! src/hotspot/share/gc/g1/g1FullGCCompactTask.cpp ! src/hotspot/share/gc/g1/g1FullGCCompactionPoint.cpp ! src/hotspot/share/gc/g1/g1FullGCOopClosures.inline.hpp ! src/hotspot/share/gc/g1/g1FullGCPrepareTask.cpp ! src/hotspot/share/gc/g1/g1OopClosures.inline.hpp ! src/hotspot/share/gc/g1/g1YoungCollector.cpp ! src/hotspot/share/gc/serial/markSweep.inline.hpp ! src/hotspot/share/gc/shared/space.cpp ! src/hotspot/share/oops/oop.inline.hpp Changeset: 839033ba Author: Man Cao Date: 2021-11-18 23:35:01 +0000 URL: https://git.openjdk.java.net/loom/commit/839033baf61ca7f10437e8e53b2114b081d97ea9 8276976: Rename LIR_OprDesc to LIR_Opr Co-authored-by: Chuck Rasbold Reviewed-by: thartmann, iveresov ! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c1_LIR_aarch64.cpp ! src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp ! src/hotspot/cpu/arm/c1_LIR_arm.cpp ! src/hotspot/cpu/ppc/c1_LIR_ppc.cpp ! src/hotspot/cpu/s390/c1_LIR_s390.cpp ! src/hotspot/cpu/x86/c1_LIR_x86.cpp ! src/hotspot/share/c1/c1_LIR.cpp ! src/hotspot/share/c1/c1_LIR.hpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/c1/c1_LIRGenerator.hpp ! src/hotspot/share/c1/c1_LinearScan.cpp ! src/hotspot/share/c1/c1_LinearScan.hpp ! src/hotspot/share/gc/g1/c1/g1BarrierSetC1.cpp Changeset: 2f0bde1a Author: Yi Yang Date: 2021-11-19 02:04:48 +0000 URL: https://git.openjdk.java.net/loom/commit/2f0bde1a658b0910304c110920a2e8ccbe4557f8 8277102: Dubious PrintCompilation output Reviewed-by: thartmann, dnsimon ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/compiler/compileTask.cpp ! src/hotspot/share/compiler/compileTask.hpp ! test/hotspot/jtreg/compiler/jvmci/compilerToVM/DisassembleCodeBlobTest.java Changeset: 47564cae Author: Tobias Hartmann Date: 2021-11-19 07:07:17 +0000 URL: https://git.openjdk.java.net/loom/commit/47564caeb0628e5c03a0e7f04093adce77d6dd3b 8275643: C2's unaryOp vector intrinsic does not properly handle LongVector.neg Reviewed-by: chagedorn, sviswanathan ! src/hotspot/share/prims/vectorSupport.cpp + test/hotspot/jtreg/compiler/vectorapi/TestLongVectorNeg.java Changeset: f34f1190 Author: Tobias Hartmann Date: 2021-11-19 07:13:05 +0000 URL: https://git.openjdk.java.net/loom/commit/f34f119080b4e8baf396fb26c21d572dd432fd91 8277213: CompileTask_lock is acquired out of order with MethodCompileQueue_lock Reviewed-by: rbackman, coleenp ! src/hotspot/share/compiler/compileTask.hpp Changeset: 2f20b0d8 Author: Jan Lahoda Date: 2021-11-19 07:49:58 +0000 URL: https://git.openjdk.java.net/loom/commit/2f20b0d8daca6bdc53b4b9e1837c428930d34236 8273039: JShell crashes when naming variable or method "abstract" or "strictfp" Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! test/langtools/jdk/jshell/ErrorRecoveryTest.java + test/langtools/tools/javac/attr/AttrRecoveryTest.java Changeset: 3a76d397 Author: Tobias Hartmann Date: 2021-11-19 08:23:45 +0000 URL: https://git.openjdk.java.net/loom/commit/3a76d397949ad22e4786476e583cc9d33c015214 8277324: C2 compilation fails with "bad AD file" on x86-32 after JDK-8276162 due to missing match rule Reviewed-by: chagedorn, roland ! src/hotspot/cpu/x86/x86_32.ad Changeset: 7a046e0f Author: Albert Mingkun Yang Date: 2021-11-19 08:31:09 +0000 URL: https://git.openjdk.java.net/loom/commit/7a046e0f765e0ad04fd52c9a882c5d90b085bc00 8277371: Remove unnecessary DefNewGeneration::ref_processor_init() Reviewed-by: stefank, tschatzl, mli ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/serial/defNewGeneration.hpp ! src/hotspot/share/gc/shared/generation.hpp Changeset: 11d819d6 Author: Hamlin Li Date: 2021-11-19 10:15:30 +0000 URL: https://git.openjdk.java.net/loom/commit/11d819d68a3ce2ae0973b496141c52aa419f90f0 8277439: G1: Correct include guard name in G1EvacFailureObjectsSet.hpp Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/g1/g1EvacFailureObjectsSet.hpp Changeset: b15e6f07 Author: Jie Fu Date: 2021-11-19 10:38:42 +0000 URL: https://git.openjdk.java.net/loom/commit/b15e6f076afe5ac68e9af68756860d0b25adea4b 8277449: compiler/vectorapi/TestLongVectorNeg.java fails with release VMs Reviewed-by: thartmann, chagedorn ! test/hotspot/jtreg/compiler/vectorapi/TestLongVectorNeg.java Changeset: 03debf27 Author: Daniel Fuchs Date: 2021-11-19 13:18:12 +0000 URL: https://git.openjdk.java.net/loom/commit/03debf277537135974d3f55e3a5c7cf6842ee5e0 8276774: Cookie stored in CookieHandler not sent if user headers contain cookie Reviewed-by: michaelm ! src/java.net.http/share/classes/jdk/internal/net/http/Http1Request.java ! src/java.net.http/share/classes/jdk/internal/net/http/Stream.java ! test/jdk/java/net/httpclient/CookieHeaderTest.java = test/jdk/java/net/httpclient/UserCookieTest.java Changeset: b1a1bf4e Author: Claes Redestad Date: 2021-11-19 13:25:40 +0000 URL: https://git.openjdk.java.net/loom/commit/b1a1bf4e305d6675f8f751aa8fef7013d99466f1 8277427: Update jib-profiles.js to use JMH 1.33 devkit Reviewed-by: shade, erikj ! make/conf/jib-profiles.js Changeset: a0227965 Author: Magnus Ihse Bursie Committer: Magnus Ihse Bursie Date: 2021-11-19 13:55:08 +0000 URL: https://git.openjdk.java.net/loom/commit/a0227965bb8d1d49718794d67f8a4cfeebc9bec2 8275745: Reproducible copyright headers Reviewed-by: ihse, erikj ! make/autoconf/basic_tools.m4 ! make/autoconf/jdk-options.m4 ! make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java ! make/jdk/src/classes/build/tools/cldrconverter/CopyrightHeaders.java ! make/jdk/src/classes/build/tools/cldrconverter/ResourceBundleGenerator.java ! make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java ! make/modules/java.base/Gensrc.gmk ! make/modules/jdk.localedata/Gensrc.gmk Changeset: 936f7ff4 Author: Andy Herrick Date: 2021-11-19 14:23:04 +0000 URL: https://git.openjdk.java.net/loom/commit/936f7ff49ed86adb74bb1ff10d93cb3d7f7d70a0 8276150: Quarantined jpackage apps are labeled as "damaged" Reviewed-by: almatvee ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppImageBuilder.java ! test/jdk/tools/jpackage/macosx/SigningAppImageTest.java Changeset: 03f8c0fb Author: Sean Mullan Date: 2021-11-19 14:36:07 +0000 URL: https://git.openjdk.java.net/loom/commit/03f8c0fb9363dc1bb07bed1ae0359c029caa0130 8275887: jarsigner prints invalid digest/signature algorithm warnings if keysize is weak/disabled Reviewed-by: weijun ! src/java.base/share/classes/sun/security/pkcs/SignerInfo.java ! src/java.base/share/classes/sun/security/provider/certpath/AlgorithmChecker.java ! src/java.base/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java ! src/java.base/share/classes/sun/security/util/DisabledAlgorithmConstraints.java ! src/java.base/share/classes/sun/security/util/JarConstraintsParameters.java ! src/java.base/share/classes/sun/security/util/ManifestEntryVerifier.java ! src/java.base/share/classes/sun/security/util/SignatureFileVerifier.java ! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java ! test/jdk/sun/security/tools/jarsigner/TimestampCheck.java Changeset: 976c2bb0 Author: Stefan Karlsson Date: 2021-11-19 15:34:22 +0000 URL: https://git.openjdk.java.net/loom/commit/976c2bb05611cdc7b11b0918aaf50ff693507aae 8277212: GC accidentally cleans valid megamorphic vtable inline caches Reviewed-by: eosterlund, pliden, coleenp, thartmann ! src/hotspot/share/code/compiledMethod.cpp Changeset: 09e8c8c6 Author: Coleen Phillimore Date: 2021-11-19 17:48:43 +0000 URL: https://git.openjdk.java.net/loom/commit/09e8c8c64abf4178a042c79b92d7e08e54467331 8277342: vmTestbase/nsk/stress/strace/strace004.java fails with SIGSEGV in InstanceKlass::jni_id_for Reviewed-by: dholmes, hseigel ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceKlass.hpp Changeset: 66775543 Author: Andrey Turbanov Committer: Roger Riggs Date: 2021-11-19 18:48:06 +0000 URL: https://git.openjdk.java.net/loom/commit/6677554374ade32c9f2ddaaa093064de8aebd831 8274949: Use String.contains() instead of String.indexOf() in java.base Reviewed-by: weijun, dfuchs, vtewari, lancea ! src/java.base/share/classes/java/net/HttpCookie.java ! src/java.base/share/classes/java/net/HttpURLConnection.java ! src/java.base/share/classes/java/net/SocketPermission.java ! src/java.base/share/classes/jdk/internal/jrtfs/JrtPath.java ! src/java.base/share/classes/jdk/internal/loader/URLClassPath.java ! src/java.base/share/classes/sun/net/www/http/HttpCapture.java ! src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java ! src/java.base/share/classes/sun/security/provider/PolicyFile.java ! src/java.base/share/classes/sun/security/rsa/RSAPSSSignature.java ! src/java.base/share/classes/sun/security/rsa/RSAUtil.java ! src/java.base/share/classes/sun/security/tools/keytool/Main.java ! src/java.base/share/classes/sun/security/util/Debug.java ! src/java.base/share/classes/sun/security/util/SignatureUtil.java ! src/java.base/share/classes/sun/security/x509/AlgorithmId.java ! src/java.base/share/classes/sun/util/locale/LocaleMatcher.java ! src/java.base/unix/classes/sun/net/www/protocol/jar/JarFileFactory.java ! src/java.base/windows/classes/sun/net/www/protocol/jar/JarFileFactory.java Changeset: 36b59f38 Author: Andrey Turbanov Committer: Roger Riggs Date: 2021-11-19 18:49:04 +0000 URL: https://git.openjdk.java.net/loom/commit/36b59f3814fdaa44c9c04a0e8d63d0ba56929326 8274333: Redundant null comparison after Pattern.split Reviewed-by: mullan, weijun, rriggs, iris ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/java.base/share/classes/sun/security/util/AlgorithmDecomposer.java Changeset: f609b8fd Author: Andrey Turbanov Committer: Roger Riggs Date: 2021-11-19 18:50:03 +0000 URL: https://git.openjdk.java.net/loom/commit/f609b8fd74c55f3149d8e5a6a9a9bc3598c0b961 8274946: Cleanup unnecessary calls to Throwable.initCause() in java.rmi Reviewed-by: iris, rriggs ! src/java.rmi/share/classes/java/rmi/server/RMIClassLoader.java ! src/java.rmi/share/classes/java/rmi/server/RemoteObjectInvocationHandler.java ! src/java.rmi/share/classes/javax/rmi/ssl/SslRMIClientSocketFactory.java ! src/java.rmi/share/classes/javax/rmi/ssl/SslRMIServerSocketFactory.java ! src/java.rmi/share/classes/sun/rmi/log/ReliableLog.java Changeset: e47cc81b Author: Andrey Turbanov Committer: Roger Riggs Date: 2021-11-19 18:51:13 +0000 URL: https://git.openjdk.java.net/loom/commit/e47cc81b095381266104e9137495e91fb4c225a4 8275386: Change nested classes in jdk.jlink to static nested classes Reviewed-by: alanb, rriggs, iris ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImagePluginStack.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ResourcePoolManager.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java Changeset: a3406a1d Author: Thomas Stuefe Date: 2021-11-19 19:49:57 +0000 URL: https://git.openjdk.java.net/loom/commit/a3406a1d8ab4228b06b4f2978f87275093c39468 8277092: TestMetaspaceAllocationMT2.java#ndebug-default fails with "RuntimeException: Committed seems high: NNNN expected at most MMMM" Reviewed-by: coleenp ! test/hotspot/jtreg/runtime/Metaspace/elastic/MetaspaceTestContext.java ! test/hotspot/jtreg/runtime/Metaspace/elastic/MetaspaceTestManyArenasManyThreads.java Changeset: 2d4af225 Author: Yasumasa Suenaga Date: 2021-11-19 20:24:17 +0000 URL: https://git.openjdk.java.net/loom/commit/2d4af2255feb2eaeca533424f8cba3ec0945d757 8277370: configure script cannot distinguish WSL version Reviewed-by: erikj ! make/autoconf/basic_windows.m4 Changeset: 2ab43ec2 Author: Pavel Rappo Date: 2021-11-19 20:51:22 +0000 URL: https://git.openjdk.java.net/loom/commit/2ab43ec2428edaebfe9a7fb0e716ff7141a28de0 8273544: Increase test coverage for snippets Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/SnippetTaglet.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Attribute.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Attributes.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Parser.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Replace.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/snippet/Style.java + test/langtools/jdk/javadoc/doclet/testSnippetTag/SnippetTester.java + test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetMarkup.java + test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetPathOption.java ! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java Changeset: c79a485f Author: Daniel D. Daugherty Date: 2021-11-19 22:37:28 +0000 URL: https://git.openjdk.java.net/loom/commit/c79a485f1c3f9c0c3a79b8847fdcd50a141cd529 8277494: [BACKOUT] JDK-8276150 Quarantined jpackage apps are labeled as "damaged" Reviewed-by: asemenyuk, tschatzl ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppImageBuilder.java ! test/jdk/tools/jpackage/macosx/SigningAppImageTest.java Changeset: 1d7cef33 Author: Derek White Date: 2021-11-20 00:48:32 +0000 URL: https://git.openjdk.java.net/loom/commit/1d7cef33c5ff24695463a03c58c7ca350ec190fc 8276662: Scalability bottleneck in SymbolTable::lookup_common() Reviewed-by: redestad, dholmes, iklam, shade ! src/hotspot/share/classfile/symbolTable.cpp Changeset: 1c215f33 Author: Vishal Chand Committer: Thomas Schatzl Date: 2021-11-20 10:03:45 +0000 URL: https://git.openjdk.java.net/loom/commit/1c215f33698ba2aef4fb230475a9bd33ed3005f9 8272773: Configurable card table card size Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1Arguments.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/parallel/objectStartArray.cpp ! src/hotspot/share/gc/parallel/objectStartArray.hpp ! src/hotspot/share/gc/parallel/parallelArguments.cpp ! src/hotspot/share/gc/shared/blockOffsetTable.cpp ! src/hotspot/share/gc/shared/blockOffsetTable.hpp ! src/hotspot/share/gc/shared/cardTable.cpp ! src/hotspot/share/gc/shared/cardTable.hpp ! src/hotspot/share/gc/shared/gc_globals.hpp ! src/hotspot/share/gc/shared/genArguments.cpp ! src/hotspot/share/gc/shared/jvmFlagConstraintsGC.cpp ! src/hotspot/share/gc/shared/jvmFlagConstraintsGC.hpp Changeset: 0a9e76c4 Author: Jie Fu Date: 2021-11-20 10:12:26 +0000 URL: https://git.openjdk.java.net/loom/commit/0a9e76c4f9d966015c19e87e3eb59ceb7489459f 8277485: Zero: Fix _fast_{i,f}access_0 bytecodes handling Reviewed-by: sgehwolf, shade ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp Changeset: 4ff43010 Author: Joe Darcy Date: 2021-11-21 20:42:37 +0000 URL: https://git.openjdk.java.net/loom/commit/4ff43010bb3f92bd58f66be52a086b3d078b0cbb 8224922: Access JavaFileObject from Element(s) Co-authored-by: Jan Lahoda Reviewed-by: jjg ! src/java.compiler/share/classes/javax/annotation/processing/Filer.java ! src/java.compiler/share/classes/javax/lang/model/element/ExecutableElement.java ! src/java.compiler/share/classes/javax/lang/model/element/package-info.java ! src/java.compiler/share/classes/javax/lang/model/util/Elements.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/model/JavacElements.java + test/langtools/tools/javac/processing/model/element/TestFileObjectOf.java ! test/langtools/tools/javac/tree/NoPrivateTypesExported.java Changeset: ca31ed53 Author: TatWai Chong Date: 2021-11-22 02:31:33 +0000 URL: https://git.openjdk.java.net/loom/commit/ca31ed5335f6fa7229c94ba20d9d6031b930d69a 8275448: [REDO] AArch64: Implement string_compare intrinsic in SVE Reviewed-by: ngasson, aph ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/aarch64_sve.ad ! src/hotspot/cpu/aarch64/aarch64_sve_ad.m4 ! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/register_aarch64.hpp ! src/hotspot/cpu/aarch64/register_definitions_aarch64.cpp ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp + test/micro/org/openjdk/bench/java/lang/StringCompareToDifferentLength.java Changeset: 3f847fe8 Author: Aleksey Shipilev Date: 2021-11-22 09:09:21 +0000 URL: https://git.openjdk.java.net/loom/commit/3f847fe89a088d6921107ca887a7a1bace871bd6 8277385: Zero: Enable CompactStrings support Reviewed-by: redestad, adinn ! src/hotspot/cpu/zero/globals_zero.hpp Changeset: 8051041e Author: Albert Mingkun Yang Date: 2021-11-22 09:59:09 +0000 URL: https://git.openjdk.java.net/loom/commit/8051041eb2b3d70d4cc62b6f2726279d51e44733 8277534: Remove unused ReferenceProcessor::has_discovered_references Reviewed-by: tschatzl ! src/hotspot/share/gc/shared/referenceProcessor.cpp ! src/hotspot/share/gc/shared/referenceProcessor.hpp Changeset: 32839ba0 Author: Serguei Spitsyn Date: 2021-11-22 10:47:47 +0000 URL: https://git.openjdk.java.net/loom/commit/32839ba012f0a0a66e249cd8d12b94499d82ec0a 8266593: vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state->get_thread()) failed: Must be" Reviewed-by: mdoerr, lmesnik, dcubed ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! test/hotspot/jtreg/ProblemList.txt Changeset: d427c79d Author: Hamlin Li Date: 2021-11-22 11:27:05 +0000 URL: https://git.openjdk.java.net/loom/commit/d427c79d3bd6c80b67c10d15a461f13ae7e0f84b 8277428: G1: Move and inline G1STWIsAliveClosure::do_object_b Reviewed-by: tschatzl, sjohanss ! src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp ! src/hotspot/share/gc/g1/g1YoungCollector.cpp Changeset: 6b4fbaed Author: Jim Laskey Date: 2021-11-22 16:17:01 +0000 URL: https://git.openjdk.java.net/loom/commit/6b4fbaedbb782c5f028735ac1d92838895589192 8273792: JumpableGenerator.rngs() documentation refers to wrong method Co-authored-by: Guy Steele Reviewed-by: rriggs ! src/java.base/share/classes/java/util/random/RandomGenerator.java Changeset: 8683de5e Author: Jim Laskey Date: 2021-11-22 16:19:23 +0000 URL: https://git.openjdk.java.net/loom/commit/8683de5eda2d1a04f187073f969140245908f324 8274685: Documentation suggests there are ArbitrarilyJumpableGenerator when none Co-authored-by: Guy Steele Reviewed-by: rriggs ! src/java.base/share/classes/java/util/random/package-info.java From raulraja at gmail.com Thu Nov 25 19:21:42 2021 From: raulraja at gmail.com (Raul Raja Martinez) Date: Thu, 25 Nov 2021 20:21:42 +0100 Subject: Access to Continuation.yield and ContinuationScope In-Reply-To: References: Message-ID: Thanks!, that worked for my local tests. Are there any plans to bring back Continuation and ContinuationScope to public status to `java.lang` or similar or is the plan that this is going to remain internal? I'm aware of other libs in the space that also depend on their public status to perform operations unrelated to concurrency but related to the power of shifting control by yielding a scope in the continuation. thanks! On Thu, Nov 25, 2021 at 2:37 AM Glavo wrote: > You can add the --add-opens option at runtime, like this: > > java --add-opens java.base/jdk.internal.vm=ALL-UNNAMED > > > Raul Raja Martinez ?2021?11?25??? ??7:56??? > >> Hello everyone, >> >> First, thank you for LOOM and the extraordinary work done here. I'm >> excited >> to see this coming to a final release. >> >> I have been using LOOM builds up until recently, building abstractions >> directly on top of what used to be `java.lang.Continuation` and the >> `Continuation.yield` capabilities. I have noticed in the latest build >> these >> became internal in the jdk.internal.vm package. >> >> When I link against those I get errors like: >> >> java.lang.IllegalAccessError: superclass access check failed: class >> fx.Continuation$package$$anon$1 (in unnamed module @0x1f75bcda) cannot >> access class jdk.internal.vm.ContinuationScope (in module java.base) >> because module java.base does not export jdk.internal.vm to unnamed module >> @0x1f75bcda >> >> I wondered if there is a way to create and use Continuation.yield in this >> latest build, and if not, how would I go about implementing a use case >> like >> this currently expressed in Scala. >> >> https://gist.github.com/raulraja/5bd7ffaf4f9fc44bf99fefc14a5e640e >> >> Thank you! >> >> Raul. >> > -- -- Ra?l Raja Mart?nez Co-founder @ 47 Degrees h: http://raulraja.com w: http://47deg.com t: http://twitter.com/raulraja From eric at kolotyluk.net Thu Nov 25 20:27:04 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Thu, 25 Nov 2021 12:27:04 -0800 Subject: Loom Evades Exception Handling Message-ID: Yes, that subject line is click-bait, but this is not intuitive to me... Am I just seeing an incomplete implementation of Project Loom, and this will be resolved in the future? public class Experiment06 { public static void main(String args[]) { Context.printHeader(Experiment06.class); try { getRemoteStrings().forEach(System.out::println); } catch (ExperimentException e) { e.printStackTrace(); } } static Stream getRemoteStrings() throws ExperimentException { try (var structuredExecutor = StructuredExecutor.open("Experiment06")) { // We want complete results, so we won't tolerate failure. var completionHandler = new StructuredExecutor.ShutdownOnFailure(); var futureResults = IntStream.range(0, 15).mapToObj(item -> { try { System.out.printf("item = %d, Thread ID = %s\n", item, Thread.currentThread()); return structuredExecutor.fork(() -> { try { System.out.printf("\ttask = %d, Thread ID = %s\n", item, Thread.currentThread()); return getRemoteString(item, new URI("https://server1/foobar.com/item")); } catch (Throwable t) { System.out.printf("TASK EXCEPTION %s\n\t%s\n\n", t.getMessage(), t.getCause()); t.printStackTrace(); throw t; } }, completionHandler); } catch (Throwable t) { System.out.printf("SPAWN EXCEPTION %s\n\t%s\n\n", t.getMessage(), t.getCause()); t.printStackTrace(); throw t; } }); structuredExecutor.joinUntil(Instant.now().plusSeconds(10)); completionHandler.throwIfFailed(); return futureResults.map(Future::resultNow); } catch (InterruptedException e) { e.printStackTrace(); throw new ExperimentException(e); } catch (ExecutionException e) { e.printStackTrace(); throw new ExperimentException(e); } catch (TimeoutException e) { e.printStackTrace(); throw new ExperimentException(e); } catch (IllegalStateException e) { e.printStackTrace(); throw new ExperimentException(e); } catch (Throwable t) { t.printStackTrace(); throw new ExperimentException(t); } } static String getRemoteString(int item, URI from) { return "Item %d from %s".formatted(item, from); } static class ExperimentException extends Exception { ExperimentException(Throwable cause) { super(cause); } } } where I get [image: image.png] (Experiment06.java:50) is return structuredExecutor.fork(() -> { (Experiment06.java:34) is getRemoteStrings().forEach(System.out::println); Is there some way I can actually find out more from the Exception handling, or other techniques? Cheers, Eric From forax at univ-mlv.fr Thu Nov 25 21:06:50 2021 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 25 Nov 2021 22:06:50 +0100 (CET) Subject: Loom Evades Exception Handling In-Reply-To: References: Message-ID: <55461503.2920318.1637874410110.JavaMail.zimbra@u-pem.fr> Hi Eric, getRemoteString() returns a Stream, and a Stream delays the call to the intermediary operations to the point where the terminal operation, here forEach(), is called. When forEach() is called, the executor is already closed, so forEach() calls map() that calls fork() that throws an IllegalStateException. I see no issue here, if you return a List instead of a Stream, you will have the behavior I believe you want. regards, R?mi ----- Original Message ----- > From: "Eric Kolotyluk" > To: "loom-dev" > Sent: Jeudi 25 Novembre 2021 21:27:04 > Subject: Loom Evades Exception Handling > Yes, that subject line is click-bait, but this is not intuitive to me... Am > I just seeing an incomplete implementation of Project Loom, and this will > be resolved in the future? > > public class Experiment06 { > > public static void main(String args[]) { > Context.printHeader(Experiment06.class); > > try { > getRemoteStrings().forEach(System.out::println); > } catch (ExperimentException e) { > e.printStackTrace(); > } > } > > static Stream getRemoteStrings() throws ExperimentException { > > try (var structuredExecutor = StructuredExecutor.open("Experiment06")) { > > // We want complete results, so we won't tolerate failure. > var completionHandler = new StructuredExecutor.ShutdownOnFailure(); > > var futureResults = IntStream.range(0, 15).mapToObj(item -> { > try { > System.out.printf("item = %d, Thread ID = %s\n", > item, Thread.currentThread()); > return structuredExecutor.fork(() -> { > try { > System.out.printf("\ttask = %d, Thread ID > = %s\n", item, Thread.currentThread()); > return getRemoteString(item, new > URI("https://server1/foobar.com/item")); > } > catch (Throwable t) { > System.out.printf("TASK EXCEPTION > %s\n\t%s\n\n", t.getMessage(), t.getCause()); > t.printStackTrace(); > throw t; > } > }, completionHandler); > } catch (Throwable t) { > System.out.printf("SPAWN EXCEPTION %s\n\t%s\n\n", > t.getMessage(), t.getCause()); > t.printStackTrace(); > throw t; > } > }); > structuredExecutor.joinUntil(Instant.now().plusSeconds(10)); > completionHandler.throwIfFailed(); > return futureResults.map(Future::resultNow); > } > catch (InterruptedException e) { > e.printStackTrace(); > throw new ExperimentException(e); > } catch (ExecutionException e) { > e.printStackTrace(); > throw new ExperimentException(e); > } catch (TimeoutException e) { > e.printStackTrace(); > throw new ExperimentException(e); > } catch (IllegalStateException e) { > e.printStackTrace(); > throw new ExperimentException(e); > } > catch (Throwable t) { > t.printStackTrace(); > throw new ExperimentException(t); > } > } > > static String getRemoteString(int item, URI from) { > return "Item %d from %s".formatted(item, from); > } > > static class ExperimentException extends Exception { > ExperimentException(Throwable cause) { > super(cause); > } > } > } > > where I get > > [image: image.png] > > > (Experiment06.java:50) is > > return structuredExecutor.fork(() -> { > > (Experiment06.java:34) is > > getRemoteStrings().forEach(System.out::println); > > Is there some way I can actually find out more from the Exception handling, > or other techniques? > > Cheers, Eric From eric at kolotyluk.net Thu Nov 25 22:16:11 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Thu, 25 Nov 2021 14:16:11 -0800 Subject: Loom Evades Exception Handling In-Reply-To: <55461503.2920318.1637874410110.JavaMail.zimbra@u-pem.fr> References: <55461503.2920318.1637874410110.JavaMail.zimbra@u-pem.fr> Message-ID: Thanks for the suggestion Remi, but that does not fix it, it does however result in different Exception Handling... [image: image.png] Actually, my concern is more about the stack traces, and messages, I cannot really pinpoint the root cause of the exception. It's like there is missing information about the root cause. Through another piece of experimental code, I have isolated it to something like structuredExecutor.join(); completionHandler.throwIfFailed(); var completedResults = futureResults.map(Future::resultNow).toList(); where the last statement produces java.lang.IllegalStateException: Task has not completed at java.base/java.util.concurrent.FutureTask.resultNow(FutureTask.java:220) at java.base/java.util.concurrent.StructuredExecutor$FutureImpl.resultNow(StructuredExecutor.java:726) at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197) at java.base/java.util.stream.IntPipeline$1$1.accept(IntPipeline.java:180) at java.base/java.util.stream.Streams$RangeIntSpliterator.forEachRemaining(Streams.java:104) at java.base/java.util.Spliterator$OfInt.forEachRemaining(Spliterator.java:711) at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509) at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499) at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:575) at java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260) at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:616) at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:622) at java.base/java.util.stream.ReferencePipeline.toList(ReferencePipeline.java:627) at net.kolotyluk.loom.Experiment00.main(Experiment00.java:160) Which begs the question, how can this throw an exception after the previous two statements? Cheers, Eric On Thu, Nov 25, 2021 at 1:06 PM Remi Forax wrote: > Hi Eric, > getRemoteString() returns a Stream, and a Stream delays the call to the > intermediary operations to the point where the terminal operation, here > forEach(), is called. > When forEach() is called, the executor is already closed, so forEach() > calls map() that calls fork() that throws an IllegalStateException. > > I see no issue here, if you return a List instead of a Stream, you will > have the behavior I believe you want. > > regards, > R?mi > > ----- Original Message ----- > > From: "Eric Kolotyluk" > > To: "loom-dev" > > Sent: Jeudi 25 Novembre 2021 21:27:04 > > Subject: Loom Evades Exception Handling > > > Yes, that subject line is click-bait, but this is not intuitive to me... > Am > > I just seeing an incomplete implementation of Project Loom, and this will > > be resolved in the future? > > > > public class Experiment06 { > > > > public static void main(String args[]) { > > Context.printHeader(Experiment06.class); > > > > try { > > getRemoteStrings().forEach(System.out::println); > > } catch (ExperimentException e) { > > e.printStackTrace(); > > } > > } > > > > static Stream getRemoteStrings() throws ExperimentException { > > > > try (var structuredExecutor = > StructuredExecutor.open("Experiment06")) { > > > > // We want complete results, so we won't tolerate failure. > > var completionHandler = new > StructuredExecutor.ShutdownOnFailure(); > > > > var futureResults = IntStream.range(0, 15).mapToObj(item -> { > > try { > > System.out.printf("item = %d, Thread ID = %s\n", > > item, Thread.currentThread()); > > return structuredExecutor.fork(() -> { > > try { > > System.out.printf("\ttask = %d, Thread ID > > = %s\n", item, Thread.currentThread()); > > return getRemoteString(item, new > > URI("https://server1/foobar.com/item")); > > } > > catch (Throwable t) { > > System.out.printf("TASK EXCEPTION > > %s\n\t%s\n\n", t.getMessage(), t.getCause()); > > t.printStackTrace(); > > throw t; > > } > > }, completionHandler); > > } catch (Throwable t) { > > System.out.printf("SPAWN EXCEPTION %s\n\t%s\n\n", > > t.getMessage(), t.getCause()); > > t.printStackTrace(); > > throw t; > > } > > }); > > structuredExecutor.joinUntil(Instant.now().plusSeconds(10)); > > completionHandler.throwIfFailed(); > > return futureResults.map(Future::resultNow); > > } > > catch (InterruptedException e) { > > e.printStackTrace(); > > throw new ExperimentException(e); > > } catch (ExecutionException e) { > > e.printStackTrace(); > > throw new ExperimentException(e); > > } catch (TimeoutException e) { > > e.printStackTrace(); > > throw new ExperimentException(e); > > } catch (IllegalStateException e) { > > e.printStackTrace(); > > throw new ExperimentException(e); > > } > > catch (Throwable t) { > > t.printStackTrace(); > > throw new ExperimentException(t); > > } > > } > > > > static String getRemoteString(int item, URI from) { > > return "Item %d from %s".formatted(item, from); > > } > > > > static class ExperimentException extends Exception { > > ExperimentException(Throwable cause) { > > super(cause); > > } > > } > > } > > > > where I get > > > > [image: image.png] > > > > > > (Experiment06.java:50) is > > > > return structuredExecutor.fork(() -> { > > > > (Experiment06.java:34) is > > > > getRemoteStrings().forEach(System.out::println); > > > > Is there some way I can actually find out more from the Exception > handling, > > or other techniques? > > > > Cheers, Eric > From forax at univ-mlv.fr Thu Nov 25 22:25:40 2021 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Thu, 25 Nov 2021 23:25:40 +0100 (CET) Subject: Loom Evades Exception Handling In-Reply-To: References: <55461503.2920318.1637874410110.JavaMail.zimbra@u-pem.fr> Message-ID: <904689040.2936183.1637879140851.JavaMail.zimbra@u-pem.fr> > From: "Eric Kolotyluk" > To: "Remi Forax" > Cc: "loom-dev" > Sent: Jeudi 25 Novembre 2021 23:16:11 > Subject: Re: Loom Evades Exception Handling > Thanks for the suggestion Remi, but that does not fix it, it does however result > in different Exception Handling... > Actually, my concern is more about the stack traces, and messages, I cannot > really pinpoint the root cause of the exception. It's like there is missing > information about the root cause. > Through another piece of experimental code, I have isolated it to something like > structuredExecutor.join() ; > completionHandler.throwIfFailed() ; > var completedResults = futureResults.map(Future::resultNow).toList() ; > where the last statement produces > java.lang.IllegalStateException: Task has not completed > at java.base/java.util.concurrent.FutureTask.resultNow(FutureTask.java:220) > at > java.base/java.util.concurrent.StructuredExecutor$FutureImpl.resultNow(StructuredExecutor.java:726) > at > java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197) > at java.base/java.util.stream.IntPipeline$1$1.accept(IntPipeline.java:180) > at > java.base/java.util.stream.Streams$RangeIntSpliterator.forEachRemaining(Streams.java:104) > at java.base/java.util.Spliterator$OfInt.forEachRemaining(Spliterator.java:711) > at > java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509) > at > java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499) > at > java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:575) > at > java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260) > at > java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:616) > at > java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:622) > at > java.base/java.util.stream.ReferencePipeline.toList(ReferencePipeline.java:627) > at net.kolotyluk.loom.Experiment00.main(Experiment00.java:160) > Which begs the question, how can this throw an exception after the previous two > statements? Again, a stream delay the calculation so you call fork() when toList is called after calling join() not before, You have to call toList() before calling throwIfFailed(). For Alan or Ron, fork() should throw an exception if called after join() ? > Cheers, Eric R?mi > On Thu, Nov 25, 2021 at 1:06 PM Remi Forax < [ mailto:forax at univ-mlv.fr | > forax at univ-mlv.fr ] > wrote: >> Hi Eric, >> getRemoteString() returns a Stream, and a Stream delays the call to the >> intermediary operations to the point where the terminal operation, here >> forEach(), is called. >> When forEach() is called, the executor is already closed, so forEach() calls >> map() that calls fork() that throws an IllegalStateException. >> I see no issue here, if you return a List instead of a Stream, you will have the >> behavior I believe you want. >> regards, >> R?mi >> ----- Original Message ----- >> > From: "Eric Kolotyluk" < [ mailto:eric at kolotyluk.net | eric at kolotyluk.net ] > >>> To: "loom-dev" < [ mailto:loom-dev at openjdk.java.net | loom-dev at openjdk.java.net >> > ] > >> > Sent: Jeudi 25 Novembre 2021 21:27:04 >> > Subject: Loom Evades Exception Handling >> > Yes, that subject line is click-bait, but this is not intuitive to me... Am >> > I just seeing an incomplete implementation of Project Loom, and this will >> > be resolved in the future? >> > public class Experiment06 { >> > public static void main(String args[]) { >> > Context.printHeader(Experiment06.class); >> > try { >> > getRemoteStrings().forEach(System.out::println); >> > } catch (ExperimentException e) { >> > e.printStackTrace(); >> > } >> > } >> > static Stream getRemoteStrings() throws ExperimentException { >> > try (var structuredExecutor = StructuredExecutor.open("Experiment06")) { >> > // We want complete results, so we won't tolerate failure. >> > var completionHandler = new StructuredExecutor.ShutdownOnFailure(); >> > var futureResults = IntStream.range(0, 15).mapToObj(item -> { >> > try { >> > System.out.printf("item = %d, Thread ID = %s\n", >> > item, Thread.currentThread()); >> > return structuredExecutor.fork(() -> { >> > try { >> > System.out.printf("\ttask = %d, Thread ID >> > = %s\n", item, Thread.currentThread()); >> > return getRemoteString(item, new >> > URI(" [ https://server1/foobar.com/item | https://server1/foobar.com/item ] ")); >> > } >> > catch (Throwable t) { >> > System.out.printf("TASK EXCEPTION >> > %s\n\t%s\n\n", t.getMessage(), t.getCause()); >> > t.printStackTrace(); >> > throw t; >> > } >> > }, completionHandler); >> > } catch (Throwable t) { >> > System.out.printf("SPAWN EXCEPTION %s\n\t%s\n\n", >> > t.getMessage(), t.getCause()); >> > t.printStackTrace(); >> > throw t; >> > } >> > }); >> > structuredExecutor.joinUntil(Instant.now().plusSeconds(10)); >> > completionHandler.throwIfFailed(); >> > return futureResults.map(Future::resultNow); >> > } >> > catch (InterruptedException e) { >> > e.printStackTrace(); >> > throw new ExperimentException(e); >> > } catch (ExecutionException e) { >> > e.printStackTrace(); >> > throw new ExperimentException(e); >> > } catch (TimeoutException e) { >> > e.printStackTrace(); >> > throw new ExperimentException(e); >> > } catch (IllegalStateException e) { >> > e.printStackTrace(); >> > throw new ExperimentException(e); >> > } >> > catch (Throwable t) { >> > t.printStackTrace(); >> > throw new ExperimentException(t); >> > } >> > } >> > static String getRemoteString(int item, URI from) { >> > return "Item %d from %s".formatted(item, from); >> > } >> > static class ExperimentException extends Exception { >> > ExperimentException(Throwable cause) { >> > super(cause); >> > } >> > } >> > } >> > where I get >> > [image: image.png] >> > (Experiment06.java:50) is >> > return structuredExecutor.fork(() -> { >> > (Experiment06.java:34) is >> > getRemoteStrings().forEach(System.out::println); >> > Is there some way I can actually find out more from the Exception handling, >> > or other techniques? >> > Cheers, Eric From augustnagro at gmail.com Thu Nov 25 22:25:57 2021 From: augustnagro at gmail.com (August Nagro) Date: Thu, 25 Nov 2021 14:25:57 -0800 Subject: Access to Continuation.yield and ContinuationScope In-Reply-To: References: Message-ID: Hi Raul, I've found that you can replicate the same behavior of jl.Continuation using a Reentrant lock on a virtual thread. For example, see Coroutine.java in https://github.com/AugustNagro/java-async-await On Thu, Nov 25, 2021, 11:22 AM Raul Raja Martinez wrote: > Thanks!, that worked for my local tests. > > Are there any plans to bring back Continuation and ContinuationScope to > public status to `java.lang` or similar or is the plan that this is going > to remain internal? > I'm aware of other libs in the space that also depend on their public > status to perform operations unrelated to concurrency but related to the > power of shifting control by yielding a scope in the continuation. > > thanks! > > On Thu, Nov 25, 2021 at 2:37 AM Glavo wrote: > > > You can add the --add-opens option at runtime, like this: > > > > java --add-opens java.base/jdk.internal.vm=ALL-UNNAMED > > > > > > Raul Raja Martinez ?2021?11?25??? ??7:56??? > > > >> Hello everyone, > >> > >> First, thank you for LOOM and the extraordinary work done here. I'm > >> excited > >> to see this coming to a final release. > >> > >> I have been using LOOM builds up until recently, building abstractions > >> directly on top of what used to be `java.lang.Continuation` and the > >> `Continuation.yield` capabilities. I have noticed in the latest build > >> these > >> became internal in the jdk.internal.vm package. > >> > >> When I link against those I get errors like: > >> > >> java.lang.IllegalAccessError: superclass access check failed: class > >> fx.Continuation$package$$anon$1 (in unnamed module @0x1f75bcda) cannot > >> access class jdk.internal.vm.ContinuationScope (in module java.base) > >> because module java.base does not export jdk.internal.vm to unnamed > module > >> @0x1f75bcda > >> > >> I wondered if there is a way to create and use Continuation.yield in > this > >> latest build, and if not, how would I go about implementing a use case > >> like > >> this currently expressed in Scala. > >> > >> https://gist.github.com/raulraja/5bd7ffaf4f9fc44bf99fefc14a5e640e > >> > >> Thank you! > >> > >> Raul. > >> > > > > -- > -- > Ra?l Raja Mart?nez > Co-founder @ 47 Degrees > h: http://raulraja.com > w: http://47deg.com > t: http://twitter.com/raulraja > From eric at kolotyluk.net Thu Nov 25 22:46:32 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Thu, 25 Nov 2021 14:46:32 -0800 Subject: Loom Evades Exception Handling In-Reply-To: <904689040.2936183.1637879140851.JavaMail.zimbra@u-pem.fr> References: <55461503.2920318.1637874410110.JavaMail.zimbra@u-pem.fr> <904689040.2936183.1637879140851.JavaMail.zimbra@u-pem.fr> Message-ID: Ahhhhhh..... now I understand the fix... try (var structuredExecutor = StructuredExecutor.open("Experiment00", virtualThreadFactory)) { var completionHandler = new StructuredExecutor.ShutdownOnFailure(); var futureStream = IntStream.range(0, 15).mapToObj(item -> { System.out.printf("item = %d, Thread ID = %s\n", item, Thread.currentThread()); return structuredExecutor.fork(() -> { System.out.printf("\ttask = %d, Thread ID = %s\n", item, Thread.currentThread()); return item; }, completionHandler); }); var futureList = futureStream.toList(); // wait for the Stream to finish structuredExecutor.join(); completionHandler.throwIfFailed(); var completedResults = futureList.stream().map(Future::resultNow).toList(); completedResults.forEach(System.out::println); System.out.println("Finished Processing"); } catch (InterruptedException e) { e.printStackTrace(); } catch (ExecutionException e) { e.printStackTrace(); } catch (IllegalStateException e) { e.printStackTrace(); } finally { System.out.println("Finished Finally"); } Thanks so much, R?mi, that was a really subtle point for me... There was more concurrency going on than I expected... We learn more from our failures than our successes... Cheers, Eric On Thu, Nov 25, 2021 at 2:25 PM wrote: > > > ------------------------------ > > *From: *"Eric Kolotyluk" > *To: *"Remi Forax" > *Cc: *"loom-dev" > *Sent: *Jeudi 25 Novembre 2021 23:16:11 > *Subject: *Re: Loom Evades Exception Handling > > Thanks for the suggestion Remi, but that does not fix it, it does however > result in different Exception Handling... > > [image: image.png] > > Actually, my concern is more about the stack traces, and messages, I > cannot really pinpoint the root cause of the exception. It's like there is > missing information about the root cause. > > Through another piece of experimental code, I have isolated it to > something like > > structuredExecutor.join(); > completionHandler.throwIfFailed(); > var completedResults = futureResults.map(Future::resultNow).toList(); > > where the last statement produces > > java.lang.IllegalStateException: Task has not completed > at java.base/java.util.concurrent.FutureTask.resultNow(FutureTask.java:220) > at > java.base/java.util.concurrent.StructuredExecutor$FutureImpl.resultNow(StructuredExecutor.java:726) > at > java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197) > at java.base/java.util.stream.IntPipeline$1$1.accept(IntPipeline.java:180) > at > java.base/java.util.stream.Streams$RangeIntSpliterator.forEachRemaining(Streams.java:104) > at > java.base/java.util.Spliterator$OfInt.forEachRemaining(Spliterator.java:711) > at > java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509) > at > java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499) > at > java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:575) > at > java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260) > at > java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:616) > at > java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:622) > at > java.base/java.util.stream.ReferencePipeline.toList(ReferencePipeline.java:627) > at net.kolotyluk.loom.Experiment00.main(Experiment00.java:160) > > Which begs the question, how can this throw an exception after the > previous two statements? > > > Again, a stream delay the calculation so you call fork() when toList is > called after calling join() not before, > You have to call toList() before calling throwIfFailed(). > > For Alan or Ron, fork() should throw an exception if called after join() ? > > > Cheers, Eric > > > R?mi > > > > On Thu, Nov 25, 2021 at 1:06 PM Remi Forax wrote: > >> Hi Eric, >> getRemoteString() returns a Stream, and a Stream delays the call to the >> intermediary operations to the point where the terminal operation, here >> forEach(), is called. >> When forEach() is called, the executor is already closed, so forEach() >> calls map() that calls fork() that throws an IllegalStateException. >> >> I see no issue here, if you return a List instead of a Stream, you will >> have the behavior I believe you want. >> >> regards, >> R?mi >> >> ----- Original Message ----- >> > From: "Eric Kolotyluk" >> > To: "loom-dev" >> > Sent: Jeudi 25 Novembre 2021 21:27:04 >> > Subject: Loom Evades Exception Handling >> >> > Yes, that subject line is click-bait, but this is not intuitive to >> me... Am >> > I just seeing an incomplete implementation of Project Loom, and this >> will >> > be resolved in the future? >> > >> > public class Experiment06 { >> > >> > public static void main(String args[]) { >> > Context.printHeader(Experiment06.class); >> > >> > try { >> > getRemoteStrings().forEach(System.out::println); >> > } catch (ExperimentException e) { >> > e.printStackTrace(); >> > } >> > } >> > >> > static Stream getRemoteStrings() throws ExperimentException { >> > >> > try (var structuredExecutor = >> StructuredExecutor.open("Experiment06")) { >> > >> > // We want complete results, so we won't tolerate failure. >> > var completionHandler = new >> StructuredExecutor.ShutdownOnFailure(); >> > >> > var futureResults = IntStream.range(0, 15).mapToObj(item -> { >> > try { >> > System.out.printf("item = %d, Thread ID = %s\n", >> > item, Thread.currentThread()); >> > return structuredExecutor.fork(() -> { >> > try { >> > System.out.printf("\ttask = %d, Thread ID >> > = %s\n", item, Thread.currentThread()); >> > return getRemoteString(item, new >> > URI("https://server1/foobar.com/item")); >> > } >> > catch (Throwable t) { >> > System.out.printf("TASK EXCEPTION >> > %s\n\t%s\n\n", t.getMessage(), t.getCause()); >> > t.printStackTrace(); >> > throw t; >> > } >> > }, completionHandler); >> > } catch (Throwable t) { >> > System.out.printf("SPAWN EXCEPTION %s\n\t%s\n\n", >> > t.getMessage(), t.getCause()); >> > t.printStackTrace(); >> > throw t; >> > } >> > }); >> > structuredExecutor.joinUntil(Instant.now().plusSeconds(10)); >> > completionHandler.throwIfFailed(); >> > return futureResults.map(Future::resultNow); >> > } >> > catch (InterruptedException e) { >> > e.printStackTrace(); >> > throw new ExperimentException(e); >> > } catch (ExecutionException e) { >> > e.printStackTrace(); >> > throw new ExperimentException(e); >> > } catch (TimeoutException e) { >> > e.printStackTrace(); >> > throw new ExperimentException(e); >> > } catch (IllegalStateException e) { >> > e.printStackTrace(); >> > throw new ExperimentException(e); >> > } >> > catch (Throwable t) { >> > t.printStackTrace(); >> > throw new ExperimentException(t); >> > } >> > } >> > >> > static String getRemoteString(int item, URI from) { >> > return "Item %d from %s".formatted(item, from); >> > } >> > >> > static class ExperimentException extends Exception { >> > ExperimentException(Throwable cause) { >> > super(cause); >> > } >> > } >> > } >> > >> > where I get >> > >> > [image: image.png] >> > >> > >> > (Experiment06.java:50) is >> > >> > return structuredExecutor.fork(() -> { >> > >> > (Experiment06.java:34) is >> > >> > getRemoteStrings().forEach(System.out::println); >> > >> > Is there some way I can actually find out more from the Exception >> handling, >> > or other techniques? >> > >> > Cheers, Eric >> > > From eric at kolotyluk.net Thu Nov 25 22:48:27 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Thu, 25 Nov 2021 14:48:27 -0800 Subject: Loom Evades Exception Handling In-Reply-To: References: <55461503.2920318.1637874410110.JavaMail.zimbra@u-pem.fr> <904689040.2936183.1637879140851.JavaMail.zimbra@u-pem.fr> Message-ID: Correction, the Stream had not terminated and needed to be terminated before calling join()... Cheers, Eric On Thu, Nov 25, 2021 at 2:46 PM Eric Kolotyluk wrote: > Ahhhhhh..... now I understand the fix... > > try (var structuredExecutor = StructuredExecutor.open("Experiment00", virtualThreadFactory)) { > var completionHandler = new StructuredExecutor.ShutdownOnFailure(); > var futureStream = IntStream.range(0, 15).mapToObj(item -> { > System.out.printf("item = %d, Thread ID = %s\n", item, Thread.currentThread()); > return structuredExecutor.fork(() -> { > System.out.printf("\ttask = %d, Thread ID = %s\n", item, Thread.currentThread()); > return item; > }, completionHandler); > }); > var futureList = futureStream.toList(); // wait for the Stream to finish > structuredExecutor.join(); > completionHandler.throwIfFailed(); > var completedResults = futureList.stream().map(Future::resultNow).toList(); > completedResults.forEach(System.out::println); > System.out.println("Finished Processing"); > } > catch (InterruptedException e) { > e.printStackTrace(); > } catch (ExecutionException e) { > e.printStackTrace(); > } catch (IllegalStateException e) { > e.printStackTrace(); > } > finally { > System.out.println("Finished Finally"); > } > > > Thanks so much, R?mi, that was a really subtle point for me... There was > more concurrency going on than I expected... > > We learn more from our failures than our successes... > > Cheers, Eric > > > On Thu, Nov 25, 2021 at 2:25 PM wrote: > >> >> >> ------------------------------ >> >> *From: *"Eric Kolotyluk" >> *To: *"Remi Forax" >> *Cc: *"loom-dev" >> *Sent: *Jeudi 25 Novembre 2021 23:16:11 >> *Subject: *Re: Loom Evades Exception Handling >> >> Thanks for the suggestion Remi, but that does not fix it, it does however >> result in different Exception Handling... >> >> [image: image.png] >> >> Actually, my concern is more about the stack traces, and messages, I >> cannot really pinpoint the root cause of the exception. It's like there is >> missing information about the root cause. >> >> Through another piece of experimental code, I have isolated it to >> something like >> >> structuredExecutor.join(); >> completionHandler.throwIfFailed(); >> var completedResults = futureResults.map(Future::resultNow).toList(); >> >> where the last statement produces >> >> java.lang.IllegalStateException: Task has not completed >> at >> java.base/java.util.concurrent.FutureTask.resultNow(FutureTask.java:220) >> at >> java.base/java.util.concurrent.StructuredExecutor$FutureImpl.resultNow(StructuredExecutor.java:726) >> at >> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197) >> at java.base/java.util.stream.IntPipeline$1$1.accept(IntPipeline.java:180) >> at >> java.base/java.util.stream.Streams$RangeIntSpliterator.forEachRemaining(Streams.java:104) >> at >> java.base/java.util.Spliterator$OfInt.forEachRemaining(Spliterator.java:711) >> at >> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509) >> at >> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499) >> at >> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:575) >> at >> java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260) >> at >> java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:616) >> at >> java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:622) >> at >> java.base/java.util.stream.ReferencePipeline.toList(ReferencePipeline.java:627) >> at net.kolotyluk.loom.Experiment00.main(Experiment00.java:160) >> >> Which begs the question, how can this throw an exception after the >> previous two statements? >> >> >> Again, a stream delay the calculation so you call fork() when toList is >> called after calling join() not before, >> You have to call toList() before calling throwIfFailed(). >> >> For Alan or Ron, fork() should throw an exception if called after join() ? >> >> >> Cheers, Eric >> >> >> R?mi >> >> >> >> On Thu, Nov 25, 2021 at 1:06 PM Remi Forax wrote: >> >>> Hi Eric, >>> getRemoteString() returns a Stream, and a Stream delays the call to the >>> intermediary operations to the point where the terminal operation, here >>> forEach(), is called. >>> When forEach() is called, the executor is already closed, so forEach() >>> calls map() that calls fork() that throws an IllegalStateException. >>> >>> I see no issue here, if you return a List instead of a Stream, you will >>> have the behavior I believe you want. >>> >>> regards, >>> R?mi >>> >>> ----- Original Message ----- >>> > From: "Eric Kolotyluk" >>> > To: "loom-dev" >>> > Sent: Jeudi 25 Novembre 2021 21:27:04 >>> > Subject: Loom Evades Exception Handling >>> >>> > Yes, that subject line is click-bait, but this is not intuitive to >>> me... Am >>> > I just seeing an incomplete implementation of Project Loom, and this >>> will >>> > be resolved in the future? >>> > >>> > public class Experiment06 { >>> > >>> > public static void main(String args[]) { >>> > Context.printHeader(Experiment06.class); >>> > >>> > try { >>> > getRemoteStrings().forEach(System.out::println); >>> > } catch (ExperimentException e) { >>> > e.printStackTrace(); >>> > } >>> > } >>> > >>> > static Stream getRemoteStrings() throws ExperimentException >>> { >>> > >>> > try (var structuredExecutor = >>> StructuredExecutor.open("Experiment06")) { >>> > >>> > // We want complete results, so we won't tolerate failure. >>> > var completionHandler = new >>> StructuredExecutor.ShutdownOnFailure(); >>> > >>> > var futureResults = IntStream.range(0, 15).mapToObj(item -> >>> { >>> > try { >>> > System.out.printf("item = %d, Thread ID = %s\n", >>> > item, Thread.currentThread()); >>> > return structuredExecutor.fork(() -> { >>> > try { >>> > System.out.printf("\ttask = %d, Thread ID >>> > = %s\n", item, Thread.currentThread()); >>> > return getRemoteString(item, new >>> > URI("https://server1/foobar.com/item")); >>> > } >>> > catch (Throwable t) { >>> > System.out.printf("TASK EXCEPTION >>> > %s\n\t%s\n\n", t.getMessage(), t.getCause()); >>> > t.printStackTrace(); >>> > throw t; >>> > } >>> > }, completionHandler); >>> > } catch (Throwable t) { >>> > System.out.printf("SPAWN EXCEPTION %s\n\t%s\n\n", >>> > t.getMessage(), t.getCause()); >>> > t.printStackTrace(); >>> > throw t; >>> > } >>> > }); >>> > structuredExecutor.joinUntil(Instant.now().plusSeconds(10)); >>> > completionHandler.throwIfFailed(); >>> > return futureResults.map(Future::resultNow); >>> > } >>> > catch (InterruptedException e) { >>> > e.printStackTrace(); >>> > throw new ExperimentException(e); >>> > } catch (ExecutionException e) { >>> > e.printStackTrace(); >>> > throw new ExperimentException(e); >>> > } catch (TimeoutException e) { >>> > e.printStackTrace(); >>> > throw new ExperimentException(e); >>> > } catch (IllegalStateException e) { >>> > e.printStackTrace(); >>> > throw new ExperimentException(e); >>> > } >>> > catch (Throwable t) { >>> > t.printStackTrace(); >>> > throw new ExperimentException(t); >>> > } >>> > } >>> > >>> > static String getRemoteString(int item, URI from) { >>> > return "Item %d from %s".formatted(item, from); >>> > } >>> > >>> > static class ExperimentException extends Exception { >>> > ExperimentException(Throwable cause) { >>> > super(cause); >>> > } >>> > } >>> > } >>> > >>> > where I get >>> > >>> > [image: image.png] >>> > >>> > >>> > (Experiment06.java:50) is >>> > >>> > return structuredExecutor.fork(() -> { >>> > >>> > (Experiment06.java:34) is >>> > >>> > getRemoteStrings().forEach(System.out::println); >>> > >>> > Is there some way I can actually find out more from the Exception >>> handling, >>> > or other techniques? >>> > >>> > Cheers, Eric >>> >> >> From eric at kolotyluk.net Fri Nov 26 00:40:42 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Thu, 25 Nov 2021 16:40:42 -0800 Subject: Loom Evades Exception Handling In-Reply-To: References: <55461503.2920318.1637874410110.JavaMail.zimbra@u-pem.fr> <904689040.2936183.1637879140851.JavaMail.zimbra@u-pem.fr> Message-ID: I have been reflecting more on my previous dysfunctional experiment and what led to my dysfunctional thinking... 1. Having spent too long in idiomatic Scala, with Scala Collections, I am still not familiar with idiomatic Java, where you need to convert Collections to Streams and back to Collections. An Akka/Scala Stream is a whole different beast... suffice it to say different idioms have led me to being an idiot. - Cache invalidation is an easier problem to solve than naming things... ?? 2. I thought I was clever using Streams to spawn Tasks. I forgot that clever programming leads to clever problems. - Possibly for(...; ...; ...) or while() is the better model, but neither return a collection as a result. 3. I suspect that R?mi is right, that perhaps join() should throw the exception sooner, with better context than waiting until calling Future::resultNow. - However, this may be impossible because it's not until later when the Stream is terminated that Tasks are spawned, so technically Loom is doing the right thing, doing the best it can. - Maybe a better Exception message such as "Task has not started yet, and join() has already been called, are you doing things in the wrong order?" Not sure how hard it would be to detect that situation? 4. It is frustrating to me that I cannot do with collections, as in Kotlin/Scala, that I must do with Streams. - In Kotlin and Scala, I can just do collection.map{ item -> spawn(item) }, but in Java, I have to convert it to a Stream and remember to terminate the Stream. - At least I know how to use Project Loom from Kotlin, but that has other issues too because Kotlin does not have try-with-resources, so you need to hack it - Scala does have try-with-resources, so maybe I should try Loom in Scala... ?? 5. I know it's not nice to raise problems without solutions, but I really don't have a solution for this little trap I fell into... - Maybe this is a good topic for the next Java Puzzlers book ?? Again, just thinking out loud again... Cheers, Eric On Thu, Nov 25, 2021 at 2:48 PM Eric Kolotyluk wrote: > Correction, the Stream had not terminated and needed to be terminated > before calling join()... > > Cheers, Eric > > On Thu, Nov 25, 2021 at 2:46 PM Eric Kolotyluk wrote: > >> Ahhhhhh..... now I understand the fix... >> >> try (var structuredExecutor = StructuredExecutor.open("Experiment00", virtualThreadFactory)) { >> var completionHandler = new StructuredExecutor.ShutdownOnFailure(); >> var futureStream = IntStream.range(0, 15).mapToObj(item -> { >> System.out.printf("item = %d, Thread ID = %s\n", item, Thread.currentThread()); >> return structuredExecutor.fork(() -> { >> System.out.printf("\ttask = %d, Thread ID = %s\n", item, Thread.currentThread()); >> return item; >> }, completionHandler); >> }); >> var futureList = futureStream.toList(); // wait for the Stream to finish >> structuredExecutor.join(); >> completionHandler.throwIfFailed(); >> var completedResults = futureList.stream().map(Future::resultNow).toList(); >> completedResults.forEach(System.out::println); >> System.out.println("Finished Processing"); >> } >> catch (InterruptedException e) { >> e.printStackTrace(); >> } catch (ExecutionException e) { >> e.printStackTrace(); >> } catch (IllegalStateException e) { >> e.printStackTrace(); >> } >> finally { >> System.out.println("Finished Finally"); >> } >> >> >> Thanks so much, R?mi, that was a really subtle point for me... There was >> more concurrency going on than I expected... >> >> We learn more from our failures than our successes... >> >> Cheers, Eric >> >> >> On Thu, Nov 25, 2021 at 2:25 PM wrote: >> >>> >>> >>> ------------------------------ >>> >>> *From: *"Eric Kolotyluk" >>> *To: *"Remi Forax" >>> *Cc: *"loom-dev" >>> *Sent: *Jeudi 25 Novembre 2021 23:16:11 >>> *Subject: *Re: Loom Evades Exception Handling >>> >>> Thanks for the suggestion Remi, but that does not fix it, it does >>> however result in different Exception Handling... >>> >>> [image: image.png] >>> >>> Actually, my concern is more about the stack traces, and messages, I >>> cannot really pinpoint the root cause of the exception. It's like there is >>> missing information about the root cause. >>> >>> Through another piece of experimental code, I have isolated it to >>> something like >>> >>> structuredExecutor.join(); >>> completionHandler.throwIfFailed(); >>> var completedResults = futureResults.map(Future::resultNow).toList(); >>> >>> where the last statement produces >>> >>> java.lang.IllegalStateException: Task has not completed >>> at >>> java.base/java.util.concurrent.FutureTask.resultNow(FutureTask.java:220) >>> at >>> java.base/java.util.concurrent.StructuredExecutor$FutureImpl.resultNow(StructuredExecutor.java:726) >>> at >>> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197) >>> at >>> java.base/java.util.stream.IntPipeline$1$1.accept(IntPipeline.java:180) >>> at >>> java.base/java.util.stream.Streams$RangeIntSpliterator.forEachRemaining(Streams.java:104) >>> at >>> java.base/java.util.Spliterator$OfInt.forEachRemaining(Spliterator.java:711) >>> at >>> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509) >>> at >>> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499) >>> at >>> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:575) >>> at >>> java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260) >>> at >>> java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:616) >>> at >>> java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:622) >>> at >>> java.base/java.util.stream.ReferencePipeline.toList(ReferencePipeline.java:627) >>> at net.kolotyluk.loom.Experiment00.main(Experiment00.java:160) >>> >>> Which begs the question, how can this throw an exception after the >>> previous two statements? >>> >>> >>> Again, a stream delay the calculation so you call fork() when toList is >>> called after calling join() not before, >>> You have to call toList() before calling throwIfFailed(). >>> >>> For Alan or Ron, fork() should throw an exception if called after join() >>> ? >>> >>> >>> Cheers, Eric >>> >>> >>> R?mi >>> >>> >>> >>> On Thu, Nov 25, 2021 at 1:06 PM Remi Forax wrote: >>> >>>> Hi Eric, >>>> getRemoteString() returns a Stream, and a Stream delays the call to the >>>> intermediary operations to the point where the terminal operation, here >>>> forEach(), is called. >>>> When forEach() is called, the executor is already closed, so forEach() >>>> calls map() that calls fork() that throws an IllegalStateException. >>>> >>>> I see no issue here, if you return a List instead of a Stream, you will >>>> have the behavior I believe you want. >>>> >>>> regards, >>>> R?mi >>>> >>>> ----- Original Message ----- >>>> > From: "Eric Kolotyluk" >>>> > To: "loom-dev" >>>> > Sent: Jeudi 25 Novembre 2021 21:27:04 >>>> > Subject: Loom Evades Exception Handling >>>> >>>> > Yes, that subject line is click-bait, but this is not intuitive to >>>> me... Am >>>> > I just seeing an incomplete implementation of Project Loom, and this >>>> will >>>> > be resolved in the future? >>>> > >>>> > public class Experiment06 { >>>> > >>>> > public static void main(String args[]) { >>>> > Context.printHeader(Experiment06.class); >>>> > >>>> > try { >>>> > getRemoteStrings().forEach(System.out::println); >>>> > } catch (ExperimentException e) { >>>> > e.printStackTrace(); >>>> > } >>>> > } >>>> > >>>> > static Stream getRemoteStrings() throws >>>> ExperimentException { >>>> > >>>> > try (var structuredExecutor = >>>> StructuredExecutor.open("Experiment06")) { >>>> > >>>> > // We want complete results, so we won't tolerate failure. >>>> > var completionHandler = new >>>> StructuredExecutor.ShutdownOnFailure(); >>>> > >>>> > var futureResults = IntStream.range(0, 15).mapToObj(item >>>> -> { >>>> > try { >>>> > System.out.printf("item = %d, Thread ID = %s\n", >>>> > item, Thread.currentThread()); >>>> > return structuredExecutor.fork(() -> { >>>> > try { >>>> > System.out.printf("\ttask = %d, Thread ID >>>> > = %s\n", item, Thread.currentThread()); >>>> > return getRemoteString(item, new >>>> > URI("https://server1/foobar.com/item")); >>>> > } >>>> > catch (Throwable t) { >>>> > System.out.printf("TASK EXCEPTION >>>> > %s\n\t%s\n\n", t.getMessage(), t.getCause()); >>>> > t.printStackTrace(); >>>> > throw t; >>>> > } >>>> > }, completionHandler); >>>> > } catch (Throwable t) { >>>> > System.out.printf("SPAWN EXCEPTION %s\n\t%s\n\n", >>>> > t.getMessage(), t.getCause()); >>>> > t.printStackTrace(); >>>> > throw t; >>>> > } >>>> > }); >>>> > >>>> structuredExecutor.joinUntil(Instant.now().plusSeconds(10)); >>>> > completionHandler.throwIfFailed(); >>>> > return futureResults.map(Future::resultNow); >>>> > } >>>> > catch (InterruptedException e) { >>>> > e.printStackTrace(); >>>> > throw new ExperimentException(e); >>>> > } catch (ExecutionException e) { >>>> > e.printStackTrace(); >>>> > throw new ExperimentException(e); >>>> > } catch (TimeoutException e) { >>>> > e.printStackTrace(); >>>> > throw new ExperimentException(e); >>>> > } catch (IllegalStateException e) { >>>> > e.printStackTrace(); >>>> > throw new ExperimentException(e); >>>> > } >>>> > catch (Throwable t) { >>>> > t.printStackTrace(); >>>> > throw new ExperimentException(t); >>>> > } >>>> > } >>>> > >>>> > static String getRemoteString(int item, URI from) { >>>> > return "Item %d from %s".formatted(item, from); >>>> > } >>>> > >>>> > static class ExperimentException extends Exception { >>>> > ExperimentException(Throwable cause) { >>>> > super(cause); >>>> > } >>>> > } >>>> > } >>>> > >>>> > where I get >>>> > >>>> > [image: image.png] >>>> > >>>> > >>>> > (Experiment06.java:50) is >>>> > >>>> > return structuredExecutor.fork(() -> { >>>> > >>>> > (Experiment06.java:34) is >>>> > >>>> > getRemoteStrings().forEach(System.out::println); >>>> > >>>> > Is there some way I can actually find out more from the Exception >>>> handling, >>>> > or other techniques? >>>> > >>>> > Cheers, Eric >>>> >>> >>> From paul.bjorkstrand at gmail.com Fri Nov 26 02:35:47 2021 From: paul.bjorkstrand at gmail.com (Paul Bjorkstrand) Date: Thu, 25 Nov 2021 20:35:47 -0600 Subject: Loom Evades Exception Handling In-Reply-To: References: <55461503.2920318.1637874410110.JavaMail.zimbra@u-pem.fr> <904689040.2936183.1637879140851.JavaMail.zimbra@u-pem.fr> Message-ID: I could see StructuredExecutor.fork() throwing an IllegalStateException when called after .join(), but that might unnecessarily preclude running some tasks in the executor, joining, then reusing the same executor for another set of tasks. If StructuredExecutor is intended to be cheap to create, maybe it is the right approach to disallow .fork() after .join(). I may be a bit naive, but I can't think of a way to detect the join-before-fork situation without the above or some pretty heroic (and possibly error prone) detection logic in StructuredExecutor. -Paul On Thu, Nov 25, 2021 at 6:41 PM Eric Kolotyluk wrote: > I have been reflecting more on my previous dysfunctional experiment and > what led to my dysfunctional thinking... > > 1. Having spent too long in idiomatic Scala, with Scala Collections, I > am still not familiar with idiomatic Java, where you need to convert > Collections to Streams and back to Collections. An Akka/Scala Stream is > a > whole different beast... suffice it to say different idioms have led me > to > being an idiot. > - Cache invalidation is an easier problem to solve than naming > things... ?? > 2. I thought I was clever using Streams to spawn Tasks. I forgot that > clever programming leads to clever problems. > - Possibly for(...; ...; ...) or while() is the better model, but > neither return a collection as a result. > 3. I suspect that R?mi is right, that perhaps join() should throw the > exception sooner, with better context than waiting until calling > Future::resultNow. > - However, this may be impossible because it's not until later when > the Stream is terminated that Tasks are spawned, so technically Loom > is > doing the right thing, doing the best it can. > - Maybe a better Exception message such as "Task has not started yet, > and join() has already been called, are you doing things in the wrong > order?" Not sure how hard it would be to detect that situation? > 4. It is frustrating to me that I cannot do with collections, as in > Kotlin/Scala, that I must do with Streams. > - In Kotlin and Scala, I can just do collection.map{ item -> > spawn(item) }, but in Java, I have to convert it to a Stream and > remember to terminate the Stream. > - At least I know how to use Project Loom from Kotlin, but that has > other issues too because Kotlin does not have try-with-resources, so > you > need to hack it > - Scala does have try-with-resources, so maybe I should try Loom in > Scala... ?? > 5. I know it's not nice to raise problems without solutions, but I > really don't have a solution for this little trap I fell into... > - Maybe this is a good topic for the next Java Puzzlers book ?? > > Again, just thinking out loud again... > > Cheers, Eric > > On Thu, Nov 25, 2021 at 2:48 PM Eric Kolotyluk wrote: > > > Correction, the Stream had not terminated and needed to be terminated > > before calling join()... > > > > Cheers, Eric > > > > On Thu, Nov 25, 2021 at 2:46 PM Eric Kolotyluk > wrote: > > > >> Ahhhhhh..... now I understand the fix... > >> > >> try (var structuredExecutor = > StructuredExecutor.open("Experiment00", virtualThreadFactory)) { > >> var completionHandler = new > StructuredExecutor.ShutdownOnFailure(); > >> var futureStream = IntStream.range(0, 15).mapToObj(item -> { > >> System.out.printf("item = %d, Thread ID = %s\n", item, > Thread.currentThread()); > >> return structuredExecutor.fork(() -> { > >> System.out.printf("\ttask = %d, Thread ID = %s\n", > item, Thread.currentThread()); > >> return item; > >> }, completionHandler); > >> }); > >> var futureList = futureStream.toList(); // wait for the > Stream to finish > >> structuredExecutor.join(); > >> completionHandler.throwIfFailed(); > >> var completedResults = > futureList.stream().map(Future::resultNow).toList(); > >> completedResults.forEach(System.out::println); > >> System.out.println("Finished Processing"); > >> } > >> catch (InterruptedException e) { > >> e.printStackTrace(); > >> } catch (ExecutionException e) { > >> e.printStackTrace(); > >> } catch (IllegalStateException e) { > >> e.printStackTrace(); > >> } > >> finally { > >> System.out.println("Finished Finally"); > >> } > >> > >> > >> Thanks so much, R?mi, that was a really subtle point for me... There was > >> more concurrency going on than I expected... > >> > >> We learn more from our failures than our successes... > >> > >> Cheers, Eric > >> > >> > >> On Thu, Nov 25, 2021 at 2:25 PM wrote: > >> > >>> > >>> > >>> ------------------------------ > >>> > >>> *From: *"Eric Kolotyluk" > >>> *To: *"Remi Forax" > >>> *Cc: *"loom-dev" > >>> *Sent: *Jeudi 25 Novembre 2021 23:16:11 > >>> *Subject: *Re: Loom Evades Exception Handling > >>> > >>> Thanks for the suggestion Remi, but that does not fix it, it does > >>> however result in different Exception Handling... > >>> > >>> [image: image.png] > >>> > >>> Actually, my concern is more about the stack traces, and messages, I > >>> cannot really pinpoint the root cause of the exception. It's like > there is > >>> missing information about the root cause. > >>> > >>> Through another piece of experimental code, I have isolated it to > >>> something like > >>> > >>> structuredExecutor.join(); > >>> completionHandler.throwIfFailed(); > >>> var completedResults = futureResults.map(Future::resultNow).toList(); > >>> > >>> where the last statement produces > >>> > >>> java.lang.IllegalStateException: Task has not completed > >>> at > >>> > java.base/java.util.concurrent.FutureTask.resultNow(FutureTask.java:220) > >>> at > >>> > java.base/java.util.concurrent.StructuredExecutor$FutureImpl.resultNow(StructuredExecutor.java:726) > >>> at > >>> > java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197) > >>> at > >>> java.base/java.util.stream.IntPipeline$1$1.accept(IntPipeline.java:180) > >>> at > >>> > java.base/java.util.stream.Streams$RangeIntSpliterator.forEachRemaining(Streams.java:104) > >>> at > >>> > java.base/java.util.Spliterator$OfInt.forEachRemaining(Spliterator.java:711) > >>> at > >>> > java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509) > >>> at > >>> > java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499) > >>> at > >>> > java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:575) > >>> at > >>> > java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:260) > >>> at > >>> > java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:616) > >>> at > >>> > java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:622) > >>> at > >>> > java.base/java.util.stream.ReferencePipeline.toList(ReferencePipeline.java:627) > >>> at net.kolotyluk.loom.Experiment00.main(Experiment00.java:160) > >>> > >>> Which begs the question, how can this throw an exception after the > >>> previous two statements? > >>> > >>> > >>> Again, a stream delay the calculation so you call fork() when toList is > >>> called after calling join() not before, > >>> You have to call toList() before calling throwIfFailed(). > >>> > >>> For Alan or Ron, fork() should throw an exception if called after > join() > >>> ? > >>> > >>> > >>> Cheers, Eric > >>> > >>> > >>> R?mi > >>> > >>> > >>> > >>> On Thu, Nov 25, 2021 at 1:06 PM Remi Forax wrote: > >>> > >>>> Hi Eric, > >>>> getRemoteString() returns a Stream, and a Stream delays the call to > the > >>>> intermediary operations to the point where the terminal operation, > here > >>>> forEach(), is called. > >>>> When forEach() is called, the executor is already closed, so forEach() > >>>> calls map() that calls fork() that throws an IllegalStateException. > >>>> > >>>> I see no issue here, if you return a List instead of a Stream, you > will > >>>> have the behavior I believe you want. > >>>> > >>>> regards, > >>>> R?mi > >>>> > >>>> ----- Original Message ----- > >>>> > From: "Eric Kolotyluk" > >>>> > To: "loom-dev" > >>>> > Sent: Jeudi 25 Novembre 2021 21:27:04 > >>>> > Subject: Loom Evades Exception Handling > >>>> > >>>> > Yes, that subject line is click-bait, but this is not intuitive to > >>>> me... Am > >>>> > I just seeing an incomplete implementation of Project Loom, and this > >>>> will > >>>> > be resolved in the future? > >>>> > > >>>> > public class Experiment06 { > >>>> > > >>>> > public static void main(String args[]) { > >>>> > Context.printHeader(Experiment06.class); > >>>> > > >>>> > try { > >>>> > getRemoteStrings().forEach(System.out::println); > >>>> > } catch (ExperimentException e) { > >>>> > e.printStackTrace(); > >>>> > } > >>>> > } > >>>> > > >>>> > static Stream getRemoteStrings() throws > >>>> ExperimentException { > >>>> > > >>>> > try (var structuredExecutor = > >>>> StructuredExecutor.open("Experiment06")) { > >>>> > > >>>> > // We want complete results, so we won't tolerate > failure. > >>>> > var completionHandler = new > >>>> StructuredExecutor.ShutdownOnFailure(); > >>>> > > >>>> > var futureResults = IntStream.range(0, 15).mapToObj(item > >>>> -> { > >>>> > try { > >>>> > System.out.printf("item = %d, Thread ID = %s\n", > >>>> > item, Thread.currentThread()); > >>>> > return structuredExecutor.fork(() -> { > >>>> > try { > >>>> > System.out.printf("\ttask = %d, Thread ID > >>>> > = %s\n", item, Thread.currentThread()); > >>>> > return getRemoteString(item, new > >>>> > URI("https://server1/foobar.com/item")); > >>>> > } > >>>> > catch (Throwable t) { > >>>> > System.out.printf("TASK EXCEPTION > >>>> > %s\n\t%s\n\n", t.getMessage(), t.getCause()); > >>>> > t.printStackTrace(); > >>>> > throw t; > >>>> > } > >>>> > }, completionHandler); > >>>> > } catch (Throwable t) { > >>>> > System.out.printf("SPAWN EXCEPTION %s\n\t%s\n\n", > >>>> > t.getMessage(), t.getCause()); > >>>> > t.printStackTrace(); > >>>> > throw t; > >>>> > } > >>>> > }); > >>>> > > >>>> structuredExecutor.joinUntil(Instant.now().plusSeconds(10)); > >>>> > completionHandler.throwIfFailed(); > >>>> > return futureResults.map(Future::resultNow); > >>>> > } > >>>> > catch (InterruptedException e) { > >>>> > e.printStackTrace(); > >>>> > throw new ExperimentException(e); > >>>> > } catch (ExecutionException e) { > >>>> > e.printStackTrace(); > >>>> > throw new ExperimentException(e); > >>>> > } catch (TimeoutException e) { > >>>> > e.printStackTrace(); > >>>> > throw new ExperimentException(e); > >>>> > } catch (IllegalStateException e) { > >>>> > e.printStackTrace(); > >>>> > throw new ExperimentException(e); > >>>> > } > >>>> > catch (Throwable t) { > >>>> > t.printStackTrace(); > >>>> > throw new ExperimentException(t); > >>>> > } > >>>> > } > >>>> > > >>>> > static String getRemoteString(int item, URI from) { > >>>> > return "Item %d from %s".formatted(item, from); > >>>> > } > >>>> > > >>>> > static class ExperimentException extends Exception { > >>>> > ExperimentException(Throwable cause) { > >>>> > super(cause); > >>>> > } > >>>> > } > >>>> > } > >>>> > > >>>> > where I get > >>>> > > >>>> > [image: image.png] > >>>> > > >>>> > > >>>> > (Experiment06.java:50) is > >>>> > > >>>> > return structuredExecutor.fork(() -> { > >>>> > > >>>> > (Experiment06.java:34) is > >>>> > > >>>> > getRemoteStrings().forEach(System.out::println); > >>>> > > >>>> > Is there some way I can actually find out more from the Exception > >>>> handling, > >>>> > or other techniques? > >>>> > > >>>> > Cheers, Eric > >>>> > >>> > >>> > From Alan.Bateman at oracle.com Fri Nov 26 07:11:58 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 26 Nov 2021 07:11:58 +0000 Subject: Access to Continuation.yield and ContinuationScope In-Reply-To: References: Message-ID: <9f694849-3e83-beb8-424b-ec9b28c74307@oracle.com> On 25/11/2021 19:21, Raul Raja Martinez wrote: > Thanks!, that worked for my local tests. > > Are there any plans to bring back Continuation and ContinuationScope to > public status to `java.lang` or similar or is the plan that this is going > to remain internal? The current focus is virtual threads and APIs for organizing large cohorts of threads. You are right that a low-level API for delimited continuations was exposed in EA builds for a long time but I think we've been consistent in replies here over the last 1-2 years that we weren't planning to expose it in a first release. There are issues with having the Thread identity change during execution, which is essentially what happens if you yield on one thread and continue on another. Once virtual threads are out of the way then we'll get back to topics such as custom schedulers and generators. It's possible that much of what you are looking to try out can be done with virtual threads and your own scheduler. -Alan From Alan.Bateman at oracle.com Fri Nov 26 07:53:18 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 26 Nov 2021 07:53:18 +0000 Subject: Loom Evades Exception Handling In-Reply-To: <904689040.2936183.1637879140851.JavaMail.zimbra@u-pem.fr> References: <55461503.2920318.1637874410110.JavaMail.zimbra@u-pem.fr> <904689040.2936183.1637879140851.JavaMail.zimbra@u-pem.fr> Message-ID: <72d6c690-0cf8-4224-b5de-6ea161375285@oracle.com> On 25/11/2021 22:25, forax at univ-mlv.fr wrote: > : > For Alan or Ron, fork() should throw an exception if called after join() ? It's good to look at examples like this. On first glance then it may be trying to be a bit too clever, or maybe lazy execution is just subtle sometimes. The API could be changed so that join is "joinAndShutdown" but it is already a very limited API. There will be cases where someone will want to catch InterruptedException and continue after join. There will be other cases where jounUntil will be used to stagger forks. A more limited check would be detecting that join has been called without fork but there again, there will be cases where an exception would be annoying. So I think we'll need to mull on this a bit to see if further seat belts would be help or hindrance. -Alan From eric at kolotyluk.net Fri Nov 26 15:51:18 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Fri, 26 Nov 2021 07:51:18 -0800 Subject: Loom Evades Exception Handling In-Reply-To: <72d6c690-0cf8-4224-b5de-6ea161375285@oracle.com> References: <55461503.2920318.1637874410110.JavaMail.zimbra@u-pem.fr> <904689040.2936183.1637879140851.JavaMail.zimbra@u-pem.fr> <72d6c690-0cf8-4224-b5de-6ea161375285@oracle.com> Message-ID: My main concern with this experiment was trying to diagnose what was going on from the stack traces. In the end, the problem was not at all what I could have imagined, but apparently easy for @Remi Forax to see. So, it would be great if the diagnostics could be improved to help people like me see and understand the problem earlier. Diagnostics are not seat belts, and in this case, I am not sure what seat belts would look like. One thing I know after using Gradle, is that bad diagnostics can send you on a wild goose chase, so inadequate diagnostics are preferred over bad diagnostics. >From Structured Concurrency , the example List runAll(List> tasks) throws Throwable { try (var s = StructuredExecutor.open()) { var handler = new StructuredExecutor.ShutdownOnFailure(); List> futures = tasks.map(t -> s.fork(t, handler)).toList(); s.join(); handler.throwIfFailed(e -> e); // propagate exception as-is return futures.map(Future::resultNow).toList(); } } Is sort of what I want to do, but as far as I can tell, that example won't compile because "tasks.map()" is not allowed, you need to use " tasks.stream.map()". If I could apply the usual monadic operations to Java collections, in a non-lazy way like Kotlin and Scala, I would not have fallen into this trap, but it's unrealistic to believe that Java collections will change to make me happy. Note: someone should correct the examples on this page... The beauty of this example is that it is really expressive in terms of functional programming, which is why "Future::resultNow" is so useful, and definitely the direction we should be going in. Cheers, Eric On Thu, Nov 25, 2021 at 11:53 PM Alan Bateman wrote: > On 25/11/2021 22:25, forax at univ-mlv.fr wrote: > > : > > For Alan or Ron, fork() should throw an exception if called after join() > ? > It's good to look at examples like this. On first glance then it may be > trying to be a bit too clever, or maybe lazy execution is just subtle > sometimes. > > The API could be changed so that join is "joinAndShutdown" but it is > already a very limited API. There will be cases where someone will want > to catch InterruptedException and continue after join. There will be > other cases where jounUntil will be used to stagger forks. A more > limited check would be detecting that join has been called without fork > but there again, there will be cases where an exception would be > annoying. So I think we'll need to mull on this a bit to see if further > seat belts would be help or hindrance. > > -Alan > From Alan.Bateman at oracle.com Fri Nov 26 16:16:54 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 26 Nov 2021 16:16:54 +0000 Subject: Loom Evades Exception Handling In-Reply-To: References: <55461503.2920318.1637874410110.JavaMail.zimbra@u-pem.fr> <904689040.2936183.1637879140851.JavaMail.zimbra@u-pem.fr> <72d6c690-0cf8-4224-b5de-6ea161375285@oracle.com> Message-ID: On 26/11/2021 15:51, Eric Kolotyluk wrote: > : > > From Structured Concurrency > , the example > | List runAll(List> tasks) throws Throwable { try > (var s = StructuredExecutor.open()) { var handler = new > StructuredExecutor.ShutdownOnFailure(); List> futures = > tasks.map(t -> s.fork(t, handler)).toList(); s.join(); > handler.throwIfFailed(e -> e); // propagate exception as-is return > futures.map(Future::resultNow).toList(); } } | > Is sort of what I want to do, but as far as I can tell, that example > won't compile because "|tasks.map()|" is not allowed, you need to use > " |tasks.stream.map()|". If I could apply the usual monadic operations > to Java collections, in a non-lazy way like Kotlin and Scala, I would > not have fallen into this trap, but it's unrealistic to believe that > Java collections will change to make me happy. > > Note: someone should correct the examples on this page... > Thanks, this one is fixed now. -Alan From eric at kolotyluk.net Sat Nov 27 07:18:45 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Fri, 26 Nov 2021 23:18:45 -0800 Subject: Loom on Scala Message-ID: package net.kolotyluk.loom import java.util.concurrent.StructuredExecutor import scala.util.Using object HelloScala { def main(args: Array[String]) { Context.printHeader(HelloScala.getClass) Using.Manager { use => // Scala's version of try-with-resources val structuredExecutor = use(StructuredExecutor.open("HelloScala")) val futureResults = (0 to 15).map{ item => println(s"item = $item, Thread ID = ${Thread.currentThread}") structuredExecutor.fork{ () => println(s"\ttask = $item, Thread ID = ${Thread.currentThread}") item } } println(futureResults.map(_.get)) structuredExecutor.join } } } Yes, Loom does run on Scala 2.13... I cannot get Scala 3 to work with Maven yet... might have to resort to SBT... ?? I wonder if ScopeLocal works correctly in Scala? ?? I guess it should... Don't have to worry about lazy Stream termination here ?? Don't need Future::resultNow either For some reason, if you don't call join(), close() does not throw an exception ?? -- that's not right? The Kotlin version was much harder to write and I will post later... A fun way to end the week... ?? Cheers, Eric "C:\Program Files (Open)\jdk-18\bin\java.exe" --enable-preview -Dfile.encoding=windows-1252 -jar C:\Users\ERIC\Documents\git\loom-lab\laboratory\target\laboratory.jar Hello net.kolotyluk.loom.HelloScala$ PID = 23312 CPU Cores = 12 Heap Size = 6442450944 bytes ______________________________________________________________________________ item = 0, Thread ID = Thread[#1,main,5,main] item = 1, Thread ID = Thread[#1,main,5,main] item = 2, Thread ID = Thread[#1,main,5,main] item = 3, Thread ID = Thread[#1,main,5,main] item = 4, Thread ID = Thread[#1,main,5,main] item = 5, Thread ID = Thread[#1,main,5,main] item = 6, Thread ID = Thread[#1,main,5,main] item = 7, Thread ID = Thread[#1,main,5,main] item = 8, Thread ID = Thread[#1,main,5,main] item = 9, Thread ID = Thread[#1,main,5,main] item = 10, Thread ID = Thread[#1,main,5,main] item = 11, Thread ID = Thread[#1,main,5,main] item = 12, Thread ID = Thread[#1,main,5,main] task = 0, Thread ID = VirtualThread[#15]/runnable at ForkJoinPool-1-worker-1 item = 13, Thread ID = Thread[#1,main,5,main] item = 14, Thread ID = Thread[#1,main,5,main] task = 1, Thread ID = VirtualThread[#17]/runnable at ForkJoinPool-1-worker-2 task = 2, Thread ID = VirtualThread[#18]/runnable at ForkJoinPool-1-worker-3 task = 4, Thread ID = VirtualThread[#20]/runnable at ForkJoinPool-1-worker-3 task = 5, Thread ID = VirtualThread[#22]/runnable at ForkJoinPool-1-worker-2 task = 7, Thread ID = VirtualThread[#24]/runnable at ForkJoinPool-1-worker-2 task = 6, Thread ID = VirtualThread[#23]/runnable at ForkJoinPool-1-worker-3 task = 8, Thread ID = VirtualThread[#25]/runnable at ForkJoinPool-1-worker-3 task = 9, Thread ID = VirtualThread[#27]/runnable at ForkJoinPool-1-worker-2 task = 3, Thread ID = VirtualThread[#19]/runnable at ForkJoinPool-1-worker-4 task = 10, Thread ID = VirtualThread[#28]/runnable at ForkJoinPool-1-worker-3 task = 11, Thread ID = VirtualThread[#29]/runnable at ForkJoinPool-1-worker-2 task = 12, Thread ID = VirtualThread[#31]/runnable at ForkJoinPool-1-worker-4 task = 13, Thread ID = VirtualThread[#34]/runnable at ForkJoinPool-1-worker-5 item = 15, Thread ID = Thread[#1,main,5,main] task = 14, Thread ID = VirtualThread[#35]/runnable at ForkJoinPool-1-worker-5 task = 15, Thread ID = VirtualThread[#42]/runnable at ForkJoinPool-1-worker-11 Vector(0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15) Process finished with exit code 0 From oleksandr.otenko at gmail.com Sat Nov 27 07:41:10 2021 From: oleksandr.otenko at gmail.com (Alex Otenko) Date: Sat, 27 Nov 2021 07:41:10 +0000 Subject: Loom on Scala In-Reply-To: References: Message-ID: Most likely Scala's try-with-resource catches and handles the exception during close() Same with map(_.get) vs map(Future::resultNow) - the difference is only in who's waiting and what kind of exception is thrown, so if Scala handles checked exceptions for you, you aren't inconvenienced. Alex On Sat, 27 Nov 2021, 07:19 Eric Kolotyluk, wrote: > package net.kolotyluk.loom > > import java.util.concurrent.StructuredExecutor > import scala.util.Using > > object HelloScala { > def main(args: Array[String]) { > Context.printHeader(HelloScala.getClass) > > Using.Manager { use => // Scala's version of try-with-resources > val structuredExecutor = use(StructuredExecutor.open("HelloScala")) > > val futureResults = (0 to 15).map{ item => > println(s"item = $item, Thread ID = ${Thread.currentThread}") > structuredExecutor.fork{ () => > println(s"\ttask = $item, Thread ID = ${Thread.currentThread}") > item > } > } > println(futureResults.map(_.get)) > structuredExecutor.join > } > } > } > > Yes, Loom does run on Scala 2.13... I cannot get Scala 3 to work with Maven > yet... might have to resort to SBT... ?? > > I wonder if ScopeLocal works correctly in Scala? ?? I guess it should... > > Don't have to worry about lazy Stream termination here ?? > > Don't need Future::resultNow either > > For some reason, if you don't call join(), close() does not throw an > exception ?? -- that's not right? > > The Kotlin version was much harder to write and I will post later... > > A fun way to end the week... ?? > > Cheers, Eric > > > "C:\Program Files (Open)\jdk-18\bin\java.exe" --enable-preview > -Dfile.encoding=windows-1252 -jar > C:\Users\ERIC\Documents\git\loom-lab\laboratory\target\laboratory.jar > Hello net.kolotyluk.loom.HelloScala$ > PID = 23312 > CPU Cores = 12 > Heap Size = 6442450944 bytes > > ______________________________________________________________________________ > > item = 0, Thread ID = Thread[#1,main,5,main] > item = 1, Thread ID = Thread[#1,main,5,main] > item = 2, Thread ID = Thread[#1,main,5,main] > item = 3, Thread ID = Thread[#1,main,5,main] > item = 4, Thread ID = Thread[#1,main,5,main] > item = 5, Thread ID = Thread[#1,main,5,main] > item = 6, Thread ID = Thread[#1,main,5,main] > item = 7, Thread ID = Thread[#1,main,5,main] > item = 8, Thread ID = Thread[#1,main,5,main] > item = 9, Thread ID = Thread[#1,main,5,main] > item = 10, Thread ID = Thread[#1,main,5,main] > item = 11, Thread ID = Thread[#1,main,5,main] > item = 12, Thread ID = Thread[#1,main,5,main] > task = 0, Thread ID = > VirtualThread[#15]/runnable at ForkJoinPool-1-worker-1 > item = 13, Thread ID = Thread[#1,main,5,main] > item = 14, Thread ID = Thread[#1,main,5,main] > task = 1, Thread ID = > VirtualThread[#17]/runnable at ForkJoinPool-1-worker-2 > task = 2, Thread ID = > VirtualThread[#18]/runnable at ForkJoinPool-1-worker-3 > task = 4, Thread ID = > VirtualThread[#20]/runnable at ForkJoinPool-1-worker-3 > task = 5, Thread ID = > VirtualThread[#22]/runnable at ForkJoinPool-1-worker-2 > task = 7, Thread ID = > VirtualThread[#24]/runnable at ForkJoinPool-1-worker-2 > task = 6, Thread ID = > VirtualThread[#23]/runnable at ForkJoinPool-1-worker-3 > task = 8, Thread ID = > VirtualThread[#25]/runnable at ForkJoinPool-1-worker-3 > task = 9, Thread ID = > VirtualThread[#27]/runnable at ForkJoinPool-1-worker-2 > task = 3, Thread ID = > VirtualThread[#19]/runnable at ForkJoinPool-1-worker-4 > task = 10, Thread ID = > VirtualThread[#28]/runnable at ForkJoinPool-1-worker-3 > task = 11, Thread ID = > VirtualThread[#29]/runnable at ForkJoinPool-1-worker-2 > task = 12, Thread ID = > VirtualThread[#31]/runnable at ForkJoinPool-1-worker-4 > task = 13, Thread ID = > VirtualThread[#34]/runnable at ForkJoinPool-1-worker-5 > item = 15, Thread ID = Thread[#1,main,5,main] > task = 14, Thread ID = > VirtualThread[#35]/runnable at ForkJoinPool-1-worker-5 > task = 15, Thread ID = > VirtualThread[#42]/runnable at ForkJoinPool-1-worker-11 > Vector(0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15) > > Process finished with exit code 0 > From eric at kolotyluk.net Sat Nov 27 21:03:02 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Sat, 27 Nov 2021 13:03:02 -0800 Subject: Loom on Scala In-Reply-To: References: Message-ID: Alex was right, Using.Manager was consuming the exception. The better solution is object HelloScala { def main(args: Array[String]) { Context.printHeader(HelloScala.getClass) val results = Using(StructuredExecutor.open("HelloScala")) { structuredExecutor => val futureResults = (0 to 15).map { item => println(s"item = $item, Thread ID = ${Thread.currentThread}") structuredExecutor.fork { () => println(s"\ttask = $item, Thread ID = ${Thread.currentThread}") item } } structuredExecutor.join futureResults.map(_.get) } println(results) } } Which outputs either Success(Vector(0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15)) or Failure(java.lang.IllegalStateException: Owner did not invoke join or joinUntil) Depending on if join() is called. Alex, map(_.get) works fine because get() will wait for the value to become available, while resultNow() won't. I am somewhat disappointed that Using consumes the exception rather than letting it be caught in a try block, but it does return the exception as a Scala Try result of either Success or Failure, which I can live with. Still, this is not intuitive. It is interesting to note that IMHO the Scala code is aesthetically more beautiful than the equivalent Java code, but Java has a stronger commitment to safety and backward compatibility which creates challenges to good aesthetics. Is there a JEP on extending Java collections to support monadic operators such as map()? After this experience, I now feel that Java Stream creates dangerous situations that are not intuitive to troubleshoot, and it would be nice if Java Collections had the same functionality as Kotlin and Scala Collections. Cheers, Eric On Fri, Nov 26, 2021 at 11:41 PM Alex Otenko wrote: > Most likely Scala's try-with-resource catches and handles the exception > during close() > > Same with map(_.get) vs map(Future::resultNow) - the difference is only in > who's waiting and what kind of exception is thrown, so if Scala handles > checked exceptions for you, you aren't inconvenienced. > > Alex > > On Sat, 27 Nov 2021, 07:19 Eric Kolotyluk, wrote: > >> package net.kolotyluk.loom >> >> import java.util.concurrent.StructuredExecutor >> import scala.util.Using >> >> object HelloScala { >> def main(args: Array[String]) { >> Context.printHeader(HelloScala.getClass) >> >> Using.Manager { use => // Scala's version of try-with-resources >> val structuredExecutor = use(StructuredExecutor.open("HelloScala")) >> >> val futureResults = (0 to 15).map{ item => >> println(s"item = $item, Thread ID = ${Thread.currentThread}") >> structuredExecutor.fork{ () => >> println(s"\ttask = $item, Thread ID = ${Thread.currentThread}") >> item >> } >> } >> println(futureResults.map(_.get)) >> structuredExecutor.join >> } >> } >> } >> >> Yes, Loom does run on Scala 2.13... I cannot get Scala 3 to work with >> Maven >> yet... might have to resort to SBT... ?? >> >> I wonder if ScopeLocal works correctly in Scala? ?? I guess it should... >> >> Don't have to worry about lazy Stream termination here ?? >> >> Don't need Future::resultNow either >> >> For some reason, if you don't call join(), close() does not throw an >> exception ?? -- that's not right? >> >> The Kotlin version was much harder to write and I will post later... >> >> A fun way to end the week... ?? >> >> Cheers, Eric >> >> >> "C:\Program Files (Open)\jdk-18\bin\java.exe" --enable-preview >> -Dfile.encoding=windows-1252 -jar >> C:\Users\ERIC\Documents\git\loom-lab\laboratory\target\laboratory.jar >> Hello net.kolotyluk.loom.HelloScala$ >> PID = 23312 >> CPU Cores = 12 >> Heap Size = 6442450944 bytes >> >> ______________________________________________________________________________ >> >> item = 0, Thread ID = Thread[#1,main,5,main] >> item = 1, Thread ID = Thread[#1,main,5,main] >> item = 2, Thread ID = Thread[#1,main,5,main] >> item = 3, Thread ID = Thread[#1,main,5,main] >> item = 4, Thread ID = Thread[#1,main,5,main] >> item = 5, Thread ID = Thread[#1,main,5,main] >> item = 6, Thread ID = Thread[#1,main,5,main] >> item = 7, Thread ID = Thread[#1,main,5,main] >> item = 8, Thread ID = Thread[#1,main,5,main] >> item = 9, Thread ID = Thread[#1,main,5,main] >> item = 10, Thread ID = Thread[#1,main,5,main] >> item = 11, Thread ID = Thread[#1,main,5,main] >> item = 12, Thread ID = Thread[#1,main,5,main] >> task = 0, Thread ID = >> VirtualThread[#15]/runnable at ForkJoinPool-1-worker-1 >> item = 13, Thread ID = Thread[#1,main,5,main] >> item = 14, Thread ID = Thread[#1,main,5,main] >> task = 1, Thread ID = >> VirtualThread[#17]/runnable at ForkJoinPool-1-worker-2 >> task = 2, Thread ID = >> VirtualThread[#18]/runnable at ForkJoinPool-1-worker-3 >> task = 4, Thread ID = >> VirtualThread[#20]/runnable at ForkJoinPool-1-worker-3 >> task = 5, Thread ID = >> VirtualThread[#22]/runnable at ForkJoinPool-1-worker-2 >> task = 7, Thread ID = >> VirtualThread[#24]/runnable at ForkJoinPool-1-worker-2 >> task = 6, Thread ID = >> VirtualThread[#23]/runnable at ForkJoinPool-1-worker-3 >> task = 8, Thread ID = >> VirtualThread[#25]/runnable at ForkJoinPool-1-worker-3 >> task = 9, Thread ID = >> VirtualThread[#27]/runnable at ForkJoinPool-1-worker-2 >> task = 3, Thread ID = >> VirtualThread[#19]/runnable at ForkJoinPool-1-worker-4 >> task = 10, Thread ID = >> VirtualThread[#28]/runnable at ForkJoinPool-1-worker-3 >> task = 11, Thread ID = >> VirtualThread[#29]/runnable at ForkJoinPool-1-worker-2 >> task = 12, Thread ID = >> VirtualThread[#31]/runnable at ForkJoinPool-1-worker-4 >> task = 13, Thread ID = >> VirtualThread[#34]/runnable at ForkJoinPool-1-worker-5 >> item = 15, Thread ID = Thread[#1,main,5,main] >> task = 14, Thread ID = >> VirtualThread[#35]/runnable at ForkJoinPool-1-worker-5 >> task = 15, Thread ID = >> VirtualThread[#42]/runnable at ForkJoinPool-1-worker-11 >> Vector(0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15) >> >> Process finished with exit code 0 >> > From oleksandr.otenko at gmail.com Sat Nov 27 22:14:40 2021 From: oleksandr.otenko at gmail.com (Alex Otenko) Date: Sat, 27 Nov 2021 22:14:40 +0000 Subject: Loom on Scala In-Reply-To: References: Message-ID: Scala Stream.map(_.get) will cause the same grief as you encountered in Java. So it's not a problem specific to Java, it is lazy evaluation in general, and that closures can make things outlive their syntactic scope. Alex On Sat, 27 Nov 2021, 21:03 Eric Kolotyluk, wrote: > Alex was right, Using.Manager was consuming the exception. The better > solution is > > object HelloScala { > def main(args: Array[String]) { > Context.printHeader(HelloScala.getClass) > > val results = > Using(StructuredExecutor.open("HelloScala")) { structuredExecutor => > val futureResults = (0 to 15).map { item => > println(s"item = $item, Thread ID = ${Thread.currentThread}") > structuredExecutor.fork { () => > println(s"\ttask = $item, Thread ID = ${Thread.currentThread}") > item > } > } > structuredExecutor.join > futureResults.map(_.get) > } > > println(results) > } > } > > Which outputs either > > Success(Vector(0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15)) > or > Failure(java.lang.IllegalStateException: Owner did not invoke join or > joinUntil) > > Depending on if join() is called. > > Alex, map(_.get) works fine because get() will wait for the value to > become available, while resultNow() won't. > > I am somewhat disappointed that Using consumes the exception rather than > letting it be caught in a try block, but it does return the exception as a > Scala Try result of either Success or Failure, which I can live with. > Still, this is not intuitive. > > It is interesting to note that IMHO the Scala code is aesthetically more > beautiful than the equivalent Java code, but Java has a stronger commitment > to safety and backward compatibility which creates challenges to good > aesthetics. > > Is there a JEP on extending Java collections to support monadic operators > such as map()? After this experience, I now feel that Java Stream creates > dangerous situations that are not intuitive to troubleshoot, and it would > be nice if Java Collections had the same functionality as Kotlin and Scala > Collections. > > Cheers, Eric > > > On Fri, Nov 26, 2021 at 11:41 PM Alex Otenko > wrote: > >> Most likely Scala's try-with-resource catches and handles the exception >> during close() >> >> Same with map(_.get) vs map(Future::resultNow) - the difference is only >> in who's waiting and what kind of exception is thrown, so if Scala handles >> checked exceptions for you, you aren't inconvenienced. >> >> Alex >> >> On Sat, 27 Nov 2021, 07:19 Eric Kolotyluk, wrote: >> >>> package net.kolotyluk.loom >>> >>> import java.util.concurrent.StructuredExecutor >>> import scala.util.Using >>> >>> object HelloScala { >>> def main(args: Array[String]) { >>> Context.printHeader(HelloScala.getClass) >>> >>> Using.Manager { use => // Scala's version of try-with-resources >>> val structuredExecutor = use(StructuredExecutor.open("HelloScala")) >>> >>> val futureResults = (0 to 15).map{ item => >>> println(s"item = $item, Thread ID = ${Thread.currentThread}") >>> structuredExecutor.fork{ () => >>> println(s"\ttask = $item, Thread ID = ${Thread.currentThread}") >>> item >>> } >>> } >>> println(futureResults.map(_.get)) >>> structuredExecutor.join >>> } >>> } >>> } >>> >>> Yes, Loom does run on Scala 2.13... I cannot get Scala 3 to work with >>> Maven >>> yet... might have to resort to SBT... ?? >>> >>> I wonder if ScopeLocal works correctly in Scala? ?? I guess it should... >>> >>> Don't have to worry about lazy Stream termination here ?? >>> >>> Don't need Future::resultNow either >>> >>> For some reason, if you don't call join(), close() does not throw an >>> exception ?? -- that's not right? >>> >>> The Kotlin version was much harder to write and I will post later... >>> >>> A fun way to end the week... ?? >>> >>> Cheers, Eric >>> >>> >>> "C:\Program Files (Open)\jdk-18\bin\java.exe" --enable-preview >>> -Dfile.encoding=windows-1252 -jar >>> C:\Users\ERIC\Documents\git\loom-lab\laboratory\target\laboratory.jar >>> Hello net.kolotyluk.loom.HelloScala$ >>> PID = 23312 >>> CPU Cores = 12 >>> Heap Size = 6442450944 bytes >>> >>> ______________________________________________________________________________ >>> >>> item = 0, Thread ID = Thread[#1,main,5,main] >>> item = 1, Thread ID = Thread[#1,main,5,main] >>> item = 2, Thread ID = Thread[#1,main,5,main] >>> item = 3, Thread ID = Thread[#1,main,5,main] >>> item = 4, Thread ID = Thread[#1,main,5,main] >>> item = 5, Thread ID = Thread[#1,main,5,main] >>> item = 6, Thread ID = Thread[#1,main,5,main] >>> item = 7, Thread ID = Thread[#1,main,5,main] >>> item = 8, Thread ID = Thread[#1,main,5,main] >>> item = 9, Thread ID = Thread[#1,main,5,main] >>> item = 10, Thread ID = Thread[#1,main,5,main] >>> item = 11, Thread ID = Thread[#1,main,5,main] >>> item = 12, Thread ID = Thread[#1,main,5,main] >>> task = 0, Thread ID = >>> VirtualThread[#15]/runnable at ForkJoinPool-1-worker-1 >>> item = 13, Thread ID = Thread[#1,main,5,main] >>> item = 14, Thread ID = Thread[#1,main,5,main] >>> task = 1, Thread ID = >>> VirtualThread[#17]/runnable at ForkJoinPool-1-worker-2 >>> task = 2, Thread ID = >>> VirtualThread[#18]/runnable at ForkJoinPool-1-worker-3 >>> task = 4, Thread ID = >>> VirtualThread[#20]/runnable at ForkJoinPool-1-worker-3 >>> task = 5, Thread ID = >>> VirtualThread[#22]/runnable at ForkJoinPool-1-worker-2 >>> task = 7, Thread ID = >>> VirtualThread[#24]/runnable at ForkJoinPool-1-worker-2 >>> task = 6, Thread ID = >>> VirtualThread[#23]/runnable at ForkJoinPool-1-worker-3 >>> task = 8, Thread ID = >>> VirtualThread[#25]/runnable at ForkJoinPool-1-worker-3 >>> task = 9, Thread ID = >>> VirtualThread[#27]/runnable at ForkJoinPool-1-worker-2 >>> task = 3, Thread ID = >>> VirtualThread[#19]/runnable at ForkJoinPool-1-worker-4 >>> task = 10, Thread ID = >>> VirtualThread[#28]/runnable at ForkJoinPool-1-worker-3 >>> task = 11, Thread ID = >>> VirtualThread[#29]/runnable at ForkJoinPool-1-worker-2 >>> task = 12, Thread ID = >>> VirtualThread[#31]/runnable at ForkJoinPool-1-worker-4 >>> task = 13, Thread ID = >>> VirtualThread[#34]/runnable at ForkJoinPool-1-worker-5 >>> item = 15, Thread ID = Thread[#1,main,5,main] >>> task = 14, Thread ID = >>> VirtualThread[#35]/runnable at ForkJoinPool-1-worker-5 >>> task = 15, Thread ID = >>> VirtualThread[#42]/runnable at ForkJoinPool-1-worker-11 >>> Vector(0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15) >>> >>> Process finished with exit code 0 >>> >> From oleksandr.otenko at gmail.com Sat Nov 27 22:58:02 2021 From: oleksandr.otenko at gmail.com (Alex Otenko) Date: Sat, 27 Nov 2021 22:58:02 +0000 Subject: Loom on Scala In-Reply-To: References: Message-ID: I meant stream.map(... executor.fork(...)) of course Alex On Sat, 27 Nov 2021, 22:14 Alex Otenko, wrote: > Scala Stream.map(_.get) will cause the same grief as you encountered in > Java. So it's not a problem specific to Java, it is lazy evaluation in > general, and that closures can make things outlive their syntactic scope. > > Alex > > On Sat, 27 Nov 2021, 21:03 Eric Kolotyluk, wrote: > >> Alex was right, Using.Manager was consuming the exception. The better >> solution is >> >> object HelloScala { >> def main(args: Array[String]) { >> Context.printHeader(HelloScala.getClass) >> >> val results = >> Using(StructuredExecutor.open("HelloScala")) { structuredExecutor => >> val futureResults = (0 to 15).map { item => >> println(s"item = $item, Thread ID = ${Thread.currentThread}") >> structuredExecutor.fork { () => >> println(s"\ttask = $item, Thread ID = ${Thread.currentThread}") >> item >> } >> } >> structuredExecutor.join >> futureResults.map(_.get) >> } >> >> println(results) >> } >> } >> >> Which outputs either >> >> Success(Vector(0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15)) >> or >> Failure(java.lang.IllegalStateException: Owner did not invoke join or >> joinUntil) >> >> Depending on if join() is called. >> >> Alex, map(_.get) works fine because get() will wait for the value to >> become available, while resultNow() won't. >> >> I am somewhat disappointed that Using consumes the exception rather than >> letting it be caught in a try block, but it does return the exception as a >> Scala Try result of either Success or Failure, which I can live with. >> Still, this is not intuitive. >> >> It is interesting to note that IMHO the Scala code is aesthetically more >> beautiful than the equivalent Java code, but Java has a stronger commitment >> to safety and backward compatibility which creates challenges to good >> aesthetics. >> >> Is there a JEP on extending Java collections to support monadic operators >> such as map()? After this experience, I now feel that Java Stream creates >> dangerous situations that are not intuitive to troubleshoot, and it would >> be nice if Java Collections had the same functionality as Kotlin and Scala >> Collections. >> >> Cheers, Eric >> >> >> On Fri, Nov 26, 2021 at 11:41 PM Alex Otenko >> wrote: >> >>> Most likely Scala's try-with-resource catches and handles the exception >>> during close() >>> >>> Same with map(_.get) vs map(Future::resultNow) - the difference is only >>> in who's waiting and what kind of exception is thrown, so if Scala handles >>> checked exceptions for you, you aren't inconvenienced. >>> >>> Alex >>> >>> On Sat, 27 Nov 2021, 07:19 Eric Kolotyluk, wrote: >>> >>>> package net.kolotyluk.loom >>>> >>>> import java.util.concurrent.StructuredExecutor >>>> import scala.util.Using >>>> >>>> object HelloScala { >>>> def main(args: Array[String]) { >>>> Context.printHeader(HelloScala.getClass) >>>> >>>> Using.Manager { use => // Scala's version of try-with-resources >>>> val structuredExecutor = >>>> use(StructuredExecutor.open("HelloScala")) >>>> >>>> val futureResults = (0 to 15).map{ item => >>>> println(s"item = $item, Thread ID = ${Thread.currentThread}") >>>> structuredExecutor.fork{ () => >>>> println(s"\ttask = $item, Thread ID = >>>> ${Thread.currentThread}") >>>> item >>>> } >>>> } >>>> println(futureResults.map(_.get)) >>>> structuredExecutor.join >>>> } >>>> } >>>> } >>>> >>>> Yes, Loom does run on Scala 2.13... I cannot get Scala 3 to work with >>>> Maven >>>> yet... might have to resort to SBT... ?? >>>> >>>> I wonder if ScopeLocal works correctly in Scala? ?? I guess it should... >>>> >>>> Don't have to worry about lazy Stream termination here ?? >>>> >>>> Don't need Future::resultNow either >>>> >>>> For some reason, if you don't call join(), close() does not throw an >>>> exception ?? -- that's not right? >>>> >>>> The Kotlin version was much harder to write and I will post later... >>>> >>>> A fun way to end the week... ?? >>>> >>>> Cheers, Eric >>>> >>>> >>>> "C:\Program Files (Open)\jdk-18\bin\java.exe" --enable-preview >>>> -Dfile.encoding=windows-1252 -jar >>>> C:\Users\ERIC\Documents\git\loom-lab\laboratory\target\laboratory.jar >>>> Hello net.kolotyluk.loom.HelloScala$ >>>> PID = 23312 >>>> CPU Cores = 12 >>>> Heap Size = 6442450944 bytes >>>> >>>> ______________________________________________________________________________ >>>> >>>> item = 0, Thread ID = Thread[#1,main,5,main] >>>> item = 1, Thread ID = Thread[#1,main,5,main] >>>> item = 2, Thread ID = Thread[#1,main,5,main] >>>> item = 3, Thread ID = Thread[#1,main,5,main] >>>> item = 4, Thread ID = Thread[#1,main,5,main] >>>> item = 5, Thread ID = Thread[#1,main,5,main] >>>> item = 6, Thread ID = Thread[#1,main,5,main] >>>> item = 7, Thread ID = Thread[#1,main,5,main] >>>> item = 8, Thread ID = Thread[#1,main,5,main] >>>> item = 9, Thread ID = Thread[#1,main,5,main] >>>> item = 10, Thread ID = Thread[#1,main,5,main] >>>> item = 11, Thread ID = Thread[#1,main,5,main] >>>> item = 12, Thread ID = Thread[#1,main,5,main] >>>> task = 0, Thread ID = >>>> VirtualThread[#15]/runnable at ForkJoinPool-1-worker-1 >>>> item = 13, Thread ID = Thread[#1,main,5,main] >>>> item = 14, Thread ID = Thread[#1,main,5,main] >>>> task = 1, Thread ID = >>>> VirtualThread[#17]/runnable at ForkJoinPool-1-worker-2 >>>> task = 2, Thread ID = >>>> VirtualThread[#18]/runnable at ForkJoinPool-1-worker-3 >>>> task = 4, Thread ID = >>>> VirtualThread[#20]/runnable at ForkJoinPool-1-worker-3 >>>> task = 5, Thread ID = >>>> VirtualThread[#22]/runnable at ForkJoinPool-1-worker-2 >>>> task = 7, Thread ID = >>>> VirtualThread[#24]/runnable at ForkJoinPool-1-worker-2 >>>> task = 6, Thread ID = >>>> VirtualThread[#23]/runnable at ForkJoinPool-1-worker-3 >>>> task = 8, Thread ID = >>>> VirtualThread[#25]/runnable at ForkJoinPool-1-worker-3 >>>> task = 9, Thread ID = >>>> VirtualThread[#27]/runnable at ForkJoinPool-1-worker-2 >>>> task = 3, Thread ID = >>>> VirtualThread[#19]/runnable at ForkJoinPool-1-worker-4 >>>> task = 10, Thread ID = >>>> VirtualThread[#28]/runnable at ForkJoinPool-1-worker-3 >>>> task = 11, Thread ID = >>>> VirtualThread[#29]/runnable at ForkJoinPool-1-worker-2 >>>> task = 12, Thread ID = >>>> VirtualThread[#31]/runnable at ForkJoinPool-1-worker-4 >>>> task = 13, Thread ID = >>>> VirtualThread[#34]/runnable at ForkJoinPool-1-worker-5 >>>> item = 15, Thread ID = Thread[#1,main,5,main] >>>> task = 14, Thread ID = >>>> VirtualThread[#35]/runnable at ForkJoinPool-1-worker-5 >>>> task = 15, Thread ID = >>>> VirtualThread[#42]/runnable at ForkJoinPool-1-worker-11 >>>> Vector(0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15) >>>> >>>> Process finished with exit code 0 >>>> >>> From eric at kolotyluk.net Sat Nov 27 23:12:12 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Sat, 27 Nov 2021 15:12:12 -0800 Subject: Loom on Scala In-Reply-To: References: Message-ID: @Alex Otenko I saw this late "I meant stream.map(... executor.fork(...)) of course" -- and yes, I agree that is one source of trouble... In this example, I was not implying Stream.map(_.get), because in this context futureResults is implicitly, val futureResults : IndexedSeq[Future[Int]] = . . . which is a Scala collection that is not lazy. But you are right in that "it is lazy evaluation in general, and that closures *can* [maybe, maybe not] make things outlive their syntactic scope" which can be a problem in any language, even Scala. Stream.map(_.get) might be a problem in some contexts, but might be fine in other contexts. However, I am trying to focus on the point that in Java, to use operations like map(), Stream is the only path to take, so we are forced to deal with lazy evaluation. This experience of using Scala leads me to two conclusions: 1. Java Collections need non-lazy monadic operators in addition to Stream. 2. StructuredExecutor#join should not be required before StructuredExecutor#close. val results = Using(StructuredExecutor.open("HelloScala")) { structuredExecutor => val futureResults = (0 to 15).map { item => println(s"item = $item, Thread ID = ${Thread.currentThread}") structuredExecutor.fork { () => println(s"\ttask = $item, Thread ID = ${Thread.currentThread}") item } } futureResults.map(_.get) } println(results) - This is a perfectly valid expression of logic because furtureResults.map(_.get) will wait/block until all the Futures have been completed, which implicitly is the same as a join(). - Project Loom is an extension of the JVM and libraries, not the Java Language. Other language users, such as Scala, should not be penalized by having to use join() when it is not semantically necessary. - Even in Java, join() should not be necessary because it is possible to wait for all Futures to be complete by other means. - Indeed, close() should be able to detect if all tasks have completed, even if join() has not been called. - It is reasonable to expect StructuredExecutor#close to implicitly join() if necessary, - and throw an exception when appropriate, even if this requires wrapping try-with-resources with another try to catch the closing exception. - yes, this would be really ugly, but we have trade-offs on where ugly and beautiful present themselves - In some cases, it's really important/useful to call join, such as dealing with any completion failures, but there are other mechanisms to catch those failures. My sense is that requiring join() before close() is a kluge, and I invite someone to convince me otherwise. I am not trying to insult anyone, just convey an emotion, and I am willing to be convinced otherwise. - Yes, calling join() before close() is an extremely good practice for many reasons, but it's not always semantically necessary. - Is calling join() before close() a seatbelt where Loom is trying to protect us from ourselves? - Is it too much work to implement this otherwise? - Is there some hard-core technical reason why this is necessary? Cheers, Eric On Sat, Nov 27, 2021 at 2:14 PM Alex Otenko wrote: > Scala Stream.map(_.get) will cause the same grief as you encountered in > Java. So it's not a problem specific to Java, it is lazy evaluation in > general, and that closures can make things outlive their syntactic scope. > > Alex > > On Sat, 27 Nov 2021, 21:03 Eric Kolotyluk, wrote: > >> Alex was right, Using.Manager was consuming the exception. The better >> solution is >> >> object HelloScala { >> def main(args: Array[String]) { >> Context.printHeader(HelloScala.getClass) >> >> val results = >> Using(StructuredExecutor.open("HelloScala")) { structuredExecutor => >> val futureResults = (0 to 15).map { item => >> println(s"item = $item, Thread ID = ${Thread.currentThread}") >> structuredExecutor.fork { () => >> println(s"\ttask = $item, Thread ID = ${Thread.currentThread}") >> item >> } >> } >> structuredExecutor.join >> futureResults.map(_.get) >> } >> >> println(results) >> } >> } >> >> Which outputs either >> >> Success(Vector(0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15)) >> or >> Failure(java.lang.IllegalStateException: Owner did not invoke join or >> joinUntil) >> >> Depending on if join() is called. >> >> Alex, map(_.get) works fine because get() will wait for the value to >> become available, while resultNow() won't. >> >> I am somewhat disappointed that Using consumes the exception rather than >> letting it be caught in a try block, but it does return the exception as a >> Scala Try result of either Success or Failure, which I can live with. >> Still, this is not intuitive. >> >> It is interesting to note that IMHO the Scala code is aesthetically more >> beautiful than the equivalent Java code, but Java has a stronger commitment >> to safety and backward compatibility which creates challenges to good >> aesthetics. >> >> Is there a JEP on extending Java collections to support monadic operators >> such as map()? After this experience, I now feel that Java Stream creates >> dangerous situations that are not intuitive to troubleshoot, and it would >> be nice if Java Collections had the same functionality as Kotlin and Scala >> Collections. >> >> Cheers, Eric >> >> >> On Fri, Nov 26, 2021 at 11:41 PM Alex Otenko >> wrote: >> >>> Most likely Scala's try-with-resource catches and handles the exception >>> during close() >>> >>> Same with map(_.get) vs map(Future::resultNow) - the difference is only >>> in who's waiting and what kind of exception is thrown, so if Scala handles >>> checked exceptions for you, you aren't inconvenienced. >>> >>> Alex >>> >>> On Sat, 27 Nov 2021, 07:19 Eric Kolotyluk, wrote: >>> >>>> package net.kolotyluk.loom >>>> >>>> import java.util.concurrent.StructuredExecutor >>>> import scala.util.Using >>>> >>>> object HelloScala { >>>> def main(args: Array[String]) { >>>> Context.printHeader(HelloScala.getClass) >>>> >>>> Using.Manager { use => // Scala's version of try-with-resources >>>> val structuredExecutor = >>>> use(StructuredExecutor.open("HelloScala")) >>>> >>>> val futureResults = (0 to 15).map{ item => >>>> println(s"item = $item, Thread ID = ${Thread.currentThread}") >>>> structuredExecutor.fork{ () => >>>> println(s"\ttask = $item, Thread ID = >>>> ${Thread.currentThread}") >>>> item >>>> } >>>> } >>>> println(futureResults.map(_.get)) >>>> structuredExecutor.join >>>> } >>>> } >>>> } >>>> >>>> Yes, Loom does run on Scala 2.13... I cannot get Scala 3 to work with >>>> Maven >>>> yet... might have to resort to SBT... ?? >>>> >>>> I wonder if ScopeLocal works correctly in Scala? ?? I guess it should... >>>> >>>> Don't have to worry about lazy Stream termination here ?? >>>> >>>> Don't need Future::resultNow either >>>> >>>> For some reason, if you don't call join(), close() does not throw an >>>> exception ?? -- that's not right? >>>> >>>> The Kotlin version was much harder to write and I will post later... >>>> >>>> A fun way to end the week... ?? >>>> >>>> Cheers, Eric >>>> >>>> >>>> "C:\Program Files (Open)\jdk-18\bin\java.exe" --enable-preview >>>> -Dfile.encoding=windows-1252 -jar >>>> C:\Users\ERIC\Documents\git\loom-lab\laboratory\target\laboratory.jar >>>> Hello net.kolotyluk.loom.HelloScala$ >>>> PID = 23312 >>>> CPU Cores = 12 >>>> Heap Size = 6442450944 bytes >>>> >>>> ______________________________________________________________________________ >>>> >>>> item = 0, Thread ID = Thread[#1,main,5,main] >>>> item = 1, Thread ID = Thread[#1,main,5,main] >>>> item = 2, Thread ID = Thread[#1,main,5,main] >>>> item = 3, Thread ID = Thread[#1,main,5,main] >>>> item = 4, Thread ID = Thread[#1,main,5,main] >>>> item = 5, Thread ID = Thread[#1,main,5,main] >>>> item = 6, Thread ID = Thread[#1,main,5,main] >>>> item = 7, Thread ID = Thread[#1,main,5,main] >>>> item = 8, Thread ID = Thread[#1,main,5,main] >>>> item = 9, Thread ID = Thread[#1,main,5,main] >>>> item = 10, Thread ID = Thread[#1,main,5,main] >>>> item = 11, Thread ID = Thread[#1,main,5,main] >>>> item = 12, Thread ID = Thread[#1,main,5,main] >>>> task = 0, Thread ID = >>>> VirtualThread[#15]/runnable at ForkJoinPool-1-worker-1 >>>> item = 13, Thread ID = Thread[#1,main,5,main] >>>> item = 14, Thread ID = Thread[#1,main,5,main] >>>> task = 1, Thread ID = >>>> VirtualThread[#17]/runnable at ForkJoinPool-1-worker-2 >>>> task = 2, Thread ID = >>>> VirtualThread[#18]/runnable at ForkJoinPool-1-worker-3 >>>> task = 4, Thread ID = >>>> VirtualThread[#20]/runnable at ForkJoinPool-1-worker-3 >>>> task = 5, Thread ID = >>>> VirtualThread[#22]/runnable at ForkJoinPool-1-worker-2 >>>> task = 7, Thread ID = >>>> VirtualThread[#24]/runnable at ForkJoinPool-1-worker-2 >>>> task = 6, Thread ID = >>>> VirtualThread[#23]/runnable at ForkJoinPool-1-worker-3 >>>> task = 8, Thread ID = >>>> VirtualThread[#25]/runnable at ForkJoinPool-1-worker-3 >>>> task = 9, Thread ID = >>>> VirtualThread[#27]/runnable at ForkJoinPool-1-worker-2 >>>> task = 3, Thread ID = >>>> VirtualThread[#19]/runnable at ForkJoinPool-1-worker-4 >>>> task = 10, Thread ID = >>>> VirtualThread[#28]/runnable at ForkJoinPool-1-worker-3 >>>> task = 11, Thread ID = >>>> VirtualThread[#29]/runnable at ForkJoinPool-1-worker-2 >>>> task = 12, Thread ID = >>>> VirtualThread[#31]/runnable at ForkJoinPool-1-worker-4 >>>> task = 13, Thread ID = >>>> VirtualThread[#34]/runnable at ForkJoinPool-1-worker-5 >>>> item = 15, Thread ID = Thread[#1,main,5,main] >>>> task = 14, Thread ID = >>>> VirtualThread[#35]/runnable at ForkJoinPool-1-worker-5 >>>> task = 15, Thread ID = >>>> VirtualThread[#42]/runnable at ForkJoinPool-1-worker-11 >>>> Vector(0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15) >>>> >>>> Process finished with exit code 0 >>>> >>> From paul.bjorkstrand at gmail.com Sun Nov 28 00:45:43 2021 From: paul.bjorkstrand at gmail.com (Paul Bjorkstrand) Date: Sat, 27 Nov 2021 18:45:43 -0600 Subject: Interesting example: actor-like model using virtual threads and dynamic proxies Message-ID: Playing with virtual threads today, I wondered how easy it would be to use virtual threads to create an actor-like model, but without sacrificing a simple Java API. Pulling from my memory, I thought "hey, why not dynamic proxies?" It went smoothly, up until I started trying to have one actor call another actor. When having one actor call _itself_, but not using "this", it deadlocked. It was a little tricky to understand what was going on at first. Once I found what the issue was, it made a lot of sense why it occurred. I was able to fix it and get it working, and here is the result, in a gist: https://gist.github.com/paul-bjorkstrand/8854b1346df290a60ba767977aeaf6e2 This gives me hope that creating actor models will not require a more cumbersome message passing model. I think this will make creating actor systems appealing, at least to people like me :-). I remember attempting something like this using thread pools before, and ran into the same deadlocking issue. At that time, I did not find a solution, and abandoned the effort. With virtual threads, since they _are_ threads, I was able to do a simple == test to bypass the scheduling (no need to schedule on the actor's thread if we are already on the actor's thread). While this is not a perfect implementation, it was a lot of fun to build and troubleshoot. -Paul From paul.bjorkstrand at gmail.com Sun Nov 28 01:19:31 2021 From: paul.bjorkstrand at gmail.com (Paul Bjorkstrand) Date: Sat, 27 Nov 2021 19:19:31 -0600 Subject: Loom on Scala In-Reply-To: References: Message-ID: > > > 1. Java Collections need non-lazy monadic operators in addition to > Stream. > The vast majority of Java developers I have worked with that understand streams, also understand that they are lazy, and require a terminal operation. There may be some places where you could simplify some code with non-lazy operations, but every non-lazy operation is just a lazy operation that has an immediate terminal operation. > - Even in Java, join() should not be necessary because it is possible to > wait for all Futures to be complete by other means. > - Indeed, close() should be able to detect if all tasks have > completed, even if join() has not been called. > - It is reasonable to expect StructuredExecutor#close to implicitly > join() if necessary, > - and throw an exception when appropriate, even if this requires > wrapping try-with-resources with another try to catch the > closing exception. > - yes, this would be really ugly, but we have trade-offs on where > ugly and beautiful present themselves > Exceptions thrown by .close() are already handled by the catch block(s) attached to the try-with-resources. There is no need for nesting. Example: class Main { public static void main(String args[]) { try (var twc = new ThrowsWhenClosed()) { // Do nothing } catch (Exception e) { System.out.println(e.getMessage()); } } } class ThrowsWhenClosed implements AutoCloseable { public void close() throws Exception { throw new Exception("Always throws"); } } This outputs "Always throws" to stdout when run. > - Yes, calling join() before close() is an extremely good practice for > many reasons, but it's not always semantically necessary. > - Is calling join() before close() a seatbelt where Loom is trying to > protect us from ourselves? > - Is it too much work to implement this otherwise? > - Is there some hard-core technical reason why this is necessary? I could see this being useful to have close() call join, in addition to it calling shutdown(), but shutdown() currently cancels futures and interrupts threads ( https://github.com/openjdk/loom/blob/70b2a4f3723379ba7e36115651b2b18bd7acee5d/src/java.base/share/classes/java/util/concurrent/StructuredExecutor.java#L557 ) I could see an additional parameter flag for StructuredExecutor.open() which changes the shutdown implementation from the default "interrupt" to "wait" aka join. -Paul From eric at kolotyluk.net Sun Nov 28 04:08:41 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Sat, 27 Nov 2021 20:08:41 -0800 Subject: Loom on Scala In-Reply-To: References: Message-ID: @Paul Bjorkstrand The vast majority of Java developers I have worked with that understand > streams, also understand that they are lazy, and require a terminal > operation. > In a polyglot world, where people are using multiple languages, expecting people to always be an expert on all idioms is asking a lot. I am advocating designs and idioms that are safer and more intuitive in the big picture. Also, I can see the utility in not having to *always *having to use lazy evaluation. WRT Koltin and Scala, Java is the oddball here. Exceptions thrown by .close() are already handled by the catch block(s) > attached to the try-with-resources. > Ah, right, I remember now encountering that scenario. Somehow I thought the close() was done in the finally, but it's done before, so catchable. Thanks for the correction. I could see this being useful to have close() call join, in addition to it > calling shutdown() > I don't think close() needs to call shutdown(), it just needs to detect if all tasks have been completed, and call join() if they have not. Even better, join() should be idempotent (and may be already). If people want to shutdown(), it should be explicit. I could see an additional parameter flag for StructuredExecutor.open() > which changes the shutdown implementation from the default "interrupt" to > "wait" aka join. > Sorry, I don't really see the utility in that. My preferred solution is to use something like structuredExecutor.joinUntil(Instant.now().plusSeconds(10)); catch the TimeoutException, and then call shutdown(). Unfortunately, that won't work because the variable structuredExecutor is out of scope in the catch. That's another Java pet peeve of mine. Maybe something like structuredExector.joinUntil(Instant.now().plusSeconds(10)).then( () -> { structuredExector.shutdown(); structuredExector.join(); } ) But now I am really just fantasizing. Cheers, Eric On Sat, Nov 27, 2021 at 5:20 PM Paul Bjorkstrand wrote: > >> 1. Java Collections need non-lazy monadic operators in addition to >> Stream. >> > > The vast majority of Java developers I have worked with that understand > streams, also understand that they are lazy, and require a terminal > operation. There may be some places where you could simplify some code with > non-lazy operations, but every non-lazy operation is just a lazy operation > that has an immediate terminal operation. > > >> - Even in Java, join() should not be necessary because it is possible >> to >> wait for all Futures to be complete by other means. >> - Indeed, close() should be able to detect if all tasks have >> completed, even if join() has not been called. >> - It is reasonable to expect StructuredExecutor#close to implicitly >> join() if necessary, >> - and throw an exception when appropriate, even if this requires >> wrapping try-with-resources with another try to catch the >> closing exception. >> - yes, this would be really ugly, but we have trade-offs on where >> ugly and beautiful present themselves >> > > Exceptions thrown by .close() are already handled by the catch block(s) > attached to the try-with-resources. There is no need for nesting. Example: > > class Main { > public static void main(String args[]) { > try (var twc = new ThrowsWhenClosed()) { > // Do nothing > } catch (Exception e) { > System.out.println(e.getMessage()); > } > } > } > > class ThrowsWhenClosed implements AutoCloseable { > public void close() throws Exception { > throw new Exception("Always throws"); > } > } > > This outputs "Always throws" to stdout when run. > > >> - Yes, calling join() before close() is an extremely good practice for >> many reasons, but it's not always semantically necessary. >> - Is calling join() before close() a seatbelt where Loom is trying to >> protect us from ourselves? >> - Is it too much work to implement this otherwise? >> - Is there some hard-core technical reason why this is necessary? > > > I could see this being useful to have close() call join, in addition to it > calling shutdown(), but shutdown() currently cancels futures and interrupts > threads ( > https://github.com/openjdk/loom/blob/70b2a4f3723379ba7e36115651b2b18bd7acee5d/src/java.base/share/classes/java/util/concurrent/StructuredExecutor.java#L557 > ) > > I could see an additional parameter flag for StructuredExecutor.open() > which changes the shutdown implementation from the default "interrupt" to > "wait" aka join. > > > -Paul > From paul.bjorkstrand at gmail.com Sun Nov 28 06:29:09 2021 From: paul.bjorkstrand at gmail.com (Paul Bjorkstrand) Date: Sun, 28 Nov 2021 00:29:09 -0600 Subject: Loom on Scala In-Reply-To: References: Message-ID: On Sat, Nov 27, 2021 at 10:08 PM Eric Kolotyluk wrote: > @Paul Bjorkstrand > > The vast majority of Java developers I have worked with that understand >> streams, also understand that they are lazy, and require a terminal >> operation. >> > > In a polyglot world, where people are using multiple languages, expecting > people to always be an expert on all idioms is asking a lot. I am > advocating designs and idioms that are safer and more intuitive in the big > picture. Also, I can see the utility in not having to *always *having to > use lazy evaluation. WRT Koltin and Scala, Java is the oddball here. > I understand that different languages have different features. One could argue that eagerly evaluated "stream-like" operations on collections is just as dangerous. Let's put this conversation to the side, though. It is not very pertinent to this list. (Happy to chat about it on the side, and hear your POV. I have limited Kotlin and zero Scala experience.) > Exceptions thrown by .close() are already handled by the catch block(s) >> attached to the try-with-resources. >> > > Ah, right, I remember now encountering that scenario. Somehow I thought > the close() was done in the finally, but it's done before, so catchable. > Thanks for the correction. > Happy to help! Also, I am thankful I never have to write this kind of code ever again, in Java: try { CloseableThing ct = ... try { ... use ct ... } finally { ct.close(); } } catch (SomeException e) { ... handle ... } > I could see this being useful to have close() call join, in addition to it >> calling shutdown() >> > > I don't think close() needs to call shutdown(), it just needs to detect if > all tasks have been completed, and call join() if they have not. Even > better, join() should be idempotent (and may be already). If people want to > shutdown(), it should be explicit. > It already does call shutdown (well, implShutdown(), but both shutdown() and close() call that method). I think the point of calling shutdown() (or its internal equivalent) in close() is to ensure the executor is entirely done being used once the scope of the try-with-resources is exited. I hope a loom dev can either confirm this or correct me if I am wrong here. As for idempotency of join(), it is not. The join() call depends on if there are any currently executing any tasks created by .fork(). From what I have read, it is perfectly valid to call fork() a bunch of times, call join() to sync them, then call fork(), then call join(), then fork(), then join()... ad infinitum, until either shutdown() or close() are called. A quick test has validated this understanding. > I could see an additional parameter flag for StructuredExecutor.open() >> which changes the shutdown implementation from the default "interrupt" to >> "wait" aka join. >> > > Sorry, I don't really see the utility in that. My preferred solution is to > use something like > Apologies if this caused any confusion, but I meant "close implementation" above instead of "shutdown implementation". The flag would merely say "call join() before you call shutdown() in close()". That way, for the simplest cases, you can omit the join() entirely. I suspect those types of use cases are not as useful, even though I recently made a case for something similar. > structuredExecutor.joinUntil(Instant.now().plusSeconds(10)); > > catch the TimeoutException, and then call shutdown(). Unfortunately, that > won't work because the variable structuredExecutor is out of scope in the > catch. That's another Java pet peeve of mine. > The problem is more than the fact that the variable is out of scope (more on that below). The biggest problem you will encounter is that the executor is *already closed* by the time the catch block is executed. At that point, there is nothing left you really can do with the executor. It is just garbage waiting to be collected. That was part of the point of try-with-resources in the first place - you don't need a reference to the closable objects inside catch anymore because they are already closed and effectively useless. But, if you really want to access a try-with-resources object outside the try... class Main { public static void main(String args[]) { AC ac = new AC(); // as long as the variable inside try-with-resources is effectively final, it can be used try (ac) { } catch (Exception e) { ac.debug(); } } static class AC implements AutoCloseable { public void close() throws Exception { throw new Exception(); } public void debug() { System.out.println("Called from catch"); } } } Using an object meant for try-with-resources outside the try-block is a pretty big red flag, IMO. > Maybe something like > > structuredExector.joinUntil(Instant.now().plusSeconds(10)).then( () -> { > structuredExector.shutdown(); structuredExector.join(); } ) > > But now I am really just fantasizing. > I don't see the point of calling join() after a shutdown(), because shutdown interrupts the other threads. Also, join() just returns if the executor is already shutdown (and throws if it is closed). Besides, since shutdown() is called in the close(), which try-with-resources calls right after the try-block has exited, there is no need to call it explicitly, unless you want to shut down early. > Cheers, Eric > > On Sat, Nov 27, 2021 at 5:20 PM Paul Bjorkstrand < > paul.bjorkstrand at gmail.com> wrote: > >> >>> 1. Java Collections need non-lazy monadic operators in addition to >>> Stream. >>> >> >> The vast majority of Java developers I have worked with that understand >> streams, also understand that they are lazy, and require a terminal >> operation. There may be some places where you could simplify some code with >> non-lazy operations, but every non-lazy operation is just a lazy operation >> that has an immediate terminal operation. >> >> >>> - Even in Java, join() should not be necessary because it is possible >>> to >>> wait for all Futures to be complete by other means. >>> - Indeed, close() should be able to detect if all tasks have >>> completed, even if join() has not been called. >>> - It is reasonable to expect StructuredExecutor#close to implicitly >>> join() if necessary, >>> - and throw an exception when appropriate, even if this requires >>> wrapping try-with-resources with another try to catch the >>> closing exception. >>> - yes, this would be really ugly, but we have trade-offs on where >>> ugly and beautiful present themselves >>> >> >> Exceptions thrown by .close() are already handled by the catch block(s) >> attached to the try-with-resources. There is no need for nesting. Example: >> >> class Main { >> public static void main(String args[]) { >> try (var twc = new ThrowsWhenClosed()) { >> // Do nothing >> } catch (Exception e) { >> System.out.println(e.getMessage()); >> } >> } >> } >> >> class ThrowsWhenClosed implements AutoCloseable { >> public void close() throws Exception { >> throw new Exception("Always throws"); >> } >> } >> >> This outputs "Always throws" to stdout when run. >> >> >>> - Yes, calling join() before close() is an extremely good practice for >>> many reasons, but it's not always semantically necessary. >>> - Is calling join() before close() a seatbelt where Loom is trying to >>> protect us from ourselves? >>> - Is it too much work to implement this otherwise? >>> - Is there some hard-core technical reason why this is necessary? >> >> >> I could see this being useful to have close() call join, in addition to >> it calling shutdown(), but shutdown() currently cancels futures and >> interrupts threads ( >> https://github.com/openjdk/loom/blob/70b2a4f3723379ba7e36115651b2b18bd7acee5d/src/java.base/share/classes/java/util/concurrent/StructuredExecutor.java#L557 >> ) >> >> I could see an additional parameter flag for StructuredExecutor.open() >> which changes the shutdown implementation from the default "interrupt" to >> "wait" aka join. >> >> >> -Paul >> > From Alan.Bateman at oracle.com Sun Nov 28 09:14:27 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 28 Nov 2021 09:14:27 +0000 Subject: Loom on Scala In-Reply-To: References: Message-ID: <6a91e583-fa4a-bdab-77b3-f1bbe16c3e32@oracle.com> On 28/11/2021 01:19, Paul Bjorkstrand wrote: > : > I could see an additional parameter flag for StructuredExecutor.open() > which changes the shutdown implementation from the default "interrupt" to > "wait" aka join. I suspect you mean "close" rather than "shutdown" here. Having shutdown wait would be very deadlock prone (a task would be waiting on itself and/or several tasks calling shutdown would deadlock waiting on each other). We've avoided having a configurable parameter to change the close behavior. The behavior in the current prototype (where close is specified to shutdown) is more useful for cases where there is an exception in the block and you fall into the close. It avoids having close waiting indefinitely for tasks that you are no longer interested in. -Alan From eric at kolotyluk.net Sun Nov 28 14:50:42 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Sun, 28 Nov 2021 06:50:42 -0800 Subject: Loom on Scala In-Reply-To: <6a91e583-fa4a-bdab-77b3-f1bbe16c3e32@oracle.com> References: <6a91e583-fa4a-bdab-77b3-f1bbe16c3e32@oracle.com> Message-ID: @Alan Bateman I noticed that StructuredExecutor has a shutdown() while newThreadPerTaskExectutor() has both shutdown() and shutdownNow()... Also, shutdown() on StructuredExecutor is very different...* it is much more useful.* The documentation for shutdown() is not clear to me in that, if shutdown() prepares for join(), in that join() will then return immediately without waiting, do we still need to call join() before close()? For example try { structuredExecutor.joinUntil(Instant.now().plusSeconds(10)); } catch (TimeoutException e) { structuredExecutor.shutdown(); structuredExecutor.join(); } Why do I still need to call join() a second time? As an aside, it is concerning me that StructuredExecutor is so very different than all the other Executors... and that it disrupts my sense of intuition. StructuredExecutor is clearly better, but it's also disruptive. Rather than the above try/catch, I would rather write something like structuredExecutor .joinUntil(Instant.now().plusSeconds(10), () -> structuredExecutor.shutdown() ); Cheers, Eric On Sun, Nov 28, 2021 at 1:15 AM Alan Bateman wrote: > On 28/11/2021 01:19, Paul Bjorkstrand wrote: > > : > > I could see an additional parameter flag for StructuredExecutor.open() > > which changes the shutdown implementation from the default "interrupt" to > > "wait" aka join. > I suspect you mean "close" rather than "shutdown" here. Having shutdown > wait would be very deadlock prone (a task would be waiting on itself > and/or several tasks calling shutdown would deadlock waiting on each > other). > > We've avoided having a configurable parameter to change the close > behavior. The behavior in the current prototype (where close is > specified to shutdown) is more useful for cases where there is an > exception in the block and you fall into the close. It avoids having > close waiting indefinitely for tasks that you are no longer interested in. > > -Alan > From eric at kolotyluk.net Sun Nov 28 15:21:07 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Sun, 28 Nov 2021 07:21:07 -0800 Subject: Using --enable-preview with IntelliJ Message-ID: I finally found the secret to getting IntelliJ IDEA to use --enable-preview on compile [image: image.png] It is not sufficient to put --enable-preview in "Additional command line parameters" it is necessary to add it to *each *of the "Override compiler parameters per-module" settings. I can now run my Loom code, *and code fragments*, directly from IntelliJ IDEA, ?? rather than building an uber jar in Maven, then running the jar. This requires editing the pom.xml each time the main entry point changes... ?? Cheers, Eric From eric at kolotyluk.net Sun Nov 28 15:40:24 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Sun, 28 Nov 2021 07:40:24 -0800 Subject: AWS Lambda Thought Experiment Message-ID: One of the problems with AWS Lambdas is that when the 'serverless' Lambda is entered, AWS starts metering its duration.* Even if the Lambda code is waiting for other operations, the meter is running...* One of the nice patterns in Project Loom StructuredExecutor is StructuredExecutor.ShutdownOnSuccess() where you can complete on the first successful result... So, in the AWS Lambda running with Loom, let's say we need a result, but we know the same result is available from multiple sources, such as different Availability Zones... If we fork() tasks for each API source, and then cancel all the other tasks waiting for the same result, we might reduce our metered wait time (rounded to the nearest ms), and lower our running costs. This could be tested in experimentation, but I wanted to see if my reasoning is sound before investing in such an experiment. One problem with this strategy is that there could be additional costs in running parallel API requests? Cheers, Eric As an aside, I once ran an Akka Node in an AWS Lambda and was surprised to find that when the Lambda was re-entered, the Akka Node still had its state from before and that within the node, multi-threading worked fine. I was going to experiment further to see if background work could still be done outside the AWS metered duration but never got around to testing it. From Alan.Bateman at oracle.com Sun Nov 28 16:01:44 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 28 Nov 2021 16:01:44 +0000 Subject: Loom on Scala In-Reply-To: References: Message-ID: On 27/11/2021 23:12, Eric Kolotyluk wrote: > : > > > - This is a perfectly valid expression of logic because > furtureResults.map(_.get) will wait/block until all the Futures have been > completed, which implicitly is the same as a join(). > - Project Loom is an extension of the JVM and libraries, not the Java > Language. Other language users, such as Scala, should not be penalized by > having to use join() when it is not semantically necessary. > - Even in Java, join() should not be necessary because it is possible to > wait for all Futures to be complete by other means. > - Indeed, close() should be able to detect if all tasks have > completed, even if join() has not been called. > - It is reasonable to expect StructuredExecutor#close to implicitly > join() if necessary, > - and throw an exception when appropriate, even if this requires > wrapping try-with-resources with another try to catch the > closing exception. > - yes, this would be really ugly, but we have trade-offs on where > ugly and beautiful present themselves > - In some cases, it's really important/useful to call join, such as > dealing with any completion failures, but there are other mechanisms to > catch those failures. > > My sense is that requiring join() before close() is a kluge, and I invite > someone to convince me otherwise. I am not trying to insult anyone, just > convey an emotion, and I am willing to be convinced otherwise. > > - Yes, calling join() before close() is an extremely good practice for > many reasons, but it's not always semantically necessary. > - Is calling join() before close() a seatbelt where Loom is trying to > protect us from ourselves? > - Is it too much work to implement this otherwise? > - Is there some hard-core technical reason why this is necessary? The intention (and we tried to make this clear in the javadoc) is that the check to ensure join is called is to help guide developers to use the API as intended. You are correct that if you do your own bookkeeping then you could invoke Future::get for every task. That would be O(n) wait/wakeups and more complex once you you have to deal with tasks that fail. -Alan From Alan.Bateman at oracle.com Sun Nov 28 16:05:23 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 28 Nov 2021 16:05:23 +0000 Subject: Loom on Scala In-Reply-To: References: <6a91e583-fa4a-bdab-77b3-f1bbe16c3e32@oracle.com> Message-ID: On 28/11/2021 14:50, Eric Kolotyluk wrote: > @Alan Bateman > I noticed that StructuredExecutor has a shutdown() while > newThreadPerTaskExectutor() has both shutdown() and shutdownNow()... > > Also, shutdown() on StructuredExecutor is very different...*/it is > much more useful./* ExecutorService has a different life cycle, we've already been down the road of having a structured-ES. > > The documentation for shutdown() > > is not clear to me in that, if shutdown() prepares for join(), in that > join() will then return immediately without waiting, do we still need > to call join() before close()? For example > try { > structuredExecutor.joinUntil(Instant.now().plusSeconds(10)); } > catch (TimeoutException e) {structuredExecutor.shutdown(); structuredExecutor.join(); } > Why do I still need to call join() a second time? You don't, it would be a no-op as the executor is shutdown. -Alan From Alan.Bateman at oracle.com Sun Nov 28 16:13:24 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 28 Nov 2021 16:13:24 +0000 Subject: AWS Lambda Thought Experiment In-Reply-To: References: Message-ID: On 28/11/2021 15:40, Eric Kolotyluk wrote: > : > > If we fork() tasks for each API source, and then cancel all the other tasks > waiting for the same result, we might reduce our metered wait time (rounded > to the nearest ms), and lower our running costs. > > This could be tested in experimentation, but I wanted to see if my > reasoning is sound before investing in such an experiment. > If you have the environment to test it then it could be an interesting experiment. I think the main thing to establish is whether the library/API that you use to request the result in the different availability zones can be cancelled via thread interrupt. -Alan From duke at openjdk.java.net Sun Nov 28 16:15:24 2021 From: duke at openjdk.java.net (duke) Date: Sun, 28 Nov 2021 16:15:24 GMT Subject: git: openjdk/loom: fibers: 6 new changesets Message-ID: Changeset: de55e82e Author: Alan Bateman Date: 2021-11-25 09:22:39 +0000 URL: https://git.openjdk.java.net/loom/commit/de55e82e094c8c2d96ef86fdc0146df6e301c08f More javadoc improvements ! src/java.base/share/classes/java/util/concurrent/StructuredExecutor.java Changeset: 9bdd1e77 Author: Alan Bateman Date: 2021-11-25 09:55:20 +0000 URL: https://git.openjdk.java.net/loom/commit/9bdd1e7715447ffc9491e76b9bbc45300bd685d9 Add example to javadoc ! src/java.base/share/classes/java/util/concurrent/StructuredExecutor.java Changeset: d76ab700 Author: Alan Bateman Date: 2021-11-25 19:05:05 +0000 URL: https://git.openjdk.java.net/loom/commit/d76ab70040c112348d4698e6164527e7e7396ff9 Move shared test class to lib ! test/jdk/java/util/concurrent/ExecutorService/CloseTest.java ! test/jdk/java/util/concurrent/Future/DefaultMethods.java = test/jdk/java/util/concurrent/lib/DelegatingExecutorService.java Changeset: 40d13391 Author: Alan Bateman Date: 2021-11-26 09:51:55 +0000 URL: https://git.openjdk.java.net/loom/commit/40d133915acd94d6296ee39dc9084b58ac44c1c5 externalSubmit need only check current thread ! src/java.base/share/classes/java/lang/VirtualThread.java ! src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java Changeset: 4cba3a19 Author: Alan Bateman Date: 2021-11-26 17:40:54 +0000 URL: https://git.openjdk.java.net/loom/commit/4cba3a19fad97b3ae5cf4304501bc879e2c9b1c4 Convert examples to snippets ! src/java.base/share/classes/java/util/concurrent/StructuredExecutor.java Changeset: 1f8b7fcc Author: Alan Bateman Date: 2021-11-28 08:45:26 +0000 URL: https://git.openjdk.java.net/loom/commit/1f8b7fcc4505028fe534e8b318198281b96e118c Convert more examples to inline snippets ! src/java.base/share/classes/java/lang/Thread.java ! src/java.base/share/classes/java/util/concurrent/StructuredExecutor.java From eric at kolotyluk.net Sun Nov 28 16:56:20 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Sun, 28 Nov 2021 08:56:20 -0800 Subject: Loom on Scala In-Reply-To: References: <6a91e583-fa4a-bdab-77b3-f1bbe16c3e32@oracle.com> Message-ID: @Alan Bateman Yes, I am being pedantic about ExecutorService(s)... perhaps overly pedantic... Thanks for confirming that join() is idempotent. It would be nice to state that clearly in the documentation. try { structuredExecutor.joinUntil(Instant.now().plusSeconds(10));}catch (TimeoutException e) { structuredExecutor.shutdown(); // after this returns, the join() has completed} It would also be nice to document the above example to make this clear. I love documentation with examples, as a picture is worth a thousand words... Cheers, Eric On Sun, Nov 28, 2021 at 8:05 AM Alan Bateman wrote: > On 28/11/2021 14:50, Eric Kolotyluk wrote: > > @Alan Bateman > > I noticed that StructuredExecutor has a shutdown() while > newThreadPerTaskExectutor() has both shutdown() and shutdownNow()... > > Also, shutdown() on StructuredExecutor is very different...* it is much > more useful.* > > > ExecutorService has a different life cycle, we've already been down the > road of having a structured-ES. > > > The documentation for shutdown() > > is not clear to me in that, if shutdown() prepares for join(), in that > join() will then return immediately without waiting, do we still need to > call join() before close()? For example > > try { > structuredExecutor.joinUntil(Instant.now().plusSeconds(10));}catch (TimeoutException e) { structuredExecutor.shutdown(); structuredExecutor.join();} > > Why do I still need to call join() a second time? > > You don't, it would be a no-op as the executor is shutdown. > > -Alan > From eric at kolotyluk.net Sun Nov 28 19:19:20 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Sun, 28 Nov 2021 11:19:20 -0800 Subject: StructuredExecutor Incompatible with HttpClient? Message-ID: package net.kolotyluk.loom; import java.net.http.HttpResponse; import java.time.Duration; import java.time.Instant; import java.util.concurrent.*; import java.util.stream.Collectors; import java.util.stream.IntStream; import java.net.http.HttpClient; import java.net.http.HttpRequest; import java.net.URI; public class Experiment20_HttpClient { public static void main2(String args[]) { Context.printHeader(Experiment20_HttpClient.class); var virtualThreadFactory = Thread.ofVirtual().factory(); try (var executorService = Executors.newThreadPerTaskExecutor(virtualThreadFactory)) { // https://apipheny.io/free-api/ var client = HttpClient.newBuilder() .executor(executorService) .connectTimeout(Duration.ofSeconds(10)) .build(); var request = HttpRequest.newBuilder() .uri(URI.create("https://www.boredapi.com/api/activity")) .build(); Callable getActivity = () -> { var response = client.sendAsync(request, HttpResponse.BodyHandlers.ofString()) .thenApply(HttpResponse::body) .join(); System.out.printf("early result = %s\n", response); return response; }; var result1 = executorService.submit(getActivity); System.out.printf("result1 = %s", result1.get()); } catch (ExecutionException e) { e.printStackTrace(); } catch (InterruptedException e) { e.printStackTrace(); } } public static void main(String args[]) { Context.printHeader(Experiment20_HttpClient.class); try (var structuredExecutor = StructuredExecutor.open("Experiment20")) { // https://apipheny.io/free-api/ var client = HttpClient.newBuilder() .executor(structuredExecutor) .connectTimeout(Duration.ofSeconds(10)) .build(); var request = HttpRequest.newBuilder() .uri(URI.create("https://www.boredapi.com/api/activity")) .build(); Callable getActivity = () -> { var response = client.sendAsync(request, HttpResponse.BodyHandlers.ofString()) .thenApply(HttpResponse::body) .join(); System.out.printf("early result = %s\n", response); return response; }; var result1 = structuredExecutor.fork(getActivity); try { structuredExecutor.joinUntil(Instant.now().plusSeconds(10)); } catch (TimeoutException e) { System.out.println("TimeoutException"); structuredExecutor.shutdown(); // structuredExecutor.join(); System.out.printf("result = %s", result1.resultNow()); } System.out.printf("result1 = %s", result1.get()); } catch (ExecutionException e) { e.printStackTrace(); } catch (InterruptedException e) { e.printStackTrace(); } } } So, main2 seems to work as expected, but main does not Hello net.kolotyluk.loom.Experiment20_HttpClient PID = 35712 CPU Cores = 12 Heap Size = 6442450944 bytes ______________________________________________________________________________ TimeoutException Process finished with exit code 130 It hangs indefinitely after TimeoutException, and I have to manually kill it. The correct output should be Hello net.kolotyluk.loom.Experiment20_HttpClient PID = 3480 CPU Cores = 12 Heap Size = 6442450944 bytes ______________________________________________________________________________ early result = {"activity":"Clean out your closet and donate the clothes you've outgrown","type":"charity","participants":1,"price":0,"link":"","key":"9026787","accessibility":0.1} result1 = {"activity":"Clean out your closet and donate the clothes you've outgrown","type":"charity","participants":1,"price":0,"link":"","key":"9026787","accessibility":0.1} Process finished with exit code 0 Cheers, Eric From Alan.Bateman at oracle.com Sun Nov 28 19:55:02 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 28 Nov 2021 19:55:02 +0000 Subject: StructuredExecutor Incompatible with HttpClient? In-Reply-To: References: Message-ID: On 28/11/2021 19:19, Eric Kolotyluk wrote: > So, main2 seems to work as expected, but main does not > > Hello net.kolotyluk.loom.Experiment20_HttpClient > PID = 35712 > CPU Cores = 12 > Heap Size = 6442450944 bytes > ______________________________________________________________________________ > > TimeoutException > > Process finished with exit code 130 > > It hangs indefinitely after TimeoutException, and I have to manually kill > it. The correct output should be > > Hello net.kolotyluk.loom.Experiment20_HttpClient > PID = 3480 > CPU Cores = 12 > Heap Size = 6442450944 bytes > ______________________________________________________________________________ > > early result = {"activity":"Clean out your closet and donate the clothes > you've > outgrown","type":"charity","participants":1,"price":0,"link":"","key":"9026787","accessibility":0.1} > result1 = {"activity":"Clean out your closet and donate the clothes you've > outgrown","type":"charity","participants":1,"price":0,"link":"","key":"9026787","accessibility":0.1} > Process finished with exit code 0 I see the the examples are using the HTTP client in async mode and using the HttpClient.Builder to set the executor for async and dependent tasks. I assume the HTTP client's "selector manager" is trying to submit tasks via the execute method but they are being rejected because the "selector manager" is outside the structure. I need to lookup how to turn on logging on but I'll bet that is what is going on. So yes, a good find that it's not suitable for this usage as it's not an Executor implementation that anyone can ask to execute tasks. Can you try the HTTP client in synchronous mode? That is what we have been testing. There was one issue with interruption that was mostly resolved in Java 16. Using the HTTP client in async mode, without overriding the executor for the HTTP client to use, should be okay too. -Alan. From eric at kolotyluk.net Sun Nov 28 21:17:30 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Sun, 28 Nov 2021 13:17:30 -0800 Subject: StructuredExecutor Incompatible with HttpClient? In-Reply-To: References: Message-ID: Changing the code to Callable getActivity = () -> { // var response = client.sendAsync(request, HttpResponse.BodyHandlers.ofString()) // .thenApply(HttpResponse::body) // .join(); var response = client.send(request, HttpResponse.BodyHandlers.ofString()).body(); System.out.printf("early result = %s\n", response); return response; }; changes the result to ______________________________________________________________________________ TimeoutException Exception in thread "main" java.lang.IllegalStateException: Task was cancelled at java.base/java.util.concurrent.FutureTask.resultNow(FutureTask.java:218) at java.base/java.util.concurrent.StructuredExecutor$FutureImpl.resultNow(StructuredExecutor.java:726) at net.kolotyluk.loom.Experiment20_HttpClient.main(Experiment20_HttpClient.java:90) Process finished with exit code 1 where line 90 is System.out.printf("result = %s", result1.resultNow()); Cheers, Eric On Sun, Nov 28, 2021 at 11:55 AM Alan Bateman wrote: > On 28/11/2021 19:19, Eric Kolotyluk wrote: > > So, main2 seems to work as expected, but main does not > > > > Hello net.kolotyluk.loom.Experiment20_HttpClient > > PID = 35712 > > CPU Cores = 12 > > Heap Size = 6442450944 bytes > > > ______________________________________________________________________________ > > > > TimeoutException > > > > Process finished with exit code 130 > > > > It hangs indefinitely after TimeoutException, and I have to manually kill > > it. The correct output should be > > > > Hello net.kolotyluk.loom.Experiment20_HttpClient > > PID = 3480 > > CPU Cores = 12 > > Heap Size = 6442450944 bytes > > > ______________________________________________________________________________ > > > > early result = {"activity":"Clean out your closet and donate the clothes > > you've > > > outgrown","type":"charity","participants":1,"price":0,"link":"","key":"9026787","accessibility":0.1} > > result1 = {"activity":"Clean out your closet and donate the clothes > you've > > > outgrown","type":"charity","participants":1,"price":0,"link":"","key":"9026787","accessibility":0.1} > > Process finished with exit code 0 > I see the the examples are using the HTTP client in async mode and using > the HttpClient.Builder to set the executor for async and dependent > tasks. I assume the HTTP client's "selector manager" is trying to submit > tasks via the execute method but they are being rejected because the > "selector manager" is outside the structure. I need to lookup how to > turn on logging on but I'll bet that is what is going on. So yes, a good > find that it's not suitable for this usage as it's not an Executor > implementation that anyone can ask to execute tasks. > > Can you try the HTTP client in synchronous mode? That is what we have > been testing. There was one issue with interruption that was mostly > resolved in Java 16. Using the HTTP client in async mode, without > overriding the executor for the HTTP client to use, should be okay too. > > -Alan. > From eric at kolotyluk.net Mon Nov 29 01:22:05 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Sun, 28 Nov 2021 17:22:05 -0800 Subject: loom-lab Message-ID: I have pushed the latest results of what I have learned to GitHub , in particular the Experiment01_Overview javadoc and the code . This is a really fun personal project for me, which is forcing me to understand Project Loom concepts and practices better, and I hope it will be useful to others someday. I really look forward to experimenting more with java.net.http.HttpClient, which works fine with Executors.newThreadPerTaskExecutor(virtualTheadFactory), but not with StructuredExecutor. However, I need StructuredExecutor so I can design the kind of experiments I really want to play with. Again, many thanks to all the excellent dialog I have found here. Cheers, Eric From Alan.Bateman at oracle.com Mon Nov 29 08:08:17 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 29 Nov 2021 08:08:17 +0000 Subject: StructuredExecutor Incompatible with HttpClient? In-Reply-To: References: Message-ID: <861a4e3f-5b25-1af0-bdb5-114cb11a24c3@oracle.com> On 28/11/2021 21:17, Eric Kolotyluk wrote: > : > > TimeoutException > Exception in thread "main" java.lang.IllegalStateException: Task was > cancelled > at > java.base/java.util.concurrent.FutureTask.resultNow(FutureTask.java:218) > at > java.base/java.util.concurrent.StructuredExecutor$FutureImpl.resultNow(StructuredExecutor.java:726) > at > net.kolotyluk.loom.Experiment20_HttpClient.main(Experiment20_HttpClient.java:90) > > Process finished with exit code 1 > So an exception is thrown because the deadline has expired and code in the catch block calls Future::resultNow without checking the status, is that right? I ran your example with -Djdk.httpclient.HttpClient.log=all and it revealed the exception: INFO: ERROR: HttpClient-1-SelectorManager: HttpClientImpl shutting down due to fatal error: java.lang.IllegalStateException: Current thread not owner or thread in flock ??????? at java.base/jdk.internal.misc.ThreadFlock.ensureOwnerOrContainsThread(ThreadFlock.java:204) ??????? at java.base/jdk.internal.misc.ThreadFlock.start(ThreadFlock.java:267) ??????? at java.base/java.util.concurrent.StructuredExecutor.spawn(StructuredExecutor.java:351) ??????? at java.base/java.util.concurrent.StructuredExecutor.execute(StructuredExecutor.java:455) ??????? at java.net.http/jdk.internal.net.http.HttpClientImpl$DelegatingExecutor.execute(HttpClientImpl.java:153) ??????? at java.net.http/jdk.internal.net.http.PlainHttpConnection$ConnectEvent.handle(PlainHttpConnection.java:152) ??????? at java.net.http/jdk.internal.net.http.HttpClientImpl$SelectorManager.handleEvent(HttpClientImpl.java:977) ??????? at java.net.http/jdk.internal.net.http.HttpClientImpl$SelectorManager.lambda$run$3(HttpClientImpl.java:932) ??????? at java.base/java.util.ArrayList.forEach(ArrayList.java:1511) ??????? at java.net.http/jdk.internal.net.http.HttpClientImpl$SelectorManager.run(HttpClientImpl.java:932) A StructuredExecutor may be an Executor but it won't execute tasks from threads that aren't in the tree, which is what is happening here when the HTTP client is used in async mode and configured to use this executor. -Alan. From eric at kolotyluk.net Mon Nov 29 14:50:20 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Mon, 29 Nov 2021 06:50:20 -0800 Subject: StructuredExecutor Incompatible with HttpClient? In-Reply-To: <861a4e3f-5b25-1af0-bdb5-114cb11a24c3@oracle.com> References: <861a4e3f-5b25-1af0-bdb5-114cb11a24c3@oracle.com> Message-ID: @Alan Bateman Thanks for trying my example... 1. Using newThreadPerTaskExecutor() with virtual threads does seem to work fine. - However, it's the StructuredExecutor that I really want to test. 2. Did you also run the case with the synchronous HTTP request? - Earlier you implied this should work, but it also failed for me. 3. Are you saying that StructuredExecutor will never work with the asynchronous HTTP client? - I am building the HTTP client with the StructuredExecutor, so why is the client using threads outside of the tree? Cheers, Eric On Mon, Nov 29, 2021 at 12:08 AM Alan Bateman wrote: > On 28/11/2021 21:17, Eric Kolotyluk wrote: > > : > > TimeoutException > Exception in thread "main" java.lang.IllegalStateException: Task was > cancelled > at java.base/java.util.concurrent.FutureTask.resultNow(FutureTask.java:218) > at > java.base/java.util.concurrent.StructuredExecutor$FutureImpl.resultNow(StructuredExecutor.java:726) > at > net.kolotyluk.loom.Experiment20_HttpClient.main(Experiment20_HttpClient.java:90) > > Process finished with exit code 1 > > So an exception is thrown because the deadline has expired and code in the > catch block calls Future::resultNow without checking the status, is that > right? > > I ran your example with -Djdk.httpclient.HttpClient.log=all and it > revealed the exception: > > INFO: ERROR: HttpClient-1-SelectorManager: HttpClientImpl shutting down > due to fatal error: java.lang.IllegalStateException: Current thread not > owner or thread in flock > at > java.base/jdk.internal.misc.ThreadFlock.ensureOwnerOrContainsThread(ThreadFlock.java:204) > at > java.base/jdk.internal.misc.ThreadFlock.start(ThreadFlock.java:267) > at > java.base/java.util.concurrent.StructuredExecutor.spawn(StructuredExecutor.java:351) > at > java.base/java.util.concurrent.StructuredExecutor.execute(StructuredExecutor.java:455) > at > java.net.http/jdk.internal.net.http.HttpClientImpl$DelegatingExecutor.execute(HttpClientImpl.java:153) > at > java.net.http/jdk.internal.net.http.PlainHttpConnection$ConnectEvent.handle(PlainHttpConnection.java:152) > at > java.net.http/jdk.internal.net.http.HttpClientImpl$SelectorManager.handleEvent(HttpClientImpl.java:977) > at > java.net.http/jdk.internal.net.http.HttpClientImpl$SelectorManager.lambda$run$3(HttpClientImpl.java:932) > at java.base/java.util.ArrayList.forEach(ArrayList.java:1511) > at > java.net.http/jdk.internal.net.http.HttpClientImpl$SelectorManager.run(HttpClientImpl.java:932) > > A StructuredExecutor may be an Executor but it won't execute tasks from > threads that aren't in the tree, which is what is happening here when the > HTTP client is used in async mode and configured to use this executor. > > -Alan. > From Alan.Bateman at oracle.com Mon Nov 29 16:01:04 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 29 Nov 2021 16:01:04 +0000 Subject: StructuredExecutor Incompatible with HttpClient? In-Reply-To: References: <861a4e3f-5b25-1af0-bdb5-114cb11a24c3@oracle.com> Message-ID: <47943c71-615e-6799-6ea0-89873d25a696@oracle.com> On 29/11/2021 14:50, Eric Kolotyluk wrote: > @Alan Bateman > Thanks for trying my example... > > 1. Using newThreadPerTaskExecutor() with virtual threads does seem to > work fine. > * However, it's the StructuredExecutor that I really want to test. > 2. Did you also run the case with the synchronous HTTP request? > * Earlier you implied this should work, but it also failed for me. > 3. Are you saying that StructuredExecutor will never work with the > asynchronous HTTP client? > * I am building the HTTP client with the StructuredExecutor, so > why is the client using threads outside of the tree? > In your example, you specify the executor for async and dependent tasks to the HttpClient.Builder. If you drop that one line then I would expect both the async and synchronous usages of the API will just work. The synchronous form replaces the sendAsync + thenApply(body) + join with send + body. I don't know how common it is to using a custom executor here but it does need to examined. It might be that the per-HttpClient "Selector Manager" can submitted to the custom executor rather than creating a daemon Thread. -Alan From eric at kolotyluk.net Mon Nov 29 16:23:15 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Mon, 29 Nov 2021 08:23:15 -0800 Subject: StructuredExecutor Incompatible with HttpClient? In-Reply-To: <47943c71-615e-6799-6ea0-89873d25a696@oracle.com> References: <861a4e3f-5b25-1af0-bdb5-114cb11a24c3@oracle.com> <47943c71-615e-6799-6ea0-89873d25a696@oracle.com> Message-ID: Indeed, commenting out var client = HttpClient.newBuilder() //.executor(structuredExecutor) .connectTimeout(Duration.ofSeconds(10)) .build(); Solves the problem, and both sync and async requests work correctly now... thanks. My goal here is to eventually run an experiment with multiple tasks making HTTP requests, and the first one to succeed with a result, should shutdown/cancel the rest of the tasks, including cancelling any HTTP Client Tasks. My ultimate goal is to see if I can lower the the AWS Lambda metered duration by making multiple requests for the same information, hoping some endpoints will have lower latency than others. Again, using newThreadPerTaskExecutor(virtualThreadFactory) seems to work fine with HTTP Client, so there is something different about StructuredExecutor. Is it a goal or non-goal of Project Loom and/or Structured Concurrency to interoperate with HTTP Client? Cheers, Eric On Mon, Nov 29, 2021 at 8:01 AM Alan Bateman wrote: > On 29/11/2021 14:50, Eric Kolotyluk wrote: > > @Alan Bateman > > Thanks for trying my example... > > 1. Using newThreadPerTaskExecutor() with virtual threads does seem to > work fine. > - However, it's the StructuredExecutor that I really want to test. > 2. Did you also run the case with the synchronous HTTP request? > - Earlier you implied this should work, but it also failed for me. > 3. Are you saying that StructuredExecutor will never work with the > asynchronous HTTP client? > - I am building the HTTP client with the StructuredExecutor, so why > is the client using threads outside of the tree? > > > In your example, you specify the executor for async and dependent tasks to > the HttpClient.Builder. If you drop that one line then I would expect both > the async and synchronous usages of the API will just work. The synchronous > form replaces the sendAsync + thenApply(body) + join with send + body. > > I don't know how common it is to using a custom executor here but it does > need to examined. It might be that the per-HttpClient "Selector Manager" > can submitted to the custom executor rather than creating a daemon Thread. > > -Alan > > From Alan.Bateman at oracle.com Mon Nov 29 17:57:20 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 29 Nov 2021 17:57:20 +0000 Subject: StructuredExecutor Incompatible with HttpClient? In-Reply-To: References: <861a4e3f-5b25-1af0-bdb5-114cb11a24c3@oracle.com> <47943c71-615e-6799-6ea0-89873d25a696@oracle.com> Message-ID: On 29/11/2021 16:23, Eric Kolotyluk wrote: > : > > Again, using newThreadPerTaskExecutor(virtualThreadFactory) seems to > work fine with HTTP Client, so there is something different about > StructuredExecutor. > > Is it a goal or non-goal of Project Loom and/or Structured Concurrency > to interoperate > with HTTP Client? > We should expect to work, in both async and synchronous forms. The custom executor case will require a change in the HTTP client implementation to ensure that the tasks are submitted from inside, rather than outside, the tree. There are a couple of options for that. For now, just avoid specifying the executor when creating the HTTP client. -Alan. From ron.pressler at oracle.com Tue Nov 30 13:42:00 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Tue, 30 Nov 2021 13:42:00 +0000 Subject: On Parallelism and Concurrency Message-ID: Hi. I?ve published a blog post that I hope will be of assistance to the readers of this mailing list: https://inside.java/2021/11/30/on-parallelism-and-concurrency/ ? Ron From eric at kolotyluk.net Tue Nov 30 15:17:37 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Tue, 30 Nov 2021 07:17:37 -0800 Subject: On Parallelism and Concurrency In-Reply-To: References: Message-ID: > > We could, therefore think of parallelism as the problem of scheduling > resources over space and of concurrency as the problem of scheduling > resources over time. I don?t know if that?s helpful, but it sure sounds > cool. > Yes, it does sound cool... If we think of multiple CPUs and cores as space, then parallelism is definitely scheduling over space... a multi-dimensional space... in a sense, parallelism is multidimensional If we think of a single one-core CPU, (no hyperthreading) as a single dimension, then concurrency is constrained to only schedule resources over time, but in a multidimensional space, it can schedule resources over time in each dimension. Thoughtful article... thanks. I may comment more as I reread a few times to try to grok it. Cheers, Eric On Tue, Nov 30, 2021 at 5:42 AM Ron Pressler wrote: > Hi. > > I?ve published a blog post that I hope will be of assistance to the > readers of this > mailing list: > https://inside.java/2021/11/30/on-parallelism-and-concurrency/ > > ? Ron > > From duke at openjdk.java.net Tue Nov 30 15:33:32 2021 From: duke at openjdk.java.net (duke) Date: Tue, 30 Nov 2021 15:33:32 GMT Subject: git: openjdk/loom: fibers: 13 new changesets Message-ID: <3da0a397-43ce-4893-939d-9ee8ad48cb86@openjdk.java.net> Changeset: dcba1b4e Author: Alan Bateman Date: 2021-11-29 08:54:41 +0000 URL: https://git.openjdk.java.net/loom/commit/dcba1b4e25af920fe01c6f8b30323c2a3fd9db75 Leave deprecation of activeCount/enumerate to main line ! src/java.base/share/classes/java/lang/Thread.java ! src/java.base/share/classes/java/lang/ThreadGroup.java Changeset: e91c1bfc Author: Alan Bateman Date: 2021-11-29 17:33:59 +0000 URL: https://git.openjdk.java.net/loom/commit/e91c1bfc0e35f8c2260c3d3e0875255e02a9b607 Improve check that join has been invoked ! src/java.base/share/classes/java/util/concurrent/StructuredExecutor.java ! test/jdk/java/util/concurrent/StructuredExecutor/StructuredExecutorTest.java Changeset: 47839007 Author: Alan Bateman Date: 2021-11-29 18:20:05 +0000 URL: https://git.openjdk.java.net/loom/commit/4783900780ab5ffc67cc8424622e3892c0118f1e Add javadoc link to example ! src/java.base/share/classes/java/util/concurrent/StructuredExecutor.java Changeset: 752a0649 Author: Alan Bateman Date: 2021-11-29 18:26:22 +0000 URL: https://git.openjdk.java.net/loom/commit/752a0649fc25967c33799a8f22ecad7d35a0de4b Improve @throws description ! src/java.base/share/classes/java/util/concurrent/StructuredExecutor.java Changeset: 61dcef30 Author: Alan Bateman Date: 2021-11-30 06:55:20 +0000 URL: https://git.openjdk.java.net/loom/commit/61dcef30f5e6eda428b9ea6dcee5d2479479ea4f Missing @PreviewFeature ! src/java.base/share/classes/java/lang/StructureViolationException.java Changeset: f9e4ed84 Author: Alan Bateman Date: 2021-11-30 07:00:30 +0000 URL: https://git.openjdk.java.net/loom/commit/f9e4ed84c0f1a553fe7d00dc74f4455b664cf292 execute should only throw REE ! src/java.base/share/classes/java/util/concurrent/StructuredExecutor.java ! test/jdk/java/util/concurrent/StructuredExecutor/StructuredExecutorTest.java Changeset: 6547c42a Author: Alan Bateman Date: 2021-11-30 07:49:44 +0000 URL: https://git.openjdk.java.net/loom/commit/6547c42adfe7fca9276a13ce95ab31bd47962236 Improve javadoc for NPE + src/java.base/share/classes/java/lang/IllegalCallerThreadException.java ! src/java.base/share/classes/java/util/concurrent/StructuredExecutor.java Changeset: ad1027e1 Author: Alan Bateman Date: 2021-11-30 09:42:43 +0000 URL: https://git.openjdk.java.net/loom/commit/ad1027e11d027cf76944bdfbee4007b95ef439bb Improve exceptions ! src/java.base/share/classes/java/lang/IllegalCallerThreadException.java ! src/java.base/share/classes/java/lang/StructureViolationException.java ! src/java.base/share/classes/java/lang/Thread.java ! src/java.base/share/classes/java/lang/VirtualThread.java ! src/java.base/share/classes/java/util/concurrent/StructuredExecutor.java ! src/java.base/share/classes/java/util/concurrent/ThreadPerTaskExecutor.java ! src/java.base/share/classes/jdk/internal/misc/ThreadFlock.java ! test/jdk/java/util/concurrent/StructuredExecutor/StructuredExecutorTest.java ! test/jdk/jdk/internal/misc/ThreadFlock/ThreadFlockTest.java Changeset: 515df331 Author: Alan Bateman Date: 2021-11-30 10:20:22 +0000 URL: https://git.openjdk.java.net/loom/commit/515df331603386360127ccd6e9cbf4656b1e8115 Fix failing test ! test/jdk/java/lang/Thread/virtual/CustomScheduler.java Changeset: 5d2de60a Author: Alan Bateman Date: 2021-11-30 11:00:26 +0000 URL: https://git.openjdk.java.net/loom/commit/5d2de60aa07b35f8312fe888933573c709a8add5 Test that execute throws REE ! test/jdk/java/util/concurrent/StructuredExecutor/StructuredExecutorTest.java Changeset: dae539eb Author: Alan Bateman Date: 2021-11-30 11:58:25 +0000 URL: https://git.openjdk.java.net/loom/commit/dae539eb93299240affbb9918029df0d14dd2338 More test coverage for scope locals ! test/jdk/jdk/internal/misc/ThreadFlock/ThreadFlockTest.java Changeset: 501f6edc Author: Alan Bateman Date: 2021-11-30 15:23:55 +0000 URL: https://git.openjdk.java.net/loom/commit/501f6edc50a607ffc2072ab20a09ce71e00076b1 Rename exception - src/java.base/share/classes/java/lang/IllegalCallerThreadException.java ! src/java.base/share/classes/java/lang/VirtualThread.java + src/java.base/share/classes/java/lang/WrongThreadException.java ! src/java.base/share/classes/java/util/concurrent/StructuredExecutor.java ! src/java.base/share/classes/java/util/concurrent/ThreadPerTaskExecutor.java ! src/java.base/share/classes/jdk/internal/misc/ThreadFlock.java ! test/jdk/java/lang/Thread/virtual/CustomScheduler.java ! test/jdk/java/util/concurrent/StructuredExecutor/StructuredExecutorTest.java ! test/jdk/jdk/internal/misc/ThreadFlock/ThreadFlockTest.java Changeset: 93e59093 Author: Alan Bateman Date: 2021-11-30 15:28:36 +0000 URL: https://git.openjdk.java.net/loom/commit/93e59093fc92d111cade010fd8934041a638b2d7 Exclude unloading_redefinition_inMemoryCompilation_keep_cl/TestDescription.java ! test/hotspot/jtreg/ProblemList.txt From eric at kolotyluk.net Tue Nov 30 16:36:40 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Tue, 30 Nov 2021 08:36:40 -0800 Subject: Concurrency and Exceptions Message-ID: In my documentation I want to make the statement In concurrent frameworks, it was not safe to throw Exceptions because the > JVM could not manage this. > My sense is that Project Loom addresses this and fixes it somewhat, but I don't want to miss-state the problem Loom attempts to solve. *Is it the JVM, or simply the Java Language/Libraries that could not support safe Exception Handling in Concurrent scenarios?* Up until now, this led to a Functional approach of returning composite results, such as Scala Option, Either, Try, etc. to avoid throwing Exceptions. I understand that in Kotlin Coroutines, it is safe to throw/catch exceptions in concurrent code, but I have never really tried this. Cheers, Eric From pedro.lamarao at prodist.com.br Tue Nov 30 19:04:38 2021 From: pedro.lamarao at prodist.com.br (=?UTF-8?Q?Pedro_Lamar=C3=A3o?=) Date: Tue, 30 Nov 2021 16:04:38 -0300 Subject: Generators In-Reply-To: References: Message-ID: Em qua., 24 de nov. de 2021 ?s 12:56, Ron Pressler escreveu: The thread could be any thread ? platform or virtual. But yes, the > construct would have to ensure that all calls are done on the same thread. > Otherwise, we risk miscompilation (the JIT compiler works on the assumption > that the current thread cannot change while executing a method; if it does, > you might get strange results). > After a few experiments, I think this restriction is not difficult to satisfy in a virtual threads architecture. If the application is architected with thread-per-session, the parser instance is easily thread-confined: the parser object may be created and bound to the Runnable::run method stack, maybe even to a try-with-resources. If I understood the restriction correctly, it is satisfied if the (Continuation inside the) Generator is always activated in the same virtual thread. I have put a few days into an HTTP parser and integrated it into a dumb HTTP server architected like the above. Stress testing with Locust reached 20K sessions in my work notebook (Intel Core i7 with 16GB RAM) and run continually for about one hour without exploding. -- Pedro Lamar?o https://www.prodist.com.br Securing Critical Systems Tel: +55 11 4380-6585 Antes de imprimir esta mensagem e seus anexos, certifique-se que seja realmente necess?rio. Proteger o meio ambiente ? nosso dever. Before printing this e-mail or attachments, be sure it is necessary. It is in our hands to protect the environment. From Alan.Bateman at oracle.com Tue Nov 30 20:28:58 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 30 Nov 2021 20:28:58 +0000 Subject: Concurrency and Exceptions In-Reply-To: References: Message-ID: <65a09bb6-23da-9803-3c35-f92973c495e5@oracle.com> On 30/11/2021 16:36, Eric Kolotyluk wrote: > In my documentation I want to make the statement > > In concurrent frameworks, it was not safe to throw Exceptions because the >> JVM could not manage this. >> > My sense is that Project Loom addresses this and fixes it somewhat, but I > don't want to miss-state the problem Loom attempts to solve. > > *Is it the JVM, or simply the Java Language/Libraries that could not > support safe Exception Handling in Concurrent scenarios?* > > Up until now, this led to a Functional approach of returning composite > results, such as Scala Option, Either, Try, etc. to avoid throwing > Exceptions. > > I understand that in Kotlin Coroutines, it is safe to throw/catch > exceptions in concurrent code, but I have never really tried this. > I think it would be a bit misleading to say "the JVM could not manage this". Our focus on exceptions is to make it easier to collect, process, select, and propagate. When a task splits into N tasks then sometimes an exception is fatal and all remaining tasks can be cancelled to avoid waiting for them to complete. In other cases, there will be some tolerance for exceptions. The idea is that you can implement the policy as a completion handler. We've tried to avoid introducing any new discriminated union, instead we are using Future objects to represent a result or exception. The completion handler that implements the policy for exceptions can define an API to make it easy to access the results or exceptions. The handler implementation will need to deal with concurrency but it can define something much simpler for the (typically main) task to use. -Alan From paul.bjorkstrand at gmail.com Tue Nov 30 21:02:35 2021 From: paul.bjorkstrand at gmail.com (Paul Bjorkstrand) Date: Tue, 30 Nov 2021 15:02:35 -0600 Subject: Concurrency and Exceptions In-Reply-To: <65a09bb6-23da-9803-3c35-f92973c495e5@oracle.com> References: <65a09bb6-23da-9803-3c35-f92973c495e5@oracle.com> Message-ID: > We've tried to avoid introducing any new discriminated union, instead we > are using Future objects to represent a result or exception. The > completion handler that implements the policy for exceptions can define > an API to make it easy to access the results or exceptions. The handler > implementation will need to deal with concurrency but it can define > something much simpler for the (typically main) task to use. > I think this was something I was missing in my original understanding, thank you for this nugget! I believe treating CompletionHandlers as the means to _provide_ the results/failures, rather than just _track_ them makes a lot of sense. Would you say that the intent of CompletionHandler is to negate, to some degree, the need to individually call Future.[result|exception]Now() (outside the handler, that is)? That is what it sounds like to me, and it makes a CompletionHandler's purpose a lot more useful than just "short circuit other tasks on the first success/failure". -Paul From duke at openjdk.java.net Tue Nov 30 21:24:22 2021 From: duke at openjdk.java.net (duke) Date: Tue, 30 Nov 2021 21:24:22 GMT Subject: git: openjdk/loom: fibers: bumped jtregMW version. Message-ID: Changeset: 4908d1c1 Author: lmesnik Date: 2021-11-30 13:22:53 +0000 URL: https://git.openjdk.java.net/loom/commit/4908d1c1f6d2b29559c14506803c33e79ba9c859 bumped jtregMW version. ! make/conf/jib-profiles.js From eric at kolotyluk.net Tue Nov 30 22:25:23 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Tue, 30 Nov 2021 14:25:23 -0800 Subject: Concurrency and Exceptions In-Reply-To: References: <65a09bb6-23da-9803-3c35-f92973c495e5@oracle.com> Message-ID: @Alan Bateman > I think it would be a bit misleading to say "the JVM could not manage > this". > Fair enough, what would be more accurate to say? "The legacy Java Concurrency Framework did not deal with Exceptions *as completely*..." I am trying to define the problems around Exceptions that Loom solves. Yes, in JDK 17 there is no way to find out the cause of a Future failing, and in JDK 18 we have state(), resultNow(), and exceptionNow() to make Exception handling *more complete*. Completion Handlers allow the implementation of broad policies on failure/success handling. Will it be okay to pass a StructuredExecutor instance to CompletableFuture CompletionStage? I imagine this could be unsafe if we pass a CompletableFuture outside the ScopeLocal of the Thread Tree, but then passing the Future out would be just as unsafe. There is so much nuance going on here, or maybe I am just perceiving it that way... Cheers, Eric On Tue, Nov 30, 2021 at 1:03 PM Paul Bjorkstrand wrote: > > >> We've tried to avoid introducing any new discriminated union, instead we >> are using Future objects to represent a result or exception. The >> completion handler that implements the policy for exceptions can define >> an API to make it easy to access the results or exceptions. The handler >> implementation will need to deal with concurrency but it can define >> something much simpler for the (typically main) task to use. >> > > I think this was something I was missing in my original understanding, > thank you for this nugget! I believe treating CompletionHandlers as the > means to _provide_ the results/failures, rather than just _track_ them > makes a lot of sense. > > Would you say that the intent of CompletionHandler is to negate, to some > degree, the need to individually call Future.[result|exception]Now() > (outside the handler, that is)? That is what it sounds like to me, and it > makes a CompletionHandler's purpose a lot more useful than just "short > circuit other tasks on the first success/failure". > > > -Paul > From pedro.lamarao at prodist.com.br Tue Nov 30 22:36:47 2021 From: pedro.lamarao at prodist.com.br (=?UTF-8?Q?Pedro_Lamar=C3=A3o?=) Date: Tue, 30 Nov 2021 19:36:47 -0300 Subject: Concurrency and Exceptions In-Reply-To: References: <65a09bb6-23da-9803-3c35-f92973c495e5@oracle.com> Message-ID: Em ter., 30 de nov. de 2021 ?s 19:28, Eric Kolotyluk escreveu: > Yes, in JDK 17 there is no way to find out the cause of a Future failing, > If the task terminates with an exception, Future.get raises an ExecutionException with the corresponding cause, no? -- Pedro Lamar?o https://www.prodist.com.br Securing Critical Systems Tel: +55 11 4380-6585 From almas337519 at gmail.com Tue Nov 30 21:18:34 2021 From: almas337519 at gmail.com (Almas Abdrazak) Date: Tue, 30 Nov 2021 13:18:34 -0800 Subject: Question about the blocking syscalls within virtual thread Message-ID: Good day, thanks for giving me an opportunity to ask this question. The question I have is about performing syscalls from a virtual thread. My main OS is Linux so I would talk in terms of Linux. When I use InputStream class from jdk, internally it uses read() syscall, according to man pages, read() syscall is blocking so it will lock the OS thread until data won't be available. So with this in mind I read JEP Virtual Threads (Preview) According to JEP "The implementations of these APIs are heavily synchronized and require changes to avoid pinning when using these APIs from virtual threads." So InputStream implementation was changed to avoid synchronized keyword, but still it uses read() syscall right ? Later on in the JEP there is a paragraph "When a virtual thread tries to park, say, by performing a blocking I/O operation, while pinned, rather than released, its underlying OS thread will be blocked" As far as I understand, using InputStream would still block the OS thread, which means I can't increase the throughput of my backend if it uses JDBC which uses InputStream under the hood(Tomcat with 200 OS threads would be better than amount of threads equals to CPU cores all waiting on IO because virtual threads were using InputStreams). Did I understand it correctly ? My other assumption is that the JVM runtime detects that blocking read() would be called and replaces it with non blocking epoll() syscall from Linux. Please clarify this to me because I can't find any information. Regards ! From eric at kolotyluk.net Tue Nov 30 22:41:59 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Tue, 30 Nov 2021 14:41:59 -0800 Subject: Concurrency and Exceptions In-Reply-To: References: <65a09bb6-23da-9803-3c35-f92973c495e5@oracle.com> Message-ID: Pedro... right you are, Future#get() can throw an ExecutionException from the competition. On Tue, Nov 30, 2021 at 2:37 PM Pedro Lamar?o wrote: > Em ter., 30 de nov. de 2021 ?s 19:28, Eric Kolotyluk > escreveu: > > >> Yes, in JDK 17 there is no way to find out the cause of a Future failing, >> > > If the task terminates with an exception, Future.get raises an > ExecutionException with the corresponding cause, no? > > -- > Pedro Lamar?o > https://www.prodist.com.br > Securing Critical Systems > Tel: +55 11 4380-6585 > From eric at kolotyluk.net Tue Nov 30 22:42:29 2021 From: eric at kolotyluk.net (Eric Kolotyluk) Date: Tue, 30 Nov 2021 14:42:29 -0800 Subject: Concurrency and Exceptions In-Reply-To: References: <65a09bb6-23da-9803-3c35-f92973c495e5@oracle.com> Message-ID: I mean ... computation... On Tue, Nov 30, 2021 at 2:41 PM Eric Kolotyluk wrote: > Pedro... right you are, Future#get() can throw an ExecutionException from > the competition. > > On Tue, Nov 30, 2021 at 2:37 PM Pedro Lamar?o < > pedro.lamarao at prodist.com.br> wrote: > >> Em ter., 30 de nov. de 2021 ?s 19:28, Eric Kolotyluk >> escreveu: >> >> >>> Yes, in JDK 17 there is no way to find out the cause of a Future failing, >>> >> >> If the task terminates with an exception, Future.get raises an >> ExecutionException with the corresponding cause, no? >> >> -- >> Pedro Lamar?o >> https://www.prodist.com.br >> Securing Critical Systems >> Tel: +55 11 4380-6585 >> >