From adam at warski.org Wed Oct 1 06:35:54 2025 From: adam at warski.org (Adam Warski) Date: Wed, 1 Oct 2025 08:35:54 +0200 Subject: Problem report on the usage of Structured Concurrency (5th preview) In-Reply-To: <51868ca8-ec63-4c2e-ba2d-a7f0f1df6954@oracle.com> References: <85467C61-8139-4832-B3BA-BFA53061E986@warski.org> <51868ca8-ec63-4c2e-ba2d-a7f0f1df6954@oracle.com> Message-ID: <7D941AAE-5168-4BE2-9A14-A8F5C0FF132D@warski.org> Hello, >> Well if scope.join() waits until all forks complete, it will only do so when there are no forks left, and then nobody can create new forks? So I don?t think there?s a race here? In other words, forks can only be created from live forks, before they complete. > That's right but allowing this (as it was in early previews) creates weirdness where a subtask can fork it cannot join. It also messes with the mental model of "parent". Who is my parent when I'm forked by a sibling? > > If the problem has been arranged so that subtask opens a new scope and decomposes into a set of sub-subtasks forked in this scope, thus creating a hierarchy, then it becomes simpler to reason about. Absolutely, if you can correctly solve your problem using nested scopes, that?s the way to go! Full agreement here :) However, the forks-in-forks is one solution or work-around for the problem of having complex, or blocking logic in the scope?s body, and wanting that logic to participate in the same error handling (interrupt when scope is cancelled) as the forks. So the whole point here is to move the logic out of the scope, into a fork, so that it can fork further. Nested scopes here are not a solution (the nested scope has the same problem). But I can see how it goes against the current idea of a subtask, which is un-joinable - you can only query it after the entire scope has joined. Also, it?s always easier to add the possibility to fork-in-fork, than to remove it (which, once the JEP is final, wouldn?t be possible). Still, the problem I described remains. And yes, the analogy with parents/siblings breaks down, but that?s just an analogy :) As for the hierarchy, I think it?s still there, it?s just that a fork creates a fork in the scope to which it belongs. You might say, that you limit the "structurefullness" of the approach to the scope, as you then allow to create forks-in-forks which don?t follow the structural properties fully. But it might also be a reasonable tradeoff between flexibility in forking and maintaining structure. Adam -- Adam Warski https://warski.org From duke at openjdk.org Wed Oct 1 09:53:57 2025 From: duke at openjdk.org (duke) Date: Wed, 1 Oct 2025 09:53:57 GMT Subject: git: openjdk/loom: fibers: 2 new changesets Message-ID: <483962ba-44ae-4f10-9a8a-e023c18ffb4b@openjdk.org> Changeset: b315a5f0 Branch: fibers Author: Michael-Mc-Mahon Date: 2025-10-01 10:07:22 +0000 URL: https://git.openjdk.org/loom/commit/b315a5f0aeb37988a29078c112386304c747a15b fixed errno issue with syscall + handle EINTR ! src/java.base/linux/classes/sun/nio/ch/iouring/IOUring.java Changeset: 2091c297 Branch: fibers Author: Michael-Mc-Mahon Date: 2025-10-01 09:16:26 +0000 URL: https://git.openjdk.org/loom/commit/2091c297102ea8cb21ee842756579896761e9abc missed file for last commit ! src/java.base/linux/classes/sun/nio/ch/iouring/SystemCallContext.java From duke at openjdk.org Wed Oct 1 16:18:59 2025 From: duke at openjdk.org (duke) Date: Wed, 1 Oct 2025 16:18:59 GMT Subject: git: openjdk/loom: fibers: 6 new changesets Message-ID: <8a470986-80e2-49cf-bd80-25f77871d187@openjdk.org> Changeset: 89f30e02 Branch: fibers Author: Patricio Chilano Mateo Date: 2025-09-23 16:58:20 +0000 URL: https://git.openjdk.org/loom/commit/89f30e0292900002a7a398df2b352541bf7fe38b Fix comments ! src/hotspot/cpu/aarch64/smallRegisterMap_aarch64.inline.hpp ! src/hotspot/cpu/arm/smallRegisterMap_arm.inline.hpp ! src/hotspot/cpu/ppc/smallRegisterMap_ppc.inline.hpp ! src/hotspot/cpu/riscv/smallRegisterMap_riscv.inline.hpp ! src/hotspot/cpu/s390/smallRegisterMap_s390.inline.hpp ! src/hotspot/cpu/x86/smallRegisterMap_x86.inline.hpp ! src/hotspot/cpu/zero/smallRegisterMap_zero.inline.hpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/runtime/continuationFreezeThaw.cpp Changeset: 9d1e97fd Branch: fibers Author: Patricio Chilano Mateo Date: 2025-09-24 15:14:59 +0000 URL: https://git.openjdk.org/loom/commit/9d1e97fdfe2b4ca3d03623fabe9d816b246225d8 Fix InterpreterRuntime::resolve_invoke ! src/hotspot/share/interpreter/interpreterRuntime.cpp Changeset: 71c3c31c Branch: fibers Author: Patricio Chilano Mateo Date: 2025-09-24 15:30:56 +0000 URL: https://git.openjdk.org/loom/commit/71c3c31c2ed09c6c4170a6b51b606b56bbb18ae2 move is_preemptable_call to cpp file ! src/hotspot/share/interpreter/interpreterRuntime.cpp ! src/hotspot/share/interpreter/interpreterRuntime.hpp Changeset: f07678b1 Branch: fibers Author: Patricio Chilano Mateo Date: 2025-09-24 18:20:07 +0000 URL: https://git.openjdk.org/loom/commit/f07678b1be5339329edb8ae3f433041a5f9df110 Remove exception output from KlassInit.java ! test/jdk/java/lang/Thread/virtual/KlassInit.java Changeset: eec31ea2 Branch: fibers Author: Patricio Chilano Mateo Date: 2025-09-25 16:45:00 +0000 URL: https://git.openjdk.org/loom/commit/eec31ea221b236c70893c16162c39ae1572d42fd Add extra checks for PreemptedException + NoPreemptMark during throw ! src/hotspot/share/utilities/exceptions.cpp Changeset: cbbc826e Branch: fibers Author: Patricio Chilano Mateo Date: 2025-10-01 11:47:37 +0000 URL: https://git.openjdk.org/loom/commit/cbbc826eca2743abce54dc1b54ff1cf44a756b82 protect init lock + objmonitor changes ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/runtime/objectMonitor.cpp ! src/hotspot/share/runtime/objectMonitor.hpp ! src/hotspot/share/runtime/synchronizer.cpp ! src/hotspot/share/runtime/synchronizer.hpp ! src/hotspot/share/runtime/synchronizer.inline.hpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp From duke at openjdk.org Thu Oct 2 01:36:09 2025 From: duke at openjdk.org (duke) Date: Thu, 2 Oct 2025 01:36:09 GMT Subject: git: openjdk/loom: fibers: 2 new changesets Message-ID: Changeset: 01906093 Branch: fibers Author: Patricio Chilano Mateo Date: 2025-10-01 21:16:33 +0000 URL: https://git.openjdk.org/loom/commit/019060932d635a6be2afc7cfbe53c4fda9ef49b5 remove ProfileTrapsMark ! src/hotspot/share/interpreter/interpreterRuntime.cpp ! src/hotspot/share/interpreter/interpreterRuntime.hpp Changeset: 5ee5c0db Branch: fibers Author: Patricio Chilano Mateo Date: 2025-10-01 21:16:45 +0000 URL: https://git.openjdk.org/loom/commit/5ee5c0dbb0684e950178e3f634a3bdf590f82805 Remove extra unnecessary changes ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/oops/stackChunkOop.hpp ! src/hotspot/share/oops/stackChunkOop.inline.hpp From duke at openjdk.org Thu Oct 2 07:00:33 2025 From: duke at openjdk.org (duke) Date: Thu, 2 Oct 2025 07:00:33 GMT Subject: git: openjdk/loom: fibers: 54 new changesets Message-ID: <0156a9d2-9a58-4e6c-9186-3d0a78781de2@openjdk.org> Changeset: e19ec6f7 Branch: fibers Author: Axel Boldt-Christmas Date: 2025-09-29 05:19:56 +0000 URL: https://git.openjdk.org/loom/commit/e19ec6f785e889d254b15c5ef2e801152c59c948 8368754: runtime/cds/appcds/SignedJar.java log regex is too strict Reviewed-by: iklam, dholmes ! test/hotspot/jtreg/runtime/cds/appcds/SignedJar.java Changeset: d53190ac Branch: fibers Author: Jan Lahoda Date: 2025-09-29 05:36:18 +0000 URL: https://git.openjdk.org/loom/commit/d53190ac4485e535f0a603036ecf47d4ff6e4178 8366582: Test jdk/jshell/ToolSimpleTest.java failed: provider not found Reviewed-by: asotona ! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java ! test/langtools/ProblemList.txt Changeset: 75269fdb Branch: fibers Author: Albert Mingkun Yang Date: 2025-09-29 07:26:43 +0000 URL: https://git.openjdk.org/loom/commit/75269fdb49aeb9d37acbbc1502c446a822fd30e3 8368715: Serial: Add GCTraceTime for marking from roots subphases during full gc marking Reviewed-by: fandreuzzi, tschatzl, iwalulya ! src/hotspot/share/gc/serial/serialFullGC.cpp Changeset: 08b677bb Branch: fibers Author: Thomas Schatzl Date: 2025-09-29 10:05:45 +0000 URL: https://git.openjdk.org/loom/commit/08b677bba4b1e23feb55b104d86fe0eef543d59c 8071277: G1: Merge commits and uncommits of contiguous memory Reviewed-by: iwalulya, ayang ! src/hotspot/share/gc/g1/g1NUMA.cpp ! src/hotspot/share/gc/g1/g1RegionToSpaceMapper.cpp ! src/hotspot/share/gc/g1/g1RegionToSpaceMapper.hpp Changeset: 61659214 Branch: fibers Author: Daniel Gredler Date: 2025-09-29 10:28:45 +0000 URL: https://git.openjdk.org/loom/commit/616592144939d80cae661bd4db26c976a035d543 7156751: [macosx] Problem with printing Reviewed-by: prr, serb ! src/java.desktop/macosx/native/libawt_lwawt/awt/CTextPipe.m ! test/jdk/java/awt/print/PrinterJob/PrintTextTest.java Changeset: fdbba049 Branch: fibers Author: Daniel Gredler Date: 2025-09-29 10:39:25 +0000 URL: https://git.openjdk.org/loom/commit/fdbba049a2491c591fc1a866e4707bf9aac50f17 8368775: Remove outdated comment in OutlineTextRenderer Reviewed-by: prr, dnguyen, serb ! src/java.desktop/share/classes/sun/java2d/pipe/OutlineTextRenderer.java Changeset: 9d9c0e06 Branch: fibers Author: Roger Riggs Date: 2025-09-29 13:55:49 +0000 URL: https://git.openjdk.org/loom/commit/9d9c0e06700116288233e3435051a1496cb64b72 8368793: java/lang/StringBuilder/RacingSBThreads.java timed out in Xcomp subtest Reviewed-by: iris, alanb, syan ! test/jdk/java/lang/StringBuilder/RacingSBThreads.java Changeset: 63688d89 Branch: fibers Author: Joe Darcy Date: 2025-09-29 14:48:04 +0000 URL: https://git.openjdk.org/loom/commit/63688d894e2157bb091be3aa62946f7e5830f384 8368822: Refactor Float16.valueOf(double) Reviewed-by: rgiulietti ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java Changeset: 9d71af10 Branch: fibers Author: Hamlin Li Date: 2025-09-29 16:04:54 +0000 URL: https://git.openjdk.org/loom/commit/9d71af108ea2cc3682607527246d60a19fd820ba 8367253: RISC-V: refactor dependent cpu extensions Reviewed-by: fyang, luhenry ! src/hotspot/cpu/riscv/vm_version_riscv.cpp ! src/hotspot/cpu/riscv/vm_version_riscv.hpp Changeset: aabf699d Branch: fibers Author: Brian Burkhalter Date: 2025-09-29 17:43:35 +0000 URL: https://git.openjdk.org/loom/commit/aabf699dd0f066efe6654db24b520068b256d855 8355339: Test java/io/File/GetCanonicalPath.java failed: The specified network name is no longer available Reviewed-by: alanb ! src/java.base/windows/native/libjava/canonicalize_md.c Changeset: 3d97e17a Branch: fibers Author: Chris Plummer Date: 2025-09-29 17:46:17 +0000 URL: https://git.openjdk.org/loom/commit/3d97e17a31c267161c2be87b551cdb118062ff57 8367318: Test vmTestbase/nsk/jdi/MethodEntryRequest/addClassFilter_rt/filter_rt001/TestDescription.java timed out after passing Reviewed-by: amenkov, sspitsyn ! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/EventHandler.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/TestDebuggerType1.java Changeset: 6c8e384c Branch: fibers Author: Chen Liang Date: 2025-09-29 18:22:24 +0000 URL: https://git.openjdk.org/loom/commit/6c8e384c63ac199a5f226b017ef5cd133130d1ac 8356022: Migrate descriptor parsing from generics to BytecodeDescriptor Reviewed-by: rriggs ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/sun/invoke/util/BytecodeDescriptor.java ! src/java.base/share/classes/sun/reflect/annotation/AnnotationParser.java + test/jdk/sun/invoke/util/BytecodeDescriptorTest.java Changeset: 59e76af4 Branch: fibers Author: Hannes Greule Date: 2025-09-29 18:40:43 +0000 URL: https://git.openjdk.org/loom/commit/59e76af47b23f582bbc21465a1871205d2499f28 8367967: C2: "fatal error: Not monotonic" with Mod nodes Co-authored-by: Christian Hagedorn Reviewed-by: bmaillard, vlivanov, chagedorn, shade ! src/hotspot/share/opto/divnode.cpp + test/hotspot/jtreg/compiler/ccp/TestModValueMonotonic.java Changeset: 2f29b3f2 Branch: fibers Author: Afshin Zafari Date: 2025-09-29 19:24:28 +0000 URL: https://git.openjdk.org/loom/commit/2f29b3f24a31bbe58d9c3433d46b69c16002694b 8366884: NMT fails with MallocLimit: reached category "mtCompiler" limit Reviewed-by: phubner, jsjolen ! test/hotspot/jtreg/runtime/NMT/MallocLimitTest.java Changeset: c57003c9 Branch: fibers Author: Alexey Semenyuk Date: 2025-09-29 21:39:42 +0000 URL: https://git.openjdk.org/loom/commit/c57003c9b837adb8671a0db636d9c576bd6a89b0 8368890: open/test/jdk/tools/jpackage/macosx/NameWithSpaceTest.java fails randomly Reviewed-by: almatvee ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacHelper.java Changeset: 538a722c Branch: fibers Author: Fei Yang Date: 2025-09-30 01:40:35 +0000 URL: https://git.openjdk.org/loom/commit/538a722c2e9123cc575355879ff230444cf2dadc 8368732: RISC-V: Detect support for misaligned vector access via hwprobe Reviewed-by: mli, dzhang ! src/hotspot/cpu/riscv/vm_version_riscv.cpp ! src/hotspot/cpu/riscv/vm_version_riscv.hpp ! src/hotspot/os_cpu/linux_riscv/riscv_hwprobe.cpp ! src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp Changeset: 89af6e13 Branch: fibers Author: Sergey Bylokhov Date: 2025-09-30 03:10:41 +0000 URL: https://git.openjdk.org/loom/commit/89af6e13f2354d6e32872791d157144cd478a88f 8362204: test/jdk/sun/awt/font/TestDevTransform.java fails on Ubuntu 24.04 Reviewed-by: avu, prr ! test/jdk/sun/awt/font/TestDevTransform.java Changeset: 2746c1a5 Branch: fibers Author: Anton Artemov Committer: Thomas Stuefe Date: 2025-09-30 05:09:33 +0000 URL: https://git.openjdk.org/loom/commit/2746c1a555891564963299182b3b0293eaefc901 8367485: os::physical_memory is broken in 32-bit JVMs when running on 64-bit OSes Reviewed-by: jsikstro, sgehwolf, stefank, stuefe, aph ! src/hotspot/os/aix/os_aix.cpp ! src/hotspot/os/aix/os_aix.hpp ! src/hotspot/os/bsd/os_bsd.cpp ! src/hotspot/os/bsd/os_bsd.hpp ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/os/linux/os_linux.hpp ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/os/windows/os_windows.hpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/gc/shared/gcInitLogger.cpp ! src/hotspot/share/gc/z/zLargePages.cpp ! src/hotspot/share/jfr/jni/jfrJniMethod.cpp ! src/hotspot/share/jfr/periodic/jfrPeriodic.cpp ! src/hotspot/share/prims/jvmtiRedefineClasses.cpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/os.cpp ! src/hotspot/share/runtime/os.hpp ! src/hotspot/share/services/heapDumper.cpp ! src/hotspot/share/utilities/globalDefinitions.hpp Changeset: c0a4c0ba Branch: fibers Author: Hamlin Li Date: 2025-09-30 08:11:02 +0000 URL: https://git.openjdk.org/loom/commit/c0a4c0ba97284d55cfdf857eb5d41fd6189e6c2d 8367981: Update CompactHashtable for readability Reviewed-by: iklam, matsaave ! src/hotspot/share/classfile/compactHashtable.cpp ! src/hotspot/share/classfile/compactHashtable.hpp Changeset: 586167cf Branch: fibers Author: Thomas Schatzl Date: 2025-09-30 08:49:08 +0000 URL: https://git.openjdk.org/loom/commit/586167cff5aaead0949c509f48bc5080834cc362 8363932: G1: Better distribute KlassCleaningTask Reviewed-by: ayang, coleenp ! src/hotspot/share/classfile/classLoaderData.hpp ! src/hotspot/share/classfile/classLoaderDataGraph.cpp ! src/hotspot/share/classfile/classLoaderDataGraph.hpp ! src/hotspot/share/gc/shared/parallelCleaning.cpp ! src/hotspot/share/gc/shared/parallelCleaning.hpp ! src/hotspot/share/oops/klass.cpp ! src/hotspot/share/oops/klass.hpp Changeset: aea71cca Branch: fibers Author: Afshin Zafari Date: 2025-09-30 08:54:53 +0000 URL: https://git.openjdk.org/loom/commit/aea71ccab7d21ae72564a07f74199eac14c7a958 8342730: Get rid of SummaryDiff in VMATree Reviewed-by: jsjolen, phubner ! src/hotspot/share/nmt/memoryFileTracker.cpp ! src/hotspot/share/nmt/regionsTree.cpp ! src/hotspot/share/nmt/regionsTree.hpp ! src/hotspot/share/nmt/virtualMemoryTracker.cpp ! src/hotspot/share/nmt/vmatree.cpp ! src/hotspot/share/nmt/vmatree.hpp ! test/hotspot/gtest/nmt/test_regions_tree.cpp ! test/hotspot/gtest/nmt/test_vmatree.cpp ! test/hotspot/gtest/runtime/test_virtualMemoryTracker.cpp Changeset: b19e8721 Branch: fibers Author: Markus Gr?nlund Date: 2025-09-30 10:35:23 +0000 URL: https://git.openjdk.org/loom/commit/b19e872192106f47c5d9b425230cc2bfe3e4786c 8362573: Incorrect weight of the first ObjectAllocationSample JFR event (regression) Reviewed-by: egahlin ! src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.cpp ! src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.hpp ! src/hotspot/share/jfr/recorder/service/jfrRecorderService.cpp ! src/hotspot/share/jfr/support/jfrAllocationTracer.cpp ! src/hotspot/share/jfr/support/jfrObjectAllocationSample.cpp ! src/hotspot/share/jfr/support/jfrObjectAllocationSample.hpp + test/jdk/jdk/jfr/event/allocation/TestObjectAllocationSampleEventInitialWeight.java Changeset: ba0a6eed Branch: fibers Author: Francesco Andreuzzi Committer: Albert Mingkun Yang Date: 2025-09-30 10:41:13 +0000 URL: https://git.openjdk.org/loom/commit/ba0a6eed1a6a22bd4c1d159592b62e054afa401a 8368357: Some source files have initial blank lines Reviewed-by: stefank, ayang, serb, jwaters, jpai ! src/hotspot/share/cds/dumpTimeClassInfo.inline.hpp ! src/hotspot/share/runtime/threads.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/services/threadIdTable.cpp ! src/hotspot/share/services/threadIdTable.hpp ! src/java.base/share/classes/sun/util/locale/UnicodeLocaleExtension.java ! src/java.desktop/share/classes/java/awt/image/LookupOp.java ! src/jdk.compiler/share/classes/com/sun/source/tree/UsesTree.java Changeset: 64c46d8e Branch: fibers Author: Yasumasa Suenaga Date: 2025-09-30 11:32:44 +0000 URL: https://git.openjdk.org/loom/commit/64c46d8efc27911b8667c3974275c075cf79a311 8367953: JFR sampler threads does not appear in thread dump Reviewed-by: mgronlun ! src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp ! src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp Changeset: 8606d3f8 Branch: fibers Author: Jan Lahoda Date: 2025-09-30 11:54:37 +0000 URL: https://git.openjdk.org/loom/commit/8606d3f8405b73878a1319ba3574ef69349aa2a1 8365060: Historical data for JDK 8 should include the jdk.net package Reviewed-by: shade, liach ! src/jdk.compiler/share/data/symbols/include.list ! src/jdk.compiler/share/data/symbols/java.base-8.sym.txt ! src/jdk.compiler/share/data/symbols/java.base-9.sym.txt ! src/jdk.compiler/share/data/symbols/java.desktop-8.sym.txt ! src/jdk.compiler/share/data/symbols/java.desktop-9.sym.txt ! src/jdk.compiler/share/data/symbols/java.xml.bind-9.sym.txt ! src/jdk.compiler/share/data/symbols/jdk.management-8.sym.txt ! src/jdk.compiler/share/data/symbols/jdk.management-9.sym.txt + src/jdk.compiler/share/data/symbols/jdk.net-8.sym.txt ! src/jdk.compiler/share/data/symbols/jdk.net-9.sym.txt ! src/jdk.compiler/share/data/symbols/symbols + test/langtools/tools/javac/platform/CompilationTest.java ! test/langtools/tools/javac/sym/ElementStructureTest.java Changeset: 444007fc Branch: fibers Author: Albert Mingkun Yang Date: 2025-09-30 12:27:22 +0000 URL: https://git.openjdk.org/loom/commit/444007fc234aeff75025831c2d1b5538c87fa8f1 8368842: Parallel: Refactor PCAddThreadRootsMarkingTaskClosure Reviewed-by: fandreuzzi, tschatzl ! src/hotspot/share/gc/parallel/psParallelCompact.cpp Changeset: 07ea907e Branch: fibers Author: Anass Baya Committer: Alexey Ivanov Date: 2025-09-30 13:57:07 +0000 URL: https://git.openjdk.org/loom/commit/07ea907e4fc8aa8fda01d8fe64c599f9d944eef9 8361606: ConsumeNextMnemonicKeyTypedTest.java fails on Windows: character typed with VK_A: a 8321303: Intermittent open/test/jdk/java/awt/KeyboardFocusmanager/ConsumeNextMnemonicKeyTypedTest/ConsumeNextMnemonicKeyTypedTest.java failure on Linux Reviewed-by: dnguyen, honkar, aivanov ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicPopupMenuUI.java ! test/jdk/ProblemList.txt ! test/jdk/java/awt/KeyboardFocusmanager/ConsumeNextMnemonicKeyTypedTest/ConsumeNextMnemonicKeyTypedTest.java Changeset: 8cc54ec6 Branch: fibers Author: Erik Gahlin Date: 2025-09-30 14:14:53 +0000 URL: https://git.openjdk.org/loom/commit/8cc54ec6b86fc5b80af02939363eccd8e3e899e7 8368563: JFR: Improve jfr query help text Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/internal/query/QueryPrinter.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/Query.java Changeset: 6b4b1020 Branch: fibers Author: Erik Gahlin Date: 2025-09-30 14:24:05 +0000 URL: https://git.openjdk.org/loom/commit/6b4b10200ed10365e1ae1ca02ade773ce5a108c3 8368809: JFR: Remove events from testSettingConfiguration in TestActiveSettingEvent Reviewed-by: mgronlun ! test/jdk/jdk/jfr/event/runtime/TestActiveSettingEvent.java Changeset: 07ecc93d Branch: fibers Author: Robbin Ehn Date: 2025-09-30 15:10:30 +0000 URL: https://git.openjdk.org/loom/commit/07ecc93dbd0b74e2362d369e22b5141289eb1f76 8367692: RISC-V: Align post call nop Reviewed-by: fyang, fjiang, mli ! src/hotspot/cpu/riscv/assembler_riscv.hpp ! src/hotspot/cpu/riscv/c1_LIRAssembler_riscv.cpp ! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp ! src/hotspot/cpu/riscv/nativeInst_riscv.cpp ! src/hotspot/cpu/riscv/nativeInst_riscv.hpp ! src/hotspot/cpu/riscv/riscv.ad ! src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp Changeset: fe9dbcc4 Branch: fibers Author: Francesco Andreuzzi Committer: Aleksey Shipilev Date: 2025-09-30 16:15:21 +0000 URL: https://git.openjdk.org/loom/commit/fe9dbcc496671a256c61ac52df5580569dbafb0a 8368599: ShenandoahConcurrentMark could use ThreadsClaimTokenScope Reviewed-by: ayang, shade, wkemper ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp Changeset: 9b02896b Branch: fibers Author: Mohamed Issa Committer: Srinivas Vamsi Parasa Date: 2025-09-30 21:08:06 +0000 URL: https://git.openjdk.org/loom/commit/9b02896b4725ef932a23be11ff76ce04bda0d652 8360558: Use hex literals instead of decimal literals in math intrinsic constants Reviewed-by: mhaessig, sparasa, jbhateja ! src/hotspot/cpu/x86/stubGenerator_x86_64_cbrt.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64_tanh.cpp Changeset: 0366d882 Branch: fibers Author: SendaoYan Date: 2025-10-01 00:52:30 +0000 URL: https://git.openjdk.org/loom/commit/0366d8823bc844225ca24964e352ce0a57d01683 8354894: java/lang/Thread/virtual/Starvation.java timeout on server with high CPUs Co-authored-by: Alan Bateman Reviewed-by: jpai ! test/jdk/java/lang/Thread/virtual/Starvation.java Changeset: 17d8fa8e Branch: fibers Author: Jaikiran Pai Date: 2025-10-01 01:40:06 +0000 URL: https://git.openjdk.org/loom/commit/17d8fa8e421db67027c9e7d2ddd634ff0b897cb6 8367026: Reorder the timeout failure handler commands to have jstack run before the rest Reviewed-by: erikj, lmesnik ! test/failure_handler/src/share/conf/common.properties Changeset: 8c3ca024 Branch: fibers Author: Kim Barrett Date: 2025-10-01 03:58:49 +0000 URL: https://git.openjdk.org/loom/commit/8c3ca024c770d3cf3b35234e967e5f0f0d610388 8368817: Convert JDK_Version::to_string to use stringStream instead of jio_snprintf-chain Reviewed-by: fandreuzzi, jsjolen ! src/hotspot/share/runtime/java.cpp Changeset: 394eb80a Branch: fibers Author: Kim Barrett Date: 2025-10-01 06:12:05 +0000 URL: https://git.openjdk.org/loom/commit/394eb80a48fa73238cf897087b99c3da5a616566 8368957: Remove metaprogramming/logical.hpp in favor of C++17 facilities Reviewed-by: mchevalier, iwalulya ! src/hotspot/share/gc/shared/workerUtils.hpp - src/hotspot/share/metaprogramming/logical.hpp - test/hotspot/gtest/metaprogramming/test_logical.cpp Changeset: 1188ca55 Branch: fibers Author: Thomas Schatzl Date: 2025-10-01 08:07:59 +0000 URL: https://git.openjdk.org/loom/commit/1188ca55f525554d2bb10691b368c818d98e5ea7 8368954: G1: Document why G1 uses TLS storage for the current card table reference Reviewed-by: ayang, rcastanedalo, iwalulya ! src/hotspot/share/gc/g1/g1ThreadLocalData.hpp Changeset: 6c2d3834 Branch: fibers Author: Thomas Schatzl Date: 2025-10-01 08:08:19 +0000 URL: https://git.openjdk.org/loom/commit/6c2d383492d194eb8a604a58a0336c371cbb1ea5 8368953: Document the reason why Serial/Parallel/G1 use zero as dirty card value Co-authored-by: Albert Mingkun Yang Reviewed-by: ayang, iwalulya ! src/hotspot/share/gc/shared/cardTable.hpp Changeset: f49849a5 Branch: fibers Author: Hamlin Li Date: 2025-10-01 08:22:02 +0000 URL: https://git.openjdk.org/loom/commit/f49849a5ed4e9383e39e69ce76bb8ea74fb443f9 8368893: RISC-V: crash after JDK-8352673 on fastdebug version Reviewed-by: fyang, dzhang ! src/hotspot/cpu/riscv/vm_version_riscv.cpp ! src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp Changeset: 84e5d63b Branch: fibers Author: Johan Sj?len Date: 2025-10-01 09:01:19 +0000 URL: https://git.openjdk.org/loom/commit/84e5d63b9fa8af0b35e1d682a81900cb157697fe 8368885: NMT CommandLine tests can check for error better Reviewed-by: phubner, azafari, shade ! test/hotspot/jtreg/runtime/NMT/CommandLineDetail.java ! test/hotspot/jtreg/runtime/NMT/CommandLineSummary.java Changeset: 5a2700f2 Branch: fibers Author: Richard Reingruber Date: 2025-10-01 09:26:43 +0000 URL: https://git.openjdk.org/loom/commit/5a2700f231d72e2241703c1d17b308f031e8566c 8368861: [TEST] compiler/floatingpoint/ScalarFPtoIntCastTest.java expects x86 IR on non-x86 platforms Reviewed-by: sviswanathan, mdoerr ! test/hotspot/jtreg/compiler/floatingpoint/ScalarFPtoIntCastTest.java Changeset: 3607e998 Branch: fibers Author: Jan Lahoda Date: 2025-10-01 11:16:44 +0000 URL: https://git.openjdk.org/loom/commit/3607e9986f1582ebdae1b6ad2a13c1a9c239e0d6 8367279: Test tools/javac/tree/TreePosTest.java timed out Reviewed-by: asotona ! test/langtools/tools/javac/tree/TreePosTest.java Changeset: c69456e8 Branch: fibers Author: Justin King Date: 2025-10-01 13:23:13 +0000 URL: https://git.openjdk.org/loom/commit/c69456e87aeb8653ce23bc7f579c254511bbf2d1 8368962: hotspot/cpu/aarch64/bytecodes_aarch64.{hpp,cpp} is unused Reviewed-by: aph, mhaessig - src/hotspot/cpu/aarch64/bytecodes_aarch64.cpp - src/hotspot/cpu/aarch64/bytecodes_aarch64.hpp Changeset: 182fbc2b Branch: fibers Author: Roberto Casta?eda Lozano Date: 2025-10-01 13:55:18 +0000 URL: https://git.openjdk.org/loom/commit/182fbc2b836d27410ccd0da512acb17bac9363c1 8368675: IGV: nodes are wrongly marked as changed in the difference view Reviewed-by: mchevalier, mhaessig, dfenacci, tholenstein ! src/utils/IdealGraphVisualizer/Data/src/main/java/com/sun/hotspot/igv/data/InputNode.java ! src/utils/IdealGraphVisualizer/Data/src/main/java/com/sun/hotspot/igv/data/serialization/Parser.java ! src/utils/IdealGraphVisualizer/Difference/src/main/java/com/sun/hotspot/igv/difference/Difference.java ! src/utils/IdealGraphVisualizer/Graph/src/main/java/com/sun/hotspot/igv/graph/Figure.java ! src/utils/IdealGraphVisualizer/View/src/main/java/com/sun/hotspot/igv/view/NodeQuickSearch.java Changeset: c54dcefb Branch: fibers Author: Francesco Andreuzzi Committer: Aleksey Shipilev Date: 2025-10-01 14:59:14 +0000 URL: https://git.openjdk.org/loom/commit/c54dcefbfd2eb44a569767740dc053813c4f6fe1 8368938: Remove ObjectWaiter::badObjectWaiterPtr Reviewed-by: shade, ayang ! src/hotspot/share/runtime/objectMonitor.hpp Changeset: e44ef0c3 Branch: fibers Author: Pavel Rappo Date: 2025-10-01 16:05:31 +0000 URL: https://git.openjdk.org/loom/commit/e44ef0c32b3c2fcd0a6293838d9185b6d0719219 8367704: Fix minor documentation issues in java.time.** Reviewed-by: naoto, rriggs ! src/java.base/share/classes/java/time/Duration.java ! src/java.base/share/classes/java/time/Instant.java ! src/java.base/share/classes/java/time/Period.java ! src/java.base/share/classes/java/time/ZoneOffset.java ! src/java.base/share/classes/java/time/ZonedDateTime.java ! src/java.base/share/classes/java/time/package-info.java ! src/java.base/share/classes/java/time/temporal/ChronoField.java ! src/java.base/share/classes/java/time/temporal/ValueRange.java Changeset: 6b72b778 Branch: fibers Author: Justin Lu Date: 2025-10-01 17:57:43 +0000 URL: https://git.openjdk.org/loom/commit/6b72b778039afce0e25986114d15dd29a6786529 6177299: [Fmt-Nu] NumberFormat.getPercentInstance() does not work correctly Reviewed-by: naoto ! src/java.base/share/classes/java/text/DecimalFormat.java ! test/jdk/java/text/Format/NumberFormat/NumberRegression.java Changeset: ef724f40 Branch: fibers Author: Joe Darcy Date: 2025-10-01 19:56:05 +0000 URL: https://git.openjdk.org/loom/commit/ef724f40c1f3cdddd215d50edf512bb06825085d 8368985: Small Float16 refactorings Reviewed-by: rgiulietti, jbhateja ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java ! test/jdk/jdk/incubator/vector/BasicFloat16ArithTests.java Changeset: db6320df Branch: fibers Author: Johannes Graham Committer: Raffaello Giulietti Date: 2025-10-01 20:00:43 +0000 URL: https://git.openjdk.org/loom/commit/db6320df980ebe7cf2a1c727970cc937ab549b97 8368968: FloatingDecimal: Clean up unused code Reviewed-by: rgiulietti ! src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java Changeset: 4df41d2a Branch: fibers Author: Igor Veresov Date: 2025-10-01 23:15:13 +0000 URL: https://git.openjdk.org/loom/commit/4df41d2a751e2942c2188ed01313d78e681835bc 8368698: runtime/cds/appcds/aotCache/OldClassSupport.java assert(can_add()) failed: Cannot add TrainingData objects Reviewed-by: heidinga, iklam ! src/hotspot/share/oops/trainingData.cpp Changeset: fa3af820 Branch: fibers Author: Boris Ulasevich Date: 2025-10-01 23:49:03 +0000 URL: https://git.openjdk.org/loom/commit/fa3af820ad310704e8d25cf496f676e09d60797d 8338197: [ubsan] ad_x86.hpp:6417:11: runtime error: shift exponent 100 is too large for 32-bit type 'unsigned int' Reviewed-by: kvn, dlong ! src/hotspot/share/adlc/output_h.cpp Changeset: 4e52877e Branch: fibers Author: Alan Bateman Date: 2025-10-02 06:21:23 +0000 URL: https://git.openjdk.org/loom/commit/4e52877eda6e5f08421a979dfe2c6d52e9ee236f Merge branch 'master' into fibers ! src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp ! src/hotspot/share/oops/klass.cpp ! src/hotspot/share/oops/klass.hpp ! src/hotspot/share/runtime/objectMonitor.hpp ! src/hotspot/share/runtime/threads.cpp ! test/jdk/ProblemList.txt ! test/langtools/ProblemList.txt ! src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp ! src/hotspot/share/oops/klass.cpp ! src/hotspot/share/oops/klass.hpp ! src/hotspot/share/runtime/objectMonitor.hpp ! src/hotspot/share/runtime/threads.cpp ! test/jdk/ProblemList.txt ! test/langtools/ProblemList.txt Changeset: 67718c47 Branch: fibers Author: Alan Bateman Date: 2025-10-01 08:28:58 +0000 URL: https://git.openjdk.org/loom/commit/67718c47a85e0818e5fb59a859eb979bc05a2aa2 Fix typo ! loom-docs/CustomSchedulers.md Changeset: 5ae8cd09 Branch: fibers Author: Alan Bateman Date: 2025-10-02 06:21:34 +0000 URL: https://git.openjdk.org/loom/commit/5ae8cd09eb619308dc896eb4f939a292ac3bb9e2 Merge loom into fibers From duke at openjdk.org Thu Oct 2 07:03:38 2025 From: duke at openjdk.org (duke) Date: Thu, 2 Oct 2025 07:03:38 GMT Subject: git: openjdk/loom: master: 51 new changesets Message-ID: <66e3cb51-fba2-47df-85c1-43e0622b975a@openjdk.org> Changeset: e19ec6f7 Branch: master Author: Axel Boldt-Christmas Date: 2025-09-29 05:19:56 +0000 URL: https://git.openjdk.org/loom/commit/e19ec6f785e889d254b15c5ef2e801152c59c948 8368754: runtime/cds/appcds/SignedJar.java log regex is too strict Reviewed-by: iklam, dholmes ! test/hotspot/jtreg/runtime/cds/appcds/SignedJar.java Changeset: d53190ac Branch: master Author: Jan Lahoda Date: 2025-09-29 05:36:18 +0000 URL: https://git.openjdk.org/loom/commit/d53190ac4485e535f0a603036ecf47d4ff6e4178 8366582: Test jdk/jshell/ToolSimpleTest.java failed: provider not found Reviewed-by: asotona ! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java ! test/langtools/ProblemList.txt Changeset: 75269fdb Branch: master Author: Albert Mingkun Yang Date: 2025-09-29 07:26:43 +0000 URL: https://git.openjdk.org/loom/commit/75269fdb49aeb9d37acbbc1502c446a822fd30e3 8368715: Serial: Add GCTraceTime for marking from roots subphases during full gc marking Reviewed-by: fandreuzzi, tschatzl, iwalulya ! src/hotspot/share/gc/serial/serialFullGC.cpp Changeset: 08b677bb Branch: master Author: Thomas Schatzl Date: 2025-09-29 10:05:45 +0000 URL: https://git.openjdk.org/loom/commit/08b677bba4b1e23feb55b104d86fe0eef543d59c 8071277: G1: Merge commits and uncommits of contiguous memory Reviewed-by: iwalulya, ayang ! src/hotspot/share/gc/g1/g1NUMA.cpp ! src/hotspot/share/gc/g1/g1RegionToSpaceMapper.cpp ! src/hotspot/share/gc/g1/g1RegionToSpaceMapper.hpp Changeset: 61659214 Branch: master Author: Daniel Gredler Date: 2025-09-29 10:28:45 +0000 URL: https://git.openjdk.org/loom/commit/616592144939d80cae661bd4db26c976a035d543 7156751: [macosx] Problem with printing Reviewed-by: prr, serb ! src/java.desktop/macosx/native/libawt_lwawt/awt/CTextPipe.m ! test/jdk/java/awt/print/PrinterJob/PrintTextTest.java Changeset: fdbba049 Branch: master Author: Daniel Gredler Date: 2025-09-29 10:39:25 +0000 URL: https://git.openjdk.org/loom/commit/fdbba049a2491c591fc1a866e4707bf9aac50f17 8368775: Remove outdated comment in OutlineTextRenderer Reviewed-by: prr, dnguyen, serb ! src/java.desktop/share/classes/sun/java2d/pipe/OutlineTextRenderer.java Changeset: 9d9c0e06 Branch: master Author: Roger Riggs Date: 2025-09-29 13:55:49 +0000 URL: https://git.openjdk.org/loom/commit/9d9c0e06700116288233e3435051a1496cb64b72 8368793: java/lang/StringBuilder/RacingSBThreads.java timed out in Xcomp subtest Reviewed-by: iris, alanb, syan ! test/jdk/java/lang/StringBuilder/RacingSBThreads.java Changeset: 63688d89 Branch: master Author: Joe Darcy Date: 2025-09-29 14:48:04 +0000 URL: https://git.openjdk.org/loom/commit/63688d894e2157bb091be3aa62946f7e5830f384 8368822: Refactor Float16.valueOf(double) Reviewed-by: rgiulietti ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java Changeset: 9d71af10 Branch: master Author: Hamlin Li Date: 2025-09-29 16:04:54 +0000 URL: https://git.openjdk.org/loom/commit/9d71af108ea2cc3682607527246d60a19fd820ba 8367253: RISC-V: refactor dependent cpu extensions Reviewed-by: fyang, luhenry ! src/hotspot/cpu/riscv/vm_version_riscv.cpp ! src/hotspot/cpu/riscv/vm_version_riscv.hpp Changeset: aabf699d Branch: master Author: Brian Burkhalter Date: 2025-09-29 17:43:35 +0000 URL: https://git.openjdk.org/loom/commit/aabf699dd0f066efe6654db24b520068b256d855 8355339: Test java/io/File/GetCanonicalPath.java failed: The specified network name is no longer available Reviewed-by: alanb ! src/java.base/windows/native/libjava/canonicalize_md.c Changeset: 3d97e17a Branch: master Author: Chris Plummer Date: 2025-09-29 17:46:17 +0000 URL: https://git.openjdk.org/loom/commit/3d97e17a31c267161c2be87b551cdb118062ff57 8367318: Test vmTestbase/nsk/jdi/MethodEntryRequest/addClassFilter_rt/filter_rt001/TestDescription.java timed out after passing Reviewed-by: amenkov, sspitsyn ! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/EventHandler.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/TestDebuggerType1.java Changeset: 6c8e384c Branch: master Author: Chen Liang Date: 2025-09-29 18:22:24 +0000 URL: https://git.openjdk.org/loom/commit/6c8e384c63ac199a5f226b017ef5cd133130d1ac 8356022: Migrate descriptor parsing from generics to BytecodeDescriptor Reviewed-by: rriggs ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/sun/invoke/util/BytecodeDescriptor.java ! src/java.base/share/classes/sun/reflect/annotation/AnnotationParser.java + test/jdk/sun/invoke/util/BytecodeDescriptorTest.java Changeset: 59e76af4 Branch: master Author: Hannes Greule Date: 2025-09-29 18:40:43 +0000 URL: https://git.openjdk.org/loom/commit/59e76af47b23f582bbc21465a1871205d2499f28 8367967: C2: "fatal error: Not monotonic" with Mod nodes Co-authored-by: Christian Hagedorn Reviewed-by: bmaillard, vlivanov, chagedorn, shade ! src/hotspot/share/opto/divnode.cpp + test/hotspot/jtreg/compiler/ccp/TestModValueMonotonic.java Changeset: 2f29b3f2 Branch: master Author: Afshin Zafari Date: 2025-09-29 19:24:28 +0000 URL: https://git.openjdk.org/loom/commit/2f29b3f24a31bbe58d9c3433d46b69c16002694b 8366884: NMT fails with MallocLimit: reached category "mtCompiler" limit Reviewed-by: phubner, jsjolen ! test/hotspot/jtreg/runtime/NMT/MallocLimitTest.java Changeset: c57003c9 Branch: master Author: Alexey Semenyuk Date: 2025-09-29 21:39:42 +0000 URL: https://git.openjdk.org/loom/commit/c57003c9b837adb8671a0db636d9c576bd6a89b0 8368890: open/test/jdk/tools/jpackage/macosx/NameWithSpaceTest.java fails randomly Reviewed-by: almatvee ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacHelper.java Changeset: 538a722c Branch: master Author: Fei Yang Date: 2025-09-30 01:40:35 +0000 URL: https://git.openjdk.org/loom/commit/538a722c2e9123cc575355879ff230444cf2dadc 8368732: RISC-V: Detect support for misaligned vector access via hwprobe Reviewed-by: mli, dzhang ! src/hotspot/cpu/riscv/vm_version_riscv.cpp ! src/hotspot/cpu/riscv/vm_version_riscv.hpp ! src/hotspot/os_cpu/linux_riscv/riscv_hwprobe.cpp ! src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp Changeset: 89af6e13 Branch: master Author: Sergey Bylokhov Date: 2025-09-30 03:10:41 +0000 URL: https://git.openjdk.org/loom/commit/89af6e13f2354d6e32872791d157144cd478a88f 8362204: test/jdk/sun/awt/font/TestDevTransform.java fails on Ubuntu 24.04 Reviewed-by: avu, prr ! test/jdk/sun/awt/font/TestDevTransform.java Changeset: 2746c1a5 Branch: master Author: Anton Artemov Committer: Thomas Stuefe Date: 2025-09-30 05:09:33 +0000 URL: https://git.openjdk.org/loom/commit/2746c1a555891564963299182b3b0293eaefc901 8367485: os::physical_memory is broken in 32-bit JVMs when running on 64-bit OSes Reviewed-by: jsikstro, sgehwolf, stefank, stuefe, aph ! src/hotspot/os/aix/os_aix.cpp ! src/hotspot/os/aix/os_aix.hpp ! src/hotspot/os/bsd/os_bsd.cpp ! src/hotspot/os/bsd/os_bsd.hpp ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/os/linux/os_linux.hpp ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/os/windows/os_windows.hpp ! src/hotspot/share/compiler/compileBroker.cpp ! src/hotspot/share/gc/shared/gcInitLogger.cpp ! src/hotspot/share/gc/z/zLargePages.cpp ! src/hotspot/share/jfr/jni/jfrJniMethod.cpp ! src/hotspot/share/jfr/periodic/jfrPeriodic.cpp ! src/hotspot/share/prims/jvmtiRedefineClasses.cpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/os.cpp ! src/hotspot/share/runtime/os.hpp ! src/hotspot/share/services/heapDumper.cpp ! src/hotspot/share/utilities/globalDefinitions.hpp Changeset: c0a4c0ba Branch: master Author: Hamlin Li Date: 2025-09-30 08:11:02 +0000 URL: https://git.openjdk.org/loom/commit/c0a4c0ba97284d55cfdf857eb5d41fd6189e6c2d 8367981: Update CompactHashtable for readability Reviewed-by: iklam, matsaave ! src/hotspot/share/classfile/compactHashtable.cpp ! src/hotspot/share/classfile/compactHashtable.hpp Changeset: 586167cf Branch: master Author: Thomas Schatzl Date: 2025-09-30 08:49:08 +0000 URL: https://git.openjdk.org/loom/commit/586167cff5aaead0949c509f48bc5080834cc362 8363932: G1: Better distribute KlassCleaningTask Reviewed-by: ayang, coleenp ! src/hotspot/share/classfile/classLoaderData.hpp ! src/hotspot/share/classfile/classLoaderDataGraph.cpp ! src/hotspot/share/classfile/classLoaderDataGraph.hpp ! src/hotspot/share/gc/shared/parallelCleaning.cpp ! src/hotspot/share/gc/shared/parallelCleaning.hpp ! src/hotspot/share/oops/klass.cpp ! src/hotspot/share/oops/klass.hpp Changeset: aea71cca Branch: master Author: Afshin Zafari Date: 2025-09-30 08:54:53 +0000 URL: https://git.openjdk.org/loom/commit/aea71ccab7d21ae72564a07f74199eac14c7a958 8342730: Get rid of SummaryDiff in VMATree Reviewed-by: jsjolen, phubner ! src/hotspot/share/nmt/memoryFileTracker.cpp ! src/hotspot/share/nmt/regionsTree.cpp ! src/hotspot/share/nmt/regionsTree.hpp ! src/hotspot/share/nmt/virtualMemoryTracker.cpp ! src/hotspot/share/nmt/vmatree.cpp ! src/hotspot/share/nmt/vmatree.hpp ! test/hotspot/gtest/nmt/test_regions_tree.cpp ! test/hotspot/gtest/nmt/test_vmatree.cpp ! test/hotspot/gtest/runtime/test_virtualMemoryTracker.cpp Changeset: b19e8721 Branch: master Author: Markus Gr?nlund Date: 2025-09-30 10:35:23 +0000 URL: https://git.openjdk.org/loom/commit/b19e872192106f47c5d9b425230cc2bfe3e4786c 8362573: Incorrect weight of the first ObjectAllocationSample JFR event (regression) Reviewed-by: egahlin ! src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.cpp ! src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.hpp ! src/hotspot/share/jfr/recorder/service/jfrRecorderService.cpp ! src/hotspot/share/jfr/support/jfrAllocationTracer.cpp ! src/hotspot/share/jfr/support/jfrObjectAllocationSample.cpp ! src/hotspot/share/jfr/support/jfrObjectAllocationSample.hpp + test/jdk/jdk/jfr/event/allocation/TestObjectAllocationSampleEventInitialWeight.java Changeset: ba0a6eed Branch: master Author: Francesco Andreuzzi Committer: Albert Mingkun Yang Date: 2025-09-30 10:41:13 +0000 URL: https://git.openjdk.org/loom/commit/ba0a6eed1a6a22bd4c1d159592b62e054afa401a 8368357: Some source files have initial blank lines Reviewed-by: stefank, ayang, serb, jwaters, jpai ! src/hotspot/share/cds/dumpTimeClassInfo.inline.hpp ! src/hotspot/share/runtime/threads.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/services/threadIdTable.cpp ! src/hotspot/share/services/threadIdTable.hpp ! src/java.base/share/classes/sun/util/locale/UnicodeLocaleExtension.java ! src/java.desktop/share/classes/java/awt/image/LookupOp.java ! src/jdk.compiler/share/classes/com/sun/source/tree/UsesTree.java Changeset: 64c46d8e Branch: master Author: Yasumasa Suenaga Date: 2025-09-30 11:32:44 +0000 URL: https://git.openjdk.org/loom/commit/64c46d8efc27911b8667c3974275c075cf79a311 8367953: JFR sampler threads does not appear in thread dump Reviewed-by: mgronlun ! src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp ! src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp Changeset: 8606d3f8 Branch: master Author: Jan Lahoda Date: 2025-09-30 11:54:37 +0000 URL: https://git.openjdk.org/loom/commit/8606d3f8405b73878a1319ba3574ef69349aa2a1 8365060: Historical data for JDK 8 should include the jdk.net package Reviewed-by: shade, liach ! src/jdk.compiler/share/data/symbols/include.list ! src/jdk.compiler/share/data/symbols/java.base-8.sym.txt ! src/jdk.compiler/share/data/symbols/java.base-9.sym.txt ! src/jdk.compiler/share/data/symbols/java.desktop-8.sym.txt ! src/jdk.compiler/share/data/symbols/java.desktop-9.sym.txt ! src/jdk.compiler/share/data/symbols/java.xml.bind-9.sym.txt ! src/jdk.compiler/share/data/symbols/jdk.management-8.sym.txt ! src/jdk.compiler/share/data/symbols/jdk.management-9.sym.txt + src/jdk.compiler/share/data/symbols/jdk.net-8.sym.txt ! src/jdk.compiler/share/data/symbols/jdk.net-9.sym.txt ! src/jdk.compiler/share/data/symbols/symbols + test/langtools/tools/javac/platform/CompilationTest.java ! test/langtools/tools/javac/sym/ElementStructureTest.java Changeset: 444007fc Branch: master Author: Albert Mingkun Yang Date: 2025-09-30 12:27:22 +0000 URL: https://git.openjdk.org/loom/commit/444007fc234aeff75025831c2d1b5538c87fa8f1 8368842: Parallel: Refactor PCAddThreadRootsMarkingTaskClosure Reviewed-by: fandreuzzi, tschatzl ! src/hotspot/share/gc/parallel/psParallelCompact.cpp Changeset: 07ea907e Branch: master Author: Anass Baya Committer: Alexey Ivanov Date: 2025-09-30 13:57:07 +0000 URL: https://git.openjdk.org/loom/commit/07ea907e4fc8aa8fda01d8fe64c599f9d944eef9 8361606: ConsumeNextMnemonicKeyTypedTest.java fails on Windows: character typed with VK_A: a 8321303: Intermittent open/test/jdk/java/awt/KeyboardFocusmanager/ConsumeNextMnemonicKeyTypedTest/ConsumeNextMnemonicKeyTypedTest.java failure on Linux Reviewed-by: dnguyen, honkar, aivanov ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicPopupMenuUI.java ! test/jdk/ProblemList.txt ! test/jdk/java/awt/KeyboardFocusmanager/ConsumeNextMnemonicKeyTypedTest/ConsumeNextMnemonicKeyTypedTest.java Changeset: 8cc54ec6 Branch: master Author: Erik Gahlin Date: 2025-09-30 14:14:53 +0000 URL: https://git.openjdk.org/loom/commit/8cc54ec6b86fc5b80af02939363eccd8e3e899e7 8368563: JFR: Improve jfr query help text Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/internal/query/QueryPrinter.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/Query.java Changeset: 6b4b1020 Branch: master Author: Erik Gahlin Date: 2025-09-30 14:24:05 +0000 URL: https://git.openjdk.org/loom/commit/6b4b10200ed10365e1ae1ca02ade773ce5a108c3 8368809: JFR: Remove events from testSettingConfiguration in TestActiveSettingEvent Reviewed-by: mgronlun ! test/jdk/jdk/jfr/event/runtime/TestActiveSettingEvent.java Changeset: 07ecc93d Branch: master Author: Robbin Ehn Date: 2025-09-30 15:10:30 +0000 URL: https://git.openjdk.org/loom/commit/07ecc93dbd0b74e2362d369e22b5141289eb1f76 8367692: RISC-V: Align post call nop Reviewed-by: fyang, fjiang, mli ! src/hotspot/cpu/riscv/assembler_riscv.hpp ! src/hotspot/cpu/riscv/c1_LIRAssembler_riscv.cpp ! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp ! src/hotspot/cpu/riscv/nativeInst_riscv.cpp ! src/hotspot/cpu/riscv/nativeInst_riscv.hpp ! src/hotspot/cpu/riscv/riscv.ad ! src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp Changeset: fe9dbcc4 Branch: master Author: Francesco Andreuzzi Committer: Aleksey Shipilev Date: 2025-09-30 16:15:21 +0000 URL: https://git.openjdk.org/loom/commit/fe9dbcc496671a256c61ac52df5580569dbafb0a 8368599: ShenandoahConcurrentMark could use ThreadsClaimTokenScope Reviewed-by: ayang, shade, wkemper ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp Changeset: 9b02896b Branch: master Author: Mohamed Issa Committer: Srinivas Vamsi Parasa Date: 2025-09-30 21:08:06 +0000 URL: https://git.openjdk.org/loom/commit/9b02896b4725ef932a23be11ff76ce04bda0d652 8360558: Use hex literals instead of decimal literals in math intrinsic constants Reviewed-by: mhaessig, sparasa, jbhateja ! src/hotspot/cpu/x86/stubGenerator_x86_64_cbrt.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64_tanh.cpp Changeset: 0366d882 Branch: master Author: SendaoYan Date: 2025-10-01 00:52:30 +0000 URL: https://git.openjdk.org/loom/commit/0366d8823bc844225ca24964e352ce0a57d01683 8354894: java/lang/Thread/virtual/Starvation.java timeout on server with high CPUs Co-authored-by: Alan Bateman Reviewed-by: jpai ! test/jdk/java/lang/Thread/virtual/Starvation.java Changeset: 17d8fa8e Branch: master Author: Jaikiran Pai Date: 2025-10-01 01:40:06 +0000 URL: https://git.openjdk.org/loom/commit/17d8fa8e421db67027c9e7d2ddd634ff0b897cb6 8367026: Reorder the timeout failure handler commands to have jstack run before the rest Reviewed-by: erikj, lmesnik ! test/failure_handler/src/share/conf/common.properties Changeset: 8c3ca024 Branch: master Author: Kim Barrett Date: 2025-10-01 03:58:49 +0000 URL: https://git.openjdk.org/loom/commit/8c3ca024c770d3cf3b35234e967e5f0f0d610388 8368817: Convert JDK_Version::to_string to use stringStream instead of jio_snprintf-chain Reviewed-by: fandreuzzi, jsjolen ! src/hotspot/share/runtime/java.cpp Changeset: 394eb80a Branch: master Author: Kim Barrett Date: 2025-10-01 06:12:05 +0000 URL: https://git.openjdk.org/loom/commit/394eb80a48fa73238cf897087b99c3da5a616566 8368957: Remove metaprogramming/logical.hpp in favor of C++17 facilities Reviewed-by: mchevalier, iwalulya ! src/hotspot/share/gc/shared/workerUtils.hpp - src/hotspot/share/metaprogramming/logical.hpp - test/hotspot/gtest/metaprogramming/test_logical.cpp Changeset: 1188ca55 Branch: master Author: Thomas Schatzl Date: 2025-10-01 08:07:59 +0000 URL: https://git.openjdk.org/loom/commit/1188ca55f525554d2bb10691b368c818d98e5ea7 8368954: G1: Document why G1 uses TLS storage for the current card table reference Reviewed-by: ayang, rcastanedalo, iwalulya ! src/hotspot/share/gc/g1/g1ThreadLocalData.hpp Changeset: 6c2d3834 Branch: master Author: Thomas Schatzl Date: 2025-10-01 08:08:19 +0000 URL: https://git.openjdk.org/loom/commit/6c2d383492d194eb8a604a58a0336c371cbb1ea5 8368953: Document the reason why Serial/Parallel/G1 use zero as dirty card value Co-authored-by: Albert Mingkun Yang Reviewed-by: ayang, iwalulya ! src/hotspot/share/gc/shared/cardTable.hpp Changeset: f49849a5 Branch: master Author: Hamlin Li Date: 2025-10-01 08:22:02 +0000 URL: https://git.openjdk.org/loom/commit/f49849a5ed4e9383e39e69ce76bb8ea74fb443f9 8368893: RISC-V: crash after JDK-8352673 on fastdebug version Reviewed-by: fyang, dzhang ! src/hotspot/cpu/riscv/vm_version_riscv.cpp ! src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp Changeset: 84e5d63b Branch: master Author: Johan Sj?len Date: 2025-10-01 09:01:19 +0000 URL: https://git.openjdk.org/loom/commit/84e5d63b9fa8af0b35e1d682a81900cb157697fe 8368885: NMT CommandLine tests can check for error better Reviewed-by: phubner, azafari, shade ! test/hotspot/jtreg/runtime/NMT/CommandLineDetail.java ! test/hotspot/jtreg/runtime/NMT/CommandLineSummary.java Changeset: 5a2700f2 Branch: master Author: Richard Reingruber Date: 2025-10-01 09:26:43 +0000 URL: https://git.openjdk.org/loom/commit/5a2700f231d72e2241703c1d17b308f031e8566c 8368861: [TEST] compiler/floatingpoint/ScalarFPtoIntCastTest.java expects x86 IR on non-x86 platforms Reviewed-by: sviswanathan, mdoerr ! test/hotspot/jtreg/compiler/floatingpoint/ScalarFPtoIntCastTest.java Changeset: 3607e998 Branch: master Author: Jan Lahoda Date: 2025-10-01 11:16:44 +0000 URL: https://git.openjdk.org/loom/commit/3607e9986f1582ebdae1b6ad2a13c1a9c239e0d6 8367279: Test tools/javac/tree/TreePosTest.java timed out Reviewed-by: asotona ! test/langtools/tools/javac/tree/TreePosTest.java Changeset: c69456e8 Branch: master Author: Justin King Date: 2025-10-01 13:23:13 +0000 URL: https://git.openjdk.org/loom/commit/c69456e87aeb8653ce23bc7f579c254511bbf2d1 8368962: hotspot/cpu/aarch64/bytecodes_aarch64.{hpp,cpp} is unused Reviewed-by: aph, mhaessig - src/hotspot/cpu/aarch64/bytecodes_aarch64.cpp - src/hotspot/cpu/aarch64/bytecodes_aarch64.hpp Changeset: 182fbc2b Branch: master Author: Roberto Casta?eda Lozano Date: 2025-10-01 13:55:18 +0000 URL: https://git.openjdk.org/loom/commit/182fbc2b836d27410ccd0da512acb17bac9363c1 8368675: IGV: nodes are wrongly marked as changed in the difference view Reviewed-by: mchevalier, mhaessig, dfenacci, tholenstein ! src/utils/IdealGraphVisualizer/Data/src/main/java/com/sun/hotspot/igv/data/InputNode.java ! src/utils/IdealGraphVisualizer/Data/src/main/java/com/sun/hotspot/igv/data/serialization/Parser.java ! src/utils/IdealGraphVisualizer/Difference/src/main/java/com/sun/hotspot/igv/difference/Difference.java ! src/utils/IdealGraphVisualizer/Graph/src/main/java/com/sun/hotspot/igv/graph/Figure.java ! src/utils/IdealGraphVisualizer/View/src/main/java/com/sun/hotspot/igv/view/NodeQuickSearch.java Changeset: c54dcefb Branch: master Author: Francesco Andreuzzi Committer: Aleksey Shipilev Date: 2025-10-01 14:59:14 +0000 URL: https://git.openjdk.org/loom/commit/c54dcefbfd2eb44a569767740dc053813c4f6fe1 8368938: Remove ObjectWaiter::badObjectWaiterPtr Reviewed-by: shade, ayang ! src/hotspot/share/runtime/objectMonitor.hpp Changeset: e44ef0c3 Branch: master Author: Pavel Rappo Date: 2025-10-01 16:05:31 +0000 URL: https://git.openjdk.org/loom/commit/e44ef0c32b3c2fcd0a6293838d9185b6d0719219 8367704: Fix minor documentation issues in java.time.** Reviewed-by: naoto, rriggs ! src/java.base/share/classes/java/time/Duration.java ! src/java.base/share/classes/java/time/Instant.java ! src/java.base/share/classes/java/time/Period.java ! src/java.base/share/classes/java/time/ZoneOffset.java ! src/java.base/share/classes/java/time/ZonedDateTime.java ! src/java.base/share/classes/java/time/package-info.java ! src/java.base/share/classes/java/time/temporal/ChronoField.java ! src/java.base/share/classes/java/time/temporal/ValueRange.java Changeset: 6b72b778 Branch: master Author: Justin Lu Date: 2025-10-01 17:57:43 +0000 URL: https://git.openjdk.org/loom/commit/6b72b778039afce0e25986114d15dd29a6786529 6177299: [Fmt-Nu] NumberFormat.getPercentInstance() does not work correctly Reviewed-by: naoto ! src/java.base/share/classes/java/text/DecimalFormat.java ! test/jdk/java/text/Format/NumberFormat/NumberRegression.java Changeset: ef724f40 Branch: master Author: Joe Darcy Date: 2025-10-01 19:56:05 +0000 URL: https://git.openjdk.org/loom/commit/ef724f40c1f3cdddd215d50edf512bb06825085d 8368985: Small Float16 refactorings Reviewed-by: rgiulietti, jbhateja ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java ! test/jdk/jdk/incubator/vector/BasicFloat16ArithTests.java Changeset: db6320df Branch: master Author: Johannes Graham Committer: Raffaello Giulietti Date: 2025-10-01 20:00:43 +0000 URL: https://git.openjdk.org/loom/commit/db6320df980ebe7cf2a1c727970cc937ab549b97 8368968: FloatingDecimal: Clean up unused code Reviewed-by: rgiulietti ! src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java Changeset: 4df41d2a Branch: master Author: Igor Veresov Date: 2025-10-01 23:15:13 +0000 URL: https://git.openjdk.org/loom/commit/4df41d2a751e2942c2188ed01313d78e681835bc 8368698: runtime/cds/appcds/aotCache/OldClassSupport.java assert(can_add()) failed: Cannot add TrainingData objects Reviewed-by: heidinga, iklam ! src/hotspot/share/oops/trainingData.cpp Changeset: fa3af820 Branch: master Author: Boris Ulasevich Date: 2025-10-01 23:49:03 +0000 URL: https://git.openjdk.org/loom/commit/fa3af820ad310704e8d25cf496f676e09d60797d 8338197: [ubsan] ad_x86.hpp:6417:11: runtime error: shift exponent 100 is too large for 32-bit type 'unsigned int' Reviewed-by: kvn, dlong ! src/hotspot/share/adlc/output_h.cpp From pedro.lamarao at prodist.com.br Thu Oct 2 17:29:25 2025 From: pedro.lamarao at prodist.com.br (=?UTF-8?Q?Pedro_Lamar=C3=A3o?=) Date: Thu, 2 Oct 2025 14:29:25 -0300 Subject: Problem report on the usage of Structured Concurrency (5th preview) In-Reply-To: <7D941AAE-5168-4BE2-9A14-A8F5C0FF132D@warski.org> References: <85467C61-8139-4832-B3BA-BFA53061E986@warski.org> <51868ca8-ec63-4c2e-ba2d-a7f0f1df6954@oracle.com> <7D941AAE-5168-4BE2-9A14-A8F5C0FF132D@warski.org> Message-ID: Em qua., 1 de out. de 2025 ?s 03:38, Adam Warski escreveu: > >> Well if scope.join() waits until all forks complete, it will only do so > when there are no forks left, and then nobody can create new forks? So I > don?t think there?s a race here? In other words, forks can only be created > from live forks, before they complete. > > That's right but allowing this (as it was in early previews) creates > weirdness where a subtask can fork it cannot join. It also messes with the > mental model of "parent". Who is my parent when I'm forked by a sibling? > > > > If the problem has been arranged so that subtask opens a new scope and > decomposes into a set of sub-subtasks forked in this scope, thus creating a > hierarchy, then it becomes simpler to reason about. > > Absolutely, if you can correctly solve your problem using nested scopes, > that?s the way to go! Full agreement here :) > > However, the forks-in-forks is one solution or work-around for the problem > of having complex, or blocking logic in the scope?s body, and wanting that > logic to participate in the same error handling (interrupt when scope is > cancelled) as the forks. > I fail to understand this; I have not tested STS extensively. Is it not the case that an inner scope will be cancelled when its parent scope is cancelled? The forked subtask would be joining the inner scope; will this inner join not be cancelled when the outer join is cancelled? In what sense does an inner scope not participate in the same error handling as the outer scope? -- Pedro Lamar?o -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Fri Oct 3 06:38:07 2025 From: duke at openjdk.org (duke) Date: Fri, 3 Oct 2025 06:38:07 GMT Subject: git: openjdk/loom: fibers: 2 new changesets Message-ID: Changeset: 4f883ab3 Branch: fibers Author: Alan Bateman Date: 2025-10-02 18:44:53 +0000 URL: https://git.openjdk.org/loom/commit/4f883ab30d42b0f2beb9ee31a5df65cff7788023 Threads should not call Subtask::get before owner has joined ! loom-docs/StructuredConcurrent-updates.md ! src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java ! src/java.base/share/classes/java/util/concurrent/StructuredTaskScopeImpl.java ! test/jdk/java/util/concurrent/StructuredTaskScope/StructuredTaskScopeTest.java Changeset: 0822a2af Branch: fibers Author: Alan Bateman Date: 2025-10-03 07:34:23 +0000 URL: https://git.openjdk.org/loom/commit/0822a2af7b189136603cce26ef866f099b40a925 Sync up FJP from pull/26479 ! src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java From duke at openjdk.org Sat Oct 4 13:06:09 2025 From: duke at openjdk.org (duke) Date: Sat, 4 Oct 2025 13:06:09 GMT Subject: git: openjdk/loom: fibers: 33 new changesets Message-ID: <265df0b6-2272-498e-98d8-e1bdd6bcb007@openjdk.org> Changeset: 5251405c Branch: fibers Author: Jan Lahoda Date: 2025-10-02 06:52:59 +0000 URL: https://git.openjdk.org/loom/commit/5251405ce9ab1cbd84b798a538cb3865ea4675e9 8368848: JShell's code completion not always working for multi-snippet inputs Reviewed-by: asotona ! src/jdk.jshell/share/classes/jdk/jshell/OuterWrapMap.java ! src/jdk.jshell/share/classes/jdk/jshell/SnippetMaps.java ! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java ! test/langtools/jdk/jshell/CompletionSuggestionTest.java Changeset: dfd38322 Branch: fibers Author: Francesco Andreuzzi Committer: Albert Mingkun Yang Date: 2025-10-02 08:58:54 +0000 URL: https://git.openjdk.org/loom/commit/dfd383224dbc2e41c9f44b1acd09ffb179cc38f3 8368966: Remove spurious VMStructs friends Reviewed-by: stefank, ayang ! src/hotspot/share/ci/ciObjectFactory.hpp ! src/hotspot/share/classfile/compactHashtable.hpp ! src/hotspot/share/code/codeBlob.hpp ! src/hotspot/share/code/dependencyContext.hpp ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/compiler/abstractCompiler.hpp ! src/hotspot/share/compiler/oopMap.hpp ! src/hotspot/share/gc/epsilon/epsilonBarrierSet.hpp ! src/hotspot/share/gc/epsilon/epsilonMonitoringSupport.cpp ! src/hotspot/share/gc/g1/g1Allocator.hpp ! src/hotspot/share/gc/g1/g1BarrierSet.hpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.hpp ! src/hotspot/share/gc/g1/g1CardTable.hpp ! src/hotspot/share/gc/g1/g1ConcurrentMarkThread.hpp ! src/hotspot/share/gc/g1/g1ConcurrentRefineThread.hpp ! src/hotspot/share/gc/g1/g1HeapRegionRemSet.hpp ! src/hotspot/share/gc/g1/g1PageBasedVirtualSpace.hpp ! src/hotspot/share/gc/parallel/mutableNUMASpace.hpp ! src/hotspot/share/gc/serial/cSpaceCounters.hpp ! src/hotspot/share/gc/shared/collectorCounters.hpp ! src/hotspot/share/gc/shared/gcPolicyCounters.hpp ! src/hotspot/share/gc/shared/generationCounters.hpp ! src/hotspot/share/gc/shared/hSpaceCounters.hpp ! src/hotspot/share/gc/shared/scavengableNMethods.hpp ! src/hotspot/share/gc/shared/stringdedup/stringDedupThread.hpp ! src/hotspot/share/gc/shenandoah/shenandoahCardTable.hpp ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.hpp ! src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.hpp ! src/hotspot/share/gc/shenandoah/shenandoahRegulatorThread.hpp ! src/hotspot/share/interpreter/templateInterpreter.hpp ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.hpp ! src/hotspot/share/interpreter/zero/zeroInterpreter.hpp ! src/hotspot/share/memory/heap.hpp ! src/hotspot/share/memory/metaspaceCounters.cpp ! src/hotspot/share/oops/instanceClassLoaderKlass.hpp ! src/hotspot/share/oops/instanceMirrorKlass.hpp ! src/hotspot/share/oops/instanceStackChunkKlass.hpp ! src/hotspot/share/opto/matcher.hpp ! src/hotspot/share/opto/parse.hpp ! src/hotspot/share/runtime/java.hpp ! src/hotspot/share/runtime/monitorDeflationThread.hpp ! src/hotspot/share/runtime/nonJavaThread.hpp ! src/hotspot/share/runtime/notificationThread.hpp ! src/hotspot/share/runtime/os.hpp ! src/hotspot/share/runtime/serviceThread.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/utilities/growableArray.hpp Changeset: 8be16160 Branch: fibers Author: Francesco Andreuzzi Committer: Kevin Walls Date: 2025-10-02 11:41:30 +0000 URL: https://git.openjdk.org/loom/commit/8be16160d2a6275ff619ea4cebb725475c646052 8367609: serviceability/sa/ClhsdbPmap.java fails when built with Clang Reviewed-by: kevinw, cjplummer ! src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c Changeset: cc563c87 Branch: fibers Author: SendaoYan Date: 2025-10-02 12:37:27 +0000 URL: https://git.openjdk.org/loom/commit/cc563c87cd277fbc96fb77af1e99f6c018ccc020 8368866: compiler/codecache/stress/UnexpectedDeoptimizationTest.java intermittent timed out Reviewed-by: shade, mhaessig ! test/hotspot/jtreg/compiler/codecache/stress/UnexpectedDeoptimizationTest.java Changeset: 56baf64a Branch: fibers Author: Daniel Jeli?ski Date: 2025-10-02 13:29:45 +0000 URL: https://git.openjdk.org/loom/commit/56baf64ada04f233fbfe4e0cd033c86183e22015 8368520: TLS 1.3 KeyUpdate fails with SunPKCS11 provider Reviewed-by: valeriep ! src/java.base/share/classes/sun/security/ssl/SSLTrafficKeyDerivation.java ! test/jdk/sun/security/pkcs11/tls/fips/FipsModeTLS.java Changeset: 2c7f7380 Branch: fibers Author: Shaojin Wen Date: 2025-10-02 13:32:09 +0000 URL: https://git.openjdk.org/loom/commit/2c7f7380ea828e5ec928e1cb05b13806646ecb3d 8368825: Use switch expression for DateTimeFormatterBuilder pattern character lookup Reviewed-by: rriggs, naoto, scolebourne ! src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java Changeset: 52522623 Branch: fibers Author: Casper Norrbin Date: 2025-10-02 13:38:41 +0000 URL: https://git.openjdk.org/loom/commit/5252262349cccb09f693ebd431fe2987ec0917f0 8292984: Refactor internal container-related interfaces for clarity Reviewed-by: sgehwolf, eosterlund ! src/hotspot/os/linux/cgroupSubsystem_linux.cpp ! src/hotspot/os/linux/cgroupSubsystem_linux.hpp ! src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp ! src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp ! src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp ! src/hotspot/os/linux/cgroupV2Subsystem_linux.hpp ! src/hotspot/os/linux/osContainer_linux.cpp ! src/hotspot/os/linux/osContainer_linux.hpp ! src/hotspot/os/linux/os_linux.cpp Changeset: 7ad9bdef Branch: fibers Author: Daniel Fuchs Date: 2025-10-02 15:19:26 +0000 URL: https://git.openjdk.org/loom/commit/7ad9bdef1ed250a824ee9dee69b37bbcc8f7c924 8368630: java/net/httpclient/http3/H3ServerPushTest.java succeeds but fails in jtreg timeout Reviewed-by: syan, jpai ! test/jdk/java/net/httpclient/http3/H3ServerPushTest.java Changeset: 1a03a1fb Branch: fibers Author: Igor Veresov Date: 2025-10-02 15:38:51 +0000 URL: https://git.openjdk.org/loom/commit/1a03a1fbb1c7a83469128106341591c59428437a 8369033: Remove dead code in training data Reviewed-by: rcastanedalo, kvn ! src/hotspot/share/oops/trainingData.cpp ! src/hotspot/share/oops/trainingData.hpp Changeset: 5fccabff Branch: fibers Author: Erik Gahlin Date: 2025-10-02 15:51:46 +0000 URL: https://git.openjdk.org/loom/commit/5fccabff15ae8bcc3d03156fa331bbc0fefb0cbe 8368670: Deadlock in JFR on event register + class load Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/internal/MetadataRepository.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/SettingsManager.java Changeset: 3d113af9 Branch: fibers Author: Joe Darcy Date: 2025-10-02 16:43:01 +0000 URL: https://git.openjdk.org/loom/commit/3d113af9e33ddf3d80452cb72f1b47b4936ec6a0 8369051: More small Float16 refactorings Reviewed-by: rgiulietti ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java Changeset: 1d55adee Branch: fibers Author: Francesco Andreuzzi Committer: Paul Hohensee Date: 2025-10-02 18:49:00 +0000 URL: https://git.openjdk.org/loom/commit/1d55adee11fc2fdbf2e009e1308b763fd7217dad 8368989: Use NMethodMarkingScope and ThreadsClaimTokenScope in shenandoahSTWMark Reviewed-by: shade, ayang ! src/hotspot/share/gc/shenandoah/shenandoahSTWMark.cpp Changeset: 3f27a03b Branch: fibers Author: Ioi Lam Date: 2025-10-02 20:00:58 +0000 URL: https://git.openjdk.org/loom/commit/3f27a03bba4760694a276376d08fb1ba97d08f7e 8368727: CDS custom loader support causes asserts during class unloading Reviewed-by: coleenp, dholmes ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/oops/klass.cpp ! test/hotspot/jtreg/runtime/cds/appcds/customLoader/UnloadUnregisteredLoaderTest.java ! test/hotspot/jtreg/runtime/cds/appcds/customLoader/test-classes/CustomLoadee5.java ! test/hotspot/jtreg/runtime/cds/appcds/customLoader/test-classes/UnloadUnregisteredLoader.java Changeset: fa6e8841 Branch: fibers Author: Damon Nguyen Date: 2025-10-02 22:09:14 +0000 URL: https://git.openjdk.org/loom/commit/fa6e884105ac247b3b83a5a2329f9c18888bd7d0 8298823: [macos] java/awt/Mouse/EnterExitEvents/DragWindowTest.java continues to fail with "No MouseReleased event on label!" Reviewed-by: aivanov, azvegint ! test/jdk/ProblemList.txt ! test/jdk/java/awt/Mouse/EnterExitEvents/DragWindowTest.java Changeset: da7121af Branch: fibers Author: Dean Long Date: 2025-10-02 22:21:13 +0000 URL: https://git.openjdk.org/loom/commit/da7121aff9eccb046b82a75093034f1cdbd9b9e4 8366461: Remove obsolete method handle invoke logic Reviewed-by: vlivanov, mhaessig ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/c1_FrameMap_aarch64.cpp ! src/hotspot/cpu/aarch64/frame_aarch64.cpp ! src/hotspot/cpu/aarch64/frame_aarch64.hpp ! src/hotspot/cpu/aarch64/frame_aarch64.inline.hpp ! src/hotspot/cpu/arm/arm.ad ! src/hotspot/cpu/arm/arm_32.ad ! src/hotspot/cpu/arm/c1_FrameMap_arm.cpp ! src/hotspot/cpu/arm/c1_Runtime1_arm.cpp ! src/hotspot/cpu/arm/frame_arm.cpp ! src/hotspot/cpu/arm/frame_arm.hpp ! src/hotspot/cpu/arm/frame_arm.inline.hpp ! src/hotspot/cpu/arm/register_arm.hpp ! src/hotspot/cpu/arm/runtime_arm.cpp ! src/hotspot/cpu/ppc/c1_FrameMap_ppc.cpp ! src/hotspot/cpu/ppc/ppc.ad ! src/hotspot/cpu/riscv/c1_FrameMap_riscv.cpp ! src/hotspot/cpu/riscv/frame_riscv.cpp ! src/hotspot/cpu/riscv/frame_riscv.hpp ! src/hotspot/cpu/riscv/frame_riscv.inline.hpp ! src/hotspot/cpu/riscv/riscv.ad ! src/hotspot/cpu/s390/c1_FrameMap_s390.cpp ! src/hotspot/cpu/s390/s390.ad ! src/hotspot/cpu/x86/c1_FrameMap_x86.cpp ! src/hotspot/cpu/x86/frame_x86.cpp ! src/hotspot/cpu/x86/frame_x86.hpp ! src/hotspot/cpu/x86/frame_x86.inline.hpp ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/os/posix/signals_posix.cpp ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/share/asm/codeBuffer.hpp ! src/hotspot/share/c1/c1_Compilation.cpp ! src/hotspot/share/c1/c1_Compilation.hpp ! src/hotspot/share/c1/c1_FrameMap.hpp ! src/hotspot/share/c1/c1_IR.cpp ! src/hotspot/share/c1/c1_IR.hpp ! src/hotspot/share/c1/c1_LIR.cpp ! src/hotspot/share/c1/c1_LIR.hpp ! src/hotspot/share/c1/c1_LIRAssembler.cpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/c1/c1_Runtime1.cpp ! src/hotspot/share/code/debugInfoRec.cpp ! src/hotspot/share/code/debugInfoRec.hpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/code/nmethod.inline.hpp ! src/hotspot/share/code/pcDesc.hpp ! src/hotspot/share/jvmci/jvmciCodeInstaller.cpp ! src/hotspot/share/jvmci/jvmciCodeInstaller.hpp ! src/hotspot/share/jvmci/jvmciRuntime.cpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/hotspot/share/opto/callGenerator.cpp ! src/hotspot/share/opto/callnode.hpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/opto/lcm.cpp ! src/hotspot/share/opto/machnode.cpp ! src/hotspot/share/opto/machnode.hpp ! src/hotspot/share/opto/matcher.cpp ! src/hotspot/share/opto/matcher.hpp ! src/hotspot/share/opto/output.cpp ! src/hotspot/share/opto/runtime.cpp ! src/hotspot/share/runtime/deoptimization.cpp ! src/hotspot/share/runtime/frame.cpp ! src/hotspot/share/runtime/frame.inline.hpp ! src/hotspot/share/runtime/javaThread.cpp ! src/hotspot/share/runtime/javaThread.hpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/NMethod.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/PCDesc.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Frame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/aarch64/AARCH64Frame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64Frame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/riscv64/RISCV64Frame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/x86/X86Frame.java Changeset: 854b384b Branch: fibers Author: Alex Menkov Date: 2025-10-02 23:39:37 +0000 URL: https://git.openjdk.org/loom/commit/854b384b120fa2af41adca3048070866fe3cafd4 8304811: vmTestbase/vm/mlvm/indy/func/jvmti/stepBreakPopReturn/INDIFY_Test.java fails with JVMTI_ERROR_TYPE_MISMATCH Reviewed-by: lmesnik, dholmes, sspitsyn ! test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/func/jvmti/stepBreakPopReturn/stepBreakPopReturn.cpp Changeset: f62b9eca Branch: fibers Author: Ashutosh Mehra Date: 2025-10-03 02:43:14 +0000 URL: https://git.openjdk.org/loom/commit/f62b9eca08694bbbe80d9e7d7b704db4f2423830 8364929: Assign unique id to each AdapterBlob stored in AOTCodeCache Reviewed-by: kvn, iklam ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp Changeset: 3790965d Branch: fibers Author: Joe Wang Date: 2025-10-03 03:50:01 +0000 URL: https://git.openjdk.org/loom/commit/3790965df3e7cba3b9792b8719d1e2ead046da15 8336695: Update Commons BCEL to Version 6.10.0 Reviewed-by: lancea, naoto, iris ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/Const.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/ExceptionConst.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/Repository.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/AccessFlags.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/AnnotationEntry.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/Annotations.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ArrayElementValue.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/Attribute.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/BootstrapMethod.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/BootstrapMethods.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ClassFormatException.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ClassParser.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/Code.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/CodeException.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/Constant.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantCP.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantDouble.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantFloat.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantInteger.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantLong.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantObject.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantPool.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantUtf8.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantValue.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/Deprecated.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/DescendingVisitor.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ElementValue.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/EmptyVisitor.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ExceptionTable.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/Field.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/FieldOrMethod.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/InnerClass.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/InnerClasses.java + src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/InvalidMethodSignatureException.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/JavaClass.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/LineNumber.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/LineNumberTable.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/LocalVariableTable.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/LocalVariableTypeTable.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/Method.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/MethodParameter.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/MethodParameters.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/Module.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ModuleExports.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ModuleMainClass.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ModuleOpens.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ModulePackages.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ModuleProvides.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ModuleRequires.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/NestMembers.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/Node.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/PMGClass.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ParameterAnnotationEntry.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ParameterAnnotations.java + src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/Record.java + src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/RecordComponentInfo.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/RuntimeInvisibleAnnotations.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/RuntimeInvisibleParameterAnnotations.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/RuntimeVisibleAnnotations.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/RuntimeVisibleParameterAnnotations.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/Signature.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/SimpleElementValue.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/SourceFile.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/StackMap.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/StackMapEntry.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/StackMapType.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/Synthetic.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/Utility.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/Visitor.java + src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/package-info.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/ARRAYLENGTH.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/ATHROW.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/AnnotationEntryGen.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/ArrayElementValueGen.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/ArrayType.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/BranchHandle.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/CPInstruction.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/ClassElementValueGen.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/ClassGen.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/CodeExceptionGen.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/ElementValuePairGen.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/EnumElementValueGen.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/ExceptionThrower.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/FieldGen.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/FieldGenOrMethodGen.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/FieldOrMethod.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/ICONST.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/INVOKEDYNAMIC.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/Instruction.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/InstructionConst.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/InstructionFactory.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/InstructionHandle.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/InstructionList.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/InstructionTargeter.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/LCMP.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/LDC.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/LineNumberGen.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/LocalVariableGen.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/LocalVariableInstruction.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/MethodGen.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/ObjectType.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/RET.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/ReferenceType.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/SWITCH.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/Select.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/SimpleElementValueGen.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/TargetLostException.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/Type.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/TypedInstruction.java + src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/package-info.java + src/java.xml/share/classes/com/sun/org/apache/bcel/internal/package-info.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/util/BCELComparator.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/util/BCELFactory.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/util/BCELifier.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/util/Class2HTML.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/util/ClassSet.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/util/CodeHTML.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/util/InstructionFinder.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/util/Repository.java + src/java.xml/share/classes/com/sun/org/apache/bcel/internal/util/package-info.java ! src/java.xml/share/classes/jdk/xml/internal/Utils.java ! src/java.xml/share/legal/bcel.md Changeset: ebb6fd7d Branch: fibers Author: Mikhail Yankelevich Date: 2025-10-03 07:37:17 +0000 URL: https://git.openjdk.org/loom/commit/ebb6fd7d7865fd20ff2f90b4ef72c5ef6a3e5dea 8360562: sun/security/tools/keytool/i18n.java add an ability to add comment for failures Reviewed-by: rhalade ! test/jdk/sun/security/tools/keytool/i18n.java Changeset: 2e783963 Branch: fibers Author: Mar?a Arias de Reyna Dom?nguez Committer: Roland Westrelin Date: 2025-10-03 07:57:24 +0000 URL: https://git.openjdk.org/loom/commit/2e783963d21c8edd88e79226ca473cfe0e41335b 8369037: Identify owning method for MethodData and MethodCounters in AOT map output Reviewed-by: iklam, asmehra, adinn, macarte ! src/hotspot/share/cds/aotMapLogger.cpp ! src/hotspot/share/cds/aotMapLogger.hpp Changeset: 134b63f0 Branch: fibers Author: Yuri Gaevsky Committer: Vladimir Kempik Date: 2025-10-03 09:44:56 +0000 URL: https://git.openjdk.org/loom/commit/134b63f0e8c4093f7ad0a528d6996898ab881d5c 8322174: RISC-V: C2 VectorizedHashCode RVV Version Reviewed-by: fyang, rehn ! src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp ! src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.hpp ! src/hotspot/cpu/riscv/riscv.ad ! src/hotspot/cpu/riscv/riscv_v.ad ! src/hotspot/cpu/riscv/stubDeclarations_riscv.hpp ! src/hotspot/cpu/riscv/stubGenerator_riscv.cpp Changeset: 72319167 Branch: fibers Author: Beno?t Maillard Committer: Manuel H?ssig Date: 2025-10-03 10:40:50 +0000 URL: https://git.openjdk.org/loom/commit/72319167543a28295276f11178c17bef6680c32f 8364757: Missing Store nodes caused by bad wiring in PhaseIdealLoop::insert_post_loop Reviewed-by: mhaessig, roland ! src/hotspot/share/opto/loopTransform.cpp ! src/hotspot/share/opto/loopnode.hpp + test/hotspot/jtreg/compiler/loopstripmining/MissingStoreAfterOuterStripMinedLoop.java Changeset: f81c7c59 Branch: fibers Author: Hannes Walln?fer Date: 2025-10-03 15:53:37 +0000 URL: https://git.openjdk.org/loom/commit/f81c7c592bbc9f5575ed41e41d12f54cbfc5e4aa 8276966: Improve diagnostic output for the mismatching parts of a hybrid snippet Reviewed-by: prappo ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/taglets/SnippetTaglet.java ! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java Changeset: 23a65644 Branch: fibers Author: Justin Lu Date: 2025-10-03 16:25:55 +0000 URL: https://git.openjdk.org/loom/commit/23a65644ae63b271ca99c55a2a60a192c4e4dfb8 8368981: Case Fold Locale Legacy Tags On Demand Reviewed-by: rriggs, naoto ! src/java.base/share/classes/sun/util/locale/LanguageTag.java ! test/jdk/java/util/Locale/CaseFoldLanguageTagTest.java Changeset: aee73d35 Branch: fibers Author: Harshitha Onkar Date: 2025-10-03 17:32:51 +0000 URL: https://git.openjdk.org/loom/commit/aee73d3568fbcb2fe7293f92154e6677c080d20c 8365424: [macos26] java/awt/Frame/DisposeTest.java fails on macOS 26 Reviewed-by: serb, azvegint ! test/jdk/java/awt/Frame/DisposeTest.java Changeset: 0935b76c Branch: fibers Author: Mikael Vidstedt Date: 2025-10-03 17:40:37 +0000 URL: https://git.openjdk.org/loom/commit/0935b76c6bd1fbfa0a431eedb54c51f6fe4d194e 8369080: Use uname -m for devkit cpu detection Reviewed-by: iris, erikj ! make/devkit/Makefile Changeset: 0e98ec36 Branch: fibers Author: Sergey Bylokhov Committer: Harshitha Onkar Date: 2025-10-03 17:49:59 +0000 URL: https://git.openjdk.org/loom/commit/0e98ec36623d5d83172209058574a97bab1d6038 8367384: The ICC_Profile class may throw exceptions during serialization Reviewed-by: honkar, prr ! src/java.desktop/share/classes/java/awt/color/ICC_Profile.java + test/jdk/java/awt/color/ICC_Profile/Serialization/SerializationSpecTest/SerializationSpecTest.java + test/jdk/java/awt/color/ICC_Profile/Serialization/SerializationSpecTest/empty.ser + test/jdk/java/awt/color/ICC_Profile/Serialization/SerializationSpecTest/invalid.ser + test/jdk/java/awt/color/ICC_Profile/Serialization/SerializationSpecTest/invalid_invalid.ser + test/jdk/java/awt/color/ICC_Profile/Serialization/SerializationSpecTest/invalid_null.ser + test/jdk/java/awt/color/ICC_Profile/Serialization/SerializationSpecTest/invalid_valid.ser + test/jdk/java/awt/color/ICC_Profile/Serialization/SerializationSpecTest/invalid_wrongType.ser + test/jdk/java/awt/color/ICC_Profile/Serialization/SerializationSpecTest/null.ser + test/jdk/java/awt/color/ICC_Profile/Serialization/SerializationSpecTest/null_invalid.ser + test/jdk/java/awt/color/ICC_Profile/Serialization/SerializationSpecTest/null_null.ser = test/jdk/java/awt/color/ICC_Profile/Serialization/SerializationSpecTest/null_valid.ser + test/jdk/java/awt/color/ICC_Profile/Serialization/SerializationSpecTest/null_wrongType.ser + test/jdk/java/awt/color/ICC_Profile/Serialization/SerializationSpecTest/valid.ser = test/jdk/java/awt/color/ICC_Profile/Serialization/SerializationSpecTest/valid_invalid.ser = test/jdk/java/awt/color/ICC_Profile/Serialization/SerializationSpecTest/valid_null.ser + test/jdk/java/awt/color/ICC_Profile/Serialization/SerializationSpecTest/valid_valid.ser + test/jdk/java/awt/color/ICC_Profile/Serialization/SerializationSpecTest/valid_wrongType.ser + test/jdk/java/awt/color/ICC_Profile/Serialization/SerializationSpecTest/wrongType.ser + test/jdk/java/awt/color/ICC_Profile/Serialization/SerializationSpecTest/wrongType_invalid.ser + test/jdk/java/awt/color/ICC_Profile/Serialization/SerializationSpecTest/wrongType_null.ser + test/jdk/java/awt/color/ICC_Profile/Serialization/SerializationSpecTest/wrongType_valid.ser + test/jdk/java/awt/color/ICC_Profile/Serialization/SerializationSpecTest/wrongType_wrongType.ser + test/jdk/java/awt/color/ICC_Profile/Serialization/StandardProfilesRoundTrip.java ! test/jdk/java/awt/color/ICC_Profile/ValidateICCHeaderData/ValidateICCHeaderData.java Changeset: 012e079d Branch: fibers Author: Roger Riggs Date: 2025-10-03 18:45:34 +0000 URL: https://git.openjdk.org/loom/commit/012e079d11b629ddda8d5f687fd43ef21d210466 8356202: Cleanup Source code in String Implementation Classes Reviewed-by: jpai, rgiulietti, liach ! src/java.base/share/classes/java/lang/StringLatin1.java ! src/java.base/share/classes/java/lang/StringUTF16.java Changeset: 837f634b Branch: fibers Author: Daniel D. Daugherty Date: 2025-10-03 21:11:33 +0000 URL: https://git.openjdk.org/loom/commit/837f634bf29fd877dd62a2e0f7d7a1bd383372d3 8369128: ProblemList jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs 8369132: Disable vmTestbase/gc/vector/CircularListLow and LinearListLow with SerialGC 8369133: Disable gc/g1/TestShrinkAuxiliaryDataRunner.java with UseLargePages option Reviewed-by: ayang, dholmes ! test/hotspot/jtreg/gc/g1/TestShrinkAuxiliaryDataRunner.java ! test/hotspot/jtreg/vmTestbase/gc/vector/CircularListLow/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/vector/LinearListLow/TestDescription.java ! test/jdk/ProblemList-Xcomp.txt Changeset: e6868c62 Branch: fibers Author: Daniel D. Daugherty Date: 2025-10-03 22:17:01 +0000 URL: https://git.openjdk.org/loom/commit/e6868c624851d5c6bd182e45ba908cb06b731e8c 8369138: New test compiler/loopstripmining/MissingStoreAfterOuterStripMinedLoop.java fails Reviewed-by: kvn ! test/hotspot/jtreg/compiler/loopstripmining/MissingStoreAfterOuterStripMinedLoop.java Changeset: c3fbbfab Branch: fibers Author: Sergey Bylokhov Date: 2025-10-03 23:16:41 +0000 URL: https://git.openjdk.org/loom/commit/c3fbbfabcc9a9535a3b422c1c9afaa8e092a5da0 8369027: Apply java.io.Serial annotations in java.scripting Reviewed-by: rriggs ! src/java.scripting/share/classes/javax/script/ScriptException.java Changeset: 76dba201 Branch: fibers Author: Jaikiran Pai Date: 2025-10-04 08:09:09 +0000 URL: https://git.openjdk.org/loom/commit/76dba201fa1a525780677e4d3dee8e9ffafd1cd7 8368821: Test java/net/httpclient/http3/GetHTTP3Test.java intermittently fails with java.io.IOException: QUIC endpoint closed Reviewed-by: dfuchs ! test/jdk/java/net/httpclient/http3/GetHTTP3Test.java ! test/jdk/java/net/httpclient/http3/PostHTTP3Test.java Changeset: 6521aaa8 Branch: fibers Author: Alan Bateman Date: 2025-10-04 11:48:40 +0000 URL: https://git.openjdk.org/loom/commit/6521aaa8322fb17b84de0e6208f784ac3a5820ca Merge branch 'master' into fibers ! src/hotspot/share/oops/klass.cpp ! src/hotspot/share/runtime/frame.cpp ! src/hotspot/share/runtime/javaThread.cpp ! src/hotspot/share/runtime/javaThread.hpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp ! test/jdk/ProblemList.txt ! src/hotspot/share/oops/klass.cpp ! src/hotspot/share/runtime/frame.cpp ! src/hotspot/share/runtime/javaThread.cpp ! src/hotspot/share/runtime/javaThread.hpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp ! test/jdk/ProblemList.txt From duke at openjdk.org Sat Oct 4 13:07:53 2025 From: duke at openjdk.org (duke) Date: Sat, 4 Oct 2025 13:07:53 GMT Subject: git: openjdk/loom: master: 32 new changesets Message-ID: <5175c151-3f05-4e0f-8b9a-977a9a08b515@openjdk.org> Changeset: 5251405c Branch: master Author: Jan Lahoda Date: 2025-10-02 06:52:59 +0000 URL: https://git.openjdk.org/loom/commit/5251405ce9ab1cbd84b798a538cb3865ea4675e9 8368848: JShell's code completion not always working for multi-snippet inputs Reviewed-by: asotona ! src/jdk.jshell/share/classes/jdk/jshell/OuterWrapMap.java ! src/jdk.jshell/share/classes/jdk/jshell/SnippetMaps.java ! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java ! test/langtools/jdk/jshell/CompletionSuggestionTest.java Changeset: dfd38322 Branch: master Author: Francesco Andreuzzi Committer: Albert Mingkun Yang Date: 2025-10-02 08:58:54 +0000 URL: https://git.openjdk.org/loom/commit/dfd383224dbc2e41c9f44b1acd09ffb179cc38f3 8368966: Remove spurious VMStructs friends Reviewed-by: stefank, ayang ! src/hotspot/share/ci/ciObjectFactory.hpp ! src/hotspot/share/classfile/compactHashtable.hpp ! src/hotspot/share/code/codeBlob.hpp ! src/hotspot/share/code/dependencyContext.hpp ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/compiler/abstractCompiler.hpp ! src/hotspot/share/compiler/oopMap.hpp ! src/hotspot/share/gc/epsilon/epsilonBarrierSet.hpp ! src/hotspot/share/gc/epsilon/epsilonMonitoringSupport.cpp ! src/hotspot/share/gc/g1/g1Allocator.hpp ! src/hotspot/share/gc/g1/g1BarrierSet.hpp ! src/hotspot/share/gc/g1/g1BlockOffsetTable.hpp ! src/hotspot/share/gc/g1/g1CardTable.hpp ! src/hotspot/share/gc/g1/g1ConcurrentMarkThread.hpp ! src/hotspot/share/gc/g1/g1ConcurrentRefineThread.hpp ! src/hotspot/share/gc/g1/g1HeapRegionRemSet.hpp ! src/hotspot/share/gc/g1/g1PageBasedVirtualSpace.hpp ! src/hotspot/share/gc/parallel/mutableNUMASpace.hpp ! src/hotspot/share/gc/serial/cSpaceCounters.hpp ! src/hotspot/share/gc/shared/collectorCounters.hpp ! src/hotspot/share/gc/shared/gcPolicyCounters.hpp ! src/hotspot/share/gc/shared/generationCounters.hpp ! src/hotspot/share/gc/shared/hSpaceCounters.hpp ! src/hotspot/share/gc/shared/scavengableNMethods.hpp ! src/hotspot/share/gc/shared/stringdedup/stringDedupThread.hpp ! src/hotspot/share/gc/shenandoah/shenandoahCardTable.hpp ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.hpp ! src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.hpp ! src/hotspot/share/gc/shenandoah/shenandoahRegulatorThread.hpp ! src/hotspot/share/interpreter/templateInterpreter.hpp ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.hpp ! src/hotspot/share/interpreter/zero/zeroInterpreter.hpp ! src/hotspot/share/memory/heap.hpp ! src/hotspot/share/memory/metaspaceCounters.cpp ! src/hotspot/share/oops/instanceClassLoaderKlass.hpp ! src/hotspot/share/oops/instanceMirrorKlass.hpp ! src/hotspot/share/oops/instanceStackChunkKlass.hpp ! src/hotspot/share/opto/matcher.hpp ! src/hotspot/share/opto/parse.hpp ! src/hotspot/share/runtime/java.hpp ! src/hotspot/share/runtime/monitorDeflationThread.hpp ! src/hotspot/share/runtime/nonJavaThread.hpp ! src/hotspot/share/runtime/notificationThread.hpp ! src/hotspot/share/runtime/os.hpp ! src/hotspot/share/runtime/serviceThread.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/utilities/growableArray.hpp Changeset: 8be16160 Branch: master Author: Francesco Andreuzzi Committer: Kevin Walls Date: 2025-10-02 11:41:30 +0000 URL: https://git.openjdk.org/loom/commit/8be16160d2a6275ff619ea4cebb725475c646052 8367609: serviceability/sa/ClhsdbPmap.java fails when built with Clang Reviewed-by: kevinw, cjplummer ! src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c Changeset: cc563c87 Branch: master Author: SendaoYan Date: 2025-10-02 12:37:27 +0000 URL: https://git.openjdk.org/loom/commit/cc563c87cd277fbc96fb77af1e99f6c018ccc020 8368866: compiler/codecache/stress/UnexpectedDeoptimizationTest.java intermittent timed out Reviewed-by: shade, mhaessig ! test/hotspot/jtreg/compiler/codecache/stress/UnexpectedDeoptimizationTest.java Changeset: 56baf64a Branch: master Author: Daniel Jeli?ski Date: 2025-10-02 13:29:45 +0000 URL: https://git.openjdk.org/loom/commit/56baf64ada04f233fbfe4e0cd033c86183e22015 8368520: TLS 1.3 KeyUpdate fails with SunPKCS11 provider Reviewed-by: valeriep ! src/java.base/share/classes/sun/security/ssl/SSLTrafficKeyDerivation.java ! test/jdk/sun/security/pkcs11/tls/fips/FipsModeTLS.java Changeset: 2c7f7380 Branch: master Author: Shaojin Wen Date: 2025-10-02 13:32:09 +0000 URL: https://git.openjdk.org/loom/commit/2c7f7380ea828e5ec928e1cb05b13806646ecb3d 8368825: Use switch expression for DateTimeFormatterBuilder pattern character lookup Reviewed-by: rriggs, naoto, scolebourne ! src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java Changeset: 52522623 Branch: master Author: Casper Norrbin Date: 2025-10-02 13:38:41 +0000 URL: https://git.openjdk.org/loom/commit/5252262349cccb09f693ebd431fe2987ec0917f0 8292984: Refactor internal container-related interfaces for clarity Reviewed-by: sgehwolf, eosterlund ! src/hotspot/os/linux/cgroupSubsystem_linux.cpp ! src/hotspot/os/linux/cgroupSubsystem_linux.hpp ! src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp ! src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp ! src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp ! src/hotspot/os/linux/cgroupV2Subsystem_linux.hpp ! src/hotspot/os/linux/osContainer_linux.cpp ! src/hotspot/os/linux/osContainer_linux.hpp ! src/hotspot/os/linux/os_linux.cpp Changeset: 7ad9bdef Branch: master Author: Daniel Fuchs Date: 2025-10-02 15:19:26 +0000 URL: https://git.openjdk.org/loom/commit/7ad9bdef1ed250a824ee9dee69b37bbcc8f7c924 8368630: java/net/httpclient/http3/H3ServerPushTest.java succeeds but fails in jtreg timeout Reviewed-by: syan, jpai ! test/jdk/java/net/httpclient/http3/H3ServerPushTest.java Changeset: 1a03a1fb Branch: master Author: Igor Veresov Date: 2025-10-02 15:38:51 +0000 URL: https://git.openjdk.org/loom/commit/1a03a1fbb1c7a83469128106341591c59428437a 8369033: Remove dead code in training data Reviewed-by: rcastanedalo, kvn ! src/hotspot/share/oops/trainingData.cpp ! src/hotspot/share/oops/trainingData.hpp Changeset: 5fccabff Branch: master Author: Erik Gahlin Date: 2025-10-02 15:51:46 +0000 URL: https://git.openjdk.org/loom/commit/5fccabff15ae8bcc3d03156fa331bbc0fefb0cbe 8368670: Deadlock in JFR on event register + class load Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/internal/MetadataRepository.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/SettingsManager.java Changeset: 3d113af9 Branch: master Author: Joe Darcy Date: 2025-10-02 16:43:01 +0000 URL: https://git.openjdk.org/loom/commit/3d113af9e33ddf3d80452cb72f1b47b4936ec6a0 8369051: More small Float16 refactorings Reviewed-by: rgiulietti ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java Changeset: 1d55adee Branch: master Author: Francesco Andreuzzi Committer: Paul Hohensee Date: 2025-10-02 18:49:00 +0000 URL: https://git.openjdk.org/loom/commit/1d55adee11fc2fdbf2e009e1308b763fd7217dad 8368989: Use NMethodMarkingScope and ThreadsClaimTokenScope in shenandoahSTWMark Reviewed-by: shade, ayang ! src/hotspot/share/gc/shenandoah/shenandoahSTWMark.cpp Changeset: 3f27a03b Branch: master Author: Ioi Lam Date: 2025-10-02 20:00:58 +0000 URL: https://git.openjdk.org/loom/commit/3f27a03bba4760694a276376d08fb1ba97d08f7e 8368727: CDS custom loader support causes asserts during class unloading Reviewed-by: coleenp, dholmes ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/oops/klass.cpp ! test/hotspot/jtreg/runtime/cds/appcds/customLoader/UnloadUnregisteredLoaderTest.java ! test/hotspot/jtreg/runtime/cds/appcds/customLoader/test-classes/CustomLoadee5.java ! test/hotspot/jtreg/runtime/cds/appcds/customLoader/test-classes/UnloadUnregisteredLoader.java Changeset: fa6e8841 Branch: master Author: Damon Nguyen Date: 2025-10-02 22:09:14 +0000 URL: https://git.openjdk.org/loom/commit/fa6e884105ac247b3b83a5a2329f9c18888bd7d0 8298823: [macos] java/awt/Mouse/EnterExitEvents/DragWindowTest.java continues to fail with "No MouseReleased event on label!" Reviewed-by: aivanov, azvegint ! test/jdk/ProblemList.txt ! test/jdk/java/awt/Mouse/EnterExitEvents/DragWindowTest.java Changeset: da7121af Branch: master Author: Dean Long Date: 2025-10-02 22:21:13 +0000 URL: https://git.openjdk.org/loom/commit/da7121aff9eccb046b82a75093034f1cdbd9b9e4 8366461: Remove obsolete method handle invoke logic Reviewed-by: vlivanov, mhaessig ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/c1_FrameMap_aarch64.cpp ! src/hotspot/cpu/aarch64/frame_aarch64.cpp ! src/hotspot/cpu/aarch64/frame_aarch64.hpp ! src/hotspot/cpu/aarch64/frame_aarch64.inline.hpp ! src/hotspot/cpu/arm/arm.ad ! src/hotspot/cpu/arm/arm_32.ad ! src/hotspot/cpu/arm/c1_FrameMap_arm.cpp ! src/hotspot/cpu/arm/c1_Runtime1_arm.cpp ! src/hotspot/cpu/arm/frame_arm.cpp ! src/hotspot/cpu/arm/frame_arm.hpp ! src/hotspot/cpu/arm/frame_arm.inline.hpp ! src/hotspot/cpu/arm/register_arm.hpp ! src/hotspot/cpu/arm/runtime_arm.cpp ! src/hotspot/cpu/ppc/c1_FrameMap_ppc.cpp ! src/hotspot/cpu/ppc/ppc.ad ! src/hotspot/cpu/riscv/c1_FrameMap_riscv.cpp ! src/hotspot/cpu/riscv/frame_riscv.cpp ! src/hotspot/cpu/riscv/frame_riscv.hpp ! src/hotspot/cpu/riscv/frame_riscv.inline.hpp ! src/hotspot/cpu/riscv/riscv.ad ! src/hotspot/cpu/s390/c1_FrameMap_s390.cpp ! src/hotspot/cpu/s390/s390.ad ! src/hotspot/cpu/x86/c1_FrameMap_x86.cpp ! src/hotspot/cpu/x86/frame_x86.cpp ! src/hotspot/cpu/x86/frame_x86.hpp ! src/hotspot/cpu/x86/frame_x86.inline.hpp ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/os/posix/signals_posix.cpp ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/share/asm/codeBuffer.hpp ! src/hotspot/share/c1/c1_Compilation.cpp ! src/hotspot/share/c1/c1_Compilation.hpp ! src/hotspot/share/c1/c1_FrameMap.hpp ! src/hotspot/share/c1/c1_IR.cpp ! src/hotspot/share/c1/c1_IR.hpp ! src/hotspot/share/c1/c1_LIR.cpp ! src/hotspot/share/c1/c1_LIR.hpp ! src/hotspot/share/c1/c1_LIRAssembler.cpp ! src/hotspot/share/c1/c1_LIRGenerator.cpp ! src/hotspot/share/c1/c1_Runtime1.cpp ! src/hotspot/share/code/debugInfoRec.cpp ! src/hotspot/share/code/debugInfoRec.hpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/code/nmethod.inline.hpp ! src/hotspot/share/code/pcDesc.hpp ! src/hotspot/share/jvmci/jvmciCodeInstaller.cpp ! src/hotspot/share/jvmci/jvmciCodeInstaller.hpp ! src/hotspot/share/jvmci/jvmciRuntime.cpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/hotspot/share/opto/callGenerator.cpp ! src/hotspot/share/opto/callnode.hpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/opto/lcm.cpp ! src/hotspot/share/opto/machnode.cpp ! src/hotspot/share/opto/machnode.hpp ! src/hotspot/share/opto/matcher.cpp ! src/hotspot/share/opto/matcher.hpp ! src/hotspot/share/opto/output.cpp ! src/hotspot/share/opto/runtime.cpp ! src/hotspot/share/runtime/deoptimization.cpp ! src/hotspot/share/runtime/frame.cpp ! src/hotspot/share/runtime/frame.inline.hpp ! src/hotspot/share/runtime/javaThread.cpp ! src/hotspot/share/runtime/javaThread.hpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/NMethod.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/PCDesc.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Frame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/aarch64/AARCH64Frame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ppc64/PPC64Frame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/riscv64/RISCV64Frame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/x86/X86Frame.java Changeset: 854b384b Branch: master Author: Alex Menkov Date: 2025-10-02 23:39:37 +0000 URL: https://git.openjdk.org/loom/commit/854b384b120fa2af41adca3048070866fe3cafd4 8304811: vmTestbase/vm/mlvm/indy/func/jvmti/stepBreakPopReturn/INDIFY_Test.java fails with JVMTI_ERROR_TYPE_MISMATCH Reviewed-by: lmesnik, dholmes, sspitsyn ! test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/func/jvmti/stepBreakPopReturn/stepBreakPopReturn.cpp Changeset: f62b9eca Branch: master Author: Ashutosh Mehra Date: 2025-10-03 02:43:14 +0000 URL: https://git.openjdk.org/loom/commit/f62b9eca08694bbbe80d9e7d7b704db4f2423830 8364929: Assign unique id to each AdapterBlob stored in AOTCodeCache Reviewed-by: kvn, iklam ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp Changeset: 3790965d Branch: master Author: Joe Wang Date: 2025-10-03 03:50:01 +0000 URL: https://git.openjdk.org/loom/commit/3790965df3e7cba3b9792b8719d1e2ead046da15 8336695: Update Commons BCEL to Version 6.10.0 Reviewed-by: lancea, naoto, iris ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/Const.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/ExceptionConst.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/Repository.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/AccessFlags.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/AnnotationEntry.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/Annotations.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ArrayElementValue.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/Attribute.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/BootstrapMethod.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/BootstrapMethods.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ClassFormatException.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ClassParser.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/Code.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/CodeException.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/Constant.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantCP.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantDouble.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantFloat.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantInteger.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantLong.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantObject.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantPool.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantUtf8.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantValue.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/Deprecated.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/DescendingVisitor.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ElementValue.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/EmptyVisitor.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ExceptionTable.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/Field.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/FieldOrMethod.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/InnerClass.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/InnerClasses.java + src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/InvalidMethodSignatureException.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/JavaClass.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/LineNumber.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/LineNumberTable.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/LocalVariableTable.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/LocalVariableTypeTable.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/Method.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/MethodParameter.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/MethodParameters.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/Module.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ModuleExports.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ModuleMainClass.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ModuleOpens.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ModulePackages.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ModuleProvides.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ModuleRequires.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/NestMembers.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/Node.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/PMGClass.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ParameterAnnotationEntry.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/ParameterAnnotations.java + src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/Record.java + src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/RecordComponentInfo.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/RuntimeInvisibleAnnotations.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/RuntimeInvisibleParameterAnnotations.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/RuntimeVisibleAnnotations.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/RuntimeVisibleParameterAnnotations.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/Signature.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/SimpleElementValue.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/SourceFile.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/StackMap.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/StackMapEntry.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/StackMapType.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/Synthetic.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/Utility.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/Visitor.java + src/java.xml/share/classes/com/sun/org/apache/bcel/internal/classfile/package-info.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/ARRAYLENGTH.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/ATHROW.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/AnnotationEntryGen.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/ArrayElementValueGen.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/ArrayType.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/BranchHandle.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/CPInstruction.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/ClassElementValueGen.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/ClassGen.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/CodeExceptionGen.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/ElementValuePairGen.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/EnumElementValueGen.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/ExceptionThrower.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/FieldGen.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/FieldGenOrMethodGen.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/FieldOrMethod.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/ICONST.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/INVOKEDYNAMIC.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/Instruction.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/InstructionConst.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/InstructionFactory.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/InstructionHandle.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/InstructionList.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/InstructionTargeter.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/LCMP.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/LDC.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/LineNumberGen.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/LocalVariableGen.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/LocalVariableInstruction.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/MethodGen.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/ObjectType.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/RET.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/ReferenceType.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/SWITCH.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/Select.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/SimpleElementValueGen.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/TargetLostException.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/Type.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/TypedInstruction.java + src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/package-info.java + src/java.xml/share/classes/com/sun/org/apache/bcel/internal/package-info.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/util/BCELComparator.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/util/BCELFactory.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/util/BCELifier.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/util/Class2HTML.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/util/ClassSet.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/util/CodeHTML.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/util/InstructionFinder.java ! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/util/Repository.java + src/java.xml/share/classes/com/sun/org/apache/bcel/internal/util/package-info.java ! src/java.xml/share/classes/jdk/xml/internal/Utils.java ! src/java.xml/share/legal/bcel.md Changeset: ebb6fd7d Branch: master Author: Mikhail Yankelevich Date: 2025-10-03 07:37:17 +0000 URL: https://git.openjdk.org/loom/commit/ebb6fd7d7865fd20ff2f90b4ef72c5ef6a3e5dea 8360562: sun/security/tools/keytool/i18n.java add an ability to add comment for failures Reviewed-by: rhalade ! test/jdk/sun/security/tools/keytool/i18n.java Changeset: 2e783963 Branch: master Author: Mar?a Arias de Reyna Dom?nguez Committer: Roland Westrelin Date: 2025-10-03 07:57:24 +0000 URL: https://git.openjdk.org/loom/commit/2e783963d21c8edd88e79226ca473cfe0e41335b 8369037: Identify owning method for MethodData and MethodCounters in AOT map output Reviewed-by: iklam, asmehra, adinn, macarte ! src/hotspot/share/cds/aotMapLogger.cpp ! src/hotspot/share/cds/aotMapLogger.hpp Changeset: 134b63f0 Branch: master Author: Yuri Gaevsky Committer: Vladimir Kempik Date: 2025-10-03 09:44:56 +0000 URL: https://git.openjdk.org/loom/commit/134b63f0e8c4093f7ad0a528d6996898ab881d5c 8322174: RISC-V: C2 VectorizedHashCode RVV Version Reviewed-by: fyang, rehn ! src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp ! src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.hpp ! src/hotspot/cpu/riscv/riscv.ad ! src/hotspot/cpu/riscv/riscv_v.ad ! src/hotspot/cpu/riscv/stubDeclarations_riscv.hpp ! src/hotspot/cpu/riscv/stubGenerator_riscv.cpp Changeset: 72319167 Branch: master Author: Beno?t Maillard Committer: Manuel H?ssig Date: 2025-10-03 10:40:50 +0000 URL: https://git.openjdk.org/loom/commit/72319167543a28295276f11178c17bef6680c32f 8364757: Missing Store nodes caused by bad wiring in PhaseIdealLoop::insert_post_loop Reviewed-by: mhaessig, roland ! src/hotspot/share/opto/loopTransform.cpp ! src/hotspot/share/opto/loopnode.hpp + test/hotspot/jtreg/compiler/loopstripmining/MissingStoreAfterOuterStripMinedLoop.java Changeset: f81c7c59 Branch: master Author: Hannes Walln?fer Date: 2025-10-03 15:53:37 +0000 URL: https://git.openjdk.org/loom/commit/f81c7c592bbc9f5575ed41e41d12f54cbfc5e4aa 8276966: Improve diagnostic output for the mismatching parts of a hybrid snippet Reviewed-by: prappo ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/taglets/SnippetTaglet.java ! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java Changeset: 23a65644 Branch: master Author: Justin Lu Date: 2025-10-03 16:25:55 +0000 URL: https://git.openjdk.org/loom/commit/23a65644ae63b271ca99c55a2a60a192c4e4dfb8 8368981: Case Fold Locale Legacy Tags On Demand Reviewed-by: rriggs, naoto ! src/java.base/share/classes/sun/util/locale/LanguageTag.java ! test/jdk/java/util/Locale/CaseFoldLanguageTagTest.java Changeset: aee73d35 Branch: master Author: Harshitha Onkar Date: 2025-10-03 17:32:51 +0000 URL: https://git.openjdk.org/loom/commit/aee73d3568fbcb2fe7293f92154e6677c080d20c 8365424: [macos26] java/awt/Frame/DisposeTest.java fails on macOS 26 Reviewed-by: serb, azvegint ! test/jdk/java/awt/Frame/DisposeTest.java Changeset: 0935b76c Branch: master Author: Mikael Vidstedt Date: 2025-10-03 17:40:37 +0000 URL: https://git.openjdk.org/loom/commit/0935b76c6bd1fbfa0a431eedb54c51f6fe4d194e 8369080: Use uname -m for devkit cpu detection Reviewed-by: iris, erikj ! make/devkit/Makefile Changeset: 0e98ec36 Branch: master Author: Sergey Bylokhov Committer: Harshitha Onkar Date: 2025-10-03 17:49:59 +0000 URL: https://git.openjdk.org/loom/commit/0e98ec36623d5d83172209058574a97bab1d6038 8367384: The ICC_Profile class may throw exceptions during serialization Reviewed-by: honkar, prr ! src/java.desktop/share/classes/java/awt/color/ICC_Profile.java + test/jdk/java/awt/color/ICC_Profile/Serialization/SerializationSpecTest/SerializationSpecTest.java + test/jdk/java/awt/color/ICC_Profile/Serialization/SerializationSpecTest/empty.ser + test/jdk/java/awt/color/ICC_Profile/Serialization/SerializationSpecTest/invalid.ser + test/jdk/java/awt/color/ICC_Profile/Serialization/SerializationSpecTest/invalid_invalid.ser + test/jdk/java/awt/color/ICC_Profile/Serialization/SerializationSpecTest/invalid_null.ser + test/jdk/java/awt/color/ICC_Profile/Serialization/SerializationSpecTest/invalid_valid.ser + test/jdk/java/awt/color/ICC_Profile/Serialization/SerializationSpecTest/invalid_wrongType.ser + test/jdk/java/awt/color/ICC_Profile/Serialization/SerializationSpecTest/null.ser + test/jdk/java/awt/color/ICC_Profile/Serialization/SerializationSpecTest/null_invalid.ser + test/jdk/java/awt/color/ICC_Profile/Serialization/SerializationSpecTest/null_null.ser = test/jdk/java/awt/color/ICC_Profile/Serialization/SerializationSpecTest/null_valid.ser + test/jdk/java/awt/color/ICC_Profile/Serialization/SerializationSpecTest/null_wrongType.ser + test/jdk/java/awt/color/ICC_Profile/Serialization/SerializationSpecTest/valid.ser = test/jdk/java/awt/color/ICC_Profile/Serialization/SerializationSpecTest/valid_invalid.ser = test/jdk/java/awt/color/ICC_Profile/Serialization/SerializationSpecTest/valid_null.ser + test/jdk/java/awt/color/ICC_Profile/Serialization/SerializationSpecTest/valid_valid.ser + test/jdk/java/awt/color/ICC_Profile/Serialization/SerializationSpecTest/valid_wrongType.ser + test/jdk/java/awt/color/ICC_Profile/Serialization/SerializationSpecTest/wrongType.ser + test/jdk/java/awt/color/ICC_Profile/Serialization/SerializationSpecTest/wrongType_invalid.ser + test/jdk/java/awt/color/ICC_Profile/Serialization/SerializationSpecTest/wrongType_null.ser + test/jdk/java/awt/color/ICC_Profile/Serialization/SerializationSpecTest/wrongType_valid.ser + test/jdk/java/awt/color/ICC_Profile/Serialization/SerializationSpecTest/wrongType_wrongType.ser + test/jdk/java/awt/color/ICC_Profile/Serialization/StandardProfilesRoundTrip.java ! test/jdk/java/awt/color/ICC_Profile/ValidateICCHeaderData/ValidateICCHeaderData.java Changeset: 012e079d Branch: master Author: Roger Riggs Date: 2025-10-03 18:45:34 +0000 URL: https://git.openjdk.org/loom/commit/012e079d11b629ddda8d5f687fd43ef21d210466 8356202: Cleanup Source code in String Implementation Classes Reviewed-by: jpai, rgiulietti, liach ! src/java.base/share/classes/java/lang/StringLatin1.java ! src/java.base/share/classes/java/lang/StringUTF16.java Changeset: 837f634b Branch: master Author: Daniel D. Daugherty Date: 2025-10-03 21:11:33 +0000 URL: https://git.openjdk.org/loom/commit/837f634bf29fd877dd62a2e0f7d7a1bd383372d3 8369128: ProblemList jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java in Xcomp configs 8369132: Disable vmTestbase/gc/vector/CircularListLow and LinearListLow with SerialGC 8369133: Disable gc/g1/TestShrinkAuxiliaryDataRunner.java with UseLargePages option Reviewed-by: ayang, dholmes ! test/hotspot/jtreg/gc/g1/TestShrinkAuxiliaryDataRunner.java ! test/hotspot/jtreg/vmTestbase/gc/vector/CircularListLow/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/vector/LinearListLow/TestDescription.java ! test/jdk/ProblemList-Xcomp.txt Changeset: e6868c62 Branch: master Author: Daniel D. Daugherty Date: 2025-10-03 22:17:01 +0000 URL: https://git.openjdk.org/loom/commit/e6868c624851d5c6bd182e45ba908cb06b731e8c 8369138: New test compiler/loopstripmining/MissingStoreAfterOuterStripMinedLoop.java fails Reviewed-by: kvn ! test/hotspot/jtreg/compiler/loopstripmining/MissingStoreAfterOuterStripMinedLoop.java Changeset: c3fbbfab Branch: master Author: Sergey Bylokhov Date: 2025-10-03 23:16:41 +0000 URL: https://git.openjdk.org/loom/commit/c3fbbfabcc9a9535a3b422c1c9afaa8e092a5da0 8369027: Apply java.io.Serial annotations in java.scripting Reviewed-by: rriggs ! src/java.scripting/share/classes/javax/script/ScriptException.java Changeset: 76dba201 Branch: master Author: Jaikiran Pai Date: 2025-10-04 08:09:09 +0000 URL: https://git.openjdk.org/loom/commit/76dba201fa1a525780677e4d3dee8e9ffafd1cd7 8368821: Test java/net/httpclient/http3/GetHTTP3Test.java intermittently fails with java.io.IOException: QUIC endpoint closed Reviewed-by: dfuchs ! test/jdk/java/net/httpclient/http3/GetHTTP3Test.java ! test/jdk/java/net/httpclient/http3/PostHTTP3Test.java From dreamlike.vertx at gmail.com Sat Oct 4 13:19:10 2025 From: dreamlike.vertx at gmail.com (dreamlike_ocean lei) Date: Sat, 4 Oct 2025 21:19:10 +0800 Subject: Scheduler API Feedback Message-ID: Hello @loom-dev , I have been enjoying the new POLLER_PER_CARRIER design in the Loom repo and I really like the direction it is going. While building on top of the latest code, I noticed a couple of issues and would like to ask for clarification. 1. When calling Thread.startVirtualThread, the new virtual thread does not inherit the scheduler of the calling virtual thread, but instead uses DEFAULT_SCHEDULER. What is the reasoning behind this design? Could there be a mechanism to allow implicit inheritance? This would be very helpful for custom schedulers based on the per-core model. 2. The method Thread.VirtualThreadScheduler::current is very helpful, but it seems not quite enough. Since Loom already provides the read-only builtin.externalView, could we also have a method like Thread.VirtualThreadScheduler::scheduler(Thread)? This would make it easier to build better schedulers. For example, I could combine Thread.currentThread with Thread.VirtualThreadScheduler.scheduler to decide whether to push a task into a local task queue rather than the eventLoop?s MPSC queue. Thank you for your time and help. Best regards, dreamlike li -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Sat Oct 4 13:31:28 2025 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 4 Oct 2025 15:31:28 +0200 (CEST) Subject: Scheduler API Feedback In-Reply-To: References: Message-ID: <1763567084.7189437.1759584688175.JavaMail.zimbra@univ-eiffel.fr> > From: "dreamlike_ocean lei" > To: "loom-dev" > Sent: Saturday, October 4, 2025 3:19:10 PM > Subject: Scheduler API Feedback > Hello @loom-dev , > I have been enjoying the new POLLER_PER_CARRIER design in the Loom repo and I > really like the direction it is going. > While building on top of the latest code, I noticed a couple of issues and would > like to ask for clarification. > 1. > When calling Thread.startVirtualThread , the new virtual thread does not inherit > the scheduler of the calling virtual thread, but instead uses DEFAULT_SCHEDULER > . What is the reasoning behind this design? Could there be a mechanism to allow > implicit inheritance? This would be very helpful for custom schedulers based on > the per-core model. I do not know if POLLER_PER_CARRIER works that way or not, but the preferred mechanism to get "inheritance" of values between virtual threads is to use a ScopeValue for the value and a StructuredTaskScope to organize the virtual threads. > 1. > The method Thread.VirtualThreadScheduler::current is very helpful, but it seems > not quite enough. Since Loom already provides the read-only > builtin.externalView , could we also have a method like > Thread.VirtualThreadScheduler::scheduler(Thread) ? This would make it easier to > build better schedulers. For example, I could combine Thread.currentThread with > Thread.VirtualThreadScheduler.scheduler to decide whether to push a task into a > local task queue rather than the eventLoop?s MPSC queue. > Thank you for your time and help. > Best regards, > dreamlike li regards, R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at me.com Sat Oct 4 13:49:37 2025 From: robaho at me.com (Robert Engels) Date: Sat, 4 Oct 2025 08:49:37 -0500 Subject: Scheduler API Feedback In-Reply-To: <1763567084.7189437.1759584688175.JavaMail.zimbra@univ-eiffel.fr> References: <1763567084.7189437.1759584688175.JavaMail.zimbra@univ-eiffel.fr> Message-ID: An HTML attachment was scrubbed... URL: From alan.bateman at oracle.com Sat Oct 4 16:35:43 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Sat, 4 Oct 2025 17:35:43 +0100 Subject: Scheduler API Feedback In-Reply-To: References: Message-ID: On 04/10/2025 14:19, dreamlike_ocean lei wrote: > > Hello @loom-dev >, > > I have been enjoying the new POLLER_PER_CARRIER design in the Loom > repo and I really like the direction it is going. > While building on top of the latest code, I noticed a couple of issues > and would like to ask for clarification. > Thanks for your mail. It's useful to hear from folks that are trying out the experimental support for custom schedulers in the loom repo as this will help to inform whether any of the directions prototyped should be taken further. BTW: I assume "dreamlike_ocean lei" isn't your real name. It would be helpful to use a real name or affiliation so we have some idea who you are. > 1. > > When calling |Thread.startVirtualThread|, the new virtual thread > does not inherit the scheduler of the calling virtual thread, but > instead uses |DEFAULT_SCHEDULER|. What is the reasoning behind > this design? Could there be a mechanism to allow implicit > inheritance? This would be very helpful for custom schedulers > based on the per-core model. > In a system with several virtual thread schedulers in use, which I think is what you mean, then it would be unpredictable and problematic to inherit the scheduler in many cases. If some library were, on first usage, start a virtual thread as a "background thread" that runs indefinitely then inheritance would mean it depends on the first usage. Examples where inheritance at thread create time is problematic are the thread context class loader, and until recently, the inherited access control context. When you say "custom schedulers based on the per-core model" do you mean you are experimenting with a scheduler per core in order to get "carrier affinity"? (virtual thread X will always be scheduled on carrier Y). You might also be using processor affinity to bind carrier Y to specific sets of CPUs. You might find it simpler to just use one scheduler and keep a mapping of virtual thread to carrier. That would remove complications with lifecycle that would arise if carriers were to terminate (e.g. idle/keep-alive). It might avoid needing to expose APIs to get a virtual thread's scheduler, which I think what your second point is about. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.bateman at oracle.com Sat Oct 4 16:57:42 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Sat, 4 Oct 2025 17:57:42 +0100 Subject: Problem report on the usage of Structured Concurrency (5th preview) In-Reply-To: References: <85467C61-8139-4832-B3BA-BFA53061E986@warski.org> <51868ca8-ec63-4c2e-ba2d-a7f0f1df6954@oracle.com> <7D941AAE-5168-4BE2-9A14-A8F5C0FF132D@warski.org> Message-ID: <41610b85-7489-4ad7-b1da-692f54ad2c07@oracle.com> On 02/10/2025 18:29, Pedro Lamar?o wrote: > : > > I fail to understand this; I have not tested STS extensively. > Is it not the case that an inner scope will be cancelled when its > parent scope is cancelled? > The forked subtask would be joining the inner scope; will this inner > join not be cancelled when the outer join is cancelled? > In what sense does an inner scope not participate in the same error > handling as the outer scope? > When the outer/parent scope is cancelled then all threads executing unfinished subtasks will be interrupted. If a subtask has created it own scope and invokes join to block waiting for its sub-subtasks, then it will wakeup with InterruptedException, and the exception handling will cause its scope to be closed, thus interrupting any remaining sub-subtasks. So yes, cancelling the parent scope may result in a "tree of scopes" being cancelled. -Alan From robaho at me.com Sat Oct 4 18:44:57 2025 From: robaho at me.com (Robert Engels) Date: Sat, 4 Oct 2025 13:44:57 -0500 Subject: Scheduler API Feedback In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From adam at warski.org Sun Oct 5 15:16:38 2025 From: adam at warski.org (Adam Warski) Date: Sun, 5 Oct 2025 17:16:38 +0200 Subject: Problem report on the usage of Structured Concurrency (5th preview) In-Reply-To: References: <85467C61-8139-4832-B3BA-BFA53061E986@warski.org> <51868ca8-ec63-4c2e-ba2d-a7f0f1df6954@oracle.com> <7D941AAE-5168-4BE2-9A14-A8F5C0FF132D@warski.org> Message-ID: <11646DDF-FF8C-4F6E-B898-99B36FEF19F9@warski.org> > I fail to understand this; I have not tested STS extensively. > Is it not the case that an inner scope will be cancelled when its parent scope is cancelled? > The forked subtask would be joining the inner scope; will this inner join not be cancelled when the outer join is cancelled? > In what sense does an inner scope not participate in the same error handling as the outer scope? Yes, you?re right, if the parent scope is cancelled, this will interrupt the thread running the child scope. If the child scope is waiting on scope.join() (or starts to wait on that method soon enough), the child scope will be properly cancelled and shut down as well. However, the problem we?re considering here is failure in the child scope, or rather that moving any blocking logic from the parent?s scope body, to the child scope body, doesn?t solve anything. Failure of forks in the child scope won?t interrupt (cancel) the child scope?s body, just as it wouldn?t interrupt (cancel) the parent?s scope body. Given, of course, that the child/parent scope body is blocked on something else than scope.join(). Adam -- Adam Warski https://warski.org From adam at warski.org Sun Oct 5 15:16:38 2025 From: adam at warski.org (Adam Warski) Date: Sun, 5 Oct 2025 17:16:38 +0200 Subject: Problem report on the usage of Structured Concurrency (5th preview) In-Reply-To: References: <85467C61-8139-4832-B3BA-BFA53061E986@warski.org> <51868ca8-ec63-4c2e-ba2d-a7f0f1df6954@oracle.com> <7D941AAE-5168-4BE2-9A14-A8F5C0FF132D@warski.org> Message-ID: <11646DDF-FF8C-4F6E-B898-99B36FEF19F9@warski.org> > I fail to understand this; I have not tested STS extensively. > Is it not the case that an inner scope will be cancelled when its parent scope is cancelled? > The forked subtask would be joining the inner scope; will this inner join not be cancelled when the outer join is cancelled? > In what sense does an inner scope not participate in the same error handling as the outer scope? Yes, you?re right, if the parent scope is cancelled, this will interrupt the thread running the child scope. If the child scope is waiting on scope.join() (or starts to wait on that method soon enough), the child scope will be properly cancelled and shut down as well. However, the problem we?re considering here is failure in the child scope, or rather that moving any blocking logic from the parent?s scope body, to the child scope body, doesn?t solve anything. Failure of forks in the child scope won?t interrupt (cancel) the child scope?s body, just as it wouldn?t interrupt (cancel) the parent?s scope body. Given, of course, that the child/parent scope body is blocked on something else than scope.join(). Adam -- Adam Warski https://warski.org From duke at openjdk.org Tue Oct 7 07:09:08 2025 From: duke at openjdk.org (duke) Date: Tue, 7 Oct 2025 07:09:08 GMT Subject: git: openjdk/loom: fibers: 20 new changesets Message-ID: <841add4b-1036-464f-9349-e8c902fecd11@openjdk.org> Changeset: f740cd2a Branch: fibers Author: Chad Rakoczy Committer: Evgeny Astigeevich Date: 2025-10-04 21:17:26 +0000 URL: https://git.openjdk.org/loom/commit/f740cd2aad43a008da1ed1ff15ebe2c790f893a0 8316694: Implement relocation of nmethod within CodeCache Reviewed-by: kvn, eosterlund, never, eastigeevich, bulasevich ! src/hotspot/cpu/aarch64/relocInfo_aarch64.cpp ! src/hotspot/share/code/codeBehaviours.cpp ! src/hotspot/share/code/codeBehaviours.hpp ! src/hotspot/share/code/codeCache.hpp ! src/hotspot/share/code/compiledIC.cpp ! src/hotspot/share/code/compiledIC.hpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/code/relocInfo.cpp ! src/hotspot/share/compiler/oopMap.cpp ! src/hotspot/share/compiler/oopMap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahUnload.cpp ! src/hotspot/share/gc/z/zUnload.cpp ! src/hotspot/share/jvmci/jvmciRuntime.hpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/globals.hpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/NMethod.java ! test/hotspot/jtreg/compiler/whitebox/CompilerWhiteBoxTest.java + test/hotspot/jtreg/compiler/whitebox/DeoptimizeRelocatedNMethod.java + test/hotspot/jtreg/compiler/whitebox/RelocateNMethod.java + test/hotspot/jtreg/compiler/whitebox/RelocateNMethodMultiplePaths.java + test/hotspot/jtreg/compiler/whitebox/StressNMethodRelocation.java + test/hotspot/jtreg/serviceability/jvmti/NMethodRelocation/NMethodRelocationTest.java + test/hotspot/jtreg/serviceability/jvmti/NMethodRelocation/libNMethodRelocationTest.cpp ! test/lib/jdk/test/whitebox/WhiteBox.java ! test/lib/jdk/test/whitebox/code/CodeBlob.java Changeset: 5d9f94e0 Branch: fibers Author: Vladimir Kozlov Date: 2025-10-05 16:20:53 +0000 URL: https://git.openjdk.org/loom/commit/5d9f94e05e1527745271d0167a418741607619e2 8369152: Problem list new tests from JDK-8316694 Reviewed-by: jpai, dholmes, serb ! test/hotspot/jtreg/ProblemList.txt Changeset: ba7bf43c Branch: fibers Author: Vladimir Ivanov Committer: Sandhya Viswanathan Date: 2025-10-05 23:55:53 +0000 URL: https://git.openjdk.org/loom/commit/ba7bf43c76c94bea85dbbd865794184b7ee0cc86 8365290: [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays Reviewed-by: sviswanathan, vpaprotski, kvn ! src/hotspot/cpu/x86/macroAssembler_x86.cpp Changeset: 85877e20 Branch: fibers Author: Damon Fenacci Date: 2025-10-06 06:17:48 +0000 URL: https://git.openjdk.org/loom/commit/85877e2022114031ef1ba13c67bf768edb0dfaa7 8355354: C2 crashed: assert(_callee == nullptr || _callee == m) failed: repeated inline attempt with different callee Reviewed-by: vlivanov, dlong ! src/hotspot/share/opto/callGenerator.cpp ! src/hotspot/share/opto/callGenerator.hpp ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp Changeset: 069c569a Branch: fibers Author: Johan Sj?len Date: 2025-10-06 07:48:45 +0000 URL: https://git.openjdk.org/loom/commit/069c569a710f50bc715f523c6c4c7aa087694af6 8368097: [asan] heap-buffer-overflow reported in ClassFileParser::skip_over_field_signature Reviewed-by: dholmes, mbaesken ! src/hotspot/share/classfile/classFileParser.cpp Changeset: e6781fd9 Branch: fibers Author: Fredrik Bredberg Date: 2025-10-06 08:10:11 +0000 URL: https://git.openjdk.org/loom/commit/e6781fd9497723a7baab38d6bfb958ba1b1c24ff 8367601: Remove held_monitor_count Reviewed-by: mdoerr, pchilanomate, fyang ! src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/ppc/globalDefinitions_ppc.hpp ! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp ! src/hotspot/cpu/riscv/globalDefinitions_riscv.hpp ! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp ! src/hotspot/cpu/riscv/macroAssembler_riscv.hpp ! src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp ! src/hotspot/cpu/x86/globalDefinitions_x86.hpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/hotspot/share/runtime/continuation.hpp ! src/hotspot/share/runtime/continuationEntry.cpp ! src/hotspot/share/runtime/continuationEntry.hpp ! src/hotspot/share/runtime/continuationFreezeThaw.cpp ! src/hotspot/share/runtime/javaThread.cpp ! src/hotspot/share/runtime/javaThread.hpp ! src/hotspot/share/runtime/objectMonitor.cpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp ! src/hotspot/share/runtime/synchronizer.cpp ! src/hotspot/share/runtime/synchronizer.inline.hpp ! src/java.base/share/classes/jdk/internal/vm/Continuation.java Changeset: 59e87437 Branch: fibers Author: Roberto Casta?eda Lozano Date: 2025-10-06 08:14:24 +0000 URL: https://git.openjdk.org/loom/commit/59e87437b4f9259121710dca5e595ca714c3e71b 8368753: IGV: improve CFG view of difference graphs Reviewed-by: chagedorn, mhaessig, dfenacci ! src/utils/IdealGraphVisualizer/Data/src/main/java/com/sun/hotspot/igv/data/InputBlock.java ! src/utils/IdealGraphVisualizer/Data/src/main/java/com/sun/hotspot/igv/data/services/Scheduler.java ! src/utils/IdealGraphVisualizer/Difference/src/main/java/com/sun/hotspot/igv/difference/Difference.java ! src/utils/IdealGraphVisualizer/ServerCompiler/src/main/java/com/sun/hotspot/igv/servercompiler/ServerCompilerScheduler.java Changeset: baf8bc57 Branch: fibers Author: Francesco Andreuzzi Committer: Aleksey Shipilev Date: 2025-10-06 08:14:44 +0000 URL: https://git.openjdk.org/loom/commit/baf8bc5701c43425e3345f82d4318b134b26d7c9 8369038: Parallel: Use NMethodMarkingScope and ThreadsClaimTokenScope in psParallelCompact Reviewed-by: ayang, shade ! src/hotspot/share/gc/parallel/psParallelCompact.cpp Changeset: 2c114d67 Branch: fibers Author: SendaoYan Date: 2025-10-06 09:26:51 +0000 URL: https://git.openjdk.org/loom/commit/2c114d676d9904094dd6058d15f06d801ec7a3d6 8367899: compiler/c2/gvn/TestBitCompressValueTransform.java intermittent timed out Reviewed-by: dfenacci, chagedorn ! test/hotspot/jtreg/compiler/c2/gvn/TestBitCompressValueTransform.java Changeset: ea08f74e Branch: fibers Author: Alan Bateman Date: 2025-10-06 10:47:17 +0000 URL: https://git.openjdk.org/loom/commit/ea08f74eb134fd007d7906dfb61c21dbc15f48d2 Merge branch 'master' into fibers ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp ! src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/share/runtime/continuation.hpp ! src/hotspot/share/runtime/continuationEntry.cpp ! src/hotspot/share/runtime/continuationEntry.hpp ! src/hotspot/share/runtime/continuationFreezeThaw.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/javaThread.cpp ! src/hotspot/share/runtime/javaThread.hpp ! src/hotspot/share/runtime/objectMonitor.cpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp ! src/hotspot/share/runtime/synchronizer.cpp ! src/hotspot/share/runtime/synchronizer.inline.hpp ! test/hotspot/jtreg/ProblemList.txt ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp ! src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/share/runtime/continuation.hpp ! src/hotspot/share/runtime/continuationEntry.cpp ! src/hotspot/share/runtime/continuationEntry.hpp ! src/hotspot/share/runtime/continuationFreezeThaw.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/javaThread.cpp ! src/hotspot/share/runtime/javaThread.hpp ! src/hotspot/share/runtime/objectMonitor.cpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp ! src/hotspot/share/runtime/synchronizer.cpp ! src/hotspot/share/runtime/synchronizer.inline.hpp ! test/hotspot/jtreg/ProblemList.txt Changeset: 2bfada3f Branch: fibers Author: jonghoonpark Committer: Thomas Schatzl Date: 2025-10-06 11:53:14 +0000 URL: https://git.openjdk.org/loom/commit/2bfada3f58df6c041d948267368cbc4db915cac3 8364927: Add @requires annotation to TestReclaimStringsLeaksMemory.java Reviewed-by: tschatzl, stefank, ayang ! test/hotspot/jtreg/gc/stress/TestReclaimStringsLeaksMemory.java Changeset: e3320a9d Branch: fibers Author: Nizar Benalla Date: 2025-10-06 13:32:46 +0000 URL: https://git.openjdk.org/loom/commit/e3320a9df592a06c466ae9158d8f173921679952 8367610: Test tools/sincechecker/modules/java.base/JavaBaseCheckSince.java timed out on Windows Reviewed-by: liach ! test/jdk/tools/sincechecker/modules/java.base/JavaBaseCheckSince.java Changeset: b6a4cfec Branch: fibers Author: Mahendra Chhipa Date: 2025-10-06 15:26:59 +0000 URL: https://git.openjdk.org/loom/commit/b6a4cfecb731615b6ef70828ac10fae4b2264cdc 8367114: Update jdk.test.lib.net.SimpleHttpServer to use SimpleFileServer Reviewed-by: dfuchs, vyazici ! test/jaxp/javax/xml/jaxp/unittest/catalog/CatalogFileInputTest.java - test/jdk/com/sun/net/httpserver/SimpleFileServer.java ! test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarHttpProperties.java ! test/jdk/sun/net/www/protocol/jar/MultiReleaseJarURLConnection.java - test/lib/jdk/test/lib/net/SimpleHttpServer.java Changeset: 596af0a7 Branch: fibers Author: Albert Mingkun Yang Date: 2025-10-06 15:44:13 +0000 URL: https://git.openjdk.org/loom/commit/596af0a7cc37e359d54689be20f855a86ae46567 8369041: Release memory after testing in ThreadsRunner.java Reviewed-by: shade, tschatzl ! test/hotspot/jtreg/vmTestbase/nsk/share/runner/ThreadsRunner.java Changeset: 0f406c42 Branch: fibers Author: Justin Lu Date: 2025-10-06 16:11:59 +0000 URL: https://git.openjdk.org/loom/commit/0f406c420e35f7a4358dc99711fd23d162f21777 8369078: Fix faulty test conversion in IllegalCharsetName.java Reviewed-by: naoto, alanb ! test/jdk/java/nio/charset/Charset/IllegalCharsetName.java Changeset: 2376a9e9 Branch: fibers Author: Erik Gahlin Date: 2025-10-06 17:30:42 +0000 URL: https://git.openjdk.org/loom/commit/2376a9e9727e9cb3020dd3f57584950a4cdcdab6 8365630: jdk/jfr/tool/TestPrintContextual.java fails with wrong spanId Reviewed-by: shade ! test/jdk/jdk/jfr/tool/TestPrintContextual.java Changeset: eb34a117 Branch: fibers Author: Mikael Vidstedt Date: 2025-10-07 00:52:38 +0000 URL: https://git.openjdk.org/loom/commit/eb34a117934951af075a425ce2cf8d3b1ced9700 8369242: Rename URL variables in devkit/Tools.gmk Reviewed-by: erikj ! make/devkit/Tools.gmk Changeset: e783c524 Branch: fibers Author: Prasanta Sadhukhan Date: 2025-10-07 04:08:32 +0000 URL: https://git.openjdk.org/loom/commit/e783c524c17e1d1a3fff4b6370e222134e66edc8 8368185: Test javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java failed: Synth ButtonUI does not handle PRESSED & MOUSE_OVER state Reviewed-by: tr, aivanov ! test/jdk/javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java Changeset: 6f0e7a8d Branch: fibers Author: Alan Bateman Date: 2025-10-07 06:49:11 +0000 URL: https://git.openjdk.org/loom/commit/6f0e7a8db9f1e6e2bcd8138492f16ca9e1ef45f3 Merge branch 'master' into fibers Changeset: b886cc9b Branch: fibers Author: Alan Bateman Date: 2025-10-07 06:50:23 +0000 URL: https://git.openjdk.org/loom/commit/b886cc9b08774408ff1b83540aece98d3269c6e7 Sync up FJP from pull/26479 ! src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java From duke at openjdk.org Tue Oct 7 07:10:04 2025 From: duke at openjdk.org (duke) Date: Tue, 7 Oct 2025 07:10:04 GMT Subject: git: openjdk/loom: master: 17 new changesets Message-ID: Changeset: f740cd2a Branch: master Author: Chad Rakoczy Committer: Evgeny Astigeevich Date: 2025-10-04 21:17:26 +0000 URL: https://git.openjdk.org/loom/commit/f740cd2aad43a008da1ed1ff15ebe2c790f893a0 8316694: Implement relocation of nmethod within CodeCache Reviewed-by: kvn, eosterlund, never, eastigeevich, bulasevich ! src/hotspot/cpu/aarch64/relocInfo_aarch64.cpp ! src/hotspot/share/code/codeBehaviours.cpp ! src/hotspot/share/code/codeBehaviours.hpp ! src/hotspot/share/code/codeCache.hpp ! src/hotspot/share/code/compiledIC.cpp ! src/hotspot/share/code/compiledIC.hpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/code/relocInfo.cpp ! src/hotspot/share/compiler/oopMap.cpp ! src/hotspot/share/compiler/oopMap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahUnload.cpp ! src/hotspot/share/gc/z/zUnload.cpp ! src/hotspot/share/jvmci/jvmciRuntime.hpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/globals.hpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/NMethod.java ! test/hotspot/jtreg/compiler/whitebox/CompilerWhiteBoxTest.java + test/hotspot/jtreg/compiler/whitebox/DeoptimizeRelocatedNMethod.java + test/hotspot/jtreg/compiler/whitebox/RelocateNMethod.java + test/hotspot/jtreg/compiler/whitebox/RelocateNMethodMultiplePaths.java + test/hotspot/jtreg/compiler/whitebox/StressNMethodRelocation.java + test/hotspot/jtreg/serviceability/jvmti/NMethodRelocation/NMethodRelocationTest.java + test/hotspot/jtreg/serviceability/jvmti/NMethodRelocation/libNMethodRelocationTest.cpp ! test/lib/jdk/test/whitebox/WhiteBox.java ! test/lib/jdk/test/whitebox/code/CodeBlob.java Changeset: 5d9f94e0 Branch: master Author: Vladimir Kozlov Date: 2025-10-05 16:20:53 +0000 URL: https://git.openjdk.org/loom/commit/5d9f94e05e1527745271d0167a418741607619e2 8369152: Problem list new tests from JDK-8316694 Reviewed-by: jpai, dholmes, serb ! test/hotspot/jtreg/ProblemList.txt Changeset: ba7bf43c Branch: master Author: Vladimir Ivanov Committer: Sandhya Viswanathan Date: 2025-10-05 23:55:53 +0000 URL: https://git.openjdk.org/loom/commit/ba7bf43c76c94bea85dbbd865794184b7ee0cc86 8365290: [perf] x86 ArrayFill intrinsic generates SPLIT_STORE for unaligned arrays Reviewed-by: sviswanathan, vpaprotski, kvn ! src/hotspot/cpu/x86/macroAssembler_x86.cpp Changeset: 85877e20 Branch: master Author: Damon Fenacci Date: 2025-10-06 06:17:48 +0000 URL: https://git.openjdk.org/loom/commit/85877e2022114031ef1ba13c67bf768edb0dfaa7 8355354: C2 crashed: assert(_callee == nullptr || _callee == m) failed: repeated inline attempt with different callee Reviewed-by: vlivanov, dlong ! src/hotspot/share/opto/callGenerator.cpp ! src/hotspot/share/opto/callGenerator.hpp ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp Changeset: 069c569a Branch: master Author: Johan Sj?len Date: 2025-10-06 07:48:45 +0000 URL: https://git.openjdk.org/loom/commit/069c569a710f50bc715f523c6c4c7aa087694af6 8368097: [asan] heap-buffer-overflow reported in ClassFileParser::skip_over_field_signature Reviewed-by: dholmes, mbaesken ! src/hotspot/share/classfile/classFileParser.cpp Changeset: e6781fd9 Branch: master Author: Fredrik Bredberg Date: 2025-10-06 08:10:11 +0000 URL: https://git.openjdk.org/loom/commit/e6781fd9497723a7baab38d6bfb958ba1b1c24ff 8367601: Remove held_monitor_count Reviewed-by: mdoerr, pchilanomate, fyang ! src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/ppc/globalDefinitions_ppc.hpp ! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp ! src/hotspot/cpu/riscv/globalDefinitions_riscv.hpp ! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp ! src/hotspot/cpu/riscv/macroAssembler_riscv.hpp ! src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp ! src/hotspot/cpu/x86/globalDefinitions_x86.hpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/hotspot/share/runtime/continuation.hpp ! src/hotspot/share/runtime/continuationEntry.cpp ! src/hotspot/share/runtime/continuationEntry.hpp ! src/hotspot/share/runtime/continuationFreezeThaw.cpp ! src/hotspot/share/runtime/javaThread.cpp ! src/hotspot/share/runtime/javaThread.hpp ! src/hotspot/share/runtime/objectMonitor.cpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp ! src/hotspot/share/runtime/synchronizer.cpp ! src/hotspot/share/runtime/synchronizer.inline.hpp ! src/java.base/share/classes/jdk/internal/vm/Continuation.java Changeset: 59e87437 Branch: master Author: Roberto Casta?eda Lozano Date: 2025-10-06 08:14:24 +0000 URL: https://git.openjdk.org/loom/commit/59e87437b4f9259121710dca5e595ca714c3e71b 8368753: IGV: improve CFG view of difference graphs Reviewed-by: chagedorn, mhaessig, dfenacci ! src/utils/IdealGraphVisualizer/Data/src/main/java/com/sun/hotspot/igv/data/InputBlock.java ! src/utils/IdealGraphVisualizer/Data/src/main/java/com/sun/hotspot/igv/data/services/Scheduler.java ! src/utils/IdealGraphVisualizer/Difference/src/main/java/com/sun/hotspot/igv/difference/Difference.java ! src/utils/IdealGraphVisualizer/ServerCompiler/src/main/java/com/sun/hotspot/igv/servercompiler/ServerCompilerScheduler.java Changeset: baf8bc57 Branch: master Author: Francesco Andreuzzi Committer: Aleksey Shipilev Date: 2025-10-06 08:14:44 +0000 URL: https://git.openjdk.org/loom/commit/baf8bc5701c43425e3345f82d4318b134b26d7c9 8369038: Parallel: Use NMethodMarkingScope and ThreadsClaimTokenScope in psParallelCompact Reviewed-by: ayang, shade ! src/hotspot/share/gc/parallel/psParallelCompact.cpp Changeset: 2c114d67 Branch: master Author: SendaoYan Date: 2025-10-06 09:26:51 +0000 URL: https://git.openjdk.org/loom/commit/2c114d676d9904094dd6058d15f06d801ec7a3d6 8367899: compiler/c2/gvn/TestBitCompressValueTransform.java intermittent timed out Reviewed-by: dfenacci, chagedorn ! test/hotspot/jtreg/compiler/c2/gvn/TestBitCompressValueTransform.java Changeset: 2bfada3f Branch: master Author: jonghoonpark Committer: Thomas Schatzl Date: 2025-10-06 11:53:14 +0000 URL: https://git.openjdk.org/loom/commit/2bfada3f58df6c041d948267368cbc4db915cac3 8364927: Add @requires annotation to TestReclaimStringsLeaksMemory.java Reviewed-by: tschatzl, stefank, ayang ! test/hotspot/jtreg/gc/stress/TestReclaimStringsLeaksMemory.java Changeset: e3320a9d Branch: master Author: Nizar Benalla Date: 2025-10-06 13:32:46 +0000 URL: https://git.openjdk.org/loom/commit/e3320a9df592a06c466ae9158d8f173921679952 8367610: Test tools/sincechecker/modules/java.base/JavaBaseCheckSince.java timed out on Windows Reviewed-by: liach ! test/jdk/tools/sincechecker/modules/java.base/JavaBaseCheckSince.java Changeset: b6a4cfec Branch: master Author: Mahendra Chhipa Date: 2025-10-06 15:26:59 +0000 URL: https://git.openjdk.org/loom/commit/b6a4cfecb731615b6ef70828ac10fae4b2264cdc 8367114: Update jdk.test.lib.net.SimpleHttpServer to use SimpleFileServer Reviewed-by: dfuchs, vyazici ! test/jaxp/javax/xml/jaxp/unittest/catalog/CatalogFileInputTest.java - test/jdk/com/sun/net/httpserver/SimpleFileServer.java ! test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarHttpProperties.java ! test/jdk/sun/net/www/protocol/jar/MultiReleaseJarURLConnection.java - test/lib/jdk/test/lib/net/SimpleHttpServer.java Changeset: 596af0a7 Branch: master Author: Albert Mingkun Yang Date: 2025-10-06 15:44:13 +0000 URL: https://git.openjdk.org/loom/commit/596af0a7cc37e359d54689be20f855a86ae46567 8369041: Release memory after testing in ThreadsRunner.java Reviewed-by: shade, tschatzl ! test/hotspot/jtreg/vmTestbase/nsk/share/runner/ThreadsRunner.java Changeset: 0f406c42 Branch: master Author: Justin Lu Date: 2025-10-06 16:11:59 +0000 URL: https://git.openjdk.org/loom/commit/0f406c420e35f7a4358dc99711fd23d162f21777 8369078: Fix faulty test conversion in IllegalCharsetName.java Reviewed-by: naoto, alanb ! test/jdk/java/nio/charset/Charset/IllegalCharsetName.java Changeset: 2376a9e9 Branch: master Author: Erik Gahlin Date: 2025-10-06 17:30:42 +0000 URL: https://git.openjdk.org/loom/commit/2376a9e9727e9cb3020dd3f57584950a4cdcdab6 8365630: jdk/jfr/tool/TestPrintContextual.java fails with wrong spanId Reviewed-by: shade ! test/jdk/jdk/jfr/tool/TestPrintContextual.java Changeset: eb34a117 Branch: master Author: Mikael Vidstedt Date: 2025-10-07 00:52:38 +0000 URL: https://git.openjdk.org/loom/commit/eb34a117934951af075a425ce2cf8d3b1ced9700 8369242: Rename URL variables in devkit/Tools.gmk Reviewed-by: erikj ! make/devkit/Tools.gmk Changeset: e783c524 Branch: master Author: Prasanta Sadhukhan Date: 2025-10-07 04:08:32 +0000 URL: https://git.openjdk.org/loom/commit/e783c524c17e1d1a3fff4b6370e222134e66edc8 8368185: Test javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java failed: Synth ButtonUI does not handle PRESSED & MOUSE_OVER state Reviewed-by: tr, aivanov ! test/jdk/javax/swing/plaf/synth/SynthButtonUI/6276188/bug6276188.java From dreamlike.vertx at gmail.com Wed Oct 8 14:57:00 2025 From: dreamlike.vertx at gmail.com (Mengyang Li) Date: Wed, 8 Oct 2025 22:57:00 +0800 Subject: Scheduler API Feedback In-Reply-To: References: Message-ID: *Thank you for your reply.* While testing the code, I found an issue when using the custom scheduler feature. When I delegate to the default scheduler, I noticed that the nested virtual thread created inside another virtual thread does *not* actually ?use? my custom scheduler. ``` java public static void main(String[] args) throws Throwable { System.getProperties().setProperty("jdk.virtualThreadScheduler.implClass", "io.github.dreamlike.CustomerVirtualThreadScheduler"); CompletableFuture future = new CompletableFuture<>(); Thread.ofVirtual() .name("parent vt") .start(() -> { Thread.ofVirtual().name("sub vt") .start(() -> { future.complete(null); }); }); future.get(); } // other file io/github/dreamlike/CustomerVirtualThreadScheduler.java public class CustomerVirtualThreadScheduler implements Thread.VirtualThreadScheduler { private final Thread.VirtualThreadScheduler defaultScheduler; public CustomerVirtualThreadScheduler(Thread.VirtualThreadScheduler defaultScheduler) { this.defaultScheduler = defaultScheduler; } @Override public void execute(Thread vthread, Runnable task) { Thread thread = Thread.currentThread(); System.out.println(thread.getClass()); System.out.println(vthread.toString() + " " + vthread.getState() + " currentThread " + thread + " current is virtual " + thread.isVirtual()); new RuntimeException().printStackTrace(); defaultScheduler.execute(vthread, task); } } ``` Console output: ``` bash WARNING: Using custom default scheduler, this is an experimental feature! class java.lang.Thread VirtualThread[#27,VirtualThreadA]/runnable RUNNABLE currentThread Thread[#3,main,5,main] current is virtual false java.lang.RuntimeException at io.github.dreamlike.CustomerVirtualThreadScheduler.execute(CustomerVirtualThreadScheduler.java:16) at java.base/java.lang.VirtualThread.submitRunContinuation(VirtualThread.java:367) at java.base/java.lang.VirtualThread.externalSubmitRunContinuationOrThrow(VirtualThread.java:456) at java.base/java.lang.VirtualThread.start(VirtualThread.java:734) at java.base/java.lang.VirtualThread.start(VirtualThread.java:745) at java.base/java.lang.ThreadBuilders$VirtualThreadBuilder.start(ThreadBuilders.java:257) at io.github.dreamlike.VTMain.main(VTMain.java:14) ``` After checking the relevant code, it seems that execution goes through the *first branch* below. This behavior doesn?t appear to align with the semantics of a custom scheduler ? the nested virtual thread is submitted directly to ct.getPool() instead of going through CustomerVirtualThreadScheduler::execute. ``` java // VirtualThread.java private void externalSubmitRunContinuationOrThrow() { if (scheduler == DEFAULT_SCHEDULER && currentCarrierThread() instanceof CarrierThread ct) { try { ct.getPool().externalSubmit(ForkJoinTask.adapt(runContinuation)); } catch (RejectedExecutionException ree) { submitFailed(ree); throw ree; } } else { submitRunContinuation(false); } } ``` Best regards, Mengyang li Alan Bateman ?2025?10?5??? 00:35??? > On 04/10/2025 14:19, dreamlike_ocean lei wrote: > > Hello @loom-dev , > > I have been enjoying the new POLLER_PER_CARRIER design in the Loom repo > and I really like the direction it is going. > While building on top of the latest code, I noticed a couple of issues and > would like to ask for clarification. > > Thanks for your mail. It's useful to hear from folks that are trying out > the experimental support for custom schedulers in the loom repo as this > will help to inform whether any of the directions prototyped should be > taken further. > > BTW: I assume "dreamlike_ocean lei" isn't your real name. It would be > helpful to use a real name or affiliation so we have some idea who you are. > > > 1. > > When calling Thread.startVirtualThread, the new virtual thread does > not inherit the scheduler of the calling virtual thread, but instead uses > DEFAULT_SCHEDULER. What is the reasoning behind this design? Could > there be a mechanism to allow implicit inheritance? This would be very > helpful for custom schedulers based on the per-core model. > > In a system with several virtual thread schedulers in use, which I think > is what you mean, then it would be unpredictable and problematic to inherit > the scheduler in many cases. If some library were, on first usage, start a > virtual thread as a "background thread" that runs indefinitely then > inheritance would mean it depends on the first usage. Examples where > inheritance at thread create time is problematic are the thread context > class loader, and until recently, the inherited access control context. > > When you say "custom schedulers based on the per-core model" do you mean > you are experimenting with a scheduler per core in order to get "carrier > affinity" (virtual thread X will always be scheduled on carrier Y). You > might also be using processor affinity to bind carrier Y to specific sets > of CPUs. > > You might find it simpler to just use one scheduler and keep a mapping of > virtual thread to carrier. That would remove complications with lifecycle > that would arise if carriers were to terminate (e.g. idle/keep-alive). It > might avoid needing to expose APIs to get a virtual thread's scheduler, > which I think what your second point is about. > > -Alan > Alan Bateman ?2025?10?5??? 00:35??? > On 04/10/2025 14:19, dreamlike_ocean lei wrote: > > Hello @loom-dev , > > I have been enjoying the new POLLER_PER_CARRIER design in the Loom repo > and I really like the direction it is going. > While building on top of the latest code, I noticed a couple of issues and > would like to ask for clarification. > > Thanks for your mail. It's useful to hear from folks that are trying out > the experimental support for custom schedulers in the loom repo as this > will help to inform whether any of the directions prototyped should be > taken further. > > BTW: I assume "dreamlike_ocean lei" isn't your real name. It would be > helpful to use a real name or affiliation so we have some idea who you are. > > > 1. > > When calling Thread.startVirtualThread, the new virtual thread does > not inherit the scheduler of the calling virtual thread, but instead uses > DEFAULT_SCHEDULER. What is the reasoning behind this design? Could > there be a mechanism to allow implicit inheritance? This would be very > helpful for custom schedulers based on the per-core model. > > In a system with several virtual thread schedulers in use, which I think > is what you mean, then it would be unpredictable and problematic to inherit > the scheduler in many cases. If some library were, on first usage, start a > virtual thread as a "background thread" that runs indefinitely then > inheritance would mean it depends on the first usage. Examples where > inheritance at thread create time is problematic are the thread context > class loader, and until recently, the inherited access control context. > > When you say "custom schedulers based on the per-core model" do you mean > you are experimenting with a scheduler per core in order to get "carrier > affinity" (virtual thread X will always be scheduled on carrier Y). You > might also be using processor affinity to bind carrier Y to specific sets > of CPUs. > > You might find it simpler to just use one scheduler and keep a mapping of > virtual thread to carrier. That would remove complications with lifecycle > that would arise if carriers were to terminate (e.g. idle/keep-alive). It > might avoid needing to expose APIs to get a virtual thread's scheduler, > which I think what your second point is about. > > -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Wed Oct 8 15:24:43 2025 From: cushon at google.com (Liam Miller-Cushon) Date: Wed, 8 Oct 2025 17:24:43 +0200 Subject: Custom Schedulers use-case Message-ID: Hi, My colleague David Gay has the following use-case for Custom Schedulers ( https://github.com/openjdk/loom/blob/fibers/loom-docs/CustomSchedulers.md): A multi-tenant server needs to provide isolation, in particular CPU isolation, between the workloads of different customers. A good way to achieve this when using virtual threads is to use some form of fair-share scheduler to allocate carrier threads to virtual threads. Custom schedulers provide a straightforward, efficient, and safe way to support this use case. Absent custom schedulers, it is possible to work around this by surrounding all blocking points in a virtual thread by blocking interactions with the fair scheduler. This however poses significant reliability risks, as identifying these points is not straightforward and missing any of them affects the fairness of the scheduling and risks starvation or deadlock. -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Wed Oct 8 15:59:13 2025 From: duke at openjdk.org (duke) Date: Wed, 8 Oct 2025 15:59:13 GMT Subject: git: openjdk/loom: fibers: 4 new changesets Message-ID: Changeset: 6079bfef Branch: fibers Author: Patricio Chilano Mateo Date: 2025-10-05 16:43:48 +0000 URL: https://git.openjdk.org/loom/commit/6079bfef3f960249b682925d53bc9b48c4549af5 Remove changes to doYield_stub ! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp ! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp ! src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/share/runtime/continuationEntry.cpp ! src/hotspot/share/runtime/continuationEntry.hpp ! src/hotspot/share/runtime/continuationFreezeThaw.cpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp Changeset: 65bfb1fc Branch: fibers Author: Patricio Chilano Mateo Date: 2025-10-05 18:05:48 +0000 URL: https://git.openjdk.org/loom/commit/65bfb1fc196bfa80587549b57064638b2e80346f use Bytecode_invoke to retrieve parameter size ! src/hotspot/share/runtime/continuationFreezeThaw.cpp Changeset: 67d650d4 Branch: fibers Author: Patricio Chilano Mateo Date: 2025-10-05 23:53:01 +0000 URL: https://git.openjdk.org/loom/commit/67d650d4c9b9bdec62162b17936f9a98f49cf8f6 Improve comments ! src/hotspot/share/runtime/continuationFreezeThaw.cpp Changeset: 6c47a1a8 Branch: fibers Author: Patricio Chilano Mateo Date: 2025-10-08 11:53:12 +0000 URL: https://git.openjdk.org/loom/commit/6c47a1a86e0cf88f3393b77c7d115923494a3c4c Increase timeout on LotsOfContendedMonitorEnter ! test/jdk/java/lang/Thread/virtual/stress/LotsOfContendedMonitorEnter.java From alan.bateman at oracle.com Wed Oct 8 17:44:24 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Wed, 8 Oct 2025 18:44:24 +0100 Subject: Scheduler API Feedback In-Reply-To: References: Message-ID: <5a78031c-ce4a-4d46-9a41-11eb9c50a598@oracle.com> On 08/10/2025 15:57, Mengyang Li wrote: > > > ``` > > Console output: > ``` bash > WARNING: Using custom default scheduler, this is an experimental feature! > class java.lang.Thread > VirtualThread[#27,VirtualThreadA]/runnable RUNNABLE currentThread > Thread[#3,main,5,main] current is virtual false > java.lang.RuntimeException > ? ? ? ? at > io.github.dreamlike.CustomerVirtualThreadScheduler.execute(CustomerVirtualThreadScheduler.java:16) > ? ? ? ? at > java.base/java.lang.VirtualThread.submitRunContinuation(VirtualThread.java:367) > ? ? ? ? at > java.base/java.lang.VirtualThread.externalSubmitRunContinuationOrThrow(VirtualThread.java:456) > ? ? ? ? at java.base/java.lang.VirtualThread.start(VirtualThread.java:734) > ? ? ? ? at java.base/java.lang.VirtualThread.start(VirtualThread.java:745) > ? ? ? ? at > java.base/java.lang.ThreadBuilders$VirtualThreadBuilder.start(ThreadBuilders.java:257) > ? ? ? ? at io.github.dreamlike.VTMain.main(VTMain.java:14) > ``` > > After checking the relevant code, it seems that execution goes through > the *first branch*?below. > > This behavior doesn?t appear to align with the semantics of a custom > scheduler ? the nested virtual thread is submitted directly to > ct.getPool()?instead of going through > CustomerVirtualThreadScheduler::execute. > Thanks for the mail. You are correct. There is confusion between the "custom default scheduler" and the "built-in default scheduler" when the former delegates to the latter. I'll sort it out. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Wed Oct 8 19:20:19 2025 From: duke at openjdk.org (duke) Date: Wed, 8 Oct 2025 19:20:19 GMT Subject: git: openjdk/loom: fibers: 35 new changesets Message-ID: Changeset: 07549f3e Branch: fibers Author: Beno?t Maillard Committer: Tobias Hartmann Date: 2025-10-07 07:43:43 +0000 URL: https://git.openjdk.org/loom/commit/07549f3e1539a2dd491a4f9ffe9df8580d7d7dea 8360389: Support printing from C2 compiled code Reviewed-by: kvn, thartmann, mhaessig ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/opto/runtime.cpp ! src/hotspot/share/opto/runtime.hpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp Changeset: c06d6805 Branch: fibers Author: Daniel Skantz Date: 2025-10-07 09:04:39 +0000 URL: https://git.openjdk.org/loom/commit/c06d6805aae3af2e6175f3f43deea46c9ce08bc6 8362394: C2: Repeated stacked string concatenation fails with "Hit MemLimit" and other resourcing errors Reviewed-by: chagedorn, rcastanedalo ! src/hotspot/share/opto/stringopts.cpp + test/hotspot/jtreg/compiler/stringopts/TestStackedConcatsMany.java Changeset: aed9485b Branch: fibers Author: Andrew Haley Date: 2025-10-07 10:09:23 +0000 URL: https://git.openjdk.org/loom/commit/aed9485bbb1d93063e5e5f60ed84bfb36053bdd1 8368303: AlwaysAtomicAccesses is excessively strict Reviewed-by: shade, vlivanov, dlong ! src/hotspot/share/gc/shared/c1/barrierSetC1.cpp Changeset: 6bec42ad Branch: fibers Author: Alexey Ivanov Date: 2025-10-07 10:21:33 +0000 URL: https://git.openjdk.org/loom/commit/6bec42adcc1d99e16ddd5148bb4012c74a0c3090 8368892: Make JEditorPane/TestBrowserBGColor.java headless Reviewed-by: serb, azvegint ! test/jdk/javax/swing/JEditorPane/TestBrowserBGColor.java Changeset: 9c46febc Branch: fibers Author: Yasumasa Suenaga Date: 2025-10-07 12:47:40 +0000 URL: https://git.openjdk.org/loom/commit/9c46febcac01b9f1831f5f3e2a68dd1f1612a01f 8245234: Still seeing missing mixed stack traces, even after JDK-8234624 Reviewed-by: kevinw, cjplummer ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/amd64/LinuxAMD64CFrame.java Changeset: 4b4d0cd3 Branch: fibers Author: Johny Jose Committer: Mark Sheppard Date: 2025-10-07 13:13:42 +0000 URL: https://git.openjdk.org/loom/commit/4b4d0cd35a32448e4b056109c502af2765766432 8365398: TEST_BUG: java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java failing intermittently Reviewed-by: msheppar, smarks, jpai ! test/jdk/ProblemList.txt ! test/jdk/java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java Changeset: a9c93f86 Branch: fibers Author: Albert Mingkun Yang Date: 2025-10-07 13:40:19 +0000 URL: https://git.openjdk.org/loom/commit/a9c93f865bb5438420bc4df278d211ff3af9a0ad 8369263: Parallel: Inline PSPromotionManager::push_depth Reviewed-by: iwalulya, shade, fandreuzzi ! src/hotspot/share/gc/parallel/psPromotionManager.hpp ! src/hotspot/share/gc/parallel/psPromotionManager.inline.hpp Changeset: 0f2a95c1 Branch: fibers Author: jonghoonpark Committer: Albert Mingkun Yang Date: 2025-10-07 15:13:23 +0000 URL: https://git.openjdk.org/loom/commit/0f2a95c15d7c1e3796660d786c9a72497dab5ab1 8365782: Remove unnecessary inclusion of in jfrOSInterface.cpp Reviewed-by: ayang, tschatzl ! src/hotspot/share/jfr/periodic/jfrOSInterface.cpp Changeset: 8a20656e Branch: fibers Author: Hannes Walln?fer Date: 2025-10-07 15:16:08 +0000 URL: https://git.openjdk.org/loom/commit/8a20656ed03aa26806c7b4a4e361999dea62aa79 8367321: Fix CSS bugs in dark theme 8366942: Dark mode pages briefly blink before going dark Reviewed-by: nbenalla, liach ! 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/script.js.template ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/stylesheet.css ! test/langtools/jdk/javadoc/doclet/testSearch/TestSearch.java Changeset: eb729f0a Branch: fibers Author: Erik Gahlin Date: 2025-10-07 15:38:58 +0000 URL: https://git.openjdk.org/loom/commit/eb729f0aaa2297c3b3dbadadf40a502d2d9ed124 8247776: JFR: TestThreadContextSwitches.java failed "RuntimeException: No events: expected false, was true" Reviewed-by: mgronlun ! test/jdk/jdk/jfr/event/os/TestThreadContextSwitches.java Changeset: eb835e05 Branch: fibers Author: Volkan Yazici Date: 2025-10-07 15:57:31 +0000 URL: https://git.openjdk.org/loom/commit/eb835e05f9cf8a65d804b733b382ecfba5b12907 8366040: Change URL.lookupViaProviders to use ScopedValue to detect recursive lookup Reviewed-by: alanb, dfuchs ! src/java.base/share/classes/java/net/URL.java ! test/jdk/java/net/spi/URLStreamHandlerProvider/Basic.java + test/jdk/java/net/spi/URLStreamHandlerProvider/circular.provider.template Changeset: 4ca3ab62 Branch: fibers Author: Joe Darcy Date: 2025-10-07 16:41:45 +0000 URL: https://git.openjdk.org/loom/commit/4ca3ab62759b366fd3e0b2267925f1fa70f057b7 8369123: Still more small Float16 refactorings Reviewed-by: rgiulietti ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java Changeset: ebeb77ba Branch: fibers Author: Phil Race Date: 2025-10-07 16:47:43 +0000 URL: https://git.openjdk.org/loom/commit/ebeb77baaeb6d9098d7462f5ddf61d8583b1e493 8358058: sun/java2d/OpenGL/DrawImageBg.java Test fails intermittently Reviewed-by: azvegint, serb, psadhukhan ! test/jdk/ProblemList.txt + test/jdk/sun/java2d/OpenGL/DrawBitmaskImage.java + test/jdk/sun/java2d/OpenGL/DrawBufImgOp.java + test/jdk/sun/java2d/OpenGL/DrawImageBg.java + test/jdk/sun/java2d/OpenGL/LargeOps.java + test/jdk/sun/java2d/OpenGL/OpaqueDest.java + test/jdk/sun/java2d/OpenGL/ScaleParamsOOB.java + test/jdk/sun/java2d/OpenGL/ShapeClip.java + test/jdk/sun/java2d/OpenGL/SrcMaskOps.java + test/jdk/sun/java2d/OpenGL/VolatileSubRegion.java + test/jdk/sun/java2d/OpenGL/XformVolatile.java Changeset: 1ea8cfa6 Branch: fibers Author: Aleksey Shipilev Date: 2025-10-07 16:54:36 +0000 URL: https://git.openjdk.org/loom/commit/1ea8cfa6dc8e6f96fd87553331abaae17ec173ea 8369226: GHA: Switch to MacOS 15 Reviewed-by: erikj, ayang, sgehwolf ! .github/workflows/main.yml Changeset: 6b316262 Branch: fibers Author: Naoto Sato Date: 2025-10-07 17:21:13 +0000 URL: https://git.openjdk.org/loom/commit/6b3162620bd808227ec7b4331ae6fc32ceb909e8 8368845: x-IBM930 uses incorrect character for Hex 42 60 Reviewed-by: sherman, rriggs, iris ! make/data/charsetmapping/IBM930.c2b ! make/data/charsetmapping/IBM930.map ! test/jdk/sun/nio/cs/mapping/CoderTest.java ! test/jdk/sun/nio/cs/mapping/ConverterTest.java ! test/jdk/sun/nio/cs/mapping/Cp930.b2c ! test/jdk/sun/nio/cs/mapping/TestConv.java Changeset: 7f070d35 Branch: fibers Author: Mikael Vidstedt Date: 2025-10-07 17:37:31 +0000 URL: https://git.openjdk.org/loom/commit/7f070d356c479ae30fe84fcf4d322c0b693fa15a 8369246: Use https in make/devkit scripts Reviewed-by: ayang, erikj ! make/devkit/Tools.gmk ! make/devkit/createAutoconfBundle.sh Changeset: 6bfd018b Branch: fibers Author: Phil Race Date: 2025-10-07 19:08:22 +0000 URL: https://git.openjdk.org/loom/commit/6bfd018beaf187940ebafc71885045b4aabca673 8366002: Beans.instantiate needs to describe the lookup procedure Reviewed-by: serb, aivanov ! src/java.desktop/share/classes/java/beans/Beans.java Changeset: 910bb68e Branch: fibers Author: Archie Cobbs Date: 2025-10-07 19:32:08 +0000 URL: https://git.openjdk.org/loom/commit/910bb68e5191f830ff6f3dff5753e4e5f6214a7b 8349847: Support configuring individual lint categories as errors Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Options.java ! src/jdk.compiler/share/man/javac.md + test/langtools/tools/javac/warnings/WerrorLint.e1.out + test/langtools/tools/javac/warnings/WerrorLint.e2.out + test/langtools/tools/javac/warnings/WerrorLint.java + test/langtools/tools/javac/warnings/WerrorLint.w1.out + test/langtools/tools/javac/warnings/WerrorLint.w2.out Changeset: 4ee6079b Branch: fibers Author: Mikael Vidstedt Date: 2025-10-08 02:05:20 +0000 URL: https://git.openjdk.org/loom/commit/4ee6079b11034e7de8be72cd2832fb717c2f140d 8369328: Use uppercase variable names in the devkit makefiles Reviewed-by: erikj ! make/devkit/Makefile ! make/devkit/Tools.gmk Changeset: 650fd35b Branch: fibers Author: Prasanta Sadhukhan Date: 2025-10-08 03:00:30 +0000 URL: https://git.openjdk.org/loom/commit/650fd35b3b30bf16e8caad968bd335d423c87b7d 8335646: Nimbus : JLabel not painted with LAF defined foreground color on Ubuntu 24.04 Reviewed-by: aivanov, dnguyen, serb ! test/jdk/javax/swing/plaf/basic/BasicHTML/bug4248210.java Changeset: 2ac24bf1 Branch: fibers Author: Emanuel Peter Date: 2025-10-08 03:06:29 +0000 URL: https://git.openjdk.org/loom/commit/2ac24bf1bac9c32704ebd72b93a75819b9404063 8367389: C2 SuperWord: refactor VTransform to model the whole loop instead of just the basic block Reviewed-by: roland, mhaessig ! src/hotspot/share/opto/phasetype.hpp ! src/hotspot/share/opto/superword.cpp ! src/hotspot/share/opto/superword.hpp ! src/hotspot/share/opto/superwordVTransformBuilder.cpp ! src/hotspot/share/opto/superwordVTransformBuilder.hpp ! src/hotspot/share/opto/vectorization.cpp ! src/hotspot/share/opto/vectorization.hpp ! src/hotspot/share/opto/vtransform.cpp ! src/hotspot/share/opto/vtransform.hpp ! test/hotspot/jtreg/compiler/lib/ir_framework/CompilePhase.java Changeset: 86211956 Branch: fibers Author: Jan Lahoda Date: 2025-10-08 05:32:51 +0000 URL: https://git.openjdk.org/loom/commit/862119565db311fe0e02e383fd3493601ed23ea8 8363917: SwitchBootstraps.enumSwitch() args not checked as documented Reviewed-by: liach ! src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java ! test/jdk/java/lang/runtime/SwitchBootstrapsTest.java Changeset: bd25db1f Branch: fibers Author: Matthias Baesken Date: 2025-10-08 07:02:34 +0000 URL: https://git.openjdk.org/loom/commit/bd25db1fb8573fc908f7a8a96bca417b1d44689a 8368960: Adjust java UL logging in the build Reviewed-by: erikj, dholmes ! make/ToolsJdk.gmk ! make/autoconf/boot-jdk.m4 Changeset: d27649fe Branch: fibers Author: Johannes Bechberger Date: 2025-10-08 08:03:32 +0000 URL: https://git.openjdk.org/loom/commit/d27649fe22a5bed9db72ac6c2595ac91f1fa28f8 8367302: New test jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082 is failing Reviewed-by: dholmes, apangin ! src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp ! src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.hpp ! src/hotspot/share/prims/whitebox.cpp ! test/jdk/ProblemList-Xcomp.txt ! test/jdk/jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java ! test/lib/jdk/test/whitebox/WhiteBox.java Changeset: f58e17fd Branch: fibers Author: Ant?n Seoane Ampudia Committer: Roberto Casta?eda Lozano Date: 2025-10-08 08:58:58 +0000 URL: https://git.openjdk.org/loom/commit/f58e17fd27e868e4a8816befc4c4bb8946c1f7fd 8368780: IGV: Upgrade to Netbeans Platform 27 Reviewed-by: rcastanedalo, chagedorn ! src/utils/IdealGraphVisualizer/Filter/pom.xml ! src/utils/IdealGraphVisualizer/README.md ! src/utils/IdealGraphVisualizer/pom.xml Changeset: d45e65ba Branch: fibers Author: Suchismith Roy Committer: Varada M Date: 2025-10-08 09:15:23 +0000 URL: https://git.openjdk.org/loom/commit/d45e65bab45f78f9f378cdc53837fe33190b7801 8030957: AIX: Implement OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX Reviewed-by: jkern, mdoerr, mbaesken ! src/jdk.management/aix/native/libmanagement_ext/UnixOperatingSystem.c ! test/jdk/ProblemList.txt Changeset: c6695064 Branch: fibers Author: Albert Mingkun Yang Date: 2025-10-08 09:29:24 +0000 URL: https://git.openjdk.org/loom/commit/c66950643e4f43b5997b223289eefdde589589fa 8369277: Remove unused CodeCacheUnloadingTask::_num_workers Reviewed-by: shade, tschatzl ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1ParallelCleaning.cpp ! src/hotspot/share/gc/g1/g1ParallelCleaning.hpp ! src/hotspot/share/gc/shared/parallelCleaning.cpp ! src/hotspot/share/gc/shared/parallelCleaning.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahParallelCleaning.cpp ! src/hotspot/share/gc/shenandoah/shenandoahParallelCleaning.hpp Changeset: 6a4c2676 Branch: fibers Author: Afshin Zafari Date: 2025-10-08 09:49:48 +0000 URL: https://git.openjdk.org/loom/commit/6a4c2676a6378f573bd58d1bc32b57765d756291 8365385: [asan] os::pretouch_memory() is not compatible with ASAN Reviewed-by: stuefe, jsjolen ! src/hotspot/share/memory/metaspace/chunkManager.cpp ! src/hotspot/share/memory/metaspace/virtualSpaceNode.cpp Changeset: c12f0e74 Branch: fibers Author: Albert Mingkun Yang Date: 2025-10-08 11:21:22 +0000 URL: https://git.openjdk.org/loom/commit/c12f0e74a9acfaa91b537853143ec94f143fe316 8369286: Parallel: Assertion failure in mutableNUMASpace Reviewed-by: jsikstro, tschatzl ! src/hotspot/share/gc/parallel/psYoungGen.cpp Changeset: 23fcbb0b Branch: fibers Author: Ruben Ayrapetyan Committer: Evgeny Astigeevich Date: 2025-10-08 12:13:04 +0000 URL: https://git.openjdk.org/loom/commit/23fcbb0badbef6d22f63ca6c5b26b0693002592c 8365153: AArch64: Set JVM flags for Neoverse N3 and V3 cores Reviewed-by: eastigeevich, aph ! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp Changeset: 927aa3f8 Branch: fibers Author: Francesco Andreuzzi Committer: Thomas Schatzl Date: 2025-10-08 14:20:23 +0000 URL: https://git.openjdk.org/loom/commit/927aa3f8da34fb71b692661bebb89d20bfa85648 8369178: G1: Use NMethodMarkingScope and ThreadsClaimTokenScope in G1RootProcessor Reviewed-by: ayang, tschatzl ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1HeapVerifier.cpp ! src/hotspot/share/gc/g1/g1RootProcessor.cpp ! src/hotspot/share/gc/g1/g1RootProcessor.hpp ! src/hotspot/share/gc/g1/g1YoungCollector.cpp ! src/hotspot/share/gc/shared/strongRootsScope.cpp ! src/hotspot/share/gc/shared/strongRootsScope.hpp ! src/hotspot/share/runtime/safepoint.cpp Changeset: 79bcc7b8 Branch: fibers Author: Richard Reingruber Date: 2025-10-08 15:56:58 +0000 URL: https://git.openjdk.org/loom/commit/79bcc7b8ec577dad592dc3f575c15d1bdeb65b19 8369257: PPC: compiler/whitebox/RelocateNMethodMultiplePaths.java fails with assertion Reviewed-by: mdoerr ! src/hotspot/cpu/ppc/nativeInst_ppc.cpp Changeset: 883d6cda Branch: fibers Author: Alan Bateman Date: 2025-10-08 17:04:11 +0000 URL: https://git.openjdk.org/loom/commit/883d6cda61dfd93d425fe49a75d92989cfa18088 Merge branch 'master' into fibers ! test/jdk/ProblemList.txt ! test/jdk/ProblemList.txt Changeset: b9976330 Branch: fibers Author: Alan Bateman Date: 2025-10-08 18:17:04 +0000 URL: https://git.openjdk.org/loom/commit/b997633069e425269fa4ae68d1b6ffa6994f3e52 Fix custom scheduler delegating to built-in default scheduler ! src/java.base/share/classes/java/lang/VirtualThread.java ! test/jdk/java/lang/Thread/virtual/CustomDefaultScheduler.java Changeset: fbf125b0 Branch: fibers Author: Alan Bateman Date: 2025-10-08 18:17:14 +0000 URL: https://git.openjdk.org/loom/commit/fbf125b065e41be81e4cd7ab0ff0a408047dce04 Merge loom into fibers From duke at openjdk.org Wed Oct 8 19:22:07 2025 From: duke at openjdk.org (duke) Date: Wed, 8 Oct 2025 19:22:07 GMT Subject: git: openjdk/loom: master: 32 new changesets Message-ID: Changeset: 07549f3e Branch: master Author: Beno?t Maillard Committer: Tobias Hartmann Date: 2025-10-07 07:43:43 +0000 URL: https://git.openjdk.org/loom/commit/07549f3e1539a2dd491a4f9ffe9df8580d7d7dea 8360389: Support printing from C2 compiled code Reviewed-by: kvn, thartmann, mhaessig ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/opto/runtime.cpp ! src/hotspot/share/opto/runtime.hpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/sharedRuntime.hpp Changeset: c06d6805 Branch: master Author: Daniel Skantz Date: 2025-10-07 09:04:39 +0000 URL: https://git.openjdk.org/loom/commit/c06d6805aae3af2e6175f3f43deea46c9ce08bc6 8362394: C2: Repeated stacked string concatenation fails with "Hit MemLimit" and other resourcing errors Reviewed-by: chagedorn, rcastanedalo ! src/hotspot/share/opto/stringopts.cpp + test/hotspot/jtreg/compiler/stringopts/TestStackedConcatsMany.java Changeset: aed9485b Branch: master Author: Andrew Haley Date: 2025-10-07 10:09:23 +0000 URL: https://git.openjdk.org/loom/commit/aed9485bbb1d93063e5e5f60ed84bfb36053bdd1 8368303: AlwaysAtomicAccesses is excessively strict Reviewed-by: shade, vlivanov, dlong ! src/hotspot/share/gc/shared/c1/barrierSetC1.cpp Changeset: 6bec42ad Branch: master Author: Alexey Ivanov Date: 2025-10-07 10:21:33 +0000 URL: https://git.openjdk.org/loom/commit/6bec42adcc1d99e16ddd5148bb4012c74a0c3090 8368892: Make JEditorPane/TestBrowserBGColor.java headless Reviewed-by: serb, azvegint ! test/jdk/javax/swing/JEditorPane/TestBrowserBGColor.java Changeset: 9c46febc Branch: master Author: Yasumasa Suenaga Date: 2025-10-07 12:47:40 +0000 URL: https://git.openjdk.org/loom/commit/9c46febcac01b9f1831f5f3e2a68dd1f1612a01f 8245234: Still seeing missing mixed stack traces, even after JDK-8234624 Reviewed-by: kevinw, cjplummer ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/amd64/LinuxAMD64CFrame.java Changeset: 4b4d0cd3 Branch: master Author: Johny Jose Committer: Mark Sheppard Date: 2025-10-07 13:13:42 +0000 URL: https://git.openjdk.org/loom/commit/4b4d0cd35a32448e4b056109c502af2765766432 8365398: TEST_BUG: java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java failing intermittently Reviewed-by: msheppar, smarks, jpai ! test/jdk/ProblemList.txt ! test/jdk/java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java Changeset: a9c93f86 Branch: master Author: Albert Mingkun Yang Date: 2025-10-07 13:40:19 +0000 URL: https://git.openjdk.org/loom/commit/a9c93f865bb5438420bc4df278d211ff3af9a0ad 8369263: Parallel: Inline PSPromotionManager::push_depth Reviewed-by: iwalulya, shade, fandreuzzi ! src/hotspot/share/gc/parallel/psPromotionManager.hpp ! src/hotspot/share/gc/parallel/psPromotionManager.inline.hpp Changeset: 0f2a95c1 Branch: master Author: jonghoonpark Committer: Albert Mingkun Yang Date: 2025-10-07 15:13:23 +0000 URL: https://git.openjdk.org/loom/commit/0f2a95c15d7c1e3796660d786c9a72497dab5ab1 8365782: Remove unnecessary inclusion of in jfrOSInterface.cpp Reviewed-by: ayang, tschatzl ! src/hotspot/share/jfr/periodic/jfrOSInterface.cpp Changeset: 8a20656e Branch: master Author: Hannes Walln?fer Date: 2025-10-07 15:16:08 +0000 URL: https://git.openjdk.org/loom/commit/8a20656ed03aa26806c7b4a4e361999dea62aa79 8367321: Fix CSS bugs in dark theme 8366942: Dark mode pages briefly blink before going dark Reviewed-by: nbenalla, liach ! 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/script.js.template ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/stylesheet.css ! test/langtools/jdk/javadoc/doclet/testSearch/TestSearch.java Changeset: eb729f0a Branch: master Author: Erik Gahlin Date: 2025-10-07 15:38:58 +0000 URL: https://git.openjdk.org/loom/commit/eb729f0aaa2297c3b3dbadadf40a502d2d9ed124 8247776: JFR: TestThreadContextSwitches.java failed "RuntimeException: No events: expected false, was true" Reviewed-by: mgronlun ! test/jdk/jdk/jfr/event/os/TestThreadContextSwitches.java Changeset: eb835e05 Branch: master Author: Volkan Yazici Date: 2025-10-07 15:57:31 +0000 URL: https://git.openjdk.org/loom/commit/eb835e05f9cf8a65d804b733b382ecfba5b12907 8366040: Change URL.lookupViaProviders to use ScopedValue to detect recursive lookup Reviewed-by: alanb, dfuchs ! src/java.base/share/classes/java/net/URL.java ! test/jdk/java/net/spi/URLStreamHandlerProvider/Basic.java + test/jdk/java/net/spi/URLStreamHandlerProvider/circular.provider.template Changeset: 4ca3ab62 Branch: master Author: Joe Darcy Date: 2025-10-07 16:41:45 +0000 URL: https://git.openjdk.org/loom/commit/4ca3ab62759b366fd3e0b2267925f1fa70f057b7 8369123: Still more small Float16 refactorings Reviewed-by: rgiulietti ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java Changeset: ebeb77ba Branch: master Author: Phil Race Date: 2025-10-07 16:47:43 +0000 URL: https://git.openjdk.org/loom/commit/ebeb77baaeb6d9098d7462f5ddf61d8583b1e493 8358058: sun/java2d/OpenGL/DrawImageBg.java Test fails intermittently Reviewed-by: azvegint, serb, psadhukhan ! test/jdk/ProblemList.txt + test/jdk/sun/java2d/OpenGL/DrawBitmaskImage.java + test/jdk/sun/java2d/OpenGL/DrawBufImgOp.java + test/jdk/sun/java2d/OpenGL/DrawImageBg.java + test/jdk/sun/java2d/OpenGL/LargeOps.java + test/jdk/sun/java2d/OpenGL/OpaqueDest.java + test/jdk/sun/java2d/OpenGL/ScaleParamsOOB.java + test/jdk/sun/java2d/OpenGL/ShapeClip.java + test/jdk/sun/java2d/OpenGL/SrcMaskOps.java + test/jdk/sun/java2d/OpenGL/VolatileSubRegion.java + test/jdk/sun/java2d/OpenGL/XformVolatile.java Changeset: 1ea8cfa6 Branch: master Author: Aleksey Shipilev Date: 2025-10-07 16:54:36 +0000 URL: https://git.openjdk.org/loom/commit/1ea8cfa6dc8e6f96fd87553331abaae17ec173ea 8369226: GHA: Switch to MacOS 15 Reviewed-by: erikj, ayang, sgehwolf ! .github/workflows/main.yml Changeset: 6b316262 Branch: master Author: Naoto Sato Date: 2025-10-07 17:21:13 +0000 URL: https://git.openjdk.org/loom/commit/6b3162620bd808227ec7b4331ae6fc32ceb909e8 8368845: x-IBM930 uses incorrect character for Hex 42 60 Reviewed-by: sherman, rriggs, iris ! make/data/charsetmapping/IBM930.c2b ! make/data/charsetmapping/IBM930.map ! test/jdk/sun/nio/cs/mapping/CoderTest.java ! test/jdk/sun/nio/cs/mapping/ConverterTest.java ! test/jdk/sun/nio/cs/mapping/Cp930.b2c ! test/jdk/sun/nio/cs/mapping/TestConv.java Changeset: 7f070d35 Branch: master Author: Mikael Vidstedt Date: 2025-10-07 17:37:31 +0000 URL: https://git.openjdk.org/loom/commit/7f070d356c479ae30fe84fcf4d322c0b693fa15a 8369246: Use https in make/devkit scripts Reviewed-by: ayang, erikj ! make/devkit/Tools.gmk ! make/devkit/createAutoconfBundle.sh Changeset: 6bfd018b Branch: master Author: Phil Race Date: 2025-10-07 19:08:22 +0000 URL: https://git.openjdk.org/loom/commit/6bfd018beaf187940ebafc71885045b4aabca673 8366002: Beans.instantiate needs to describe the lookup procedure Reviewed-by: serb, aivanov ! src/java.desktop/share/classes/java/beans/Beans.java Changeset: 910bb68e Branch: master Author: Archie Cobbs Date: 2025-10-07 19:32:08 +0000 URL: https://git.openjdk.org/loom/commit/910bb68e5191f830ff6f3dff5753e4e5f6214a7b 8349847: Support configuring individual lint categories as errors Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Options.java ! src/jdk.compiler/share/man/javac.md + test/langtools/tools/javac/warnings/WerrorLint.e1.out + test/langtools/tools/javac/warnings/WerrorLint.e2.out + test/langtools/tools/javac/warnings/WerrorLint.java + test/langtools/tools/javac/warnings/WerrorLint.w1.out + test/langtools/tools/javac/warnings/WerrorLint.w2.out Changeset: 4ee6079b Branch: master Author: Mikael Vidstedt Date: 2025-10-08 02:05:20 +0000 URL: https://git.openjdk.org/loom/commit/4ee6079b11034e7de8be72cd2832fb717c2f140d 8369328: Use uppercase variable names in the devkit makefiles Reviewed-by: erikj ! make/devkit/Makefile ! make/devkit/Tools.gmk Changeset: 650fd35b Branch: master Author: Prasanta Sadhukhan Date: 2025-10-08 03:00:30 +0000 URL: https://git.openjdk.org/loom/commit/650fd35b3b30bf16e8caad968bd335d423c87b7d 8335646: Nimbus : JLabel not painted with LAF defined foreground color on Ubuntu 24.04 Reviewed-by: aivanov, dnguyen, serb ! test/jdk/javax/swing/plaf/basic/BasicHTML/bug4248210.java Changeset: 2ac24bf1 Branch: master Author: Emanuel Peter Date: 2025-10-08 03:06:29 +0000 URL: https://git.openjdk.org/loom/commit/2ac24bf1bac9c32704ebd72b93a75819b9404063 8367389: C2 SuperWord: refactor VTransform to model the whole loop instead of just the basic block Reviewed-by: roland, mhaessig ! src/hotspot/share/opto/phasetype.hpp ! src/hotspot/share/opto/superword.cpp ! src/hotspot/share/opto/superword.hpp ! src/hotspot/share/opto/superwordVTransformBuilder.cpp ! src/hotspot/share/opto/superwordVTransformBuilder.hpp ! src/hotspot/share/opto/vectorization.cpp ! src/hotspot/share/opto/vectorization.hpp ! src/hotspot/share/opto/vtransform.cpp ! src/hotspot/share/opto/vtransform.hpp ! test/hotspot/jtreg/compiler/lib/ir_framework/CompilePhase.java Changeset: 86211956 Branch: master Author: Jan Lahoda Date: 2025-10-08 05:32:51 +0000 URL: https://git.openjdk.org/loom/commit/862119565db311fe0e02e383fd3493601ed23ea8 8363917: SwitchBootstraps.enumSwitch() args not checked as documented Reviewed-by: liach ! src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java ! test/jdk/java/lang/runtime/SwitchBootstrapsTest.java Changeset: bd25db1f Branch: master Author: Matthias Baesken Date: 2025-10-08 07:02:34 +0000 URL: https://git.openjdk.org/loom/commit/bd25db1fb8573fc908f7a8a96bca417b1d44689a 8368960: Adjust java UL logging in the build Reviewed-by: erikj, dholmes ! make/ToolsJdk.gmk ! make/autoconf/boot-jdk.m4 Changeset: d27649fe Branch: master Author: Johannes Bechberger Date: 2025-10-08 08:03:32 +0000 URL: https://git.openjdk.org/loom/commit/d27649fe22a5bed9db72ac6c2595ac91f1fa28f8 8367302: New test jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082 is failing Reviewed-by: dholmes, apangin ! src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp ! src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.hpp ! src/hotspot/share/prims/whitebox.cpp ! test/jdk/ProblemList-Xcomp.txt ! test/jdk/jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java ! test/lib/jdk/test/whitebox/WhiteBox.java Changeset: f58e17fd Branch: master Author: Ant?n Seoane Ampudia Committer: Roberto Casta?eda Lozano Date: 2025-10-08 08:58:58 +0000 URL: https://git.openjdk.org/loom/commit/f58e17fd27e868e4a8816befc4c4bb8946c1f7fd 8368780: IGV: Upgrade to Netbeans Platform 27 Reviewed-by: rcastanedalo, chagedorn ! src/utils/IdealGraphVisualizer/Filter/pom.xml ! src/utils/IdealGraphVisualizer/README.md ! src/utils/IdealGraphVisualizer/pom.xml Changeset: d45e65ba Branch: master Author: Suchismith Roy Committer: Varada M Date: 2025-10-08 09:15:23 +0000 URL: https://git.openjdk.org/loom/commit/d45e65bab45f78f9f378cdc53837fe33190b7801 8030957: AIX: Implement OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX Reviewed-by: jkern, mdoerr, mbaesken ! src/jdk.management/aix/native/libmanagement_ext/UnixOperatingSystem.c ! test/jdk/ProblemList.txt Changeset: c6695064 Branch: master Author: Albert Mingkun Yang Date: 2025-10-08 09:29:24 +0000 URL: https://git.openjdk.org/loom/commit/c66950643e4f43b5997b223289eefdde589589fa 8369277: Remove unused CodeCacheUnloadingTask::_num_workers Reviewed-by: shade, tschatzl ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1ParallelCleaning.cpp ! src/hotspot/share/gc/g1/g1ParallelCleaning.hpp ! src/hotspot/share/gc/shared/parallelCleaning.cpp ! src/hotspot/share/gc/shared/parallelCleaning.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp ! src/hotspot/share/gc/shenandoah/shenandoahParallelCleaning.cpp ! src/hotspot/share/gc/shenandoah/shenandoahParallelCleaning.hpp Changeset: 6a4c2676 Branch: master Author: Afshin Zafari Date: 2025-10-08 09:49:48 +0000 URL: https://git.openjdk.org/loom/commit/6a4c2676a6378f573bd58d1bc32b57765d756291 8365385: [asan] os::pretouch_memory() is not compatible with ASAN Reviewed-by: stuefe, jsjolen ! src/hotspot/share/memory/metaspace/chunkManager.cpp ! src/hotspot/share/memory/metaspace/virtualSpaceNode.cpp Changeset: c12f0e74 Branch: master Author: Albert Mingkun Yang Date: 2025-10-08 11:21:22 +0000 URL: https://git.openjdk.org/loom/commit/c12f0e74a9acfaa91b537853143ec94f143fe316 8369286: Parallel: Assertion failure in mutableNUMASpace Reviewed-by: jsikstro, tschatzl ! src/hotspot/share/gc/parallel/psYoungGen.cpp Changeset: 23fcbb0b Branch: master Author: Ruben Ayrapetyan Committer: Evgeny Astigeevich Date: 2025-10-08 12:13:04 +0000 URL: https://git.openjdk.org/loom/commit/23fcbb0badbef6d22f63ca6c5b26b0693002592c 8365153: AArch64: Set JVM flags for Neoverse N3 and V3 cores Reviewed-by: eastigeevich, aph ! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp Changeset: 927aa3f8 Branch: master Author: Francesco Andreuzzi Committer: Thomas Schatzl Date: 2025-10-08 14:20:23 +0000 URL: https://git.openjdk.org/loom/commit/927aa3f8da34fb71b692661bebb89d20bfa85648 8369178: G1: Use NMethodMarkingScope and ThreadsClaimTokenScope in G1RootProcessor Reviewed-by: ayang, tschatzl ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1HeapVerifier.cpp ! src/hotspot/share/gc/g1/g1RootProcessor.cpp ! src/hotspot/share/gc/g1/g1RootProcessor.hpp ! src/hotspot/share/gc/g1/g1YoungCollector.cpp ! src/hotspot/share/gc/shared/strongRootsScope.cpp ! src/hotspot/share/gc/shared/strongRootsScope.hpp ! src/hotspot/share/runtime/safepoint.cpp Changeset: 79bcc7b8 Branch: master Author: Richard Reingruber Date: 2025-10-08 15:56:58 +0000 URL: https://git.openjdk.org/loom/commit/79bcc7b8ec577dad592dc3f575c15d1bdeb65b19 8369257: PPC: compiler/whitebox/RelocateNMethodMultiplePaths.java fails with assertion Reviewed-by: mdoerr ! src/hotspot/cpu/ppc/nativeInst_ppc.cpp From duke at openjdk.org Wed Oct 8 22:10:47 2025 From: duke at openjdk.org (duke) Date: Wed, 8 Oct 2025 22:10:47 GMT Subject: git: openjdk/loom: fibers: 3 new changesets Message-ID: <6bb799d5-c470-429f-be48-6b01e516660e@openjdk.org> Changeset: 7c852b47 Branch: fibers Author: Patricio Chilano Mateo Date: 2025-10-08 15:38:45 +0000 URL: https://git.openjdk.org/loom/commit/7c852b4789886e966035b9e2400be44331f82f42 Remove extra space ! src/hotspot/share/runtime/continuationFreezeThaw.cpp Changeset: d41155c9 Branch: fibers Author: Patricio Chilano Mateo Date: 2025-10-08 16:00:16 +0000 URL: https://git.openjdk.org/loom/commit/d41155c9a9588c34694d12b01872484064f17815 Improve output for LotsOfContendedMonitorEnter ! test/jdk/java/lang/Thread/virtual/stress/LotsOfContendedMonitorEnter.java Changeset: 56bca53b Branch: fibers Author: Patricio Chilano Mateo Date: 2025-10-08 18:02:05 +0000 URL: https://git.openjdk.org/loom/commit/56bca53b9c664976c64c4409a6b6c963ea1f5f28 Cleanups in continuationFreezeThaw ! src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp ! src/hotspot/cpu/x86/continuationFreezeThaw_x86.inline.hpp ! src/hotspot/share/runtime/continuationFreezeThaw.cpp From duke at openjdk.org Thu Oct 9 03:09:06 2025 From: duke at openjdk.org (duke) Date: Thu, 9 Oct 2025 03:09:06 GMT Subject: git: openjdk/loom: fibers: 2 new changesets Message-ID: <7c8a550c-844e-449b-8f6b-ad14f7b0be1a@openjdk.org> Changeset: a8c80a66 Branch: fibers Author: Patricio Chilano Mateo Date: 2025-10-08 22:28:14 +0000 URL: https://git.openjdk.org/loom/commit/a8c80a666b90fe086f8a345cfa98a2c033ccedf2 Fix requires in KlassInit.java ! test/jdk/java/lang/Thread/virtual/KlassInit.java Changeset: 0bb54fa6 Branch: fibers Author: Patricio Chilano Mateo Date: 2025-10-08 22:28:43 +0000 URL: https://git.openjdk.org/loom/commit/0bb54fa641dd5d62237d11e8c82ccaaeda652375 Minor comment cleanup ! src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp ! src/hotspot/cpu/x86/interp_masm_x86.cpp From duke at openjdk.org Thu Oct 9 17:04:08 2025 From: duke at openjdk.org (duke) Date: Thu, 9 Oct 2025 17:04:08 GMT Subject: git: openjdk/loom: fibers: 19 new changesets Message-ID: <499dbd0c-5bab-4bca-8f81-34eb3b1bbb85@openjdk.org> Changeset: ac73e688 Branch: fibers Author: Valerie Peng Date: 2025-10-08 17:36:03 +0000 URL: https://git.openjdk.org/loom/commit/ac73e688b13595b63dcfc9ce0aee76e7262d68c3 8368984: Extra slashes in Cipher transformation leads to NSPE instead of NSAE Reviewed-by: weijun ! src/java.base/share/classes/javax/crypto/Cipher.java ! test/jdk/com/sun/crypto/provider/Cipher/ChaCha20/unittest/ChaCha20CipherUnitTest.java ! test/jdk/javax/crypto/Cipher/TestEmptyModePadding.java ! test/jdk/javax/crypto/Cipher/TestGetInstance.java Changeset: 92f2ab2e Branch: fibers Author: William Kemper Date: 2025-10-08 18:14:26 +0000 URL: https://git.openjdk.org/loom/commit/92f2ab2e1b5a7c02ea6d3a3a07c7fbbfc725cdea 8264851: Shenandoah: Rework control loop mechanics to use timed waits Reviewed-by: kdnilsen, shade ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.hpp Changeset: 4d0da18a Branch: fibers Author: David Holmes Date: 2025-10-08 20:28:21 +0000 URL: https://git.openjdk.org/loom/commit/4d0da18ab6e83549e81074e15011cf8a4fbd4ea9 8369250: Assess and remedy any unsafe usage of the Semaphore used by NonJavaThread::List Reviewed-by: kbarrett, stefank ! src/hotspot/share/runtime/nonJavaThread.cpp ! src/hotspot/share/runtime/nonJavaThread.hpp ! src/hotspot/share/runtime/threads.cpp Changeset: 1aa62dca Branch: fibers Author: Chris Plummer Date: 2025-10-08 20:38:30 +0000 URL: https://git.openjdk.org/loom/commit/1aa62dcafd9f11ff3cb191525437e10bb789d276 8369230: com/sun/jdi/SimulResumerTest.java timed out Reviewed-by: sspitsyn ! test/jdk/com/sun/jdi/SimulResumerTest.java Changeset: 0e5655e6 Branch: fibers Author: Emanuel Peter Date: 2025-10-08 23:09:37 +0000 URL: https://git.openjdk.org/loom/commit/0e5655e6680762a99b5aecb58369b880ea913565 8367657: C2 SuperWord: NormalMapping demo from JVMLS 2025 Reviewed-by: chagedorn, galder ! test/hotspot/jtreg/TEST.groups + test/hotspot/jtreg/compiler/gallery/NormalMapping.java + test/hotspot/jtreg/compiler/gallery/TestNormalMapping.java + test/hotspot/jtreg/compiler/gallery/normal_map.png Changeset: 5873c4b5 Branch: fibers Author: Archie Cobbs Date: 2025-10-09 01:32:02 +0000 URL: https://git.openjdk.org/loom/commit/5873c4b5d61844b6b34a46e8955bd94bdd3d7610 8369039: JDK-8348611 caused regression in Javac-Hot-Generate Co-authored-by: Claes Redestad Reviewed-by: jlahoda, redestad ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/LintMapper.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java Changeset: 0b81db1d Branch: fibers Author: Lei Zhu Committer: Christian Hagedorn Date: 2025-10-09 05:28:27 +0000 URL: https://git.openjdk.org/loom/commit/0b81db1d38e69e6d8c73f22e4dae63ff5775852e 8364346: Typo in IR framework README Reviewed-by: thartmann, fandreuzzi, chagedorn ! test/hotspot/jtreg/compiler/lib/ir_framework/README.md Changeset: 914b44e2 Branch: fibers Author: Daniel Jeli?ski Date: 2025-10-09 06:01:25 +0000 URL: https://git.openjdk.org/loom/commit/914b44e277df23418736eb00c022bbd829d64e11 8368694: PKCS11-NSS generic keys generated by DH have leading zeroes stripped Reviewed-by: valeriep ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyAgreement.java ! test/jdk/com/sun/crypto/provider/TLS/TestLeadingZeroes.java ! test/jdk/sun/security/pkcs11/tls/TestLeadingZeroesP11.java Changeset: 1b11bea7 Branch: fibers Author: Ramkumar Sunderbabu Committer: Christian Hagedorn Date: 2025-10-09 06:19:00 +0000 URL: https://git.openjdk.org/loom/commit/1b11bea76ba29d1dfa414ad7e10693cf054bb96f 8286865: vmTestbase/vm/mlvm/meth/stress/jni/nativeAndMH/Test.java fails with Out of space in CodeCache Reviewed-by: dlong, chagedorn ! test/hotspot/jtreg/vmTestbase/vm/mlvm/meth/stress/jni/nativeAndMH/Test.java Changeset: 991f8e6f Branch: fibers Author: Damon Fenacci Date: 2025-10-09 06:21:08 +0000 URL: https://git.openjdk.org/loom/commit/991f8e6f385ab85b33d2e4d274506995b651ce65 8360031: C2 compilation asserts in MemBarNode::remove Reviewed-by: dlong, kvn, shade ! src/hotspot/share/opto/escape.cpp ! src/hotspot/share/opto/memnode.cpp ! test/hotspot/jtreg/compiler/c2/irTests/ConstructorBarriers.java Changeset: af2fbd5a Branch: fibers Author: Joel Sikstr?m Date: 2025-10-09 08:17:45 +0000 URL: https://git.openjdk.org/loom/commit/af2fbd5a7182cabdd88764b5653d2ce666f05d70 8367413: Fix potential truncation error in Arguments::set_heap_size() Reviewed-by: ayang, lkorinth ! src/hotspot/share/runtime/arguments.cpp Changeset: b37a1a33 Branch: fibers Author: Daniel Jeli?ski Date: 2025-10-09 09:20:14 +0000 URL: https://git.openjdk.org/loom/commit/b37a1a33aebaf86223eb94b3d641a5bed66f9e20 8369291: Test java/net/httpclient/http3/H3DataLimitsTest.java fails in quic connection timeout with linux fastdebug builds Reviewed-by: jpai, dfuchs, vyazici ! test/jdk/java/net/httpclient/BasicHTTP2Test.java ! test/jdk/java/net/httpclient/BasicHTTP3Test.java ! test/jdk/java/net/httpclient/http3/H3DataLimitsTest.java ! test/jdk/java/net/httpclient/http3/H3HeaderSizeLimitTest.java ! test/jdk/java/net/httpclient/http3/H3InsertionsLimitTest.java Changeset: 285d16a3 Branch: fibers Author: Prasanta Sadhukhan Date: 2025-10-09 09:42:27 +0000 URL: https://git.openjdk.org/loom/commit/285d16a3a3b29b175670a042165780859a7dbc81 8365886: JSplitPane loses track of the left component when the component orientation is changed Reviewed-by: tr, kizune ! src/java.desktop/share/classes/javax/swing/JSplitPane.java ! test/jdk/javax/swing/JSplitPane/TestSplitPaneOrientationTest.java Changeset: 692c20ce Branch: fibers Author: Joachim Kern Date: 2025-10-09 09:46:01 +0000 URL: https://git.openjdk.org/loom/commit/692c20ce1df1526bd175572a61d3355a57d42d02 8368997: AIX allows reading from address zero which leads to several ubsan findings Reviewed-by: mdoerr, mbaesken ! src/hotspot/os/posix/safefetch_sigjmp.cpp Changeset: 7e3e55a5 Branch: fibers Author: Manuel H?ssig Date: 2025-10-09 10:24:27 +0000 URL: https://git.openjdk.org/loom/commit/7e3e55a576b24ae704395b01a15c363ce6e28cae 8368573: MultiBranchNode::required_outcnt should return an unsigned int Reviewed-by: chagedorn, dfenacci, fandreuzzi ! src/hotspot/share/opto/cfgnode.hpp Changeset: e24b6cbe Branch: fibers Author: Alan Bateman Date: 2025-10-09 13:47:07 +0000 URL: https://git.openjdk.org/loom/commit/e24b6cbe6990e8f81c57d20ddefc77cf0e6be44f Merge branch 'master' into fibers ! src/hotspot/share/runtime/threads.cpp ! test/hotspot/jtreg/TEST.groups ! src/hotspot/share/runtime/threads.cpp ! test/hotspot/jtreg/TEST.groups Changeset: 5a321735 Branch: fibers Author: Alan Bateman Date: 2025-10-09 10:30:41 +0000 URL: https://git.openjdk.org/loom/commit/5a3217355985a92573ad5354c90e1c8f0b1b4a79 Cleanup of custom default scheduler prototype ! src/java.base/share/classes/java/lang/VirtualThread.java Changeset: 57662d33 Branch: fibers Author: Alan Bateman Date: 2025-10-09 13:47:15 +0000 URL: https://git.openjdk.org/loom/commit/57662d33fcbc4b8fbafb71d12d3b690c143b4b52 Merge loom into fibers Changeset: 68f342e3 Branch: fibers Author: Alan Bateman Date: 2025-10-09 17:59:11 +0000 URL: https://git.openjdk.org/loom/commit/68f342e34f97c38e9132d82db58b814ae320d597 Revert JTREG_AUTO_TIMEOUT_FACTOR, as per pull/27721 ! make/RunTests.gmk From duke at openjdk.org Thu Oct 9 17:04:59 2025 From: duke at openjdk.org (duke) Date: Thu, 9 Oct 2025 17:04:59 GMT Subject: git: openjdk/loom: master: 15 new changesets Message-ID: <9a6d7651-0c7e-48a8-b525-9d354fc28b25@openjdk.org> Changeset: ac73e688 Branch: master Author: Valerie Peng Date: 2025-10-08 17:36:03 +0000 URL: https://git.openjdk.org/loom/commit/ac73e688b13595b63dcfc9ce0aee76e7262d68c3 8368984: Extra slashes in Cipher transformation leads to NSPE instead of NSAE Reviewed-by: weijun ! src/java.base/share/classes/javax/crypto/Cipher.java ! test/jdk/com/sun/crypto/provider/Cipher/ChaCha20/unittest/ChaCha20CipherUnitTest.java ! test/jdk/javax/crypto/Cipher/TestEmptyModePadding.java ! test/jdk/javax/crypto/Cipher/TestGetInstance.java Changeset: 92f2ab2e Branch: master Author: William Kemper Date: 2025-10-08 18:14:26 +0000 URL: https://git.openjdk.org/loom/commit/92f2ab2e1b5a7c02ea6d3a3a07c7fbbfc725cdea 8264851: Shenandoah: Rework control loop mechanics to use timed waits Reviewed-by: kdnilsen, shade ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp ! src/hotspot/share/gc/shenandoah/shenandoahControlThread.hpp Changeset: 4d0da18a Branch: master Author: David Holmes Date: 2025-10-08 20:28:21 +0000 URL: https://git.openjdk.org/loom/commit/4d0da18ab6e83549e81074e15011cf8a4fbd4ea9 8369250: Assess and remedy any unsafe usage of the Semaphore used by NonJavaThread::List Reviewed-by: kbarrett, stefank ! src/hotspot/share/runtime/nonJavaThread.cpp ! src/hotspot/share/runtime/nonJavaThread.hpp ! src/hotspot/share/runtime/threads.cpp Changeset: 1aa62dca Branch: master Author: Chris Plummer Date: 2025-10-08 20:38:30 +0000 URL: https://git.openjdk.org/loom/commit/1aa62dcafd9f11ff3cb191525437e10bb789d276 8369230: com/sun/jdi/SimulResumerTest.java timed out Reviewed-by: sspitsyn ! test/jdk/com/sun/jdi/SimulResumerTest.java Changeset: 0e5655e6 Branch: master Author: Emanuel Peter Date: 2025-10-08 23:09:37 +0000 URL: https://git.openjdk.org/loom/commit/0e5655e6680762a99b5aecb58369b880ea913565 8367657: C2 SuperWord: NormalMapping demo from JVMLS 2025 Reviewed-by: chagedorn, galder ! test/hotspot/jtreg/TEST.groups + test/hotspot/jtreg/compiler/gallery/NormalMapping.java + test/hotspot/jtreg/compiler/gallery/TestNormalMapping.java + test/hotspot/jtreg/compiler/gallery/normal_map.png Changeset: 5873c4b5 Branch: master Author: Archie Cobbs Date: 2025-10-09 01:32:02 +0000 URL: https://git.openjdk.org/loom/commit/5873c4b5d61844b6b34a46e8955bd94bdd3d7610 8369039: JDK-8348611 caused regression in Javac-Hot-Generate Co-authored-by: Claes Redestad Reviewed-by: jlahoda, redestad ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/LintMapper.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Log.java Changeset: 0b81db1d Branch: master Author: Lei Zhu Committer: Christian Hagedorn Date: 2025-10-09 05:28:27 +0000 URL: https://git.openjdk.org/loom/commit/0b81db1d38e69e6d8c73f22e4dae63ff5775852e 8364346: Typo in IR framework README Reviewed-by: thartmann, fandreuzzi, chagedorn ! test/hotspot/jtreg/compiler/lib/ir_framework/README.md Changeset: 914b44e2 Branch: master Author: Daniel Jeli?ski Date: 2025-10-09 06:01:25 +0000 URL: https://git.openjdk.org/loom/commit/914b44e277df23418736eb00c022bbd829d64e11 8368694: PKCS11-NSS generic keys generated by DH have leading zeroes stripped Reviewed-by: valeriep ! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyAgreement.java ! test/jdk/com/sun/crypto/provider/TLS/TestLeadingZeroes.java ! test/jdk/sun/security/pkcs11/tls/TestLeadingZeroesP11.java Changeset: 1b11bea7 Branch: master Author: Ramkumar Sunderbabu Committer: Christian Hagedorn Date: 2025-10-09 06:19:00 +0000 URL: https://git.openjdk.org/loom/commit/1b11bea76ba29d1dfa414ad7e10693cf054bb96f 8286865: vmTestbase/vm/mlvm/meth/stress/jni/nativeAndMH/Test.java fails with Out of space in CodeCache Reviewed-by: dlong, chagedorn ! test/hotspot/jtreg/vmTestbase/vm/mlvm/meth/stress/jni/nativeAndMH/Test.java Changeset: 991f8e6f Branch: master Author: Damon Fenacci Date: 2025-10-09 06:21:08 +0000 URL: https://git.openjdk.org/loom/commit/991f8e6f385ab85b33d2e4d274506995b651ce65 8360031: C2 compilation asserts in MemBarNode::remove Reviewed-by: dlong, kvn, shade ! src/hotspot/share/opto/escape.cpp ! src/hotspot/share/opto/memnode.cpp ! test/hotspot/jtreg/compiler/c2/irTests/ConstructorBarriers.java Changeset: af2fbd5a Branch: master Author: Joel Sikstr?m Date: 2025-10-09 08:17:45 +0000 URL: https://git.openjdk.org/loom/commit/af2fbd5a7182cabdd88764b5653d2ce666f05d70 8367413: Fix potential truncation error in Arguments::set_heap_size() Reviewed-by: ayang, lkorinth ! src/hotspot/share/runtime/arguments.cpp Changeset: b37a1a33 Branch: master Author: Daniel Jeli?ski Date: 2025-10-09 09:20:14 +0000 URL: https://git.openjdk.org/loom/commit/b37a1a33aebaf86223eb94b3d641a5bed66f9e20 8369291: Test java/net/httpclient/http3/H3DataLimitsTest.java fails in quic connection timeout with linux fastdebug builds Reviewed-by: jpai, dfuchs, vyazici ! test/jdk/java/net/httpclient/BasicHTTP2Test.java ! test/jdk/java/net/httpclient/BasicHTTP3Test.java ! test/jdk/java/net/httpclient/http3/H3DataLimitsTest.java ! test/jdk/java/net/httpclient/http3/H3HeaderSizeLimitTest.java ! test/jdk/java/net/httpclient/http3/H3InsertionsLimitTest.java Changeset: 285d16a3 Branch: master Author: Prasanta Sadhukhan Date: 2025-10-09 09:42:27 +0000 URL: https://git.openjdk.org/loom/commit/285d16a3a3b29b175670a042165780859a7dbc81 8365886: JSplitPane loses track of the left component when the component orientation is changed Reviewed-by: tr, kizune ! src/java.desktop/share/classes/javax/swing/JSplitPane.java ! test/jdk/javax/swing/JSplitPane/TestSplitPaneOrientationTest.java Changeset: 692c20ce Branch: master Author: Joachim Kern Date: 2025-10-09 09:46:01 +0000 URL: https://git.openjdk.org/loom/commit/692c20ce1df1526bd175572a61d3355a57d42d02 8368997: AIX allows reading from address zero which leads to several ubsan findings Reviewed-by: mdoerr, mbaesken ! src/hotspot/os/posix/safefetch_sigjmp.cpp Changeset: 7e3e55a5 Branch: master Author: Manuel H?ssig Date: 2025-10-09 10:24:27 +0000 URL: https://git.openjdk.org/loom/commit/7e3e55a576b24ae704395b01a15c363ce6e28cae 8368573: MultiBranchNode::required_outcnt should return an unsigned int Reviewed-by: chagedorn, dfenacci, fandreuzzi ! src/hotspot/share/opto/cfgnode.hpp From manc at google.com Thu Oct 9 21:11:44 2025 From: manc at google.com (Man Cao) Date: Thu, 9 Oct 2025 14:11:44 -0700 Subject: Custom Schedulers use-case In-Reply-To: References: Message-ID: Hi loom developers, Official support for custom schedulers is highly valuable to some of our Java applications such as our colleague David Gay's use case. Are there any major concerns or obstacles to official support for custom schedulers? I found recent discussions and user interests on custom schedulers, but could not find information regarding concerns or obstacles for official support. - https://mail.openjdk.org/pipermail/loom-dev/2025-July/007641.html - https://mail.openjdk.org/pipermail/loom-dev/2025-June/007584.html -Man On Wed, Oct 8, 2025 at 8:25?AM Liam Miller-Cushon wrote: > Hi, > > My colleague David Gay has the following use-case for Custom Schedulers ( > https://github.com/openjdk/loom/blob/fibers/loom-docs/CustomSchedulers.md > ): > > A multi-tenant server needs to provide isolation, in particular CPU > isolation, between the workloads of different customers. A good way to > achieve this when using virtual threads is to use some form of fair-share > scheduler to allocate carrier threads to virtual threads. Custom schedulers > provide a straightforward, efficient, and safe way to support this use case. > > Absent custom schedulers, it is possible to work around this by > surrounding all blocking points in a virtual thread by blocking > interactions with the fair scheduler. This however poses significant > reliability risks, as identifying these points is not straightforward and > missing any of them affects the fairness of the scheduling and risks > starvation or deadlock. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.bateman at oracle.com Fri Oct 10 08:01:32 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Fri, 10 Oct 2025 09:01:32 +0100 Subject: Custom Schedulers use-case In-Reply-To: References: Message-ID: On 09/10/2025 22:11, Man Cao wrote: > Hi loom developers, > > Official support for custom schedulers is highly valuable to some of > our Java?applications?such as our colleague David Gay's use case. > > Are there any major concerns or obstacles to official support for > custom schedulers? > There are some workloads that are not suited to a work stealing scheduler. We've seen this with workloads that have low concurrency, not a lot going on, and the scanning to "find work" consuming additional CPU cycles that nobody wants to pay for. There may be merit in having the JDK provide a different scheduler for such cases, more experimentation is required. There are folks that want to do things like using the AWT event thread, or the JavaFX application thread, as the carrier. They've seen coroutines used on UI threads in other systems and want to experiment doing something similar. Early explorations into this did not go very far. There are other folks that are interested in thread affinity, binding virtual threads to specific carriers, and carriers to specific cores in NUMA nodes. Some of this exploration is about integration with existing systems that use event loops. We are looking forward to a write-up of these explorations and any findings. Beyond this there are folks doing fun things with simulation and other experimentation. I'm not familiar with David Gay's work except for Liam's mail to say that they are doing something in the area of multi-tenancy. If a write-up or a summary of the explorations and findings could be sent to loom-dev then it would be useful. To your question, the topic of custom schedulers is an exploration/research topic. The JDK has to be cautious. Calling out to a custom scheduler (= arbitrary code) from core/sensitive parts of the runtime is very scary. It's very easy to "self deadlock" - we've seen folks trying to use locks to coordinate between mounted virtual threads and their carrier. We are also concerned that the API surface for schedulers will grow. There are two prototypes in the loom repo at this time, this is what Liam linked to. We are hoping that folks that are interested in this topic will try one or both and come back their findings. The more data, esp. from real world usage, will help inform this project on whether there is merit is going further with either direction or whether there are other directions that might be more fruitful. -Alan From yujige at gmail.com Sun Oct 12 05:32:33 2025 From: yujige at gmail.com (Jige Yu) Date: Sat, 11 Oct 2025 22:32:33 -0700 Subject: Feedback on Structured Concurrency (JEP 525, 6th Preview) Message-ID: Hi Project Loom.First and foremost, I want to express my gratitude for the effort that has gone into structured concurrency. API design in this space is notoriously difficult, and this feedback is offered with the greatest respect for the team's work and in the spirit of collaborative refinement. My perspective is that of a developer looking to use Structured Concurrency for common, IO-intensive fan-out operations. My focus is to replace everyday async callback hell, or reactive chains with something simpler and more readable. It will lack depth in the highly specialized concurrent programming area. And I acknowledge this viewpoint may bias my feedback. ------------------------------ *High-Level Impression* >From this perspective, the current API feels imperative and more complex for the common intended use cases than necessary. It introduces significant cognitive load through its stateful nature and manual lifecycle management. ------------------------------ *Specific Points of Concern* 1. *Stateful and Imperative API:* The API imposes quite some "don't do this at time X" rules. Attempting to fork() after join() leads to a runtime error; forgetting to call join() is another error; and the imperative fork/join sequence is more cumbersome than a declarative approach would be. None of these are unmanageable though. 2. *Challenging Exception Handling:* The exception handling model is tricky: - *Loss of Checked Exception Compile-Time Safety:* FailedException is effectively an unchecked wrapper that erases checked exception information at compile time. Migrating from sequential, structured code to concurrent code now means losing valuable compiler guarantees. - *No Help For Exception Handling: *For code that wants to catch and handle these exceptions, it's the same story of using *instanceof* on the getCause(), again, losing all compile-time safety that was available in equivalent sequential code. - *Burdensome InterruptedException Handling:* The requirement for the caller to handle or propagate InterruptedException from join() will add room for error as handling InterruptedException is easy to get wrong: one can forget to call currentThread().interrupt(). Or, if the caller decides to declare *throws* *InterruptedException*, the signature propagation becomes viral. - *Default Exception Swallowing:* The AnySuccessOrThrow policy *swallows all exceptions* by default, including critical ones like NullPointerException, IllegalArgumentException, or even an Error. This makes it dangerously easy to mask bugs that should be highly visible. There is no straightforward mechanism to inspect these suppressed exceptions or fail on specific, unexpected types. 3. *Conflated API Semantics:* The StructuredTaskScope API unifies two very different concurrency patterns?"gather all" (allSuccessfulOrThrow) and "race to first success" (anySuccessfulResultOrThrow)?under a single class but with different interaction models for the same method. - In the *"gather all"* pattern (allSuccessfulOrThrow), join() returns void. The callsite should use subtask.get() to retrieve results. - In the *"race"* pattern (anySuccessfulResultOrThrow), join() returns the result (R) of the first successful subtask directly. The developer should *not* call get() on individual subtasks. Having the join()+subtask.get() method spec'ed conditionally (which method to use and how depends on the actual policy) feels like a minor violation of LSP and is a source of confusion. It may be an indication of premature abstraction. 4. *Overly Complex Customization:* The StructuredTaskScope.Policy API, while powerful, feels like a potential footgun. The powerful lifecycle callback methods like onFork(), onComplete(), onTimeout() may lower the barrier to creating intricate, framework-like abstractions that are difficult to reason about and debug. ------------------------------ *Suggestions for a Simpler Model* My preference is that the API for the most common use cases should be more *declarative and functional*. 1. *Simplify the "Gather All" Pattern:* The primary "fan-out and gather" use case could be captured in a simple, high-level construct. An average user shouldn't need to learn the wide API surface of StructuredTaskScope + Joiner + the lifecycles. For example: Java // Ideal API for the 80% use case Robot robot = Concurrently.call( () -> fetchArm(), () -> fetchLeg(), (arm, leg) -> new Robot(arm, leg) ); 2. *Separate Race Semantics into Composable Operations:* The "race" pattern feels like a distinct use case that could be implemented more naturally using composable, functional APIs like Stream gatherers, rather than requiring a specialized API at all. For example, if mapConcurrent() fully embraced structured concurrency, guaranteeing fail-fast and happens-before, a recoverable race could be written explicitly: Java // Pseudo-code for a recoverable race using a stream gatherer T race(Collection> tasks, int maxConcurrency) { var exceptions = new ConcurrentLinkedQueue(); return tasks.stream() .gather(mapConcurrent(maxConcurrency, task -> { try { return task.call(); } catch (RpcException e) { if (isRecoverable(e)) { // Selectively recover exceptions.add(e); return null; // Suppress and continue } throw new RuntimeException(e); // Fail fast on non-recoverable } })) .filter(Objects::nonNull) .findFirst() // Short-circuiting and cancellation .orElseThrow(() -> new AggregateException(exceptions)); } While this is slightly more verbose than the JEP example, it's familiar Stream semantics that people have already learned, and it offers explicit control over which exceptions are recoverable versus fatal. The boilerplate for exception aggregation could easily be wrapped in a helper method. 3. *Reserve Complexity for Complex Cases:* The low-level StructuredTaskScope and its policy mechanism are powerful tools. However, they should be positioned as the "expert-level" API for building custom frameworks. Or perhaps just keep them in the traditional ExecutorService API. The everyday developer experience should be centered around simpler, declarative constructs that cover the most frequent needs. ------------------------------ I realize my perspective is heavily biased towards the 'everyday' use case and I may not realize or appreciate the full scope of problems the JEP aims to solve. And I used a lot of "feels". ;-> Anyhow, please forgive ignorance and disregard any points that don't align with the project's broader vision. Thank you again for your dedication to moving Java forward. -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Sun Oct 12 08:58:27 2025 From: duke at openjdk.org (duke) Date: Sun, 12 Oct 2025 08:58:27 GMT Subject: git: openjdk/loom: fibers: 40 new changesets Message-ID: <9713d766-b680-4de8-beec-3e7e628a7d41@openjdk.org> Changeset: 9def7bfe Branch: fibers Author: Francesco Andreuzzi Committer: Thomas Schatzl Date: 2025-10-09 12:42:24 +0000 URL: https://git.openjdk.org/loom/commit/9def7bfea263f6f77f0bd9d4c16f00b7a0834243 8369433: G1: Replace G1MarkScope with NMethodMarkingScope Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1YoungCollector.cpp Changeset: 5bb9fed9 Branch: fibers Author: Matthew Donovan Date: 2025-10-09 13:20:34 +0000 URL: https://git.openjdk.org/loom/commit/5bb9fed9de3297639d5c0cd1d8046656d98863dd 8351354: Enhance java -XshowSettings:security:tls to show enabled TLS groups Reviewed-by: mullan, coffeys ! src/java.base/share/classes/sun/launcher/SecuritySettings.java ! test/jdk/tools/launcher/Settings.java Changeset: fd296774 Branch: fibers Author: Justin King Date: 2025-10-09 13:30:02 +0000 URL: https://git.openjdk.org/loom/commit/fd29677479797956e0d205b5ce6e7cb9ad407bd1 8369190: JavaFrameAnchor on AArch64 has unnecessary barriers and wrong store order in MacroAssembler Reviewed-by: aph, dlong ! src/hotspot/cpu/aarch64/javaFrameAnchor_aarch64.hpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp Changeset: dd410e0b Branch: fibers Author: Christian Hagedorn Date: 2025-10-09 13:33:18 +0000 URL: https://git.openjdk.org/loom/commit/dd410e0b776a01b617a457786b11ddf87d3b4d60 8369423: Reduce execution time of testlibrary_tests/ir_framework/tests/TestDFlags.java Reviewed-by: thartmann, dfenacci ! test/hotspot/jtreg/compiler/lib/ir_framework/README.md ! test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestDFlags.java Changeset: 005877b0 Branch: fibers Author: Christian Hagedorn Date: 2025-10-09 13:33:53 +0000 URL: https://git.openjdk.org/loom/commit/005877b0635f1a9547724168ebd894b1b61fc116 8369236: testlibrary_tests/ir_framework/tests/TestCompileThreshold.java timed out Reviewed-by: ayang, dfenacci ! test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestCompileThreshold.java Changeset: 233d3a8d Branch: fibers Author: Artur Barashev Date: 2025-10-09 13:59:31 +0000 URL: https://git.openjdk.org/loom/commit/233d3a8d43578af4eafd572cee3db0978d3d65a0 8366244: TLS1.3 ChangeCipherSpec message received after the client's Finished message should trigger a connection abort with "unexpected message" Reviewed-by: hchao ! src/java.base/share/classes/sun/security/ssl/ChangeCipherSpec.java + test/jdk/sun/security/ssl/SSLEngineImpl/TLS13ChangeCipherSpecAfterFinished.java Changeset: 13f460c3 Branch: fibers Author: SendaoYan Date: 2025-10-09 14:27:09 +0000 URL: https://git.openjdk.org/loom/commit/13f460c3958b3513f0e62851fa3588f30d75daa3 8368677: acvp test should throw SkippedException when no ACVP-Server available Reviewed-by: weijun, shade ! test/jdk/sun/security/provider/acvp/Launcher.java Changeset: 48d21b50 Branch: fibers Author: Daniel Fuchs Date: 2025-10-09 15:08:46 +0000 URL: https://git.openjdk.org/loom/commit/48d21b50faed61eaa4f1d115531a21d0c29a5dff 8369434: java/net/httpclient/AltServiceUsageTest.java fails intermittently Reviewed-by: vyazici, jpai ! test/jdk/java/net/httpclient/AltServiceUsageTest.java Changeset: 9891cd69 Branch: fibers Author: Daniel Fuchs Date: 2025-10-09 15:52:28 +0000 URL: https://git.openjdk.org/loom/commit/9891cd69e442cdfa6fb76ecbd20391291f4bf6ad 8369313: java/net/httpclient/TimeoutBasic.java should accept that HttpTimeoutException should be somewhere down the cause chain Reviewed-by: vyazici, jpai ! test/jdk/java/net/httpclient/TimeoutBasic.java Changeset: 7c75cb31 Branch: fibers Author: Jeremy Wood Committer: Alexey Ivanov Date: 2025-10-09 16:02:01 +0000 URL: https://git.openjdk.org/loom/commit/7c75cb312c0f9c645a140e10df212e364b99ee42 8367376: Bad ButtonUI prevents other components from updating when system changes desktop properties Reviewed-by: aivanov, prr, psadhukhan ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java ! src/java.desktop/share/classes/sun/swing/plaf/DesktopProperty.java + test/jdk/com/sun/java/swing/plaf/DesktopPropertyResetPendingFlagTest.java Changeset: 37b725d9 Branch: fibers Author: Naoto Sato Date: 2025-10-09 16:20:59 +0000 URL: https://git.openjdk.org/loom/commit/37b725d9c12834358a562e6c03fb7f566d639ca5 8369184: SimpleTimeZone equals() Returns True for Unequal Instances with Different hashCode Values Reviewed-by: prappo, jlu, rriggs, iris ! src/java.base/share/classes/java/util/SimpleTimeZone.java + test/jdk/java/util/TimeZone/SimpleTimeZoneEqualsHashCodeTest.java Changeset: 501fa204 Branch: fibers Author: William Kemper Date: 2025-10-09 18:25:47 +0000 URL: https://git.openjdk.org/loom/commit/501fa2041a77139a9ac42fef69f28b1fd50fee65 8368501: Shenandoah: GC progress evaluation does not use generation Reviewed-by: ysr ! src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoahMetrics.cpp ! src/hotspot/share/gc/shenandoah/shenandoahMetrics.hpp Changeset: 1992b69a Branch: fibers Author: Aleksey Shipilev Date: 2025-10-09 18:47:43 +0000 URL: https://git.openjdk.org/loom/commit/1992b69a4794d1f2f65eaeb6dbb1e1e23a948b6e 8369283: Improve trace logs in safepoint machinery Reviewed-by: fbredberg, dholmes, rehn ! src/hotspot/share/runtime/safepoint.cpp ! src/hotspot/share/runtime/sharedRuntime.cpp Changeset: b73228b5 Branch: fibers Author: Vladimir Petko Committer: Erik Joelsson Date: 2025-10-09 19:38:44 +0000 URL: https://git.openjdk.org/loom/commit/b73228b51c1b1c59c8cd8ee7b14522edc12d564a 8369450: [Ubuntu 25.10] openjdk fails to build due to rust-coreutils date Reviewed-by: erikj ! make/autoconf/basic_tools.m4 Changeset: 1cdd241f Branch: fibers Author: Albert Mingkun Yang Date: 2025-10-09 19:39:06 +0000 URL: https://git.openjdk.org/loom/commit/1cdd241ff3ed57a4df4bac54b2659d68d161b53c 8369420: Parallel: Use multiple workers for class unloading Reviewed-by: fandreuzzi, tschatzl, zgu ! src/hotspot/share/gc/parallel/psParallelCompact.cpp Changeset: cd1ce588 Branch: fibers Author: Mikael Vidstedt Date: 2025-10-09 19:55:49 +0000 URL: https://git.openjdk.org/loom/commit/cd1ce5883db55540379ce090244b698696e16ec3 8369454: Verify checksums of downloaded source bundles when creating devkit Reviewed-by: erikj ! make/devkit/Tools.gmk Changeset: d6e2d4eb Branch: fibers Author: William Kemper Date: 2025-10-10 00:16:10 +0000 URL: https://git.openjdk.org/loom/commit/d6e2d4eb1f87016ab158b62c61c33c4bf92a0ed4 8367646: [GenShen] Control thread may overwrite gc cancellation cause set by mutator Reviewed-by: ysr, kdnilsen ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp Changeset: 52b02eda Branch: fibers Author: Alexander Matveev Date: 2025-10-10 01:11:10 +0000 URL: https://git.openjdk.org/loom/commit/52b02edaba55920c44b9aba6a9db53d8c9ae9292 8362598: [macos] Add tests for custom info plist files Reviewed-by: asemenyuk = src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/PListWriter.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/XmlUtils.java + test/jdk/tools/jpackage/helpers-test/jdk/jpackage/test/MacHelperTest.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacHelper.java + test/jdk/tools/jpackage/macosx/CustomInfoPListTest.java ! test/jdk/tools/jpackage/macosx/MacFileAssociationsTest.java ! test/jdk/tools/jpackage/macosx/SigningRuntimeImagePackageTest.java Changeset: 1873b459 Branch: fibers Author: Alexander Matveev Date: 2025-10-10 01:11:35 +0000 URL: https://git.openjdk.org/loom/commit/1873b4594883758a5c8b4094f49dfea36c7c0145 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts Reviewed-by: asemenyuk ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacPkgInstallerScripts.java ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacPkgPackager.java - src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/postinstall.template - src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/preinstall.template ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/OverridableResource.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources.properties ! src/jdk.jpackage/unix/classes/jdk/jpackage/internal/PackageScripts.java ! src/jdk.jpackage/unix/classes/jdk/jpackage/internal/ShellScriptResource.java + test/jdk/tools/jpackage/macosx/PkgScriptsTest.java Changeset: 2311ec39 Branch: fibers Author: Alexey Semenyuk Date: 2025-10-10 02:42:11 +0000 URL: https://git.openjdk.org/loom/commit/2311ec394df9a096d6f7cd52b65ae2660dfe20b4 8363979: Add JDK bundle/image validation for --runtime-image option Reviewed-by: almatvee ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacBundle.java ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacFromParams.java + src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacRuntimeValidator.java ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/DeployParams.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/FromParams.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/RuntimeBuilderBuilder.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources.properties ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixSourceConverter.java ! test/jdk/tools/jpackage/share/ErrorTest.java Changeset: f4209dff Branch: fibers Author: Saint Wesonga Committer: David Holmes Date: 2025-10-10 03:55:47 +0000 URL: https://git.openjdk.org/loom/commit/f4209dff3ba14ccbdc0846d9bfcc62688361b6d5 8348862: runtime/ErrorHandling/CreateCoredumpOnCrash fails on Windows aarch64 Reviewed-by: dholmes, mbeckwit ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/os/windows/os_windows.hpp + src/hotspot/os/windows/safefetch_static_windows.cpp ! src/hotspot/os_cpu/windows_aarch64/os_windows_aarch64.cpp + src/hotspot/os_cpu/windows_aarch64/safefetch_windows_aarch64.S ! src/hotspot/share/runtime/safefetch.hpp ! test/hotspot/jtreg/runtime/ErrorHandling/UncaughtNativeExceptionTest.java ! test/hotspot/jtreg/runtime/ErrorHandling/libNativeException.c Changeset: 5a32966d Branch: fibers Author: Phil Race Date: 2025-10-10 04:30:14 +0000 URL: https://git.openjdk.org/loom/commit/5a32966d4255131cf0ac1273b603d994829596e2 8369516: Delete duplicate imaging test Reviewed-by: serb - test/jdk/java/awt/image/VolatileImage/DrawBufImgOp.java Changeset: be107224 Branch: fibers Author: Yasumasa Suenaga Date: 2025-10-10 05:02:56 +0000 URL: https://git.openjdk.org/loom/commit/be10722436f20df26de66c00c4bc1b6772aa9087 8366847: JFR reports incorrect number of cores on hybrid CPU Reviewed-by: dholmes, egahlin ! src/hotspot/cpu/x86/vm_version_x86.cpp ! src/hotspot/share/jfr/metadata/metadata.xml Changeset: b6e5ef4a Branch: fibers Author: Mikhail Yankelevich Date: 2025-10-10 06:54:58 +0000 URL: https://git.openjdk.org/loom/commit/b6e5ef4ad0989d3bf0c579dbd6f5bf36b52e41e2 8360373: src/java.base/share/classes/sun/security/util/Debug.java implement negative testing Reviewed-by: coffeys ! test/jdk/sun/security/util/Debug/DebugOptions.java Changeset: b00720ed Branch: fibers Author: Zhengyu Gu Date: 2025-10-10 07:37:09 +0000 URL: https://git.openjdk.org/loom/commit/b00720edd72226ae9ffecbcb9c1062d3ceb8c6df 8369419: Error reporting of JFR JNI method registration crash on MacOSX Reviewed-by: jbachorik, egahlin ! src/hotspot/share/jfr/jni/jfrJniMethodRegistration.cpp Changeset: 1159b53b Branch: fibers Author: Joel Sikstr?m Date: 2025-10-10 08:10:07 +0000 URL: https://git.openjdk.org/loom/commit/1159b53bfcfce771a23506394d998b0d95eb8981 8369483: Cleanup dead code in HandleArea Reviewed-by: fandreuzzi, stefank ! src/hotspot/share/runtime/handles.cpp ! src/hotspot/share/runtime/handles.hpp ! src/hotspot/share/runtime/thread.cpp Changeset: a1a37bd7 Branch: fibers Author: Severin Gehwolf Date: 2025-10-10 08:14:06 +0000 URL: https://git.openjdk.org/loom/commit/a1a37bd7b2a8807f462909eadfa83ec26261e464 8369441: Two container tests fail after JDK-8292984 Reviewed-by: mbaesken, cnorrbin, syan ! test/hotspot/jtreg/containers/docker/TestJFREvents.java ! test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java Changeset: d5a20799 Branch: fibers Author: Chris Dennis Committer: Alan Bateman Date: 2025-10-10 09:19:55 +0000 URL: https://git.openjdk.org/loom/commit/d5a207994b9c374e6638e57826326f8f4593b96b 8362123: ClassLoader Leak via Executors.newSingleThreadExecutor(...) Reviewed-by: vklang, alanb ! src/java.base/share/classes/java/util/concurrent/Executors.java ! test/jdk/java/util/concurrent/Executors/AutoShutdown.java Changeset: f52aed6f Branch: fibers Author: Mar?a Arias de Reyna Dom?nguez Committer: Severin Gehwolf Date: 2025-10-10 09:46:37 +0000 URL: https://git.openjdk.org/loom/commit/f52aed6f81e7df9ab9a379ada952b8e666c54e6d 8369418: Identify owning class for KlassTrainingData in AOT map output Reviewed-by: iklam, adinn ! src/hotspot/share/cds/aotMapLogger.cpp ! src/hotspot/share/cds/aotMapLogger.hpp Changeset: afda8ad4 Branch: fibers Author: Albert Mingkun Yang Date: 2025-10-10 10:18:45 +0000 URL: https://git.openjdk.org/loom/commit/afda8ad46045a4e2d1db608397aa3e03a953153f 8369501: Parallel: Add UseAdaptiveSizePolicy requirement to TestDynShrinkHeap.java Reviewed-by: jsikstro, tschatzl ! test/hotspot/jtreg/gc/parallel/TestDynShrinkHeap.java ! test/jtreg-ext/requires/VMProps.java Changeset: 5594d6bc Branch: fibers Author: Aleksei Voitylov Committer: Severin Gehwolf Date: 2025-10-10 13:33:12 +0000 URL: https://git.openjdk.org/loom/commit/5594d6bc88bbe39e6ebfd02fb9c37cf40b8d0479 8368522: (fs) BasicFileAttributes Linux musl 1.2.5 incompatibility with statx Reviewed-by: sgehwolf, bpb ! src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c ! test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c Changeset: f6d77cb3 Branch: fibers Author: Kangcheng Xu Committer: Roland Westrelin Date: 2025-10-10 14:04:51 +0000 URL: https://git.openjdk.org/loom/commit/f6d77cb33299ae0636a2b52ee752f27e9ea9191b 8347555: [REDO] C2: implement optimization for series of Add of unique value Reviewed-by: roland, epeter ! src/hotspot/share/opto/addnode.cpp ! src/hotspot/share/opto/addnode.hpp ! src/hotspot/share/utilities/globalDefinitions.hpp ! test/hotspot/gtest/utilities/test_java_arithmetic.cpp + test/hotspot/jtreg/compiler/c2/gvn/TestCollapsingSameTermAdditions.java + test/micro/org/openjdk/bench/vm/compiler/SerialAdditions.java Changeset: fc49a1b5 Branch: fibers Author: Francesco Andreuzzi Committer: Brian Burkhalter Date: 2025-10-10 15:39:27 +0000 URL: https://git.openjdk.org/loom/commit/fc49a1b502530908618b19bcd749aa4db0b598d9 8368846: java/io/File/createTempFile/TargetDirectory fails when run by root user Reviewed-by: bpb ! test/jdk/java/io/File/createTempFile/TargetDirectory.java Changeset: 376d77e8 Branch: fibers Author: Justin Lu Date: 2025-10-10 16:27:56 +0000 URL: https://git.openjdk.org/loom/commit/376d77e8a71478f456af5baaf47f446eebd79e36 8369050: DecimalFormat Rounding Errors for Fractional Ties Near Zero Reviewed-by: naoto ! src/java.base/share/classes/java/text/DigitList.java + test/jdk/java/text/Format/DecimalFormat/RoundingTiesNearZeroTest.java ! test/jdk/java/text/Format/NumberFormat/NumberRegression.java Changeset: 7e29d294 Branch: fibers Author: Albert Mingkun Yang Date: 2025-10-10 18:01:09 +0000 URL: https://git.openjdk.org/loom/commit/7e29d294e53a246864e9473bf461f0f4c1f6e388 8369097: Parallel: Support allocation in from space when heap is too full Reviewed-by: tschatzl, fandreuzzi ! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp Changeset: 2dfe4586 Branch: fibers Author: SendaoYan Date: 2025-10-11 05:58:14 +0000 URL: https://git.openjdk.org/loom/commit/2dfe4586f7a29d9e3a944e6483d5d4cbbdde3be8 8369490: Remove unused Runinfo parameters in compiler/c2/gvn/TestBitCompressValueTransform.java Reviewed-by: chagedorn, mhaessig ! test/hotspot/jtreg/compiler/c2/gvn/TestBitCompressValueTransform.java Changeset: 9b99bc8e Branch: fibers Author: Francesco Andreuzzi Committer: SendaoYan Date: 2025-10-11 06:13:13 +0000 URL: https://git.openjdk.org/loom/commit/9b99bc8ef53ad20c4f1cb5d26cffc64b0deb79ad 8369440: Remove RootResolverMarkScope and RootSetClosureMarkScope Reviewed-by: ayang ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/serial/serialHeap.cpp - src/hotspot/share/gc/shared/strongRootsScope.cpp - src/hotspot/share/gc/shared/strongRootsScope.hpp ! src/hotspot/share/jfr/leakprofiler/chains/rootSetClosure.cpp ! src/hotspot/share/jfr/leakprofiler/checkpoint/rootResolver.cpp Changeset: 84c16cbd Branch: fibers Author: Alan Bateman Date: 2025-10-11 08:12:36 +0000 URL: https://git.openjdk.org/loom/commit/84c16cbdbdd83b296e3fc0f52bd60ea44854b744 Merge branch 'master' into fibers ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/share/runtime/thread.cpp Changeset: 4e7d563e Branch: fibers Author: Alan Bateman Date: 2025-10-12 07:18:45 +0000 URL: https://git.openjdk.org/loom/commit/4e7d563e00340c38755c74c88f907268b9cf7041 Test cleanup ! test/jdk/java/lang/Thread/virtual/KlassInit.java Changeset: 7c0ce3ac Branch: fibers Author: Alan Bateman Date: 2025-10-12 08:03:32 +0000 URL: https://git.openjdk.org/loom/commit/7c0ce3ac242a3f556e337822496496a5b328ee1d Minor updates to scheduler doc ! loom-docs/CustomSchedulers.md From duke at openjdk.org Sun Oct 12 09:00:31 2025 From: duke at openjdk.org (duke) Date: Sun, 12 Oct 2025 09:00:31 GMT Subject: git: openjdk/loom: master: 37 new changesets Message-ID: <7923a249-9bc0-496f-8ad5-b3323ada0690@openjdk.org> Changeset: 9def7bfe Branch: master Author: Francesco Andreuzzi Committer: Thomas Schatzl Date: 2025-10-09 12:42:24 +0000 URL: https://git.openjdk.org/loom/commit/9def7bfea263f6f77f0bd9d4c16f00b7a0834243 8369433: G1: Replace G1MarkScope with NMethodMarkingScope Reviewed-by: tschatzl, ayang ! src/hotspot/share/gc/g1/g1YoungCollector.cpp Changeset: 5bb9fed9 Branch: master Author: Matthew Donovan Date: 2025-10-09 13:20:34 +0000 URL: https://git.openjdk.org/loom/commit/5bb9fed9de3297639d5c0cd1d8046656d98863dd 8351354: Enhance java -XshowSettings:security:tls to show enabled TLS groups Reviewed-by: mullan, coffeys ! src/java.base/share/classes/sun/launcher/SecuritySettings.java ! test/jdk/tools/launcher/Settings.java Changeset: fd296774 Branch: master Author: Justin King Date: 2025-10-09 13:30:02 +0000 URL: https://git.openjdk.org/loom/commit/fd29677479797956e0d205b5ce6e7cb9ad407bd1 8369190: JavaFrameAnchor on AArch64 has unnecessary barriers and wrong store order in MacroAssembler Reviewed-by: aph, dlong ! src/hotspot/cpu/aarch64/javaFrameAnchor_aarch64.hpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp Changeset: dd410e0b Branch: master Author: Christian Hagedorn Date: 2025-10-09 13:33:18 +0000 URL: https://git.openjdk.org/loom/commit/dd410e0b776a01b617a457786b11ddf87d3b4d60 8369423: Reduce execution time of testlibrary_tests/ir_framework/tests/TestDFlags.java Reviewed-by: thartmann, dfenacci ! test/hotspot/jtreg/compiler/lib/ir_framework/README.md ! test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestDFlags.java Changeset: 005877b0 Branch: master Author: Christian Hagedorn Date: 2025-10-09 13:33:53 +0000 URL: https://git.openjdk.org/loom/commit/005877b0635f1a9547724168ebd894b1b61fc116 8369236: testlibrary_tests/ir_framework/tests/TestCompileThreshold.java timed out Reviewed-by: ayang, dfenacci ! test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestCompileThreshold.java Changeset: 233d3a8d Branch: master Author: Artur Barashev Date: 2025-10-09 13:59:31 +0000 URL: https://git.openjdk.org/loom/commit/233d3a8d43578af4eafd572cee3db0978d3d65a0 8366244: TLS1.3 ChangeCipherSpec message received after the client's Finished message should trigger a connection abort with "unexpected message" Reviewed-by: hchao ! src/java.base/share/classes/sun/security/ssl/ChangeCipherSpec.java + test/jdk/sun/security/ssl/SSLEngineImpl/TLS13ChangeCipherSpecAfterFinished.java Changeset: 13f460c3 Branch: master Author: SendaoYan Date: 2025-10-09 14:27:09 +0000 URL: https://git.openjdk.org/loom/commit/13f460c3958b3513f0e62851fa3588f30d75daa3 8368677: acvp test should throw SkippedException when no ACVP-Server available Reviewed-by: weijun, shade ! test/jdk/sun/security/provider/acvp/Launcher.java Changeset: 48d21b50 Branch: master Author: Daniel Fuchs Date: 2025-10-09 15:08:46 +0000 URL: https://git.openjdk.org/loom/commit/48d21b50faed61eaa4f1d115531a21d0c29a5dff 8369434: java/net/httpclient/AltServiceUsageTest.java fails intermittently Reviewed-by: vyazici, jpai ! test/jdk/java/net/httpclient/AltServiceUsageTest.java Changeset: 9891cd69 Branch: master Author: Daniel Fuchs Date: 2025-10-09 15:52:28 +0000 URL: https://git.openjdk.org/loom/commit/9891cd69e442cdfa6fb76ecbd20391291f4bf6ad 8369313: java/net/httpclient/TimeoutBasic.java should accept that HttpTimeoutException should be somewhere down the cause chain Reviewed-by: vyazici, jpai ! test/jdk/java/net/httpclient/TimeoutBasic.java Changeset: 7c75cb31 Branch: master Author: Jeremy Wood Committer: Alexey Ivanov Date: 2025-10-09 16:02:01 +0000 URL: https://git.openjdk.org/loom/commit/7c75cb312c0f9c645a140e10df212e364b99ee42 8367376: Bad ButtonUI prevents other components from updating when system changes desktop properties Reviewed-by: aivanov, prr, psadhukhan ! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java ! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java ! src/java.desktop/share/classes/sun/swing/plaf/DesktopProperty.java + test/jdk/com/sun/java/swing/plaf/DesktopPropertyResetPendingFlagTest.java Changeset: 37b725d9 Branch: master Author: Naoto Sato Date: 2025-10-09 16:20:59 +0000 URL: https://git.openjdk.org/loom/commit/37b725d9c12834358a562e6c03fb7f566d639ca5 8369184: SimpleTimeZone equals() Returns True for Unequal Instances with Different hashCode Values Reviewed-by: prappo, jlu, rriggs, iris ! src/java.base/share/classes/java/util/SimpleTimeZone.java + test/jdk/java/util/TimeZone/SimpleTimeZoneEqualsHashCodeTest.java Changeset: 501fa204 Branch: master Author: William Kemper Date: 2025-10-09 18:25:47 +0000 URL: https://git.openjdk.org/loom/commit/501fa2041a77139a9ac42fef69f28b1fd50fee65 8368501: Shenandoah: GC progress evaluation does not use generation Reviewed-by: ysr ! src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoahMetrics.cpp ! src/hotspot/share/gc/shenandoah/shenandoahMetrics.hpp Changeset: 1992b69a Branch: master Author: Aleksey Shipilev Date: 2025-10-09 18:47:43 +0000 URL: https://git.openjdk.org/loom/commit/1992b69a4794d1f2f65eaeb6dbb1e1e23a948b6e 8369283: Improve trace logs in safepoint machinery Reviewed-by: fbredberg, dholmes, rehn ! src/hotspot/share/runtime/safepoint.cpp ! src/hotspot/share/runtime/sharedRuntime.cpp Changeset: b73228b5 Branch: master Author: Vladimir Petko Committer: Erik Joelsson Date: 2025-10-09 19:38:44 +0000 URL: https://git.openjdk.org/loom/commit/b73228b51c1b1c59c8cd8ee7b14522edc12d564a 8369450: [Ubuntu 25.10] openjdk fails to build due to rust-coreutils date Reviewed-by: erikj ! make/autoconf/basic_tools.m4 Changeset: 1cdd241f Branch: master Author: Albert Mingkun Yang Date: 2025-10-09 19:39:06 +0000 URL: https://git.openjdk.org/loom/commit/1cdd241ff3ed57a4df4bac54b2659d68d161b53c 8369420: Parallel: Use multiple workers for class unloading Reviewed-by: fandreuzzi, tschatzl, zgu ! src/hotspot/share/gc/parallel/psParallelCompact.cpp Changeset: cd1ce588 Branch: master Author: Mikael Vidstedt Date: 2025-10-09 19:55:49 +0000 URL: https://git.openjdk.org/loom/commit/cd1ce5883db55540379ce090244b698696e16ec3 8369454: Verify checksums of downloaded source bundles when creating devkit Reviewed-by: erikj ! make/devkit/Tools.gmk Changeset: d6e2d4eb Branch: master Author: William Kemper Date: 2025-10-10 00:16:10 +0000 URL: https://git.openjdk.org/loom/commit/d6e2d4eb1f87016ab158b62c61c33c4bf92a0ed4 8367646: [GenShen] Control thread may overwrite gc cancellation cause set by mutator Reviewed-by: ysr, kdnilsen ! src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp ! src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.cpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp ! src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp Changeset: 52b02eda Branch: master Author: Alexander Matveev Date: 2025-10-10 01:11:10 +0000 URL: https://git.openjdk.org/loom/commit/52b02edaba55920c44b9aba6a9db53d8c9ae9292 8362598: [macos] Add tests for custom info plist files Reviewed-by: asemenyuk = src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/PListWriter.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/XmlUtils.java + test/jdk/tools/jpackage/helpers-test/jdk/jpackage/test/MacHelperTest.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacHelper.java + test/jdk/tools/jpackage/macosx/CustomInfoPListTest.java ! test/jdk/tools/jpackage/macosx/MacFileAssociationsTest.java ! test/jdk/tools/jpackage/macosx/SigningRuntimeImagePackageTest.java Changeset: 1873b459 Branch: master Author: Alexander Matveev Date: 2025-10-10 01:11:35 +0000 URL: https://git.openjdk.org/loom/commit/1873b4594883758a5c8b4094f49dfea36c7c0145 8356047: [macos] jpackage produces confusing post- and pre- installation PKG scripts Reviewed-by: asemenyuk ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacPkgInstallerScripts.java ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacPkgPackager.java - src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/postinstall.template - src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/preinstall.template ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/OverridableResource.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources.properties ! src/jdk.jpackage/unix/classes/jdk/jpackage/internal/PackageScripts.java ! src/jdk.jpackage/unix/classes/jdk/jpackage/internal/ShellScriptResource.java + test/jdk/tools/jpackage/macosx/PkgScriptsTest.java Changeset: 2311ec39 Branch: master Author: Alexey Semenyuk Date: 2025-10-10 02:42:11 +0000 URL: https://git.openjdk.org/loom/commit/2311ec394df9a096d6f7cd52b65ae2660dfe20b4 8363979: Add JDK bundle/image validation for --runtime-image option Reviewed-by: almatvee ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacBundle.java ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacFromParams.java + src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacRuntimeValidator.java ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources.properties ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/DeployParams.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/FromParams.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/RuntimeBuilderBuilder.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources.properties ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixSourceConverter.java ! test/jdk/tools/jpackage/share/ErrorTest.java Changeset: f4209dff Branch: master Author: Saint Wesonga Committer: David Holmes Date: 2025-10-10 03:55:47 +0000 URL: https://git.openjdk.org/loom/commit/f4209dff3ba14ccbdc0846d9bfcc62688361b6d5 8348862: runtime/ErrorHandling/CreateCoredumpOnCrash fails on Windows aarch64 Reviewed-by: dholmes, mbeckwit ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/os/windows/os_windows.hpp + src/hotspot/os/windows/safefetch_static_windows.cpp ! src/hotspot/os_cpu/windows_aarch64/os_windows_aarch64.cpp + src/hotspot/os_cpu/windows_aarch64/safefetch_windows_aarch64.S ! src/hotspot/share/runtime/safefetch.hpp ! test/hotspot/jtreg/runtime/ErrorHandling/UncaughtNativeExceptionTest.java ! test/hotspot/jtreg/runtime/ErrorHandling/libNativeException.c Changeset: 5a32966d Branch: master Author: Phil Race Date: 2025-10-10 04:30:14 +0000 URL: https://git.openjdk.org/loom/commit/5a32966d4255131cf0ac1273b603d994829596e2 8369516: Delete duplicate imaging test Reviewed-by: serb - test/jdk/java/awt/image/VolatileImage/DrawBufImgOp.java Changeset: be107224 Branch: master Author: Yasumasa Suenaga Date: 2025-10-10 05:02:56 +0000 URL: https://git.openjdk.org/loom/commit/be10722436f20df26de66c00c4bc1b6772aa9087 8366847: JFR reports incorrect number of cores on hybrid CPU Reviewed-by: dholmes, egahlin ! src/hotspot/cpu/x86/vm_version_x86.cpp ! src/hotspot/share/jfr/metadata/metadata.xml Changeset: b6e5ef4a Branch: master Author: Mikhail Yankelevich Date: 2025-10-10 06:54:58 +0000 URL: https://git.openjdk.org/loom/commit/b6e5ef4ad0989d3bf0c579dbd6f5bf36b52e41e2 8360373: src/java.base/share/classes/sun/security/util/Debug.java implement negative testing Reviewed-by: coffeys ! test/jdk/sun/security/util/Debug/DebugOptions.java Changeset: b00720ed Branch: master Author: Zhengyu Gu Date: 2025-10-10 07:37:09 +0000 URL: https://git.openjdk.org/loom/commit/b00720edd72226ae9ffecbcb9c1062d3ceb8c6df 8369419: Error reporting of JFR JNI method registration crash on MacOSX Reviewed-by: jbachorik, egahlin ! src/hotspot/share/jfr/jni/jfrJniMethodRegistration.cpp Changeset: 1159b53b Branch: master Author: Joel Sikstr?m Date: 2025-10-10 08:10:07 +0000 URL: https://git.openjdk.org/loom/commit/1159b53bfcfce771a23506394d998b0d95eb8981 8369483: Cleanup dead code in HandleArea Reviewed-by: fandreuzzi, stefank ! src/hotspot/share/runtime/handles.cpp ! src/hotspot/share/runtime/handles.hpp ! src/hotspot/share/runtime/thread.cpp Changeset: a1a37bd7 Branch: master Author: Severin Gehwolf Date: 2025-10-10 08:14:06 +0000 URL: https://git.openjdk.org/loom/commit/a1a37bd7b2a8807f462909eadfa83ec26261e464 8369441: Two container tests fail after JDK-8292984 Reviewed-by: mbaesken, cnorrbin, syan ! test/hotspot/jtreg/containers/docker/TestJFREvents.java ! test/hotspot/jtreg/containers/docker/TestMemoryAwareness.java Changeset: d5a20799 Branch: master Author: Chris Dennis Committer: Alan Bateman Date: 2025-10-10 09:19:55 +0000 URL: https://git.openjdk.org/loom/commit/d5a207994b9c374e6638e57826326f8f4593b96b 8362123: ClassLoader Leak via Executors.newSingleThreadExecutor(...) Reviewed-by: vklang, alanb ! src/java.base/share/classes/java/util/concurrent/Executors.java ! test/jdk/java/util/concurrent/Executors/AutoShutdown.java Changeset: f52aed6f Branch: master Author: Mar?a Arias de Reyna Dom?nguez Committer: Severin Gehwolf Date: 2025-10-10 09:46:37 +0000 URL: https://git.openjdk.org/loom/commit/f52aed6f81e7df9ab9a379ada952b8e666c54e6d 8369418: Identify owning class for KlassTrainingData in AOT map output Reviewed-by: iklam, adinn ! src/hotspot/share/cds/aotMapLogger.cpp ! src/hotspot/share/cds/aotMapLogger.hpp Changeset: afda8ad4 Branch: master Author: Albert Mingkun Yang Date: 2025-10-10 10:18:45 +0000 URL: https://git.openjdk.org/loom/commit/afda8ad46045a4e2d1db608397aa3e03a953153f 8369501: Parallel: Add UseAdaptiveSizePolicy requirement to TestDynShrinkHeap.java Reviewed-by: jsikstro, tschatzl ! test/hotspot/jtreg/gc/parallel/TestDynShrinkHeap.java ! test/jtreg-ext/requires/VMProps.java Changeset: 5594d6bc Branch: master Author: Aleksei Voitylov Committer: Severin Gehwolf Date: 2025-10-10 13:33:12 +0000 URL: https://git.openjdk.org/loom/commit/5594d6bc88bbe39e6ebfd02fb9c37cf40b8d0479 8368522: (fs) BasicFileAttributes Linux musl 1.2.5 incompatibility with statx Reviewed-by: sgehwolf, bpb ! src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c ! test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c Changeset: f6d77cb3 Branch: master Author: Kangcheng Xu Committer: Roland Westrelin Date: 2025-10-10 14:04:51 +0000 URL: https://git.openjdk.org/loom/commit/f6d77cb33299ae0636a2b52ee752f27e9ea9191b 8347555: [REDO] C2: implement optimization for series of Add of unique value Reviewed-by: roland, epeter ! src/hotspot/share/opto/addnode.cpp ! src/hotspot/share/opto/addnode.hpp ! src/hotspot/share/utilities/globalDefinitions.hpp ! test/hotspot/gtest/utilities/test_java_arithmetic.cpp + test/hotspot/jtreg/compiler/c2/gvn/TestCollapsingSameTermAdditions.java + test/micro/org/openjdk/bench/vm/compiler/SerialAdditions.java Changeset: fc49a1b5 Branch: master Author: Francesco Andreuzzi Committer: Brian Burkhalter Date: 2025-10-10 15:39:27 +0000 URL: https://git.openjdk.org/loom/commit/fc49a1b502530908618b19bcd749aa4db0b598d9 8368846: java/io/File/createTempFile/TargetDirectory fails when run by root user Reviewed-by: bpb ! test/jdk/java/io/File/createTempFile/TargetDirectory.java Changeset: 376d77e8 Branch: master Author: Justin Lu Date: 2025-10-10 16:27:56 +0000 URL: https://git.openjdk.org/loom/commit/376d77e8a71478f456af5baaf47f446eebd79e36 8369050: DecimalFormat Rounding Errors for Fractional Ties Near Zero Reviewed-by: naoto ! src/java.base/share/classes/java/text/DigitList.java + test/jdk/java/text/Format/DecimalFormat/RoundingTiesNearZeroTest.java ! test/jdk/java/text/Format/NumberFormat/NumberRegression.java Changeset: 7e29d294 Branch: master Author: Albert Mingkun Yang Date: 2025-10-10 18:01:09 +0000 URL: https://git.openjdk.org/loom/commit/7e29d294e53a246864e9473bf461f0f4c1f6e388 8369097: Parallel: Support allocation in from space when heap is too full Reviewed-by: tschatzl, fandreuzzi ! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp Changeset: 2dfe4586 Branch: master Author: SendaoYan Date: 2025-10-11 05:58:14 +0000 URL: https://git.openjdk.org/loom/commit/2dfe4586f7a29d9e3a944e6483d5d4cbbdde3be8 8369490: Remove unused Runinfo parameters in compiler/c2/gvn/TestBitCompressValueTransform.java Reviewed-by: chagedorn, mhaessig ! test/hotspot/jtreg/compiler/c2/gvn/TestBitCompressValueTransform.java Changeset: 9b99bc8e Branch: master Author: Francesco Andreuzzi Committer: SendaoYan Date: 2025-10-11 06:13:13 +0000 URL: https://git.openjdk.org/loom/commit/9b99bc8ef53ad20c4f1cb5d26cffc64b0deb79ad 8369440: Remove RootResolverMarkScope and RootSetClosureMarkScope Reviewed-by: ayang ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/serial/serialHeap.cpp - src/hotspot/share/gc/shared/strongRootsScope.cpp - src/hotspot/share/gc/shared/strongRootsScope.hpp ! src/hotspot/share/jfr/leakprofiler/chains/rootSetClosure.cpp ! src/hotspot/share/jfr/leakprofiler/checkpoint/rootResolver.cpp From robaho at me.com Sun Oct 12 11:07:05 2025 From: robaho at me.com (Robert Engels) Date: Sun, 12 Oct 2025 06:07:05 -0500 Subject: Feedback on Structured Concurrency (JEP 525, 6th Preview) In-Reply-To: References: Message-ID: <04D8BCCB-C92D-4EBE-B1F0-4C134864F116@me.com> Well said. > On Oct 12, 2025, at 12:33?AM, Jige Yu wrote: > > ? > Hi Project Loom. > > First and foremost, I want to express my gratitude for the effort that has gone into structured concurrency. API design in this space is notoriously difficult, and this feedback is offered with the greatest respect for the team's work and in the spirit of collaborative refinement. > > My perspective is that of a developer looking to use Structured Concurrency for common, IO-intensive fan-out operations. My focus is to replace everyday async callback hell, or reactive chains with something simpler and more readable. > > It will lack depth in the highly specialized concurrent programming area. And I acknowledge this viewpoint may bias my feedback. > > High-Level Impression > > From this perspective, the current API feels imperative and more complex for the common intended use cases than necessary. It introduces significant cognitive load through its stateful nature and manual lifecycle management. > > Specific Points of Concern > > Stateful and Imperative API: The API imposes quite some "don't do this at time X" rules. Attempting to fork() after join() leads to a runtime error; forgetting to call join() is another error; and the imperative fork/join sequence is more cumbersome than a declarative approach would be. None of these are unmanageable though. > > Challenging Exception Handling: The exception handling model is tricky: > > Loss of Checked Exception Compile-Time Safety: FailedException is effectively an unchecked wrapper that erases checked exception information at compile time. Migrating from sequential, structured code to concurrent code now means losing valuable compiler guarantees. > > No Help For Exception Handling: For code that wants to catch and handle these exceptions, it's the same story of using instanceof on the getCause(), again, losing all compile-time safety that was available in equivalent sequential code. > > Burdensome InterruptedException Handling: The requirement for the caller to handle or propagate InterruptedException from join() will add room for error as handling InterruptedException is easy to get wrong: one can forget to call currentThread().interrupt(). Or, if the caller decides to declare throws InterruptedException, the signature propagation becomes viral. > > Default Exception Swallowing: The AnySuccessOrThrow policy swallows all exceptions by default, including critical ones like NullPointerException, IllegalArgumentException, or even an Error. This makes it dangerously easy to mask bugs that should be highly visible. There is no straightforward mechanism to inspect these suppressed exceptions or fail on specific, unexpected types. > > Conflated API Semantics: The StructuredTaskScope API unifies two very different concurrency patterns?"gather all" (allSuccessfulOrThrow) and "race to first success" (anySuccessfulResultOrThrow)?under a single class but with different interaction models for the same method. > > In the "gather all" pattern (allSuccessfulOrThrow), join() returns void. The callsite should use subtask.get() to retrieve results. > > In the "race" pattern (anySuccessfulResultOrThrow), join() returns the result (R) of the first successful subtask directly. The developer should not call get() on individual subtasks. Having the join()+subtask.get() method spec'ed conditionally (which method to use and how depends on the actual policy) feels like a minor violation of LSP and is a source of confusion. It may be an indication of premature abstraction. > > Overly Complex Customization: The StructuredTaskScope.Policy API, while powerful, feels like a potential footgun. The powerful lifecycle callback methods like onFork(), onComplete(), onTimeout() may lower the barrier to creating intricate, framework-like abstractions that are difficult to reason about and debug. > > Suggestions for a Simpler Model > > My preference is that the API for the most common use cases should be more declarative and functional. > > Simplify the "Gather All" Pattern: The primary "fan-out and gather" use case could be captured in a simple, high-level construct. An average user shouldn't need to learn the wide API surface of StructuredTaskScope + Joiner + the lifecycles. For example: > > Java > > // Ideal API for the 80% use case > Robot robot = Concurrently.call( > () -> fetchArm(), > () -> fetchLeg(), > (arm, leg) -> new Robot(arm, leg) > ); > Separate Race Semantics into Composable Operations: The "race" pattern feels like a distinct use case that could be implemented more naturally using composable, functional APIs like Stream gatherers, rather than requiring a specialized API at all. For example, if mapConcurrent() fully embraced structured concurrency, guaranteeing fail-fast and happens-before, a recoverable race could be written explicitly: > > Java > > // Pseudo-code for a recoverable race using a stream gatherer > T race(Collection> tasks, int maxConcurrency) { > var exceptions = new ConcurrentLinkedQueue(); > return tasks.stream() > .gather(mapConcurrent(maxConcurrency, task -> { > try { > return task.call(); > } catch (RpcException e) { > if (isRecoverable(e)) { // Selectively recover > exceptions.add(e); > return null; // Suppress and continue > } > throw new RuntimeException(e); // Fail fast on non-recoverable > } > })) > .filter(Objects::nonNull) > .findFirst() // Short-circuiting and cancellation > .orElseThrow(() -> new AggregateException(exceptions)); > } > While this is slightly more verbose than the JEP example, it's familiar Stream semantics that people have already learned, and it offers explicit control over which exceptions are recoverable versus fatal. The boilerplate for exception aggregation could easily be wrapped in a helper method. > > Reserve Complexity for Complex Cases: The low-level StructuredTaskScope and its policy mechanism are powerful tools. However, they should be positioned as the "expert-level" API for building custom frameworks. Or perhaps just keep them in the traditional ExecutorService API. The everyday developer experience should be centered around simpler, declarative constructs that cover the most frequent needs. > > I realize my perspective is heavily biased towards the 'everyday' use case and I may not realize or appreciate the full scope of problems the JEP aims to solve. And I used a lot of "feels". ;-> > > Anyhow, please forgive ignorance and disregard any points that don't align with the project's broader vision. > > Thank you again for your dedication to moving Java forward. -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Sun Oct 12 13:27:23 2025 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 12 Oct 2025 15:27:23 +0200 (CEST) Subject: Feedback on Structured Concurrency (JEP 525, 6th Preview) In-Reply-To: References: Message-ID: <1020836368.12976271.1760275643219.JavaMail.zimbra@univ-eiffel.fr> > From: "Jige Yu" > To: "loom-dev" > Sent: Sunday, October 12, 2025 7:32:33 AM > Subject: Feedback on Structured Concurrency (JEP 525, 6th Preview) > Hi Project Loom. Hello, > First and foremost, I want to express my gratitude for the effort that has gone > into structured concurrency. API design in this space is notoriously difficult, > and this feedback is offered with the greatest respect for the team's work and > in the spirit of collaborative refinement. > My perspective is that of a developer looking to use Structured Concurrency for > common, IO-intensive fan-out operations. My focus is to replace everyday async > callback hell, or reactive chains with something simpler and more readable. > It will lack depth in the highly specialized concurrent programming area. And I > acknowledge this viewpoint may bias my feedback. > High-Level Impression > From this perspective, the current API feels imperative and more complex for the > common intended use cases than necessary. It introduces significant cognitive > load through its stateful nature and manual lifecycle management. > Specific Points of Concern > 1. > Stateful and Imperative API: The API imposes quite some "don't do this at time > X" rules. Attempting to fork() after join() leads to a runtime error; > forgetting to call join() is another error; and the imperative fork / join > sequence is more cumbersome than a declarative approach would be. None of these > are unmanageable though. I had a similar feeling the first time I used the API, but once you play with it, it kind of make sense. The API can be used when all tasks are different (concurrent tasks) or when all task are the same (parallel tasks), a more functional API will only work with the latter. > 1. > Challenging Exception Handling: The exception handling model is tricky: > * > Loss of Checked Exception Compile-Time Safety: FailedException is effectively an > unchecked wrapper that erases checked exception information at compile time. > Migrating from sequential, structured code to concurrent code now means losing > valuable compiler guarantees. You can propagate the exceptions but it makes the API clunkier (one more type variable everywhere) and do not solve the fundamental problem that you do not want to merge the control flow of an exception that comes from a callable with one that comes from STS.join(). By example, distinguishing if an InterruptedException is raised because the main thread is interrupted or if one of the callable is interrupted (and this is the same will all runtime exceptions). > 1. > * > No Help For Exception Handling: For code that wants to catch and handle these > exceptions, it's the same story of using instanceof on the getCause(), again, > losing all compile-time safety that was available in equivalent sequential > code. see above > 1. > * > Burdensome InterruptedException Handling: The requirement for the caller to > handle or propagate InterruptedException from join() will add room for error as > handling InterruptedException is easy to get wrong: one can forget to call > currentThread().interrupt(). Or, if the caller decides to declare throws > InterruptedException , the signature propagation becomes viral. Having InterruptedException not being runtime exception is a pain. But this is a pain for all blocking methods. And BTW, you can also wrap it into a runtime exception (usually UncheckedIOException/IOError) which works better than currentThread().interrupt() because you do not loose the context (the stack trace) and avoid the problem of the signature propagation. Perhaps at some point in the future, all exceptions will be runtime exceptions (like in Kotlin or C#) but this is a Java problem not a problem of the STS API. > 1. > * > Default Exception Swallowing: The AnySuccessOrThrow policy swallows all > exceptions by default, including critical ones like NullPointerException , > IllegalArgumentException , or even an Error . This makes it dangerously easy to > mask bugs that should be highly visible. There is no straightforward mechanism > to inspect these suppressed exceptions or fail on specific, unexpected types. The straightforward mechanism is to inspect the Subtasks that keep that information (if available). > 1. > Conflated API Semantics: The StructuredTaskScope API unifies two very different > concurrency patterns?"gather all" ( allSuccessfulOrThrow ) and "race to first > success" ( anySuccessfulResultOrThrow )?under a single class but with different > interaction models for the same method. > * > In the "gather all" pattern ( allSuccessfulOrThrow ), join() returns void . The > callsite should use subtask.get() to retrieve results. > * > In the "race" pattern ( anySuccessfulResultOrThrow ), join() returns the result > ( R ) of the first successful subtask directly. The developer should not call > get() on individual subtasks. Having the join()+subtask.get() method spec'ed > conditionally (which method to use and how depends on the actual policy) feels > like a minor violation of LSP and is a source of confusion. It may be an > indication of premature abstraction. I kind agree on this one, i.e. i would like the semantics of when to stop the STS and the semantics of getting all subtaks or not to be separated given there are separated concern. > 1. > Overly Complex Customization: The StructuredTaskScope.Policy API, while > powerful, feels like a potential footgun. The powerful lifecycle callback > methods like onFork(), onComplete(), onTimeout() may lower the barrier to > creating intricate, framework-like abstractions that are difficult to reason > about and debug. yes, especially if you try to do reduce to a value (like a Collector) inside the Joiner but this is called out by the documentation. I will answer the rest of the mail, in a new message. R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Sun Oct 12 13:43:00 2025 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 12 Oct 2025 15:43:00 +0200 (CEST) Subject: Feedback on Structured Concurrency (JEP 525, 6th Preview) In-Reply-To: References: Message-ID: <1111940277.12978084.1760276580257.JavaMail.zimbra@univ-eiffel.fr> > From: "Jige Yu" > To: "loom-dev" > Sent: Sunday, October 12, 2025 7:32:33 AM > Subject: Feedback on Structured Concurrency (JEP 525, 6th Preview) > Hi Project Loom. > First and foremost, I want to express my gratitude for the effort that has gone > into structured concurrency. API design in this space is notoriously difficult, > and this feedback is offered with the greatest respect for the team's work and > in the spirit of collaborative refinement. > My perspective is that of a developer looking to use Structured Concurrency for > common, IO-intensive fan-out operations. My focus is to replace everyday async > callback hell, or reactive chains with something simpler and more readable. > It will lack depth in the highly specialized concurrent programming area. And I > acknowledge this viewpoint may bias my feedback. [...] > Suggestions for a Simpler Model > My preference is that the API for the most common use cases should be more > declarative and functional . > 1. > Simplify the "Gather All" Pattern: The primary "fan-out and gather" use case > could be captured in a simple, high-level construct. An average user shouldn't > need to learn the wide API surface of StructuredTaskScope + Joiner + the > lifecycles. For example: > Java > // Ideal API for the 80% use case Robot robot = Concurrently.call( > () -> fetchArm(), > () -> fetchLeg(), > (arm, leg) -> new Robot(arm, leg) > ); I'm curious how you want to type that API, does it work only for two tasks, do you have an overload for each arity (2 tasks, 3 tasks, etc). And how exceptions are supposed to work given that the type system of Java is not able to merge type variable representing exceptions correctly. > 1. > Separate Race Semantics into Composable Operations: The "race" pattern feels > like a distinct use case that could be implemented more naturally using > composable, functional APIs like Stream gatherers, rather than requiring a > specialized API at all. For example, if mapConcurrent() fully embraced > structured concurrency, guaranteeing fail-fast and happens-before, a > recoverable race could be written explicitly: > Java > // Pseudo-code for a recoverable race using a stream gatherer T race > (Collection> tasks, int maxConcurrency) { var exceptions = new > ConcurrentLinkedQueue(); return tasks.stream() > .gather(mapConcurrent(maxConcurrency, task -> { try { return task.call(); > } catch (RpcException e) { if (isRecoverable(e)) { // Selectively recover > exceptions.add(e); return null ; // Suppress and continue } throw new > RuntimeException(e); // Fail fast on non-recoverable } > })) > .filter(Objects::nonNull) > .findFirst() // Short-circuiting and cancellation .orElseThrow(() -> new > AggregateException(exceptions)); > } > While this is slightly more verbose than the JEP example, it's familiar Stream > semantics that people have already learned, and it offers explicit control over > which exceptions are recoverable versus fatal. The boilerplate for exception > aggregation could easily be wrapped in a helper method. Several points : - I believe the current STS API has no way to deal with if the exception is recoverable or not because it's far easier to do that at the end of the callable. Your example becomes : sts.fork(() -> { try { taskCall(); } catch(RPCException e) { ... } }); - You do not want to post the result/exception of a task into a concurrent data structure, i think the idea of the STS API in this case is to fork all the tasks and then take a look to all the subtasks. I believe it's more efficient because there is no CAS to be done if the main thread take a look to the subtasks afterward than if the joiner tries to maintain a concurrent data structure. > 1. > Reserve Complexity for Complex Cases: The low-level StructuredTaskScope and its > policy mechanism are powerful tools. However, they should be positioned as the > "expert-level" API for building custom frameworks. Or perhaps just keep them in > the traditional ExecutorService API. The everyday developer experience should > be centered around simpler, declarative constructs that cover the most frequent > needs. For me, that's why you have an open Joiner interface for expert and already available Joiner (like all.../any...) that are more for everyday developers. regards, R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at me.com Sun Oct 12 13:52:02 2025 From: robaho at me.com (Robert Engels) Date: Sun, 12 Oct 2025 08:52:02 -0500 Subject: Feedback on Structured Concurrency (JEP 525, 6th Preview) In-Reply-To: <1020836368.12976271.1760275643219.JavaMail.zimbra@univ-eiffel.fr> References: <1020836368.12976271.1760275643219.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <841CE986-3903-473A-B10B-0BDAE58CAEF3@me.com> Checked exceptions are great. Just need to understand how to use them properly. I think the Swift way of addressing it is fantastic. > On Oct 12, 2025, at 8:28?AM, Remi Forax wrote: > > ? > > > From: "Jige Yu" > To: "loom-dev" > Sent: Sunday, October 12, 2025 7:32:33 AM > Subject: Feedback on Structured Concurrency (JEP 525, 6th Preview) > Hi Project Loom. > > > Hello, > > First and foremost, I want to express my gratitude for the effort that has gone into structured concurrency. API design in this space is notoriously difficult, and this feedback is offered with the greatest respect for the team's work and in the spirit of collaborative refinement. > > My perspective is that of a developer looking to use Structured Concurrency for common, IO-intensive fan-out operations. My focus is to replace everyday async callback hell, or reactive chains with something simpler and more readable. > > It will lack depth in the highly specialized concurrent programming area. And I acknowledge this viewpoint may bias my feedback. > > High-Level Impression > > From this perspective, the current API feels imperative and more complex for the common intended use cases than necessary. It introduces significant cognitive load through its stateful nature and manual lifecycle management. > > Specific Points of Concern > > Stateful and Imperative API: The API imposes quite some "don't do this at time X" rules. Attempting to fork() after join() leads to a runtime error; forgetting to call join() is another error; and the imperative fork/join sequence is more cumbersome than a declarative approach would be. None of these are unmanageable though. > > > I had a similar feeling the first time I used the API, but once you play with it, it kind of make sense. > The API can be used when all tasks are different (concurrent tasks) or when all task are the same (parallel tasks), a more functional API will only work with the latter. > > > Challenging Exception Handling: The exception handling model is tricky: > > Loss of Checked Exception Compile-Time Safety: FailedException is effectively an unchecked wrapper that erases checked exception information at compile time. Migrating from sequential, structured code to concurrent code now means losing valuable compiler guarantees. > > > You can propagate the exceptions but it makes the API clunkier (one more type variable everywhere) and do not solve the fundamental problem that you do not want to merge the control flow of an exception that comes from a callable with one that comes from STS.join(). By example, distinguishing if an InterruptedException is raised because the main thread is interrupted or if one of the callable is interrupted (and this is the same will all runtime exceptions). > > No Help For Exception Handling: For code that wants to catch and handle these exceptions, it's the same story of using instanceof on the getCause(), again, losing all compile-time safety that was available in equivalent sequential code. > > > see above > > Burdensome InterruptedException Handling: The requirement for the caller to handle or propagate InterruptedException from join() will add room for error as handling InterruptedException is easy to get wrong: one can forget to call currentThread().interrupt(). Or, if the caller decides to declare throws InterruptedException, the signature propagation becomes viral. > > > Having InterruptedException not being runtime exception is a pain. But this is a pain for all blocking methods. > And BTW, you can also wrap it into a runtime exception (usually UncheckedIOException/IOError) which works better than currentThread().interrupt() because you do not loose the context (the stack trace) and avoid the problem of the signature propagation. > > Perhaps at some point in the future, all exceptions will be runtime exceptions (like in Kotlin or C#) but this is a Java problem not a problem of the STS API. > > > Default Exception Swallowing: The AnySuccessOrThrow policy swallows all exceptions by default, including critical ones like NullPointerException, IllegalArgumentException, or even an Error. This makes it dangerously easy to mask bugs that should be highly visible. There is no straightforward mechanism to inspect these suppressed exceptions or fail on specific, unexpected types. > > > The straightforward mechanism is to inspect the Subtasks that keep that information (if available). > > Conflated API Semantics: The StructuredTaskScope API unifies two very different concurrency patterns?"gather all" (allSuccessfulOrThrow) and "race to first success" (anySuccessfulResultOrThrow)?under a single class but with different interaction models for the same method. > > In the "gather all" pattern (allSuccessfulOrThrow), join() returns void. The callsite should use subtask.get() to retrieve results. > > In the "race" pattern (anySuccessfulResultOrThrow), join() returns the result (R) of the first successful subtask directly. The developer should not call get() on individual subtasks. Having the join()+subtask.get() method spec'ed conditionally (which method to use and how depends on the actual policy) feels like a minor violation of LSP and is a source of confusion. It may be an indication of premature abstraction. > > > I kind agree on this one, i.e. i would like the semantics of when to stop the STS and the semantics of getting all subtaks or not to be separated given there are separated concern. > > Overly Complex Customization: The StructuredTaskScope.Policy API, while powerful, feels like a potential footgun. The powerful lifecycle callback methods like onFork(), onComplete(), onTimeout() may lower the barrier to creating intricate, framework-like abstractions that are difficult to reason about and debug. > > > yes, especially if you try to do reduce to a value (like a Collector) inside the Joiner but this is called out by the documentation. > > I will answer the rest of the mail, in a new message. > > R?mi > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Sun Oct 12 16:39:31 2025 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Sun, 12 Oct 2025 18:39:31 +0200 (CEST) Subject: Feedback on Structured Concurrency (JEP 525, 6th Preview) In-Reply-To: <841CE986-3903-473A-B10B-0BDAE58CAEF3@me.com> References: <1020836368.12976271.1760275643219.JavaMail.zimbra@univ-eiffel.fr> <841CE986-3903-473A-B10B-0BDAE58CAEF3@me.com> Message-ID: <1607665109.13070803.1760287171464.JavaMail.zimbra@univ-eiffel.fr> > From: "Robert Engels" > To: "Remi Forax" > Cc: "Jige Yu" , "loom-dev" > Sent: Sunday, October 12, 2025 3:52:02 PM > Subject: Re: Feedback on Structured Concurrency (JEP 525, 6th Preview) > Checked exceptions are great. Just need to understand how to use them properly. > I think the Swift way of addressing it is fantastic. see [ https://www.artima.com/articles/the-trouble-with-checked-exceptions | https://www.artima.com/articles/the-trouble-with-checked-exceptions ] regards, R?mi >> On Oct 12, 2025, at 8:28 AM, Remi Forax wrote: >>> From: "Jige Yu" >>> To: "loom-dev" >>> Sent: Sunday, October 12, 2025 7:32:33 AM >>> Subject: Feedback on Structured Concurrency (JEP 525, 6th Preview) >>> Hi Project Loom. >> Hello, >>> First and foremost, I want to express my gratitude for the effort that has gone >>> into structured concurrency. API design in this space is notoriously difficult, >>> and this feedback is offered with the greatest respect for the team's work and >>> in the spirit of collaborative refinement. >>> My perspective is that of a developer looking to use Structured Concurrency for >>> common, IO-intensive fan-out operations. My focus is to replace everyday async >>> callback hell, or reactive chains with something simpler and more readable. >>> It will lack depth in the highly specialized concurrent programming area. And I >>> acknowledge this viewpoint may bias my feedback. >>> High-Level Impression >>> From this perspective, the current API feels imperative and more complex for the >>> common intended use cases than necessary. It introduces significant cognitive >>> load through its stateful nature and manual lifecycle management. >>> Specific Points of Concern >>> 1. >>> Stateful and Imperative API: The API imposes quite some "don't do this at time >>> X" rules. Attempting to fork() after join() leads to a runtime error; >>> forgetting to call join() is another error; and the imperative fork / join >>> sequence is more cumbersome than a declarative approach would be. None of these >>> are unmanageable though. >> I had a similar feeling the first time I used the API, but once you play with >> it, it kind of make sense. >> The API can be used when all tasks are different (concurrent tasks) or when all >> task are the same (parallel tasks), a more functional API will only work with >> the latter. >>> 1. >>> Challenging Exception Handling: The exception handling model is tricky: >>> * >>> Loss of Checked Exception Compile-Time Safety: FailedException is effectively an >>> unchecked wrapper that erases checked exception information at compile time. >>> Migrating from sequential, structured code to concurrent code now means losing >>> valuable compiler guarantees. >> You can propagate the exceptions but it makes the API clunkier (one more type >> variable everywhere) and do not solve the fundamental problem that you do not >> want to merge the control flow of an exception that comes from a callable with >> one that comes from STS.join(). By example, distinguishing if an >> InterruptedException is raised because the main thread is interrupted or if one >> of the callable is interrupted (and this is the same will all runtime >> exceptions). >>> 1. >>> * >>> No Help For Exception Handling: For code that wants to catch and handle these >>> exceptions, it's the same story of using instanceof on the getCause(), again, >>> losing all compile-time safety that was available in equivalent sequential >>> code. >> see above >>> 1. >>> * >>> Burdensome InterruptedException Handling: The requirement for the caller to >>> handle or propagate InterruptedException from join() will add room for error as >>> handling InterruptedException is easy to get wrong: one can forget to call >>> currentThread().interrupt(). Or, if the caller decides to declare throws >>> InterruptedException , the signature propagation becomes viral. >> Having InterruptedException not being runtime exception is a pain. But this is a >> pain for all blocking methods. >> And BTW, you can also wrap it into a runtime exception (usually >> UncheckedIOException/IOError) which works better than >> currentThread().interrupt() because you do not loose the context (the stack >> trace) and avoid the problem of the signature propagation. >> Perhaps at some point in the future, all exceptions will be runtime exceptions >> (like in Kotlin or C#) but this is a Java problem not a problem of the STS API. >>> 1. >>> * >>> Default Exception Swallowing: The AnySuccessOrThrow policy swallows all >>> exceptions by default, including critical ones like NullPointerException , >>> IllegalArgumentException , or even an Error . This makes it dangerously easy to >>> mask bugs that should be highly visible. There is no straightforward mechanism >>> to inspect these suppressed exceptions or fail on specific, unexpected types. >> The straightforward mechanism is to inspect the Subtasks that keep that >> information (if available). >>> 1. >>> Conflated API Semantics: The StructuredTaskScope API unifies two very different >>> concurrency patterns?"gather all" ( allSuccessfulOrThrow ) and "race to first >>> success" ( anySuccessfulResultOrThrow )?under a single class but with different >>> interaction models for the same method. >>> * >>> In the "gather all" pattern ( allSuccessfulOrThrow ), join() returns void . The >>> callsite should use subtask.get() to retrieve results. >>> * >>> In the "race" pattern ( anySuccessfulResultOrThrow ), join() returns the result >>> ( R ) of the first successful subtask directly. The developer should not call >>> get() on individual subtasks. Having the join()+subtask.get() method spec'ed >>> conditionally (which method to use and how depends on the actual policy) feels >>> like a minor violation of LSP and is a source of confusion. It may be an >>> indication of premature abstraction. >> I kind agree on this one, i.e. i would like the semantics of when to stop the >> STS and the semantics of getting all subtaks or not to be separated given there >> are separated concern. >>> 1. >>> Overly Complex Customization: The StructuredTaskScope.Policy API, while >>> powerful, feels like a potential footgun. The powerful lifecycle callback >>> methods like onFork(), onComplete(), onTimeout() may lower the barrier to >>> creating intricate, framework-like abstractions that are difficult to reason >>> about and debug. >> yes, especially if you try to do reduce to a value (like a Collector) inside the >> Joiner but this is called out by the documentation. >> I will answer the rest of the mail, in a new message. >> R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From yujige at gmail.com Sun Oct 12 16:49:19 2025 From: yujige at gmail.com (Jige Yu) Date: Sun, 12 Oct 2025 09:49:19 -0700 Subject: Feedback on Structured Concurrency (JEP 525, 6th Preview) In-Reply-To: <1111940277.12978084.1760276580257.JavaMail.zimbra@univ-eiffel.fr> References: <1111940277.12978084.1760276580257.JavaMail.zimbra@univ-eiffel.fr> Message-ID: Thanks for the quick reply, Remi! I'll focus on discussing alternatives, which hopefully should also help clarify my concerns of the current API. On Sun, Oct 12, 2025 at 6:43?AM Remi Forax wrote: > > > ------------------------------ > > *From: *"Jige Yu" > *To: *"loom-dev" > *Sent: *Sunday, October 12, 2025 7:32:33 AM > *Subject: *Feedback on Structured Concurrency (JEP 525, 6th Preview) > > Hi Project Loom.First and foremost, I want to express my gratitude for > the effort that has gone into structured concurrency. API design in this > space is notoriously difficult, and this feedback is offered with the > greatest respect for the team's work and in the spirit of collaborative > refinement. > > My perspective is that of a developer looking to use Structured > Concurrency for common, IO-intensive fan-out operations. My focus is to > replace everyday async callback hell, or reactive chains with something > simpler and more readable. > > It will lack depth in the highly specialized concurrent programming area. > And I acknowledge this viewpoint may bias my feedback. > ------------------------------ > > [...] > > *Suggestions for a Simpler Model* > > My preference is that the API for the most common use cases should be more *declarative > and functional*. > > 1. > > *Simplify the "Gather All" Pattern:* The primary "fan-out and gather" > use case could be captured in a simple, high-level construct. An average > user shouldn't need to learn the wide API surface of StructuredTaskScope + > Joiner + the lifecycles. For example: > Java > > // Ideal API for the 80% use case > Robot robot = Concurrently.call( > () -> fetchArm(), > () -> fetchLeg(), > (arm, leg) -> new Robot(arm, leg) > ); > > > > I'm curious how you want to type that API, does it work only for two > tasks, do you have an overload for each arity (2 tasks, 3 tasks, etc). > And how exceptions are supposed to work given that the type system of Java > is not able to merge type variable representing exceptions correctly. > Just a handful of overloads. Looking from Google's internal code base, up to 5 concurrent fanout probably covers 95% of use cases. The other 5% can either build their own helpers like: // MoreConcurrency R concurrently( Supplier, ..., Supplier, Function10 combiner) { return concurrently( // just nest some concurrent calls () -> concurrently(task1, task2, ..., task5, Tuple5::new), () -> concurrently(task6, ..., task10, Tuple5::new), (tuple1, tuple2) -> combiner.apply(tuple1.a(), tuple1.b(), ..., tuple2.e()); } Or, they can use the homogeneous mapConcurrent() gatherer, and deal with some type casting. In terms of exceptions, directly propagating checked exception across threads may not always be desirable because their stack trace will be confusing. This is why traditionally Future throws ExecutionException with the stack traces chained together. It should be a conscious choice of the developer if they don't mind losing the extra stack trace. I was thinking of one of Google's internal compile-time plugins to help with exception propagation. But before I dive into the details, allow me to clarify the principle that I implicitly adheres to: *Any Checked Exception Must Be Explicitly Caught or Declared As Throws* There must be no secret pathway where it can become unchecked without the developer's explicit acknowledgement. And that is why I'm concerned about the current SC API, where the checked exception can be thrown in the Callable lambda, not have to be caught. And then at the call site it has become unchecked. (well, except maybe InterruptedException, which probably shouldn't have required the developer to catch and handle) Now I'll explain what the Google's internal plugin does, it's called TunnedException, which is an unchecked exception. For streams, it's used like: try { return list.stream().map(v -> tunnel(() -> process(v))).toList(); } catch (TunnelException e) { try { // If you forgot a checked exception, compilation will FAIL throw e.rethrow(IOException.class, InvalidSyntaxException.class); } catch (IOExeption e) { ... } catch (InvalidSyntaxException e) { ... } } At the javac level, tunnel() expects a Callable, which does allow checked exceptions to be magically "unchecked" as TunnelException. And at runtime, the TunnelException will be thrown as is by Stream. But in the ErrorProne plugin, it will recognize that the special tunnel() call has suppressed a few checked exception types (in this case, IOException and InvalidSyntaxException). And then the plugin will validate that within the same lexical scope, rethrow() with the two exception types must be called. Thus compile-time enforcement of checked exceptions remains. And at the catch site we still have the compiler-check about which checked exception that we have forgotten to catch, or the checked exception type cannot possibly be thrown. I played with this idea inside Google, using it for this functional concurrently() flavor of structured concurrency. And it worked out ok: try { return Concurrently.call( () -> tunnel(() -> fetchArm()), () -> tunnel(() -> fetchLeg()), (arm, leg) -> new Robot(arm, leg) ); } catch (TunnelException e) { throw e.rethrow(RpcException.class); // or wrap it in an appropriate application-level exception } I'm not saying that the Google's ErrorrProne plugin be adopted verbatim by Loom. I actually had hoped that the Java team, being the god of Java, can do more, giving us a more systematic solution to checked exceptions in structured concurrency. Google's ErrorProne plugin can be considered a baseline, that at worst, this is what we can do. That said, it's understandable that this whole checked-exception-does-not-work-across-abstractions problem is considered an orthogonal issue and Loom decides it's not in scope. But even then, it's probably prudent to use Supplier instead of Callable for fork(), or in this hypothetical functional SC. The reason I prefer Supplier is that it's consistent with the established checked exception philosophy, and will force the developer to handle the checked exceptions. Even if you do want to propagate it in unchecked, it should be an explicit choice. Either by using plain old try-catch-rethrow, or the developer (or Project Loom) can provide an explicit "unchecker" helper to help save boilerplate: public static Supplier unchecked(Callable task) { return () -> { try { return task.call(); } catch (RuntimeException e) { throw e; } catch (Exception e) { throw new UncheckedExecutionException(e); } }; } Then it's only a matter of changing the call site to the following: return Concurrently.call( unchecked(() -> fetchArm()), unchecked(() -> fetchLeg()), (arm, leg) -> new Robot(arm, leg)); > 1. > > *Separate Race Semantics into Composable Operations:* The "race" > pattern feels like a distinct use case that could be implemented more > naturally using composable, functional APIs like Stream gatherers, rather > than requiring a specialized API at all. For example, if > mapConcurrent() fully embraced structured concurrency, guaranteeing > fail-fast and happens-before, a recoverable race could be written > explicitly: > Java > > // Pseudo-code for a recoverable race using a stream gatherer > T race(Collection> tasks, int maxConcurrency){ > var exceptions = new ConcurrentLinkedQueue(); > return tasks.stream() > .gather(mapConcurrent(maxConcurrency, task -> { > try { > return task.call(); > } catch (RpcException e) { > if (isRecoverable(e)) { // Selectively recover > exceptions.add(e); > return null; // Suppress and continue > } > throw new RuntimeException(e); // Fail fast on non-recoverable > } > })) > .filter(Objects::nonNull) > .findFirst() // Short-circuiting and cancellation > .orElseThrow(() -> new AggregateException(exceptions)); > } > > While this is slightly more verbose than the JEP example, it's > familiar Stream semantics that people have already learned, and it offers > explicit control over which exceptions are recoverable versus fatal. The > boilerplate for exception aggregation could easily be wrapped in a helper > method. > > > Several points : > - I believe the current STS API has no way to deal with if the exception > is recoverable or not because it's far easier to do that at the end of the > callable. > Your example becomes : > > sts.fork(() -> { > try { > taskCall(); > } catch(RPCException e) { > ... > } > }); > > Yes. Though my point is that this now becomes an *opt-in*. It should be an opt-out. Swallowing exceptions should not be the default behavior. And for the anySuccessfulOrThrow() joiner, I don't know it helps much because even if it's not recoverable,you'd still throw in the lambda, and it will still be swallowed by the joiner. > - You do not want to post the result/exception of a task into a concurrent > data structure, i think the idea of the STS API in this case is to fork all > the tasks and then take a look to all the subtasks. > It probably is. What I was trying to say is that the mapConcurrent() approach feels more natural, and safer. > I believe it's more efficient because there is no CAS to be done if the > main thread take a look to the subtasks afterward than if the joiner tries > to maintain a concurrent data structure. > > This may be my blind spot. I've always assumed that structured concurrency where I need to fan out IO-blocking tasks isn't usually the hot path. Even with virtual threads, context switching still isn't cheap enough to worry about low-level micro optimizations? > 1. > > *Reserve Complexity for Complex Cases:* The low-level > StructuredTaskScope and its policy mechanism are powerful tools. > However, they should be positioned as the "expert-level" API for building > custom frameworks. Or perhaps just keep them in the traditional > ExecutorService API. The everyday developer experience should be centered > around simpler, declarative constructs that cover the most frequent needs. > > > For me, that's why you have an open Joiner interface for expert and > already available Joiner (like all.../any...) that are more for everyday > developers. > > Yeah. My point is the current Joiner interface looks too much like an inviting couch that an average developer would immediately start to think: "oh I have a use case I may be able to implement by overriding onComplete()!". But *you don't really need it*. In an analogy, there is Stream API. Most of us would just use the Steam API, passing in lambdas, collectors etc. We would not think of implementing our own BaseStream, which imho would have been an unfortunate distraction. ------------------------------ *InterruptedException* Lastly, my view of InterruptedException is like what you've said: it being a checked exception is unfortunate. It forces people to catch it, which then makes it easier to make the mistake of forgetting to re-interrupt the thread. And actually, few people even understand it (where it comes from, what triggers it,what needs to be done). Even if you do painstakingly declare throws InterruptedException all the way up the call stack, as the usual best practice suggests, the end result is still just as if it were unchecked in the first place, only that way it wouldn't have mandated so much maintenance effort of the developers: the top-level handler catch and handle it once and for all. So I'd consider it a plus if the SC API hides away InterruptedException. Heck, mapConcurrent() already hides it away without forcing users to catch it. If you expect average users to mis-handle it, the better alternative may be to handle it for them already, including perhaps re-interrupting the thread, and turning it into an UncheckedInterruptedException, so that most developers won't be given the chance to make the mistake. regards, > R?mi > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.bateman at oracle.com Sun Oct 12 19:41:33 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Sun, 12 Oct 2025 20:41:33 +0100 Subject: Feedback on Structured Concurrency (JEP 525, 6th Preview) In-Reply-To: References: Message-ID: On 12/10/2025 06:32, Jige Yu wrote: > > > Hi Project Loom. > > > First and foremost, I want to express my gratitude for the > effort that has gone into structured concurrency. API design in > this space is notoriously difficult, and this feedback is > offered with the greatest respect for the team's work and in the > spirit of collaborative refinement. > > My perspective is that of a developer looking to use Structured > Concurrency for common, IO-intensive fan-out operations. My focus is > to replace everyday async callback hell,?or reactive chains with > something simpler and more readable. > > It will lack depth in the highly specialized concurrent programming > area. And I acknowledge this viewpoint may bias my feedback. > Just a general point on providing feedback: The feedback that we most value is feedback from people that have tried a feature or API in earnest. We regularly have people showing up here with alternative APIs proposals but it's never clear if they have the same goals, whether they've tried the feature, or have considered many use cases. This isn't a criticism of your proposal, it's just not clear if this is after trying the feature or not. > ------------------------------------------------------------------------ > > 1. > > *Stateful and Imperative API:* The API imposes quite some "don't > do this at time X" rules. Attempting to |fork()| after |join()| > leads to a runtime error; forgetting to call join() is another > error; and the imperative |fork|/|join| sequence is more > cumbersome than a declarative approach would be. None of these are > unmanageable though. > The API has 5 instance methods and isn't too hard to get wrong. Yes, it's an exception at runtime if someone joins before forking, or attempts to process the outcome before joining. With a few basic recipes/examples then it should be possible for someone to get started quickly. The issues dealing with cancellation and shutdown are difficult to get right and we hope this API will help to avoid several of issues with a relatively simple API. > 1. > > *Challenging Exception Handling:* The exception handling model is > tricky: > > * > > *Loss of Checked Exception Compile-Time Safety:* > |FailedException| is effectively an unchecked wrapper that > erases checked exception information at compile time. > Migrating from sequential, structured code to concurrent code > now means losing valuable compiler guarantees. > > * > > *No Help For Exception Handling: *For code that wants to catch > and handle these exceptions, it's the same story of using > /instanceof/ on the getCause(), again, losing all compile-time > safety that was available in equivalent sequential code. > > * > > *Burdensome |InterruptedException| Handling:* The requirement > for the caller to handle or propagate |InterruptedException| > from |join()|?will add room for error as handling > InterruptedException is easy to get wrong: one can forget to > call currentThread().interrupt(). Or, if the caller decides to > declare /throws/ /InterruptedException/, the signature > propagation becomes viral. > > * > > *Default Exception Swallowing:* The |AnySuccessOrThrow|?policy > *swallows?all exceptions* by default, including critical ones > like |NullPointerException|, |IllegalArgumentException|, or > even an |Error|. This makes it dangerously easy to mask bugs > that should be highly visible. There is no straightforward > mechanism to inspect these suppressed exceptions or fail on > specific, unexpected types. > We aren't happy with needing to wrap exceptions but it is no different to other concurrent APIs, e.g. Future. Countless hours have been spent on explorations to do better. All modelling of exceptions with type parameters lead to cumbersome usage, e.g. a type parameter for the exception thrown by subtasks and another type parameter for the exception thrown by join. If there were union types for exceptions or other changes to the language then we might do better. On anySuccessfulOrThrow, then it's like invokeAny and similar combinators in that it causes join to return a result from any subtasks or throw if all subtasks fail. It would be feasible to develop a Joiner that returns something like `record(Optional result, Map, Throwable> exceptions)` where the map contains the subtasks that failed before the successful subtask. That would be harder to use than the simpler built-in and users always have the option of logging in the failed subtask. > 1. > > *Conflated API Semantics:* The |StructuredTaskScope| API unifies > two very different concurrency patterns?"gather all" > (allSuccessfulOrThrow) and "race to first success" > (|anySuccessfulResultOrThrow|)?under a single class but with > different interaction models for the same method. > > * > > In the *"gather all"* pattern (|allSuccessfulOrThrow|), > |join()| returns |void|. The callsite should use > |subtask.get()|? to retrieve results. > > * > > In the *"race"* pattern (|anySuccessfulResultOrThrow|), > |join()| returns the result (|R|) of the first successful > subtask directly. The developer should /not/ call |get()| on > individual subtasks. Having the |join()+subtask.get()| method > spec'ed conditionally (which method to use and how depends on > the actual policy) feels like a minor violation of LSP and is > a source of confusion. It may be an indication of premature > abstraction. > join always returns something. For allSuccessfulOrThrow it returns a stream of successful subtasks. I think your comment is really about cases where the subtasks return results of the same type vs. other cases where subtasks return results of different types. This is an area where we need feedback. To date, we've been assuming that the more common case is subtasks that return results of different types (arms and legs in your example). For these cases, it's more useful to keep a reference to the subtask so that you don't have to cast when handling the results. It may be that we don't have this right and the common case is homogeneous subtasks, in which case the default Joiner should be allSuccessfulOrThrow so you don't need to keep a reference to the subtasks. > 1. > > *Overly Complex Customization:* The |StructuredTaskScope.Policy| > API, while powerful, feels like a potential footgun. The?powerful > lifecycle callback methods like onFork(), onComplete(), > onTimeout() may lower the barrier to creating intricate, > framework-like abstractions that are difficult to reason about and > debug. > Developing a Joiner for more advanced/expert developers. We have several guidelines in the API docs, the more relevant here is that they aren't the place for business logic, and should be designed to be as general purpose as possible. > ------------------------------------------------------------------------ > > > *Suggestions for a Simpler Model* > > My preference is that the API for the most common use cases should be > more *declarative and functional*. > > 1. > > *Simplify the "Gather All" Pattern:* The primary "fan-out and > gather" use case could be captured in a simple, high-level > construct. An average user shouldn't need to learn the?wide API > surface of StructuredTaskScope + Joiner + the lifecycles. For example: > > Java > |// Ideal API for the 80% use case Robot robot = > Concurrently.call( () -> fetchArm(), () -> fetchLeg(), (arm, leg) > -> new Robot(arm, leg) ); | > We've been down the road of combinator or utility methods a number of times, and have decided not to propose that direction for this API. It's not too hard to what create a method that does what you want, e.g. ??? R callConcurrently(Callable task1, Callable task2, BiFunction combine) { ??????? try (var scope = StructuredTaskScope.open()) { ??????????? Supplier subtask1 = scope.fork(task1); ??????????? Supplier subtask2 = scope.fork(task2); ??????????? scope.join(); ??????????? return combine.apply(subtask1.get(), subtask2.get()); ??????? } ??? } (there's a more general form of the example presented in the JEP), > 1. > > *Separate Race Semantics into Composable Operations:* The "race" > pattern feels like a distinct use case that could be implemented > more naturally using composable, functional APIs like Stream > gatherers, rather than requiring a specialized API at all. For > example, if |mapConcurrent()| fully embraced structured > concurrency, guaranteeing fail-fast and happens-before, a > recoverable race could be written explicitly: > > Java > |// Pseudo-code for a recoverable race using a stream gatherer > T race(Collection> tasks, int maxConcurrency) { var > exceptions = new ConcurrentLinkedQueue(); return > tasks.stream() .gather(mapConcurrent(maxConcurrency, task -> { try > { return task.call(); } catch (RpcException e) { if > (isRecoverable(e)) { // Selectively recover exceptions.add(e); > return null; // Suppress and continue } throw new > RuntimeException(e); // Fail fast on non-recoverable } })) > .filter(Objects::nonNull) .findFirst() // Short-circuiting and > cancellation .orElseThrow(() -> new > AggregateException(exceptions)); } | > > While this is slightly more verbose than the JEP example, it's > familiar Stream semantics that people have already learned, and it > offers explicit control over which exceptions are recoverable > versus fatal. The boilerplate for exception aggregation could > easily be wrapped in a helper method. > There are many use cases. Joiner defines a small set of static factory for built-ins that we hope will cover most usages, equivalent to the built-ins defined by Gatherers. The anySuccessfulOrThrow (which is "race" in some Scala libraries) fits in well. We do want to bring mapConcurrent (or a successor) into the structured fold but don't have a good proposal at this time. > 1. > > *Reserve Complexity for Complex Cases:* The low-level > |StructuredTaskScope| and its policy mechanism are powerful tools. > However, they should be positioned as the "expert-level" API for > building custom frameworks. Or perhaps just keep them in the > traditional ExecutorService API. The everyday developer experience > should be centered around simpler, declarative constructs that > cover the most frequent needs. > STS is intended to usable by average developers. Implementing Joiner is more advanced/expert.? Early exploration did propose additions to ExecutorService, including a variant of inokveAll that short circuited when a task failed, but just hides everything about structured concurrency. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From yujige at gmail.com Sun Oct 12 21:56:18 2025 From: yujige at gmail.com (Jige Yu) Date: Sun, 12 Oct 2025 14:56:18 -0700 Subject: Feedback on Structured Concurrency (JEP 525, 6th Preview) In-Reply-To: References: Message-ID: On Sun, Oct 12, 2025 at 12:53?PM Alan Bateman wrote: > On 12/10/2025 06:32, Jige Yu wrote: > > Hi Project Loom. First and foremost, I want to express my gratitude for > the effort that has gone into structured concurrency. API design in this > space is notoriously difficult, and this feedback is offered with the > greatest respect for the team's work and in the spirit of collaborative > refinement. > > My perspective is that of a developer looking to use Structured > Concurrency for common, IO-intensive fan-out operations. My focus is to > replace everyday async callback hell, or reactive chains with something > simpler and more readable. > > It will lack depth in the highly specialized concurrent programming area. > And I acknowledge this viewpoint may bias my feedback. > > Just a general point on providing feedback: The feedback that we most > value is feedback from people that have tried a feature or API in earnest. > We regularly have people showing up here with alternative APIs proposals > but it's never clear if they have the same goals, whether they've tried the > feature, or have considered many use cases. This isn't a criticism of your > proposal, it's just not clear if this is after trying the feature or not. > Yeah. I've learned that feedbacks from tried, real earnest users would be more useful, which sadly I'm not. The exception handling part of it was enough for me to want to try something different and this is the angle I came in. I know my feedback is generally negative but they are honest. I did try to use mapConcurrent() and tried it out from the structured concurrency aspect. And I've then realized that it doesn't entirely have the two most important properties: fail-fast and happens-before. It does however provide two-way cancellation and task interruptions. I've also gotten my feet wet in trying to implement what I had proposed, making sure at least I know what I'm talking about, fwiw. > > ------------------------------ > > 1. > > *Stateful and Imperative API:* The API imposes quite some "don't do > this at time X" rules. Attempting to fork() after join() leads to a > runtime error; forgetting to call join() is another error; and the > imperative fork/join sequence is more cumbersome than a declarative > approach would be. None of these are unmanageable though. > > The API has 5 instance methods and isn't too hard to get wrong. Yes, it's > an exception at runtime if someone joins before forking, or attempts to > process the outcome before joining. With a few basic recipes/examples then > it should be possible for someone to get started quickly. The issues > dealing with cancellation and shutdown are difficult to get right and we > hope this API will help to avoid several of issues with a relatively simple > API. > > > > 1. > > *Challenging Exception Handling:* The exception handling model is > tricky: > - > > *Loss of Checked Exception Compile-Time Safety:* FailedException is > effectively an unchecked wrapper that erases checked exception information > at compile time. Migrating from sequential, structured code to concurrent > code now means losing valuable compiler guarantees. > - > > *No Help For Exception Handling: *For code that wants to catch and > handle these exceptions, it's the same story of using *instanceof* > on the getCause(), again, losing all compile-time safety that was available > in equivalent sequential code. > - > > *Burdensome InterruptedException Handling:* The requirement for the > caller to handle or propagate InterruptedException from join() will > add room for error as handling InterruptedException is easy to get wrong: > one can forget to call currentThread().interrupt(). Or, if the caller > decides to declare *throws* *InterruptedException*, the signature > propagation becomes viral. > - > > *Default Exception Swallowing:* The AnySuccessOrThrow policy *swallows all > exceptions* by default, including critical ones like > NullPointerException, IllegalArgumentException, or even an Error. > This makes it dangerously easy to mask bugs that should be highly visible. > There is no straightforward mechanism to inspect these suppressed > exceptions or fail on specific, unexpected types. > > We aren't happy with needing to wrap exceptions but it is no different to > other concurrent APIs, e.g. Future. Countless hours have been spent on > explorations to do better. All modelling of exceptions with type parameters > lead to cumbersome usage, e.g. a type parameter for the exception thrown by > subtasks and another type parameter for the exception thrown by join. If > there were union types for exceptions or other changes to the language then > we might do better. > I understand that. And I'm not proposing to add exception type parameters. Those aren't gonna work. I was hoping Java could add some help to make exception tunneling easier (I had some detailed clarification in my reply to Remi), But even failing that, 3 points are orthogonal to adding type parameters: 1. Should the callback be Callable or Supplier? With Callable (and with FailedException being unchecked), it's essentially a sneaky exception unchecker. Whereas Supplier would be more like Stream, still not going to make everyone happy, but it's at least honest: won't silently uncheck-ify exceptions. 2. Forcing callers to catch or handle InterruptedException is not helpful. mapConcurrent() on the other hand doesn't, which I believe is a better model. 3. anySuccessfulResultThrow() swallows runtime exceptions and errors. This to me seems like an anti-pattern. > On anySuccessfulOrThrow, then it's like invokeAny and similar combinators > in that it causes join to return a result from any subtasks or throw if all > subtasks fail. It would be feasible to develop a Joiner that returns > something like `record(Optional result, Map, Throwable> > exceptions)` where the map contains the subtasks that failed before the > successful subtask. That would be harder to use than the simpler built-in > and users always have the option of logging in the failed subtask. > > I know. But the thought that a standard JDK API would silently swallow *by default* still feels scary. > > > > 1. > > *Conflated API Semantics:* The StructuredTaskScope API unifies two > very different concurrency patterns?"gather all" (allSuccessfulOrThrow) > and "race to first success" (anySuccessfulResultOrThrow)?under a > single class but with different interaction models for the same method. > - > > In the *"gather all"* pattern (allSuccessfulOrThrow), join() > returns void. The callsite should use subtask.get() to retrieve > results. > - > > In the *"race"* pattern (anySuccessfulResultOrThrow), join() > returns the result (R) of the first successful subtask directly. > The developer should *not* call get() on individual subtasks. > Having the join()+subtask.get() method spec'ed conditionally (which > method to use and how depends on the actual policy) feels like a minor > violation of LSP and is a source of confusion. It may be an indication of > premature abstraction. > > join always returns something. For allSuccessfulOrThrow it returns a > stream of successful subtasks. > > I think your comment is really about cases where the subtasks return > results of the same type vs. other cases where subtasks return results of > different types. This is an area where we need feedback. To date, we've > been assuming that the more common case is subtasks that return results of > different types (arms and legs in your example). For these cases, it's more > useful to keep a reference to the subtask so that you don't have to cast > when handling the results. It may be that we don't have this right and the > common case is homogeneous subtasks, in which case the default Joiner > should be allSuccessfulOrThrow so you don't need to keep a reference to the > subtasks. > I guess my feedback was at a higher level than the details in the Joiner API. My question was: is the Joiner/STS API even the right API that pulls this weight? If the STS team only needed to make mapConcurrent() fully structured-concurrency, and it only needed to provide a simple, functional API, the API would be a lot simpler and all of these extra imperative concepts like subtasks, joiners, lifecycle callbacks etc. might not even need to exist. It's quite likely that the Loom team had already discussed and reached the conclusion that a functional API similar to what I had described, despite being simpler, would not be sufficient, and the extra weight in the current STS is worth it (for reasons X, Y and Z). If that's the case, then consider my questions dismissed. Otherwise, I just want to make sure the unpopular question (*is it worth it to build the imperative, complex API?*) is on the table. > > > > > 1. > > *Overly Complex Customization:* The StructuredTaskScope.Policy API, > while powerful, feels like a potential footgun. The powerful lifecycle > callback methods like onFork(), onComplete(), onTimeout() may lower the > barrier to creating intricate, framework-like abstractions that are > difficult to reason about and debug. > > Developing a Joiner for more advanced/expert developers. We have several > guidelines in the API docs, the more relevant here is that they aren't the > place for business logic, and should be designed to be as general purpose > as possible. > I guess I got my impression from recent online discussions that people can be keen on using these lifecycle callbacks to bake in business-specific needs. It's the thing with these generic libraries though: they can be used, and they can be abused. And imho "how can it avoid being abused" should also be a critical part of designing an API. > > > ------------------------------ > *Suggestions for a Simpler Model* > > My preference is that the API for the most common use cases should be more *declarative > and functional*. > > 1. > > *Simplify the "Gather All" Pattern:* The primary "fan-out and gather" > use case could be captured in a simple, high-level construct. An average > user shouldn't need to learn the wide API surface of StructuredTaskScope + > Joiner + the lifecycles. For example: > Java > > // Ideal API for the 80% use case > Robot robot = Concurrently.call( > () -> fetchArm(), > () -> fetchLeg(), > (arm, leg) -> new Robot(arm, leg) > ); > > > > We've been down the road of combinator or utility methods a number of > times, and have decided not to propose that direction for this API. It's > not too hard to what create a method that does what you want, e.g. > > R callConcurrently(Callable task1, Callable task2, > BiFunction combine) { > try (var scope = StructuredTaskScope.open()) { > Supplier subtask1 = scope.fork(task1); > Supplier subtask2 = scope.fork(task2); > scope.join(); > return combine.apply(subtask1.get(), subtask2.get()); > } > } > > (there's a more general form of the example presented in the JEP), > Yes. I understand it can be built on top of STS. But my point is to ask: *could it be that the simpler API is all that most people need?* There's immense power in the *default option* provided by the standard JDK. If STS is the default provided by Loom, I'm sure it'll be what majority of people use, even if technically one can build a simpler wrapper - it takes an extra dependency, or it takes extra work, and all the documents are about the default option, so in the end, the theoretical simpler alternative wrapper may not get a chance. But there are two potential downsides: 1. It changes the perception from SC being really easy in Java to something less punchy. The ease-of-use of an API is imho much more important than its raw power. 2. The overly powerful STS API, with its sharp edges (e.g. anySuccessfulOrThrow swallows exceptions) can be abused, generating code that's less maintainable in the long run. And by asking that question, I guess my daring proposal (out of my average-user naivety) is to decouple the two: - Provide a simple, functional API for the 90% users to enjoy SC in the simplest possible way. *Forget about power and max coverage in this phase*. - Take the meaty STS API as an "advanced, follow-up project" and evaluate the ROI, given 90% use cases already satisfied by the functional API. > > > 1. > > *Separate Race Semantics into Composable Operations:* The "race" > pattern feels like a distinct use case that could be implemented more > naturally using composable, functional APIs like Stream gatherers, rather > than requiring a specialized API at all. For example, if > mapConcurrent() fully embraced structured concurrency, guaranteeing > fail-fast and happens-before, a recoverable race could be written > explicitly: > Java > > // Pseudo-code for a recoverable race using a stream gatherer > T race(Collection> tasks, int maxConcurrency) { > var exceptions = new ConcurrentLinkedQueue(); > return tasks.stream() > .gather(mapConcurrent(maxConcurrency, task -> { > try { > return task.call(); > } catch (RpcException e) { > if (isRecoverable(e)) { // Selectively recover > exceptions.add(e); > return null; // Suppress and continue > } > throw new RuntimeException(e); // Fail fast on non-recoverable > } > })) > .filter(Objects::nonNull) > .findFirst() // Short-circuiting and cancellation > .orElseThrow(() -> new AggregateException(exceptions)); > } > > While this is slightly more verbose than the JEP example, it's > familiar Stream semantics that people have already learned, and it offers > explicit control over which exceptions are recoverable versus fatal. The > boilerplate for exception aggregation could easily be wrapped in a helper > method. > > > There are many use cases. Joiner defines a small set of static factory for > built-ins that we hope will cover most usages, equivalent to the built-ins > defined by Gatherers. The anySuccessfulOrThrow (which is "race" in some > Scala libraries) fits in well. > > We do want to bring mapConcurrent (or a successor) into the structured > fold but don't have a good proposal at this time. > > > > > > 1. > > *Reserve Complexity for Complex Cases:* The low-level > StructuredTaskScope and its policy mechanism are powerful tools. > However, they should be positioned as the "expert-level" API for building > custom frameworks. Or perhaps just keep them in the traditional > ExecutorService API. The everyday developer experience should be centered > around simpler, declarative constructs that cover the most frequent needs. > > STS is intended to usable by average developers. Implementing Joiner is > more advanced/expert. Early exploration did propose additions to > ExecutorService, including a variant of inokveAll that short circuited when > a task failed, but just hides everything about structured concurrency. > > -Alan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From petereastham at gmail.com Sun Oct 12 23:59:10 2025 From: petereastham at gmail.com (Peter Eastham) Date: Sun, 12 Oct 2025 17:59:10 -0600 Subject: Feedback on Structured Concurrency (JEP 525, 6th Preview) In-Reply-To: References: Message-ID: I'll toss my two cents in here as another perspective. I understand your point is that the API might be more complex than it needs to be, but I'm struggling to see how. It was brought up earlier, but I'll reiterate that the best feedback comes from real world usage *because* those use cases provide concrete examples of why a specific feature is (or is not!) needed. While conversations like this are useful, I think your best next step is to either create or find and contribute to some OSS Library that wraps STS. I'm unsure if Apache has one yet, but that's a historical location for wrappers around some sharp edges. You could also continue to iterate on your own personal use cases, the library approach just makes it easier to ensure you aren't being too biased towards your own usage. My perspective is that while STS does expose a somewhat complex API with some quirks, it's *near impossible* to achieve all the goals otherwise without complete isolation from the other concurrency models in Java. For example, without some way to populate non-inheritable ThreadLocals STS *wouldn't be usable* for most applications, as they (and more importantly the libraries they import) weren't designed with STS and ScopedValues in mind. Given that most developers that want to use STS within the next 5 years will be writing with or in existing codebases, that makes sense that any API around it has to be able to accomplish that. Your goal of making sure STS isn't more complex than it needs to be *is good*, I'm hoping my comments above help clarify how you can put your efforts to use for a better ROI. -Peter P.S Alan it might be useful for the Wiki to get some updates around the explored options and where they fell short. I know from my own experience that Wikis are not read as much as they should be, but I can see more comments around the API happening as excitement continues to grow. Just another 2 cents. On Sun, Oct 12, 2025 at 3:56?PM Jige Yu wrote: > > > On Sun, Oct 12, 2025 at 12:53?PM Alan Bateman > wrote: > >> On 12/10/2025 06:32, Jige Yu wrote: >> >> Hi Project Loom. First and foremost, I want to express my gratitude for >> the effort that has gone into structured concurrency. API design in this >> space is notoriously difficult, and this feedback is offered with the >> greatest respect for the team's work and in the spirit of collaborative >> refinement. >> >> My perspective is that of a developer looking to use Structured >> Concurrency for common, IO-intensive fan-out operations. My focus is to >> replace everyday async callback hell, or reactive chains with something >> simpler and more readable. >> >> It will lack depth in the highly specialized concurrent programming area. >> And I acknowledge this viewpoint may bias my feedback. >> >> Just a general point on providing feedback: The feedback that we most >> value is feedback from people that have tried a feature or API in earnest. >> We regularly have people showing up here with alternative APIs proposals >> but it's never clear if they have the same goals, whether they've tried the >> feature, or have considered many use cases. This isn't a criticism of your >> proposal, it's just not clear if this is after trying the feature or not. >> > > Yeah. I've learned that feedbacks from tried, real earnest users would be > more useful, which sadly I'm not. > > The exception handling part of it was enough for me to want to try > something different and this is the angle I came in. I know my feedback is > generally negative but they are honest. > > I did try to use mapConcurrent() and tried it out from the structured > concurrency aspect. And I've then realized that it doesn't entirely have > the two most important properties: fail-fast and happens-before. It does > however provide two-way cancellation and task interruptions. > > I've also gotten my feet wet in trying to implement what I had proposed, > making sure at least I know what I'm talking about, fwiw. > >> >> ------------------------------ >> >> 1. >> >> *Stateful and Imperative API:* The API imposes quite some "don't do >> this at time X" rules. Attempting to fork() after join() leads to a >> runtime error; forgetting to call join() is another error; and the >> imperative fork/join sequence is more cumbersome than a declarative >> approach would be. None of these are unmanageable though. >> >> The API has 5 instance methods and isn't too hard to get wrong. Yes, >> it's an exception at runtime if someone joins before forking, or attempts >> to process the outcome before joining. With a few basic recipes/examples >> then it should be possible for someone to get started quickly. The issues >> dealing with cancellation and shutdown are difficult to get right and we >> hope this API will help to avoid several of issues with a relatively simple >> API. >> >> >> >> 1. >> >> *Challenging Exception Handling:* The exception handling model is >> tricky: >> - >> >> *Loss of Checked Exception Compile-Time Safety:* FailedException >> is effectively an unchecked wrapper that erases checked exception >> information at compile time. Migrating from sequential, structured code to >> concurrent code now means losing valuable compiler guarantees. >> - >> >> *No Help For Exception Handling: *For code that wants to catch and >> handle these exceptions, it's the same story of using *instanceof* >> on the getCause(), again, losing all compile-time safety that was available >> in equivalent sequential code. >> - >> >> *Burdensome InterruptedException Handling:* The requirement for >> the caller to handle or propagate InterruptedException from join() will >> add room for error as handling InterruptedException is easy to get wrong: >> one can forget to call currentThread().interrupt(). Or, if the caller >> decides to declare *throws* *InterruptedException*, the signature >> propagation becomes viral. >> - >> >> *Default Exception Swallowing:* The AnySuccessOrThrow policy *swallows all >> exceptions* by default, including critical ones like >> NullPointerException, IllegalArgumentException, or even an Error. >> This makes it dangerously easy to mask bugs that should be highly visible. >> There is no straightforward mechanism to inspect these suppressed >> exceptions or fail on specific, unexpected types. >> >> We aren't happy with needing to wrap exceptions but it is no different to >> other concurrent APIs, e.g. Future. Countless hours have been spent on >> explorations to do better. All modelling of exceptions with type parameters >> lead to cumbersome usage, e.g. a type parameter for the exception thrown by >> subtasks and another type parameter for the exception thrown by join. If >> there were union types for exceptions or other changes to the language then >> we might do better. >> > > I understand that. And I'm not proposing to add exception type parameters. > Those aren't gonna work. > > I was hoping Java could add some help to make exception tunneling easier > (I had some detailed clarification in my reply to Remi), > > But even failing that, 3 points are orthogonal to adding type parameters: > > 1. Should the callback be Callable or Supplier? With Callable (and > with FailedException being unchecked), it's essentially a sneaky exception > unchecker. Whereas Supplier would be more like Stream, still not going to > make everyone happy, but it's at least honest: won't silently uncheck-ify > exceptions. > 2. Forcing callers to catch or handle InterruptedException is not > helpful. mapConcurrent() on the other hand doesn't, which I believe is a > better model. > 3. anySuccessfulResultThrow() swallows runtime exceptions and errors. > This to me seems like an anti-pattern. > > >> On anySuccessfulOrThrow, then it's like invokeAny and similar combinators >> in that it causes join to return a result from any subtasks or throw if all >> subtasks fail. It would be feasible to develop a Joiner that returns >> something like `record(Optional result, Map, Throwable> >> exceptions)` where the map contains the subtasks that failed before the >> successful subtask. That would be harder to use than the simpler built-in >> and users always have the option of logging in the failed subtask. >> >> I know. But the thought that a standard JDK API would silently swallow *by > default* still feels scary. > >> >> >> >> 1. >> >> *Conflated API Semantics:* The StructuredTaskScope API unifies two >> very different concurrency patterns?"gather all" (allSuccessfulOrThrow) >> and "race to first success" (anySuccessfulResultOrThrow)?under a >> single class but with different interaction models for the same method. >> - >> >> In the *"gather all"* pattern (allSuccessfulOrThrow), join() >> returns void. The callsite should use subtask.get() to retrieve >> results. >> - >> >> In the *"race"* pattern (anySuccessfulResultOrThrow), join() >> returns the result (R) of the first successful subtask directly. >> The developer should *not* call get() on individual subtasks. >> Having the join()+subtask.get() method spec'ed conditionally >> (which method to use and how depends on the actual policy) feels like a >> minor violation of LSP and is a source of confusion. It may be an >> indication of premature abstraction. >> >> join always returns something. For allSuccessfulOrThrow it returns a >> stream of successful subtasks. >> >> I think your comment is really about cases where the subtasks return >> results of the same type vs. other cases where subtasks return results of >> different types. This is an area where we need feedback. To date, we've >> been assuming that the more common case is subtasks that return results of >> different types (arms and legs in your example). For these cases, it's more >> useful to keep a reference to the subtask so that you don't have to cast >> when handling the results. It may be that we don't have this right and the >> common case is homogeneous subtasks, in which case the default Joiner >> should be allSuccessfulOrThrow so you don't need to keep a reference to the >> subtasks. >> > > I guess my feedback was at a higher level than the details in the Joiner > API. My question was: is the Joiner/STS API even the right API that pulls > this weight? If the STS team only needed to make mapConcurrent() fully > structured-concurrency, and it only needed to provide a simple, functional > API, the API would be a lot simpler and all of these extra imperative > concepts like subtasks, joiners, lifecycle callbacks etc. might not even > need to exist. > > It's quite likely that the Loom team had already discussed and reached the > conclusion that a functional API similar to what I had described, despite > being simpler, would not be sufficient, and the extra weight in the current > STS is worth it (for reasons X, Y and Z). If that's the case, then > consider my questions dismissed. > > Otherwise, I just want to make sure the unpopular question (*is it worth > it to build the imperative, complex API?*) is on the table. > >> >> >> >> >> 1. >> >> *Overly Complex Customization:* The StructuredTaskScope.Policy API, >> while powerful, feels like a potential footgun. The powerful lifecycle >> callback methods like onFork(), onComplete(), onTimeout() may lower the >> barrier to creating intricate, framework-like abstractions that are >> difficult to reason about and debug. >> >> Developing a Joiner for more advanced/expert developers. We have several >> guidelines in the API docs, the more relevant here is that they aren't the >> place for business logic, and should be designed to be as general purpose >> as possible. >> > > I guess I got my impression from recent online discussions that people > can be keen on using these lifecycle callbacks to bake in business-specific > needs. > > It's the thing with these generic libraries though: they can be used, and > they can be abused. And imho "how can it avoid being abused" should also be > a critical part of designing an API. > >> >> >> ------------------------------ >> *Suggestions for a Simpler Model* >> >> My preference is that the API for the most common use cases should be >> more *declarative and functional*. >> >> 1. >> >> *Simplify the "Gather All" Pattern:* The primary "fan-out and gather" >> use case could be captured in a simple, high-level construct. An average >> user shouldn't need to learn the wide API surface of StructuredTaskScope + >> Joiner + the lifecycles. For example: >> Java >> >> // Ideal API for the 80% use case >> Robot robot = Concurrently.call( >> () -> fetchArm(), >> () -> fetchLeg(), >> (arm, leg) -> new Robot(arm, leg) >> ); >> >> >> >> We've been down the road of combinator or utility methods a number of >> times, and have decided not to propose that direction for this API. It's >> not too hard to what create a method that does what you want, e.g. >> >> R callConcurrently(Callable task1, Callable task2, >> BiFunction combine) { >> try (var scope = StructuredTaskScope.open()) { >> Supplier subtask1 = scope.fork(task1); >> Supplier subtask2 = scope.fork(task2); >> scope.join(); >> return combine.apply(subtask1.get(), subtask2.get()); >> } >> } >> >> (there's a more general form of the example presented in the JEP), >> > > Yes. I understand it can be built on top of STS. But my point is to ask: *could > it be that the simpler API is all that most people need?* > > There's immense power in the *default option* provided by the standard > JDK. If STS is the default provided by Loom, I'm sure it'll be what > majority of people use, even if technically one can build a simpler wrapper > - it takes an extra dependency, or it takes extra work, and all the > documents are about the default option, so in the end, the theoretical > simpler alternative wrapper may not get a chance. > > But there are two potential downsides: > > 1. It changes the perception from SC being really easy in Java to > something less punchy. The ease-of-use of an API is imho much more > important than its raw power. > 2. The overly powerful STS API, with its sharp edges (e.g. > anySuccessfulOrThrow swallows exceptions) can be abused, generating code > that's less maintainable in the long run. > > And by asking that question, I guess my daring proposal (out of my > average-user naivety) is to decouple the two: > > - Provide a simple, functional API for the 90% users to enjoy SC in > the simplest possible way. *Forget about power and max coverage in > this phase*. > - Take the meaty STS API as an "advanced, follow-up project" and > evaluate the ROI, given 90% use cases already satisfied by the functional > API. > > >> >> >> 1. >> >> *Separate Race Semantics into Composable Operations:* The "race" >> pattern feels like a distinct use case that could be implemented more >> naturally using composable, functional APIs like Stream gatherers, rather >> than requiring a specialized API at all. For example, if >> mapConcurrent() fully embraced structured concurrency, guaranteeing >> fail-fast and happens-before, a recoverable race could be written >> explicitly: >> Java >> >> // Pseudo-code for a recoverable race using a stream gatherer >> T race(Collection> tasks, int maxConcurrency) { >> var exceptions = new ConcurrentLinkedQueue(); >> return tasks.stream() >> .gather(mapConcurrent(maxConcurrency, task -> { >> try { >> return task.call(); >> } catch (RpcException e) { >> if (isRecoverable(e)) { // Selectively recover >> exceptions.add(e); >> return null; // Suppress and continue >> } >> throw new RuntimeException(e); // Fail fast on non-recoverable >> } >> })) >> .filter(Objects::nonNull) >> .findFirst() // Short-circuiting and cancellation >> .orElseThrow(() -> new AggregateException(exceptions)); >> } >> >> While this is slightly more verbose than the JEP example, it's >> familiar Stream semantics that people have already learned, and it offers >> explicit control over which exceptions are recoverable versus fatal. The >> boilerplate for exception aggregation could easily be wrapped in a helper >> method. >> >> >> There are many use cases. Joiner defines a small set of static factory >> for built-ins that we hope will cover most usages, equivalent to the >> built-ins defined by Gatherers. The anySuccessfulOrThrow (which is "race" >> in some Scala libraries) fits in well. >> >> We do want to bring mapConcurrent (or a successor) into the structured >> fold but don't have a good proposal at this time. >> >> >> >> >> >> 1. >> >> *Reserve Complexity for Complex Cases:* The low-level >> StructuredTaskScope and its policy mechanism are powerful tools. >> However, they should be positioned as the "expert-level" API for building >> custom frameworks. Or perhaps just keep them in the traditional >> ExecutorService API. The everyday developer experience should be centered >> around simpler, declarative constructs that cover the most frequent needs. >> >> STS is intended to usable by average developers. Implementing Joiner is >> more advanced/expert. Early exploration did propose additions to >> ExecutorService, including a variant of inokveAll that short circuited when >> a task failed, but just hides everything about structured concurrency. >> >> -Alan >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at me.com Mon Oct 13 00:09:18 2025 From: robaho at me.com (Robert Engels) Date: Sun, 12 Oct 2025 19:09:18 -0500 Subject: Feedback on Structured Concurrency (JEP 525, 6th Preview) In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From yujige at gmail.com Mon Oct 13 01:05:53 2025 From: yujige at gmail.com (Jige Yu) Date: Sun, 12 Oct 2025 18:05:53 -0700 Subject: Feedback on Structured Concurrency (JEP 525, 6th Preview) In-Reply-To: References: Message-ID: Yeah, I understand by not really having used the STS api seriously, I must have limited my understanding of it in some ways. And I certainly don't claim that I know all its power and potential. Thus I'm sending the email to validate my overly-simplistic observation: a much simpler functional API would have sufficed. If I were to propose a new functionality, then I totally should have tried using the STS API and see why it couldn't solve my need. But here I'm not having a new use case or asking for a new feature. I'm simply saying that for all the use cases I can visualize, I only need a very limited subset of the STS API. Yes, it does solve my needs (if we ignore the exception handling sharp edges and the ergonomics). It's proved by you already, because what I want - the functional API, can be implemented as a functionality-reducing wrapper of the current STS API. I think my type of "yeah, but my use case is so simple, I don't need this powerful tool" feedback, raising a use case that exceeds the capability of the functional API, yet is still considered common, would have been convincing? That's what most API designs use, to gate every complexity, every feature with two questions: 1. What does it really solve that existing, simpler API can't solve well? 2. Is this use case compelling enough to pull the weight? Thanks for the pointer to the wiki, Peter. I'm browsing it now. But if anyone has a pointer to the past discussion that's related to "the simpler functional API isn't sufficient", I'll appreciate it! On Sun, Oct 12, 2025 at 4:59?PM Peter Eastham wrote: > I'll toss my two cents in here as another perspective. > > I understand your point is that the API might be more complex than it > needs to be, but I'm struggling to see how. It was brought up earlier, but > I'll reiterate that the best feedback comes from real world usage > *because* those use cases provide concrete examples of why a specific > feature is (or is not!) needed. While conversations like this are useful, I > think your best next step is to either create or find and contribute to > some OSS Library that wraps STS. I'm unsure if Apache has one yet, but > that's a historical location for wrappers around some sharp edges. You > could also continue to iterate on your own personal use cases, the library > approach just makes it easier to ensure you aren't being too biased towards > your own usage. > > My perspective is that while STS does expose a somewhat complex API with > some quirks, it's *near impossible* to achieve all the goals otherwise > without complete isolation from the other concurrency models in Java. For > example, without some way to populate non-inheritable ThreadLocals STS *wouldn't > be usable* for most applications, as they (and more importantly the > libraries they import) weren't designed with STS and ScopedValues in mind. > Given that most developers that want to use STS within the next 5 years > will be writing with or in existing codebases, that makes sense that any > API around it has to be able to accomplish that. > > Your goal of making sure STS isn't more complex than it needs to be *is > good*, I'm hoping my comments above help clarify how you can put your > efforts to use for a better ROI. > -Peter > > P.S > Alan it might be useful for the Wiki > to get some updates around the > explored options and where they fell short. I know from my own experience > that Wikis are not read as much as they should be, but I can see more > comments around the API happening as excitement continues to grow. Just > another 2 cents. > > On Sun, Oct 12, 2025 at 3:56?PM Jige Yu wrote: > >> >> >> On Sun, Oct 12, 2025 at 12:53?PM Alan Bateman >> wrote: >> >>> On 12/10/2025 06:32, Jige Yu wrote: >>> >>> Hi Project Loom. First and foremost, I want to express my gratitude for >>> the effort that has gone into structured concurrency. API design in this >>> space is notoriously difficult, and this feedback is offered with the >>> greatest respect for the team's work and in the spirit of collaborative >>> refinement. >>> >>> My perspective is that of a developer looking to use Structured >>> Concurrency for common, IO-intensive fan-out operations. My focus is to >>> replace everyday async callback hell, or reactive chains with something >>> simpler and more readable. >>> >>> It will lack depth in the highly specialized concurrent programming >>> area. And I acknowledge this viewpoint may bias my feedback. >>> >>> Just a general point on providing feedback: The feedback that we most >>> value is feedback from people that have tried a feature or API in earnest. >>> We regularly have people showing up here with alternative APIs proposals >>> but it's never clear if they have the same goals, whether they've tried the >>> feature, or have considered many use cases. This isn't a criticism of your >>> proposal, it's just not clear if this is after trying the feature or not. >>> >> >> Yeah. I've learned that feedbacks from tried, real earnest users would >> be more useful, which sadly I'm not. >> >> The exception handling part of it was enough for me to want to try >> something different and this is the angle I came in. I know my feedback is >> generally negative but they are honest. >> >> I did try to use mapConcurrent() and tried it out from the structured >> concurrency aspect. And I've then realized that it doesn't entirely have >> the two most important properties: fail-fast and happens-before. It does >> however provide two-way cancellation and task interruptions. >> >> I've also gotten my feet wet in trying to implement what I had proposed, >> making sure at least I know what I'm talking about, fwiw. >> >>> >>> ------------------------------ >>> >>> 1. >>> >>> *Stateful and Imperative API:* The API imposes quite some "don't do >>> this at time X" rules. Attempting to fork() after join() leads to a >>> runtime error; forgetting to call join() is another error; and the >>> imperative fork/join sequence is more cumbersome than a declarative >>> approach would be. None of these are unmanageable though. >>> >>> The API has 5 instance methods and isn't too hard to get wrong. Yes, >>> it's an exception at runtime if someone joins before forking, or attempts >>> to process the outcome before joining. With a few basic recipes/examples >>> then it should be possible for someone to get started quickly. The issues >>> dealing with cancellation and shutdown are difficult to get right and we >>> hope this API will help to avoid several of issues with a relatively simple >>> API. >>> >>> >>> >>> 1. >>> >>> *Challenging Exception Handling:* The exception handling model is >>> tricky: >>> - >>> >>> *Loss of Checked Exception Compile-Time Safety:* FailedException >>> is effectively an unchecked wrapper that erases checked exception >>> information at compile time. Migrating from sequential, structured code to >>> concurrent code now means losing valuable compiler guarantees. >>> - >>> >>> *No Help For Exception Handling: *For code that wants to catch >>> and handle these exceptions, it's the same story of using >>> *instanceof* on the getCause(), again, losing all compile-time >>> safety that was available in equivalent sequential code. >>> - >>> >>> *Burdensome InterruptedException Handling:* The requirement for >>> the caller to handle or propagate InterruptedException from join() will >>> add room for error as handling InterruptedException is easy to get wrong: >>> one can forget to call currentThread().interrupt(). Or, if the caller >>> decides to declare *throws* *InterruptedException*, the signature >>> propagation becomes viral. >>> - >>> >>> *Default Exception Swallowing:* The AnySuccessOrThrow policy *swallows all >>> exceptions* by default, including critical ones like >>> NullPointerException, IllegalArgumentException, or even an Error. >>> This makes it dangerously easy to mask bugs that should be highly visible. >>> There is no straightforward mechanism to inspect these suppressed >>> exceptions or fail on specific, unexpected types. >>> >>> We aren't happy with needing to wrap exceptions but it is no different >>> to other concurrent APIs, e.g. Future. Countless hours have been spent on >>> explorations to do better. All modelling of exceptions with type parameters >>> lead to cumbersome usage, e.g. a type parameter for the exception thrown by >>> subtasks and another type parameter for the exception thrown by join. If >>> there were union types for exceptions or other changes to the language then >>> we might do better. >>> >> >> I understand that. And I'm not proposing to add exception type >> parameters. Those aren't gonna work. >> >> I was hoping Java could add some help to make exception tunneling easier >> (I had some detailed clarification in my reply to Remi), >> >> But even failing that, 3 points are orthogonal to adding type parameters: >> >> 1. Should the callback be Callable or Supplier? With Callable (and >> with FailedException being unchecked), it's essentially a sneaky exception >> unchecker. Whereas Supplier would be more like Stream, still not going to >> make everyone happy, but it's at least honest: won't silently uncheck-ify >> exceptions. >> 2. Forcing callers to catch or handle InterruptedException is not >> helpful. mapConcurrent() on the other hand doesn't, which I believe is a >> better model. >> 3. anySuccessfulResultThrow() swallows runtime exceptions and errors. >> This to me seems like an anti-pattern. >> >> >>> On anySuccessfulOrThrow, then it's like invokeAny and similar >>> combinators in that it causes join to return a result from any subtasks or >>> throw if all subtasks fail. It would be feasible to develop a Joiner that >>> returns something like `record(Optional result, Map, >>> Throwable> exceptions)` where the map contains the subtasks that failed >>> before the successful subtask. That would be harder to use than the simpler >>> built-in and users always have the option of logging in the failed subtask. >>> >>> I know. But the thought that a standard JDK API would silently swallow *by >> default* still feels scary. >> >>> >>> >>> >>> 1. >>> >>> *Conflated API Semantics:* The StructuredTaskScope API unifies two >>> very different concurrency patterns?"gather all" ( >>> allSuccessfulOrThrow) and "race to first success" ( >>> anySuccessfulResultOrThrow)?under a single class but with different >>> interaction models for the same method. >>> - >>> >>> In the *"gather all"* pattern (allSuccessfulOrThrow), join() >>> returns void. The callsite should use subtask.get() to retrieve >>> results. >>> - >>> >>> In the *"race"* pattern (anySuccessfulResultOrThrow), join() >>> returns the result (R) of the first successful subtask directly. >>> The developer should *not* call get() on individual subtasks. >>> Having the join()+subtask.get() method spec'ed conditionally >>> (which method to use and how depends on the actual policy) feels like a >>> minor violation of LSP and is a source of confusion. It may be an >>> indication of premature abstraction. >>> >>> join always returns something. For allSuccessfulOrThrow it returns a >>> stream of successful subtasks. >>> >>> I think your comment is really about cases where the subtasks return >>> results of the same type vs. other cases where subtasks return results of >>> different types. This is an area where we need feedback. To date, we've >>> been assuming that the more common case is subtasks that return results of >>> different types (arms and legs in your example). For these cases, it's more >>> useful to keep a reference to the subtask so that you don't have to cast >>> when handling the results. It may be that we don't have this right and the >>> common case is homogeneous subtasks, in which case the default Joiner >>> should be allSuccessfulOrThrow so you don't need to keep a reference to the >>> subtasks. >>> >> >> I guess my feedback was at a higher level than the details in the Joiner >> API. My question was: is the Joiner/STS API even the right API that pulls >> this weight? If the STS team only needed to make mapConcurrent() fully >> structured-concurrency, and it only needed to provide a simple, functional >> API, the API would be a lot simpler and all of these extra imperative >> concepts like subtasks, joiners, lifecycle callbacks etc. might not even >> need to exist. >> >> It's quite likely that the Loom team had already discussed and reached >> the conclusion that a functional API similar to what I had described, >> despite being simpler, would not be sufficient, and the extra weight in the >> current STS is worth it (for reasons X, Y and Z). If that's the case, then >> consider my questions dismissed. >> >> Otherwise, I just want to make sure the unpopular question (*is it worth >> it to build the imperative, complex API?*) is on the table. >> >>> >>> >>> >>> >>> 1. >>> >>> *Overly Complex Customization:* The StructuredTaskScope.Policy API, >>> while powerful, feels like a potential footgun. The powerful lifecycle >>> callback methods like onFork(), onComplete(), onTimeout() may lower the >>> barrier to creating intricate, framework-like abstractions that are >>> difficult to reason about and debug. >>> >>> Developing a Joiner for more advanced/expert developers. We have several >>> guidelines in the API docs, the more relevant here is that they aren't the >>> place for business logic, and should be designed to be as general purpose >>> as possible. >>> >> >> I guess I got my impression from recent online discussions that people >> can be keen on using these lifecycle callbacks to bake in business-specific >> needs. >> >> It's the thing with these generic libraries though: they can be used, and >> they can be abused. And imho "how can it avoid being abused" should also be >> a critical part of designing an API. >> >>> >>> >>> ------------------------------ >>> *Suggestions for a Simpler Model* >>> >>> My preference is that the API for the most common use cases should be >>> more *declarative and functional*. >>> >>> 1. >>> >>> *Simplify the "Gather All" Pattern:* The primary "fan-out and >>> gather" use case could be captured in a simple, high-level construct. An >>> average user shouldn't need to learn the wide API surface of >>> StructuredTaskScope + Joiner + the lifecycles. For example: >>> Java >>> >>> // Ideal API for the 80% use case >>> Robot robot = Concurrently.call( >>> () -> fetchArm(), >>> () -> fetchLeg(), >>> (arm, leg) -> new Robot(arm, leg) >>> ); >>> >>> >>> >>> We've been down the road of combinator or utility methods a number of >>> times, and have decided not to propose that direction for this API. It's >>> not too hard to what create a method that does what you want, e.g. >>> >>> R callConcurrently(Callable task1, Callable task2, >>> BiFunction combine) { >>> try (var scope = StructuredTaskScope.open()) { >>> Supplier subtask1 = scope.fork(task1); >>> Supplier subtask2 = scope.fork(task2); >>> scope.join(); >>> return combine.apply(subtask1.get(), subtask2.get()); >>> } >>> } >>> >>> (there's a more general form of the example presented in the JEP), >>> >> >> Yes. I understand it can be built on top of STS. But my point is to ask: *could >> it be that the simpler API is all that most people need?* >> >> There's immense power in the *default option* provided by the standard >> JDK. If STS is the default provided by Loom, I'm sure it'll be what >> majority of people use, even if technically one can build a simpler wrapper >> - it takes an extra dependency, or it takes extra work, and all the >> documents are about the default option, so in the end, the theoretical >> simpler alternative wrapper may not get a chance. >> >> But there are two potential downsides: >> >> 1. It changes the perception from SC being really easy in Java to >> something less punchy. The ease-of-use of an API is imho much more >> important than its raw power. >> 2. The overly powerful STS API, with its sharp edges (e.g. >> anySuccessfulOrThrow swallows exceptions) can be abused, generating code >> that's less maintainable in the long run. >> >> And by asking that question, I guess my daring proposal (out of my >> average-user naivety) is to decouple the two: >> >> - Provide a simple, functional API for the 90% users to enjoy SC in >> the simplest possible way. *Forget about power and max coverage in >> this phase*. >> - Take the meaty STS API as an "advanced, follow-up project" and >> evaluate the ROI, given 90% use cases already satisfied by the functional >> API. >> >> >>> >>> >>> 1. >>> >>> *Separate Race Semantics into Composable Operations:* The "race" >>> pattern feels like a distinct use case that could be implemented more >>> naturally using composable, functional APIs like Stream gatherers, rather >>> than requiring a specialized API at all. For example, if >>> mapConcurrent() fully embraced structured concurrency, guaranteeing >>> fail-fast and happens-before, a recoverable race could be written >>> explicitly: >>> Java >>> >>> // Pseudo-code for a recoverable race using a stream gatherer >>> T race(Collection> tasks, int maxConcurrency) { >>> var exceptions = new ConcurrentLinkedQueue(); >>> return tasks.stream() >>> .gather(mapConcurrent(maxConcurrency, task -> { >>> try { >>> return task.call(); >>> } catch (RpcException e) { >>> if (isRecoverable(e)) { // Selectively recover >>> exceptions.add(e); >>> return null; // Suppress and continue >>> } >>> throw new RuntimeException(e); // Fail fast on non-recoverable >>> } >>> })) >>> .filter(Objects::nonNull) >>> .findFirst() // Short-circuiting and cancellation >>> .orElseThrow(() -> new AggregateException(exceptions)); >>> } >>> >>> While this is slightly more verbose than the JEP example, it's >>> familiar Stream semantics that people have already learned, and it offers >>> explicit control over which exceptions are recoverable versus fatal. The >>> boilerplate for exception aggregation could easily be wrapped in a helper >>> method. >>> >>> >>> There are many use cases. Joiner defines a small set of static factory >>> for built-ins that we hope will cover most usages, equivalent to the >>> built-ins defined by Gatherers. The anySuccessfulOrThrow (which is "race" >>> in some Scala libraries) fits in well. >>> >>> We do want to bring mapConcurrent (or a successor) into the structured >>> fold but don't have a good proposal at this time. >>> >>> >>> >>> >>> >>> 1. >>> >>> *Reserve Complexity for Complex Cases:* The low-level >>> StructuredTaskScope and its policy mechanism are powerful tools. >>> However, they should be positioned as the "expert-level" API for building >>> custom frameworks. Or perhaps just keep them in the traditional >>> ExecutorService API. The everyday developer experience should be centered >>> around simpler, declarative constructs that cover the most frequent needs. >>> >>> STS is intended to usable by average developers. Implementing Joiner is >>> more advanced/expert. Early exploration did propose additions to >>> ExecutorService, including a variant of inokveAll that short circuited when >>> a task failed, but just hides everything about structured concurrency. >>> >>> -Alan >>> >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From petereastham at gmail.com Mon Oct 13 01:47:17 2025 From: petereastham at gmail.com (Peter Eastham) Date: Sun, 12 Oct 2025 19:47:17 -0600 Subject: Feedback on Structured Concurrency (JEP 525, 6th Preview) In-Reply-To: References: Message-ID: > I think my type of "yeah, but my use case is so simple, I don't need this powerful tool" feedback, raising a use case that exceeds the capability of the functional API, yet is still considered common, would have been convincing? There are always going to be sharp edges and missing features to any API. Mentioning them is useful, the real world examples help to put the context around *how bad* those aspects are. Since we have a mature preview API, it enables people to provide more than thoughts. If we're going to focus on my comment, "I think your best next step is to either create or find and contribute to some OSS Library that wraps STS", I'll call out that the important part was "next step". I'm sorry if this came across as "Don't comment without a real world example". -Peter On Sun, Oct 12, 2025 at 7:06?PM Jige Yu wrote: > Yeah, I understand by not really having used the STS api seriously, I must > have limited my understanding of it in some ways. > > And I certainly don't claim that I know all its power and potential. Thus > I'm sending the email to validate my overly-simplistic observation: a much > simpler functional API would have sufficed. > > If I were to propose a new functionality, then I totally should have tried > using the STS API and see why it couldn't solve my need. > > But here I'm not having a new use case or asking for a new feature. > > I'm simply saying that for all the use cases I can visualize, I only need > a very limited subset of the STS API. > > Yes, it does solve my needs (if we ignore the exception handling sharp > edges and the ergonomics). It's proved by you already, because what I want > - the functional API, can be implemented as a functionality-reducing > wrapper of the current STS API. > > I think my type of "yeah, but my use case is so simple, I don't need this > powerful tool" feedback, raising a use case that exceeds the capability of > the functional API, yet is still considered common, would have been > convincing? > > That's what most API designs use, to gate every complexity, every feature > with two questions: > > 1. What does it really solve that existing, simpler API can't solve > well? > 2. Is this use case compelling enough to pull the weight? > > > Thanks for the pointer to the wiki, Peter. I'm browsing it now. But if > anyone has a pointer to the past discussion that's related to "the simpler > functional API isn't sufficient", I'll appreciate it! > > > On Sun, Oct 12, 2025 at 4:59?PM Peter Eastham > wrote: > >> I'll toss my two cents in here as another perspective. >> >> I understand your point is that the API might be more complex than it >> needs to be, but I'm struggling to see how. It was brought up earlier, but >> I'll reiterate that the best feedback comes from real world usage >> *because* those use cases provide concrete examples of why a specific >> feature is (or is not!) needed. While conversations like this are useful, I >> think your best next step is to either create or find and contribute to >> some OSS Library that wraps STS. I'm unsure if Apache has one yet, but >> that's a historical location for wrappers around some sharp edges. You >> could also continue to iterate on your own personal use cases, the library >> approach just makes it easier to ensure you aren't being too biased towards >> your own usage. >> >> My perspective is that while STS does expose a somewhat complex API with >> some quirks, it's *near impossible* to achieve all the goals otherwise >> without complete isolation from the other concurrency models in Java. For >> example, without some way to populate non-inheritable ThreadLocals STS *wouldn't >> be usable* for most applications, as they (and more importantly the >> libraries they import) weren't designed with STS and ScopedValues in mind. >> Given that most developers that want to use STS within the next 5 years >> will be writing with or in existing codebases, that makes sense that any >> API around it has to be able to accomplish that. >> >> Your goal of making sure STS isn't more complex than it needs to be *is >> good*, I'm hoping my comments above help clarify how you can put your >> efforts to use for a better ROI. >> -Peter >> >> P.S >> Alan it might be useful for the Wiki >> to get some updates around the >> explored options and where they fell short. I know from my own experience >> that Wikis are not read as much as they should be, but I can see more >> comments around the API happening as excitement continues to grow. Just >> another 2 cents. >> >> On Sun, Oct 12, 2025 at 3:56?PM Jige Yu wrote: >> >>> >>> >>> On Sun, Oct 12, 2025 at 12:53?PM Alan Bateman >>> wrote: >>> >>>> On 12/10/2025 06:32, Jige Yu wrote: >>>> >>>> Hi Project Loom. First and foremost, I want to express my gratitude >>>> for the effort that has gone into structured concurrency. API design in >>>> this space is notoriously difficult, and this feedback is offered with the >>>> greatest respect for the team's work and in the spirit of collaborative >>>> refinement. >>>> >>>> My perspective is that of a developer looking to use Structured >>>> Concurrency for common, IO-intensive fan-out operations. My focus is to >>>> replace everyday async callback hell, or reactive chains with >>>> something simpler and more readable. >>>> >>>> It will lack depth in the highly specialized concurrent programming >>>> area. And I acknowledge this viewpoint may bias my feedback. >>>> >>>> Just a general point on providing feedback: The feedback that we most >>>> value is feedback from people that have tried a feature or API in earnest. >>>> We regularly have people showing up here with alternative APIs proposals >>>> but it's never clear if they have the same goals, whether they've tried the >>>> feature, or have considered many use cases. This isn't a criticism of your >>>> proposal, it's just not clear if this is after trying the feature or not. >>>> >>> >>> Yeah. I've learned that feedbacks from tried, real earnest users would >>> be more useful, which sadly I'm not. >>> >>> The exception handling part of it was enough for me to want to try >>> something different and this is the angle I came in. I know my feedback is >>> generally negative but they are honest. >>> >>> I did try to use mapConcurrent() and tried it out from the structured >>> concurrency aspect. And I've then realized that it doesn't entirely have >>> the two most important properties: fail-fast and happens-before. It does >>> however provide two-way cancellation and task interruptions. >>> >>> I've also gotten my feet wet in trying to implement what I had proposed, >>> making sure at least I know what I'm talking about, fwiw. >>> >>>> >>>> ------------------------------ >>>> >>>> 1. >>>> >>>> *Stateful and Imperative API:* The API imposes quite some "don't do >>>> this at time X" rules. Attempting to fork() after join() leads to a >>>> runtime error; forgetting to call join() is another error; and the >>>> imperative fork/join sequence is more cumbersome than a declarative >>>> approach would be. None of these are unmanageable though. >>>> >>>> The API has 5 instance methods and isn't too hard to get wrong. Yes, >>>> it's an exception at runtime if someone joins before forking, or attempts >>>> to process the outcome before joining. With a few basic recipes/examples >>>> then it should be possible for someone to get started quickly. The issues >>>> dealing with cancellation and shutdown are difficult to get right and we >>>> hope this API will help to avoid several of issues with a relatively simple >>>> API. >>>> >>>> >>>> >>>> 1. >>>> >>>> *Challenging Exception Handling:* The exception handling model is >>>> tricky: >>>> - >>>> >>>> *Loss of Checked Exception Compile-Time Safety:* FailedException >>>> is effectively an unchecked wrapper that erases checked exception >>>> information at compile time. Migrating from sequential, structured code to >>>> concurrent code now means losing valuable compiler guarantees. >>>> - >>>> >>>> *No Help For Exception Handling: *For code that wants to catch >>>> and handle these exceptions, it's the same story of using >>>> *instanceof* on the getCause(), again, losing all compile-time >>>> safety that was available in equivalent sequential code. >>>> - >>>> >>>> *Burdensome InterruptedException Handling:* The requirement for >>>> the caller to handle or propagate InterruptedException from >>>> join() will add room for error as handling InterruptedException >>>> is easy to get wrong: one can forget to call currentThread().interrupt(). >>>> Or, if the caller decides to declare *throws* >>>> *InterruptedException*, the signature propagation becomes viral. >>>> - >>>> >>>> *Default Exception Swallowing:* The AnySuccessOrThrow policy *swallows all >>>> exceptions* by default, including critical ones like >>>> NullPointerException, IllegalArgumentException, or even an Error. >>>> This makes it dangerously easy to mask bugs that should be highly visible. >>>> There is no straightforward mechanism to inspect these suppressed >>>> exceptions or fail on specific, unexpected types. >>>> >>>> We aren't happy with needing to wrap exceptions but it is no different >>>> to other concurrent APIs, e.g. Future. Countless hours have been spent on >>>> explorations to do better. All modelling of exceptions with type parameters >>>> lead to cumbersome usage, e.g. a type parameter for the exception thrown by >>>> subtasks and another type parameter for the exception thrown by join. If >>>> there were union types for exceptions or other changes to the language then >>>> we might do better. >>>> >>> >>> I understand that. And I'm not proposing to add exception type >>> parameters. Those aren't gonna work. >>> >>> I was hoping Java could add some help to make exception tunneling easier >>> (I had some detailed clarification in my reply to Remi), >>> >>> But even failing that, 3 points are orthogonal to adding type parameters: >>> >>> 1. Should the callback be Callable or Supplier? With Callable (and >>> with FailedException being unchecked), it's essentially a sneaky exception >>> unchecker. Whereas Supplier would be more like Stream, still not going to >>> make everyone happy, but it's at least honest: won't silently uncheck-ify >>> exceptions. >>> 2. Forcing callers to catch or handle InterruptedException is not >>> helpful. mapConcurrent() on the other hand doesn't, which I believe is a >>> better model. >>> 3. anySuccessfulResultThrow() swallows runtime exceptions and >>> errors. This to me seems like an anti-pattern. >>> >>> >>>> On anySuccessfulOrThrow, then it's like invokeAny and similar >>>> combinators in that it causes join to return a result from any subtasks or >>>> throw if all subtasks fail. It would be feasible to develop a Joiner that >>>> returns something like `record(Optional result, Map, >>>> Throwable> exceptions)` where the map contains the subtasks that failed >>>> before the successful subtask. That would be harder to use than the simpler >>>> built-in and users always have the option of logging in the failed subtask. >>>> >>>> I know. But the thought that a standard JDK API would silently swallow *by >>> default* still feels scary. >>> >>>> >>>> >>>> >>>> 1. >>>> >>>> *Conflated API Semantics:* The StructuredTaskScope API unifies two >>>> very different concurrency patterns?"gather all" ( >>>> allSuccessfulOrThrow) and "race to first success" ( >>>> anySuccessfulResultOrThrow)?under a single class but with different >>>> interaction models for the same method. >>>> - >>>> >>>> In the *"gather all"* pattern (allSuccessfulOrThrow), join() >>>> returns void. The callsite should use subtask.get() to retrieve >>>> results. >>>> - >>>> >>>> In the *"race"* pattern (anySuccessfulResultOrThrow), join() >>>> returns the result (R) of the first successful subtask directly. >>>> The developer should *not* call get() on individual subtasks. >>>> Having the join()+subtask.get() method spec'ed conditionally >>>> (which method to use and how depends on the actual policy) feels like a >>>> minor violation of LSP and is a source of confusion. It may be an >>>> indication of premature abstraction. >>>> >>>> join always returns something. For allSuccessfulOrThrow it returns a >>>> stream of successful subtasks. >>>> >>>> I think your comment is really about cases where the subtasks return >>>> results of the same type vs. other cases where subtasks return results of >>>> different types. This is an area where we need feedback. To date, we've >>>> been assuming that the more common case is subtasks that return results of >>>> different types (arms and legs in your example). For these cases, it's more >>>> useful to keep a reference to the subtask so that you don't have to cast >>>> when handling the results. It may be that we don't have this right and the >>>> common case is homogeneous subtasks, in which case the default Joiner >>>> should be allSuccessfulOrThrow so you don't need to keep a reference to the >>>> subtasks. >>>> >>> >>> I guess my feedback was at a higher level than the details in the Joiner >>> API. My question was: is the Joiner/STS API even the right API that pulls >>> this weight? If the STS team only needed to make mapConcurrent() fully >>> structured-concurrency, and it only needed to provide a simple, functional >>> API, the API would be a lot simpler and all of these extra imperative >>> concepts like subtasks, joiners, lifecycle callbacks etc. might not even >>> need to exist. >>> >>> It's quite likely that the Loom team had already discussed and reached >>> the conclusion that a functional API similar to what I had described, >>> despite being simpler, would not be sufficient, and the extra weight in the >>> current STS is worth it (for reasons X, Y and Z). If that's the case, then >>> consider my questions dismissed. >>> >>> Otherwise, I just want to make sure the unpopular question (*is it >>> worth it to build the imperative, complex API?*) is on the table. >>> >>>> >>>> >>>> >>>> >>>> 1. >>>> >>>> *Overly Complex Customization:* The StructuredTaskScope.Policy API, >>>> while powerful, feels like a potential footgun. The powerful lifecycle >>>> callback methods like onFork(), onComplete(), onTimeout() may lower the >>>> barrier to creating intricate, framework-like abstractions that are >>>> difficult to reason about and debug. >>>> >>>> Developing a Joiner for more advanced/expert developers. We have >>>> several guidelines in the API docs, the more relevant here is that they >>>> aren't the place for business logic, and should be designed to be as >>>> general purpose as possible. >>>> >>> >>> I guess I got my impression from recent online discussions that people >>> can be keen on using these lifecycle callbacks to bake in business-specific >>> needs. >>> >>> It's the thing with these generic libraries though: they can be used, >>> and they can be abused. And imho "how can it avoid being abused" should >>> also be a critical part of designing an API. >>> >>>> >>>> >>>> ------------------------------ >>>> *Suggestions for a Simpler Model* >>>> >>>> My preference is that the API for the most common use cases should be >>>> more *declarative and functional*. >>>> >>>> 1. >>>> >>>> *Simplify the "Gather All" Pattern:* The primary "fan-out and >>>> gather" use case could be captured in a simple, high-level construct. An >>>> average user shouldn't need to learn the wide API surface of >>>> StructuredTaskScope + Joiner + the lifecycles. For example: >>>> Java >>>> >>>> // Ideal API for the 80% use case >>>> Robot robot = Concurrently.call( >>>> () -> fetchArm(), >>>> () -> fetchLeg(), >>>> (arm, leg) -> new Robot(arm, leg) >>>> ); >>>> >>>> >>>> >>>> We've been down the road of combinator or utility methods a number of >>>> times, and have decided not to propose that direction for this API. It's >>>> not too hard to what create a method that does what you want, e.g. >>>> >>>> R callConcurrently(Callable task1, Callable task2, >>>> BiFunction combine) { >>>> try (var scope = StructuredTaskScope.open()) { >>>> Supplier subtask1 = scope.fork(task1); >>>> Supplier subtask2 = scope.fork(task2); >>>> scope.join(); >>>> return combine.apply(subtask1.get(), subtask2.get()); >>>> } >>>> } >>>> >>>> (there's a more general form of the example presented in the JEP), >>>> >>> >>> Yes. I understand it can be built on top of STS. But my point is to ask: *could >>> it be that the simpler API is all that most people need?* >>> >>> There's immense power in the *default option* provided by the standard >>> JDK. If STS is the default provided by Loom, I'm sure it'll be what >>> majority of people use, even if technically one can build a simpler wrapper >>> - it takes an extra dependency, or it takes extra work, and all the >>> documents are about the default option, so in the end, the theoretical >>> simpler alternative wrapper may not get a chance. >>> >>> But there are two potential downsides: >>> >>> 1. It changes the perception from SC being really easy in Java to >>> something less punchy. The ease-of-use of an API is imho much more >>> important than its raw power. >>> 2. The overly powerful STS API, with its sharp edges (e.g. >>> anySuccessfulOrThrow swallows exceptions) can be abused, generating code >>> that's less maintainable in the long run. >>> >>> And by asking that question, I guess my daring proposal (out of my >>> average-user naivety) is to decouple the two: >>> >>> - Provide a simple, functional API for the 90% users to enjoy SC in >>> the simplest possible way. *Forget about power and max coverage in >>> this phase*. >>> - Take the meaty STS API as an "advanced, follow-up project" and >>> evaluate the ROI, given 90% use cases already satisfied by the functional >>> API. >>> >>> >>>> >>>> >>>> 1. >>>> >>>> *Separate Race Semantics into Composable Operations:* The "race" >>>> pattern feels like a distinct use case that could be implemented more >>>> naturally using composable, functional APIs like Stream gatherers, rather >>>> than requiring a specialized API at all. For example, if >>>> mapConcurrent() fully embraced structured concurrency, guaranteeing >>>> fail-fast and happens-before, a recoverable race could be written >>>> explicitly: >>>> Java >>>> >>>> // Pseudo-code for a recoverable race using a stream gatherer >>>> T race(Collection> tasks, int maxConcurrency) { >>>> var exceptions = new ConcurrentLinkedQueue(); >>>> return tasks.stream() >>>> .gather(mapConcurrent(maxConcurrency, task -> { >>>> try { >>>> return task.call(); >>>> } catch (RpcException e) { >>>> if (isRecoverable(e)) { // Selectively recover >>>> exceptions.add(e); >>>> return null; // Suppress and continue >>>> } >>>> throw new RuntimeException(e); // Fail fast on non-recoverable >>>> } >>>> })) >>>> .filter(Objects::nonNull) >>>> .findFirst() // Short-circuiting and cancellation >>>> .orElseThrow(() -> new AggregateException(exceptions)); >>>> } >>>> >>>> While this is slightly more verbose than the JEP example, it's >>>> familiar Stream semantics that people have already learned, and it offers >>>> explicit control over which exceptions are recoverable versus fatal. The >>>> boilerplate for exception aggregation could easily be wrapped in a helper >>>> method. >>>> >>>> >>>> There are many use cases. Joiner defines a small set of static factory >>>> for built-ins that we hope will cover most usages, equivalent to the >>>> built-ins defined by Gatherers. The anySuccessfulOrThrow (which is "race" >>>> in some Scala libraries) fits in well. >>>> >>>> We do want to bring mapConcurrent (or a successor) into the structured >>>> fold but don't have a good proposal at this time. >>>> >>>> >>>> >>>> >>>> >>>> 1. >>>> >>>> *Reserve Complexity for Complex Cases:* The low-level >>>> StructuredTaskScope and its policy mechanism are powerful tools. >>>> However, they should be positioned as the "expert-level" API for building >>>> custom frameworks. Or perhaps just keep them in the traditional >>>> ExecutorService API. The everyday developer experience should be centered >>>> around simpler, declarative constructs that cover the most frequent needs. >>>> >>>> STS is intended to usable by average developers. Implementing Joiner is >>>> more advanced/expert. Early exploration did propose additions to >>>> ExecutorService, including a variant of inokveAll that short circuited when >>>> a task failed, but just hides everything about structured concurrency. >>>> >>>> -Alan >>>> >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From yujige at gmail.com Mon Oct 13 01:56:54 2025 From: yujige at gmail.com (Jige Yu) Date: Sun, 12 Oct 2025 18:56:54 -0700 Subject: Feedback on Structured Concurrency (JEP 525, 6th Preview) In-Reply-To: References: Message-ID: Understood your perspective, Peter. Thanks for the response! I think my earlier comment could be interpreted the wrong way. So if I may take it back to phrase it more accurately, this feedback is more like: A swiss army knife is what I need everyday. This jigsaw *can* cut for me, > but the sharp edges and the unwieldiness are my concern. On Sun, Oct 12, 2025 at 6:47?PM Peter Eastham wrote: > > I think my type of "yeah, but my use case is so simple, I don't need > this powerful tool" feedback, raising a use case that exceeds the > capability of the functional API, yet is still considered common, would > have been convincing? > > There are always going to be sharp edges and missing features to any API. > Mentioning them is useful, the real world examples help to put the context > around *how bad* those aspects are. Since we have a mature preview API, > it enables people to provide more than thoughts. > > If we're going to focus on my comment, "I think your best next step is to > either create or find and contribute to some OSS Library that wraps STS", > I'll call out that the important part was "next step". I'm sorry if this > came across as "Don't comment without a real world example". > -Peter > > On Sun, Oct 12, 2025 at 7:06?PM Jige Yu wrote: > >> Yeah, I understand by not really having used the STS api seriously, I >> must have limited my understanding of it in some ways. >> >> And I certainly don't claim that I know all its power and potential. Thus >> I'm sending the email to validate my overly-simplistic observation: a much >> simpler functional API would have sufficed. >> >> If I were to propose a new functionality, then I totally should have >> tried using the STS API and see why it couldn't solve my need. >> >> But here I'm not having a new use case or asking for a new feature. >> >> I'm simply saying that for all the use cases I can visualize, I only need >> a very limited subset of the STS API. >> >> Yes, it does solve my needs (if we ignore the exception handling sharp >> edges and the ergonomics). It's proved by you already, because what I want >> - the functional API, can be implemented as a functionality-reducing >> wrapper of the current STS API. >> >> I think my type of "yeah, but my use case is so simple, I don't need this >> powerful tool" feedback, raising a use case that exceeds the capability of >> the functional API, yet is still considered common, would have been >> convincing? >> >> That's what most API designs use, to gate every complexity, every feature >> with two questions: >> >> 1. What does it really solve that existing, simpler API can't solve >> well? >> 2. Is this use case compelling enough to pull the weight? >> >> >> Thanks for the pointer to the wiki, Peter. I'm browsing it now. But if >> anyone has a pointer to the past discussion that's related to "the simpler >> functional API isn't sufficient", I'll appreciate it! >> >> >> On Sun, Oct 12, 2025 at 4:59?PM Peter Eastham >> wrote: >> >>> I'll toss my two cents in here as another perspective. >>> >>> I understand your point is that the API might be more complex than it >>> needs to be, but I'm struggling to see how. It was brought up earlier, but >>> I'll reiterate that the best feedback comes from real world usage >>> *because* those use cases provide concrete examples of why a specific >>> feature is (or is not!) needed. While conversations like this are useful, I >>> think your best next step is to either create or find and contribute to >>> some OSS Library that wraps STS. I'm unsure if Apache has one yet, but >>> that's a historical location for wrappers around some sharp edges. You >>> could also continue to iterate on your own personal use cases, the library >>> approach just makes it easier to ensure you aren't being too biased towards >>> your own usage. >>> >>> My perspective is that while STS does expose a somewhat complex API with >>> some quirks, it's *near impossible* to achieve all the goals otherwise >>> without complete isolation from the other concurrency models in Java. For >>> example, without some way to populate non-inheritable ThreadLocals STS *wouldn't >>> be usable* for most applications, as they (and more importantly the >>> libraries they import) weren't designed with STS and ScopedValues in mind. >>> Given that most developers that want to use STS within the next 5 years >>> will be writing with or in existing codebases, that makes sense that any >>> API around it has to be able to accomplish that. >>> >>> Your goal of making sure STS isn't more complex than it needs to be *is >>> good*, I'm hoping my comments above help clarify how you can put your >>> efforts to use for a better ROI. >>> -Peter >>> >>> P.S >>> Alan it might be useful for the Wiki >>> to get some updates around the >>> explored options and where they fell short. I know from my own experience >>> that Wikis are not read as much as they should be, but I can see more >>> comments around the API happening as excitement continues to grow. Just >>> another 2 cents. >>> >>> On Sun, Oct 12, 2025 at 3:56?PM Jige Yu wrote: >>> >>>> >>>> >>>> On Sun, Oct 12, 2025 at 12:53?PM Alan Bateman >>>> wrote: >>>> >>>>> On 12/10/2025 06:32, Jige Yu wrote: >>>>> >>>>> Hi Project Loom. First and foremost, I want to express my gratitude >>>>> for the effort that has gone into structured concurrency. API design in >>>>> this space is notoriously difficult, and this feedback is offered with the >>>>> greatest respect for the team's work and in the spirit of collaborative >>>>> refinement. >>>>> >>>>> My perspective is that of a developer looking to use Structured >>>>> Concurrency for common, IO-intensive fan-out operations. My focus is to >>>>> replace everyday async callback hell, or reactive chains with >>>>> something simpler and more readable. >>>>> >>>>> It will lack depth in the highly specialized concurrent programming >>>>> area. And I acknowledge this viewpoint may bias my feedback. >>>>> >>>>> Just a general point on providing feedback: The feedback that we most >>>>> value is feedback from people that have tried a feature or API in earnest. >>>>> We regularly have people showing up here with alternative APIs proposals >>>>> but it's never clear if they have the same goals, whether they've tried the >>>>> feature, or have considered many use cases. This isn't a criticism of your >>>>> proposal, it's just not clear if this is after trying the feature or not. >>>>> >>>> >>>> Yeah. I've learned that feedbacks from tried, real earnest users would >>>> be more useful, which sadly I'm not. >>>> >>>> The exception handling part of it was enough for me to want to try >>>> something different and this is the angle I came in. I know my feedback is >>>> generally negative but they are honest. >>>> >>>> I did try to use mapConcurrent() and tried it out from the structured >>>> concurrency aspect. And I've then realized that it doesn't entirely have >>>> the two most important properties: fail-fast and happens-before. It does >>>> however provide two-way cancellation and task interruptions. >>>> >>>> I've also gotten my feet wet in trying to implement what I had >>>> proposed, making sure at least I know what I'm talking about, fwiw. >>>> >>>>> >>>>> ------------------------------ >>>>> >>>>> 1. >>>>> >>>>> *Stateful and Imperative API:* The API imposes quite some "don't >>>>> do this at time X" rules. Attempting to fork() after join() leads >>>>> to a runtime error; forgetting to call join() is another error; and the >>>>> imperative fork/join sequence is more cumbersome than a >>>>> declarative approach would be. None of these are unmanageable though. >>>>> >>>>> The API has 5 instance methods and isn't too hard to get wrong. Yes, >>>>> it's an exception at runtime if someone joins before forking, or attempts >>>>> to process the outcome before joining. With a few basic recipes/examples >>>>> then it should be possible for someone to get started quickly. The issues >>>>> dealing with cancellation and shutdown are difficult to get right and we >>>>> hope this API will help to avoid several of issues with a relatively simple >>>>> API. >>>>> >>>>> >>>>> >>>>> 1. >>>>> >>>>> *Challenging Exception Handling:* The exception handling model is >>>>> tricky: >>>>> - >>>>> >>>>> *Loss of Checked Exception Compile-Time Safety:* FailedException >>>>> is effectively an unchecked wrapper that erases checked exception >>>>> information at compile time. Migrating from sequential, structured code to >>>>> concurrent code now means losing valuable compiler guarantees. >>>>> - >>>>> >>>>> *No Help For Exception Handling: *For code that wants to catch >>>>> and handle these exceptions, it's the same story of using >>>>> *instanceof* on the getCause(), again, losing all compile-time >>>>> safety that was available in equivalent sequential code. >>>>> - >>>>> >>>>> *Burdensome InterruptedException Handling:* The requirement for >>>>> the caller to handle or propagate InterruptedException from >>>>> join() will add room for error as handling InterruptedException >>>>> is easy to get wrong: one can forget to call currentThread().interrupt(). >>>>> Or, if the caller decides to declare *throws* >>>>> *InterruptedException*, the signature propagation becomes viral. >>>>> - >>>>> >>>>> *Default Exception Swallowing:* The AnySuccessOrThrow policy *swallows all >>>>> exceptions* by default, including critical ones like >>>>> NullPointerException, IllegalArgumentException, or even an Error. >>>>> This makes it dangerously easy to mask bugs that should be highly visible. >>>>> There is no straightforward mechanism to inspect these suppressed >>>>> exceptions or fail on specific, unexpected types. >>>>> >>>>> We aren't happy with needing to wrap exceptions but it is no different >>>>> to other concurrent APIs, e.g. Future. Countless hours have been spent on >>>>> explorations to do better. All modelling of exceptions with type parameters >>>>> lead to cumbersome usage, e.g. a type parameter for the exception thrown by >>>>> subtasks and another type parameter for the exception thrown by join. If >>>>> there were union types for exceptions or other changes to the language then >>>>> we might do better. >>>>> >>>> >>>> I understand that. And I'm not proposing to add exception type >>>> parameters. Those aren't gonna work. >>>> >>>> I was hoping Java could add some help to make exception tunneling >>>> easier (I had some detailed clarification in my reply to Remi), >>>> >>>> But even failing that, 3 points are orthogonal to adding type >>>> parameters: >>>> >>>> 1. Should the callback be Callable or Supplier? With Callable (and >>>> with FailedException being unchecked), it's essentially a sneaky exception >>>> unchecker. Whereas Supplier would be more like Stream, still not going to >>>> make everyone happy, but it's at least honest: won't silently uncheck-ify >>>> exceptions. >>>> 2. Forcing callers to catch or handle InterruptedException is not >>>> helpful. mapConcurrent() on the other hand doesn't, which I believe is a >>>> better model. >>>> 3. anySuccessfulResultThrow() swallows runtime exceptions and >>>> errors. This to me seems like an anti-pattern. >>>> >>>> >>>>> On anySuccessfulOrThrow, then it's like invokeAny and similar >>>>> combinators in that it causes join to return a result from any subtasks or >>>>> throw if all subtasks fail. It would be feasible to develop a Joiner that >>>>> returns something like `record(Optional result, Map, >>>>> Throwable> exceptions)` where the map contains the subtasks that failed >>>>> before the successful subtask. That would be harder to use than the simpler >>>>> built-in and users always have the option of logging in the failed subtask. >>>>> >>>>> I know. But the thought that a standard JDK API would silently swallow *by >>>> default* still feels scary. >>>> >>>>> >>>>> >>>>> >>>>> 1. >>>>> >>>>> *Conflated API Semantics:* The StructuredTaskScope API unifies two >>>>> very different concurrency patterns?"gather all" ( >>>>> allSuccessfulOrThrow) and "race to first success" ( >>>>> anySuccessfulResultOrThrow)?under a single class but with >>>>> different interaction models for the same method. >>>>> - >>>>> >>>>> In the *"gather all"* pattern (allSuccessfulOrThrow), join() >>>>> returns void. The callsite should use subtask.get() to >>>>> retrieve results. >>>>> - >>>>> >>>>> In the *"race"* pattern (anySuccessfulResultOrThrow), join() >>>>> returns the result (R) of the first successful subtask >>>>> directly. The developer should *not* call get() on individual >>>>> subtasks. Having the join()+subtask.get() method spec'ed >>>>> conditionally (which method to use and how depends on the actual policy) >>>>> feels like a minor violation of LSP and is a source of confusion. It may be >>>>> an indication of premature abstraction. >>>>> >>>>> join always returns something. For allSuccessfulOrThrow it returns a >>>>> stream of successful subtasks. >>>>> >>>>> I think your comment is really about cases where the subtasks return >>>>> results of the same type vs. other cases where subtasks return results of >>>>> different types. This is an area where we need feedback. To date, we've >>>>> been assuming that the more common case is subtasks that return results of >>>>> different types (arms and legs in your example). For these cases, it's more >>>>> useful to keep a reference to the subtask so that you don't have to cast >>>>> when handling the results. It may be that we don't have this right and the >>>>> common case is homogeneous subtasks, in which case the default Joiner >>>>> should be allSuccessfulOrThrow so you don't need to keep a reference to the >>>>> subtasks. >>>>> >>>> >>>> I guess my feedback was at a higher level than the details in the >>>> Joiner API. My question was: is the Joiner/STS API even the right API that >>>> pulls this weight? If the STS team only needed to make mapConcurrent() >>>> fully structured-concurrency, and it only needed to provide a simple, >>>> functional API, the API would be a lot simpler and all of these extra >>>> imperative concepts like subtasks, joiners, lifecycle callbacks etc. might >>>> not even need to exist. >>>> >>>> It's quite likely that the Loom team had already discussed and reached >>>> the conclusion that a functional API similar to what I had described, >>>> despite being simpler, would not be sufficient, and the extra weight in the >>>> current STS is worth it (for reasons X, Y and Z). If that's the case, then >>>> consider my questions dismissed. >>>> >>>> Otherwise, I just want to make sure the unpopular question (*is it >>>> worth it to build the imperative, complex API?*) is on the table. >>>> >>>>> >>>>> >>>>> >>>>> >>>>> 1. >>>>> >>>>> *Overly Complex Customization:* The StructuredTaskScope.Policy >>>>> API, while powerful, feels like a potential footgun. The powerful lifecycle >>>>> callback methods like onFork(), onComplete(), onTimeout() may lower the >>>>> barrier to creating intricate, framework-like abstractions that are >>>>> difficult to reason about and debug. >>>>> >>>>> Developing a Joiner for more advanced/expert developers. We have >>>>> several guidelines in the API docs, the more relevant here is that they >>>>> aren't the place for business logic, and should be designed to be as >>>>> general purpose as possible. >>>>> >>>> >>>> I guess I got my impression from recent online discussions that people >>>> can be keen on using these lifecycle callbacks to bake in business-specific >>>> needs. >>>> >>>> It's the thing with these generic libraries though: they can be used, >>>> and they can be abused. And imho "how can it avoid being abused" should >>>> also be a critical part of designing an API. >>>> >>>>> >>>>> >>>>> ------------------------------ >>>>> *Suggestions for a Simpler Model* >>>>> >>>>> My preference is that the API for the most common use cases should be >>>>> more *declarative and functional*. >>>>> >>>>> 1. >>>>> >>>>> *Simplify the "Gather All" Pattern:* The primary "fan-out and >>>>> gather" use case could be captured in a simple, high-level construct. An >>>>> average user shouldn't need to learn the wide API surface of >>>>> StructuredTaskScope + Joiner + the lifecycles. For example: >>>>> Java >>>>> >>>>> // Ideal API for the 80% use case >>>>> Robot robot = Concurrently.call( >>>>> () -> fetchArm(), >>>>> () -> fetchLeg(), >>>>> (arm, leg) -> new Robot(arm, leg) >>>>> ); >>>>> >>>>> >>>>> >>>>> We've been down the road of combinator or utility methods a number of >>>>> times, and have decided not to propose that direction for this API. It's >>>>> not too hard to what create a method that does what you want, e.g. >>>>> >>>>> R callConcurrently(Callable task1, Callable task2, >>>>> BiFunction combine) { >>>>> try (var scope = StructuredTaskScope.open()) { >>>>> Supplier subtask1 = scope.fork(task1); >>>>> Supplier subtask2 = scope.fork(task2); >>>>> scope.join(); >>>>> return combine.apply(subtask1.get(), subtask2.get()); >>>>> } >>>>> } >>>>> >>>>> (there's a more general form of the example presented in the JEP), >>>>> >>>> >>>> Yes. I understand it can be built on top of STS. But my point is to >>>> ask: *could it be that the simpler API is all that most people need?* >>>> >>>> There's immense power in the *default option* provided by the standard >>>> JDK. If STS is the default provided by Loom, I'm sure it'll be what >>>> majority of people use, even if technically one can build a simpler wrapper >>>> - it takes an extra dependency, or it takes extra work, and all the >>>> documents are about the default option, so in the end, the theoretical >>>> simpler alternative wrapper may not get a chance. >>>> >>>> But there are two potential downsides: >>>> >>>> 1. It changes the perception from SC being really easy in Java to >>>> something less punchy. The ease-of-use of an API is imho much more >>>> important than its raw power. >>>> 2. The overly powerful STS API, with its sharp edges (e.g. >>>> anySuccessfulOrThrow swallows exceptions) can be abused, generating code >>>> that's less maintainable in the long run. >>>> >>>> And by asking that question, I guess my daring proposal (out of my >>>> average-user naivety) is to decouple the two: >>>> >>>> - Provide a simple, functional API for the 90% users to enjoy SC in >>>> the simplest possible way. *Forget about power and max coverage in >>>> this phase*. >>>> - Take the meaty STS API as an "advanced, follow-up project" and >>>> evaluate the ROI, given 90% use cases already satisfied by the functional >>>> API. >>>> >>>> >>>>> >>>>> >>>>> 1. >>>>> >>>>> *Separate Race Semantics into Composable Operations:* The "race" >>>>> pattern feels like a distinct use case that could be implemented more >>>>> naturally using composable, functional APIs like Stream gatherers, rather >>>>> than requiring a specialized API at all. For example, if >>>>> mapConcurrent() fully embraced structured concurrency, >>>>> guaranteeing fail-fast and happens-before, a recoverable race could be >>>>> written explicitly: >>>>> Java >>>>> >>>>> // Pseudo-code for a recoverable race using a stream gatherer >>>>> T race(Collection> tasks, int maxConcurrency) { >>>>> var exceptions = new ConcurrentLinkedQueue(); >>>>> return tasks.stream() >>>>> .gather(mapConcurrent(maxConcurrency, task -> { >>>>> try { >>>>> return task.call(); >>>>> } catch (RpcException e) { >>>>> if (isRecoverable(e)) { // Selectively recover >>>>> exceptions.add(e); >>>>> return null; // Suppress and continue >>>>> } >>>>> throw new RuntimeException(e); // Fail fast on non-recoverable >>>>> } >>>>> })) >>>>> .filter(Objects::nonNull) >>>>> .findFirst() // Short-circuiting and cancellation >>>>> .orElseThrow(() -> new AggregateException(exceptions)); >>>>> } >>>>> >>>>> While this is slightly more verbose than the JEP example, it's >>>>> familiar Stream semantics that people have already learned, and it offers >>>>> explicit control over which exceptions are recoverable versus fatal. The >>>>> boilerplate for exception aggregation could easily be wrapped in a helper >>>>> method. >>>>> >>>>> >>>>> There are many use cases. Joiner defines a small set of static factory >>>>> for built-ins that we hope will cover most usages, equivalent to the >>>>> built-ins defined by Gatherers. The anySuccessfulOrThrow (which is "race" >>>>> in some Scala libraries) fits in well. >>>>> >>>>> We do want to bring mapConcurrent (or a successor) into the structured >>>>> fold but don't have a good proposal at this time. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> 1. >>>>> >>>>> *Reserve Complexity for Complex Cases:* The low-level >>>>> StructuredTaskScope and its policy mechanism are powerful tools. >>>>> However, they should be positioned as the "expert-level" API for building >>>>> custom frameworks. Or perhaps just keep them in the traditional >>>>> ExecutorService API. The everyday developer experience should be centered >>>>> around simpler, declarative constructs that cover the most frequent needs. >>>>> >>>>> STS is intended to usable by average developers. Implementing Joiner >>>>> is more advanced/expert. Early exploration did propose additions to >>>>> ExecutorService, including a variant of inokveAll that short circuited when >>>>> a task failed, but just hides everything about structured concurrency. >>>>> >>>>> -Alan >>>>> >>>>> >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From fyang at openjdk.org Mon Oct 13 02:41:24 2025 From: fyang at openjdk.org (Fei Yang) Date: Mon, 13 Oct 2025 02:41:24 GMT Subject: RFR: RISC-V: Allow virtual thread preemption on some common class initialization paths Message-ID: <4G-7Ql8abR8pJGoyWbkt_NoQ3b4JkxcK8401cQm9Tow=.6ab472a8-225a-4ba5-93a2-bbe4b5245d40@github.com> This adds RISC-V support for : https://bugs.openjdk.org/browse/JDK-8369238 Testing performed on linux-riscv64 platform: - [x] hs:tier1 - hs:tier3 (release) - [x] make test TEST="hotspot_loom jdk_loom" (release) - [x] make test TEST="hotspot_loom jdk_loom" TEST_VM_OPTS="-XX:+VerifyStack -XX:+VerifyContinuations" (fastdebug) ------------- Commit messages: - RISC-V: Allow virtual thread preemption on some common class initialization paths Changes: https://git.openjdk.org/loom/pull/222/files Webrev: https://webrevs.openjdk.org/?repo=loom&pr=222&range=00 Stats: 186 lines in 11 files changed: 131 ins; 23 del; 32 mod Patch: https://git.openjdk.org/loom/pull/222.diff Fetch: git fetch https://git.openjdk.org/loom.git pull/222/head:pull/222 PR: https://git.openjdk.org/loom/pull/222 From yujige at gmail.com Mon Oct 13 04:22:21 2025 From: yujige at gmail.com (Jige Yu) Date: Sun, 12 Oct 2025 21:22:21 -0700 Subject: Feedback on Structured Concurrency (JEP 525, 6th Preview) In-Reply-To: References: Message-ID: At the risk of a tangent, recently there was a discussion thread about a use case of web crawler and having different forks inter-communicating with the parent scope being blocked etc. Imho, this may be a case of the imperative STS API encouraging users toward complex solutions. If there were nothing but a functional approach, I'd think the use case can be trivially implemented with a mapConcurrent() that fully supports structured concurrency : int maxConcurrency = 10; Set seen = new HashSet<>(); seen.add(root); for (List toCrawl = List.of(root); toCrawl.size() > 0; ) { toCrawl = toCrawl.stream() .gather(mapConcurrent(maxConcurrency, url -> loadWebPage(url))) .flatMap(page -> page.getLinks().stream()) .filter(seen::add) .toList(); } The code essentially does a breadth-first traversal, at each round concurrently crawls web pages with a map concurrency limit. And this is the direction I'd hope the Loom team can more seriously entertain: put a strong constraint on the API's imperative power, run a thought experiment to see if the functional variant could offer sufficient flexibility under the constraint. And along the way, make exceptions easier to use. On Sun, Oct 12, 2025 at 6:56?PM Jige Yu wrote: > Understood your perspective, Peter. Thanks for the response! > > I think my earlier comment could be interpreted the wrong way. > > So if I may take it back to phrase it more accurately, this feedback is > more like: > > A swiss army knife is what I need everyday. This jigsaw *can* cut for me, >> but the sharp edges and the unwieldiness are my concern. > > > On Sun, Oct 12, 2025 at 6:47?PM Peter Eastham > wrote: > >> > I think my type of "yeah, but my use case is so simple, I don't need >> this powerful tool" feedback, raising a use case that exceeds the >> capability of the functional API, yet is still considered common, would >> have been convincing? >> >> There are always going to be sharp edges and missing features to any API. >> Mentioning them is useful, the real world examples help to put the context >> around *how bad* those aspects are. Since we have a mature preview API, >> it enables people to provide more than thoughts. >> >> If we're going to focus on my comment, "I think your best next step is to >> either create or find and contribute to some OSS Library that wraps STS", >> I'll call out that the important part was "next step". I'm sorry if this >> came across as "Don't comment without a real world example". >> -Peter >> >> On Sun, Oct 12, 2025 at 7:06?PM Jige Yu wrote: >> >>> Yeah, I understand by not really having used the STS api seriously, I >>> must have limited my understanding of it in some ways. >>> >>> And I certainly don't claim that I know all its power and potential. >>> Thus I'm sending the email to validate my overly-simplistic observation: a >>> much simpler functional API would have sufficed. >>> >>> If I were to propose a new functionality, then I totally should have >>> tried using the STS API and see why it couldn't solve my need. >>> >>> But here I'm not having a new use case or asking for a new feature. >>> >>> I'm simply saying that for all the use cases I can visualize, I only >>> need a very limited subset of the STS API. >>> >>> Yes, it does solve my needs (if we ignore the exception handling sharp >>> edges and the ergonomics). It's proved by you already, because what I want >>> - the functional API, can be implemented as a functionality-reducing >>> wrapper of the current STS API. >>> >>> I think my type of "yeah, but my use case is so simple, I don't need >>> this powerful tool" feedback, raising a use case that exceeds the >>> capability of the functional API, yet is still considered common, would >>> have been convincing? >>> >>> That's what most API designs use, to gate every complexity, every >>> feature with two questions: >>> >>> 1. What does it really solve that existing, simpler API can't solve >>> well? >>> 2. Is this use case compelling enough to pull the weight? >>> >>> >>> Thanks for the pointer to the wiki, Peter. I'm browsing it now. But if >>> anyone has a pointer to the past discussion that's related to "the simpler >>> functional API isn't sufficient", I'll appreciate it! >>> >>> >>> On Sun, Oct 12, 2025 at 4:59?PM Peter Eastham >>> wrote: >>> >>>> I'll toss my two cents in here as another perspective. >>>> >>>> I understand your point is that the API might be more complex than it >>>> needs to be, but I'm struggling to see how. It was brought up earlier, but >>>> I'll reiterate that the best feedback comes from real world usage >>>> *because* those use cases provide concrete examples of why a specific >>>> feature is (or is not!) needed. While conversations like this are useful, I >>>> think your best next step is to either create or find and contribute to >>>> some OSS Library that wraps STS. I'm unsure if Apache has one yet, but >>>> that's a historical location for wrappers around some sharp edges. You >>>> could also continue to iterate on your own personal use cases, the library >>>> approach just makes it easier to ensure you aren't being too biased towards >>>> your own usage. >>>> >>>> My perspective is that while STS does expose a somewhat complex API >>>> with some quirks, it's *near impossible* to achieve all the goals >>>> otherwise without complete isolation from the other concurrency models in >>>> Java. For example, without some way to populate non-inheritable >>>> ThreadLocals STS *wouldn't be usable* for most applications, as they >>>> (and more importantly the libraries they import) weren't designed with STS >>>> and ScopedValues in mind. Given that most developers that want to use STS >>>> within the next 5 years will be writing with or in existing codebases, that >>>> makes sense that any API around it has to be able to accomplish that. >>>> >>>> Your goal of making sure STS isn't more complex than it needs to be *is >>>> good*, I'm hoping my comments above help clarify how you can put your >>>> efforts to use for a better ROI. >>>> -Peter >>>> >>>> P.S >>>> Alan it might be useful for the Wiki >>>> to get some updates around the >>>> explored options and where they fell short. I know from my own experience >>>> that Wikis are not read as much as they should be, but I can see more >>>> comments around the API happening as excitement continues to grow. Just >>>> another 2 cents. >>>> >>>> On Sun, Oct 12, 2025 at 3:56?PM Jige Yu wrote: >>>> >>>>> >>>>> >>>>> On Sun, Oct 12, 2025 at 12:53?PM Alan Bateman >>>>> wrote: >>>>> >>>>>> On 12/10/2025 06:32, Jige Yu wrote: >>>>>> >>>>>> Hi Project Loom. First and foremost, I want to express my gratitude >>>>>> for the effort that has gone into structured concurrency. API design in >>>>>> this space is notoriously difficult, and this feedback is offered with the >>>>>> greatest respect for the team's work and in the spirit of collaborative >>>>>> refinement. >>>>>> >>>>>> My perspective is that of a developer looking to use Structured >>>>>> Concurrency for common, IO-intensive fan-out operations. My focus is to >>>>>> replace everyday async callback hell, or reactive chains with >>>>>> something simpler and more readable. >>>>>> >>>>>> It will lack depth in the highly specialized concurrent programming >>>>>> area. And I acknowledge this viewpoint may bias my feedback. >>>>>> >>>>>> Just a general point on providing feedback: The feedback that we most >>>>>> value is feedback from people that have tried a feature or API in earnest. >>>>>> We regularly have people showing up here with alternative APIs proposals >>>>>> but it's never clear if they have the same goals, whether they've tried the >>>>>> feature, or have considered many use cases. This isn't a criticism of your >>>>>> proposal, it's just not clear if this is after trying the feature or not. >>>>>> >>>>> >>>>> Yeah. I've learned that feedbacks from tried, real earnest users >>>>> would be more useful, which sadly I'm not. >>>>> >>>>> The exception handling part of it was enough for me to want to try >>>>> something different and this is the angle I came in. I know my feedback is >>>>> generally negative but they are honest. >>>>> >>>>> I did try to use mapConcurrent() and tried it out from the structured >>>>> concurrency aspect. And I've then realized that it doesn't entirely have >>>>> the two most important properties: fail-fast and happens-before. It does >>>>> however provide two-way cancellation and task interruptions. >>>>> >>>>> I've also gotten my feet wet in trying to implement what I had >>>>> proposed, making sure at least I know what I'm talking about, fwiw. >>>>> >>>>>> >>>>>> ------------------------------ >>>>>> >>>>>> 1. >>>>>> >>>>>> *Stateful and Imperative API:* The API imposes quite some "don't >>>>>> do this at time X" rules. Attempting to fork() after join() leads >>>>>> to a runtime error; forgetting to call join() is another error; and the >>>>>> imperative fork/join sequence is more cumbersome than a >>>>>> declarative approach would be. None of these are unmanageable though. >>>>>> >>>>>> The API has 5 instance methods and isn't too hard to get wrong. Yes, >>>>>> it's an exception at runtime if someone joins before forking, or attempts >>>>>> to process the outcome before joining. With a few basic recipes/examples >>>>>> then it should be possible for someone to get started quickly. The issues >>>>>> dealing with cancellation and shutdown are difficult to get right and we >>>>>> hope this API will help to avoid several of issues with a relatively simple >>>>>> API. >>>>>> >>>>>> >>>>>> >>>>>> 1. >>>>>> >>>>>> *Challenging Exception Handling:* The exception handling model is >>>>>> tricky: >>>>>> - >>>>>> >>>>>> *Loss of Checked Exception Compile-Time Safety:* >>>>>> FailedException is effectively an unchecked wrapper that >>>>>> erases checked exception information at compile time. Migrating from >>>>>> sequential, structured code to concurrent code now means losing valuable >>>>>> compiler guarantees. >>>>>> - >>>>>> >>>>>> *No Help For Exception Handling: *For code that wants to catch >>>>>> and handle these exceptions, it's the same story of using >>>>>> *instanceof* on the getCause(), again, losing all compile-time >>>>>> safety that was available in equivalent sequential code. >>>>>> - >>>>>> >>>>>> *Burdensome InterruptedException Handling:* The requirement >>>>>> for the caller to handle or propagate InterruptedException >>>>>> from join() will add room for error as handling >>>>>> InterruptedException is easy to get wrong: one can forget to call >>>>>> currentThread().interrupt(). Or, if the caller decides to declare >>>>>> *throws* *InterruptedException*, the signature propagation >>>>>> becomes viral. >>>>>> - >>>>>> >>>>>> *Default Exception Swallowing:* The AnySuccessOrThrow policy *swallows all >>>>>> exceptions* by default, including critical ones like >>>>>> NullPointerException, IllegalArgumentException, or even an >>>>>> Error. This makes it dangerously easy to mask bugs that should >>>>>> be highly visible. There is no straightforward mechanism to inspect these >>>>>> suppressed exceptions or fail on specific, unexpected types. >>>>>> >>>>>> We aren't happy with needing to wrap exceptions but it is no >>>>>> different to other concurrent APIs, e.g. Future. Countless hours have been >>>>>> spent on explorations to do better. All modelling of exceptions with type >>>>>> parameters lead to cumbersome usage, e.g. a type parameter for the >>>>>> exception thrown by subtasks and another type parameter for the exception >>>>>> thrown by join. If there were union types for exceptions or other changes >>>>>> to the language then we might do better. >>>>>> >>>>> >>>>> I understand that. And I'm not proposing to add exception type >>>>> parameters. Those aren't gonna work. >>>>> >>>>> I was hoping Java could add some help to make exception tunneling >>>>> easier (I had some detailed clarification in my reply to Remi), >>>>> >>>>> But even failing that, 3 points are orthogonal to adding type >>>>> parameters: >>>>> >>>>> 1. Should the callback be Callable or Supplier? With Callable (and >>>>> with FailedException being unchecked), it's essentially a sneaky exception >>>>> unchecker. Whereas Supplier would be more like Stream, still not going to >>>>> make everyone happy, but it's at least honest: won't silently uncheck-ify >>>>> exceptions. >>>>> 2. Forcing callers to catch or handle InterruptedException is not >>>>> helpful. mapConcurrent() on the other hand doesn't, which I believe is a >>>>> better model. >>>>> 3. anySuccessfulResultThrow() swallows runtime exceptions and >>>>> errors. This to me seems like an anti-pattern. >>>>> >>>>> >>>>>> On anySuccessfulOrThrow, then it's like invokeAny and similar >>>>>> combinators in that it causes join to return a result from any subtasks or >>>>>> throw if all subtasks fail. It would be feasible to develop a Joiner that >>>>>> returns something like `record(Optional result, Map, >>>>>> Throwable> exceptions)` where the map contains the subtasks that failed >>>>>> before the successful subtask. That would be harder to use than the simpler >>>>>> built-in and users always have the option of logging in the failed subtask. >>>>>> >>>>>> I know. But the thought that a standard JDK API would silently >>>>> swallow *by default* still feels scary. >>>>> >>>>>> >>>>>> >>>>>> >>>>>> 1. >>>>>> >>>>>> *Conflated API Semantics:* The StructuredTaskScope API unifies >>>>>> two very different concurrency patterns?"gather all" ( >>>>>> allSuccessfulOrThrow) and "race to first success" ( >>>>>> anySuccessfulResultOrThrow)?under a single class but with >>>>>> different interaction models for the same method. >>>>>> - >>>>>> >>>>>> In the *"gather all"* pattern (allSuccessfulOrThrow), join() >>>>>> returns void. The callsite should use subtask.get() to >>>>>> retrieve results. >>>>>> - >>>>>> >>>>>> In the *"race"* pattern (anySuccessfulResultOrThrow), join() >>>>>> returns the result (R) of the first successful subtask >>>>>> directly. The developer should *not* call get() on individual >>>>>> subtasks. Having the join()+subtask.get() method spec'ed >>>>>> conditionally (which method to use and how depends on the actual policy) >>>>>> feels like a minor violation of LSP and is a source of confusion. It may be >>>>>> an indication of premature abstraction. >>>>>> >>>>>> join always returns something. For allSuccessfulOrThrow it returns a >>>>>> stream of successful subtasks. >>>>>> >>>>>> I think your comment is really about cases where the subtasks return >>>>>> results of the same type vs. other cases where subtasks return results of >>>>>> different types. This is an area where we need feedback. To date, we've >>>>>> been assuming that the more common case is subtasks that return results of >>>>>> different types (arms and legs in your example). For these cases, it's more >>>>>> useful to keep a reference to the subtask so that you don't have to cast >>>>>> when handling the results. It may be that we don't have this right and the >>>>>> common case is homogeneous subtasks, in which case the default Joiner >>>>>> should be allSuccessfulOrThrow so you don't need to keep a reference to the >>>>>> subtasks. >>>>>> >>>>> >>>>> I guess my feedback was at a higher level than the details in the >>>>> Joiner API. My question was: is the Joiner/STS API even the right API that >>>>> pulls this weight? If the STS team only needed to make mapConcurrent() >>>>> fully structured-concurrency, and it only needed to provide a simple, >>>>> functional API, the API would be a lot simpler and all of these extra >>>>> imperative concepts like subtasks, joiners, lifecycle callbacks etc. might >>>>> not even need to exist. >>>>> >>>>> It's quite likely that the Loom team had already discussed and reached >>>>> the conclusion that a functional API similar to what I had described, >>>>> despite being simpler, would not be sufficient, and the extra weight in the >>>>> current STS is worth it (for reasons X, Y and Z). If that's the case, then >>>>> consider my questions dismissed. >>>>> >>>>> Otherwise, I just want to make sure the unpopular question (*is it >>>>> worth it to build the imperative, complex API?*) is on the table. >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 1. >>>>>> >>>>>> *Overly Complex Customization:* The StructuredTaskScope.Policy >>>>>> API, while powerful, feels like a potential footgun. The powerful lifecycle >>>>>> callback methods like onFork(), onComplete(), onTimeout() may lower the >>>>>> barrier to creating intricate, framework-like abstractions that are >>>>>> difficult to reason about and debug. >>>>>> >>>>>> Developing a Joiner for more advanced/expert developers. We have >>>>>> several guidelines in the API docs, the more relevant here is that they >>>>>> aren't the place for business logic, and should be designed to be as >>>>>> general purpose as possible. >>>>>> >>>>> >>>>> I guess I got my impression from recent online discussions that people >>>>> can be keen on using these lifecycle callbacks to bake in business-specific >>>>> needs. >>>>> >>>>> It's the thing with these generic libraries though: they can be used, >>>>> and they can be abused. And imho "how can it avoid being abused" should >>>>> also be a critical part of designing an API. >>>>> >>>>>> >>>>>> >>>>>> ------------------------------ >>>>>> *Suggestions for a Simpler Model* >>>>>> >>>>>> My preference is that the API for the most common use cases should be >>>>>> more *declarative and functional*. >>>>>> >>>>>> 1. >>>>>> >>>>>> *Simplify the "Gather All" Pattern:* The primary "fan-out and >>>>>> gather" use case could be captured in a simple, high-level construct. An >>>>>> average user shouldn't need to learn the wide API surface of >>>>>> StructuredTaskScope + Joiner + the lifecycles. For example: >>>>>> Java >>>>>> >>>>>> // Ideal API for the 80% use case >>>>>> Robot robot = Concurrently.call( >>>>>> () -> fetchArm(), >>>>>> () -> fetchLeg(), >>>>>> (arm, leg) -> new Robot(arm, leg) >>>>>> ); >>>>>> >>>>>> >>>>>> >>>>>> We've been down the road of combinator or utility methods a number of >>>>>> times, and have decided not to propose that direction for this API. It's >>>>>> not too hard to what create a method that does what you want, e.g. >>>>>> >>>>>> R callConcurrently(Callable task1, Callable >>>>>> task2, BiFunction combine) { >>>>>> try (var scope = StructuredTaskScope.open()) { >>>>>> Supplier subtask1 = scope.fork(task1); >>>>>> Supplier subtask2 = scope.fork(task2); >>>>>> scope.join(); >>>>>> return combine.apply(subtask1.get(), subtask2.get()); >>>>>> } >>>>>> } >>>>>> >>>>>> (there's a more general form of the example presented in the JEP), >>>>>> >>>>> >>>>> Yes. I understand it can be built on top of STS. But my point is to >>>>> ask: *could it be that the simpler API is all that most people need?* >>>>> >>>>> There's immense power in the *default option* provided by the >>>>> standard JDK. If STS is the default provided by Loom, I'm sure it'll be >>>>> what majority of people use, even if technically one can build a simpler >>>>> wrapper - it takes an extra dependency, or it takes extra work, and all the >>>>> documents are about the default option, so in the end, the theoretical >>>>> simpler alternative wrapper may not get a chance. >>>>> >>>>> But there are two potential downsides: >>>>> >>>>> 1. It changes the perception from SC being really easy in Java to >>>>> something less punchy. The ease-of-use of an API is imho much more >>>>> important than its raw power. >>>>> 2. The overly powerful STS API, with its sharp edges (e.g. >>>>> anySuccessfulOrThrow swallows exceptions) can be abused, generating code >>>>> that's less maintainable in the long run. >>>>> >>>>> And by asking that question, I guess my daring proposal (out of my >>>>> average-user naivety) is to decouple the two: >>>>> >>>>> - Provide a simple, functional API for the 90% users to enjoy SC >>>>> in the simplest possible way. *Forget about power and max coverage >>>>> in this phase*. >>>>> - Take the meaty STS API as an "advanced, follow-up project" and >>>>> evaluate the ROI, given 90% use cases already satisfied by the functional >>>>> API. >>>>> >>>>> >>>>>> >>>>>> >>>>>> 1. >>>>>> >>>>>> *Separate Race Semantics into Composable Operations:* The "race" >>>>>> pattern feels like a distinct use case that could be implemented more >>>>>> naturally using composable, functional APIs like Stream gatherers, rather >>>>>> than requiring a specialized API at all. For example, if >>>>>> mapConcurrent() fully embraced structured concurrency, >>>>>> guaranteeing fail-fast and happens-before, a recoverable race could be >>>>>> written explicitly: >>>>>> Java >>>>>> >>>>>> // Pseudo-code for a recoverable race using a stream gatherer >>>>>> T race(Collection> tasks, int maxConcurrency) { >>>>>> var exceptions = new ConcurrentLinkedQueue(); >>>>>> return tasks.stream() >>>>>> .gather(mapConcurrent(maxConcurrency, task -> { >>>>>> try { >>>>>> return task.call(); >>>>>> } catch (RpcException e) { >>>>>> if (isRecoverable(e)) { // Selectively recover >>>>>> exceptions.add(e); >>>>>> return null; // Suppress and continue >>>>>> } >>>>>> throw new RuntimeException(e); // Fail fast on non-recoverable >>>>>> } >>>>>> })) >>>>>> .filter(Objects::nonNull) >>>>>> .findFirst() // Short-circuiting and cancellation >>>>>> .orElseThrow(() -> new AggregateException(exceptions)); >>>>>> } >>>>>> >>>>>> While this is slightly more verbose than the JEP example, it's >>>>>> familiar Stream semantics that people have already learned, and it offers >>>>>> explicit control over which exceptions are recoverable versus fatal. The >>>>>> boilerplate for exception aggregation could easily be wrapped in a helper >>>>>> method. >>>>>> >>>>>> >>>>>> There are many use cases. Joiner defines a small set of static >>>>>> factory for built-ins that we hope will cover most usages, equivalent to >>>>>> the built-ins defined by Gatherers. The anySuccessfulOrThrow (which is >>>>>> "race" in some Scala libraries) fits in well. >>>>>> >>>>>> We do want to bring mapConcurrent (or a successor) into the >>>>>> structured fold but don't have a good proposal at this time. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 1. >>>>>> >>>>>> *Reserve Complexity for Complex Cases:* The low-level >>>>>> StructuredTaskScope and its policy mechanism are powerful tools. >>>>>> However, they should be positioned as the "expert-level" API for building >>>>>> custom frameworks. Or perhaps just keep them in the traditional >>>>>> ExecutorService API. The everyday developer experience should be centered >>>>>> around simpler, declarative constructs that cover the most frequent needs. >>>>>> >>>>>> STS is intended to usable by average developers. Implementing Joiner >>>>>> is more advanced/expert. Early exploration did propose additions to >>>>>> ExecutorService, including a variant of inokveAll that short circuited when >>>>>> a task failed, but just hides everything about structured concurrency. >>>>>> >>>>>> -Alan >>>>>> >>>>>> >>>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.bateman at oracle.com Mon Oct 13 06:38:16 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Mon, 13 Oct 2025 07:38:16 +0100 Subject: Feedback on Structured Concurrency (JEP 525, 6th Preview) In-Reply-To: References: Message-ID: On 13/10/2025 05:22, Jige Yu wrote: > : > > And this is the direction I'd hope the Loom team can more seriously > entertain: put a strong constraint on the API's imperative power, run > a thought experiment to see if the functional variant could offer > sufficient flexibility under the constraint. > I can't tell from your mails if you have read the JEP or not. We've tried to make it clear in every JEP that the goal is not to create the definitive structured concurrency API. This is an on-ramp API intended to "promote a style of concurrent programming that can eliminate common risks from cancellation and shutdown".? Its sweet spot is in fan-out scenarios. Its deliberately imperative and kept as simple as possible.? There will be other APIs. For example, we would like to bring channels based and other fan-in scenarios into the fold. We would like to eventually expose a lower level APIs for building other structured APIs outside of the JDK. On mapConcurrent. We've been around and around the topic of bringing it into the "structured fold".? From your back and forth with Viktor on core-libs-dev then I think you understand the issues.? When JEP 485 was preparing to make the gatherers API permanent it had to be decided if mapConcurrent should be pulled out. The conclusion was that it was useful enough as is, and we will look at improving or replacing it in the future. So yes, we of course want this, it's just not in the first API. -Alan From viktor.klang at oracle.com Mon Oct 13 09:31:38 2025 From: viktor.klang at oracle.com (Viktor Klang) Date: Mon, 13 Oct 2025 09:31:38 +0000 Subject: Feedback on Structured Concurrency (JEP 525, 6th Preview) In-Reply-To: References: Message-ID: Let me just weigh in by saying that these kinds of conversations are not ideal if the goal is to make change happen?as mentioned previously, real-world feedback is what we've found (over decades) to be the most important kind of feedback to make change happen. For the current incarnation of Structured Concurrency, Alan and I have exhausted the design space several times over with tons of different prototypes, including functional combinators (composition of N-ary concurrent ANDs and ORs). Not only is the current Structured Concurrency APIs not envisioned to be the complete solution, also I believe it to be important to tease apart questions?are we having a discussion about API design and its trade-offs in general, or are we discussing user-observed problems with a specific API design in particular? The reason for separating those two is that the former is rather open-ended and its outcomes are rather limited in terms of impact, but the latter can lead to improvements for a large number of Java developers out there. To clarify, I don't want to sound dismissive, I want to make sure that everyone's time and effort is invested wisely. Adding some additional details around Gatherers.mapConcurrent(?)?one of the main reasons that it currently does not participate in Structured Concurrency is because it is a continuous window of concurrent work-in-progress with no "singular join", i.e. it produces results and starts new work whenever possible. This is further "complicated" by requiring that the results are produced on the calling thread to fit in with the evaluation model of the reference implementation of java.util.stream.Stream. As Alan said previously, we'd like for mapConcurrent to better integrate with Structured Concurrency, and we're considering the options there. As a personal anecdote, I had many situations in the evolution of this API where a solution would "intuitively" look better but it made something crucial either impossible or too easy to get wrong without noticing. Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle Confidential ? Oracle Internal ________________________________ From: loom-dev on behalf of Alan Bateman Sent: Monday, 13 October 2025 08:38 To: Jige Yu Cc: loom-dev at openjdk.org Subject: Re: Feedback on Structured Concurrency (JEP 525, 6th Preview) On 13/10/2025 05:22, Jige Yu wrote: > : > > And this is the direction I'd hope the Loom team can more seriously > entertain: put a strong constraint on the API's imperative power, run > a thought experiment to see if the functional variant could offer > sufficient flexibility under the constraint. > I can't tell from your mails if you have read the JEP or not. We've tried to make it clear in every JEP that the goal is not to create the definitive structured concurrency API. This is an on-ramp API intended to "promote a style of concurrent programming that can eliminate common risks from cancellation and shutdown". Its sweet spot is in fan-out scenarios. Its deliberately imperative and kept as simple as possible. There will be other APIs. For example, we would like to bring channels based and other fan-in scenarios into the fold. We would like to eventually expose a lower level APIs for building other structured APIs outside of the JDK. On mapConcurrent. We've been around and around the topic of bringing it into the "structured fold". From your back and forth with Viktor on core-libs-dev then I think you understand the issues. When JEP 485 was preparing to make the gatherers API permanent it had to be decided if mapConcurrent should be pulled out. The conclusion was that it was useful enough as is, and we will look at improving or replacing it in the future. So yes, we of course want this, it's just not in the first API. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From yujige at gmail.com Mon Oct 13 14:31:07 2025 From: yujige at gmail.com (Jige Yu) Date: Mon, 13 Oct 2025 07:31:07 -0700 Subject: Feedback on Structured Concurrency (JEP 525, 6th Preview) In-Reply-To: References: Message-ID: Thank you for your response, Viktor. I appreciate you weighing in and clarifying the context of the design process, particularly your mention of having "exhausted the design space several times over" and the extensive prototyping, including for "functional combinators (composition of N-ary concurrent ANDs and ORs)." I agree with you on the importance of real-world feedback and the need to tease apart API design discussions from observed user problems with a specific design. My feedback is rooted in the latter: user-observed problems with the current Structured Task Scope (STS) API's usability, specifically its complexity for the common "concurrent AND" use case. Before diving into the specific points, I want to say that I do not intend to engage in open-ended design debates. I will not argue when it comes to value judgements. For example, if you tell me the team believe the OR use cases are critical despite I viewing them as niche, that's the difference I wanted to find and it's what I sent this email for. On Mon, Oct 13, 2025 at 2:31?AM Viktor Klang wrote: > Let me just weigh in by saying that these kinds of conversations are not > ideal if the goal is to make change happen?as mentioned previously, > real-world feedback is what we've found (over decades) to be the most > important kind of feedback to make change happen. > > For the current incarnation of Structured Concurrency, Alan and I have > exhausted the design space several times over with tons of different > prototypes, including functional combinators (composition of N-ary > concurrent ANDs and ORs). > > Not only is the current Structured Concurrency APIs *not envisioned* to > be the complete solution, also I believe it to be important to tease apart > questions?are we having a discussion about API design and its trade-offs in > general, or are we discussing user-observed problems with a specific API > design in particular? > My primary argument is not that a better, more complete set of combinators exists, nor is it that the current design *should* support more use cases. In fact, it is the opposite. My point is about *subtraction*?the potential to achieve a simpler, more intuitive API for the 80% use case by *deferring or omitting support for less common use cases*, such as the concurrent OR. - Current Rationale Heard: The current, potentially complex, API is the best trade-off because it handles both ANDs and ORs after exploring all options. - My Question: Has a strategy of *doing less* been thoroughly explored and documented, and if so, *what were the specific trade-offs that compelled the inclusion of OR support, thus requiring a more complex imperative API for the AND use case?* I believe the trade-off discussion I'm missing is the one that directly addresses the strawman I proposed: 1. Introduce a simple, focused API for the common "concurrent AND" pattern (with reasonably overloaded arity): e.g., concurrently(()?fetchArm(),()?fetchLeg(),(arm, leg)??) 2. Defer "concurrent OR" and other niche cases to a separate mechanism, perhaps a *mapConcurrent() gatherer *(or sibling). With your earlier encouragement, I experimented with an alternative gatherer. And it seems to be able to support ORs reasonably. Maybe not the most convenient for all OR cases, but as I said, I view them as niche so a bit inconvenience is fine if it means the main SC API gets to stay simple. If supporting the OR pattern via STS is deemed critical, it might be worth it to document the justification for paying the complexity cost in the primary API. What is the key use case or design constraint that makes it imperative to support ORs *within* the core Structured Task Scope API, instead of *separating*, deferring them? > The reason for separating those two is that the former is rather > open-ended and its outcomes are rather limited in terms of impact, but the > latter can lead to improvements for a large number of Java developers out > there. > > To clarify, I don't want to sound dismissive, I want to make sure that > everyone's time and effort is invested wisely. > > Adding some additional details around Gatherers.mapConcurrent(?)?one of > the main reasons that it currently does not participate in Structured > Concurrency is because it is a continuous window of concurrent > work-in-progress with no "singular join", i.e. it produces results and > starts new work whenever possible. This is further "complicated" by > requiring that the results are produced on the calling thread to fit in > with the evaluation model of the reference implementation of > java.util.stream.Stream. > > As Alan said previously, we'd like for mapConcurrent to better integrate > with Structured Concurrency, and we're considering the options there. > > As a personal anecdote, I had many situations in the evolution of this API > where a solution would "intuitively" look better but it made something > crucial either impossible or too easy to get wrong without noticing. > > Cheers, > ? > > > *Viktor Klang* > Software Architect, Java Platform Group > Oracle > > Confidential ? Oracle Internal > ------------------------------ > *From:* loom-dev on behalf of Alan Bateman < > alan.bateman at oracle.com> > *Sent:* Monday, 13 October 2025 08:38 > *To:* Jige Yu > *Cc:* loom-dev at openjdk.org > *Subject:* Re: Feedback on Structured Concurrency (JEP 525, 6th Preview) > > On 13/10/2025 05:22, Jige Yu wrote: > > : > > > > And this is the direction I'd hope the Loom team can more seriously > > entertain: put a strong constraint on the API's imperative power, run > > a thought experiment to see if the functional variant could offer > > sufficient flexibility under the constraint. > > > I can't tell from your mails if you have read the JEP or not. We've > tried to make it clear in every JEP that the goal is not to create the > definitive structured concurrency API. This is an on-ramp API intended > to "promote a style of concurrent programming that can eliminate common > risks from cancellation and shutdown". Its sweet spot is in fan-out > scenarios. Its deliberately imperative and kept as simple as possible. > There will be other APIs. For example, we would like to bring channels > based and other fan-in scenarios into the fold. We would like to > eventually expose a lower level APIs for building other structured APIs > outside of the JDK. > > On mapConcurrent. We've been around and around the topic of bringing it > into the "structured fold". From your back and forth with Viktor on > core-libs-dev then I think you understand the issues. When JEP 485 was > preparing to make the gatherers API permanent it had to be decided if > mapConcurrent should be pulled out. The conclusion was that it was > useful enough as is, and we will look at improving or replacing it in > the future. So yes, we of course want this, it's just not in the first API. > > -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pchilanomate at openjdk.org Mon Oct 13 14:37:08 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 13 Oct 2025 14:37:08 GMT Subject: RFR: RISC-V: Allow virtual thread preemption on some common class initialization paths In-Reply-To: <4G-7Ql8abR8pJGoyWbkt_NoQ3b4JkxcK8401cQm9Tow=.6ab472a8-225a-4ba5-93a2-bbe4b5245d40@github.com> References: <4G-7Ql8abR8pJGoyWbkt_NoQ3b4JkxcK8401cQm9Tow=.6ab472a8-225a-4ba5-93a2-bbe4b5245d40@github.com> Message-ID: <4DS9IhPgeO9UboD2HLAq-6xbauiqI2fqAhNQ6vvI2Wk=.a784f8b4-b7d5-4119-aa87-4ce4992e5dcb@github.com> On Mon, 13 Oct 2025 02:27:41 GMT, Fei Yang wrote: > This adds RISC-V support for : https://bugs.openjdk.org/browse/JDK-8369238 > > Testing performed on linux-riscv64 platform: > - [x] hs:tier1 - hs:tier3 (release) > - [x] make test TEST="hotspot_loom jdk_loom" (release) > - [x] make test TEST="hotspot_loom jdk_loom" TEST_VM_OPTS="-XX:+VerifyStack -XX:+VerifyContinuations" (fastdebug) Thanks @RealFYang! ------------- Marked as reviewed by pchilanomate (Committer). PR Review: https://git.openjdk.org/loom/pull/222#pullrequestreview-3331887682 From duke at openjdk.org Mon Oct 13 15:12:53 2025 From: duke at openjdk.org (duke) Date: Mon, 13 Oct 2025 15:12:53 GMT Subject: git: openjdk/loom: master: 12 new changesets Message-ID: Changeset: a6f624b0 Branch: master Author: Axel Boldt-Christmas Date: 2025-10-13 07:48:54 +0000 URL: https://git.openjdk.org/loom/commit/a6f624b0743a1e0a3df4e8323c13b0d1fd6d0002 8369468: Rdtsc: Move getCPUIDBrandString_stub into VM_Version stub area Reviewed-by: mgronlun, kvn ! src/hotspot/cpu/x86/rdtsc_x86.cpp ! src/hotspot/cpu/x86/vm_version_x86.cpp ! src/hotspot/cpu/x86/vm_version_x86.hpp Changeset: 1605e839 Branch: master Author: Kevin Walls Date: 2025-10-13 08:13:37 +0000 URL: https://git.openjdk.org/loom/commit/1605e8392e8efa972134a0bf3eecad0ed4f992fa 8369574: Remove javax/management/remote/mandatory/connection/BrokenConnectionTest.java from ProblemList-Virtual.txt Reviewed-by: ayang ! test/jdk/ProblemList-Virtual.txt Changeset: 4728f746 Branch: master Author: Albert Mingkun Yang Date: 2025-10-13 09:23:48 +0000 URL: https://git.openjdk.org/loom/commit/4728f746a89ca7cb787b3d9969f09a80cc92f502 8369571: Parallel: Use ThreadsClaimTokenScope in PSAdjustTask Reviewed-by: fandreuzzi, tschatzl ! src/hotspot/share/gc/parallel/psParallelCompact.cpp Changeset: 98e1d2fa Branch: master Author: Matthias Baesken Date: 2025-10-13 10:13:00 +0000 URL: https://git.openjdk.org/loom/commit/98e1d2fab123befa78342ba53b76a560dddd6385 8369563: Gtest dll_address_to_function_and_library_name has issues with stripped pdb files Reviewed-by: clanger, lucy ! test/hotspot/gtest/runtime/test_os.cpp Changeset: 0af959a3 Branch: master Author: Matthias Baesken Date: 2025-10-13 10:15:39 +0000 URL: https://git.openjdk.org/loom/commit/0af959a340fe68caa47fc476ff861f0e86087162 8369560: Slowdebug build without CDS fails Reviewed-by: mdoerr, kvn ! src/hotspot/share/classfile/vmClasses.cpp ! src/hotspot/share/oops/trainingData.cpp ! src/hotspot/share/oops/trainingData.hpp Changeset: 28460ca3 Branch: master Author: Hamlin Li Date: 2025-10-13 10:32:48 +0000 URL: https://git.openjdk.org/loom/commit/28460ca3305a444238e6edcc80e335be20356e6d 8368897: RISC-V: Cleanup RV_EXT_FEATURE_FLAGS & RV_NON_EXT_FEATURE_FLAGS Reviewed-by: fyang, rehn ! src/hotspot/cpu/riscv/vm_version_riscv.cpp ! src/hotspot/cpu/riscv/vm_version_riscv.hpp ! src/hotspot/os_cpu/linux_riscv/riscv_hwprobe.cpp ! src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp Changeset: 0db47028 Branch: master Author: Darragh Clarke Date: 2025-10-13 11:03:49 +0000 URL: https://git.openjdk.org/loom/commit/0db47028913b64b84116d912876c58b136a9f70c 8368877: Generate Jextract bindings for Kqueue Reviewed-by: alanb, aefimov + src/java.base/macosx/classes/jdk/internal/ffi/generated/errno/errno_h$shared.java + src/java.base/macosx/classes/jdk/internal/ffi/generated/errno/errno_h.java + src/java.base/macosx/classes/jdk/internal/ffi/generated/errno/package-info.java + src/java.base/macosx/classes/jdk/internal/ffi/generated/kqueue/kevent.java + src/java.base/macosx/classes/jdk/internal/ffi/generated/kqueue/kqueue_h$shared.java + src/java.base/macosx/classes/jdk/internal/ffi/generated/kqueue/kqueue_h.java + src/java.base/macosx/classes/jdk/internal/ffi/generated/kqueue/package-info.java + src/java.base/macosx/classes/jdk/internal/ffi/generated/timespec/package-info.java + src/java.base/macosx/classes/jdk/internal/ffi/generated/timespec/timespec.java + src/java.base/macosx/classes/jdk/internal/ffi/generated/timespec/timespec_h$shared.java + src/java.base/macosx/classes/jdk/internal/ffi/generated/timespec/timespec_h.java Changeset: 62fa971f Branch: master Author: Markus Gr?nlund Date: 2025-10-13 11:34:30 +0000 URL: https://git.openjdk.org/loom/commit/62fa971f3116828398294c9d57650c4e0aca7379 8369255: Assess and remedy any unsafe usage of the Semaphores used by JFR Reviewed-by: egahlin ! src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp ! src/hotspot/share/jfr/recorder/service/jfrRecorderService.cpp Changeset: d278043d Branch: master Author: Alexey Ivanov Date: 2025-10-13 12:09:38 +0000 URL: https://git.openjdk.org/loom/commit/d278043ddba0cd9ec3ddf8b490366965f5831a22 8367772: Refactor createUI in PassFailJFrame Reviewed-by: dnguyen, honkar ! test/jdk/java/awt/regtesthelpers/PassFailJFrame.java Changeset: d47e6b71 Branch: master Author: Axel Boldt-Christmas Date: 2025-10-13 12:16:54 +0000 URL: https://git.openjdk.org/loom/commit/d47e6b713c77d9e2f477f05291e8772129a5471c 8369469: Rdtsc: Remove potential races in Rdtsc::initialize Reviewed-by: dholmes, stefank ! src/hotspot/cpu/x86/rdtsc_x86.cpp ! src/hotspot/cpu/x86/rdtsc_x86.hpp ! src/hotspot/share/jfr/utilities/jfrTime.cpp ! src/hotspot/share/utilities/ticks.cpp Changeset: 04968061 Branch: master Author: Emanuel Peter Date: 2025-10-13 13:59:48 +0000 URL: https://git.openjdk.org/loom/commit/0496806102bb621bdd82613d5796651d9655ea1c 8359412: Template-Framework Library: Operations and Expressions Reviewed-by: chagedorn, mhaessig, galder + test/hotspot/jtreg/compiler/igvn/ExpressionFuzzer.java + test/hotspot/jtreg/compiler/lib/template_framework/library/Expression.java + test/hotspot/jtreg/compiler/lib/template_framework/library/Operations.java ! test/hotspot/jtreg/compiler/lib/template_framework/library/PrimitiveType.java + test/hotspot/jtreg/testlibrary_tests/template_framework/examples/TestExpressions.java ! test/hotspot/jtreg/testlibrary_tests/template_framework/examples/TestPrimitiveTypes.java + test/hotspot/jtreg/testlibrary_tests/template_framework/tests/TestExpression.java Changeset: 9feb8f21 Branch: master Author: Patricio Chilano Mateo Date: 2025-10-13 14:07:40 +0000 URL: https://git.openjdk.org/loom/commit/9feb8f21b5d000f8901938f1dde89638c79ca805 8369019: Improve timed-park mechanism in ObjectMonitor for virtual thread support Reviewed-by: dholmes, alanb ! src/hotspot/share/runtime/objectMonitor.cpp ! src/hotspot/share/runtime/objectMonitor.hpp ! src/hotspot/share/runtime/objectMonitor.inline.hpp ! test/jdk/java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java From duke at openjdk.org Mon Oct 13 15:25:45 2025 From: duke at openjdk.org (duke) Date: Mon, 13 Oct 2025 15:25:45 GMT Subject: git: openjdk/loom: fibers: 13 new changesets Message-ID: Changeset: a6f624b0 Branch: fibers Author: Axel Boldt-Christmas Date: 2025-10-13 07:48:54 +0000 URL: https://git.openjdk.org/loom/commit/a6f624b0743a1e0a3df4e8323c13b0d1fd6d0002 8369468: Rdtsc: Move getCPUIDBrandString_stub into VM_Version stub area Reviewed-by: mgronlun, kvn ! src/hotspot/cpu/x86/rdtsc_x86.cpp ! src/hotspot/cpu/x86/vm_version_x86.cpp ! src/hotspot/cpu/x86/vm_version_x86.hpp Changeset: 1605e839 Branch: fibers Author: Kevin Walls Date: 2025-10-13 08:13:37 +0000 URL: https://git.openjdk.org/loom/commit/1605e8392e8efa972134a0bf3eecad0ed4f992fa 8369574: Remove javax/management/remote/mandatory/connection/BrokenConnectionTest.java from ProblemList-Virtual.txt Reviewed-by: ayang ! test/jdk/ProblemList-Virtual.txt Changeset: 4728f746 Branch: fibers Author: Albert Mingkun Yang Date: 2025-10-13 09:23:48 +0000 URL: https://git.openjdk.org/loom/commit/4728f746a89ca7cb787b3d9969f09a80cc92f502 8369571: Parallel: Use ThreadsClaimTokenScope in PSAdjustTask Reviewed-by: fandreuzzi, tschatzl ! src/hotspot/share/gc/parallel/psParallelCompact.cpp Changeset: 98e1d2fa Branch: fibers Author: Matthias Baesken Date: 2025-10-13 10:13:00 +0000 URL: https://git.openjdk.org/loom/commit/98e1d2fab123befa78342ba53b76a560dddd6385 8369563: Gtest dll_address_to_function_and_library_name has issues with stripped pdb files Reviewed-by: clanger, lucy ! test/hotspot/gtest/runtime/test_os.cpp Changeset: 0af959a3 Branch: fibers Author: Matthias Baesken Date: 2025-10-13 10:15:39 +0000 URL: https://git.openjdk.org/loom/commit/0af959a340fe68caa47fc476ff861f0e86087162 8369560: Slowdebug build without CDS fails Reviewed-by: mdoerr, kvn ! src/hotspot/share/classfile/vmClasses.cpp ! src/hotspot/share/oops/trainingData.cpp ! src/hotspot/share/oops/trainingData.hpp Changeset: 28460ca3 Branch: fibers Author: Hamlin Li Date: 2025-10-13 10:32:48 +0000 URL: https://git.openjdk.org/loom/commit/28460ca3305a444238e6edcc80e335be20356e6d 8368897: RISC-V: Cleanup RV_EXT_FEATURE_FLAGS & RV_NON_EXT_FEATURE_FLAGS Reviewed-by: fyang, rehn ! src/hotspot/cpu/riscv/vm_version_riscv.cpp ! src/hotspot/cpu/riscv/vm_version_riscv.hpp ! src/hotspot/os_cpu/linux_riscv/riscv_hwprobe.cpp ! src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp Changeset: 0db47028 Branch: fibers Author: Darragh Clarke Date: 2025-10-13 11:03:49 +0000 URL: https://git.openjdk.org/loom/commit/0db47028913b64b84116d912876c58b136a9f70c 8368877: Generate Jextract bindings for Kqueue Reviewed-by: alanb, aefimov + src/java.base/macosx/classes/jdk/internal/ffi/generated/errno/errno_h$shared.java + src/java.base/macosx/classes/jdk/internal/ffi/generated/errno/errno_h.java + src/java.base/macosx/classes/jdk/internal/ffi/generated/errno/package-info.java + src/java.base/macosx/classes/jdk/internal/ffi/generated/kqueue/kevent.java + src/java.base/macosx/classes/jdk/internal/ffi/generated/kqueue/kqueue_h$shared.java + src/java.base/macosx/classes/jdk/internal/ffi/generated/kqueue/kqueue_h.java + src/java.base/macosx/classes/jdk/internal/ffi/generated/kqueue/package-info.java + src/java.base/macosx/classes/jdk/internal/ffi/generated/timespec/package-info.java + src/java.base/macosx/classes/jdk/internal/ffi/generated/timespec/timespec.java + src/java.base/macosx/classes/jdk/internal/ffi/generated/timespec/timespec_h$shared.java + src/java.base/macosx/classes/jdk/internal/ffi/generated/timespec/timespec_h.java Changeset: 62fa971f Branch: fibers Author: Markus Gr?nlund Date: 2025-10-13 11:34:30 +0000 URL: https://git.openjdk.org/loom/commit/62fa971f3116828398294c9d57650c4e0aca7379 8369255: Assess and remedy any unsafe usage of the Semaphores used by JFR Reviewed-by: egahlin ! src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp ! src/hotspot/share/jfr/recorder/service/jfrRecorderService.cpp Changeset: d278043d Branch: fibers Author: Alexey Ivanov Date: 2025-10-13 12:09:38 +0000 URL: https://git.openjdk.org/loom/commit/d278043ddba0cd9ec3ddf8b490366965f5831a22 8367772: Refactor createUI in PassFailJFrame Reviewed-by: dnguyen, honkar ! test/jdk/java/awt/regtesthelpers/PassFailJFrame.java Changeset: d47e6b71 Branch: fibers Author: Axel Boldt-Christmas Date: 2025-10-13 12:16:54 +0000 URL: https://git.openjdk.org/loom/commit/d47e6b713c77d9e2f477f05291e8772129a5471c 8369469: Rdtsc: Remove potential races in Rdtsc::initialize Reviewed-by: dholmes, stefank ! src/hotspot/cpu/x86/rdtsc_x86.cpp ! src/hotspot/cpu/x86/rdtsc_x86.hpp ! src/hotspot/share/jfr/utilities/jfrTime.cpp ! src/hotspot/share/utilities/ticks.cpp Changeset: 04968061 Branch: fibers Author: Emanuel Peter Date: 2025-10-13 13:59:48 +0000 URL: https://git.openjdk.org/loom/commit/0496806102bb621bdd82613d5796651d9655ea1c 8359412: Template-Framework Library: Operations and Expressions Reviewed-by: chagedorn, mhaessig, galder + test/hotspot/jtreg/compiler/igvn/ExpressionFuzzer.java + test/hotspot/jtreg/compiler/lib/template_framework/library/Expression.java + test/hotspot/jtreg/compiler/lib/template_framework/library/Operations.java ! test/hotspot/jtreg/compiler/lib/template_framework/library/PrimitiveType.java + test/hotspot/jtreg/testlibrary_tests/template_framework/examples/TestExpressions.java ! test/hotspot/jtreg/testlibrary_tests/template_framework/examples/TestPrimitiveTypes.java + test/hotspot/jtreg/testlibrary_tests/template_framework/tests/TestExpression.java Changeset: 9feb8f21 Branch: fibers Author: Patricio Chilano Mateo Date: 2025-10-13 14:07:40 +0000 URL: https://git.openjdk.org/loom/commit/9feb8f21b5d000f8901938f1dde89638c79ca805 8369019: Improve timed-park mechanism in ObjectMonitor for virtual thread support Reviewed-by: dholmes, alanb ! src/hotspot/share/runtime/objectMonitor.cpp ! src/hotspot/share/runtime/objectMonitor.hpp ! src/hotspot/share/runtime/objectMonitor.inline.hpp ! test/jdk/java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java Changeset: 50be4ebf Branch: fibers Author: Patricio Chilano Mateo Date: 2025-10-13 11:13:33 +0000 URL: https://git.openjdk.org/loom/commit/50be4ebf8521e2cb04339465aef6612e80586b2e Merge branch 'master' into fibers ! src/hotspot/share/runtime/objectMonitor.cpp ! test/jdk/ProblemList-Virtual.txt ! src/hotspot/share/runtime/objectMonitor.cpp ! test/jdk/ProblemList-Virtual.txt From forax at univ-mlv.fr Mon Oct 13 17:37:44 2025 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Mon, 13 Oct 2025 19:37:44 +0200 (CEST) Subject: Feedback on Structured Concurrency (JEP 525, 6th Preview) In-Reply-To: References: <1111940277.12978084.1760276580257.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <1615992324.14359732.1760377064603.JavaMail.zimbra@univ-eiffel.fr> > From: "Jige Yu" > To: "Remi Forax" > Cc: "loom-dev" > Sent: Sunday, October 12, 2025 6:49:19 PM > Subject: Re: Feedback on Structured Concurrency (JEP 525, 6th Preview) > Thanks for the quick reply, Remi! > I'll focus on discussing alternatives, which hopefully should also help clarify > my concerns of the current API. > On Sun, Oct 12, 2025 at 6:43 AM Remi Forax < [ mailto:forax at univ-mlv.fr | > forax at univ-mlv.fr ] > wrote: >>> From: "Jige Yu" < [ mailto:yujige at gmail.com | yujige at gmail.com ] > >>> To: "loom-dev" < [ mailto:loom-dev at openjdk.org | loom-dev at openjdk.org ] > >>> Sent: Sunday, October 12, 2025 7:32:33 AM >>> Subject: Feedback on Structured Concurrency (JEP 525, 6th Preview) >>> Hi Project Loom. >>> First and foremost, I want to express my gratitude for the effort that has gone >>> into structured concurrency. API design in this space is notoriously difficult, >>> and this feedback is offered with the greatest respect for the team's work and >>> in the spirit of collaborative refinement. >>> My perspective is that of a developer looking to use Structured Concurrency for >>> common, IO-intensive fan-out operations. My focus is to replace everyday async >>> callback hell, or reactive chains with something simpler and more readable. >>> It will lack depth in the highly specialized concurrent programming area. And I >>> acknowledge this viewpoint may bias my feedback. >> [...] >>> Suggestions for a Simpler Model >>> My preference is that the API for the most common use cases should be more >>> declarative and functional . >>> 1. >>> Simplify the "Gather All" Pattern: The primary "fan-out and gather" use case >>> could be captured in a simple, high-level construct. An average user shouldn't >>> need to learn the wide API surface of StructuredTaskScope + Joiner + the >>> lifecycles. For example: >>> Java >>> // Ideal API for the 80% use case Robot robot = Concurrently.call( >>> () -> fetchArm(), >>> () -> fetchLeg(), >>> (arm, leg) -> new Robot(arm, leg) >>> ); >> I'm curious how you want to type that API, does it work only for two tasks, do >> you have an overload for each arity (2 tasks, 3 tasks, etc). >> And how exceptions are supposed to work given that the type system of Java is >> not able to merge type variable representing exceptions correctly. > Just a handful of overloads. Looking from Google's internal code base, up to 5 > concurrent fanout probably covers 95% of use cases. The other 5% can either > build their own helpers like: > // MoreConcurrency > R concurrently( > Supplier, ..., Supplier, > Function10 combiner) { > return concurrently( // just nest some concurrent calls > () -> concurrently(task1, task2, ..., task5, Tuple5::new), > () -> concurrently(task6, ..., task10, Tuple5::new), > (tuple1, tuple2) -> combiner.apply(tuple1.a(), tuple1.b(), ..., tuple2.e()); > } > Or, they can use the homogeneous mapConcurrent() gatherer, and deal with some > type casting. > In terms of exceptions, directly propagating checked exception across threads > may not always be desirable because their stack trace will be confusing. This > is why traditionally Future throws ExecutionException with the stack traces > chained together. It should be a conscious choice of the developer if they > don't mind losing the extra stack trace. > I was thinking of one of Google's internal compile-time plugins to help with > exception propagation. But before I dive into the details, allow me to clarify > the principle that I implicitly adheres to: > Any Checked Exception Must Be Explicitly Caught or Declared As Throws > There must be no secret pathway where it can become unchecked without the > developer's explicit acknowledgement. > And that is why I'm concerned about the current SC API, where the checked > exception can be thrown in the Callable lambda, not have to be caught. And then > at the call site it has become unchecked. > (well, except maybe InterruptedException, which probably shouldn't have required > the developer to catch and handle) > Now I'll explain what the Google's internal plugin does, it's called > TunnedException, which is an unchecked exception. For streams, it's used like: > try { > return list.stream().map(v -> tunnel(() -> process(v))).toList(); > } catch (TunnelException e) { > try { > // If you forgot a checked exception, compilation will FAIL > throw e.rethrow(IOException.class, InvalidSyntaxException.class); > } catch (IOExeption e) { > ... > } catch (InvalidSyntaxException e) { > ... > } > } > At the javac level, tunnel() expects a Callable, which does allow checked > exceptions to be magically "unchecked" as TunnelException. And at runtime, the > TunnelException will be thrown as is by Stream. > But in the ErrorProne plugin, it will recognize that the special tunnel() call > has suppressed a few checked exception types (in this case, IOException and > InvalidSyntaxException). And then the plugin will validate that within the same > lexical scope, rethrow() with the two exception types must be called. Thus > compile-time enforcement of checked exceptions remains. And at the catch site > we still have the compiler-check about which checked exception that we have > forgotten to catch, or the checked exception type cannot possibly be thrown. > I played with this idea inside Google, using it for this functional > concurrently() flavor of structured concurrency. And it worked out ok: > try { > return Concurrently.call( > () -> tunnel(() -> fetchArm()), > () -> tunnel(() -> fetchLeg()), > (arm, leg) -> new Robot(arm, leg) > ); > } catch (TunnelException e) { > throw e.rethrow(RpcException.class); > // or wrap it in an appropriate application-level exception > } > I'm not saying that the Google's ErrorrProne plugin be adopted verbatim by Loom. > I actually had hoped that the Java team, being the god of Java, can do more, > giving us a more systematic solution to checked exceptions in structured > concurrency. Google's ErrorProne plugin can be considered a baseline, that at > worst, this is what we can do. > That said, it's understandable that this whole > checked-exception-does-not-work-across-abstractions problem is considered an > orthogonal issue and Loom decides it's not in scope. > But even then, it's probably prudent to use Supplier instead of Callable for > fork(), or in this hypothetical functional SC. > The reason I prefer Supplier is that it's consistent with the established > checked exception philosophy, and will force the developer to handle the > checked exceptions. Even if you do want to propagate it in unchecked, it should > be an explicit choice. Either by using plain old try-catch-rethrow, or the > developer (or Project Loom) can provide an explicit "unchecker" helper to help > save boilerplate: > public static Supplier unchecked(Callable task) { > return () -> { > try { > return task.call(); > } catch (RuntimeException e) { > throw e; > } catch (Exception e) { > throw new UncheckedExecutionException(e); > } > }; > } > Then it's only a matter of changing the call site to the following: > return Concurrently.call( > unchecked(() -> fetchArm()), > unchecked(() -> fetchLeg()), > (arm, leg) -> new Robot(arm, leg)); Exceptions management is really really hard in Java, mostly because of checked exceptions and IDE failing to implement the fact that exception should be catch as late as possible. You can use a Supplier or any other functional interfaces of java.util.function to force users to manually deal with exceptions, sadly what i'm seeing is that my students write code that shallow exceptions or throw everything as a RuntimeException (the default behavior of Eclipse and IntelliJ respectively). We have already a way to deal with exceptions in Executor/Callable/Future, the default behavior wraps every exceptions, Yes, you get only one part of the tunneling, you have to write the rethrowing part yourself, but at least that default behavior is better than letting users to deal with exceptions. >>> 1. >>> Separate Race Semantics into Composable Operations: The "race" pattern feels >>> like a distinct use case that could be implemented more naturally using >>> composable, functional APIs like Stream gatherers, rather than requiring a >>> specialized API at all. For example, if mapConcurrent() fully embraced >>> structured concurrency, guaranteeing fail-fast and happens-before, a >>> recoverable race could be written explicitly: >>> Java >>> // Pseudo-code for a recoverable race using a stream gatherer T race >>> (Collection> tasks, int maxConcurrency) { var exceptions = new >>> ConcurrentLinkedQueue(); return tasks.stream() >>> .gather(mapConcurrent(maxConcurrency, task -> { try { return task.call(); >>> } catch (RpcException e) { if (isRecoverable(e)) { // Selectively recover >>> exceptions.add(e); return null ; // Suppress and continue } throw new >>> RuntimeException(e); // Fail fast on non-recoverable } >>> })) >>> .filter(Objects::nonNull) >>> .findFirst() // Short-circuiting and cancellation .orElseThrow(() -> new >>> AggregateException(exceptions)); >>> } >>> While this is slightly more verbose than the JEP example, it's familiar Stream >>> semantics that people have already learned, and it offers explicit control over >>> which exceptions are recoverable versus fatal. The boilerplate for exception >>> aggregation could easily be wrapped in a helper method. >> Several points : >> - I believe the current STS API has no way to deal with if the exception is >> recoverable or not because it's far easier to do that at the end of the >> callable. >> Your example becomes : >> sts.fork(() -> { >> try { >> taskCall(); >> } catch(RPCException e) { >> ... >> } >> }); > Yes. Though my point is that this now becomes an opt-in . It should be an > opt-out. Swallowing exceptions should not be the default behavior. > And for the anySuccessfulOrThrow() joiner, I don't know it helps much because > even if it's not recoverable,you'd still throw in the lambda, and it will still > be swallowed by the joiner. anySuccessfulResultOrThrow() has the semantics of stopping the STS when one result is found. So you may never run some callables, so you may never know if a Callable fails or not. Given that semantics, not propagating the exceptions through the joiner seems the right thing to do, again, you are not even sure that all callables will run. >> - You do not want to post the result/exception of a task into a concurrent data >> structure, i think the idea of the STS API in this case is to fork all the >> tasks and then take a look to all the subtasks. > It probably is. What I was trying to say is that the mapConcurrent() approach > feels more natural, and safer. >> I believe it's more efficient because there is no CAS to be done if the main >> thread take a look to the subtasks afterward than if the joiner tries to >> maintain a concurrent data structure. > This may be my blind spot. I've always assumed that structured concurrency where > I need to fan out IO-blocking tasks isn't usually the hot path. Even with > virtual threads, context switching still isn't cheap enough to worry about > low-level micro optimizations ? >>> 1. >>> Reserve Complexity for Complex Cases: The low-level StructuredTaskScope and its >>> policy mechanism are powerful tools. However, they should be positioned as the >>> "expert-level" API for building custom frameworks. Or perhaps just keep them in >>> the traditional ExecutorService API. The everyday developer experience should >>> be centered around simpler, declarative constructs that cover the most frequent >>> needs. >> For me, that's why you have an open Joiner interface for expert and already >> available Joiner (like all.../any...) that are more for everyday developers. > Yeah. My point is the current Joiner interface looks too much like an inviting > couch that an average developer would immediately start to think: "oh I have a > use case I may be able to implement by overriding onComplete()!". But you don't > really need it . > In an analogy, there is Stream API. Most of us would just use the Steam API, > passing in lambdas, collectors etc. We would not think of implementing our own > BaseStream, which imho would have been an unfortunate distraction. Wrong guy, i've implemented quite a lot of spliterators (the abstraction used by the Stream implementation). More seriously, yes you may implement onComplete or the Predicate of allUntil() when you should not, but it's like implementing a Spliterator, not a lot of people will do it anyway, it's clearly marked for expert. > InterruptedException > Lastly, my view of InterruptedException is like what you've said: it being a > checked exception is unfortunate. It forces people to catch it, which then > makes it easier to make the mistake of forgetting to re-interrupt the thread. > And actually, few people even understand it (where it comes from, what triggers > it,what needs to be done). > Even if you do painstakingly declare throws InterruptedException all the way up > the call stack, as the usual best practice suggests, the end result is still > just as if it were unchecked in the first place, only that way it wouldn't have > mandated so much maintenance effort of the developers: the top-level handler > catch and handle it once and for all. > So I'd consider it a plus if the SC API hides away InterruptedException. Heck, > mapConcurrent() already hides it away without forcing users to catch it. > If you expect average users to mis-handle it, the better alternative may be to > handle it for them already, including perhaps re-interrupting the thread, and > turning it into an UncheckedInterruptedException, so that most developers won't > be given the chance to make the mistake. Again, you can think that InterruptedException should not be a checked exception, i will go even further saying Java should not have checked exceptions, but this is not the kind of fix you should do in an API, it should be done at the language level. It's more important to have an API that integrate seamlessly with the rest of Java, hence using InterruptedException when a blocking join() is interrupted. regards, R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: From dreamlike.vertx at gmail.com Mon Oct 13 17:52:06 2025 From: dreamlike.vertx at gmail.com (Mengyang Li) Date: Tue, 14 Oct 2025 01:52:06 +0800 Subject: Scheduler API Feedback In-Reply-To: <5a78031c-ce4a-4d46-9a41-11eb9c50a598@oracle.com> References: <5a78031c-ce4a-4d46-9a41-11eb9c50a598@oracle.com> Message-ID: Hello @loom-dev When reading kotlin coroutine code: https://github.com/Kotlin/kotlinx.coroutines/blob/8c27d51025d56a7b8de8eec2fb234b0094ce84f1/kotlinx-coroutines-core/common/src/Delay.kt#L9 https://github.com/Kotlin/kotlinx.coroutines/blob/8c27d51025d56a7b8de8eec2fb234b0094ce84f1/kotlinx-coroutines-core/common/src/Delay.kt#L149 I came up with a new idea ? what if we provide an additional Delay interface? If the current scheduler implements this interface, we can use the scheduler?s own delay method. Otherwise, we fall back to `DelayedTaskSchedulers.schedule`. Currently, Loom only optimizes ForkJoinPool for this case. ``` java VirtualThreadScheduler scheduler(boolean revealBuiltin) { if (scheduler instanceof BuiltinDefaultScheduler builtin && !revealBuiltin) { return builtin.externalView(); } else { return scheduler; } } ``` But if I use Netty?s EventLoop as the scheduler, being able to implement delay based on the event loop would be fantastic. Best regards, Mengyang Li Alan Bateman ?2025?10?9??? 01:44??? > > > On 08/10/2025 15:57, Mengyang Li wrote: > > > ``` > > Console output: > ``` bash > WARNING: Using custom default scheduler, this is an experimental feature! > class java.lang.Thread > VirtualThread[#27,VirtualThreadA]/runnable RUNNABLE currentThread > Thread[#3,main,5,main] current is virtual false > java.lang.RuntimeException > at > io.github.dreamlike.CustomerVirtualThreadScheduler.execute(CustomerVirtualThreadScheduler.java:16) > at > java.base/java.lang.VirtualThread.submitRunContinuation(VirtualThread.java:367) > at > java.base/java.lang.VirtualThread.externalSubmitRunContinuationOrThrow(VirtualThread.java:456) > at java.base/java.lang.VirtualThread.start(VirtualThread.java:734) > at java.base/java.lang.VirtualThread.start(VirtualThread.java:745) > at > java.base/java.lang.ThreadBuilders$VirtualThreadBuilder.start(ThreadBuilders.java:257) > at io.github.dreamlike.VTMain.main(VTMain.java:14) > ``` > > After checking the relevant code, it seems that execution goes through the *first > branch* below. > > This behavior doesn?t appear to align with the semantics of a custom > scheduler ? the nested virtual thread is submitted directly to > ct.getPool() instead of going through > CustomerVirtualThreadScheduler::execute. > > Thanks for the mail. You are correct. There is confusion between the > "custom default scheduler" and the "built-in default scheduler" when the > former delegates to the latter. I'll sort it out. > > -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yujige at gmail.com Mon Oct 13 23:48:00 2025 From: yujige at gmail.com (Jige Yu) Date: Mon, 13 Oct 2025 16:48:00 -0700 Subject: Feedback on Structured Concurrency (JEP 525, 6th Preview) In-Reply-To: <1615992324.14359732.1760377064603.JavaMail.zimbra@univ-eiffel.fr> References: <1111940277.12978084.1760276580257.JavaMail.zimbra@univ-eiffel.fr> <1615992324.14359732.1760377064603.JavaMail.zimbra@univ-eiffel.fr> Message-ID: On Mon, Oct 13, 2025 at 10:37?AM wrote: > > > ------------------------------ > > *From: *"Jige Yu" > *To: *"Remi Forax" > *Cc: *"loom-dev" > *Sent: *Sunday, October 12, 2025 6:49:19 PM > *Subject: *Re: Feedback on Structured Concurrency (JEP 525, 6th Preview) > > Thanks for the quick reply, Remi! > I'll focus on discussing alternatives, which hopefully should also help > clarify my concerns of the current API. > > On Sun, Oct 12, 2025 at 6:43?AM Remi Forax wrote: > >> >> >> ------------------------------ >> >> *From: *"Jige Yu" >> *To: *"loom-dev" >> *Sent: *Sunday, October 12, 2025 7:32:33 AM >> *Subject: *Feedback on Structured Concurrency (JEP 525, 6th Preview) >> >> Hi Project Loom.First and foremost, I want to express my gratitude for >> the effort that has gone into structured concurrency. API design in this >> space is notoriously difficult, and this feedback is offered with the >> greatest respect for the team's work and in the spirit of collaborative >> refinement. >> >> My perspective is that of a developer looking to use Structured >> Concurrency for common, IO-intensive fan-out operations. My focus is to >> replace everyday async callback hell, or reactive chains with something >> simpler and more readable. >> >> It will lack depth in the highly specialized concurrent programming area. >> And I acknowledge this viewpoint may bias my feedback. >> ------------------------------ >> >> [...] >> >> *Suggestions for a Simpler Model* >> >> My preference is that the API for the most common use cases should be >> more *declarative and functional*. >> >> 1. >> >> *Simplify the "Gather All" Pattern:* The primary "fan-out and gather" >> use case could be captured in a simple, high-level construct. An average >> user shouldn't need to learn the wide API surface of StructuredTaskScope + >> Joiner + the lifecycles. For example: >> Java >> >> // Ideal API for the 80% use case >> Robot robot = Concurrently.call( >> () -> fetchArm(), >> () -> fetchLeg(), >> (arm, leg) -> new Robot(arm, leg) >> ); >> >> >> >> I'm curious how you want to type that API, does it work only for two >> tasks, do you have an overload for each arity (2 tasks, 3 tasks, etc). >> And how exceptions are supposed to work given that the type system of >> Java is not able to merge type variable representing exceptions correctly. >> > > > Just a handful of overloads. Looking from Google's internal code base, up > to 5 concurrent fanout probably covers 95% of use cases. The other 5% can > either build their own helpers like: > > // MoreConcurrency > R concurrently( > Supplier, ..., Supplier, > Function10 combiner) { > return concurrently( // just nest some concurrent calls > () -> concurrently(task1, task2, ..., task5, Tuple5::new), > () -> concurrently(task6, ..., task10, Tuple5::new), > (tuple1, tuple2) -> combiner.apply(tuple1.a(), tuple1.b(), ..., tuple2.e()); > } > > > Or, they can use the homogeneous mapConcurrent() gatherer, and deal with > some type casting. > > In terms of exceptions, directly propagating checked exception across > threads may not always be desirable because their stack trace will be > confusing. This is why traditionally Future throws ExecutionException with > the stack traces chained together. It should be a conscious choice of the > developer if they don't mind losing the extra stack trace. > > I was thinking of one of Google's internal compile-time plugins to help > with exception propagation. But before I dive into the details, allow me to > clarify the principle that I implicitly adheres to: > > *Any Checked Exception Must Be Explicitly Caught or Declared As Throws* > > There must be no secret pathway where it can become unchecked without the > developer's explicit acknowledgement. > > And that is why I'm concerned about the current SC API, where the checked > exception can be thrown in the Callable lambda, not have to be caught. And > then at the call site it has become unchecked. > > (well, except maybe InterruptedException, which probably shouldn't have > required the developer to catch and handle) > > Now I'll explain what the Google's internal plugin does, it's called > TunnedException, which is an unchecked exception. For streams, it's used > like: > > try { > return list.stream().map(v -> tunnel(() -> process(v))).toList(); > } catch (TunnelException e) { > try { > // If you forgot a checked exception, compilation will FAIL > > throw e.rethrow(IOException.class, InvalidSyntaxException.class); > } catch (IOExeption e) { > ... > } catch (InvalidSyntaxException e) { > ... > } > } > > > At the javac level, tunnel() expects a Callable, which does allow checked > exceptions to be magically "unchecked" as TunnelException. And at runtime, > the TunnelException will be thrown as is by Stream. > > But in the ErrorProne plugin, it will recognize that the special tunnel() call > has suppressed a few checked exception types (in this case, IOException and > InvalidSyntaxException). And then the plugin will validate that within the > same lexical scope, rethrow() with the two exception types must be called. > Thus compile-time enforcement of checked exceptions remains. And at the > catch site we still have the compiler-check about which checked exception > that we have forgotten to catch, or the checked exception type cannot > possibly be thrown. > > I played with this idea inside Google, using it for this functional > concurrently() flavor of structured concurrency. And it worked out ok: > > try { > return Concurrently.call( > () -> tunnel(() -> fetchArm()), > () -> tunnel(() -> fetchLeg()), > (arm, leg) -> new Robot(arm, leg) > ); > } catch (TunnelException e) { > throw e.rethrow(RpcException.class); > // or wrap it in an appropriate application-level exception > } > > > I'm not saying that the Google's ErrorrProne plugin be adopted verbatim by > Loom. I actually had hoped that the Java team, being the god of Java, can > do more, giving us a more systematic solution to checked exceptions in > structured concurrency. Google's ErrorProne plugin can be considered a > baseline, that at worst, this is what we can do. > > That said, it's understandable that this whole > checked-exception-does-not-work-across-abstractions problem is considered > an orthogonal issue and Loom decides it's not in scope. > > But even then, it's probably prudent to use Supplier instead of Callable > for fork(), or in this hypothetical functional SC. > > The reason I prefer Supplier is that it's consistent with the established > checked exception philosophy, and will force the developer to handle the > checked exceptions. Even if you do want to propagate it in unchecked, it > should be an explicit choice. Either by using plain old try-catch-rethrow, > or the developer (or Project Loom) can provide an explicit "unchecker" > helper to help save boilerplate: > > public static Supplier unchecked(Callable task) { > return () -> { > try { > return task.call(); > } catch (RuntimeException e) { > throw e; > } catch (Exception e) { > throw new UncheckedExecutionException(e); > } > }; > } > > Then it's only a matter of changing the call site to the following: > > return Concurrently.call( > unchecked(() -> fetchArm()), > unchecked(() -> fetchLeg()), > (arm, leg) -> new Robot(arm, leg)); > > > Exceptions management is really really hard in Java, mostly because of > checked exceptions and IDE failing to implement the fact that exception > should be catch as late as possible. > > You can use a Supplier or any other functional interfaces of > java.util.function to force users to manually deal with exceptions, sadly > what i'm seeing is that my students write code that shallow exceptions or > throw everything as a RuntimeException (the default behavior of Eclipse and > IntelliJ respectively). > > We have already a way to deal with exceptions in Executor/Callable/Future, > the default behavior wraps every exceptions, > Yes, you get only one part of the tunneling, you have to write the > rethrowing part yourself, but at least that default behavior is better than > letting users to deal with exceptions. > Agreed that checked exception management is hard. But by using Function/Supplier there is at least a consistency card: it will be the same user experience as Stream. Users still have to catch checked exceptions in the lambdas, but they have to do that already with streams anyways. And as you said: it's important to have the API integrate seamlessly with the rest of Java. So sticking to the same precedent of Stream, and not allow checked exceptions to sneakily become unchecked, would seem like a safe bet. > > > >> 1. >> >> *Separate Race Semantics into Composable Operations:* The "race" >> pattern feels like a distinct use case that could be implemented more >> naturally using composable, functional APIs like Stream gatherers, rather >> than requiring a specialized API at all. For example, if >> mapConcurrent() fully embraced structured concurrency, guaranteeing >> fail-fast and happens-before, a recoverable race could be written >> explicitly: >> Java >> >> // Pseudo-code for a recoverable race using a stream gatherer >> T race(Collection> tasks, int maxConcurrency){ >> var exceptions = new ConcurrentLinkedQueue(); >> return tasks.stream() >> .gather(mapConcurrent(maxConcurrency, task -> { >> try { >> return task.call(); >> } catch (RpcException e) { >> if (isRecoverable(e)) { // Selectively recover >> exceptions.add(e); >> return null; // Suppress and continue >> } >> throw new RuntimeException(e); // Fail fast on non-recoverable >> } >> })) >> .filter(Objects::nonNull) >> .findFirst() // Short-circuiting and cancellation >> .orElseThrow(() -> new AggregateException(exceptions)); >> } >> >> While this is slightly more verbose than the JEP example, it's >> familiar Stream semantics that people have already learned, and it offers >> explicit control over which exceptions are recoverable versus fatal. The >> boilerplate for exception aggregation could easily be wrapped in a helper >> method. >> >> >> Several points : >> - I believe the current STS API has no way to deal with if the exception >> is recoverable or not because it's far easier to do that at the end of the >> callable. >> Your example becomes : >> >> sts.fork(() -> { >> try { >> taskCall(); >> } catch(RPCException e) { >> ... >> } >> }); >> >> Yes. Though my point is that this now becomes an *opt-in*. It should be > an opt-out. Swallowing exceptions should not be the default behavior. > > And for the anySuccessfulOrThrow() joiner, I don't know it helps much > because even if it's not recoverable,you'd still throw in the lambda, and > it will still be swallowed by the joiner. > > > anySuccessfulResultOrThrow() has the semantics of stopping the STS when > one result is found. > So you may never run some callables, so you may never know if a Callable > fails or not. > > Given that semantics, not propagating the exceptions through the joiner > seems the right thing to do, > again, you are not even sure that all callables will run. > This is inconsistent with the fail-fast semantics we get from Streams though. list.parallelStream() .map(item -> processAndMayThrow(item)) .findAny(); It still truthfully throws whatever exception that was thrown before the first successful item was found. Sure, you can't predict which item will be processed. But failures that have already happened cannot be ignored. Otherwise, unexpected fatal errors won't be reported until a success is found. If the success takes a long time, or if it blocks and waits for things, it can defeat fail fast, or even hang the program. A throttled error won't stop the program from flooding the server; a security audit error won't stop the subtasks from doing whatever bad things they would be doing. > >> - You do not want to post the result/exception of a task into a >> concurrent data structure, i think the idea of the STS API in this case is >> to fork all the tasks and then take a look to all the subtasks. >> > > It probably is. What I was trying to say is that the mapConcurrent() > approach feels more natural, and safer. > > >> I believe it's more efficient because there is no CAS to be done if the >> main thread take a look to the subtasks afterward than if the joiner tries >> to maintain a concurrent data structure. >> >> This may be my blind spot. I've always assumed that structured > concurrency where I need to fan out IO-blocking tasks isn't usually the hot > path. Even with virtual threads, context switching still isn't cheap enough > to worry about low-level micro optimizations ? > > >> 1. >> >> *Reserve Complexity for Complex Cases:* The low-level >> StructuredTaskScope and its policy mechanism are powerful tools. >> However, they should be positioned as the "expert-level" API for building >> custom frameworks. Or perhaps just keep them in the traditional >> ExecutorService API. The everyday developer experience should be centered >> around simpler, declarative constructs that cover the most frequent needs. >> >> >> For me, that's why you have an open Joiner interface for expert and >> already available Joiner (like all.../any...) that are more for everyday >> developers. >> >> > Yeah. My point is the current Joiner interface looks too much like an > inviting couch that an average developer would immediately start to think: > "oh I have a use case I may be able to implement by overriding > onComplete()!". But *you don't really need it*. > > In an analogy, there is Stream API. Most of us would just use the Steam > API, passing in lambdas, collectors etc. We would not think of implementing > our own BaseStream, which imho would have been an unfortunate distraction. > > > Wrong guy, i've implemented quite a lot of spliterators (the abstraction > used by the Stream implementation). > > More seriously, yes you may implement onComplete or the Predicate of > allUntil() when you should not, but it's like implementing a Spliterator, > not a lot of people will do it anyway, it's clearly marked for expert. > > > > ------------------------------ > *InterruptedException* > Lastly, my view of InterruptedException is like what you've said: it being > a checked exception is unfortunate. It forces people to catch it, which > then makes it easier to make the mistake of forgetting to re-interrupt the > thread. And actually, few people even understand it (where it comes from, > what triggers it,what needs to be done). > > Even if you do painstakingly declare throws InterruptedException all the > way up the call stack, as the usual best practice suggests, the end result > is still just as if it were unchecked in the first place, only that way it > wouldn't have mandated so much maintenance effort of the developers: the > top-level handler catch and handle it once and for all. > > So I'd consider it a plus if the SC API hides away InterruptedException. > Heck, mapConcurrent() already hides it away without forcing users to catch > it. > > If you expect average users to mis-handle it, the better alternative may > be to handle it for them already, including perhaps re-interrupting the > thread, and turning it into an UncheckedInterruptedException, so that most > developers won't be given the chance to make the mistake. > > > Again, you can think that InterruptedException should not be a checked > exception, i will go even further saying Java should not have checked > exceptions, > but this is not the kind of fix you should do in an API, it should be done > at the language level. > It's more important to have an API that integrate seamlessly with the rest > of Java, hence using InterruptedException when a blocking join() is > interrupted. > Personally, I like mapConcurrent()'s model. It doesn't throw InterruptedException, but it interrupts the subtask threads, and leaves it to the subtask lambdas to catch and respond to IE. That to me seems to be reasonable. > > regards, > R?mi > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fyang at openjdk.org Tue Oct 14 01:41:39 2025 From: fyang at openjdk.org (Fei Yang) Date: Tue, 14 Oct 2025 01:41:39 GMT Subject: RFR: RISC-V: Allow virtual thread preemption on some common class initialization paths [v2] In-Reply-To: <4G-7Ql8abR8pJGoyWbkt_NoQ3b4JkxcK8401cQm9Tow=.6ab472a8-225a-4ba5-93a2-bbe4b5245d40@github.com> References: <4G-7Ql8abR8pJGoyWbkt_NoQ3b4JkxcK8401cQm9Tow=.6ab472a8-225a-4ba5-93a2-bbe4b5245d40@github.com> Message-ID: <1x9GkvUGV-OnT0LBQQkVuDaarRPSDYdn4X__sp5lhQY=.072c0690-3aa4-49f9-997a-121d6f542c50@github.com> > This adds RISC-V support for : https://bugs.openjdk.org/browse/JDK-8369238 > > Testing performed on linux-riscv64 platform: > - [x] hs:tier1 - hs:tier3 (release) > - [x] make test TEST="hotspot_loom jdk_loom" (release) > - [x] make test TEST="hotspot_loom jdk_loom" TEST_VM_OPTS="-XX:+VerifyStack -XX:+VerifyContinuations" (fastdebug) Fei Yang 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 two additional commits since the last revision: - Merge remote-tracking branch 'upstream/fibers' into 8369238-riscv64 - RISC-V: Allow virtual thread preemption on some common class initialization paths ------------- Changes: - all: https://git.openjdk.org/loom/pull/222/files - new: https://git.openjdk.org/loom/pull/222/files/6f1bb94a..0e1b94f9 Webrevs: - full: https://webrevs.openjdk.org/?repo=loom&pr=222&range=01 - incr: https://webrevs.openjdk.org/?repo=loom&pr=222&range=00-01 Stats: 3512 lines in 40 files changed: 3199 ins; 156 del; 157 mod Patch: https://git.openjdk.org/loom/pull/222.diff Fetch: git fetch https://git.openjdk.org/loom.git pull/222/head:pull/222 PR: https://git.openjdk.org/loom/pull/222 From fyang at openjdk.org Tue Oct 14 07:28:52 2025 From: fyang at openjdk.org (Fei Yang) Date: Tue, 14 Oct 2025 07:28:52 GMT Subject: RFR: RISC-V: Allow virtual thread preemption on some common class initialization paths [v2] In-Reply-To: <4DS9IhPgeO9UboD2HLAq-6xbauiqI2fqAhNQ6vvI2Wk=.a784f8b4-b7d5-4119-aa87-4ce4992e5dcb@github.com> References: <4G-7Ql8abR8pJGoyWbkt_NoQ3b4JkxcK8401cQm9Tow=.6ab472a8-225a-4ba5-93a2-bbe4b5245d40@github.com> <4DS9IhPgeO9UboD2HLAq-6xbauiqI2fqAhNQ6vvI2Wk=.a784f8b4-b7d5-4119-aa87-4ce4992e5dcb@github.com> Message-ID: On Mon, 13 Oct 2025 14:34:18 GMT, Patricio Chilano Mateo wrote: >> Fei Yang 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 two additional commits since the last revision: >> >> - Merge remote-tracking branch 'upstream/fibers' into 8369238-riscv64 >> - RISC-V: Allow virtual thread preemption on some common class initialization paths > > Thanks @RealFYang! @pchilano : Thanks for the review! ------------- PR Comment: https://git.openjdk.org/loom/pull/222#issuecomment-3400460799 From duke at openjdk.org Tue Oct 14 07:31:22 2025 From: duke at openjdk.org (duke) Date: Tue, 14 Oct 2025 07:31:22 GMT Subject: RFR: RISC-V: Allow virtual thread preemption on some common class initialization paths [v2] In-Reply-To: <1x9GkvUGV-OnT0LBQQkVuDaarRPSDYdn4X__sp5lhQY=.072c0690-3aa4-49f9-997a-121d6f542c50@github.com> References: <4G-7Ql8abR8pJGoyWbkt_NoQ3b4JkxcK8401cQm9Tow=.6ab472a8-225a-4ba5-93a2-bbe4b5245d40@github.com> <1x9GkvUGV-OnT0LBQQkVuDaarRPSDYdn4X__sp5lhQY=.072c0690-3aa4-49f9-997a-121d6f542c50@github.com> Message-ID: On Tue, 14 Oct 2025 01:41:39 GMT, Fei Yang wrote: >> This adds RISC-V support for : https://bugs.openjdk.org/browse/JDK-8369238 >> >> Testing performed on linux-riscv64 platform: >> - [x] hs:tier1 - hs:tier3 (release) >> - [x] make test TEST="hotspot_loom jdk_loom" (release) >> - [x] make test TEST="hotspot_loom jdk_loom" TEST_VM_OPTS="-XX:+VerifyStack -XX:+VerifyContinuations" (fastdebug) > > Fei Yang 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 two additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/fibers' into 8369238-riscv64 > - RISC-V: Allow virtual thread preemption on some common class initialization paths @RealFYang Your change (at version 0e1b94f9b643eb862dfa2e8565b8770db7a32930) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/loom/pull/222#issuecomment-3400468729 From fyang at openjdk.org Tue Oct 14 07:37:24 2025 From: fyang at openjdk.org (Fei Yang) Date: Tue, 14 Oct 2025 07:37:24 GMT Subject: Integrated: RISC-V: Allow virtual thread preemption on some common class initialization paths In-Reply-To: <4G-7Ql8abR8pJGoyWbkt_NoQ3b4JkxcK8401cQm9Tow=.6ab472a8-225a-4ba5-93a2-bbe4b5245d40@github.com> References: <4G-7Ql8abR8pJGoyWbkt_NoQ3b4JkxcK8401cQm9Tow=.6ab472a8-225a-4ba5-93a2-bbe4b5245d40@github.com> Message-ID: On Mon, 13 Oct 2025 02:27:41 GMT, Fei Yang wrote: > This adds RISC-V support for : https://bugs.openjdk.org/browse/JDK-8369238 > > Testing performed on linux-riscv64 platform: > - [x] hs:tier1 - hs:tier3 (release) > - [x] make test TEST="hotspot_loom jdk_loom" (release) > - [x] make test TEST="hotspot_loom jdk_loom" TEST_VM_OPTS="-XX:+VerifyStack -XX:+VerifyContinuations" (fastdebug) This pull request has now been integrated. Changeset: 74572525 Author: Fei Yang Committer: Alan Bateman URL: https://git.openjdk.org/loom/commit/74572525842ac46916924240636529f109b03779 Stats: 186 lines in 11 files changed: 131 ins; 23 del; 32 mod RISC-V: Allow virtual thread preemption on some common class initialization paths Reviewed-by: pchilanomate ------------- PR: https://git.openjdk.org/loom/pull/222 From alan.bateman at oracle.com Tue Oct 14 08:05:40 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Tue, 14 Oct 2025 09:05:40 +0100 Subject: Scheduler API Feedback In-Reply-To: References: <5a78031c-ce4a-4d46-9a41-11eb9c50a598@oracle.com> Message-ID: <761515b0-b937-40fc-bf3f-721802b57304@oracle.com> On 13/10/2025 18:52, Mengyang Li wrote: > : > > I came up with a new idea ? what if we provide an additional Delay > interface? > > If the current scheduler implements this interface, we can use the > scheduler?s own delay method. > > Otherwise, we fall back to `DelayedTaskSchedulers.schedule`. > > Currently, Loom only optimizes ForkJoinPool for this case. > > ``` java > > VirtualThreadScheduler scheduler(boolean revealBuiltin) { > ? ? if (scheduler instanceof BuiltinDefaultScheduler builtin && > !revealBuiltin) { > ? ? ? ? return builtin.externalView(); > ? ? } else { > ? ? ? ? return scheduler; > ? ? } > } > > ``` > > But if I use Netty?s EventLoop as the scheduler, being able to > implement delay based on the event loop would be fantastic. > For now, the experimental/prototype for custom schedulers will only call out to the custom scheduler to execute a task that starts or continue a virtual thread. The VirtualThreadScheduler interface could be extended to allow the custom scheduler to take on delayed tasks but these are not virtual thread tasks, they are tasks to support timed-Object.wait for timed-park. You are right that a SPTE based implementation is used in the JDK when there is a custom scheduler configured. Is this causing an issue? Timeouts are usually cancelled, >99% in many cases, so I'd like to understand if your workloads are different, maybe you have more scenarios where a timeout occurs? -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Thu Oct 16 09:34:40 2025 From: duke at openjdk.org (duke) Date: Thu, 16 Oct 2025 09:34:40 GMT Subject: git: openjdk/loom: fibers: 52 new changesets Message-ID: <0c9ae348-3f8b-482d-9bb5-e8e7b28c1db5@openjdk.org> Changeset: f292d7c6 Branch: fibers Author: Thomas Schatzl Date: 2025-10-13 14:51:08 +0000 URL: https://git.openjdk.org/loom/commit/f292d7c66c6279f929eb37ffcc1857a269f72e3d 8048180: G1: Eager reclaim of humongous objects with references Co-authored-by: Ivan Walulya Reviewed-by: iwalulya, ayang ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1HeapVerifier.cpp ! src/hotspot/share/gc/g1/g1HeapVerifier.hpp ! src/hotspot/share/gc/g1/g1OopClosures.inline.hpp ! src/hotspot/share/gc/g1/g1RemSet.cpp ! src/hotspot/share/gc/g1/g1RemSetTrackingPolicy.cpp ! src/hotspot/share/gc/g1/g1YoungCollector.cpp ! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp ! test/hotspot/jtreg/gc/g1/TestEagerReclaimHumongousRegions.java - test/hotspot/jtreg/gc/g1/TestEagerReclaimHumongousRegionsClearMarkBits.java Changeset: 551cd03b Branch: fibers Author: Xiaolong Peng Date: 2025-10-13 15:03:01 +0000 URL: https://git.openjdk.org/loom/commit/551cd03b99feb34d98703b7d04571f92f83f2471 8369611: Remove safepoint synchronization from ParallelScavengeHeap and SerialHeap Reviewed-by: kbarrett, ayang, shade, tschatzl ! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp ! src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp ! src/hotspot/share/gc/serial/serialHeap.cpp ! src/hotspot/share/gc/serial/serialHeap.hpp Changeset: b83e7939 Branch: fibers Author: Henry Jen Date: 2025-10-13 15:05:53 +0000 URL: https://git.openjdk.org/loom/commit/b83e7939dd9401314f2351a9fefd1e212387c6e5 8347007: --strip-debug removes parameter names included with -parameters Reviewed-by: alanb ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/DefaultStripDebugPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/StripJavaDebugAttributesPlugin.java ! test/jdk/tools/jlink/plugins/DefaultStripDebugPluginTest.java + test/jdk/tools/jlink/plugins/StripParameterNamesTest.java Changeset: 16681623 Branch: fibers Author: Erik Gahlin Date: 2025-10-13 15:17:36 +0000 URL: https://git.openjdk.org/loom/commit/166816231988dd94f644a7b892cdddf0fea94570 8369510: JFR: Remove flush handler from Dispatcher lookup Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/Dispatcher.java Changeset: 8b1cf8ee Branch: fibers Author: Brian Burkhalter Date: 2025-10-13 16:03:43 +0000 URL: https://git.openjdk.org/loom/commit/8b1cf8eefe4e3439dba983bced06d55a6ca7da4e 8368098: (aio) java/nio/channels/Channels/AsyncCloseStreams.java fails in junit timeout Reviewed-by: alanb ! test/jdk/java/nio/channels/Channels/AsyncCloseStreams.java Changeset: 9b1633de Branch: fibers Author: Ravi.Patel8 Committer: Harshitha Onkar Date: 2025-10-13 16:10:48 +0000 URL: https://git.openjdk.org/loom/commit/9b1633ded0e1d952ef13c054b6c507149d22f8cd 8368606: Printer lookup returns empty on AIX platform due to uninitialized results list Reviewed-by: honkar, serb ! src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java Changeset: 1d6cafdc Branch: fibers Author: Justin Lu Date: 2025-10-13 16:11:09 +0000 URL: https://git.openjdk.org/loom/commit/1d6cafdc5244960ddec2fd82b8454c6c3cafe022 8369452: Locale.Builder.setLanguageTag(String) does not clear on empty or null String Reviewed-by: naoto ! src/java.base/share/classes/java/util/Locale.java ! test/jdk/java/util/Locale/LocaleEnhanceTest.java Changeset: 4ca4485e Branch: fibers Author: Xueming Shen Date: 2025-10-13 20:29:06 +0000 URL: https://git.openjdk.org/loom/commit/4ca4485e9af10a49ca95710c4e26aa3895835d47 8365588: defineClass that accepts a ByteBuffer does not work as expected Reviewed-by: alanb ! src/java.base/share/classes/java/lang/ClassLoader.java + test/jdk/java/lang/ClassLoader/defineClass/DefineClassDirectByteBuffer.java + test/micro/org/openjdk/bench/java/lang/ClassLoaderDefineClass.java Changeset: d6ca382f Branch: fibers Author: Phil Race Date: 2025-10-14 03:33:23 +0000 URL: https://git.openjdk.org/loom/commit/d6ca382f4ee5793dfa191bba694a7fef88c591fc 8369335: Two sun/java2d/OpenGL tests fail on Windows after JDK-8358058 Reviewed-by: jdv ! test/jdk/sun/java2d/OpenGL/OpaqueDest.java ! test/jdk/sun/java2d/OpenGL/ScaleParamsOOB.java Changeset: 44964181 Branch: fibers Author: Jatin Bhateja Date: 2025-10-14 03:35:11 +0000 URL: https://git.openjdk.org/loom/commit/449641813ada3b0af6441dd7299e40235e7adf56 8365205: C2: Optimize popcount value computation using knownbits Reviewed-by: epeter, hgreule, qamai ! src/hotspot/share/opto/countbitsnode.cpp ! src/hotspot/share/opto/countbitsnode.hpp + test/hotspot/jtreg/compiler/intrinsics/TestPopCountValueTransforms.java ! test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java + test/micro/org/openjdk/bench/java/lang/PopCountValueTransform.java Changeset: be0e49b7 Branch: fibers Author: Axel Boldt-Christmas Date: 2025-10-14 05:38:13 +0000 URL: https://git.openjdk.org/loom/commit/be0e49b7e20103ed5c1f3729df1cddf3c9c7ae80 8369467: Rdtsc: Remove experimental support for non invariant tsc Reviewed-by: dholmes, mgronlun ! src/hotspot/cpu/x86/rdtsc_x86.cpp ! src/hotspot/cpu/x86/rdtsc_x86.hpp Changeset: 5bf1bab5 Branch: fibers Author: Serguei Spitsyn Committer: Axel Boldt-Christmas Date: 2025-10-14 05:40:07 +0000 URL: https://git.openjdk.org/loom/commit/5bf1bab5b3b7ebd2adbc0508e451d6f37580d3ce 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll in disallowed state Co-authored-by: Patricio Chilano Mateo Reviewed-by: sspitsyn, pchilanomate ! src/hotspot/share/prims/jvmtiExport.cpp ! src/hotspot/share/runtime/continuationFreezeThaw.cpp Changeset: 2eb0898f Branch: fibers Author: Jaikiran Pai Date: 2025-10-14 06:10:09 +0000 URL: https://git.openjdk.org/loom/commit/2eb0898fef7b7fef7285b7ee1837b73336b9f7be 8367157: Remove jrunscript tool Reviewed-by: erikj, ayang, ihse, alanb ! make/modules/java.scripting/Java.gmk - make/modules/java.scripting/Launcher.gmk - src/java.scripting/share/classes/com/sun/tools/script/shell/Main.java - src/java.scripting/share/classes/com/sun/tools/script/shell/init.js - src/java.scripting/share/classes/com/sun/tools/script/shell/messages.properties ! src/java.scripting/share/classes/module-info.java - src/java.scripting/share/man/jrunscript.md ! test/jdk/TEST.groups - test/jdk/sun/tools/jrunscript/CheckEngine.java - test/jdk/sun/tools/jrunscript/Hello.java - test/jdk/sun/tools/jrunscript/common.sh - test/jdk/sun/tools/jrunscript/dash-e.out - test/jdk/sun/tools/jrunscript/dash-f.out - test/jdk/sun/tools/jrunscript/hello.js - test/jdk/sun/tools/jrunscript/jrunscript-DTest.sh - test/jdk/sun/tools/jrunscript/jrunscript-argsTest.sh - test/jdk/sun/tools/jrunscript/jrunscript-cpTest.sh - test/jdk/sun/tools/jrunscript/jrunscript-eTest.sh - test/jdk/sun/tools/jrunscript/jrunscript-fTest.sh - test/jdk/sun/tools/jrunscript/jrunscript-helpTest.sh - test/jdk/sun/tools/jrunscript/jrunscriptTest.sh - test/jdk/sun/tools/jrunscript/repl.out ! test/jdk/tools/launcher/HelpFlagsTest.java ! test/jdk/tools/launcher/VersionCheck.java Changeset: a3ee821f Branch: fibers Author: Matthias Baesken Date: 2025-10-14 07:28:28 +0000 URL: https://git.openjdk.org/loom/commit/a3ee821f38d0d04f982465f5157170249c92cc49 8369305: Adjust usage of CDS in the boot JDK Reviewed-by: erikj, clanger ! make/autoconf/boot-jdk.m4 ! make/autoconf/bootcycle-spec.gmk.template Changeset: 4786f8be Branch: fibers Author: Emanuel Peter Date: 2025-10-14 08:32:32 +0000 URL: https://git.openjdk.org/loom/commit/4786f8bee5c79c1bcf652758a25360b4d308ce1c 8369448: C2 SuperWord: refactor VTransform to do move_unordered_reduction_out_of_loop during VTransform::optimize Reviewed-by: chagedorn, kvn ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/loopnode.hpp ! src/hotspot/share/opto/loopopts.cpp ! src/hotspot/share/opto/superword.cpp ! src/hotspot/share/opto/traceAutoVectorizationTag.hpp ! src/hotspot/share/opto/vectorization.hpp ! src/hotspot/share/opto/vectornode.cpp ! src/hotspot/share/opto/vectornode.hpp ! src/hotspot/share/opto/vtransform.cpp ! src/hotspot/share/opto/vtransform.hpp Changeset: 702179e7 Branch: fibers Author: Christian Stein Date: 2025-10-14 08:54:42 +0000 URL: https://git.openjdk.org/loom/commit/702179e7858bae1c7c13ad6eda3c4fbffdbb15db 8369488: Update to use jtreg 8.1 Reviewed-by: iris, erikj, jpai, syan ! make/autoconf/lib-tests.m4 ! make/conf/github-actions.conf ! make/conf/jib-profiles.js ! test/docs/TEST.ROOT ! test/hotspot/jtreg/TEST.ROOT ! test/jaxp/TEST.ROOT ! test/jdk/TEST.ROOT ! test/langtools/TEST.ROOT ! test/lib-test/TEST.ROOT Changeset: 90cf3a20 Branch: fibers Author: jonghoonpark Committer: Stefan Johansson Date: 2025-10-14 09:09:58 +0000 URL: https://git.openjdk.org/loom/commit/90cf3a2086cb0705dd519ff327be350e24a83af5 8366716: Move SmapsParser from runtime/os/TestTracePageSizes.java into testlib Co-authored-by: Stefan Johansson Reviewed-by: sjohanss, syan ! test/hotspot/jtreg/gc/TestTransparentHugePagesHeap.java ! test/hotspot/jtreg/runtime/os/TestTracePageSizes.java + test/lib/jdk/test/lib/os/linux/Smaps.java Changeset: 6d1529cd Branch: fibers Author: Daniel Jeli?ski Date: 2025-10-14 12:23:48 +0000 URL: https://git.openjdk.org/loom/commit/6d1529cd70718b3c26d65cc54c8a4fb8df06adb7 8369593: Test H3MalformedResponseTest.testMalformedResponse still times out Reviewed-by: jpai, vyazici, dfuchs ! test/jdk/java/net/httpclient/http3/H3MalformedResponseTest.java Changeset: 72663695 Branch: fibers Author: Feilong Jiang Date: 2025-10-14 13:50:19 +0000 URL: https://git.openjdk.org/loom/commit/72663695da9a51c8eefbd496f14a6d1625ad7b42 8369616: JavaFrameAnchor on RISC-V has unnecessary barriers and wrong store order in MacroAssembler Reviewed-by: fyang, luhenry ! src/hotspot/cpu/riscv/javaFrameAnchor_riscv.hpp ! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp Changeset: 4b85ba90 Branch: fibers Author: Joachim Kern Date: 2025-10-14 14:04:36 +0000 URL: https://git.openjdk.org/loom/commit/4b85ba90671c0ac816a772584c3eeb30ef9062ba 8369657: [AIX] TOC overflow in static-launcher build when building slowdebug after JDK-8352064 Reviewed-by: mdoerr, erikj, clanger, mbaesken ! make/StaticLibs.gmk Changeset: 64ff7062 Branch: fibers Author: Ramkumar Sunderbabu Committer: Christian Hagedorn Date: 2025-10-14 15:33:49 +0000 URL: https://git.openjdk.org/loom/commit/64ff7062c1cef13d16acddbcaf5401d7c2ad6dc0 8369806: Remove nsk/jvmti/AttachOnDemand/attach020 from problemlist Reviewed-by: lmesnik, chagedorn ! test/hotspot/jtreg/ProblemList-Xcomp.txt Changeset: 7ed93cf4 Branch: fibers Author: Joe Darcy Date: 2025-10-14 16:04:27 +0000 URL: https://git.openjdk.org/loom/commit/7ed93cf40ed4fa1ad545dcb1a33b0d4fdabfa277 8369312: Refactor Float.toHexString() to avoid use of regex Reviewed-by: rgiulietti ! src/java.base/share/classes/java/lang/Float.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java Changeset: bbbb9c5f Branch: fibers Author: Harshitha Onkar Date: 2025-10-14 16:31:21 +0000 URL: https://git.openjdk.org/loom/commit/bbbb9c5f1557cb1e80d72a820c034c71308cb3a2 8365423: [macos26] java/awt/MenuBar/8007006/bug8007006.java fails on macOS 26 Reviewed-by: kizune, prr ! test/jdk/java/awt/MenuBar/8007006/bug8007006.java Changeset: d6537c6d Branch: fibers Author: Phil Race Date: 2025-10-14 17:36:54 +0000 URL: https://git.openjdk.org/loom/commit/d6537c6d3ee6d7a59d609b277f0538da0afb0fbf 8344918: Unused private variables in SwingUtilities.java Reviewed-by: azvegint ! src/java.desktop/share/classes/javax/swing/SwingUtilities.java Changeset: 65b8fe62 Branch: fibers Author: Brian Burkhalter Date: 2025-10-14 17:48:15 +0000 URL: https://git.openjdk.org/loom/commit/65b8fe62b4dc9355866df4b0ddd7cfccaaf0e39b 8368907: (fs) Windows Error code 1314 not translated to AccessDeniedException (win) Reviewed-by: alanb ! src/java.base/windows/classes/sun/nio/fs/WindowsConstants.java ! src/java.base/windows/classes/sun/nio/fs/WindowsException.java Changeset: 09e87971 Branch: fibers Author: Brian Burkhalter Date: 2025-10-14 17:48:37 +0000 URL: https://git.openjdk.org/loom/commit/09e87971e8a53951b40eef15d127aad0b7c2bee8 8368633: (fs) Path.toRealPath(NOFOLLOW_LINKS) very slow on macOS Reviewed-by: alanb ! src/java.base/unix/classes/sun/nio/fs/UnixPath.java ! test/jdk/java/nio/file/Path/ToRealPath.java + test/micro/org/openjdk/bench/java/nio/file/ToRealPath.java Changeset: 622a611c Branch: fibers Author: Ashutosh Mehra Date: 2025-10-14 18:15:06 +0000 URL: https://git.openjdk.org/loom/commit/622a611c338ba766bc1a70c95e8241d1bddf6add 8369296: Add fast class init checks in interpreter for resolving ConstantPool entries for static field Co-authored-by: Vladimir Ivanov Co-authored-by: Amit Kumar Co-authored-by: Fei Yang Co-authored-by: Martin Doerr Reviewed-by: mdoerr, vlivanov, kvn, amitkumar, fyang, mli ! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp ! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp ! src/hotspot/cpu/riscv/templateTable_riscv.cpp ! src/hotspot/cpu/s390/templateTable_s390.cpp ! src/hotspot/cpu/x86/templateTable_x86.cpp ! src/hotspot/share/interpreter/interpreterRuntime.cpp Changeset: 310ad381 Branch: fibers Author: Alan Bateman Date: 2025-10-16 08:25:55 +0000 URL: https://git.openjdk.org/loom/commit/310ad381ec505044f0dfca1a121e0125247b9a19 Merge commit '622a611c338ba766bc1a70c95e8241d1bddf6add' into fibers ! src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp ! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp ! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp ! src/hotspot/cpu/riscv/templateTable_riscv.cpp ! src/hotspot/cpu/x86/continuationFreezeThaw_x86.inline.hpp ! src/hotspot/cpu/x86/templateTable_x86.cpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/interpreter/interpreterRuntime.cpp ! src/hotspot/share/runtime/continuationFreezeThaw.cpp ! test/hotspot/jtreg/ProblemList-Xcomp.txt ! src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp ! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp ! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp ! src/hotspot/cpu/riscv/templateTable_riscv.cpp ! src/hotspot/cpu/x86/continuationFreezeThaw_x86.inline.hpp ! src/hotspot/cpu/x86/templateTable_x86.cpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/javaClasses.hpp ! src/hotspot/share/interpreter/interpreterRuntime.cpp ! src/hotspot/share/runtime/continuationFreezeThaw.cpp ! test/hotspot/jtreg/ProblemList-Xcomp.txt Changeset: ad2d0473 Branch: fibers Author: Ioi Lam Date: 2025-10-14 20:03:18 +0000 URL: https://git.openjdk.org/loom/commit/ad2d04733b64a6793e20fd32a3e9fafab93556c5 8367449: Test runtime/cds/CDSMapTest.java timed out but passed Reviewed-by: dholmes ! test/hotspot/jtreg/runtime/cds/CDSMapTest.java ! test/hotspot/jtreg/runtime/cds/appcds/aotCache/AOTMapTest.java Changeset: 70528bd3 Branch: fibers Author: Joe Darcy Date: 2025-10-14 21:29:04 +0000 URL: https://git.openjdk.org/loom/commit/70528bd39925fabf23aad25f0a58a61f746ca9d8 8369851: Remove darcy author tags from langtools tests Reviewed-by: vromero, iris ! test/langtools/tools/javac/HexThree.java ! test/langtools/tools/javac/StringsInSwitch/OneCaseSwitches.java ! test/langtools/tools/javac/StringsInSwitch/StringSwitches.java ! test/langtools/tools/javac/TryWithResources/BadTwr.java ! test/langtools/tools/javac/TryWithResources/BadTwr.out ! test/langtools/tools/javac/TryWithResources/BadTwrSyntax.java ! test/langtools/tools/javac/TryWithResources/BadTwrSyntax.out ! test/langtools/tools/javac/TryWithResources/ExplicitFinal.java ! test/langtools/tools/javac/TryWithResources/PlainTry.java ! test/langtools/tools/javac/TryWithResources/PlainTry.out ! test/langtools/tools/javac/TryWithResources/TwrFlow.java ! test/langtools/tools/javac/TryWithResources/TwrFlow.out ! test/langtools/tools/javac/TryWithResources/TwrLint.java ! test/langtools/tools/javac/TryWithResources/TwrLint.out ! test/langtools/tools/javac/TryWithResources/TwrMultiCatch.java ! test/langtools/tools/javac/TryWithResources/TwrOnNonResource.java ! test/langtools/tools/javac/TryWithResources/TwrOnNonResource.out ! test/langtools/tools/javac/TryWithResources/TwrSuppression.java ! test/langtools/tools/javac/TryWithResources/WeirdTwr.java ! test/langtools/tools/javac/annotations/pos/TrailingComma.java ! test/langtools/tools/javac/boxing/BoxingCaching.java ! test/langtools/tools/javac/enum/6350057/T6350057.java ! test/langtools/tools/javac/enum/AbstractEmptyEnum.java ! test/langtools/tools/javac/enum/AbstractEmptyEnum.out ! test/langtools/tools/javac/enum/EnumImplicitPrivateConstructor.java ! test/langtools/tools/javac/enum/EnumPrivateConstructor.java ! test/langtools/tools/javac/enum/EnumProtectedConstructor.java ! test/langtools/tools/javac/enum/EnumProtectedConstructor.out ! test/langtools/tools/javac/enum/EnumPublicConstructor.java ! test/langtools/tools/javac/enum/EnumPublicConstructor.out ! test/langtools/tools/javac/enum/ExplicitlyAbstractEnum1.java ! test/langtools/tools/javac/enum/ExplicitlyAbstractEnum1.out ! test/langtools/tools/javac/enum/ExplicitlyAbstractEnum2.java ! test/langtools/tools/javac/enum/ExplicitlyAbstractEnum2.out ! test/langtools/tools/javac/enum/ExplicitlyFinalEnum1.java ! test/langtools/tools/javac/enum/ExplicitlyFinalEnum1.out ! test/langtools/tools/javac/enum/ExplicitlyFinalEnum2.java ! test/langtools/tools/javac/enum/ExplicitlyFinalEnum2.out ! test/langtools/tools/javac/enum/FauxEnum1.java ! test/langtools/tools/javac/enum/FauxEnum1.out ! test/langtools/tools/javac/enum/FauxEnum3.java ! test/langtools/tools/javac/enum/FauxEnum3.out ! test/langtools/tools/javac/enum/FauxSpecialEnum1.java ! test/langtools/tools/javac/enum/FauxSpecialEnum1.out ! test/langtools/tools/javac/enum/FauxSpecialEnum2.java ! test/langtools/tools/javac/enum/FauxSpecialEnum2.out ! test/langtools/tools/javac/generics/InheritanceConflict3.java ! test/langtools/tools/javac/generics/InheritanceConflict3.out ! test/langtools/tools/javac/multicatch/Neg01.java ! test/langtools/tools/javac/multicatch/Neg01.out ! test/langtools/tools/javac/multicatch/Neg01eff_final.java ! test/langtools/tools/javac/multicatch/Neg01eff_final.out ! test/langtools/tools/javac/multicatch/Neg07.java ! test/langtools/tools/javac/multicatch/Neg07.out ! test/langtools/tools/javac/multicatch/Pos10.java ! test/langtools/tools/javac/processing/6365040/T6365040.java ! test/langtools/tools/javac/processing/6378728/T6378728.java ! test/langtools/tools/javac/processing/6634138/T6634138.java ! test/langtools/tools/javac/processing/completion/TestCompletions.java ! test/langtools/tools/javac/processing/environment/TestSourceVersion.java ! test/langtools/tools/javac/processing/environment/round/TestElementsAnnotatedWith.java ! test/langtools/tools/javac/processing/errors/TestFatalityOfParseErrors.java ! test/langtools/tools/javac/processing/errors/TestOptionSyntaxErrors.java ! test/langtools/tools/javac/processing/errors/TestReturnCode.java ! test/langtools/tools/javac/processing/filer/TestFilerConstraints.java ! test/langtools/tools/javac/processing/filer/TestGetResource.java ! test/langtools/tools/javac/processing/filer/TestPackageInfo.java ! test/langtools/tools/javac/processing/messager/MessagerBasics.java ! test/langtools/tools/javac/processing/model/TestExceptions.java ! test/langtools/tools/javac/processing/model/TestSourceVersion.java ! test/langtools/tools/javac/processing/model/element/TestAnonClassNames.java ! test/langtools/tools/javac/processing/model/element/TestElement.java ! test/langtools/tools/javac/processing/model/element/TestExecutableElement.java ! test/langtools/tools/javac/processing/model/element/TestNames.java ! test/langtools/tools/javac/processing/model/element/TestPackageElement.java ! test/langtools/tools/javac/processing/model/element/TestResourceVariable.java ! test/langtools/tools/javac/processing/model/type/MirroredTypeEx/NpeTest.java ! test/langtools/tools/javac/processing/model/type/MirroredTypeEx/Plurality.java ! test/langtools/tools/javac/processing/model/type/TestTypeKind.java ! test/langtools/tools/javac/processing/model/util/deprecation/TestDeprecation.java ! test/langtools/tools/javac/processing/model/util/elements/TestGetConstantExpression.java ! test/langtools/tools/javac/processing/model/util/elements/TestGetPackageOf.java ! test/langtools/tools/javac/processing/model/util/elements/TestIsFunctionalInterface.java ! test/langtools/tools/javac/processing/model/util/elements/VacuousEnum.java ! test/langtools/tools/javac/processing/model/util/filter/TestIterables.java ! test/langtools/tools/javac/processing/model/util/types/TestPseudoTypeHandling.java ! test/langtools/tools/javac/processing/warnings/TestSourceVersionWarnings.java Changeset: 95def24b Branch: fibers Author: Alexey Semenyuk Date: 2025-10-14 22:31:17 +0000 URL: https://git.openjdk.org/loom/commit/95def24b025341b5a6b99abdd4d1f3d26a40431c 8369853: jpackage signing tests fail after JDK-8358723 Reviewed-by: almatvee ! test/jdk/tools/jpackage/TEST.properties ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/LauncherVerifier.java Changeset: 3d95c83b Branch: fibers Author: Ioi Lam Date: 2025-10-14 23:50:55 +0000 URL: https://git.openjdk.org/loom/commit/3d95c83b14cf9a6f683776053e57c07b1847cc17 8358597: [asan] Buffer overflow in ArchiveBuilder::make_shallow_copy with Symbols Reviewed-by: mbaesken, jsjolen ! src/hotspot/share/cds/archiveBuilder.cpp Changeset: c82c8920 Branch: fibers Author: Erik Gahlin Date: 2025-10-15 00:58:34 +0000 URL: https://git.openjdk.org/loom/commit/c82c892063ebb91ffeb853db2f325154465cfdff 8282427: jdk/jfr/jvm/TestWaste.java is failing with "exit code 139" Reviewed-by: mgronlun ! src/hotspot/share/jfr/leakprofiler/chains/bfsClosure.cpp ! test/jdk/ProblemList.txt Changeset: 42b2999c Branch: fibers Author: Jaikiran Pai Date: 2025-10-15 02:01:11 +0000 URL: https://git.openjdk.org/loom/commit/42b2999c31d63d0f8326c83e95eff83f5a467926 8369812: HttpClient doesn't handle H3_REQUEST_REJECTED correctly Reviewed-by: dfuchs, djelinski ! src/java.net.http/share/classes/jdk/internal/net/http/Http3ExchangeImpl.java + test/jdk/java/net/httpclient/http3/H3RequestRejectedTest.java Changeset: 355cb459 Branch: fibers Author: Mar?a Arias de Reyna Dom?nguez Committer: Andrew Dinn Date: 2025-10-15 09:17:25 +0000 URL: https://git.openjdk.org/loom/commit/355cb45943797ff2e8f2634c20100e85a53096d0 8369559: Identify owning method for MethodTrainingData and CompileTrainingData in AOT map output Reviewed-by: adinn, iklam ! src/hotspot/share/cds/aotMapLogger.cpp ! src/hotspot/share/cds/aotMapLogger.hpp Changeset: 008d8d91 Branch: fibers Author: Francesco Andreuzzi Committer: Albert Mingkun Yang Date: 2025-10-15 09:17:49 +0000 URL: https://git.openjdk.org/loom/commit/008d8d914cd4dd4573361390ee31120134338802 8369817: [TESTBUG] EmptyPath::toString is ignored Reviewed-by: jpai, ayang ! test/jdk/java/io/File/EmptyPath.java Changeset: 112d8852 Branch: fibers Author: Martin Doerr Date: 2025-10-15 09:18:22 +0000 URL: https://git.openjdk.org/loom/commit/112d88523d9d75829594da466c9b66dfe157cc3e 8334247: [PPC64] Consider trap based nmethod entry barriers Reviewed-by: ssarathi, rrich ! src/hotspot/cpu/ppc/assembler_ppc.hpp ! src/hotspot/cpu/ppc/gc/shared/barrierSetAssembler_ppc.cpp ! src/hotspot/cpu/ppc/gc/shared/barrierSetNMethod_ppc.cpp ! src/hotspot/cpu/ppc/globals_ppc.hpp ! src/hotspot/cpu/ppc/nativeInst_ppc.hpp ! src/hotspot/cpu/ppc/vm_version_ppc.cpp ! src/hotspot/os_cpu/aix_ppc/os_aix_ppc.cpp ! src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp Changeset: 9d117877 Branch: fibers Author: Albert Mingkun Yang Date: 2025-10-15 09:18:46 +0000 URL: https://git.openjdk.org/loom/commit/9d11787799718a82087f3c7b0c70abe7dfcead72 8369681: Parallel: Remove conditional check in ParallelScavengeHeap::verify Reviewed-by: fandreuzzi, tschatzl ! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp Changeset: c53ab10d Branch: fibers Author: Thomas Schatzl Date: 2025-10-15 11:25:09 +0000 URL: https://git.openjdk.org/loom/commit/c53ab10daedb5acd3fc7b17e8431b30dff88e3c7 8369818: G1: Add missing region types in gc+heap=debug heap output Reviewed-by: ayang, iwalulya ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp Changeset: 159452e8 Branch: fibers Author: Thomas Schatzl Date: 2025-10-15 11:25:31 +0000 URL: https://git.openjdk.org/loom/commit/159452e85a55745fecc58b68ead03a8d330d14dd 8369809: G1: Merge G1CollectedHeap::do_collection_pause_at_safepoint[_helper] Reviewed-by: ayang, iwalulya ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp Changeset: 1af37e5c Branch: fibers Author: Thomas Schatzl Date: 2025-10-15 11:27:18 +0000 URL: https://git.openjdk.org/loom/commit/1af37e5c3f7ca46561ef4431ac9b779524888e61 8369793: G1: Remove unused G1FreeIdSet Reviewed-by: stefank, sjohanss, kbarrett ! make/hotspot/lib/CompileJvm.gmk - src/hotspot/share/gc/g1/g1FreeIdSet.cpp - src/hotspot/share/gc/g1/g1FreeIdSet.hpp - test/hotspot/gtest/gc/g1/test_g1FreeIdSet.cpp Changeset: 5191d720 Branch: fibers Author: Kevin Walls Date: 2025-10-15 14:06:38 +0000 URL: https://git.openjdk.org/loom/commit/5191d72092a51d158ded061aa2e0f8a8231a9453 8369894: Remove javax/management/remote/mandatory/loading/RMIDownloadTest.java from problemlist Reviewed-by: alanb ! test/jdk/ProblemList-Virtual.txt Changeset: 784af438 Branch: fibers Author: Matias Saavedra Silva Date: 2025-10-15 14:09:22 +0000 URL: https://git.openjdk.org/loom/commit/784af438efd3f2cd8a4c0518b4aa06d496bd7846 8351595: JVM_FindClassFromCaller: unused var may be removed Reviewed-by: dholmes, alanb, liach, fandreuzzi ! src/hotspot/share/include/jvm.h ! src/hotspot/share/prims/jvm.cpp ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/native/libjava/Class.c Changeset: 1bd814c3 Branch: fibers Author: Matias Saavedra Silva Date: 2025-10-15 14:34:38 +0000 URL: https://git.openjdk.org/loom/commit/1bd814c3b24eb7ef5633ee34bb418e0981ca1708 8364660: ClassVerifier::ends_in_athrow() should be removed Reviewed-by: liach, dlong ! src/hotspot/share/classfile/verifier.cpp ! src/hotspot/share/classfile/verifier.hpp ! src/java.base/share/classes/jdk/internal/classfile/impl/verifier/VerifierImpl.java Changeset: bfe69372 Branch: fibers Author: David Briemann Date: 2025-10-15 18:28:56 +0000 URL: https://git.openjdk.org/loom/commit/bfe6937244ff7ec9899bb6a5eaa4222736898177 8369444: JavaFrameAnchor on PPC64 has unnecessary barriers Reviewed-by: mdoerr, dlong ! src/hotspot/cpu/ppc/javaFrameAnchor_ppc.hpp Changeset: c9cbd31f Branch: fibers Author: David Briemann Date: 2025-10-15 18:29:23 +0000 URL: https://git.openjdk.org/loom/commit/c9cbd31f8575a25c4decd68dc645378c5ba2bad0 8307495: Specialize atomic bitset functions for aix-ppc Reviewed-by: mdoerr, rrich + src/hotspot/cpu/ppc/atomicAccess_ppc.hpp = src/hotspot/cpu/ppc/orderAccess_ppc.hpp ! src/hotspot/os_cpu/aix_ppc/atomicAccess_aix_ppc.hpp ! src/hotspot/os_cpu/aix_ppc/orderAccess_aix_ppc.hpp ! src/hotspot/os_cpu/linux_ppc/atomicAccess_linux_ppc.hpp ! src/hotspot/os_cpu/linux_ppc/orderAccess_linux_ppc.hpp Changeset: a7a3a660 Branch: fibers Author: Weijun Wang Date: 2025-10-15 20:47:46 +0000 URL: https://git.openjdk.org/loom/commit/a7a3a660e33fabc025ebe887f5605741be9ca8c3 8354469: Keytool exposes the password in plain text when command is piped using | grep Reviewed-by: mullan, smarks, naoto, hchao ! src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java ! src/java.base/share/classes/sun/security/util/Password.java ! src/java.base/share/classes/sun/security/util/resources/security.properties + test/jdk/sun/security/tools/keytool/EchoPassword.java + test/jdk/sun/security/tools/keytool/SetInPassword.java ! test/jdk/sun/security/util/Resources/Usages.java Changeset: 4ed36403 Branch: fibers Author: Prasanta Sadhukhan Date: 2025-10-16 02:02:16 +0000 URL: https://git.openjdk.org/loom/commit/4ed364033daef96f6141a3ad2d217fa1ec5eca3e 8369251: Opensource few tests Reviewed-by: honkar + test/jdk/java/awt/Choice/PaintArtefacts.java + test/jdk/java/awt/Choice/SelectBetweenPressRelease.java + test/jdk/java/awt/FullScreen/DisplayModeNoRefreshTest.java + test/jdk/java/awt/print/PrinterJob/ImagePrinting/BitmaskImage.java + test/jdk/javax/swing/JFrame/ClientDecoratedIcon/ClientDecoratedIconTest.java + test/jdk/javax/swing/JFrame/ClientDecoratedIcon/DialogIconTest.java + test/jdk/javax/swing/JFrame/ClientDecoratedIcon/DialogInheritIcon.java + test/jdk/javax/swing/text/JTextComponent/bug4532590.java Changeset: 0168687f Branch: fibers Author: Thomas Schatzl Date: 2025-10-16 05:32:00 +0000 URL: https://git.openjdk.org/loom/commit/0168687fc372e6649f8e9a5a96a3614e7bab8543 8368940: Missing ResourceMark when stalling for shutdown Reviewed-by: shade, syan ! src/hotspot/share/gc/shared/collectedHeap.cpp Changeset: 5696d606 Branch: fibers Author: Jan Lahoda Date: 2025-10-16 06:21:26 +0000 URL: https://git.openjdk.org/loom/commit/5696d60663f1bb917728808118fab3b346ed0341 8357809: Test jdk/jshell/JdiListeningExecutionControlTest.java failed with com.sun.jdi.connect.TransportTimeoutException Reviewed-by: asotona ! test/langtools/jdk/jshell/JdiBadOptionListenExecutionControlTest.java ! test/langtools/jdk/jshell/JdiListeningExecutionControlTest.java ! test/langtools/jdk/jshell/Presets.java Changeset: aa194c6a Branch: fibers Author: Emanuel Peter Date: 2025-10-16 06:45:10 +0000 URL: https://git.openjdk.org/loom/commit/aa194c6a5a21aca64d454e4c5eeed1464c8f190b 8369881: C2: Unexpected node in SuperWord truncation: ReverseBytesS, ReverseBytesUS Reviewed-by: chagedorn, kvn ! src/hotspot/share/opto/superword.cpp ! test/hotspot/jtreg/compiler/vectorization/TestSubwordTruncation.java Changeset: c95fae5d Branch: fibers Author: Alan Bateman Date: 2025-10-16 08:26:04 +0000 URL: https://git.openjdk.org/loom/commit/c95fae5d6e5094f6d3dff5134d6d6a61b6a52f47 Merge branch 'master' into fibers ! test/jdk/ProblemList-Virtual.txt ! test/jdk/ProblemList.txt ! test/jdk/ProblemList-Virtual.txt ! test/jdk/ProblemList.txt From duke at openjdk.org Thu Oct 16 09:37:32 2025 From: duke at openjdk.org (duke) Date: Thu, 16 Oct 2025 09:37:32 GMT Subject: git: openjdk/loom: master: 50 new changesets Message-ID: Changeset: f292d7c6 Branch: master Author: Thomas Schatzl Date: 2025-10-13 14:51:08 +0000 URL: https://git.openjdk.org/loom/commit/f292d7c66c6279f929eb37ffcc1857a269f72e3d 8048180: G1: Eager reclaim of humongous objects with references Co-authored-by: Ivan Walulya Reviewed-by: iwalulya, ayang ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1HeapVerifier.cpp ! src/hotspot/share/gc/g1/g1HeapVerifier.hpp ! src/hotspot/share/gc/g1/g1OopClosures.inline.hpp ! src/hotspot/share/gc/g1/g1RemSet.cpp ! src/hotspot/share/gc/g1/g1RemSetTrackingPolicy.cpp ! src/hotspot/share/gc/g1/g1YoungCollector.cpp ! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp ! test/hotspot/jtreg/gc/g1/TestEagerReclaimHumongousRegions.java - test/hotspot/jtreg/gc/g1/TestEagerReclaimHumongousRegionsClearMarkBits.java Changeset: 551cd03b Branch: master Author: Xiaolong Peng Date: 2025-10-13 15:03:01 +0000 URL: https://git.openjdk.org/loom/commit/551cd03b99feb34d98703b7d04571f92f83f2471 8369611: Remove safepoint synchronization from ParallelScavengeHeap and SerialHeap Reviewed-by: kbarrett, ayang, shade, tschatzl ! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp ! src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp ! src/hotspot/share/gc/serial/serialHeap.cpp ! src/hotspot/share/gc/serial/serialHeap.hpp Changeset: b83e7939 Branch: master Author: Henry Jen Date: 2025-10-13 15:05:53 +0000 URL: https://git.openjdk.org/loom/commit/b83e7939dd9401314f2351a9fefd1e212387c6e5 8347007: --strip-debug removes parameter names included with -parameters Reviewed-by: alanb ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/TaskHelper.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/DefaultStripDebugPlugin.java ! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/StripJavaDebugAttributesPlugin.java ! test/jdk/tools/jlink/plugins/DefaultStripDebugPluginTest.java + test/jdk/tools/jlink/plugins/StripParameterNamesTest.java Changeset: 16681623 Branch: master Author: Erik Gahlin Date: 2025-10-13 15:17:36 +0000 URL: https://git.openjdk.org/loom/commit/166816231988dd94f644a7b892cdddf0fea94570 8369510: JFR: Remove flush handler from Dispatcher lookup Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/Dispatcher.java Changeset: 8b1cf8ee Branch: master Author: Brian Burkhalter Date: 2025-10-13 16:03:43 +0000 URL: https://git.openjdk.org/loom/commit/8b1cf8eefe4e3439dba983bced06d55a6ca7da4e 8368098: (aio) java/nio/channels/Channels/AsyncCloseStreams.java fails in junit timeout Reviewed-by: alanb ! test/jdk/java/nio/channels/Channels/AsyncCloseStreams.java Changeset: 9b1633de Branch: master Author: Ravi.Patel8 Committer: Harshitha Onkar Date: 2025-10-13 16:10:48 +0000 URL: https://git.openjdk.org/loom/commit/9b1633ded0e1d952ef13c054b6c507149d22f8cd 8368606: Printer lookup returns empty on AIX platform due to uninitialized results list Reviewed-by: honkar, serb ! src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java Changeset: 1d6cafdc Branch: master Author: Justin Lu Date: 2025-10-13 16:11:09 +0000 URL: https://git.openjdk.org/loom/commit/1d6cafdc5244960ddec2fd82b8454c6c3cafe022 8369452: Locale.Builder.setLanguageTag(String) does not clear on empty or null String Reviewed-by: naoto ! src/java.base/share/classes/java/util/Locale.java ! test/jdk/java/util/Locale/LocaleEnhanceTest.java Changeset: 4ca4485e Branch: master Author: Xueming Shen Date: 2025-10-13 20:29:06 +0000 URL: https://git.openjdk.org/loom/commit/4ca4485e9af10a49ca95710c4e26aa3895835d47 8365588: defineClass that accepts a ByteBuffer does not work as expected Reviewed-by: alanb ! src/java.base/share/classes/java/lang/ClassLoader.java + test/jdk/java/lang/ClassLoader/defineClass/DefineClassDirectByteBuffer.java + test/micro/org/openjdk/bench/java/lang/ClassLoaderDefineClass.java Changeset: d6ca382f Branch: master Author: Phil Race Date: 2025-10-14 03:33:23 +0000 URL: https://git.openjdk.org/loom/commit/d6ca382f4ee5793dfa191bba694a7fef88c591fc 8369335: Two sun/java2d/OpenGL tests fail on Windows after JDK-8358058 Reviewed-by: jdv ! test/jdk/sun/java2d/OpenGL/OpaqueDest.java ! test/jdk/sun/java2d/OpenGL/ScaleParamsOOB.java Changeset: 44964181 Branch: master Author: Jatin Bhateja Date: 2025-10-14 03:35:11 +0000 URL: https://git.openjdk.org/loom/commit/449641813ada3b0af6441dd7299e40235e7adf56 8365205: C2: Optimize popcount value computation using knownbits Reviewed-by: epeter, hgreule, qamai ! src/hotspot/share/opto/countbitsnode.cpp ! src/hotspot/share/opto/countbitsnode.hpp + test/hotspot/jtreg/compiler/intrinsics/TestPopCountValueTransforms.java ! test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java + test/micro/org/openjdk/bench/java/lang/PopCountValueTransform.java Changeset: be0e49b7 Branch: master Author: Axel Boldt-Christmas Date: 2025-10-14 05:38:13 +0000 URL: https://git.openjdk.org/loom/commit/be0e49b7e20103ed5c1f3729df1cddf3c9c7ae80 8369467: Rdtsc: Remove experimental support for non invariant tsc Reviewed-by: dholmes, mgronlun ! src/hotspot/cpu/x86/rdtsc_x86.cpp ! src/hotspot/cpu/x86/rdtsc_x86.hpp Changeset: 5bf1bab5 Branch: master Author: Serguei Spitsyn Committer: Axel Boldt-Christmas Date: 2025-10-14 05:40:07 +0000 URL: https://git.openjdk.org/loom/commit/5bf1bab5b3b7ebd2adbc0508e451d6f37580d3ce 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll in disallowed state Co-authored-by: Patricio Chilano Mateo Reviewed-by: sspitsyn, pchilanomate ! src/hotspot/share/prims/jvmtiExport.cpp ! src/hotspot/share/runtime/continuationFreezeThaw.cpp Changeset: 2eb0898f Branch: master Author: Jaikiran Pai Date: 2025-10-14 06:10:09 +0000 URL: https://git.openjdk.org/loom/commit/2eb0898fef7b7fef7285b7ee1837b73336b9f7be 8367157: Remove jrunscript tool Reviewed-by: erikj, ayang, ihse, alanb ! make/modules/java.scripting/Java.gmk - make/modules/java.scripting/Launcher.gmk - src/java.scripting/share/classes/com/sun/tools/script/shell/Main.java - src/java.scripting/share/classes/com/sun/tools/script/shell/init.js - src/java.scripting/share/classes/com/sun/tools/script/shell/messages.properties ! src/java.scripting/share/classes/module-info.java - src/java.scripting/share/man/jrunscript.md ! test/jdk/TEST.groups - test/jdk/sun/tools/jrunscript/CheckEngine.java - test/jdk/sun/tools/jrunscript/Hello.java - test/jdk/sun/tools/jrunscript/common.sh - test/jdk/sun/tools/jrunscript/dash-e.out - test/jdk/sun/tools/jrunscript/dash-f.out - test/jdk/sun/tools/jrunscript/hello.js - test/jdk/sun/tools/jrunscript/jrunscript-DTest.sh - test/jdk/sun/tools/jrunscript/jrunscript-argsTest.sh - test/jdk/sun/tools/jrunscript/jrunscript-cpTest.sh - test/jdk/sun/tools/jrunscript/jrunscript-eTest.sh - test/jdk/sun/tools/jrunscript/jrunscript-fTest.sh - test/jdk/sun/tools/jrunscript/jrunscript-helpTest.sh - test/jdk/sun/tools/jrunscript/jrunscriptTest.sh - test/jdk/sun/tools/jrunscript/repl.out ! test/jdk/tools/launcher/HelpFlagsTest.java ! test/jdk/tools/launcher/VersionCheck.java Changeset: a3ee821f Branch: master Author: Matthias Baesken Date: 2025-10-14 07:28:28 +0000 URL: https://git.openjdk.org/loom/commit/a3ee821f38d0d04f982465f5157170249c92cc49 8369305: Adjust usage of CDS in the boot JDK Reviewed-by: erikj, clanger ! make/autoconf/boot-jdk.m4 ! make/autoconf/bootcycle-spec.gmk.template Changeset: 4786f8be Branch: master Author: Emanuel Peter Date: 2025-10-14 08:32:32 +0000 URL: https://git.openjdk.org/loom/commit/4786f8bee5c79c1bcf652758a25360b4d308ce1c 8369448: C2 SuperWord: refactor VTransform to do move_unordered_reduction_out_of_loop during VTransform::optimize Reviewed-by: chagedorn, kvn ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/loopnode.hpp ! src/hotspot/share/opto/loopopts.cpp ! src/hotspot/share/opto/superword.cpp ! src/hotspot/share/opto/traceAutoVectorizationTag.hpp ! src/hotspot/share/opto/vectorization.hpp ! src/hotspot/share/opto/vectornode.cpp ! src/hotspot/share/opto/vectornode.hpp ! src/hotspot/share/opto/vtransform.cpp ! src/hotspot/share/opto/vtransform.hpp Changeset: 702179e7 Branch: master Author: Christian Stein Date: 2025-10-14 08:54:42 +0000 URL: https://git.openjdk.org/loom/commit/702179e7858bae1c7c13ad6eda3c4fbffdbb15db 8369488: Update to use jtreg 8.1 Reviewed-by: iris, erikj, jpai, syan ! make/autoconf/lib-tests.m4 ! make/conf/github-actions.conf ! make/conf/jib-profiles.js ! test/docs/TEST.ROOT ! test/hotspot/jtreg/TEST.ROOT ! test/jaxp/TEST.ROOT ! test/jdk/TEST.ROOT ! test/langtools/TEST.ROOT ! test/lib-test/TEST.ROOT Changeset: 90cf3a20 Branch: master Author: jonghoonpark Committer: Stefan Johansson Date: 2025-10-14 09:09:58 +0000 URL: https://git.openjdk.org/loom/commit/90cf3a2086cb0705dd519ff327be350e24a83af5 8366716: Move SmapsParser from runtime/os/TestTracePageSizes.java into testlib Co-authored-by: Stefan Johansson Reviewed-by: sjohanss, syan ! test/hotspot/jtreg/gc/TestTransparentHugePagesHeap.java ! test/hotspot/jtreg/runtime/os/TestTracePageSizes.java + test/lib/jdk/test/lib/os/linux/Smaps.java Changeset: 6d1529cd Branch: master Author: Daniel Jeli?ski Date: 2025-10-14 12:23:48 +0000 URL: https://git.openjdk.org/loom/commit/6d1529cd70718b3c26d65cc54c8a4fb8df06adb7 8369593: Test H3MalformedResponseTest.testMalformedResponse still times out Reviewed-by: jpai, vyazici, dfuchs ! test/jdk/java/net/httpclient/http3/H3MalformedResponseTest.java Changeset: 72663695 Branch: master Author: Feilong Jiang Date: 2025-10-14 13:50:19 +0000 URL: https://git.openjdk.org/loom/commit/72663695da9a51c8eefbd496f14a6d1625ad7b42 8369616: JavaFrameAnchor on RISC-V has unnecessary barriers and wrong store order in MacroAssembler Reviewed-by: fyang, luhenry ! src/hotspot/cpu/riscv/javaFrameAnchor_riscv.hpp ! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp Changeset: 4b85ba90 Branch: master Author: Joachim Kern Date: 2025-10-14 14:04:36 +0000 URL: https://git.openjdk.org/loom/commit/4b85ba90671c0ac816a772584c3eeb30ef9062ba 8369657: [AIX] TOC overflow in static-launcher build when building slowdebug after JDK-8352064 Reviewed-by: mdoerr, erikj, clanger, mbaesken ! make/StaticLibs.gmk Changeset: 64ff7062 Branch: master Author: Ramkumar Sunderbabu Committer: Christian Hagedorn Date: 2025-10-14 15:33:49 +0000 URL: https://git.openjdk.org/loom/commit/64ff7062c1cef13d16acddbcaf5401d7c2ad6dc0 8369806: Remove nsk/jvmti/AttachOnDemand/attach020 from problemlist Reviewed-by: lmesnik, chagedorn ! test/hotspot/jtreg/ProblemList-Xcomp.txt Changeset: 7ed93cf4 Branch: master Author: Joe Darcy Date: 2025-10-14 16:04:27 +0000 URL: https://git.openjdk.org/loom/commit/7ed93cf40ed4fa1ad545dcb1a33b0d4fdabfa277 8369312: Refactor Float.toHexString() to avoid use of regex Reviewed-by: rgiulietti ! src/java.base/share/classes/java/lang/Float.java ! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java Changeset: bbbb9c5f Branch: master Author: Harshitha Onkar Date: 2025-10-14 16:31:21 +0000 URL: https://git.openjdk.org/loom/commit/bbbb9c5f1557cb1e80d72a820c034c71308cb3a2 8365423: [macos26] java/awt/MenuBar/8007006/bug8007006.java fails on macOS 26 Reviewed-by: kizune, prr ! test/jdk/java/awt/MenuBar/8007006/bug8007006.java Changeset: d6537c6d Branch: master Author: Phil Race Date: 2025-10-14 17:36:54 +0000 URL: https://git.openjdk.org/loom/commit/d6537c6d3ee6d7a59d609b277f0538da0afb0fbf 8344918: Unused private variables in SwingUtilities.java Reviewed-by: azvegint ! src/java.desktop/share/classes/javax/swing/SwingUtilities.java Changeset: 65b8fe62 Branch: master Author: Brian Burkhalter Date: 2025-10-14 17:48:15 +0000 URL: https://git.openjdk.org/loom/commit/65b8fe62b4dc9355866df4b0ddd7cfccaaf0e39b 8368907: (fs) Windows Error code 1314 not translated to AccessDeniedException (win) Reviewed-by: alanb ! src/java.base/windows/classes/sun/nio/fs/WindowsConstants.java ! src/java.base/windows/classes/sun/nio/fs/WindowsException.java Changeset: 09e87971 Branch: master Author: Brian Burkhalter Date: 2025-10-14 17:48:37 +0000 URL: https://git.openjdk.org/loom/commit/09e87971e8a53951b40eef15d127aad0b7c2bee8 8368633: (fs) Path.toRealPath(NOFOLLOW_LINKS) very slow on macOS Reviewed-by: alanb ! src/java.base/unix/classes/sun/nio/fs/UnixPath.java ! test/jdk/java/nio/file/Path/ToRealPath.java + test/micro/org/openjdk/bench/java/nio/file/ToRealPath.java Changeset: 622a611c Branch: master Author: Ashutosh Mehra Date: 2025-10-14 18:15:06 +0000 URL: https://git.openjdk.org/loom/commit/622a611c338ba766bc1a70c95e8241d1bddf6add 8369296: Add fast class init checks in interpreter for resolving ConstantPool entries for static field Co-authored-by: Vladimir Ivanov Co-authored-by: Amit Kumar Co-authored-by: Fei Yang Co-authored-by: Martin Doerr Reviewed-by: mdoerr, vlivanov, kvn, amitkumar, fyang, mli ! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp ! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp ! src/hotspot/cpu/riscv/templateTable_riscv.cpp ! src/hotspot/cpu/s390/templateTable_s390.cpp ! src/hotspot/cpu/x86/templateTable_x86.cpp ! src/hotspot/share/interpreter/interpreterRuntime.cpp Changeset: ad2d0473 Branch: master Author: Ioi Lam Date: 2025-10-14 20:03:18 +0000 URL: https://git.openjdk.org/loom/commit/ad2d04733b64a6793e20fd32a3e9fafab93556c5 8367449: Test runtime/cds/CDSMapTest.java timed out but passed Reviewed-by: dholmes ! test/hotspot/jtreg/runtime/cds/CDSMapTest.java ! test/hotspot/jtreg/runtime/cds/appcds/aotCache/AOTMapTest.java Changeset: 70528bd3 Branch: master Author: Joe Darcy Date: 2025-10-14 21:29:04 +0000 URL: https://git.openjdk.org/loom/commit/70528bd39925fabf23aad25f0a58a61f746ca9d8 8369851: Remove darcy author tags from langtools tests Reviewed-by: vromero, iris ! test/langtools/tools/javac/HexThree.java ! test/langtools/tools/javac/StringsInSwitch/OneCaseSwitches.java ! test/langtools/tools/javac/StringsInSwitch/StringSwitches.java ! test/langtools/tools/javac/TryWithResources/BadTwr.java ! test/langtools/tools/javac/TryWithResources/BadTwr.out ! test/langtools/tools/javac/TryWithResources/BadTwrSyntax.java ! test/langtools/tools/javac/TryWithResources/BadTwrSyntax.out ! test/langtools/tools/javac/TryWithResources/ExplicitFinal.java ! test/langtools/tools/javac/TryWithResources/PlainTry.java ! test/langtools/tools/javac/TryWithResources/PlainTry.out ! test/langtools/tools/javac/TryWithResources/TwrFlow.java ! test/langtools/tools/javac/TryWithResources/TwrFlow.out ! test/langtools/tools/javac/TryWithResources/TwrLint.java ! test/langtools/tools/javac/TryWithResources/TwrLint.out ! test/langtools/tools/javac/TryWithResources/TwrMultiCatch.java ! test/langtools/tools/javac/TryWithResources/TwrOnNonResource.java ! test/langtools/tools/javac/TryWithResources/TwrOnNonResource.out ! test/langtools/tools/javac/TryWithResources/TwrSuppression.java ! test/langtools/tools/javac/TryWithResources/WeirdTwr.java ! test/langtools/tools/javac/annotations/pos/TrailingComma.java ! test/langtools/tools/javac/boxing/BoxingCaching.java ! test/langtools/tools/javac/enum/6350057/T6350057.java ! test/langtools/tools/javac/enum/AbstractEmptyEnum.java ! test/langtools/tools/javac/enum/AbstractEmptyEnum.out ! test/langtools/tools/javac/enum/EnumImplicitPrivateConstructor.java ! test/langtools/tools/javac/enum/EnumPrivateConstructor.java ! test/langtools/tools/javac/enum/EnumProtectedConstructor.java ! test/langtools/tools/javac/enum/EnumProtectedConstructor.out ! test/langtools/tools/javac/enum/EnumPublicConstructor.java ! test/langtools/tools/javac/enum/EnumPublicConstructor.out ! test/langtools/tools/javac/enum/ExplicitlyAbstractEnum1.java ! test/langtools/tools/javac/enum/ExplicitlyAbstractEnum1.out ! test/langtools/tools/javac/enum/ExplicitlyAbstractEnum2.java ! test/langtools/tools/javac/enum/ExplicitlyAbstractEnum2.out ! test/langtools/tools/javac/enum/ExplicitlyFinalEnum1.java ! test/langtools/tools/javac/enum/ExplicitlyFinalEnum1.out ! test/langtools/tools/javac/enum/ExplicitlyFinalEnum2.java ! test/langtools/tools/javac/enum/ExplicitlyFinalEnum2.out ! test/langtools/tools/javac/enum/FauxEnum1.java ! test/langtools/tools/javac/enum/FauxEnum1.out ! test/langtools/tools/javac/enum/FauxEnum3.java ! test/langtools/tools/javac/enum/FauxEnum3.out ! test/langtools/tools/javac/enum/FauxSpecialEnum1.java ! test/langtools/tools/javac/enum/FauxSpecialEnum1.out ! test/langtools/tools/javac/enum/FauxSpecialEnum2.java ! test/langtools/tools/javac/enum/FauxSpecialEnum2.out ! test/langtools/tools/javac/generics/InheritanceConflict3.java ! test/langtools/tools/javac/generics/InheritanceConflict3.out ! test/langtools/tools/javac/multicatch/Neg01.java ! test/langtools/tools/javac/multicatch/Neg01.out ! test/langtools/tools/javac/multicatch/Neg01eff_final.java ! test/langtools/tools/javac/multicatch/Neg01eff_final.out ! test/langtools/tools/javac/multicatch/Neg07.java ! test/langtools/tools/javac/multicatch/Neg07.out ! test/langtools/tools/javac/multicatch/Pos10.java ! test/langtools/tools/javac/processing/6365040/T6365040.java ! test/langtools/tools/javac/processing/6378728/T6378728.java ! test/langtools/tools/javac/processing/6634138/T6634138.java ! test/langtools/tools/javac/processing/completion/TestCompletions.java ! test/langtools/tools/javac/processing/environment/TestSourceVersion.java ! test/langtools/tools/javac/processing/environment/round/TestElementsAnnotatedWith.java ! test/langtools/tools/javac/processing/errors/TestFatalityOfParseErrors.java ! test/langtools/tools/javac/processing/errors/TestOptionSyntaxErrors.java ! test/langtools/tools/javac/processing/errors/TestReturnCode.java ! test/langtools/tools/javac/processing/filer/TestFilerConstraints.java ! test/langtools/tools/javac/processing/filer/TestGetResource.java ! test/langtools/tools/javac/processing/filer/TestPackageInfo.java ! test/langtools/tools/javac/processing/messager/MessagerBasics.java ! test/langtools/tools/javac/processing/model/TestExceptions.java ! test/langtools/tools/javac/processing/model/TestSourceVersion.java ! test/langtools/tools/javac/processing/model/element/TestAnonClassNames.java ! test/langtools/tools/javac/processing/model/element/TestElement.java ! test/langtools/tools/javac/processing/model/element/TestExecutableElement.java ! test/langtools/tools/javac/processing/model/element/TestNames.java ! test/langtools/tools/javac/processing/model/element/TestPackageElement.java ! test/langtools/tools/javac/processing/model/element/TestResourceVariable.java ! test/langtools/tools/javac/processing/model/type/MirroredTypeEx/NpeTest.java ! test/langtools/tools/javac/processing/model/type/MirroredTypeEx/Plurality.java ! test/langtools/tools/javac/processing/model/type/TestTypeKind.java ! test/langtools/tools/javac/processing/model/util/deprecation/TestDeprecation.java ! test/langtools/tools/javac/processing/model/util/elements/TestGetConstantExpression.java ! test/langtools/tools/javac/processing/model/util/elements/TestGetPackageOf.java ! test/langtools/tools/javac/processing/model/util/elements/TestIsFunctionalInterface.java ! test/langtools/tools/javac/processing/model/util/elements/VacuousEnum.java ! test/langtools/tools/javac/processing/model/util/filter/TestIterables.java ! test/langtools/tools/javac/processing/model/util/types/TestPseudoTypeHandling.java ! test/langtools/tools/javac/processing/warnings/TestSourceVersionWarnings.java Changeset: 95def24b Branch: master Author: Alexey Semenyuk Date: 2025-10-14 22:31:17 +0000 URL: https://git.openjdk.org/loom/commit/95def24b025341b5a6b99abdd4d1f3d26a40431c 8369853: jpackage signing tests fail after JDK-8358723 Reviewed-by: almatvee ! test/jdk/tools/jpackage/TEST.properties ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/LauncherVerifier.java Changeset: 3d95c83b Branch: master Author: Ioi Lam Date: 2025-10-14 23:50:55 +0000 URL: https://git.openjdk.org/loom/commit/3d95c83b14cf9a6f683776053e57c07b1847cc17 8358597: [asan] Buffer overflow in ArchiveBuilder::make_shallow_copy with Symbols Reviewed-by: mbaesken, jsjolen ! src/hotspot/share/cds/archiveBuilder.cpp Changeset: c82c8920 Branch: master Author: Erik Gahlin Date: 2025-10-15 00:58:34 +0000 URL: https://git.openjdk.org/loom/commit/c82c892063ebb91ffeb853db2f325154465cfdff 8282427: jdk/jfr/jvm/TestWaste.java is failing with "exit code 139" Reviewed-by: mgronlun ! src/hotspot/share/jfr/leakprofiler/chains/bfsClosure.cpp ! test/jdk/ProblemList.txt Changeset: 42b2999c Branch: master Author: Jaikiran Pai Date: 2025-10-15 02:01:11 +0000 URL: https://git.openjdk.org/loom/commit/42b2999c31d63d0f8326c83e95eff83f5a467926 8369812: HttpClient doesn't handle H3_REQUEST_REJECTED correctly Reviewed-by: dfuchs, djelinski ! src/java.net.http/share/classes/jdk/internal/net/http/Http3ExchangeImpl.java + test/jdk/java/net/httpclient/http3/H3RequestRejectedTest.java Changeset: 355cb459 Branch: master Author: Mar?a Arias de Reyna Dom?nguez Committer: Andrew Dinn Date: 2025-10-15 09:17:25 +0000 URL: https://git.openjdk.org/loom/commit/355cb45943797ff2e8f2634c20100e85a53096d0 8369559: Identify owning method for MethodTrainingData and CompileTrainingData in AOT map output Reviewed-by: adinn, iklam ! src/hotspot/share/cds/aotMapLogger.cpp ! src/hotspot/share/cds/aotMapLogger.hpp Changeset: 008d8d91 Branch: master Author: Francesco Andreuzzi Committer: Albert Mingkun Yang Date: 2025-10-15 09:17:49 +0000 URL: https://git.openjdk.org/loom/commit/008d8d914cd4dd4573361390ee31120134338802 8369817: [TESTBUG] EmptyPath::toString is ignored Reviewed-by: jpai, ayang ! test/jdk/java/io/File/EmptyPath.java Changeset: 112d8852 Branch: master Author: Martin Doerr Date: 2025-10-15 09:18:22 +0000 URL: https://git.openjdk.org/loom/commit/112d88523d9d75829594da466c9b66dfe157cc3e 8334247: [PPC64] Consider trap based nmethod entry barriers Reviewed-by: ssarathi, rrich ! src/hotspot/cpu/ppc/assembler_ppc.hpp ! src/hotspot/cpu/ppc/gc/shared/barrierSetAssembler_ppc.cpp ! src/hotspot/cpu/ppc/gc/shared/barrierSetNMethod_ppc.cpp ! src/hotspot/cpu/ppc/globals_ppc.hpp ! src/hotspot/cpu/ppc/nativeInst_ppc.hpp ! src/hotspot/cpu/ppc/vm_version_ppc.cpp ! src/hotspot/os_cpu/aix_ppc/os_aix_ppc.cpp ! src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp Changeset: 9d117877 Branch: master Author: Albert Mingkun Yang Date: 2025-10-15 09:18:46 +0000 URL: https://git.openjdk.org/loom/commit/9d11787799718a82087f3c7b0c70abe7dfcead72 8369681: Parallel: Remove conditional check in ParallelScavengeHeap::verify Reviewed-by: fandreuzzi, tschatzl ! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp Changeset: c53ab10d Branch: master Author: Thomas Schatzl Date: 2025-10-15 11:25:09 +0000 URL: https://git.openjdk.org/loom/commit/c53ab10daedb5acd3fc7b17e8431b30dff88e3c7 8369818: G1: Add missing region types in gc+heap=debug heap output Reviewed-by: ayang, iwalulya ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp Changeset: 159452e8 Branch: master Author: Thomas Schatzl Date: 2025-10-15 11:25:31 +0000 URL: https://git.openjdk.org/loom/commit/159452e85a55745fecc58b68ead03a8d330d14dd 8369809: G1: Merge G1CollectedHeap::do_collection_pause_at_safepoint[_helper] Reviewed-by: ayang, iwalulya ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/g1/g1CollectedHeap.hpp Changeset: 1af37e5c Branch: master Author: Thomas Schatzl Date: 2025-10-15 11:27:18 +0000 URL: https://git.openjdk.org/loom/commit/1af37e5c3f7ca46561ef4431ac9b779524888e61 8369793: G1: Remove unused G1FreeIdSet Reviewed-by: stefank, sjohanss, kbarrett ! make/hotspot/lib/CompileJvm.gmk - src/hotspot/share/gc/g1/g1FreeIdSet.cpp - src/hotspot/share/gc/g1/g1FreeIdSet.hpp - test/hotspot/gtest/gc/g1/test_g1FreeIdSet.cpp Changeset: 5191d720 Branch: master Author: Kevin Walls Date: 2025-10-15 14:06:38 +0000 URL: https://git.openjdk.org/loom/commit/5191d72092a51d158ded061aa2e0f8a8231a9453 8369894: Remove javax/management/remote/mandatory/loading/RMIDownloadTest.java from problemlist Reviewed-by: alanb ! test/jdk/ProblemList-Virtual.txt Changeset: 784af438 Branch: master Author: Matias Saavedra Silva Date: 2025-10-15 14:09:22 +0000 URL: https://git.openjdk.org/loom/commit/784af438efd3f2cd8a4c0518b4aa06d496bd7846 8351595: JVM_FindClassFromCaller: unused var may be removed Reviewed-by: dholmes, alanb, liach, fandreuzzi ! src/hotspot/share/include/jvm.h ! src/hotspot/share/prims/jvm.cpp ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/native/libjava/Class.c Changeset: 1bd814c3 Branch: master Author: Matias Saavedra Silva Date: 2025-10-15 14:34:38 +0000 URL: https://git.openjdk.org/loom/commit/1bd814c3b24eb7ef5633ee34bb418e0981ca1708 8364660: ClassVerifier::ends_in_athrow() should be removed Reviewed-by: liach, dlong ! src/hotspot/share/classfile/verifier.cpp ! src/hotspot/share/classfile/verifier.hpp ! src/java.base/share/classes/jdk/internal/classfile/impl/verifier/VerifierImpl.java Changeset: bfe69372 Branch: master Author: David Briemann Date: 2025-10-15 18:28:56 +0000 URL: https://git.openjdk.org/loom/commit/bfe6937244ff7ec9899bb6a5eaa4222736898177 8369444: JavaFrameAnchor on PPC64 has unnecessary barriers Reviewed-by: mdoerr, dlong ! src/hotspot/cpu/ppc/javaFrameAnchor_ppc.hpp Changeset: c9cbd31f Branch: master Author: David Briemann Date: 2025-10-15 18:29:23 +0000 URL: https://git.openjdk.org/loom/commit/c9cbd31f8575a25c4decd68dc645378c5ba2bad0 8307495: Specialize atomic bitset functions for aix-ppc Reviewed-by: mdoerr, rrich + src/hotspot/cpu/ppc/atomicAccess_ppc.hpp = src/hotspot/cpu/ppc/orderAccess_ppc.hpp ! src/hotspot/os_cpu/aix_ppc/atomicAccess_aix_ppc.hpp ! src/hotspot/os_cpu/aix_ppc/orderAccess_aix_ppc.hpp ! src/hotspot/os_cpu/linux_ppc/atomicAccess_linux_ppc.hpp ! src/hotspot/os_cpu/linux_ppc/orderAccess_linux_ppc.hpp Changeset: a7a3a660 Branch: master Author: Weijun Wang Date: 2025-10-15 20:47:46 +0000 URL: https://git.openjdk.org/loom/commit/a7a3a660e33fabc025ebe887f5605741be9ca8c3 8354469: Keytool exposes the password in plain text when command is piped using | grep Reviewed-by: mullan, smarks, naoto, hchao ! src/java.base/share/classes/jdk/internal/io/JdkConsoleImpl.java ! src/java.base/share/classes/sun/security/util/Password.java ! src/java.base/share/classes/sun/security/util/resources/security.properties + test/jdk/sun/security/tools/keytool/EchoPassword.java + test/jdk/sun/security/tools/keytool/SetInPassword.java ! test/jdk/sun/security/util/Resources/Usages.java Changeset: 4ed36403 Branch: master Author: Prasanta Sadhukhan Date: 2025-10-16 02:02:16 +0000 URL: https://git.openjdk.org/loom/commit/4ed364033daef96f6141a3ad2d217fa1ec5eca3e 8369251: Opensource few tests Reviewed-by: honkar + test/jdk/java/awt/Choice/PaintArtefacts.java + test/jdk/java/awt/Choice/SelectBetweenPressRelease.java + test/jdk/java/awt/FullScreen/DisplayModeNoRefreshTest.java + test/jdk/java/awt/print/PrinterJob/ImagePrinting/BitmaskImage.java + test/jdk/javax/swing/JFrame/ClientDecoratedIcon/ClientDecoratedIconTest.java + test/jdk/javax/swing/JFrame/ClientDecoratedIcon/DialogIconTest.java + test/jdk/javax/swing/JFrame/ClientDecoratedIcon/DialogInheritIcon.java + test/jdk/javax/swing/text/JTextComponent/bug4532590.java Changeset: 0168687f Branch: master Author: Thomas Schatzl Date: 2025-10-16 05:32:00 +0000 URL: https://git.openjdk.org/loom/commit/0168687fc372e6649f8e9a5a96a3614e7bab8543 8368940: Missing ResourceMark when stalling for shutdown Reviewed-by: shade, syan ! src/hotspot/share/gc/shared/collectedHeap.cpp Changeset: 5696d606 Branch: master Author: Jan Lahoda Date: 2025-10-16 06:21:26 +0000 URL: https://git.openjdk.org/loom/commit/5696d60663f1bb917728808118fab3b346ed0341 8357809: Test jdk/jshell/JdiListeningExecutionControlTest.java failed with com.sun.jdi.connect.TransportTimeoutException Reviewed-by: asotona ! test/langtools/jdk/jshell/JdiBadOptionListenExecutionControlTest.java ! test/langtools/jdk/jshell/JdiListeningExecutionControlTest.java ! test/langtools/jdk/jshell/Presets.java Changeset: aa194c6a Branch: master Author: Emanuel Peter Date: 2025-10-16 06:45:10 +0000 URL: https://git.openjdk.org/loom/commit/aa194c6a5a21aca64d454e4c5eeed1464c8f190b 8369881: C2: Unexpected node in SuperWord truncation: ReverseBytesS, ReverseBytesUS Reviewed-by: chagedorn, kvn ! src/hotspot/share/opto/superword.cpp ! test/hotspot/jtreg/compiler/vectorization/TestSubwordTruncation.java From ron.pressler at oracle.com Thu Oct 16 15:02:14 2025 From: ron.pressler at oracle.com (Ron Pressler) Date: Thu, 16 Oct 2025 15:02:14 +0000 Subject: Feedback on Structured Concurrency (JEP 525, 6th Preview) In-Reply-To: References: Message-ID: > On 13 Oct 2025, at 15:31, Jige Yu wrote: > > I agree with you on the importance of real-world feedback and the need to tease apart API design discussions from observed user problems with a specific design. My feedback is rooted in the latter: user-observed problems with the current Structured Task Scope (STS) API's usability, specifically its complexity for the common "concurrent AND" use case. Hi. If you want your feedback to have an impact, please limit it to: I tried doing X, here?s what my code looks like, and here are the difficulties I?ve ran into in that code. Such feedback has typically had a very strong record of impacting decisions. Talking about problems in the abstract tends to obscure tradeoffs, and we simply do not have the bandwidth to list all the pros and all the cons of each possible design here on the mailing list (not even all the designs we?ve tried), especially when some alternative designs don?t conform with our goals and future planned work. E.g. our goal might not be to offer the cleanest possible design, but rather something that takes into consideration training programmers already familiar with existing constructs, and or something that can serve as a building block for higher-level abstractions in the future. In short, if you?ve run into some specific difficulty in actual code, show us what it is. ? Ron From manc at google.com Fri Oct 17 23:13:14 2025 From: manc at google.com (Man Cao) Date: Fri, 17 Oct 2025 16:13:14 -0700 Subject: Custom Schedulers use-case In-Reply-To: References: Message-ID: Thanks for the detailed response. We hope OpenJDK will commit to supporting custom schedulers at some point. For "self deadlock" cases, the API could provide some guidelines on what users should not do inside custom schedulers. Our colleague David Gay also provided more details on the multi-tenancy use case: Firestore is a cloud-based database, implemented with a multi-tenant (i.e., a single job serves many customers) architecture. Multi-tenancy allows us to serve small-scale customers very cheaply, but brings isolation challenges: : traffic to a single Firestore database can potentially affect the performance and availability of other databases by consuming all or most of the resources in one or more components. Thus providing isolation between customers sending traffic to the same task in a job is critical. Specifically for Java: Firestore backends are implemented in Java, currently using a custom asynchronous programming framework which basically: - provides all the usual Java control structures (try-catch, loops, etc) - "automatic" suspension at (manually identified) blocking points - scheduling of 'slices' of these asynchronous computations via a fair scheduler (we're using a stride scheduler) Replacing our custom asynchronous programming framework with virtual threads is obviously highly desirable - much more readable and efficient code (and I can stop getting confused by continuations), but the fair scheduling of slices is an absolute requirement. We did experiments comparing the performance impact of an antagonistic workload from customer A on an 'innocent' workload from customer B: - without fair scheduling, B sees two orders of magnitude worse latency (p50 and p99) - with fair scheduling, B sees essentially no p50 latency impact and tolerable p99 impact The 'without fair scheduling' measurements are effectively measuring how the linux kernel schedules our threads - I would expect broadly similar results from the default virtual thread scheduler as neither has any information on which customer owns which traffic to appropriately prioritise scheduling. The above is partly summarised from https://research.google/pubs/firestore-the-nosql-serverless-database-for-the-application-developer/ - specifically see: - section IV.C for the overview of our isolation approach - section V.C and Figure 11 for the isolation benchmark -Man On Fri, Oct 10, 2025 at 1:01?AM Alan Bateman wrote: > On 09/10/2025 22:11, Man Cao wrote: > > Hi loom developers, > > > > Official support for custom schedulers is highly valuable to some of > > our Java applications such as our colleague David Gay's use case. > > > > Are there any major concerns or obstacles to official support for > > custom schedulers? > > > > There are some workloads that are not suited to a work stealing > scheduler. We've seen this with workloads that have low concurrency, not > a lot going on, and the scanning to "find work" consuming additional CPU > cycles that nobody wants to pay for. There may be merit in having the > JDK provide a different scheduler for such cases, more experimentation > is required. > > There are folks that want to do things like using the AWT event thread, > or the JavaFX application thread, as the carrier. They've seen > coroutines used on UI threads in other systems and want to experiment > doing something similar. Early explorations into this did not go very far. > > There are other folks that are interested in thread affinity, binding > virtual threads to specific carriers, and carriers to specific cores in > NUMA nodes. Some of this exploration is about integration with existing > systems that use event loops. We are looking forward to a write-up of > these explorations and any findings. > > Beyond this there are folks doing fun things with simulation and other > experimentation. > > I'm not familiar with David Gay's work except for Liam's mail to say > that they are doing something in the area of multi-tenancy. If a > write-up or a summary of the explorations and findings could be sent to > loom-dev then it would be useful. > > To your question, the topic of custom schedulers is an > exploration/research topic. The JDK has to be cautious. Calling out to a > custom scheduler (= arbitrary code) from core/sensitive parts of the > runtime is very scary. It's very easy to "self deadlock" - we've seen > folks trying to use locks to coordinate between mounted virtual threads > and their carrier. We are also concerned that the API surface for > schedulers will grow. > > There are two prototypes in the loom repo at this time, this is what > Liam linked to. We are hoping that folks that are interested in this > topic will try one or both and come back their findings. The more data, > esp. from real world usage, will help inform this project on whether > there is merit is going further with either direction or whether there > are other directions that might be more fruitful. > > -Alan > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at me.com Fri Oct 17 23:54:46 2025 From: robaho at me.com (Robert Engels) Date: Fri, 17 Oct 2025 18:54:46 -0500 Subject: Custom Schedulers use-case In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From alan.bateman at oracle.com Sat Oct 18 08:15:39 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Sat, 18 Oct 2025 09:15:39 +0100 Subject: Custom Schedulers use-case In-Reply-To: References: Message-ID: On 18/10/2025 00:13, Man Cao wrote: > Thanks for the detailed response. We hope OpenJDK will commit to > supporting custom schedulers at some?point. Do you know if David/Firestore team have tried one or both of the prototypes in the loom repo? It would be helpful to this project to know what they have tried, what worked and didn't work. I think it would at least be useful to know if they have tried setting the virtual thread scheduler to a deterministic stride scheduler. I think it would also be useful to expand on the comment about antagonistic workloads and if that assumes a means to do forced preemption. There is a prototype support for forced preemption but going further would require detailed changes in several core areas of the JDK and some features for a scheduler to control it. -Alan From duke at openjdk.org Sat Oct 18 09:26:07 2025 From: duke at openjdk.org (duke) Date: Sat, 18 Oct 2025 09:26:07 GMT Subject: git: openjdk/loom: fibers: 51 new changesets Message-ID: Changeset: 7fe06657 Branch: fibers Author: Roland Westrelin Date: 2025-10-16 07:23:41 +0000 URL: https://git.openjdk.org/loom/commit/7fe066573004a525673e4ec55df6783b13bfc189 8369167: C2: refactor LShiftINode/LShiftLNode Value/Identity/Ideal Reviewed-by: epeter, mchevalier ! src/hotspot/share/opto/mulnode.cpp ! src/hotspot/share/opto/mulnode.hpp ! src/hotspot/share/opto/node.hpp ! src/hotspot/share/utilities/globalDefinitions.hpp ! test/hotspot/jtreg/compiler/c2/irTests/LShiftINodeIdealizationTests.java ! test/hotspot/jtreg/compiler/c2/irTests/LShiftLNodeIdealizationTests.java Changeset: aed42a16 Branch: fibers Author: Artem Semenov Date: 2025-10-16 07:28:13 +0000 URL: https://git.openjdk.org/loom/commit/aed42a16bacb24753a536d07fedd736d64cde3be 8365609: Fix several potential NULL native pointer dereferences in the desktop module Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Artem Semenov Artem Semenov Reviewed-by: azvegint, prr, serb ! src/java.desktop/share/native/libsplashscreen/splashscreen_gif.c ! src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c Changeset: ff6a0170 Branch: fibers Author: Roland Westrelin Date: 2025-10-16 07:35:41 +0000 URL: https://git.openjdk.org/loom/commit/ff6a0170f0ab5cfb4af6d6a4a779451823c486d6 8369258: C2: enable ReassociateInvariants for all loop types Reviewed-by: epeter, qamai ! src/hotspot/share/opto/loopnode.cpp + test/hotspot/jtreg/compiler/loopopts/TestReassociateInvariants.java - test/hotspot/jtreg/compiler/loopopts/superword/TestMemorySegment_8360204.java - test/hotspot/jtreg/compiler/loopopts/superword/TestMemorySegment_8365982.java + test/hotspot/jtreg/compiler/loopopts/superword/TestMemorySegment_ReassociateInvariants1.java + test/hotspot/jtreg/compiler/loopopts/superword/TestMemorySegment_ReassociateInvariants2.java Changeset: 17c13e53 Branch: fibers Author: Christoph Langer Date: 2025-10-16 07:54:23 +0000 URL: https://git.openjdk.org/loom/commit/17c13e53aff16b294c7c0286ccb6ea3054b1de91 8369683: Exclude runtime/Monitor/MonitorWithDeadObjectTest.java#DumpThreadsBeforeDetach on Alpine Linux debug Reviewed-by: mbaesken, dholmes ! test/hotspot/jtreg/runtime/Monitor/MonitorWithDeadObjectTest.java Changeset: b5b83247 Branch: fibers Author: Viktor Klang Date: 2025-10-16 08:28:22 +0000 URL: https://git.openjdk.org/loom/commit/b5b83247da9caea30c88b69543e350783663bc46 8369656: Calling CompletableFuture.join() could execute task in common pool Reviewed-by: alanb, dl ! src/java.base/share/classes/java/util/concurrent/CompletableFuture.java ! test/jdk/java/util/concurrent/tck/CompletableFutureTest.java Changeset: 6e911d81 Branch: fibers Author: Martin Doerr Date: 2025-10-16 09:40:55 +0000 URL: https://git.openjdk.org/loom/commit/6e911d819efa0f14ab1f9009b5bf325d99edb26c 8368205: [TESTBUG] VectorMaskCompareNotTest.java crashes when MaxVectorSize=8 Reviewed-by: dzhang, epeter, rrich ! test/hotspot/jtreg/compiler/vectorapi/VectorMaskCompareNotTest.java ! test/jtreg-ext/requires/VMProps.java Changeset: d6c122b3 Branch: fibers Author: Erik Gahlin Date: 2025-10-16 09:57:11 +0000 URL: https://git.openjdk.org/loom/commit/d6c122b3ff1ccd559ba9c310976a77eefaf09ece 8369982: ProblemList jdk/jfr/jvm/TestWaste.java Reviewed-by: tschatzl, dholmes ! test/jdk/ProblemList.txt Changeset: ead35a75 Branch: fibers Author: Daniel Jeli?ski Date: 2025-10-16 11:05:13 +0000 URL: https://git.openjdk.org/loom/commit/ead35a754bf3a545a1b68f28d3d939750f11af39 8358942: HttpClient adds Content-Length: 0 for a GET request with a BodyPublishers.noBody() Reviewed-by: dfuchs, vyazici ! src/java.net.http/share/classes/jdk/internal/net/http/Http1Request.java ! test/jdk/java/net/httpclient/ContentLengthHeaderTest.java Changeset: 5fc3904b Branch: fibers Author: Stefan Karlsson Date: 2025-10-16 11:16:05 +0000 URL: https://git.openjdk.org/loom/commit/5fc3904bfe290625ed6cf9b41773b35b52bf72b7 8369491: Temporarily revert default TIMEOUT_FACTOR back to 4 Reviewed-by: lkorinth, cstein, jpai, syan, serb, prr ! doc/testing.html ! doc/testing.md ! make/RunTests.gmk Changeset: 16539998 Branch: fibers Author: Yasumasa Suenaga Date: 2025-10-16 12:45:05 +0000 URL: https://git.openjdk.org/loom/commit/1653999871c8d7b1e61b44f8525e09b2cd0bdb6b 8369505: jhsdb jstack cannot handle continuation stub Reviewed-by: cjplummer, pchilanomate ! src/hotspot/share/runtime/continuationEntry.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeBlob.java + src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ContinuationEntry.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaThread.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/aarch64/AARCH64Frame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/riscv64/RISCV64Frame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/x86/X86Frame.java + test/hotspot/jtreg/serviceability/sa/LingeredAppWithVirtualThread.java + test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackWithVirtualThread.java Changeset: f475eb8e Branch: fibers Author: Hamlin Li Date: 2025-10-16 14:04:45 +0000 URL: https://git.openjdk.org/loom/commit/f475eb8ee7c9a3e360b2f1210ed71b629243cd2a 8368950: RISC-V: fail to catch out of order declarations among dependent cpu extensions/flags Reviewed-by: fyang, luhenry ! src/hotspot/cpu/riscv/vm_version_riscv.hpp ! src/hotspot/os_cpu/linux_riscv/riscv_hwprobe.cpp Changeset: 5dfe115c Branch: fibers Author: Emanuel Peter Date: 2025-10-16 14:10:14 +0000 URL: https://git.openjdk.org/loom/commit/5dfe115ce1fbcff67777518a3c23a7560ebec423 8369912: [TESTBUG] testlibrary_tests/template_framework/examples/TestExpressions.java fails with ArithmeticException: / by zero - forgot to respect Expression.info Reviewed-by: kvn, mhaessig ! test/hotspot/jtreg/testlibrary_tests/template_framework/examples/TestExpressions.java Changeset: f2a99832 Branch: fibers Author: Emanuel Peter Date: 2025-10-16 14:22:15 +0000 URL: https://git.openjdk.org/loom/commit/f2a998326a6bebd4a7d2d0a39f785b2e6dac68c4 8369804: TestGenerators.java fails with IllegalArgumentException: bound must be greater than origin Reviewed-by: chagedorn, thartmann ! test/hotspot/jtreg/compiler/lib/generators/UniformDoubleGenerator.java ! test/hotspot/jtreg/compiler/lib/generators/UniformFloatGenerator.java ! test/hotspot/jtreg/testlibrary_tests/generators/tests/TestGenerators.java Changeset: 303eb109 Branch: fibers Author: Daniel Lund?n Date: 2025-10-16 15:02:32 +0000 URL: https://git.openjdk.org/loom/commit/303eb1096ccaf06106aa080b9ea0553c0f6912dd 8369573: Add missing compile commands help documentation for the signature part of method patterns Reviewed-by: rcastanedalo, aseoane, thartmann ! src/hotspot/share/compiler/compilerOracle.cpp Changeset: 87092ef1 Branch: fibers Author: Arno Zeller Committer: Matthias Baesken Date: 2025-10-16 15:15:19 +0000 URL: https://git.openjdk.org/loom/commit/87092ef1d97e00ddb6674b0e309f2f904d307604 8183336: Better cleanup for jdk/test/java/lang/module/customfs/ModulesInCustomFileSystem.java Reviewed-by: alanb, syan ! test/jdk/java/lang/module/customfs/ModulesInCustomFileSystem.java Changeset: 95380e1e Branch: fibers Author: Roger Riggs Date: 2025-10-16 15:54:22 +0000 URL: https://git.openjdk.org/loom/commit/95380e1ea5c3f531f82fb7c4b2f75726f3cd2fc2 8362637: Convert java.nio.ByteOrder to an enum Reviewed-by: alanb, liach, bpb ! src/java.base/share/classes/java/nio/ByteOrder.java Changeset: e56db377 Branch: fibers Author: Christian Hagedorn Date: 2025-10-16 16:02:26 +0000 URL: https://git.openjdk.org/loom/commit/e56db37734aa7cbc0f20ba3fc469f51224f288fa 8369232: testlibrary_tests/ir_framework/tests/TestScenariosCrossProduct.java timed out Reviewed-by: dfenacci, epeter ! test/hotspot/jtreg/compiler/lib/ir_framework/TestFramework.java ! test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestScenariosCrossProduct.java Changeset: 7e032409 Branch: fibers Author: Joe Darcy Date: 2025-10-16 16:38:18 +0000 URL: https://git.openjdk.org/loom/commit/7e03240974cd66c471f5d02e14fd77971fe6d173 8369858: Remove darcy author tags from jdk tests Reviewed-by: rriggs, iris, lancea ! test/jdk/java/io/Serializable/cloneArray/CloneArray.java ! test/jdk/java/lang/Byte/Decode.java ! test/jdk/java/lang/Class/IsAnnotationType.java ! test/jdk/java/lang/Class/IsEnum.java ! test/jdk/java/lang/Class/IsSynthetic.java ! test/jdk/java/lang/Class/getEnclosingConstructor/EnclosingConstructorTests.java ! test/jdk/java/lang/Class/getEnclosingMethod/EnclosingMethodTests.java ! test/jdk/java/lang/Double/BitwiseConversion.java ! test/jdk/java/lang/Double/Constants.java ! test/jdk/java/lang/Double/Extrema.java ! test/jdk/java/lang/Double/NaNInfinityParsing.java ! test/jdk/java/lang/Double/ParseHexFloatingPoint.java ! test/jdk/java/lang/Double/ToHexString.java ! test/jdk/java/lang/Float/BitwiseConversion.java ! test/jdk/java/lang/Float/Constants.java ! test/jdk/java/lang/Float/Extrema.java ! test/jdk/java/lang/Float/NaNInfinityParsing.java ! test/jdk/java/lang/Integer/Decode.java ! test/jdk/java/lang/Integer/ParsingTest.java ! test/jdk/java/lang/Integer/Unsigned.java ! test/jdk/java/lang/Long/Decode.java ! test/jdk/java/lang/Long/ParsingTest.java ! test/jdk/java/lang/Long/Unsigned.java ! test/jdk/java/lang/Short/Decode.java ! test/jdk/java/lang/Throwable/SuppressedExceptions.java ! test/jdk/java/lang/annotation/Missing/MissingTest.java ! test/jdk/java/lang/annotation/TestIncompleteAnnotationExceptionNPE.java ! test/jdk/java/lang/reflect/AnnotatedElement/TestAnnotatedElementDefaults.java ! test/jdk/java/lang/reflect/Constructor/GenericStringTest.java ! test/jdk/java/lang/reflect/Constructor/TestParameterAnnotations.java ! test/jdk/java/lang/reflect/DefaultAccessibility.java ! test/jdk/java/lang/reflect/Field/GenericStringTest.java ! test/jdk/java/lang/reflect/Generics/HashCodeTest.java ! test/jdk/java/lang/reflect/Generics/Probe.java ! test/jdk/java/lang/reflect/Generics/StringsAndBounds.java ! test/jdk/java/lang/reflect/Generics/TestParameterizedType.java ! test/jdk/java/lang/reflect/Generics/exceptionCauseTest.java ! test/jdk/java/lang/reflect/Generics/getAnnotationTest.java ! test/jdk/java/lang/reflect/Method/GenericStringTest.java ! test/jdk/java/lang/reflect/Method/IsDefaultTest.java ! test/jdk/java/lang/reflect/Method/defaultMethodModeling/DefaultMethodModeling.java ! test/jdk/java/lang/reflect/TypeVariable/TestAnnotatedElement.java ! test/jdk/java/math/BigDecimal/AddTests.java ! test/jdk/java/math/BigDecimal/CompareToTests.java ! test/jdk/java/math/BigDecimal/DivideTests.java ! test/jdk/java/math/BigDecimal/IntegralDivisionTests.java ! test/jdk/java/math/BigDecimal/NegateTests.java ! test/jdk/java/math/BigDecimal/PowTests.java ! test/jdk/java/math/BigDecimal/PrecisionTests.java ! test/jdk/java/math/BigDecimal/RoundingTests.java ! test/jdk/java/math/BigDecimal/ScaleByPowerOfTenTests.java ! test/jdk/java/math/BigDecimal/StrippingZerosTest.java ! test/jdk/java/math/BigDecimal/ToPlainStringTests.java ! test/jdk/java/math/BigDecimal/ZeroScalingTests.java ! test/jdk/java/math/BigInteger/CompareToTests.java ! test/jdk/java/math/BigInteger/ExtremeShiftingTests.java ! test/jdk/java/math/BigInteger/OperatorNpeTests.java ! test/jdk/java/math/BigInteger/StringConstructor.java ! test/jdk/java/math/BigInteger/TestValueExact.java ! test/jdk/java/math/RoundingMode/RoundingModeTests.java ! test/jdk/tools/launcher/ChangeDataModel.java ! test/jdk/tools/launcher/I18NTest.java ! test/jdk/tools/launcher/UnresolvedExceptions.java Changeset: 873666d1 Branch: fibers Author: Chris Plummer Date: 2025-10-16 16:53:47 +0000 URL: https://git.openjdk.org/loom/commit/873666d157340b3b953ad869576afd30d4304610 8369451: Debug agent support for USE_ITERATE_THROUGH_HEAP is broken and should be removed Reviewed-by: sspitsyn, amenkov ! src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c ! src/jdk.jdwp.agent/share/native/libjdwp/util.c ! src/jdk.jdwp.agent/share/native/libjdwp/util.h Changeset: d7b525ab Branch: fibers Author: Phil Race Date: 2025-10-16 16:58:38 +0000 URL: https://git.openjdk.org/loom/commit/d7b525ab9980743cf0cab3e3daaa4ccb725bfea8 8364673: Remove duplicate font mapping for itcavantgarde in psfontj2d.properties Reviewed-by: azvegint, kizune ! src/java.desktop/share/conf/psfontj2d.properties Changeset: 844118a9 Branch: fibers Author: Phil Race Date: 2025-10-16 16:58:56 +0000 URL: https://git.openjdk.org/loom/commit/844118a9d854459778f88d299b148c2288131344 8369146: java/awt/PrintJob/GetGraphicsTest.java: Parse Exception: Invalid or unrecognized bugid: 50510568367702 Reviewed-by: syan, azvegint, kizune, jdv ! test/jdk/java/awt/PrintJob/GetGraphicsTest.java Changeset: d4472979 Branch: fibers Author: William Kemper Date: 2025-10-16 17:49:08 +0000 URL: https://git.openjdk.org/loom/commit/d4472979c43d9825ed2d008dbaed26dbf6d36180 8367709: GenShen: Dirty cards for objects that get promoted by safepoint that intervenes between allocation and stores Reviewed-by: ysr ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.cpp ! src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp ! src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.inline.hpp Changeset: 9589a29d Branch: fibers Author: Mikael Vidstedt Date: 2025-10-16 19:43:44 +0000 URL: https://git.openjdk.org/loom/commit/9589a29d2515888b437d382204df22d01d4266ff 8355752: Bump minimum boot jdk to JDK 25 Reviewed-by: darcy, shade, ihse, iris ! make/conf/github-actions.conf ! make/conf/jib-profiles.js ! make/conf/version-numbers.conf Changeset: 3248aaf3 Branch: fibers Author: Chen Liang Date: 2025-10-16 19:45:57 +0000 URL: https://git.openjdk.org/loom/commit/3248aaf3c4f6784d5176e2a2c5bac0fbda47ee6b 8356548: Use ClassFile API instead of ASM to transform classes in tests Reviewed-by: sspitsyn, lmesnik, coleenp, iklam ! test/hotspot/jtreg/compiler/calls/common/InvokeDynamicPatcher.java ! test/hotspot/jtreg/compiler/calls/fromCompiled/CompiledInvokeDynamic2CompiledTest.java ! test/hotspot/jtreg/compiler/calls/fromCompiled/CompiledInvokeDynamic2InterpretedTest.java ! test/hotspot/jtreg/compiler/calls/fromCompiled/CompiledInvokeDynamic2NativeTest.java ! test/hotspot/jtreg/compiler/calls/fromInterpreted/InterpretedInvokeDynamic2CompiledTest.java ! test/hotspot/jtreg/compiler/calls/fromInterpreted/InterpretedInvokeDynamic2InterpretedTest.java ! test/hotspot/jtreg/compiler/calls/fromInterpreted/InterpretedInvokeDynamic2NativeTest.java ! test/hotspot/jtreg/compiler/jsr292/RedefineMethodUsedByMultipleMethodHandles.java ! test/hotspot/jtreg/compiler/jvmci/common/CTVMUtilities.java ! test/hotspot/jtreg/runtime/MirrorFrame/Asmator.java ! test/hotspot/jtreg/runtime/MirrorFrame/Test8003720.java ! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/MissedStackMapFrames/MissedStackMapFrames.java ! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineAnnotations.java ! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineGenericSignatureTest.java ! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineObject.java ! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/GenClassPoolJar.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_keepRef_rootClass_inMemoryCompilation_keep_cl/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_keepRef_rootClass_inMemoryCompilation_keep_class/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_keepRef_rootClass_inMemoryCompilation_keep_obj/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_keepRef_rootClass_keep_cl/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_keepRef_rootClass_keep_class/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_keepRef_rootClass_keep_obj/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassFields/getclfld007.java Changeset: 1392a0b4 Branch: fibers Author: Albert Mingkun Yang Date: 2025-10-16 19:55:07 +0000 URL: https://git.openjdk.org/loom/commit/1392a0b4608f6196f207fcebbab75b2d79fdc758 8368740: Serial: Swap eden and survivor spaces position in young generation Reviewed-by: gli, fandreuzzi ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/serial/defNewGeneration.hpp ! src/hotspot/share/gc/serial/serialHeap.cpp ! src/hotspot/share/gc/serial/serialHeap.hpp ! src/hotspot/share/gc/shared/space.cpp Changeset: 18fd0477 Branch: fibers Author: Justin King Date: 2025-10-16 19:59:13 +0000 URL: https://git.openjdk.org/loom/commit/18fd04770294e27011bd576b5ea5fe43fa03e5e3 8369506: Bytecode rewriting causes Java heap corruption on AArch64 Co-authored-by: Man Cao Co-authored-by: Chuck Rasbold Reviewed-by: shade, aph, manc ! src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp ! src/hotspot/cpu/aarch64/interp_masm_aarch64.hpp ! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp Changeset: 0c1c86e6 Branch: fibers Author: Patricio Chilano Mateo Date: 2025-10-16 21:20:42 +0000 URL: https://git.openjdk.org/loom/commit/0c1c86e68efcc140cefbde89b4d1d8708e931528 8370036: TestJhsdbJstackWithVirtualThread.java fails when run with -showversion Reviewed-by: ayang, cjplummer ! test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackWithVirtualThread.java Changeset: 0bdd6f06 Branch: fibers Author: Francesco Andreuzzi Committer: Serguei Spitsyn Date: 2025-10-16 22:04:40 +0000 URL: https://git.openjdk.org/loom/commit/0bdd6f0640fc25667f911228eed6a0fa118e8ff8 8369734: JvmtiExport::post_class_file_load_hook return value is never used Reviewed-by: dholmes, sspitsyn ! src/hotspot/share/prims/jvmtiExport.cpp ! src/hotspot/share/prims/jvmtiExport.hpp Changeset: 4d20f769 Branch: fibers Author: William Kemper Date: 2025-10-17 00:15:37 +0000 URL: https://git.openjdk.org/loom/commit/4d20f7696c015bc0e59544ff064fe0c640d61edf 8370050: Shenandoah: Obsolete ShenandoahPacing option Reviewed-by: ysr ! src/hotspot/share/runtime/arguments.cpp Changeset: bd731564 Branch: fibers Author: Ioi Lam Date: 2025-10-17 00:36:54 +0000 URL: https://git.openjdk.org/loom/commit/bd7315648f2bb18cba9cfbeca00e6132b8eb95ef 8369856: AOT map does not include unregistered classes Co-authored-by: Ashutosh Mehra Reviewed-by: kvn, matsaave ! src/hotspot/share/classfile/systemDictionaryShared.cpp + test/hotspot/jtreg/runtime/cds/AOTMapReader.java = test/hotspot/jtreg/runtime/cds/AOTMapTest.java - test/hotspot/jtreg/runtime/cds/CDSMapReader.java ! test/hotspot/jtreg/runtime/cds/appcds/aotCache/AOTMapTest.java Changeset: 55787fe5 Branch: fibers Author: Prasanta Sadhukhan Date: 2025-10-17 01:31:39 +0000 URL: https://git.openjdk.org/loom/commit/55787fe5f52544ea902cac35f1f552e26d954167 8342401: [TESTBUG] javax/swing/JSpinner/8223788/JSpinnerButtonFocusTest.java test fails in ubuntu 22.04 on SBR Hosts Reviewed-by: honkar, serb ! test/jdk/javax/swing/JSpinner/8223788/JSpinnerButtonFocusTest.java Changeset: 31beb7d3 Branch: fibers Author: Prasanta Sadhukhan Date: 2025-10-17 01:33:30 +0000 URL: https://git.openjdk.org/loom/commit/31beb7d3b34c3516c326c9d29a267f6becb38805 8068310: [TEST_BUG] Test javax/swing/JColorChooser/Test4234761.java fails with GTKL&F Reviewed-by: serb ! test/jdk/javax/swing/JColorChooser/Test4234761.java Changeset: 46c23bb1 Branch: fibers Author: Laurent Bourg?s Date: 2025-10-17 05:43:10 +0000 URL: https://git.openjdk.org/loom/commit/46c23bb1a252916096876c2ae3a72f4a525dd6f9 8341381: Random lines appear in graphic causing by the fix of JDK-8297230 Reviewed-by: prr ! src/java.desktop/share/classes/sun/java2d/marlin/Curve.java ! src/java.desktop/share/classes/sun/java2d/marlin/DMarlinRenderingEngine.java ! src/java.desktop/share/classes/sun/java2d/marlin/Helpers.java ! src/java.desktop/share/classes/sun/java2d/marlin/Stroker.java + test/jdk/sun/java2d/marlin/Bug8341381.java Changeset: a22438dd Branch: fibers Author: Kevin Walls Date: 2025-10-17 08:16:59 +0000 URL: https://git.openjdk.org/loom/commit/a22438ddc5949fcfb6f773bd8dc080cd8a1f2710 8369924: Remove test/jdk/javax/management/remote/mandatory/loading/MissingClassTest.java from problemlist Reviewed-by: sspitsyn ! test/jdk/ProblemList-Virtual.txt Changeset: 9b9559a2 Branch: fibers Author: David Briemann Date: 2025-10-17 08:59:55 +0000 URL: https://git.openjdk.org/loom/commit/9b9559a2e33827126e1aeab7bf6f4861acaae109 8369979: Flag UsePopCountInstruction was accidentally disabled on PPC64 Reviewed-by: aph, mdoerr ! src/hotspot/cpu/ppc/vm_version_ppc.cpp Changeset: e62a7fa3 Branch: fibers Author: Albert Mingkun Yang Date: 2025-10-17 09:02:09 +0000 URL: https://git.openjdk.org/loom/commit/e62a7fa3832bbba11e6d630015f85ae945fac824 8342659: Test vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java failed: Class nsk.share.jdi.TestClass1 was not unloaded Co-authored-by: Chris Plummer Reviewed-by: sspitsyn, cjplummer ! test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jpda/AbstractDebuggeeTest.java Changeset: 0a97bef8 Branch: fibers Author: Albert Mingkun Yang Date: 2025-10-17 09:32:40 +0000 URL: https://git.openjdk.org/loom/commit/0a97bef840f8799313a1a55a65d9334e09cc1cf4 8369814: G1: Relax card mark and store ordering Reviewed-by: tschatzl, fandreuzzi ! src/hotspot/share/gc/g1/g1BarrierSet.hpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp ! src/hotspot/share/gc/serial/serialHeap.cpp ! src/hotspot/share/gc/shared/cardTableBarrierSet.cpp ! src/hotspot/share/gc/shared/cardTableBarrierSet.hpp ! src/hotspot/share/gc/shared/gc_globals.hpp ! src/hotspot/share/gc/shared/vmStructs_gc.hpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp ! src/hotspot/share/runtime/javaThread.cpp ! src/hotspot/share/runtime/javaThread.hpp Changeset: e8e2aadd Branch: fibers Author: Hamlin Li Date: 2025-10-17 11:22:23 +0000 URL: https://git.openjdk.org/loom/commit/e8e2aadd9ea302b7b448d0fda9d069d3813f31c5 8369685: RISC-V: refactor code related to RVFeatureValue::enabled Reviewed-by: fyang, rehn ! src/hotspot/cpu/riscv/vm_version_riscv.cpp ! src/hotspot/cpu/riscv/vm_version_riscv.hpp ! src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp Changeset: b159ca09 Branch: fibers Author: Francesco Andreuzzi Committer: Aleksey Shipilev Date: 2025-10-17 14:19:21 +0000 URL: https://git.openjdk.org/loom/commit/b159ca097a71407d0bc10f6c5d86d5f45c7d7642 8369980: Use ThreadsClaimTokenScope in ShenandoahThreadRoots Reviewed-by: ayang, wkemper ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.hpp Changeset: cc6f8f13 Branch: fibers Author: Brian Burkhalter Date: 2025-10-17 15:12:27 +0000 URL: https://git.openjdk.org/loom/commit/cc6f8f1307476886aa3c43a2b966fc7bff2be04e 8369997: Tests that use custom scheduler should use jdk.test.lib.thread.VThreadScheduler Reviewed-by: sspitsyn, alanb ! test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadStateTest/ThreadStateTest.java ! test/jdk/java/io/ByteArrayOutputStream/WriteToReleasesCarrier.java ! test/jdk/jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java Changeset: 757e9ab3 Branch: fibers Author: Alan Bateman Date: 2025-10-17 16:43:51 +0000 URL: https://git.openjdk.org/loom/commit/757e9ab30dae0b14eee7ef93d14acdf37c533a7c Merge branch 'master' into fibers ! src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp ! src/hotspot/cpu/aarch64/interp_masm_aarch64.hpp ! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp ! src/hotspot/share/runtime/continuationEntry.hpp ! src/hotspot/share/runtime/javaThread.cpp ! src/hotspot/share/runtime/javaThread.hpp ! test/jdk/ProblemList-Virtual.txt ! test/jdk/ProblemList.txt ! src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp ! src/hotspot/cpu/aarch64/interp_masm_aarch64.hpp ! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp ! src/hotspot/share/runtime/continuationEntry.hpp ! src/hotspot/share/runtime/javaThread.cpp ! src/hotspot/share/runtime/javaThread.hpp ! test/jdk/ProblemList-Virtual.txt ! test/jdk/ProblemList.txt Changeset: 00e5869e Branch: fibers Author: Alan Bateman Date: 2025-10-16 08:13:35 +0000 URL: https://git.openjdk.org/loom/commit/00e5869ed3cd11d07bfabc27fc3043687ca91f5b Bad assert when FJP instrumented ! src/java.base/share/classes/jdk/internal/misc/CarrierThread.java Changeset: 022b619a Branch: fibers Author: Alan Bateman Date: 2025-10-17 16:39:35 +0000 URL: https://git.openjdk.org/loom/commit/022b619ae10881ca78b9707c6c39089336a2e959 More API cleanup ! loom-docs/StructuredConcurrent-updates.md ! src/java.base/share/classes/java/util/concurrent/Joiners.java ! src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java ! src/java.base/share/classes/java/util/concurrent/StructuredTaskScopeImpl.java ! test/jdk/java/util/concurrent/StructuredTaskScope/StressCancellation.java ! test/jdk/java/util/concurrent/StructuredTaskScope/StructuredTaskScopeTest.java Changeset: 258c26c8 Branch: fibers Author: Alan Bateman Date: 2025-10-17 16:43:57 +0000 URL: https://git.openjdk.org/loom/commit/258c26c8b417e633eafaedecf25d50f84dd2bb6e Merge loom into fibers Changeset: d1e8c144 Branch: fibers Author: Alan Bateman Date: 2025-10-17 16:45:02 +0000 URL: https://git.openjdk.org/loom/commit/d1e8c14460d53533a35ee6209e482a64f3abbe9f Allow signal when queue resized ! src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java Changeset: 28bf9176 Branch: fibers Author: Leonid Mesnik Date: 2025-10-17 16:03:24 +0000 URL: https://git.openjdk.org/loom/commit/28bf9176b8d460242bb7cedfb3bde5c6294c56fb 8348844: Remove remaining JVMTI tests from ProblemList-Virtual, use requires instead Reviewed-by: dholmes, alanb, syan, sspitsyn ! test/hotspot/jtreg/ProblemList-Virtual.txt ! test/hotspot/jtreg/gc/arguments/TestNewSizeThreadIncrease.java ! test/hotspot/jtreg/gc/g1/TestSkipRebuildRemsetPhase.java ! test/hotspot/jtreg/runtime/ErrorHandling/MachCodeFramesInErrorFile.java ! test/hotspot/jtreg/runtime/Thread/AsyncExceptionOnMonitorEnter.java ! test/hotspot/jtreg/runtime/Thread/StopAtExit.java ! test/hotspot/jtreg/runtime/handshake/HandshakeWalkStackTest.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetCurrentThreadCpuTime/curthrcputime001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadCpuTime/thrcputime001/TestDescription.java ! test/jdk/ProblemList-Virtual.txt ! test/jdk/java/lang/StackWalker/CallerFromMain.java ! test/jdk/java/lang/StackWalker/DumpStackTest.java ! test/jdk/java/lang/StackWalker/StackWalkTest.java ! test/jdk/java/lang/Thread/MainThreadTest.java ! test/jdk/java/lang/Thread/UncaughtExceptionsTest.java ! test/jdk/java/lang/ref/OOMEInReferenceHandler.java ! test/jdk/java/util/concurrent/locks/Lock/OOMEInAQS.java ! test/jdk/jdk/internal/vm/Continuation/Scoped.java Changeset: 1e5e17a1 Branch: fibers Author: Justin Lu Date: 2025-10-17 16:19:35 +0000 URL: https://git.openjdk.org/loom/commit/1e5e17a10a001c189f6ab19f61efca2d08cb0301 8369590: LocaleEnhanceTest has incorrectly passing test case Reviewed-by: naoto ! test/jdk/java/util/Locale/LocaleEnhanceTest.java Changeset: 51f05840 Branch: fibers Author: Alan Bateman Date: 2025-10-17 17:45:46 +0000 URL: https://git.openjdk.org/loom/commit/51f058407cf56337477a7a63ef5bd1e6ca8e22cb Merge branch 'master' into fibers ! test/hotspot/jtreg/ProblemList-Virtual.txt ! test/jdk/ProblemList-Virtual.txt ! test/hotspot/jtreg/ProblemList-Virtual.txt ! test/jdk/ProblemList-Virtual.txt Changeset: 1caced5b Branch: fibers Author: Alan Bateman Date: 2025-10-18 07:35:23 +0000 URL: https://git.openjdk.org/loom/commit/1caced5ba5873b84989f3cbcb8b29ef84788a12b Partial restore of ProblemList-Virtual.txt after merge with JDK-8348844 ! test/jdk/ProblemList-Virtual.txt Changeset: 57d56c9b Branch: fibers Author: Alan Bateman Date: 2025-10-18 07:54:49 +0000 URL: https://git.openjdk.org/loom/commit/57d56c9b5c360135944e9b6b54d83a99ebe8386c Fixed test comments ! loom-docs/StructuredConcurrent-updates.md ! test/jdk/java/util/concurrent/StructuredTaskScope/StructuredTaskScopeTest.java Changeset: 6b6a6a84 Branch: fibers Author: Alan Bateman Date: 2025-10-18 07:55:04 +0000 URL: https://git.openjdk.org/loom/commit/6b6a6a84e58f6a7b1ae318dac2ec2f90d55890b9 Merge loom into fibers From duke at openjdk.org Sat Oct 18 09:28:26 2025 From: duke at openjdk.org (duke) Date: Sat, 18 Oct 2025 09:28:26 GMT Subject: git: openjdk/loom: master: 42 new changesets Message-ID: <3474848b-9f09-42da-8bbe-4ea47d5a7219@openjdk.org> Changeset: 7fe06657 Branch: master Author: Roland Westrelin Date: 2025-10-16 07:23:41 +0000 URL: https://git.openjdk.org/loom/commit/7fe066573004a525673e4ec55df6783b13bfc189 8369167: C2: refactor LShiftINode/LShiftLNode Value/Identity/Ideal Reviewed-by: epeter, mchevalier ! src/hotspot/share/opto/mulnode.cpp ! src/hotspot/share/opto/mulnode.hpp ! src/hotspot/share/opto/node.hpp ! src/hotspot/share/utilities/globalDefinitions.hpp ! test/hotspot/jtreg/compiler/c2/irTests/LShiftINodeIdealizationTests.java ! test/hotspot/jtreg/compiler/c2/irTests/LShiftLNodeIdealizationTests.java Changeset: aed42a16 Branch: master Author: Artem Semenov Date: 2025-10-16 07:28:13 +0000 URL: https://git.openjdk.org/loom/commit/aed42a16bacb24753a536d07fedd736d64cde3be 8365609: Fix several potential NULL native pointer dereferences in the desktop module Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Artem Semenov Artem Semenov Reviewed-by: azvegint, prr, serb ! src/java.desktop/share/native/libsplashscreen/splashscreen_gif.c ! src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c Changeset: ff6a0170 Branch: master Author: Roland Westrelin Date: 2025-10-16 07:35:41 +0000 URL: https://git.openjdk.org/loom/commit/ff6a0170f0ab5cfb4af6d6a4a779451823c486d6 8369258: C2: enable ReassociateInvariants for all loop types Reviewed-by: epeter, qamai ! src/hotspot/share/opto/loopnode.cpp + test/hotspot/jtreg/compiler/loopopts/TestReassociateInvariants.java - test/hotspot/jtreg/compiler/loopopts/superword/TestMemorySegment_8360204.java - test/hotspot/jtreg/compiler/loopopts/superword/TestMemorySegment_8365982.java + test/hotspot/jtreg/compiler/loopopts/superword/TestMemorySegment_ReassociateInvariants1.java + test/hotspot/jtreg/compiler/loopopts/superword/TestMemorySegment_ReassociateInvariants2.java Changeset: 17c13e53 Branch: master Author: Christoph Langer Date: 2025-10-16 07:54:23 +0000 URL: https://git.openjdk.org/loom/commit/17c13e53aff16b294c7c0286ccb6ea3054b1de91 8369683: Exclude runtime/Monitor/MonitorWithDeadObjectTest.java#DumpThreadsBeforeDetach on Alpine Linux debug Reviewed-by: mbaesken, dholmes ! test/hotspot/jtreg/runtime/Monitor/MonitorWithDeadObjectTest.java Changeset: b5b83247 Branch: master Author: Viktor Klang Date: 2025-10-16 08:28:22 +0000 URL: https://git.openjdk.org/loom/commit/b5b83247da9caea30c88b69543e350783663bc46 8369656: Calling CompletableFuture.join() could execute task in common pool Reviewed-by: alanb, dl ! src/java.base/share/classes/java/util/concurrent/CompletableFuture.java ! test/jdk/java/util/concurrent/tck/CompletableFutureTest.java Changeset: 6e911d81 Branch: master Author: Martin Doerr Date: 2025-10-16 09:40:55 +0000 URL: https://git.openjdk.org/loom/commit/6e911d819efa0f14ab1f9009b5bf325d99edb26c 8368205: [TESTBUG] VectorMaskCompareNotTest.java crashes when MaxVectorSize=8 Reviewed-by: dzhang, epeter, rrich ! test/hotspot/jtreg/compiler/vectorapi/VectorMaskCompareNotTest.java ! test/jtreg-ext/requires/VMProps.java Changeset: d6c122b3 Branch: master Author: Erik Gahlin Date: 2025-10-16 09:57:11 +0000 URL: https://git.openjdk.org/loom/commit/d6c122b3ff1ccd559ba9c310976a77eefaf09ece 8369982: ProblemList jdk/jfr/jvm/TestWaste.java Reviewed-by: tschatzl, dholmes ! test/jdk/ProblemList.txt Changeset: ead35a75 Branch: master Author: Daniel Jeli?ski Date: 2025-10-16 11:05:13 +0000 URL: https://git.openjdk.org/loom/commit/ead35a754bf3a545a1b68f28d3d939750f11af39 8358942: HttpClient adds Content-Length: 0 for a GET request with a BodyPublishers.noBody() Reviewed-by: dfuchs, vyazici ! src/java.net.http/share/classes/jdk/internal/net/http/Http1Request.java ! test/jdk/java/net/httpclient/ContentLengthHeaderTest.java Changeset: 5fc3904b Branch: master Author: Stefan Karlsson Date: 2025-10-16 11:16:05 +0000 URL: https://git.openjdk.org/loom/commit/5fc3904bfe290625ed6cf9b41773b35b52bf72b7 8369491: Temporarily revert default TIMEOUT_FACTOR back to 4 Reviewed-by: lkorinth, cstein, jpai, syan, serb, prr ! doc/testing.html ! doc/testing.md ! make/RunTests.gmk Changeset: 16539998 Branch: master Author: Yasumasa Suenaga Date: 2025-10-16 12:45:05 +0000 URL: https://git.openjdk.org/loom/commit/1653999871c8d7b1e61b44f8525e09b2cd0bdb6b 8369505: jhsdb jstack cannot handle continuation stub Reviewed-by: cjplummer, pchilanomate ! src/hotspot/share/runtime/continuationEntry.hpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeBlob.java + src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ContinuationEntry.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaThread.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/aarch64/AARCH64Frame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/riscv64/RISCV64Frame.java ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/x86/X86Frame.java + test/hotspot/jtreg/serviceability/sa/LingeredAppWithVirtualThread.java + test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackWithVirtualThread.java Changeset: f475eb8e Branch: master Author: Hamlin Li Date: 2025-10-16 14:04:45 +0000 URL: https://git.openjdk.org/loom/commit/f475eb8ee7c9a3e360b2f1210ed71b629243cd2a 8368950: RISC-V: fail to catch out of order declarations among dependent cpu extensions/flags Reviewed-by: fyang, luhenry ! src/hotspot/cpu/riscv/vm_version_riscv.hpp ! src/hotspot/os_cpu/linux_riscv/riscv_hwprobe.cpp Changeset: 5dfe115c Branch: master Author: Emanuel Peter Date: 2025-10-16 14:10:14 +0000 URL: https://git.openjdk.org/loom/commit/5dfe115ce1fbcff67777518a3c23a7560ebec423 8369912: [TESTBUG] testlibrary_tests/template_framework/examples/TestExpressions.java fails with ArithmeticException: / by zero - forgot to respect Expression.info Reviewed-by: kvn, mhaessig ! test/hotspot/jtreg/testlibrary_tests/template_framework/examples/TestExpressions.java Changeset: f2a99832 Branch: master Author: Emanuel Peter Date: 2025-10-16 14:22:15 +0000 URL: https://git.openjdk.org/loom/commit/f2a998326a6bebd4a7d2d0a39f785b2e6dac68c4 8369804: TestGenerators.java fails with IllegalArgumentException: bound must be greater than origin Reviewed-by: chagedorn, thartmann ! test/hotspot/jtreg/compiler/lib/generators/UniformDoubleGenerator.java ! test/hotspot/jtreg/compiler/lib/generators/UniformFloatGenerator.java ! test/hotspot/jtreg/testlibrary_tests/generators/tests/TestGenerators.java Changeset: 303eb109 Branch: master Author: Daniel Lund?n Date: 2025-10-16 15:02:32 +0000 URL: https://git.openjdk.org/loom/commit/303eb1096ccaf06106aa080b9ea0553c0f6912dd 8369573: Add missing compile commands help documentation for the signature part of method patterns Reviewed-by: rcastanedalo, aseoane, thartmann ! src/hotspot/share/compiler/compilerOracle.cpp Changeset: 87092ef1 Branch: master Author: Arno Zeller Committer: Matthias Baesken Date: 2025-10-16 15:15:19 +0000 URL: https://git.openjdk.org/loom/commit/87092ef1d97e00ddb6674b0e309f2f904d307604 8183336: Better cleanup for jdk/test/java/lang/module/customfs/ModulesInCustomFileSystem.java Reviewed-by: alanb, syan ! test/jdk/java/lang/module/customfs/ModulesInCustomFileSystem.java Changeset: 95380e1e Branch: master Author: Roger Riggs Date: 2025-10-16 15:54:22 +0000 URL: https://git.openjdk.org/loom/commit/95380e1ea5c3f531f82fb7c4b2f75726f3cd2fc2 8362637: Convert java.nio.ByteOrder to an enum Reviewed-by: alanb, liach, bpb ! src/java.base/share/classes/java/nio/ByteOrder.java Changeset: e56db377 Branch: master Author: Christian Hagedorn Date: 2025-10-16 16:02:26 +0000 URL: https://git.openjdk.org/loom/commit/e56db37734aa7cbc0f20ba3fc469f51224f288fa 8369232: testlibrary_tests/ir_framework/tests/TestScenariosCrossProduct.java timed out Reviewed-by: dfenacci, epeter ! test/hotspot/jtreg/compiler/lib/ir_framework/TestFramework.java ! test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestScenariosCrossProduct.java Changeset: 7e032409 Branch: master Author: Joe Darcy Date: 2025-10-16 16:38:18 +0000 URL: https://git.openjdk.org/loom/commit/7e03240974cd66c471f5d02e14fd77971fe6d173 8369858: Remove darcy author tags from jdk tests Reviewed-by: rriggs, iris, lancea ! test/jdk/java/io/Serializable/cloneArray/CloneArray.java ! test/jdk/java/lang/Byte/Decode.java ! test/jdk/java/lang/Class/IsAnnotationType.java ! test/jdk/java/lang/Class/IsEnum.java ! test/jdk/java/lang/Class/IsSynthetic.java ! test/jdk/java/lang/Class/getEnclosingConstructor/EnclosingConstructorTests.java ! test/jdk/java/lang/Class/getEnclosingMethod/EnclosingMethodTests.java ! test/jdk/java/lang/Double/BitwiseConversion.java ! test/jdk/java/lang/Double/Constants.java ! test/jdk/java/lang/Double/Extrema.java ! test/jdk/java/lang/Double/NaNInfinityParsing.java ! test/jdk/java/lang/Double/ParseHexFloatingPoint.java ! test/jdk/java/lang/Double/ToHexString.java ! test/jdk/java/lang/Float/BitwiseConversion.java ! test/jdk/java/lang/Float/Constants.java ! test/jdk/java/lang/Float/Extrema.java ! test/jdk/java/lang/Float/NaNInfinityParsing.java ! test/jdk/java/lang/Integer/Decode.java ! test/jdk/java/lang/Integer/ParsingTest.java ! test/jdk/java/lang/Integer/Unsigned.java ! test/jdk/java/lang/Long/Decode.java ! test/jdk/java/lang/Long/ParsingTest.java ! test/jdk/java/lang/Long/Unsigned.java ! test/jdk/java/lang/Short/Decode.java ! test/jdk/java/lang/Throwable/SuppressedExceptions.java ! test/jdk/java/lang/annotation/Missing/MissingTest.java ! test/jdk/java/lang/annotation/TestIncompleteAnnotationExceptionNPE.java ! test/jdk/java/lang/reflect/AnnotatedElement/TestAnnotatedElementDefaults.java ! test/jdk/java/lang/reflect/Constructor/GenericStringTest.java ! test/jdk/java/lang/reflect/Constructor/TestParameterAnnotations.java ! test/jdk/java/lang/reflect/DefaultAccessibility.java ! test/jdk/java/lang/reflect/Field/GenericStringTest.java ! test/jdk/java/lang/reflect/Generics/HashCodeTest.java ! test/jdk/java/lang/reflect/Generics/Probe.java ! test/jdk/java/lang/reflect/Generics/StringsAndBounds.java ! test/jdk/java/lang/reflect/Generics/TestParameterizedType.java ! test/jdk/java/lang/reflect/Generics/exceptionCauseTest.java ! test/jdk/java/lang/reflect/Generics/getAnnotationTest.java ! test/jdk/java/lang/reflect/Method/GenericStringTest.java ! test/jdk/java/lang/reflect/Method/IsDefaultTest.java ! test/jdk/java/lang/reflect/Method/defaultMethodModeling/DefaultMethodModeling.java ! test/jdk/java/lang/reflect/TypeVariable/TestAnnotatedElement.java ! test/jdk/java/math/BigDecimal/AddTests.java ! test/jdk/java/math/BigDecimal/CompareToTests.java ! test/jdk/java/math/BigDecimal/DivideTests.java ! test/jdk/java/math/BigDecimal/IntegralDivisionTests.java ! test/jdk/java/math/BigDecimal/NegateTests.java ! test/jdk/java/math/BigDecimal/PowTests.java ! test/jdk/java/math/BigDecimal/PrecisionTests.java ! test/jdk/java/math/BigDecimal/RoundingTests.java ! test/jdk/java/math/BigDecimal/ScaleByPowerOfTenTests.java ! test/jdk/java/math/BigDecimal/StrippingZerosTest.java ! test/jdk/java/math/BigDecimal/ToPlainStringTests.java ! test/jdk/java/math/BigDecimal/ZeroScalingTests.java ! test/jdk/java/math/BigInteger/CompareToTests.java ! test/jdk/java/math/BigInteger/ExtremeShiftingTests.java ! test/jdk/java/math/BigInteger/OperatorNpeTests.java ! test/jdk/java/math/BigInteger/StringConstructor.java ! test/jdk/java/math/BigInteger/TestValueExact.java ! test/jdk/java/math/RoundingMode/RoundingModeTests.java ! test/jdk/tools/launcher/ChangeDataModel.java ! test/jdk/tools/launcher/I18NTest.java ! test/jdk/tools/launcher/UnresolvedExceptions.java Changeset: 873666d1 Branch: master Author: Chris Plummer Date: 2025-10-16 16:53:47 +0000 URL: https://git.openjdk.org/loom/commit/873666d157340b3b953ad869576afd30d4304610 8369451: Debug agent support for USE_ITERATE_THROUGH_HEAP is broken and should be removed Reviewed-by: sspitsyn, amenkov ! src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c ! src/jdk.jdwp.agent/share/native/libjdwp/util.c ! src/jdk.jdwp.agent/share/native/libjdwp/util.h Changeset: d7b525ab Branch: master Author: Phil Race Date: 2025-10-16 16:58:38 +0000 URL: https://git.openjdk.org/loom/commit/d7b525ab9980743cf0cab3e3daaa4ccb725bfea8 8364673: Remove duplicate font mapping for itcavantgarde in psfontj2d.properties Reviewed-by: azvegint, kizune ! src/java.desktop/share/conf/psfontj2d.properties Changeset: 844118a9 Branch: master Author: Phil Race Date: 2025-10-16 16:58:56 +0000 URL: https://git.openjdk.org/loom/commit/844118a9d854459778f88d299b148c2288131344 8369146: java/awt/PrintJob/GetGraphicsTest.java: Parse Exception: Invalid or unrecognized bugid: 50510568367702 Reviewed-by: syan, azvegint, kizune, jdv ! test/jdk/java/awt/PrintJob/GetGraphicsTest.java Changeset: d4472979 Branch: master Author: William Kemper Date: 2025-10-16 17:49:08 +0000 URL: https://git.openjdk.org/loom/commit/d4472979c43d9825ed2d008dbaed26dbf6d36180 8367709: GenShen: Dirty cards for objects that get promoted by safepoint that intervenes between allocation and stores Reviewed-by: ysr ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp ! src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.cpp ! src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp ! src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.inline.hpp Changeset: 9589a29d Branch: master Author: Mikael Vidstedt Date: 2025-10-16 19:43:44 +0000 URL: https://git.openjdk.org/loom/commit/9589a29d2515888b437d382204df22d01d4266ff 8355752: Bump minimum boot jdk to JDK 25 Reviewed-by: darcy, shade, ihse, iris ! make/conf/github-actions.conf ! make/conf/jib-profiles.js ! make/conf/version-numbers.conf Changeset: 3248aaf3 Branch: master Author: Chen Liang Date: 2025-10-16 19:45:57 +0000 URL: https://git.openjdk.org/loom/commit/3248aaf3c4f6784d5176e2a2c5bac0fbda47ee6b 8356548: Use ClassFile API instead of ASM to transform classes in tests Reviewed-by: sspitsyn, lmesnik, coleenp, iklam ! test/hotspot/jtreg/compiler/calls/common/InvokeDynamicPatcher.java ! test/hotspot/jtreg/compiler/calls/fromCompiled/CompiledInvokeDynamic2CompiledTest.java ! test/hotspot/jtreg/compiler/calls/fromCompiled/CompiledInvokeDynamic2InterpretedTest.java ! test/hotspot/jtreg/compiler/calls/fromCompiled/CompiledInvokeDynamic2NativeTest.java ! test/hotspot/jtreg/compiler/calls/fromInterpreted/InterpretedInvokeDynamic2CompiledTest.java ! test/hotspot/jtreg/compiler/calls/fromInterpreted/InterpretedInvokeDynamic2InterpretedTest.java ! test/hotspot/jtreg/compiler/calls/fromInterpreted/InterpretedInvokeDynamic2NativeTest.java ! test/hotspot/jtreg/compiler/jsr292/RedefineMethodUsedByMultipleMethodHandles.java ! test/hotspot/jtreg/compiler/jvmci/common/CTVMUtilities.java ! test/hotspot/jtreg/runtime/MirrorFrame/Asmator.java ! test/hotspot/jtreg/runtime/MirrorFrame/Test8003720.java ! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/MissedStackMapFrames/MissedStackMapFrames.java ! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineAnnotations.java ! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineGenericSignatureTest.java ! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineObject.java ! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/GenClassPoolJar.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_keepRef_rootClass_inMemoryCompilation_keep_cl/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_keepRef_rootClass_inMemoryCompilation_keep_class/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_keepRef_rootClass_inMemoryCompilation_keep_obj/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_keepRef_rootClass_keep_cl/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_keepRef_rootClass_keep_class/TestDescription.java ! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_keepRef_rootClass_keep_obj/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassFields/getclfld007.java Changeset: 1392a0b4 Branch: master Author: Albert Mingkun Yang Date: 2025-10-16 19:55:07 +0000 URL: https://git.openjdk.org/loom/commit/1392a0b4608f6196f207fcebbab75b2d79fdc758 8368740: Serial: Swap eden and survivor spaces position in young generation Reviewed-by: gli, fandreuzzi ! src/hotspot/share/gc/serial/defNewGeneration.cpp ! src/hotspot/share/gc/serial/defNewGeneration.hpp ! src/hotspot/share/gc/serial/serialHeap.cpp ! src/hotspot/share/gc/serial/serialHeap.hpp ! src/hotspot/share/gc/shared/space.cpp Changeset: 18fd0477 Branch: master Author: Justin King Date: 2025-10-16 19:59:13 +0000 URL: https://git.openjdk.org/loom/commit/18fd04770294e27011bd576b5ea5fe43fa03e5e3 8369506: Bytecode rewriting causes Java heap corruption on AArch64 Co-authored-by: Man Cao Co-authored-by: Chuck Rasbold Reviewed-by: shade, aph, manc ! src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp ! src/hotspot/cpu/aarch64/interp_masm_aarch64.hpp ! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp Changeset: 0c1c86e6 Branch: master Author: Patricio Chilano Mateo Date: 2025-10-16 21:20:42 +0000 URL: https://git.openjdk.org/loom/commit/0c1c86e68efcc140cefbde89b4d1d8708e931528 8370036: TestJhsdbJstackWithVirtualThread.java fails when run with -showversion Reviewed-by: ayang, cjplummer ! test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackWithVirtualThread.java Changeset: 0bdd6f06 Branch: master Author: Francesco Andreuzzi Committer: Serguei Spitsyn Date: 2025-10-16 22:04:40 +0000 URL: https://git.openjdk.org/loom/commit/0bdd6f0640fc25667f911228eed6a0fa118e8ff8 8369734: JvmtiExport::post_class_file_load_hook return value is never used Reviewed-by: dholmes, sspitsyn ! src/hotspot/share/prims/jvmtiExport.cpp ! src/hotspot/share/prims/jvmtiExport.hpp Changeset: 4d20f769 Branch: master Author: William Kemper Date: 2025-10-17 00:15:37 +0000 URL: https://git.openjdk.org/loom/commit/4d20f7696c015bc0e59544ff064fe0c640d61edf 8370050: Shenandoah: Obsolete ShenandoahPacing option Reviewed-by: ysr ! src/hotspot/share/runtime/arguments.cpp Changeset: bd731564 Branch: master Author: Ioi Lam Date: 2025-10-17 00:36:54 +0000 URL: https://git.openjdk.org/loom/commit/bd7315648f2bb18cba9cfbeca00e6132b8eb95ef 8369856: AOT map does not include unregistered classes Co-authored-by: Ashutosh Mehra Reviewed-by: kvn, matsaave ! src/hotspot/share/classfile/systemDictionaryShared.cpp + test/hotspot/jtreg/runtime/cds/AOTMapReader.java = test/hotspot/jtreg/runtime/cds/AOTMapTest.java - test/hotspot/jtreg/runtime/cds/CDSMapReader.java ! test/hotspot/jtreg/runtime/cds/appcds/aotCache/AOTMapTest.java Changeset: 55787fe5 Branch: master Author: Prasanta Sadhukhan Date: 2025-10-17 01:31:39 +0000 URL: https://git.openjdk.org/loom/commit/55787fe5f52544ea902cac35f1f552e26d954167 8342401: [TESTBUG] javax/swing/JSpinner/8223788/JSpinnerButtonFocusTest.java test fails in ubuntu 22.04 on SBR Hosts Reviewed-by: honkar, serb ! test/jdk/javax/swing/JSpinner/8223788/JSpinnerButtonFocusTest.java Changeset: 31beb7d3 Branch: master Author: Prasanta Sadhukhan Date: 2025-10-17 01:33:30 +0000 URL: https://git.openjdk.org/loom/commit/31beb7d3b34c3516c326c9d29a267f6becb38805 8068310: [TEST_BUG] Test javax/swing/JColorChooser/Test4234761.java fails with GTKL&F Reviewed-by: serb ! test/jdk/javax/swing/JColorChooser/Test4234761.java Changeset: 46c23bb1 Branch: master Author: Laurent Bourg?s Date: 2025-10-17 05:43:10 +0000 URL: https://git.openjdk.org/loom/commit/46c23bb1a252916096876c2ae3a72f4a525dd6f9 8341381: Random lines appear in graphic causing by the fix of JDK-8297230 Reviewed-by: prr ! src/java.desktop/share/classes/sun/java2d/marlin/Curve.java ! src/java.desktop/share/classes/sun/java2d/marlin/DMarlinRenderingEngine.java ! src/java.desktop/share/classes/sun/java2d/marlin/Helpers.java ! src/java.desktop/share/classes/sun/java2d/marlin/Stroker.java + test/jdk/sun/java2d/marlin/Bug8341381.java Changeset: a22438dd Branch: master Author: Kevin Walls Date: 2025-10-17 08:16:59 +0000 URL: https://git.openjdk.org/loom/commit/a22438ddc5949fcfb6f773bd8dc080cd8a1f2710 8369924: Remove test/jdk/javax/management/remote/mandatory/loading/MissingClassTest.java from problemlist Reviewed-by: sspitsyn ! test/jdk/ProblemList-Virtual.txt Changeset: 9b9559a2 Branch: master Author: David Briemann Date: 2025-10-17 08:59:55 +0000 URL: https://git.openjdk.org/loom/commit/9b9559a2e33827126e1aeab7bf6f4861acaae109 8369979: Flag UsePopCountInstruction was accidentally disabled on PPC64 Reviewed-by: aph, mdoerr ! src/hotspot/cpu/ppc/vm_version_ppc.cpp Changeset: e62a7fa3 Branch: master Author: Albert Mingkun Yang Date: 2025-10-17 09:02:09 +0000 URL: https://git.openjdk.org/loom/commit/e62a7fa3832bbba11e6d630015f85ae945fac824 8342659: Test vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java failed: Class nsk.share.jdi.TestClass1 was not unloaded Co-authored-by: Chris Plummer Reviewed-by: sspitsyn, cjplummer ! test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jpda/AbstractDebuggeeTest.java Changeset: 0a97bef8 Branch: master Author: Albert Mingkun Yang Date: 2025-10-17 09:32:40 +0000 URL: https://git.openjdk.org/loom/commit/0a97bef840f8799313a1a55a65d9334e09cc1cf4 8369814: G1: Relax card mark and store ordering Reviewed-by: tschatzl, fandreuzzi ! src/hotspot/share/gc/g1/g1BarrierSet.hpp ! src/hotspot/share/gc/g1/g1CollectedHeap.cpp ! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp ! src/hotspot/share/gc/serial/serialHeap.cpp ! src/hotspot/share/gc/shared/cardTableBarrierSet.cpp ! src/hotspot/share/gc/shared/cardTableBarrierSet.hpp ! src/hotspot/share/gc/shared/gc_globals.hpp ! src/hotspot/share/gc/shared/vmStructs_gc.hpp ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp ! src/hotspot/share/runtime/javaThread.cpp ! src/hotspot/share/runtime/javaThread.hpp Changeset: e8e2aadd Branch: master Author: Hamlin Li Date: 2025-10-17 11:22:23 +0000 URL: https://git.openjdk.org/loom/commit/e8e2aadd9ea302b7b448d0fda9d069d3813f31c5 8369685: RISC-V: refactor code related to RVFeatureValue::enabled Reviewed-by: fyang, rehn ! src/hotspot/cpu/riscv/vm_version_riscv.cpp ! src/hotspot/cpu/riscv/vm_version_riscv.hpp ! src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp Changeset: b159ca09 Branch: master Author: Francesco Andreuzzi Committer: Aleksey Shipilev Date: 2025-10-17 14:19:21 +0000 URL: https://git.openjdk.org/loom/commit/b159ca097a71407d0bc10f6c5d86d5f45c7d7642 8369980: Use ThreadsClaimTokenScope in ShenandoahThreadRoots Reviewed-by: ayang, wkemper ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp ! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.hpp Changeset: cc6f8f13 Branch: master Author: Brian Burkhalter Date: 2025-10-17 15:12:27 +0000 URL: https://git.openjdk.org/loom/commit/cc6f8f1307476886aa3c43a2b966fc7bff2be04e 8369997: Tests that use custom scheduler should use jdk.test.lib.thread.VThreadScheduler Reviewed-by: sspitsyn, alanb ! test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadStateTest/ThreadStateTest.java ! test/jdk/java/io/ByteArrayOutputStream/WriteToReleasesCarrier.java ! test/jdk/jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java Changeset: 28bf9176 Branch: master Author: Leonid Mesnik Date: 2025-10-17 16:03:24 +0000 URL: https://git.openjdk.org/loom/commit/28bf9176b8d460242bb7cedfb3bde5c6294c56fb 8348844: Remove remaining JVMTI tests from ProblemList-Virtual, use requires instead Reviewed-by: dholmes, alanb, syan, sspitsyn ! test/hotspot/jtreg/ProblemList-Virtual.txt ! test/hotspot/jtreg/gc/arguments/TestNewSizeThreadIncrease.java ! test/hotspot/jtreg/gc/g1/TestSkipRebuildRemsetPhase.java ! test/hotspot/jtreg/runtime/ErrorHandling/MachCodeFramesInErrorFile.java ! test/hotspot/jtreg/runtime/Thread/AsyncExceptionOnMonitorEnter.java ! test/hotspot/jtreg/runtime/Thread/StopAtExit.java ! test/hotspot/jtreg/runtime/handshake/HandshakeWalkStackTest.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetCurrentThreadCpuTime/curthrcputime001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetThreadCpuTime/thrcputime001/TestDescription.java ! test/jdk/ProblemList-Virtual.txt ! test/jdk/java/lang/StackWalker/CallerFromMain.java ! test/jdk/java/lang/StackWalker/DumpStackTest.java ! test/jdk/java/lang/StackWalker/StackWalkTest.java ! test/jdk/java/lang/Thread/MainThreadTest.java ! test/jdk/java/lang/Thread/UncaughtExceptionsTest.java ! test/jdk/java/lang/ref/OOMEInReferenceHandler.java ! test/jdk/java/util/concurrent/locks/Lock/OOMEInAQS.java ! test/jdk/jdk/internal/vm/Continuation/Scoped.java Changeset: 1e5e17a1 Branch: master Author: Justin Lu Date: 2025-10-17 16:19:35 +0000 URL: https://git.openjdk.org/loom/commit/1e5e17a10a001c189f6ab19f61efca2d08cb0301 8369590: LocaleEnhanceTest has incorrectly passing test case Reviewed-by: naoto ! test/jdk/java/util/Locale/LocaleEnhanceTest.java From alan.bateman at oracle.com Sun Oct 19 10:32:09 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Sun, 19 Oct 2025 11:32:09 +0100 Subject: Remark on the StructuredTaskScope API of Java 25 In-Reply-To: <2087574876.55745.1758833190197.JavaMail.zimbra@univ-eiffel.fr> References: <715342229.35882407.1758728261503.JavaMail.zimbra@univ-eiffel.fr> <79566ee3-ef1d-4d07-a716-90a3428a45c9@oracle.com> <2087574876.55745.1758833190197.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <1dac2620-bc20-4d3f-b37c-21034c7c72c4@oracle.com> On 25/09/2025 21:46, forax at univ-mlv.fr wrote: > > > ------------------------------------------------------------------------ > > *From: *"Alan Bateman" > *To: *"Remi Forax" , "loom-dev" > > *Sent: *Thursday, September 25, 2025 3:50:16 PM > *Subject: *Re: Remark on the StructuredTaskScope API of Java 25 > > On 24/09/2025 16:37, Remi Forax wrote: > > : > > - allSuccessfulOrThrow() should return a Joiner>>, so the result is a List and not a stream. > In terms of implementation, in result(), the code should be > return Collections.unmodifiableList(subtasks); > > Can you say more on this? Right now, preferring a stream works > well. For a Joiner returned by allSuccessfulOrThrow it makes it > easy to use join().map(Subtask::get) or other mapping function. > Add .toList() to get a list. > > > A collection is more powerful than a Stream, you can always do more > with a List than with a Stream > (like indexed access). > > Yes, you can always call toList() on a stream, but you are asking to > duplicate all the elements, > here stream.toList() is semantically equivalent to a call to > List.copyOf(), so it's slow if you have quite a lot of elements. > > So yes, it might be convenient for some use cases to return a stream > than to call .stream() on the returned List, > but you are trading convenience for performance. I don't think this is right argument to change it to return List. However, another angle is that users might assume the stream is lazily populated and that results can be consumed before join completes. For this Joiner, join is meant to wait until all subtasks complete or any subtask fails. So while returning a Stream is much more flexible, it may indeed be better to return a List. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Sun Oct 19 10:54:14 2025 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Sun, 19 Oct 2025 12:54:14 +0200 (CEST) Subject: Remark on the StructuredTaskScope API of Java 25 In-Reply-To: <1dac2620-bc20-4d3f-b37c-21034c7c72c4@oracle.com> References: <715342229.35882407.1758728261503.JavaMail.zimbra@univ-eiffel.fr> <79566ee3-ef1d-4d07-a716-90a3428a45c9@oracle.com> <2087574876.55745.1758833190197.JavaMail.zimbra@univ-eiffel.fr> <1dac2620-bc20-4d3f-b37c-21034c7c72c4@oracle.com> Message-ID: <298756004.18572588.1760871254293.JavaMail.zimbra@univ-eiffel.fr> > From: "Alan Bateman" > To: "Remi Forax" > Cc: "loom-dev" > Sent: Sunday, October 19, 2025 12:32:09 PM > Subject: Re: Remark on the StructuredTaskScope API of Java 25 > On 25/09/2025 21:46, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] wrote: >>> From: "Alan Bateman" [ mailto:alan.bateman at oracle.com | >>> ] >>> To: "Remi Forax" [ mailto:forax at univ-mlv.fr | ] , "loom-dev" >>> [ mailto:loom-dev at openjdk.java.net | ] >>> Sent: Thursday, September 25, 2025 3:50:16 PM >>> Subject: Re: Remark on the StructuredTaskScope API of Java 25 >>> On 24/09/2025 16:37, Remi Forax wrote: >>>> : >>>> - allSuccessfulOrThrow() should return a Joiner>>, so the >>>> result is a List and not a stream. >>>> In terms of implementation, in result(), the code should be >>>> return Collections.unmodifiableList(subtasks); >>> Can you say more on this? Right now, preferring a stream works well. For a >>> Joiner returned by allSuccessfulOrThrow it makes it easy to use >>> join().map(Subtask::get) or other mapping function. Add .toList() to get a >>> list. >> A collection is more powerful than a Stream, you can always do more with a List >> than with a Stream >> (like indexed access). >> Yes, you can always call toList() on a stream, but you are asking to duplicate >> all the elements, >> here stream.toList() is semantically equivalent to a call to List.copyOf(), so >> it's slow if you have quite a lot of elements. >> So yes, it might be convenient for some use cases to return a stream than to >> call .stream() on the returned List, >> but you are trading convenience for performance. > I don't think this is right argument to change it to return List. However, > another angle is that users might assume the stream is lazily populated and > that results can be consumed before join completes. For this Joiner, join is > meant to wait until all subtasks complete or any subtask fails. So while > returning a Stream is much more flexible, it may indeed be better to return a > List. I agree, this argument is a better argument. But I still disagree that a Stream is more flexible than a List, a stream is an abstraction over a computation, it can be an infinite loop. > -Alan regards, R?mi -------------- next part -------------- An HTML attachment was scrubbed... URL: