From duke at openjdk.org  Thu Jan  1 09:16:24 2026
From: duke at openjdk.org (duke)
Date: Thu, 1 Jan 2026 09:16:24 GMT
Subject: git: openjdk/loom: fibers: 51 new changesets
Message-ID: <2b3b1d72-6014-43b8-a0d8-715d02a23c8c@openjdk.org>

Changeset: 3579c752
Branch: fibers
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2025-12-22 07:57:31 +0000
URL:       https://git.openjdk.org/loom/commit/3579c752bcf2c160de47ec748c8b649b0028826a

8373876: StackWalkNativeToJava print more output in case of failures

Reviewed-by: dholmes, mdoerr

! test/hotspot/jtreg/runtime/ErrorHandling/StackWalkNativeToJava.java

Changeset: e6c3ebe2
Branch: fibers
Author:    Stefan Karlsson <stefank at openjdk.org>
Date:      2025-12-22 09:32:22 +0000
URL:       https://git.openjdk.org/loom/commit/e6c3ebe27b0dd4cbf1885d79ea50acb208e364fa

8374145: Remove legacy locking remnants from markWord

Reviewed-by: aboldtch, kbarrett, coleenp

! src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
! src/hotspot/share/oops/markWord.hpp

Changeset: 551e6562
Branch: fibers
Author:    Stefan Karlsson <stefank at openjdk.org>
Date:      2025-12-22 09:55:38 +0000
URL:       https://git.openjdk.org/loom/commit/551e656218f18fa815d42e6035f85e907c6d66a4

8374113: Taughtological if check in Reflection::array_set

Reviewed-by: fparain, liach

! src/hotspot/share/runtime/reflection.cpp

Changeset: 2715f5e6
Branch: fibers
Author:    Stefan Karlsson <stefank at openjdk.org>
Date:      2025-12-22 10:16:14 +0000
URL:       https://git.openjdk.org/loom/commit/2715f5e698b49cd67faa233a3188e6a69ddb80c0

8374151: Cleanup minor markWord function disorder

Reviewed-by: rcastanedalo, dholmes

! src/hotspot/share/oops/markWord.hpp

Changeset: a61a1d32
Branch: fibers
Author:    Damon Fenacci <dfenacci at openjdk.org>
Date:      2025-12-22 12:49:30 +0000
URL:       https://git.openjdk.org/loom/commit/a61a1d32a2bbf227081b9da6d101071ceb73076a

8373525: C2: assert(_base == Long) failed: Not a Long

Reviewed-by: chagedorn, mhaessig

! src/hotspot/share/opto/addnode.cpp
+ test/hotspot/jtreg/compiler/loopopts/TestValidTypeInOverflowProtection.java

Changeset: 9715e6da
Branch: fibers
Author:    Jie Fu <jiefu at openjdk.org>
Date:      2025-12-22 15:15:20 +0000
URL:       https://git.openjdk.org/loom/commit/9715e6da8355a103d9066bd15ce68b4773cbadcb

8374178: Missing include in systemDictionary.cpp after JDK-8365526

Reviewed-by: kbarrett, dholmes

! src/hotspot/share/classfile/systemDictionary.cpp

Changeset: 72505420
Branch: fibers
Author:    Chris Plummer <cjplummer at openjdk.org>
Date:      2025-12-22 19:28:10 +0000
URL:       https://git.openjdk.org/loom/commit/72505420ca22c2ba1584f9d401ff0a1047b8c79b

8374038: JDI EventRequestManager javadoc has unrendered @link tags inside an @code block

Reviewed-by: kevinw, amenkov

! src/jdk.jdi/share/classes/com/sun/jdi/request/EventRequestManager.java

Changeset: 4b8eda30
Branch: fibers
Author:    Ioi Lam <iklam at openjdk.org>
Date:      2025-12-22 19:43:55 +0000
URL:       https://git.openjdk.org/loom/commit/4b8eda30474b99a9f1065e5cea9d8c2fb859bab2

8373983: java/util/Locale/UseOldISOCodesTest.java fails with JTREG_AOT_JDK=onestep

Reviewed-by: naoto

! test/jdk/ProblemList-AotJdk.txt

Changeset: ecb42341
Branch: fibers
Author:    Chen Liang <liach at openjdk.org>
Date:      2025-12-23 00:12:55 +0000
URL:       https://git.openjdk.org/loom/commit/ecb42341a94326b1ee85ddd7b9ebadce8c952b99

8373447: Suspicious sign extension after integer promotion in imageDecompressor.cpp

Reviewed-by: alanb

! src/java.base/share/native/libjimage/imageDecompressor.cpp

Changeset: a0094f52
Branch: fibers
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
Date:      2025-12-23 04:39:50 +0000
URL:       https://git.openjdk.org/loom/commit/a0094f529a6cf7e1e28a20d5033a9a1405f49d9f

8374216: Assorted changes to jpackage without functional impact

Reviewed-by: almatvee

! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxBundlingEnvironment.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacBundlingEnvironment.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/DefaultBundlingEnvironment.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/LauncherBuilder.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/LauncherFromOptions.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/PackagingPipeline.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/OptionSpecMapperOptionScope.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardBundlingOperation.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardOption.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/Application.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/BundleSpec.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/BundlingOperationDescriptor.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/Package.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/IdentityWrapper.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/SetBuilder.java
! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinBundlingEnvironment.java
= src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinFromOptions.java
! test/jdk/tools/jpackage/helpers-test/jdk/jpackage/test/JUnitUtilsTest.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/helpers/jdk/jpackage/test/MsiDatabase.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/PackageType.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TKit.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/OptionsValidationFailTest.java
! test/jdk/tools/jpackage/junit/tools/jdk/jpackage/test/JUnitUtils.java
! test/jdk/tools/jpackage/share/BasicTest.java
! test/jdk/tools/jpackage/share/InOutPathTest.java

Changeset: e1d81c09
Branch: fibers
Author:    Hao Sun <haosun at openjdk.org>
Date:      2025-12-23 08:08:25 +0000
URL:       https://git.openjdk.org/loom/commit/e1d81c0946364a266a006481a8fbbac24c7e6c6a

8373122: JFR build failure with CDS disabled due to -Werror=unused-function after JDK-8365400

Reviewed-by: mgronlun, jiefu, fandreuzzi

! src/hotspot/share/jfr/support/jfrClassDefineEvent.cpp

Changeset: 40755afd
Branch: fibers
Author:    Aleksei Efimov <aefimov at openjdk.org>
Date:      2025-12-23 12:37:34 +0000
URL:       https://git.openjdk.org/loom/commit/40755afdf9061d65dfd039a9707445188bc04303

8373808: Refactor java/net/httpclient qpack and hpack tests to use JUnit

Reviewed-by: djelinski

! test/jdk/java/net/httpclient/http2/HpackBinaryTestDriver.java
! test/jdk/java/net/httpclient/http2/HpackCircularBufferDriver.java
! test/jdk/java/net/httpclient/http2/HpackDecoderDriver.java
! test/jdk/java/net/httpclient/http2/HpackEncoderDriver.java
! test/jdk/java/net/httpclient/http2/HpackHeaderTableDriver.java
! test/jdk/java/net/httpclient/http2/HpackHuffmanDriver.java
! test/jdk/java/net/httpclient/http2/HpackTestHelper.java
! test/jdk/java/net/httpclient/http2/java.net.http/jdk/internal/net/http/hpack/BinaryPrimitivesTest.java
! test/jdk/java/net/httpclient/http2/java.net.http/jdk/internal/net/http/hpack/CircularBufferTest.java
! test/jdk/java/net/httpclient/http2/java.net.http/jdk/internal/net/http/hpack/DecoderTest.java
! test/jdk/java/net/httpclient/http2/java.net.http/jdk/internal/net/http/hpack/EncoderTest.java
! test/jdk/java/net/httpclient/http2/java.net.http/jdk/internal/net/http/hpack/HeaderTableTest.java
! test/jdk/java/net/httpclient/http2/java.net.http/jdk/internal/net/http/hpack/HuffmanTest.java
! test/jdk/java/net/httpclient/http2/java.net.http/jdk/internal/net/http/hpack/SimpleHeaderTableTest.java
! test/jdk/java/net/httpclient/http2/java.net.http/jdk/internal/net/http/hpack/TestHelper.java
! test/jdk/java/net/httpclient/qpack/BlockingDecodingTest.java
! test/jdk/java/net/httpclient/qpack/DecoderSectionSizeLimitTest.java
! test/jdk/java/net/httpclient/qpack/DecoderTest.java
! test/jdk/java/net/httpclient/qpack/DynamicTableFieldLineRepresentationTest.java
! test/jdk/java/net/httpclient/qpack/DynamicTableTest.java
! test/jdk/java/net/httpclient/qpack/EncoderDecoderConnectionTest.java
! test/jdk/java/net/httpclient/qpack/EncoderDecoderConnector.java
! test/jdk/java/net/httpclient/qpack/EncoderDecoderTest.java
! test/jdk/java/net/httpclient/qpack/EncoderTest.java
! test/jdk/java/net/httpclient/qpack/EntriesEvictionTest.java
! test/jdk/java/net/httpclient/qpack/FieldSectionPrefixTest.java
! test/jdk/java/net/httpclient/qpack/IntegerReaderMaxValuesTest.java
! test/jdk/java/net/httpclient/qpack/StaticTableFieldsTest.java
! test/jdk/java/net/httpclient/qpack/StringLengthLimitsTest.java
! test/jdk/java/net/httpclient/qpack/TablesIndexerTest.java
! test/jdk/java/net/httpclient/qpack/UnacknowledgedInsertionTest.java

Changeset: f1c50412
Branch: fibers
Author:    Jie Fu <jiefu at openjdk.org>
Date:      2025-12-23 14:31:29 +0000
URL:       https://git.openjdk.org/loom/commit/f1c50412f0ded30f88720e9489e3ff4dd347ffa3

8374200: jdk/internal/platform/cgroup/TestCgroupMetrics.java fails with common prefix metrics

Reviewed-by: dholmes

! test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV2.java

Changeset: be2ac088
Branch: fibers
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2025-12-23 18:33:56 +0000
URL:       https://git.openjdk.org/loom/commit/be2ac088e86f2be59f26997003cd02bad16672a0

8373967: [macos] User interactions with List do not trigger ItemEvent after programmatic change

Reviewed-by: azvegint

! src/java.desktop/macosx/classes/sun/lwawt/LWListPeer.java
+ test/jdk/java/awt/List/NoEvents/MixProgrammaticUserChange.java

Changeset: 8d80bac1
Branch: fibers
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2025-12-23 19:20:46 +0000
URL:       https://git.openjdk.org/loom/commit/8d80bac1ec2f5eb66619c9e269d7c44612e1d04c

8374296: Comment clean up in os_linux.cpp

Reviewed-by: mdoerr

! src/hotspot/os/linux/os_linux.cpp

Changeset: 61cb6d74
Branch: fibers
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2025-12-23 20:47:55 +0000
URL:       https://git.openjdk.org/loom/commit/61cb6d740807f8ef356d88c0328d05be1a33a8c1

8374232: Comment cleanup in diagnosticCommand.cpp

Reviewed-by: cjplummer

! src/hotspot/share/services/diagnosticCommand.cpp

Changeset: f5249db9
Branch: fibers
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
Date:      2025-12-23 22:21:58 +0000
URL:       https://git.openjdk.org/loom/commit/f5249db9c566f87f7fc4f3ed70114a8168babd8b

8374233: Overloaded constructor MountUnmountDisabler(jthread thread) is missed

Reviewed-by: cjplummer, amenkov

! src/hotspot/share/runtime/mountUnmountDisabler.cpp
! src/hotspot/share/runtime/mountUnmountDisabler.hpp

Changeset: 72e1e157
Branch: fibers
Author:    Damon Nguyen <dnguyen at openjdk.org>
Date:      2025-12-24 00:05:12 +0000
URL:       https://git.openjdk.org/loom/commit/72e1e15779c3d7846f267c0dfd98191b99a55548

8373474: 2 Unintentional format string defect groups in jabswitch.cpp

Reviewed-by: aivanov, prr, azvegint

! src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp

Changeset: a59dbc51
Branch: fibers
Author:    Damon Nguyen <dnguyen at openjdk.org>
Date:      2025-12-24 00:05:27 +0000
URL:       https://git.openjdk.org/loom/commit/a59dbc5105b04234c501aa03474b82481658e5b5

8373475: Unintentional format string in logString of AccessInfo.cpp

Reviewed-by: aivanov, prr, azvegint

! src/jdk.accessibility/windows/native/toolscommon/AccessInfo.cpp

Changeset: 4a0f7e42
Branch: fibers
Author:    Wang Haomin <wanghaomin at openjdk.org>
Committer: Jayathirth D V <jdv at openjdk.org>
Date:      2025-12-24 09:06:39 +0000
URL:       https://git.openjdk.org/loom/commit/4a0f7e4294d2ccc2d2bf460bea87b342fe934d03

8374321: Fix undefined reference to 'png_init_filter_functions_lsx' after 8371914

Reviewed-by: jiefu, jdv

! make/modules/java.desktop/lib/ClientLibraries.gmk

Changeset: f23b958e
Branch: fibers
Author:    Nizar Benalla <nbenalla at openjdk.org>
Date:      2025-12-24 14:31:54 +0000
URL:       https://git.openjdk.org/loom/commit/f23b958eca5c1b9f4e22b897ede6a07ed9224c5f

8373446: Update --release 26 symbol information for JDK 26 build 29

Reviewed-by: iris, liach

+ src/jdk.compiler/share/data/symbols/jdk.management-Q.sym.txt
! src/jdk.compiler/share/data/symbols/symbols

Changeset: 6ade3480
Branch: fibers
Author:    Nizar Benalla <nbenalla at openjdk.org>
Date:      2025-12-24 14:38:08 +0000
URL:       https://git.openjdk.org/loom/commit/6ade34804f175b5dd1bf78515b78e5444d8be7f5

8374177: Update @since of HotSpotAOTCacheMXBean after JDK-8373607

Reviewed-by: alanb, iklam

! src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java

Changeset: 98b7792a
Branch: fibers
Author:    Nizar Benalla <nbenalla at openjdk.org>
Date:      2025-12-24 14:47:04 +0000
URL:       https://git.openjdk.org/loom/commit/98b7792a072380978b09fda4ec194f333d2ce7e3

8372801: tools/sincechecker/modules/java.base/JavaBaseCheckSince.java fails with JDK 27

Reviewed-by: liach

! test/jdk/ProblemList.txt

Changeset: 73a8629c
Branch: fibers
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2025-12-25 01:25:29 +0000
URL:       https://git.openjdk.org/loom/commit/73a8629c5b52b678febcc9d339e01ebcc5277909

8374310: Update copyright year to 2025 for client-libs in files where it was missed

Reviewed-by: jdv, aivanov

! src/java.desktop/aix/classes/sun/awt/X11InputMethod.java
! src/java.desktop/macosx/classes/apple/laf/JRSUIControl.java
! src/java.desktop/macosx/classes/apple/laf/JRSUIFocus.java
! src/java.desktop/macosx/classes/apple/laf/JRSUIState.java
! src/java.desktop/macosx/classes/apple/laf/JRSUIStateFactory.java
! src/java.desktop/macosx/classes/apple/laf/JRSUIUtils.java
! src/java.desktop/macosx/classes/com/apple/eawt/ApplicationBeanInfo.java
! src/java.desktop/macosx/classes/com/apple/eawt/FullScreenAdapter.java
! src/java.desktop/macosx/classes/com/apple/eawt/MacQuitResponse.java
! src/java.desktop/macosx/classes/com/apple/eawt/_AppDockIconHandler.java
! src/java.desktop/macosx/classes/com/apple/eawt/_AppEventHandler.java
! src/java.desktop/macosx/classes/com/apple/eawt/_AppMenuBarHandler.java
! src/java.desktop/macosx/classes/com/apple/eawt/_AppMiscHandlers.java
! src/java.desktop/macosx/classes/com/apple/eawt/event/FullScreenEvent.java
! src/java.desktop/macosx/classes/com/apple/eawt/event/GestureAdapter.java
! src/java.desktop/macosx/classes/com/apple/eawt/event/GestureHandler.java
! src/java.desktop/macosx/classes/com/apple/eawt/event/GesturePhaseEvent.java
! src/java.desktop/macosx/classes/com/apple/eawt/event/MagnificationEvent.java
! src/java.desktop/macosx/classes/com/apple/eawt/event/RotationEvent.java
! src/java.desktop/macosx/classes/com/apple/eawt/event/SwipeEvent.java
! src/java.desktop/macosx/classes/com/apple/eio/FileManager.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaButtonCheckBoxUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaButtonExtendedTypes.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaButtonLabeledUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaButtonRadioUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaButtonToggleUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaCaret.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxButton.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxRenderer.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxRendererInternal.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaEditorPaneUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaFileChooserUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaFileSystemModel.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaFileView.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaFocus.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaFocusHandler.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaFonts.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaGroupBorder.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaHighlighter.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaIcon.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaImageFactory.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaInternalFrameBorder.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaInternalFrameManager.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaInternalFramePaneUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaInternalFrameUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaLabelUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaListUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaLookAndFeel.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaMenuBarBorder.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaMenuBarUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaMenuBorder.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaMenuItemUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaMenuPainter.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaMenuUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaNativeResources.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaOptionPaneUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaPainter.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaPanelUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaPopupMenuSeparatorUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaPopupMenuUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaProgressBarUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaScrollBarUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaScrollPaneUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaScrollRegionBorder.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaSliderUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaSpinnerUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaSplitPaneDividerUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaSplitPaneUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaTabbedPaneContrastUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaTabbedPaneTabState.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaTabbedPaneUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaTableHeaderBorder.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaTableHeaderUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaTableUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaTextAreaUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaTextFieldBorder.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaTextFieldFormattedUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaTextFieldSearch.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaTextPaneUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaTextPasswordFieldUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaToolBarSeparatorUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaToolBarUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaToolTipUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaTreeUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaUtilControlSize.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaUtils.java
! src/java.desktop/macosx/classes/com/apple/laf/ScreenMenuBar.java
! src/java.desktop/macosx/classes/com/apple/laf/ScreenMenuItem.java
! src/java.desktop/macosx/classes/com/apple/laf/ScreenMenuItemCheckbox.java
! src/java.desktop/macosx/classes/com/apple/laf/ScreenMenuPropertyListener.java
! src/java.desktop/macosx/classes/com/apple/laf/ScreenPopupFactory.java
! src/java.desktop/macosx/classes/sun/awt/CGraphicsConfig.java
! src/java.desktop/macosx/classes/sun/awt/CGraphicsEnvironment.java
! src/java.desktop/macosx/classes/sun/awt/PlatformGraphicsInfo.java
! src/java.desktop/macosx/classes/sun/font/CCompositeGlyphMapper.java
! src/java.desktop/macosx/classes/sun/font/CFont.java
! src/java.desktop/macosx/classes/sun/font/CFontConfiguration.java
! src/java.desktop/macosx/classes/sun/font/CFontManager.java
! src/java.desktop/macosx/classes/sun/font/CStrikeDisposer.java
! src/java.desktop/macosx/classes/sun/font/NativeFont.java
! src/java.desktop/macosx/classes/sun/font/NativeStrike.java
! src/java.desktop/macosx/classes/sun/java2d/CRenderer.java
! src/java.desktop/macosx/classes/sun/java2d/CompositeCRenderer.java
! src/java.desktop/macosx/classes/sun/java2d/DataBufferNIOInt.java
! src/java.desktop/macosx/classes/sun/java2d/IntegerNIORaster.java
! src/java.desktop/macosx/classes/sun/java2d/MacOSFlags.java
! src/java.desktop/macosx/classes/sun/java2d/OSXOffScreenSurfaceData.java
! src/java.desktop/macosx/classes/sun/java2d/OSXSurfaceData.java
! src/java.desktop/macosx/classes/sun/java2d/metal/MTLBlitLoops.java
! src/java.desktop/macosx/classes/sun/java2d/metal/MTLBufImgOps.java
! src/java.desktop/macosx/classes/sun/java2d/metal/MTLContext.java
! src/java.desktop/macosx/classes/sun/java2d/metal/MTLDrawImage.java
! src/java.desktop/macosx/classes/sun/java2d/metal/MTLGraphicsConfig.java
! src/java.desktop/macosx/classes/sun/java2d/metal/MTLLayer.java
! src/java.desktop/macosx/classes/sun/java2d/metal/MTLMaskBlit.java
! src/java.desktop/macosx/classes/sun/java2d/metal/MTLMaskFill.java
! src/java.desktop/macosx/classes/sun/java2d/metal/MTLPaints.java
! src/java.desktop/macosx/classes/sun/java2d/metal/MTLRenderQueue.java
! src/java.desktop/macosx/classes/sun/java2d/metal/MTLRenderer.java
! src/java.desktop/macosx/classes/sun/java2d/metal/MTLSurfaceData.java
! src/java.desktop/macosx/classes/sun/java2d/metal/MTLSurfaceDataProxy.java
! src/java.desktop/macosx/classes/sun/java2d/metal/MTLTextRenderer.java
! src/java.desktop/macosx/classes/sun/java2d/metal/MTLVolatileSurfaceManager.java
! src/java.desktop/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java
! src/java.desktop/macosx/classes/sun/java2d/opengl/CGLLayer.java
! src/java.desktop/macosx/classes/sun/java2d/opengl/CGLSurfaceData.java
! src/java.desktop/macosx/classes/sun/java2d/opengl/CGLVolatileSurfaceManager.java
! src/java.desktop/macosx/classes/sun/lwawt/LWKeyboardFocusManagerPeer.java
! src/java.desktop/macosx/classes/sun/lwawt/LWLightweightFramePeer.java
! src/java.desktop/macosx/classes/sun/lwawt/LWMouseInfoPeer.java
! src/java.desktop/macosx/classes/sun/lwawt/LWWindowPeer.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibleText.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CCheckboxMenuItem.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CCustomCursor.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CDataTransferer.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CDragSourceContextPeer.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CDropTargetContextPeer.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CFileDialog.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CImage.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CInputMethod.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CInputMethodDescriptor.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CMouseDragGestureRecognizer.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformLWComponent.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformLWView.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformLWWindow.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterDialogPeer.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CSystemTray.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CToolkitThreadBlockedHandler.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CTrayIcon.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CViewEmbeddedFrame.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CViewPlatformEmbeddedFrame.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/LWCToolkit.java
! src/java.desktop/macosx/classes/sun/print/PlatformPrinterJobProxy.java
! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTEvent.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/CGraphicsDevice.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/CGraphicsEnv.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/DnDUtilities.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TabButtonAccessibility.m
! src/java.desktop/macosx/native/libawt_lwawt/font/CGGlyphImages.m
! src/java.desktop/share/classes/com/sun/imageio/plugins/gif/GIFImageWriter.java
! src/java.desktop/share/classes/com/sun/imageio/plugins/png/PNGImageWriter.java
! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFImageWriter.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKEngine.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifFileChooserUI.java
! src/java.desktop/share/classes/java/awt/Dialog.java
! src/java.desktop/share/classes/java/awt/EventQueue.java
! src/java.desktop/share/classes/java/awt/Font.java
! src/java.desktop/share/classes/java/awt/GraphicsEnvironment.java
! src/java.desktop/share/classes/java/awt/HeadlessException.java
! src/java.desktop/share/classes/java/awt/KeyboardFocusManager.java
! src/java.desktop/share/classes/java/awt/Polygon.java
! src/java.desktop/share/classes/java/awt/PrintJob.java
! src/java.desktop/share/classes/java/awt/SystemTray.java
! src/java.desktop/share/classes/java/awt/doc-files/FocusSpec.html
! src/java.desktop/share/classes/java/awt/doc-files/Modality.html
! src/java.desktop/share/classes/java/awt/image/BandedSampleModel.java
! src/java.desktop/share/classes/java/awt/image/ComponentSampleModel.java
! src/java.desktop/share/classes/java/awt/image/LookupOp.java
! src/java.desktop/share/classes/java/awt/image/MultiPixelPackedSampleModel.java
! src/java.desktop/share/classes/java/awt/image/SampleModel.java
! src/java.desktop/share/classes/java/awt/image/SinglePixelPackedSampleModel.java
! src/java.desktop/share/classes/java/beans/Beans.java
! src/java.desktop/share/classes/java/beans/DesignMode.java
! src/java.desktop/share/classes/javax/imageio/ImageReader.java
! src/java.desktop/share/classes/javax/imageio/ImageWriter.java
! src/java.desktop/share/classes/javax/imageio/metadata/IIOMetadataFormatImpl.java
! src/java.desktop/share/classes/javax/imageio/spi/IIORegistry.java
! src/java.desktop/share/classes/javax/imageio/spi/ServiceRegistry.java
! src/java.desktop/share/classes/javax/imageio/stream/FileCacheImageInputStream.java
! src/java.desktop/share/classes/javax/imageio/stream/FileCacheImageOutputStream.java
! src/java.desktop/share/classes/javax/imageio/stream/ImageInputStreamImpl.java
! src/java.desktop/share/classes/javax/imageio/stream/MemoryCacheImageInputStream.java
! src/java.desktop/share/classes/javax/imageio/stream/package-info.java
! src/java.desktop/share/classes/javax/swing/Action.java
! src/java.desktop/share/classes/javax/swing/BufferStrategyPaintManager.java
! src/java.desktop/share/classes/javax/swing/JComponent.java
! src/java.desktop/share/classes/javax/swing/JEditorPane.java
! src/java.desktop/share/classes/javax/swing/JFileChooser.java
! src/java.desktop/share/classes/javax/swing/JOptionPane.java
! src/java.desktop/share/classes/javax/swing/JRootPane.java
! src/java.desktop/share/classes/javax/swing/JViewport.java
! src/java.desktop/share/classes/javax/swing/RootPaneContainer.java
! src/java.desktop/share/classes/javax/swing/SwingPaintEventDispatcher.java
! src/java.desktop/share/classes/javax/swing/SwingUtilities.java
! src/java.desktop/share/classes/javax/swing/Timer.java
! src/java.desktop/share/classes/javax/swing/ToolTipManager.java
! src/java.desktop/share/classes/javax/swing/UIManager.java
! src/java.desktop/share/classes/javax/swing/package-info.java
! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java
! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthDefaultLookup.java
! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthParser.java
! src/java.desktop/share/classes/javax/swing/plaf/synth/doc-files/synth.dtd
! src/java.desktop/share/classes/javax/swing/plaf/synth/doc-files/synthFileFormat.html
! src/java.desktop/share/classes/javax/swing/text/StringContent.java
! src/java.desktop/share/classes/javax/swing/text/html/parser/Entity.java
! src/java.desktop/share/classes/sun/awt/AppContext.java
! src/java.desktop/share/classes/sun/awt/EmbeddedFrame.java
! src/java.desktop/share/classes/sun/awt/SunToolkit.java
! src/java.desktop/share/classes/sun/awt/image/ByteInterleavedRaster.java
! src/java.desktop/share/classes/sun/awt/image/SunVolatileImage.java
! src/java.desktop/share/classes/sun/awt/image/SurfaceManager.java
! src/java.desktop/share/classes/sun/awt/util/PerformanceLogger.java
! src/java.desktop/share/classes/sun/font/FileFont.java
! src/java.desktop/share/classes/sun/font/FontManager.java
! src/java.desktop/share/classes/sun/font/SunFontManager.java
! src/java.desktop/share/classes/sun/java2d/marlin/DMarlinRenderingEngine.java
! src/java.desktop/share/classes/sun/java2d/opengl/OGLGraphicsConfig.java
! src/java.desktop/share/classes/sun/java2d/pipe/BufferedContext.java
! src/java.desktop/share/classes/sun/print/PathGraphics.java
! src/java.desktop/share/classes/sun/swing/FilePane.java
! src/java.desktop/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java
! src/java.desktop/share/conf/psfontj2d.properties
! src/java.desktop/share/native/libawt/awt/image/imageInitIDs.c
! src/java.desktop/share/native/libawt/awt/image/imageInitIDs.h
! src/java.desktop/share/native/libawt/java2d/SurfaceData.h
! src/java.desktop/share/native/libawt/java2d/loops/Blit.c
! src/java.desktop/share/native/libfontmanager/freetypeScaler.c
! src/java.desktop/unix/classes/sun/awt/FcFontManager.java
! src/java.desktop/unix/classes/sun/awt/X11/GtkFileDialogPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/InfoWindow.java
! src/java.desktop/unix/classes/sun/awt/X11/MotifColorUtilities.java
! src/java.desktop/unix/classes/sun/awt/X11/MotifDnDConstants.java
! src/java.desktop/unix/classes/sun/awt/X11/MotifDnDDragSourceProtocol.java
! src/java.desktop/unix/classes/sun/awt/X11/MotifDnDDropTargetProtocol.java
! src/java.desktop/unix/classes/sun/awt/X11/Native.java
! src/java.desktop/unix/classes/sun/awt/X11/UnsafeXDisposerRecord.java
! src/java.desktop/unix/classes/sun/awt/X11/WindowDimensions.java
! src/java.desktop/unix/classes/sun/awt/X11/WindowPropertyGetter.java
! src/java.desktop/unix/classes/sun/awt/X11/XAWTLookAndFeel.java
! src/java.desktop/unix/classes/sun/awt/X11/XAWTXSettings.java
! src/java.desktop/unix/classes/sun/awt/X11/XAtom.java
! src/java.desktop/unix/classes/sun/awt/X11/XAtomList.java
! src/java.desktop/unix/classes/sun/awt/X11/XAwtState.java
! src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
! src/java.desktop/unix/classes/sun/awt/X11/XBaseWindow.java
! src/java.desktop/unix/classes/sun/awt/X11/XButtonPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XCanvasPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XCheckboxPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XChoicePeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XClipboard.java
! src/java.desktop/unix/classes/sun/awt/X11/XContentWindow.java
! src/java.desktop/unix/classes/sun/awt/X11/XCreateWindowParams.java
! src/java.desktop/unix/classes/sun/awt/X11/XCustomCursor.java
! src/java.desktop/unix/classes/sun/awt/X11/XDataTransferer.java
! src/java.desktop/unix/classes/sun/awt/X11/XDecoratedPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XDesktopPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XDialogPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XDnDConstants.java
! src/java.desktop/unix/classes/sun/awt/X11/XDnDDragSourceProtocol.java
! src/java.desktop/unix/classes/sun/awt/X11/XDnDDropTargetProtocol.java
! src/java.desktop/unix/classes/sun/awt/X11/XDragSourceContextPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XDragSourceProtocol.java
! src/java.desktop/unix/classes/sun/awt/X11/XDropTargetContextPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XEmbedCanvasPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XEmbedChildProxy.java
! src/java.desktop/unix/classes/sun/awt/X11/XEmbedChildProxyPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XEmbedClientHelper.java
! src/java.desktop/unix/classes/sun/awt/X11/XEmbedServerTester.java
! src/java.desktop/unix/classes/sun/awt/X11/XEmbeddedFrame.java
! src/java.desktop/unix/classes/sun/awt/X11/XEmbeddedFramePeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XEmbeddingContainer.java
! src/java.desktop/unix/classes/sun/awt/X11/XErrorHandler.java
! src/java.desktop/unix/classes/sun/awt/X11/XException.java
! src/java.desktop/unix/classes/sun/awt/X11/XFocusProxyWindow.java
! src/java.desktop/unix/classes/sun/awt/X11/XFontPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XGlobalCursorManager.java
! src/java.desktop/unix/classes/sun/awt/X11/XHorizontalScrollbar.java
! src/java.desktop/unix/classes/sun/awt/X11/XIconWindow.java
! src/java.desktop/unix/classes/sun/awt/X11/XInputMethod.java
! src/java.desktop/unix/classes/sun/awt/X11/XInputMethodDescriptor.java
! src/java.desktop/unix/classes/sun/awt/X11/XKeyboardFocusManagerPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XLabelPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XLightweightFramePeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XListPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XMSelection.java
! src/java.desktop/unix/classes/sun/awt/X11/XMenuBarPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XMenuItemPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XMenuPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XMenuWindow.java
! src/java.desktop/unix/classes/sun/awt/X11/XMouseDragGestureRecognizer.java
! src/java.desktop/unix/classes/sun/awt/X11/XNETProtocol.java
! src/java.desktop/unix/classes/sun/awt/X11/XPanelPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XPopupMenuPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XPropertyCache.java
! src/java.desktop/unix/classes/sun/awt/X11/XQueryTree.java
! src/java.desktop/unix/classes/sun/awt/X11/XRepaintArea.java
! src/java.desktop/unix/classes/sun/awt/X11/XRootWindow.java
! src/java.desktop/unix/classes/sun/awt/X11/XScrollPanePeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XScrollbar.java
! src/java.desktop/unix/classes/sun/awt/X11/XScrollbarPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XSelection.java
! src/java.desktop/unix/classes/sun/awt/X11/XSystemTrayPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XTextAreaPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XToolkitThreadBlockedHandler.java
! src/java.desktop/unix/classes/sun/awt/X11/XTranslateCoordinates.java
! src/java.desktop/unix/classes/sun/awt/X11/XTrayIconPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XVerticalScrollbar.java
! src/java.desktop/unix/classes/sun/awt/X11/XWINProtocol.java
! src/java.desktop/unix/classes/sun/awt/X11/XWindow.java
! src/java.desktop/unix/classes/sun/awt/X11/XWindowAttributesData.java
! src/java.desktop/unix/classes/sun/awt/X11/XWrapperBase.java
! src/java.desktop/unix/classes/sun/awt/X11/XlibUtil.java
! src/java.desktop/unix/classes/sun/awt/X11CustomCursor.java
! src/java.desktop/unix/classes/sun/awt/X11FontManager.java
! src/java.desktop/unix/classes/sun/awt/X11GraphicsConfig.java
! src/java.desktop/unix/classes/sun/awt/X11GraphicsEnvironment.java
! src/java.desktop/unix/classes/sun/awt/X11InputMethod.java
! src/java.desktop/unix/classes/sun/awt/X11InputMethodBase.java
! src/java.desktop/unix/classes/sun/awt/X11InputMethodDescriptor.java
! src/java.desktop/unix/classes/sun/awt/XSettings.java
! src/java.desktop/unix/classes/sun/font/DelegateStrike.java
! src/java.desktop/unix/classes/sun/font/DoubleByteEncoder.java
! src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java
! src/java.desktop/unix/classes/sun/font/FontConfigManager.java
! src/java.desktop/unix/classes/sun/font/MFontConfiguration.java
! src/java.desktop/unix/classes/sun/font/NativeFont.java
! src/java.desktop/unix/classes/sun/font/NativeStrike.java
! src/java.desktop/unix/classes/sun/font/NativeStrikeDisposer.java
! src/java.desktop/unix/classes/sun/font/X11Dingbats.java
! src/java.desktop/unix/classes/sun/font/X11GB18030_0.java
! src/java.desktop/unix/classes/sun/font/X11GB18030_1.java
! src/java.desktop/unix/classes/sun/font/X11GB2312.java
! src/java.desktop/unix/classes/sun/font/X11GBK.java
! src/java.desktop/unix/classes/sun/font/X11Johab.java
! src/java.desktop/unix/classes/sun/font/X11KSC5601.java
! src/java.desktop/unix/classes/sun/font/X11SunUnicode_0.java
! src/java.desktop/unix/classes/sun/font/X11TextRenderer.java
! src/java.desktop/unix/classes/sun/font/XMap.java
! src/java.desktop/unix/classes/sun/font/XRGlyphCache.java
! src/java.desktop/unix/classes/sun/font/XRGlyphCacheEntry.java
! src/java.desktop/unix/classes/sun/font/XRTextRenderer.java
! src/java.desktop/unix/classes/sun/java2d/opengl/GLXGraphicsConfig.java
! src/java.desktop/unix/classes/sun/java2d/opengl/GLXSurfaceData.java
! src/java.desktop/unix/classes/sun/java2d/opengl/GLXVolatileSurfaceManager.java
! src/java.desktop/unix/classes/sun/java2d/x11/X11PMBlitBgLoops.java
! src/java.desktop/unix/classes/sun/java2d/x11/X11PMBlitLoops.java
! src/java.desktop/unix/classes/sun/java2d/x11/X11Renderer.java
! src/java.desktop/unix/classes/sun/java2d/x11/X11SurfaceData.java
! src/java.desktop/unix/classes/sun/java2d/x11/X11SurfaceDataProxy.java
! src/java.desktop/unix/classes/sun/java2d/x11/X11VolatileSurfaceManager.java
! src/java.desktop/unix/classes/sun/java2d/xr/DirtyRegion.java
! src/java.desktop/unix/classes/sun/java2d/xr/GrowableByteArray.java
! src/java.desktop/unix/classes/sun/java2d/xr/GrowableEltArray.java
! src/java.desktop/unix/classes/sun/java2d/xr/GrowablePointArray.java
! src/java.desktop/unix/classes/sun/java2d/xr/GrowableRectArray.java
! src/java.desktop/unix/classes/sun/java2d/xr/MaskTile.java
! src/java.desktop/unix/classes/sun/java2d/xr/MaskTileManager.java
! src/java.desktop/unix/classes/sun/java2d/xr/MutableInteger.java
! src/java.desktop/unix/classes/sun/java2d/xr/XIDGenerator.java
! src/java.desktop/unix/classes/sun/java2d/xr/XRBackendNative.java
! src/java.desktop/unix/classes/sun/java2d/xr/XRColor.java
! src/java.desktop/unix/classes/sun/java2d/xr/XRCompositeManager.java
! src/java.desktop/unix/classes/sun/java2d/xr/XRDrawImage.java
! src/java.desktop/unix/classes/sun/java2d/xr/XRDrawLine.java
! src/java.desktop/unix/classes/sun/java2d/xr/XRGraphicsConfig.java
! src/java.desktop/unix/classes/sun/java2d/xr/XRMaskBlit.java
! src/java.desktop/unix/classes/sun/java2d/xr/XRMaskFill.java
! src/java.desktop/unix/classes/sun/java2d/xr/XRMaskImage.java
! src/java.desktop/unix/classes/sun/java2d/xr/XRPMBlitLoops.java
! src/java.desktop/unix/classes/sun/java2d/xr/XRPaints.java
! src/java.desktop/unix/classes/sun/java2d/xr/XRRenderer.java
! src/java.desktop/unix/classes/sun/java2d/xr/XRSolidSrcPict.java
! src/java.desktop/unix/classes/sun/java2d/xr/XRSurfaceData.java
! src/java.desktop/unix/classes/sun/java2d/xr/XRSurfaceDataProxy.java
! src/java.desktop/unix/classes/sun/java2d/xr/XRUtils.java
! src/java.desktop/unix/classes/sun/java2d/xr/XRVolatileSurfaceManager.java
! src/java.desktop/unix/classes/sun/java2d/xr/XcbRequestCounter.java
! src/java.desktop/unix/classes/sun/print/AttributeClass.java
! src/java.desktop/unix/classes/sun/print/CUPSPrinter.java
! src/java.desktop/unix/classes/sun/print/IPPPrintService.java
! src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java
! src/java.desktop/unix/classes/sun/print/UnixPrintService.java
! src/java.desktop/unix/native/common/awt/awt_GraphicsEnv.h
! src/java.desktop/unix/native/common/awt/fontpath.c
! src/java.desktop/unix/native/libawt/awt/awt_LoadLibrary.c
! src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/AnimationController.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/TMSchema.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsBorders.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsButtonUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsCheckBoxUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsClassicLookAndFeel.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsComboBoxUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsDesktopIconUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsDesktopPaneUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsEditorPaneUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsGraphicsUtils.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsInternalFrameUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLabelUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsMenuBarUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsOptionPaneUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsPasswordFieldUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsPopupMenuSeparatorUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsPopupMenuUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsPopupWindow.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsRadioButtonUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsRootPaneUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsScrollBarUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsScrollPaneUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsSeparatorUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsSliderUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsSpinnerUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsSplitPaneDivider.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsSplitPaneUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsTabbedPaneUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsTableHeaderUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsTextAreaUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsTextFieldUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsTextPaneUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsTextUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsToggleButtonUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsToolBarSeparatorUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsToolBarUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsTreeUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/XPStyle.java
! src/java.desktop/windows/classes/sun/awt/PlatformGraphicsInfo.java
! src/java.desktop/windows/classes/sun/awt/Win32ColorModel24.java
! src/java.desktop/windows/classes/sun/awt/Win32FontManager.java
! src/java.desktop/windows/classes/sun/awt/Win32GraphicsConfig.java
! src/java.desktop/windows/classes/sun/awt/Win32GraphicsDevice.java
! src/java.desktop/windows/classes/sun/awt/Win32GraphicsEnvironment.java
! src/java.desktop/windows/classes/sun/awt/windows/TranslucentWindowPainter.java
! src/java.desktop/windows/classes/sun/awt/windows/WComponentPeer.java
! src/java.desktop/windows/classes/sun/awt/windows/WDataTransferer.java
! src/java.desktop/windows/classes/sun/awt/windows/WDefaultFontCharset.java
! src/java.desktop/windows/classes/sun/awt/windows/WDesktopProperties.java
! src/java.desktop/windows/classes/sun/awt/windows/WDragSourceContextPeer.java
! src/java.desktop/windows/classes/sun/awt/windows/WEmbeddedFrame.java
! src/java.desktop/windows/classes/sun/awt/windows/WEmbeddedFramePeer.java
! src/java.desktop/windows/classes/sun/awt/windows/WInputMethod.java
! src/java.desktop/windows/classes/sun/awt/windows/WLabelPeer.java
! src/java.desktop/windows/classes/sun/awt/windows/WLightweightFramePeer.java
! src/java.desktop/windows/classes/sun/awt/windows/WMenuItemPeer.java
! src/java.desktop/windows/classes/sun/awt/windows/WMouseInfoPeer.java
! src/java.desktop/windows/classes/sun/awt/windows/WPopupMenuPeer.java
! src/java.desktop/windows/classes/sun/awt/windows/WScrollPanePeer.java
! src/java.desktop/windows/classes/sun/awt/windows/WScrollbarPeer.java
! src/java.desktop/windows/classes/sun/awt/windows/WTrayIconPeer.java
! src/java.desktop/windows/classes/sun/awt/windows/WWindowPeer.java
! src/java.desktop/windows/classes/sun/awt/windows/WingDings.java
! src/java.desktop/windows/classes/sun/font/NativeFont.java
! src/java.desktop/windows/classes/sun/font/NativeStrike.java
! src/java.desktop/windows/classes/sun/java2d/d3d/D3DBlitLoops.java
! src/java.desktop/windows/classes/sun/java2d/d3d/D3DBufImgOps.java
! src/java.desktop/windows/classes/sun/java2d/d3d/D3DContext.java
! src/java.desktop/windows/classes/sun/java2d/d3d/D3DDrawImage.java
! src/java.desktop/windows/classes/sun/java2d/d3d/D3DGraphicsConfig.java
! src/java.desktop/windows/classes/sun/java2d/d3d/D3DGraphicsDevice.java
! src/java.desktop/windows/classes/sun/java2d/d3d/D3DMaskBlit.java
! src/java.desktop/windows/classes/sun/java2d/d3d/D3DMaskFill.java
! src/java.desktop/windows/classes/sun/java2d/d3d/D3DPaints.java
! src/java.desktop/windows/classes/sun/java2d/d3d/D3DRenderQueue.java
! src/java.desktop/windows/classes/sun/java2d/d3d/D3DRenderer.java
! src/java.desktop/windows/classes/sun/java2d/d3d/D3DScreenUpdateManager.java
! src/java.desktop/windows/classes/sun/java2d/d3d/D3DSurfaceData.java
! src/java.desktop/windows/classes/sun/java2d/d3d/D3DSurfaceDataProxy.java
! src/java.desktop/windows/classes/sun/java2d/d3d/D3DTextRenderer.java
! src/java.desktop/windows/classes/sun/java2d/d3d/D3DVolatileSurfaceManager.java
! src/java.desktop/windows/classes/sun/java2d/opengl/WGLGraphicsConfig.java
! src/java.desktop/windows/classes/sun/java2d/opengl/WGLSurfaceData.java
! src/java.desktop/windows/classes/sun/java2d/opengl/WGLVolatileSurfaceManager.java
! src/java.desktop/windows/classes/sun/java2d/windows/GDIBlitLoops.java
! src/java.desktop/windows/classes/sun/java2d/windows/GDIRenderer.java
! src/java.desktop/windows/classes/sun/java2d/windows/GDIWindowSurfaceData.java
! src/java.desktop/windows/classes/sun/print/PlatformPrinterJobProxy.java
! src/java.desktop/windows/classes/sun/print/PrintServiceLookupProvider.java
! src/java.desktop/windows/classes/sun/print/Win32MediaTray.java
! src/java.desktop/windows/classes/sun/print/Win32PrintJob.java
! src/java.desktop/windows/classes/sun/print/Win32PrintService.java
! src/java.desktop/windows/classes/sun/swing/plaf/windows/ClassicSortArrowIcon.java
! src/java.desktop/windows/native/libawt/windows/awt_Dialog.h
! src/java.desktop/windows/native/libawt/windows/awt_GDIObject.cpp
! src/java.desktop/windows/native/libawt/windows/awt_InputMethod.cpp
! src/java.desktop/windows/native/libawt/windows/awt_Mlib.cpp
! src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp
! src/java.desktop/windows/native/libawt/windows/awt_new.cpp
! test/jdk/java/awt/Choice/ChoiceLocationTest/ChoiceLocationTest.java
! test/jdk/java/awt/Dialog/CloseDialog/CloseDialogTest.java
! test/jdk/java/awt/Focus/ChoiceFocus/ChoiceFocus.java
! test/jdk/java/awt/Frame/GetGraphicsStressTest/GetGraphicsStressTest.java
! test/jdk/java/awt/Frame/ShapeNotSetSometimes/ShapeNotSetSometimes.java
! test/jdk/java/awt/List/FirstItemRemoveTest/FirstItemRemoveTest.java
! test/jdk/java/awt/List/FocusEmptyListTest/FocusEmptyListTest.java
! test/jdk/java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java
! test/jdk/java/awt/Modal/PrintDialogsTest/Test.java
! test/jdk/java/awt/Mouse/GetMousePositionTest/GetMousePositionWithOverlay.java
! test/jdk/java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java
! test/jdk/java/awt/PrintJob/PageSetupDlgBlockingTest/PageSetupDlgBlockingTest.java
! test/jdk/java/awt/TextArea/TextAreaCursorTest/HoveringAndDraggingTest.java
! test/jdk/java/awt/TextArea/TextScrollTest.java
! test/jdk/java/awt/datatransfer/DragUnicodeBetweenJVMTest/DragUnicodeBetweenJVMTest.java
! test/jdk/java/awt/datatransfer/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.java
! test/jdk/java/awt/dnd/DnDFileGroupDescriptor/DnDFileGroupDescriptor.java
! test/jdk/java/awt/dnd/FileListBetweenJVMsTest/FileListBetweenJVMsTest.java
! test/jdk/java/awt/dnd/URIListBetweenJVMsTest/URIListBetweenJVMsTest.java
! test/jdk/java/awt/dnd/URIListToFileListBetweenJVMsTest/URIListToFileListBetweenJVMsTest.java
! test/jdk/java/awt/event/KeyEvent/KeyTyped/EscapeKeyTyped.java
! test/jdk/java/awt/event/MouseEvent/MenuDragMouseEventAbsoluteCoordsTest/MenuDragMouseEventAbsoluteCoordsTest.java
! test/jdk/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_2.java
! test/jdk/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_3.java
! test/jdk/java/awt/event/helpers/lwcomponents/LWButton.java
! test/jdk/java/awt/font/GlyphVector/GetGlyphCharIndexTest.java
! test/jdk/java/awt/grab/EmbeddedFrameTest1/EmbeddedFrameTest1.java
! test/jdk/java/awt/im/8041990/bug8041990.java
! test/jdk/java/awt/im/PinyinIMCapsTest.java
! test/jdk/java/awt/im/PinyinIMCommaTest.java
! test/jdk/java/awt/im/PinyinIMFullstopTest.java
! test/jdk/java/awt/image/AffineTransformOp/AffineTxOpSizeTest.java
! test/jdk/java/awt/image/DrawImage/TiledImage.java
! test/jdk/java/awt/print/Dialog/DialogOrient.java
! test/jdk/java/awt/print/PrinterJob/PageDialogTest.java
! test/jdk/java/awt/print/PrinterJob/PrintDialog.java
! test/jdk/java/awt/print/PrinterJob/PrintDialogCancel.java
! test/jdk/java/awt/print/PrinterJob/ThinLines.java
! test/jdk/java/awt/print/RemotePrinterStatusRefresh/RemotePrinterStatusRefresh.java
! test/jdk/java/awt/regtesthelpers/AbstractTest.java
! test/jdk/java/awt/regtesthelpers/Util.java
! test/jdk/java/awt/regtesthelpers/process/ProcessCommunicator.java
! test/jdk/javax/sound/midi/MidiDeviceConnectors/TestAllDevices.java
! test/jdk/javax/sound/midi/Sequencer/Looping.java
! test/jdk/javax/sound/midi/SysexMessage/SendRawSysexMessage.java
! test/jdk/javax/sound/midi/spi/MidiDeviceProvider/ExpectedNPEOnNull.java
! test/jdk/javax/sound/midi/spi/MidiDeviceProvider/FakeInfo.java
! test/jdk/javax/sound/midi/spi/MidiDeviceProvider/UnsupportedInfo.java
! test/jdk/javax/sound/sampled/Clip/ClipFlushCrash.java
! test/jdk/javax/sound/sampled/Clip/IsRunningHang.java
! test/jdk/javax/sound/sampled/Clip/OpenNonIntegralNumberOfSampleframes.java
! test/jdk/javax/sound/sampled/DataLine/LongFramePosition.java
! test/jdk/javax/sound/sampled/DirectAudio/bug6372428.java
! test/jdk/javax/sound/sampled/LinuxBlock/PlaySine.java
! test/jdk/javax/swing/JOptionPane/bug4174551.java
! test/jdk/javax/swing/JTextArea/4697612/bug4697612.java
! test/jdk/javax/swing/text/html/parser/Parser/6990651/bug6990651.java
! test/jdk/javax/swing/text/html/parser/Parser/8078268/bug8078268.java
! test/jdk/sun/java2d/marlin/ClipShapeTest.java
! test/jdk/sun/java2d/marlin/CrashNaNTest.java
! test/jdk/sun/java2d/marlin/CrashPaintTest.java
! test/jdk/sun/java2d/marlin/TextClipErrorTest.java

Changeset: 534c33d0
Branch: fibers
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2025-12-25 07:25:40 +0000
URL:       https://git.openjdk.org/loom/commit/534c33d0ef7daa0d0d5b56a1101b4c9d47a48049

8374323: Update copyright year to 2025 for the build system in files where it was missed

Reviewed-by: erikj

! .github/actions/build-jtreg/action.yml
! .github/actions/get-bundles/action.yml
! .github/actions/get-gtest/action.yml
! .github/actions/get-jtreg/action.yml
! .github/actions/get-msys2/action.yml
! .github/actions/upload-bundles/action.yml
! .github/workflows/build-alpine-linux.yml
! .github/workflows/build-cross-compile.yml
! .github/workflows/build-linux.yml
! .github/workflows/build-macos.yml
! .github/workflows/build-windows.yml
! .github/workflows/main.yml
! .github/workflows/test.yml
! make/RunTestsPrebuiltSpec.gmk
! make/autoconf/bootcycle-spec.gmk.template
! make/autoconf/buildjdk-spec.gmk.template
! make/autoconf/compare.sh.template
! make/autoconf/hotspot.m4
! make/autoconf/lib-bundled.m4
! make/autoconf/platform.m4
! make/devkit/createWindowsDevkit.sh
! make/jdk/src/classes/build/tools/pandocfilter/PandocFilter.java
! make/jdk/src/classes/build/tools/taglet/JSpec.java
! make/jdk/src/classes/build/tools/taglet/ToolGuide.java
! make/langtools/tools/propertiesparser/parser/Message.java
! make/scripts/compare-logger.sh
! make/scripts/compare.sh

Changeset: 3e6170c5
Branch: fibers
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2025-12-26 03:46:40 +0000
URL:       https://git.openjdk.org/loom/commit/3e6170c5be95f92a209c58928be487e8a9f97287

8374354: Update copyright year to 2025 for jdk.javadoc in files where it was missed

Reviewed-by: liach

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractTreeWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllClassesIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlLinkFactory.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/NestedClassWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SerializedFormWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Table.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyles.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/taglets/LinkTaglet.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/CommentUtils.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/WorkArounds.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocFile.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/Content.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/ContentBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/Entity.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/RawHtml.java

Changeset: e65ace10
Branch: fibers
Author:    Daniel Gredler <dgredler at openjdk.org>
Date:      2025-12-26 11:58:48 +0000
URL:       https://git.openjdk.org/loom/commit/e65ace10e3c40d6fef4e9997311d88c900e84ced

6517125: FontStrike.getGlyphVectorOutline() not used

Reviewed-by: prr, serb

! src/java.desktop/macosx/classes/sun/font/CStrike.java
! src/java.desktop/macosx/classes/sun/font/NativeStrike.java
! src/java.desktop/share/classes/sun/font/CompositeStrike.java
! src/java.desktop/share/classes/sun/font/FileFontStrike.java
! src/java.desktop/share/classes/sun/font/FontStrike.java
! src/java.desktop/unix/classes/sun/font/DelegateStrike.java
! src/java.desktop/unix/classes/sun/font/NativeStrike.java
! src/java.desktop/windows/classes/sun/font/NativeStrike.java

Changeset: ac07a41d
Branch: fibers
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2025-12-26 19:12:55 +0000
URL:       https://git.openjdk.org/loom/commit/ac07a41de9877aec3e9d5e7a23b0583038a7956d

8374360: Update copyright year to 2025 for test/jdk/jdk/jfr in files where it was missed

Reviewed-by: egahlin

! test/jdk/jdk/jfr/api/consumer/TestRecordedClass.java
! test/jdk/jdk/jfr/api/consumer/TestRecordedFrameType.java
! test/jdk/jdk/jfr/api/consumer/TestRecordingFileSanitization.java
! test/jdk/jdk/jfr/api/consumer/TestRecordingFileWrite.java
! test/jdk/jdk/jfr/api/consumer/log/TestContent.java
! test/jdk/jdk/jfr/api/consumer/log/TestDiskOnOff.java
! test/jdk/jdk/jfr/api/consumer/log/TestDynamicStart.java
! test/jdk/jdk/jfr/api/consumer/log/TestMemoryDiskTransition.java
! test/jdk/jdk/jfr/api/consumer/log/TestMemoryOnly.java
! test/jdk/jdk/jfr/api/consumer/log/TestSystemEvents.java
! test/jdk/jdk/jfr/api/consumer/log/TestTruncation.java
! test/jdk/jdk/jfr/api/consumer/log/TestUserEvents.java
! test/jdk/jdk/jfr/api/consumer/log/TestVerbosity.java
! test/jdk/jdk/jfr/api/consumer/log/TestWithStreaming.java
! test/jdk/jdk/jfr/api/consumer/recordingstream/TestDump.java
! test/jdk/jdk/jfr/api/consumer/recordingstream/TestRecordingName.java
! test/jdk/jdk/jfr/api/consumer/streaming/TestBaseRepositoryAfterStart.java
! test/jdk/jdk/jfr/api/consumer/streaming/TestBaseRepositoryBeforeStart.java
! test/jdk/jdk/jfr/api/consumer/streaming/TestBaseRepositoryLastModified.java
! test/jdk/jdk/jfr/api/consumer/streaming/TestBaseRepositoryMultipleProcesses.java
! test/jdk/jdk/jfr/api/recording/dump/TestDumpDevNull.java
! test/jdk/jdk/jfr/event/allocation/TestObjectAllocationSampleEvent.java
! test/jdk/jdk/jfr/event/compiler/TestCompilerQueueUtilization.java
! test/jdk/jdk/jfr/event/gc/detailed/TestG1InvalidHeapRegionTypeChangeEvent.java
! test/jdk/jdk/jfr/event/gc/detailed/TestGCCPUTimeEvent.java
! test/jdk/jdk/jfr/event/gc/detailed/TestGCHeapMemoryPoolUsageEvent.java
! test/jdk/jdk/jfr/event/gc/heapsummary/HeapSummaryEventAllGcs.java
! test/jdk/jdk/jfr/event/io/TestAsynchronousFileChannelEvents.java
! test/jdk/jdk/jfr/event/io/TestSocketAdapterEvents.java
! test/jdk/jdk/jfr/event/runtime/TestDeprecatedEvent.java
! test/jdk/jdk/jfr/event/runtime/TestDirectBufferStatisticsEvent.java
! test/jdk/jdk/jfr/event/runtime/TestFinalizerStatisticsEvent.java
! test/jdk/jdk/jfr/event/runtime/TestNativeLibraryLoadEvent.java
! test/jdk/jdk/jfr/event/security/TestInitialSecurityPropertyEvent.java
! test/jdk/jdk/jfr/event/security/TestSecurityProviderServiceEvent.java
! test/jdk/jdk/jfr/jcmd/TestJcmdConfigureReadOnly.java
! test/jdk/jdk/jfr/jcmd/TestJcmdOptionSpecifiedOnce.java
! test/jdk/jdk/jfr/jcmd/TestJcmdStartGeneratedFilename.java
! test/jdk/jdk/jfr/jcmd/TestJcmdViewMissingData.java
! test/jdk/jdk/jfr/jmx/streaming/TestClose.java
! test/jdk/jdk/jfr/jmx/streaming/TestDelegated.java
! test/jdk/jdk/jfr/jmx/streaming/TestDumpOrder.java
! test/jdk/jdk/jfr/jmx/streaming/TestMetadataEvent.java
! test/jdk/jdk/jfr/jmx/streaming/TestMultipleChunks.java
! test/jdk/jdk/jfr/jmx/streaming/TestNew.java
! test/jdk/jdk/jfr/jmx/streaming/TestRotate.java
! test/jdk/jdk/jfr/jmx/streaming/TestSetSettings.java
! test/jdk/jdk/jfr/jmx/streaming/TestStart.java
! test/jdk/jdk/jfr/jmx/streaming/TestStop.java
! test/jdk/jdk/jfr/jvm/TestChunkIntegrity.java
! test/jdk/jdk/jfr/jvm/TestFatEvent.java
! test/jdk/jdk/jfr/jvm/TestHiddenWait.java
! test/jdk/jdk/jfr/jvm/TestLongStringsInPool.java
! test/jdk/jdk/jfr/jvm/TestVerifyInstrumentation.java
! test/jdk/jdk/jfr/startupargs/TestPreserveRepository.java
! test/jdk/jdk/jfr/startupargs/TestStartHelp.java
! test/jdk/jdk/jfr/startupargs/TestStartupOptionSpecifiedOnce.java
! test/jdk/jdk/jfr/threading/TestStringPoolVirtualThreadPinning.java
! test/jdk/jdk/jfr/tool/TestConfigure.java
! test/jdk/jdk/jfr/tool/TestView.java

Changeset: e7f9132e
Branch: fibers
Author:    Alexey Ivanov <aivanov at openjdk.org>
Date:      2025-12-26 20:12:15 +0000
URL:       https://git.openjdk.org/loom/commit/e7f9132e8992ac281d1e4777a9664d1c8b817f4f

8374345: Restore the original copyright year in ExtremeFontSizeTest.java

Reviewed-by: serb, syan

! test/jdk/java/awt/FontMetrics/ExtremeFontSizeTest.java

Changeset: 5c694eab
Branch: fibers
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2025-12-27 04:45:56 +0000
URL:       https://git.openjdk.org/loom/commit/5c694eab0f48045d2f71d0cd5ab53c1daddaa963

8374363: Update copyright year to 2025 for test/micro in files where it was missed

Reviewed-by: phh

! test/micro/org/openjdk/bench/java/lang/foreign/AllocFromSliceTest.java
! test/micro/org/openjdk/bench/java/util/ImmutableColls.java
! test/micro/org/openjdk/bench/vm/compiler/MergeStoreBench.java
! test/micro/org/openjdk/bench/vm/gc/systemgc/AllDead.java
! test/micro/org/openjdk/bench/vm/gc/systemgc/AllLive.java
! test/micro/org/openjdk/bench/vm/gc/systemgc/DifferentObjectSizesArray.java
! test/micro/org/openjdk/bench/vm/gc/systemgc/DifferentObjectSizesHashMap.java
! test/micro/org/openjdk/bench/vm/gc/systemgc/DifferentObjectSizesTreeMap.java
! test/micro/org/openjdk/bench/vm/gc/systemgc/HalfDeadFirstPart.java
! test/micro/org/openjdk/bench/vm/gc/systemgc/HalfDeadInterleaved.java
! test/micro/org/openjdk/bench/vm/gc/systemgc/HalfDeadInterleavedChunks.java
! test/micro/org/openjdk/bench/vm/gc/systemgc/HalfDeadSecondPart.java
! test/micro/org/openjdk/bench/vm/gc/systemgc/HalfHashedHalfDead.java
! test/micro/org/openjdk/bench/vm/gc/systemgc/NoObjects.java
! test/micro/org/openjdk/bench/vm/gc/systemgc/OneBigObject.java

Changeset: 2886c3b6
Branch: fibers
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2025-12-27 04:56:04 +0000
URL:       https://git.openjdk.org/loom/commit/2886c3b68a8d4b098f7d093f0406d2a15e5910dc

8374358: Update copyright year to 2025 for test/hotspot in files where it was missed

Reviewed-by: phh

! test/hotspot/jtreg/TEST.quick-groups
! test/hotspot/jtreg/applications/jcstress/TestGenerator.java
! test/hotspot/jtreg/compiler/c2/Test7005594.java
! test/hotspot/jtreg/compiler/c2/TestReduceAllocationAndLoadKlass.java
! test/hotspot/jtreg/compiler/c2/TestReduceAllocationAndNonExactAllocate.java
! test/hotspot/jtreg/compiler/c2/TestReduceAllocationAndNullableLoads.java
! test/hotspot/jtreg/compiler/c2/irTests/TestPhiDuplicatedConversion.java
! test/hotspot/jtreg/compiler/cpuflags/TestAESIntrinsicsOnSupportedConfig.java
! test/hotspot/jtreg/compiler/cpuflags/TestAESIntrinsicsOnUnsupportedConfig.java
! test/hotspot/jtreg/compiler/escapeAnalysis/TestReduceAllocationAndNonReduciblePhi.java
! test/hotspot/jtreg/compiler/intrinsics/bmi/BMITestRunner.java
! test/hotspot/jtreg/compiler/intrinsics/math/TestMinMaxIntrinsics.java
! test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseMD5IntrinsicsOptionOnSupportedCPU.java
! test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseMD5IntrinsicsOptionOnUnsupportedCPU.java
! test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnSupportedCPU.java
! test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnUnsupportedCPU.java
! test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnUnsupportedCPU.java
! test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseSHA512IntrinsicsOptionOnUnsupportedCPU.java
! test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseSHAOptionOnSupportedCPU.java
! test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseSHAOptionOnUnsupportedCPU.java
! test/hotspot/jtreg/compiler/intrinsics/sha/cli/testcases/GenericTestCaseForUnsupportedCPU.java
! test/hotspot/jtreg/compiler/jvmci/TestUncaughtErrorInCompileMethod.java
! test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventListener.java
! test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java
! test/hotspot/jtreg/compiler/lib/compile_framework/CompileFramework.java
! test/hotspot/jtreg/compiler/lib/ir_framework/driver/irmatching/parser/VMInfo.java
! test/hotspot/jtreg/compiler/lib/ir_framework/shared/TestFrameworkSocket.java
! test/hotspot/jtreg/compiler/loopopts/TestMissingSkeletonPredicateForIfNode.java
! test/hotspot/jtreg/compiler/loopopts/superword/TestGeneralizedReductions.java
! test/hotspot/jtreg/compiler/profiling/TestTypeProfiling.java
! test/hotspot/jtreg/compiler/vectorapi/reshape/TestVectorReinterpret.java
! test/hotspot/jtreg/compiler/vectorization/TestBufferVectorization.java
! test/hotspot/jtreg/compiler/vectorization/TestOptionVectorizeIR.java
! test/hotspot/jtreg/compiler/vectorization/TestRoundVectFloat.java
! test/hotspot/jtreg/compiler/vectorization/TestRoundVectRiscv64.java
! test/hotspot/jtreg/compiler/vectorization/runner/ArrayShiftOpTest.java
! test/hotspot/jtreg/compiler/vectorization/runner/BasicBooleanOpTest.java
! test/hotspot/jtreg/compiler/vectorization/runner/BasicByteOpTest.java
! test/hotspot/jtreg/compiler/vectorization/runner/BasicDoubleOpTest.java
! test/hotspot/jtreg/compiler/vectorization/runner/BasicIntOpTest.java
! test/hotspot/jtreg/compiler/vectorization/runner/BasicLongOpTest.java
! test/hotspot/jtreg/compiler/vectorization/runner/LoopLiveOutNodesTest.java
! test/hotspot/jtreg/compiler/vectorization/runner/LoopRangeStrideTest.java
! test/hotspot/jtreg/compiler/vectorization/runner/MultipleLoopsTest.java
! test/hotspot/jtreg/gc/arguments/TestMinInitialErgonomics.java
! test/hotspot/jtreg/gc/arguments/TestParallelGCErgo.java
! test/hotspot/jtreg/gc/g1/TestHumongousConcurrentStartUndo.java
! test/hotspot/jtreg/gc/g1/TestMixedGCLiveThreshold.java
! test/hotspot/jtreg/gc/g1/TestShrinkAuxiliaryDataRunner.java
! test/hotspot/jtreg/gc/g1/plab/TestPLABEvacuationFailure.java
! test/hotspot/jtreg/gc/g1/plab/lib/PLABUtils.java
! test/hotspot/jtreg/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java
! test/hotspot/jtreg/gc/stress/TestStressG1Uncommit.java
! test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherWithG1.java
! test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherWithParallel.java
! test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherWithSerial.java
! test/hotspot/jtreg/runtime/CDSCompressedKPtrs/XShareAuto.java
! test/hotspot/jtreg/runtime/CommandLine/OptionsValidation/TestJcmdOutput.java
! test/hotspot/jtreg/runtime/ErrorHandling/ShowRegistersOnAssertTest.java
! test/hotspot/jtreg/runtime/ErrorHandling/StackWalkNativeToJava.java
! test/hotspot/jtreg/runtime/Monitor/MonitorWithDeadObjectTest.java
! test/hotspot/jtreg/runtime/NMT/JcmdWithNMTDisabled.java
! test/hotspot/jtreg/runtime/StackGap/TestStackGap.java
! test/hotspot/jtreg/runtime/StackGuardPages/TestStackGuardPages.java
! test/hotspot/jtreg/runtime/TLS/TestTLS.java
! test/hotspot/jtreg/runtime/Thread/TooSmallStackSize.java
! test/hotspot/jtreg/runtime/cds/appcds/LambdaWithUseImplMethodHandle.java
! test/hotspot/jtreg/runtime/cds/appcds/LotsOfJRTClasses.java
! test/hotspot/jtreg/runtime/cds/appcds/SignedJar.java
! test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFileSafety.java
! test/hotspot/jtreg/runtime/cds/appcds/test-classes/BadLookupSwitch.jcod
! test/hotspot/jtreg/runtime/jni/atExit/libatExit.c
! test/hotspot/jtreg/runtime/jni/checked/TestLargeUTF8Length.java
! test/hotspot/jtreg/runtime/jni/daemonDestroy/TestDaemonDestroy.java
! test/hotspot/jtreg/runtime/jni/getCreatedJavaVMs/TestGetCreatedJavaVMs.java
! test/hotspot/jtreg/runtime/verifier/TraceClassRes.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbAttach.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbAttachDifferentJVMs.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbClasses.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbDumpclass.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbField.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbFlags.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbHistory.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbInspect.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbJdis.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbJstack.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbPrintAs.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbPstack.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbScanOops.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbSource.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbSymbol.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbTestAllocationMerge.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbThread.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbVmStructsDump.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbWhere.java
! test/hotspot/jtreg/serviceability/sa/DeadlockDetectionTest.java
! test/hotspot/jtreg/serviceability/sa/TestClassDump.java
! test/hotspot/jtreg/serviceability/sa/TestClhsdbJstackLock.java
! test/hotspot/jtreg/serviceability/sa/TestCpoolForInvokeDynamic.java
! test/hotspot/jtreg/serviceability/sa/TestDebugInfoDecode.java
! test/hotspot/jtreg/serviceability/sa/TestDefaultMethods.java
! test/hotspot/jtreg/serviceability/sa/TestG1HeapRegion.java
! test/hotspot/jtreg/serviceability/sa/TestHeapDumpForInvokeDynamic.java
! test/hotspot/jtreg/serviceability/sa/TestInstanceKlassSize.java
! test/hotspot/jtreg/serviceability/sa/TestInstanceKlassSizeForInterface.java
! test/hotspot/jtreg/serviceability/sa/TestIntConstant.java
! test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixed.java
! test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackPrintVMLocks.java
! test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackUpcall.java
! test/hotspot/jtreg/serviceability/sa/TestJmapCore.java
! test/hotspot/jtreg/serviceability/sa/TestJmapCoreMetaspace.java
! test/hotspot/jtreg/serviceability/sa/TestObjectMonitorIterate.java
! test/hotspot/jtreg/serviceability/sa/TestPrintMdo.java
! test/hotspot/jtreg/serviceability/sa/TestSysProps.java
! test/hotspot/jtreg/serviceability/sa/TestType.java
! test/hotspot/jtreg/serviceability/sa/UniqueVtableTest.java
! test/hotspot/jtreg/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java
! test/hotspot/jtreg/serviceability/sa/sadebugd/ClhsdbAttachToDebugServer.java
! test/hotspot/jtreg/serviceability/sa/sadebugd/ClhsdbTestConnectArgument.java
! test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdConnectTest.java
! test/hotspot/jtreg/serviceability/sa/sadebugd/DisableRegistryTest.java
! test/hotspot/jtreg/testlibrary/ctw/Makefile
! test/hotspot/jtreg/testlibrary/ctw/src/sun/hotspot/tools/ctw/Compiler.java
! test/hotspot/jtreg/testlibrary/ctw/src/sun/hotspot/tools/ctw/PathHandler.java
! test/hotspot/jtreg/testlibrary/jittester/src/jdk/test/lib/jittester/visitors/ByteCodeVisitor.java
! test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestBadFormat.java
! test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/flag/TestCompilePhaseCollector.java
! test/hotspot/jtreg/testlibrary_tests/verify/tests/TestVerify.java
! test/hotspot/jtreg/vmTestbase/gc/vector/LinearListLow/TestDescription.java
! test/hotspot/jtreg/vmTestbase/jit/removal_candidates.txt
! test/hotspot/jtreg/vmTestbase/metaspace/shrink_grow/ShrinkGrowTest/ShrinkGrowTest.java
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach010/attach010Agent00.java
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC05/tc05t001/tc05t001.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t006/ma10t006.cpp
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/MemoryPoolMBean/isUsageThresholdExceeded/isexceeded001.java
! test/hotspot/jtreg/vmTestbase/nsk/share/gc/GC.java
! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/TestDebuggerType1.java
! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/hotswap/HotSwap.cpp
! test/hotspot/jtreg/vmTestbase/nsk/share/runner/ThreadsRunner.java
! test/hotspot/jtreg/vmTestbase/nsk/share/test/Stresser.java
! test/hotspot/jtreg/vmTestbase/nsk/stress/jni/libjnistress007.cpp
! test/hotspot/jtreg/vmTestbase/vm/jit/LongTransitions/JniArmHFTestGenerator.java.txt

Changeset: 9512a43e
Branch: fibers
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2025-12-27 07:02:41 +0000
URL:       https://git.openjdk.org/loom/commit/9512a43e82652be7294338c11cc9ffb0f0324b92

8374365: Update copyright year to 2025 for test/jdk in files where it was missed

Reviewed-by: phh

! test/jdk/com/sun/net/httpserver/simpleserver/CustomFileSystemTest.java
! test/jdk/java/beans/Introspector/4520754/Test4520754.java
! test/jdk/java/beans/Performance/TestIntrospector.java
! test/jdk/java/beans/PropertyChangeSupport/Test4682386.java
! test/jdk/java/foreign/TestMemoryAlignment.java
! test/jdk/java/foreign/TestUpcallStructScope.java
! test/jdk/java/foreign/libTest4BAlignedDouble.c
! test/jdk/java/foreign/libTestUpcallStructScope.c
! test/jdk/java/io/File/libGetXSpace.c
! test/jdk/java/io/pathNames/win32/DriveOnly.java
! test/jdk/java/lang/Class/getEnclosingClass/EnclosingClass.java
! test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java
! test/jdk/java/lang/Class/getEnclosingClass/common/TestMe.java
! test/jdk/java/lang/ProcessBuilder/FDLeakTest/exeFDLeakTester.c
! test/jdk/java/lang/ScopedValue/ManyBindings.java
! test/jdk/java/lang/ScopedValue/ScopedValueAPI.java
! test/jdk/java/lang/System/PropertyTest.java
! test/jdk/java/lang/System/i18nEnvArg.java
! test/jdk/java/lang/module/ClassFileVersionsTest.java
! test/jdk/java/lang/module/ModuleDescriptorTest.java
! test/jdk/java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java
! test/jdk/java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java
! test/jdk/java/net/URL/OpenStream.java
! test/jdk/java/net/httpclient/altsvc/altsvc-dns-hosts.txt
! test/jdk/java/nio/channels/FileChannel/directio/DirectIOTest.java
! test/jdk/java/nio/channels/FileChannel/directio/libDirectIO.c
! test/jdk/java/nio/file/Path/UriImportExport.java
! test/jdk/java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java
! test/jdk/java/nio/file/spi/CustomSystemClassLoader.java
! test/jdk/java/nio/file/spi/SetDefaultProvider.java
! test/jdk/java/security/KeyFactory/KeyFactoryGetKeySpecForInvalidSpec.java
! test/jdk/java/time/tck/java/time/TCKInstant.java
! test/jdk/java/util/Collections/T5078378.java
! test/jdk/java/util/List/ListFactories.java
! test/jdk/java/util/Locale/LocaleProvidersFormat.java
! test/jdk/java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java
! test/jdk/java/util/concurrent/Executors/AutoShutdown.java
! test/jdk/java/util/concurrent/forkjoin/Starvation.java
! test/jdk/java/util/concurrent/locks/StampedLock/OOMEInStampedLock.java
! test/jdk/java/util/regex/TestCases.txt
! test/jdk/java/util/stream/GathererTest.java
! test/jdk/java/util/zip/CloseInflaterDeflaterTest.java
! test/jdk/java/util/zip/DeflaterClose.java
! test/jdk/java/util/zip/InflaterClose.java
! test/jdk/java/util/zip/TotalInOut.java
! test/jdk/javax/management/security/HashedPasswordFileTest.java
! test/jdk/javax/net/ssl/SSLSocket/Tls13PacketSize.java
! test/jdk/javax/net/ssl/Stapling/StapleEnableProps.java
! test/jdk/jdk/incubator/vector/gen-template.sh
! test/jdk/jdk/incubator/vector/templates/Unit-header.template
! test/jdk/jdk/internal/platform/docker/TestSystemMetrics.java
! test/jdk/jdk/internal/platform/docker/TestUseContainerSupport.java
! test/jdk/jdk/modules/etc/DefaultModules.java
! test/jdk/jni/nullCaller/NullCallerTest.java
! test/jdk/performance/client/SwingMark/src/AbstractSwingTest.java
! test/jdk/performance/client/SwingMark/src/JMTest_01.java
! test/jdk/performance/client/SwingMark/src/JMTest_02.java
! test/jdk/performance/client/SwingMark/src/JMTest_03.java
! test/jdk/performance/client/SwingMark/src/JMTest_04.java
! test/jdk/performance/client/SwingMark/src/JMTest_05.java
! test/jdk/performance/client/SwingMark/src/MenuTest.java
! test/jdk/performance/client/SwingMark/src/TypingTest.java
! test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/button/resources/ButtonDemo.html
! test/jdk/sun/awt/font/TestArabicHebrew.java
! test/jdk/sun/security/provider/FileInputStreamPool/FileInputStreamPoolTest.java
! test/jdk/tools/jimage/ImageReaderDuplicateChildNodesTest.java
! test/jdk/tools/jlink/SnippetsTest.java
! test/jdk/tools/jpackage/helpers-test/jdk/jpackage/test/JavaAppDescTest.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/Annotations.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/AppImageFile.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/LauncherAsServiceVerifier.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/RunnablePackageTest.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/DefaultBundlingEnvironmentTest.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/OverridableResourceTest.java
! test/jdk/tools/jpackage/windows/WinRenameTest.java
! test/jdk/tools/launcher/JniInvocationTest.java

Changeset: 5e685f6f
Branch: fibers
Author:    Anjian Wen <wenanjian at openjdk.org>
Date:      2025-12-28 09:13:09 +0000
URL:       https://git.openjdk.org/loom/commit/5e685f6f2c7872a4239ef0c0a0afa60f4526529e

8374351: RISC-V: Small refactoring for crypto macro-assembler routines

Reviewed-by: fyang, fjiang

! src/hotspot/cpu/riscv/stubGenerator_riscv.cpp

Changeset: 078e71f4
Branch: fibers
Author:    Kirill Shirokov <kirshiro at amazon.com>
Committer: Xiaolong Peng <xpeng at openjdk.org>
Date:      2025-12-29 21:09:41 +0000
URL:       https://git.openjdk.org/loom/commit/078e71f4a3d68d298ab3c383e46d18912e1de7db

8344345: test/hotspot/gtest/x86/x86-asmtest.py has trailing whitespaces

Reviewed-by: phh, lmesnik

! test/hotspot/gtest/x86/x86-asmtest.py

Changeset: 92c6799b
Branch: fibers
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2025-12-29 21:20:59 +0000
URL:       https://git.openjdk.org/loom/commit/92c6799b401eb786949e88cd7142002b2a875ce0

8374361: Update copyright year to 2025 for jdk.hotspot.agent in files where it was missed

Reviewed-by: phh

! src/jdk.hotspot.agent/linux/native/libsaproc/LinuxDebuggerLocal.cpp
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/HSDB.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/HotSpotAgent.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/Debugger.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/BsdThreadContextFactory.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/LinuxThreadContextFactory.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerClient.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebugger.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebuggerLocal.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/StackValueCollection.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64CurrentFrameGuess.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64RegisterMap.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/bsd_amd64/BsdAMD64JavaThreadPDAccess.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/linux_amd64/LinuxAMD64JavaThreadPDAccess.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/win32_amd64/Win32AMD64JavaThreadPDAccess.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/AnnotatedMemoryPanel.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java
! src/jdk.hotspot.agent/windows/native/libsaproc/sawindbg.cpp

Changeset: 08450f2c
Branch: fibers
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2025-12-30 07:01:49 +0000
URL:       https://git.openjdk.org/loom/commit/08450f2c4d447c42a2ca8222d162ae3d2d25268a

8374326: Update copyright year to 2025 for jdk.jpackage in files where it was missed

Reviewed-by: phh

! src/jdk.jpackage/linux/native/libapplauncher/LinuxLauncherLib.cpp
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacPkgInstallerScripts.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/ResourceLocator.java
! src/jdk.jpackage/share/native/applauncher/PackageFile.cpp
! src/jdk.jpackage/share/native/common/Dll.h
! src/jdk.jpackage/share/native/common/app.cpp
! src/jdk.jpackage/share/native/common/tstrings.cpp
! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixLauncherAsService.java
! src/jdk.jpackage/windows/native/common/MsiUtils.h
! src/jdk.jpackage/windows/native/libjpackage/VersionInfo.cpp
! src/jdk.jpackage/windows/native/libmsica/Version.cpp
! src/jdk.jpackage/windows/native/libmsica/Version.h
! src/jdk.jpackage/windows/native/libmsica/libmsica.cpp

Changeset: e4e923a1
Branch: fibers
Author:    Martin Doerr <mdoerr at openjdk.org>
Date:      2025-12-30 09:49:05 +0000
URL:       https://git.openjdk.org/loom/commit/e4e923a1ffc8ff059c983c7e9201d0ee3273482d

8374195: TestReplaceNarrowPhiWithBottomPhi fails on ppc64 platforms in (fast)debug

Reviewed-by: mbaesken, jbechberger

! test/hotspot/jtreg/compiler/c2/TestReplaceNarrowPhiWithBottomPhi.java

Changeset: a6462d64
Branch: fibers
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2025-12-30 12:08:36 +0000
URL:       https://git.openjdk.org/loom/commit/a6462d641cba004829f9136df22f3d953c0e0c5d

8374316: Update copyright year to 2025 for hotspot in files where it was missed

Reviewed-by: kbarrett

! src/hotspot/cpu/aarch64/assembler_aarch64.inline.hpp
! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.hpp
! src/hotspot/cpu/aarch64/continuationHelper_aarch64.inline.hpp
! src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.hpp
! src/hotspot/cpu/aarch64/gc/shared/cardTableBarrierSetAssembler_aarch64.hpp
! src/hotspot/cpu/aarch64/gc/z/zBarrierSetAssembler_aarch64.hpp
! src/hotspot/cpu/aarch64/gc/z/z_aarch64.ad
! src/hotspot/cpu/aarch64/javaFrameAnchor_aarch64.hpp
! src/hotspot/cpu/aarch64/methodHandles_aarch64.hpp
! src/hotspot/cpu/aarch64/register_aarch64.hpp
! src/hotspot/cpu/aarch64/smallRegisterMap_aarch64.inline.hpp
! src/hotspot/cpu/aarch64/stackChunkFrameStream_aarch64.inline.hpp
! src/hotspot/cpu/arm/assembler_arm_32.hpp
! src/hotspot/cpu/arm/c1_Defs_arm.hpp
! src/hotspot/cpu/arm/c1_LIRAssembler_arm.hpp
! src/hotspot/cpu/arm/continuationFreezeThaw_arm.inline.hpp
! src/hotspot/cpu/arm/gc/shared/cardTableBarrierSetAssembler_arm.hpp
! src/hotspot/cpu/arm/interp_masm_arm.hpp
! src/hotspot/cpu/arm/matcher_arm.hpp
! src/hotspot/cpu/arm/smallRegisterMap_arm.inline.hpp
! src/hotspot/cpu/arm/stackChunkFrameStream_arm.inline.hpp
! src/hotspot/cpu/arm/stubRoutines_arm.hpp
! src/hotspot/cpu/arm/vmreg_arm.hpp
! src/hotspot/cpu/arm/vmreg_arm.inline.hpp
! src/hotspot/cpu/ppc/c1_Defs_ppc.hpp
! src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.hpp
! src/hotspot/cpu/ppc/continuationFreezeThaw_ppc.inline.hpp
! src/hotspot/cpu/ppc/continuationHelper_ppc.inline.hpp
! src/hotspot/cpu/ppc/gc/shared/barrierSetAssembler_ppc.hpp
! src/hotspot/cpu/ppc/gc/shared/cardTableBarrierSetAssembler_ppc.hpp
! src/hotspot/cpu/ppc/smallRegisterMap_ppc.inline.hpp
! src/hotspot/cpu/ppc/stackChunkFrameStream_ppc.inline.hpp
! src/hotspot/cpu/riscv/assembler_riscv.inline.hpp
! src/hotspot/cpu/riscv/c1_Defs_riscv.hpp
! src/hotspot/cpu/riscv/c1_LIRAssembler_riscv.hpp
! src/hotspot/cpu/riscv/codeBuffer_riscv.hpp
! src/hotspot/cpu/riscv/continuationFreezeThaw_riscv.inline.hpp
! src/hotspot/cpu/riscv/continuationHelper_riscv.inline.hpp
! src/hotspot/cpu/riscv/gc/shared/barrierSetAssembler_riscv.hpp
! src/hotspot/cpu/riscv/gc/shared/cardTableBarrierSetAssembler_riscv.hpp
! src/hotspot/cpu/riscv/gc/z/z_riscv.ad
! src/hotspot/cpu/riscv/interp_masm_riscv.hpp
! src/hotspot/cpu/riscv/javaFrameAnchor_riscv.hpp
! src/hotspot/cpu/riscv/matcher_riscv.hpp
! src/hotspot/cpu/riscv/methodHandles_riscv.hpp
! src/hotspot/cpu/riscv/riscv_b.ad
! src/hotspot/cpu/riscv/smallRegisterMap_riscv.inline.hpp
! src/hotspot/cpu/riscv/stackChunkFrameStream_riscv.inline.hpp
! src/hotspot/cpu/riscv/stubRoutines_riscv.hpp
! src/hotspot/cpu/s390/assembler_s390.inline.hpp
! src/hotspot/cpu/s390/c1_Defs_s390.hpp
! src/hotspot/cpu/s390/c1_FrameMap_s390.hpp
! src/hotspot/cpu/s390/continuationFreezeThaw_s390.inline.hpp
! src/hotspot/cpu/s390/disassembler_s390.cpp
! src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.hpp
! src/hotspot/cpu/s390/gc/shared/cardTableBarrierSetAssembler_s390.hpp
! src/hotspot/cpu/s390/interp_masm_s390.hpp
! src/hotspot/cpu/s390/javaFrameAnchor_s390.hpp
! src/hotspot/cpu/s390/matcher_s390.hpp
! src/hotspot/cpu/s390/smallRegisterMap_s390.inline.hpp
! src/hotspot/cpu/s390/stackChunkFrameStream_s390.inline.hpp
! src/hotspot/cpu/s390/stubRoutines_s390.hpp
! src/hotspot/cpu/x86/assembler_x86.inline.hpp
! src/hotspot/cpu/x86/c1_Defs_x86.hpp
! src/hotspot/cpu/x86/c1_FrameMap_x86.hpp
! src/hotspot/cpu/x86/c1_LIRAssembler_x86.hpp
! src/hotspot/cpu/x86/c1_LinearScan_x86.hpp
! src/hotspot/cpu/x86/continuationHelper_x86.inline.hpp
! src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.hpp
! src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.hpp
! src/hotspot/cpu/x86/gc/z/zBarrierSetAssembler_x86.hpp
! src/hotspot/cpu/x86/gc/z/z_x86_64.ad
! src/hotspot/cpu/x86/icache_x86.hpp
! src/hotspot/cpu/x86/interpreterRT_x86.hpp
! src/hotspot/cpu/x86/matcher_x86.hpp
! src/hotspot/cpu/x86/methodHandles_x86.hpp
! src/hotspot/cpu/x86/nativeInst_x86.hpp
! src/hotspot/cpu/x86/peephole_x86_64.hpp
! src/hotspot/cpu/x86/rdtsc_x86.hpp
! src/hotspot/cpu/x86/smallRegisterMap_x86.inline.hpp
! src/hotspot/cpu/x86/stackChunkFrameStream_x86.inline.hpp
! src/hotspot/cpu/x86/stubRoutines_x86.hpp
! src/hotspot/cpu/zero/assembler_zero.inline.hpp
! src/hotspot/cpu/zero/continuationFreezeThaw_zero.inline.hpp
! src/hotspot/cpu/zero/icache_zero.hpp
! src/hotspot/cpu/zero/smallRegisterMap_zero.inline.hpp
! src/hotspot/cpu/zero/stackChunkFrameStream_zero.inline.hpp
! src/hotspot/cpu/zero/stubRoutines_zero.hpp
! src/hotspot/os/aix/libodm_aix.cpp
! src/hotspot/os/aix/libperfstat_aix.hpp
! src/hotspot/os/aix/osThread_aix.hpp
! src/hotspot/os/aix/os_aix.hpp
! src/hotspot/os/linux/gc/z/zSyscall_linux.hpp
! src/hotspot/os/linux/os_linux.hpp
! src/hotspot/os/linux/os_linux.inline.hpp
! src/hotspot/os/linux/procMapsParser.hpp
! src/hotspot/os/posix/include/jvm_md.h
! src/hotspot/os/posix/signals_posix.hpp
! src/hotspot/os/posix/threadLocalStorage_posix.cpp
! src/hotspot/os/windows/gc/z/zSyscall_windows.hpp
! src/hotspot/os/windows/os_windows.hpp
! src/hotspot/os/windows/safefetch_windows.hpp
! src/hotspot/os_cpu/bsd_aarch64/icache_bsd_aarch64.hpp
! src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.S
! src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.S
! src/hotspot/os_cpu/linux_aarch64/icache_linux_aarch64.hpp
! src/hotspot/os_cpu/linux_aarch64/safefetch_linux_aarch64.S
! src/hotspot/os_cpu/linux_aarch64/threadLS_linux_aarch64.S
! src/hotspot/os_cpu/linux_ppc/gc/z/zSyscall_linux_ppc.hpp
! src/hotspot/os_cpu/linux_riscv/orderAccess_linux_riscv.hpp
! src/hotspot/os_cpu/windows_aarch64/icache_windows_aarch64.hpp
! src/hotspot/share/adlc/adlc.hpp
! src/hotspot/share/adlc/adlparse.hpp
! src/hotspot/share/asm/assembler.hpp
! src/hotspot/share/c1/c1_Canonicalizer.hpp
! src/hotspot/share/c1/c1_Defs.hpp
! src/hotspot/share/c1/c1_GraphBuilder.hpp
! src/hotspot/share/c1/c1_Instruction.hpp
! src/hotspot/share/c1/c1_InstructionPrinter.hpp
! src/hotspot/share/c1/c1_LinearScan.hpp
! src/hotspot/share/c1/c1_Optimizer.hpp
! src/hotspot/share/c1/c1_RangeCheckElimination.hpp
! src/hotspot/share/cds/aotClassLinker.hpp
! src/hotspot/share/cds/aotMappedHeapLoader.inline.hpp
! src/hotspot/share/cds/aotStreamedHeapLoader.hpp
! src/hotspot/share/cds/aotThread.cpp
! src/hotspot/share/cds/lambdaFormInvokers.inline.hpp
! src/hotspot/share/ci/bcEscapeAnalyzer.hpp
! src/hotspot/share/ci/ciEnv.hpp
! src/hotspot/share/ci/ciInstance.hpp
! src/hotspot/share/ci/ciMetadata.hpp
! src/hotspot/share/ci/ciTypeFlow.hpp
! src/hotspot/share/ci/ciUtilities.inline.hpp
! src/hotspot/share/classfile/bytecodeAssembler.hpp
! src/hotspot/share/classfile/classLoaderDataGraph.hpp
! src/hotspot/share/classfile/classLoaderStats.hpp
! src/hotspot/share/classfile/defaultMethods.hpp
! src/hotspot/share/classfile/javaClassesImpl.hpp
! src/hotspot/share/classfile/vmClasses.hpp
! src/hotspot/share/code/codeBehaviours.hpp
! src/hotspot/share/code/codeCache.hpp
! src/hotspot/share/code/compiledIC.hpp
! src/hotspot/share/code/dependencyContext.hpp
! src/hotspot/share/compiler/abstractCompiler.hpp
! src/hotspot/share/compiler/compileLog.hpp
! src/hotspot/share/compiler/compiler_globals.hpp
! src/hotspot/share/compiler/directivesParser.hpp
! src/hotspot/share/compiler/disassembler.hpp
! src/hotspot/share/compiler/methodMatcher.hpp
! src/hotspot/share/compiler/oopMap.hpp
! src/hotspot/share/compiler/oopMap.inline.hpp
! src/hotspot/share/gc/g1/g1AllocRegion.hpp
! src/hotspot/share/gc/g1/g1AllocRegion.inline.hpp
! src/hotspot/share/gc/g1/g1Allocator.hpp
! src/hotspot/share/gc/g1/g1Allocator.inline.hpp
! src/hotspot/share/gc/g1/g1AnalyticsSequences.inline.hpp
! src/hotspot/share/gc/g1/g1CardSet.inline.hpp
! src/hotspot/share/gc/g1/g1CardSetMemory.inline.hpp
! src/hotspot/share/gc/g1/g1CollectionSet.hpp
! src/hotspot/share/gc/g1/g1CollectionSet.inline.hpp
! src/hotspot/share/gc/g1/g1CollectionSetCandidates.hpp
! src/hotspot/share/gc/g1/g1CollectionSetCandidates.inline.hpp
! src/hotspot/share/gc/g1/g1CollectionSetChooser.hpp
! src/hotspot/share/gc/g1/g1ConcurrentMarkObjArrayProcessor.inline.hpp
! src/hotspot/share/gc/g1/g1EdenRegions.hpp
! src/hotspot/share/gc/g1/g1EvacStats.hpp
! src/hotspot/share/gc/g1/g1FullGCResetMetadataTask.hpp
! src/hotspot/share/gc/g1/g1FullGCScope.hpp
! src/hotspot/share/gc/g1/g1HeapRegionAttr.hpp
! src/hotspot/share/gc/g1/g1IHOPControl.hpp
! src/hotspot/share/gc/g1/g1MonitoringSupport.hpp
! src/hotspot/share/gc/g1/g1PageBasedVirtualSpace.hpp
! src/hotspot/share/gc/g1/g1ParallelCleaning.hpp
! src/hotspot/share/gc/g1/g1RegionMarkStatsCache.hpp
! src/hotspot/share/gc/g1/g1RegionToSpaceMapper.hpp
! src/hotspot/share/gc/g1/g1RegionsOnNodes.hpp
! src/hotspot/share/gc/g1/g1RootProcessor.hpp
! src/hotspot/share/gc/g1/g1ServiceThread.hpp
! src/hotspot/share/gc/g1/g1SurvivorRegions.hpp
! src/hotspot/share/gc/g1/g1Trace.hpp
! src/hotspot/share/gc/g1/g1VMOperations.hpp
! src/hotspot/share/gc/parallel/objectStartArray.hpp
! src/hotspot/share/gc/parallel/parallel_globals.hpp
! src/hotspot/share/gc/parallel/psAdaptiveSizePolicy.hpp
! src/hotspot/share/gc/parallel/psCompactionManager.hpp
! src/hotspot/share/gc/parallel/psCompactionManager.inline.hpp
! src/hotspot/share/gc/parallel/psMemoryPool.hpp
! src/hotspot/share/gc/parallel/psOldGen.hpp
! src/hotspot/share/gc/parallel/psPromotionLAB.hpp
! src/hotspot/share/gc/parallel/psPromotionManager.hpp
! src/hotspot/share/gc/parallel/psScavenge.hpp
! src/hotspot/share/gc/parallel/psVMOperations.hpp
! src/hotspot/share/gc/parallel/psVirtualspace.hpp
! src/hotspot/share/gc/parallel/psYoungGen.hpp
! src/hotspot/share/gc/parallel/spaceCounters.hpp
! src/hotspot/share/gc/parallel/vmStructs_parallelgc.hpp
! src/hotspot/share/gc/serial/cSpaceCounters.hpp
! src/hotspot/share/gc/serial/defNewGeneration.hpp
! src/hotspot/share/gc/serial/serialVMOperations.hpp
! src/hotspot/share/gc/serial/tenuredGeneration.hpp
! src/hotspot/share/gc/serial/tenuredGeneration.inline.hpp
! src/hotspot/share/gc/shared/adaptiveSizePolicy.hpp
! src/hotspot/share/gc/shared/barrierSet.hpp
! src/hotspot/share/gc/shared/barrierSetConfig.hpp
! src/hotspot/share/gc/shared/barrierSetConfig.inline.hpp
! src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.hpp
! src/hotspot/share/gc/shared/cardTableBarrierSet.hpp
! src/hotspot/share/gc/shared/collectedHeap.inline.hpp
! src/hotspot/share/gc/shared/collectorCounters.hpp
! src/hotspot/share/gc/shared/gcArguments.hpp
! src/hotspot/share/gc/shared/gcCause.hpp
! src/hotspot/share/gc/shared/gcHeapSummary.hpp
! src/hotspot/share/gc/shared/gcLocker.hpp
! src/hotspot/share/gc/shared/gcLogPrecious.hpp
! src/hotspot/share/gc/shared/gcPolicyCounters.hpp
! src/hotspot/share/gc/shared/gcThreadLocalData.hpp
! src/hotspot/share/gc/shared/gcTrace.hpp
! src/hotspot/share/gc/shared/gcVMOperations.hpp
! src/hotspot/share/gc/shared/genArguments.hpp
! src/hotspot/share/gc/shared/hSpaceCounters.hpp
! src/hotspot/share/gc/shared/oopStorage.hpp
! src/hotspot/share/gc/shared/parallelCleaning.hpp
! src/hotspot/share/gc/shared/partialArraySplitter.hpp
! src/hotspot/share/gc/shared/referenceProcessor.hpp
! src/hotspot/share/gc/shared/scavengableNMethods.hpp
! src/hotspot/share/gc/shared/stringdedup/stringDedup.hpp
! src/hotspot/share/gc/shared/stringdedup/stringDedupStat.hpp
! src/hotspot/share/gc/shared/stringdedup/stringDedupThread.hpp
! src/hotspot/share/gc/shared/threadLocalAllocBuffer.hpp
! src/hotspot/share/gc/shared/vmStructs_gc.hpp
! src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.hpp
! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp
! src/hotspot/share/gc/z/zArguments.hpp
! src/hotspot/share/gc/z/zBarrier.hpp
! src/hotspot/share/gc/z/zBarrierSet.hpp
! src/hotspot/share/gc/z/zBarrierSetNMethod.hpp
! src/hotspot/share/gc/z/zGeneration.hpp
! src/hotspot/share/gc/z/zGlobals.hpp
! src/hotspot/share/gc/z/zHeapIterator.hpp
! src/hotspot/share/gc/z/zMark.hpp
! src/hotspot/share/gc/z/zMark.inline.hpp
! src/hotspot/share/gc/z/zMarkContext.hpp
! src/hotspot/share/gc/z/zMarkContext.inline.hpp
! src/hotspot/share/gc/z/zNMethod.hpp
! src/hotspot/share/gc/z/zNMethodTableIteration.hpp
! src/hotspot/share/gc/z/zPageTable.hpp
! src/hotspot/share/gc/z/zRemembered.hpp
! src/hotspot/share/gc/z/zStat.hpp
! src/hotspot/share/gc/z/zThreadLocalData.hpp
! src/hotspot/share/gc/z/zUncoloredRoot.hpp
! src/hotspot/share/include/jmm.h
! src/hotspot/share/include/jvm_io.h
! src/hotspot/share/interpreter/bytecode.hpp
! src/hotspot/share/interpreter/bytecode.inline.hpp
! src/hotspot/share/interpreter/bytecodeHistogram.hpp
! src/hotspot/share/interpreter/bytecodeStream.hpp
! src/hotspot/share/interpreter/bytecodeTracer.hpp
! src/hotspot/share/interpreter/interpreter.hpp
! src/hotspot/share/interpreter/interpreterRuntime.hpp
! src/hotspot/share/interpreter/linkResolver.hpp
! src/hotspot/share/interpreter/templateInterpreter.hpp
! src/hotspot/share/interpreter/templateInterpreterGenerator.hpp
! src/hotspot/share/interpreter/zero/bytecodeInterpreter.hpp
! src/hotspot/share/interpreter/zero/bytecodeInterpreter.inline.hpp
! src/hotspot/share/interpreter/zero/zeroInterpreter.hpp
! src/hotspot/share/interpreter/zero/zeroInterpreterGenerator.hpp
! src/hotspot/share/jfr/leakprofiler/chains/dfsClosure.hpp
! src/hotspot/share/jfr/leakprofiler/chains/edgeQueue.hpp
! src/hotspot/share/jfr/leakprofiler/checkpoint/eventEmitter.hpp
! src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.hpp
! src/hotspot/share/jfr/leakprofiler/sampling/objectSample.hpp
! src/hotspot/share/jfr/metadata/jfrSerializer.hpp
! src/hotspot/share/jfr/recorder/jfrEventSetting.hpp
! src/hotspot/share/jfr/recorder/stacktrace/jfrStackFilterRegistry.hpp
! src/hotspot/share/jfr/recorder/storage/jfrStorageUtils.hpp
! src/hotspot/share/jfr/recorder/stringpool/jfrStringPoolWriter.hpp
! src/hotspot/share/jfr/support/jfrDeprecationEventWriter.hpp
! src/hotspot/share/jfr/support/jfrDeprecationManager.hpp
! src/hotspot/share/jfr/support/jfrObjectAllocationSample.hpp
! src/hotspot/share/jfr/support/jfrStackTraceMark.hpp
! src/hotspot/share/jfr/utilities/jfrBigEndian.hpp
! src/hotspot/share/jfr/utilities/jfrDoublyLinkedList.hpp
! src/hotspot/share/jfr/utilities/jfrEpochQueue.inline.hpp
! src/hotspot/share/jfr/utilities/jfrRelation.hpp
! src/hotspot/share/jfr/writers/jfrMemoryWriterHost.hpp
! src/hotspot/share/jfr/writers/jfrMemoryWriterHost.inline.hpp
! src/hotspot/share/jfr/writers/jfrStreamWriterHost.inline.hpp
! src/hotspot/share/jvmci/jvmci.hpp
! src/hotspot/share/jvmci/jvmciEnv.hpp
! src/hotspot/share/jvmci/jvmci_globals.hpp
! src/hotspot/share/jvmci/vmSymbols_jvmci.hpp
! src/hotspot/share/libadt/vectset.hpp
! src/hotspot/share/logging/log.hpp
! src/hotspot/share/logging/logConfiguration.hpp
! src/hotspot/share/logging/logDecorators.hpp
! src/hotspot/share/memory/heapInspection.hpp
! src/hotspot/share/memory/iterator.hpp
! src/hotspot/share/memory/memoryReserver.hpp
! src/hotspot/share/memory/metaspace/metablock.inline.hpp
! src/hotspot/share/memory/resourceArea.inline.hpp
! src/hotspot/share/nmt/mallocHeader.hpp
! src/hotspot/share/nmt/mallocHeader.inline.hpp
! src/hotspot/share/nmt/nativeCallStackPrinter.hpp
! src/hotspot/share/oops/access.hpp
! src/hotspot/share/oops/access.inline.hpp
! src/hotspot/share/oops/instanceClassLoaderKlass.hpp
! src/hotspot/share/oops/instanceMirrorKlass.hpp
! src/hotspot/share/oops/instanceRefKlass.hpp
! src/hotspot/share/oops/instanceStackChunkKlass.hpp
! src/hotspot/share/oops/metadata.hpp
! src/hotspot/share/oops/oopCast.inline.hpp
! src/hotspot/share/oops/oopHandle.inline.hpp
! src/hotspot/share/oops/stackChunkOop.hpp
! src/hotspot/share/oops/weakHandle.inline.hpp
! src/hotspot/share/opto/callGenerator.hpp
! src/hotspot/share/opto/countbitsnode.hpp
! src/hotspot/share/opto/escape.hpp
! src/hotspot/share/opto/graphKit.hpp
! src/hotspot/share/opto/idealKit.hpp
! src/hotspot/share/opto/indexSet.hpp
! src/hotspot/share/opto/intrinsicnode.hpp
! src/hotspot/share/opto/multnode.hpp
! src/hotspot/share/opto/stringopts.hpp
! src/hotspot/share/opto/superwordVTransformBuilder.hpp
! src/hotspot/share/prims/foreignGlobals.inline.hpp
! src/hotspot/share/prims/jvmtiAgent.hpp
! src/hotspot/share/prims/jvmtiEventController.inline.hpp
! src/hotspot/share/prims/jvmtiImpl.hpp
! src/hotspot/share/prims/jvmtiTagMapTable.hpp
! src/hotspot/share/prims/jvmtiThreadState.inline.hpp
! src/hotspot/share/prims/methodHandles.hpp
! src/hotspot/share/prims/vectorSupport.hpp
! src/hotspot/share/prims/vmstorage.hpp
! src/hotspot/share/runtime/continuationHelper.inline.hpp
! src/hotspot/share/runtime/continuationJavaClasses.hpp
! src/hotspot/share/runtime/continuationWrapper.inline.hpp
! src/hotspot/share/runtime/flags/flagSetting.hpp
! src/hotspot/share/runtime/flags/jvmFlagLookup.hpp
! src/hotspot/share/runtime/handles.hpp
! src/hotspot/share/runtime/handles.inline.hpp
! src/hotspot/share/runtime/icache.hpp
! src/hotspot/share/runtime/interfaceSupport.inline.hpp
! src/hotspot/share/runtime/java.hpp
! src/hotspot/share/runtime/jfieldIDWorkaround.hpp
! src/hotspot/share/runtime/monitorDeflationThread.hpp
! src/hotspot/share/runtime/notificationThread.hpp
! src/hotspot/share/runtime/park.hpp
! src/hotspot/share/runtime/perfDataTypes.hpp
! src/hotspot/share/runtime/safefetch.hpp
! src/hotspot/share/runtime/safepoint.hpp
! src/hotspot/share/runtime/safepointVerifiers.hpp
! src/hotspot/share/runtime/signature.cpp
! src/hotspot/share/runtime/smallRegisterMap.inline.hpp
! src/hotspot/share/runtime/stackChunkFrameStream.hpp
! src/hotspot/share/runtime/stackChunkFrameStream.inline.hpp
! src/hotspot/share/runtime/stackWatermark.hpp
! src/hotspot/share/runtime/threadIdentifier.hpp
! src/hotspot/share/runtime/vframe.hpp
! src/hotspot/share/runtime/vmOperations.hpp
! src/hotspot/share/services/gcNotifier.hpp
! src/hotspot/share/services/threadIdTable.hpp
! src/hotspot/share/utilities/elfFile.hpp
! src/hotspot/share/utilities/macros.hpp
! src/hotspot/share/utilities/nativeCallStack.hpp
! src/hotspot/share/utilities/numberSeq.hpp
! src/hotspot/share/utilities/objectBitSet.hpp
! src/hotspot/share/utilities/objectBitSet.inline.hpp
! src/hotspot/share/utilities/resizableHashTable.hpp
! src/hotspot/share/utilities/ticks.hpp
! test/hotspot/jtreg/compiler/c2/cr7200264/TestIntVect.java
! test/hotspot/jtreg/compiler/c2/irTests/LShiftINodeIdealizationTests.java
! test/hotspot/jtreg/compiler/c2/irTests/LShiftLNodeIdealizationTests.java
! test/hotspot/jtreg/compiler/c2/irTests/RShiftINodeIdealizationTests.java
! test/hotspot/jtreg/compiler/c2/irTests/RShiftLNodeIdealizationTests.java
! test/hotspot/jtreg/compiler/c2/irTests/TestConv2BExpansion.java
! test/hotspot/jtreg/compiler/c2/irTests/TestFPComparison.java
! test/hotspot/jtreg/compiler/c2/irTests/TestIfMinMax.java
! test/hotspot/jtreg/compiler/c2/irTests/TestLongRangeChecks.java
! test/hotspot/jtreg/compiler/c2/irTests/TestMinMaxIdentities.java
! test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java
! test/hotspot/jtreg/compiler/c2/irTests/scalarReplacement/AllocationMergesTests.java
! test/hotspot/jtreg/compiler/ciReplay/InliningBase.java
! test/hotspot/jtreg/compiler/compilercontrol/commands/OptionTest.java
! test/hotspot/jtreg/compiler/escapeAnalysis/TestFindInstMemRecursion.java
! test/hotspot/jtreg/compiler/escapeAnalysis/TestIterativeEA.java
! test/hotspot/jtreg/compiler/gcbarriers/TestZGCBarrierElision.java
! test/hotspot/jtreg/compiler/intrinsics/TestCompareUnsigned.java
! test/hotspot/jtreg/compiler/intrinsics/bigInteger/TestMultiplyToLen.java
! test/hotspot/jtreg/compiler/intrinsics/bigInteger/TestShift.java
! test/hotspot/jtreg/compiler/intrinsics/bigInteger/TestSquareToLen.java
! test/hotspot/jtreg/compiler/intrinsics/bmi/verifycode/BlsiTestI.java
! test/hotspot/jtreg/compiler/intrinsics/bmi/verifycode/BlsmskTestI.java
! test/hotspot/jtreg/compiler/intrinsics/bmi/verifycode/BlsrTestI.java
! test/hotspot/jtreg/compiler/intrinsics/klass/CastNullCheckDroppingsTest.java
! test/hotspot/jtreg/compiler/intrinsics/string/TestStringIntrinsics.java
! test/hotspot/jtreg/compiler/jsr292/MHInlineTest.java
! test/hotspot/jtreg/compiler/jsr292/patches/java.base/java/lang/invoke/MethodHandleHelper.java
! test/hotspot/jtreg/compiler/jvmci/TestJVMCIPrintProperties.java
! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaField.java
! test/hotspot/jtreg/compiler/loopopts/TestLoopPredicationDivZeroCheck.java
! test/hotspot/jtreg/compiler/loopopts/superword/TestCyclicDependency.java
! test/hotspot/jtreg/compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java
! test/hotspot/jtreg/compiler/loopopts/superword/TestMulAddS2I.java
! test/hotspot/jtreg/compiler/loopopts/superword/TestScheduleReordersScalarMemops.java
! test/hotspot/jtreg/compiler/loopopts/superword/TestUnorderedReductionPartialVectorization.java
! test/hotspot/jtreg/compiler/predicates/assertion/TestTemplateWithoutOpaqueLoopNodes.java
! test/hotspot/jtreg/compiler/splitif/TestSplitDivisionThroughPhi.java
! test/hotspot/jtreg/compiler/unsafe/OpaqueAccesses.java
! test/hotspot/jtreg/compiler/vectorization/TestFloatConversionsVectorNaN.java
! test/hotspot/jtreg/compiler/vectorization/TestReverseBitsVector.java
! test/hotspot/jtreg/compiler/vectorization/runner/LoopArrayIndexComputeTest.java
! test/hotspot/jtreg/compiler/vectorization/runner/LoopCombinedOpTest.java
! test/hotspot/jtreg/compiler/whitebox/CompilerWhiteBoxTest.java
! test/hotspot/jtreg/gc/TestPLABAdaptToMinTLABSize.java
! test/hotspot/jtreg/gc/arguments/TestMinAndInitialSurvivorRatioFlags.java
! test/hotspot/jtreg/gc/arguments/TestNewRatioFlag.java
! test/hotspot/jtreg/gc/arguments/TestNewSizeFlags.java
! test/hotspot/jtreg/gc/arguments/TestSurvivorRatioFlag.java
! test/hotspot/jtreg/gc/arguments/TestUseCompressedOopsFlagsWithUlimit.java
! test/hotspot/jtreg/gc/g1/pinnedobjs/TestPinnedOldObjectsEvacuation.java
! test/hotspot/jtreg/gc/parallel/TestDynShrinkHeap.java
! test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherWithZ.java
! test/hotspot/jtreg/gtest/AsyncLogGtest.java
! test/hotspot/jtreg/gtest/CompressedKlassGtest.java
! test/hotspot/jtreg/gtest/MetaspaceGtests.java
! test/hotspot/jtreg/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java
! test/hotspot/jtreg/runtime/CommandLine/VMOptionWarning.java
! test/hotspot/jtreg/runtime/ErrorHandling/UncaughtNativeExceptionTest.java
! test/hotspot/jtreg/runtime/ErrorHandling/libNativeException.c
! test/hotspot/jtreg/runtime/NMT/MallocRoundingReportTest.java
! test/hotspot/jtreg/runtime/NMT/MallocTestType.java
! test/hotspot/jtreg/runtime/NMT/MallocTrackingVerify.java
! test/hotspot/jtreg/runtime/NMT/ThreadedMallocTestType.java
! test/hotspot/jtreg/runtime/Safepoint/TestAbortVMOnSafepointTimeout.java
! test/hotspot/jtreg/runtime/Thread/TestAlwaysPreTouchStacks.java
! test/hotspot/jtreg/runtime/cds/ServiceLoaderTest.java
! test/hotspot/jtreg/runtime/cds/SharedStringsDedup.java
! test/hotspot/jtreg/runtime/cds/SharedStringsRunAuto.java
! test/hotspot/jtreg/runtime/cds/appcds/CreateAOTCacheVerifyError.java
! test/hotspot/jtreg/runtime/cds/appcds/TestZGCWithCDS.java
! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/ArchivedIntegerCacheTest.java
! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/ArchivedModuleWithCustomImageTest.java
! test/hotspot/jtreg/runtime/cds/appcds/customLoader/PrintSharedArchiveAndExit.java
! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/NestHostOldInf.java
! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/PrintSharedArchiveAndExit.java
! test/hotspot/jtreg/runtime/cds/appcds/jigsaw/modulepath/src/com.foos/module-info.java
! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/SharedStringsHumongous.java
! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/SharedStringsUtils.java
! test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitor.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbPrintAll.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/server/ServerMemoryMXBean.java

Changeset: 3fd7bde3
Branch: fibers
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2025-12-31 07:21:32 +0000
URL:       https://git.openjdk.org/loom/commit/3fd7bde31b965e027df423b3c2b5e1f360397195

8374378: Update copyright year to 2025 for jdk.internal.vm.ci in files where it was missed

Reviewed-by: phh

! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/code/BytecodeFrame.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/code/VirtualObject.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/code/site/Site.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/CompilerToVM.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotCompiledCode.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotCompiledCodeStream.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotCompiledNmethod.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotJavaType.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotObjectConstant.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotObjectConstantImpl.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotResolvedJavaFieldImpl.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethodImpl.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotResolvedJavaType.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotResolvedObjectType.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotSpeculationLog.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotVMConfigAccess.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/VMField.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/meta/ConstantPool.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/meta/EncodedSpeculationReason.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/meta/ResolvedJavaMethod.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/meta/ResolvedJavaType.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/services/JVMCIServiceLocator.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/services/Services.java

Changeset: 36d2c277
Branch: fibers
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2025-12-31 09:13:32 +0000
URL:       https://git.openjdk.org/loom/commit/36d2c277c47767ba22208e2e49c46001642bd4f5

8374327: Update copyright year to 2025 for files in java.base added/updated by commits in 2025

Reviewed-by: jpai

! src/java.base/aix/classes/sun/nio/ch/AixPollPort.java
! src/java.base/share/classes/com/sun/crypto/provider/RSACipher.java
! src/java.base/share/classes/java/lang/CharacterData00.java.template
! src/java.base/share/classes/java/lang/CharacterDataLatin1.java.template
! src/java.base/share/classes/java/lang/CharacterDataPrivateUse.java
! src/java.base/share/classes/java/lang/CharacterDataUndefined.java
! src/java.base/share/classes/java/lang/ThreadBuilders.java
! src/java.base/share/classes/java/lang/invoke/VarHandle.java
! src/java.base/share/classes/java/lang/ref/Cleaner.java
! src/java.base/share/classes/java/lang/ref/PhantomReference.java
! src/java.base/share/classes/java/lang/ref/SoftReference.java
! src/java.base/share/classes/java/lang/ref/WeakReference.java
! src/java.base/share/classes/java/lang/runtime/ExactConversionsSupport.java
! src/java.base/share/classes/java/net/Authenticator.java
! src/java.base/share/classes/java/net/doc-files/net-properties.html
! src/java.base/share/classes/java/nio/charset/Charset-X-Coder.java.template
! src/java.base/share/classes/java/security/Provider.java
! src/java.base/share/classes/java/util/Collection.java
! src/java.base/share/classes/java/util/WeakHashMap.java
! src/java.base/share/classes/java/util/jar/JarInputStream.java
! src/java.base/share/classes/java/util/jar/JarVerifier.java
! src/java.base/share/classes/java/util/stream/GathererOp.java
! src/java.base/share/classes/java/util/zip/GZIPOutputStream.java
! src/java.base/share/classes/java/util/zip/snippet-files/Snippets.java
! src/java.base/share/classes/javax/security/auth/Subject.java
! src/java.base/share/classes/jdk/internal/ValueBased.java
! src/java.base/share/classes/jdk/internal/access/JavaUtilConcurrentTLRAccess.java
! src/java.base/share/classes/jdk/internal/classfile/components/snippet-files/PackageSnippets.java
! src/java.base/share/classes/jdk/internal/foreign/abi/NativeEntryPoint.java
! src/java.base/share/classes/jdk/internal/foreign/abi/VMStorage.java
! src/java.base/share/classes/jdk/internal/icu/impl/Norm2AllModes.java
! src/java.base/share/classes/jdk/internal/icu/impl/UBiDiProps.java
! src/java.base/share/classes/jdk/internal/icu/impl/UCharacterProperty.java
! src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystem.java
! src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template
! src/java.base/share/classes/jdk/internal/module/ModuleInfo.java
! src/java.base/share/classes/sun/net/www/MimeTable.java
! src/java.base/share/classes/sun/nio/ch/ThreadPool.java
! src/java.base/share/classes/sun/nio/fs/AbstractPoller.java
! src/java.base/share/classes/sun/nio/fs/Cancellable.java
! src/java.base/share/classes/sun/nio/fs/PollingWatchService.java
! src/java.base/share/classes/sun/security/ec/ECPrivateKeyImpl.java
! src/java.base/share/classes/sun/security/rsa/RSAPadding.java
! src/java.base/share/classes/sun/security/ssl/CertStatusExtension.java
! src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java
! src/java.base/share/classes/sun/security/ssl/CertificateStatus.java
! src/java.base/share/classes/sun/security/ssl/CookieExtension.java
! src/java.base/share/classes/sun/security/ssl/DHServerKeyExchange.java
! src/java.base/share/classes/sun/security/ssl/DTLSOutputRecord.java
! src/java.base/share/classes/sun/security/ssl/ECDHServerKeyExchange.java
! src/java.base/share/classes/sun/security/ssl/ECPointFormatsExtension.java
! src/java.base/share/classes/sun/security/ssl/EncryptedExtensions.java
! src/java.base/share/classes/sun/security/ssl/ExtendedMasterSecretExtension.java
! src/java.base/share/classes/sun/security/ssl/HandshakeOutStream.java
! src/java.base/share/classes/sun/security/ssl/HelloRequest.java
! src/java.base/share/classes/sun/security/ssl/HelloVerifyRequest.java
! src/java.base/share/classes/sun/security/ssl/MaxFragExtension.java
! src/java.base/share/classes/sun/security/ssl/NamedGroup.java
! src/java.base/share/classes/sun/security/ssl/PredefinedDHParameterSpecs.java
! src/java.base/share/classes/sun/security/ssl/PskKeyExchangeModesExtension.java
! src/java.base/share/classes/sun/security/ssl/RSAServerKeyExchange.java
! src/java.base/share/classes/sun/security/ssl/RenegoInfoExtension.java
! src/java.base/share/classes/sun/security/ssl/ServerHelloDone.java
! src/java.base/share/classes/sun/security/ssl/ServerNameExtension.java
! src/java.base/unix/classes/java/lang/ProcessImpl.java
! src/java.base/unix/classes/sun/nio/ch/FileKey.java
! src/java.base/unix/classes/sun/nio/fs/UnixFileAttributeViews.java
! src/java.base/unix/classes/sun/nio/fs/UnixFileKey.java
! src/java.base/unix/classes/sun/nio/fs/UnixFileStore.java
! src/java.base/unix/native/jspawnhelper/jspawnhelper.c
! src/java.base/unix/native/launcher/relauncher.c
! src/java.base/unix/native/libjava/locale_str.h
! src/java.base/unix/native/libnet/Inet4AddressImpl.c
! src/java.base/unix/native/libnet/NetworkInterface.c
! src/java.base/unix/native/libnet/net_util_md.h
! src/java.base/windows/classes/java/lang/ProcessImpl.java
! src/java.base/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthSequence.java
! src/java.base/windows/classes/sun/nio/ch/PipeImpl.java
! src/java.base/windows/native/launcher/relauncher.c
! src/java.base/windows/native/libnet/NTLMAuthSequence.c

Changeset: c6246d58
Branch: fibers
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2025-12-31 10:04:45 +0000
URL:       https://git.openjdk.org/loom/commit/c6246d58f72942b66cb0632186366f0b99402306

8374383: Update the copyright year to 2025 in the remaining files under test/ where it was missed

Reviewed-by: jpai

! test/benchmarks/micros-javac/src/main/java/org/openjdk/bench/langtools/javac/GroupJavacBenchmark.java
! test/benchmarks/micros-javac/src/main/java/org/openjdk/bench/langtools/javac/JavacBenchmark.java
! test/benchmarks/micros-javac/src/main/java/org/openjdk/bench/langtools/javac/SingleJavacBenchmark.java
! test/failure_handler/src/share/conf/mac.properties
! test/jaxp/javax/xml/jaxp/unittest/validation/ValidationTest.java
! test/jdk/java/lang/StringBuffer/ECoreIndexOf.java
! test/jdk/java/lang/Thread/virtual/YieldQueuing.java
! test/jdk/javax/management/mxbean/MXBeanInteropTest1.java
! test/jdk/jdk/incubator/vector/Byte128VectorTests.java
! test/jdk/jdk/incubator/vector/Byte256VectorTests.java
! test/jdk/jdk/incubator/vector/Byte512VectorTests.java
! test/jdk/jdk/incubator/vector/Byte64VectorTests.java
! test/jdk/jdk/incubator/vector/ByteMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Double128VectorTests.java
! test/jdk/jdk/incubator/vector/Double256VectorTests.java
! test/jdk/jdk/incubator/vector/Double512VectorTests.java
! test/jdk/jdk/incubator/vector/Double64VectorTests.java
! test/jdk/jdk/incubator/vector/DoubleMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Float128VectorTests.java
! test/jdk/jdk/incubator/vector/Float256VectorTests.java
! test/jdk/jdk/incubator/vector/Float512VectorTests.java
! test/jdk/jdk/incubator/vector/Float64VectorTests.java
! test/jdk/jdk/incubator/vector/FloatMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Int128VectorTests.java
! test/jdk/jdk/incubator/vector/Int256VectorTests.java
! test/jdk/jdk/incubator/vector/Int512VectorTests.java
! test/jdk/jdk/incubator/vector/Int64VectorTests.java
! test/jdk/jdk/incubator/vector/IntMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Long128VectorTests.java
! test/jdk/jdk/incubator/vector/Long256VectorTests.java
! test/jdk/jdk/incubator/vector/Long512VectorTests.java
! test/jdk/jdk/incubator/vector/Long64VectorTests.java
! test/jdk/jdk/incubator/vector/LongMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Short128VectorTests.java
! test/jdk/jdk/incubator/vector/Short256VectorTests.java
! test/jdk/jdk/incubator/vector/Short512VectorTests.java
! test/jdk/jdk/incubator/vector/Short64VectorTests.java
! test/jdk/jdk/incubator/vector/ShortMaxVectorTests.java
! test/jdk/jdk/internal/platform/docker/MetricsCpuTester.java
! test/jdk/jdk/jfr/event/profiling/BaseTestFullStackTrace.java
! test/jdk/jdk/jfr/event/profiling/TestCPUTimeSampleNative.java
! test/jdk/jdk/jfr/event/profiling/TestCPUTimeSamplingLongPeriod.java
! test/langtools/jdk/javadoc/doclet/testHtmlLandmarkRegions/TestHtmlLandmarkRegions.java
! test/langtools/jdk/javadoc/doclet/testHtmlVersion/TestHtmlVersion.java
! test/langtools/jdk/javadoc/doclet/testMarkdown/TestMarkdownLinks.java
! test/langtools/jdk/javadoc/doclet/testRelativeLinks/pkg/C.java
! test/langtools/jdk/javadoc/doclet/testSeeTag/TestSeeTagWithModule.java
! test/langtools/jdk/javadoc/doclet/testTitleInHref/TestTitleInHref.java
! test/langtools/jdk/javadoc/tool/modules/Modules.java
! test/langtools/jdk/jshell/Compiler.java
! test/langtools/jdk/jshell/HighlightUITest.java
! test/langtools/jdk/jshell/Presets.java
! test/langtools/tools/jdeps/listdeps/ListModuleDeps.java
! test/langtools/tools/jnativescan/TestMissingSystemClass.java
! test/langtools/tools/jnativescan/cases/classpath/missingsystem/App.java
! test/langtools/tools/lib/toolbox/JavacTask.java
! test/langtools/tools/lib/types/TypeHarness.java
! test/lib/jdk/test/lib/NetworkConfiguration.java
! test/lib/jdk/test/lib/SA/SATestUtils.java
! test/lib/jdk/test/lib/containers/docker/DockerRunOptions.java
! test/lib/jdk/test/lib/helpers/ClassFileInstaller.java
! test/lib/jdk/test/whitebox/code/CodeBlob.java
! test/make/autoconf/test.m4
! test/micro/org/openjdk/bench/java/lang/FPComparison.java
! test/micro/org/openjdk/bench/java/lang/foreign/xor/GetArrayCriticalXorOpImpl.java
! test/micro/org/openjdk/bench/java/lang/foreign/xor/GetArrayElementsXorOpImpl.java
! test/micro/org/openjdk/bench/java/lang/foreign/xor/GetArrayForeignXorOpCriticalImpl.java
! test/micro/org/openjdk/bench/java/lang/foreign/xor/GetArrayForeignXorOpImpl.java
! test/micro/org/openjdk/bench/java/lang/foreign/xor/GetArrayForeignXorOpInitImpl.java
! test/micro/org/openjdk/bench/java/lang/foreign/xor/GetArrayRegionXorOpImpl.java
! test/micro/org/openjdk/bench/java/lang/foreign/xor/XorOp.java
! test/micro/org/openjdk/bench/java/lang/foreign/xor/libjnitest.c
! test/micro/org/openjdk/bench/vm/compiler/ArrayFill.java
! test/micro/org/openjdk/bench/vm/compiler/TypeVectorOperations.java
! test/micro/org/openjdk/bench/vm/compiler/VectorAliasing.java
! test/micro/org/openjdk/bench/vm/compiler/VectorReduction2.java

Changeset: 97f4f003
Branch: fibers
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2025-12-31 15:50:17 +0000
URL:       https://git.openjdk.org/loom/commit/97f4f003f4de19596de7f3d40295506edaaa30af

8373917: test/hotspot/jtreg/vmTestbase/nsk/monitoring: -iterations setting misused in tests

Reviewed-by: lmesnik

! test/hotspot/jtreg/vmTestbase/nsk/share/runner/RunParams.java

Changeset: a1a75ab6
Branch: fibers
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2025-12-31 16:26:09 +0000
URL:       https://git.openjdk.org/loom/commit/a1a75ab6d1ca25fc88be75239670f5a011ea3053

8373642: Test vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters003/TestDescription.java failed

Reviewed-by: cjplummer, syan

! test/hotspot/jtreg/vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters001/CollectionCounters001.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters002/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters003/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters004/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters005/TestDescription.java

Changeset: 2447e071
Branch: fibers
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2025-12-31 17:13:17 +0000
URL:       https://git.openjdk.org/loom/commit/2447e07137b809aec9bdbb97f89b52488f5c02de

8374355: Update copyright year to 2025 for demo in files where it was missed

Reviewed-by: aivanov

! src/demo/share/java2d/J2DBench/Makefile
! src/demo/share/java2d/J2DBench/build.xml
! src/demo/share/java2d/J2DBench/src/j2dbench/report/J2DAnalyzer.java
! src/demo/share/jfc/CodePointIM/com/sun/inputmethods/internal/codepointim/CodePointInputMethodDescriptor.java
! src/demo/share/jfc/J2Ddemo/java2d/RunWindow.java
! src/demo/share/jfc/J2Ddemo/java2d/Tools.java
! src/demo/share/jfc/Stylepad/HelloWorld.java
! src/demo/share/jfc/SwingSet2/SwingSet2.java
! src/demo/share/jfc/SwingSet2/resources/swingset_de.properties

Changeset: 2d1be8a9
Branch: fibers
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2025-12-31 17:15:34 +0000
URL:       https://git.openjdk.org/loom/commit/2d1be8a9e66fe82b60f7a22fd7796f0e54e60a5f

8374391: Update the copyright year to 2025 in the remaining files under src/ where it was missed

Reviewed-by: aivanov

! src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java
! src/java.base/share/classes/java/lang/invoke/CallSite.java
! src/java.base/share/classes/sun/util/locale/UnicodeLocaleExtension.java
! src/java.base/share/native/libjava/VirtualThread.c
! src/java.base/share/native/libverify/check_code.c
! src/java.compiler/share/classes/javax/tools/JavaFileManager.java
! src/java.compiler/share/classes/javax/tools/StandardLocation.java
! src/java.logging/share/classes/java/util/logging/ConsoleHandler.java
! src/java.management/share/classes/javax/management/modelmbean/RequiredModelMBean.java
! src/java.management/share/classes/javax/management/remote/JMXConnectorServer.java
! src/java.management/share/classes/javax/management/remote/JMXConnectorServerMBean.java
! src/java.management/share/classes/sun/management/MemoryImpl.java
! src/java.naming/share/classes/com/sun/jndi/ldap/DefaultResponseControlFactory.java
! src/java.naming/share/classes/javax/naming/ldap/PagedResultsControl.java
! src/java.rmi/share/classes/sun/rmi/log/LogInputStream.java
! src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5InitCredential.java
! src/java.sql/share/classes/java/sql/Statement.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/LDC.java
! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/ReferenceType.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_de.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ja.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_CN.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_de.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ja.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_zh_CN.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_de.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_ja.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_zh_CN.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/regex/RegularExpression.java
! src/jdk.compiler/share/classes/com/sun/source/tree/UsesTree.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/GCCause.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/FileMapInfo.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ThreadLocalAllocBuffer.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMask.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMath.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorSpecies.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/package-info.java
! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v1_0/PerfDataBuffer.java
! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/resources/aliasmap
! src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/util/InetAddressConverter.java
! src/jdk.jcmd/share/classes/sun/tools/jstat/ExpressionExecuter.java
! src/jdk.jcmd/share/classes/sun/tools/jstat/ExpressionResolver.java
! src/jdk.jcmd/share/classes/sun/tools/jstat/Parser.java
! src/jdk.jcmd/share/classes/sun/tools/jstat/resources/jstat_options
! src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/Main.java
! src/jdk.jdi/share/classes/com/sun/tools/jdi/ThreadReferenceImpl.java
! src/jdk.jdi/windows/native/libdt_shmem/shmem_md.c
! src/jdk.jdwp.agent/windows/native/libjdwp/proc_md.h
! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/ConstantMap.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/Dispatcher.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/query/FieldBuilder.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/query/QueryResolver.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/Query.java
! src/jdk.jfr/share/man/jfr.md
! src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage.properties
! src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage_de.properties
! src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage_ja.properties
! src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage_zh_CN.properties
! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java
! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Snippets.java
! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ModuleDescriptorBuilder.java
! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/StripJavaDebugAttributesPlugin.java
! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java
! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java
! src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_de.properties
! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/IOContext.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/Startup.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties
! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_de.properties
! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_ja.properties
! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_zh_CN.properties
! src/jdk.jshell/share/classes/jdk/internal/shellsupport/doc/JavadocHelper.java
! 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/execution/JdiDefaultExecutionControl.java
! src/utils/IdealGraphVisualizer/HierarchicalLayout/src/main/java/com/sun/hotspot/igv/hierarchicallayout/FreeInteractiveLayoutManager.java
! src/utils/IdealGraphVisualizer/HierarchicalLayout/src/main/java/com/sun/hotspot/igv/hierarchicallayout/HierarchicalLayoutManager.java
! src/utils/IdealGraphVisualizer/HierarchicalLayout/src/main/java/com/sun/hotspot/igv/hierarchicallayout/LayoutGraph.java
! src/utils/IdealGraphVisualizer/HierarchicalLayout/src/main/java/com/sun/hotspot/igv/hierarchicallayout/LayoutMover.java
! src/utils/IdealGraphVisualizer/HierarchicalLayout/src/main/java/com/sun/hotspot/igv/hierarchicallayout/LayoutNode.java
! src/utils/IdealGraphVisualizer/View/src/main/java/com/sun/hotspot/igv/view/actions/EnableFreeLayoutAction.java
! src/utils/IdealGraphVisualizer/View/src/main/java/com/sun/hotspot/igv/view/widgets/LineWidget.java
! src/utils/LogCompilation/src/main/java/com/sun/hotspot/tools/compiler/LogParser.java
! src/utils/LogCompilation/src/main/java/com/sun/hotspot/tools/compiler/MakeNotEntrantEvent.java

Changeset: 481ef1de
Branch: fibers
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2025-12-31 17:53:43 +0000
URL:       https://git.openjdk.org/loom/commit/481ef1de7a2721adfb8a48bb56513e617347c122

8374352: Update copyright year to 2025 for test/langtools/tools/javac/ in files where it was missed

Reviewed-by: aivanov

! test/langtools/tools/javac/6457284/T6457284.java
! test/langtools/tools/javac/OverrideChecks/InterfaceImplements.java
! test/langtools/tools/javac/OverrideChecks/InterfaceOverride.java
! test/langtools/tools/javac/OverrideChecks/T6326485.java
! test/langtools/tools/javac/T4093617/T4093617.java
! test/langtools/tools/javac/T5092545.java
! test/langtools/tools/javac/T5105890.java
! test/langtools/tools/javac/T6180021/AbstractSub.java
! test/langtools/tools/javac/T6180021/Sub.java
! test/langtools/tools/javac/T6231246/T6231246.java
! test/langtools/tools/javac/T6266772.java
! test/langtools/tools/javac/T6358024.java
! test/langtools/tools/javac/T6358166.java
! test/langtools/tools/javac/T6361619.java
! test/langtools/tools/javac/T6395974.java
! test/langtools/tools/javac/T6397286.java
! test/langtools/tools/javac/T6458823/T6458823.java
! test/langtools/tools/javac/TryWithResources/InterruptedExceptionTest.java
! test/langtools/tools/javac/TryWithResources/TwrAvoidNullCheck.java
! test/langtools/tools/javac/TryWithResources/TwrSimpleClose.java
! test/langtools/tools/javac/annotations/crash_empty_enum_const/CrashEmptyEnumConstructorTest.java
! test/langtools/tools/javac/annotations/pos/AnnotationMethods.java
! test/langtools/tools/javac/api/6400303/T6400303.java
! test/langtools/tools/javac/api/6406133/T6406133.java
! test/langtools/tools/javac/api/6410643/T6410643.java
! test/langtools/tools/javac/api/6411310/T6411310.java
! test/langtools/tools/javac/api/6411333/T6411333.java
! test/langtools/tools/javac/api/6412656/T6412656.java
! test/langtools/tools/javac/api/6415780/T6415780.java
! test/langtools/tools/javac/api/6418694/T6418694.java
! test/langtools/tools/javac/api/6420409/T6420409.java
! test/langtools/tools/javac/api/6421111/T6421111.java
! test/langtools/tools/javac/api/6421756/T6421756.java
! test/langtools/tools/javac/api/6422215/T6422215.java
! test/langtools/tools/javac/api/6422327/T6422327.java
! test/langtools/tools/javac/api/6423003/T6423003.java
! test/langtools/tools/javac/api/6431257/T6431257.java
! test/langtools/tools/javac/api/6437999/T6437999.java
! test/langtools/tools/javac/api/6440333/T6440333.java
! test/langtools/tools/javac/api/6440528/T6440528.java
! test/langtools/tools/javac/api/6452876/T6452876.java
! test/langtools/tools/javac/api/6468404/T6468404.java
! test/langtools/tools/javac/api/6471599/Main.java
! test/langtools/tools/javac/api/6731573/T6731573.java
! test/langtools/tools/javac/api/7086261/T7086261.java
! test/langtools/tools/javac/api/8007344/Test.java
! test/langtools/tools/javac/api/DiagSpans.java
! test/langtools/tools/javac/api/Sibling.java
! test/langtools/tools/javac/api/T6257235.java
! test/langtools/tools/javac/api/T6258271.java
! test/langtools/tools/javac/api/T6265137.java
! test/langtools/tools/javac/api/T6306137.java
! test/langtools/tools/javac/api/T6357331.java
! test/langtools/tools/javac/api/T6358786.java
! test/langtools/tools/javac/api/T6397104.java
! test/langtools/tools/javac/api/T6400205.java
! test/langtools/tools/javac/api/T6400207.java
! test/langtools/tools/javac/api/T6407011.java
! test/langtools/tools/javac/api/TestEvalExpression.java
! test/langtools/tools/javac/api/TestGetTree.java
! test/langtools/tools/javac/api/TestJavacTask.java
! test/langtools/tools/javac/api/TestJavacTaskScanner.java
! test/langtools/tools/javac/api/TestOperators.java
! test/langtools/tools/javac/api/TestResolveIdent.java
! test/langtools/tools/javac/api/TestTreePath.java
! test/langtools/tools/javac/api/guide/Test.java
! test/langtools/tools/javac/api/taskListeners/EventsBalancedTest.java
! test/langtools/tools/javac/boxing/T6348760.java
! test/langtools/tools/javac/cast/5043020/T5043020.java
! test/langtools/tools/javac/cast/6302214/T6302214a.java
! test/langtools/tools/javac/diags/ArgTypeCompilerFactory.java
! test/langtools/tools/javac/diags/CheckResourceKeys.java
! test/langtools/tools/javac/diags/examples/AttemptToSynchronizeOnInstanceOfVbc.java
! test/langtools/tools/javac/diags/examples/ImportModule.java
! test/langtools/tools/javac/diags/examples/ImportModuleDoesNotRead/module-info.java
! test/langtools/tools/javac/diags/examples/ImportModuleDoesNotReadUnnamed.java
! test/langtools/tools/javac/diags/examples/ImportModuleNotFound.java
! test/langtools/tools/javac/diags/examples/ReturnBeforeSuperclassInit.java
! test/langtools/tools/javac/diags/examples/TryResourceThrowsInterruptedExc.java
! test/langtools/tools/javac/enum/6424358/T6424358.java
! test/langtools/tools/javac/enum/OkFinal.java
! test/langtools/tools/javac/enum/T5075242.java
! test/langtools/tools/javac/fatalErrors/ImproveFatalErrorHandling.java
! test/langtools/tools/javac/generics/5086027/T5086027pos.java
! test/langtools/tools/javac/generics/6192945/Method.java
! test/langtools/tools/javac/generics/6207386/Test.java
! test/langtools/tools/javac/generics/6227936/T6227936.java
! test/langtools/tools/javac/generics/6245699/T6245699c.java
! test/langtools/tools/javac/generics/6292765/T6292765.java
! test/langtools/tools/javac/generics/6332204/T6332204.java
! test/langtools/tools/javac/generics/6413682/TestPos.java
! test/langtools/tools/javac/generics/T6391995.java
! test/langtools/tools/javac/generics/inference/5073060/T5073060a.java
! test/langtools/tools/javac/generics/inference/5081782/Pos.java
! test/langtools/tools/javac/generics/inference/6215213/T6215213.java
! test/langtools/tools/javac/generics/inference/6278587/T6278587.java
! test/langtools/tools/javac/generics/inference/6302954/T6456971.java
! test/langtools/tools/javac/generics/inference/6359106/T6359106.java
! test/langtools/tools/javac/generics/rawOverride/AttributeSet.java
! test/langtools/tools/javac/generics/rawOverride/T6178365.java
! test/langtools/tools/javac/generics/typevars/4856983/T4856983.java
! test/langtools/tools/javac/generics/typevars/5060485/Method.java
! test/langtools/tools/javac/generics/typevars/5060485/Pos.java
! test/langtools/tools/javac/generics/wildcards/6330931/T6330931.java
! test/langtools/tools/javac/generics/wildcards/T5097548.java
! test/langtools/tools/javac/generics/wildcards/T5097548b.java
! test/langtools/tools/javac/jvm/6397652/T6397652.java
! test/langtools/tools/javac/lambda/LambdaExpr02.java
! test/langtools/tools/javac/lib/DPrinter.java
! test/langtools/tools/javac/modules/AddModulesTest.java
! test/langtools/tools/javac/modules/ConvenientAccessErrorsTest.java
! test/langtools/tools/javac/modules/EdgeCases.java
! test/langtools/tools/javac/modules/QueryBeforeEnter.java
! test/langtools/tools/javac/multicatch/Pos10.java
! test/langtools/tools/javac/overload/T4494762.java
! test/langtools/tools/javac/patterns/Domination.java
! test/langtools/tools/javac/patterns/PrettyTest.java
! test/langtools/tools/javac/patterns/SOEDeeplyNestedBlocksTest.java
! test/langtools/tools/javac/patterns/T8332463a.java
! test/langtools/tools/javac/patterns/T8332463b.java
! test/langtools/tools/javac/positions/T6402077.java
! test/langtools/tools/javac/positions/T6404194.java
! test/langtools/tools/javac/positions/TreeEndPosTest.java
! test/langtools/tools/javac/processing/6348499/T6348499.java
! test/langtools/tools/javac/processing/6359313/T6359313.java
! test/langtools/tools/javac/processing/6413690/T6413690.java
! test/langtools/tools/javac/processing/6414633/T6414633.java
! test/langtools/tools/javac/processing/6430209/T6430209.java
! test/langtools/tools/javac/processing/T6439826.java
! test/langtools/tools/javac/processing/T8142931.java
! test/langtools/tools/javac/processing/errors/TestReturnCode.java
! test/langtools/tools/javac/processing/filer/TestPackageInfo.java
! test/langtools/tools/javac/processing/model/6194785/T6194785.java
! test/langtools/tools/javac/processing/model/LocalInAnonymous.java
! test/langtools/tools/javac/processing/model/testgetallmembers/Main.java
! test/langtools/tools/javac/processing/options/TestNoteOnImplicitProcessing.java
! test/langtools/tools/javac/processing/options/Xprint.java
! test/langtools/tools/javac/processing/rounds/CompleteOnClosed.java
! test/langtools/tools/javac/scope/6225935/T6225935.java
! test/langtools/tools/javac/scope/6225935/T6381787.java
! test/langtools/tools/javac/scope/6225935/Test.java
! test/langtools/tools/javac/scope/6392998/T6392998.java
! test/langtools/tools/javac/sealed/SealedDiffConfigurationsTest.java
! test/langtools/tools/javac/sym/ElementStructureTest.java
! test/langtools/tools/javac/tree/VarTree.java
! test/langtools/tools/javac/types/UnknownTypeTest.java
! test/langtools/tools/javac/unicode/FirstChar.java
! test/langtools/tools/javac/unit/T6198196.java
! test/langtools/tools/javac/unit/util/convert/EnclosingCandidates.java
! test/langtools/tools/javac/unit/util/list/AbstractList.java
! test/langtools/tools/javac/unit/util/list/FromArray.java
! test/langtools/tools/javac/util/filemanager/TestName.java

Changeset: 96e5c270
Branch: fibers
Author:    Michael McMahon <michaelm at openjdk.org>
Date:      2025-12-31 22:05:31 +0000
URL:       https://git.openjdk.org/loom/commit/96e5c270b4ca0ad2b47ef3c090cbbfe4661bfc22

8373893: Refactor networking http server tests to use JUnit

Reviewed-by: djelinski

! test/jdk/com/sun/net/httpserver/BasicAuthenticatorRealm.java
! test/jdk/com/sun/net/httpserver/CreateHttpServerTest.java
! test/jdk/com/sun/net/httpserver/DateFormatterTest.java
! test/jdk/com/sun/net/httpserver/FilterTest.java
! test/jdk/com/sun/net/httpserver/HeadersTest.java
! test/jdk/com/sun/net/httpserver/HttpContextTest.java
! test/jdk/com/sun/net/httpserver/HttpPrincipalTest.java
! test/jdk/com/sun/net/httpserver/HttpServerProviderTest.java
! test/jdk/com/sun/net/httpserver/InputNotRead.java
! test/jdk/com/sun/net/httpserver/UnmodifiableHeadersTest.java
! test/jdk/com/sun/net/httpserver/bugs/BasicAuthenticatorExceptionCheck.java
! test/jdk/com/sun/net/httpserver/simpleserver/CommandLineNegativeTest.java
! test/jdk/com/sun/net/httpserver/simpleserver/CommandLinePortNotSpecifiedTest.java
! test/jdk/com/sun/net/httpserver/simpleserver/CommandLinePositiveTest.java
! test/jdk/com/sun/net/httpserver/simpleserver/CustomFileSystemTest.java
! test/jdk/com/sun/net/httpserver/simpleserver/FileServerHandlerTest.java
! test/jdk/com/sun/net/httpserver/simpleserver/HttpHandlersTest.java
! test/jdk/com/sun/net/httpserver/simpleserver/HttpsServerAlertTest.java
! test/jdk/com/sun/net/httpserver/simpleserver/HttpsServerTest.java
! test/jdk/com/sun/net/httpserver/simpleserver/IdempotencyAndCommutativityTest.java
! test/jdk/com/sun/net/httpserver/simpleserver/MapToPathTest.java
! test/jdk/com/sun/net/httpserver/simpleserver/OutputFilterTest.java
! test/jdk/com/sun/net/httpserver/simpleserver/RequestTest.java
! test/jdk/com/sun/net/httpserver/simpleserver/ServerMimeTypesResolutionTest.java
! test/jdk/com/sun/net/httpserver/simpleserver/SimpleFileServerTest.java
! test/jdk/com/sun/net/httpserver/simpleserver/StressDirListings.java
! test/jdk/com/sun/net/httpserver/simpleserver/ZipFileSystemTest.java
! test/jdk/com/sun/net/httpserver/simpleserver/jwebserver/CommandLineNegativeTest.java
! test/jdk/com/sun/net/httpserver/simpleserver/jwebserver/CommandLinePortNotSpecifiedTest.java
! test/jdk/com/sun/net/httpserver/simpleserver/jwebserver/CommandLinePositiveTest.java
! test/jdk/com/sun/net/httpserver/simpleserver/jwebserver/MaxRequestTimeTest.java

Changeset: 752f46d6
Branch: fibers
Author:    Eunbin Son <thswlsqls at naver.com>
Committer: Alan Bateman <alanb at openjdk.org>
Date:      2026-01-01 07:49:30 +0000
URL:       https://git.openjdk.org/loom/commit/752f46d66250dd44e1b13bbdbd86c70a33be3ac2

8374373: Typo in VirtualThreadSchedulerMXBean.setParallelism javadoc

Reviewed-by: alanb

! src/jdk.management/share/classes/jdk/management/VirtualThreadSchedulerMXBean.java

Changeset: d9bd300c
Branch: fibers
Author:    Alan Bateman <alanb at openjdk.org>
Date:      2026-01-01 07:49:49 +0000
URL:       https://git.openjdk.org/loom/commit/d9bd300c6eddfd30a83e53e7ae03c47ea43a9e08

8374382: (aio) AsynchronousFileChannel writes wrong content using heap ByteBuffer when position != 0

Reviewed-by: jpai

! src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java
+ test/jdk/java/nio/channels/AsynchronousFileChannel/BufferPositions.java

Changeset: 13070982
Branch: fibers
Author:    Alan Bateman <alan.bateman at oracle.com>
Date:      2026-01-01 08:08:45 +0000
URL:       https://git.openjdk.org/loom/commit/1307098253bc6cadca1612117de221101af33dc0

Merge branch 'master' into fibers

! src/java.base/share/classes/java/lang/ThreadBuilders.java
! test/jdk/ProblemList.txt
! src/java.base/share/classes/java/lang/ThreadBuilders.java
! test/jdk/ProblemList.txt

Changeset: 5e2060b3
Branch: fibers
Author:    Alan Bateman <alan.bateman at oracle.com>
Date:      2026-01-01 09:10:23 +0000
URL:       https://git.openjdk.org/loom/commit/5e2060b31e934a1b5865b5a07e82b15a5080290f

Exclude JavaBaseCheckSince.java again

! test/jdk/ProblemList.txt


From duke at openjdk.org  Thu Jan  1 09:19:05 2026
From: duke at openjdk.org (duke)
Date: Thu, 1 Jan 2026 09:19:05 GMT
Subject: git: openjdk/loom: master: 49 new changesets
Message-ID: <d5f2bbcc-cee9-460c-bad1-12615609ce32@openjdk.org>

Changeset: 3579c752
Branch: master
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2025-12-22 07:57:31 +0000
URL:       https://git.openjdk.org/loom/commit/3579c752bcf2c160de47ec748c8b649b0028826a

8373876: StackWalkNativeToJava print more output in case of failures

Reviewed-by: dholmes, mdoerr

! test/hotspot/jtreg/runtime/ErrorHandling/StackWalkNativeToJava.java

Changeset: e6c3ebe2
Branch: master
Author:    Stefan Karlsson <stefank at openjdk.org>
Date:      2025-12-22 09:32:22 +0000
URL:       https://git.openjdk.org/loom/commit/e6c3ebe27b0dd4cbf1885d79ea50acb208e364fa

8374145: Remove legacy locking remnants from markWord

Reviewed-by: aboldtch, kbarrett, coleenp

! src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
! src/hotspot/share/oops/markWord.hpp

Changeset: 551e6562
Branch: master
Author:    Stefan Karlsson <stefank at openjdk.org>
Date:      2025-12-22 09:55:38 +0000
URL:       https://git.openjdk.org/loom/commit/551e656218f18fa815d42e6035f85e907c6d66a4

8374113: Taughtological if check in Reflection::array_set

Reviewed-by: fparain, liach

! src/hotspot/share/runtime/reflection.cpp

Changeset: 2715f5e6
Branch: master
Author:    Stefan Karlsson <stefank at openjdk.org>
Date:      2025-12-22 10:16:14 +0000
URL:       https://git.openjdk.org/loom/commit/2715f5e698b49cd67faa233a3188e6a69ddb80c0

8374151: Cleanup minor markWord function disorder

Reviewed-by: rcastanedalo, dholmes

! src/hotspot/share/oops/markWord.hpp

Changeset: a61a1d32
Branch: master
Author:    Damon Fenacci <dfenacci at openjdk.org>
Date:      2025-12-22 12:49:30 +0000
URL:       https://git.openjdk.org/loom/commit/a61a1d32a2bbf227081b9da6d101071ceb73076a

8373525: C2: assert(_base == Long) failed: Not a Long

Reviewed-by: chagedorn, mhaessig

! src/hotspot/share/opto/addnode.cpp
+ test/hotspot/jtreg/compiler/loopopts/TestValidTypeInOverflowProtection.java

Changeset: 9715e6da
Branch: master
Author:    Jie Fu <jiefu at openjdk.org>
Date:      2025-12-22 15:15:20 +0000
URL:       https://git.openjdk.org/loom/commit/9715e6da8355a103d9066bd15ce68b4773cbadcb

8374178: Missing include in systemDictionary.cpp after JDK-8365526

Reviewed-by: kbarrett, dholmes

! src/hotspot/share/classfile/systemDictionary.cpp

Changeset: 72505420
Branch: master
Author:    Chris Plummer <cjplummer at openjdk.org>
Date:      2025-12-22 19:28:10 +0000
URL:       https://git.openjdk.org/loom/commit/72505420ca22c2ba1584f9d401ff0a1047b8c79b

8374038: JDI EventRequestManager javadoc has unrendered @link tags inside an @code block

Reviewed-by: kevinw, amenkov

! src/jdk.jdi/share/classes/com/sun/jdi/request/EventRequestManager.java

Changeset: 4b8eda30
Branch: master
Author:    Ioi Lam <iklam at openjdk.org>
Date:      2025-12-22 19:43:55 +0000
URL:       https://git.openjdk.org/loom/commit/4b8eda30474b99a9f1065e5cea9d8c2fb859bab2

8373983: java/util/Locale/UseOldISOCodesTest.java fails with JTREG_AOT_JDK=onestep

Reviewed-by: naoto

! test/jdk/ProblemList-AotJdk.txt

Changeset: ecb42341
Branch: master
Author:    Chen Liang <liach at openjdk.org>
Date:      2025-12-23 00:12:55 +0000
URL:       https://git.openjdk.org/loom/commit/ecb42341a94326b1ee85ddd7b9ebadce8c952b99

8373447: Suspicious sign extension after integer promotion in imageDecompressor.cpp

Reviewed-by: alanb

! src/java.base/share/native/libjimage/imageDecompressor.cpp

Changeset: a0094f52
Branch: master
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
Date:      2025-12-23 04:39:50 +0000
URL:       https://git.openjdk.org/loom/commit/a0094f529a6cf7e1e28a20d5033a9a1405f49d9f

8374216: Assorted changes to jpackage without functional impact

Reviewed-by: almatvee

! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxBundlingEnvironment.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacBundlingEnvironment.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/DefaultBundlingEnvironment.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/LauncherBuilder.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/LauncherFromOptions.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/PackagingPipeline.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/OptionSpecMapperOptionScope.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardBundlingOperation.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardOption.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/Application.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/BundleSpec.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/BundlingOperationDescriptor.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/Package.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/IdentityWrapper.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/SetBuilder.java
! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinBundlingEnvironment.java
= src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinFromOptions.java
! test/jdk/tools/jpackage/helpers-test/jdk/jpackage/test/JUnitUtilsTest.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/helpers/jdk/jpackage/test/MsiDatabase.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/PackageType.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TKit.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/OptionsValidationFailTest.java
! test/jdk/tools/jpackage/junit/tools/jdk/jpackage/test/JUnitUtils.java
! test/jdk/tools/jpackage/share/BasicTest.java
! test/jdk/tools/jpackage/share/InOutPathTest.java

Changeset: e1d81c09
Branch: master
Author:    Hao Sun <haosun at openjdk.org>
Date:      2025-12-23 08:08:25 +0000
URL:       https://git.openjdk.org/loom/commit/e1d81c0946364a266a006481a8fbbac24c7e6c6a

8373122: JFR build failure with CDS disabled due to -Werror=unused-function after JDK-8365400

Reviewed-by: mgronlun, jiefu, fandreuzzi

! src/hotspot/share/jfr/support/jfrClassDefineEvent.cpp

Changeset: 40755afd
Branch: master
Author:    Aleksei Efimov <aefimov at openjdk.org>
Date:      2025-12-23 12:37:34 +0000
URL:       https://git.openjdk.org/loom/commit/40755afdf9061d65dfd039a9707445188bc04303

8373808: Refactor java/net/httpclient qpack and hpack tests to use JUnit

Reviewed-by: djelinski

! test/jdk/java/net/httpclient/http2/HpackBinaryTestDriver.java
! test/jdk/java/net/httpclient/http2/HpackCircularBufferDriver.java
! test/jdk/java/net/httpclient/http2/HpackDecoderDriver.java
! test/jdk/java/net/httpclient/http2/HpackEncoderDriver.java
! test/jdk/java/net/httpclient/http2/HpackHeaderTableDriver.java
! test/jdk/java/net/httpclient/http2/HpackHuffmanDriver.java
! test/jdk/java/net/httpclient/http2/HpackTestHelper.java
! test/jdk/java/net/httpclient/http2/java.net.http/jdk/internal/net/http/hpack/BinaryPrimitivesTest.java
! test/jdk/java/net/httpclient/http2/java.net.http/jdk/internal/net/http/hpack/CircularBufferTest.java
! test/jdk/java/net/httpclient/http2/java.net.http/jdk/internal/net/http/hpack/DecoderTest.java
! test/jdk/java/net/httpclient/http2/java.net.http/jdk/internal/net/http/hpack/EncoderTest.java
! test/jdk/java/net/httpclient/http2/java.net.http/jdk/internal/net/http/hpack/HeaderTableTest.java
! test/jdk/java/net/httpclient/http2/java.net.http/jdk/internal/net/http/hpack/HuffmanTest.java
! test/jdk/java/net/httpclient/http2/java.net.http/jdk/internal/net/http/hpack/SimpleHeaderTableTest.java
! test/jdk/java/net/httpclient/http2/java.net.http/jdk/internal/net/http/hpack/TestHelper.java
! test/jdk/java/net/httpclient/qpack/BlockingDecodingTest.java
! test/jdk/java/net/httpclient/qpack/DecoderSectionSizeLimitTest.java
! test/jdk/java/net/httpclient/qpack/DecoderTest.java
! test/jdk/java/net/httpclient/qpack/DynamicTableFieldLineRepresentationTest.java
! test/jdk/java/net/httpclient/qpack/DynamicTableTest.java
! test/jdk/java/net/httpclient/qpack/EncoderDecoderConnectionTest.java
! test/jdk/java/net/httpclient/qpack/EncoderDecoderConnector.java
! test/jdk/java/net/httpclient/qpack/EncoderDecoderTest.java
! test/jdk/java/net/httpclient/qpack/EncoderTest.java
! test/jdk/java/net/httpclient/qpack/EntriesEvictionTest.java
! test/jdk/java/net/httpclient/qpack/FieldSectionPrefixTest.java
! test/jdk/java/net/httpclient/qpack/IntegerReaderMaxValuesTest.java
! test/jdk/java/net/httpclient/qpack/StaticTableFieldsTest.java
! test/jdk/java/net/httpclient/qpack/StringLengthLimitsTest.java
! test/jdk/java/net/httpclient/qpack/TablesIndexerTest.java
! test/jdk/java/net/httpclient/qpack/UnacknowledgedInsertionTest.java

Changeset: f1c50412
Branch: master
Author:    Jie Fu <jiefu at openjdk.org>
Date:      2025-12-23 14:31:29 +0000
URL:       https://git.openjdk.org/loom/commit/f1c50412f0ded30f88720e9489e3ff4dd347ffa3

8374200: jdk/internal/platform/cgroup/TestCgroupMetrics.java fails with common prefix metrics

Reviewed-by: dholmes

! test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV2.java

Changeset: be2ac088
Branch: master
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2025-12-23 18:33:56 +0000
URL:       https://git.openjdk.org/loom/commit/be2ac088e86f2be59f26997003cd02bad16672a0

8373967: [macos] User interactions with List do not trigger ItemEvent after programmatic change

Reviewed-by: azvegint

! src/java.desktop/macosx/classes/sun/lwawt/LWListPeer.java
+ test/jdk/java/awt/List/NoEvents/MixProgrammaticUserChange.java

Changeset: 8d80bac1
Branch: master
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2025-12-23 19:20:46 +0000
URL:       https://git.openjdk.org/loom/commit/8d80bac1ec2f5eb66619c9e269d7c44612e1d04c

8374296: Comment clean up in os_linux.cpp

Reviewed-by: mdoerr

! src/hotspot/os/linux/os_linux.cpp

Changeset: 61cb6d74
Branch: master
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2025-12-23 20:47:55 +0000
URL:       https://git.openjdk.org/loom/commit/61cb6d740807f8ef356d88c0328d05be1a33a8c1

8374232: Comment cleanup in diagnosticCommand.cpp

Reviewed-by: cjplummer

! src/hotspot/share/services/diagnosticCommand.cpp

Changeset: f5249db9
Branch: master
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
Date:      2025-12-23 22:21:58 +0000
URL:       https://git.openjdk.org/loom/commit/f5249db9c566f87f7fc4f3ed70114a8168babd8b

8374233: Overloaded constructor MountUnmountDisabler(jthread thread) is missed

Reviewed-by: cjplummer, amenkov

! src/hotspot/share/runtime/mountUnmountDisabler.cpp
! src/hotspot/share/runtime/mountUnmountDisabler.hpp

Changeset: 72e1e157
Branch: master
Author:    Damon Nguyen <dnguyen at openjdk.org>
Date:      2025-12-24 00:05:12 +0000
URL:       https://git.openjdk.org/loom/commit/72e1e15779c3d7846f267c0dfd98191b99a55548

8373474: 2 Unintentional format string defect groups in jabswitch.cpp

Reviewed-by: aivanov, prr, azvegint

! src/jdk.accessibility/windows/native/jabswitch/jabswitch.cpp

Changeset: a59dbc51
Branch: master
Author:    Damon Nguyen <dnguyen at openjdk.org>
Date:      2025-12-24 00:05:27 +0000
URL:       https://git.openjdk.org/loom/commit/a59dbc5105b04234c501aa03474b82481658e5b5

8373475: Unintentional format string in logString of AccessInfo.cpp

Reviewed-by: aivanov, prr, azvegint

! src/jdk.accessibility/windows/native/toolscommon/AccessInfo.cpp

Changeset: 4a0f7e42
Branch: master
Author:    Wang Haomin <wanghaomin at openjdk.org>
Committer: Jayathirth D V <jdv at openjdk.org>
Date:      2025-12-24 09:06:39 +0000
URL:       https://git.openjdk.org/loom/commit/4a0f7e4294d2ccc2d2bf460bea87b342fe934d03

8374321: Fix undefined reference to 'png_init_filter_functions_lsx' after 8371914

Reviewed-by: jiefu, jdv

! make/modules/java.desktop/lib/ClientLibraries.gmk

Changeset: f23b958e
Branch: master
Author:    Nizar Benalla <nbenalla at openjdk.org>
Date:      2025-12-24 14:31:54 +0000
URL:       https://git.openjdk.org/loom/commit/f23b958eca5c1b9f4e22b897ede6a07ed9224c5f

8373446: Update --release 26 symbol information for JDK 26 build 29

Reviewed-by: iris, liach

+ src/jdk.compiler/share/data/symbols/jdk.management-Q.sym.txt
! src/jdk.compiler/share/data/symbols/symbols

Changeset: 6ade3480
Branch: master
Author:    Nizar Benalla <nbenalla at openjdk.org>
Date:      2025-12-24 14:38:08 +0000
URL:       https://git.openjdk.org/loom/commit/6ade34804f175b5dd1bf78515b78e5444d8be7f5

8374177: Update @since of HotSpotAOTCacheMXBean after JDK-8373607

Reviewed-by: alanb, iklam

! src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java

Changeset: 98b7792a
Branch: master
Author:    Nizar Benalla <nbenalla at openjdk.org>
Date:      2025-12-24 14:47:04 +0000
URL:       https://git.openjdk.org/loom/commit/98b7792a072380978b09fda4ec194f333d2ce7e3

8372801: tools/sincechecker/modules/java.base/JavaBaseCheckSince.java fails with JDK 27

Reviewed-by: liach

! test/jdk/ProblemList.txt

Changeset: 73a8629c
Branch: master
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2025-12-25 01:25:29 +0000
URL:       https://git.openjdk.org/loom/commit/73a8629c5b52b678febcc9d339e01ebcc5277909

8374310: Update copyright year to 2025 for client-libs in files where it was missed

Reviewed-by: jdv, aivanov

! src/java.desktop/aix/classes/sun/awt/X11InputMethod.java
! src/java.desktop/macosx/classes/apple/laf/JRSUIControl.java
! src/java.desktop/macosx/classes/apple/laf/JRSUIFocus.java
! src/java.desktop/macosx/classes/apple/laf/JRSUIState.java
! src/java.desktop/macosx/classes/apple/laf/JRSUIStateFactory.java
! src/java.desktop/macosx/classes/apple/laf/JRSUIUtils.java
! src/java.desktop/macosx/classes/com/apple/eawt/ApplicationBeanInfo.java
! src/java.desktop/macosx/classes/com/apple/eawt/FullScreenAdapter.java
! src/java.desktop/macosx/classes/com/apple/eawt/MacQuitResponse.java
! src/java.desktop/macosx/classes/com/apple/eawt/_AppDockIconHandler.java
! src/java.desktop/macosx/classes/com/apple/eawt/_AppEventHandler.java
! src/java.desktop/macosx/classes/com/apple/eawt/_AppMenuBarHandler.java
! src/java.desktop/macosx/classes/com/apple/eawt/_AppMiscHandlers.java
! src/java.desktop/macosx/classes/com/apple/eawt/event/FullScreenEvent.java
! src/java.desktop/macosx/classes/com/apple/eawt/event/GestureAdapter.java
! src/java.desktop/macosx/classes/com/apple/eawt/event/GestureHandler.java
! src/java.desktop/macosx/classes/com/apple/eawt/event/GesturePhaseEvent.java
! src/java.desktop/macosx/classes/com/apple/eawt/event/MagnificationEvent.java
! src/java.desktop/macosx/classes/com/apple/eawt/event/RotationEvent.java
! src/java.desktop/macosx/classes/com/apple/eawt/event/SwipeEvent.java
! src/java.desktop/macosx/classes/com/apple/eio/FileManager.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaButtonCheckBoxUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaButtonExtendedTypes.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaButtonLabeledUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaButtonRadioUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaButtonToggleUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaCaret.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxButton.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxRenderer.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxRendererInternal.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaEditorPaneUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaFileChooserUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaFileSystemModel.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaFileView.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaFocus.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaFocusHandler.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaFonts.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaGroupBorder.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaHighlighter.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaIcon.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaImageFactory.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaInternalFrameBorder.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaInternalFrameManager.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaInternalFramePaneUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaInternalFrameUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaLabelUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaListUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaLookAndFeel.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaMenuBarBorder.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaMenuBarUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaMenuBorder.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaMenuItemUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaMenuPainter.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaMenuUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaNativeResources.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaOptionPaneUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaPainter.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaPanelUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaPopupMenuSeparatorUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaPopupMenuUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaProgressBarUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaScrollBarUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaScrollPaneUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaScrollRegionBorder.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaSliderUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaSpinnerUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaSplitPaneDividerUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaSplitPaneUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaTabbedPaneContrastUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaTabbedPaneTabState.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaTabbedPaneUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaTableHeaderBorder.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaTableHeaderUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaTableUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaTextAreaUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaTextFieldBorder.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaTextFieldFormattedUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaTextFieldSearch.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaTextPaneUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaTextPasswordFieldUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaToolBarSeparatorUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaToolBarUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaToolTipUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaTreeUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaUtilControlSize.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaUtils.java
! src/java.desktop/macosx/classes/com/apple/laf/ScreenMenuBar.java
! src/java.desktop/macosx/classes/com/apple/laf/ScreenMenuItem.java
! src/java.desktop/macosx/classes/com/apple/laf/ScreenMenuItemCheckbox.java
! src/java.desktop/macosx/classes/com/apple/laf/ScreenMenuPropertyListener.java
! src/java.desktop/macosx/classes/com/apple/laf/ScreenPopupFactory.java
! src/java.desktop/macosx/classes/sun/awt/CGraphicsConfig.java
! src/java.desktop/macosx/classes/sun/awt/CGraphicsEnvironment.java
! src/java.desktop/macosx/classes/sun/awt/PlatformGraphicsInfo.java
! src/java.desktop/macosx/classes/sun/font/CCompositeGlyphMapper.java
! src/java.desktop/macosx/classes/sun/font/CFont.java
! src/java.desktop/macosx/classes/sun/font/CFontConfiguration.java
! src/java.desktop/macosx/classes/sun/font/CFontManager.java
! src/java.desktop/macosx/classes/sun/font/CStrikeDisposer.java
! src/java.desktop/macosx/classes/sun/font/NativeFont.java
! src/java.desktop/macosx/classes/sun/font/NativeStrike.java
! src/java.desktop/macosx/classes/sun/java2d/CRenderer.java
! src/java.desktop/macosx/classes/sun/java2d/CompositeCRenderer.java
! src/java.desktop/macosx/classes/sun/java2d/DataBufferNIOInt.java
! src/java.desktop/macosx/classes/sun/java2d/IntegerNIORaster.java
! src/java.desktop/macosx/classes/sun/java2d/MacOSFlags.java
! src/java.desktop/macosx/classes/sun/java2d/OSXOffScreenSurfaceData.java
! src/java.desktop/macosx/classes/sun/java2d/OSXSurfaceData.java
! src/java.desktop/macosx/classes/sun/java2d/metal/MTLBlitLoops.java
! src/java.desktop/macosx/classes/sun/java2d/metal/MTLBufImgOps.java
! src/java.desktop/macosx/classes/sun/java2d/metal/MTLContext.java
! src/java.desktop/macosx/classes/sun/java2d/metal/MTLDrawImage.java
! src/java.desktop/macosx/classes/sun/java2d/metal/MTLGraphicsConfig.java
! src/java.desktop/macosx/classes/sun/java2d/metal/MTLLayer.java
! src/java.desktop/macosx/classes/sun/java2d/metal/MTLMaskBlit.java
! src/java.desktop/macosx/classes/sun/java2d/metal/MTLMaskFill.java
! src/java.desktop/macosx/classes/sun/java2d/metal/MTLPaints.java
! src/java.desktop/macosx/classes/sun/java2d/metal/MTLRenderQueue.java
! src/java.desktop/macosx/classes/sun/java2d/metal/MTLRenderer.java
! src/java.desktop/macosx/classes/sun/java2d/metal/MTLSurfaceData.java
! src/java.desktop/macosx/classes/sun/java2d/metal/MTLSurfaceDataProxy.java
! src/java.desktop/macosx/classes/sun/java2d/metal/MTLTextRenderer.java
! src/java.desktop/macosx/classes/sun/java2d/metal/MTLVolatileSurfaceManager.java
! src/java.desktop/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java
! src/java.desktop/macosx/classes/sun/java2d/opengl/CGLLayer.java
! src/java.desktop/macosx/classes/sun/java2d/opengl/CGLSurfaceData.java
! src/java.desktop/macosx/classes/sun/java2d/opengl/CGLVolatileSurfaceManager.java
! src/java.desktop/macosx/classes/sun/lwawt/LWKeyboardFocusManagerPeer.java
! src/java.desktop/macosx/classes/sun/lwawt/LWLightweightFramePeer.java
! src/java.desktop/macosx/classes/sun/lwawt/LWMouseInfoPeer.java
! src/java.desktop/macosx/classes/sun/lwawt/LWWindowPeer.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibleText.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CCheckboxMenuItem.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CCustomCursor.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CDataTransferer.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CDragSourceContextPeer.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CDropTargetContextPeer.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CFileDialog.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CImage.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CInputMethod.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CInputMethodDescriptor.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CMouseDragGestureRecognizer.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformLWComponent.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformLWView.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformLWWindow.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterDialogPeer.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CSystemTray.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CToolkitThreadBlockedHandler.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CTrayIcon.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CViewEmbeddedFrame.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/CViewPlatformEmbeddedFrame.java
! src/java.desktop/macosx/classes/sun/lwawt/macosx/LWCToolkit.java
! src/java.desktop/macosx/classes/sun/print/PlatformPrinterJobProxy.java
! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTEvent.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/CGraphicsDevice.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/CGraphicsEnv.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/DnDUtilities.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/TabButtonAccessibility.m
! src/java.desktop/macosx/native/libawt_lwawt/font/CGGlyphImages.m
! src/java.desktop/share/classes/com/sun/imageio/plugins/gif/GIFImageWriter.java
! src/java.desktop/share/classes/com/sun/imageio/plugins/png/PNGImageWriter.java
! src/java.desktop/share/classes/com/sun/imageio/plugins/tiff/TIFFImageWriter.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKEngine.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifFileChooserUI.java
! src/java.desktop/share/classes/java/awt/Dialog.java
! src/java.desktop/share/classes/java/awt/EventQueue.java
! src/java.desktop/share/classes/java/awt/Font.java
! src/java.desktop/share/classes/java/awt/GraphicsEnvironment.java
! src/java.desktop/share/classes/java/awt/HeadlessException.java
! src/java.desktop/share/classes/java/awt/KeyboardFocusManager.java
! src/java.desktop/share/classes/java/awt/Polygon.java
! src/java.desktop/share/classes/java/awt/PrintJob.java
! src/java.desktop/share/classes/java/awt/SystemTray.java
! src/java.desktop/share/classes/java/awt/doc-files/FocusSpec.html
! src/java.desktop/share/classes/java/awt/doc-files/Modality.html
! src/java.desktop/share/classes/java/awt/image/BandedSampleModel.java
! src/java.desktop/share/classes/java/awt/image/ComponentSampleModel.java
! src/java.desktop/share/classes/java/awt/image/LookupOp.java
! src/java.desktop/share/classes/java/awt/image/MultiPixelPackedSampleModel.java
! src/java.desktop/share/classes/java/awt/image/SampleModel.java
! src/java.desktop/share/classes/java/awt/image/SinglePixelPackedSampleModel.java
! src/java.desktop/share/classes/java/beans/Beans.java
! src/java.desktop/share/classes/java/beans/DesignMode.java
! src/java.desktop/share/classes/javax/imageio/ImageReader.java
! src/java.desktop/share/classes/javax/imageio/ImageWriter.java
! src/java.desktop/share/classes/javax/imageio/metadata/IIOMetadataFormatImpl.java
! src/java.desktop/share/classes/javax/imageio/spi/IIORegistry.java
! src/java.desktop/share/classes/javax/imageio/spi/ServiceRegistry.java
! src/java.desktop/share/classes/javax/imageio/stream/FileCacheImageInputStream.java
! src/java.desktop/share/classes/javax/imageio/stream/FileCacheImageOutputStream.java
! src/java.desktop/share/classes/javax/imageio/stream/ImageInputStreamImpl.java
! src/java.desktop/share/classes/javax/imageio/stream/MemoryCacheImageInputStream.java
! src/java.desktop/share/classes/javax/imageio/stream/package-info.java
! src/java.desktop/share/classes/javax/swing/Action.java
! src/java.desktop/share/classes/javax/swing/BufferStrategyPaintManager.java
! src/java.desktop/share/classes/javax/swing/JComponent.java
! src/java.desktop/share/classes/javax/swing/JEditorPane.java
! src/java.desktop/share/classes/javax/swing/JFileChooser.java
! src/java.desktop/share/classes/javax/swing/JOptionPane.java
! src/java.desktop/share/classes/javax/swing/JRootPane.java
! src/java.desktop/share/classes/javax/swing/JViewport.java
! src/java.desktop/share/classes/javax/swing/RootPaneContainer.java
! src/java.desktop/share/classes/javax/swing/SwingPaintEventDispatcher.java
! src/java.desktop/share/classes/javax/swing/SwingUtilities.java
! src/java.desktop/share/classes/javax/swing/Timer.java
! src/java.desktop/share/classes/javax/swing/ToolTipManager.java
! src/java.desktop/share/classes/javax/swing/UIManager.java
! src/java.desktop/share/classes/javax/swing/package-info.java
! src/java.desktop/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java
! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthDefaultLookup.java
! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthParser.java
! src/java.desktop/share/classes/javax/swing/plaf/synth/doc-files/synth.dtd
! src/java.desktop/share/classes/javax/swing/plaf/synth/doc-files/synthFileFormat.html
! src/java.desktop/share/classes/javax/swing/text/StringContent.java
! src/java.desktop/share/classes/javax/swing/text/html/parser/Entity.java
! src/java.desktop/share/classes/sun/awt/AppContext.java
! src/java.desktop/share/classes/sun/awt/EmbeddedFrame.java
! src/java.desktop/share/classes/sun/awt/SunToolkit.java
! src/java.desktop/share/classes/sun/awt/image/ByteInterleavedRaster.java
! src/java.desktop/share/classes/sun/awt/image/SunVolatileImage.java
! src/java.desktop/share/classes/sun/awt/image/SurfaceManager.java
! src/java.desktop/share/classes/sun/awt/util/PerformanceLogger.java
! src/java.desktop/share/classes/sun/font/FileFont.java
! src/java.desktop/share/classes/sun/font/FontManager.java
! src/java.desktop/share/classes/sun/font/SunFontManager.java
! src/java.desktop/share/classes/sun/java2d/marlin/DMarlinRenderingEngine.java
! src/java.desktop/share/classes/sun/java2d/opengl/OGLGraphicsConfig.java
! src/java.desktop/share/classes/sun/java2d/pipe/BufferedContext.java
! src/java.desktop/share/classes/sun/print/PathGraphics.java
! src/java.desktop/share/classes/sun/swing/FilePane.java
! src/java.desktop/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java
! src/java.desktop/share/conf/psfontj2d.properties
! src/java.desktop/share/native/libawt/awt/image/imageInitIDs.c
! src/java.desktop/share/native/libawt/awt/image/imageInitIDs.h
! src/java.desktop/share/native/libawt/java2d/SurfaceData.h
! src/java.desktop/share/native/libawt/java2d/loops/Blit.c
! src/java.desktop/share/native/libfontmanager/freetypeScaler.c
! src/java.desktop/unix/classes/sun/awt/FcFontManager.java
! src/java.desktop/unix/classes/sun/awt/X11/GtkFileDialogPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/InfoWindow.java
! src/java.desktop/unix/classes/sun/awt/X11/MotifColorUtilities.java
! src/java.desktop/unix/classes/sun/awt/X11/MotifDnDConstants.java
! src/java.desktop/unix/classes/sun/awt/X11/MotifDnDDragSourceProtocol.java
! src/java.desktop/unix/classes/sun/awt/X11/MotifDnDDropTargetProtocol.java
! src/java.desktop/unix/classes/sun/awt/X11/Native.java
! src/java.desktop/unix/classes/sun/awt/X11/UnsafeXDisposerRecord.java
! src/java.desktop/unix/classes/sun/awt/X11/WindowDimensions.java
! src/java.desktop/unix/classes/sun/awt/X11/WindowPropertyGetter.java
! src/java.desktop/unix/classes/sun/awt/X11/XAWTLookAndFeel.java
! src/java.desktop/unix/classes/sun/awt/X11/XAWTXSettings.java
! src/java.desktop/unix/classes/sun/awt/X11/XAtom.java
! src/java.desktop/unix/classes/sun/awt/X11/XAtomList.java
! src/java.desktop/unix/classes/sun/awt/X11/XAwtState.java
! src/java.desktop/unix/classes/sun/awt/X11/XBaseMenuWindow.java
! src/java.desktop/unix/classes/sun/awt/X11/XBaseWindow.java
! src/java.desktop/unix/classes/sun/awt/X11/XButtonPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XCanvasPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XCheckboxPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XChoicePeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XClipboard.java
! src/java.desktop/unix/classes/sun/awt/X11/XContentWindow.java
! src/java.desktop/unix/classes/sun/awt/X11/XCreateWindowParams.java
! src/java.desktop/unix/classes/sun/awt/X11/XCustomCursor.java
! src/java.desktop/unix/classes/sun/awt/X11/XDataTransferer.java
! src/java.desktop/unix/classes/sun/awt/X11/XDecoratedPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XDesktopPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XDialogPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XDnDConstants.java
! src/java.desktop/unix/classes/sun/awt/X11/XDnDDragSourceProtocol.java
! src/java.desktop/unix/classes/sun/awt/X11/XDnDDropTargetProtocol.java
! src/java.desktop/unix/classes/sun/awt/X11/XDragSourceContextPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XDragSourceProtocol.java
! src/java.desktop/unix/classes/sun/awt/X11/XDropTargetContextPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XEmbedCanvasPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XEmbedChildProxy.java
! src/java.desktop/unix/classes/sun/awt/X11/XEmbedChildProxyPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XEmbedClientHelper.java
! src/java.desktop/unix/classes/sun/awt/X11/XEmbedServerTester.java
! src/java.desktop/unix/classes/sun/awt/X11/XEmbeddedFrame.java
! src/java.desktop/unix/classes/sun/awt/X11/XEmbeddedFramePeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XEmbeddingContainer.java
! src/java.desktop/unix/classes/sun/awt/X11/XErrorHandler.java
! src/java.desktop/unix/classes/sun/awt/X11/XException.java
! src/java.desktop/unix/classes/sun/awt/X11/XFocusProxyWindow.java
! src/java.desktop/unix/classes/sun/awt/X11/XFontPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XGlobalCursorManager.java
! src/java.desktop/unix/classes/sun/awt/X11/XHorizontalScrollbar.java
! src/java.desktop/unix/classes/sun/awt/X11/XIconWindow.java
! src/java.desktop/unix/classes/sun/awt/X11/XInputMethod.java
! src/java.desktop/unix/classes/sun/awt/X11/XInputMethodDescriptor.java
! src/java.desktop/unix/classes/sun/awt/X11/XKeyboardFocusManagerPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XLabelPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XLightweightFramePeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XListPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XMSelection.java
! src/java.desktop/unix/classes/sun/awt/X11/XMenuBarPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XMenuItemPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XMenuPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XMenuWindow.java
! src/java.desktop/unix/classes/sun/awt/X11/XMouseDragGestureRecognizer.java
! src/java.desktop/unix/classes/sun/awt/X11/XNETProtocol.java
! src/java.desktop/unix/classes/sun/awt/X11/XPanelPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XPopupMenuPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XPropertyCache.java
! src/java.desktop/unix/classes/sun/awt/X11/XQueryTree.java
! src/java.desktop/unix/classes/sun/awt/X11/XRepaintArea.java
! src/java.desktop/unix/classes/sun/awt/X11/XRootWindow.java
! src/java.desktop/unix/classes/sun/awt/X11/XScrollPanePeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XScrollbar.java
! src/java.desktop/unix/classes/sun/awt/X11/XScrollbarPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XSelection.java
! src/java.desktop/unix/classes/sun/awt/X11/XSystemTrayPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XTextAreaPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XToolkitThreadBlockedHandler.java
! src/java.desktop/unix/classes/sun/awt/X11/XTranslateCoordinates.java
! src/java.desktop/unix/classes/sun/awt/X11/XTrayIconPeer.java
! src/java.desktop/unix/classes/sun/awt/X11/XVerticalScrollbar.java
! src/java.desktop/unix/classes/sun/awt/X11/XWINProtocol.java
! src/java.desktop/unix/classes/sun/awt/X11/XWindow.java
! src/java.desktop/unix/classes/sun/awt/X11/XWindowAttributesData.java
! src/java.desktop/unix/classes/sun/awt/X11/XWrapperBase.java
! src/java.desktop/unix/classes/sun/awt/X11/XlibUtil.java
! src/java.desktop/unix/classes/sun/awt/X11CustomCursor.java
! src/java.desktop/unix/classes/sun/awt/X11FontManager.java
! src/java.desktop/unix/classes/sun/awt/X11GraphicsConfig.java
! src/java.desktop/unix/classes/sun/awt/X11GraphicsEnvironment.java
! src/java.desktop/unix/classes/sun/awt/X11InputMethod.java
! src/java.desktop/unix/classes/sun/awt/X11InputMethodBase.java
! src/java.desktop/unix/classes/sun/awt/X11InputMethodDescriptor.java
! src/java.desktop/unix/classes/sun/awt/XSettings.java
! src/java.desktop/unix/classes/sun/font/DelegateStrike.java
! src/java.desktop/unix/classes/sun/font/DoubleByteEncoder.java
! src/java.desktop/unix/classes/sun/font/FcFontConfiguration.java
! src/java.desktop/unix/classes/sun/font/FontConfigManager.java
! src/java.desktop/unix/classes/sun/font/MFontConfiguration.java
! src/java.desktop/unix/classes/sun/font/NativeFont.java
! src/java.desktop/unix/classes/sun/font/NativeStrike.java
! src/java.desktop/unix/classes/sun/font/NativeStrikeDisposer.java
! src/java.desktop/unix/classes/sun/font/X11Dingbats.java
! src/java.desktop/unix/classes/sun/font/X11GB18030_0.java
! src/java.desktop/unix/classes/sun/font/X11GB18030_1.java
! src/java.desktop/unix/classes/sun/font/X11GB2312.java
! src/java.desktop/unix/classes/sun/font/X11GBK.java
! src/java.desktop/unix/classes/sun/font/X11Johab.java
! src/java.desktop/unix/classes/sun/font/X11KSC5601.java
! src/java.desktop/unix/classes/sun/font/X11SunUnicode_0.java
! src/java.desktop/unix/classes/sun/font/X11TextRenderer.java
! src/java.desktop/unix/classes/sun/font/XMap.java
! src/java.desktop/unix/classes/sun/font/XRGlyphCache.java
! src/java.desktop/unix/classes/sun/font/XRGlyphCacheEntry.java
! src/java.desktop/unix/classes/sun/font/XRTextRenderer.java
! src/java.desktop/unix/classes/sun/java2d/opengl/GLXGraphicsConfig.java
! src/java.desktop/unix/classes/sun/java2d/opengl/GLXSurfaceData.java
! src/java.desktop/unix/classes/sun/java2d/opengl/GLXVolatileSurfaceManager.java
! src/java.desktop/unix/classes/sun/java2d/x11/X11PMBlitBgLoops.java
! src/java.desktop/unix/classes/sun/java2d/x11/X11PMBlitLoops.java
! src/java.desktop/unix/classes/sun/java2d/x11/X11Renderer.java
! src/java.desktop/unix/classes/sun/java2d/x11/X11SurfaceData.java
! src/java.desktop/unix/classes/sun/java2d/x11/X11SurfaceDataProxy.java
! src/java.desktop/unix/classes/sun/java2d/x11/X11VolatileSurfaceManager.java
! src/java.desktop/unix/classes/sun/java2d/xr/DirtyRegion.java
! src/java.desktop/unix/classes/sun/java2d/xr/GrowableByteArray.java
! src/java.desktop/unix/classes/sun/java2d/xr/GrowableEltArray.java
! src/java.desktop/unix/classes/sun/java2d/xr/GrowablePointArray.java
! src/java.desktop/unix/classes/sun/java2d/xr/GrowableRectArray.java
! src/java.desktop/unix/classes/sun/java2d/xr/MaskTile.java
! src/java.desktop/unix/classes/sun/java2d/xr/MaskTileManager.java
! src/java.desktop/unix/classes/sun/java2d/xr/MutableInteger.java
! src/java.desktop/unix/classes/sun/java2d/xr/XIDGenerator.java
! src/java.desktop/unix/classes/sun/java2d/xr/XRBackendNative.java
! src/java.desktop/unix/classes/sun/java2d/xr/XRColor.java
! src/java.desktop/unix/classes/sun/java2d/xr/XRCompositeManager.java
! src/java.desktop/unix/classes/sun/java2d/xr/XRDrawImage.java
! src/java.desktop/unix/classes/sun/java2d/xr/XRDrawLine.java
! src/java.desktop/unix/classes/sun/java2d/xr/XRGraphicsConfig.java
! src/java.desktop/unix/classes/sun/java2d/xr/XRMaskBlit.java
! src/java.desktop/unix/classes/sun/java2d/xr/XRMaskFill.java
! src/java.desktop/unix/classes/sun/java2d/xr/XRMaskImage.java
! src/java.desktop/unix/classes/sun/java2d/xr/XRPMBlitLoops.java
! src/java.desktop/unix/classes/sun/java2d/xr/XRPaints.java
! src/java.desktop/unix/classes/sun/java2d/xr/XRRenderer.java
! src/java.desktop/unix/classes/sun/java2d/xr/XRSolidSrcPict.java
! src/java.desktop/unix/classes/sun/java2d/xr/XRSurfaceData.java
! src/java.desktop/unix/classes/sun/java2d/xr/XRSurfaceDataProxy.java
! src/java.desktop/unix/classes/sun/java2d/xr/XRUtils.java
! src/java.desktop/unix/classes/sun/java2d/xr/XRVolatileSurfaceManager.java
! src/java.desktop/unix/classes/sun/java2d/xr/XcbRequestCounter.java
! src/java.desktop/unix/classes/sun/print/AttributeClass.java
! src/java.desktop/unix/classes/sun/print/CUPSPrinter.java
! src/java.desktop/unix/classes/sun/print/IPPPrintService.java
! src/java.desktop/unix/classes/sun/print/PrintServiceLookupProvider.java
! src/java.desktop/unix/classes/sun/print/UnixPrintService.java
! src/java.desktop/unix/native/common/awt/awt_GraphicsEnv.h
! src/java.desktop/unix/native/common/awt/fontpath.c
! src/java.desktop/unix/native/libawt/awt/awt_LoadLibrary.c
! src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/AnimationController.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/TMSchema.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsBorders.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsButtonUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsCheckBoxUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsClassicLookAndFeel.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsComboBoxUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsDesktopIconUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsDesktopPaneUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsEditorPaneUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsGraphicsUtils.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsInternalFrameUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLabelUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsMenuBarUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsOptionPaneUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsPasswordFieldUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsPopupMenuSeparatorUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsPopupMenuUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsPopupWindow.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsRadioButtonUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsRootPaneUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsScrollBarUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsScrollPaneUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsSeparatorUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsSliderUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsSpinnerUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsSplitPaneDivider.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsSplitPaneUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsTabbedPaneUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsTableHeaderUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsTextAreaUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsTextFieldUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsTextPaneUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsTextUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsToggleButtonUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsToolBarSeparatorUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsToolBarUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsTreeUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/XPStyle.java
! src/java.desktop/windows/classes/sun/awt/PlatformGraphicsInfo.java
! src/java.desktop/windows/classes/sun/awt/Win32ColorModel24.java
! src/java.desktop/windows/classes/sun/awt/Win32FontManager.java
! src/java.desktop/windows/classes/sun/awt/Win32GraphicsConfig.java
! src/java.desktop/windows/classes/sun/awt/Win32GraphicsDevice.java
! src/java.desktop/windows/classes/sun/awt/Win32GraphicsEnvironment.java
! src/java.desktop/windows/classes/sun/awt/windows/TranslucentWindowPainter.java
! src/java.desktop/windows/classes/sun/awt/windows/WComponentPeer.java
! src/java.desktop/windows/classes/sun/awt/windows/WDataTransferer.java
! src/java.desktop/windows/classes/sun/awt/windows/WDefaultFontCharset.java
! src/java.desktop/windows/classes/sun/awt/windows/WDesktopProperties.java
! src/java.desktop/windows/classes/sun/awt/windows/WDragSourceContextPeer.java
! src/java.desktop/windows/classes/sun/awt/windows/WEmbeddedFrame.java
! src/java.desktop/windows/classes/sun/awt/windows/WEmbeddedFramePeer.java
! src/java.desktop/windows/classes/sun/awt/windows/WInputMethod.java
! src/java.desktop/windows/classes/sun/awt/windows/WLabelPeer.java
! src/java.desktop/windows/classes/sun/awt/windows/WLightweightFramePeer.java
! src/java.desktop/windows/classes/sun/awt/windows/WMenuItemPeer.java
! src/java.desktop/windows/classes/sun/awt/windows/WMouseInfoPeer.java
! src/java.desktop/windows/classes/sun/awt/windows/WPopupMenuPeer.java
! src/java.desktop/windows/classes/sun/awt/windows/WScrollPanePeer.java
! src/java.desktop/windows/classes/sun/awt/windows/WScrollbarPeer.java
! src/java.desktop/windows/classes/sun/awt/windows/WTrayIconPeer.java
! src/java.desktop/windows/classes/sun/awt/windows/WWindowPeer.java
! src/java.desktop/windows/classes/sun/awt/windows/WingDings.java
! src/java.desktop/windows/classes/sun/font/NativeFont.java
! src/java.desktop/windows/classes/sun/font/NativeStrike.java
! src/java.desktop/windows/classes/sun/java2d/d3d/D3DBlitLoops.java
! src/java.desktop/windows/classes/sun/java2d/d3d/D3DBufImgOps.java
! src/java.desktop/windows/classes/sun/java2d/d3d/D3DContext.java
! src/java.desktop/windows/classes/sun/java2d/d3d/D3DDrawImage.java
! src/java.desktop/windows/classes/sun/java2d/d3d/D3DGraphicsConfig.java
! src/java.desktop/windows/classes/sun/java2d/d3d/D3DGraphicsDevice.java
! src/java.desktop/windows/classes/sun/java2d/d3d/D3DMaskBlit.java
! src/java.desktop/windows/classes/sun/java2d/d3d/D3DMaskFill.java
! src/java.desktop/windows/classes/sun/java2d/d3d/D3DPaints.java
! src/java.desktop/windows/classes/sun/java2d/d3d/D3DRenderQueue.java
! src/java.desktop/windows/classes/sun/java2d/d3d/D3DRenderer.java
! src/java.desktop/windows/classes/sun/java2d/d3d/D3DScreenUpdateManager.java
! src/java.desktop/windows/classes/sun/java2d/d3d/D3DSurfaceData.java
! src/java.desktop/windows/classes/sun/java2d/d3d/D3DSurfaceDataProxy.java
! src/java.desktop/windows/classes/sun/java2d/d3d/D3DTextRenderer.java
! src/java.desktop/windows/classes/sun/java2d/d3d/D3DVolatileSurfaceManager.java
! src/java.desktop/windows/classes/sun/java2d/opengl/WGLGraphicsConfig.java
! src/java.desktop/windows/classes/sun/java2d/opengl/WGLSurfaceData.java
! src/java.desktop/windows/classes/sun/java2d/opengl/WGLVolatileSurfaceManager.java
! src/java.desktop/windows/classes/sun/java2d/windows/GDIBlitLoops.java
! src/java.desktop/windows/classes/sun/java2d/windows/GDIRenderer.java
! src/java.desktop/windows/classes/sun/java2d/windows/GDIWindowSurfaceData.java
! src/java.desktop/windows/classes/sun/print/PlatformPrinterJobProxy.java
! src/java.desktop/windows/classes/sun/print/PrintServiceLookupProvider.java
! src/java.desktop/windows/classes/sun/print/Win32MediaTray.java
! src/java.desktop/windows/classes/sun/print/Win32PrintJob.java
! src/java.desktop/windows/classes/sun/print/Win32PrintService.java
! src/java.desktop/windows/classes/sun/swing/plaf/windows/ClassicSortArrowIcon.java
! src/java.desktop/windows/native/libawt/windows/awt_Dialog.h
! src/java.desktop/windows/native/libawt/windows/awt_GDIObject.cpp
! src/java.desktop/windows/native/libawt/windows/awt_InputMethod.cpp
! src/java.desktop/windows/native/libawt/windows/awt_Mlib.cpp
! src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp
! src/java.desktop/windows/native/libawt/windows/awt_new.cpp
! test/jdk/java/awt/Choice/ChoiceLocationTest/ChoiceLocationTest.java
! test/jdk/java/awt/Dialog/CloseDialog/CloseDialogTest.java
! test/jdk/java/awt/Focus/ChoiceFocus/ChoiceFocus.java
! test/jdk/java/awt/Frame/GetGraphicsStressTest/GetGraphicsStressTest.java
! test/jdk/java/awt/Frame/ShapeNotSetSometimes/ShapeNotSetSometimes.java
! test/jdk/java/awt/List/FirstItemRemoveTest/FirstItemRemoveTest.java
! test/jdk/java/awt/List/FocusEmptyListTest/FocusEmptyListTest.java
! test/jdk/java/awt/Modal/PrintDialogsTest/PrintDialogsTest.java
! test/jdk/java/awt/Modal/PrintDialogsTest/Test.java
! test/jdk/java/awt/Mouse/GetMousePositionTest/GetMousePositionWithOverlay.java
! test/jdk/java/awt/Mouse/GetMousePositionTest/GetMousePositionWithPopup.java
! test/jdk/java/awt/PrintJob/PageSetupDlgBlockingTest/PageSetupDlgBlockingTest.java
! test/jdk/java/awt/TextArea/TextAreaCursorTest/HoveringAndDraggingTest.java
! test/jdk/java/awt/TextArea/TextScrollTest.java
! test/jdk/java/awt/datatransfer/DragUnicodeBetweenJVMTest/DragUnicodeBetweenJVMTest.java
! test/jdk/java/awt/datatransfer/MissedHtmlAndRtfBug/MissedHtmlAndRtfBug.java
! test/jdk/java/awt/dnd/DnDFileGroupDescriptor/DnDFileGroupDescriptor.java
! test/jdk/java/awt/dnd/FileListBetweenJVMsTest/FileListBetweenJVMsTest.java
! test/jdk/java/awt/dnd/URIListBetweenJVMsTest/URIListBetweenJVMsTest.java
! test/jdk/java/awt/dnd/URIListToFileListBetweenJVMsTest/URIListToFileListBetweenJVMsTest.java
! test/jdk/java/awt/event/KeyEvent/KeyTyped/EscapeKeyTyped.java
! test/jdk/java/awt/event/MouseEvent/MenuDragMouseEventAbsoluteCoordsTest/MenuDragMouseEventAbsoluteCoordsTest.java
! test/jdk/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_2.java
! test/jdk/java/awt/event/MouseWheelEvent/InfiniteRecursion/InfiniteRecursion_3.java
! test/jdk/java/awt/event/helpers/lwcomponents/LWButton.java
! test/jdk/java/awt/font/GlyphVector/GetGlyphCharIndexTest.java
! test/jdk/java/awt/grab/EmbeddedFrameTest1/EmbeddedFrameTest1.java
! test/jdk/java/awt/im/8041990/bug8041990.java
! test/jdk/java/awt/im/PinyinIMCapsTest.java
! test/jdk/java/awt/im/PinyinIMCommaTest.java
! test/jdk/java/awt/im/PinyinIMFullstopTest.java
! test/jdk/java/awt/image/AffineTransformOp/AffineTxOpSizeTest.java
! test/jdk/java/awt/image/DrawImage/TiledImage.java
! test/jdk/java/awt/print/Dialog/DialogOrient.java
! test/jdk/java/awt/print/PrinterJob/PageDialogTest.java
! test/jdk/java/awt/print/PrinterJob/PrintDialog.java
! test/jdk/java/awt/print/PrinterJob/PrintDialogCancel.java
! test/jdk/java/awt/print/PrinterJob/ThinLines.java
! test/jdk/java/awt/print/RemotePrinterStatusRefresh/RemotePrinterStatusRefresh.java
! test/jdk/java/awt/regtesthelpers/AbstractTest.java
! test/jdk/java/awt/regtesthelpers/Util.java
! test/jdk/java/awt/regtesthelpers/process/ProcessCommunicator.java
! test/jdk/javax/sound/midi/MidiDeviceConnectors/TestAllDevices.java
! test/jdk/javax/sound/midi/Sequencer/Looping.java
! test/jdk/javax/sound/midi/SysexMessage/SendRawSysexMessage.java
! test/jdk/javax/sound/midi/spi/MidiDeviceProvider/ExpectedNPEOnNull.java
! test/jdk/javax/sound/midi/spi/MidiDeviceProvider/FakeInfo.java
! test/jdk/javax/sound/midi/spi/MidiDeviceProvider/UnsupportedInfo.java
! test/jdk/javax/sound/sampled/Clip/ClipFlushCrash.java
! test/jdk/javax/sound/sampled/Clip/IsRunningHang.java
! test/jdk/javax/sound/sampled/Clip/OpenNonIntegralNumberOfSampleframes.java
! test/jdk/javax/sound/sampled/DataLine/LongFramePosition.java
! test/jdk/javax/sound/sampled/DirectAudio/bug6372428.java
! test/jdk/javax/sound/sampled/LinuxBlock/PlaySine.java
! test/jdk/javax/swing/JOptionPane/bug4174551.java
! test/jdk/javax/swing/JTextArea/4697612/bug4697612.java
! test/jdk/javax/swing/text/html/parser/Parser/6990651/bug6990651.java
! test/jdk/javax/swing/text/html/parser/Parser/8078268/bug8078268.java
! test/jdk/sun/java2d/marlin/ClipShapeTest.java
! test/jdk/sun/java2d/marlin/CrashNaNTest.java
! test/jdk/sun/java2d/marlin/CrashPaintTest.java
! test/jdk/sun/java2d/marlin/TextClipErrorTest.java

Changeset: 534c33d0
Branch: master
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2025-12-25 07:25:40 +0000
URL:       https://git.openjdk.org/loom/commit/534c33d0ef7daa0d0d5b56a1101b4c9d47a48049

8374323: Update copyright year to 2025 for the build system in files where it was missed

Reviewed-by: erikj

! .github/actions/build-jtreg/action.yml
! .github/actions/get-bundles/action.yml
! .github/actions/get-gtest/action.yml
! .github/actions/get-jtreg/action.yml
! .github/actions/get-msys2/action.yml
! .github/actions/upload-bundles/action.yml
! .github/workflows/build-alpine-linux.yml
! .github/workflows/build-cross-compile.yml
! .github/workflows/build-linux.yml
! .github/workflows/build-macos.yml
! .github/workflows/build-windows.yml
! .github/workflows/main.yml
! .github/workflows/test.yml
! make/RunTestsPrebuiltSpec.gmk
! make/autoconf/bootcycle-spec.gmk.template
! make/autoconf/buildjdk-spec.gmk.template
! make/autoconf/compare.sh.template
! make/autoconf/hotspot.m4
! make/autoconf/lib-bundled.m4
! make/autoconf/platform.m4
! make/devkit/createWindowsDevkit.sh
! make/jdk/src/classes/build/tools/pandocfilter/PandocFilter.java
! make/jdk/src/classes/build/tools/taglet/JSpec.java
! make/jdk/src/classes/build/tools/taglet/ToolGuide.java
! make/langtools/tools/propertiesparser/parser/Message.java
! make/scripts/compare-logger.sh
! make/scripts/compare.sh

Changeset: 3e6170c5
Branch: master
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2025-12-26 03:46:40 +0000
URL:       https://git.openjdk.org/loom/commit/3e6170c5be95f92a209c58928be487e8a9f97287

8374354: Update copyright year to 2025 for jdk.javadoc in files where it was missed

Reviewed-by: liach

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractTreeWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllClassesIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlLinkFactory.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/NestedClassWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SerializedFormWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Table.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyles.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/taglets/LinkTaglet.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/CommentUtils.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/WorkArounds.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocFile.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/Content.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/ContentBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/Entity.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/RawHtml.java

Changeset: e65ace10
Branch: master
Author:    Daniel Gredler <dgredler at openjdk.org>
Date:      2025-12-26 11:58:48 +0000
URL:       https://git.openjdk.org/loom/commit/e65ace10e3c40d6fef4e9997311d88c900e84ced

6517125: FontStrike.getGlyphVectorOutline() not used

Reviewed-by: prr, serb

! src/java.desktop/macosx/classes/sun/font/CStrike.java
! src/java.desktop/macosx/classes/sun/font/NativeStrike.java
! src/java.desktop/share/classes/sun/font/CompositeStrike.java
! src/java.desktop/share/classes/sun/font/FileFontStrike.java
! src/java.desktop/share/classes/sun/font/FontStrike.java
! src/java.desktop/unix/classes/sun/font/DelegateStrike.java
! src/java.desktop/unix/classes/sun/font/NativeStrike.java
! src/java.desktop/windows/classes/sun/font/NativeStrike.java

Changeset: ac07a41d
Branch: master
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2025-12-26 19:12:55 +0000
URL:       https://git.openjdk.org/loom/commit/ac07a41de9877aec3e9d5e7a23b0583038a7956d

8374360: Update copyright year to 2025 for test/jdk/jdk/jfr in files where it was missed

Reviewed-by: egahlin

! test/jdk/jdk/jfr/api/consumer/TestRecordedClass.java
! test/jdk/jdk/jfr/api/consumer/TestRecordedFrameType.java
! test/jdk/jdk/jfr/api/consumer/TestRecordingFileSanitization.java
! test/jdk/jdk/jfr/api/consumer/TestRecordingFileWrite.java
! test/jdk/jdk/jfr/api/consumer/log/TestContent.java
! test/jdk/jdk/jfr/api/consumer/log/TestDiskOnOff.java
! test/jdk/jdk/jfr/api/consumer/log/TestDynamicStart.java
! test/jdk/jdk/jfr/api/consumer/log/TestMemoryDiskTransition.java
! test/jdk/jdk/jfr/api/consumer/log/TestMemoryOnly.java
! test/jdk/jdk/jfr/api/consumer/log/TestSystemEvents.java
! test/jdk/jdk/jfr/api/consumer/log/TestTruncation.java
! test/jdk/jdk/jfr/api/consumer/log/TestUserEvents.java
! test/jdk/jdk/jfr/api/consumer/log/TestVerbosity.java
! test/jdk/jdk/jfr/api/consumer/log/TestWithStreaming.java
! test/jdk/jdk/jfr/api/consumer/recordingstream/TestDump.java
! test/jdk/jdk/jfr/api/consumer/recordingstream/TestRecordingName.java
! test/jdk/jdk/jfr/api/consumer/streaming/TestBaseRepositoryAfterStart.java
! test/jdk/jdk/jfr/api/consumer/streaming/TestBaseRepositoryBeforeStart.java
! test/jdk/jdk/jfr/api/consumer/streaming/TestBaseRepositoryLastModified.java
! test/jdk/jdk/jfr/api/consumer/streaming/TestBaseRepositoryMultipleProcesses.java
! test/jdk/jdk/jfr/api/recording/dump/TestDumpDevNull.java
! test/jdk/jdk/jfr/event/allocation/TestObjectAllocationSampleEvent.java
! test/jdk/jdk/jfr/event/compiler/TestCompilerQueueUtilization.java
! test/jdk/jdk/jfr/event/gc/detailed/TestG1InvalidHeapRegionTypeChangeEvent.java
! test/jdk/jdk/jfr/event/gc/detailed/TestGCCPUTimeEvent.java
! test/jdk/jdk/jfr/event/gc/detailed/TestGCHeapMemoryPoolUsageEvent.java
! test/jdk/jdk/jfr/event/gc/heapsummary/HeapSummaryEventAllGcs.java
! test/jdk/jdk/jfr/event/io/TestAsynchronousFileChannelEvents.java
! test/jdk/jdk/jfr/event/io/TestSocketAdapterEvents.java
! test/jdk/jdk/jfr/event/runtime/TestDeprecatedEvent.java
! test/jdk/jdk/jfr/event/runtime/TestDirectBufferStatisticsEvent.java
! test/jdk/jdk/jfr/event/runtime/TestFinalizerStatisticsEvent.java
! test/jdk/jdk/jfr/event/runtime/TestNativeLibraryLoadEvent.java
! test/jdk/jdk/jfr/event/security/TestInitialSecurityPropertyEvent.java
! test/jdk/jdk/jfr/event/security/TestSecurityProviderServiceEvent.java
! test/jdk/jdk/jfr/jcmd/TestJcmdConfigureReadOnly.java
! test/jdk/jdk/jfr/jcmd/TestJcmdOptionSpecifiedOnce.java
! test/jdk/jdk/jfr/jcmd/TestJcmdStartGeneratedFilename.java
! test/jdk/jdk/jfr/jcmd/TestJcmdViewMissingData.java
! test/jdk/jdk/jfr/jmx/streaming/TestClose.java
! test/jdk/jdk/jfr/jmx/streaming/TestDelegated.java
! test/jdk/jdk/jfr/jmx/streaming/TestDumpOrder.java
! test/jdk/jdk/jfr/jmx/streaming/TestMetadataEvent.java
! test/jdk/jdk/jfr/jmx/streaming/TestMultipleChunks.java
! test/jdk/jdk/jfr/jmx/streaming/TestNew.java
! test/jdk/jdk/jfr/jmx/streaming/TestRotate.java
! test/jdk/jdk/jfr/jmx/streaming/TestSetSettings.java
! test/jdk/jdk/jfr/jmx/streaming/TestStart.java
! test/jdk/jdk/jfr/jmx/streaming/TestStop.java
! test/jdk/jdk/jfr/jvm/TestChunkIntegrity.java
! test/jdk/jdk/jfr/jvm/TestFatEvent.java
! test/jdk/jdk/jfr/jvm/TestHiddenWait.java
! test/jdk/jdk/jfr/jvm/TestLongStringsInPool.java
! test/jdk/jdk/jfr/jvm/TestVerifyInstrumentation.java
! test/jdk/jdk/jfr/startupargs/TestPreserveRepository.java
! test/jdk/jdk/jfr/startupargs/TestStartHelp.java
! test/jdk/jdk/jfr/startupargs/TestStartupOptionSpecifiedOnce.java
! test/jdk/jdk/jfr/threading/TestStringPoolVirtualThreadPinning.java
! test/jdk/jdk/jfr/tool/TestConfigure.java
! test/jdk/jdk/jfr/tool/TestView.java

Changeset: e7f9132e
Branch: master
Author:    Alexey Ivanov <aivanov at openjdk.org>
Date:      2025-12-26 20:12:15 +0000
URL:       https://git.openjdk.org/loom/commit/e7f9132e8992ac281d1e4777a9664d1c8b817f4f

8374345: Restore the original copyright year in ExtremeFontSizeTest.java

Reviewed-by: serb, syan

! test/jdk/java/awt/FontMetrics/ExtremeFontSizeTest.java

Changeset: 5c694eab
Branch: master
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2025-12-27 04:45:56 +0000
URL:       https://git.openjdk.org/loom/commit/5c694eab0f48045d2f71d0cd5ab53c1daddaa963

8374363: Update copyright year to 2025 for test/micro in files where it was missed

Reviewed-by: phh

! test/micro/org/openjdk/bench/java/lang/foreign/AllocFromSliceTest.java
! test/micro/org/openjdk/bench/java/util/ImmutableColls.java
! test/micro/org/openjdk/bench/vm/compiler/MergeStoreBench.java
! test/micro/org/openjdk/bench/vm/gc/systemgc/AllDead.java
! test/micro/org/openjdk/bench/vm/gc/systemgc/AllLive.java
! test/micro/org/openjdk/bench/vm/gc/systemgc/DifferentObjectSizesArray.java
! test/micro/org/openjdk/bench/vm/gc/systemgc/DifferentObjectSizesHashMap.java
! test/micro/org/openjdk/bench/vm/gc/systemgc/DifferentObjectSizesTreeMap.java
! test/micro/org/openjdk/bench/vm/gc/systemgc/HalfDeadFirstPart.java
! test/micro/org/openjdk/bench/vm/gc/systemgc/HalfDeadInterleaved.java
! test/micro/org/openjdk/bench/vm/gc/systemgc/HalfDeadInterleavedChunks.java
! test/micro/org/openjdk/bench/vm/gc/systemgc/HalfDeadSecondPart.java
! test/micro/org/openjdk/bench/vm/gc/systemgc/HalfHashedHalfDead.java
! test/micro/org/openjdk/bench/vm/gc/systemgc/NoObjects.java
! test/micro/org/openjdk/bench/vm/gc/systemgc/OneBigObject.java

Changeset: 2886c3b6
Branch: master
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2025-12-27 04:56:04 +0000
URL:       https://git.openjdk.org/loom/commit/2886c3b68a8d4b098f7d093f0406d2a15e5910dc

8374358: Update copyright year to 2025 for test/hotspot in files where it was missed

Reviewed-by: phh

! test/hotspot/jtreg/TEST.quick-groups
! test/hotspot/jtreg/applications/jcstress/TestGenerator.java
! test/hotspot/jtreg/compiler/c2/Test7005594.java
! test/hotspot/jtreg/compiler/c2/TestReduceAllocationAndLoadKlass.java
! test/hotspot/jtreg/compiler/c2/TestReduceAllocationAndNonExactAllocate.java
! test/hotspot/jtreg/compiler/c2/TestReduceAllocationAndNullableLoads.java
! test/hotspot/jtreg/compiler/c2/irTests/TestPhiDuplicatedConversion.java
! test/hotspot/jtreg/compiler/cpuflags/TestAESIntrinsicsOnSupportedConfig.java
! test/hotspot/jtreg/compiler/cpuflags/TestAESIntrinsicsOnUnsupportedConfig.java
! test/hotspot/jtreg/compiler/escapeAnalysis/TestReduceAllocationAndNonReduciblePhi.java
! test/hotspot/jtreg/compiler/intrinsics/bmi/BMITestRunner.java
! test/hotspot/jtreg/compiler/intrinsics/math/TestMinMaxIntrinsics.java
! test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseMD5IntrinsicsOptionOnSupportedCPU.java
! test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseMD5IntrinsicsOptionOnUnsupportedCPU.java
! test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnSupportedCPU.java
! test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseSHA1IntrinsicsOptionOnUnsupportedCPU.java
! test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseSHA256IntrinsicsOptionOnUnsupportedCPU.java
! test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseSHA512IntrinsicsOptionOnUnsupportedCPU.java
! test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseSHAOptionOnSupportedCPU.java
! test/hotspot/jtreg/compiler/intrinsics/sha/cli/TestUseSHAOptionOnUnsupportedCPU.java
! test/hotspot/jtreg/compiler/intrinsics/sha/cli/testcases/GenericTestCaseForUnsupportedCPU.java
! test/hotspot/jtreg/compiler/jvmci/TestUncaughtErrorInCompileMethod.java
! test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventListener.java
! test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java
! test/hotspot/jtreg/compiler/lib/compile_framework/CompileFramework.java
! test/hotspot/jtreg/compiler/lib/ir_framework/driver/irmatching/parser/VMInfo.java
! test/hotspot/jtreg/compiler/lib/ir_framework/shared/TestFrameworkSocket.java
! test/hotspot/jtreg/compiler/loopopts/TestMissingSkeletonPredicateForIfNode.java
! test/hotspot/jtreg/compiler/loopopts/superword/TestGeneralizedReductions.java
! test/hotspot/jtreg/compiler/profiling/TestTypeProfiling.java
! test/hotspot/jtreg/compiler/vectorapi/reshape/TestVectorReinterpret.java
! test/hotspot/jtreg/compiler/vectorization/TestBufferVectorization.java
! test/hotspot/jtreg/compiler/vectorization/TestOptionVectorizeIR.java
! test/hotspot/jtreg/compiler/vectorization/TestRoundVectFloat.java
! test/hotspot/jtreg/compiler/vectorization/TestRoundVectRiscv64.java
! test/hotspot/jtreg/compiler/vectorization/runner/ArrayShiftOpTest.java
! test/hotspot/jtreg/compiler/vectorization/runner/BasicBooleanOpTest.java
! test/hotspot/jtreg/compiler/vectorization/runner/BasicByteOpTest.java
! test/hotspot/jtreg/compiler/vectorization/runner/BasicDoubleOpTest.java
! test/hotspot/jtreg/compiler/vectorization/runner/BasicIntOpTest.java
! test/hotspot/jtreg/compiler/vectorization/runner/BasicLongOpTest.java
! test/hotspot/jtreg/compiler/vectorization/runner/LoopLiveOutNodesTest.java
! test/hotspot/jtreg/compiler/vectorization/runner/LoopRangeStrideTest.java
! test/hotspot/jtreg/compiler/vectorization/runner/MultipleLoopsTest.java
! test/hotspot/jtreg/gc/arguments/TestMinInitialErgonomics.java
! test/hotspot/jtreg/gc/arguments/TestParallelGCErgo.java
! test/hotspot/jtreg/gc/g1/TestHumongousConcurrentStartUndo.java
! test/hotspot/jtreg/gc/g1/TestMixedGCLiveThreshold.java
! test/hotspot/jtreg/gc/g1/TestShrinkAuxiliaryDataRunner.java
! test/hotspot/jtreg/gc/g1/plab/TestPLABEvacuationFailure.java
! test/hotspot/jtreg/gc/g1/plab/lib/PLABUtils.java
! test/hotspot/jtreg/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java
! test/hotspot/jtreg/gc/stress/TestStressG1Uncommit.java
! test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherWithG1.java
! test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherWithParallel.java
! test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherWithSerial.java
! test/hotspot/jtreg/runtime/CDSCompressedKPtrs/XShareAuto.java
! test/hotspot/jtreg/runtime/CommandLine/OptionsValidation/TestJcmdOutput.java
! test/hotspot/jtreg/runtime/ErrorHandling/ShowRegistersOnAssertTest.java
! test/hotspot/jtreg/runtime/ErrorHandling/StackWalkNativeToJava.java
! test/hotspot/jtreg/runtime/Monitor/MonitorWithDeadObjectTest.java
! test/hotspot/jtreg/runtime/NMT/JcmdWithNMTDisabled.java
! test/hotspot/jtreg/runtime/StackGap/TestStackGap.java
! test/hotspot/jtreg/runtime/StackGuardPages/TestStackGuardPages.java
! test/hotspot/jtreg/runtime/TLS/TestTLS.java
! test/hotspot/jtreg/runtime/Thread/TooSmallStackSize.java
! test/hotspot/jtreg/runtime/cds/appcds/LambdaWithUseImplMethodHandle.java
! test/hotspot/jtreg/runtime/cds/appcds/LotsOfJRTClasses.java
! test/hotspot/jtreg/runtime/cds/appcds/SignedJar.java
! test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFileSafety.java
! test/hotspot/jtreg/runtime/cds/appcds/test-classes/BadLookupSwitch.jcod
! test/hotspot/jtreg/runtime/jni/atExit/libatExit.c
! test/hotspot/jtreg/runtime/jni/checked/TestLargeUTF8Length.java
! test/hotspot/jtreg/runtime/jni/daemonDestroy/TestDaemonDestroy.java
! test/hotspot/jtreg/runtime/jni/getCreatedJavaVMs/TestGetCreatedJavaVMs.java
! test/hotspot/jtreg/runtime/verifier/TraceClassRes.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbAttach.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbAttachDifferentJVMs.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbClasses.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbDumpclass.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbField.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbFlags.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbHistory.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbInspect.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbJdis.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbJstack.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbPrintAs.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbPstack.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbScanOops.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbSource.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbSymbol.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbTestAllocationMerge.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbThread.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbVmStructsDump.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbWhere.java
! test/hotspot/jtreg/serviceability/sa/DeadlockDetectionTest.java
! test/hotspot/jtreg/serviceability/sa/TestClassDump.java
! test/hotspot/jtreg/serviceability/sa/TestClhsdbJstackLock.java
! test/hotspot/jtreg/serviceability/sa/TestCpoolForInvokeDynamic.java
! test/hotspot/jtreg/serviceability/sa/TestDebugInfoDecode.java
! test/hotspot/jtreg/serviceability/sa/TestDefaultMethods.java
! test/hotspot/jtreg/serviceability/sa/TestG1HeapRegion.java
! test/hotspot/jtreg/serviceability/sa/TestHeapDumpForInvokeDynamic.java
! test/hotspot/jtreg/serviceability/sa/TestInstanceKlassSize.java
! test/hotspot/jtreg/serviceability/sa/TestInstanceKlassSizeForInterface.java
! test/hotspot/jtreg/serviceability/sa/TestIntConstant.java
! test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixed.java
! test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackPrintVMLocks.java
! test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackUpcall.java
! test/hotspot/jtreg/serviceability/sa/TestJmapCore.java
! test/hotspot/jtreg/serviceability/sa/TestJmapCoreMetaspace.java
! test/hotspot/jtreg/serviceability/sa/TestObjectMonitorIterate.java
! test/hotspot/jtreg/serviceability/sa/TestPrintMdo.java
! test/hotspot/jtreg/serviceability/sa/TestSysProps.java
! test/hotspot/jtreg/serviceability/sa/TestType.java
! test/hotspot/jtreg/serviceability/sa/UniqueVtableTest.java
! test/hotspot/jtreg/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java
! test/hotspot/jtreg/serviceability/sa/sadebugd/ClhsdbAttachToDebugServer.java
! test/hotspot/jtreg/serviceability/sa/sadebugd/ClhsdbTestConnectArgument.java
! test/hotspot/jtreg/serviceability/sa/sadebugd/DebugdConnectTest.java
! test/hotspot/jtreg/serviceability/sa/sadebugd/DisableRegistryTest.java
! test/hotspot/jtreg/testlibrary/ctw/Makefile
! test/hotspot/jtreg/testlibrary/ctw/src/sun/hotspot/tools/ctw/Compiler.java
! test/hotspot/jtreg/testlibrary/ctw/src/sun/hotspot/tools/ctw/PathHandler.java
! test/hotspot/jtreg/testlibrary/jittester/src/jdk/test/lib/jittester/visitors/ByteCodeVisitor.java
! test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestBadFormat.java
! test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/flag/TestCompilePhaseCollector.java
! test/hotspot/jtreg/testlibrary_tests/verify/tests/TestVerify.java
! test/hotspot/jtreg/vmTestbase/gc/vector/LinearListLow/TestDescription.java
! test/hotspot/jtreg/vmTestbase/jit/removal_candidates.txt
! test/hotspot/jtreg/vmTestbase/metaspace/shrink_grow/ShrinkGrowTest/ShrinkGrowTest.java
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach010/attach010Agent00.java
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC05/tc05t001/tc05t001.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA10/ma10t006/ma10t006.cpp
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/MemoryPoolMBean/isUsageThresholdExceeded/isexceeded001.java
! test/hotspot/jtreg/vmTestbase/nsk/share/gc/GC.java
! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/TestDebuggerType1.java
! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/hotswap/HotSwap.cpp
! test/hotspot/jtreg/vmTestbase/nsk/share/runner/ThreadsRunner.java
! test/hotspot/jtreg/vmTestbase/nsk/share/test/Stresser.java
! test/hotspot/jtreg/vmTestbase/nsk/stress/jni/libjnistress007.cpp
! test/hotspot/jtreg/vmTestbase/vm/jit/LongTransitions/JniArmHFTestGenerator.java.txt

Changeset: 9512a43e
Branch: master
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2025-12-27 07:02:41 +0000
URL:       https://git.openjdk.org/loom/commit/9512a43e82652be7294338c11cc9ffb0f0324b92

8374365: Update copyright year to 2025 for test/jdk in files where it was missed

Reviewed-by: phh

! test/jdk/com/sun/net/httpserver/simpleserver/CustomFileSystemTest.java
! test/jdk/java/beans/Introspector/4520754/Test4520754.java
! test/jdk/java/beans/Performance/TestIntrospector.java
! test/jdk/java/beans/PropertyChangeSupport/Test4682386.java
! test/jdk/java/foreign/TestMemoryAlignment.java
! test/jdk/java/foreign/TestUpcallStructScope.java
! test/jdk/java/foreign/libTest4BAlignedDouble.c
! test/jdk/java/foreign/libTestUpcallStructScope.c
! test/jdk/java/io/File/libGetXSpace.c
! test/jdk/java/io/pathNames/win32/DriveOnly.java
! test/jdk/java/lang/Class/getEnclosingClass/EnclosingClass.java
! test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java
! test/jdk/java/lang/Class/getEnclosingClass/common/TestMe.java
! test/jdk/java/lang/ProcessBuilder/FDLeakTest/exeFDLeakTester.c
! test/jdk/java/lang/ScopedValue/ManyBindings.java
! test/jdk/java/lang/ScopedValue/ScopedValueAPI.java
! test/jdk/java/lang/System/PropertyTest.java
! test/jdk/java/lang/System/i18nEnvArg.java
! test/jdk/java/lang/module/ClassFileVersionsTest.java
! test/jdk/java/lang/module/ModuleDescriptorTest.java
! test/jdk/java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java
! test/jdk/java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java
! test/jdk/java/net/URL/OpenStream.java
! test/jdk/java/net/httpclient/altsvc/altsvc-dns-hosts.txt
! test/jdk/java/nio/channels/FileChannel/directio/DirectIOTest.java
! test/jdk/java/nio/channels/FileChannel/directio/libDirectIO.c
! test/jdk/java/nio/file/Path/UriImportExport.java
! test/jdk/java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java
! test/jdk/java/nio/file/spi/CustomSystemClassLoader.java
! test/jdk/java/nio/file/spi/SetDefaultProvider.java
! test/jdk/java/security/KeyFactory/KeyFactoryGetKeySpecForInvalidSpec.java
! test/jdk/java/time/tck/java/time/TCKInstant.java
! test/jdk/java/util/Collections/T5078378.java
! test/jdk/java/util/List/ListFactories.java
! test/jdk/java/util/Locale/LocaleProvidersFormat.java
! test/jdk/java/util/concurrent/CompletableFuture/CompletableFutureOrTimeoutExceptionallyTest.java
! test/jdk/java/util/concurrent/Executors/AutoShutdown.java
! test/jdk/java/util/concurrent/forkjoin/Starvation.java
! test/jdk/java/util/concurrent/locks/StampedLock/OOMEInStampedLock.java
! test/jdk/java/util/regex/TestCases.txt
! test/jdk/java/util/stream/GathererTest.java
! test/jdk/java/util/zip/CloseInflaterDeflaterTest.java
! test/jdk/java/util/zip/DeflaterClose.java
! test/jdk/java/util/zip/InflaterClose.java
! test/jdk/java/util/zip/TotalInOut.java
! test/jdk/javax/management/security/HashedPasswordFileTest.java
! test/jdk/javax/net/ssl/SSLSocket/Tls13PacketSize.java
! test/jdk/javax/net/ssl/Stapling/StapleEnableProps.java
! test/jdk/jdk/incubator/vector/gen-template.sh
! test/jdk/jdk/incubator/vector/templates/Unit-header.template
! test/jdk/jdk/internal/platform/docker/TestSystemMetrics.java
! test/jdk/jdk/internal/platform/docker/TestUseContainerSupport.java
! test/jdk/jdk/modules/etc/DefaultModules.java
! test/jdk/jni/nullCaller/NullCallerTest.java
! test/jdk/performance/client/SwingMark/src/AbstractSwingTest.java
! test/jdk/performance/client/SwingMark/src/JMTest_01.java
! test/jdk/performance/client/SwingMark/src/JMTest_02.java
! test/jdk/performance/client/SwingMark/src/JMTest_03.java
! test/jdk/performance/client/SwingMark/src/JMTest_04.java
! test/jdk/performance/client/SwingMark/src/JMTest_05.java
! test/jdk/performance/client/SwingMark/src/MenuTest.java
! test/jdk/performance/client/SwingMark/src/TypingTest.java
! test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/button/resources/ButtonDemo.html
! test/jdk/sun/awt/font/TestArabicHebrew.java
! test/jdk/sun/security/provider/FileInputStreamPool/FileInputStreamPoolTest.java
! test/jdk/tools/jimage/ImageReaderDuplicateChildNodesTest.java
! test/jdk/tools/jlink/SnippetsTest.java
! test/jdk/tools/jpackage/helpers-test/jdk/jpackage/test/JavaAppDescTest.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/Annotations.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/AppImageFile.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/LauncherAsServiceVerifier.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/RunnablePackageTest.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/DefaultBundlingEnvironmentTest.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/OverridableResourceTest.java
! test/jdk/tools/jpackage/windows/WinRenameTest.java
! test/jdk/tools/launcher/JniInvocationTest.java

Changeset: 5e685f6f
Branch: master
Author:    Anjian Wen <wenanjian at openjdk.org>
Date:      2025-12-28 09:13:09 +0000
URL:       https://git.openjdk.org/loom/commit/5e685f6f2c7872a4239ef0c0a0afa60f4526529e

8374351: RISC-V: Small refactoring for crypto macro-assembler routines

Reviewed-by: fyang, fjiang

! src/hotspot/cpu/riscv/stubGenerator_riscv.cpp

Changeset: 078e71f4
Branch: master
Author:    Kirill Shirokov <kirshiro at amazon.com>
Committer: Xiaolong Peng <xpeng at openjdk.org>
Date:      2025-12-29 21:09:41 +0000
URL:       https://git.openjdk.org/loom/commit/078e71f4a3d68d298ab3c383e46d18912e1de7db

8344345: test/hotspot/gtest/x86/x86-asmtest.py has trailing whitespaces

Reviewed-by: phh, lmesnik

! test/hotspot/gtest/x86/x86-asmtest.py

Changeset: 92c6799b
Branch: master
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2025-12-29 21:20:59 +0000
URL:       https://git.openjdk.org/loom/commit/92c6799b401eb786949e88cd7142002b2a875ce0

8374361: Update copyright year to 2025 for jdk.hotspot.agent in files where it was missed

Reviewed-by: phh

! src/jdk.hotspot.agent/linux/native/libsaproc/LinuxDebuggerLocal.cpp
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/HSDB.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/HotSpotAgent.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/Debugger.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/bsd/BsdThreadContextFactory.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/LinuxThreadContextFactory.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerClient.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebugger.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebuggerLocal.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/StackValueCollection.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64CurrentFrameGuess.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64RegisterMap.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/bsd_amd64/BsdAMD64JavaThreadPDAccess.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/linux_amd64/LinuxAMD64JavaThreadPDAccess.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/win32_amd64/Win32AMD64JavaThreadPDAccess.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/ui/AnnotatedMemoryPanel.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/PlatformInfo.java
! src/jdk.hotspot.agent/windows/native/libsaproc/sawindbg.cpp

Changeset: 08450f2c
Branch: master
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2025-12-30 07:01:49 +0000
URL:       https://git.openjdk.org/loom/commit/08450f2c4d447c42a2ca8222d162ae3d2d25268a

8374326: Update copyright year to 2025 for jdk.jpackage in files where it was missed

Reviewed-by: phh

! src/jdk.jpackage/linux/native/libapplauncher/LinuxLauncherLib.cpp
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacPkgInstallerScripts.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/ResourceLocator.java
! src/jdk.jpackage/share/native/applauncher/PackageFile.cpp
! src/jdk.jpackage/share/native/common/Dll.h
! src/jdk.jpackage/share/native/common/app.cpp
! src/jdk.jpackage/share/native/common/tstrings.cpp
! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixLauncherAsService.java
! src/jdk.jpackage/windows/native/common/MsiUtils.h
! src/jdk.jpackage/windows/native/libjpackage/VersionInfo.cpp
! src/jdk.jpackage/windows/native/libmsica/Version.cpp
! src/jdk.jpackage/windows/native/libmsica/Version.h
! src/jdk.jpackage/windows/native/libmsica/libmsica.cpp

Changeset: e4e923a1
Branch: master
Author:    Martin Doerr <mdoerr at openjdk.org>
Date:      2025-12-30 09:49:05 +0000
URL:       https://git.openjdk.org/loom/commit/e4e923a1ffc8ff059c983c7e9201d0ee3273482d

8374195: TestReplaceNarrowPhiWithBottomPhi fails on ppc64 platforms in (fast)debug

Reviewed-by: mbaesken, jbechberger

! test/hotspot/jtreg/compiler/c2/TestReplaceNarrowPhiWithBottomPhi.java

Changeset: a6462d64
Branch: master
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2025-12-30 12:08:36 +0000
URL:       https://git.openjdk.org/loom/commit/a6462d641cba004829f9136df22f3d953c0e0c5d

8374316: Update copyright year to 2025 for hotspot in files where it was missed

Reviewed-by: kbarrett

! src/hotspot/cpu/aarch64/assembler_aarch64.inline.hpp
! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.hpp
! src/hotspot/cpu/aarch64/continuationHelper_aarch64.inline.hpp
! src/hotspot/cpu/aarch64/gc/shared/barrierSetAssembler_aarch64.hpp
! src/hotspot/cpu/aarch64/gc/shared/cardTableBarrierSetAssembler_aarch64.hpp
! src/hotspot/cpu/aarch64/gc/z/zBarrierSetAssembler_aarch64.hpp
! src/hotspot/cpu/aarch64/gc/z/z_aarch64.ad
! src/hotspot/cpu/aarch64/javaFrameAnchor_aarch64.hpp
! src/hotspot/cpu/aarch64/methodHandles_aarch64.hpp
! src/hotspot/cpu/aarch64/register_aarch64.hpp
! src/hotspot/cpu/aarch64/smallRegisterMap_aarch64.inline.hpp
! src/hotspot/cpu/aarch64/stackChunkFrameStream_aarch64.inline.hpp
! src/hotspot/cpu/arm/assembler_arm_32.hpp
! src/hotspot/cpu/arm/c1_Defs_arm.hpp
! src/hotspot/cpu/arm/c1_LIRAssembler_arm.hpp
! src/hotspot/cpu/arm/continuationFreezeThaw_arm.inline.hpp
! src/hotspot/cpu/arm/gc/shared/cardTableBarrierSetAssembler_arm.hpp
! src/hotspot/cpu/arm/interp_masm_arm.hpp
! src/hotspot/cpu/arm/matcher_arm.hpp
! src/hotspot/cpu/arm/smallRegisterMap_arm.inline.hpp
! src/hotspot/cpu/arm/stackChunkFrameStream_arm.inline.hpp
! src/hotspot/cpu/arm/stubRoutines_arm.hpp
! src/hotspot/cpu/arm/vmreg_arm.hpp
! src/hotspot/cpu/arm/vmreg_arm.inline.hpp
! src/hotspot/cpu/ppc/c1_Defs_ppc.hpp
! src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.hpp
! src/hotspot/cpu/ppc/continuationFreezeThaw_ppc.inline.hpp
! src/hotspot/cpu/ppc/continuationHelper_ppc.inline.hpp
! src/hotspot/cpu/ppc/gc/shared/barrierSetAssembler_ppc.hpp
! src/hotspot/cpu/ppc/gc/shared/cardTableBarrierSetAssembler_ppc.hpp
! src/hotspot/cpu/ppc/smallRegisterMap_ppc.inline.hpp
! src/hotspot/cpu/ppc/stackChunkFrameStream_ppc.inline.hpp
! src/hotspot/cpu/riscv/assembler_riscv.inline.hpp
! src/hotspot/cpu/riscv/c1_Defs_riscv.hpp
! src/hotspot/cpu/riscv/c1_LIRAssembler_riscv.hpp
! src/hotspot/cpu/riscv/codeBuffer_riscv.hpp
! src/hotspot/cpu/riscv/continuationFreezeThaw_riscv.inline.hpp
! src/hotspot/cpu/riscv/continuationHelper_riscv.inline.hpp
! src/hotspot/cpu/riscv/gc/shared/barrierSetAssembler_riscv.hpp
! src/hotspot/cpu/riscv/gc/shared/cardTableBarrierSetAssembler_riscv.hpp
! src/hotspot/cpu/riscv/gc/z/z_riscv.ad
! src/hotspot/cpu/riscv/interp_masm_riscv.hpp
! src/hotspot/cpu/riscv/javaFrameAnchor_riscv.hpp
! src/hotspot/cpu/riscv/matcher_riscv.hpp
! src/hotspot/cpu/riscv/methodHandles_riscv.hpp
! src/hotspot/cpu/riscv/riscv_b.ad
! src/hotspot/cpu/riscv/smallRegisterMap_riscv.inline.hpp
! src/hotspot/cpu/riscv/stackChunkFrameStream_riscv.inline.hpp
! src/hotspot/cpu/riscv/stubRoutines_riscv.hpp
! src/hotspot/cpu/s390/assembler_s390.inline.hpp
! src/hotspot/cpu/s390/c1_Defs_s390.hpp
! src/hotspot/cpu/s390/c1_FrameMap_s390.hpp
! src/hotspot/cpu/s390/continuationFreezeThaw_s390.inline.hpp
! src/hotspot/cpu/s390/disassembler_s390.cpp
! src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.hpp
! src/hotspot/cpu/s390/gc/shared/cardTableBarrierSetAssembler_s390.hpp
! src/hotspot/cpu/s390/interp_masm_s390.hpp
! src/hotspot/cpu/s390/javaFrameAnchor_s390.hpp
! src/hotspot/cpu/s390/matcher_s390.hpp
! src/hotspot/cpu/s390/smallRegisterMap_s390.inline.hpp
! src/hotspot/cpu/s390/stackChunkFrameStream_s390.inline.hpp
! src/hotspot/cpu/s390/stubRoutines_s390.hpp
! src/hotspot/cpu/x86/assembler_x86.inline.hpp
! src/hotspot/cpu/x86/c1_Defs_x86.hpp
! src/hotspot/cpu/x86/c1_FrameMap_x86.hpp
! src/hotspot/cpu/x86/c1_LIRAssembler_x86.hpp
! src/hotspot/cpu/x86/c1_LinearScan_x86.hpp
! src/hotspot/cpu/x86/continuationHelper_x86.inline.hpp
! src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.hpp
! src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.hpp
! src/hotspot/cpu/x86/gc/z/zBarrierSetAssembler_x86.hpp
! src/hotspot/cpu/x86/gc/z/z_x86_64.ad
! src/hotspot/cpu/x86/icache_x86.hpp
! src/hotspot/cpu/x86/interpreterRT_x86.hpp
! src/hotspot/cpu/x86/matcher_x86.hpp
! src/hotspot/cpu/x86/methodHandles_x86.hpp
! src/hotspot/cpu/x86/nativeInst_x86.hpp
! src/hotspot/cpu/x86/peephole_x86_64.hpp
! src/hotspot/cpu/x86/rdtsc_x86.hpp
! src/hotspot/cpu/x86/smallRegisterMap_x86.inline.hpp
! src/hotspot/cpu/x86/stackChunkFrameStream_x86.inline.hpp
! src/hotspot/cpu/x86/stubRoutines_x86.hpp
! src/hotspot/cpu/zero/assembler_zero.inline.hpp
! src/hotspot/cpu/zero/continuationFreezeThaw_zero.inline.hpp
! src/hotspot/cpu/zero/icache_zero.hpp
! src/hotspot/cpu/zero/smallRegisterMap_zero.inline.hpp
! src/hotspot/cpu/zero/stackChunkFrameStream_zero.inline.hpp
! src/hotspot/cpu/zero/stubRoutines_zero.hpp
! src/hotspot/os/aix/libodm_aix.cpp
! src/hotspot/os/aix/libperfstat_aix.hpp
! src/hotspot/os/aix/osThread_aix.hpp
! src/hotspot/os/aix/os_aix.hpp
! src/hotspot/os/linux/gc/z/zSyscall_linux.hpp
! src/hotspot/os/linux/os_linux.hpp
! src/hotspot/os/linux/os_linux.inline.hpp
! src/hotspot/os/linux/procMapsParser.hpp
! src/hotspot/os/posix/include/jvm_md.h
! src/hotspot/os/posix/signals_posix.hpp
! src/hotspot/os/posix/threadLocalStorage_posix.cpp
! src/hotspot/os/windows/gc/z/zSyscall_windows.hpp
! src/hotspot/os/windows/os_windows.hpp
! src/hotspot/os/windows/safefetch_windows.hpp
! src/hotspot/os_cpu/bsd_aarch64/icache_bsd_aarch64.hpp
! src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.S
! src/hotspot/os_cpu/linux_aarch64/copy_linux_aarch64.S
! src/hotspot/os_cpu/linux_aarch64/icache_linux_aarch64.hpp
! src/hotspot/os_cpu/linux_aarch64/safefetch_linux_aarch64.S
! src/hotspot/os_cpu/linux_aarch64/threadLS_linux_aarch64.S
! src/hotspot/os_cpu/linux_ppc/gc/z/zSyscall_linux_ppc.hpp
! src/hotspot/os_cpu/linux_riscv/orderAccess_linux_riscv.hpp
! src/hotspot/os_cpu/windows_aarch64/icache_windows_aarch64.hpp
! src/hotspot/share/adlc/adlc.hpp
! src/hotspot/share/adlc/adlparse.hpp
! src/hotspot/share/asm/assembler.hpp
! src/hotspot/share/c1/c1_Canonicalizer.hpp
! src/hotspot/share/c1/c1_Defs.hpp
! src/hotspot/share/c1/c1_GraphBuilder.hpp
! src/hotspot/share/c1/c1_Instruction.hpp
! src/hotspot/share/c1/c1_InstructionPrinter.hpp
! src/hotspot/share/c1/c1_LinearScan.hpp
! src/hotspot/share/c1/c1_Optimizer.hpp
! src/hotspot/share/c1/c1_RangeCheckElimination.hpp
! src/hotspot/share/cds/aotClassLinker.hpp
! src/hotspot/share/cds/aotMappedHeapLoader.inline.hpp
! src/hotspot/share/cds/aotStreamedHeapLoader.hpp
! src/hotspot/share/cds/aotThread.cpp
! src/hotspot/share/cds/lambdaFormInvokers.inline.hpp
! src/hotspot/share/ci/bcEscapeAnalyzer.hpp
! src/hotspot/share/ci/ciEnv.hpp
! src/hotspot/share/ci/ciInstance.hpp
! src/hotspot/share/ci/ciMetadata.hpp
! src/hotspot/share/ci/ciTypeFlow.hpp
! src/hotspot/share/ci/ciUtilities.inline.hpp
! src/hotspot/share/classfile/bytecodeAssembler.hpp
! src/hotspot/share/classfile/classLoaderDataGraph.hpp
! src/hotspot/share/classfile/classLoaderStats.hpp
! src/hotspot/share/classfile/defaultMethods.hpp
! src/hotspot/share/classfile/javaClassesImpl.hpp
! src/hotspot/share/classfile/vmClasses.hpp
! src/hotspot/share/code/codeBehaviours.hpp
! src/hotspot/share/code/codeCache.hpp
! src/hotspot/share/code/compiledIC.hpp
! src/hotspot/share/code/dependencyContext.hpp
! src/hotspot/share/compiler/abstractCompiler.hpp
! src/hotspot/share/compiler/compileLog.hpp
! src/hotspot/share/compiler/compiler_globals.hpp
! src/hotspot/share/compiler/directivesParser.hpp
! src/hotspot/share/compiler/disassembler.hpp
! src/hotspot/share/compiler/methodMatcher.hpp
! src/hotspot/share/compiler/oopMap.hpp
! src/hotspot/share/compiler/oopMap.inline.hpp
! src/hotspot/share/gc/g1/g1AllocRegion.hpp
! src/hotspot/share/gc/g1/g1AllocRegion.inline.hpp
! src/hotspot/share/gc/g1/g1Allocator.hpp
! src/hotspot/share/gc/g1/g1Allocator.inline.hpp
! src/hotspot/share/gc/g1/g1AnalyticsSequences.inline.hpp
! src/hotspot/share/gc/g1/g1CardSet.inline.hpp
! src/hotspot/share/gc/g1/g1CardSetMemory.inline.hpp
! src/hotspot/share/gc/g1/g1CollectionSet.hpp
! src/hotspot/share/gc/g1/g1CollectionSet.inline.hpp
! src/hotspot/share/gc/g1/g1CollectionSetCandidates.hpp
! src/hotspot/share/gc/g1/g1CollectionSetCandidates.inline.hpp
! src/hotspot/share/gc/g1/g1CollectionSetChooser.hpp
! src/hotspot/share/gc/g1/g1ConcurrentMarkObjArrayProcessor.inline.hpp
! src/hotspot/share/gc/g1/g1EdenRegions.hpp
! src/hotspot/share/gc/g1/g1EvacStats.hpp
! src/hotspot/share/gc/g1/g1FullGCResetMetadataTask.hpp
! src/hotspot/share/gc/g1/g1FullGCScope.hpp
! src/hotspot/share/gc/g1/g1HeapRegionAttr.hpp
! src/hotspot/share/gc/g1/g1IHOPControl.hpp
! src/hotspot/share/gc/g1/g1MonitoringSupport.hpp
! src/hotspot/share/gc/g1/g1PageBasedVirtualSpace.hpp
! src/hotspot/share/gc/g1/g1ParallelCleaning.hpp
! src/hotspot/share/gc/g1/g1RegionMarkStatsCache.hpp
! src/hotspot/share/gc/g1/g1RegionToSpaceMapper.hpp
! src/hotspot/share/gc/g1/g1RegionsOnNodes.hpp
! src/hotspot/share/gc/g1/g1RootProcessor.hpp
! src/hotspot/share/gc/g1/g1ServiceThread.hpp
! src/hotspot/share/gc/g1/g1SurvivorRegions.hpp
! src/hotspot/share/gc/g1/g1Trace.hpp
! src/hotspot/share/gc/g1/g1VMOperations.hpp
! src/hotspot/share/gc/parallel/objectStartArray.hpp
! src/hotspot/share/gc/parallel/parallel_globals.hpp
! src/hotspot/share/gc/parallel/psAdaptiveSizePolicy.hpp
! src/hotspot/share/gc/parallel/psCompactionManager.hpp
! src/hotspot/share/gc/parallel/psCompactionManager.inline.hpp
! src/hotspot/share/gc/parallel/psMemoryPool.hpp
! src/hotspot/share/gc/parallel/psOldGen.hpp
! src/hotspot/share/gc/parallel/psPromotionLAB.hpp
! src/hotspot/share/gc/parallel/psPromotionManager.hpp
! src/hotspot/share/gc/parallel/psScavenge.hpp
! src/hotspot/share/gc/parallel/psVMOperations.hpp
! src/hotspot/share/gc/parallel/psVirtualspace.hpp
! src/hotspot/share/gc/parallel/psYoungGen.hpp
! src/hotspot/share/gc/parallel/spaceCounters.hpp
! src/hotspot/share/gc/parallel/vmStructs_parallelgc.hpp
! src/hotspot/share/gc/serial/cSpaceCounters.hpp
! src/hotspot/share/gc/serial/defNewGeneration.hpp
! src/hotspot/share/gc/serial/serialVMOperations.hpp
! src/hotspot/share/gc/serial/tenuredGeneration.hpp
! src/hotspot/share/gc/serial/tenuredGeneration.inline.hpp
! src/hotspot/share/gc/shared/adaptiveSizePolicy.hpp
! src/hotspot/share/gc/shared/barrierSet.hpp
! src/hotspot/share/gc/shared/barrierSetConfig.hpp
! src/hotspot/share/gc/shared/barrierSetConfig.inline.hpp
! src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.hpp
! src/hotspot/share/gc/shared/cardTableBarrierSet.hpp
! src/hotspot/share/gc/shared/collectedHeap.inline.hpp
! src/hotspot/share/gc/shared/collectorCounters.hpp
! src/hotspot/share/gc/shared/gcArguments.hpp
! src/hotspot/share/gc/shared/gcCause.hpp
! src/hotspot/share/gc/shared/gcHeapSummary.hpp
! src/hotspot/share/gc/shared/gcLocker.hpp
! src/hotspot/share/gc/shared/gcLogPrecious.hpp
! src/hotspot/share/gc/shared/gcPolicyCounters.hpp
! src/hotspot/share/gc/shared/gcThreadLocalData.hpp
! src/hotspot/share/gc/shared/gcTrace.hpp
! src/hotspot/share/gc/shared/gcVMOperations.hpp
! src/hotspot/share/gc/shared/genArguments.hpp
! src/hotspot/share/gc/shared/hSpaceCounters.hpp
! src/hotspot/share/gc/shared/oopStorage.hpp
! src/hotspot/share/gc/shared/parallelCleaning.hpp
! src/hotspot/share/gc/shared/partialArraySplitter.hpp
! src/hotspot/share/gc/shared/referenceProcessor.hpp
! src/hotspot/share/gc/shared/scavengableNMethods.hpp
! src/hotspot/share/gc/shared/stringdedup/stringDedup.hpp
! src/hotspot/share/gc/shared/stringdedup/stringDedupStat.hpp
! src/hotspot/share/gc/shared/stringdedup/stringDedupThread.hpp
! src/hotspot/share/gc/shared/threadLocalAllocBuffer.hpp
! src/hotspot/share/gc/shared/vmStructs_gc.hpp
! src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.hpp
! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp
! src/hotspot/share/gc/z/zArguments.hpp
! src/hotspot/share/gc/z/zBarrier.hpp
! src/hotspot/share/gc/z/zBarrierSet.hpp
! src/hotspot/share/gc/z/zBarrierSetNMethod.hpp
! src/hotspot/share/gc/z/zGeneration.hpp
! src/hotspot/share/gc/z/zGlobals.hpp
! src/hotspot/share/gc/z/zHeapIterator.hpp
! src/hotspot/share/gc/z/zMark.hpp
! src/hotspot/share/gc/z/zMark.inline.hpp
! src/hotspot/share/gc/z/zMarkContext.hpp
! src/hotspot/share/gc/z/zMarkContext.inline.hpp
! src/hotspot/share/gc/z/zNMethod.hpp
! src/hotspot/share/gc/z/zNMethodTableIteration.hpp
! src/hotspot/share/gc/z/zPageTable.hpp
! src/hotspot/share/gc/z/zRemembered.hpp
! src/hotspot/share/gc/z/zStat.hpp
! src/hotspot/share/gc/z/zThreadLocalData.hpp
! src/hotspot/share/gc/z/zUncoloredRoot.hpp
! src/hotspot/share/include/jmm.h
! src/hotspot/share/include/jvm_io.h
! src/hotspot/share/interpreter/bytecode.hpp
! src/hotspot/share/interpreter/bytecode.inline.hpp
! src/hotspot/share/interpreter/bytecodeHistogram.hpp
! src/hotspot/share/interpreter/bytecodeStream.hpp
! src/hotspot/share/interpreter/bytecodeTracer.hpp
! src/hotspot/share/interpreter/interpreter.hpp
! src/hotspot/share/interpreter/interpreterRuntime.hpp
! src/hotspot/share/interpreter/linkResolver.hpp
! src/hotspot/share/interpreter/templateInterpreter.hpp
! src/hotspot/share/interpreter/templateInterpreterGenerator.hpp
! src/hotspot/share/interpreter/zero/bytecodeInterpreter.hpp
! src/hotspot/share/interpreter/zero/bytecodeInterpreter.inline.hpp
! src/hotspot/share/interpreter/zero/zeroInterpreter.hpp
! src/hotspot/share/interpreter/zero/zeroInterpreterGenerator.hpp
! src/hotspot/share/jfr/leakprofiler/chains/dfsClosure.hpp
! src/hotspot/share/jfr/leakprofiler/chains/edgeQueue.hpp
! src/hotspot/share/jfr/leakprofiler/checkpoint/eventEmitter.hpp
! src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.hpp
! src/hotspot/share/jfr/leakprofiler/sampling/objectSample.hpp
! src/hotspot/share/jfr/metadata/jfrSerializer.hpp
! src/hotspot/share/jfr/recorder/jfrEventSetting.hpp
! src/hotspot/share/jfr/recorder/stacktrace/jfrStackFilterRegistry.hpp
! src/hotspot/share/jfr/recorder/storage/jfrStorageUtils.hpp
! src/hotspot/share/jfr/recorder/stringpool/jfrStringPoolWriter.hpp
! src/hotspot/share/jfr/support/jfrDeprecationEventWriter.hpp
! src/hotspot/share/jfr/support/jfrDeprecationManager.hpp
! src/hotspot/share/jfr/support/jfrObjectAllocationSample.hpp
! src/hotspot/share/jfr/support/jfrStackTraceMark.hpp
! src/hotspot/share/jfr/utilities/jfrBigEndian.hpp
! src/hotspot/share/jfr/utilities/jfrDoublyLinkedList.hpp
! src/hotspot/share/jfr/utilities/jfrEpochQueue.inline.hpp
! src/hotspot/share/jfr/utilities/jfrRelation.hpp
! src/hotspot/share/jfr/writers/jfrMemoryWriterHost.hpp
! src/hotspot/share/jfr/writers/jfrMemoryWriterHost.inline.hpp
! src/hotspot/share/jfr/writers/jfrStreamWriterHost.inline.hpp
! src/hotspot/share/jvmci/jvmci.hpp
! src/hotspot/share/jvmci/jvmciEnv.hpp
! src/hotspot/share/jvmci/jvmci_globals.hpp
! src/hotspot/share/jvmci/vmSymbols_jvmci.hpp
! src/hotspot/share/libadt/vectset.hpp
! src/hotspot/share/logging/log.hpp
! src/hotspot/share/logging/logConfiguration.hpp
! src/hotspot/share/logging/logDecorators.hpp
! src/hotspot/share/memory/heapInspection.hpp
! src/hotspot/share/memory/iterator.hpp
! src/hotspot/share/memory/memoryReserver.hpp
! src/hotspot/share/memory/metaspace/metablock.inline.hpp
! src/hotspot/share/memory/resourceArea.inline.hpp
! src/hotspot/share/nmt/mallocHeader.hpp
! src/hotspot/share/nmt/mallocHeader.inline.hpp
! src/hotspot/share/nmt/nativeCallStackPrinter.hpp
! src/hotspot/share/oops/access.hpp
! src/hotspot/share/oops/access.inline.hpp
! src/hotspot/share/oops/instanceClassLoaderKlass.hpp
! src/hotspot/share/oops/instanceMirrorKlass.hpp
! src/hotspot/share/oops/instanceRefKlass.hpp
! src/hotspot/share/oops/instanceStackChunkKlass.hpp
! src/hotspot/share/oops/metadata.hpp
! src/hotspot/share/oops/oopCast.inline.hpp
! src/hotspot/share/oops/oopHandle.inline.hpp
! src/hotspot/share/oops/stackChunkOop.hpp
! src/hotspot/share/oops/weakHandle.inline.hpp
! src/hotspot/share/opto/callGenerator.hpp
! src/hotspot/share/opto/countbitsnode.hpp
! src/hotspot/share/opto/escape.hpp
! src/hotspot/share/opto/graphKit.hpp
! src/hotspot/share/opto/idealKit.hpp
! src/hotspot/share/opto/indexSet.hpp
! src/hotspot/share/opto/intrinsicnode.hpp
! src/hotspot/share/opto/multnode.hpp
! src/hotspot/share/opto/stringopts.hpp
! src/hotspot/share/opto/superwordVTransformBuilder.hpp
! src/hotspot/share/prims/foreignGlobals.inline.hpp
! src/hotspot/share/prims/jvmtiAgent.hpp
! src/hotspot/share/prims/jvmtiEventController.inline.hpp
! src/hotspot/share/prims/jvmtiImpl.hpp
! src/hotspot/share/prims/jvmtiTagMapTable.hpp
! src/hotspot/share/prims/jvmtiThreadState.inline.hpp
! src/hotspot/share/prims/methodHandles.hpp
! src/hotspot/share/prims/vectorSupport.hpp
! src/hotspot/share/prims/vmstorage.hpp
! src/hotspot/share/runtime/continuationHelper.inline.hpp
! src/hotspot/share/runtime/continuationJavaClasses.hpp
! src/hotspot/share/runtime/continuationWrapper.inline.hpp
! src/hotspot/share/runtime/flags/flagSetting.hpp
! src/hotspot/share/runtime/flags/jvmFlagLookup.hpp
! src/hotspot/share/runtime/handles.hpp
! src/hotspot/share/runtime/handles.inline.hpp
! src/hotspot/share/runtime/icache.hpp
! src/hotspot/share/runtime/interfaceSupport.inline.hpp
! src/hotspot/share/runtime/java.hpp
! src/hotspot/share/runtime/jfieldIDWorkaround.hpp
! src/hotspot/share/runtime/monitorDeflationThread.hpp
! src/hotspot/share/runtime/notificationThread.hpp
! src/hotspot/share/runtime/park.hpp
! src/hotspot/share/runtime/perfDataTypes.hpp
! src/hotspot/share/runtime/safefetch.hpp
! src/hotspot/share/runtime/safepoint.hpp
! src/hotspot/share/runtime/safepointVerifiers.hpp
! src/hotspot/share/runtime/signature.cpp
! src/hotspot/share/runtime/smallRegisterMap.inline.hpp
! src/hotspot/share/runtime/stackChunkFrameStream.hpp
! src/hotspot/share/runtime/stackChunkFrameStream.inline.hpp
! src/hotspot/share/runtime/stackWatermark.hpp
! src/hotspot/share/runtime/threadIdentifier.hpp
! src/hotspot/share/runtime/vframe.hpp
! src/hotspot/share/runtime/vmOperations.hpp
! src/hotspot/share/services/gcNotifier.hpp
! src/hotspot/share/services/threadIdTable.hpp
! src/hotspot/share/utilities/elfFile.hpp
! src/hotspot/share/utilities/macros.hpp
! src/hotspot/share/utilities/nativeCallStack.hpp
! src/hotspot/share/utilities/numberSeq.hpp
! src/hotspot/share/utilities/objectBitSet.hpp
! src/hotspot/share/utilities/objectBitSet.inline.hpp
! src/hotspot/share/utilities/resizableHashTable.hpp
! src/hotspot/share/utilities/ticks.hpp
! test/hotspot/jtreg/compiler/c2/cr7200264/TestIntVect.java
! test/hotspot/jtreg/compiler/c2/irTests/LShiftINodeIdealizationTests.java
! test/hotspot/jtreg/compiler/c2/irTests/LShiftLNodeIdealizationTests.java
! test/hotspot/jtreg/compiler/c2/irTests/RShiftINodeIdealizationTests.java
! test/hotspot/jtreg/compiler/c2/irTests/RShiftLNodeIdealizationTests.java
! test/hotspot/jtreg/compiler/c2/irTests/TestConv2BExpansion.java
! test/hotspot/jtreg/compiler/c2/irTests/TestFPComparison.java
! test/hotspot/jtreg/compiler/c2/irTests/TestIfMinMax.java
! test/hotspot/jtreg/compiler/c2/irTests/TestLongRangeChecks.java
! test/hotspot/jtreg/compiler/c2/irTests/TestMinMaxIdentities.java
! test/hotspot/jtreg/compiler/c2/irTests/TestVectorizationMismatchedAccess.java
! test/hotspot/jtreg/compiler/c2/irTests/scalarReplacement/AllocationMergesTests.java
! test/hotspot/jtreg/compiler/ciReplay/InliningBase.java
! test/hotspot/jtreg/compiler/compilercontrol/commands/OptionTest.java
! test/hotspot/jtreg/compiler/escapeAnalysis/TestFindInstMemRecursion.java
! test/hotspot/jtreg/compiler/escapeAnalysis/TestIterativeEA.java
! test/hotspot/jtreg/compiler/gcbarriers/TestZGCBarrierElision.java
! test/hotspot/jtreg/compiler/intrinsics/TestCompareUnsigned.java
! test/hotspot/jtreg/compiler/intrinsics/bigInteger/TestMultiplyToLen.java
! test/hotspot/jtreg/compiler/intrinsics/bigInteger/TestShift.java
! test/hotspot/jtreg/compiler/intrinsics/bigInteger/TestSquareToLen.java
! test/hotspot/jtreg/compiler/intrinsics/bmi/verifycode/BlsiTestI.java
! test/hotspot/jtreg/compiler/intrinsics/bmi/verifycode/BlsmskTestI.java
! test/hotspot/jtreg/compiler/intrinsics/bmi/verifycode/BlsrTestI.java
! test/hotspot/jtreg/compiler/intrinsics/klass/CastNullCheckDroppingsTest.java
! test/hotspot/jtreg/compiler/intrinsics/string/TestStringIntrinsics.java
! test/hotspot/jtreg/compiler/jsr292/MHInlineTest.java
! test/hotspot/jtreg/compiler/jsr292/patches/java.base/java/lang/invoke/MethodHandleHelper.java
! test/hotspot/jtreg/compiler/jvmci/TestJVMCIPrintProperties.java
! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.runtime.test/src/jdk/vm/ci/runtime/test/TestResolvedJavaField.java
! test/hotspot/jtreg/compiler/loopopts/TestLoopPredicationDivZeroCheck.java
! test/hotspot/jtreg/compiler/loopopts/superword/TestCyclicDependency.java
! test/hotspot/jtreg/compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java
! test/hotspot/jtreg/compiler/loopopts/superword/TestMulAddS2I.java
! test/hotspot/jtreg/compiler/loopopts/superword/TestScheduleReordersScalarMemops.java
! test/hotspot/jtreg/compiler/loopopts/superword/TestUnorderedReductionPartialVectorization.java
! test/hotspot/jtreg/compiler/predicates/assertion/TestTemplateWithoutOpaqueLoopNodes.java
! test/hotspot/jtreg/compiler/splitif/TestSplitDivisionThroughPhi.java
! test/hotspot/jtreg/compiler/unsafe/OpaqueAccesses.java
! test/hotspot/jtreg/compiler/vectorization/TestFloatConversionsVectorNaN.java
! test/hotspot/jtreg/compiler/vectorization/TestReverseBitsVector.java
! test/hotspot/jtreg/compiler/vectorization/runner/LoopArrayIndexComputeTest.java
! test/hotspot/jtreg/compiler/vectorization/runner/LoopCombinedOpTest.java
! test/hotspot/jtreg/compiler/whitebox/CompilerWhiteBoxTest.java
! test/hotspot/jtreg/gc/TestPLABAdaptToMinTLABSize.java
! test/hotspot/jtreg/gc/arguments/TestMinAndInitialSurvivorRatioFlags.java
! test/hotspot/jtreg/gc/arguments/TestNewRatioFlag.java
! test/hotspot/jtreg/gc/arguments/TestNewSizeFlags.java
! test/hotspot/jtreg/gc/arguments/TestSurvivorRatioFlag.java
! test/hotspot/jtreg/gc/arguments/TestUseCompressedOopsFlagsWithUlimit.java
! test/hotspot/jtreg/gc/g1/pinnedobjs/TestPinnedOldObjectsEvacuation.java
! test/hotspot/jtreg/gc/parallel/TestDynShrinkHeap.java
! test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherWithZ.java
! test/hotspot/jtreg/gtest/AsyncLogGtest.java
! test/hotspot/jtreg/gtest/CompressedKlassGtest.java
! test/hotspot/jtreg/gtest/MetaspaceGtests.java
! test/hotspot/jtreg/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java
! test/hotspot/jtreg/runtime/CommandLine/VMOptionWarning.java
! test/hotspot/jtreg/runtime/ErrorHandling/UncaughtNativeExceptionTest.java
! test/hotspot/jtreg/runtime/ErrorHandling/libNativeException.c
! test/hotspot/jtreg/runtime/NMT/MallocRoundingReportTest.java
! test/hotspot/jtreg/runtime/NMT/MallocTestType.java
! test/hotspot/jtreg/runtime/NMT/MallocTrackingVerify.java
! test/hotspot/jtreg/runtime/NMT/ThreadedMallocTestType.java
! test/hotspot/jtreg/runtime/Safepoint/TestAbortVMOnSafepointTimeout.java
! test/hotspot/jtreg/runtime/Thread/TestAlwaysPreTouchStacks.java
! test/hotspot/jtreg/runtime/cds/ServiceLoaderTest.java
! test/hotspot/jtreg/runtime/cds/SharedStringsDedup.java
! test/hotspot/jtreg/runtime/cds/SharedStringsRunAuto.java
! test/hotspot/jtreg/runtime/cds/appcds/CreateAOTCacheVerifyError.java
! test/hotspot/jtreg/runtime/cds/appcds/TestZGCWithCDS.java
! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/ArchivedIntegerCacheTest.java
! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/ArchivedModuleWithCustomImageTest.java
! test/hotspot/jtreg/runtime/cds/appcds/customLoader/PrintSharedArchiveAndExit.java
! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/NestHostOldInf.java
! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/PrintSharedArchiveAndExit.java
! test/hotspot/jtreg/runtime/cds/appcds/jigsaw/modulepath/src/com.foos/module-info.java
! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/SharedStringsHumongous.java
! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/SharedStringsUtils.java
! test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/MyPackage/HeapMonitor.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbPrintAll.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/share/server/ServerMemoryMXBean.java

Changeset: 3fd7bde3
Branch: master
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2025-12-31 07:21:32 +0000
URL:       https://git.openjdk.org/loom/commit/3fd7bde31b965e027df423b3c2b5e1f360397195

8374378: Update copyright year to 2025 for jdk.internal.vm.ci in files where it was missed

Reviewed-by: phh

! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/code/BytecodeFrame.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/code/VirtualObject.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/code/site/Site.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/CompilerToVM.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotCompiledCode.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotCompiledCodeStream.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotCompiledNmethod.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotJavaType.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotObjectConstant.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotObjectConstantImpl.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotResolvedJavaFieldImpl.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethodImpl.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotResolvedJavaType.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotResolvedObjectType.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotSpeculationLog.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotVMConfigAccess.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/VMField.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/meta/ConstantPool.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/meta/EncodedSpeculationReason.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/meta/ResolvedJavaMethod.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/meta/ResolvedJavaType.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/services/JVMCIServiceLocator.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/services/Services.java

Changeset: 36d2c277
Branch: master
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2025-12-31 09:13:32 +0000
URL:       https://git.openjdk.org/loom/commit/36d2c277c47767ba22208e2e49c46001642bd4f5

8374327: Update copyright year to 2025 for files in java.base added/updated by commits in 2025

Reviewed-by: jpai

! src/java.base/aix/classes/sun/nio/ch/AixPollPort.java
! src/java.base/share/classes/com/sun/crypto/provider/RSACipher.java
! src/java.base/share/classes/java/lang/CharacterData00.java.template
! src/java.base/share/classes/java/lang/CharacterDataLatin1.java.template
! src/java.base/share/classes/java/lang/CharacterDataPrivateUse.java
! src/java.base/share/classes/java/lang/CharacterDataUndefined.java
! src/java.base/share/classes/java/lang/ThreadBuilders.java
! src/java.base/share/classes/java/lang/invoke/VarHandle.java
! src/java.base/share/classes/java/lang/ref/Cleaner.java
! src/java.base/share/classes/java/lang/ref/PhantomReference.java
! src/java.base/share/classes/java/lang/ref/SoftReference.java
! src/java.base/share/classes/java/lang/ref/WeakReference.java
! src/java.base/share/classes/java/lang/runtime/ExactConversionsSupport.java
! src/java.base/share/classes/java/net/Authenticator.java
! src/java.base/share/classes/java/net/doc-files/net-properties.html
! src/java.base/share/classes/java/nio/charset/Charset-X-Coder.java.template
! src/java.base/share/classes/java/security/Provider.java
! src/java.base/share/classes/java/util/Collection.java
! src/java.base/share/classes/java/util/WeakHashMap.java
! src/java.base/share/classes/java/util/jar/JarInputStream.java
! src/java.base/share/classes/java/util/jar/JarVerifier.java
! src/java.base/share/classes/java/util/stream/GathererOp.java
! src/java.base/share/classes/java/util/zip/GZIPOutputStream.java
! src/java.base/share/classes/java/util/zip/snippet-files/Snippets.java
! src/java.base/share/classes/javax/security/auth/Subject.java
! src/java.base/share/classes/jdk/internal/ValueBased.java
! src/java.base/share/classes/jdk/internal/access/JavaUtilConcurrentTLRAccess.java
! src/java.base/share/classes/jdk/internal/classfile/components/snippet-files/PackageSnippets.java
! src/java.base/share/classes/jdk/internal/foreign/abi/NativeEntryPoint.java
! src/java.base/share/classes/jdk/internal/foreign/abi/VMStorage.java
! src/java.base/share/classes/jdk/internal/icu/impl/Norm2AllModes.java
! src/java.base/share/classes/jdk/internal/icu/impl/UBiDiProps.java
! src/java.base/share/classes/jdk/internal/icu/impl/UCharacterProperty.java
! src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystem.java
! src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template
! src/java.base/share/classes/jdk/internal/module/ModuleInfo.java
! src/java.base/share/classes/sun/net/www/MimeTable.java
! src/java.base/share/classes/sun/nio/ch/ThreadPool.java
! src/java.base/share/classes/sun/nio/fs/AbstractPoller.java
! src/java.base/share/classes/sun/nio/fs/Cancellable.java
! src/java.base/share/classes/sun/nio/fs/PollingWatchService.java
! src/java.base/share/classes/sun/security/ec/ECPrivateKeyImpl.java
! src/java.base/share/classes/sun/security/rsa/RSAPadding.java
! src/java.base/share/classes/sun/security/ssl/CertStatusExtension.java
! src/java.base/share/classes/sun/security/ssl/CertificateAuthoritiesExtension.java
! src/java.base/share/classes/sun/security/ssl/CertificateStatus.java
! src/java.base/share/classes/sun/security/ssl/CookieExtension.java
! src/java.base/share/classes/sun/security/ssl/DHServerKeyExchange.java
! src/java.base/share/classes/sun/security/ssl/DTLSOutputRecord.java
! src/java.base/share/classes/sun/security/ssl/ECDHServerKeyExchange.java
! src/java.base/share/classes/sun/security/ssl/ECPointFormatsExtension.java
! src/java.base/share/classes/sun/security/ssl/EncryptedExtensions.java
! src/java.base/share/classes/sun/security/ssl/ExtendedMasterSecretExtension.java
! src/java.base/share/classes/sun/security/ssl/HandshakeOutStream.java
! src/java.base/share/classes/sun/security/ssl/HelloRequest.java
! src/java.base/share/classes/sun/security/ssl/HelloVerifyRequest.java
! src/java.base/share/classes/sun/security/ssl/MaxFragExtension.java
! src/java.base/share/classes/sun/security/ssl/NamedGroup.java
! src/java.base/share/classes/sun/security/ssl/PredefinedDHParameterSpecs.java
! src/java.base/share/classes/sun/security/ssl/PskKeyExchangeModesExtension.java
! src/java.base/share/classes/sun/security/ssl/RSAServerKeyExchange.java
! src/java.base/share/classes/sun/security/ssl/RenegoInfoExtension.java
! src/java.base/share/classes/sun/security/ssl/ServerHelloDone.java
! src/java.base/share/classes/sun/security/ssl/ServerNameExtension.java
! src/java.base/unix/classes/java/lang/ProcessImpl.java
! src/java.base/unix/classes/sun/nio/ch/FileKey.java
! src/java.base/unix/classes/sun/nio/fs/UnixFileAttributeViews.java
! src/java.base/unix/classes/sun/nio/fs/UnixFileKey.java
! src/java.base/unix/classes/sun/nio/fs/UnixFileStore.java
! src/java.base/unix/native/jspawnhelper/jspawnhelper.c
! src/java.base/unix/native/launcher/relauncher.c
! src/java.base/unix/native/libjava/locale_str.h
! src/java.base/unix/native/libnet/Inet4AddressImpl.c
! src/java.base/unix/native/libnet/NetworkInterface.c
! src/java.base/unix/native/libnet/net_util_md.h
! src/java.base/windows/classes/java/lang/ProcessImpl.java
! src/java.base/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthSequence.java
! src/java.base/windows/classes/sun/nio/ch/PipeImpl.java
! src/java.base/windows/native/launcher/relauncher.c
! src/java.base/windows/native/libnet/NTLMAuthSequence.c

Changeset: c6246d58
Branch: master
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2025-12-31 10:04:45 +0000
URL:       https://git.openjdk.org/loom/commit/c6246d58f72942b66cb0632186366f0b99402306

8374383: Update the copyright year to 2025 in the remaining files under test/ where it was missed

Reviewed-by: jpai

! test/benchmarks/micros-javac/src/main/java/org/openjdk/bench/langtools/javac/GroupJavacBenchmark.java
! test/benchmarks/micros-javac/src/main/java/org/openjdk/bench/langtools/javac/JavacBenchmark.java
! test/benchmarks/micros-javac/src/main/java/org/openjdk/bench/langtools/javac/SingleJavacBenchmark.java
! test/failure_handler/src/share/conf/mac.properties
! test/jaxp/javax/xml/jaxp/unittest/validation/ValidationTest.java
! test/jdk/java/lang/StringBuffer/ECoreIndexOf.java
! test/jdk/java/lang/Thread/virtual/YieldQueuing.java
! test/jdk/javax/management/mxbean/MXBeanInteropTest1.java
! test/jdk/jdk/incubator/vector/Byte128VectorTests.java
! test/jdk/jdk/incubator/vector/Byte256VectorTests.java
! test/jdk/jdk/incubator/vector/Byte512VectorTests.java
! test/jdk/jdk/incubator/vector/Byte64VectorTests.java
! test/jdk/jdk/incubator/vector/ByteMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Double128VectorTests.java
! test/jdk/jdk/incubator/vector/Double256VectorTests.java
! test/jdk/jdk/incubator/vector/Double512VectorTests.java
! test/jdk/jdk/incubator/vector/Double64VectorTests.java
! test/jdk/jdk/incubator/vector/DoubleMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Float128VectorTests.java
! test/jdk/jdk/incubator/vector/Float256VectorTests.java
! test/jdk/jdk/incubator/vector/Float512VectorTests.java
! test/jdk/jdk/incubator/vector/Float64VectorTests.java
! test/jdk/jdk/incubator/vector/FloatMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Int128VectorTests.java
! test/jdk/jdk/incubator/vector/Int256VectorTests.java
! test/jdk/jdk/incubator/vector/Int512VectorTests.java
! test/jdk/jdk/incubator/vector/Int64VectorTests.java
! test/jdk/jdk/incubator/vector/IntMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Long128VectorTests.java
! test/jdk/jdk/incubator/vector/Long256VectorTests.java
! test/jdk/jdk/incubator/vector/Long512VectorTests.java
! test/jdk/jdk/incubator/vector/Long64VectorTests.java
! test/jdk/jdk/incubator/vector/LongMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Short128VectorTests.java
! test/jdk/jdk/incubator/vector/Short256VectorTests.java
! test/jdk/jdk/incubator/vector/Short512VectorTests.java
! test/jdk/jdk/incubator/vector/Short64VectorTests.java
! test/jdk/jdk/incubator/vector/ShortMaxVectorTests.java
! test/jdk/jdk/internal/platform/docker/MetricsCpuTester.java
! test/jdk/jdk/jfr/event/profiling/BaseTestFullStackTrace.java
! test/jdk/jdk/jfr/event/profiling/TestCPUTimeSampleNative.java
! test/jdk/jdk/jfr/event/profiling/TestCPUTimeSamplingLongPeriod.java
! test/langtools/jdk/javadoc/doclet/testHtmlLandmarkRegions/TestHtmlLandmarkRegions.java
! test/langtools/jdk/javadoc/doclet/testHtmlVersion/TestHtmlVersion.java
! test/langtools/jdk/javadoc/doclet/testMarkdown/TestMarkdownLinks.java
! test/langtools/jdk/javadoc/doclet/testRelativeLinks/pkg/C.java
! test/langtools/jdk/javadoc/doclet/testSeeTag/TestSeeTagWithModule.java
! test/langtools/jdk/javadoc/doclet/testTitleInHref/TestTitleInHref.java
! test/langtools/jdk/javadoc/tool/modules/Modules.java
! test/langtools/jdk/jshell/Compiler.java
! test/langtools/jdk/jshell/HighlightUITest.java
! test/langtools/jdk/jshell/Presets.java
! test/langtools/tools/jdeps/listdeps/ListModuleDeps.java
! test/langtools/tools/jnativescan/TestMissingSystemClass.java
! test/langtools/tools/jnativescan/cases/classpath/missingsystem/App.java
! test/langtools/tools/lib/toolbox/JavacTask.java
! test/langtools/tools/lib/types/TypeHarness.java
! test/lib/jdk/test/lib/NetworkConfiguration.java
! test/lib/jdk/test/lib/SA/SATestUtils.java
! test/lib/jdk/test/lib/containers/docker/DockerRunOptions.java
! test/lib/jdk/test/lib/helpers/ClassFileInstaller.java
! test/lib/jdk/test/whitebox/code/CodeBlob.java
! test/make/autoconf/test.m4
! test/micro/org/openjdk/bench/java/lang/FPComparison.java
! test/micro/org/openjdk/bench/java/lang/foreign/xor/GetArrayCriticalXorOpImpl.java
! test/micro/org/openjdk/bench/java/lang/foreign/xor/GetArrayElementsXorOpImpl.java
! test/micro/org/openjdk/bench/java/lang/foreign/xor/GetArrayForeignXorOpCriticalImpl.java
! test/micro/org/openjdk/bench/java/lang/foreign/xor/GetArrayForeignXorOpImpl.java
! test/micro/org/openjdk/bench/java/lang/foreign/xor/GetArrayForeignXorOpInitImpl.java
! test/micro/org/openjdk/bench/java/lang/foreign/xor/GetArrayRegionXorOpImpl.java
! test/micro/org/openjdk/bench/java/lang/foreign/xor/XorOp.java
! test/micro/org/openjdk/bench/java/lang/foreign/xor/libjnitest.c
! test/micro/org/openjdk/bench/vm/compiler/ArrayFill.java
! test/micro/org/openjdk/bench/vm/compiler/TypeVectorOperations.java
! test/micro/org/openjdk/bench/vm/compiler/VectorAliasing.java
! test/micro/org/openjdk/bench/vm/compiler/VectorReduction2.java

Changeset: 97f4f003
Branch: master
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2025-12-31 15:50:17 +0000
URL:       https://git.openjdk.org/loom/commit/97f4f003f4de19596de7f3d40295506edaaa30af

8373917: test/hotspot/jtreg/vmTestbase/nsk/monitoring: -iterations setting misused in tests

Reviewed-by: lmesnik

! test/hotspot/jtreg/vmTestbase/nsk/share/runner/RunParams.java

Changeset: a1a75ab6
Branch: master
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2025-12-31 16:26:09 +0000
URL:       https://git.openjdk.org/loom/commit/a1a75ab6d1ca25fc88be75239670f5a011ea3053

8373642: Test vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters003/TestDescription.java failed

Reviewed-by: cjplummer, syan

! test/hotspot/jtreg/vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters001/CollectionCounters001.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters002/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters003/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters004/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters005/TestDescription.java

Changeset: 2447e071
Branch: master
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2025-12-31 17:13:17 +0000
URL:       https://git.openjdk.org/loom/commit/2447e07137b809aec9bdbb97f89b52488f5c02de

8374355: Update copyright year to 2025 for demo in files where it was missed

Reviewed-by: aivanov

! src/demo/share/java2d/J2DBench/Makefile
! src/demo/share/java2d/J2DBench/build.xml
! src/demo/share/java2d/J2DBench/src/j2dbench/report/J2DAnalyzer.java
! src/demo/share/jfc/CodePointIM/com/sun/inputmethods/internal/codepointim/CodePointInputMethodDescriptor.java
! src/demo/share/jfc/J2Ddemo/java2d/RunWindow.java
! src/demo/share/jfc/J2Ddemo/java2d/Tools.java
! src/demo/share/jfc/Stylepad/HelloWorld.java
! src/demo/share/jfc/SwingSet2/SwingSet2.java
! src/demo/share/jfc/SwingSet2/resources/swingset_de.properties

Changeset: 2d1be8a9
Branch: master
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2025-12-31 17:15:34 +0000
URL:       https://git.openjdk.org/loom/commit/2d1be8a9e66fe82b60f7a22fd7796f0e54e60a5f

8374391: Update the copyright year to 2025 in the remaining files under src/ where it was missed

Reviewed-by: aivanov

! src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java
! src/java.base/share/classes/java/lang/invoke/CallSite.java
! src/java.base/share/classes/sun/util/locale/UnicodeLocaleExtension.java
! src/java.base/share/native/libjava/VirtualThread.c
! src/java.base/share/native/libverify/check_code.c
! src/java.compiler/share/classes/javax/tools/JavaFileManager.java
! src/java.compiler/share/classes/javax/tools/StandardLocation.java
! src/java.logging/share/classes/java/util/logging/ConsoleHandler.java
! src/java.management/share/classes/javax/management/modelmbean/RequiredModelMBean.java
! src/java.management/share/classes/javax/management/remote/JMXConnectorServer.java
! src/java.management/share/classes/javax/management/remote/JMXConnectorServerMBean.java
! src/java.management/share/classes/sun/management/MemoryImpl.java
! src/java.naming/share/classes/com/sun/jndi/ldap/DefaultResponseControlFactory.java
! src/java.naming/share/classes/javax/naming/ldap/PagedResultsControl.java
! src/java.rmi/share/classes/sun/rmi/log/LogInputStream.java
! src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5InitCredential.java
! src/java.sql/share/classes/java/sql/Statement.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/LDC.java
! src/java.xml/share/classes/com/sun/org/apache/bcel/internal/generic/ReferenceType.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_de.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ja.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_CN.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_de.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ja.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_zh_CN.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_de.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_ja.java
! src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_zh_CN.java
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties
! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/regex/RegularExpression.java
! src/jdk.compiler/share/classes/com/sun/source/tree/UsesTree.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/GCCause.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/FileMapInfo.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ThreadLocalAllocBuffer.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMask.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMath.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorSpecies.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/package-info.java
! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/monitor/v1_0/PerfDataBuffer.java
! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/resources/aliasmap
! src/jdk.internal.opt/share/classes/jdk/internal/joptsimple/util/InetAddressConverter.java
! src/jdk.jcmd/share/classes/sun/tools/jstat/ExpressionExecuter.java
! src/jdk.jcmd/share/classes/sun/tools/jstat/ExpressionResolver.java
! src/jdk.jcmd/share/classes/sun/tools/jstat/Parser.java
! src/jdk.jcmd/share/classes/sun/tools/jstat/resources/jstat_options
! src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/Main.java
! src/jdk.jdi/share/classes/com/sun/tools/jdi/ThreadReferenceImpl.java
! src/jdk.jdi/windows/native/libdt_shmem/shmem_md.c
! src/jdk.jdwp.agent/windows/native/libjdwp/proc_md.h
! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/ConstantMap.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/Dispatcher.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/query/FieldBuilder.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/query/QueryResolver.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/Query.java
! src/jdk.jfr/share/man/jfr.md
! src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage.properties
! src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage_de.properties
! src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage_ja.properties
! src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage_zh_CN.properties
! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java
! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Snippets.java
! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ModuleDescriptorBuilder.java
! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/StripJavaDebugAttributesPlugin.java
! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/SystemModulesPlugin.java
! src/jdk.jlink/share/classes/jdk/tools/jmod/JmodTask.java
! src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_de.properties
! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/IOContext.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/Startup.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n.properties
! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_de.properties
! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_ja.properties
! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/resources/l10n_zh_CN.properties
! src/jdk.jshell/share/classes/jdk/internal/shellsupport/doc/JavadocHelper.java
! 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/execution/JdiDefaultExecutionControl.java
! src/utils/IdealGraphVisualizer/HierarchicalLayout/src/main/java/com/sun/hotspot/igv/hierarchicallayout/FreeInteractiveLayoutManager.java
! src/utils/IdealGraphVisualizer/HierarchicalLayout/src/main/java/com/sun/hotspot/igv/hierarchicallayout/HierarchicalLayoutManager.java
! src/utils/IdealGraphVisualizer/HierarchicalLayout/src/main/java/com/sun/hotspot/igv/hierarchicallayout/LayoutGraph.java
! src/utils/IdealGraphVisualizer/HierarchicalLayout/src/main/java/com/sun/hotspot/igv/hierarchicallayout/LayoutMover.java
! src/utils/IdealGraphVisualizer/HierarchicalLayout/src/main/java/com/sun/hotspot/igv/hierarchicallayout/LayoutNode.java
! src/utils/IdealGraphVisualizer/View/src/main/java/com/sun/hotspot/igv/view/actions/EnableFreeLayoutAction.java
! src/utils/IdealGraphVisualizer/View/src/main/java/com/sun/hotspot/igv/view/widgets/LineWidget.java
! src/utils/LogCompilation/src/main/java/com/sun/hotspot/tools/compiler/LogParser.java
! src/utils/LogCompilation/src/main/java/com/sun/hotspot/tools/compiler/MakeNotEntrantEvent.java

Changeset: 481ef1de
Branch: master
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2025-12-31 17:53:43 +0000
URL:       https://git.openjdk.org/loom/commit/481ef1de7a2721adfb8a48bb56513e617347c122

8374352: Update copyright year to 2025 for test/langtools/tools/javac/ in files where it was missed

Reviewed-by: aivanov

! test/langtools/tools/javac/6457284/T6457284.java
! test/langtools/tools/javac/OverrideChecks/InterfaceImplements.java
! test/langtools/tools/javac/OverrideChecks/InterfaceOverride.java
! test/langtools/tools/javac/OverrideChecks/T6326485.java
! test/langtools/tools/javac/T4093617/T4093617.java
! test/langtools/tools/javac/T5092545.java
! test/langtools/tools/javac/T5105890.java
! test/langtools/tools/javac/T6180021/AbstractSub.java
! test/langtools/tools/javac/T6180021/Sub.java
! test/langtools/tools/javac/T6231246/T6231246.java
! test/langtools/tools/javac/T6266772.java
! test/langtools/tools/javac/T6358024.java
! test/langtools/tools/javac/T6358166.java
! test/langtools/tools/javac/T6361619.java
! test/langtools/tools/javac/T6395974.java
! test/langtools/tools/javac/T6397286.java
! test/langtools/tools/javac/T6458823/T6458823.java
! test/langtools/tools/javac/TryWithResources/InterruptedExceptionTest.java
! test/langtools/tools/javac/TryWithResources/TwrAvoidNullCheck.java
! test/langtools/tools/javac/TryWithResources/TwrSimpleClose.java
! test/langtools/tools/javac/annotations/crash_empty_enum_const/CrashEmptyEnumConstructorTest.java
! test/langtools/tools/javac/annotations/pos/AnnotationMethods.java
! test/langtools/tools/javac/api/6400303/T6400303.java
! test/langtools/tools/javac/api/6406133/T6406133.java
! test/langtools/tools/javac/api/6410643/T6410643.java
! test/langtools/tools/javac/api/6411310/T6411310.java
! test/langtools/tools/javac/api/6411333/T6411333.java
! test/langtools/tools/javac/api/6412656/T6412656.java
! test/langtools/tools/javac/api/6415780/T6415780.java
! test/langtools/tools/javac/api/6418694/T6418694.java
! test/langtools/tools/javac/api/6420409/T6420409.java
! test/langtools/tools/javac/api/6421111/T6421111.java
! test/langtools/tools/javac/api/6421756/T6421756.java
! test/langtools/tools/javac/api/6422215/T6422215.java
! test/langtools/tools/javac/api/6422327/T6422327.java
! test/langtools/tools/javac/api/6423003/T6423003.java
! test/langtools/tools/javac/api/6431257/T6431257.java
! test/langtools/tools/javac/api/6437999/T6437999.java
! test/langtools/tools/javac/api/6440333/T6440333.java
! test/langtools/tools/javac/api/6440528/T6440528.java
! test/langtools/tools/javac/api/6452876/T6452876.java
! test/langtools/tools/javac/api/6468404/T6468404.java
! test/langtools/tools/javac/api/6471599/Main.java
! test/langtools/tools/javac/api/6731573/T6731573.java
! test/langtools/tools/javac/api/7086261/T7086261.java
! test/langtools/tools/javac/api/8007344/Test.java
! test/langtools/tools/javac/api/DiagSpans.java
! test/langtools/tools/javac/api/Sibling.java
! test/langtools/tools/javac/api/T6257235.java
! test/langtools/tools/javac/api/T6258271.java
! test/langtools/tools/javac/api/T6265137.java
! test/langtools/tools/javac/api/T6306137.java
! test/langtools/tools/javac/api/T6357331.java
! test/langtools/tools/javac/api/T6358786.java
! test/langtools/tools/javac/api/T6397104.java
! test/langtools/tools/javac/api/T6400205.java
! test/langtools/tools/javac/api/T6400207.java
! test/langtools/tools/javac/api/T6407011.java
! test/langtools/tools/javac/api/TestEvalExpression.java
! test/langtools/tools/javac/api/TestGetTree.java
! test/langtools/tools/javac/api/TestJavacTask.java
! test/langtools/tools/javac/api/TestJavacTaskScanner.java
! test/langtools/tools/javac/api/TestOperators.java
! test/langtools/tools/javac/api/TestResolveIdent.java
! test/langtools/tools/javac/api/TestTreePath.java
! test/langtools/tools/javac/api/guide/Test.java
! test/langtools/tools/javac/api/taskListeners/EventsBalancedTest.java
! test/langtools/tools/javac/boxing/T6348760.java
! test/langtools/tools/javac/cast/5043020/T5043020.java
! test/langtools/tools/javac/cast/6302214/T6302214a.java
! test/langtools/tools/javac/diags/ArgTypeCompilerFactory.java
! test/langtools/tools/javac/diags/CheckResourceKeys.java
! test/langtools/tools/javac/diags/examples/AttemptToSynchronizeOnInstanceOfVbc.java
! test/langtools/tools/javac/diags/examples/ImportModule.java
! test/langtools/tools/javac/diags/examples/ImportModuleDoesNotRead/module-info.java
! test/langtools/tools/javac/diags/examples/ImportModuleDoesNotReadUnnamed.java
! test/langtools/tools/javac/diags/examples/ImportModuleNotFound.java
! test/langtools/tools/javac/diags/examples/ReturnBeforeSuperclassInit.java
! test/langtools/tools/javac/diags/examples/TryResourceThrowsInterruptedExc.java
! test/langtools/tools/javac/enum/6424358/T6424358.java
! test/langtools/tools/javac/enum/OkFinal.java
! test/langtools/tools/javac/enum/T5075242.java
! test/langtools/tools/javac/fatalErrors/ImproveFatalErrorHandling.java
! test/langtools/tools/javac/generics/5086027/T5086027pos.java
! test/langtools/tools/javac/generics/6192945/Method.java
! test/langtools/tools/javac/generics/6207386/Test.java
! test/langtools/tools/javac/generics/6227936/T6227936.java
! test/langtools/tools/javac/generics/6245699/T6245699c.java
! test/langtools/tools/javac/generics/6292765/T6292765.java
! test/langtools/tools/javac/generics/6332204/T6332204.java
! test/langtools/tools/javac/generics/6413682/TestPos.java
! test/langtools/tools/javac/generics/T6391995.java
! test/langtools/tools/javac/generics/inference/5073060/T5073060a.java
! test/langtools/tools/javac/generics/inference/5081782/Pos.java
! test/langtools/tools/javac/generics/inference/6215213/T6215213.java
! test/langtools/tools/javac/generics/inference/6278587/T6278587.java
! test/langtools/tools/javac/generics/inference/6302954/T6456971.java
! test/langtools/tools/javac/generics/inference/6359106/T6359106.java
! test/langtools/tools/javac/generics/rawOverride/AttributeSet.java
! test/langtools/tools/javac/generics/rawOverride/T6178365.java
! test/langtools/tools/javac/generics/typevars/4856983/T4856983.java
! test/langtools/tools/javac/generics/typevars/5060485/Method.java
! test/langtools/tools/javac/generics/typevars/5060485/Pos.java
! test/langtools/tools/javac/generics/wildcards/6330931/T6330931.java
! test/langtools/tools/javac/generics/wildcards/T5097548.java
! test/langtools/tools/javac/generics/wildcards/T5097548b.java
! test/langtools/tools/javac/jvm/6397652/T6397652.java
! test/langtools/tools/javac/lambda/LambdaExpr02.java
! test/langtools/tools/javac/lib/DPrinter.java
! test/langtools/tools/javac/modules/AddModulesTest.java
! test/langtools/tools/javac/modules/ConvenientAccessErrorsTest.java
! test/langtools/tools/javac/modules/EdgeCases.java
! test/langtools/tools/javac/modules/QueryBeforeEnter.java
! test/langtools/tools/javac/multicatch/Pos10.java
! test/langtools/tools/javac/overload/T4494762.java
! test/langtools/tools/javac/patterns/Domination.java
! test/langtools/tools/javac/patterns/PrettyTest.java
! test/langtools/tools/javac/patterns/SOEDeeplyNestedBlocksTest.java
! test/langtools/tools/javac/patterns/T8332463a.java
! test/langtools/tools/javac/patterns/T8332463b.java
! test/langtools/tools/javac/positions/T6402077.java
! test/langtools/tools/javac/positions/T6404194.java
! test/langtools/tools/javac/positions/TreeEndPosTest.java
! test/langtools/tools/javac/processing/6348499/T6348499.java
! test/langtools/tools/javac/processing/6359313/T6359313.java
! test/langtools/tools/javac/processing/6413690/T6413690.java
! test/langtools/tools/javac/processing/6414633/T6414633.java
! test/langtools/tools/javac/processing/6430209/T6430209.java
! test/langtools/tools/javac/processing/T6439826.java
! test/langtools/tools/javac/processing/T8142931.java
! test/langtools/tools/javac/processing/errors/TestReturnCode.java
! test/langtools/tools/javac/processing/filer/TestPackageInfo.java
! test/langtools/tools/javac/processing/model/6194785/T6194785.java
! test/langtools/tools/javac/processing/model/LocalInAnonymous.java
! test/langtools/tools/javac/processing/model/testgetallmembers/Main.java
! test/langtools/tools/javac/processing/options/TestNoteOnImplicitProcessing.java
! test/langtools/tools/javac/processing/options/Xprint.java
! test/langtools/tools/javac/processing/rounds/CompleteOnClosed.java
! test/langtools/tools/javac/scope/6225935/T6225935.java
! test/langtools/tools/javac/scope/6225935/T6381787.java
! test/langtools/tools/javac/scope/6225935/Test.java
! test/langtools/tools/javac/scope/6392998/T6392998.java
! test/langtools/tools/javac/sealed/SealedDiffConfigurationsTest.java
! test/langtools/tools/javac/sym/ElementStructureTest.java
! test/langtools/tools/javac/tree/VarTree.java
! test/langtools/tools/javac/types/UnknownTypeTest.java
! test/langtools/tools/javac/unicode/FirstChar.java
! test/langtools/tools/javac/unit/T6198196.java
! test/langtools/tools/javac/unit/util/convert/EnclosingCandidates.java
! test/langtools/tools/javac/unit/util/list/AbstractList.java
! test/langtools/tools/javac/unit/util/list/FromArray.java
! test/langtools/tools/javac/util/filemanager/TestName.java

Changeset: 96e5c270
Branch: master
Author:    Michael McMahon <michaelm at openjdk.org>
Date:      2025-12-31 22:05:31 +0000
URL:       https://git.openjdk.org/loom/commit/96e5c270b4ca0ad2b47ef3c090cbbfe4661bfc22

8373893: Refactor networking http server tests to use JUnit

Reviewed-by: djelinski

! test/jdk/com/sun/net/httpserver/BasicAuthenticatorRealm.java
! test/jdk/com/sun/net/httpserver/CreateHttpServerTest.java
! test/jdk/com/sun/net/httpserver/DateFormatterTest.java
! test/jdk/com/sun/net/httpserver/FilterTest.java
! test/jdk/com/sun/net/httpserver/HeadersTest.java
! test/jdk/com/sun/net/httpserver/HttpContextTest.java
! test/jdk/com/sun/net/httpserver/HttpPrincipalTest.java
! test/jdk/com/sun/net/httpserver/HttpServerProviderTest.java
! test/jdk/com/sun/net/httpserver/InputNotRead.java
! test/jdk/com/sun/net/httpserver/UnmodifiableHeadersTest.java
! test/jdk/com/sun/net/httpserver/bugs/BasicAuthenticatorExceptionCheck.java
! test/jdk/com/sun/net/httpserver/simpleserver/CommandLineNegativeTest.java
! test/jdk/com/sun/net/httpserver/simpleserver/CommandLinePortNotSpecifiedTest.java
! test/jdk/com/sun/net/httpserver/simpleserver/CommandLinePositiveTest.java
! test/jdk/com/sun/net/httpserver/simpleserver/CustomFileSystemTest.java
! test/jdk/com/sun/net/httpserver/simpleserver/FileServerHandlerTest.java
! test/jdk/com/sun/net/httpserver/simpleserver/HttpHandlersTest.java
! test/jdk/com/sun/net/httpserver/simpleserver/HttpsServerAlertTest.java
! test/jdk/com/sun/net/httpserver/simpleserver/HttpsServerTest.java
! test/jdk/com/sun/net/httpserver/simpleserver/IdempotencyAndCommutativityTest.java
! test/jdk/com/sun/net/httpserver/simpleserver/MapToPathTest.java
! test/jdk/com/sun/net/httpserver/simpleserver/OutputFilterTest.java
! test/jdk/com/sun/net/httpserver/simpleserver/RequestTest.java
! test/jdk/com/sun/net/httpserver/simpleserver/ServerMimeTypesResolutionTest.java
! test/jdk/com/sun/net/httpserver/simpleserver/SimpleFileServerTest.java
! test/jdk/com/sun/net/httpserver/simpleserver/StressDirListings.java
! test/jdk/com/sun/net/httpserver/simpleserver/ZipFileSystemTest.java
! test/jdk/com/sun/net/httpserver/simpleserver/jwebserver/CommandLineNegativeTest.java
! test/jdk/com/sun/net/httpserver/simpleserver/jwebserver/CommandLinePortNotSpecifiedTest.java
! test/jdk/com/sun/net/httpserver/simpleserver/jwebserver/CommandLinePositiveTest.java
! test/jdk/com/sun/net/httpserver/simpleserver/jwebserver/MaxRequestTimeTest.java

Changeset: 752f46d6
Branch: master
Author:    Eunbin Son <thswlsqls at naver.com>
Committer: Alan Bateman <alanb at openjdk.org>
Date:      2026-01-01 07:49:30 +0000
URL:       https://git.openjdk.org/loom/commit/752f46d66250dd44e1b13bbdbd86c70a33be3ac2

8374373: Typo in VirtualThreadSchedulerMXBean.setParallelism javadoc

Reviewed-by: alanb

! src/jdk.management/share/classes/jdk/management/VirtualThreadSchedulerMXBean.java

Changeset: d9bd300c
Branch: master
Author:    Alan Bateman <alanb at openjdk.org>
Date:      2026-01-01 07:49:49 +0000
URL:       https://git.openjdk.org/loom/commit/d9bd300c6eddfd30a83e53e7ae03c47ea43a9e08

8374382: (aio) AsynchronousFileChannel writes wrong content using heap ByteBuffer when position != 0

Reviewed-by: jpai

! src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java
+ test/jdk/java/nio/channels/AsynchronousFileChannel/BufferPositions.java


From duke at openjdk.org  Wed Jan  7 11:39:55 2026
From: duke at openjdk.org (duke)
Date: Wed, 7 Jan 2026 11:39:55 GMT
Subject: git: openjdk/loom: master: 44 new changesets
Message-ID: <347b6c22-819a-43ca-aad7-6ca6e9b66c8f@openjdk.org>

Changeset: 65af6bcb
Branch: master
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2026-01-02 09:27:40 +0000
URL:       https://git.openjdk.org/loom/commit/65af6bcb8f74484436b0331032260f2a646f203f

8374371: Failed assertion in G1HeapRegion gtest

Reviewed-by: tschatzl, iwalulya

! test/hotspot/gtest/gc/g1/test_heapRegion.cpp

Changeset: 2ea3c00e
Branch: master
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2026-01-02 09:48:40 +0000
URL:       https://git.openjdk.org/loom/commit/2ea3c00e4f2a6e8c0a55039aee6fdfc8194a70a7

4337898: Serializing DefaultTableCellRenderer changes colors

Reviewed-by: azvegint

! src/java.desktop/share/classes/javax/swing/table/DefaultTableCellRenderer.java
+ test/jdk/javax/swing/DefaultTableCellRenderer/DefRendererSerialize.java

Changeset: 05d2f7f4
Branch: master
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2026-01-02 09:53:04 +0000
URL:       https://git.openjdk.org/loom/commit/05d2f7f4080f5cc6d3eef97878806e28773d6f70

8373847: Test javax/swing/JMenuItem/MenuItemTest/bug6197830.java failed because The test case automatically fails when clicking any items in the ?Nothing? menu in all four windows (Left-to-right)-Menu Item Test and (Right-to-left)-Menu Item Test

Reviewed-by: serb, aivanov, dnguyen

! test/jdk/javax/swing/JMenuItem/MenuItemTest/bug6197830.java

Changeset: efb79dc6
Branch: master
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2026-01-02 10:19:17 +0000
URL:       https://git.openjdk.org/loom/commit/efb79dc6b4907ecf4e1bab3c393ee5cd5fe911a8

8374444: Fix simple -Wzero-as-null-pointer-constant warnings

Reviewed-by: aboldtch

! src/hotspot/share/cds/aotMappedHeapWriter.cpp
! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp
! src/hotspot/share/opto/vectorization.cpp
! src/hotspot/share/runtime/continuationFreezeThaw.cpp
! test/hotspot/gtest/nmt/test_regions_tree.cpp

Changeset: 34395124
Branch: master
Author:    Artur Barashev <abarashev at openjdk.org>
Date:      2026-01-02 13:28:15 +0000
URL:       https://git.openjdk.org/loom/commit/34395124018c434b0bad534cb6f85452466fd404

8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket

Reviewed-by: djelinski, mpowers, ascarpino

! src/java.base/share/classes/sun/security/ssl/SessionTicketExtension.java

Changeset: 2daf12ed
Branch: master
Author:    Francesco Andreuzzi <fandreuzzi at openjdk.org>
Date:      2026-01-02 14:51:37 +0000
URL:       https://git.openjdk.org/loom/commit/2daf12edd24e641d4d7706d582994c2b3fe95e87

8374465: Spurious dot in documentation for JVMTI ClassLoad

Reviewed-by: kbarrett

! src/hotspot/share/prims/jvmti.xml

Changeset: 53824cf2
Branch: master
Author:    Leonid Mesnik <lmesnik at openjdk.org>
Date:      2026-01-03 02:52:53 +0000
URL:       https://git.openjdk.org/loom/commit/53824cf2a97adbc25d32bec0acaff24d105081f9

8343809: Add requires tag to mark tests that are incompatible with exploded image

Reviewed-by: alanb, dholmes

! test/hotspot/jtreg/TEST.ROOT
! test/hotspot/jtreg/runtime/getSysPackage/GetSysPkgTest.java
! test/hotspot/jtreg/runtime/modules/ModulesSymLink.java
! test/hotspot/jtreg/runtime/modules/PatchModule/PatchModuleTraceCL.java
! test/jtreg-ext/requires/VMProps.java

Changeset: 6eaabed5
Branch: master
Author:    Xiaohong Gong <xgong at openjdk.org>
Date:      2026-01-05 01:54:31 +0000
URL:       https://git.openjdk.org/loom/commit/6eaabed55ca4670d8c317f0a4323ccea4dd0b9ca

8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently

Reviewed-by: jiefu, jbhateja, erfang, qamai

! test/hotspot/jtreg/compiler/vectorapi/TestVectorOperationsWithPartialSize.java

Changeset: 16303822
Branch: master
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2026-01-05 08:27:37 +0000
URL:       https://git.openjdk.org/loom/commit/163038222a371c07aff8bce50eee55bb389104d0

8373704: Improve "SocketException: Protocol family unavailable" message

Reviewed-by: lucy, jpai

! src/java.base/unix/native/libnet/net_util_md.c
! src/java.base/windows/native/libnet/net_util_md.c

Changeset: e676c9de
Branch: master
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2026-01-05 09:35:50 +0000
URL:       https://git.openjdk.org/loom/commit/e676c9de3da3b820081cde1b11c0df3129787130

8357258: x86: Improve receiver type profiling reliability

Reviewed-by: kvn, vlivanov

! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp
! src/hotspot/cpu/x86/c1_LIRAssembler_x86.hpp
! src/hotspot/cpu/x86/interp_masm_x86.cpp
! src/hotspot/cpu/x86/interp_masm_x86.hpp
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.hpp
! src/hotspot/cpu/x86/templateTable_x86.cpp
! src/hotspot/share/oops/methodData.hpp

Changeset: eee58545
Branch: master
Author:    Daisuke Yamazaki <dyama at openjdk.org>
Committer: Sean Mullan <mullan at openjdk.org>
Date:      2026-01-05 13:19:32 +0000
URL:       https://git.openjdk.org/loom/commit/eee58545c8342fc39b3bec5b38da6c01d92d05f2

8366058: Outdated comment in WinCAPISeedGenerator

Reviewed-by: mullan

! src/java.base/windows/native/libjava/WinCAPISeedGenerator.c

Changeset: 6ae3e064
Branch: master
Author:    Roland Westrelin <roland at openjdk.org>
Date:      2026-01-05 14:02:41 +0000
URL:       https://git.openjdk.org/loom/commit/6ae3e064352a56c5be140fba1ad6d040219432b0

8373508: C2: sinking CreateEx out of loop breaks the graph

Reviewed-by: chagedorn, dlong

! src/hotspot/share/opto/loopopts.cpp
+ test/hotspot/jtreg/compiler/loopopts/TestCreateExSunkOutOfLoop.java
+ test/hotspot/jtreg/compiler/loopopts/TestCreateExSunkOutOfLoop2.java

Changeset: 4458cab4
Branch: master
Author:    Beno?t Maillard <bmaillard at openjdk.org>
Date:      2026-01-05 14:39:38 +0000
URL:       https://git.openjdk.org/loom/commit/4458cab4b0063f39333392321f542d0aa0db490d

8367627: C2: Missed Ideal() optimization opportunity with MemBar

Reviewed-by: chagedorn, epeter

! src/hotspot/share/opto/graphKit.cpp
! src/hotspot/share/opto/node.cpp
+ test/hotspot/jtreg/compiler/c2/igvn/TestMissingOptMemBarRemovePrecedentEdge.java

Changeset: 27dbdec2
Branch: master
Author:    Naoto Sato <naoto at openjdk.org>
Date:      2026-01-05 17:16:35 +0000
URL:       https://git.openjdk.org/loom/commit/27dbdec297fc8030812f7290a7601b6a99defb46

8374217: Remove IO.java test from AOT ProblemList

Reviewed-by: jpai, iklam

! test/jdk/ProblemList-AotJdk.txt
! test/jdk/java/lang/IO/IO.java

Changeset: 5fd095fb
Branch: master
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
Date:      2026-01-05 19:16:40 +0000
URL:       https://git.openjdk.org/loom/commit/5fd095fb9b8f1d2000760519d42d7d0068b82651

8372591: assert(!current->cont_fastpath() || freeze.check_valid_fast_path()) failed

Reviewed-by: dholmes, alanb, rrich, fyang

! src/hotspot/share/runtime/sharedRuntime.cpp
+ test/jdk/jdk/internal/vm/Continuation/OSRWithManyLocals.java

Changeset: fa8ea6b3
Branch: master
Author:    Alex Menkov <amenkov at openjdk.org>
Date:      2026-01-05 19:55:54 +0000
URL:       https://git.openjdk.org/loom/commit/fa8ea6b32d463a84affa529d37cfb97280503fc6

8374168: Resolve disabled warnings in JDWP agent

Reviewed-by: cjplummer, sspitsyn, erikj

! make/modules/jdk.jdwp.agent/Lib.gmk
! src/jdk.jdwp.agent/share/native/libjdwp/EventRequestImpl.c
! src/jdk.jdwp.agent/share/native/libjdwp/SDE.c
! src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c
! src/jdk.jdwp.agent/share/native/libjdwp/error_messages.c
! src/jdk.jdwp.agent/share/native/libjdwp/eventFilter.c
! src/jdk.jdwp.agent/share/native/libjdwp/inStream.c
! src/jdk.jdwp.agent/share/native/libjdwp/log_messages.c
! src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c
! src/jdk.jdwp.agent/share/native/libjdwp/utf_util.c
! src/jdk.jdwp.agent/share/native/libjdwp/util.h

Changeset: de81d389
Branch: master
Author:    David Holmes <dholmes at openjdk.org>
Date:      2026-01-05 20:09:49 +0000
URL:       https://git.openjdk.org/loom/commit/de81d38995356a2e8528a419ebd445e79cd136d1

8374456: JVM crashes with "assert(resolved_method->method_holder()->is_linked()) failed: must be linked" when run with large  value for PreallocatedOutOfMemoryErrorCount

Reviewed-by: coleenp

! src/hotspot/share/runtime/globals.hpp

Changeset: d063c954
Branch: master
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2026-01-06 07:40:36 +0000
URL:       https://git.openjdk.org/loom/commit/d063c9546b4a500f4c76fcd01442c2b7281f6d65

8374507: GHA: Limit debug symbols generation to conserve disk space

Reviewed-by: erikj

! .github/workflows/build-alpine-linux.yml
! .github/workflows/build-cross-compile.yml
! .github/workflows/build-linux.yml
! .github/workflows/build-macos.yml
! .github/workflows/build-windows.yml

Changeset: 2fbc4162
Branch: master
Author:    Fabian Meumertzheim <fmeum at openjdk.org>
Committer: Alan Bateman <alanb at openjdk.org>
Date:      2026-01-06 08:09:42 +0000
URL:       https://git.openjdk.org/loom/commit/2fbc4162e808f14b6114499f49db3e6ef1590f24

8374441: (fs) FileSystemProvider.readAttributesIfExists throws "Not a directory" when element in path is not directory should return null for ENOTDIR (unix)

Reviewed-by: alanb

! src/java.base/unix/classes/sun/nio/fs/UnixFileAttributes.java
! test/jdk/java/nio/file/Files/NotADirectory.java

Changeset: 2cb228e1
Branch: master
Author:    Emanuel Peter <epeter at openjdk.org>
Date:      2026-01-06 08:51:40 +0000
URL:       https://git.openjdk.org/loom/commit/2cb228e142369ec73d768d8a69653a984b1c5908

8374489: Template Library: need to tag Float16.float16ToRawShortBits as having non-deterministic result because of multiple NaN bit patterns

Reviewed-by: chagedorn, kvn

! test/hotspot/jtreg/compiler/lib/template_framework/library/Operations.java

Changeset: 3a80c639
Branch: master
Author:    Volkan Yazici <vyazici at openjdk.org>
Date:      2026-01-06 10:21:14 +0000
URL:       https://git.openjdk.org/loom/commit/3a80c639d804a0697b8eb477fe4c96407709449b

8373515: Migrate "test/jdk/java/net/httpclient/" to null-safe "SimpleSSLContext" methods

Reviewed-by: jpai

! test/jdk/java/net/httpclient/ALPNProxyFailureTest.java
! test/jdk/java/net/httpclient/AbstractNoBody.java
! test/jdk/java/net/httpclient/AbstractThrowingPublishers.java
! test/jdk/java/net/httpclient/AbstractThrowingPushPromises.java
! test/jdk/java/net/httpclient/AbstractThrowingSubscribers.java
! test/jdk/java/net/httpclient/AggregateRequestBodyTest.java
! test/jdk/java/net/httpclient/AltServiceUsageTest.java
! test/jdk/java/net/httpclient/AsFileDownloadTest.java
! test/jdk/java/net/httpclient/AsyncExecutorShutdown.java
! test/jdk/java/net/httpclient/AsyncShutdownNow.java
! test/jdk/java/net/httpclient/AuthFilterCacheTest.java
! test/jdk/java/net/httpclient/BasicAuthTest.java
! test/jdk/java/net/httpclient/BasicHTTP2Test.java
! test/jdk/java/net/httpclient/BasicHTTP3Test.java
! test/jdk/java/net/httpclient/BasicRedirectTest.java
! test/jdk/java/net/httpclient/BufferSize1Test.java
! test/jdk/java/net/httpclient/CancelRequestTest.java
! test/jdk/java/net/httpclient/CancelStreamedBodyTest.java
! test/jdk/java/net/httpclient/CancelledPartialResponseTest.java
! test/jdk/java/net/httpclient/CancelledResponse.java
! test/jdk/java/net/httpclient/CancelledResponse2.java
! test/jdk/java/net/httpclient/ConcurrentResponses.java
! test/jdk/java/net/httpclient/ContentLengthHeaderTest.java
! test/jdk/java/net/httpclient/CookieHeaderTest.java
! test/jdk/java/net/httpclient/CustomRequestPublisher.java
! test/jdk/java/net/httpclient/CustomResponseSubscriber.java
! test/jdk/java/net/httpclient/DependentActionsTest.java
! test/jdk/java/net/httpclient/DependentPromiseActionsTest.java
! test/jdk/java/net/httpclient/DigestEchoClient.java
! test/jdk/java/net/httpclient/DurationOverflowTest.java
! test/jdk/java/net/httpclient/EmptyAuthenticate.java
! test/jdk/java/net/httpclient/EncodedCharsInURI.java
! test/jdk/java/net/httpclient/EscapedOctetsInURI.java
! test/jdk/java/net/httpclient/ExecutorShutdown.java
! test/jdk/java/net/httpclient/ExpectContinue.java
! test/jdk/java/net/httpclient/FileChannelPublisherTest.java
! test/jdk/java/net/httpclient/FilePublisherTest.java
! test/jdk/java/net/httpclient/FlowAdapterPublisherTest.java
! test/jdk/java/net/httpclient/FlowAdapterSubscriberTest.java
! test/jdk/java/net/httpclient/ForbiddenHeadTest.java
! test/jdk/java/net/httpclient/GZIPInputStreamTest.java
! test/jdk/java/net/httpclient/HeadTest.java
! test/jdk/java/net/httpclient/HeadersLowerCaseTest.java
! test/jdk/java/net/httpclient/HttpClientAuthRetryLimitTest.java
! test/jdk/java/net/httpclient/HttpClientBuilderTest.java
! test/jdk/java/net/httpclient/HttpClientClose.java
! test/jdk/java/net/httpclient/HttpClientLocalAddrTest.java
! test/jdk/java/net/httpclient/HttpClientSNITest.java
! test/jdk/java/net/httpclient/HttpClientShutdown.java
! test/jdk/java/net/httpclient/HttpGetInCancelledFuture.java
! test/jdk/java/net/httpclient/HttpRedirectTest.java
! test/jdk/java/net/httpclient/HttpResponseConnectionLabelTest.java
! test/jdk/java/net/httpclient/HttpResponseLimitingTest.java
! test/jdk/java/net/httpclient/HttpSlowServerTest.java
! test/jdk/java/net/httpclient/HttpVersionsTest.java
! test/jdk/java/net/httpclient/HttpsTunnelAuthTest.java
! test/jdk/java/net/httpclient/HttpsTunnelTest.java
! test/jdk/java/net/httpclient/ISO_8859_1_Test.java
! test/jdk/java/net/httpclient/IdleConnectionTimeoutTest.java
! test/jdk/java/net/httpclient/ImmutableFlowItems.java
! test/jdk/java/net/httpclient/ImmutableSSLSessionTest.java
! test/jdk/java/net/httpclient/InvalidInputStreamSubscriptionRequest.java
! test/jdk/java/net/httpclient/InvalidSSLContextTest.java
! test/jdk/java/net/httpclient/InvalidSubscriptionRequest.java
! test/jdk/java/net/httpclient/LargeResponseTest.java
! test/jdk/java/net/httpclient/LightWeightHttpServer.java
! test/jdk/java/net/httpclient/LineBodyHandlerTest.java
! test/jdk/java/net/httpclient/ManyRequests.java
! test/jdk/java/net/httpclient/ManyRequestsLegacy.java
! test/jdk/java/net/httpclient/MappingResponseSubscriber.java
! test/jdk/java/net/httpclient/MaxStreams.java
! test/jdk/java/net/httpclient/NonAsciiCharsInURI.java
! test/jdk/java/net/httpclient/PathSubscriber/BodyHandlerOfFileDownloadTest.java
! test/jdk/java/net/httpclient/PathSubscriber/BodyHandlerOfFileTest.java
! test/jdk/java/net/httpclient/PathSubscriber/BodySubscriberOfFileTest.java
! test/jdk/java/net/httpclient/PlainConnectionLockTest.java
! test/jdk/java/net/httpclient/ProxySelectorTest.java
! test/jdk/java/net/httpclient/ProxyTest.java
! test/jdk/java/net/httpclient/RedirectMethodChange.java
! test/jdk/java/net/httpclient/RedirectTimeoutTest.java
! test/jdk/java/net/httpclient/RedirectWithCookie.java
! test/jdk/java/net/httpclient/Response1xxTest.java
! test/jdk/java/net/httpclient/Response204V2Test.java
! test/jdk/java/net/httpclient/ResponseBodyBeforeError.java
! test/jdk/java/net/httpclient/ResponsePublisher.java
! test/jdk/java/net/httpclient/RetryWithCookie.java
! test/jdk/java/net/httpclient/ServerCloseTest.java
! test/jdk/java/net/httpclient/ShortResponseBody.java
! test/jdk/java/net/httpclient/ShutdownNow.java
! test/jdk/java/net/httpclient/SmokeTest.java
! test/jdk/java/net/httpclient/SpecialHeadersTest.java
! test/jdk/java/net/httpclient/SplitResponse.java
! test/jdk/java/net/httpclient/StreamingBody.java
! test/jdk/java/net/httpclient/TimeoutBasic.java
! test/jdk/java/net/httpclient/TimeoutResponseTestSupport.java
! test/jdk/java/net/httpclient/TlsContextTest.java
! test/jdk/java/net/httpclient/UnauthorizedTest.java
! test/jdk/java/net/httpclient/UnknownBodyLengthTest.java
! test/jdk/java/net/httpclient/UserAuthWithAuthenticator.java
! test/jdk/java/net/httpclient/UserCookieTest.java
! test/jdk/java/net/httpclient/http2/BadHeadersTest.java
! test/jdk/java/net/httpclient/http2/BasicTest.java
! test/jdk/java/net/httpclient/http2/ConnectionFlowControlTest.java
! test/jdk/java/net/httpclient/http2/ConnectionReuseTest.java
! test/jdk/java/net/httpclient/http2/ContinuationFrameTest.java
! test/jdk/java/net/httpclient/http2/ErrorTest.java
! test/jdk/java/net/httpclient/http2/FixedThreadPoolTest.java
! test/jdk/java/net/httpclient/http2/H2GoAwayTest.java
! test/jdk/java/net/httpclient/http2/H2SelectorVTTest.java
! test/jdk/java/net/httpclient/http2/NoBodyTest.java
! test/jdk/java/net/httpclient/http2/ProxyTest2.java
! test/jdk/java/net/httpclient/http2/SimpleGet.java
! test/jdk/java/net/httpclient/http2/StreamFlowControlTest.java
! test/jdk/java/net/httpclient/http2/UserInfoTest.java
! test/jdk/java/net/httpclient/http3/BadCipherSuiteErrorTest.java
! test/jdk/java/net/httpclient/http3/GetHTTP3Test.java
! test/jdk/java/net/httpclient/http3/H3BadHeadersTest.java
! test/jdk/java/net/httpclient/http3/H3BasicTest.java
! test/jdk/java/net/httpclient/http3/H3ConcurrentPush.java
! test/jdk/java/net/httpclient/http3/H3ConnectionPoolTest.java
! test/jdk/java/net/httpclient/http3/H3DataLimitsTest.java
! test/jdk/java/net/httpclient/http3/H3ErrorHandlingTest.java
! test/jdk/java/net/httpclient/http3/H3FixedThreadPoolTest.java
! test/jdk/java/net/httpclient/http3/H3GoAwayTest.java
! test/jdk/java/net/httpclient/http3/H3HeaderSizeLimitTest.java
! test/jdk/java/net/httpclient/http3/H3HeadersEncoding.java
! test/jdk/java/net/httpclient/http3/H3IdleExceedsQuicIdleTimeout.java
! test/jdk/java/net/httpclient/http3/H3ImplicitPushCancel.java
! test/jdk/java/net/httpclient/http3/H3InsertionsLimitTest.java
! test/jdk/java/net/httpclient/http3/H3LogHandshakeErrors.java
! test/jdk/java/net/httpclient/http3/H3MalformedResponseTest.java
! test/jdk/java/net/httpclient/http3/H3MaxInitialTimeoutTest.java
! test/jdk/java/net/httpclient/http3/H3MemoryHandlingTest.java
! test/jdk/java/net/httpclient/http3/H3MultipleConnectionsToSameHost.java
! test/jdk/java/net/httpclient/http3/H3ProxyTest.java
! test/jdk/java/net/httpclient/http3/H3PushCancel.java
! test/jdk/java/net/httpclient/http3/H3QuicTLSConnection.java
! test/jdk/java/net/httpclient/http3/H3QuicVTTest.java
! test/jdk/java/net/httpclient/http3/H3RedirectTest.java
! test/jdk/java/net/httpclient/http3/H3RequestRejectedTest.java
! test/jdk/java/net/httpclient/http3/H3ServerPush.java
! test/jdk/java/net/httpclient/http3/H3ServerPushCancel.java
! test/jdk/java/net/httpclient/http3/H3ServerPushTest.java
! test/jdk/java/net/httpclient/http3/H3ServerPushWithDiffTypes.java
! test/jdk/java/net/httpclient/http3/H3SimpleGet.java
! test/jdk/java/net/httpclient/http3/H3SimplePost.java
! test/jdk/java/net/httpclient/http3/H3SimpleTest.java
! test/jdk/java/net/httpclient/http3/H3StopSendingTest.java
! test/jdk/java/net/httpclient/http3/H3StreamLimitReachedTest.java
! test/jdk/java/net/httpclient/http3/H3Timeout.java
! test/jdk/java/net/httpclient/http3/H3UserInfoTest.java
! test/jdk/java/net/httpclient/http3/HTTP3NoBodyTest.java
! test/jdk/java/net/httpclient/http3/Http3ExpectContinueTest.java
! test/jdk/java/net/httpclient/http3/PostHTTP3Test.java
! test/jdk/java/net/httpclient/http3/StopSendingTest.java
! test/jdk/java/net/httpclient/http3/StreamLimitTest.java
! test/jdk/java/net/httpclient/quic/KeyUpdateTest.java
! test/jdk/java/net/httpclient/quic/PacketLossTest.java
! test/jdk/java/net/httpclient/quic/QuicRequestResponseTest.java
! test/jdk/java/net/httpclient/quic/StatelessResetReceiptTest.java
! test/jdk/java/net/httpclient/quic/VersionNegotiationTest.java
! test/jdk/java/net/httpclient/quic/tls/QuicTLSEngineBadParametersTest.java
! test/jdk/java/net/httpclient/quic/tls/QuicTLSEngineFailedALPNTest.java
! test/jdk/java/net/httpclient/quic/tls/QuicTLSEngineMissingParametersTest.java
! test/jdk/java/net/httpclient/websocket/HandshakeUrlEncodingTest.java
! test/jdk/java/net/httpclient/websocket/WSHandshakeExceptionTest.java
! test/jdk/java/net/httpclient/websocket/WebSocketProxyTest.java
! test/jdk/java/net/httpclient/whitebox/AltSvcFrameTest.java
! test/jdk/java/net/httpclient/whitebox/AltSvcRegistryTest.java
! test/jdk/java/net/httpclient/whitebox/FlowTestDriver.java
! test/jdk/java/net/httpclient/whitebox/SSLEchoTubeTestDriver.java
! test/jdk/java/net/httpclient/whitebox/SSLFlowDelegateTestDriver.java
! test/jdk/java/net/httpclient/whitebox/SSLTubeTestDriver.java
! test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/AbstractSSLTubeTest.java
! test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/FlowTest.java
! test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/SSLFlowDelegateTest.java
! test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/SSLTubeTest.java
- test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/SimpleSSLContext.java
+ test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/SimpleSSLContextWhiteboxAdapter.java

Changeset: 938bbd5b
Branch: master
Author:    Christian Hagedorn <chagedorn at openjdk.org>
Date:      2026-01-06 10:23:45 +0000
URL:       https://git.openjdk.org/loom/commit/938bbd5b604e990514b64a0451ed1bceb07eb23b

8374518: C1: Remove dead LinearScanStatistic::Counter::counter_fpu_stack

Reviewed-by: thartmann, mdoerr

! src/hotspot/share/c1/c1_LinearScan.hpp
+ test/hotspot/jtreg/compiler/c1/TestCITimeCountLinearScan.java

Changeset: 5df183be
Branch: master
Author:    Johny Jose <johny.jose at oracle.com>
Committer: Sean Coffey <coffeys at openjdk.org>
Date:      2026-01-06 10:36:41 +0000
URL:       https://git.openjdk.org/loom/commit/5df183be6c484d8f9635fac149caf5e2079c5561

8373476: (tz) Update Timezone Data to 2025c

Reviewed-by: coffeys, naoto

! src/java.base/share/data/tzdata/VERSION
! src/java.base/share/data/tzdata/africa
! src/java.base/share/data/tzdata/antarctica
! src/java.base/share/data/tzdata/asia
! src/java.base/share/data/tzdata/australasia
! src/java.base/share/data/tzdata/europe
! src/java.base/share/data/tzdata/iso3166.tab
! src/java.base/share/data/tzdata/leapseconds
! src/java.base/share/data/tzdata/northamerica
! src/java.base/share/data/tzdata/southamerica
! test/jdk/java/util/TimeZone/TimeZoneData/VERSION

Changeset: 532a0a65
Branch: master
Author:    Fernando Guallini <fguallini at openjdk.org>
Date:      2026-01-06 10:53:27 +0000
URL:       https://git.openjdk.org/loom/commit/532a0a65b130e1fbe74ccbd16cdeed258cc2c245

8372950: Pem.pemEncoded should cache the Pattern

Reviewed-by: ascarpino

! src/java.base/share/classes/sun/security/util/Pem.java

Changeset: df5b49e6
Branch: master
Author:    Dingli Zhang <dzhang at openjdk.org>
Date:      2026-01-06 12:49:16 +0000
URL:       https://git.openjdk.org/loom/commit/df5b49e604d3204c6383484ba3807d39abd0b0f1

8374525: RISC-V: Several masked float16 vector operations are not supported

Reviewed-by: fjiang, fyang

! src/hotspot/cpu/riscv/riscv_v.ad

Changeset: e27309f1
Branch: master
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2026-01-06 15:00:45 +0000
URL:       https://git.openjdk.org/loom/commit/e27309f10d32695972f468df17b2535d36a746a2

8374350: Convert hotspot gtests to use Atomic<T>

Reviewed-by: aboldtch, iwalulya

! test/hotspot/gtest/cds/test_archiveWorkers.cpp
! test/hotspot/gtest/gc/g1/test_g1BatchedGangTask.cpp
! test/hotspot/gtest/gc/g1/test_g1CardSet.cpp
! test/hotspot/gtest/gc/g1/test_stressCommitUncommit.cpp
! test/hotspot/gtest/gc/shared/test_bufferNodeAllocator.cpp
! test/hotspot/gtest/utilities/test_concurrentHashtable.cpp
! test/hotspot/gtest/utilities/test_globalCounter_nested.cpp
! test/hotspot/gtest/utilities/test_singleWriterSynchronizer.cpp
! test/hotspot/gtest/utilities/test_waitBarrier.cpp

Changeset: 32144282
Branch: master
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2026-01-06 15:05:29 +0000
URL:       https://git.openjdk.org/loom/commit/3214428203642e986c47eabc29ebdea93016b2c5

8374446: Fix -Wzero-as-null-pointer-constant warnings in test_compressedKlass.cpp

Reviewed-by: dholmes

! test/hotspot/gtest/oops/test_compressedKlass.cpp

Changeset: c611da25
Branch: master
Author:    Leonid Mesnik <lmesnik at openjdk.org>
Date:      2026-01-06 15:48:53 +0000
URL:       https://git.openjdk.org/loom/commit/c611da257f69e9c9b178b85cb705a4b0a42545ac

8374483: Eliminate :serviceability_ttf_virtual group and mark svc non-virtual tests with requires

Reviewed-by: syan, dholmes

! test/hotspot/jtreg/TEST.groups
! test/hotspot/jtreg/serviceability/jvmti/events/Breakpoint/breakpoint01/breakpoint01.java
! test/hotspot/jtreg/serviceability/jvmti/events/ClassLoad/classload01/classload01.java
! test/hotspot/jtreg/serviceability/jvmti/events/ClassPrepare/classprep01/classprep01.java
! test/hotspot/jtreg/serviceability/jvmti/events/MethodEntry/mentry02/mentry02.java
! test/hotspot/jtreg/serviceability/jvmti/events/MonitorWaited/monitorwaited01/monitorwaited01.java
! test/hotspot/jtreg/serviceability/jvmti/negative/thrinfo02/thrinfo02.java
! test/hotspot/jtreg/serviceability/jvmti/thread/GetThreadInfo/thrinfo01/thrinfo01.java
! test/hotspot/jtreg/serviceability/jvmti/vthread/BoundVThreadTest/BoundVThreadTest.java
! test/hotspot/jtreg/serviceability/jvmti/vthread/ContinuationTest/ContinuationTest.java
! test/hotspot/jtreg/serviceability/jvmti/vthread/FollowReferences/VThreadStackRefTest.java
! test/hotspot/jtreg/serviceability/jvmti/vthread/SelfSuspendDisablerTest/SelfSuspendDisablerTest.java
! test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java
! test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume2/SuspendResume2.java
! test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResumeAll/SuspendResumeAll.java
! test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadTLSTest/VThreadTLSTest.java
! test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadTest/VThreadTest.java
! test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadUnsupportedTest/VThreadUnsupportedTest.java
! test/hotspot/jtreg/serviceability/jvmti/vthread/WaitNotifySuspendedVThreadTest/WaitNotifySuspendedVThreadTest.java

Changeset: 136ac0d1
Branch: master
Author:    Naoto Sato <naoto at openjdk.org>
Date:      2026-01-06 16:28:33 +0000
URL:       https://git.openjdk.org/loom/commit/136ac0d10b92df8875f36c717e85595740b50ed2

8374433: java/util/Locale/PreserveTagCase.java does not run any tests

Reviewed-by: iris, joehw, jlu

! test/jdk/java/util/Locale/PreserveTagCase.java

Changeset: 3f652159
Branch: master
Author:    Daniel Gredler <dgredler at openjdk.org>
Date:      2026-01-06 16:52:21 +0000
URL:       https://git.openjdk.org/loom/commit/3f6521596014510b75318b53ef4aef6b01056545

8374340: FontRenderContext instance variables should be final

Reviewed-by: aivanov, aturbanov, prr, serb

! src/java.desktop/share/classes/java/awt/font/FontRenderContext.java

Changeset: 62181b63
Branch: master
Author:    Daniel Gredler <dgredler at openjdk.org>
Date:      2026-01-06 17:56:43 +0000
URL:       https://git.openjdk.org/loom/commit/62181b6363926968298ed37ac7780ee6d5ef0916

6562639: Wrong pixel bounds from TextLayout with white font

Reviewed-by: serb, prr

! src/java.desktop/share/classes/java/awt/font/TextLine.java
+ test/jdk/java/awt/font/TextLayout/TestGetPixelBoundsWithColors.java

Changeset: cdbc493a
Branch: master
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2026-01-06 17:57:02 +0000
URL:       https://git.openjdk.org/loom/commit/cdbc493a6d93a0da0db987245daa7b1d00cc8add

8374190: Convert ConcurrentHashTable atomic lists to use Atomic<T>

Reviewed-by: dholmes, iwalulya

! src/hotspot/share/utilities/concurrentHashTable.hpp
! src/hotspot/share/utilities/concurrentHashTable.inline.hpp

Changeset: fbc59ac0
Branch: master
Author:    Weijun Wang <weijun at openjdk.org>
Date:      2026-01-06 18:05:27 +0000
URL:       https://git.openjdk.org/loom/commit/fbc59ac0a1248066e9fbcfde3bd6a8eb4d60992c

8374555: No need for visible input warning in s.s.u.Password when not reading from System.in

Reviewed-by: coffeys, hchao

! src/java.base/share/classes/sun/security/util/Password.java
+ test/jdk/sun/security/util/Password/EmptyIn.java

Changeset: f1e0e0c2
Branch: master
Author:    Roger Riggs <rriggs at openjdk.org>
Date:      2026-01-06 18:07:43 +0000
URL:       https://git.openjdk.org/loom/commit/f1e0e0c25ec62a543b9cbfabd630fc4ef17a8b5c

8374544: Add SleepyCat diagnostics for all platforms

Reviewed-by: jpai

! test/jdk/java/lang/RuntimeTests/exec/SleepyCat.java
= test/jdk/java/lang/RuntimeTests/exec/TEST.properties

Changeset: 53300b4a
Branch: master
Author:    Justin Lu <jlu at openjdk.org>
Date:      2026-01-06 19:24:43 +0000
URL:       https://git.openjdk.org/loom/commit/53300b4ac12240ea08227386412bfb90650c0aee

8373830: Refactor test/jdk/java/time/test tests to use JUnit over TestNG
8373829: Refactor test/jdk/java/time/tck tests to use JUnit over TestNG

Reviewed-by: naoto

= test/jdk/java/time/nonjunit/java/time/chrono/HijrahConfigCheck.java
= test/jdk/java/time/nonjunit/java/time/chrono/HijrahConfigTest.java
= test/jdk/java/time/nonjunit/java/time/chrono/hijrah-config-Hijrah-test_islamic-test.properties
= test/jdk/java/time/nonjunit/java/time/zone/CustomZoneNameTest.java
= test/jdk/java/time/nonjunit/java/time/zone/zoneProvider/META-INF/services/java.time.zone.ZoneRulesProvider
= test/jdk/java/time/nonjunit/java/time/zone/zoneProvider/META-INF/services/java.util.spi.TimeZoneNameProvider
= test/jdk/java/time/nonjunit/java/time/zone/zoneProvider/custom/CustomTimeZoneNameProvider.java
= test/jdk/java/time/nonjunit/java/time/zone/zoneProvider/custom/CustomZoneRulesProvider.java
! test/jdk/java/time/tck/TEST.properties
! test/jdk/java/time/tck/java/time/AbstractDateTimeTest.java
! test/jdk/java/time/tck/java/time/AbstractTCKTest.java
! test/jdk/java/time/tck/java/time/TCKClock.java
! test/jdk/java/time/tck/java/time/TCKClock_Fixed.java
! test/jdk/java/time/tck/java/time/TCKClock_Offset.java
! test/jdk/java/time/tck/java/time/TCKClock_System.java
! test/jdk/java/time/tck/java/time/TCKClock_Tick.java
! test/jdk/java/time/tck/java/time/TCKDayOfWeek.java
! test/jdk/java/time/tck/java/time/TCKDuration.java
! test/jdk/java/time/tck/java/time/TCKInstant.java
! test/jdk/java/time/tck/java/time/TCKLocalDate.java
! test/jdk/java/time/tck/java/time/TCKLocalDateTime.java
! test/jdk/java/time/tck/java/time/TCKLocalTime.java
! test/jdk/java/time/tck/java/time/TCKMonth.java
! test/jdk/java/time/tck/java/time/TCKMonthDay.java
! test/jdk/java/time/tck/java/time/TCKOffsetDateTime.java
! test/jdk/java/time/tck/java/time/TCKOffsetTime.java
! test/jdk/java/time/tck/java/time/TCKPeriod.java
! test/jdk/java/time/tck/java/time/TCKYear.java
! test/jdk/java/time/tck/java/time/TCKYearMonth.java
! test/jdk/java/time/tck/java/time/TCKZoneId.java
! test/jdk/java/time/tck/java/time/TCKZoneOffset.java
! test/jdk/java/time/tck/java/time/TCKZonedDateTime.java
! test/jdk/java/time/tck/java/time/TestIsoChronology.java
! test/jdk/java/time/tck/java/time/chrono/TCKChronoLocalDate.java
! test/jdk/java/time/tck/java/time/chrono/TCKChronoLocalDateTime.java
! test/jdk/java/time/tck/java/time/chrono/TCKChronoPeriod.java
! test/jdk/java/time/tck/java/time/chrono/TCKChronoZonedDateTime.java
! test/jdk/java/time/tck/java/time/chrono/TCKChronology.java
! test/jdk/java/time/tck/java/time/chrono/TCKHijrahChronology.java
! test/jdk/java/time/tck/java/time/chrono/TCKHijrahEra.java
! test/jdk/java/time/tck/java/time/chrono/TCKIsoChronology.java
! test/jdk/java/time/tck/java/time/chrono/TCKIsoEra.java
! test/jdk/java/time/tck/java/time/chrono/TCKJapaneseChronology.java
! test/jdk/java/time/tck/java/time/chrono/TCKJapaneseEra.java
! test/jdk/java/time/tck/java/time/chrono/TCKMinguoChronology.java
! test/jdk/java/time/tck/java/time/chrono/TCKMinguoEra.java
! test/jdk/java/time/tck/java/time/chrono/TCKTestServiceLoader.java
! test/jdk/java/time/tck/java/time/chrono/TCKThaiBuddhistChronology.java
! test/jdk/java/time/tck/java/time/chrono/TCKThaiBuddhistEra.java
! test/jdk/java/time/tck/java/time/chrono/serial/TCKChronoLocalDateSerialization.java
! test/jdk/java/time/tck/java/time/chrono/serial/TCKChronoLocalDateTimeSerialization.java
! test/jdk/java/time/tck/java/time/chrono/serial/TCKChronoZonedDateTimeSerialization.java
! test/jdk/java/time/tck/java/time/chrono/serial/TCKChronologySerialization.java
! test/jdk/java/time/tck/java/time/chrono/serial/TCKCopticSerialization.java
! test/jdk/java/time/tck/java/time/chrono/serial/TCKEraSerialization.java
! test/jdk/java/time/tck/java/time/format/TCKChronoPrinterParser.java
! test/jdk/java/time/tck/java/time/format/TCKDTFParsedInstant.java
! test/jdk/java/time/tck/java/time/format/TCKDateTimeFormatter.java
! test/jdk/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java
! test/jdk/java/time/tck/java/time/format/TCKDateTimeFormatters.java
! test/jdk/java/time/tck/java/time/format/TCKDateTimeParseResolver.java
! test/jdk/java/time/tck/java/time/format/TCKDateTimeTextPrinting.java
! test/jdk/java/time/tck/java/time/format/TCKDecimalStyle.java
! test/jdk/java/time/tck/java/time/format/TCKFormatStyle.java
! test/jdk/java/time/tck/java/time/format/TCKInstantPrinterParser.java
! test/jdk/java/time/tck/java/time/format/TCKLocalizedFieldParser.java
! test/jdk/java/time/tck/java/time/format/TCKLocalizedFieldPrinter.java
! test/jdk/java/time/tck/java/time/format/TCKLocalizedOffsetIdPrinterParser.java
! test/jdk/java/time/tck/java/time/format/TCKLocalizedPrinterParser.java
! test/jdk/java/time/tck/java/time/format/TCKOffsetPrinterParser.java
! test/jdk/java/time/tck/java/time/format/TCKPadPrinterParser.java
! test/jdk/java/time/tck/java/time/format/TCKResolverStyle.java
! test/jdk/java/time/tck/java/time/format/TCKSignStyle.java
! test/jdk/java/time/tck/java/time/format/TCKTextStyle.java
! test/jdk/java/time/tck/java/time/format/TCKZoneIdPrinterParser.java
! test/jdk/java/time/tck/java/time/serial/TCKClockSerialization.java
! test/jdk/java/time/tck/java/time/serial/TCKDurationSerialization.java
! test/jdk/java/time/tck/java/time/serial/TCKInstantSerialization.java
! test/jdk/java/time/tck/java/time/serial/TCKLocalDateSerialization.java
! test/jdk/java/time/tck/java/time/serial/TCKLocalDateTimeSerialization.java
! test/jdk/java/time/tck/java/time/serial/TCKLocalTimeSerialization.java
! test/jdk/java/time/tck/java/time/serial/TCKMonthDaySerialization.java
! test/jdk/java/time/tck/java/time/serial/TCKOffsetDateTimeSerialization.java
! test/jdk/java/time/tck/java/time/serial/TCKOffsetTimeSerialization.java
! test/jdk/java/time/tck/java/time/serial/TCKPeriodSerialization.java
! test/jdk/java/time/tck/java/time/serial/TCKYearMonthSerialization.java
! test/jdk/java/time/tck/java/time/serial/TCKYearSerialization.java
! test/jdk/java/time/tck/java/time/serial/TCKZoneIdSerialization.java
! test/jdk/java/time/tck/java/time/serial/TCKZoneOffsetSerialization.java
! test/jdk/java/time/tck/java/time/serial/TCKZonedDateTimeSerialization.java
! test/jdk/java/time/tck/java/time/temporal/TCKChronoField.java
! test/jdk/java/time/tck/java/time/temporal/TCKChronoUnit.java
! test/jdk/java/time/tck/java/time/temporal/TCKIsoFields.java
! test/jdk/java/time/tck/java/time/temporal/TCKJulianFields.java
! test/jdk/java/time/tck/java/time/temporal/TCKTemporalAdjusters.java
! test/jdk/java/time/tck/java/time/temporal/TCKWeekFields.java
! test/jdk/java/time/tck/java/time/temporal/serial/TCKChronoFieldSerialization.java
! test/jdk/java/time/tck/java/time/temporal/serial/TCKChronoUnitSerialization.java
! test/jdk/java/time/tck/java/time/temporal/serial/TCKJulianFieldsSerialization.java
! test/jdk/java/time/tck/java/time/temporal/serial/TCKValueRangeSerialization.java
! test/jdk/java/time/tck/java/time/temporal/serial/TCKWeekFieldsSerialization.java
! test/jdk/java/time/tck/java/time/zone/TCKFixedZoneRules.java
! test/jdk/java/time/tck/java/time/zone/TCKZoneOffsetTransition.java
! test/jdk/java/time/tck/java/time/zone/TCKZoneOffsetTransitionRule.java
! test/jdk/java/time/tck/java/time/zone/TCKZoneRules.java
! test/jdk/java/time/tck/java/time/zone/TCKZoneRulesProvider.java
! test/jdk/java/time/tck/java/time/zone/serial/TCKFixedZoneRulesSerialization.java
! test/jdk/java/time/tck/java/time/zone/serial/TCKZoneOffsetTransitionRuleSerialization.java
! test/jdk/java/time/tck/java/time/zone/serial/TCKZoneOffsetTransitionSerialization.java
! test/jdk/java/time/tck/java/time/zone/serial/TCKZoneRulesSerialization.java
! test/jdk/java/time/test/TEST.properties
! test/jdk/java/time/test/java/time/AbstractTest.java
! test/jdk/java/time/test/java/time/TestClock_Fixed.java
! test/jdk/java/time/test/java/time/TestClock_Offset.java
! test/jdk/java/time/test/java/time/TestClock_System.java
! test/jdk/java/time/test/java/time/TestClock_Tick.java
! test/jdk/java/time/test/java/time/TestDuration.java
! test/jdk/java/time/test/java/time/TestInstant.java
! test/jdk/java/time/test/java/time/TestInstantSource.java
! test/jdk/java/time/test/java/time/TestLocalDate.java
! test/jdk/java/time/test/java/time/TestLocalDateTime.java
! test/jdk/java/time/test/java/time/TestLocalTime.java
! test/jdk/java/time/test/java/time/TestMonthDay.java
! test/jdk/java/time/test/java/time/TestOffsetDateTime.java
! test/jdk/java/time/test/java/time/TestOffsetDateTime_instants.java
! test/jdk/java/time/test/java/time/TestOffsetTime.java
! test/jdk/java/time/test/java/time/TestPeriod.java
! test/jdk/java/time/test/java/time/TestYear.java
! test/jdk/java/time/test/java/time/TestYearMonth.java
! test/jdk/java/time/test/java/time/TestZoneId.java
! test/jdk/java/time/test/java/time/TestZoneOffset.java
! test/jdk/java/time/test/java/time/TestZonedDateTime.java
! test/jdk/java/time/test/java/time/chrono/TestChronoLocalDate.java
! test/jdk/java/time/test/java/time/chrono/TestChronologyPerf.java
! test/jdk/java/time/test/java/time/chrono/TestEraDisplayName.java
! test/jdk/java/time/test/java/time/chrono/TestExampleCode.java
! test/jdk/java/time/test/java/time/chrono/TestIsoChronoImpl.java
! test/jdk/java/time/test/java/time/chrono/TestJapaneseChronoImpl.java
! test/jdk/java/time/test/java/time/chrono/TestJapaneseChronology.java
! test/jdk/java/time/test/java/time/chrono/TestServiceLoader.java
! test/jdk/java/time/test/java/time/chrono/TestThaiBuddhistChronoImpl.java
! test/jdk/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java
! test/jdk/java/time/test/java/time/format/AbstractTestPrinterParser.java
! test/jdk/java/time/test/java/time/format/TestCharLiteralParser.java
! test/jdk/java/time/test/java/time/format/TestCharLiteralPrinter.java
! test/jdk/java/time/test/java/time/format/TestDateTimeFormatter.java
! test/jdk/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java
! test/jdk/java/time/test/java/time/format/TestDateTimeFormatterBuilderWithLocale.java
! test/jdk/java/time/test/java/time/format/TestDateTimeParsing.java
! test/jdk/java/time/test/java/time/format/TestDateTimeTextProvider.java
! test/jdk/java/time/test/java/time/format/TestDateTimeTextProviderWithLocale.java
! test/jdk/java/time/test/java/time/format/TestDecimalStyle.java
! test/jdk/java/time/test/java/time/format/TestFractionPrinterParser.java
! test/jdk/java/time/test/java/time/format/TestLocalizedOffsetPrinterParser.java
! test/jdk/java/time/test/java/time/format/TestLocalizedPattern.java
! test/jdk/java/time/test/java/time/format/TestNarrowMonthNamesAndDayNames.java
! test/jdk/java/time/test/java/time/format/TestNonIsoFormatter.java
! test/jdk/java/time/test/java/time/format/TestNumberParser.java
! test/jdk/java/time/test/java/time/format/TestNumberPrinter.java
! test/jdk/java/time/test/java/time/format/TestPadPrinterDecorator.java
! test/jdk/java/time/test/java/time/format/TestReducedParser.java
! test/jdk/java/time/test/java/time/format/TestReducedPrinter.java
! test/jdk/java/time/test/java/time/format/TestSettingsParser.java
! test/jdk/java/time/test/java/time/format/TestStringLiteralParser.java
! test/jdk/java/time/test/java/time/format/TestStringLiteralPrinter.java
! test/jdk/java/time/test/java/time/format/TestTextParser.java
! test/jdk/java/time/test/java/time/format/TestTextParserWithLocale.java
! test/jdk/java/time/test/java/time/format/TestTextPrinter.java
! test/jdk/java/time/test/java/time/format/TestTextPrinterWithLocale.java
! test/jdk/java/time/test/java/time/format/TestUTCParse.java
! test/jdk/java/time/test/java/time/format/TestUnicodeExtension.java
! test/jdk/java/time/test/java/time/format/TestZoneOffsetParser.java
! test/jdk/java/time/test/java/time/format/TestZoneOffsetPrinter.java
! test/jdk/java/time/test/java/time/format/TestZoneTextPrinterParser.java
! test/jdk/java/time/test/java/time/temporal/TestChronoField.java
! test/jdk/java/time/test/java/time/temporal/TestChronoUnit.java
! test/jdk/java/time/test/java/time/temporal/TestDateTimeBuilderCombinations.java
! test/jdk/java/time/test/java/time/temporal/TestDateTimeValueRange.java
! test/jdk/java/time/test/java/time/temporal/TestIsoFields.java
! test/jdk/java/time/test/java/time/temporal/TestIsoWeekFields.java
! test/jdk/java/time/test/java/time/temporal/TestJulianFields.java
! test/jdk/java/time/test/java/time/zone/TestFixedZoneRules.java
! test/jdk/java/time/test/java/time/zone/TestMutableZoneRules.java
! test/jdk/java/time/test/java/time/zone/TestZoneRules.java
! test/jdk/java/time/test/java/time/zone/TestZoneRulesProvider.java
! test/jdk/java/time/test/java/util/TestFormatter.java

Changeset: 7c979c14
Branch: master
Author:    David Beaumont <david.beaumont at oracle.com>
Committer: Roger Riggs <rriggs at openjdk.org>
Date:      2026-01-06 19:54:49 +0000
URL:       https://git.openjdk.org/loom/commit/7c979c148724ab7de650593caa22df8405d740e5

8374308: ImageBufferCache has no effect and can be removed

Reviewed-by: alanb, rriggs

! src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java
- src/java.base/share/classes/jdk/internal/jimage/ImageBufferCache.java
! src/java.base/share/classes/jdk/internal/jimage/ImageReader.java
! src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java

Changeset: 6b3c1e0f
Branch: master
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
Date:      2026-01-06 23:56:59 +0000
URL:       https://git.openjdk.org/loom/commit/6b3c1e0f786a889d2ac25c8bd05f4d83e666425f

8373833: "error.cert.not.found" and "error.explicit-sign-no-cert" errors duplicate each other

Reviewed-by: almatvee

! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/SigningIdentityBuilder.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources.properties
! test/jdk/tools/jpackage/share/ErrorTest.java

Changeset: 5c6947f7
Branch: master
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-07 06:30:14 +0000
URL:       https://git.openjdk.org/loom/commit/5c6947f736568413d53d5a00de2e865f86e637c4

8373429: gc/g1/TestCodeCacheUnloadDuringConcCycle fails on various platforms

Reviewed-by: mbaesken, mdoerr

! test/hotspot/jtreg/gc/g1/TestCodeCacheUnloadDuringConcCycle.java

Changeset: c1c0ac87
Branch: master
Author:    Damon Fenacci <dfenacci at openjdk.org>
Date:      2026-01-07 07:29:00 +0000
URL:       https://git.openjdk.org/loom/commit/c1c0ac877033c3edb0c2681c2c5f825be8adcfb3

8342772: Assert in LateInlineMHCallGenerator::do_late_inline_check

Reviewed-by: vlivanov, chagedorn, thartmann

! src/hotspot/share/opto/callGenerator.cpp

Changeset: a01283a5
Branch: master
Author:    Ana-Maria Mihalceanu <ana-maria.m.mihalceanu at oracle.com>
Committer: Jaikiran Pai <jpai at openjdk.org>
Date:      2026-01-07 08:24:31 +0000
URL:       https://git.openjdk.org/loom/commit/a01283a5a57723673b1fd3c93434678fdae4102c

8374632: Broken list layout in the man page of jlink

Reviewed-by: jpai

! src/jdk.jlink/share/man/jlink.md

Changeset: 7e18de13
Branch: master
Author:    Volkan Yazici <vyazici at openjdk.org>
Date:      2026-01-07 09:22:38 +0000
URL:       https://git.openjdk.org/loom/commit/7e18de137c3b5f08a479af2b64eb22923261900b

8374210: [BACKOUT] Move input validation checks to Java for java.lang.StringCoding intrinsics

Reviewed-by: shade, thartmann

! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/share/classfile/vmIntrinsics.hpp
! src/hotspot/share/opto/c2_globals.hpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/opto/library_call.hpp
! src/java.base/share/classes/java/lang/String.java
! src/java.base/share/classes/java/lang/StringCoding.java
! src/java.base/share/classes/java/lang/System.java
! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java
! src/java.base/share/classes/sun/nio/cs/CESU_8.java
! src/java.base/share/classes/sun/nio/cs/DoubleByte.java
! src/java.base/share/classes/sun/nio/cs/ISO_8859_1.java
! src/java.base/share/classes/sun/nio/cs/SingleByte.java
! src/java.base/share/classes/sun/nio/cs/US_ASCII.java
! src/java.base/share/classes/sun/nio/cs/UTF_8.java
! src/jdk.charsets/share/classes/sun/nio/cs/ext/EUC_JP.java.template
- test/hotspot/jtreg/compiler/intrinsics/TestVerifyIntrinsicChecks.java
! test/hotspot/jtreg/compiler/intrinsics/string/TestCountPositives.java
! test/hotspot/jtreg/compiler/intrinsics/string/TestEncodeIntrinsics.java
! test/hotspot/jtreg/compiler/intrinsics/string/TestHasNegatives.java
! test/hotspot/jtreg/compiler/patches/java.base/java/lang/Helper.java

Changeset: 2074b975
Branch: master
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2026-01-07 10:06:29 +0000
URL:       https://git.openjdk.org/loom/commit/2074b975c3d08fec2ecd47dab48132be2ec7c3cf

8374623: Move DependentAlwaysFalse variable template to its own file

Reviewed-by: jsjolen

+ src/hotspot/share/metaprogramming/dependentAlwaysFalse.hpp
! src/hotspot/share/runtime/atomic.hpp
! src/hotspot/share/utilities/globalDefinitions.hpp
! src/hotspot/share/utilities/lockFreeStack.hpp

Changeset: f83918c6
Branch: master
Author:    Alan Bateman <alanb at openjdk.org>
Date:      2026-01-07 10:43:11 +0000
URL:       https://git.openjdk.org/loom/commit/f83918c692143802f2e94bed72dfe7121d1742f9

8369227: Virtual thread stuck in PARKED state

Reviewed-by: pchilanomate

! src/java.base/share/classes/java/lang/VirtualThread.java
+ test/jdk/java/lang/Thread/virtual/stress/ParkAfterTimedPark.java
! test/jdk/java/lang/Thread/virtual/stress/TimedWaitALot.java

Changeset: 6af27420
Branch: master
Author:    Alan Bateman <alanb at openjdk.org>
Date:      2026-01-07 10:43:24 +0000
URL:       https://git.openjdk.org/loom/commit/6af27420e3b1980bc093776e3db76072123f7487

8373427: StructuredTaskScope::join not clear if called with interrupted status set

Reviewed-by: jpai

! src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java


From duke at openjdk.org  Wed Jan  7 11:37:24 2026
From: duke at openjdk.org (duke)
Date: Wed, 7 Jan 2026 11:37:24 GMT
Subject: git: openjdk/loom: fibers: 48 new changesets
Message-ID: <8c4b253a-f6b5-451a-9a37-74d911f0c5fa@openjdk.org>

Changeset: 65af6bcb
Branch: fibers
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2026-01-02 09:27:40 +0000
URL:       https://git.openjdk.org/loom/commit/65af6bcb8f74484436b0331032260f2a646f203f

8374371: Failed assertion in G1HeapRegion gtest

Reviewed-by: tschatzl, iwalulya

! test/hotspot/gtest/gc/g1/test_heapRegion.cpp

Changeset: 2ea3c00e
Branch: fibers
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2026-01-02 09:48:40 +0000
URL:       https://git.openjdk.org/loom/commit/2ea3c00e4f2a6e8c0a55039aee6fdfc8194a70a7

4337898: Serializing DefaultTableCellRenderer changes colors

Reviewed-by: azvegint

! src/java.desktop/share/classes/javax/swing/table/DefaultTableCellRenderer.java
+ test/jdk/javax/swing/DefaultTableCellRenderer/DefRendererSerialize.java

Changeset: 05d2f7f4
Branch: fibers
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2026-01-02 09:53:04 +0000
URL:       https://git.openjdk.org/loom/commit/05d2f7f4080f5cc6d3eef97878806e28773d6f70

8373847: Test javax/swing/JMenuItem/MenuItemTest/bug6197830.java failed because The test case automatically fails when clicking any items in the ?Nothing? menu in all four windows (Left-to-right)-Menu Item Test and (Right-to-left)-Menu Item Test

Reviewed-by: serb, aivanov, dnguyen

! test/jdk/javax/swing/JMenuItem/MenuItemTest/bug6197830.java

Changeset: efb79dc6
Branch: fibers
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2026-01-02 10:19:17 +0000
URL:       https://git.openjdk.org/loom/commit/efb79dc6b4907ecf4e1bab3c393ee5cd5fe911a8

8374444: Fix simple -Wzero-as-null-pointer-constant warnings

Reviewed-by: aboldtch

! src/hotspot/share/cds/aotMappedHeapWriter.cpp
! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp
! src/hotspot/share/opto/vectorization.cpp
! src/hotspot/share/runtime/continuationFreezeThaw.cpp
! test/hotspot/gtest/nmt/test_regions_tree.cpp

Changeset: 34395124
Branch: fibers
Author:    Artur Barashev <abarashev at openjdk.org>
Date:      2026-01-02 13:28:15 +0000
URL:       https://git.openjdk.org/loom/commit/34395124018c434b0bad534cb6f85452466fd404

8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket

Reviewed-by: djelinski, mpowers, ascarpino

! src/java.base/share/classes/sun/security/ssl/SessionTicketExtension.java

Changeset: 2daf12ed
Branch: fibers
Author:    Francesco Andreuzzi <fandreuzzi at openjdk.org>
Date:      2026-01-02 14:51:37 +0000
URL:       https://git.openjdk.org/loom/commit/2daf12edd24e641d4d7706d582994c2b3fe95e87

8374465: Spurious dot in documentation for JVMTI ClassLoad

Reviewed-by: kbarrett

! src/hotspot/share/prims/jvmti.xml

Changeset: 53824cf2
Branch: fibers
Author:    Leonid Mesnik <lmesnik at openjdk.org>
Date:      2026-01-03 02:52:53 +0000
URL:       https://git.openjdk.org/loom/commit/53824cf2a97adbc25d32bec0acaff24d105081f9

8343809: Add requires tag to mark tests that are incompatible with exploded image

Reviewed-by: alanb, dholmes

! test/hotspot/jtreg/TEST.ROOT
! test/hotspot/jtreg/runtime/getSysPackage/GetSysPkgTest.java
! test/hotspot/jtreg/runtime/modules/ModulesSymLink.java
! test/hotspot/jtreg/runtime/modules/PatchModule/PatchModuleTraceCL.java
! test/jtreg-ext/requires/VMProps.java

Changeset: 6eaabed5
Branch: fibers
Author:    Xiaohong Gong <xgong at openjdk.org>
Date:      2026-01-05 01:54:31 +0000
URL:       https://git.openjdk.org/loom/commit/6eaabed55ca4670d8c317f0a4323ccea4dd0b9ca

8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently

Reviewed-by: jiefu, jbhateja, erfang, qamai

! test/hotspot/jtreg/compiler/vectorapi/TestVectorOperationsWithPartialSize.java

Changeset: 16303822
Branch: fibers
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2026-01-05 08:27:37 +0000
URL:       https://git.openjdk.org/loom/commit/163038222a371c07aff8bce50eee55bb389104d0

8373704: Improve "SocketException: Protocol family unavailable" message

Reviewed-by: lucy, jpai

! src/java.base/unix/native/libnet/net_util_md.c
! src/java.base/windows/native/libnet/net_util_md.c

Changeset: e676c9de
Branch: fibers
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2026-01-05 09:35:50 +0000
URL:       https://git.openjdk.org/loom/commit/e676c9de3da3b820081cde1b11c0df3129787130

8357258: x86: Improve receiver type profiling reliability

Reviewed-by: kvn, vlivanov

! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp
! src/hotspot/cpu/x86/c1_LIRAssembler_x86.hpp
! src/hotspot/cpu/x86/interp_masm_x86.cpp
! src/hotspot/cpu/x86/interp_masm_x86.hpp
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.hpp
! src/hotspot/cpu/x86/templateTable_x86.cpp
! src/hotspot/share/oops/methodData.hpp

Changeset: eee58545
Branch: fibers
Author:    Daisuke Yamazaki <dyama at openjdk.org>
Committer: Sean Mullan <mullan at openjdk.org>
Date:      2026-01-05 13:19:32 +0000
URL:       https://git.openjdk.org/loom/commit/eee58545c8342fc39b3bec5b38da6c01d92d05f2

8366058: Outdated comment in WinCAPISeedGenerator

Reviewed-by: mullan

! src/java.base/windows/native/libjava/WinCAPISeedGenerator.c

Changeset: 6ae3e064
Branch: fibers
Author:    Roland Westrelin <roland at openjdk.org>
Date:      2026-01-05 14:02:41 +0000
URL:       https://git.openjdk.org/loom/commit/6ae3e064352a56c5be140fba1ad6d040219432b0

8373508: C2: sinking CreateEx out of loop breaks the graph

Reviewed-by: chagedorn, dlong

! src/hotspot/share/opto/loopopts.cpp
+ test/hotspot/jtreg/compiler/loopopts/TestCreateExSunkOutOfLoop.java
+ test/hotspot/jtreg/compiler/loopopts/TestCreateExSunkOutOfLoop2.java

Changeset: 4458cab4
Branch: fibers
Author:    Beno?t Maillard <bmaillard at openjdk.org>
Date:      2026-01-05 14:39:38 +0000
URL:       https://git.openjdk.org/loom/commit/4458cab4b0063f39333392321f542d0aa0db490d

8367627: C2: Missed Ideal() optimization opportunity with MemBar

Reviewed-by: chagedorn, epeter

! src/hotspot/share/opto/graphKit.cpp
! src/hotspot/share/opto/node.cpp
+ test/hotspot/jtreg/compiler/c2/igvn/TestMissingOptMemBarRemovePrecedentEdge.java

Changeset: 27dbdec2
Branch: fibers
Author:    Naoto Sato <naoto at openjdk.org>
Date:      2026-01-05 17:16:35 +0000
URL:       https://git.openjdk.org/loom/commit/27dbdec297fc8030812f7290a7601b6a99defb46

8374217: Remove IO.java test from AOT ProblemList

Reviewed-by: jpai, iklam

! test/jdk/ProblemList-AotJdk.txt
! test/jdk/java/lang/IO/IO.java

Changeset: 5fd095fb
Branch: fibers
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
Date:      2026-01-05 19:16:40 +0000
URL:       https://git.openjdk.org/loom/commit/5fd095fb9b8f1d2000760519d42d7d0068b82651

8372591: assert(!current->cont_fastpath() || freeze.check_valid_fast_path()) failed

Reviewed-by: dholmes, alanb, rrich, fyang

! src/hotspot/share/runtime/sharedRuntime.cpp
+ test/jdk/jdk/internal/vm/Continuation/OSRWithManyLocals.java

Changeset: fa8ea6b3
Branch: fibers
Author:    Alex Menkov <amenkov at openjdk.org>
Date:      2026-01-05 19:55:54 +0000
URL:       https://git.openjdk.org/loom/commit/fa8ea6b32d463a84affa529d37cfb97280503fc6

8374168: Resolve disabled warnings in JDWP agent

Reviewed-by: cjplummer, sspitsyn, erikj

! make/modules/jdk.jdwp.agent/Lib.gmk
! src/jdk.jdwp.agent/share/native/libjdwp/EventRequestImpl.c
! src/jdk.jdwp.agent/share/native/libjdwp/SDE.c
! src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c
! src/jdk.jdwp.agent/share/native/libjdwp/error_messages.c
! src/jdk.jdwp.agent/share/native/libjdwp/eventFilter.c
! src/jdk.jdwp.agent/share/native/libjdwp/inStream.c
! src/jdk.jdwp.agent/share/native/libjdwp/log_messages.c
! src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c
! src/jdk.jdwp.agent/share/native/libjdwp/utf_util.c
! src/jdk.jdwp.agent/share/native/libjdwp/util.h

Changeset: de81d389
Branch: fibers
Author:    David Holmes <dholmes at openjdk.org>
Date:      2026-01-05 20:09:49 +0000
URL:       https://git.openjdk.org/loom/commit/de81d38995356a2e8528a419ebd445e79cd136d1

8374456: JVM crashes with "assert(resolved_method->method_holder()->is_linked()) failed: must be linked" when run with large  value for PreallocatedOutOfMemoryErrorCount

Reviewed-by: coleenp

! src/hotspot/share/runtime/globals.hpp

Changeset: d063c954
Branch: fibers
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2026-01-06 07:40:36 +0000
URL:       https://git.openjdk.org/loom/commit/d063c9546b4a500f4c76fcd01442c2b7281f6d65

8374507: GHA: Limit debug symbols generation to conserve disk space

Reviewed-by: erikj

! .github/workflows/build-alpine-linux.yml
! .github/workflows/build-cross-compile.yml
! .github/workflows/build-linux.yml
! .github/workflows/build-macos.yml
! .github/workflows/build-windows.yml

Changeset: 2fbc4162
Branch: fibers
Author:    Fabian Meumertzheim <fmeum at openjdk.org>
Committer: Alan Bateman <alanb at openjdk.org>
Date:      2026-01-06 08:09:42 +0000
URL:       https://git.openjdk.org/loom/commit/2fbc4162e808f14b6114499f49db3e6ef1590f24

8374441: (fs) FileSystemProvider.readAttributesIfExists throws "Not a directory" when element in path is not directory should return null for ENOTDIR (unix)

Reviewed-by: alanb

! src/java.base/unix/classes/sun/nio/fs/UnixFileAttributes.java
! test/jdk/java/nio/file/Files/NotADirectory.java

Changeset: 2cb228e1
Branch: fibers
Author:    Emanuel Peter <epeter at openjdk.org>
Date:      2026-01-06 08:51:40 +0000
URL:       https://git.openjdk.org/loom/commit/2cb228e142369ec73d768d8a69653a984b1c5908

8374489: Template Library: need to tag Float16.float16ToRawShortBits as having non-deterministic result because of multiple NaN bit patterns

Reviewed-by: chagedorn, kvn

! test/hotspot/jtreg/compiler/lib/template_framework/library/Operations.java

Changeset: 3a80c639
Branch: fibers
Author:    Volkan Yazici <vyazici at openjdk.org>
Date:      2026-01-06 10:21:14 +0000
URL:       https://git.openjdk.org/loom/commit/3a80c639d804a0697b8eb477fe4c96407709449b

8373515: Migrate "test/jdk/java/net/httpclient/" to null-safe "SimpleSSLContext" methods

Reviewed-by: jpai

! test/jdk/java/net/httpclient/ALPNProxyFailureTest.java
! test/jdk/java/net/httpclient/AbstractNoBody.java
! test/jdk/java/net/httpclient/AbstractThrowingPublishers.java
! test/jdk/java/net/httpclient/AbstractThrowingPushPromises.java
! test/jdk/java/net/httpclient/AbstractThrowingSubscribers.java
! test/jdk/java/net/httpclient/AggregateRequestBodyTest.java
! test/jdk/java/net/httpclient/AltServiceUsageTest.java
! test/jdk/java/net/httpclient/AsFileDownloadTest.java
! test/jdk/java/net/httpclient/AsyncExecutorShutdown.java
! test/jdk/java/net/httpclient/AsyncShutdownNow.java
! test/jdk/java/net/httpclient/AuthFilterCacheTest.java
! test/jdk/java/net/httpclient/BasicAuthTest.java
! test/jdk/java/net/httpclient/BasicHTTP2Test.java
! test/jdk/java/net/httpclient/BasicHTTP3Test.java
! test/jdk/java/net/httpclient/BasicRedirectTest.java
! test/jdk/java/net/httpclient/BufferSize1Test.java
! test/jdk/java/net/httpclient/CancelRequestTest.java
! test/jdk/java/net/httpclient/CancelStreamedBodyTest.java
! test/jdk/java/net/httpclient/CancelledPartialResponseTest.java
! test/jdk/java/net/httpclient/CancelledResponse.java
! test/jdk/java/net/httpclient/CancelledResponse2.java
! test/jdk/java/net/httpclient/ConcurrentResponses.java
! test/jdk/java/net/httpclient/ContentLengthHeaderTest.java
! test/jdk/java/net/httpclient/CookieHeaderTest.java
! test/jdk/java/net/httpclient/CustomRequestPublisher.java
! test/jdk/java/net/httpclient/CustomResponseSubscriber.java
! test/jdk/java/net/httpclient/DependentActionsTest.java
! test/jdk/java/net/httpclient/DependentPromiseActionsTest.java
! test/jdk/java/net/httpclient/DigestEchoClient.java
! test/jdk/java/net/httpclient/DurationOverflowTest.java
! test/jdk/java/net/httpclient/EmptyAuthenticate.java
! test/jdk/java/net/httpclient/EncodedCharsInURI.java
! test/jdk/java/net/httpclient/EscapedOctetsInURI.java
! test/jdk/java/net/httpclient/ExecutorShutdown.java
! test/jdk/java/net/httpclient/ExpectContinue.java
! test/jdk/java/net/httpclient/FileChannelPublisherTest.java
! test/jdk/java/net/httpclient/FilePublisherTest.java
! test/jdk/java/net/httpclient/FlowAdapterPublisherTest.java
! test/jdk/java/net/httpclient/FlowAdapterSubscriberTest.java
! test/jdk/java/net/httpclient/ForbiddenHeadTest.java
! test/jdk/java/net/httpclient/GZIPInputStreamTest.java
! test/jdk/java/net/httpclient/HeadTest.java
! test/jdk/java/net/httpclient/HeadersLowerCaseTest.java
! test/jdk/java/net/httpclient/HttpClientAuthRetryLimitTest.java
! test/jdk/java/net/httpclient/HttpClientBuilderTest.java
! test/jdk/java/net/httpclient/HttpClientClose.java
! test/jdk/java/net/httpclient/HttpClientLocalAddrTest.java
! test/jdk/java/net/httpclient/HttpClientSNITest.java
! test/jdk/java/net/httpclient/HttpClientShutdown.java
! test/jdk/java/net/httpclient/HttpGetInCancelledFuture.java
! test/jdk/java/net/httpclient/HttpRedirectTest.java
! test/jdk/java/net/httpclient/HttpResponseConnectionLabelTest.java
! test/jdk/java/net/httpclient/HttpResponseLimitingTest.java
! test/jdk/java/net/httpclient/HttpSlowServerTest.java
! test/jdk/java/net/httpclient/HttpVersionsTest.java
! test/jdk/java/net/httpclient/HttpsTunnelAuthTest.java
! test/jdk/java/net/httpclient/HttpsTunnelTest.java
! test/jdk/java/net/httpclient/ISO_8859_1_Test.java
! test/jdk/java/net/httpclient/IdleConnectionTimeoutTest.java
! test/jdk/java/net/httpclient/ImmutableFlowItems.java
! test/jdk/java/net/httpclient/ImmutableSSLSessionTest.java
! test/jdk/java/net/httpclient/InvalidInputStreamSubscriptionRequest.java
! test/jdk/java/net/httpclient/InvalidSSLContextTest.java
! test/jdk/java/net/httpclient/InvalidSubscriptionRequest.java
! test/jdk/java/net/httpclient/LargeResponseTest.java
! test/jdk/java/net/httpclient/LightWeightHttpServer.java
! test/jdk/java/net/httpclient/LineBodyHandlerTest.java
! test/jdk/java/net/httpclient/ManyRequests.java
! test/jdk/java/net/httpclient/ManyRequestsLegacy.java
! test/jdk/java/net/httpclient/MappingResponseSubscriber.java
! test/jdk/java/net/httpclient/MaxStreams.java
! test/jdk/java/net/httpclient/NonAsciiCharsInURI.java
! test/jdk/java/net/httpclient/PathSubscriber/BodyHandlerOfFileDownloadTest.java
! test/jdk/java/net/httpclient/PathSubscriber/BodyHandlerOfFileTest.java
! test/jdk/java/net/httpclient/PathSubscriber/BodySubscriberOfFileTest.java
! test/jdk/java/net/httpclient/PlainConnectionLockTest.java
! test/jdk/java/net/httpclient/ProxySelectorTest.java
! test/jdk/java/net/httpclient/ProxyTest.java
! test/jdk/java/net/httpclient/RedirectMethodChange.java
! test/jdk/java/net/httpclient/RedirectTimeoutTest.java
! test/jdk/java/net/httpclient/RedirectWithCookie.java
! test/jdk/java/net/httpclient/Response1xxTest.java
! test/jdk/java/net/httpclient/Response204V2Test.java
! test/jdk/java/net/httpclient/ResponseBodyBeforeError.java
! test/jdk/java/net/httpclient/ResponsePublisher.java
! test/jdk/java/net/httpclient/RetryWithCookie.java
! test/jdk/java/net/httpclient/ServerCloseTest.java
! test/jdk/java/net/httpclient/ShortResponseBody.java
! test/jdk/java/net/httpclient/ShutdownNow.java
! test/jdk/java/net/httpclient/SmokeTest.java
! test/jdk/java/net/httpclient/SpecialHeadersTest.java
! test/jdk/java/net/httpclient/SplitResponse.java
! test/jdk/java/net/httpclient/StreamingBody.java
! test/jdk/java/net/httpclient/TimeoutBasic.java
! test/jdk/java/net/httpclient/TimeoutResponseTestSupport.java
! test/jdk/java/net/httpclient/TlsContextTest.java
! test/jdk/java/net/httpclient/UnauthorizedTest.java
! test/jdk/java/net/httpclient/UnknownBodyLengthTest.java
! test/jdk/java/net/httpclient/UserAuthWithAuthenticator.java
! test/jdk/java/net/httpclient/UserCookieTest.java
! test/jdk/java/net/httpclient/http2/BadHeadersTest.java
! test/jdk/java/net/httpclient/http2/BasicTest.java
! test/jdk/java/net/httpclient/http2/ConnectionFlowControlTest.java
! test/jdk/java/net/httpclient/http2/ConnectionReuseTest.java
! test/jdk/java/net/httpclient/http2/ContinuationFrameTest.java
! test/jdk/java/net/httpclient/http2/ErrorTest.java
! test/jdk/java/net/httpclient/http2/FixedThreadPoolTest.java
! test/jdk/java/net/httpclient/http2/H2GoAwayTest.java
! test/jdk/java/net/httpclient/http2/H2SelectorVTTest.java
! test/jdk/java/net/httpclient/http2/NoBodyTest.java
! test/jdk/java/net/httpclient/http2/ProxyTest2.java
! test/jdk/java/net/httpclient/http2/SimpleGet.java
! test/jdk/java/net/httpclient/http2/StreamFlowControlTest.java
! test/jdk/java/net/httpclient/http2/UserInfoTest.java
! test/jdk/java/net/httpclient/http3/BadCipherSuiteErrorTest.java
! test/jdk/java/net/httpclient/http3/GetHTTP3Test.java
! test/jdk/java/net/httpclient/http3/H3BadHeadersTest.java
! test/jdk/java/net/httpclient/http3/H3BasicTest.java
! test/jdk/java/net/httpclient/http3/H3ConcurrentPush.java
! test/jdk/java/net/httpclient/http3/H3ConnectionPoolTest.java
! test/jdk/java/net/httpclient/http3/H3DataLimitsTest.java
! test/jdk/java/net/httpclient/http3/H3ErrorHandlingTest.java
! test/jdk/java/net/httpclient/http3/H3FixedThreadPoolTest.java
! test/jdk/java/net/httpclient/http3/H3GoAwayTest.java
! test/jdk/java/net/httpclient/http3/H3HeaderSizeLimitTest.java
! test/jdk/java/net/httpclient/http3/H3HeadersEncoding.java
! test/jdk/java/net/httpclient/http3/H3IdleExceedsQuicIdleTimeout.java
! test/jdk/java/net/httpclient/http3/H3ImplicitPushCancel.java
! test/jdk/java/net/httpclient/http3/H3InsertionsLimitTest.java
! test/jdk/java/net/httpclient/http3/H3LogHandshakeErrors.java
! test/jdk/java/net/httpclient/http3/H3MalformedResponseTest.java
! test/jdk/java/net/httpclient/http3/H3MaxInitialTimeoutTest.java
! test/jdk/java/net/httpclient/http3/H3MemoryHandlingTest.java
! test/jdk/java/net/httpclient/http3/H3MultipleConnectionsToSameHost.java
! test/jdk/java/net/httpclient/http3/H3ProxyTest.java
! test/jdk/java/net/httpclient/http3/H3PushCancel.java
! test/jdk/java/net/httpclient/http3/H3QuicTLSConnection.java
! test/jdk/java/net/httpclient/http3/H3QuicVTTest.java
! test/jdk/java/net/httpclient/http3/H3RedirectTest.java
! test/jdk/java/net/httpclient/http3/H3RequestRejectedTest.java
! test/jdk/java/net/httpclient/http3/H3ServerPush.java
! test/jdk/java/net/httpclient/http3/H3ServerPushCancel.java
! test/jdk/java/net/httpclient/http3/H3ServerPushTest.java
! test/jdk/java/net/httpclient/http3/H3ServerPushWithDiffTypes.java
! test/jdk/java/net/httpclient/http3/H3SimpleGet.java
! test/jdk/java/net/httpclient/http3/H3SimplePost.java
! test/jdk/java/net/httpclient/http3/H3SimpleTest.java
! test/jdk/java/net/httpclient/http3/H3StopSendingTest.java
! test/jdk/java/net/httpclient/http3/H3StreamLimitReachedTest.java
! test/jdk/java/net/httpclient/http3/H3Timeout.java
! test/jdk/java/net/httpclient/http3/H3UserInfoTest.java
! test/jdk/java/net/httpclient/http3/HTTP3NoBodyTest.java
! test/jdk/java/net/httpclient/http3/Http3ExpectContinueTest.java
! test/jdk/java/net/httpclient/http3/PostHTTP3Test.java
! test/jdk/java/net/httpclient/http3/StopSendingTest.java
! test/jdk/java/net/httpclient/http3/StreamLimitTest.java
! test/jdk/java/net/httpclient/quic/KeyUpdateTest.java
! test/jdk/java/net/httpclient/quic/PacketLossTest.java
! test/jdk/java/net/httpclient/quic/QuicRequestResponseTest.java
! test/jdk/java/net/httpclient/quic/StatelessResetReceiptTest.java
! test/jdk/java/net/httpclient/quic/VersionNegotiationTest.java
! test/jdk/java/net/httpclient/quic/tls/QuicTLSEngineBadParametersTest.java
! test/jdk/java/net/httpclient/quic/tls/QuicTLSEngineFailedALPNTest.java
! test/jdk/java/net/httpclient/quic/tls/QuicTLSEngineMissingParametersTest.java
! test/jdk/java/net/httpclient/websocket/HandshakeUrlEncodingTest.java
! test/jdk/java/net/httpclient/websocket/WSHandshakeExceptionTest.java
! test/jdk/java/net/httpclient/websocket/WebSocketProxyTest.java
! test/jdk/java/net/httpclient/whitebox/AltSvcFrameTest.java
! test/jdk/java/net/httpclient/whitebox/AltSvcRegistryTest.java
! test/jdk/java/net/httpclient/whitebox/FlowTestDriver.java
! test/jdk/java/net/httpclient/whitebox/SSLEchoTubeTestDriver.java
! test/jdk/java/net/httpclient/whitebox/SSLFlowDelegateTestDriver.java
! test/jdk/java/net/httpclient/whitebox/SSLTubeTestDriver.java
! test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/AbstractSSLTubeTest.java
! test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/FlowTest.java
! test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/SSLFlowDelegateTest.java
! test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/SSLTubeTest.java
- test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/SimpleSSLContext.java
+ test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/SimpleSSLContextWhiteboxAdapter.java

Changeset: 938bbd5b
Branch: fibers
Author:    Christian Hagedorn <chagedorn at openjdk.org>
Date:      2026-01-06 10:23:45 +0000
URL:       https://git.openjdk.org/loom/commit/938bbd5b604e990514b64a0451ed1bceb07eb23b

8374518: C1: Remove dead LinearScanStatistic::Counter::counter_fpu_stack

Reviewed-by: thartmann, mdoerr

! src/hotspot/share/c1/c1_LinearScan.hpp
+ test/hotspot/jtreg/compiler/c1/TestCITimeCountLinearScan.java

Changeset: 5df183be
Branch: fibers
Author:    Johny Jose <johny.jose at oracle.com>
Committer: Sean Coffey <coffeys at openjdk.org>
Date:      2026-01-06 10:36:41 +0000
URL:       https://git.openjdk.org/loom/commit/5df183be6c484d8f9635fac149caf5e2079c5561

8373476: (tz) Update Timezone Data to 2025c

Reviewed-by: coffeys, naoto

! src/java.base/share/data/tzdata/VERSION
! src/java.base/share/data/tzdata/africa
! src/java.base/share/data/tzdata/antarctica
! src/java.base/share/data/tzdata/asia
! src/java.base/share/data/tzdata/australasia
! src/java.base/share/data/tzdata/europe
! src/java.base/share/data/tzdata/iso3166.tab
! src/java.base/share/data/tzdata/leapseconds
! src/java.base/share/data/tzdata/northamerica
! src/java.base/share/data/tzdata/southamerica
! test/jdk/java/util/TimeZone/TimeZoneData/VERSION

Changeset: 532a0a65
Branch: fibers
Author:    Fernando Guallini <fguallini at openjdk.org>
Date:      2026-01-06 10:53:27 +0000
URL:       https://git.openjdk.org/loom/commit/532a0a65b130e1fbe74ccbd16cdeed258cc2c245

8372950: Pem.pemEncoded should cache the Pattern

Reviewed-by: ascarpino

! src/java.base/share/classes/sun/security/util/Pem.java

Changeset: df5b49e6
Branch: fibers
Author:    Dingli Zhang <dzhang at openjdk.org>
Date:      2026-01-06 12:49:16 +0000
URL:       https://git.openjdk.org/loom/commit/df5b49e604d3204c6383484ba3807d39abd0b0f1

8374525: RISC-V: Several masked float16 vector operations are not supported

Reviewed-by: fjiang, fyang

! src/hotspot/cpu/riscv/riscv_v.ad

Changeset: e27309f1
Branch: fibers
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2026-01-06 15:00:45 +0000
URL:       https://git.openjdk.org/loom/commit/e27309f10d32695972f468df17b2535d36a746a2

8374350: Convert hotspot gtests to use Atomic<T>

Reviewed-by: aboldtch, iwalulya

! test/hotspot/gtest/cds/test_archiveWorkers.cpp
! test/hotspot/gtest/gc/g1/test_g1BatchedGangTask.cpp
! test/hotspot/gtest/gc/g1/test_g1CardSet.cpp
! test/hotspot/gtest/gc/g1/test_stressCommitUncommit.cpp
! test/hotspot/gtest/gc/shared/test_bufferNodeAllocator.cpp
! test/hotspot/gtest/utilities/test_concurrentHashtable.cpp
! test/hotspot/gtest/utilities/test_globalCounter_nested.cpp
! test/hotspot/gtest/utilities/test_singleWriterSynchronizer.cpp
! test/hotspot/gtest/utilities/test_waitBarrier.cpp

Changeset: 32144282
Branch: fibers
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2026-01-06 15:05:29 +0000
URL:       https://git.openjdk.org/loom/commit/3214428203642e986c47eabc29ebdea93016b2c5

8374446: Fix -Wzero-as-null-pointer-constant warnings in test_compressedKlass.cpp

Reviewed-by: dholmes

! test/hotspot/gtest/oops/test_compressedKlass.cpp

Changeset: c611da25
Branch: fibers
Author:    Leonid Mesnik <lmesnik at openjdk.org>
Date:      2026-01-06 15:48:53 +0000
URL:       https://git.openjdk.org/loom/commit/c611da257f69e9c9b178b85cb705a4b0a42545ac

8374483: Eliminate :serviceability_ttf_virtual group and mark svc non-virtual tests with requires

Reviewed-by: syan, dholmes

! test/hotspot/jtreg/TEST.groups
! test/hotspot/jtreg/serviceability/jvmti/events/Breakpoint/breakpoint01/breakpoint01.java
! test/hotspot/jtreg/serviceability/jvmti/events/ClassLoad/classload01/classload01.java
! test/hotspot/jtreg/serviceability/jvmti/events/ClassPrepare/classprep01/classprep01.java
! test/hotspot/jtreg/serviceability/jvmti/events/MethodEntry/mentry02/mentry02.java
! test/hotspot/jtreg/serviceability/jvmti/events/MonitorWaited/monitorwaited01/monitorwaited01.java
! test/hotspot/jtreg/serviceability/jvmti/negative/thrinfo02/thrinfo02.java
! test/hotspot/jtreg/serviceability/jvmti/thread/GetThreadInfo/thrinfo01/thrinfo01.java
! test/hotspot/jtreg/serviceability/jvmti/vthread/BoundVThreadTest/BoundVThreadTest.java
! test/hotspot/jtreg/serviceability/jvmti/vthread/ContinuationTest/ContinuationTest.java
! test/hotspot/jtreg/serviceability/jvmti/vthread/FollowReferences/VThreadStackRefTest.java
! test/hotspot/jtreg/serviceability/jvmti/vthread/SelfSuspendDisablerTest/SelfSuspendDisablerTest.java
! test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/SuspendResume1.java
! test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume2/SuspendResume2.java
! test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResumeAll/SuspendResumeAll.java
! test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadTLSTest/VThreadTLSTest.java
! test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadTest/VThreadTest.java
! test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadUnsupportedTest/VThreadUnsupportedTest.java
! test/hotspot/jtreg/serviceability/jvmti/vthread/WaitNotifySuspendedVThreadTest/WaitNotifySuspendedVThreadTest.java

Changeset: 11f0bd94
Branch: fibers
Author:    Alan Bateman <alan.bateman at oracle.com>
Date:      2026-01-06 15:55:33 +0000
URL:       https://git.openjdk.org/loom/commit/11f0bd945f4adce509b348b4dec5f8ffbf7e5b68

Merge branch 'master' into fibers

! src/hotspot/share/runtime/globals.hpp
! test/hotspot/jtreg/TEST.groups
! src/hotspot/share/runtime/globals.hpp
! test/hotspot/jtreg/TEST.groups

Changeset: d6e5874c
Branch: fibers
Author:    Alan Bateman <alan.bateman at oracle.com>
Date:      2026-01-02 07:21:05 +0000
URL:       https://git.openjdk.org/loom/commit/d6e5874cdb3bfe8c6ed30aae79e71873625e90d0

Remove left over code

! src/hotspot/share/prims/jvm.cpp

Changeset: 047a5abd
Branch: fibers
Author:    Alan Bateman <alan.bateman at oracle.com>
Date:      2026-01-06 15:56:17 +0000
URL:       https://git.openjdk.org/loom/commit/047a5abd76de1855c4a462829682579f5fa53799

Merge loom into fibers


Changeset: 136ac0d1
Branch: fibers
Author:    Naoto Sato <naoto at openjdk.org>
Date:      2026-01-06 16:28:33 +0000
URL:       https://git.openjdk.org/loom/commit/136ac0d10b92df8875f36c717e85595740b50ed2

8374433: java/util/Locale/PreserveTagCase.java does not run any tests

Reviewed-by: iris, joehw, jlu

! test/jdk/java/util/Locale/PreserveTagCase.java

Changeset: 3f652159
Branch: fibers
Author:    Daniel Gredler <dgredler at openjdk.org>
Date:      2026-01-06 16:52:21 +0000
URL:       https://git.openjdk.org/loom/commit/3f6521596014510b75318b53ef4aef6b01056545

8374340: FontRenderContext instance variables should be final

Reviewed-by: aivanov, aturbanov, prr, serb

! src/java.desktop/share/classes/java/awt/font/FontRenderContext.java

Changeset: 62181b63
Branch: fibers
Author:    Daniel Gredler <dgredler at openjdk.org>
Date:      2026-01-06 17:56:43 +0000
URL:       https://git.openjdk.org/loom/commit/62181b6363926968298ed37ac7780ee6d5ef0916

6562639: Wrong pixel bounds from TextLayout with white font

Reviewed-by: serb, prr

! src/java.desktop/share/classes/java/awt/font/TextLine.java
+ test/jdk/java/awt/font/TextLayout/TestGetPixelBoundsWithColors.java

Changeset: cdbc493a
Branch: fibers
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2026-01-06 17:57:02 +0000
URL:       https://git.openjdk.org/loom/commit/cdbc493a6d93a0da0db987245daa7b1d00cc8add

8374190: Convert ConcurrentHashTable atomic lists to use Atomic<T>

Reviewed-by: dholmes, iwalulya

! src/hotspot/share/utilities/concurrentHashTable.hpp
! src/hotspot/share/utilities/concurrentHashTable.inline.hpp

Changeset: fbc59ac0
Branch: fibers
Author:    Weijun Wang <weijun at openjdk.org>
Date:      2026-01-06 18:05:27 +0000
URL:       https://git.openjdk.org/loom/commit/fbc59ac0a1248066e9fbcfde3bd6a8eb4d60992c

8374555: No need for visible input warning in s.s.u.Password when not reading from System.in

Reviewed-by: coffeys, hchao

! src/java.base/share/classes/sun/security/util/Password.java
+ test/jdk/sun/security/util/Password/EmptyIn.java

Changeset: f1e0e0c2
Branch: fibers
Author:    Roger Riggs <rriggs at openjdk.org>
Date:      2026-01-06 18:07:43 +0000
URL:       https://git.openjdk.org/loom/commit/f1e0e0c25ec62a543b9cbfabd630fc4ef17a8b5c

8374544: Add SleepyCat diagnostics for all platforms

Reviewed-by: jpai

! test/jdk/java/lang/RuntimeTests/exec/SleepyCat.java
= test/jdk/java/lang/RuntimeTests/exec/TEST.properties

Changeset: 53300b4a
Branch: fibers
Author:    Justin Lu <jlu at openjdk.org>
Date:      2026-01-06 19:24:43 +0000
URL:       https://git.openjdk.org/loom/commit/53300b4ac12240ea08227386412bfb90650c0aee

8373830: Refactor test/jdk/java/time/test tests to use JUnit over TestNG
8373829: Refactor test/jdk/java/time/tck tests to use JUnit over TestNG

Reviewed-by: naoto

= test/jdk/java/time/nonjunit/java/time/chrono/HijrahConfigCheck.java
= test/jdk/java/time/nonjunit/java/time/chrono/HijrahConfigTest.java
= test/jdk/java/time/nonjunit/java/time/chrono/hijrah-config-Hijrah-test_islamic-test.properties
= test/jdk/java/time/nonjunit/java/time/zone/CustomZoneNameTest.java
= test/jdk/java/time/nonjunit/java/time/zone/zoneProvider/META-INF/services/java.time.zone.ZoneRulesProvider
= test/jdk/java/time/nonjunit/java/time/zone/zoneProvider/META-INF/services/java.util.spi.TimeZoneNameProvider
= test/jdk/java/time/nonjunit/java/time/zone/zoneProvider/custom/CustomTimeZoneNameProvider.java
= test/jdk/java/time/nonjunit/java/time/zone/zoneProvider/custom/CustomZoneRulesProvider.java
! test/jdk/java/time/tck/TEST.properties
! test/jdk/java/time/tck/java/time/AbstractDateTimeTest.java
! test/jdk/java/time/tck/java/time/AbstractTCKTest.java
! test/jdk/java/time/tck/java/time/TCKClock.java
! test/jdk/java/time/tck/java/time/TCKClock_Fixed.java
! test/jdk/java/time/tck/java/time/TCKClock_Offset.java
! test/jdk/java/time/tck/java/time/TCKClock_System.java
! test/jdk/java/time/tck/java/time/TCKClock_Tick.java
! test/jdk/java/time/tck/java/time/TCKDayOfWeek.java
! test/jdk/java/time/tck/java/time/TCKDuration.java
! test/jdk/java/time/tck/java/time/TCKInstant.java
! test/jdk/java/time/tck/java/time/TCKLocalDate.java
! test/jdk/java/time/tck/java/time/TCKLocalDateTime.java
! test/jdk/java/time/tck/java/time/TCKLocalTime.java
! test/jdk/java/time/tck/java/time/TCKMonth.java
! test/jdk/java/time/tck/java/time/TCKMonthDay.java
! test/jdk/java/time/tck/java/time/TCKOffsetDateTime.java
! test/jdk/java/time/tck/java/time/TCKOffsetTime.java
! test/jdk/java/time/tck/java/time/TCKPeriod.java
! test/jdk/java/time/tck/java/time/TCKYear.java
! test/jdk/java/time/tck/java/time/TCKYearMonth.java
! test/jdk/java/time/tck/java/time/TCKZoneId.java
! test/jdk/java/time/tck/java/time/TCKZoneOffset.java
! test/jdk/java/time/tck/java/time/TCKZonedDateTime.java
! test/jdk/java/time/tck/java/time/TestIsoChronology.java
! test/jdk/java/time/tck/java/time/chrono/TCKChronoLocalDate.java
! test/jdk/java/time/tck/java/time/chrono/TCKChronoLocalDateTime.java
! test/jdk/java/time/tck/java/time/chrono/TCKChronoPeriod.java
! test/jdk/java/time/tck/java/time/chrono/TCKChronoZonedDateTime.java
! test/jdk/java/time/tck/java/time/chrono/TCKChronology.java
! test/jdk/java/time/tck/java/time/chrono/TCKHijrahChronology.java
! test/jdk/java/time/tck/java/time/chrono/TCKHijrahEra.java
! test/jdk/java/time/tck/java/time/chrono/TCKIsoChronology.java
! test/jdk/java/time/tck/java/time/chrono/TCKIsoEra.java
! test/jdk/java/time/tck/java/time/chrono/TCKJapaneseChronology.java
! test/jdk/java/time/tck/java/time/chrono/TCKJapaneseEra.java
! test/jdk/java/time/tck/java/time/chrono/TCKMinguoChronology.java
! test/jdk/java/time/tck/java/time/chrono/TCKMinguoEra.java
! test/jdk/java/time/tck/java/time/chrono/TCKTestServiceLoader.java
! test/jdk/java/time/tck/java/time/chrono/TCKThaiBuddhistChronology.java
! test/jdk/java/time/tck/java/time/chrono/TCKThaiBuddhistEra.java
! test/jdk/java/time/tck/java/time/chrono/serial/TCKChronoLocalDateSerialization.java
! test/jdk/java/time/tck/java/time/chrono/serial/TCKChronoLocalDateTimeSerialization.java
! test/jdk/java/time/tck/java/time/chrono/serial/TCKChronoZonedDateTimeSerialization.java
! test/jdk/java/time/tck/java/time/chrono/serial/TCKChronologySerialization.java
! test/jdk/java/time/tck/java/time/chrono/serial/TCKCopticSerialization.java
! test/jdk/java/time/tck/java/time/chrono/serial/TCKEraSerialization.java
! test/jdk/java/time/tck/java/time/format/TCKChronoPrinterParser.java
! test/jdk/java/time/tck/java/time/format/TCKDTFParsedInstant.java
! test/jdk/java/time/tck/java/time/format/TCKDateTimeFormatter.java
! test/jdk/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java
! test/jdk/java/time/tck/java/time/format/TCKDateTimeFormatters.java
! test/jdk/java/time/tck/java/time/format/TCKDateTimeParseResolver.java
! test/jdk/java/time/tck/java/time/format/TCKDateTimeTextPrinting.java
! test/jdk/java/time/tck/java/time/format/TCKDecimalStyle.java
! test/jdk/java/time/tck/java/time/format/TCKFormatStyle.java
! test/jdk/java/time/tck/java/time/format/TCKInstantPrinterParser.java
! test/jdk/java/time/tck/java/time/format/TCKLocalizedFieldParser.java
! test/jdk/java/time/tck/java/time/format/TCKLocalizedFieldPrinter.java
! test/jdk/java/time/tck/java/time/format/TCKLocalizedOffsetIdPrinterParser.java
! test/jdk/java/time/tck/java/time/format/TCKLocalizedPrinterParser.java
! test/jdk/java/time/tck/java/time/format/TCKOffsetPrinterParser.java
! test/jdk/java/time/tck/java/time/format/TCKPadPrinterParser.java
! test/jdk/java/time/tck/java/time/format/TCKResolverStyle.java
! test/jdk/java/time/tck/java/time/format/TCKSignStyle.java
! test/jdk/java/time/tck/java/time/format/TCKTextStyle.java
! test/jdk/java/time/tck/java/time/format/TCKZoneIdPrinterParser.java
! test/jdk/java/time/tck/java/time/serial/TCKClockSerialization.java
! test/jdk/java/time/tck/java/time/serial/TCKDurationSerialization.java
! test/jdk/java/time/tck/java/time/serial/TCKInstantSerialization.java
! test/jdk/java/time/tck/java/time/serial/TCKLocalDateSerialization.java
! test/jdk/java/time/tck/java/time/serial/TCKLocalDateTimeSerialization.java
! test/jdk/java/time/tck/java/time/serial/TCKLocalTimeSerialization.java
! test/jdk/java/time/tck/java/time/serial/TCKMonthDaySerialization.java
! test/jdk/java/time/tck/java/time/serial/TCKOffsetDateTimeSerialization.java
! test/jdk/java/time/tck/java/time/serial/TCKOffsetTimeSerialization.java
! test/jdk/java/time/tck/java/time/serial/TCKPeriodSerialization.java
! test/jdk/java/time/tck/java/time/serial/TCKYearMonthSerialization.java
! test/jdk/java/time/tck/java/time/serial/TCKYearSerialization.java
! test/jdk/java/time/tck/java/time/serial/TCKZoneIdSerialization.java
! test/jdk/java/time/tck/java/time/serial/TCKZoneOffsetSerialization.java
! test/jdk/java/time/tck/java/time/serial/TCKZonedDateTimeSerialization.java
! test/jdk/java/time/tck/java/time/temporal/TCKChronoField.java
! test/jdk/java/time/tck/java/time/temporal/TCKChronoUnit.java
! test/jdk/java/time/tck/java/time/temporal/TCKIsoFields.java
! test/jdk/java/time/tck/java/time/temporal/TCKJulianFields.java
! test/jdk/java/time/tck/java/time/temporal/TCKTemporalAdjusters.java
! test/jdk/java/time/tck/java/time/temporal/TCKWeekFields.java
! test/jdk/java/time/tck/java/time/temporal/serial/TCKChronoFieldSerialization.java
! test/jdk/java/time/tck/java/time/temporal/serial/TCKChronoUnitSerialization.java
! test/jdk/java/time/tck/java/time/temporal/serial/TCKJulianFieldsSerialization.java
! test/jdk/java/time/tck/java/time/temporal/serial/TCKValueRangeSerialization.java
! test/jdk/java/time/tck/java/time/temporal/serial/TCKWeekFieldsSerialization.java
! test/jdk/java/time/tck/java/time/zone/TCKFixedZoneRules.java
! test/jdk/java/time/tck/java/time/zone/TCKZoneOffsetTransition.java
! test/jdk/java/time/tck/java/time/zone/TCKZoneOffsetTransitionRule.java
! test/jdk/java/time/tck/java/time/zone/TCKZoneRules.java
! test/jdk/java/time/tck/java/time/zone/TCKZoneRulesProvider.java
! test/jdk/java/time/tck/java/time/zone/serial/TCKFixedZoneRulesSerialization.java
! test/jdk/java/time/tck/java/time/zone/serial/TCKZoneOffsetTransitionRuleSerialization.java
! test/jdk/java/time/tck/java/time/zone/serial/TCKZoneOffsetTransitionSerialization.java
! test/jdk/java/time/tck/java/time/zone/serial/TCKZoneRulesSerialization.java
! test/jdk/java/time/test/TEST.properties
! test/jdk/java/time/test/java/time/AbstractTest.java
! test/jdk/java/time/test/java/time/TestClock_Fixed.java
! test/jdk/java/time/test/java/time/TestClock_Offset.java
! test/jdk/java/time/test/java/time/TestClock_System.java
! test/jdk/java/time/test/java/time/TestClock_Tick.java
! test/jdk/java/time/test/java/time/TestDuration.java
! test/jdk/java/time/test/java/time/TestInstant.java
! test/jdk/java/time/test/java/time/TestInstantSource.java
! test/jdk/java/time/test/java/time/TestLocalDate.java
! test/jdk/java/time/test/java/time/TestLocalDateTime.java
! test/jdk/java/time/test/java/time/TestLocalTime.java
! test/jdk/java/time/test/java/time/TestMonthDay.java
! test/jdk/java/time/test/java/time/TestOffsetDateTime.java
! test/jdk/java/time/test/java/time/TestOffsetDateTime_instants.java
! test/jdk/java/time/test/java/time/TestOffsetTime.java
! test/jdk/java/time/test/java/time/TestPeriod.java
! test/jdk/java/time/test/java/time/TestYear.java
! test/jdk/java/time/test/java/time/TestYearMonth.java
! test/jdk/java/time/test/java/time/TestZoneId.java
! test/jdk/java/time/test/java/time/TestZoneOffset.java
! test/jdk/java/time/test/java/time/TestZonedDateTime.java
! test/jdk/java/time/test/java/time/chrono/TestChronoLocalDate.java
! test/jdk/java/time/test/java/time/chrono/TestChronologyPerf.java
! test/jdk/java/time/test/java/time/chrono/TestEraDisplayName.java
! test/jdk/java/time/test/java/time/chrono/TestExampleCode.java
! test/jdk/java/time/test/java/time/chrono/TestIsoChronoImpl.java
! test/jdk/java/time/test/java/time/chrono/TestJapaneseChronoImpl.java
! test/jdk/java/time/test/java/time/chrono/TestJapaneseChronology.java
! test/jdk/java/time/test/java/time/chrono/TestServiceLoader.java
! test/jdk/java/time/test/java/time/chrono/TestThaiBuddhistChronoImpl.java
! test/jdk/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java
! test/jdk/java/time/test/java/time/format/AbstractTestPrinterParser.java
! test/jdk/java/time/test/java/time/format/TestCharLiteralParser.java
! test/jdk/java/time/test/java/time/format/TestCharLiteralPrinter.java
! test/jdk/java/time/test/java/time/format/TestDateTimeFormatter.java
! test/jdk/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java
! test/jdk/java/time/test/java/time/format/TestDateTimeFormatterBuilderWithLocale.java
! test/jdk/java/time/test/java/time/format/TestDateTimeParsing.java
! test/jdk/java/time/test/java/time/format/TestDateTimeTextProvider.java
! test/jdk/java/time/test/java/time/format/TestDateTimeTextProviderWithLocale.java
! test/jdk/java/time/test/java/time/format/TestDecimalStyle.java
! test/jdk/java/time/test/java/time/format/TestFractionPrinterParser.java
! test/jdk/java/time/test/java/time/format/TestLocalizedOffsetPrinterParser.java
! test/jdk/java/time/test/java/time/format/TestLocalizedPattern.java
! test/jdk/java/time/test/java/time/format/TestNarrowMonthNamesAndDayNames.java
! test/jdk/java/time/test/java/time/format/TestNonIsoFormatter.java
! test/jdk/java/time/test/java/time/format/TestNumberParser.java
! test/jdk/java/time/test/java/time/format/TestNumberPrinter.java
! test/jdk/java/time/test/java/time/format/TestPadPrinterDecorator.java
! test/jdk/java/time/test/java/time/format/TestReducedParser.java
! test/jdk/java/time/test/java/time/format/TestReducedPrinter.java
! test/jdk/java/time/test/java/time/format/TestSettingsParser.java
! test/jdk/java/time/test/java/time/format/TestStringLiteralParser.java
! test/jdk/java/time/test/java/time/format/TestStringLiteralPrinter.java
! test/jdk/java/time/test/java/time/format/TestTextParser.java
! test/jdk/java/time/test/java/time/format/TestTextParserWithLocale.java
! test/jdk/java/time/test/java/time/format/TestTextPrinter.java
! test/jdk/java/time/test/java/time/format/TestTextPrinterWithLocale.java
! test/jdk/java/time/test/java/time/format/TestUTCParse.java
! test/jdk/java/time/test/java/time/format/TestUnicodeExtension.java
! test/jdk/java/time/test/java/time/format/TestZoneOffsetParser.java
! test/jdk/java/time/test/java/time/format/TestZoneOffsetPrinter.java
! test/jdk/java/time/test/java/time/format/TestZoneTextPrinterParser.java
! test/jdk/java/time/test/java/time/temporal/TestChronoField.java
! test/jdk/java/time/test/java/time/temporal/TestChronoUnit.java
! test/jdk/java/time/test/java/time/temporal/TestDateTimeBuilderCombinations.java
! test/jdk/java/time/test/java/time/temporal/TestDateTimeValueRange.java
! test/jdk/java/time/test/java/time/temporal/TestIsoFields.java
! test/jdk/java/time/test/java/time/temporal/TestIsoWeekFields.java
! test/jdk/java/time/test/java/time/temporal/TestJulianFields.java
! test/jdk/java/time/test/java/time/zone/TestFixedZoneRules.java
! test/jdk/java/time/test/java/time/zone/TestMutableZoneRules.java
! test/jdk/java/time/test/java/time/zone/TestZoneRules.java
! test/jdk/java/time/test/java/time/zone/TestZoneRulesProvider.java
! test/jdk/java/time/test/java/util/TestFormatter.java

Changeset: 7c979c14
Branch: fibers
Author:    David Beaumont <david.beaumont at oracle.com>
Committer: Roger Riggs <rriggs at openjdk.org>
Date:      2026-01-06 19:54:49 +0000
URL:       https://git.openjdk.org/loom/commit/7c979c148724ab7de650593caa22df8405d740e5

8374308: ImageBufferCache has no effect and can be removed

Reviewed-by: alanb, rriggs

! src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java
- src/java.base/share/classes/jdk/internal/jimage/ImageBufferCache.java
! src/java.base/share/classes/jdk/internal/jimage/ImageReader.java
! src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java

Changeset: 6b3c1e0f
Branch: fibers
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
Date:      2026-01-06 23:56:59 +0000
URL:       https://git.openjdk.org/loom/commit/6b3c1e0f786a889d2ac25c8bd05f4d83e666425f

8373833: "error.cert.not.found" and "error.explicit-sign-no-cert" errors duplicate each other

Reviewed-by: almatvee

! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/SigningIdentityBuilder.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources.properties
! test/jdk/tools/jpackage/share/ErrorTest.java

Changeset: 5c6947f7
Branch: fibers
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-07 06:30:14 +0000
URL:       https://git.openjdk.org/loom/commit/5c6947f736568413d53d5a00de2e865f86e637c4

8373429: gc/g1/TestCodeCacheUnloadDuringConcCycle fails on various platforms

Reviewed-by: mbaesken, mdoerr

! test/hotspot/jtreg/gc/g1/TestCodeCacheUnloadDuringConcCycle.java

Changeset: c1c0ac87
Branch: fibers
Author:    Damon Fenacci <dfenacci at openjdk.org>
Date:      2026-01-07 07:29:00 +0000
URL:       https://git.openjdk.org/loom/commit/c1c0ac877033c3edb0c2681c2c5f825be8adcfb3

8342772: Assert in LateInlineMHCallGenerator::do_late_inline_check

Reviewed-by: vlivanov, chagedorn, thartmann

! src/hotspot/share/opto/callGenerator.cpp

Changeset: a01283a5
Branch: fibers
Author:    Ana-Maria Mihalceanu <ana-maria.m.mihalceanu at oracle.com>
Committer: Jaikiran Pai <jpai at openjdk.org>
Date:      2026-01-07 08:24:31 +0000
URL:       https://git.openjdk.org/loom/commit/a01283a5a57723673b1fd3c93434678fdae4102c

8374632: Broken list layout in the man page of jlink

Reviewed-by: jpai

! src/jdk.jlink/share/man/jlink.md

Changeset: 7e18de13
Branch: fibers
Author:    Volkan Yazici <vyazici at openjdk.org>
Date:      2026-01-07 09:22:38 +0000
URL:       https://git.openjdk.org/loom/commit/7e18de137c3b5f08a479af2b64eb22923261900b

8374210: [BACKOUT] Move input validation checks to Java for java.lang.StringCoding intrinsics

Reviewed-by: shade, thartmann

! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/share/classfile/vmIntrinsics.hpp
! src/hotspot/share/opto/c2_globals.hpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/opto/library_call.hpp
! src/java.base/share/classes/java/lang/String.java
! src/java.base/share/classes/java/lang/StringCoding.java
! src/java.base/share/classes/java/lang/System.java
! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java
! src/java.base/share/classes/sun/nio/cs/CESU_8.java
! src/java.base/share/classes/sun/nio/cs/DoubleByte.java
! src/java.base/share/classes/sun/nio/cs/ISO_8859_1.java
! src/java.base/share/classes/sun/nio/cs/SingleByte.java
! src/java.base/share/classes/sun/nio/cs/US_ASCII.java
! src/java.base/share/classes/sun/nio/cs/UTF_8.java
! src/jdk.charsets/share/classes/sun/nio/cs/ext/EUC_JP.java.template
- test/hotspot/jtreg/compiler/intrinsics/TestVerifyIntrinsicChecks.java
! test/hotspot/jtreg/compiler/intrinsics/string/TestCountPositives.java
! test/hotspot/jtreg/compiler/intrinsics/string/TestEncodeIntrinsics.java
! test/hotspot/jtreg/compiler/intrinsics/string/TestHasNegatives.java
! test/hotspot/jtreg/compiler/patches/java.base/java/lang/Helper.java

Changeset: 2074b975
Branch: fibers
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2026-01-07 10:06:29 +0000
URL:       https://git.openjdk.org/loom/commit/2074b975c3d08fec2ecd47dab48132be2ec7c3cf

8374623: Move DependentAlwaysFalse variable template to its own file

Reviewed-by: jsjolen

+ src/hotspot/share/metaprogramming/dependentAlwaysFalse.hpp
! src/hotspot/share/runtime/atomic.hpp
! src/hotspot/share/utilities/globalDefinitions.hpp
! src/hotspot/share/utilities/lockFreeStack.hpp

Changeset: f83918c6
Branch: fibers
Author:    Alan Bateman <alanb at openjdk.org>
Date:      2026-01-07 10:43:11 +0000
URL:       https://git.openjdk.org/loom/commit/f83918c692143802f2e94bed72dfe7121d1742f9

8369227: Virtual thread stuck in PARKED state

Reviewed-by: pchilanomate

! src/java.base/share/classes/java/lang/VirtualThread.java
+ test/jdk/java/lang/Thread/virtual/stress/ParkAfterTimedPark.java
! test/jdk/java/lang/Thread/virtual/stress/TimedWaitALot.java

Changeset: 6af27420
Branch: fibers
Author:    Alan Bateman <alanb at openjdk.org>
Date:      2026-01-07 10:43:24 +0000
URL:       https://git.openjdk.org/loom/commit/6af27420e3b1980bc093776e3db76072123f7487

8373427: StructuredTaskScope::join not clear if called with interrupted status set

Reviewed-by: jpai

! src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java

Changeset: 535625ea
Branch: fibers
Author:    Alan Bateman <alan.bateman at oracle.com>
Date:      2026-01-07 11:33:01 +0000
URL:       https://git.openjdk.org/loom/commit/535625ea6cc1df93a850026e82298bac574d6eb4

Merge branch 'master' into fibers

! src/java.base/share/classes/java/lang/System.java
! src/java.base/share/classes/java/lang/VirtualThread.java
! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java
! src/java.base/share/classes/java/lang/System.java
! src/java.base/share/classes/java/lang/VirtualThread.java
! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java


From alex at puredanger.com  Thu Jan  8 17:48:43 2026
From: alex at puredanger.com (Alex Miller)
Date: Thu, 8 Jan 2026 11:48:43 -0600
Subject: Ephemeral threads
Message-ID: <CAOdgdgzQU4z+8RA2WMuD=nGUtXAdx1D0P8BW3CMQcGcQDcTSYw@mail.gmail.com>

I?d like to discuss adding support for ephemeral threads in the API. I know
virtual threads were originally ephemeral but before the Java 21 release
virtual thread tracking was added for observability (
https://bugs.openjdk.org/browse/JDK-8309406). It seems the notion of
explicit ephemeral threads has been considered as a possible feature in the
past to bring that back (
https://mail.openjdk.org/pipermail/loom-dev/2024-July/006892.html).

In Clojure, we released a CSP/Go-like system called core.async way back in
2013 (https://clojure.github.io/core.async/rationale.html). This system is
implemented via inversion of control and does parking on channel (queue)
operations via code rewriting. Core.async go blocks are ephemeral - they
are represented as data, referred to by channels when the go block is
parked waiting to put or take data on those channels. If all of the
channels a go block may be waiting on are GC?ed, the go block is GC?ed as
it can never run again.

We have ported core.async to use virtual threads as it provides a superset
of the blocking/parking semantics we need (other than ephemerality). There
are many benefits to this change - no more code rewriting, lighter-weight
handoffs, extended parking support for I/O operations, etc. We would love
to make this switch.

However, due to virtual thread tracking the ephemeral thread patterns our
users have relied on for more than a decade now result in go blocks being
strongly tracked even when unreachable, which creates memory leaks. Setting
-Djdk.trackAllThreads=false does what we want, but we are uneasy about
relying on undocumented flags that could change or go away.


I understand the history of this change with respect to observability, and
the expectation that existing Java users are used to ensuring that threads
complete. Unlike Java users, our Clojure core.async users DO expect to be
able to safely abandon go blocks when all of their channels are no longer
reachable - we?ve been doing that for a long time.

Virtual threads open the possibility of new Erlang-like architectures.
Ephemeral threads importantly enable lightweight process *library*
development as these new patterns can be composed without needing to handle
the termination concerns. core.async e.g. provides pub/sub, multiplexing,
pipelining and various other bits of non-trivial plumbing as libraries.
Most of those run as infinite loops to which user code maintains no
enduring references. There is simply no way to build such libraries on an
old-school approach to process termination.

Given where things stood at Java 21 time and where we are now, can we move
the idea of ephemeral thread support forward? This is very important to us
and we are happy to get involved with the process and contribute if that
would be helpful.


Thanks for your consideration,

Alex Miller (Clojure team)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260108/58e7bea8/attachment.htm>

From robaho at me.com  Thu Jan  8 18:33:58 2026
From: robaho at me.com (Robert Engels)
Date: Thu, 8 Jan 2026 12:33:58 -0600
Subject: Ephemeral threads
In-Reply-To: <CAOdgdgzQU4z+8RA2WMuD=nGUtXAdx1D0P8BW3CMQcGcQDcTSYw@mail.gmail.com>
References: <CAOdgdgzQU4z+8RA2WMuD=nGUtXAdx1D0P8BW3CMQcGcQDcTSYw@mail.gmail.com>
Message-ID: <56EC15B5-9B61-459D-AF20-BC1537CF2665@me.com>

Isn?t this as simple as using weak references at the stdlib level to track the virtual threads? I?m surprised this isn?t the case already. 

> On Jan 8, 2026, at 11:49?AM, Alex Miller <alex at puredanger.com> wrote:
> 
> ?
> I?d like to discuss adding support for ephemeral threads in the API. I know virtual threads were originally ephemeral but before the Java 21 release virtual thread tracking was added for observability (https://bugs.openjdk.org/browse/JDK-8309406). It seems the notion of explicit ephemeral threads has been considered as a possible feature in the past to bring that back (https://mail.openjdk.org/pipermail/loom-dev/2024-July/006892.html).
> 
> In Clojure, we released a CSP/Go-like system called core.async way back in 2013 (https://clojure.github.io/core.async/rationale.html). This system is implemented via inversion of control and does parking on channel (queue) operations via code rewriting. Core.async go blocks are ephemeral - they are represented as data, referred to by channels when the go block is parked waiting to put or take data on those channels. If all of the channels a go block may be waiting on are GC?ed, the go block is GC?ed as it can never run again.
> 
> We have ported core.async to use virtual threads as it provides a superset of the blocking/parking semantics we need (other than ephemerality). There are many benefits to this change - no more code rewriting, lighter-weight handoffs, extended parking support for I/O operations, etc. We would love to make this switch.
> 
> However, due to virtual thread tracking the ephemeral thread patterns our users have relied on for more than a decade now result in go blocks being strongly tracked even when unreachable, which creates memory leaks. Setting -Djdk.trackAllThreads=false does what we want, but we are uneasy about relying on undocumented flags that could change or go away.
> 
> I understand the history of this change with respect to observability, and the expectation that existing Java users are used to ensuring that threads complete. Unlike Java users, our Clojure core.async users DO expect to be able to safely abandon go blocks when all of their channels are no longer reachable - we?ve been doing that for a long time.
> 
> Virtual threads open the possibility of new Erlang-like architectures. Ephemeral threads importantly enable lightweight process *library* development as these new patterns can be composed without needing to handle the termination concerns. core.async e.g. provides pub/sub, multiplexing, pipelining and various other bits of non-trivial plumbing as libraries. Most of those run as infinite loops to which user code maintains no enduring references. There is simply no way to build such libraries on an old-school approach to process termination.
> 
> Given where things stood at Java 21 time and where we are now, can we move the idea of ephemeral thread support forward? This is very important to us and we are happy to get involved with the process and contribute if that would be helpful.
> 
> Thanks for your consideration,
> Alex Miller (Clojure team)
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260108/d9294027/attachment-0001.htm>

From alan.bateman at oracle.com  Fri Jan  9 09:33:46 2026
From: alan.bateman at oracle.com (Alan Bateman)
Date: Fri, 9 Jan 2026 09:33:46 +0000
Subject: Ephemeral threads
In-Reply-To: <CAOdgdgzQU4z+8RA2WMuD=nGUtXAdx1D0P8BW3CMQcGcQDcTSYw@mail.gmail.com>
References: <CAOdgdgzQU4z+8RA2WMuD=nGUtXAdx1D0P8BW3CMQcGcQDcTSYw@mail.gmail.com>
Message-ID: <518ce8ef-4fa7-4166-a6fd-d2d699e51ba2@oracle.com>

On 08/01/2026 17:48, Alex Miller wrote:
>
> Given where things stood at Java 21 time and where we are now, can we 
> move the idea of ephemeral thread support forward? This is very 
> important to us and we are happy to get involved with the process and 
> contribute if that would be helpful.
>

The possibility of GC'ing a started thread before it terminates is a 
scary topic. It interacts with many areas and gets really scary once you 
bring phantom refs, cleaners, and finalizers into the discussion.

For these so-called "forgotten sender" and "abandoned receiver" cases 
then it might be more interesting to see how they could be work with 
structured concurrency. Right now, the first API is focused on fan-out 
scenarios but in time we would like to have it work with channel like 
constructs too. I suspect this will be closer to what you are interested in.

-Alan










-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260109/3ced835b/attachment.htm>

From viktor.klang at oracle.com  Fri Jan  9 13:03:39 2026
From: viktor.klang at oracle.com (Viktor Klang)
Date: Fri, 9 Jan 2026 14:03:39 +0100
Subject: Ephemeral threads
In-Reply-To: <518ce8ef-4fa7-4166-a6fd-d2d699e51ba2@oracle.com>
References: <CAOdgdgzQU4z+8RA2WMuD=nGUtXAdx1D0P8BW3CMQcGcQDcTSYw@mail.gmail.com>
 <518ce8ef-4fa7-4166-a6fd-d2d699e51ba2@oracle.com>
Message-ID: <f9f15ec0-28cf-40fe-aea8-5ecc89c16d9f@oracle.com>

Hi Alex,

 From my perspective, the big issue with ephemerality of VTs is that it 
easily leads to problems where resources leak with no trace of who 
leaked it?which tends to be rather nightmarish to deal with once they 
pop up in production?"Hey, why is this semaphore unbalanced?!".

On one hand, there's a bit of a 30-year old semantical expectation that 
"threads are GC roots"?which allows things like daemon threads?what is 
the expectation of daemon ephemeral virtual threads? Interestingly, 
daemonicity is sort of "half-ephemeral in the global scale" in the sense 
that only non-daemonic threads prevents the exit of the runtime.

On the other, the ephemerality feature is intrinsically related to the 
notion of reachability, which is a runtime determination only loosely 
related to the code itself?as an example, people tend to be surprised 
that an object instance can be garbage-collected (i.e. deemed 
unreachable) while a method on it is still being executed.

Theoretically, you could make a rather solid argument that a 
VirtualThread is never ephemeral, but a Continuation could be?

Another complicating factor is that the code to be executed does not 
know whether it executes on an ephemeral VirtualThread or not??as the 
general case for Thread::run() calls into third-party logic, considering 
that the Java standard library, to a developer not working on the JDK, 
is third-party logic to that developer.

Should all developers, always, ensure that the code they write is 
correct under the presumption that the evaluator (a Thread) is 
ephemeral? That carries the implication that all tests should always be 
executed by ephemeral virtual threads?and they should be run N (what 
would be a reasonable value of N here?) times, because timing of 
unreachability may change observable effects. I, personally, think that 
price is too steep to pay for this feature.


On 2026-01-09 10:33, Alan Bateman wrote:
> On 08/01/2026 17:48, Alex Miller wrote:
>>
>> Given where things stood at Java 21 time and where we are now, can we 
>> move the idea of ephemeral thread support forward? This is very 
>> important to us and we are happy to get involved with the process and 
>> contribute if that would be helpful.
>>
>
> The possibility of GC'ing a started thread before it terminates is a 
> scary topic. It interacts with many areas and gets really scary once 
> you bring phantom refs, cleaners, and finalizers into the discussion.
>
> For these so-called "forgotten sender" and "abandoned receiver" cases 
> then it might be more interesting to see how they could be work with 
> structured concurrency. Right now, the first API is focused on fan-out 
> scenarios but in time we would like to have it work with channel like 
> constructs too. I suspect this will be closer to what you are 
> interested in.
>
> -Alan
>
>
>
>
>
>
>
>
>
>
>
-- 
Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260109/f7b9c227/attachment-0001.htm>

From dmitry.zaslavsky at gmail.com  Fri Jan  9 14:39:04 2026
From: dmitry.zaslavsky at gmail.com (Dmitry Zaslavsky)
Date: Fri, 9 Jan 2026 09:39:04 -0500
Subject: Ephemeral threads
In-Reply-To: <f9f15ec0-28cf-40fe-aea8-5ecc89c16d9f@oracle.com>
References: <CAOdgdgzQU4z+8RA2WMuD=nGUtXAdx1D0P8BW3CMQcGcQDcTSYw@mail.gmail.com>
 <518ce8ef-4fa7-4166-a6fd-d2d699e51ba2@oracle.com>
 <f9f15ec0-28cf-40fe-aea8-5ecc89c16d9f@oracle.com>
Message-ID: <6E8BCF39-B438-4C4A-A892-8C933FB86F92@gmail.com>

I wanted to add another ?user? vote for Ephemeral threads.

We are experimenting with custom schedulers (thread pools) for VT, which is what I suspect Alex?s point was about in the first place.
Victor I think you are almost making the same observation when you said:
> Theoretically, you could make a rather solid argument that a VirtualThread is never ephemeral, but a Continuation could be?
> 

So in someways (more powerful than Continuation) I would like to have VT have some semantics relaxed for custom VT schedulers.

Additional questions do arise for example: we don?t allow our users to use try?. 

We provide a replacement API that deals with additional semantics.

We also have a concept of cancellationScopes (Seems there might be some intersection with what Alan referred to when he mentioned ScopedTasks)

For example:
someCollection.apar.map { ?. }
Can spin N tasks (Each can get it's VT) If some iteration of the loop throws, we don?t need to rest of the code to run, it?s costly.
If the task are not actively mounted but previously started and are waiting? (in our case it?s LockSupport.park) we just want to drop that entire queue and everything around it?.




> On Jan 9, 2026, at 8:03?AM, Viktor Klang <viktor.klang at oracle.com> wrote:
> 
> Hi Alex,
> 
> From my perspective, the big issue with ephemerality of VTs is that it easily leads to problems where resources leak with no trace of who leaked it?which tends to be rather nightmarish to deal with once they pop up in production?"Hey, why is this semaphore unbalanced?!".
> 
> On one hand, there's a bit of a 30-year old semantical expectation that "threads are GC roots??said:which allows things like daemon threads?what is the expectation of daemon ephemeral virtual threads? Interestingly, daemonicity is sort of "half-ephemeral in the global scale" in the sense that only non-daemonic threads prevents the exit of the runtime.
> 
> On the other, the ephemerality feature is intrinsically related to the notion of reachability, which is a runtime determination only loosely related to the code itself?as an example, people tend to be surprised that an object instance can be garbage-collected (i.e. deemed unreachable) while a method on it is still being executed.
> 
> Theoretically, you could make a rather solid argument that a VirtualThread is never ephemeral, but a Continuation could be?
> 
> Another complicating factor is that the code to be executed does not know whether it executes on an ephemeral VirtualThread or not??as the general case for Thread::run() calls into third-party logic, considering that the Java standard library, to a developer not working on the JDK, is third-party logic to that developer. 
> 
> Should all developers, always, ensure that the code they write is correct under the presumption that the evaluator (a Thread) is ephemeral? That carries the implication that all tests should always be executed by ephemeral virtual threads?and they should be run N (what would be a reasonable value of N here?) times, because timing of unreachability may change observable effects. I, personally, think that price is too steep to pay for this feature.
> 
> 
> 
> On 2026-01-09 10:33, Alan Bateman wrote:
>> On 08/01/2026 17:48, Alex Miller wrote:
>>> 
>>> Given where things stood at Java 21 time and where we are now, can we move the idea of ephemeral thread support forward? This is very important to us and we are happy to get involved with the process and contribute if that would be helpful.
>> 
>> The possibility of GC'ing a started thread before it terminates is a scary topic. It interacts with many areas and gets really scary once you bring phantom refs, cleaners, and finalizers into the discussion.
>> 
>> For these so-called "forgotten sender" and "abandoned receiver" cases then it might be more interesting to see how they could be work with structured concurrency. Right now, the first API is focused on fan-out scenarios but in time we would like to have it work with channel like constructs too. I suspect this will be closer to what you are interested in.
>> 
>> -Alan
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> -- 
> Cheers,
> ?
> 
> 
> Viktor Klang
> Software Architect, Java Platform Group
> Oracle

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260109/79bdd60f/attachment.htm>

From alan.bateman at oracle.com  Fri Jan  9 15:08:34 2026
From: alan.bateman at oracle.com (Alan Bateman)
Date: Fri, 9 Jan 2026 15:08:34 +0000
Subject: Ephemeral threads
In-Reply-To: <6E8BCF39-B438-4C4A-A892-8C933FB86F92@gmail.com>
References: <CAOdgdgzQU4z+8RA2WMuD=nGUtXAdx1D0P8BW3CMQcGcQDcTSYw@mail.gmail.com>
 <518ce8ef-4fa7-4166-a6fd-d2d699e51ba2@oracle.com>
 <f9f15ec0-28cf-40fe-aea8-5ecc89c16d9f@oracle.com>
 <6E8BCF39-B438-4C4A-A892-8C933FB86F92@gmail.com>
Message-ID: <afb5b33c-bf02-47e5-afb9-c182a063e0fc@oracle.com>

On 09/01/2026 14:39, Dmitry Zaslavsky wrote:
> I wanted to add another ?user? vote for Ephemeral threads.
>
> We are experimenting with custom schedulers (thread pools) for VT

Are these experiments using one of the prototypes in the loom repo? Are 
you able to send a summary to the mailing list about your experiments?

-Alan

From viktor.klang at oracle.com  Fri Jan  9 15:26:36 2026
From: viktor.klang at oracle.com (Viktor Klang)
Date: Fri, 9 Jan 2026 16:26:36 +0100
Subject: [External] : Re: Ephemeral threads
In-Reply-To: <6E8BCF39-B438-4C4A-A892-8C933FB86F92@gmail.com>
References: <CAOdgdgzQU4z+8RA2WMuD=nGUtXAdx1D0P8BW3CMQcGcQDcTSYw@mail.gmail.com>
 <518ce8ef-4fa7-4166-a6fd-d2d699e51ba2@oracle.com>
 <f9f15ec0-28cf-40fe-aea8-5ecc89c16d9f@oracle.com>
 <6E8BCF39-B438-4C4A-A892-8C933FB86F92@gmail.com>
Message-ID: <01c37422-171d-49b0-a216-15bb8aaaf172@oracle.com>


On 2026-01-09 15:39, Dmitry Zaslavsky wrote:
> someCollection.apar.map { ?. }
> Can spin N tasks (Each can get it's VT) If some iteration of the loop 
> throws, we don?t need to rest of the code to run, it?s costly.
> If the task are not actively mounted but previously started and are 
> waiting? (in our case it?s LockSupport.park) we just want to drop that 
> entire queue and everything around it?.
>
>
How do you handle acquired native resources that are yet to be released?


-- 
Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle


From dmitry.zaslavsky at gmail.com  Fri Jan  9 16:16:03 2026
From: dmitry.zaslavsky at gmail.com (Dmitry Zaslavsky)
Date: Fri, 9 Jan 2026 11:16:03 -0500
Subject: Ephemeral threads
In-Reply-To: <afb5b33c-bf02-47e5-afb9-c182a063e0fc@oracle.com>
References: <CAOdgdgzQU4z+8RA2WMuD=nGUtXAdx1D0P8BW3CMQcGcQDcTSYw@mail.gmail.com>
 <518ce8ef-4fa7-4166-a6fd-d2d699e51ba2@oracle.com>
 <f9f15ec0-28cf-40fe-aea8-5ecc89c16d9f@oracle.com>
 <6E8BCF39-B438-4C4A-A892-8C933FB86F92@gmail.com>
 <afb5b33c-bf02-47e5-afb9-c182a063e0fc@oracle.com>
Message-ID: <3AC893FF-26CF-4C24-AB47-DE8F623414D7@gmail.com>

Please don?t kill me?..
My current experiment on a large code base and I am using JDK 25 and opening up some internals.
I try to stick to what available in loom branch?. Hoping to reap out my kludge with what you?ll presumably provide.
For example I provided myself 
Thread.ofVirtual().factory().scheduler() 

I will have a question / report email in a few weeks.

I see that doc there (loom repro) changes as well. 
It?s not clear to me if all you want to expose is what?s in current doc or what is still in the code.
For example I need that variable on VirtualTask that disappeared in the current doc.

I can start the thread now :) 



> On Jan 9, 2026, at 10:08?AM, Alan Bateman <alan.bateman at oracle.com> wrote:
> 
> On 09/01/2026 14:39, Dmitry Zaslavsky wrote:
>> I wanted to add another ?user? vote for Ephemeral threads.
>> 
>> We are experimenting with custom schedulers (thread pools) for VT
> 
> Are these experiments using one of the prototypes in the loom repo? Are you able to send a summary to the mailing list about your experiments?
> 
> -Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260109/fe5a3d01/attachment.htm>

From dmitry.zaslavsky at gmail.com  Fri Jan  9 16:27:29 2026
From: dmitry.zaslavsky at gmail.com (Dmitry Zaslavsky)
Date: Fri, 9 Jan 2026 11:27:29 -0500
Subject: [External] : Re: Ephemeral threads
In-Reply-To: <01c37422-171d-49b0-a216-15bb8aaaf172@oracle.com>
References: <CAOdgdgzQU4z+8RA2WMuD=nGUtXAdx1D0P8BW3CMQcGcQDcTSYw@mail.gmail.com>
 <518ce8ef-4fa7-4166-a6fd-d2d699e51ba2@oracle.com>
 <f9f15ec0-28cf-40fe-aea8-5ecc89c16d9f@oracle.com>
 <6E8BCF39-B438-4C4A-A892-8C933FB86F92@gmail.com>
 <01c37422-171d-49b0-a216-15bb8aaaf172@oracle.com>
Message-ID: <5A5AEC77-43CC-4D2D-87E1-3EC6F8D066AF@gmail.com>

Not sure what you mean by native resources?
Do you mean what people would use like try resources?
We generally don?t allow try blocks (providing other constructs), we also very strongly discourage (just a drop short of disallowing) ANY threading primitives.

Which makes me think that there is a better way to express my point from before.
I think there is actually a common pattern here.

We use VT inside of the lib. We don?t want users to actually use any threads all.
I think it?s a goal of Alex as well. 
We use VT as  a way to avoid using threads (if that makes sense).

I think ScopedTasks is going in the same direction. Ideally user just doesn?t know there are threads.
We use Scala (appealing to Victor ;)) vals and immutable collections is the norm.

We don?t want users to think about Threads period.
So the thought of "GC roots on a VT ? we don?t want that though to ever occur or we failed ;)



 

> On Jan 9, 2026, at 10:26?AM, Viktor Klang <viktor.klang at oracle.com> wrote:
> 
> 
> On 2026-01-09 15:39, Dmitry Zaslavsky wrote:
>> someCollection.apar.map { ?. }
>> Can spin N tasks (Each can get it's VT) If some iteration of the loop throws, we don?t need to rest of the code to run, it?s costly.
>> If the task are not actively mounted but previously started and are waiting? (in our case it?s LockSupport.park) we just want to drop that entire queue and everything around it?.
>> 
>> 
> How do you handle acquired native resources that are yet to be released?
> 
> 
> -- 
> Cheers,
> ?
> 
> 
> Viktor Klang
> Software Architect, Java Platform Group
> Oracle
> 


From aph at redhat.com  Sat Jan 10 11:04:34 2026
From: aph at redhat.com (Andrew Haley)
Date: Sat, 10 Jan 2026 11:04:34 +0000
Subject: Ephemeral threads
In-Reply-To: <f9f15ec0-28cf-40fe-aea8-5ecc89c16d9f@oracle.com>
References: <CAOdgdgzQU4z+8RA2WMuD=nGUtXAdx1D0P8BW3CMQcGcQDcTSYw@mail.gmail.com>
 <518ce8ef-4fa7-4166-a6fd-d2d699e51ba2@oracle.com>
 <f9f15ec0-28cf-40fe-aea8-5ecc89c16d9f@oracle.com>
Message-ID: <bf0a7ae7-ca5e-48d3-a3bb-e8177fcb95ba@redhat.com>

On 09/01/2026 13:03, Viktor Klang wrote:
>   From my perspective, the big issue with ephemerality of VTs is that it
> easily leads to problems where resources leak with no trace of who
> leaked it?which tends to be rather nightmarish to deal with once they
> pop up in production?"Hey, why is this semaphore unbalanced?!".

I don't understand what scenario you're talking about.

How, exactly, would you make a thread unreachable? It can't be on any 
reachable queue, so it isn't waiting on a timer or I/O. It can't be 
running, because the it's trivially reachable.

Maybe it's waiting on some kind of semaphore that has become 
unreachable. In that case, the thread cannot make any progress. It makes 
no difference whether you GC it or not. The native resources it holds 
will never be released. Semantically, an unreachable thread is not a 
thing: it has no properties.

Therefore, any thread that is unreachable may be GC'd, surely.

I guess I may be missing some way that an unreachable thread is 
observable? If so, what is it?

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From outsider404 at gmail.com  Sat Jan 10 12:51:54 2026
From: outsider404 at gmail.com (Michal Domagala)
Date: Sat, 10 Jan 2026 13:51:54 +0100
Subject: Ephemeral threads
In-Reply-To: <bf0a7ae7-ca5e-48d3-a3bb-e8177fcb95ba@redhat.com>
References: <CAOdgdgzQU4z+8RA2WMuD=nGUtXAdx1D0P8BW3CMQcGcQDcTSYw@mail.gmail.com>
 <518ce8ef-4fa7-4166-a6fd-d2d699e51ba2@oracle.com>
 <f9f15ec0-28cf-40fe-aea8-5ecc89c16d9f@oracle.com>
 <bf0a7ae7-ca5e-48d3-a3bb-e8177fcb95ba@redhat.com>
Message-ID: <CA+heAJDQUg97iGpbJL3y44TRi+nvngn8pkJdQgy67fa08rZCSA@mail.gmail.com>

Hi,

I would like to present my case for ephemeral VT.
I have a websocket, the websocket has a correlated blocking queue, there is
a virtual thread which reads from the queue and writes to the websocket
session.
When session is closed, I remove blocking queue from global concurrent hash
map
But I have to
- keep reference to VT
- interrupt VT on-session-closed
It is similar to  C++ destructor.
If I can rely on GC, I will just remove blocking queue reference and
everything will happen automatically.

Regards,
Michal Domagala


sob., 10 sty 2026 o 13:20 Andrew Haley <aph at redhat.com> napisa?(a):

> On 09/01/2026 13:03, Viktor Klang wrote:
> >   From my perspective, the big issue with ephemerality of VTs is that it
> > easily leads to problems where resources leak with no trace of who
> > leaked it?which tends to be rather nightmarish to deal with once they
> > pop up in production?"Hey, why is this semaphore unbalanced?!".
>
> I don't understand what scenario you're talking about.
>
> How, exactly, would you make a thread unreachable? It can't be on any
> reachable queue, so it isn't waiting on a timer or I/O. It can't be
> running, because the it's trivially reachable.
>
> Maybe it's waiting on some kind of semaphore that has become
> unreachable. In that case, the thread cannot make any progress. It makes
> no difference whether you GC it or not. The native resources it holds
> will never be released. Semantically, an unreachable thread is not a
> thing: it has no properties.
>
> Therefore, any thread that is unreachable may be GC'd, surely.
>
> I guess I may be missing some way that an unreachable thread is
> observable? If so, what is it?
>
> --
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260110/93200b0d/attachment.htm>

From robaho at me.com  Sat Jan 10 15:34:04 2026
From: robaho at me.com (Robert Engels)
Date: Sat, 10 Jan 2026 09:34:04 -0600
Subject: Ephemeral threads
In-Reply-To: <CA+heAJDQUg97iGpbJL3y44TRi+nvngn8pkJdQgy67fa08rZCSA@mail.gmail.com>
References: <CA+heAJDQUg97iGpbJL3y44TRi+nvngn8pkJdQgy67fa08rZCSA@mail.gmail.com>
Message-ID: <E4F3998B-E2BA-4D1B-A977-5D967A687FB4@me.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260110/2c59e334/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: closablequeue.png
Type: image/png
Size: 170923 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260110/2c59e334/closablequeue-0001.png>

From alan.bateman at oracle.com  Sat Jan 10 15:42:52 2026
From: alan.bateman at oracle.com (Alan Bateman)
Date: Sat, 10 Jan 2026 15:42:52 +0000
Subject: Ephemeral threads
In-Reply-To: <bf0a7ae7-ca5e-48d3-a3bb-e8177fcb95ba@redhat.com>
References: <CAOdgdgzQU4z+8RA2WMuD=nGUtXAdx1D0P8BW3CMQcGcQDcTSYw@mail.gmail.com>
 <518ce8ef-4fa7-4166-a6fd-d2d699e51ba2@oracle.com>
 <f9f15ec0-28cf-40fe-aea8-5ecc89c16d9f@oracle.com>
 <bf0a7ae7-ca5e-48d3-a3bb-e8177fcb95ba@redhat.com>
Message-ID: <637c717c-eede-4697-aa97-70db7b3e981f@oracle.com>

On 10/01/2026 11:04, Andrew Haley wrote:
> :
>
> Maybe it's waiting on some kind of semaphore that has become 
> unreachable. In that case, the thread cannot make any progress. It 
> makes no difference whether you GC it or not. The native resources it 
> holds will never be released. Semantically, an unreachable thread is 
> not a thing: it has no properties.
>
> Therefore, any thread that is unreachable may be GC'd, surely.
>
> I guess I may be missing some way that an unreachable thread is 
> observable? If so, what is it?
>
Diagnosing resource leaks, semaphore permit "leaks" etc. is much harder 
if threads can be GC'ed before they terminate.

We looked into the implications of ephemeral threads a few years ago. 
Aside from being fragile to use, they lead to issues that range from 
mildly spooky to?truly horrifying. Think of cleaners running when 
objects are in inconsistent state. Think of objects with finalizers that 
put a "goodbye" element to a queue and cause a thread to come back from 
the dead. There's a lot more to this. The summary is that introducing 
ephemeral threads has huge implications due to the interactions with so 
many parts of the system. We decided not to spend further time on it.

-Alan


From alex at puredanger.com  Sat Jan 10 15:55:05 2026
From: alex at puredanger.com (Alex Miller)
Date: Sat, 10 Jan 2026 09:55:05 -0600
Subject: Ephemeral threads
In-Reply-To: <637c717c-eede-4697-aa97-70db7b3e981f@oracle.com>
References: <637c717c-eede-4697-aa97-70db7b3e981f@oracle.com>
Message-ID: <FCE7C380-F20B-4CEC-BE48-179C69BAF001@puredanger.com>

What is the likely future of the trackAllThreads flag?

> On Jan 10, 2026, at 9:43?AM, Alan Bateman <alan.bateman at oracle.com> wrote:
> 
> ?On 10/01/2026 11:04, Andrew Haley wrote:
>> :
>> 
>> Maybe it's waiting on some kind of semaphore that has become unreachable. In that case, the thread cannot make any progress. It makes no difference whether you GC it or not. The native resources it holds will never be released. Semantically, an unreachable thread is not a thing: it has no properties.
>> 
>> Therefore, any thread that is unreachable may be GC'd, surely.
>> 
>> I guess I may be missing some way that an unreachable thread is observable? If so, what is it?
>> 
> Diagnosing resource leaks, semaphore permit "leaks" etc. is much harder if threads can be GC'ed before they terminate.
> 
> We looked into the implications of ephemeral threads a few years ago. Aside from being fragile to use, they lead to issues that range from mildly spooky to truly horrifying. Think of cleaners running when objects are in inconsistent state. Think of objects with finalizers that put a "goodbye" element to a queue and cause a thread to come back from the dead. There's a lot more to this. The summary is that introducing ephemeral threads has huge implications due to the interactions with so many parts of the system. We decided not to spend further time on it.
> 
> -Alan
> 

From aph at redhat.com  Sat Jan 10 16:00:17 2026
From: aph at redhat.com (Andrew Haley)
Date: Sat, 10 Jan 2026 16:00:17 +0000
Subject: Ephemeral threads
In-Reply-To: <637c717c-eede-4697-aa97-70db7b3e981f@oracle.com>
References: <CAOdgdgzQU4z+8RA2WMuD=nGUtXAdx1D0P8BW3CMQcGcQDcTSYw@mail.gmail.com>
 <518ce8ef-4fa7-4166-a6fd-d2d699e51ba2@oracle.com>
 <f9f15ec0-28cf-40fe-aea8-5ecc89c16d9f@oracle.com>
 <bf0a7ae7-ca5e-48d3-a3bb-e8177fcb95ba@redhat.com>
 <637c717c-eede-4697-aa97-70db7b3e981f@oracle.com>
Message-ID: <641baf6f-1a6c-423c-8d3c-526c3adbe731@redhat.com>

On 10/01/2026 15:42, Alan Bateman wrote:
> On 10/01/2026 11:04, Andrew Haley wrote:
>> :
>>
>> Maybe it's waiting on some kind of semaphore that has become
>> unreachable. In that case, the thread cannot make any progress. It
>> makes no difference whether you GC it or not. The native resources it
>> holds will never be released. Semantically, an unreachable thread is
>> not a thing: it has no properties.
>>
>> Therefore, any thread that is unreachable may be GC'd, surely.
>>
>> I guess I may be missing some way that an unreachable thread is
>> observable? If so, what is it?
>>
> Diagnosing resource leaks, semaphore permit "leaks" etc. is much harder
> if threads can be GC'ed before they terminate.
> 
> We looked into the implications of ephemeral threads a few years ago.
> Aside from being fragile to use, they lead to issues that range from
> mildly spooky to?truly horrifying. Think of cleaners running when
> objects are in inconsistent state. Think of objects with finalizers that
> put a "goodbye" element to a queue and cause a thread to come back from
> the dead.

OK, I think I get it. The issue here is that a thread is unreachable but 
can be resurrected if it's finalized.

So, at some risk of flogging a dead horse, I'm wondering: what if we 
could figure out a way in which an unreachable thread could be GC'd, but 
only if it was honest-to-goodness unreachable, i.e. it wasn't on a 
reference queue and it had no finalizer. We'd be good, right?

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From alan.bateman at oracle.com  Sat Jan 10 17:18:13 2026
From: alan.bateman at oracle.com (Alan Bateman)
Date: Sat, 10 Jan 2026 17:18:13 +0000
Subject: Ephemeral threads
In-Reply-To: <641baf6f-1a6c-423c-8d3c-526c3adbe731@redhat.com>
References: <CAOdgdgzQU4z+8RA2WMuD=nGUtXAdx1D0P8BW3CMQcGcQDcTSYw@mail.gmail.com>
 <518ce8ef-4fa7-4166-a6fd-d2d699e51ba2@oracle.com>
 <f9f15ec0-28cf-40fe-aea8-5ecc89c16d9f@oracle.com>
 <bf0a7ae7-ca5e-48d3-a3bb-e8177fcb95ba@redhat.com>
 <637c717c-eede-4697-aa97-70db7b3e981f@oracle.com>
 <641baf6f-1a6c-423c-8d3c-526c3adbe731@redhat.com>
Message-ID: <84805f86-fa9d-4821-8957-52cab1d35c85@oracle.com>

On 10/01/2026 16:00, Andrew Haley wrote:
>
> OK, I think I get it. The issue here is that a thread is unreachable 
> but can be resurrected if it's finalized.
>
> So, at some risk of flogging a dead horse, I'm wondering: what if we 
> could figure out a way in which an unreachable thread could be GC'd, 
> but only if it was honest-to-goodness unreachable, i.e. it wasn't on a 
> reference queue and it had no finalizer. We'd be good, right?
>
Hopefully finalization will be disabled by default, and eventually 
removed, but there a lot more to the topic. You can summon other demons 
when the threads act on objects with cleaners (or more generally, 
anything with cleanup actions based on phantom refs). This can lead to 
cleaning actions that attempt to release resources in an inconsistent 
state. Even if we spent a few years on the issues, the usage (to allow 
the alive threads be GC'ed) is very fragile to setup, and the resulting 
behavior would surely be surprising to most developers. If we do 
channels that integrate with structured concurrency then it might be 
that some of the calls for ephemeral threads go away.

-Alan.

From robaho at me.com  Sat Jan 10 18:17:50 2026
From: robaho at me.com (Robert Engels)
Date: Sat, 10 Jan 2026 12:17:50 -0600
Subject: Ephemeral threads
In-Reply-To: <84805f86-fa9d-4821-8957-52cab1d35c85@oracle.com>
References: <CAOdgdgzQU4z+8RA2WMuD=nGUtXAdx1D0P8BW3CMQcGcQDcTSYw@mail.gmail.com>
 <518ce8ef-4fa7-4166-a6fd-d2d699e51ba2@oracle.com>
 <f9f15ec0-28cf-40fe-aea8-5ecc89c16d9f@oracle.com>
 <bf0a7ae7-ca5e-48d3-a3bb-e8177fcb95ba@redhat.com>
 <637c717c-eede-4697-aa97-70db7b3e981f@oracle.com>
 <641baf6f-1a6c-423c-8d3c-526c3adbe731@redhat.com>
 <84805f86-fa9d-4821-8957-52cab1d35c85@oracle.com>
Message-ID: <3E90C760-8568-4C8E-8AEA-59F873BBCF02@me.com>

I think ClosableQueue - which are essentially CSP channels - demonstrates that you don?t need anything special to accomplish this with the existing infrastructure with loom or structured concurrency.

> On Jan 10, 2026, at 11:18?AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 10/01/2026 16:00, Andrew Haley wrote:
>> 
>> OK, I think I get it. The issue here is that a thread is unreachable but can be resurrected if it's finalized.
>> 
>> So, at some risk of flogging a dead horse, I'm wondering: what if we could figure out a way in which an unreachable thread could be GC'd, but only if it was honest-to-goodness unreachable, i.e. it wasn't on a reference queue and it had no finalizer. We'd be good, right?
>> 
> Hopefully finalization will be disabled by default, and eventually removed, but there a lot more to the topic. You can summon other demons when the threads act on objects with cleaners (or more generally, anything with cleanup actions based on phantom refs). This can lead to cleaning actions that attempt to release resources in an inconsistent state. Even if we spent a few years on the issues, the usage (to allow the alive threads be GC'ed) is very fragile to setup, and the resulting behavior would surely be surprising to most developers. If we do channels that integrate with structured concurrency then it might be that some of the calls for ephemeral threads go away.
> 
> -Alan.


From viktor.klang at oracle.com  Sun Jan 11 00:02:53 2026
From: viktor.klang at oracle.com (Viktor Klang)
Date: Sun, 11 Jan 2026 01:02:53 +0100
Subject: [External] : Re: Ephemeral threads
In-Reply-To: <5A5AEC77-43CC-4D2D-87E1-3EC6F8D066AF@gmail.com>
References: <CAOdgdgzQU4z+8RA2WMuD=nGUtXAdx1D0P8BW3CMQcGcQDcTSYw@mail.gmail.com>
 <518ce8ef-4fa7-4166-a6fd-d2d699e51ba2@oracle.com>
 <f9f15ec0-28cf-40fe-aea8-5ecc89c16d9f@oracle.com>
 <6E8BCF39-B438-4C4A-A892-8C933FB86F92@gmail.com>
 <01c37422-171d-49b0-a216-15bb8aaaf172@oracle.com>
 <5A5AEC77-43CC-4D2D-87E1-3EC6F8D066AF@gmail.com>
Message-ID: <1ef40f81-0e75-4752-989b-11cd4e5601a7@oracle.com>

Hi Dmitry,

An example can look like:

void method() {
 ? ? long fileDescriptor = acquireFileDescriptor();
 ? ? LockSupport.park();
 ? ? releaseFileDescriptor(fileDescriptor);
}

If an ephemeral VT executes that method, and there are no other 
references to that ephemeral VT, then at the point of park(), nothing 
can unpark it anymore, and it will then never release the file descriptor.


 >We generally don?t allow try blocks (providing other constructs), we 
also very strongly discourage (just a drop short of disallowing) ANY 
threading primitives.


I don't see how that can work in practice, because it requires all users 
of your constructs to be familiar about exactly how all third-party 
logic (including JDK classes) are implemented under the hood. Perhaps 
I'm misunderstanding?

On 2026-01-09 17:27, Dmitry Zaslavsky wrote:
> Not sure what you mean by native resources?
> Do you mean what people would use like try resources?
> We generally don?t allow try blocks (providing other constructs), we also very strongly discourage (just a drop short of disallowing) ANY threading primitives.
>
> Which makes me think that there is a better way to express my point from before.
> I think there is actually a common pattern here.
>
> We use VT inside of the lib. We don?t want users to actually use any threads all.
> I think it?s a goal of Alex as well.
> We use VT as  a way to avoid using threads (if that makes sense).
>
> I think ScopedTasks is going in the same direction. Ideally user just doesn?t know there are threads.
> We use Scala (appealing to Victor ;)) vals and immutable collections is the norm.
>
> We don?t want users to think about Threads period.
> So the thought of "GC roots on a VT ? we don?t want that though to ever occur or we failed ;)
>
>
>
>   
>
>> On Jan 9, 2026, at 10:26?AM, Viktor Klang<viktor.klang at oracle.com> wrote:
>>
>>
>> On 2026-01-09 15:39, Dmitry Zaslavsky wrote:
>>> someCollection.apar.map { ?. }
>>> Can spin N tasks (Each can get it's VT) If some iteration of the loop throws, we don?t need to rest of the code to run, it?s costly.
>>> If the task are not actively mounted but previously started and are waiting? (in our case it?s LockSupport.park) we just want to drop that entire queue and everything around it?.
>>>
>>>
>> How do you handle acquired native resources that are yet to be released?
>>
>>
>> -- 
>> Cheers,
>> ?
>>
>>
>> Viktor Klang
>> Software Architect, Java Platform Group
>> Oracle
>>
-- 
Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260111/378da473/attachment-0001.htm>

From outsider404 at gmail.com  Sun Jan 11 00:37:30 2026
From: outsider404 at gmail.com (Michal Domagala)
Date: Sun, 11 Jan 2026 01:37:30 +0100
Subject: Ephemeral threads
In-Reply-To: <E4F3998B-E2BA-4D1B-A977-5D967A687FB4@me.com>
References: <CA+heAJDQUg97iGpbJL3y44TRi+nvngn8pkJdQgy67fa08rZCSA@mail.gmail.com>
 <E4F3998B-E2BA-4D1B-A977-5D967A687FB4@me.com>
Message-ID: <CA+heAJCDMuSczQgZUTZfqvzBGwQgZSwR=fO62GeUKioVXcSsKA@mail.gmail.com>

I appreciate your help, probably the library is smart and elegant, but I
will not use it and I will recommend not using it to anybody in my
situation.
Why?
My situation is a dead simple case from the first page websocket book.
1. Serial write to session
2. Clean resources on-session-close
The first is implemented by blocking queue and VT, the second is
implemented by interrupting VT to let them die. It would be elegant to let
GC  kill VT. but now it does not work.
In this situation I prefer to bloat code a little and manually interrupt
the thread rather than taking a library, which is hard to understand (not
because of bad code style but due complex domain).
Commenting in code that this library automatically cleanups thread would be
longer and more elaborative than its own implementation.

My additional concern is QueueClosedException. Must the producer of
messages care about it or not? I think yes, maybe  I do not understand the
code. With blocking queue there is no doubt - if producer has reference to
abandoned queue, he may put anything into, it will GCed

I think this library is very useful for real usage as well as for learning.
But as project manager, which must take care of codebase maintainability, I
will not agree to import complex-domain library  to solve trivial case.

I was already engaged in ephemeral VT discussion, I remember this library,
now I have a second use-case (websocket) for why I would like to use
ephemeral thread.
But one thing has not changed - the library does not fill my requirement -
I think it is impossible without true ephemeral threads.
My requirement is:
1. One thread may decide to release the blocking queue and its
resources(VT) by removing the queue from global concurrent map
2. But the second thread may trust the queue is working as long as the
second thread has a reference to the blocking queue. Especially, it means
no QueueClosedException. Because the queue is not closed. Because the
reference is live.Additionally, for my previous, not-websocket use case,
even if one thread decided to release a resource, it does not mean blocking
consumer may disappear. I expect the consumer to be like a captain on the
sinking ship - continue work to the end, of course with some deviation from
ordinary flow.

sob., 10 sty 2026 o 16:34 Robert Engels <robaho at me.com> napisa?(a):

> If you?re working with queues, a ?closable queue? works well and it?s non
> intrusive. See the docs.
>
> [image: closablequeue.png]
>
> robaho/closablequeue: a Java FIFO blocking queue with "close" semantics.
> designed for virtual threads. <https://github.com/robaho/closablequeue>
> github.com <https://github.com/robaho/closablequeue>
> <https://github.com/robaho/closablequeue>
>
>
> On Jan 10, 2026, at 6:52?AM, Michal Domagala <outsider404 at gmail.com>
> wrote:
>
> ?
> Hi,
>
> I would like to present my case for ephemeral VT.
> I have a websocket, the websocket has a correlated blocking queue, there
> is a virtual thread which reads from the queue and writes to the websocket
> session.
> When session is closed, I remove blocking queue from global
> concurrent hash map
> But I have to
> - keep reference to VT
> - interrupt VT on-session-closed
> It is similar to  C++ destructor.
> If I can rely on GC, I will just remove blocking queue reference and
> everything will happen automatically.
>
> Regards,
> Michal Domagala
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260111/d1f8e8eb/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: closablequeue.png
Type: image/png
Size: 170923 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260111/d1f8e8eb/closablequeue-0001.png>

From robaho at me.com  Sun Jan 11 00:50:29 2026
From: robaho at me.com (Robert Engels)
Date: Sat, 10 Jan 2026 18:50:29 -0600
Subject: [External] : Re: Ephemeral threads
In-Reply-To: <1ef40f81-0e75-4752-989b-11cd4e5601a7@oracle.com>
References: <1ef40f81-0e75-4752-989b-11cd4e5601a7@oracle.com>
Message-ID: <1604DAB4-FCCA-4362-BAB9-22237B88AFF4@me.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260110/3df9113c/attachment.htm>

From dmitry.zaslavsky at gmail.com  Sun Jan 11 04:17:30 2026
From: dmitry.zaslavsky at gmail.com (Dmitry Zaslavsky)
Date: Sat, 10 Jan 2026 23:17:30 -0500
Subject: [External] : Re: Ephemeral threads
In-Reply-To: <1ef40f81-0e75-4752-989b-11cd4e5601a7@oracle.com>
References: <CAOdgdgzQU4z+8RA2WMuD=nGUtXAdx1D0P8BW3CMQcGcQDcTSYw@mail.gmail.com>
 <518ce8ef-4fa7-4166-a6fd-d2d699e51ba2@oracle.com>
 <f9f15ec0-28cf-40fe-aea8-5ecc89c16d9f@oracle.com>
 <6E8BCF39-B438-4C4A-A892-8C933FB86F92@gmail.com>
 <01c37422-171d-49b0-a216-15bb8aaaf172@oracle.com>
 <5A5AEC77-43CC-4D2D-87E1-3EC6F8D066AF@gmail.com>
 <1ef40f81-0e75-4752-989b-11cd4e5601a7@oracle.com>
Message-ID: <7286AE3F-6E40-4318-B6D1-A363B9C746E7@gmail.com>

Your code would be broken in our case, but it?s broken in ?plain? java case as well.
Meaning park() doesn?t have to return?. Exception could be thrown and release never called?.

Resources must be used with try blocks (or some logically similar construct) 
That?s what we are trying to ?manage? by having a library construct.
That library construct ensures (optionally) that finally (clean up) called up in any case.

The other option I would want to consider is allowing try/finally and throwing an interrupt exception.
I haven?t played with this. Ideally JVM support that lets me know if there is a finally block on stack would be nice.
But I know it?s too much to ask.



> On Jan 10, 2026, at 7:02?PM, Viktor Klang <viktor.klang at oracle.com> wrote:
> 
> Hi Dmitry,
> 
> An example can look like:
> 
> void method() {
>     long fileDescriptor = acquireFileDescriptor();
>     LockSupport.park();
>     releaseFileDescriptor(fileDescriptor);
> }
> 
> If an ephemeral VT executes that method, and there are no other references to that ephemeral VT, then at the point of park(), nothing can unpark it anymore, and it will then never release the file descriptor.
> 
> 
> >We generally don?t allow try blocks (providing other constructs), we also very strongly discourage (just a drop short of disallowing) ANY threading primitives.
> 
> 
> I don't see how that can work in practice, because it requires all users of your constructs to be familiar about exactly how all third-party logic (including JDK classes) are implemented under the hood. Perhaps I'm misunderstanding?
> 
> 
> On 2026-01-09 17:27, Dmitry Zaslavsky wrote:
>> Not sure what you mean by native resources?
>> Do you mean what people would use like try resources?
>> We generally don?t allow try blocks (providing other constructs), we also very strongly discourage (just a drop short of disallowing) ANY threading primitives.
>> 
>> Which makes me think that there is a better way to express my point from before.
>> I think there is actually a common pattern here.
>> 
>> We use VT inside of the lib. We don?t want users to actually use any threads all.
>> I think it?s a goal of Alex as well. 
>> We use VT as  a way to avoid using threads (if that makes sense).
>> 
>> I think ScopedTasks is going in the same direction. Ideally user just doesn?t know there are threads.
>> We use Scala (appealing to Victor ;)) vals and immutable collections is the norm.
>> 
>> We don?t want users to think about Threads period.
>> So the thought of "GC roots on a VT ? we don?t want that though to ever occur or we failed ;)
>> 
>> 
>> 
>>  
>> 
>>> On Jan 9, 2026, at 10:26?AM, Viktor Klang <viktor.klang at oracle.com> <mailto:viktor.klang at oracle.com> wrote:
>>> 
>>> 
>>> On 2026-01-09 15:39, Dmitry Zaslavsky wrote:
>>>> someCollection.apar.map { ?. }
>>>> Can spin N tasks (Each can get it's VT) If some iteration of the loop throws, we don?t need to rest of the code to run, it?s costly.
>>>> If the task are not actively mounted but previously started and are waiting? (in our case it?s LockSupport.park) we just want to drop that entire queue and everything around it?.
>>>> 
>>>> 
>>> How do you handle acquired native resources that are yet to be released?
>>> 
>>> 
>>> -- 
>>> Cheers,
>>> ?
>>> 
>>> 
>>> Viktor Klang
>>> Software Architect, Java Platform Group
>>> Oracle
>>> 
> -- 
> Cheers,
> ?
> 
> 
> Viktor Klang
> Software Architect, Java Platform Group
> Oracle

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260110/cdac6954/attachment-0001.htm>

From robaho at me.com  Sun Jan 11 05:10:57 2026
From: robaho at me.com (Robert Engels)
Date: Sat, 10 Jan 2026 23:10:57 -0600
Subject: [External] : Re: Ephemeral threads
In-Reply-To: <7286AE3F-6E40-4318-B6D1-A363B9C746E7@gmail.com>
References: <7286AE3F-6E40-4318-B6D1-A363B9C746E7@gmail.com>
Message-ID: <C2587117-9D8E-44E5-B2E6-3320DBF07ADF@me.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260110/c65b9e24/attachment.htm>

From outsider404 at gmail.com  Sun Jan 11 11:12:22 2026
From: outsider404 at gmail.com (Michal Domagala)
Date: Sun, 11 Jan 2026 12:12:22 +0100
Subject: Ephemeral threads
In-Reply-To: <84805f86-fa9d-4821-8957-52cab1d35c85@oracle.com>
References: <CAOdgdgzQU4z+8RA2WMuD=nGUtXAdx1D0P8BW3CMQcGcQDcTSYw@mail.gmail.com>
 <518ce8ef-4fa7-4166-a6fd-d2d699e51ba2@oracle.com>
 <f9f15ec0-28cf-40fe-aea8-5ecc89c16d9f@oracle.com>
 <bf0a7ae7-ca5e-48d3-a3bb-e8177fcb95ba@redhat.com>
 <637c717c-eede-4697-aa97-70db7b3e981f@oracle.com>
 <641baf6f-1a6c-423c-8d3c-526c3adbe731@redhat.com>
 <84805f86-fa9d-4821-8957-52cab1d35c85@oracle.com>
Message-ID: <CA+heAJBefH-AU3Yp6AzD7kZMakvLAy_dS-w2jRfDTK5miQDwmQ@mail.gmail.com>

Maybe a good idea would be `Thread.ofEphemeral()` ? Effort on JVM side is
minimal , because each non-tracked VT is ephemeral, everyone who want
experiment with ephemeral has an option, no one will comply about
semaphores, summoned demons, etc. because who consents cannot be injured

sob., 10 sty 2026 o 18:18 Alan Bateman <alan.bateman at oracle.com> napisa?(a):

> On 10/01/2026 16:00, Andrew Haley wrote:
> >
> You can summon other demons
> when the threads act on objects with cleaners (or more generally,
> anything with cleanup actions based on phantom refs). This can lead to
> cleaning actions that attempt to release resources in an inconsistent
> state. Even if we spent a few years on the issues, the usage (to allow
> the alive threads be GC'ed) is very fragile to setup, and the resulting
> behavior would surely be surprising to most developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260111/77249ac6/attachment.htm>

From duke at openjdk.org  Sun Jan 11 12:14:30 2026
From: duke at openjdk.org (duke)
Date: Sun, 11 Jan 2026 12:14:30 GMT
Subject: git: openjdk/loom: fibers: 53 new changesets
Message-ID: <3d353a53-b4b9-4337-89be-113b9efc9ed6@openjdk.org>

Changeset: d7a3df63
Branch: fibers
Author:    Tobias Hotz <tobias.hotz at hotmail.de>
Committer: Tobias Hartmann <thartmann at openjdk.org>
Date:      2026-01-07 11:48:47 +0000
URL:       https://git.openjdk.org/loom/commit/d7a3df639977ac8442eec1efb41de6dc50384150

8374436: compiler/igvn/IntegerDivValueTests.java failed with division by zero

Reviewed-by: chagedorn, thartmann

! test/hotspot/jtreg/compiler/igvn/IntegerDivValueTests.java

Changeset: 929864b1
Branch: fibers
Author:    SendaoYan <syan at openjdk.org>
Date:      2026-01-07 11:51:28 +0000
URL:       https://git.openjdk.org/loom/commit/929864b1a40eb222d3b7b3451fc6d4e5316a7cc8

8362087: Test containers/docker/ShareTmpDir.java intermittent fails

Reviewed-by: sgehwolf, cnorrbin

! test/hotspot/jtreg/containers/docker/ShareTmpDir.java
! test/hotspot/jtreg/containers/docker/WaitForFlagFile.java

Changeset: da14813a
Branch: fibers
Author:    Emanuel Peter <epeter at openjdk.org>
Date:      2026-01-07 12:37:52 +0000
URL:       https://git.openjdk.org/loom/commit/da14813a5bdadaf0a1f81fa57ff6e1b103eaf113

8373453: C2 SuperWord: must handle load slices that have loads with different memory inputs

Reviewed-by: kvn, thartmann, qamai

! src/hotspot/share/opto/vectorization.cpp
! src/hotspot/share/opto/vectorization.hpp
+ test/hotspot/jtreg/compiler/loopopts/superword/TestLoadSliceWithMultipleMemoryInputStates.java

Changeset: 3541bc86
Branch: fibers
Author:    Volkan Yazici <vyazici at openjdk.org>
Date:      2026-01-07 15:38:20 +0000
URL:       https://git.openjdk.org/loom/commit/3541bc8635ad8f5f4151758de3a134c9c105cebd

8373538: Migrate all tests to null-safe "SimpleSSLContext" methods

Reviewed-by: djelinski, jpai

! test/jdk/com/sun/net/httpserver/ClearTextServerSSL.java
! test/jdk/java/net/HttpURLConnection/SetAuthenticator/HTTPTest.java
! test/jdk/java/net/HttpURLConnection/SetAuthenticator/HTTPTestClient.java
! test/jdk/java/net/URLPermission/URLTest.java
! test/jdk/javax/net/ssl/HttpsURLConnection/DummyCacheResponse.java
! test/jdk/javax/net/ssl/HttpsURLConnection/Equals.java
! test/jdk/javax/net/ssl/HttpsURLConnection/HttpsSession.java
! test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIP.java
! test/jdk/sun/net/www/protocol/http/RedirectOnPost.java
! test/jdk/sun/security/krb5/auto/HttpsCB.java
! test/langtools/jdk/javadoc/doclet/testLinkOption/TestRedirectLinks.java
! test/lib/jdk/test/lib/net/SimpleSSLContext.java

Changeset: 640343f7
Branch: fibers
Author:    Jatin Bhateja <jbhateja at openjdk.org>
Date:      2026-01-07 17:00:57 +0000
URL:       https://git.openjdk.org/loom/commit/640343f7d94894b0378ea5b1768eeac203a9aaf8

8373724: Assertion failure in TestSignumVector.java with UseAPX

Reviewed-by: sviswanathan

! src/hotspot/cpu/x86/x86.ad

Changeset: dd20e915
Branch: fibers
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2026-01-07 18:10:06 +0000
URL:       https://git.openjdk.org/loom/commit/dd20e9150666f247af61dfa524a170ef7dd96c03

8374521: Support fine-grained native debug levels

Reviewed-by: erikj, krk, clanger

! .github/workflows/build-alpine-linux.yml
! .github/workflows/build-cross-compile.yml
! .github/workflows/build-linux.yml
! .github/workflows/build-macos.yml
! make/autoconf/flags-cflags.m4

Changeset: 383fe1ef
Branch: fibers
Author:    Erik Joelsson <erikj at openjdk.org>
Date:      2026-01-07 21:52:12 +0000
URL:       https://git.openjdk.org/loom/commit/383fe1efc3a23385b8576e20f458f91085c6325e

8374642: EscapeHash macro fails with GNU make 4.3 and 4.4

Reviewed-by: tbell, shade

! make/common/Utils.gmk

Changeset: 9a944e55
Branch: fibers
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2026-01-07 22:23:39 +0000
URL:       https://git.openjdk.org/loom/commit/9a944e558733950d135b5a91d093b7a28e934f59

8372754: Add wrapper for <cstdlib>
8369205: AIX build break in forbiddenFunctions.hpp

Reviewed-by: mdoerr, tschatzl

! src/hotspot/cpu/aarch64/immediate_aarch64.cpp
! src/hotspot/cpu/aarch64/immediate_aarch64.hpp
! src/hotspot/os/aix/libodm_aix.cpp
! src/hotspot/os/aix/libperfstat_aix.hpp
! src/hotspot/os/aix/os_perf_aix.cpp
! src/hotspot/os/bsd/memMapPrinter_macosx.cpp
! src/hotspot/os/linux/os_linux.cpp
! src/hotspot/os/linux/os_perf_linux.cpp
! src/hotspot/os/posix/forbiddenFunctions_posix.hpp
! src/hotspot/os/posix/os_posix.cpp
! src/hotspot/os/posix/permitForbiddenFunctions_posix.hpp
! src/hotspot/os/windows/os_windows.cpp
! src/hotspot/os/windows/permitForbiddenFunctions_windows.hpp
! src/hotspot/os/windows/vmError_windows.cpp
! src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp
! src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp
! src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp
! src/hotspot/os_cpu/linux_arm/os_linux_arm.cpp
! src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp
! src/hotspot/os_cpu/linux_riscv/os_linux_riscv.cpp
! src/hotspot/os_cpu/linux_s390/os_linux_s390.cpp
! src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp
! src/hotspot/os_cpu/windows_aarch64/os_windows_aarch64.cpp
! src/hotspot/share/classfile/classLoader.cpp
+ src/hotspot/share/cppstdlib/cstdlib.hpp
! src/hotspot/share/utilities/byteswap.hpp
! src/hotspot/share/utilities/forbiddenFunctions.hpp
! src/hotspot/share/utilities/globalDefinitions_gcc.hpp
! src/hotspot/share/utilities/globalDefinitions_visCPP.hpp
! src/hotspot/share/utilities/parseInteger.hpp
! src/hotspot/share/utilities/permitForbiddenFunctions.hpp
! test/hotspot/gtest/gtestMain.cpp
! test/hotspot/gtest/unittest.hpp
! test/hotspot/gtest/utilities/test_bitMap_setops.cpp

Changeset: 0a1fa219
Branch: fibers
Author:    Chad Rakoczy <chadrako at amazon.com>
Committer: Leonid Mesnik <lmesnik at openjdk.org>
Date:      2026-01-08 01:14:01 +0000
URL:       https://git.openjdk.org/loom/commit/0a1fa219214b985e4c7d9e612bd5cda1b0f25577

8369150: NMethodRelocationTest fails when JVMTI events not published before JVM exit

Reviewed-by: lmesnik, sspitsyn

! test/hotspot/jtreg/ProblemList.txt
! test/hotspot/jtreg/serviceability/jvmti/NMethodRelocation/NMethodRelocationTest.java
! test/hotspot/jtreg/serviceability/jvmti/NMethodRelocation/libNMethodRelocationTest.cpp
! test/lib/jdk/test/lib/jvmti/jvmti_common.hpp

Changeset: 70669d05
Branch: fibers
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2026-01-08 04:43:06 +0000
URL:       https://git.openjdk.org/loom/commit/70669d0585c708e04befe0f9ba945f6154f9afec

8374712: AOTMappedHeapWriter::relocate_field_in_buffer should use CompressedOops::narrow_oop_cast

Reviewed-by: kvn

! src/hotspot/share/cds/aotMappedHeapWriter.cpp

Changeset: 95137580
Branch: fibers
Author:    Ioi Lam <iklam at openjdk.org>
Date:      2026-01-08 05:31:06 +0000
URL:       https://git.openjdk.org/loom/commit/95137580b81fb48474b0d8fb748d9d4af7a27850

8374662: Remove unused type check functions from javaClasses.hpp

Reviewed-by: jsjolen

! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/classfile/javaClasses.hpp

Changeset: e6abf98e
Branch: fibers
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2026-01-08 07:01:03 +0000
URL:       https://git.openjdk.org/loom/commit/e6abf98e35079ed1b5547f2cc0ac6f518b78d67b

8374434: Several JShell tests report JUnit discovery warnings

Reviewed-by: jpai

! test/langtools/jdk/jshell/ErrorTranslationTest.java
! test/langtools/jdk/jshell/IdGeneratorTest.java
! test/langtools/jdk/jshell/KullaCompletenessStressTest.java

Changeset: 1a6da449
Branch: fibers
Author:    Per Minborg <pminborg at openjdk.org>
Date:      2026-01-08 08:14:57 +0000
URL:       https://git.openjdk.org/loom/commit/1a6da4499cf8805ff3e1e517fbca81c2eeb987a9

8374467: Incorrect ranges in jdk.internal.util.ByteArray JavaDoc

Reviewed-by: rriggs

! src/java.base/share/classes/jdk/internal/util/ByteArray.java
! src/java.base/share/classes/jdk/internal/util/ByteArrayLittleEndian.java

Changeset: a71326a0
Branch: fibers
Author:    Emanuel Peter <epeter at openjdk.org>
Date:      2026-01-08 08:32:02 +0000
URL:       https://git.openjdk.org/loom/commit/a71326a0e2660158fdb85282da4b59ce61c66ee3

8374528: C2 SuperWord: TestAliasingFuzzer.java strengthen no-multiversioning IR rule

Reviewed-by: chagedorn, mhaessig

! test/hotspot/jtreg/compiler/loopopts/superword/TestAliasingFuzzer.java

Changeset: 08ff16f0
Branch: fibers
Author:    Ramkumar Sunderbabu <rsunderbabu at openjdk.org>
Committer: SendaoYan <syan at openjdk.org>
Date:      2026-01-08 09:25:11 +0000
URL:       https://git.openjdk.org/loom/commit/08ff16f0aa8eaa9596da52d568720c69c897f3c5

8374576: Disable MemoryEaterMT for VirtualThread

Reviewed-by: lmesnik, dholmes

! test/hotspot/jtreg/vmTestbase/gc/gctests/MemoryEaterMT/MemoryEaterMT.java

Changeset: 067fd3cb
Branch: fibers
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2026-01-08 09:32:51 +0000
URL:       https://git.openjdk.org/loom/commit/067fd3cb2fa6a4a0484a922df8efbde03325ad3d

8374768: S390X builds are failing after JDK-8372754

Reviewed-by: stefank, mdoerr

! src/hotspot/os_cpu/linux_s390/os_linux_s390.cpp

Changeset: 904ba5f5
Branch: fibers
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
Date:      2026-01-08 10:24:03 +0000
URL:       https://git.openjdk.org/loom/commit/904ba5f5ed7d3ac1a3606ff7532ba3c206a2d9b9

8374718: Generation of CompilerProperties can fail in subtle ways

Reviewed-by: jlahoda

! make/langtools/tools/propertiesparser/gen/ClassGenerator.java
! make/langtools/tools/propertiesparser/resources/templates.properties
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java

Changeset: c5159fc9
Branch: fibers
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2026-01-08 11:07:08 +0000
URL:       https://git.openjdk.org/loom/commit/c5159fc9fa0fd81dec629cd821b3411b4a6df967

8374328: Convert simple AtomicAccess uses in gc/shared to use Atomic<T>

Reviewed-by: dholmes, tschatzl

! src/hotspot/share/gc/shared/barrierSetNMethod.cpp
! src/hotspot/share/gc/shared/concurrentGCThread.cpp
! src/hotspot/share/gc/shared/concurrentGCThread.hpp
! src/hotspot/share/gc/shared/gcLocker.cpp
! src/hotspot/share/gc/shared/gcLocker.hpp
! src/hotspot/share/gc/shared/gcLocker.inline.hpp
! src/hotspot/share/gc/shared/pretouchTask.cpp
! src/hotspot/share/gc/shared/pretouchTask.hpp
! src/hotspot/share/gc/shared/suspendibleThreadSet.cpp
! src/hotspot/share/gc/shared/suspendibleThreadSet.hpp
! src/hotspot/share/gc/shared/workerThread.cpp
! src/hotspot/share/gc/shared/workerThread.hpp

Changeset: 78b1ca6c
Branch: fibers
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2026-01-08 12:44:08 +0000
URL:       https://git.openjdk.org/loom/commit/78b1ca6cc14e1a92bf25cbcfb687067ac17af92b

8374711: Hotspot runtime/CommandLine/OptionsValidation/TestOptionsWithRanges fails without printing the option name

Reviewed-by: mdoerr, dholmes

! test/hotspot/jtreg/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOption.java

Changeset: ec657349
Branch: fibers
Author:    Brian Burkhalter <bpb at openjdk.org>
Date:      2026-01-08 16:28:10 +0000
URL:       https://git.openjdk.org/loom/commit/ec657349ff654dcb41b9f17178aeea638329101e

8374641: Remove java/nio/channels/AsyncCloseAndInterrupt.java from problem list

Reviewed-by: iris

! test/jdk/ProblemList.txt

Changeset: 677572b4
Branch: fibers
Author:    Brian Burkhalter <bpb at openjdk.org>
Date:      2026-01-08 16:28:43 +0000
URL:       https://git.openjdk.org/loom/commit/677572b42d6d0ee62063c3f19ffad1e501ac9bf3

8372377: Test java/io/File/GetXSpace.java failed: The system cannot find the path specified

Reviewed-by: alanb, jpai

! test/jdk/java/io/File/GetXSpace.java
! test/jdk/java/io/File/libGetXSpace.c

Changeset: fa2eb626
Branch: fibers
Author:    Erik Gahlin <egahlin at openjdk.org>
Date:      2026-01-08 16:34:39 +0000
URL:       https://git.openjdk.org/loom/commit/fa2eb626478806dc64fe03d8729f53f7ed26a172

8367949: JFR: MethodTrace double-counts methods that catch their own exceptions

Reviewed-by: mgronlun

! src/jdk.jfr/share/classes/jdk/jfr/internal/tracing/Instrumentation.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/tracing/Method.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/tracing/Transform.java
+ test/jdk/jdk/jfr/event/tracing/TestConstructors.java
! test/jdk/jdk/jfr/event/tracing/TestInstrumentation.java

Changeset: c834e4c6
Branch: fibers
Author:    Jonas Norlinder <jnorlinder at openjdk.org>
Committer: Claes Redestad <redestad at openjdk.org>
Date:      2026-01-08 16:46:28 +0000
URL:       https://git.openjdk.org/loom/commit/c834e4c641bf6c73e88b93c0cdba40a83f3192c1

8373647: Avoid fstat when opening file for write with RandomAccessFile or FileOutputStream

Reviewed-by: redestad, alanb

! src/java.base/unix/native/libjava/io_util_md.c
! test/micro/org/openjdk/bench/java/io/FileWrite.java

Changeset: 7e1051bf
Branch: fibers
Author:    Francisco Ferrari Bihurriet <fferrari at openjdk.org>
Date:      2026-01-08 16:46:48 +0000
URL:       https://git.openjdk.org/loom/commit/7e1051bfcc01aad538376c86354e16e25d2eaf7a

8352728: InternalError loading java.security due to Windows parent folder permissions

Reviewed-by: weijun, mullan

! src/java.base/share/classes/java/security/Security.java
- test/jdk/java/security/Security/ConfigFileTest.java
+ test/jdk/java/security/Security/SecurityPropFile/ExtraFileAndIncludes.java
+ test/jdk/java/security/Security/SecurityPropFile/LinuxAnonymousFiles.java
- test/jdk/java/security/Security/SecurityPropFile/SecurityPropFile.file
- test/jdk/java/security/Security/SecurityPropFile/SecurityPropFile.java
+ test/jdk/java/security/Security/SecurityPropFile/WindowsParentDirPermissions.java

Changeset: afd216ec
Branch: fibers
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2026-01-08 17:19:12 +0000
URL:       https://git.openjdk.org/loom/commit/afd216ec3f5bfd1be88c6f4d4f53b763205c4fee

8374752: Add more JLS links to javax.lang.model.element.*

Reviewed-by: liach

! src/java.compiler/share/classes/javax/lang/model/element/ExecutableElement.java
! src/java.compiler/share/classes/javax/lang/model/element/PackageElement.java
! src/java.compiler/share/classes/javax/lang/model/element/Parameterizable.java
! src/java.compiler/share/classes/javax/lang/model/element/QualifiedNameable.java
! src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java
! src/java.compiler/share/classes/javax/lang/model/element/TypeParameterElement.java
! src/java.compiler/share/classes/javax/lang/model/element/VariableElement.java

Changeset: 92abc6df
Branch: fibers
Author:    Mark Powers <mpowers at openjdk.org>
Date:      2026-01-08 17:35:43 +0000
URL:       https://git.openjdk.org/loom/commit/92abc6dfe43a2c1f10dcfcf1e197fc9369f70ee3

8369282: Distrust TLS server certificates anchored by Chunghwa ePKI Root CA

Reviewed-by: mullan

! src/java.base/share/classes/sun/security/validator/CADistrustPolicy.java
+ src/java.base/share/classes/sun/security/validator/ChunghwaTLSPolicy.java
! src/java.base/share/conf/security/java.security
+ test/jdk/sun/security/ssl/X509TrustManagerImpl/distrust/Chunghwa.java
+ test/jdk/sun/security/ssl/X509TrustManagerImpl/distrust/chains/chunghwa/chunghwaepkirootca-chain.pem

Changeset: 1fb5030a
Branch: fibers
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2026-01-08 17:58:35 +0000
URL:       https://git.openjdk.org/loom/commit/1fb5030ab351a52b4a7455cbdd57f5b50aab9bd5

8374767: Amend JDK-8374521 with new option name

Reviewed-by: clanger, krk

! .github/workflows/build-alpine-linux.yml
! .github/workflows/build-cross-compile.yml
! .github/workflows/build-linux.yml
! .github/workflows/build-macos.yml
! make/autoconf/flags-cflags.m4

Changeset: 9fd86e37
Branch: fibers
Author:    Ioi Lam <iklam at openjdk.org>
Date:      2026-01-08 18:42:20 +0000
URL:       https://git.openjdk.org/loom/commit/9fd86e37492c419fbae0837f69aab26a201c927e

8374639: Static archive with AOTClassLinking breaks dynamic archive

Reviewed-by: coleenp, matsaave

! src/hotspot/share/cds/aotConstantPoolResolver.cpp
! src/hotspot/share/cds/aotMetaspace.cpp
! src/hotspot/share/cds/archiveBuilder.cpp
! src/hotspot/share/cds/dynamicArchive.cpp
! src/hotspot/share/cds/dynamicArchive.hpp
+ test/hotspot/jtreg/runtime/cds/appcds/aotClassLinking/DynamicDumpWithAOTLinkedStaticArchive.java
- test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/ArrayKlasses.java
- test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/test-classes/ArrayKlassesApp.java
! test/lib/jdk/test/lib/cds/CDSAppTester.java
! test/lib/jdk/test/lib/cds/SimpleCDSAppTester.java

Changeset: 8212993a
Branch: fibers
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2026-01-08 18:51:25 +0000
URL:       https://git.openjdk.org/loom/commit/8212993ac331d8761ddb7c0eef23dbfcc6ca0c7d

8374540: Add comment describing implementation choices of Math.fma

Reviewed-by: rgiulietti

! src/java.base/share/classes/java/lang/Math.java

Changeset: 1342db0b
Branch: fibers
Author:    Justin Lu <jlu at openjdk.org>
Date:      2026-01-08 19:02:06 +0000
URL:       https://git.openjdk.org/loom/commit/1342db0bde25c111b25f4339ae2a858dc3b15687

8374051: Incorrect parameterized testing of exceptions in AbstractDateTimeTest.java

Reviewed-by: naoto, rriggs

! test/jdk/java/time/tck/java/time/AbstractDateTimeTest.java
! test/jdk/java/time/tck/java/time/TCKInstant.java
! test/jdk/java/time/tck/java/time/TCKLocalDate.java
! test/jdk/java/time/tck/java/time/TCKLocalTime.java
! test/jdk/java/time/tck/java/time/TCKMonthDay.java
! test/jdk/java/time/tck/java/time/TCKOffsetDateTime.java
! test/jdk/java/time/tck/java/time/TCKOffsetTime.java
! test/jdk/java/time/tck/java/time/TCKYearMonth.java
! test/jdk/java/time/tck/java/time/TCKZonedDateTime.java

Changeset: 982aa3f8
Branch: fibers
Author:    Phil Race <prr at openjdk.org>
Date:      2026-01-08 19:47:01 +0000
URL:       https://git.openjdk.org/loom/commit/982aa3f8ead84817be5373c3257d48feab1758d3

8336654: [lworld] Tests depending on sun.awt.AppContext can fail when run with migrated classes

Reviewed-by: serb, azvegint

! src/java.desktop/macosx/classes/com/apple/laf/AquaUtils.java
! src/java.desktop/share/classes/sun/awt/AppContext.java
! src/java.desktop/share/classes/sun/awt/image/ImageCache.java
- test/jdk/javax/swing/Security/6657138/bug6657138.java

Changeset: 385c4f81
Branch: fibers
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
Date:      2026-01-08 20:46:38 +0000
URL:       https://git.openjdk.org/loom/commit/385c4f8180d30c0e41b848eb4b2c1c8788211422

8373714: Shenandoah: Register heuristic penalties following a degenerated GC

Reviewed-by: wkemper

! src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.cpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.hpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.hpp
! src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.cpp

Changeset: 368de9ff
Branch: fibers
Author:    SendaoYan <syan at openjdk.org>
Date:      2026-01-09 02:09:37 +0000
URL:       https://git.openjdk.org/loom/commit/368de9ff2e46e4c66ee57b5fb961804c5d25c42a

8374721: containers/docker/ShareTmpDir.java timed out after 8362087

Reviewed-by: cnorrbin, sgehwolf

! test/hotspot/jtreg/containers/docker/ShareTmpDir.java

Changeset: 9932c78c
Branch: fibers
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2026-01-09 02:27:16 +0000
URL:       https://git.openjdk.org/loom/commit/9932c78c238f9b7959e28a056c37a88a7f6ce958

8374749: Clarify AnnotationValue specification

Reviewed-by: liach, iris

! src/java.compiler/share/classes/javax/lang/model/element/AnnotationMirror.java
! src/java.compiler/share/classes/javax/lang/model/element/AnnotationValue.java

Changeset: 775f48de
Branch: fibers
Author:    Jasmine Karthikeyan <jkarthikeyan at openjdk.org>
Date:      2026-01-09 05:16:32 +0000
URL:       https://git.openjdk.org/loom/commit/775f48de6129092d05650fec17dad171944e6d89

8365570: C2 fails assert(false) failed: Unexpected node in SuperWord truncation: CastII

Reviewed-by: chagedorn, thartmann, epeter

! src/hotspot/share/opto/superword.cpp
! test/hotspot/jtreg/compiler/vectorization/TestSubwordTruncation.java

Changeset: a4fb07ee
Branch: fibers
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2026-01-09 06:26:16 +0000
URL:       https://git.openjdk.org/loom/commit/a4fb07ee3e26c2f0ed3111c39c3a22167d292d04

8374644: Regression in GZIPInputStream performance after JDK-7036144

Reviewed-by: lancea, alanb

! src/java.base/share/classes/java/util/zip/GZIPInputStream.java

Changeset: 42313289
Branch: fibers
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2026-01-09 07:16:58 +0000
URL:       https://git.openjdk.org/loom/commit/423132895d4ee787d13daa412f9a3f9438834117

8374698: Stub names should look more like identifiers

Reviewed-by: adinn, kvn

! src/hotspot/share/opto/callnode.cpp
! src/hotspot/share/opto/callnode.hpp
! src/hotspot/share/opto/escape.cpp
! src/hotspot/share/runtime/stubDeclarations.hpp
! src/hotspot/share/runtime/stubInfo.cpp

Changeset: a8552243
Branch: fibers
Author:    Jonas Norlinder <jnorlinder at openjdk.org>
Committer: Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-09 08:41:39 +0000
URL:       https://git.openjdk.org/loom/commit/a855224305e025aea80165ae63ee921dca299b9c

8373695: G1: Using a value near integer max for ActiveProcessorCount causes fatal crash

Reviewed-by: stefank, tschatzl

! src/hotspot/share/gc/g1/g1Arguments.cpp

Changeset: 2a965dff
Branch: fibers
Author:    Jeremy Wood <jwood at openjdk.org>
Committer: Jayathirth D V <jdv at openjdk.org>
Date:      2026-01-09 09:56:39 +0000
URL:       https://git.openjdk.org/loom/commit/2a965dffdd2791ab87a2dbfba8ed44f8adb996c7

8374377: PNGImageDecoder Slow For 8-bit PNGs

Reviewed-by: jdv, prr

! src/java.desktop/share/classes/sun/awt/image/PNGImageDecoder.java
+ test/jdk/sun/awt/image/png/PngImageDecoder8BitTest.java
+ test/micro/org/openjdk/bench/java/awt/image/PNGImageDecoder_8bit_uninterlaced.java

Changeset: c8c6e700
Branch: fibers
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2026-01-09 10:23:03 +0000
URL:       https://git.openjdk.org/loom/commit/c8c6e7007aec9a568c25dcd5d4242b7911a83bfe

8374825: vmTestbase comment typo: lunch

Reviewed-by: tschatzl, shade

! test/hotspot/jtreg/vmTestbase/nsk/share/gc/Algorithms.java
! test/hotspot/jtreg/vmTestbase/nsk/share/gc/gp/GarbageUtils.java

Changeset: 47e19353
Branch: fibers
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2026-01-09 12:24:13 +0000
URL:       https://git.openjdk.org/loom/commit/47e19353cd3661ad9aed00f6a415818da45cdfef

8373941: Epsilon: Robust counter updates in early VM phases

Reviewed-by: stefank, tschatzl

! src/hotspot/share/gc/epsilon/epsilonHeap.cpp
! src/hotspot/share/gc/epsilon/epsilonHeap.hpp
! src/hotspot/share/gc/epsilon/epsilonMonitoringSupport.cpp
! src/hotspot/share/gc/epsilon/epsilonMonitoringSupport.hpp
+ test/hotspot/jtreg/gc/epsilon/TestInitAllocs.java

Changeset: 6d1bfdf7
Branch: fibers
Author:    Coleen Phillimore <coleenp at openjdk.org>
Date:      2026-01-09 13:14:25 +0000
URL:       https://git.openjdk.org/loom/commit/6d1bfdf7a92e44ff855307f86d1734fad909ea3d

8374796: CompressedOops versions of runtime/cds/TestDefaultArchiveLoading.java aren't run

Reviewed-by: stefank, shade

! test/hotspot/jtreg/runtime/cds/TestDefaultArchiveLoading.java

Changeset: 8737a8ca
Branch: fibers
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
Date:      2026-01-09 14:49:52 +0000
URL:       https://git.openjdk.org/loom/commit/8737a8ca73952d60129e7fc2f7e17eea3b800af7

8373448: jpackage: StackOverflowError when processing a very long argument

Reviewed-by: almatvee

! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardOption.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/StandardOptionTest.java

Changeset: f5fa9e40
Branch: fibers
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2026-01-09 16:49:04 +0000
URL:       https://git.openjdk.org/loom/commit/f5fa9e40b09b7b6322edb5f057a6350d44980e14

8374745: Test vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters004/TestDescription.java failed

Reviewed-by: lmesnik, sspitsyn

! test/hotspot/jtreg/vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters001/CollectionCounters001.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters002/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters003/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters004/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters005/TestDescription.java

Changeset: 663a0833
Branch: fibers
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
Date:      2026-01-09 22:20:05 +0000
URL:       https://git.openjdk.org/loom/commit/663a08331a83c852622b8b11900f12b0dc3dbe82

8374219: Fix issues in jpackage's Executor class

Reviewed-by: almatvee

! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/DesktopIntegration.java
! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LibProvidersLookup.java
! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxBundlingEnvironment.java
! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxDebPackager.java
! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxDebSystemEnvironment.java
! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxDebSystemEnvironmentMixin.java
! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxFromOptions.java
! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxLaunchersAsServices.java
! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxPackageArch.java
! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxPackageBuilder.java
! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxRpmSystemEnvironment.java
! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxRpmSystemEnvironmentMixin.java
! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxSystemEnvironment.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/AppImageSigner.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/Codesign.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacBundlingEnvironment.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacCertificateUtils.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacDmgPackager.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacDmgSystemEnvironment.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacPkgPackager.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/TempKeychain.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/DefaultBundlingEnvironment.java
- src/jdk.jpackage/share/classes/jdk/jpackage/internal/Enquoter.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/Executor.java
+ src/jdk.jpackage/share/classes/jdk/jpackage/internal/ExecutorFactory.java
+ src/jdk.jpackage/share/classes/jdk/jpackage/internal/Globals.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/IOUtils.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/JLinkRuntimeBuilder.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/Log.java
+ src/jdk.jpackage/share/classes/jdk/jpackage/internal/ObjectFactory.java
- src/jdk.jpackage/share/classes/jdk/jpackage/internal/RetryExecutor.java
+ src/jdk.jpackage/share/classes/jdk/jpackage/internal/RetryExecutorFactory.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/SystemEnvironment.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/ToolValidator.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/Main.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources.properties
+ src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/CommandLineFormat.java
+ src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/CommandOutputControl.java
+ src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/Enquoter.java
+ src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/RetryExecutor.java
+ src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/TeeOutputStream.java
! src/jdk.jpackage/unix/classes/jdk/jpackage/internal/UnixLaunchersAsServices.java
! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinBundlingEnvironment.java
! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixTool.java
- test/jdk/tools/jpackage/helpers-test/jdk/jpackage/test/ExecutorTest.java
! test/jdk/tools/jpackage/helpers-test/jdk/jpackage/test/PackageTestTest.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/Executor.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/LinuxHelper.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacHelper.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacSign.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacSignVerify.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/WindowsHelper.java
+ test/jdk/tools/jpackage/helpers/jdk/jpackage/test/mock/CommandAction.java
+ test/jdk/tools/jpackage/helpers/jdk/jpackage/test/mock/CommandActionSpec.java
+ test/jdk/tools/jpackage/helpers/jdk/jpackage/test/mock/CommandActionSpecs.java
+ test/jdk/tools/jpackage/helpers/jdk/jpackage/test/mock/CommandMock.java
+ test/jdk/tools/jpackage/helpers/jdk/jpackage/test/mock/CommandMockExit.java
+ test/jdk/tools/jpackage/helpers/jdk/jpackage/test/mock/CommandMockSpec.java
+ test/jdk/tools/jpackage/helpers/jdk/jpackage/test/mock/CompletableCommandMock.java
+ test/jdk/tools/jpackage/helpers/jdk/jpackage/test/mock/MockIOException.java
+ test/jdk/tools/jpackage/helpers/jdk/jpackage/test/mock/MockIllegalStateException.java
+ test/jdk/tools/jpackage/helpers/jdk/jpackage/test/mock/MockingToolProvider.java
+ test/jdk/tools/jpackage/helpers/jdk/jpackage/test/mock/Script.java
+ test/jdk/tools/jpackage/helpers/jdk/jpackage/test/mock/ScriptSpec.java
+ test/jdk/tools/jpackage/helpers/jdk/jpackage/test/mock/ScriptSpecInDir.java
+ test/jdk/tools/jpackage/helpers/jdk/jpackage/test/mock/ToolProviderCommandMock.java
+ test/jdk/tools/jpackage/helpers/jdk/jpackage/test/mock/ToolProviderCompletableCommandMock.java
+ test/jdk/tools/jpackage/helpers/jdk/jpackage/test/mock/VerbatimCommandMock.java
+ test/jdk/tools/jpackage/junit/linux/jdk.jpackage/jdk/jpackage/internal/LibProvidersLookupTest.java
+ test/jdk/tools/jpackage/junit/linux/jdk.jpackage/jdk/jpackage/internal/LinuxPackageArchTest.java
+ test/jdk/tools/jpackage/junit/linux/jdk.jpackage/jdk/jpackage/internal/LinuxSystemEnvironmentTest.java
! test/jdk/tools/jpackage/junit/linux/junit.java
+ test/jdk/tools/jpackage/junit/macosx/jdk.jpackage/jdk/jpackage/internal/MacDmgPackagerTest.java
+ test/jdk/tools/jpackage/junit/macosx/jdk.jpackage/jdk/jpackage/internal/MacDmgSystemEnvironmentTest.java
! test/jdk/tools/jpackage/junit/macosx/junit.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/DefaultBundlingEnvironmentTest.java
- test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/EnquoterTest.java
+ test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/ExecutorTest.java
+ test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/MockUtils.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/OptionsValidationFailTest.excludes
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/OptionsValidationFailTest.java
+ test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/util/CommandOutputControlTest.java
+ test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/util/CommandOutputControlTestUtils.java
+ test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/util/EnquoterTest.java
+ test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/util/RetryExecutorTest.java
! test/jdk/tools/jpackage/share/ErrorTest.java
! test/jdk/tools/jpackage/share/PostImageScriptTest.java

Changeset: 805866bb
Branch: fibers
Author:    jonghoonpark <dev at jonghoonpark.com>
Committer: Kim Barrett <kbarrett at openjdk.org>
Date:      2026-01-09 22:42:53 +0000
URL:       https://git.openjdk.org/loom/commit/805866bbf680f44219e5c634eb9726e1c5dea690

8372040: Remove Prefetch header vs inline header separation

Reviewed-by: kbarrett, stefank

! src/hotspot/os_cpu/aix_ppc/prefetch_aix_ppc.inline.hpp
! src/hotspot/os_cpu/bsd_aarch64/prefetch_bsd_aarch64.inline.hpp
! src/hotspot/os_cpu/bsd_x86/prefetch_bsd_x86.inline.hpp
! src/hotspot/os_cpu/bsd_zero/prefetch_bsd_zero.inline.hpp
! src/hotspot/os_cpu/linux_aarch64/prefetch_linux_aarch64.inline.hpp
! src/hotspot/os_cpu/linux_arm/prefetch_linux_arm.inline.hpp
! src/hotspot/os_cpu/linux_ppc/prefetch_linux_ppc.inline.hpp
! src/hotspot/os_cpu/linux_riscv/prefetch_linux_riscv.inline.hpp
! src/hotspot/os_cpu/linux_s390/prefetch_linux_s390.inline.hpp
! src/hotspot/os_cpu/linux_x86/prefetch_linux_x86.inline.hpp
! src/hotspot/os_cpu/linux_zero/prefetch_linux_zero.inline.hpp
! src/hotspot/os_cpu/windows_aarch64/prefetch_windows_aarch64.inline.hpp
! src/hotspot/os_cpu/windows_x86/prefetch_windows_x86.inline.hpp
! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp
! src/hotspot/share/gc/serial/cardTableRS.cpp
! src/hotspot/share/gc/serial/generation.hpp
- src/hotspot/share/runtime/prefetch.hpp
! src/hotspot/share/runtime/prefetch.inline.hpp

Changeset: 74faf033
Branch: fibers
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
Date:      2026-01-09 23:36:19 +0000
URL:       https://git.openjdk.org/loom/commit/74faf033127ab3a5e28be75b91e662c589f81084

8374819: jpackage and jpackage tests leave some I/O streams unclosed

Reviewed-by: almatvee

! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/AppImageInfoPListFile.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageFile.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/PListReader.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/AppImageFile.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/LauncherVerifier.java
! test/jdk/tools/jpackage/macosx/HostArchPkgTest.java
! test/jdk/tools/jpackage/windows/WinLongVersionTest.java

Changeset: a726e834
Branch: fibers
Author:    John Jiang <jjiang at openjdk.org>
Date:      2026-01-10 00:52:34 +0000
URL:       https://git.openjdk.org/loom/commit/a726e834b6d3674f0d573d8a0df6eb00464b825b

8373231: ECDSAOperations::toAffinePoint is redundant

Reviewed-by: mullan

! src/java.base/share/classes/sun/security/ec/ECDSAOperations.java
! test/jdk/sun/security/ec/ECDSAPrimitive.java

Changeset: 0537a3fa
Branch: fibers
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2026-01-10 01:55:00 +0000
URL:       https://git.openjdk.org/loom/commit/0537a3fae9bd55ab8b7279da7d3ee4b5ce5bc492

8374922: Build failure after JDK-8372040

Reviewed-by: smarks

! src/hotspot/share/gc/serial/serialHeap.cpp

Changeset: 657d5f77
Branch: fibers
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2026-01-10 02:17:37 +0000
URL:       https://git.openjdk.org/loom/commit/657d5f77f4985304995ee44fc2ae1643504de8df

8374754: jtreg failure handler - replace inline javascript and inline event handlers with same origin javascript files

Reviewed-by: erikj

! test/failure_handler/src/share/classes/jdk/test/failurehandler/HtmlPage.java
! test/failure_handler/src/share/classes/jdk/test/failurehandler/HtmlSection.java
! test/failure_handler/src/share/classes/jdk/test/failurehandler/jtreg/GatherDiagnosticInfoObserver.java
! test/failure_handler/src/share/classes/jdk/test/failurehandler/jtreg/GatherProcessInfoTimeoutHandler.java

Changeset: 12894a87
Branch: fibers
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
Date:      2026-01-10 11:10:06 +0000
URL:       https://git.openjdk.org/loom/commit/12894a870a3c8d1da13a885cc006458ae9475b6e

8373643: Test serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java still failing

Reviewed-by: lmesnik

! test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java

Changeset: 659b53fe
Branch: fibers
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
Date:      2026-01-10 15:04:16 +0000
URL:       https://git.openjdk.org/loom/commit/659b53fe33eaa531bca1951a26f357b51902311e

8374923: runtime/cds/ServiceLoaderTest.java fails with mismatch between cds and non-cds

Reviewed-by: almatvee

! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/Main.java

Changeset: 3d9e866f
Branch: fibers
Author:    Alan Bateman <alan.bateman at oracle.com>
Date:      2026-01-11 07:47:13 +0000
URL:       https://git.openjdk.org/loom/commit/3d9e866f60bdebc55b59b9fd40a4898002c35e96

Merge branch 'master' into fibers

! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/classfile/javaClasses.hpp
! test/jdk/ProblemList.txt
! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/classfile/javaClasses.hpp
! test/jdk/ProblemList.txt


From nigro.fra at gmail.com  Sun Jan 11 12:15:35 2026
From: nigro.fra at gmail.com (Francesco Nigro)
Date: Sun, 11 Jan 2026 13:15:35 +0100
Subject: Ephemeral threads
In-Reply-To: <CA+heAJBefH-AU3Yp6AzD7kZMakvLAy_dS-w2jRfDTK5miQDwmQ@mail.gmail.com>
References: <CAOdgdgzQU4z+8RA2WMuD=nGUtXAdx1D0P8BW3CMQcGcQDcTSYw@mail.gmail.com>
 <518ce8ef-4fa7-4166-a6fd-d2d699e51ba2@oracle.com>
 <f9f15ec0-28cf-40fe-aea8-5ecc89c16d9f@oracle.com>
 <bf0a7ae7-ca5e-48d3-a3bb-e8177fcb95ba@redhat.com>
 <637c717c-eede-4697-aa97-70db7b3e981f@oracle.com>
 <641baf6f-1a6c-423c-8d3c-526c3adbe731@redhat.com>
 <84805f86-fa9d-4821-8957-52cab1d35c85@oracle.com>
 <CA+heAJBefH-AU3Yp6AzD7kZMakvLAy_dS-w2jRfDTK5miQDwmQ@mail.gmail.com>
Message-ID: <CAKxGtTU8une5UgQk62Djjra9-NMA_mAOoPfb-nhQPJEe_x246A@mail.gmail.com>

Just FYI in my experience on writing a Netty custom scheduler I had to
implement on top of. JCTools algorithm (mpsc) a closeable queue for the per
carrier run queue.
You can find the code at
https://github.com/franz1981/Netty-VirtualThread-Scheduler/blob/master/core/src/main/java/io/netty/loom/MpscUnboundedStream.java

And it was useful to have a precise semantic to allow VT bound to run on a
specific carrier to make progress (or complete) once racing with their
scheduler if latter is shutdown.

disclaimer: I am one of the JCTools developers

Il dom 11 gen 2026, 12:12 Michal Domagala <outsider404 at gmail.com> ha
scritto:

> Maybe a good idea would be `Thread.ofEphemeral()` ? Effort on JVM side is
> minimal , because each non-tracked VT is ephemeral, everyone who want
> experiment with ephemeral has an option, no one will comply about
> semaphores, summoned demons, etc. because who consents cannot be injured
>
> sob., 10 sty 2026 o 18:18 Alan Bateman <alan.bateman at oracle.com>
> napisa?(a):
>
>> On 10/01/2026 16:00, Andrew Haley wrote:
>> >
>> You can summon other demons
>> when the threads act on objects with cleaners (or more generally,
>> anything with cleanup actions based on phantom refs). This can lead to
>> cleaning actions that attempt to release resources in an inconsistent
>> state. Even if we spent a few years on the issues, the usage (to allow
>> the alive threads be GC'ed) is very fragile to setup, and the resulting
>> behavior would surely be surprising to most developers
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260111/85a327f0/attachment.htm>

From duke at openjdk.org  Sun Jan 11 12:17:25 2026
From: duke at openjdk.org (duke)
Date: Sun, 11 Jan 2026 12:17:25 GMT
Subject: git: openjdk/loom: master: 52 new changesets
Message-ID: <34ef0b24-2633-4e37-8404-709fd1237b6d@openjdk.org>

Changeset: d7a3df63
Branch: master
Author:    Tobias Hotz <tobias.hotz at hotmail.de>
Committer: Tobias Hartmann <thartmann at openjdk.org>
Date:      2026-01-07 11:48:47 +0000
URL:       https://git.openjdk.org/loom/commit/d7a3df639977ac8442eec1efb41de6dc50384150

8374436: compiler/igvn/IntegerDivValueTests.java failed with division by zero

Reviewed-by: chagedorn, thartmann

! test/hotspot/jtreg/compiler/igvn/IntegerDivValueTests.java

Changeset: 929864b1
Branch: master
Author:    SendaoYan <syan at openjdk.org>
Date:      2026-01-07 11:51:28 +0000
URL:       https://git.openjdk.org/loom/commit/929864b1a40eb222d3b7b3451fc6d4e5316a7cc8

8362087: Test containers/docker/ShareTmpDir.java intermittent fails

Reviewed-by: sgehwolf, cnorrbin

! test/hotspot/jtreg/containers/docker/ShareTmpDir.java
! test/hotspot/jtreg/containers/docker/WaitForFlagFile.java

Changeset: da14813a
Branch: master
Author:    Emanuel Peter <epeter at openjdk.org>
Date:      2026-01-07 12:37:52 +0000
URL:       https://git.openjdk.org/loom/commit/da14813a5bdadaf0a1f81fa57ff6e1b103eaf113

8373453: C2 SuperWord: must handle load slices that have loads with different memory inputs

Reviewed-by: kvn, thartmann, qamai

! src/hotspot/share/opto/vectorization.cpp
! src/hotspot/share/opto/vectorization.hpp
+ test/hotspot/jtreg/compiler/loopopts/superword/TestLoadSliceWithMultipleMemoryInputStates.java

Changeset: 3541bc86
Branch: master
Author:    Volkan Yazici <vyazici at openjdk.org>
Date:      2026-01-07 15:38:20 +0000
URL:       https://git.openjdk.org/loom/commit/3541bc8635ad8f5f4151758de3a134c9c105cebd

8373538: Migrate all tests to null-safe "SimpleSSLContext" methods

Reviewed-by: djelinski, jpai

! test/jdk/com/sun/net/httpserver/ClearTextServerSSL.java
! test/jdk/java/net/HttpURLConnection/SetAuthenticator/HTTPTest.java
! test/jdk/java/net/HttpURLConnection/SetAuthenticator/HTTPTestClient.java
! test/jdk/java/net/URLPermission/URLTest.java
! test/jdk/javax/net/ssl/HttpsURLConnection/DummyCacheResponse.java
! test/jdk/javax/net/ssl/HttpsURLConnection/Equals.java
! test/jdk/javax/net/ssl/HttpsURLConnection/HttpsSession.java
! test/jdk/javax/net/ssl/HttpsURLConnection/SubjectAltNameIP.java
! test/jdk/sun/net/www/protocol/http/RedirectOnPost.java
! test/jdk/sun/security/krb5/auto/HttpsCB.java
! test/langtools/jdk/javadoc/doclet/testLinkOption/TestRedirectLinks.java
! test/lib/jdk/test/lib/net/SimpleSSLContext.java

Changeset: 640343f7
Branch: master
Author:    Jatin Bhateja <jbhateja at openjdk.org>
Date:      2026-01-07 17:00:57 +0000
URL:       https://git.openjdk.org/loom/commit/640343f7d94894b0378ea5b1768eeac203a9aaf8

8373724: Assertion failure in TestSignumVector.java with UseAPX

Reviewed-by: sviswanathan

! src/hotspot/cpu/x86/x86.ad

Changeset: dd20e915
Branch: master
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2026-01-07 18:10:06 +0000
URL:       https://git.openjdk.org/loom/commit/dd20e9150666f247af61dfa524a170ef7dd96c03

8374521: Support fine-grained native debug levels

Reviewed-by: erikj, krk, clanger

! .github/workflows/build-alpine-linux.yml
! .github/workflows/build-cross-compile.yml
! .github/workflows/build-linux.yml
! .github/workflows/build-macos.yml
! make/autoconf/flags-cflags.m4

Changeset: 383fe1ef
Branch: master
Author:    Erik Joelsson <erikj at openjdk.org>
Date:      2026-01-07 21:52:12 +0000
URL:       https://git.openjdk.org/loom/commit/383fe1efc3a23385b8576e20f458f91085c6325e

8374642: EscapeHash macro fails with GNU make 4.3 and 4.4

Reviewed-by: tbell, shade

! make/common/Utils.gmk

Changeset: 9a944e55
Branch: master
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2026-01-07 22:23:39 +0000
URL:       https://git.openjdk.org/loom/commit/9a944e558733950d135b5a91d093b7a28e934f59

8372754: Add wrapper for <cstdlib>
8369205: AIX build break in forbiddenFunctions.hpp

Reviewed-by: mdoerr, tschatzl

! src/hotspot/cpu/aarch64/immediate_aarch64.cpp
! src/hotspot/cpu/aarch64/immediate_aarch64.hpp
! src/hotspot/os/aix/libodm_aix.cpp
! src/hotspot/os/aix/libperfstat_aix.hpp
! src/hotspot/os/aix/os_perf_aix.cpp
! src/hotspot/os/bsd/memMapPrinter_macosx.cpp
! src/hotspot/os/linux/os_linux.cpp
! src/hotspot/os/linux/os_perf_linux.cpp
! src/hotspot/os/posix/forbiddenFunctions_posix.hpp
! src/hotspot/os/posix/os_posix.cpp
! src/hotspot/os/posix/permitForbiddenFunctions_posix.hpp
! src/hotspot/os/windows/os_windows.cpp
! src/hotspot/os/windows/permitForbiddenFunctions_windows.hpp
! src/hotspot/os/windows/vmError_windows.cpp
! src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp
! src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp
! src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp
! src/hotspot/os_cpu/linux_arm/os_linux_arm.cpp
! src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp
! src/hotspot/os_cpu/linux_riscv/os_linux_riscv.cpp
! src/hotspot/os_cpu/linux_s390/os_linux_s390.cpp
! src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp
! src/hotspot/os_cpu/windows_aarch64/os_windows_aarch64.cpp
! src/hotspot/share/classfile/classLoader.cpp
+ src/hotspot/share/cppstdlib/cstdlib.hpp
! src/hotspot/share/utilities/byteswap.hpp
! src/hotspot/share/utilities/forbiddenFunctions.hpp
! src/hotspot/share/utilities/globalDefinitions_gcc.hpp
! src/hotspot/share/utilities/globalDefinitions_visCPP.hpp
! src/hotspot/share/utilities/parseInteger.hpp
! src/hotspot/share/utilities/permitForbiddenFunctions.hpp
! test/hotspot/gtest/gtestMain.cpp
! test/hotspot/gtest/unittest.hpp
! test/hotspot/gtest/utilities/test_bitMap_setops.cpp

Changeset: 0a1fa219
Branch: master
Author:    Chad Rakoczy <chadrako at amazon.com>
Committer: Leonid Mesnik <lmesnik at openjdk.org>
Date:      2026-01-08 01:14:01 +0000
URL:       https://git.openjdk.org/loom/commit/0a1fa219214b985e4c7d9e612bd5cda1b0f25577

8369150: NMethodRelocationTest fails when JVMTI events not published before JVM exit

Reviewed-by: lmesnik, sspitsyn

! test/hotspot/jtreg/ProblemList.txt
! test/hotspot/jtreg/serviceability/jvmti/NMethodRelocation/NMethodRelocationTest.java
! test/hotspot/jtreg/serviceability/jvmti/NMethodRelocation/libNMethodRelocationTest.cpp
! test/lib/jdk/test/lib/jvmti/jvmti_common.hpp

Changeset: 70669d05
Branch: master
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2026-01-08 04:43:06 +0000
URL:       https://git.openjdk.org/loom/commit/70669d0585c708e04befe0f9ba945f6154f9afec

8374712: AOTMappedHeapWriter::relocate_field_in_buffer should use CompressedOops::narrow_oop_cast

Reviewed-by: kvn

! src/hotspot/share/cds/aotMappedHeapWriter.cpp

Changeset: 95137580
Branch: master
Author:    Ioi Lam <iklam at openjdk.org>
Date:      2026-01-08 05:31:06 +0000
URL:       https://git.openjdk.org/loom/commit/95137580b81fb48474b0d8fb748d9d4af7a27850

8374662: Remove unused type check functions from javaClasses.hpp

Reviewed-by: jsjolen

! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/classfile/javaClasses.hpp

Changeset: e6abf98e
Branch: master
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2026-01-08 07:01:03 +0000
URL:       https://git.openjdk.org/loom/commit/e6abf98e35079ed1b5547f2cc0ac6f518b78d67b

8374434: Several JShell tests report JUnit discovery warnings

Reviewed-by: jpai

! test/langtools/jdk/jshell/ErrorTranslationTest.java
! test/langtools/jdk/jshell/IdGeneratorTest.java
! test/langtools/jdk/jshell/KullaCompletenessStressTest.java

Changeset: 1a6da449
Branch: master
Author:    Per Minborg <pminborg at openjdk.org>
Date:      2026-01-08 08:14:57 +0000
URL:       https://git.openjdk.org/loom/commit/1a6da4499cf8805ff3e1e517fbca81c2eeb987a9

8374467: Incorrect ranges in jdk.internal.util.ByteArray JavaDoc

Reviewed-by: rriggs

! src/java.base/share/classes/jdk/internal/util/ByteArray.java
! src/java.base/share/classes/jdk/internal/util/ByteArrayLittleEndian.java

Changeset: a71326a0
Branch: master
Author:    Emanuel Peter <epeter at openjdk.org>
Date:      2026-01-08 08:32:02 +0000
URL:       https://git.openjdk.org/loom/commit/a71326a0e2660158fdb85282da4b59ce61c66ee3

8374528: C2 SuperWord: TestAliasingFuzzer.java strengthen no-multiversioning IR rule

Reviewed-by: chagedorn, mhaessig

! test/hotspot/jtreg/compiler/loopopts/superword/TestAliasingFuzzer.java

Changeset: 08ff16f0
Branch: master
Author:    Ramkumar Sunderbabu <rsunderbabu at openjdk.org>
Committer: SendaoYan <syan at openjdk.org>
Date:      2026-01-08 09:25:11 +0000
URL:       https://git.openjdk.org/loom/commit/08ff16f0aa8eaa9596da52d568720c69c897f3c5

8374576: Disable MemoryEaterMT for VirtualThread

Reviewed-by: lmesnik, dholmes

! test/hotspot/jtreg/vmTestbase/gc/gctests/MemoryEaterMT/MemoryEaterMT.java

Changeset: 067fd3cb
Branch: master
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2026-01-08 09:32:51 +0000
URL:       https://git.openjdk.org/loom/commit/067fd3cb2fa6a4a0484a922df8efbde03325ad3d

8374768: S390X builds are failing after JDK-8372754

Reviewed-by: stefank, mdoerr

! src/hotspot/os_cpu/linux_s390/os_linux_s390.cpp

Changeset: 904ba5f5
Branch: master
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
Date:      2026-01-08 10:24:03 +0000
URL:       https://git.openjdk.org/loom/commit/904ba5f5ed7d3ac1a3606ff7532ba3c206a2d9b9

8374718: Generation of CompilerProperties can fail in subtle ways

Reviewed-by: jlahoda

! make/langtools/tools/propertiesparser/gen/ClassGenerator.java
! make/langtools/tools/propertiesparser/resources/templates.properties
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java

Changeset: c5159fc9
Branch: master
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2026-01-08 11:07:08 +0000
URL:       https://git.openjdk.org/loom/commit/c5159fc9fa0fd81dec629cd821b3411b4a6df967

8374328: Convert simple AtomicAccess uses in gc/shared to use Atomic<T>

Reviewed-by: dholmes, tschatzl

! src/hotspot/share/gc/shared/barrierSetNMethod.cpp
! src/hotspot/share/gc/shared/concurrentGCThread.cpp
! src/hotspot/share/gc/shared/concurrentGCThread.hpp
! src/hotspot/share/gc/shared/gcLocker.cpp
! src/hotspot/share/gc/shared/gcLocker.hpp
! src/hotspot/share/gc/shared/gcLocker.inline.hpp
! src/hotspot/share/gc/shared/pretouchTask.cpp
! src/hotspot/share/gc/shared/pretouchTask.hpp
! src/hotspot/share/gc/shared/suspendibleThreadSet.cpp
! src/hotspot/share/gc/shared/suspendibleThreadSet.hpp
! src/hotspot/share/gc/shared/workerThread.cpp
! src/hotspot/share/gc/shared/workerThread.hpp

Changeset: 78b1ca6c
Branch: master
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2026-01-08 12:44:08 +0000
URL:       https://git.openjdk.org/loom/commit/78b1ca6cc14e1a92bf25cbcfb687067ac17af92b

8374711: Hotspot runtime/CommandLine/OptionsValidation/TestOptionsWithRanges fails without printing the option name

Reviewed-by: mdoerr, dholmes

! test/hotspot/jtreg/runtime/CommandLine/OptionsValidation/common/optionsvalidation/JVMOption.java

Changeset: ec657349
Branch: master
Author:    Brian Burkhalter <bpb at openjdk.org>
Date:      2026-01-08 16:28:10 +0000
URL:       https://git.openjdk.org/loom/commit/ec657349ff654dcb41b9f17178aeea638329101e

8374641: Remove java/nio/channels/AsyncCloseAndInterrupt.java from problem list

Reviewed-by: iris

! test/jdk/ProblemList.txt

Changeset: 677572b4
Branch: master
Author:    Brian Burkhalter <bpb at openjdk.org>
Date:      2026-01-08 16:28:43 +0000
URL:       https://git.openjdk.org/loom/commit/677572b42d6d0ee62063c3f19ffad1e501ac9bf3

8372377: Test java/io/File/GetXSpace.java failed: The system cannot find the path specified

Reviewed-by: alanb, jpai

! test/jdk/java/io/File/GetXSpace.java
! test/jdk/java/io/File/libGetXSpace.c

Changeset: fa2eb626
Branch: master
Author:    Erik Gahlin <egahlin at openjdk.org>
Date:      2026-01-08 16:34:39 +0000
URL:       https://git.openjdk.org/loom/commit/fa2eb626478806dc64fe03d8729f53f7ed26a172

8367949: JFR: MethodTrace double-counts methods that catch their own exceptions

Reviewed-by: mgronlun

! src/jdk.jfr/share/classes/jdk/jfr/internal/tracing/Instrumentation.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/tracing/Method.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/tracing/Transform.java
+ test/jdk/jdk/jfr/event/tracing/TestConstructors.java
! test/jdk/jdk/jfr/event/tracing/TestInstrumentation.java

Changeset: c834e4c6
Branch: master
Author:    Jonas Norlinder <jnorlinder at openjdk.org>
Committer: Claes Redestad <redestad at openjdk.org>
Date:      2026-01-08 16:46:28 +0000
URL:       https://git.openjdk.org/loom/commit/c834e4c641bf6c73e88b93c0cdba40a83f3192c1

8373647: Avoid fstat when opening file for write with RandomAccessFile or FileOutputStream

Reviewed-by: redestad, alanb

! src/java.base/unix/native/libjava/io_util_md.c
! test/micro/org/openjdk/bench/java/io/FileWrite.java

Changeset: 7e1051bf
Branch: master
Author:    Francisco Ferrari Bihurriet <fferrari at openjdk.org>
Date:      2026-01-08 16:46:48 +0000
URL:       https://git.openjdk.org/loom/commit/7e1051bfcc01aad538376c86354e16e25d2eaf7a

8352728: InternalError loading java.security due to Windows parent folder permissions

Reviewed-by: weijun, mullan

! src/java.base/share/classes/java/security/Security.java
- test/jdk/java/security/Security/ConfigFileTest.java
+ test/jdk/java/security/Security/SecurityPropFile/ExtraFileAndIncludes.java
+ test/jdk/java/security/Security/SecurityPropFile/LinuxAnonymousFiles.java
- test/jdk/java/security/Security/SecurityPropFile/SecurityPropFile.file
- test/jdk/java/security/Security/SecurityPropFile/SecurityPropFile.java
+ test/jdk/java/security/Security/SecurityPropFile/WindowsParentDirPermissions.java

Changeset: afd216ec
Branch: master
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2026-01-08 17:19:12 +0000
URL:       https://git.openjdk.org/loom/commit/afd216ec3f5bfd1be88c6f4d4f53b763205c4fee

8374752: Add more JLS links to javax.lang.model.element.*

Reviewed-by: liach

! src/java.compiler/share/classes/javax/lang/model/element/ExecutableElement.java
! src/java.compiler/share/classes/javax/lang/model/element/PackageElement.java
! src/java.compiler/share/classes/javax/lang/model/element/Parameterizable.java
! src/java.compiler/share/classes/javax/lang/model/element/QualifiedNameable.java
! src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java
! src/java.compiler/share/classes/javax/lang/model/element/TypeParameterElement.java
! src/java.compiler/share/classes/javax/lang/model/element/VariableElement.java

Changeset: 92abc6df
Branch: master
Author:    Mark Powers <mpowers at openjdk.org>
Date:      2026-01-08 17:35:43 +0000
URL:       https://git.openjdk.org/loom/commit/92abc6dfe43a2c1f10dcfcf1e197fc9369f70ee3

8369282: Distrust TLS server certificates anchored by Chunghwa ePKI Root CA

Reviewed-by: mullan

! src/java.base/share/classes/sun/security/validator/CADistrustPolicy.java
+ src/java.base/share/classes/sun/security/validator/ChunghwaTLSPolicy.java
! src/java.base/share/conf/security/java.security
+ test/jdk/sun/security/ssl/X509TrustManagerImpl/distrust/Chunghwa.java
+ test/jdk/sun/security/ssl/X509TrustManagerImpl/distrust/chains/chunghwa/chunghwaepkirootca-chain.pem

Changeset: 1fb5030a
Branch: master
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2026-01-08 17:58:35 +0000
URL:       https://git.openjdk.org/loom/commit/1fb5030ab351a52b4a7455cbdd57f5b50aab9bd5

8374767: Amend JDK-8374521 with new option name

Reviewed-by: clanger, krk

! .github/workflows/build-alpine-linux.yml
! .github/workflows/build-cross-compile.yml
! .github/workflows/build-linux.yml
! .github/workflows/build-macos.yml
! make/autoconf/flags-cflags.m4

Changeset: 9fd86e37
Branch: master
Author:    Ioi Lam <iklam at openjdk.org>
Date:      2026-01-08 18:42:20 +0000
URL:       https://git.openjdk.org/loom/commit/9fd86e37492c419fbae0837f69aab26a201c927e

8374639: Static archive with AOTClassLinking breaks dynamic archive

Reviewed-by: coleenp, matsaave

! src/hotspot/share/cds/aotConstantPoolResolver.cpp
! src/hotspot/share/cds/aotMetaspace.cpp
! src/hotspot/share/cds/archiveBuilder.cpp
! src/hotspot/share/cds/dynamicArchive.cpp
! src/hotspot/share/cds/dynamicArchive.hpp
+ test/hotspot/jtreg/runtime/cds/appcds/aotClassLinking/DynamicDumpWithAOTLinkedStaticArchive.java
- test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/ArrayKlasses.java
- test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/test-classes/ArrayKlassesApp.java
! test/lib/jdk/test/lib/cds/CDSAppTester.java
! test/lib/jdk/test/lib/cds/SimpleCDSAppTester.java

Changeset: 8212993a
Branch: master
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2026-01-08 18:51:25 +0000
URL:       https://git.openjdk.org/loom/commit/8212993ac331d8761ddb7c0eef23dbfcc6ca0c7d

8374540: Add comment describing implementation choices of Math.fma

Reviewed-by: rgiulietti

! src/java.base/share/classes/java/lang/Math.java

Changeset: 1342db0b
Branch: master
Author:    Justin Lu <jlu at openjdk.org>
Date:      2026-01-08 19:02:06 +0000
URL:       https://git.openjdk.org/loom/commit/1342db0bde25c111b25f4339ae2a858dc3b15687

8374051: Incorrect parameterized testing of exceptions in AbstractDateTimeTest.java

Reviewed-by: naoto, rriggs

! test/jdk/java/time/tck/java/time/AbstractDateTimeTest.java
! test/jdk/java/time/tck/java/time/TCKInstant.java
! test/jdk/java/time/tck/java/time/TCKLocalDate.java
! test/jdk/java/time/tck/java/time/TCKLocalTime.java
! test/jdk/java/time/tck/java/time/TCKMonthDay.java
! test/jdk/java/time/tck/java/time/TCKOffsetDateTime.java
! test/jdk/java/time/tck/java/time/TCKOffsetTime.java
! test/jdk/java/time/tck/java/time/TCKYearMonth.java
! test/jdk/java/time/tck/java/time/TCKZonedDateTime.java

Changeset: 982aa3f8
Branch: master
Author:    Phil Race <prr at openjdk.org>
Date:      2026-01-08 19:47:01 +0000
URL:       https://git.openjdk.org/loom/commit/982aa3f8ead84817be5373c3257d48feab1758d3

8336654: [lworld] Tests depending on sun.awt.AppContext can fail when run with migrated classes

Reviewed-by: serb, azvegint

! src/java.desktop/macosx/classes/com/apple/laf/AquaUtils.java
! src/java.desktop/share/classes/sun/awt/AppContext.java
! src/java.desktop/share/classes/sun/awt/image/ImageCache.java
- test/jdk/javax/swing/Security/6657138/bug6657138.java

Changeset: 385c4f81
Branch: master
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
Date:      2026-01-08 20:46:38 +0000
URL:       https://git.openjdk.org/loom/commit/385c4f8180d30c0e41b848eb4b2c1c8788211422

8373714: Shenandoah: Register heuristic penalties following a degenerated GC

Reviewed-by: wkemper

! src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.cpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.hpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.hpp
! src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.cpp

Changeset: 368de9ff
Branch: master
Author:    SendaoYan <syan at openjdk.org>
Date:      2026-01-09 02:09:37 +0000
URL:       https://git.openjdk.org/loom/commit/368de9ff2e46e4c66ee57b5fb961804c5d25c42a

8374721: containers/docker/ShareTmpDir.java timed out after 8362087

Reviewed-by: cnorrbin, sgehwolf

! test/hotspot/jtreg/containers/docker/ShareTmpDir.java

Changeset: 9932c78c
Branch: master
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2026-01-09 02:27:16 +0000
URL:       https://git.openjdk.org/loom/commit/9932c78c238f9b7959e28a056c37a88a7f6ce958

8374749: Clarify AnnotationValue specification

Reviewed-by: liach, iris

! src/java.compiler/share/classes/javax/lang/model/element/AnnotationMirror.java
! src/java.compiler/share/classes/javax/lang/model/element/AnnotationValue.java

Changeset: 775f48de
Branch: master
Author:    Jasmine Karthikeyan <jkarthikeyan at openjdk.org>
Date:      2026-01-09 05:16:32 +0000
URL:       https://git.openjdk.org/loom/commit/775f48de6129092d05650fec17dad171944e6d89

8365570: C2 fails assert(false) failed: Unexpected node in SuperWord truncation: CastII

Reviewed-by: chagedorn, thartmann, epeter

! src/hotspot/share/opto/superword.cpp
! test/hotspot/jtreg/compiler/vectorization/TestSubwordTruncation.java

Changeset: a4fb07ee
Branch: master
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2026-01-09 06:26:16 +0000
URL:       https://git.openjdk.org/loom/commit/a4fb07ee3e26c2f0ed3111c39c3a22167d292d04

8374644: Regression in GZIPInputStream performance after JDK-7036144

Reviewed-by: lancea, alanb

! src/java.base/share/classes/java/util/zip/GZIPInputStream.java

Changeset: 42313289
Branch: master
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2026-01-09 07:16:58 +0000
URL:       https://git.openjdk.org/loom/commit/423132895d4ee787d13daa412f9a3f9438834117

8374698: Stub names should look more like identifiers

Reviewed-by: adinn, kvn

! src/hotspot/share/opto/callnode.cpp
! src/hotspot/share/opto/callnode.hpp
! src/hotspot/share/opto/escape.cpp
! src/hotspot/share/runtime/stubDeclarations.hpp
! src/hotspot/share/runtime/stubInfo.cpp

Changeset: a8552243
Branch: master
Author:    Jonas Norlinder <jnorlinder at openjdk.org>
Committer: Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-09 08:41:39 +0000
URL:       https://git.openjdk.org/loom/commit/a855224305e025aea80165ae63ee921dca299b9c

8373695: G1: Using a value near integer max for ActiveProcessorCount causes fatal crash

Reviewed-by: stefank, tschatzl

! src/hotspot/share/gc/g1/g1Arguments.cpp

Changeset: 2a965dff
Branch: master
Author:    Jeremy Wood <jwood at openjdk.org>
Committer: Jayathirth D V <jdv at openjdk.org>
Date:      2026-01-09 09:56:39 +0000
URL:       https://git.openjdk.org/loom/commit/2a965dffdd2791ab87a2dbfba8ed44f8adb996c7

8374377: PNGImageDecoder Slow For 8-bit PNGs

Reviewed-by: jdv, prr

! src/java.desktop/share/classes/sun/awt/image/PNGImageDecoder.java
+ test/jdk/sun/awt/image/png/PngImageDecoder8BitTest.java
+ test/micro/org/openjdk/bench/java/awt/image/PNGImageDecoder_8bit_uninterlaced.java

Changeset: c8c6e700
Branch: master
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2026-01-09 10:23:03 +0000
URL:       https://git.openjdk.org/loom/commit/c8c6e7007aec9a568c25dcd5d4242b7911a83bfe

8374825: vmTestbase comment typo: lunch

Reviewed-by: tschatzl, shade

! test/hotspot/jtreg/vmTestbase/nsk/share/gc/Algorithms.java
! test/hotspot/jtreg/vmTestbase/nsk/share/gc/gp/GarbageUtils.java

Changeset: 47e19353
Branch: master
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2026-01-09 12:24:13 +0000
URL:       https://git.openjdk.org/loom/commit/47e19353cd3661ad9aed00f6a415818da45cdfef

8373941: Epsilon: Robust counter updates in early VM phases

Reviewed-by: stefank, tschatzl

! src/hotspot/share/gc/epsilon/epsilonHeap.cpp
! src/hotspot/share/gc/epsilon/epsilonHeap.hpp
! src/hotspot/share/gc/epsilon/epsilonMonitoringSupport.cpp
! src/hotspot/share/gc/epsilon/epsilonMonitoringSupport.hpp
+ test/hotspot/jtreg/gc/epsilon/TestInitAllocs.java

Changeset: 6d1bfdf7
Branch: master
Author:    Coleen Phillimore <coleenp at openjdk.org>
Date:      2026-01-09 13:14:25 +0000
URL:       https://git.openjdk.org/loom/commit/6d1bfdf7a92e44ff855307f86d1734fad909ea3d

8374796: CompressedOops versions of runtime/cds/TestDefaultArchiveLoading.java aren't run

Reviewed-by: stefank, shade

! test/hotspot/jtreg/runtime/cds/TestDefaultArchiveLoading.java

Changeset: 8737a8ca
Branch: master
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
Date:      2026-01-09 14:49:52 +0000
URL:       https://git.openjdk.org/loom/commit/8737a8ca73952d60129e7fc2f7e17eea3b800af7

8373448: jpackage: StackOverflowError when processing a very long argument

Reviewed-by: almatvee

! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardOption.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/StandardOptionTest.java

Changeset: f5fa9e40
Branch: master
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2026-01-09 16:49:04 +0000
URL:       https://git.openjdk.org/loom/commit/f5fa9e40b09b7b6322edb5f057a6350d44980e14

8374745: Test vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters004/TestDescription.java failed

Reviewed-by: lmesnik, sspitsyn

! test/hotspot/jtreg/vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters001/CollectionCounters001.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters002/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters003/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters004/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/GarbageCollectorMXBean/CollectionCounters/CollectionCounters005/TestDescription.java

Changeset: 663a0833
Branch: master
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
Date:      2026-01-09 22:20:05 +0000
URL:       https://git.openjdk.org/loom/commit/663a08331a83c852622b8b11900f12b0dc3dbe82

8374219: Fix issues in jpackage's Executor class

Reviewed-by: almatvee

! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/DesktopIntegration.java
! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LibProvidersLookup.java
! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxBundlingEnvironment.java
! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxDebPackager.java
! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxDebSystemEnvironment.java
! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxDebSystemEnvironmentMixin.java
! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxFromOptions.java
! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxLaunchersAsServices.java
! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxPackageArch.java
! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxPackageBuilder.java
! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxRpmSystemEnvironment.java
! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxRpmSystemEnvironmentMixin.java
! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxSystemEnvironment.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/AppImageSigner.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/Codesign.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacBundlingEnvironment.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacCertificateUtils.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacDmgPackager.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacDmgSystemEnvironment.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacPkgPackager.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/TempKeychain.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/DefaultBundlingEnvironment.java
- src/jdk.jpackage/share/classes/jdk/jpackage/internal/Enquoter.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/Executor.java
+ src/jdk.jpackage/share/classes/jdk/jpackage/internal/ExecutorFactory.java
+ src/jdk.jpackage/share/classes/jdk/jpackage/internal/Globals.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/IOUtils.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/JLinkRuntimeBuilder.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/Log.java
+ src/jdk.jpackage/share/classes/jdk/jpackage/internal/ObjectFactory.java
- src/jdk.jpackage/share/classes/jdk/jpackage/internal/RetryExecutor.java
+ src/jdk.jpackage/share/classes/jdk/jpackage/internal/RetryExecutorFactory.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/SystemEnvironment.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/ToolValidator.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/Main.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources.properties
+ src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/CommandLineFormat.java
+ src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/CommandOutputControl.java
+ src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/Enquoter.java
+ src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/RetryExecutor.java
+ src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/TeeOutputStream.java
! src/jdk.jpackage/unix/classes/jdk/jpackage/internal/UnixLaunchersAsServices.java
! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinBundlingEnvironment.java
! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixTool.java
- test/jdk/tools/jpackage/helpers-test/jdk/jpackage/test/ExecutorTest.java
! test/jdk/tools/jpackage/helpers-test/jdk/jpackage/test/PackageTestTest.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/Executor.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/LinuxHelper.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacHelper.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacSign.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacSignVerify.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/WindowsHelper.java
+ test/jdk/tools/jpackage/helpers/jdk/jpackage/test/mock/CommandAction.java
+ test/jdk/tools/jpackage/helpers/jdk/jpackage/test/mock/CommandActionSpec.java
+ test/jdk/tools/jpackage/helpers/jdk/jpackage/test/mock/CommandActionSpecs.java
+ test/jdk/tools/jpackage/helpers/jdk/jpackage/test/mock/CommandMock.java
+ test/jdk/tools/jpackage/helpers/jdk/jpackage/test/mock/CommandMockExit.java
+ test/jdk/tools/jpackage/helpers/jdk/jpackage/test/mock/CommandMockSpec.java
+ test/jdk/tools/jpackage/helpers/jdk/jpackage/test/mock/CompletableCommandMock.java
+ test/jdk/tools/jpackage/helpers/jdk/jpackage/test/mock/MockIOException.java
+ test/jdk/tools/jpackage/helpers/jdk/jpackage/test/mock/MockIllegalStateException.java
+ test/jdk/tools/jpackage/helpers/jdk/jpackage/test/mock/MockingToolProvider.java
+ test/jdk/tools/jpackage/helpers/jdk/jpackage/test/mock/Script.java
+ test/jdk/tools/jpackage/helpers/jdk/jpackage/test/mock/ScriptSpec.java
+ test/jdk/tools/jpackage/helpers/jdk/jpackage/test/mock/ScriptSpecInDir.java
+ test/jdk/tools/jpackage/helpers/jdk/jpackage/test/mock/ToolProviderCommandMock.java
+ test/jdk/tools/jpackage/helpers/jdk/jpackage/test/mock/ToolProviderCompletableCommandMock.java
+ test/jdk/tools/jpackage/helpers/jdk/jpackage/test/mock/VerbatimCommandMock.java
+ test/jdk/tools/jpackage/junit/linux/jdk.jpackage/jdk/jpackage/internal/LibProvidersLookupTest.java
+ test/jdk/tools/jpackage/junit/linux/jdk.jpackage/jdk/jpackage/internal/LinuxPackageArchTest.java
+ test/jdk/tools/jpackage/junit/linux/jdk.jpackage/jdk/jpackage/internal/LinuxSystemEnvironmentTest.java
! test/jdk/tools/jpackage/junit/linux/junit.java
+ test/jdk/tools/jpackage/junit/macosx/jdk.jpackage/jdk/jpackage/internal/MacDmgPackagerTest.java
+ test/jdk/tools/jpackage/junit/macosx/jdk.jpackage/jdk/jpackage/internal/MacDmgSystemEnvironmentTest.java
! test/jdk/tools/jpackage/junit/macosx/junit.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/DefaultBundlingEnvironmentTest.java
- test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/EnquoterTest.java
+ test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/ExecutorTest.java
+ test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/MockUtils.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/OptionsValidationFailTest.excludes
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/OptionsValidationFailTest.java
+ test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/util/CommandOutputControlTest.java
+ test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/util/CommandOutputControlTestUtils.java
+ test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/util/EnquoterTest.java
+ test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/util/RetryExecutorTest.java
! test/jdk/tools/jpackage/share/ErrorTest.java
! test/jdk/tools/jpackage/share/PostImageScriptTest.java

Changeset: 805866bb
Branch: master
Author:    jonghoonpark <dev at jonghoonpark.com>
Committer: Kim Barrett <kbarrett at openjdk.org>
Date:      2026-01-09 22:42:53 +0000
URL:       https://git.openjdk.org/loom/commit/805866bbf680f44219e5c634eb9726e1c5dea690

8372040: Remove Prefetch header vs inline header separation

Reviewed-by: kbarrett, stefank

! src/hotspot/os_cpu/aix_ppc/prefetch_aix_ppc.inline.hpp
! src/hotspot/os_cpu/bsd_aarch64/prefetch_bsd_aarch64.inline.hpp
! src/hotspot/os_cpu/bsd_x86/prefetch_bsd_x86.inline.hpp
! src/hotspot/os_cpu/bsd_zero/prefetch_bsd_zero.inline.hpp
! src/hotspot/os_cpu/linux_aarch64/prefetch_linux_aarch64.inline.hpp
! src/hotspot/os_cpu/linux_arm/prefetch_linux_arm.inline.hpp
! src/hotspot/os_cpu/linux_ppc/prefetch_linux_ppc.inline.hpp
! src/hotspot/os_cpu/linux_riscv/prefetch_linux_riscv.inline.hpp
! src/hotspot/os_cpu/linux_s390/prefetch_linux_s390.inline.hpp
! src/hotspot/os_cpu/linux_x86/prefetch_linux_x86.inline.hpp
! src/hotspot/os_cpu/linux_zero/prefetch_linux_zero.inline.hpp
! src/hotspot/os_cpu/windows_aarch64/prefetch_windows_aarch64.inline.hpp
! src/hotspot/os_cpu/windows_x86/prefetch_windows_x86.inline.hpp
! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp
! src/hotspot/share/gc/serial/cardTableRS.cpp
! src/hotspot/share/gc/serial/generation.hpp
- src/hotspot/share/runtime/prefetch.hpp
! src/hotspot/share/runtime/prefetch.inline.hpp

Changeset: 74faf033
Branch: master
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
Date:      2026-01-09 23:36:19 +0000
URL:       https://git.openjdk.org/loom/commit/74faf033127ab3a5e28be75b91e662c589f81084

8374819: jpackage and jpackage tests leave some I/O streams unclosed

Reviewed-by: almatvee

! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/AppImageInfoPListFile.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageFile.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/PListReader.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/AppImageFile.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/LauncherVerifier.java
! test/jdk/tools/jpackage/macosx/HostArchPkgTest.java
! test/jdk/tools/jpackage/windows/WinLongVersionTest.java

Changeset: a726e834
Branch: master
Author:    John Jiang <jjiang at openjdk.org>
Date:      2026-01-10 00:52:34 +0000
URL:       https://git.openjdk.org/loom/commit/a726e834b6d3674f0d573d8a0df6eb00464b825b

8373231: ECDSAOperations::toAffinePoint is redundant

Reviewed-by: mullan

! src/java.base/share/classes/sun/security/ec/ECDSAOperations.java
! test/jdk/sun/security/ec/ECDSAPrimitive.java

Changeset: 0537a3fa
Branch: master
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2026-01-10 01:55:00 +0000
URL:       https://git.openjdk.org/loom/commit/0537a3fae9bd55ab8b7279da7d3ee4b5ce5bc492

8374922: Build failure after JDK-8372040

Reviewed-by: smarks

! src/hotspot/share/gc/serial/serialHeap.cpp

Changeset: 657d5f77
Branch: master
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2026-01-10 02:17:37 +0000
URL:       https://git.openjdk.org/loom/commit/657d5f77f4985304995ee44fc2ae1643504de8df

8374754: jtreg failure handler - replace inline javascript and inline event handlers with same origin javascript files

Reviewed-by: erikj

! test/failure_handler/src/share/classes/jdk/test/failurehandler/HtmlPage.java
! test/failure_handler/src/share/classes/jdk/test/failurehandler/HtmlSection.java
! test/failure_handler/src/share/classes/jdk/test/failurehandler/jtreg/GatherDiagnosticInfoObserver.java
! test/failure_handler/src/share/classes/jdk/test/failurehandler/jtreg/GatherProcessInfoTimeoutHandler.java

Changeset: 12894a87
Branch: master
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
Date:      2026-01-10 11:10:06 +0000
URL:       https://git.openjdk.org/loom/commit/12894a870a3c8d1da13a885cc006458ae9475b6e

8373643: Test serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java still failing

Reviewed-by: lmesnik

! test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadListStackTracesTest/ThreadListStackTracesTest.java

Changeset: 659b53fe
Branch: master
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
Date:      2026-01-10 15:04:16 +0000
URL:       https://git.openjdk.org/loom/commit/659b53fe33eaa531bca1951a26f357b51902311e

8374923: runtime/cds/ServiceLoaderTest.java fails with mismatch between cds and non-cds

Reviewed-by: almatvee

! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/Main.java


From viktor.klang at oracle.com  Sun Jan 11 16:30:18 2026
From: viktor.klang at oracle.com (Viktor Klang)
Date: Sun, 11 Jan 2026 17:30:18 +0100
Subject: [External] : Re: Ephemeral threads
In-Reply-To: <7286AE3F-6E40-4318-B6D1-A363B9C746E7@gmail.com>
References: <CAOdgdgzQU4z+8RA2WMuD=nGUtXAdx1D0P8BW3CMQcGcQDcTSYw@mail.gmail.com>
 <518ce8ef-4fa7-4166-a6fd-d2d699e51ba2@oracle.com>
 <f9f15ec0-28cf-40fe-aea8-5ecc89c16d9f@oracle.com>
 <6E8BCF39-B438-4C4A-A892-8C933FB86F92@gmail.com>
 <01c37422-171d-49b0-a216-15bb8aaaf172@oracle.com>
 <5A5AEC77-43CC-4D2D-87E1-3EC6F8D066AF@gmail.com>
 <1ef40f81-0e75-4752-989b-11cd4e5601a7@oracle.com>
 <7286AE3F-6E40-4318-B6D1-A363B9C746E7@gmail.com>
Message-ID: <ad6c6c2e-5c4d-43bd-9963-654dd2e497ba@oracle.com>

 >Meaning park() doesn?t have to return?. Exception could be thrown and 
release never called?.

park() 
<https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/concurrent/locks/LockSupport.html#park()> 
isn't documented to throw any exception, and even if it were to throw an 
exception, it would unwind the stack and end up in some 
UncaughtExceptionHandler.

 >Resources must be used with try blocks (or some logically similar 
construct)

I deliberately omitted the try-finally to be able to say this: 
try-finally wouldn't help here if the VT is GCed when parked.

On 2026-01-11 05:17, Dmitry Zaslavsky wrote:
> Your code would be broken in our case, but it?s broken in ?plain? java 
> case as well.
> Meaning park() doesn?t have to return?. Exception could be thrown and 
> release never called?.
>
> Resources must be used with try blocks (or some logically similar 
> construct)
> That?s what we are trying to ?manage? by having a library construct.
> That library construct ensures (optionally) that finally (clean up) 
> called up in any case.
>
> The other option I would want to consider is allowing try/finally and 
> throwing an interrupt exception.
> I haven?t played with this. Ideally JVM support that lets me know if 
> there is a finally block on stack would be nice.
> But I know it?s too much to ask.
>
>
>
>> On Jan 10, 2026, at 7:02?PM, Viktor Klang <viktor.klang at oracle.com> 
>> wrote:
>>
>> Hi Dmitry,
>>
>> An example can look like:
>>
>> void method() {
>> ? ? long fileDescriptor = acquireFileDescriptor();
>> ? ? LockSupport.park();
>> ? ? releaseFileDescriptor(fileDescriptor);
>> }
>>
>> If an ephemeral VT executes that method, and there are no other 
>> references to that ephemeral VT, then at the point of park(), nothing 
>> can unpark it anymore, and it will then never release the file 
>> descriptor.
>>
>>
>> >We generally don?t allow try blocks (providing other constructs), we 
>> also very strongly discourage (just a drop short of disallowing) ANY 
>> threading primitives.
>>
>>
>> I don't see how that can work in practice, because it requires all 
>> users of your constructs to be familiar about exactly how all 
>> third-party logic (including JDK classes) are implemented under the 
>> hood. Perhaps I'm misunderstanding?
>>
>> On 2026-01-09 17:27, Dmitry Zaslavsky wrote:
>>> Not sure what you mean by native resources?
>>> Do you mean what people would use like try resources?
>>> We generally don?t allow try blocks (providing other constructs), we also very strongly discourage (just a drop short of disallowing) ANY threading primitives.
>>>
>>> Which makes me think that there is a better way to express my point from before.
>>> I think there is actually a common pattern here.
>>>
>>> We use VT inside of the lib. We don?t want users to actually use any threads all.
>>> I think it?s a goal of Alex as well.
>>> We use VT as  a way to avoid using threads (if that makes sense).
>>>
>>> I think ScopedTasks is going in the same direction. Ideally user just doesn?t know there are threads.
>>> We use Scala (appealing to Victor ;)) vals and immutable collections is the norm.
>>>
>>> We don?t want users to think about Threads period.
>>> So the thought of "GC roots on a VT ? we don?t want that though to ever occur or we failed ;)
>>>
>>>
>>>
>>>   
>>>
>>>> On Jan 9, 2026, at 10:26?AM, Viktor Klang<viktor.klang at oracle.com> wrote:
>>>>
>>>>
>>>> On 2026-01-09 15:39, Dmitry Zaslavsky wrote:
>>>>> someCollection.apar.map { ?. }
>>>>> Can spin N tasks (Each can get it's VT) If some iteration of the loop throws, we don?t need to rest of the code to run, it?s costly.
>>>>> If the task are not actively mounted but previously started and are waiting? (in our case it?s LockSupport.park) we just want to drop that entire queue and everything around it?.
>>>>>
>>>>>
>>>> How do you handle acquired native resources that are yet to be released?
>>>>
>>>>
>>>> -- 
>>>> Cheers,
>>>> ?
>>>>
>>>>
>>>> Viktor Klang
>>>> Software Architect, Java Platform Group
>>>> Oracle
>>>>
>> -- 
>> Cheers,
>> ?
>>
>>
>> Viktor Klang
>> Software Architect, Java Platform Group
>> Oracle
>
-- 
Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260111/191ff255/attachment.htm>

From viktor.klang at oracle.com  Sun Jan 11 16:30:24 2026
From: viktor.klang at oracle.com (Viktor Klang)
Date: Sun, 11 Jan 2026 17:30:24 +0100
Subject: [External] : Re: Ephemeral threads
In-Reply-To: <1604DAB4-FCCA-4362-BAB9-22237B88AFF4@me.com>
References: <1ef40f81-0e75-4752-989b-11cd4e5601a7@oracle.com>
 <1604DAB4-FCCA-4362-BAB9-22237B88AFF4@me.com>
Message-ID: <a96c0530-5430-4c5b-8a61-8182a2ff934c@oracle.com>

 >This code is fundamentally broken. Park() can wake up for any reason.

I don't see how "When park wakes up" (i.e. the temporal aspect) affects 
correctness in any way in the example given.

 >I suggest you look at ClosableQueue - it is correct and far easier to 
use.

The example is completely devoid of any queuing concerns. We're talking 
about logic which is executed by some thread, and the person who writes 
the code does not strictly know whether that thread is a platform 
thread, a pooled platform thread, a virtual thread, an ephemeral virtual 
thread, a GC finalizer thread.

In short, this is about: pre-existing code which may get executed by an 
ephemeral virtual thread may /silently/ leak resources under certain 
circumstances. Now, it can be argued that most of that code was "not 
ideal" in the first place, but the big difference is that when any such 
defect gets noticed in a running application, there's a much better 
visibility if the thread which ran into the problem is still there 
(evidence) vs not (no evidence).

On 2026-01-11 01:50, Robert Engels wrote:
> This code is fundamentally broken. Park() can wake up for any reason.
>
> I suggest you look at ClosableQueue - it is correct and far easier to 
> use.
>
>> On Jan 10, 2026, at 6:03?PM, Viktor Klang <viktor.klang at oracle.com> 
>> wrote:
>>
>> ?
>>
>> Hi Dmitry,
>>
>> An example can look like:
>>
>> void method() {
>> ? ? long fileDescriptor = acquireFileDescriptor();
>> ? ? LockSupport.park();
>> ? ? releaseFileDescriptor(fileDescriptor);
>> }
>>
>> If an ephemeral VT executes that method, and there are no other 
>> references to that ephemeral VT, then at the point of park(), nothing 
>> can unpark it anymore, and it will then never release the file 
>> descriptor.
>>
>>
>> >We generally don?t allow try blocks (providing other constructs), we 
>> also very strongly discourage (just a drop short of disallowing) ANY 
>> threading primitives.
>>
>>
>> I don't see how that can work in practice, because it requires all 
>> users of your constructs to be familiar about exactly how all 
>> third-party logic (including JDK classes) are implemented under the 
>> hood. Perhaps I'm misunderstanding?
>>
>> On 2026-01-09 17:27, Dmitry Zaslavsky wrote:
>>> Not sure what you mean by native resources?
>>> Do you mean what people would use like try resources?
>>> We generally don?t allow try blocks (providing other constructs), we also very strongly discourage (just a drop short of disallowing) ANY threading primitives.
>>>
>>> Which makes me think that there is a better way to express my point from before.
>>> I think there is actually a common pattern here.
>>>
>>> We use VT inside of the lib. We don?t want users to actually use any threads all.
>>> I think it?s a goal of Alex as well.
>>> We use VT as  a way to avoid using threads (if that makes sense).
>>>
>>> I think ScopedTasks is going in the same direction. Ideally user just doesn?t know there are threads.
>>> We use Scala (appealing to Victor ;)) vals and immutable collections is the norm.
>>>
>>> We don?t want users to think about Threads period.
>>> So the thought of "GC roots on a VT ? we don?t want that though to ever occur or we failed ;)
>>>
>>>
>>>
>>>   
>>>
>>>> On Jan 9, 2026, at 10:26?AM, Viktor Klang<viktor.klang at oracle.com> wrote:
>>>>
>>>>
>>>> On 2026-01-09 15:39, Dmitry Zaslavsky wrote:
>>>>> someCollection.apar.map { ?. }
>>>>> Can spin N tasks (Each can get it's VT) If some iteration of the loop throws, we don?t need to rest of the code to run, it?s costly.
>>>>> If the task are not actively mounted but previously started and are waiting? (in our case it?s LockSupport.park) we just want to drop that entire queue and everything around it?.
>>>>>
>>>>>
>>>> How do you handle acquired native resources that are yet to be released?
>>>>
>>>>
>>>> -- 
>>>> Cheers,
>>>> ?
>>>>
>>>>
>>>> Viktor Klang
>>>> Software Architect, Java Platform Group
>>>> Oracle
>>>>
>> -- 
>> Cheers,
>> ?
>>
>>
>> Viktor Klang
>> Software Architect, Java Platform Group
>> Oracle

-- 
Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260111/7b058a6a/attachment-0001.htm>

From viktor.klang at oracle.com  Sun Jan 11 16:34:38 2026
From: viktor.klang at oracle.com (Viktor Klang)
Date: Sun, 11 Jan 2026 17:34:38 +0100
Subject: Ephemeral threads
In-Reply-To: <CA+heAJBefH-AU3Yp6AzD7kZMakvLAy_dS-w2jRfDTK5miQDwmQ@mail.gmail.com>
References: <CAOdgdgzQU4z+8RA2WMuD=nGUtXAdx1D0P8BW3CMQcGcQDcTSYw@mail.gmail.com>
 <518ce8ef-4fa7-4166-a6fd-d2d699e51ba2@oracle.com>
 <f9f15ec0-28cf-40fe-aea8-5ecc89c16d9f@oracle.com>
 <bf0a7ae7-ca5e-48d3-a3bb-e8177fcb95ba@redhat.com>
 <637c717c-eede-4697-aa97-70db7b3e981f@oracle.com>
 <641baf6f-1a6c-423c-8d3c-526c3adbe731@redhat.com>
 <84805f86-fa9d-4821-8957-52cab1d35c85@oracle.com>
 <CA+heAJBefH-AU3Yp6AzD7kZMakvLAy_dS-w2jRfDTK5miQDwmQ@mail.gmail.com>
Message-ID: <1d774f83-6993-474c-9b06-526ac3582325@oracle.com>

We've explored this in the past. Unfortunately it doesn't help, as it 
can observably change the behavior exhibited by code executed by such a 
thread.

On 2026-01-11 12:12, Michal Domagala wrote:
> Maybe a good idea would be `Thread.ofEphemeral()` ? Effort on JVM side 
> is minimal , because each non-tracked VT is ephemeral, everyone who 
> want experiment with ephemeral has an option, no one will comply about 
> semaphores, summoned demons, etc. because who consents cannot be injured
>
> sob., 10 sty 2026 o 18:18?Alan Bateman <alan.bateman at oracle.com> 
> napisa?(a):
>
>     On 10/01/2026 16:00, Andrew Haley wrote:
>     >
>     You can summon other demons
>     when the threads act on objects with cleaners (or more generally,
>     anything with cleanup actions based on phantom refs). This can
>     lead to
>     cleaning actions that attempt to release resources in an inconsistent
>     state. Even if we spent a few years on the issues, the usage (to
>     allow
>     the alive threads be GC'ed) is very fragile to setup, and the
>     resulting
>     behavior would surely be surprising to most developers
>
-- 
Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260111/ce901a58/attachment.htm>

From robaho at me.com  Sun Jan 11 17:57:21 2026
From: robaho at me.com (robert engels)
Date: Sun, 11 Jan 2026 11:57:21 -0600
Subject: [External] : Re: Ephemeral threads
In-Reply-To: <a96c0530-5430-4c5b-8a61-8182a2ff934c@oracle.com>
References: <a96c0530-5430-4c5b-8a61-8182a2ff934c@oracle.com>
Message-ID: <3C66E7C5-ABF7-4247-A88C-08683E7E2075@me.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260111/369531af/attachment-0001.htm>

From robaho at me.com  Sun Jan 11 17:58:51 2026
From: robaho at me.com (robert engels)
Date: Sun, 11 Jan 2026 11:58:51 -0600
Subject: [External] : Re: Ephemeral threads
In-Reply-To: <3C66E7C5-ABF7-4247-A88C-08683E7E2075@me.com>
References: <3C66E7C5-ABF7-4247-A88C-08683E7E2075@me.com>
Message-ID: <12D33401-33A6-4CBB-B0BE-5756E5A9DBE2@me.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260111/157fc135/attachment.htm>

From outsider404 at gmail.com  Mon Jan 12 00:22:08 2026
From: outsider404 at gmail.com (Michal Domagala)
Date: Mon, 12 Jan 2026 01:22:08 +0100
Subject: Ephemeral threads
In-Reply-To: <1d774f83-6993-474c-9b06-526ac3582325@oracle.com>
References: <CAOdgdgzQU4z+8RA2WMuD=nGUtXAdx1D0P8BW3CMQcGcQDcTSYw@mail.gmail.com>
 <518ce8ef-4fa7-4166-a6fd-d2d699e51ba2@oracle.com>
 <f9f15ec0-28cf-40fe-aea8-5ecc89c16d9f@oracle.com>
 <bf0a7ae7-ca5e-48d3-a3bb-e8177fcb95ba@redhat.com>
 <637c717c-eede-4697-aa97-70db7b3e981f@oracle.com>
 <641baf6f-1a6c-423c-8d3c-526c3adbe731@redhat.com>
 <84805f86-fa9d-4821-8957-52cab1d35c85@oracle.com>
 <CA+heAJBefH-AU3Yp6AzD7kZMakvLAy_dS-w2jRfDTK5miQDwmQ@mail.gmail.com>
 <1d774f83-6993-474c-9b06-526ac3582325@oracle.com>
Message-ID: <CA+heAJCxmw9Vqhh54xniBwuiXUZ6yCksrVf6VtoiUWxQ0KzKAA@mail.gmail.com>

>
>  Unfortunately it doesn't help, as it can observably change the behavior
> exhibited by code executed by such a thread.
>
Assuming it is true, activation  -Djdk.trackAllThreads=false changes the
behavior also. Option to disable tracking for particular thread does not
change general understanding what is a help and what is not a help
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260112/b2323e8e/attachment.htm>

From dmitry.zaslavsky at gmail.com  Mon Jan 12 04:17:06 2026
From: dmitry.zaslavsky at gmail.com (Dmitry Zaslavsky)
Date: Sun, 11 Jan 2026 23:17:06 -0500
Subject: [External] : Re: Ephemeral threads
In-Reply-To: <ad6c6c2e-5c4d-43bd-9963-654dd2e497ba@oracle.com>
References: <CAOdgdgzQU4z+8RA2WMuD=nGUtXAdx1D0P8BW3CMQcGcQDcTSYw@mail.gmail.com>
 <518ce8ef-4fa7-4166-a6fd-d2d699e51ba2@oracle.com>
 <f9f15ec0-28cf-40fe-aea8-5ecc89c16d9f@oracle.com>
 <6E8BCF39-B438-4C4A-A892-8C933FB86F92@gmail.com>
 <01c37422-171d-49b0-a216-15bb8aaaf172@oracle.com>
 <5A5AEC77-43CC-4D2D-87E1-3EC6F8D066AF@gmail.com>
 <1ef40f81-0e75-4752-989b-11cd4e5601a7@oracle.com>
 <7286AE3F-6E40-4318-B6D1-A363B9C746E7@gmail.com>
 <ad6c6c2e-5c4d-43bd-9963-654dd2e497ba@oracle.com>
Message-ID: <93E1C564-91A2-4F30-9B15-C627FFA9DA25@gmail.com>

I am not being clear. 

I am NOT arguing that there could be no demonstrable differences between VT GCed and not.
For my case we are not interested in such differences. They can be detected as disallowed.
As I mentioned previously we generally don?t let users use threading primitives, not locks and surely not LockSupport.

My example with our custom Try is just to say we can allow an ?escape? for special cases.
I can similarly allow any case by wrapping it into a function that will ?register? the thread.

Your case TBH is not a great case.
>>>     long fileDescriptor = acquireFileDescriptor();
>>>     LockSupport.park();				
>>>     releaseFileDescriptor(fileDescriptor);
>>> 

The only way VT would get GCed if someone dropped all the VT references and that would mean that park() would never return.
So GCed or not releaseXXX is not called.
I admit (I think that?s what Alan was saying) that it would be easier to debug such case, if one still finds a thread on a heap.

The reason I am so interested in dropping a VT which was cancelled is that we need to make sure that no code under a given cancellation scope will execute after some barrier ?. cancellAndWait(someCancellationScope) 
That function first cancels the scope (sets the variable), that means no new tasks will be started under that scope.
Now, I have to wait for all currently running tasks to complete in some shape or form.
Now if some tasks are cancelled but ?parked? I would have to hydrate them and inject an exception hoping to complete them as soon as possible.
It?s rather expensive and a complete waste in our system.

I think cancellation would be very important for scoped tasks. Logically at least they are closer to what our system is doing.

But even if you don?t want such cancellation for scoped tasks, maybe you can allow us to commit an evil thing and drop the VT.
i.e. make it an option on virtual thread builder or some way as part of VirtualScheduler interface?

Thanks again.
I really appreciate super quick response here (on Sunday!)



> On Jan 11, 2026, at 11:30?AM, Viktor Klang <viktor.klang at oracle.com> wrote:
> 
> >Meaning park() doesn?t have to return?. Exception could be thrown and release never called?.
> 
> park() <https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/concurrent/locks/LockSupport.html#park()> isn't documented to throw any exception, and even if it were to throw an exception, it would unwind the stack and end up in some UncaughtExceptionHandler.
> 
> >Resources must be used with try blocks (or some logically similar construct) 
> 
> I deliberately omitted the try-finally to be able to say this: try-finally wouldn't help here if the VT is GCed when parked.
> 
> On 2026-01-11 05:17, Dmitry Zaslavsky wrote:
>> Your code would be broken in our case, but it?s broken in ?plain? java case as well.
>> Meaning park() doesn?t have to return?. Exception could be thrown and release never called?.
>> 
>> Resources must be used with try blocks (or some logically similar construct) 
>> That?s what we are trying to ?manage? by having a library construct.
>> That library construct ensures (optionally) that finally (clean up) called up in any case.
>> 
>> The other option I would want to consider is allowing try/finally and throwing an interrupt exception.
>> I haven?t played with this. Ideally JVM support that lets me know if there is a finally block on stack would be nice.
>> But I know it?s too much to ask.
>> 
>> 
>> 
>>> On Jan 10, 2026, at 7:02?PM, Viktor Klang <viktor.klang at oracle.com> <mailto:viktor.klang at oracle.com> wrote:
>>> 
>>> Hi Dmitry,
>>> 
>>> An example can look like:
>>> 
>>> void method() {
>>>     long fileDescriptor = acquireFileDescriptor();
>>>     LockSupport.park();
>>>     releaseFileDescriptor(fileDescriptor);
>>> }
>>> 
>>> If an ephemeral VT executes that method, and there are no other references to that ephemeral VT, then at the point of park(), nothing can unpark it anymore, and it will then never release the file descriptor.
>>> 
>>> 
>>> >We generally don?t allow try blocks (providing other constructs), we also very strongly discourage (just a drop short of disallowing) ANY threading primitives.
>>> 
>>> 
>>> I don't see how that can work in practice, because it requires all users of your constructs to be familiar about exactly how all third-party logic (including JDK classes) are implemented under the hood. Perhaps I'm misunderstanding?
>>> 
>>> 
>>> On 2026-01-09 17:27, Dmitry Zaslavsky wrote:
>>>> Not sure what you mean by native resources?
>>>> Do you mean what people would use like try resources?
>>>> We generally don?t allow try blocks (providing other constructs), we also very strongly discourage (just a drop short of disallowing) ANY threading primitives.
>>>> 
>>>> Which makes me think that there is a better way to express my point from before.
>>>> I think there is actually a common pattern here.
>>>> 
>>>> We use VT inside of the lib. We don?t want users to actually use any threads all.
>>>> I think it?s a goal of Alex as well. 
>>>> We use VT as  a way to avoid using threads (if that makes sense).
>>>> 
>>>> I think ScopedTasks is going in the same direction. Ideally user just doesn?t know there are threads.
>>>> We use Scala (appealing to Victor ;)) vals and immutable collections is the norm.
>>>> 
>>>> We don?t want users to think about Threads period.
>>>> So the thought of "GC roots on a VT ? we don?t want that though to ever occur or we failed ;)
>>>> 
>>>> 
>>>> 
>>>>  
>>>> 
>>>>> On Jan 9, 2026, at 10:26?AM, Viktor Klang <viktor.klang at oracle.com> <mailto:viktor.klang at oracle.com> wrote:
>>>>> 
>>>>> 
>>>>> On 2026-01-09 15:39, Dmitry Zaslavsky wrote:
>>>>>> someCollection.apar.map { ?. }
>>>>>> Can spin N tasks (Each can get it's VT) If some iteration of the loop throws, we don?t need to rest of the code to run, it?s costly.
>>>>>> If the task are not actively mounted but previously started and are waiting? (in our case it?s LockSupport.park) we just want to drop that entire queue and everything around it?.
>>>>>> 
>>>>>> 
>>>>> How do you handle acquired native resources that are yet to be released?
>>>>> 
>>>>> 
>>>>> -- 
>>>>> Cheers,
>>>>> ?
>>>>> 
>>>>> 
>>>>> Viktor Klang
>>>>> Software Architect, Java Platform Group
>>>>> Oracle
>>>>> 
>>> -- 
>>> Cheers,
>>> ?
>>> 
>>> 
>>> Viktor Klang
>>> Software Architect, Java Platform Group
>>> Oracle
>> 
> -- 
> Cheers,
> ?
> 
> 
> Viktor Klang
> Software Architect, Java Platform Group
> Oracle

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260111/e620caaa/attachment-0001.htm>

From robaho at me.com  Mon Jan 12 04:36:21 2026
From: robaho at me.com (robert engels)
Date: Sun, 11 Jan 2026 22:36:21 -0600
Subject: [External] : Re: Ephemeral threads
In-Reply-To: <93E1C564-91A2-4F30-9B15-C627FFA9DA25@gmail.com>
References: <93E1C564-91A2-4F30-9B15-C627FFA9DA25@gmail.com>
Message-ID: <4C55B68F-8769-4823-A9F8-55E1F9A92767@me.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260111/7f7d6e54/attachment.htm>

From viktor.klang at oracle.com  Mon Jan 12 09:57:44 2026
From: viktor.klang at oracle.com (Viktor Klang)
Date: Mon, 12 Jan 2026 10:57:44 +0100
Subject: [External] : Re: Ephemeral threads
In-Reply-To: <4C55B68F-8769-4823-A9F8-55E1F9A92767@me.com>
References: <93E1C564-91A2-4F30-9B15-C627FFA9DA25@gmail.com>
 <4C55B68F-8769-4823-A9F8-55E1F9A92767@me.com>
Message-ID: <7781235b-b513-49fa-95c7-5cd7d57f452d@oracle.com>

How do you find the bug?

On 2026-01-12 05:36, robert engels wrote:
> Why not just fix your design to ensure the proper behavior?

-- 
Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle


From viktor.klang at oracle.com  Mon Jan 12 09:59:43 2026
From: viktor.klang at oracle.com (Viktor Klang)
Date: Mon, 12 Jan 2026 10:59:43 +0100
Subject: [External] : Re: Ephemeral threads
In-Reply-To: <3C66E7C5-ABF7-4247-A88C-08683E7E2075@me.com>
References: <a96c0530-5430-4c5b-8a61-8182a2ff934c@oracle.com>
 <3C66E7C5-ABF7-4247-A88C-08683E7E2075@me.com>
Message-ID: <d0ebb91e-5868-4f00-9725-4362bf95f253@oracle.com>

In my example there is no queue. Are you suggesting that all 
pre-existing code and all new code should get rewritten using some new API?

On 2026-01-11 18:57, robert engels wrote:
> because if park wakes up, the thread already has a reference to the 
> queue meaning it can start another thread that puts items into the 
> queue. ?Meaning the queue is not ?unreferenceable?, so you can?t 
> simply destroy a thread waiting in park().
>
>> On Jan 11, 2026, at 10:30?AM, Viktor Klang <viktor.klang at oracle.com> 
>> wrote:
>>
>> ?
>>
>> >This code is fundamentally broken. Park() can wake up for any reason.
>>
>> I don't see how "When park wakes up" (i.e. the temporal aspect) 
>> affects correctness in any way in the example given.
>>
>> >I suggest you look at ClosableQueue - it is correct and far easier 
>> to use.
>>
>> The example is completely devoid of any queuing concerns. We're 
>> talking about logic which is executed by some thread, and the person 
>> who writes the code does not strictly know whether that thread is a 
>> platform thread, a pooled platform thread, a virtual thread, an 
>> ephemeral virtual thread, a GC finalizer thread.
>>
>> In short, this is about: pre-existing code which may get executed by 
>> an ephemeral virtual thread may /silently/ leak resources under 
>> certain circumstances. Now, it can be argued that most of that code 
>> was "not ideal" in the first place, but the big difference is that 
>> when any such defect gets noticed in a running application, there's a 
>> much better visibility if the thread which ran into the problem is 
>> still there (evidence) vs not (no evidence).
>>
>> On 2026-01-11 01:50, Robert Engels wrote:
>>> This code is fundamentally broken. Park() can wake up for any reason.
>>>
>>> I suggest you look at ClosableQueue - it is correct and far easier 
>>> to use.
>>>
>>>> On Jan 10, 2026, at 6:03?PM, Viktor Klang <viktor.klang at oracle.com> 
>>>> wrote:
>>>>
>>>> ?
>>>>
>>>> Hi Dmitry,
>>>>
>>>> An example can look like:
>>>>
>>>> void method() {
>>>> ? ? long fileDescriptor = acquireFileDescriptor();
>>>> ? ? LockSupport.park();
>>>> ? ? releaseFileDescriptor(fileDescriptor);
>>>> }
>>>>
>>>> If an ephemeral VT executes that method, and there are no other 
>>>> references to that ephemeral VT, then at the point of park(), 
>>>> nothing can unpark it anymore, and it will then never release the 
>>>> file descriptor.
>>>>
>>>>
>>>> >We generally don?t allow try blocks (providing other constructs), 
>>>> we also very strongly discourage (just a drop short of disallowing) 
>>>> ANY threading primitives.
>>>>
>>>>
>>>> I don't see how that can work in practice, because it requires all 
>>>> users of your constructs to be familiar about exactly how all 
>>>> third-party logic (including JDK classes) are implemented under the 
>>>> hood. Perhaps I'm misunderstanding?
>>>>
>>>> On 2026-01-09 17:27, Dmitry Zaslavsky wrote:
>>>>> Not sure what you mean by native resources?
>>>>> Do you mean what people would use like try resources?
>>>>> We generally don?t allow try blocks (providing other constructs), we also very strongly discourage (just a drop short of disallowing) ANY threading primitives.
>>>>>
>>>>> Which makes me think that there is a better way to express my point from before.
>>>>> I think there is actually a common pattern here.
>>>>>
>>>>> We use VT inside of the lib. We don?t want users to actually use any threads all.
>>>>> I think it?s a goal of Alex as well.
>>>>> We use VT as  a way to avoid using threads (if that makes sense).
>>>>>
>>>>> I think ScopedTasks is going in the same direction. Ideally user just doesn?t know there are threads.
>>>>> We use Scala (appealing to Victor ;)) vals and immutable collections is the norm.
>>>>>
>>>>> We don?t want users to think about Threads period.
>>>>> So the thought of "GC roots on a VT ? we don?t want that though to ever occur or we failed ;)
>>>>>
>>>>>
>>>>>
>>>>>   
>>>>>
>>>>>> On Jan 9, 2026, at 10:26?AM, Viktor Klang<viktor.klang at oracle.com> wrote:
>>>>>>
>>>>>>
>>>>>> On 2026-01-09 15:39, Dmitry Zaslavsky wrote:
>>>>>>> someCollection.apar.map { ?. }
>>>>>>> Can spin N tasks (Each can get it's VT) If some iteration of the loop throws, we don?t need to rest of the code to run, it?s costly.
>>>>>>> If the task are not actively mounted but previously started and are waiting? (in our case it?s LockSupport.park) we just want to drop that entire queue and everything around it?.
>>>>>>>
>>>>>>>
>>>>>> How do you handle acquired native resources that are yet to be released?
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> Cheers,
>>>>>> ?
>>>>>>
>>>>>>
>>>>>> Viktor Klang
>>>>>> Software Architect, Java Platform Group
>>>>>> Oracle
>>>>>>
>>>> -- 
>>>> Cheers,
>>>> ?
>>>>
>>>>
>>>> Viktor Klang
>>>> Software Architect, Java Platform Group
>>>> Oracle
>> -- 
>> Cheers,
>> ?
>>
>>
>> Viktor Klang
>> Software Architect, Java Platform Group
>> Oracle

-- 
Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260112/d1799845/attachment.htm>

From oleksandr.otenko at gmail.com  Mon Jan 12 10:05:00 2026
From: oleksandr.otenko at gmail.com (Alex Otenko)
Date: Mon, 12 Jan 2026 10:05:00 +0000
Subject: [External] : Re: Ephemeral threads
In-Reply-To: <7781235b-b513-49fa-95c7-5cd7d57f452d@oracle.com>
References: <93E1C564-91A2-4F30-9B15-C627FFA9DA25@gmail.com>
 <4C55B68F-8769-4823-A9F8-55E1F9A92767@me.com>
 <7781235b-b513-49fa-95c7-5cd7d57f452d@oracle.com>
Message-ID: <CANkgWKiL3U_4-H3oy002+uXwC6m-XsYe+C-TS8rcisJDyNWJQA@mail.gmail.com>

I'd say it's not even clear why that'd constitute a bug. Whole systems are
built on go-rourines and continuations getting GCed.

I think there certainly is a clash between the need to track life cycle of
something (tell threads to terminate) in a system where life cycle of
things is not tracked (because GC).

On Mon, 12 Jan 2026, 09:58 Viktor Klang, <viktor.klang at oracle.com> wrote:

> How do you find the bug?
>
> On 2026-01-12 05:36, robert engels wrote:
> > Why not just fix your design to ensure the proper behavior?
>
> --
> Cheers,
> ?
>
>
> Viktor Klang
> Software Architect, Java Platform Group
> Oracle
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260112/8d0bb406/attachment-0001.htm>

From rengels at ix.netcom.com  Mon Jan 12 11:22:53 2026
From: rengels at ix.netcom.com (Robert Engels)
Date: Mon, 12 Jan 2026 05:22:53 -0600
Subject: [External] : Re: Ephemeral threads
In-Reply-To: <CANkgWKiL3U_4-H3oy002+uXwC6m-XsYe+C-TS8rcisJDyNWJQA@mail.gmail.com>
References: <CANkgWKiL3U_4-H3oy002+uXwC6m-XsYe+C-TS8rcisJDyNWJQA@mail.gmail.com>
Message-ID: <2BC7AC23-83CA-40D5-95DE-35E8471EB656@ix.netcom.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260112/c3e71658/attachment.htm>

From rengels at ix.netcom.com  Mon Jan 12 11:31:47 2026
From: rengels at ix.netcom.com (Robert Engels)
Date: Mon, 12 Jan 2026 05:31:47 -0600
Subject: [External] : Re: Ephemeral threads
In-Reply-To: <d0ebb91e-5868-4f00-9725-4362bf95f253@oracle.com>
References: <d0ebb91e-5868-4f00-9725-4362bf95f253@oracle.com>
Message-ID: <799A0CA7-8A87-4645-9761-8980835E1624@ix.netcom.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260112/fd4d6cd7/attachment.htm>

From viktor.klang at oracle.com  Mon Jan 12 11:50:54 2026
From: viktor.klang at oracle.com (Viktor Klang)
Date: Mon, 12 Jan 2026 12:50:54 +0100
Subject: [External] : Re: Ephemeral threads
In-Reply-To: <2BC7AC23-83CA-40D5-95DE-35E8471EB656@ix.netcom.com>
References: <CANkgWKiL3U_4-H3oy002+uXwC6m-XsYe+C-TS8rcisJDyNWJQA@mail.gmail.com>
 <2BC7AC23-83CA-40D5-95DE-35E8471EB656@ix.netcom.com>
Message-ID: <4f9b2ac9-db35-4a32-9d78-ef32c4660cca@oracle.com>

Yes, just search for "forgotten sender abandoned receiver".

On 2026-01-12 12:22, Robert Engels wrote:
> That is not true. Go routines do not ?clean up? when they cannot make 
> progress due to no producers. Go leaks due to this are very common.
>
>> On Jan 12, 2026, at 4:05?AM, Alex Otenko <oleksandr.otenko at gmail.com> 
>> wrote:
>>
>> ?
>> I'd say it's not even clear why that'd constitute a bug. Whole 
>> systems are built on go-rourines and continuations getting GCed.
>>
>> I think there certainly is a clash between the need to track life 
>> cycle of something (tell threads to terminate) in a system where life 
>> cycle of things is not tracked (because GC).
>>
>> On Mon, 12 Jan 2026, 09:58 Viktor Klang, <viktor.klang at oracle.com> wrote:
>>
>>     How do you find the bug?
>>
>>     On 2026-01-12 05:36, robert engels wrote:
>>     > Why not just fix your design to ensure the proper behavior?
>>
>>     -- 
>>     Cheers,
>>     ?
>>
>>
>>     Viktor Klang
>>     Software Architect, Java Platform Group
>>     Oracle
>>
-- 
Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260112/41659bfe/attachment-0001.htm>

From viktor.klang at oracle.com  Mon Jan 12 11:53:11 2026
From: viktor.klang at oracle.com (Viktor Klang)
Date: Mon, 12 Jan 2026 12:53:11 +0100
Subject: [External] : Re: Ephemeral threads
In-Reply-To: <799A0CA7-8A87-4645-9761-8980835E1624@ix.netcom.com>
References: <d0ebb91e-5868-4f00-9725-4362bf95f253@oracle.com>
 <799A0CA7-8A87-4645-9761-8980835E1624@ix.netcom.com>
Message-ID: <e03f025b-e460-489d-baf7-a87bb75e5df0@oracle.com>

What I'm saying is that detecting, and debugging, such issues is vastly 
more difficult when the forgotten thread has been GC:ed.

On 2026-01-12 12:31, Robert Engels wrote:
> No, just ensure that there is always a thread this will eventually 
> call unpark().
>
> You can ensure this with proper use of try/finally.
>
> If you write that code any nothing ever calls unpark - it is hung (and 
> leaked). You can resolve this without any new APIs.
>
> It has nothing to do with queues - it is all about correctness. It 
> seems queues (or channels) has been discussed because this is a common 
> source of this issue (especially in Go). See #2 here: 
> https://oneuptime.com/blog/post/2026-01-07-go-goroutine-leaks/view 
> <https://urldefense.com/v3/__https://oneuptime.com/blog/post/2026-01-07-go-goroutine-leaks/view__;!!ACWV5N9M2RV99hQ!Lc6RAKDcwT9pWlm7RR0zEh8Bw0kuCIHACWakPWcDKd89LJW1dwJMlK3Suc5v2grGe5E02hM6uJKJvH9m4PI$>
>
>> On Jan 12, 2026, at 4:00?AM, Viktor Klang <viktor.klang at oracle.com> 
>> wrote:
>>
>> ?
>>
>> In my example there is no queue. Are you suggesting that all 
>> pre-existing code and all new code should get rewritten using some 
>> new API?
>>
>> On 2026-01-11 18:57, robert engels wrote:
>>> because if park wakes up, the thread already has a reference to the 
>>> queue meaning it can start another thread that puts items into the 
>>> queue. ?Meaning the queue is not ?unreferenceable?, so you can?t 
>>> simply destroy a thread waiting in park().
>>>
>>>> On Jan 11, 2026, at 10:30?AM, Viktor Klang 
>>>> <viktor.klang at oracle.com> wrote:
>>>>
>>>> ?
>>>>
>>>> >This code is fundamentally broken. Park() can wake up for any reason.
>>>>
>>>> I don't see how "When park wakes up" (i.e. the temporal aspect) 
>>>> affects correctness in any way in the example given.
>>>>
>>>> >I suggest you look at ClosableQueue - it is correct and far easier 
>>>> to use.
>>>>
>>>> The example is completely devoid of any queuing concerns. We're 
>>>> talking about logic which is executed by some thread, and the 
>>>> person who writes the code does not strictly know whether that 
>>>> thread is a platform thread, a pooled platform thread, a virtual 
>>>> thread, an ephemeral virtual thread, a GC finalizer thread.
>>>>
>>>> In short, this is about: pre-existing code which may get executed 
>>>> by an ephemeral virtual thread may /silently/ leak resources under 
>>>> certain circumstances. Now, it can be argued that most of that code 
>>>> was "not ideal" in the first place, but the big difference is that 
>>>> when any such defect gets noticed in a running application, there's 
>>>> a much better visibility if the thread which ran into the problem 
>>>> is still there (evidence) vs not (no evidence).
>>>>
>>>> On 2026-01-11 01:50, Robert Engels wrote:
>>>>> This code is fundamentally broken. Park() can wake up for any reason.
>>>>>
>>>>> I suggest you look at ClosableQueue - it is correct and far easier 
>>>>> to use.
>>>>>
>>>>>> On Jan 10, 2026, at 6:03?PM, Viktor Klang 
>>>>>> <viktor.klang at oracle.com> wrote:
>>>>>>
>>>>>> ?
>>>>>>
>>>>>> Hi Dmitry,
>>>>>>
>>>>>> An example can look like:
>>>>>>
>>>>>> void method() {
>>>>>> ? ? long fileDescriptor = acquireFileDescriptor();
>>>>>> ? ? LockSupport.park();
>>>>>> ? ? releaseFileDescriptor(fileDescriptor);
>>>>>> }
>>>>>>
>>>>>> If an ephemeral VT executes that method, and there are no other 
>>>>>> references to that ephemeral VT, then at the point of park(), 
>>>>>> nothing can unpark it anymore, and it will then never release the 
>>>>>> file descriptor.
>>>>>>
>>>>>>
>>>>>> >We generally don?t allow try blocks (providing other 
>>>>>> constructs), we also very strongly discourage (just a drop short 
>>>>>> of disallowing) ANY threading primitives.
>>>>>>
>>>>>>
>>>>>> I don't see how that can work in practice, because it requires 
>>>>>> all users of your constructs to be familiar about exactly how all 
>>>>>> third-party logic (including JDK classes) are implemented under 
>>>>>> the hood. Perhaps I'm misunderstanding?
>>>>>>
>>>>>> On 2026-01-09 17:27, Dmitry Zaslavsky wrote:
>>>>>>> Not sure what you mean by native resources?
>>>>>>> Do you mean what people would use like try resources?
>>>>>>> We generally don?t allow try blocks (providing other constructs), we also very strongly discourage (just a drop short of disallowing) ANY threading primitives.
>>>>>>>
>>>>>>> Which makes me think that there is a better way to express my point from before.
>>>>>>> I think there is actually a common pattern here.
>>>>>>>
>>>>>>> We use VT inside of the lib. We don?t want users to actually use any threads all.
>>>>>>> I think it?s a goal of Alex as well.
>>>>>>> We use VT as  a way to avoid using threads (if that makes sense).
>>>>>>>
>>>>>>> I think ScopedTasks is going in the same direction. Ideally user just doesn?t know there are threads.
>>>>>>> We use Scala (appealing to Victor ;)) vals and immutable collections is the norm.
>>>>>>>
>>>>>>> We don?t want users to think about Threads period.
>>>>>>> So the thought of "GC roots on a VT ? we don?t want that though to ever occur or we failed ;)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>   
>>>>>>>
>>>>>>>> On Jan 9, 2026, at 10:26?AM, Viktor Klang<viktor.klang at oracle.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2026-01-09 15:39, Dmitry Zaslavsky wrote:
>>>>>>>>> someCollection.apar.map { ?. }
>>>>>>>>> Can spin N tasks (Each can get it's VT) If some iteration of the loop throws, we don?t need to rest of the code to run, it?s costly.
>>>>>>>>> If the task are not actively mounted but previously started and are waiting? (in our case it?s LockSupport.park) we just want to drop that entire queue and everything around it?.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> How do you handle acquired native resources that are yet to be released?
>>>>>>>>
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> Cheers,
>>>>>>>> ?
>>>>>>>>
>>>>>>>>
>>>>>>>> Viktor Klang
>>>>>>>> Software Architect, Java Platform Group
>>>>>>>> Oracle
>>>>>>>>
>>>>>> -- 
>>>>>> Cheers,
>>>>>> ?
>>>>>>
>>>>>>
>>>>>> Viktor Klang
>>>>>> Software Architect, Java Platform Group
>>>>>> Oracle
>>>> -- 
>>>> Cheers,
>>>> ?
>>>>
>>>>
>>>> Viktor Klang
>>>> Software Architect, Java Platform Group
>>>> Oracle
>> -- 
>> Cheers,
>> ?
>>
>>
>> Viktor Klang
>> Software Architect, Java Platform Group
>> Oracle

-- 
Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260112/16b13a16/attachment.htm>

From rengels at ix.netcom.com  Mon Jan 12 12:15:50 2026
From: rengels at ix.netcom.com (Robert Engels)
Date: Mon, 12 Jan 2026 06:15:50 -0600
Subject: [External] : Re: Ephemeral threads
In-Reply-To: <e03f025b-e460-489d-baf7-a87bb75e5df0@oracle.com>
References: <e03f025b-e460-489d-baf7-a87bb75e5df0@oracle.com>
Message-ID: <A5653545-189E-4CF3-87E7-E598D0AFC1BC@ix.netcom.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260112/82452da7/attachment-0001.htm>

From alan.bateman at oracle.com  Mon Jan 12 12:41:01 2026
From: alan.bateman at oracle.com (Alan Bateman)
Date: Mon, 12 Jan 2026 12:41:01 +0000
Subject: Ephemeral threads
In-Reply-To: <FCE7C380-F20B-4CEC-BE48-179C69BAF001@puredanger.com>
References: <637c717c-eede-4697-aa97-70db7b3e981f@oracle.com>
 <FCE7C380-F20B-4CEC-BE48-179C69BAF001@puredanger.com>
Message-ID: <100c240d-5e75-4452-8a0b-1e405a659578@oracle.com>



On 10/01/2026 15:55, Alex Miller wrote:
> What is the likely future of the trackAllThreads flag?
TBD. It's clearly an attractive nuisance right now and setting it to 
false is specific to the root "thread grouping". There is some 
performance work required in that area but otherwise I think it needs to 
be removed.

-Alan

From viktor.klang at oracle.com  Mon Jan 12 12:59:57 2026
From: viktor.klang at oracle.com (Viktor Klang)
Date: Mon, 12 Jan 2026 13:59:57 +0100
Subject: [External] : Re: Ephemeral threads
In-Reply-To: <A5653545-189E-4CF3-87E7-E598D0AFC1BC@ix.netcom.com>
References: <e03f025b-e460-489d-baf7-a87bb75e5df0@oracle.com>
 <A5653545-189E-4CF3-87E7-E598D0AFC1BC@ix.netcom.com>
Message-ID: <95ddd0d8-db95-4ee0-9021-3005b2c6f057@oracle.com>

Why wouldn't it have a stack trace or object references? How would it be 
able to log something on thread exit if it never exits (it gets GC:ed).

On 2026-01-12 13:15, Robert Engels wrote:
> It would have no object references and no stack trace.

-- 
Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle


From robaho at me.com  Mon Jan 12 13:11:53 2026
From: robaho at me.com (robert engels)
Date: Mon, 12 Jan 2026 07:11:53 -0600
Subject: [External] : Re: Ephemeral threads
In-Reply-To: <95ddd0d8-db95-4ee0-9021-3005b2c6f057@oracle.com>
References: <95ddd0d8-db95-4ee0-9021-3005b2c6f057@oracle.com>
Message-ID: <9E7A8E26-8672-412B-92AD-F05B24912F22@me.com>

I?m sorry - but I?m confused now. The primary cause of the issue is no unparkers left (which with ephemeral would mean that the waiters would ?disappear? since they could never make progress. So the unparker thread must have exited - that is the source of the bug. Having the waiters just be GCd would break the language specification regarding try/finally. I understand that if the thread cannot make progress there should be no difference - but there is - because of details like weak references and finalizers- the system would be in an inconsistent state. 

So the proper solution is no to ?disappear? the threads, but fix the prime issue of no unparkers. 

> On Jan 12, 2026, at 7:00?AM, Viktor Klang <viktor.klang at oracle.com> wrote:
> 
> ?Why wouldn't it have a stack trace or object references? How would it be able to log something on thread exit if it never exits (it gets GC:ed).
> 
>> On 2026-01-12 13:15, Robert Engels wrote:
>> It would have no object references and no stack trace.
> 
> --
> Cheers,
> ?
> 
> 
> Viktor Klang
> Software Architect, Java Platform Group
> Oracle
> 

From viktor.klang at oracle.com  Mon Jan 12 14:05:44 2026
From: viktor.klang at oracle.com (Viktor Klang)
Date: Mon, 12 Jan 2026 15:05:44 +0100
Subject: [External] : Re: Ephemeral threads
In-Reply-To: <9E7A8E26-8672-412B-92AD-F05B24912F22@me.com>
References: <95ddd0d8-db95-4ee0-9021-3005b2c6f057@oracle.com>
 <9E7A8E26-8672-412B-92AD-F05B24912F22@me.com>
Message-ID: <d6a96068-aea4-4f61-b767-a3c280ce57c8@oracle.com>

The unparker thread doesn't have had to have exited, it just forgot whom 
to unpark.

On 2026-01-12 14:11, robert engels wrote:
> I?m sorry - but I?m confused now. The primary cause of the issue is no unparkers left (which with ephemeral would mean that the waiters would ?disappear? since they could never make progress. So the unparker thread must have exited - that is the source of the bug. Having the waiters just be GCd would break the language specification regarding try/finally. I understand that if the thread cannot make progress there should be no difference - but there is - because of details like weak references and finalizers- the system would be in an inconsistent state.
>
> So the proper solution is no to ?disappear? the threads, but fix the prime issue of no unparkers.
>
>> On Jan 12, 2026, at 7:00?AM, Viktor Klang <viktor.klang at oracle.com> wrote:
>>
>> ?Why wouldn't it have a stack trace or object references? How would it be able to log something on thread exit if it never exits (it gets GC:ed).
>>
>>> On 2026-01-12 13:15, Robert Engels wrote:
>>> It would have no object references and no stack trace.
>> --
>> Cheers,
>> ?
>>
>>
>> Viktor Klang
>> Software Architect, Java Platform Group
>> Oracle
>>
-- 
Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle


From rengels at ix.netcom.com  Mon Jan 12 14:14:35 2026
From: rengels at ix.netcom.com (Robert Engels)
Date: Mon, 12 Jan 2026 08:14:35 -0600
Subject: [External] : Re: Ephemeral threads
In-Reply-To: <d6a96068-aea4-4f61-b767-a3c280ce57c8@oracle.com>
References: <d6a96068-aea4-4f61-b767-a3c280ce57c8@oracle.com>
Message-ID: <B0B4AC86-E1C7-4A85-819E-2860F445273E@ix.netcom.com>

That would still be a design bug / logic flaw. 

> On Jan 12, 2026, at 8:06?AM, Viktor Klang <viktor.klang at oracle.com> wrote:
> 
> ?The unparker thread doesn't have had to have exited, it just forgot whom to unpark.
> 
>> On 2026-01-12 14:11, robert engels wrote:
>> I?m sorry - but I?m confused now. The primary cause of the issue is no unparkers left (which with ephemeral would mean that the waiters would ?disappear? since they could never make progress. So the unparker thread must have exited - that is the source of the bug. Having the waiters just be GCd would break the language specification regarding try/finally. I understand that if the thread cannot make progress there should be no difference - but there is - because of details like weak references and finalizers- the system would be in an inconsistent state.
>> 
>> So the proper solution is no to ?disappear? the threads, but fix the prime issue of no unparkers.
>> 
>>>> On Jan 12, 2026, at 7:00?AM, Viktor Klang <viktor.klang at oracle.com> wrote:
>>> 
>>> ?Why wouldn't it have a stack trace or object references? How would it be able to log something on thread exit if it never exits (it gets GC:ed).
>>> 
>>>> On 2026-01-12 13:15, Robert Engels wrote:
>>>> It would have no object references and no stack trace.
>>> --
>>> Cheers,
>>> ?
>>> 
>>> 
>>> Viktor Klang
>>> Software Architect, Java Platform Group
>>> Oracle
>>> 
> --
> Cheers,
> ?
> 
> 
> Viktor Klang
> Software Architect, Java Platform Group
> Oracle
> 

From viktor.klang at oracle.com  Mon Jan 12 14:37:38 2026
From: viktor.klang at oracle.com (Viktor Klang)
Date: Mon, 12 Jan 2026 15:37:38 +0100
Subject: [External] : Re: Ephemeral threads
In-Reply-To: <B0B4AC86-E1C7-4A85-819E-2860F445273E@ix.netcom.com>
References: <d6a96068-aea4-4f61-b767-a3c280ce57c8@oracle.com>
 <B0B4AC86-E1C7-4A85-819E-2860F445273E@ix.netcom.com>
Message-ID: <e1ca566d-4413-472c-a367-546045b8ba31@oracle.com>

Yes, as previously mentioned, there is a big impact on debuggability.

On 2026-01-12 15:14, Robert Engels wrote:
> That would still be a design bug / logic flaw.
>
>> On Jan 12, 2026, at 8:06?AM, Viktor Klang <viktor.klang at oracle.com> wrote:
>>
>> ?The unparker thread doesn't have had to have exited, it just forgot whom to unpark.
>>
>>> On 2026-01-12 14:11, robert engels wrote:
>>> I?m sorry - but I?m confused now. The primary cause of the issue is no unparkers left (which with ephemeral would mean that the waiters would ?disappear? since they could never make progress. So the unparker thread must have exited - that is the source of the bug. Having the waiters just be GCd would break the language specification regarding try/finally. I understand that if the thread cannot make progress there should be no difference - but there is - because of details like weak references and finalizers- the system would be in an inconsistent state.
>>>
>>> So the proper solution is no to ?disappear? the threads, but fix the prime issue of no unparkers.
>>>
>>>>> On Jan 12, 2026, at 7:00?AM, Viktor Klang <viktor.klang at oracle.com> wrote:
>>>> ?Why wouldn't it have a stack trace or object references? How would it be able to log something on thread exit if it never exits (it gets GC:ed).
>>>>
>>>>> On 2026-01-12 13:15, Robert Engels wrote:
>>>>> It would have no object references and no stack trace.
>>>> --
>>>> Cheers,
>>>> ?
>>>>
>>>>
>>>> Viktor Klang
>>>> Software Architect, Java Platform Group
>>>> Oracle
>>>>
>> --
>> Cheers,
>> ?
>>
>>
>> Viktor Klang
>> Software Architect, Java Platform Group
>> Oracle
>>
-- 
Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle


From oleksandr.otenko at gmail.com  Tue Jan 13 06:42:06 2026
From: oleksandr.otenko at gmail.com (Alex Otenko)
Date: Tue, 13 Jan 2026 06:42:06 +0000
Subject: [External] : Re: Ephemeral threads
In-Reply-To: <4f9b2ac9-db35-4a32-9d78-ef32c4660cca@oracle.com>
References: <CANkgWKiL3U_4-H3oy002+uXwC6m-XsYe+C-TS8rcisJDyNWJQA@mail.gmail.com>
 <2BC7AC23-83CA-40D5-95DE-35E8471EB656@ix.netcom.com>
 <4f9b2ac9-db35-4a32-9d78-ef32c4660cca@oracle.com>
Message-ID: <CANkgWKj34NoSTtk5THOc_i6hOkXNwO5LuJMSE43DWFTf-X01Lg@mail.gmail.com>

Oh, ok, I confused it with something else. I recall dealing with a system
that would panic or report that there were fibers that were no longer going
to make progress.

I think there are plenty of designs with generators, iterators and async
where non-termination is not a bug.

On Mon, 12 Jan 2026, 11:51 Viktor Klang, <viktor.klang at oracle.com> wrote:

> Yes, just search for "forgotten sender abandoned receiver".
> On 2026-01-12 12:22, Robert Engels wrote:
>
> That is not true. Go routines do not ?clean up? when they cannot make
> progress due to no producers. Go leaks due to this are very common.
>
> On Jan 12, 2026, at 4:05?AM, Alex Otenko <oleksandr.otenko at gmail.com>
> <oleksandr.otenko at gmail.com> wrote:
>
> ?
> I'd say it's not even clear why that'd constitute a bug. Whole systems are
> built on go-rourines and continuations getting GCed.
>
> I think there certainly is a clash between the need to track life cycle of
> something (tell threads to terminate) in a system where life cycle of
> things is not tracked (because GC).
>
> On Mon, 12 Jan 2026, 09:58 Viktor Klang, <viktor.klang at oracle.com> wrote:
>
>> How do you find the bug?
>>
>> On 2026-01-12 05:36, robert engels wrote:
>> > Why not just fix your design to ensure the proper behavior?
>>
>> --
>> Cheers,
>> ?
>>
>>
>> Viktor Klang
>> Software Architect, Java Platform Group
>> Oracle
>>
>> --
> Cheers,
> ?
>
>
> Viktor Klang
> Software Architect, Java Platform Group
> Oracle
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260113/c18b9b6d/attachment.htm>

From michael.van.acken at gmail.com  Tue Jan 13 07:45:15 2026
From: michael.van.acken at gmail.com (Michael van Acken)
Date: Tue, 13 Jan 2026 08:45:15 +0100
Subject: [External] : Re: Ephemeral threads
In-Reply-To: <CANkgWKj34NoSTtk5THOc_i6hOkXNwO5LuJMSE43DWFTf-X01Lg@mail.gmail.com>
References: <CANkgWKiL3U_4-H3oy002+uXwC6m-XsYe+C-TS8rcisJDyNWJQA@mail.gmail.com>
 <2BC7AC23-83CA-40D5-95DE-35E8471EB656@ix.netcom.com>
 <4f9b2ac9-db35-4a32-9d78-ef32c4660cca@oracle.com>
 <CANkgWKj34NoSTtk5THOc_i6hOkXNwO5LuJMSE43DWFTf-X01Lg@mail.gmail.com>
Message-ID: <CAEYHehiiZw32z71DggH2NZWpqPqUXUL6nWDy=OyN-huxnFHH+w@mail.gmail.com>

Am Di., 13. Jan. 2026 um 07:42 Uhr schrieb Alex Otenko <
oleksandr.otenko at gmail.com>:

> Oh, ok, I confused it with something else. I recall dealing with a system
> that would panic or report that there were fibers that were no longer going
> to make progress.
>
> I think there are plenty of designs with generators, iterators and async
> where non-termination is not a bug.
>

I have been thinking about this as well, what the difference between
various perspectives/designs actually is.

My first and up to now only idea: a thread comes with hard promises about
what things will happen in the future.

Its accumulated call/handler stack is a batch of unfinished business that
is guaranteed to be worked upon.
If there are two statements "A; B;", then there is a hard promise that
normal completion of A implies execution of B.
If A completes exceptionally, then other rules apply, but they also clearly
state what happens next.

A thread "disappearing" at the point of A would be a mode of completion
different from both "normal" and "exceptional".

-- mva





>
> On Mon, 12 Jan 2026, 11:51 Viktor Klang, <viktor.klang at oracle.com> wrote:
>
>> Yes, just search for "forgotten sender abandoned receiver".
>> On 2026-01-12 12:22, Robert Engels wrote:
>>
>> That is not true. Go routines do not ?clean up? when they cannot make
>> progress due to no producers. Go leaks due to this are very common.
>>
>> On Jan 12, 2026, at 4:05?AM, Alex Otenko <oleksandr.otenko at gmail.com>
>> <oleksandr.otenko at gmail.com> wrote:
>>
>> ?
>> I'd say it's not even clear why that'd constitute a bug. Whole systems
>> are built on go-rourines and continuations getting GCed.
>>
>> I think there certainly is a clash between the need to track life cycle
>> of something (tell threads to terminate) in a system where life cycle of
>> things is not tracked (because GC).
>>
>> On Mon, 12 Jan 2026, 09:58 Viktor Klang, <viktor.klang at oracle.com> wrote:
>>
>>> How do you find the bug?
>>>
>>> On 2026-01-12 05:36, robert engels wrote:
>>> > Why not just fix your design to ensure the proper behavior?
>>>
>>> --
>>> Cheers,
>>> ?
>>>
>>>
>>> Viktor Klang
>>> Software Architect, Java Platform Group
>>> Oracle
>>>
>>> --
>> Cheers,
>> ?
>>
>>
>> Viktor Klang
>> Software Architect, Java Platform Group
>> Oracle
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260113/3c982e5f/attachment.htm>

From alan.bateman at oracle.com  Tue Jan 13 08:00:25 2026
From: alan.bateman at oracle.com (Alan Bateman)
Date: Tue, 13 Jan 2026 08:00:25 +0000
Subject: [External] : Re: Ephemeral threads
In-Reply-To: <CANkgWKj34NoSTtk5THOc_i6hOkXNwO5LuJMSE43DWFTf-X01Lg@mail.gmail.com>
References: <CANkgWKiL3U_4-H3oy002+uXwC6m-XsYe+C-TS8rcisJDyNWJQA@mail.gmail.com>
 <2BC7AC23-83CA-40D5-95DE-35E8471EB656@ix.netcom.com>
 <4f9b2ac9-db35-4a32-9d78-ef32c4660cca@oracle.com>
 <CANkgWKj34NoSTtk5THOc_i6hOkXNwO5LuJMSE43DWFTf-X01Lg@mail.gmail.com>
Message-ID: <adb3b75e-fbb5-488b-bead-c31521a38f24@oracle.com>



On 13/01/2026 06:42, Alex Otenko wrote:
>
> I think there are plenty of designs with generators, iterators and 
> async where non-termination is not a bug.

That is true is some other languages/runtimes. If Java were to add 
generators or some other exotic control flow in the future then there 
would be more spooky issues to work through, some of which overlap with 
the spooky issues that have come up in the discussion here.

-Alan

From oleksandr.otenko at gmail.com  Tue Jan 13 09:28:13 2026
From: oleksandr.otenko at gmail.com (Alex Otenko)
Date: Tue, 13 Jan 2026 09:28:13 +0000
Subject: [External] : Re: Ephemeral threads
In-Reply-To: <adb3b75e-fbb5-488b-bead-c31521a38f24@oracle.com>
References: <CANkgWKiL3U_4-H3oy002+uXwC6m-XsYe+C-TS8rcisJDyNWJQA@mail.gmail.com>
 <2BC7AC23-83CA-40D5-95DE-35E8471EB656@ix.netcom.com>
 <4f9b2ac9-db35-4a32-9d78-ef32c4660cca@oracle.com>
 <CANkgWKj34NoSTtk5THOc_i6hOkXNwO5LuJMSE43DWFTf-X01Lg@mail.gmail.com>
 <adb3b75e-fbb5-488b-bead-c31521a38f24@oracle.com>
Message-ID: <CANkgWKiqy8-8eZoevF1XnJRnUZk+CqNYP1K=c1K+4bTyFKFbiQ@mail.gmail.com>

Yes, I understand that now that's not easy to do in Java. I just don't
think it's all that exotic, and certainly not a bug. After all, we've all
written at least one iterator when we did a coding interview.

There is 1:1 correspondence between the iterators and the generators. So if
we can GC the iterators without special dance, we should be able to do that
for the generators. You could see an iterator as an explicit declaration
that you are not going to use any features that rely on there being a
finally - no unlocking, no resource management outside of what a finalizer
can achieve, no peer to coordinate with, etc. Likewise an explicit
declaration by an engineer that this here piece of code entering a wait is
perfectly fine to GC, doesn't seem all that different.

Yes, in general there are thread semantics, try-finally, reference loops
and other obstacles - but we don't need to solve a general case, just the
one that is in 1:1 correspondence with the iterators.

I understand that there may be safe ways to implement the same with the
existing mechanisms - like, the user of the generator might wrap the
interaction in a try-with-resource, and that way control the lifecycle
explicitly.

On Tue, 13 Jan 2026, 08:00 Alan Bateman, <alan.bateman at oracle.com> wrote:

>
>
> On 13/01/2026 06:42, Alex Otenko wrote:
> >
> > I think there are plenty of designs with generators, iterators and
> > async where non-termination is not a bug.
>
> That is true is some other languages/runtimes. If Java were to add
> generators or some other exotic control flow in the future then there
> would be more spooky issues to work through, some of which overlap with
> the spooky issues that have come up in the discussion here.
>
> -Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260113/799e8900/attachment.htm>

From forax at univ-mlv.fr  Tue Jan 13 10:13:19 2026
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 13 Jan 2026 11:13:19 +0100 (CET)
Subject: [External] : Re: Ephemeral threads
In-Reply-To: <adb3b75e-fbb5-488b-bead-c31521a38f24@oracle.com>
References: <CANkgWKiL3U_4-H3oy002+uXwC6m-XsYe+C-TS8rcisJDyNWJQA@mail.gmail.com>
 <2BC7AC23-83CA-40D5-95DE-35E8471EB656@ix.netcom.com>
 <4f9b2ac9-db35-4a32-9d78-ef32c4660cca@oracle.com>
 <CANkgWKj34NoSTtk5THOc_i6hOkXNwO5LuJMSE43DWFTf-X01Lg@mail.gmail.com>
 <adb3b75e-fbb5-488b-bead-c31521a38f24@oracle.com>
Message-ID: <2111937546.13899793.1768299199908.JavaMail.zimbra@univ-eiffel.fr>

While it makes sense to see Java coroutine as Thread, it makes less sense to see generators as Thread.

So if we introduce generators, we will use a different mechanism than virtual threads,
so the expectations are not the same, so most of the spooky issues discuss here do not exist.

R?mi

----- Original Message -----
> From: "Alan Bateman" <alan.bateman at oracle.com>
> To: "Alex Otenko" <oleksandr.otenko at gmail.com>
> Cc: "loom-dev" <loom-dev at openjdk.org>
> Sent: Tuesday, January 13, 2026 9:00:25 AM
> Subject: Re: [External] : Re: Ephemeral threads

> On 13/01/2026 06:42, Alex Otenko wrote:
>>
>> I think there are plenty of designs with generators, iterators and
>> async where non-termination is not a bug.
> 
> That is true is some other languages/runtimes. If Java were to add
> generators or some other exotic control flow in the future then there
> would be more spooky issues to work through, some of which overlap with
> the spooky issues that have come up in the discussion here.
> 
> -Alan

From forax at univ-mlv.fr  Tue Jan 13 10:17:13 2026
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 13 Jan 2026 11:17:13 +0100 (CET)
Subject: [External] : Re: Ephemeral threads
In-Reply-To: <CANkgWKiqy8-8eZoevF1XnJRnUZk+CqNYP1K=c1K+4bTyFKFbiQ@mail.gmail.com>
References: <CANkgWKiL3U_4-H3oy002+uXwC6m-XsYe+C-TS8rcisJDyNWJQA@mail.gmail.com>
 <2BC7AC23-83CA-40D5-95DE-35E8471EB656@ix.netcom.com>
 <4f9b2ac9-db35-4a32-9d78-ef32c4660cca@oracle.com>
 <CANkgWKj34NoSTtk5THOc_i6hOkXNwO5LuJMSE43DWFTf-X01Lg@mail.gmail.com>
 <adb3b75e-fbb5-488b-bead-c31521a38f24@oracle.com>
 <CANkgWKiqy8-8eZoevF1XnJRnUZk+CqNYP1K=c1K+4bTyFKFbiQ@mail.gmail.com>
Message-ID: <589436274.13902990.1768299433698.JavaMail.zimbra@univ-eiffel.fr>

It starts to be off topic, 
but it's not clear to me that in Java we want to map a generator to an iterator and not to stream (a push iterator with a cleanup semantics). 

regards, 
R?mi 

> From: "Alex Otenko" <oleksandr.otenko at gmail.com>
> To: "Alan Bateman" <alan.bateman at oracle.com>
> Cc: "loom-dev" <loom-dev at openjdk.org>
> Sent: Tuesday, January 13, 2026 10:28:13 AM
> Subject: Re: [External] : Re: Ephemeral threads

> Yes, I understand that now that's not easy to do in Java. I just don't think
> it's all that exotic, and certainly not a bug. After all, we've all written at
> least one iterator when we did a coding interview.

> There is 1:1 correspondence between the iterators and the generators. So if we
> can GC the iterators without special dance, we should be able to do that for
> the generators. You could see an iterator as an explicit declaration that you
> are not going to use any features that rely on there being a finally - no
> unlocking, no resource management outside of what a finalizer can achieve, no
> peer to coordinate with, etc. Likewise an explicit declaration by an engineer
> that this here piece of code entering a wait is perfectly fine to GC, doesn't
> seem all that different.

> Yes, in general there are thread semantics, try-finally, reference loops and
> other obstacles - but we don't need to solve a general case, just the one that
> is in 1:1 correspondence with the iterators.

> I understand that there may be safe ways to implement the same with the existing
> mechanisms - like, the user of the generator might wrap the interaction in a
> try-with-resource, and that way control the lifecycle explicitly.

> On Tue, 13 Jan 2026, 08:00 Alan Bateman, < [ mailto:alan.bateman at oracle.com |
> alan.bateman at oracle.com ] > wrote:

>> On 13/01/2026 06:42, Alex Otenko wrote:

>> > I think there are plenty of designs with generators, iterators and
>> > async where non-termination is not a bug.

>> That is true is some other languages/runtimes. If Java were to add
>> generators or some other exotic control flow in the future then there
>> would be more spooky issues to work through, some of which overlap with
>> the spooky issues that have come up in the discussion here.

>> -Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260113/73ade446/attachment-0001.htm>

From aph at redhat.com  Tue Jan 13 11:05:46 2026
From: aph at redhat.com (Andrew Haley)
Date: Tue, 13 Jan 2026 11:05:46 +0000
Subject: [External] : Re: Ephemeral threads
In-Reply-To: <CAEYHehiiZw32z71DggH2NZWpqPqUXUL6nWDy=OyN-huxnFHH+w@mail.gmail.com>
References: <CANkgWKiL3U_4-H3oy002+uXwC6m-XsYe+C-TS8rcisJDyNWJQA@mail.gmail.com>
 <2BC7AC23-83CA-40D5-95DE-35E8471EB656@ix.netcom.com>
 <4f9b2ac9-db35-4a32-9d78-ef32c4660cca@oracle.com>
 <CANkgWKj34NoSTtk5THOc_i6hOkXNwO5LuJMSE43DWFTf-X01Lg@mail.gmail.com>
 <CAEYHehiiZw32z71DggH2NZWpqPqUXUL6nWDy=OyN-huxnFHH+w@mail.gmail.com>
Message-ID: <a6e21633-f039-4615-a7fc-b29d4f74097e@redhat.com>

On 13/01/2026 07:45, Michael van Acken wrote:
> Am Di., 13. Jan. 2026 um 07:42 Uhr schrieb Alex Otenko <
> oleksandr.otenko at gmail.com>:
> 
>> Oh, ok, I confused it with something else. I recall dealing with a system
>> that would panic or report that there were fibers that were no longer going
>> to make progress.
>>
>> I think there are plenty of designs with generators, iterators and async
>> where non-termination is not a bug.
> 
> I have been thinking about this as well, what the difference between
> various perspectives/designs actually is.
> 
> My first and up to now only idea: a thread comes with hard promises about
> what things will happen in the future.
> 
> Its accumulated call/handler stack is a batch of unfinished business that
> is guaranteed to be worked upon.

That would be a major change to Java. People tend to assume that threads 
will make progress "eventually", but there can be no guarantees.

As Gil Tene wonderfully put it,

"If a system MUST be non-blocking, it should probably not be on the JVM, 
OS, Hypervisor, Hardware-that-uses-Power-management, 
Hardware-that-does-ECC, etc. Basically, non-blocking (systems) as 
opposed to algorithms or sets of threads only exit on paper, in the 
sense that if you have a system that MUST be non-blocking (as a system), 
you probably need to execute it on paper... ;-)"

I'm not absolutely certain if the rules about "premature collection" 
permit a thread to be garbage collected along with its referents before 
that thread is exited. JLS 12.6.2, Interaction with the Memory Model, 
says that once an object X is not _reachable_ it may be collected, then 
goes on to describe "All active uses of X in thread t that come after..."

I'd assume that if thread t is not reachable, and t is only thread that 
refers to X, then there are no active uses of X, and therefore X is not 
reachable, and so collection of X (and all that implies) is legal.

But we're not only talking about theoretical issues here, but also the 
principle of least astonishment.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From alan.bateman at oracle.com  Tue Jan 13 12:34:45 2026
From: alan.bateman at oracle.com (Alan Bateman)
Date: Tue, 13 Jan 2026 12:34:45 +0000
Subject: [External] : Re: Ephemeral threads
In-Reply-To: <2111937546.13899793.1768299199908.JavaMail.zimbra@univ-eiffel.fr>
References: <CANkgWKiL3U_4-H3oy002+uXwC6m-XsYe+C-TS8rcisJDyNWJQA@mail.gmail.com>
 <2BC7AC23-83CA-40D5-95DE-35E8471EB656@ix.netcom.com>
 <4f9b2ac9-db35-4a32-9d78-ef32c4660cca@oracle.com>
 <CANkgWKj34NoSTtk5THOc_i6hOkXNwO5LuJMSE43DWFTf-X01Lg@mail.gmail.com>
 <adb3b75e-fbb5-488b-bead-c31521a38f24@oracle.com>
 <2111937546.13899793.1768299199908.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <5c7fd9c9-a4c3-4998-b9b5-1506e80d99b8@oracle.com>



On 13/01/2026 10:13, Remi Forax wrote:
> While it makes sense to see Java coroutine as Thread, it makes less sense to see generators as Thread.
>
> So if we introduce generators, we will use a different mechanism than virtual threads,
> so the expectations are not the same, so most of the spooky issues discuss here do not exist.

We are getting a bit off topic but we can't be too dismissive of the 
spooky issues that would go with the control flow of generators. Even if 
implemented on delimited continuations, and even if thread confined, 
there are a bunch of related to reachability and breaking structure. 
There's enough there to keep a market for Ghostbuster proton packs going 
for a few years.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260113/235a6f47/attachment.htm>

From michael.van.acken at gmail.com  Tue Jan 13 12:35:18 2026
From: michael.van.acken at gmail.com (Michael van Acken)
Date: Tue, 13 Jan 2026 13:35:18 +0100
Subject: [External] : Re: Ephemeral threads
In-Reply-To: <a6e21633-f039-4615-a7fc-b29d4f74097e@redhat.com>
References: <CANkgWKiL3U_4-H3oy002+uXwC6m-XsYe+C-TS8rcisJDyNWJQA@mail.gmail.com>
 <2BC7AC23-83CA-40D5-95DE-35E8471EB656@ix.netcom.com>
 <4f9b2ac9-db35-4a32-9d78-ef32c4660cca@oracle.com>
 <CANkgWKj34NoSTtk5THOc_i6hOkXNwO5LuJMSE43DWFTf-X01Lg@mail.gmail.com>
 <CAEYHehiiZw32z71DggH2NZWpqPqUXUL6nWDy=OyN-huxnFHH+w@mail.gmail.com>
 <a6e21633-f039-4615-a7fc-b29d4f74097e@redhat.com>
Message-ID: <CAEYHehh-oWLWEs4Tjq=2vgpus15oaa28P5iCgt_yGXi1=WFGOA@mail.gmail.com>

Am Di., 13. Jan. 2026 um 12:06 Uhr schrieb Andrew Haley <aph at redhat.com>:

> On 13/01/2026 07:45, Michael van Acken wrote:
> [...]
> > I have been thinking about this as well, what the difference between
> > various perspectives/designs actually is.
> >
> > My first and up to now only idea: a thread comes with hard promises about
> > what things will happen in the future.
> >
> > Its accumulated call/handler stack is a batch of unfinished business that
> > is guaranteed to be worked upon.
>
> That would be a major change to Java. People tend to assume that threads
> will make progress "eventually", but there can be no guarantees.


Thank you for pointing this out.  It made me aware just how much my
thinking is predicated around the idea that a method call does complete
in either of two ways.  Of course, even a simple endless loop prevents
completion, nor is there any guarantee that it happens before JVM exit.

Non-completion comes to my mind usually in the negative "How do I prevent
this piece of code from ending up not completing?" (trying to avoid
anticipated
future pain), or from trying to find out why something unexpectedly hangs.
In the
latter case I am grateful for any support the JVM gives me to narrow the
problem
down, closing the circle to the observability mechanisms mentioned earlier
in this
thread.

Up to now, a method call not completing is for me either something that
should
be avoided or is an abnormal program condition.  Actively embracing this in
places
other than e.g. a thread's top-level method would require some adjustment
on my part.

-- mva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260113/a2c5a0db/attachment-0001.htm>

From rengels at ix.netcom.com  Tue Jan 13 13:43:22 2026
From: rengels at ix.netcom.com (Robert Engels)
Date: Tue, 13 Jan 2026 07:43:22 -0600
Subject: [External] : Re: Ephemeral threads
In-Reply-To: <CAEYHehh-oWLWEs4Tjq=2vgpus15oaa28P5iCgt_yGXi1=WFGOA@mail.gmail.com>
References: <CAEYHehh-oWLWEs4Tjq=2vgpus15oaa28P5iCgt_yGXi1=WFGOA@mail.gmail.com>
Message-ID: <42F7E9DD-9FF1-4003-8C1B-0164E9E3666F@ix.netcom.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260113/f6b14b70/attachment.htm>

From aph at redhat.com  Tue Jan 13 13:44:30 2026
From: aph at redhat.com (Andrew Haley)
Date: Tue, 13 Jan 2026 13:44:30 +0000
Subject: [External] : Re: Ephemeral threads
In-Reply-To: <CAEYHehh-oWLWEs4Tjq=2vgpus15oaa28P5iCgt_yGXi1=WFGOA@mail.gmail.com>
References: <CANkgWKiL3U_4-H3oy002+uXwC6m-XsYe+C-TS8rcisJDyNWJQA@mail.gmail.com>
 <2BC7AC23-83CA-40D5-95DE-35E8471EB656@ix.netcom.com>
 <4f9b2ac9-db35-4a32-9d78-ef32c4660cca@oracle.com>
 <CANkgWKj34NoSTtk5THOc_i6hOkXNwO5LuJMSE43DWFTf-X01Lg@mail.gmail.com>
 <CAEYHehiiZw32z71DggH2NZWpqPqUXUL6nWDy=OyN-huxnFHH+w@mail.gmail.com>
 <a6e21633-f039-4615-a7fc-b29d4f74097e@redhat.com>
 <CAEYHehh-oWLWEs4Tjq=2vgpus15oaa28P5iCgt_yGXi1=WFGOA@mail.gmail.com>
Message-ID: <429bd244-8586-4192-a757-ccc3b1b54b04@redhat.com>

On 13/01/2026 12:35, Michael van Acken wrote:
> Up to now, a method call not completing is for me either something that should
> be avoided or is an abnormal program condition.

No disagreement there! But that's a "should" rather than a "shall", and 
"should"s have no place in a language specification.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From viktor.klang at oracle.com  Tue Jan 13 14:25:40 2026
From: viktor.klang at oracle.com (Viktor Klang)
Date: Tue, 13 Jan 2026 15:25:40 +0100
Subject: [External] : Re: Ephemeral threads
In-Reply-To: <42F7E9DD-9FF1-4003-8C1B-0164E9E3666F@ix.netcom.com>
References: <CAEYHehh-oWLWEs4Tjq=2vgpus15oaa28P5iCgt_yGXi1=WFGOA@mail.gmail.com>
 <42F7E9DD-9FF1-4003-8C1B-0164E9E3666F@ix.netcom.com>
Message-ID: <9017aa27-a26d-43c3-af0e-21600b797942@oracle.com>

I could see that there could be problems with "forcibly"-closing such 
generators if generation is stuck on, let's say a stdin read() and the 
user of the generator throws the generator away?which would leave the 
generator stuck waiting on the read, or let it time out, before it is 
reclaimed.

In such situations what often happens is that you split the 
responsibility for detecting and disposing to a third party (a thread), 
and now you've re-implemented finalization (or some variant thereof)...

On 2026-01-13 14:43, Robert Engels wrote:
> Related, there are no changes needed to Java to implement efficient 
> generators using virtual threads. See https://github.com/robaho/generators
>
>> On Jan 13, 2026, at 6:35?AM, Michael van Acken 
>> <michael.van.acken at gmail.com> wrote:
>>
>> ?
>> Am Di., 13. Jan. 2026 um 12:06?Uhr schrieb Andrew Haley <aph at redhat.com>:
>>
>>     On 13/01/2026 07:45, Michael van Acken wrote:
>>     [...]
>>     > I have been thinking about this as well, what the difference
>>     between
>>     > various perspectives/designs actually is.
>>     >
>>     > My first and up to now only idea: a thread comes with hard
>>     promises about
>>     > what things will happen in the future.
>>     >
>>     > Its accumulated call/handler stack is a batch of unfinished
>>     business that
>>     > is guaranteed to be worked upon.
>>
>>     That would be a major change to Java. People tend to assume that
>>     threads
>>     will make progress "eventually", but there can be no guarantees.
>>
>>
>> Thank you for pointing this out.? It made me aware just how much my
>> thinking is predicated around the idea that a method call does complete
>> in either of two ways.? Of course, even a simple endless loop prevents
>> completion, nor is there any guarantee that it happens before JVM exit.
>>
>> Non-completion comes to my mind usually in the negative "How do I prevent
>> this piece of code from ending up not completing?" (trying to avoid 
>> anticipated
>> future pain), or from trying to find out why something unexpectedly 
>> hangs.? In the
>> latter case I am grateful for any support the JVM gives me to narrow 
>> the problem
>> down, closing the circle to the observability mechanisms mentioned 
>> earlier in this
>> thread.
>>
>> Up to now, a method call not completing is for me either something 
>> that should
>> be avoided or is an abnormal program condition. Actively embracing 
>> this in places
>> other than e.g. a thread's top-level method would require some 
>> adjustment on my part.
>>
>> -- mva
>>
-- 
Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260113/b9530aec/attachment-0001.htm>

From rengels at ix.netcom.com  Tue Jan 13 14:45:25 2026
From: rengels at ix.netcom.com (Robert Engels)
Date: Tue, 13 Jan 2026 08:45:25 -0600
Subject: [External] : Re: Ephemeral threads
In-Reply-To: <9017aa27-a26d-43c3-af0e-21600b797942@oracle.com>
References: <9017aa27-a26d-43c3-af0e-21600b797942@oracle.com>
Message-ID: <B192FE7D-6822-45FD-8D68-305FBC781AB2@ix.netcom.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260113/51ebe360/attachment.htm>

From duke at openjdk.org  Wed Jan 14 19:12:28 2026
From: duke at openjdk.org (duke)
Date: Wed, 14 Jan 2026 19:12:28 GMT
Subject: git: openjdk/loom: fibers: 45 new changesets
Message-ID: <4613804d-c6b4-4736-89c7-d8d9c39775d2@openjdk.org>

Changeset: 33689485
Branch: fibers
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2026-01-11 20:37:04 +0000
URL:       https://git.openjdk.org/loom/commit/336894857bfc9f610da55e6180dd7b668bf67752

8374878: Add Atomic<T>::compare_set

Reviewed-by: kbarrett, stefank

! src/hotspot/share/gc/shared/oopStorage.cpp
! src/hotspot/share/gc/shared/pretouchTask.cpp
! src/hotspot/share/gc/shared/taskqueue.hpp
! src/hotspot/share/gc/shared/taskqueue.inline.hpp
! src/hotspot/share/runtime/atomic.hpp
! src/hotspot/share/utilities/concurrentHashTable.inline.hpp
! src/hotspot/share/utilities/waitBarrier_generic.cpp
! test/hotspot/gtest/runtime/test_atomic.cpp

Changeset: 669977f7
Branch: fibers
Author:    Trevor Bond <trevorkbond at gmail.com>
Committer: Adam Sotona <asotona at openjdk.org>
Date:      2026-01-12 07:05:52 +0000
URL:       https://git.openjdk.org/loom/commit/669977f7c4b58ab4901a340906262ab907b3ffb6

8341272: Factory to create wide iinc instruction with small arguments

Reviewed-by: liach, asotona

! src/java.base/share/classes/java/lang/classfile/instruction/IncrementInstruction.java
! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractInstruction.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BytecodeHelpers.java
! test/jdk/jdk/classfile/InstructionValidationTest.java

Changeset: 7cf7f01f
Branch: fibers
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2026-01-12 07:46:25 +0000
URL:       https://git.openjdk.org/loom/commit/7cf7f01fb339bf3c5b81d946be8afa71ec267e42

8374875: Improve perfMemory warning about 'Insufficient space for shared memory file'

Reviewed-by: lucy, mdoerr, clanger

! src/hotspot/os/posix/perfMemory_posix.cpp

Changeset: 49040462
Branch: fibers
Author:    Beno?t Maillard <bmaillard at openjdk.org>
Date:      2026-01-12 07:59:37 +0000
URL:       https://git.openjdk.org/loom/commit/49040462f3d2761435cded1bd8898d0c6b16fc02

8372302: C2: IGVN verification fails because ModXNode::Ideal creates unused intermediate nodes

Reviewed-by: epeter, qamai

! src/hotspot/share/opto/divnode.cpp
+ test/hotspot/jtreg/compiler/c2/igvn/TestModIdealCreatesUselessNode.java

Changeset: 133a023e
Branch: fibers
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2026-01-12 08:04:14 +0000
URL:       https://git.openjdk.org/loom/commit/133a023e8e1ec1c555265a92eb0fcb4965f0b162

8374471: Check bin and lib folder of JDK image for unwanted files

Reviewed-by: erikj, clanger

+ test/jdk/build/CheckFiles.java

Changeset: fb13abef
Branch: fibers
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-12 08:26:10 +0000
URL:       https://git.openjdk.org/loom/commit/fb13abef44d535ebc4535921fd4eb0f285030465

8374743: G1 starts a concurrent mark when allocating humongous objects during initialization

Co-authored-by: Erik ?sterlund <eosterlund at openjdk.org>
Reviewed-by: eosterlund, iwalulya, sjohanss, shade

! src/hotspot/share/gc/g1/g1CollectedHeap.cpp

Changeset: d0aae04d
Branch: fibers
Author:    Johan Sj?len <jsjolen at openjdk.org>
Date:      2026-01-12 11:01:12 +0000
URL:       https://git.openjdk.org/loom/commit/d0aae04d61c90698ab5a01b4389dc6932de63cb7

8325108: POSIX map_memory_to_file calls release_memory unnecessarily

Reviewed-by: dholmes, coleenp

! src/hotspot/os/posix/os_posix.cpp

Changeset: 2fbe4755
Branch: fibers
Author:    Emanuel Peter <epeter at openjdk.org>
Date:      2026-01-12 11:18:28 +0000
URL:       https://git.openjdk.org/loom/commit/2fbe47559e9ba45306bd08c3636647f865a75abd

8374785: Template Library: need to tag Float16.copySign as having non-deterministic result because of multiple NaNs with different sign bits

Reviewed-by: thartmann, qamai

! test/hotspot/jtreg/compiler/lib/template_framework/library/Operations.java

Changeset: 556bddfd
Branch: fibers
Author:    Erik Gahlin <egahlin at openjdk.org>
Date:      2026-01-12 11:30:43 +0000
URL:       https://git.openjdk.org/loom/commit/556bddfd9439d1bad698ab5134317ce263a36b04

8372321: TestBackToBackSensitive fails intermittently after JDK-8365972

Reviewed-by: mgronlun

! test/jdk/jdk/jfr/event/runtime/TestBackToBackSensitive.java

Changeset: d433ce52
Branch: fibers
Author:    Liam Miller-Cushon <cushon at openjdk.org>
Date:      2026-01-12 15:22:42 +0000
URL:       https://git.openjdk.org/loom/commit/d433ce52360994be5a88a0bcbf39cbb741b435ec

8369564: Provide a MemorySegment API to read strings with known lengths

Co-authored-by: Per Minborg <pminborg at openjdk.org>
Reviewed-by: jvernee, mcimadamore

! src/java.base/share/classes/java/lang/String.java
! src/java.base/share/classes/java/lang/System.java
! src/java.base/share/classes/java/lang/foreign/MemorySegment.java
! src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java
! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java
! src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java
! src/java.base/share/classes/jdk/internal/foreign/StringSupport.java
! test/jdk/java/foreign/TestStringEncoding.java
+ test/micro/org/openjdk/bench/java/lang/foreign/FromJavaStringTest.java
! test/micro/org/openjdk/bench/java/lang/foreign/ToJavaStringTest.java

Changeset: 9a2592f8
Branch: fibers
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2026-01-12 19:41:21 +0000
URL:       https://git.openjdk.org/loom/commit/9a2592f8d2177f1480758e94faf9b986c7bba681

8374953: Add note on about implicit state when comparing TypeMirrors

Reviewed-by: attila, vromero, jlahoda

! src/java.compiler/share/classes/javax/lang/model/type/TypeMirror.java
! src/java.compiler/share/classes/javax/lang/model/util/Types.java

Changeset: 15b7a425
Branch: fibers
Author:    William Kemper <wkemper at openjdk.org>
Date:      2026-01-12 23:36:26 +0000
URL:       https://git.openjdk.org/loom/commit/15b7a4252b8d3595b7bc409e20d4c617e89240e8

8373819: Genshen: Control thread can miss allocation failure notification (redux)

Reviewed-by: kdnilsen, ysr

! src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.cpp
! src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.hpp
! src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.hpp
! src/hotspot/share/gc/shenandoah/shenandoahRegulatorThread.cpp

Changeset: e89c1290
Branch: fibers
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2026-01-13 01:29:20 +0000
URL:       https://git.openjdk.org/loom/commit/e89c1290ca8b3e07bef12f4c0465c3e83389fef4

8374181: failure_handler: The cores.html file is formatted incorrectly and so hides the core dump information

Reviewed-by: erikj

! test/failure_handler/src/share/classes/jdk/test/failurehandler/jtreg/GatherDiagnosticInfoObserver.java

Changeset: 0b9d4c02
Branch: fibers
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2026-01-13 04:29:12 +0000
URL:       https://git.openjdk.org/loom/commit/0b9d4c02e39191e9dba721115f422e28ee5b9869

4765299: componentResized() not always called with nested JSplitPanes

Reviewed-by: tr, kizune

! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicSplitPaneUI.java
+ test/jdk/javax/swing/JSplitPane/TestSplitPaneCompResize.java

Changeset: f4ebf958
Branch: fibers
Author:    David Holmes <dholmes at openjdk.org>
Date:      2026-01-13 06:02:01 +0000
URL:       https://git.openjdk.org/loom/commit/f4ebf9585f63177584d8c48838ef793407ebce12

8370314: Update signals_posix with new Linux signal codes

Reviewed-by: shade, jwaters

! src/hotspot/os/posix/signals_posix.cpp

Changeset: 586846b8
Branch: fibers
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2026-01-13 06:49:04 +0000
URL:       https://git.openjdk.org/loom/commit/586846b84a38d285c5905437e903cfc57f609410

8374450: GTest opto.canonicalize_constraints cannot run without VM

Reviewed-by: qamai, thartmann, shade

! test/hotspot/gtest/opto/test_rangeinference.cpp

Changeset: c000343b
Branch: fibers
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2026-01-13 07:30:13 +0000
URL:       https://git.openjdk.org/loom/commit/c000343bbb1d822d2cee37e1a27672cfb3128bee

8374876: Epsilon: Convert to use Atomic<T>

Reviewed-by: tschatzl, stefank

! src/hotspot/share/gc/epsilon/epsilonHeap.cpp
! src/hotspot/share/gc/epsilon/epsilonHeap.hpp
! src/hotspot/share/gc/epsilon/epsilonMonitoringSupport.cpp
! src/hotspot/share/gc/epsilon/epsilonMonitoringSupport.hpp

Changeset: d6f43d73
Branch: fibers
Author:    Liam Miller-Cushon <cushon at openjdk.org>
Date:      2026-01-13 08:05:57 +0000
URL:       https://git.openjdk.org/loom/commit/d6f43d7329bf0ba08464f6d0a22de7e27ca8b399

8375066: Test tools/sincechecker/modules/java.base/JavaBaseCheckSince.java broken by JDK-8369564

Reviewed-by: jpai, shade

! src/java.base/share/classes/java/lang/foreign/MemorySegment.java
! src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java

Changeset: 578204f8
Branch: fibers
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2026-01-13 08:12:35 +0000
URL:       https://git.openjdk.org/loom/commit/578204f8c49f06be8b9c4855359ca61c9e107678

8374379: Type annotation in new array dimension expression causes java.lang.AssertionError

Reviewed-by: vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java
! test/langtools/tools/javac/annotations/typeAnnotations/classfile/TestNewCastArray.java

Changeset: 543a9722
Branch: fibers
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
Date:      2026-01-13 11:44:32 +0000
URL:       https://git.openjdk.org/loom/commit/543a972222118155e4c72c6f2d32d154c5dfd442

8373485: JFR Crash during sampling:  assert(jt->has_last_Java_frame()) failed: invariant

Reviewed-by: shade, egahlin

! src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp

Changeset: a90c7eee
Branch: fibers
Author:    Quan Anh Mai <qamai at openjdk.org>
Date:      2026-01-13 12:42:25 +0000
URL:       https://git.openjdk.org/loom/commit/a90c7eee6f7e950edea4d94cf2b109fdb5e49909

8374969: Incorrect results of LoadStoreNode::adr_type and SCMemProj::adr_type

Reviewed-by: roland, mhaessig

! src/hotspot/share/opto/memnode.cpp
! src/hotspot/share/opto/memnode.hpp

Changeset: f7be1dcf
Branch: fibers
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
Date:      2026-01-13 13:33:41 +0000
URL:       https://git.openjdk.org/loom/commit/f7be1dcf296d28f8e004d180038ab715153a6c15

8375054: Removed "signed" property from jpackage app image file

Reviewed-by: almatvee

! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/AppImageSigner.java
- src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacBundle.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacFromOptions.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacPackagingPipeline.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/model/MacApplication.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/OptionSpecBuilder.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardAppImageFileOption.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardOption.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardValidator.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/Validator.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources.properties
+ src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/MacBundle.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/AppImageFile.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/helpers/jdk/jpackage/test/MacSignVerify.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/AppImageFileTest.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/TestUtils.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/ValidatorTest.java
! test/jdk/tools/jpackage/share/AppImagePackageTest.java
! test/jdk/tools/jpackage/share/ErrorTest.java

Changeset: 47029ccf
Branch: fibers
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
Date:      2026-01-13 13:36:44 +0000
URL:       https://git.openjdk.org/loom/commit/47029ccfec988e0a9298e35dcc729d9eeffc45e1

8375050: Simplify process management in jpackage tests

Reviewed-by: almatvee

! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/Executor.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/HelloApp.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/WindowsHelper.java
! test/jdk/tools/jpackage/macosx/ArgumentsFilteringTest.java
! test/jdk/tools/jpackage/share/MainClassTest.java
! test/jdk/tools/jpackage/windows/Win8301247Test.java
! test/jdk/tools/jpackage/windows/WinChildProcessTest.java
! test/jdk/tools/jpackage/windows/WinNoRestartTest.java

Changeset: 7330e1a9
Branch: fibers
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2026-01-13 13:51:00 +0000
URL:       https://git.openjdk.org/loom/commit/7330e1a996fd43d92430a73b818f33552bc6ae9c

8374990: Check include and jmods folder of JDK image for unwanted files

Reviewed-by: erikj

! test/jdk/build/CheckFiles.java

Changeset: 49f72658
Branch: fibers
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2026-01-13 13:54:04 +0000
URL:       https://git.openjdk.org/loom/commit/49f7265894652ea243f3a531cf3f9d0b06e53565

8374872: Cleanup outdated SAP AG copyright header info

Reviewed-by: clanger, mdoerr

! test/hotspot/jtreg/runtime/exceptionMsgs/IllegalAccessError/IAE78_A.java
! test/hotspot/jtreg/runtime/exceptionMsgs/IllegalAccessError/IAE_Loader2.java
! test/hotspot/jtreg/runtime/execstack/Test.java
! test/hotspot/jtreg/runtime/execstack/TestMT.java
! test/hotspot/jtreg/runtime/execstack/libtest-rw.c
! test/hotspot/jtreg/runtime/execstack/libtest-rwx.c

Changeset: 45990d79
Branch: fibers
Author:    Volodymyr Paprotski <vpaprotski at openjdk.org>
Date:      2026-01-13 15:15:36 +0000
URL:       https://git.openjdk.org/loom/commit/45990d796ffafc228c6e843049c80aefedb0f12b

8374570: Assertion failure in ClearArray.java  with -XX:+EnableX86EcoreOpts

Reviewed-by: thartmann, epeter, qamai

! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! test/hotspot/jtreg/compiler/c2/ClearArray.java

Changeset: 7f707ba8
Branch: fibers
Author:    Damon Nguyen <dnguyen at openjdk.org>
Date:      2026-01-13 16:55:03 +0000
URL:       https://git.openjdk.org/loom/commit/7f707ba8e746d859ac171d71ef8f731953a92e6a

8373727: New XBM images parser regression: only the first line of the bitmap array is parsed

Reviewed-by: prr, jdv

! src/java.desktop/share/classes/sun/awt/image/XbmImageDecoder.java
! test/jdk/java/awt/image/XBMDecoder/XBMDecoderTest.java
+ test/jdk/java/awt/image/XBMDecoder/invalid_empty.xbm
! test/jdk/java/awt/image/XBMDecoder/invalid_hex.xbm
+ test/jdk/java/awt/image/XBMDecoder/invalid_plus.xbm
+ test/jdk/java/awt/image/XBMDecoder/valid_multiline.xbm

Changeset: 07403843
Branch: fibers
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2026-01-13 16:57:30 +0000
URL:       https://git.openjdk.org/loom/commit/074038438f5b8b91e9390430b4fa58ff53e5df26

8374727: Audio configuration Platform class - use nio for getting endianness of the underlying platform

Reviewed-by: prr, kizune

! src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_PCM.cpp
! src/java.desktop/share/classes/com/sun/media/sound/Platform.java
- src/java.desktop/share/native/libjsound/Platform.c
! src/java.desktop/share/native/libjsound/Utilities.c
! src/java.desktop/share/native/libjsound/Utilities.h

Changeset: f23752a7
Branch: fibers
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
Date:      2026-01-13 18:06:04 +0000
URL:       https://git.openjdk.org/loom/commit/f23752a75ee3d3af0853eff9c678d2496bb1cf58

8371014: Dump JFR recording on CrashOnOutOfMemoryError is incorrectly implemented

Reviewed-by: ysuenaga

! src/hotspot/share/jfr/jfr.cpp
! src/hotspot/share/jfr/jfr.hpp
! src/hotspot/share/jfr/jni/jfrJniMethod.cpp
! src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp
! src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.hpp
! src/hotspot/share/jfr/recorder/service/jfrPostBox.cpp
! src/hotspot/share/jfr/recorder/service/jfrPostBox.hpp
! src/hotspot/share/jfr/recorder/service/jfrRecorderService.cpp
! src/hotspot/share/jfr/recorder/service/jfrRecorderService.hpp
! src/hotspot/share/jfr/recorder/service/jfrRecorderThreadLoop.cpp
! src/hotspot/share/runtime/java.cpp
! src/hotspot/share/utilities/debug.cpp
! src/hotspot/share/utilities/vmError.cpp
! test/jdk/ProblemList.txt
! test/jdk/jdk/jfr/event/oldobject/TestEmergencyDumpAtOOM.java

Changeset: b070367b
Branch: fibers
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
Date:      2026-01-13 19:40:20 +0000
URL:       https://git.openjdk.org/loom/commit/b070367bdf980ef1c257cab485927db39b544241

8373106: JFR suspend/resume deadlock on macOS in pthreads library

Reviewed-by: egahlin

! src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp

Changeset: 4d0ad0a4
Branch: fibers
Author:    Brent Christian <bchristi at openjdk.org>
Date:      2026-01-13 19:47:11 +0000
URL:       https://git.openjdk.org/loom/commit/4d0ad0a4a391286c683ebb8c8d711ea0be68c31a

8373718: jdk/internal/misc/VM/RuntimeArguments.java test fails in Virtual threads mode

Reviewed-by: alanb

! test/jdk/jdk/internal/misc/VM/RuntimeArguments.java

Changeset: 9ed0ecbc
Branch: fibers
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
Date:      2026-01-13 22:38:12 +0000
URL:       https://git.openjdk.org/loom/commit/9ed0ecbcc1b4796bc56b7cb341ff8f9d3898713d

8375061: Multiple jpackage tool providers may share the same logging config

Reviewed-by: almatvee

! src/jdk.jpackage/share/classes/jdk/jpackage/internal/Globals.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/Log.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/Main.java
+ test/jdk/tools/jpackage/helpers-test/jdk/jpackage/test/JPackageCommandTest.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/Executor.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/Main.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TKit.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/OptionsValidationFailTest.java
! test/jdk/tools/jpackage/junit/tools/jdk/jpackage/test/JUnitAdapter.java
! test/jdk/tools/jpackage/share/AsyncTest.java
! test/jdk/tools/jpackage/windows/Win8301247Test.java
! test/jdk/tools/jpackage/windows/WinNoRestartTest.java

Changeset: 0d19d91b
Branch: fibers
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
Date:      2026-01-13 23:48:14 +0000
URL:       https://git.openjdk.org/loom/commit/0d19d91b44e5232dbd99d34dcdf6500f892e3048

8369048: GenShen: Defer ShenFreeSet::available() during rebuild

Reviewed-by: wkemper, ysr

! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp
! src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp
! src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahMetrics.cpp
! src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.cpp

Changeset: de6f35ef
Branch: fibers
Author:    Dingli Zhang <dzhang at openjdk.org>
Date:      2026-01-14 01:01:52 +0000
URL:       https://git.openjdk.org/loom/commit/de6f35eff988e737496d5e99e991868e97d72db4

8375094: RISC-V: Fix client builds after JDK-8368732

Reviewed-by: fyang, wenanjian, fjiang

! src/hotspot/cpu/riscv/vm_version_riscv.cpp

Changeset: 5da70b18
Branch: fibers
Author:    Jonas Norlinder <jnorlinder at openjdk.org>
Committer: David Holmes <dholmes at openjdk.org>
Date:      2026-01-14 02:13:13 +0000
URL:       https://git.openjdk.org/loom/commit/5da70b180461d46b1aa44f24ba3c05efdeb03f49

8375006: [Linux] Remove obsolete O_CLOEXEC check in os::open

Reviewed-by: dholmes, jsjolen

! src/hotspot/os/linux/os_linux.cpp

Changeset: b082a390
Branch: fibers
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
Date:      2026-01-14 04:04:08 +0000
URL:       https://git.openjdk.org/loom/commit/b082a390b77fca7134000bfe631f73bfd082bfa1

8375240: Make bundling progress messages issued by jpackage consistent across platforms

Reviewed-by: almatvee

! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxDebPackager.java
! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxRpmPackager.java
! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/resources/LinuxResources.properties
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacBundlingEnvironment.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacDmgPackager.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacPackagingPipeline.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources.properties
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/DefaultBundlingEnvironment.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/PackagingPipeline.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/OptionsAnalyzer.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardBundlingOperation.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardOption.java
+ src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/AppImageBundleType.java
- src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/AppImagePackageType.java
+ src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/BundleType.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/PackageType.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/StandardPackageType.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources.properties
! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinExePackager.java
! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiPackager.java
! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources.properties
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/PackageTest.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/DefaultBundlingEnvironmentTest.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/PackagingPipelineTest.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/StandardOptionTest.java
! test/jdk/tools/jpackage/share/BasicTest.java
+ test/jdk/tools/jpackage/share/OutputErrorTest.java

Changeset: 56d7b524
Branch: fibers
Author:    Eric Fang <erfang at openjdk.org>
Committer: Xiaohong Gong <xgong at openjdk.org>
Date:      2026-01-14 06:17:04 +0000
URL:       https://git.openjdk.org/loom/commit/56d7b524b3ddb49b985b4e6f061a7128b10cffb5

8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions

Reviewed-by: psandoz, qamai, xgong

! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template
! test/jdk/jdk/incubator/vector/Byte128VectorTests.java
! test/jdk/jdk/incubator/vector/Byte256VectorTests.java
! test/jdk/jdk/incubator/vector/Byte512VectorTests.java
! test/jdk/jdk/incubator/vector/Byte64VectorTests.java
! test/jdk/jdk/incubator/vector/ByteMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Double128VectorTests.java
! test/jdk/jdk/incubator/vector/Double256VectorTests.java
! test/jdk/jdk/incubator/vector/Double512VectorTests.java
! test/jdk/jdk/incubator/vector/Double64VectorTests.java
! test/jdk/jdk/incubator/vector/DoubleMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Float128VectorTests.java
! test/jdk/jdk/incubator/vector/Float256VectorTests.java
! test/jdk/jdk/incubator/vector/Float512VectorTests.java
! test/jdk/jdk/incubator/vector/Float64VectorTests.java
! test/jdk/jdk/incubator/vector/FloatMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Int128VectorTests.java
! test/jdk/jdk/incubator/vector/Int256VectorTests.java
! test/jdk/jdk/incubator/vector/Int512VectorTests.java
! test/jdk/jdk/incubator/vector/Int64VectorTests.java
! test/jdk/jdk/incubator/vector/IntMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Long128VectorTests.java
! test/jdk/jdk/incubator/vector/Long256VectorTests.java
! test/jdk/jdk/incubator/vector/Long512VectorTests.java
! test/jdk/jdk/incubator/vector/Long64VectorTests.java
! test/jdk/jdk/incubator/vector/LongMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Short128VectorTests.java
! test/jdk/jdk/incubator/vector/Short256VectorTests.java
! test/jdk/jdk/incubator/vector/Short512VectorTests.java
! test/jdk/jdk/incubator/vector/Short64VectorTests.java
! test/jdk/jdk/incubator/vector/ShortMaxVectorTests.java
! test/jdk/jdk/incubator/vector/gen-template.sh
! test/jdk/jdk/incubator/vector/templates/Kernel-Reduction-Masked-op-func.template
! test/jdk/jdk/incubator/vector/templates/Kernel-Reduction-Masked-op.template
! test/jdk/jdk/incubator/vector/templates/Kernel-Reduction-op-func.template
! test/jdk/jdk/incubator/vector/templates/Kernel-Reduction-op.template
! test/jdk/jdk/incubator/vector/templates/Kernel-SaturatingReduction-Masked-op.template
! test/jdk/jdk/incubator/vector/templates/Kernel-SaturatingReduction-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Reduction-op-func.template
! test/jdk/jdk/incubator/vector/templates/Unit-Reduction-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-SaturatingReduction-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-header.template

Changeset: 624d7144
Branch: fibers
Author:    Quan Anh Mai <qamai at openjdk.org>
Date:      2026-01-14 07:09:38 +0000
URL:       https://git.openjdk.org/loom/commit/624d7144f757c39215ae3dfed1b78cdd3b3e4f8e

8374435: assert(addp->is_AddP()) failed: must be AddP during EA with -XX:-UseCompressedOops

Reviewed-by: chagedorn, thartmann

! src/hotspot/share/opto/escape.cpp
+ test/hotspot/jtreg/compiler/escapeAnalysis/TestSplitLoadThroughPhiDuringEA.java

Changeset: 1b6c2bdd
Branch: fibers
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2026-01-14 07:21:25 +0000
URL:       https://git.openjdk.org/loom/commit/1b6c2bdd7b57891ed35e3c067871d2c0bf282824

8375055: C2: Better dead loop detection printout

Reviewed-by: chagedorn, qamai

! src/hotspot/share/opto/phaseX.cpp

Changeset: 703665c1
Branch: fibers
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
Date:      2026-01-14 13:46:40 +0000
URL:       https://git.openjdk.org/loom/commit/703665c13f754f3ba7858c4bb2549c76cbc22a62

8356684: jpackage error messages are not helpful

Reviewed-by: almatvee

! src/jdk.jpackage/share/classes/jdk/jpackage/internal/Executor.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/Main.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardOption.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/Utils.java
+ src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/ExecutableAttributesWithCapturedOutput.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/JPackageException.java
+ src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/SelfContainedException.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources.properties
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/CommandOutputControl.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/Executor.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/mock/CommandActionSpecs.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/MainTest.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/util/CommandOutputControlTest.java

Changeset: 20bd178b
Branch: fibers
Author:    Roger Calnan <roger.calnan at oracle.com>
Committer: Jesper Wilhelmsson <jwilhelm at openjdk.org>
Date:      2026-01-14 14:08:21 +0000
URL:       https://git.openjdk.org/loom/commit/20bd178b997b8bbf895877774d55d1a9e87c3038

8373836: add anchors to the java options in the java man page

Reviewed-by: jwilhelm, iris

! src/java.base/share/man/java.md

Changeset: 56545328
Branch: fibers
Author:    Jonas Norlinder <jnorlinder at openjdk.org>
Committer: Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-14 16:54:24 +0000
URL:       https://git.openjdk.org/loom/commit/56545328f849c3ebf062e3ff601224084fa3b46e

8375297: ZGC: Remove obsolete O_CLOEXEC definition

Reviewed-by: tschatzl, eosterlund

! src/hotspot/os/linux/gc/z/zPhysicalMemoryBacking_linux.cpp

Changeset: 6228300e
Branch: fibers
Author:    Alan Bateman <alan.bateman at oracle.com>
Date:      2026-01-14 18:06:25 +0000
URL:       https://git.openjdk.org/loom/commit/6228300e903c8b4b4b0308e0d35e865d0ac581ea

Merge branch 'master' into fibers

! src/java.base/share/classes/java/lang/System.java
! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java
! test/jdk/ProblemList.txt
! src/java.base/share/classes/java/lang/System.java
! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java
! test/jdk/ProblemList.txt

Changeset: 47cc2287
Branch: fibers
Author:    Alan Bateman <alan.bateman at oracle.com>
Date:      2026-01-14 18:05:46 +0000
URL:       https://git.openjdk.org/loom/commit/47cc228728bf302922fee39c051a99278d124a60

Prototype unstarted only needs to check caller when preferred carrier specified

! src/java.base/share/classes/java/lang/ThreadBuilders.java

Changeset: 5ae76405
Branch: fibers
Author:    Alan Bateman <alan.bateman at oracle.com>
Date:      2026-01-14 18:06:34 +0000
URL:       https://git.openjdk.org/loom/commit/5ae76405773761d3b570625fea62fb673fd529aa

Merge loom into fibers



From duke at openjdk.org  Wed Jan 14 19:15:00 2026
From: duke at openjdk.org (duke)
Date: Wed, 14 Jan 2026 19:15:00 GMT
Subject: git: openjdk/loom: master: 42 new changesets
Message-ID: <ad8ed087-1765-4426-92e9-efe76126cf3c@openjdk.org>

Changeset: 33689485
Branch: master
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2026-01-11 20:37:04 +0000
URL:       https://git.openjdk.org/loom/commit/336894857bfc9f610da55e6180dd7b668bf67752

8374878: Add Atomic<T>::compare_set

Reviewed-by: kbarrett, stefank

! src/hotspot/share/gc/shared/oopStorage.cpp
! src/hotspot/share/gc/shared/pretouchTask.cpp
! src/hotspot/share/gc/shared/taskqueue.hpp
! src/hotspot/share/gc/shared/taskqueue.inline.hpp
! src/hotspot/share/runtime/atomic.hpp
! src/hotspot/share/utilities/concurrentHashTable.inline.hpp
! src/hotspot/share/utilities/waitBarrier_generic.cpp
! test/hotspot/gtest/runtime/test_atomic.cpp

Changeset: 669977f7
Branch: master
Author:    Trevor Bond <trevorkbond at gmail.com>
Committer: Adam Sotona <asotona at openjdk.org>
Date:      2026-01-12 07:05:52 +0000
URL:       https://git.openjdk.org/loom/commit/669977f7c4b58ab4901a340906262ab907b3ffb6

8341272: Factory to create wide iinc instruction with small arguments

Reviewed-by: liach, asotona

! src/java.base/share/classes/java/lang/classfile/instruction/IncrementInstruction.java
! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractInstruction.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BytecodeHelpers.java
! test/jdk/jdk/classfile/InstructionValidationTest.java

Changeset: 7cf7f01f
Branch: master
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2026-01-12 07:46:25 +0000
URL:       https://git.openjdk.org/loom/commit/7cf7f01fb339bf3c5b81d946be8afa71ec267e42

8374875: Improve perfMemory warning about 'Insufficient space for shared memory file'

Reviewed-by: lucy, mdoerr, clanger

! src/hotspot/os/posix/perfMemory_posix.cpp

Changeset: 49040462
Branch: master
Author:    Beno?t Maillard <bmaillard at openjdk.org>
Date:      2026-01-12 07:59:37 +0000
URL:       https://git.openjdk.org/loom/commit/49040462f3d2761435cded1bd8898d0c6b16fc02

8372302: C2: IGVN verification fails because ModXNode::Ideal creates unused intermediate nodes

Reviewed-by: epeter, qamai

! src/hotspot/share/opto/divnode.cpp
+ test/hotspot/jtreg/compiler/c2/igvn/TestModIdealCreatesUselessNode.java

Changeset: 133a023e
Branch: master
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2026-01-12 08:04:14 +0000
URL:       https://git.openjdk.org/loom/commit/133a023e8e1ec1c555265a92eb0fcb4965f0b162

8374471: Check bin and lib folder of JDK image for unwanted files

Reviewed-by: erikj, clanger

+ test/jdk/build/CheckFiles.java

Changeset: fb13abef
Branch: master
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-12 08:26:10 +0000
URL:       https://git.openjdk.org/loom/commit/fb13abef44d535ebc4535921fd4eb0f285030465

8374743: G1 starts a concurrent mark when allocating humongous objects during initialization

Co-authored-by: Erik ?sterlund <eosterlund at openjdk.org>
Reviewed-by: eosterlund, iwalulya, sjohanss, shade

! src/hotspot/share/gc/g1/g1CollectedHeap.cpp

Changeset: d0aae04d
Branch: master
Author:    Johan Sj?len <jsjolen at openjdk.org>
Date:      2026-01-12 11:01:12 +0000
URL:       https://git.openjdk.org/loom/commit/d0aae04d61c90698ab5a01b4389dc6932de63cb7

8325108: POSIX map_memory_to_file calls release_memory unnecessarily

Reviewed-by: dholmes, coleenp

! src/hotspot/os/posix/os_posix.cpp

Changeset: 2fbe4755
Branch: master
Author:    Emanuel Peter <epeter at openjdk.org>
Date:      2026-01-12 11:18:28 +0000
URL:       https://git.openjdk.org/loom/commit/2fbe47559e9ba45306bd08c3636647f865a75abd

8374785: Template Library: need to tag Float16.copySign as having non-deterministic result because of multiple NaNs with different sign bits

Reviewed-by: thartmann, qamai

! test/hotspot/jtreg/compiler/lib/template_framework/library/Operations.java

Changeset: 556bddfd
Branch: master
Author:    Erik Gahlin <egahlin at openjdk.org>
Date:      2026-01-12 11:30:43 +0000
URL:       https://git.openjdk.org/loom/commit/556bddfd9439d1bad698ab5134317ce263a36b04

8372321: TestBackToBackSensitive fails intermittently after JDK-8365972

Reviewed-by: mgronlun

! test/jdk/jdk/jfr/event/runtime/TestBackToBackSensitive.java

Changeset: d433ce52
Branch: master
Author:    Liam Miller-Cushon <cushon at openjdk.org>
Date:      2026-01-12 15:22:42 +0000
URL:       https://git.openjdk.org/loom/commit/d433ce52360994be5a88a0bcbf39cbb741b435ec

8369564: Provide a MemorySegment API to read strings with known lengths

Co-authored-by: Per Minborg <pminborg at openjdk.org>
Reviewed-by: jvernee, mcimadamore

! src/java.base/share/classes/java/lang/String.java
! src/java.base/share/classes/java/lang/System.java
! src/java.base/share/classes/java/lang/foreign/MemorySegment.java
! src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java
! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java
! src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java
! src/java.base/share/classes/jdk/internal/foreign/StringSupport.java
! test/jdk/java/foreign/TestStringEncoding.java
+ test/micro/org/openjdk/bench/java/lang/foreign/FromJavaStringTest.java
! test/micro/org/openjdk/bench/java/lang/foreign/ToJavaStringTest.java

Changeset: 9a2592f8
Branch: master
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2026-01-12 19:41:21 +0000
URL:       https://git.openjdk.org/loom/commit/9a2592f8d2177f1480758e94faf9b986c7bba681

8374953: Add note on about implicit state when comparing TypeMirrors

Reviewed-by: attila, vromero, jlahoda

! src/java.compiler/share/classes/javax/lang/model/type/TypeMirror.java
! src/java.compiler/share/classes/javax/lang/model/util/Types.java

Changeset: 15b7a425
Branch: master
Author:    William Kemper <wkemper at openjdk.org>
Date:      2026-01-12 23:36:26 +0000
URL:       https://git.openjdk.org/loom/commit/15b7a4252b8d3595b7bc409e20d4c617e89240e8

8373819: Genshen: Control thread can miss allocation failure notification (redux)

Reviewed-by: kdnilsen, ysr

! src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.cpp
! src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.hpp
! src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.hpp
! src/hotspot/share/gc/shenandoah/shenandoahRegulatorThread.cpp

Changeset: e89c1290
Branch: master
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2026-01-13 01:29:20 +0000
URL:       https://git.openjdk.org/loom/commit/e89c1290ca8b3e07bef12f4c0465c3e83389fef4

8374181: failure_handler: The cores.html file is formatted incorrectly and so hides the core dump information

Reviewed-by: erikj

! test/failure_handler/src/share/classes/jdk/test/failurehandler/jtreg/GatherDiagnosticInfoObserver.java

Changeset: 0b9d4c02
Branch: master
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2026-01-13 04:29:12 +0000
URL:       https://git.openjdk.org/loom/commit/0b9d4c02e39191e9dba721115f422e28ee5b9869

4765299: componentResized() not always called with nested JSplitPanes

Reviewed-by: tr, kizune

! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicSplitPaneUI.java
+ test/jdk/javax/swing/JSplitPane/TestSplitPaneCompResize.java

Changeset: f4ebf958
Branch: master
Author:    David Holmes <dholmes at openjdk.org>
Date:      2026-01-13 06:02:01 +0000
URL:       https://git.openjdk.org/loom/commit/f4ebf9585f63177584d8c48838ef793407ebce12

8370314: Update signals_posix with new Linux signal codes

Reviewed-by: shade, jwaters

! src/hotspot/os/posix/signals_posix.cpp

Changeset: 586846b8
Branch: master
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2026-01-13 06:49:04 +0000
URL:       https://git.openjdk.org/loom/commit/586846b84a38d285c5905437e903cfc57f609410

8374450: GTest opto.canonicalize_constraints cannot run without VM

Reviewed-by: qamai, thartmann, shade

! test/hotspot/gtest/opto/test_rangeinference.cpp

Changeset: c000343b
Branch: master
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2026-01-13 07:30:13 +0000
URL:       https://git.openjdk.org/loom/commit/c000343bbb1d822d2cee37e1a27672cfb3128bee

8374876: Epsilon: Convert to use Atomic<T>

Reviewed-by: tschatzl, stefank

! src/hotspot/share/gc/epsilon/epsilonHeap.cpp
! src/hotspot/share/gc/epsilon/epsilonHeap.hpp
! src/hotspot/share/gc/epsilon/epsilonMonitoringSupport.cpp
! src/hotspot/share/gc/epsilon/epsilonMonitoringSupport.hpp

Changeset: d6f43d73
Branch: master
Author:    Liam Miller-Cushon <cushon at openjdk.org>
Date:      2026-01-13 08:05:57 +0000
URL:       https://git.openjdk.org/loom/commit/d6f43d7329bf0ba08464f6d0a22de7e27ca8b399

8375066: Test tools/sincechecker/modules/java.base/JavaBaseCheckSince.java broken by JDK-8369564

Reviewed-by: jpai, shade

! src/java.base/share/classes/java/lang/foreign/MemorySegment.java
! src/java.base/share/classes/java/lang/foreign/SegmentAllocator.java

Changeset: 578204f8
Branch: master
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2026-01-13 08:12:35 +0000
URL:       https://git.openjdk.org/loom/commit/578204f8c49f06be8b9c4855359ca61c9e107678

8374379: Type annotation in new array dimension expression causes java.lang.AssertionError

Reviewed-by: vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java
! test/langtools/tools/javac/annotations/typeAnnotations/classfile/TestNewCastArray.java

Changeset: 543a9722
Branch: master
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
Date:      2026-01-13 11:44:32 +0000
URL:       https://git.openjdk.org/loom/commit/543a972222118155e4c72c6f2d32d154c5dfd442

8373485: JFR Crash during sampling:  assert(jt->has_last_Java_frame()) failed: invariant

Reviewed-by: shade, egahlin

! src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp

Changeset: a90c7eee
Branch: master
Author:    Quan Anh Mai <qamai at openjdk.org>
Date:      2026-01-13 12:42:25 +0000
URL:       https://git.openjdk.org/loom/commit/a90c7eee6f7e950edea4d94cf2b109fdb5e49909

8374969: Incorrect results of LoadStoreNode::adr_type and SCMemProj::adr_type

Reviewed-by: roland, mhaessig

! src/hotspot/share/opto/memnode.cpp
! src/hotspot/share/opto/memnode.hpp

Changeset: f7be1dcf
Branch: master
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
Date:      2026-01-13 13:33:41 +0000
URL:       https://git.openjdk.org/loom/commit/f7be1dcf296d28f8e004d180038ab715153a6c15

8375054: Removed "signed" property from jpackage app image file

Reviewed-by: almatvee

! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/AppImageSigner.java
- src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacBundle.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacFromOptions.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacPackagingPipeline.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/model/MacApplication.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/OptionSpecBuilder.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardAppImageFileOption.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardOption.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardValidator.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/Validator.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources.properties
+ src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/MacBundle.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/AppImageFile.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/helpers/jdk/jpackage/test/MacSignVerify.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/AppImageFileTest.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/TestUtils.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/ValidatorTest.java
! test/jdk/tools/jpackage/share/AppImagePackageTest.java
! test/jdk/tools/jpackage/share/ErrorTest.java

Changeset: 47029ccf
Branch: master
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
Date:      2026-01-13 13:36:44 +0000
URL:       https://git.openjdk.org/loom/commit/47029ccfec988e0a9298e35dcc729d9eeffc45e1

8375050: Simplify process management in jpackage tests

Reviewed-by: almatvee

! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/Executor.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/HelloApp.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/WindowsHelper.java
! test/jdk/tools/jpackage/macosx/ArgumentsFilteringTest.java
! test/jdk/tools/jpackage/share/MainClassTest.java
! test/jdk/tools/jpackage/windows/Win8301247Test.java
! test/jdk/tools/jpackage/windows/WinChildProcessTest.java
! test/jdk/tools/jpackage/windows/WinNoRestartTest.java

Changeset: 7330e1a9
Branch: master
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2026-01-13 13:51:00 +0000
URL:       https://git.openjdk.org/loom/commit/7330e1a996fd43d92430a73b818f33552bc6ae9c

8374990: Check include and jmods folder of JDK image for unwanted files

Reviewed-by: erikj

! test/jdk/build/CheckFiles.java

Changeset: 49f72658
Branch: master
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2026-01-13 13:54:04 +0000
URL:       https://git.openjdk.org/loom/commit/49f7265894652ea243f3a531cf3f9d0b06e53565

8374872: Cleanup outdated SAP AG copyright header info

Reviewed-by: clanger, mdoerr

! test/hotspot/jtreg/runtime/exceptionMsgs/IllegalAccessError/IAE78_A.java
! test/hotspot/jtreg/runtime/exceptionMsgs/IllegalAccessError/IAE_Loader2.java
! test/hotspot/jtreg/runtime/execstack/Test.java
! test/hotspot/jtreg/runtime/execstack/TestMT.java
! test/hotspot/jtreg/runtime/execstack/libtest-rw.c
! test/hotspot/jtreg/runtime/execstack/libtest-rwx.c

Changeset: 45990d79
Branch: master
Author:    Volodymyr Paprotski <vpaprotski at openjdk.org>
Date:      2026-01-13 15:15:36 +0000
URL:       https://git.openjdk.org/loom/commit/45990d796ffafc228c6e843049c80aefedb0f12b

8374570: Assertion failure in ClearArray.java  with -XX:+EnableX86EcoreOpts

Reviewed-by: thartmann, epeter, qamai

! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! test/hotspot/jtreg/compiler/c2/ClearArray.java

Changeset: 7f707ba8
Branch: master
Author:    Damon Nguyen <dnguyen at openjdk.org>
Date:      2026-01-13 16:55:03 +0000
URL:       https://git.openjdk.org/loom/commit/7f707ba8e746d859ac171d71ef8f731953a92e6a

8373727: New XBM images parser regression: only the first line of the bitmap array is parsed

Reviewed-by: prr, jdv

! src/java.desktop/share/classes/sun/awt/image/XbmImageDecoder.java
! test/jdk/java/awt/image/XBMDecoder/XBMDecoderTest.java
+ test/jdk/java/awt/image/XBMDecoder/invalid_empty.xbm
! test/jdk/java/awt/image/XBMDecoder/invalid_hex.xbm
+ test/jdk/java/awt/image/XBMDecoder/invalid_plus.xbm
+ test/jdk/java/awt/image/XBMDecoder/valid_multiline.xbm

Changeset: 07403843
Branch: master
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2026-01-13 16:57:30 +0000
URL:       https://git.openjdk.org/loom/commit/074038438f5b8b91e9390430b4fa58ff53e5df26

8374727: Audio configuration Platform class - use nio for getting endianness of the underlying platform

Reviewed-by: prr, kizune

! src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_PCM.cpp
! src/java.desktop/share/classes/com/sun/media/sound/Platform.java
- src/java.desktop/share/native/libjsound/Platform.c
! src/java.desktop/share/native/libjsound/Utilities.c
! src/java.desktop/share/native/libjsound/Utilities.h

Changeset: f23752a7
Branch: master
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
Date:      2026-01-13 18:06:04 +0000
URL:       https://git.openjdk.org/loom/commit/f23752a75ee3d3af0853eff9c678d2496bb1cf58

8371014: Dump JFR recording on CrashOnOutOfMemoryError is incorrectly implemented

Reviewed-by: ysuenaga

! src/hotspot/share/jfr/jfr.cpp
! src/hotspot/share/jfr/jfr.hpp
! src/hotspot/share/jfr/jni/jfrJniMethod.cpp
! src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp
! src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.hpp
! src/hotspot/share/jfr/recorder/service/jfrPostBox.cpp
! src/hotspot/share/jfr/recorder/service/jfrPostBox.hpp
! src/hotspot/share/jfr/recorder/service/jfrRecorderService.cpp
! src/hotspot/share/jfr/recorder/service/jfrRecorderService.hpp
! src/hotspot/share/jfr/recorder/service/jfrRecorderThreadLoop.cpp
! src/hotspot/share/runtime/java.cpp
! src/hotspot/share/utilities/debug.cpp
! src/hotspot/share/utilities/vmError.cpp
! test/jdk/ProblemList.txt
! test/jdk/jdk/jfr/event/oldobject/TestEmergencyDumpAtOOM.java

Changeset: b070367b
Branch: master
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
Date:      2026-01-13 19:40:20 +0000
URL:       https://git.openjdk.org/loom/commit/b070367bdf980ef1c257cab485927db39b544241

8373106: JFR suspend/resume deadlock on macOS in pthreads library

Reviewed-by: egahlin

! src/hotspot/share/jfr/periodic/sampling/jfrThreadSampler.cpp

Changeset: 4d0ad0a4
Branch: master
Author:    Brent Christian <bchristi at openjdk.org>
Date:      2026-01-13 19:47:11 +0000
URL:       https://git.openjdk.org/loom/commit/4d0ad0a4a391286c683ebb8c8d711ea0be68c31a

8373718: jdk/internal/misc/VM/RuntimeArguments.java test fails in Virtual threads mode

Reviewed-by: alanb

! test/jdk/jdk/internal/misc/VM/RuntimeArguments.java

Changeset: 9ed0ecbc
Branch: master
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
Date:      2026-01-13 22:38:12 +0000
URL:       https://git.openjdk.org/loom/commit/9ed0ecbcc1b4796bc56b7cb341ff8f9d3898713d

8375061: Multiple jpackage tool providers may share the same logging config

Reviewed-by: almatvee

! src/jdk.jpackage/share/classes/jdk/jpackage/internal/Globals.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/Log.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/Main.java
+ test/jdk/tools/jpackage/helpers-test/jdk/jpackage/test/JPackageCommandTest.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/Executor.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/Main.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TKit.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/OptionsValidationFailTest.java
! test/jdk/tools/jpackage/junit/tools/jdk/jpackage/test/JUnitAdapter.java
! test/jdk/tools/jpackage/share/AsyncTest.java
! test/jdk/tools/jpackage/windows/Win8301247Test.java
! test/jdk/tools/jpackage/windows/WinNoRestartTest.java

Changeset: 0d19d91b
Branch: master
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
Date:      2026-01-13 23:48:14 +0000
URL:       https://git.openjdk.org/loom/commit/0d19d91b44e5232dbd99d34dcdf6500f892e3048

8369048: GenShen: Defer ShenFreeSet::available() during rebuild

Reviewed-by: wkemper, ysr

! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp
! src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp
! src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahMetrics.cpp
! src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.cpp

Changeset: de6f35ef
Branch: master
Author:    Dingli Zhang <dzhang at openjdk.org>
Date:      2026-01-14 01:01:52 +0000
URL:       https://git.openjdk.org/loom/commit/de6f35eff988e737496d5e99e991868e97d72db4

8375094: RISC-V: Fix client builds after JDK-8368732

Reviewed-by: fyang, wenanjian, fjiang

! src/hotspot/cpu/riscv/vm_version_riscv.cpp

Changeset: 5da70b18
Branch: master
Author:    Jonas Norlinder <jnorlinder at openjdk.org>
Committer: David Holmes <dholmes at openjdk.org>
Date:      2026-01-14 02:13:13 +0000
URL:       https://git.openjdk.org/loom/commit/5da70b180461d46b1aa44f24ba3c05efdeb03f49

8375006: [Linux] Remove obsolete O_CLOEXEC check in os::open

Reviewed-by: dholmes, jsjolen

! src/hotspot/os/linux/os_linux.cpp

Changeset: b082a390
Branch: master
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
Date:      2026-01-14 04:04:08 +0000
URL:       https://git.openjdk.org/loom/commit/b082a390b77fca7134000bfe631f73bfd082bfa1

8375240: Make bundling progress messages issued by jpackage consistent across platforms

Reviewed-by: almatvee

! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxDebPackager.java
! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxRpmPackager.java
! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/resources/LinuxResources.properties
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacBundlingEnvironment.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacDmgPackager.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacPackagingPipeline.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources.properties
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/DefaultBundlingEnvironment.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/PackagingPipeline.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/OptionsAnalyzer.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardBundlingOperation.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardOption.java
+ src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/AppImageBundleType.java
- src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/AppImagePackageType.java
+ src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/BundleType.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/PackageType.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/StandardPackageType.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources.properties
! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinExePackager.java
! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiPackager.java
! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources.properties
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/PackageTest.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/DefaultBundlingEnvironmentTest.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/PackagingPipelineTest.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/StandardOptionTest.java
! test/jdk/tools/jpackage/share/BasicTest.java
+ test/jdk/tools/jpackage/share/OutputErrorTest.java

Changeset: 56d7b524
Branch: master
Author:    Eric Fang <erfang at openjdk.org>
Committer: Xiaohong Gong <xgong at openjdk.org>
Date:      2026-01-14 06:17:04 +0000
URL:       https://git.openjdk.org/loom/commit/56d7b524b3ddb49b985b4e6f061a7128b10cffb5

8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions

Reviewed-by: psandoz, qamai, xgong

! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template
! test/jdk/jdk/incubator/vector/Byte128VectorTests.java
! test/jdk/jdk/incubator/vector/Byte256VectorTests.java
! test/jdk/jdk/incubator/vector/Byte512VectorTests.java
! test/jdk/jdk/incubator/vector/Byte64VectorTests.java
! test/jdk/jdk/incubator/vector/ByteMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Double128VectorTests.java
! test/jdk/jdk/incubator/vector/Double256VectorTests.java
! test/jdk/jdk/incubator/vector/Double512VectorTests.java
! test/jdk/jdk/incubator/vector/Double64VectorTests.java
! test/jdk/jdk/incubator/vector/DoubleMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Float128VectorTests.java
! test/jdk/jdk/incubator/vector/Float256VectorTests.java
! test/jdk/jdk/incubator/vector/Float512VectorTests.java
! test/jdk/jdk/incubator/vector/Float64VectorTests.java
! test/jdk/jdk/incubator/vector/FloatMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Int128VectorTests.java
! test/jdk/jdk/incubator/vector/Int256VectorTests.java
! test/jdk/jdk/incubator/vector/Int512VectorTests.java
! test/jdk/jdk/incubator/vector/Int64VectorTests.java
! test/jdk/jdk/incubator/vector/IntMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Long128VectorTests.java
! test/jdk/jdk/incubator/vector/Long256VectorTests.java
! test/jdk/jdk/incubator/vector/Long512VectorTests.java
! test/jdk/jdk/incubator/vector/Long64VectorTests.java
! test/jdk/jdk/incubator/vector/LongMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Short128VectorTests.java
! test/jdk/jdk/incubator/vector/Short256VectorTests.java
! test/jdk/jdk/incubator/vector/Short512VectorTests.java
! test/jdk/jdk/incubator/vector/Short64VectorTests.java
! test/jdk/jdk/incubator/vector/ShortMaxVectorTests.java
! test/jdk/jdk/incubator/vector/gen-template.sh
! test/jdk/jdk/incubator/vector/templates/Kernel-Reduction-Masked-op-func.template
! test/jdk/jdk/incubator/vector/templates/Kernel-Reduction-Masked-op.template
! test/jdk/jdk/incubator/vector/templates/Kernel-Reduction-op-func.template
! test/jdk/jdk/incubator/vector/templates/Kernel-Reduction-op.template
! test/jdk/jdk/incubator/vector/templates/Kernel-SaturatingReduction-Masked-op.template
! test/jdk/jdk/incubator/vector/templates/Kernel-SaturatingReduction-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Reduction-op-func.template
! test/jdk/jdk/incubator/vector/templates/Unit-Reduction-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-SaturatingReduction-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-header.template

Changeset: 624d7144
Branch: master
Author:    Quan Anh Mai <qamai at openjdk.org>
Date:      2026-01-14 07:09:38 +0000
URL:       https://git.openjdk.org/loom/commit/624d7144f757c39215ae3dfed1b78cdd3b3e4f8e

8374435: assert(addp->is_AddP()) failed: must be AddP during EA with -XX:-UseCompressedOops

Reviewed-by: chagedorn, thartmann

! src/hotspot/share/opto/escape.cpp
+ test/hotspot/jtreg/compiler/escapeAnalysis/TestSplitLoadThroughPhiDuringEA.java

Changeset: 1b6c2bdd
Branch: master
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2026-01-14 07:21:25 +0000
URL:       https://git.openjdk.org/loom/commit/1b6c2bdd7b57891ed35e3c067871d2c0bf282824

8375055: C2: Better dead loop detection printout

Reviewed-by: chagedorn, qamai

! src/hotspot/share/opto/phaseX.cpp

Changeset: 703665c1
Branch: master
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
Date:      2026-01-14 13:46:40 +0000
URL:       https://git.openjdk.org/loom/commit/703665c13f754f3ba7858c4bb2549c76cbc22a62

8356684: jpackage error messages are not helpful

Reviewed-by: almatvee

! src/jdk.jpackage/share/classes/jdk/jpackage/internal/Executor.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/Main.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardOption.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/Utils.java
+ src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/ExecutableAttributesWithCapturedOutput.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/JPackageException.java
+ src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/SelfContainedException.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources.properties
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/CommandOutputControl.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/Executor.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/mock/CommandActionSpecs.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/MainTest.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/util/CommandOutputControlTest.java

Changeset: 20bd178b
Branch: master
Author:    Roger Calnan <roger.calnan at oracle.com>
Committer: Jesper Wilhelmsson <jwilhelm at openjdk.org>
Date:      2026-01-14 14:08:21 +0000
URL:       https://git.openjdk.org/loom/commit/20bd178b997b8bbf895877774d55d1a9e87c3038

8373836: add anchors to the java options in the java man page

Reviewed-by: jwilhelm, iris

! src/java.base/share/man/java.md

Changeset: 56545328
Branch: master
Author:    Jonas Norlinder <jnorlinder at openjdk.org>
Committer: Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-14 16:54:24 +0000
URL:       https://git.openjdk.org/loom/commit/56545328f849c3ebf062e3ff601224084fa3b46e

8375297: ZGC: Remove obsolete O_CLOEXEC definition

Reviewed-by: tschatzl, eosterlund

! src/hotspot/os/linux/gc/z/zPhysicalMemoryBacking_linux.cpp


From oleksandr.otenko at gmail.com  Fri Jan 16 10:05:18 2026
From: oleksandr.otenko at gmail.com (Alex Otenko)
Date: Fri, 16 Jan 2026 10:05:18 +0000
Subject: [External] : Re: Ephemeral threads
In-Reply-To: <589436274.13902990.1768299433698.JavaMail.zimbra@univ-eiffel.fr>
References: <CANkgWKiL3U_4-H3oy002+uXwC6m-XsYe+C-TS8rcisJDyNWJQA@mail.gmail.com>
 <2BC7AC23-83CA-40D5-95DE-35E8471EB656@ix.netcom.com>
 <4f9b2ac9-db35-4a32-9d78-ef32c4660cca@oracle.com>
 <CANkgWKj34NoSTtk5THOc_i6hOkXNwO5LuJMSE43DWFTf-X01Lg@mail.gmail.com>
 <adb3b75e-fbb5-488b-bead-c31521a38f24@oracle.com>
 <CANkgWKiqy8-8eZoevF1XnJRnUZk+CqNYP1K=c1K+4bTyFKFbiQ@mail.gmail.com>
 <589436274.13902990.1768299433698.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <CANkgWKjFLzkfwhUN7KtTr3fkt3JX1OjTp5ATRzgkpK=zdi0X6g@mail.gmail.com>

Because a push iterator isn't the same as a generator.

The code interacting with a generator is like two threads joined with a 0
capacity queue.

On Tue, 13 Jan 2026, 10:17 Remi Forax, <forax at univ-mlv.fr> wrote:

> It starts to be off topic,
> but it's not clear to me that in Java we want to map a generator to an
> iterator and not to stream (a push iterator with a cleanup semantics).
>
> regards,
> R?mi
>
> ------------------------------
>
> *From: *"Alex Otenko" <oleksandr.otenko at gmail.com>
> *To: *"Alan Bateman" <alan.bateman at oracle.com>
> *Cc: *"loom-dev" <loom-dev at openjdk.org>
> *Sent: *Tuesday, January 13, 2026 10:28:13 AM
> *Subject: *Re: [External] : Re: Ephemeral threads
>
> Yes, I understand that now that's not easy to do in Java. I just don't
> think it's all that exotic, and certainly not a bug. After all, we've all
> written at least one iterator when we did a coding interview.
>
> There is 1:1 correspondence between the iterators and the generators. So
> if we can GC the iterators without special dance, we should be able to do
> that for the generators. You could see an iterator as an explicit
> declaration that you are not going to use any features that rely on there
> being a finally - no unlocking, no resource management outside of what a
> finalizer can achieve, no peer to coordinate with, etc. Likewise an
> explicit declaration by an engineer that this here piece of code entering a
> wait is perfectly fine to GC, doesn't seem all that different.
>
> Yes, in general there are thread semantics, try-finally, reference loops
> and other obstacles - but we don't need to solve a general case, just the
> one that is in 1:1 correspondence with the iterators.
>
> I understand that there may be safe ways to implement the same with the
> existing mechanisms - like, the user of the generator might wrap the
> interaction in a try-with-resource, and that way control the lifecycle
> explicitly.
>
> On Tue, 13 Jan 2026, 08:00 Alan Bateman, <alan.bateman at oracle.com> wrote:
>
>>
>>
>> On 13/01/2026 06:42, Alex Otenko wrote:
>> >
>> > I think there are plenty of designs with generators, iterators and
>> > async where non-termination is not a bug.
>>
>> That is true is some other languages/runtimes. If Java were to add
>> generators or some other exotic control flow in the future then there
>> would be more spooky issues to work through, some of which overlap with
>> the spooky issues that have come up in the discussion here.
>>
>> -Alan
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260116/dff4aff5/attachment.htm>

From rengels at ix.netcom.com  Fri Jan 16 12:46:52 2026
From: rengels at ix.netcom.com (Robert Engels)
Date: Fri, 16 Jan 2026 06:46:52 -0600
Subject: [External] : Re: Ephemeral threads
In-Reply-To: <CANkgWKjFLzkfwhUN7KtTr3fkt3JX1OjTp5ATRzgkpK=zdi0X6g@mail.gmail.com>
References: <CANkgWKjFLzkfwhUN7KtTr3fkt3JX1OjTp5ATRzgkpK=zdi0X6g@mail.gmail.com>
Message-ID: <2C2F7164-F2A3-466B-BA33-D949D62704DB@ix.netcom.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260116/3ad5d8bf/attachment.htm>

From duke at openjdk.org  Sat Jan 17 14:12:54 2026
From: duke at openjdk.org (duke)
Date: Sat, 17 Jan 2026 14:12:54 GMT
Subject: git: openjdk/loom: fibers: 41 new changesets
Message-ID: <e5faeb63-8a07-4988-99a9-c4e4b8be4229@openjdk.org>

Changeset: 60fbaf5b
Branch: fibers
Author:    Coleen Phillimore <coleenp at openjdk.org>
Date:      2026-01-14 18:53:10 +0000
URL:       https://git.openjdk.org/loom/commit/60fbaf5b26d7d359b1258898d4c4dfd86010b8a5

8374828: Save load_barrier_on_oop_field_preloaded in aot CodeCache

Reviewed-by: adinn, iklam, shade

! src/hotspot/share/code/aotCodeCache.cpp

Changeset: a7507ffa
Branch: fibers
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2026-01-14 19:26:45 +0000
URL:       https://git.openjdk.org/loom/commit/a7507ffa1dda403110a61c4b61143b76e8a7911e

8375237: Document existing exceptional behavior of divideUnsigned and remainderUnsigned

Reviewed-by: rgiulietti

! src/java.base/share/classes/java/lang/Integer.java
! src/java.base/share/classes/java/lang/Long.java

Changeset: 3007365b
Branch: fibers
Author:    Roger Riggs <rriggs at openjdk.org>
Date:      2026-01-14 19:27:10 +0000
URL:       https://git.openjdk.org/loom/commit/3007365b73d400ee6a5ea9a9041899bb81cf357a

8373913: Refactor serialization tests to use JUnit

Reviewed-by: jlu, naoto

! test/jdk/java/io/Serializable/GetField/ReadFieldsCNF.java
! test/jdk/java/io/Serializable/class/NonSerializableTest.java
! test/jdk/java/io/Serializable/records/RecordClassTest.java
! test/jdk/java/io/Serializable/records/SerialVersionUIDTest.java
! test/jdk/java/io/Serializable/serialFilter/CheckArrayTest.java
! test/jdk/java/io/Serializable/serialFilter/CheckInputOrderTest.java
! test/jdk/java/io/Serializable/serialFilter/GlobalFilterTest.java
! test/jdk/java/io/Serializable/serialFilter/InvalidGlobalFilterTest.java
! test/jdk/java/io/Serializable/serialFilter/MixedFiltersTest.java
! test/jdk/java/io/Serializable/serialFilter/SerialFactoryExample.java
! test/jdk/java/io/Serializable/serialFilter/SerialFactoryFaults.java
! test/jdk/java/io/Serializable/serialFilter/SerialFilterFactoryTest.java
! test/jdk/java/io/Serializable/serialFilter/SerialFilterFunctionTest.java
! test/jdk/java/io/Serializable/serialFilter/SerialFilterTest.java

Changeset: 6ad9f4ef
Branch: fibers
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2026-01-14 21:27:34 +0000
URL:       https://git.openjdk.org/loom/commit/6ad9f4ef6826bb031db7840ba3f689b0bde47775

8374493: Add missing @Override annotations in "com.sun.java.swing.plaf.motif" package

Reviewed-by: tr, prr, aivanov

! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifBorders.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifButtonListener.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifButtonUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifCheckBoxMenuItemUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifCheckBoxUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifComboBoxUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifDesktopIconUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifDesktopPaneUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifEditorPaneUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifFileChooserUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifIconFactory.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifInternalFrameTitlePane.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifInternalFrameUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifLookAndFeel.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifMenuItemUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifMenuMouseListener.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifMenuMouseMotionListener.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifMenuUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifOptionPaneUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifPasswordFieldUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifPopupMenuSeparatorUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifPopupMenuUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifRadioButtonMenuItemUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifRadioButtonUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifScrollBarButton.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifScrollBarUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifSliderUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifSplitPaneDivider.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifSplitPaneUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifTabbedPaneUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifTextAreaUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifTextFieldUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifTextPaneUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifTextUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifToggleButtonUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifTreeCellRenderer.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifTreeUI.java

Changeset: fb526c8f
Branch: fibers
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
Date:      2026-01-14 21:37:44 +0000
URL:       https://git.openjdk.org/loom/commit/fb526c8f45de6ca9a57608f728ac223cbca118be

8373001: LauncherFromOptions.create() not properly handling FileAssociationNoExtensionsException

Reviewed-by: almatvee

! src/jdk.jpackage/share/classes/jdk/jpackage/internal/LauncherFromOptions.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources.properties

Changeset: d8f45faf
Branch: fibers
Author:    SendaoYan <syan at openjdk.org>
Date:      2026-01-15 02:40:36 +0000
URL:       https://git.openjdk.org/loom/commit/d8f45faf5849e66b8f0e35e1d18ed0331a0cb1c2

8374432: TimeoutResponseBodyTest.java#retriesEnabledForResponseFailure fails run with -Xcomp

Reviewed-by: vyazici, dfuchs

! test/jdk/java/net/httpclient/TimeoutResponseTestSupport.java

Changeset: ce5e0d8a
Branch: fibers
Author:    SendaoYan <syan at openjdk.org>
Date:      2026-01-15 02:44:16 +0000
URL:       https://git.openjdk.org/loom/commit/ce5e0d8a48296b51c9c2eff4867e2a9a70194091

8373945: Use WB.fullGC() in ClassUnloader.unloadClass to force GC for vmTestbase tests

Reviewed-by: cjplummer, lmesnik

! test/hotspot/jtreg/vmTestbase/gc/gctests/LargeObjects/large001/large001.java
! test/hotspot/jtreg/vmTestbase/gc/gctests/LargeObjects/large002/TestDescription.java
! test/hotspot/jtreg/vmTestbase/gc/gctests/LargeObjects/large003/TestDescription.java
! test/hotspot/jtreg/vmTestbase/gc/gctests/LargeObjects/large004/TestDescription.java
! test/hotspot/jtreg/vmTestbase/gc/gctests/LargeObjects/large005/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassObjectReference/reflectedType/reflectype002/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassUnloadEvent/className/classname001/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassUnloadEvent/classSignature/signature001/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassUnloadRequest/addClassExclusionFilter/exclfilter001/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassUnloadRequest/addClassFilter/filter001/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/allFields/allfields003/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/allMethods/allmethods003/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/classObject/classobj002/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/equals/equals002/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/failedToInitialize/failedtoinit002/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/fieldByName/fieldbyname003/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/fields/fields003/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/hashCode/hashcode002/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/isAbstract/isabstract002/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/isInitialized/isinit002/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/isPrepared/isprepared002/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/isVerified/isverified002/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/methods/methods003/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/methodsByName_s/methbyname_s003/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/methodsByName_ss/methbyname_ss003/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/name/name002/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/sourceName/sourcename002/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/visibleFields/visibfield003/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/visibleMethods/visibmethod003/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/instanceCounts/instancecounts003/instancecounts003.java
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ObjectFree/objfree001/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t005/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM07/em07t002/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/extension/EX03/ex03t001/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/load001/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/load002/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/load003/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/load004/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/load005/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/load006/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/load007/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/load008/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/load009/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/load010/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/load011/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/load012/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/unload001/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/unload002/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/unload003/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/unload004/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/unload005/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/unload006/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/unload007/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/unload008/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/unload009/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/unload010/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/unload011/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/unload012/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java

Changeset: 2b1e11c2
Branch: fibers
Author:    SendaoYan <syan at openjdk.org>
Date:      2026-01-15 02:46:20 +0000
URL:       https://git.openjdk.org/loom/commit/2b1e11c2541f799142bd71e9526cbd04743c6f4e

8374879: NMethodRelocationTest fails with -Xcomp after 8369150

Reviewed-by: lmesnik, chagedorn

! test/hotspot/jtreg/serviceability/jvmti/NMethodRelocation/NMethodRelocationTest.java

Changeset: 499b5882
Branch: fibers
Author:    Alexander Matveev <almatvee at openjdk.org>
Date:      2026-01-15 03:53:53 +0000
URL:       https://git.openjdk.org/loom/commit/499b58820225eb96c728816af9ea2ade47d1fc6b

8374215: [macos] Clean and fix "lic_template.plist" to correctly work with multiple languages

Reviewed-by: asemenyuk

+ src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacDmgLicense.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacDmgPackager.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources.properties
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_de.properties
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_ja.properties
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_zh_CN.properties
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/lic_template.plist
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/Executor.java
! test/jdk/tools/jpackage/share/LicenseTest.java

Changeset: b6b33792
Branch: fibers
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2026-01-15 05:58:18 +0000
URL:       https://git.openjdk.org/loom/commit/b6b337926d5f13ee2bca12ea94530ea59911ff2f

8371762: Incorrect use of checked_cast in Arguments::process_settings_file

Reviewed-by: dholmes, kbarrett

! src/hotspot/share/runtime/arguments.cpp

Changeset: d16a9b2e
Branch: fibers
Author:    Galder Zamarre?o <galder at openjdk.org>
Committer: Emanuel Peter <epeter at openjdk.org>
Date:      2026-01-15 07:22:54 +0000
URL:       https://git.openjdk.org/loom/commit/d16a9b2ec507251a44f034f1ccf8039f02023d52

8373134: C2: Min/Max users of Min/Max uses should be enqueued for GVN

Reviewed-by: epeter, bmaillard, dlong

! src/hotspot/share/opto/addnode.cpp
! src/hotspot/share/opto/addnode.hpp
! src/hotspot/share/opto/loopnode.cpp
! src/hotspot/share/opto/macro.cpp
! src/hotspot/share/opto/movenode.cpp
! src/hotspot/share/opto/node.hpp
! src/hotspot/share/opto/phaseX.cpp
! src/hotspot/share/opto/vectorization.cpp
+ test/hotspot/jtreg/compiler/igvn/TestMinMaxIdentity.java

Changeset: f6d26c6b
Branch: fibers
Author:    Manuel H?ssig <mhaessig at openjdk.org>
Date:      2026-01-15 07:50:52 +0000
URL:       https://git.openjdk.org/loom/commit/f6d26c6b32a3ea394cc9b7f6046cd9d7d635c568

8354853: Clean up x86 registers after 32-bit x86 removal

Reviewed-by: aph, shade, mchevalier

! src/hotspot/cpu/x86/register_x86.cpp
! src/hotspot/cpu/x86/register_x86.hpp
! src/hotspot/cpu/x86/vmreg_x86.cpp
! src/hotspot/cpu/x86/vmreg_x86.hpp
! src/hotspot/cpu/x86/vmreg_x86.inline.hpp

Changeset: bf0da3dd
Branch: fibers
Author:    Stefan Karlsson <stefank at openjdk.org>
Date:      2026-01-15 09:22:42 +0000
URL:       https://git.openjdk.org/loom/commit/bf0da3dd5c20410aceab8e6f7a7a31432d17b96d

8375040: Clearer names for non-metadata oop iterators in ObjArrayKlass

Reviewed-by: tschatzl, kbarrett, aboldtch

! src/hotspot/share/gc/g1/g1FullGCMarker.inline.hpp
! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp
! src/hotspot/share/gc/serial/serialFullGC.cpp
! src/hotspot/share/gc/shenandoah/shenandoahMark.inline.hpp
! src/hotspot/share/gc/z/zHeapIterator.cpp
! src/hotspot/share/gc/z/zIterator.hpp
! src/hotspot/share/gc/z/zIterator.inline.hpp
! src/hotspot/share/oops/objArrayKlass.hpp
! src/hotspot/share/oops/objArrayKlass.inline.hpp
! src/hotspot/share/oops/objArrayOop.hpp
! src/hotspot/share/oops/objArrayOop.inline.hpp

Changeset: f6e5c885
Branch: fibers
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-15 11:16:00 +0000
URL:       https://git.openjdk.org/loom/commit/f6e5c885e7ca90da2f9fd9ec1c00b4a955ccdf29

8375282: G1: Fix wrong indendation introduced by JDK-8374743

Reviewed-by: kbarrett

! src/hotspot/share/gc/g1/g1CollectedHeap.cpp

Changeset: 8ad8920a
Branch: fibers
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2026-01-15 12:37:50 +0000
URL:       https://git.openjdk.org/loom/commit/8ad8920aae5c27de947532ba3cd2b57213208d1e

8374984: Convert workerUtils to use Atomic<T>

Reviewed-by: shade, stefank

! src/hotspot/share/gc/shared/workerUtils.cpp
! src/hotspot/share/gc/shared/workerUtils.hpp

Changeset: 78a106ff
Branch: fibers
Author:    Artur Barashev <abarashev at openjdk.org>
Date:      2026-01-15 13:18:20 +0000
URL:       https://git.openjdk.org/loom/commit/78a106ffbba0e056e7421ca9d77af02f9b8379d3

8375183: Remove unused SSLConfiguration.maximumProtocolVersion variable

Reviewed-by: djelinski, myankelevich, hchao

! src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java
! src/java.base/share/classes/sun/security/ssl/TransportContext.java

Changeset: 203eb701
Branch: fibers
Author:    Roger Riggs <rriggs at openjdk.org>
Date:      2026-01-15 15:54:11 +0000
URL:       https://git.openjdk.org/loom/commit/203eb70110dd546784e03243bf98ff3ddb407030

8291986: ProcessBuilder.redirectErrorStream(true) leaves error stream available

Reviewed-by: jpai

! src/java.base/unix/native/libjava/ProcessImpl_md.c
! test/jdk/java/lang/ProcessBuilder/PipelineLeaksFD.java
= test/jdk/java/lang/ProcessBuilder/TEST.properties

Changeset: ee0387be
Branch: fibers
Author:    Roger Calnan <roger.calnan at oracle.com>
Committer: Roger Riggs <rriggs at openjdk.org>
Date:      2026-01-15 17:08:49 +0000
URL:       https://git.openjdk.org/loom/commit/ee0387be4c562c7f7ad5240f412d4d5363358855

8375342: jdk/javadoc/doccheck/checks/jdkCheckHtml.java failed with duplicate anchors

Reviewed-by: alanb, iris

! src/java.base/share/man/java.md

Changeset: 34705a77
Branch: fibers
Author:    Justin Lu <jlu at openjdk.org>
Date:      2026-01-15 17:38:46 +0000
URL:       https://git.openjdk.org/loom/commit/34705a77f9a90da5ab2a440c11d79aef7bb3ba54

8375231: Refactor util/ServiceLoader tests to use JUnit
8375232: Refactor util/StringJoiner tests to use JUnit
8375233: Refactor util/Vector tests to use JUnit

Reviewed-by: naoto, alanb

! test/jdk/java/util/ServiceLoader/BadProvidersTest.java
! test/jdk/java/util/ServiceLoader/CachingTest.java
! test/jdk/java/util/ServiceLoader/ModulesTest.java
! test/jdk/java/util/ServiceLoader/NoInterferenceTest.java
! test/jdk/java/util/ServiceLoader/ReloadTest.java
! test/jdk/java/util/ServiceLoader/TwoIterators.java
! test/jdk/java/util/ServiceLoader/basic/ServiceLoaderBasicTest.java
! test/jdk/java/util/StringJoiner/MergeTest.java
! test/jdk/java/util/StringJoiner/StringJoinerOomUtf16Test.java
! test/jdk/java/util/StringJoiner/StringJoinerTest.java
! test/jdk/java/util/Vector/ArrayManagement.java

Changeset: 3f01e8b9
Branch: fibers
Author:    Kirill Shirokov <kirshiro at amazon.com>
Committer: Sergey Bylokhov <serb at openjdk.org>
Date:      2026-01-15 18:52:44 +0000
URL:       https://git.openjdk.org/loom/commit/3f01e8b9b8f68560545540f9a70391a7ff7726d0

8366522: CodeSource.getCodeSigners() throws NPE within empty certs

Reviewed-by: mullan

! src/java.base/share/classes/java/security/CodeSource.java
+ test/jdk/java/security/CodeSource/CodeSourceNoInputs.java

Changeset: e97fb0e2
Branch: fibers
Author:    Koushik Thirupattur <koushik.thirupattur at oracle.com>
Committer: Valerie Peng <valeriep at openjdk.org>
Date:      2026-01-15 19:01:24 +0000
URL:       https://git.openjdk.org/loom/commit/e97fb0e2072a16c59014599719b64e8ea52a4976

8367024: JNI exception pending in Java_sun_security_pkcs11_wrapper_PKCS11_C_1DeriveKey of p11_keymgmt.c:950

Reviewed-by: valeriep, hchao, djelinski

! src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_keymgmt.c

Changeset: 25c834a8
Branch: fibers
Author:    Koushik Thirupattur <koushik.thirupattur at oracle.com>
Committer: Valerie Peng <valeriep at openjdk.org>
Date:      2026-01-15 19:05:19 +0000
URL:       https://git.openjdk.org/loom/commit/25c834a897ac0cac94942a019c9e377a53851f2c

8366807: JNI exception pending in Java_sun_security_pkcs11_wrapper_PKCS11_initializeLibrary of p11_general.c:106

Reviewed-by: valeriep

! src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_general.c

Changeset: a8b845e0
Branch: fibers
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2026-01-15 19:14:46 +0000
URL:       https://git.openjdk.org/loom/commit/a8b845e08ce2f1fbe7d807cd963cb6b5e4df5ce6

8374445: Fix -Wzero-as-null-pointer-constant warnings in JfrSet

Reviewed-by: mgronlun

! src/hotspot/share/jfr/utilities/jfrSet.hpp

Changeset: 30cda000
Branch: fibers
Author:    Brian Burkhalter <bpb at openjdk.org>
Date:      2026-01-15 19:31:11 +0000
URL:       https://git.openjdk.org/loom/commit/30cda00010888b6e9a2bf8cdeaedbb3eb4b6a222

8375294: (fs) Files.copy can fail with EOPNOTSUPP when copy_file_range not supported

Reviewed-by: alanb, jpai

! src/java.base/linux/native/libnio/ch/FileDispatcherImpl.c
! src/java.base/linux/native/libnio/fs/LinuxNativeDispatcher.c

Changeset: a1b039aa
Branch: fibers
Author:    Hai-May Chao <hchao at openjdk.org>
Date:      2026-01-15 22:33:34 +0000
URL:       https://git.openjdk.org/loom/commit/a1b039aa989ca91b6e70962363f720f581c5bfaf

8286032: keytool -list -alias should not assume it is always a certificate

Reviewed-by: weijun

! src/java.base/share/classes/sun/security/tools/keytool/Main.java
+ test/jdk/sun/security/tools/keytool/ListAlias.java
! test/jdk/sun/security/tools/keytool/WeakAlg.java

Changeset: 87cbcada
Branch: fibers
Author:    William Kemper <wkemper at openjdk.org>
Date:      2026-01-15 22:35:49 +0000
URL:       https://git.openjdk.org/loom/commit/87cbcadacfa20b24e9ba0bf8374ecbcd331d2b35

8351892: GenShen: Remove vestigial young generation sizing options

Reviewed-by: kdnilsen, ysr

! src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp

Changeset: 1d889b92
Branch: fibers
Author:    Volodymyr Paprotski <vpaprotski at openjdk.org>
Date:      2026-01-15 23:11:12 +0000
URL:       https://git.openjdk.org/loom/commit/1d889b92bde5dfcb1fbe6cddb389a77f92eb1ce7

8360271: String.indexOf intrinsics fail with +EnableX86ECoreOpts and -CompactStrings

Reviewed-by: thartmann, jbhateja, sviswanathan

! src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp
! test/jdk/java/lang/String/IndexOf.java

Changeset: fddba3b7
Branch: fibers
Author:    Phil Race <prr at openjdk.org>
Date:      2026-01-16 00:47:24 +0000
URL:       https://git.openjdk.org/loom/commit/fddba3b7ecb11136e9699861b5d86aeb3d481be6

8375350: Remove usage of AppContext from javax.imageio implementation

Reviewed-by: kizune, dnguyen

! src/java.desktop/share/classes/javax/imageio/ImageIO.java

Changeset: 9876875e
Branch: fibers
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
Date:      2026-01-16 02:51:40 +0000
URL:       https://git.openjdk.org/loom/commit/9876875e37b5cd4ac5263007ff96611ab0707cd5

8375364: [macos] Some jpackage signing tests fail after JDK-8375240

Reviewed-by: almatvee

! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java

Changeset: e4474ad8
Branch: fibers
Author:    SendaoYan <syan at openjdk.org>
Date:      2026-01-16 03:19:28 +0000
URL:       https://git.openjdk.org/loom/commit/e4474ad8ae250771e031b8c18809d3e461970365

8375367: vmTestbase tests reported variable uninitialized by clang23

Reviewed-by: sspitsyn, amenkov, lmesnik

! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t002/ma04t002.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t002/ma04t002a.cpp

Changeset: fda8d050
Branch: fibers
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-16 07:48:26 +0000
URL:       https://git.openjdk.org/loom/commit/fda8d0506a511c00e65c3f97aaaf6f018945b213

8375455: G1: Remove unused G1HeapRegionStats::coarsen_stats()

Reviewed-by: kbarrett

! src/hotspot/share/gc/g1/g1CardSet.cpp
! src/hotspot/share/gc/g1/g1HeapRegionRemSet.hpp

Changeset: 5664d914
Branch: fibers
Author:    Richard Reingruber <rrich at openjdk.org>
Date:      2026-01-16 08:01:40 +0000
URL:       https://git.openjdk.org/loom/commit/5664d9148401934cd26308dc4493f4a5656e89bd

8374769: PPC: MASM::pop_cont_fastpath() should reset _cont_fastpath if SP == _cont_fastpath

Reviewed-by: mdoerr

! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp

Changeset: b7346c30
Branch: fibers
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2026-01-16 08:03:55 +0000
URL:       https://git.openjdk.org/loom/commit/b7346c307fc1aba01c10fc6dc745e5e520b1d7b9

8375311: Some builds are missing debug helpers

Reviewed-by: mdoerr, aph

! src/hotspot/share/utilities/debug.cpp

Changeset: e7432d57
Branch: fibers
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
Date:      2026-01-16 20:03:00 +0000
URL:       https://git.openjdk.org/loom/commit/e7432d574540109e2c4faca11cf49d9272a147e6

8375323: Improve handling of the "--app-content" and "--input" options in jpackage

Reviewed-by: almatvee

! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxPackager.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/AppImageSigner.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacApplicationBuilder.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacDmgPackageBuilder.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacDmgPackager.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacFromOptions.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacPkgPackager.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/model/MacDmgPackageMixin.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/ApplicationBuilder.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/ApplicationImageUtils.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/DefaultBundlingEnvironment.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/FromOptions.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/LauncherFromOptions.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/PackagingPipeline.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/JOptSimpleOptionsBuilder.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/OptionArrayValueConverter.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/OptionSpec.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/OptionSpecBuilder.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/OptionSpecMapperOptionScope.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/OptionValueConverter.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/OptionsAnalyzer.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/OptionsProcessor.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardAppImageFileOption.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardOption.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardValueConverter.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/Validator.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/ValueConverter.java
+ src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/ValueConverterFunction.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/Application.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources.properties
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/FileUtils.java
+ src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/RootedPath.java
! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinExePackager.java
! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiPackager.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/AppImageFileTest.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/PackagingPipelineTest.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/OptionSpecMutatorOptionScopeTest.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/OptionSpecTest.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/OptionValueConverterTest.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/StandardOptionTest.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/StandardValueConverterTest.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/util/FileUtilsTest.java
! test/jdk/tools/jpackage/junit/tools/jdk/jpackage/test/JUnitUtils.java
! test/jdk/tools/jpackage/share/AppContentTest.java
! test/jdk/tools/jpackage/share/InOutPathTest.java

Changeset: 9b47c23b
Branch: fibers
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
Date:      2026-01-16 23:16:43 +0000
URL:       https://git.openjdk.org/loom/commit/9b47c23b4b809f7070c6c8279b7ffdf83234dcdb

8375242: [macos] Improve jpackage signing coverage

Reviewed-by: almatvee

! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacHelper.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacSign.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacSignVerify.java
! test/jdk/tools/jpackage/macosx/EntitlementsTest.java
! test/jdk/tools/jpackage/macosx/MacSignTest.java
! test/jdk/tools/jpackage/macosx/SigningAppImageTest.java
! test/jdk/tools/jpackage/macosx/SigningAppImageTwoStepsTest.java
+ test/jdk/tools/jpackage/macosx/SigningBase.java
! test/jdk/tools/jpackage/macosx/SigningPackageTest.java
! test/jdk/tools/jpackage/macosx/SigningPackageTwoStepTest.java
! test/jdk/tools/jpackage/macosx/SigningRuntimeImagePackageTest.java
- test/jdk/tools/jpackage/macosx/base/SigningBase.java

Changeset: 0dd5b591
Branch: fibers
Author:    SendaoYan <syan at openjdk.org>
Date:      2026-01-17 04:30:02 +0000
URL:       https://git.openjdk.org/loom/commit/0dd5b59194f32f54c2ec6572833f45e1402515ba

8375370: XRBackendNative.c reported variable uninitialized by clang23

Reviewed-by: prr

! src/java.desktop/unix/native/libawt_xawt/java2d/x11/XRBackendNative.c

Changeset: 436c62af
Branch: fibers
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
Date:      2026-01-17 06:24:31 +0000
URL:       https://git.openjdk.org/loom/commit/436c62afd285a3ce2be9aef59876df4b9f0955ff

8373867: Improve robustness of Attach API for finding tmp directory

Reviewed-by: sspitsyn, amenkov

! src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java
! src/jdk.attach/share/classes/com/sun/tools/attach/AttachNotSupportedException.java
+ test/jdk/com/sun/tools/attach/TestWithoutDumpableProcess.java

Changeset: 6a16d8d5
Branch: fibers
Author:    Alan Bateman <alan.bateman at oracle.com>
Date:      2026-01-17 12:03:45 +0000
URL:       https://git.openjdk.org/loom/commit/6a16d8d50b9e7c4a8fffc30a2a615d29dba12994

Merge branch 'master' into fibers


Changeset: e8f3883e
Branch: fibers
Author:    Alan Bateman <alan.bateman at oracle.com>
Date:      2026-01-17 12:02:38 +0000
URL:       https://git.openjdk.org/loom/commit/e8f3883eabf8a8beca4cd3d6f54b941af438ce8b

Make VirtualThreadScheduler.newThread default method

! src/java.base/share/classes/java/lang/System.java
! src/java.base/share/classes/java/lang/Thread.java
! src/java.base/share/classes/java/lang/ThreadBuilders.java
! src/java.base/share/classes/java/lang/VirtualThread.java
! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java
! src/java.base/share/classes/sun/nio/ch/Poller.java
! test/jdk/java/foreign/TestRestricted.java
! test/jdk/java/lang/Thread/virtual/CustomDefaultScheduler.java
! test/jdk/java/lang/Thread/virtual/CustomScheduler.java
! test/jdk/java/nio/channels/vthread/BlockingChannelOps.java
! test/lib/jdk/test/lib/thread/VThreadScheduler.java

Changeset: c5d6ac34
Branch: fibers
Author:    Alan Bateman <alan.bateman at oracle.com>
Date:      2026-01-17 12:03:51 +0000
URL:       https://git.openjdk.org/loom/commit/c5d6ac340b6e6a05f3af414197c836ff86880c6c

Merge loom into fibers


Changeset: 05c625f0
Branch: fibers
Author:    Alan Bateman <alan.bateman at oracle.com>
Date:      2026-01-17 14:08:00 +0000
URL:       https://git.openjdk.org/loom/commit/05c625f032772c92e7634ca50cacf1cae4926d88

AttachNotSupportedException missing @since 27

! src/jdk.attach/share/classes/com/sun/tools/attach/AttachNotSupportedException.java


From duke at openjdk.org  Sat Jan 17 14:14:56 2026
From: duke at openjdk.org (duke)
Date: Sat, 17 Jan 2026 14:14:56 GMT
Subject: git: openjdk/loom: master: 37 new changesets
Message-ID: <8b5ab5af-9cc9-4a2c-9dee-e0af035af8cb@openjdk.org>

Changeset: 60fbaf5b
Branch: master
Author:    Coleen Phillimore <coleenp at openjdk.org>
Date:      2026-01-14 18:53:10 +0000
URL:       https://git.openjdk.org/loom/commit/60fbaf5b26d7d359b1258898d4c4dfd86010b8a5

8374828: Save load_barrier_on_oop_field_preloaded in aot CodeCache

Reviewed-by: adinn, iklam, shade

! src/hotspot/share/code/aotCodeCache.cpp

Changeset: a7507ffa
Branch: master
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2026-01-14 19:26:45 +0000
URL:       https://git.openjdk.org/loom/commit/a7507ffa1dda403110a61c4b61143b76e8a7911e

8375237: Document existing exceptional behavior of divideUnsigned and remainderUnsigned

Reviewed-by: rgiulietti

! src/java.base/share/classes/java/lang/Integer.java
! src/java.base/share/classes/java/lang/Long.java

Changeset: 3007365b
Branch: master
Author:    Roger Riggs <rriggs at openjdk.org>
Date:      2026-01-14 19:27:10 +0000
URL:       https://git.openjdk.org/loom/commit/3007365b73d400ee6a5ea9a9041899bb81cf357a

8373913: Refactor serialization tests to use JUnit

Reviewed-by: jlu, naoto

! test/jdk/java/io/Serializable/GetField/ReadFieldsCNF.java
! test/jdk/java/io/Serializable/class/NonSerializableTest.java
! test/jdk/java/io/Serializable/records/RecordClassTest.java
! test/jdk/java/io/Serializable/records/SerialVersionUIDTest.java
! test/jdk/java/io/Serializable/serialFilter/CheckArrayTest.java
! test/jdk/java/io/Serializable/serialFilter/CheckInputOrderTest.java
! test/jdk/java/io/Serializable/serialFilter/GlobalFilterTest.java
! test/jdk/java/io/Serializable/serialFilter/InvalidGlobalFilterTest.java
! test/jdk/java/io/Serializable/serialFilter/MixedFiltersTest.java
! test/jdk/java/io/Serializable/serialFilter/SerialFactoryExample.java
! test/jdk/java/io/Serializable/serialFilter/SerialFactoryFaults.java
! test/jdk/java/io/Serializable/serialFilter/SerialFilterFactoryTest.java
! test/jdk/java/io/Serializable/serialFilter/SerialFilterFunctionTest.java
! test/jdk/java/io/Serializable/serialFilter/SerialFilterTest.java

Changeset: 6ad9f4ef
Branch: master
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2026-01-14 21:27:34 +0000
URL:       https://git.openjdk.org/loom/commit/6ad9f4ef6826bb031db7840ba3f689b0bde47775

8374493: Add missing @Override annotations in "com.sun.java.swing.plaf.motif" package

Reviewed-by: tr, prr, aivanov

! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifBorders.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifButtonListener.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifButtonUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifCheckBoxMenuItemUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifCheckBoxUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifComboBoxUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifDesktopIconUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifDesktopPaneUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifEditorPaneUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifFileChooserUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifIconFactory.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifInternalFrameTitlePane.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifInternalFrameUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifLookAndFeel.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifMenuItemUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifMenuMouseListener.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifMenuMouseMotionListener.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifMenuUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifOptionPaneUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifPasswordFieldUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifPopupMenuSeparatorUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifPopupMenuUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifRadioButtonMenuItemUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifRadioButtonUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifScrollBarButton.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifScrollBarUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifSliderUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifSplitPaneDivider.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifSplitPaneUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifTabbedPaneUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifTextAreaUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifTextFieldUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifTextPaneUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifTextUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifToggleButtonUI.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifTreeCellRenderer.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifTreeUI.java

Changeset: fb526c8f
Branch: master
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
Date:      2026-01-14 21:37:44 +0000
URL:       https://git.openjdk.org/loom/commit/fb526c8f45de6ca9a57608f728ac223cbca118be

8373001: LauncherFromOptions.create() not properly handling FileAssociationNoExtensionsException

Reviewed-by: almatvee

! src/jdk.jpackage/share/classes/jdk/jpackage/internal/LauncherFromOptions.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources.properties

Changeset: d8f45faf
Branch: master
Author:    SendaoYan <syan at openjdk.org>
Date:      2026-01-15 02:40:36 +0000
URL:       https://git.openjdk.org/loom/commit/d8f45faf5849e66b8f0e35e1d18ed0331a0cb1c2

8374432: TimeoutResponseBodyTest.java#retriesEnabledForResponseFailure fails run with -Xcomp

Reviewed-by: vyazici, dfuchs

! test/jdk/java/net/httpclient/TimeoutResponseTestSupport.java

Changeset: ce5e0d8a
Branch: master
Author:    SendaoYan <syan at openjdk.org>
Date:      2026-01-15 02:44:16 +0000
URL:       https://git.openjdk.org/loom/commit/ce5e0d8a48296b51c9c2eff4867e2a9a70194091

8373945: Use WB.fullGC() in ClassUnloader.unloadClass to force GC for vmTestbase tests

Reviewed-by: cjplummer, lmesnik

! test/hotspot/jtreg/vmTestbase/gc/gctests/LargeObjects/large001/large001.java
! test/hotspot/jtreg/vmTestbase/gc/gctests/LargeObjects/large002/TestDescription.java
! test/hotspot/jtreg/vmTestbase/gc/gctests/LargeObjects/large003/TestDescription.java
! test/hotspot/jtreg/vmTestbase/gc/gctests/LargeObjects/large004/TestDescription.java
! test/hotspot/jtreg/vmTestbase/gc/gctests/LargeObjects/large005/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassObjectReference/reflectedType/reflectype002/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassUnloadEvent/className/classname001/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassUnloadEvent/classSignature/signature001/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassUnloadRequest/addClassExclusionFilter/exclfilter001/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ClassUnloadRequest/addClassFilter/filter001/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/allFields/allfields003/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/allMethods/allmethods003/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/classObject/classobj002/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/equals/equals002/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/failedToInitialize/failedtoinit002/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/fieldByName/fieldbyname003/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/fields/fields003/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/hashCode/hashcode002/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/isAbstract/isabstract002/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/isInitialized/isinit002/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/isPrepared/isprepared002/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/isVerified/isverified002/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/methods/methods003/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/methodsByName_s/methbyname_s003/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/methodsByName_ss/methbyname_ss003/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/name/name002/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/sourceName/sourcename002/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/visibleFields/visibfield003/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ReferenceType/visibleMethods/visibmethod003/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/instanceCounts/instancecounts003/instancecounts003.java
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001.java
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/CompiledMethodUnload/compmethunload001/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ObjectFree/objfree001/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t005/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM07/em07t002/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/extension/EX03/ex03t001/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/load001/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/load002/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/load003/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/load004/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/load005/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/load006/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/load007/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/load008/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/load009/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/load010/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/load011/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/load012/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/unload001/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/unload002/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/unload003/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/unload004/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/unload005/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/unload006/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/unload007/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/unload008/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/unload009/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/unload010/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/unload011/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/monitoring/stress/classload/unload012/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java

Changeset: 2b1e11c2
Branch: master
Author:    SendaoYan <syan at openjdk.org>
Date:      2026-01-15 02:46:20 +0000
URL:       https://git.openjdk.org/loom/commit/2b1e11c2541f799142bd71e9526cbd04743c6f4e

8374879: NMethodRelocationTest fails with -Xcomp after 8369150

Reviewed-by: lmesnik, chagedorn

! test/hotspot/jtreg/serviceability/jvmti/NMethodRelocation/NMethodRelocationTest.java

Changeset: 499b5882
Branch: master
Author:    Alexander Matveev <almatvee at openjdk.org>
Date:      2026-01-15 03:53:53 +0000
URL:       https://git.openjdk.org/loom/commit/499b58820225eb96c728816af9ea2ade47d1fc6b

8374215: [macos] Clean and fix "lic_template.plist" to correctly work with multiple languages

Reviewed-by: asemenyuk

+ src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacDmgLicense.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacDmgPackager.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources.properties
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_de.properties
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_ja.properties
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_zh_CN.properties
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/lic_template.plist
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/Executor.java
! test/jdk/tools/jpackage/share/LicenseTest.java

Changeset: b6b33792
Branch: master
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2026-01-15 05:58:18 +0000
URL:       https://git.openjdk.org/loom/commit/b6b337926d5f13ee2bca12ea94530ea59911ff2f

8371762: Incorrect use of checked_cast in Arguments::process_settings_file

Reviewed-by: dholmes, kbarrett

! src/hotspot/share/runtime/arguments.cpp

Changeset: d16a9b2e
Branch: master
Author:    Galder Zamarre?o <galder at openjdk.org>
Committer: Emanuel Peter <epeter at openjdk.org>
Date:      2026-01-15 07:22:54 +0000
URL:       https://git.openjdk.org/loom/commit/d16a9b2ec507251a44f034f1ccf8039f02023d52

8373134: C2: Min/Max users of Min/Max uses should be enqueued for GVN

Reviewed-by: epeter, bmaillard, dlong

! src/hotspot/share/opto/addnode.cpp
! src/hotspot/share/opto/addnode.hpp
! src/hotspot/share/opto/loopnode.cpp
! src/hotspot/share/opto/macro.cpp
! src/hotspot/share/opto/movenode.cpp
! src/hotspot/share/opto/node.hpp
! src/hotspot/share/opto/phaseX.cpp
! src/hotspot/share/opto/vectorization.cpp
+ test/hotspot/jtreg/compiler/igvn/TestMinMaxIdentity.java

Changeset: f6d26c6b
Branch: master
Author:    Manuel H?ssig <mhaessig at openjdk.org>
Date:      2026-01-15 07:50:52 +0000
URL:       https://git.openjdk.org/loom/commit/f6d26c6b32a3ea394cc9b7f6046cd9d7d635c568

8354853: Clean up x86 registers after 32-bit x86 removal

Reviewed-by: aph, shade, mchevalier

! src/hotspot/cpu/x86/register_x86.cpp
! src/hotspot/cpu/x86/register_x86.hpp
! src/hotspot/cpu/x86/vmreg_x86.cpp
! src/hotspot/cpu/x86/vmreg_x86.hpp
! src/hotspot/cpu/x86/vmreg_x86.inline.hpp

Changeset: bf0da3dd
Branch: master
Author:    Stefan Karlsson <stefank at openjdk.org>
Date:      2026-01-15 09:22:42 +0000
URL:       https://git.openjdk.org/loom/commit/bf0da3dd5c20410aceab8e6f7a7a31432d17b96d

8375040: Clearer names for non-metadata oop iterators in ObjArrayKlass

Reviewed-by: tschatzl, kbarrett, aboldtch

! src/hotspot/share/gc/g1/g1FullGCMarker.inline.hpp
! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp
! src/hotspot/share/gc/serial/serialFullGC.cpp
! src/hotspot/share/gc/shenandoah/shenandoahMark.inline.hpp
! src/hotspot/share/gc/z/zHeapIterator.cpp
! src/hotspot/share/gc/z/zIterator.hpp
! src/hotspot/share/gc/z/zIterator.inline.hpp
! src/hotspot/share/oops/objArrayKlass.hpp
! src/hotspot/share/oops/objArrayKlass.inline.hpp
! src/hotspot/share/oops/objArrayOop.hpp
! src/hotspot/share/oops/objArrayOop.inline.hpp

Changeset: f6e5c885
Branch: master
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-15 11:16:00 +0000
URL:       https://git.openjdk.org/loom/commit/f6e5c885e7ca90da2f9fd9ec1c00b4a955ccdf29

8375282: G1: Fix wrong indendation introduced by JDK-8374743

Reviewed-by: kbarrett

! src/hotspot/share/gc/g1/g1CollectedHeap.cpp

Changeset: 8ad8920a
Branch: master
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2026-01-15 12:37:50 +0000
URL:       https://git.openjdk.org/loom/commit/8ad8920aae5c27de947532ba3cd2b57213208d1e

8374984: Convert workerUtils to use Atomic<T>

Reviewed-by: shade, stefank

! src/hotspot/share/gc/shared/workerUtils.cpp
! src/hotspot/share/gc/shared/workerUtils.hpp

Changeset: 78a106ff
Branch: master
Author:    Artur Barashev <abarashev at openjdk.org>
Date:      2026-01-15 13:18:20 +0000
URL:       https://git.openjdk.org/loom/commit/78a106ffbba0e056e7421ca9d77af02f9b8379d3

8375183: Remove unused SSLConfiguration.maximumProtocolVersion variable

Reviewed-by: djelinski, myankelevich, hchao

! src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java
! src/java.base/share/classes/sun/security/ssl/TransportContext.java

Changeset: 203eb701
Branch: master
Author:    Roger Riggs <rriggs at openjdk.org>
Date:      2026-01-15 15:54:11 +0000
URL:       https://git.openjdk.org/loom/commit/203eb70110dd546784e03243bf98ff3ddb407030

8291986: ProcessBuilder.redirectErrorStream(true) leaves error stream available

Reviewed-by: jpai

! src/java.base/unix/native/libjava/ProcessImpl_md.c
! test/jdk/java/lang/ProcessBuilder/PipelineLeaksFD.java
= test/jdk/java/lang/ProcessBuilder/TEST.properties

Changeset: ee0387be
Branch: master
Author:    Roger Calnan <roger.calnan at oracle.com>
Committer: Roger Riggs <rriggs at openjdk.org>
Date:      2026-01-15 17:08:49 +0000
URL:       https://git.openjdk.org/loom/commit/ee0387be4c562c7f7ad5240f412d4d5363358855

8375342: jdk/javadoc/doccheck/checks/jdkCheckHtml.java failed with duplicate anchors

Reviewed-by: alanb, iris

! src/java.base/share/man/java.md

Changeset: 34705a77
Branch: master
Author:    Justin Lu <jlu at openjdk.org>
Date:      2026-01-15 17:38:46 +0000
URL:       https://git.openjdk.org/loom/commit/34705a77f9a90da5ab2a440c11d79aef7bb3ba54

8375231: Refactor util/ServiceLoader tests to use JUnit
8375232: Refactor util/StringJoiner tests to use JUnit
8375233: Refactor util/Vector tests to use JUnit

Reviewed-by: naoto, alanb

! test/jdk/java/util/ServiceLoader/BadProvidersTest.java
! test/jdk/java/util/ServiceLoader/CachingTest.java
! test/jdk/java/util/ServiceLoader/ModulesTest.java
! test/jdk/java/util/ServiceLoader/NoInterferenceTest.java
! test/jdk/java/util/ServiceLoader/ReloadTest.java
! test/jdk/java/util/ServiceLoader/TwoIterators.java
! test/jdk/java/util/ServiceLoader/basic/ServiceLoaderBasicTest.java
! test/jdk/java/util/StringJoiner/MergeTest.java
! test/jdk/java/util/StringJoiner/StringJoinerOomUtf16Test.java
! test/jdk/java/util/StringJoiner/StringJoinerTest.java
! test/jdk/java/util/Vector/ArrayManagement.java

Changeset: 3f01e8b9
Branch: master
Author:    Kirill Shirokov <kirshiro at amazon.com>
Committer: Sergey Bylokhov <serb at openjdk.org>
Date:      2026-01-15 18:52:44 +0000
URL:       https://git.openjdk.org/loom/commit/3f01e8b9b8f68560545540f9a70391a7ff7726d0

8366522: CodeSource.getCodeSigners() throws NPE within empty certs

Reviewed-by: mullan

! src/java.base/share/classes/java/security/CodeSource.java
+ test/jdk/java/security/CodeSource/CodeSourceNoInputs.java

Changeset: e97fb0e2
Branch: master
Author:    Koushik Thirupattur <koushik.thirupattur at oracle.com>
Committer: Valerie Peng <valeriep at openjdk.org>
Date:      2026-01-15 19:01:24 +0000
URL:       https://git.openjdk.org/loom/commit/e97fb0e2072a16c59014599719b64e8ea52a4976

8367024: JNI exception pending in Java_sun_security_pkcs11_wrapper_PKCS11_C_1DeriveKey of p11_keymgmt.c:950

Reviewed-by: valeriep, hchao, djelinski

! src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_keymgmt.c

Changeset: 25c834a8
Branch: master
Author:    Koushik Thirupattur <koushik.thirupattur at oracle.com>
Committer: Valerie Peng <valeriep at openjdk.org>
Date:      2026-01-15 19:05:19 +0000
URL:       https://git.openjdk.org/loom/commit/25c834a897ac0cac94942a019c9e377a53851f2c

8366807: JNI exception pending in Java_sun_security_pkcs11_wrapper_PKCS11_initializeLibrary of p11_general.c:106

Reviewed-by: valeriep

! src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_general.c

Changeset: a8b845e0
Branch: master
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2026-01-15 19:14:46 +0000
URL:       https://git.openjdk.org/loom/commit/a8b845e08ce2f1fbe7d807cd963cb6b5e4df5ce6

8374445: Fix -Wzero-as-null-pointer-constant warnings in JfrSet

Reviewed-by: mgronlun

! src/hotspot/share/jfr/utilities/jfrSet.hpp

Changeset: 30cda000
Branch: master
Author:    Brian Burkhalter <bpb at openjdk.org>
Date:      2026-01-15 19:31:11 +0000
URL:       https://git.openjdk.org/loom/commit/30cda00010888b6e9a2bf8cdeaedbb3eb4b6a222

8375294: (fs) Files.copy can fail with EOPNOTSUPP when copy_file_range not supported

Reviewed-by: alanb, jpai

! src/java.base/linux/native/libnio/ch/FileDispatcherImpl.c
! src/java.base/linux/native/libnio/fs/LinuxNativeDispatcher.c

Changeset: a1b039aa
Branch: master
Author:    Hai-May Chao <hchao at openjdk.org>
Date:      2026-01-15 22:33:34 +0000
URL:       https://git.openjdk.org/loom/commit/a1b039aa989ca91b6e70962363f720f581c5bfaf

8286032: keytool -list -alias should not assume it is always a certificate

Reviewed-by: weijun

! src/java.base/share/classes/sun/security/tools/keytool/Main.java
+ test/jdk/sun/security/tools/keytool/ListAlias.java
! test/jdk/sun/security/tools/keytool/WeakAlg.java

Changeset: 87cbcada
Branch: master
Author:    William Kemper <wkemper at openjdk.org>
Date:      2026-01-15 22:35:49 +0000
URL:       https://git.openjdk.org/loom/commit/87cbcadacfa20b24e9ba0bf8374ecbcd331d2b35

8351892: GenShen: Remove vestigial young generation sizing options

Reviewed-by: kdnilsen, ysr

! src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp

Changeset: 1d889b92
Branch: master
Author:    Volodymyr Paprotski <vpaprotski at openjdk.org>
Date:      2026-01-15 23:11:12 +0000
URL:       https://git.openjdk.org/loom/commit/1d889b92bde5dfcb1fbe6cddb389a77f92eb1ce7

8360271: String.indexOf intrinsics fail with +EnableX86ECoreOpts and -CompactStrings

Reviewed-by: thartmann, jbhateja, sviswanathan

! src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp
! test/jdk/java/lang/String/IndexOf.java

Changeset: fddba3b7
Branch: master
Author:    Phil Race <prr at openjdk.org>
Date:      2026-01-16 00:47:24 +0000
URL:       https://git.openjdk.org/loom/commit/fddba3b7ecb11136e9699861b5d86aeb3d481be6

8375350: Remove usage of AppContext from javax.imageio implementation

Reviewed-by: kizune, dnguyen

! src/java.desktop/share/classes/javax/imageio/ImageIO.java

Changeset: 9876875e
Branch: master
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
Date:      2026-01-16 02:51:40 +0000
URL:       https://git.openjdk.org/loom/commit/9876875e37b5cd4ac5263007ff96611ab0707cd5

8375364: [macos] Some jpackage signing tests fail after JDK-8375240

Reviewed-by: almatvee

! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java

Changeset: e4474ad8
Branch: master
Author:    SendaoYan <syan at openjdk.org>
Date:      2026-01-16 03:19:28 +0000
URL:       https://git.openjdk.org/loom/commit/e4474ad8ae250771e031b8c18809d3e461970365

8375367: vmTestbase tests reported variable uninitialized by clang23

Reviewed-by: sspitsyn, amenkov, lmesnik

! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t002/ma04t002.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/multienv/MA04/ma04t002/ma04t002a.cpp

Changeset: fda8d050
Branch: master
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-16 07:48:26 +0000
URL:       https://git.openjdk.org/loom/commit/fda8d0506a511c00e65c3f97aaaf6f018945b213

8375455: G1: Remove unused G1HeapRegionStats::coarsen_stats()

Reviewed-by: kbarrett

! src/hotspot/share/gc/g1/g1CardSet.cpp
! src/hotspot/share/gc/g1/g1HeapRegionRemSet.hpp

Changeset: 5664d914
Branch: master
Author:    Richard Reingruber <rrich at openjdk.org>
Date:      2026-01-16 08:01:40 +0000
URL:       https://git.openjdk.org/loom/commit/5664d9148401934cd26308dc4493f4a5656e89bd

8374769: PPC: MASM::pop_cont_fastpath() should reset _cont_fastpath if SP == _cont_fastpath

Reviewed-by: mdoerr

! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp

Changeset: b7346c30
Branch: master
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2026-01-16 08:03:55 +0000
URL:       https://git.openjdk.org/loom/commit/b7346c307fc1aba01c10fc6dc745e5e520b1d7b9

8375311: Some builds are missing debug helpers

Reviewed-by: mdoerr, aph

! src/hotspot/share/utilities/debug.cpp

Changeset: e7432d57
Branch: master
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
Date:      2026-01-16 20:03:00 +0000
URL:       https://git.openjdk.org/loom/commit/e7432d574540109e2c4faca11cf49d9272a147e6

8375323: Improve handling of the "--app-content" and "--input" options in jpackage

Reviewed-by: almatvee

! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxPackager.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/AppImageSigner.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacApplicationBuilder.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacDmgPackageBuilder.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacDmgPackager.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacFromOptions.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacPkgPackager.java
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/model/MacDmgPackageMixin.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/ApplicationBuilder.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/ApplicationImageUtils.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/DefaultBundlingEnvironment.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/FromOptions.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/LauncherFromOptions.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/PackagingPipeline.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/JOptSimpleOptionsBuilder.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/OptionArrayValueConverter.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/OptionSpec.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/OptionSpecBuilder.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/OptionSpecMapperOptionScope.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/OptionValueConverter.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/OptionsAnalyzer.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/OptionsProcessor.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardAppImageFileOption.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardOption.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardValueConverter.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/Validator.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/ValueConverter.java
+ src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/ValueConverterFunction.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/model/Application.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources.properties
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/FileUtils.java
+ src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/RootedPath.java
! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinExePackager.java
! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiPackager.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/AppImageFileTest.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/PackagingPipelineTest.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/OptionSpecMutatorOptionScopeTest.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/OptionSpecTest.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/OptionValueConverterTest.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/StandardOptionTest.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/StandardValueConverterTest.java
! test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/util/FileUtilsTest.java
! test/jdk/tools/jpackage/junit/tools/jdk/jpackage/test/JUnitUtils.java
! test/jdk/tools/jpackage/share/AppContentTest.java
! test/jdk/tools/jpackage/share/InOutPathTest.java

Changeset: 9b47c23b
Branch: master
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
Date:      2026-01-16 23:16:43 +0000
URL:       https://git.openjdk.org/loom/commit/9b47c23b4b809f7070c6c8279b7ffdf83234dcdb

8375242: [macos] Improve jpackage signing coverage

Reviewed-by: almatvee

! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacHelper.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacSign.java
! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacSignVerify.java
! test/jdk/tools/jpackage/macosx/EntitlementsTest.java
! test/jdk/tools/jpackage/macosx/MacSignTest.java
! test/jdk/tools/jpackage/macosx/SigningAppImageTest.java
! test/jdk/tools/jpackage/macosx/SigningAppImageTwoStepsTest.java
+ test/jdk/tools/jpackage/macosx/SigningBase.java
! test/jdk/tools/jpackage/macosx/SigningPackageTest.java
! test/jdk/tools/jpackage/macosx/SigningPackageTwoStepTest.java
! test/jdk/tools/jpackage/macosx/SigningRuntimeImagePackageTest.java
- test/jdk/tools/jpackage/macosx/base/SigningBase.java

Changeset: 0dd5b591
Branch: master
Author:    SendaoYan <syan at openjdk.org>
Date:      2026-01-17 04:30:02 +0000
URL:       https://git.openjdk.org/loom/commit/0dd5b59194f32f54c2ec6572833f45e1402515ba

8375370: XRBackendNative.c reported variable uninitialized by clang23

Reviewed-by: prr

! src/java.desktop/unix/native/libawt_xawt/java2d/x11/XRBackendNative.c

Changeset: 436c62af
Branch: master
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
Date:      2026-01-17 06:24:31 +0000
URL:       https://git.openjdk.org/loom/commit/436c62afd285a3ce2be9aef59876df4b9f0955ff

8373867: Improve robustness of Attach API for finding tmp directory

Reviewed-by: sspitsyn, amenkov

! src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java
! src/jdk.attach/share/classes/com/sun/tools/attach/AttachNotSupportedException.java
+ test/jdk/com/sun/tools/attach/TestWithoutDumpableProcess.java


From duke at openjdk.org  Tue Jan 20 11:54:35 2026
From: duke at openjdk.org (duke)
Date: Tue, 20 Jan 2026 11:54:35 GMT
Subject: git: openjdk/loom: fibers: 28 new changesets
Message-ID: <4246a7ee-67b3-4acf-9260-b1f4c7c51258@openjdk.org>

Changeset: a0e6f028
Branch: fibers
Author:    Shawn M Emery <shawn.emery at oracle.com>
Committer: Jatin Bhateja <jbhateja at openjdk.org>
Date:      2026-01-17 11:08:30 +0000
URL:       https://git.openjdk.org/loom/commit/a0e6f028a8952f61d9115f7bdf04b8a87f8ebba4

8360934: Add AVX-512 intrinsics for ML-KEM - enhancement on AVX512_VBMI

Co-authored-by: Sandhya Viswanathan <sviswanathan at openjdk.org>
Reviewed-by: jbhateja, vpaprotski

! src/hotspot/cpu/x86/stubGenerator_x86_64_kyber.cpp

Changeset: 1cdb8174
Branch: fibers
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
Date:      2026-01-18 07:35:12 +0000
URL:       https://git.openjdk.org/loom/commit/1cdb8174220e52c055406e0e927bc982c91ac595

8375575: AttachNotSupportedException constructor missing @since 27

Reviewed-by: liach

! src/jdk.attach/share/classes/com/sun/tools/attach/AttachNotSupportedException.java

Changeset: a67979c4
Branch: fibers
Author:    Guanqiang Han <ghan at openjdk.org>
Committer: David Holmes <dholmes at openjdk.org>
Date:      2026-01-19 02:33:18 +0000
URL:       https://git.openjdk.org/loom/commit/a67979c4e6dcea70e63cc79a105be12a9306c660

8375125: assert(false) failed: "Attempting to acquire lock NativeHeapTrimmer_lock/nosafepoint out of order with lock ConcurrentHashTableResize_lock/nosafepoint-2 -- possible deadlock" when using native heap trimmer

Reviewed-by: dholmes, stuefe

! src/hotspot/share/classfile/stringTable.cpp
! src/hotspot/share/classfile/symbolTable.cpp
+ test/hotspot/jtreg/runtime/os/TestTrimNativeHeapIntervalTablesCleanup.java

Changeset: 75172e06
Branch: fibers
Author:    Per Minborg <pminborg at openjdk.org>
Date:      2026-01-19 07:45:21 +0000
URL:       https://git.openjdk.org/loom/commit/75172e06585060e5efca080a11d8a8a51b40afed

8374717: Unclear wording in docs for recursion for List, Map and LazyConstant

Reviewed-by: rriggs

! src/java.base/share/classes/java/lang/LazyConstant.java
! src/java.base/share/classes/java/util/List.java
! src/java.base/share/classes/java/util/Map.java

Changeset: 9d7ecd51
Branch: fibers
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-19 08:32:03 +0000
URL:       https://git.openjdk.org/loom/commit/9d7ecd51d72a1a9f34a19c07813e8b5530e6a944

8375437: G1: Convert G1EvacFailureRegions to use Atomic<T>

Reviewed-by: stefank, iwalulya

! src/hotspot/share/gc/g1/g1EvacFailureRegions.cpp
! src/hotspot/share/gc/g1/g1EvacFailureRegions.hpp
! src/hotspot/share/gc/g1/g1EvacFailureRegions.inline.hpp

Changeset: 30f39d88
Branch: fibers
Author:    David Briemann <dbriemann at openjdk.org>
Date:      2026-01-19 08:54:18 +0000
URL:       https://git.openjdk.org/loom/commit/30f39d88e5af36bb6db458c03215e9fa6a31d6f3

8375530: PPC64: incorrect quick verify_method_data_pointer check causes poor performance in debug build

Reviewed-by: mdoerr, shade

! src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp

Changeset: 3e181485
Branch: fibers
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-19 09:02:33 +0000
URL:       https://git.openjdk.org/loom/commit/3e181485709d108ef3d1e6b595fbd95ecc8ef74a

8375439: G1: Convert G1MonotonicArena class to use Atomic<T>

Reviewed-by: stefank, iwalulya

! src/hotspot/share/gc/g1/g1MonotonicArena.cpp
! src/hotspot/share/gc/g1/g1MonotonicArena.hpp
! src/hotspot/share/gc/g1/g1MonotonicArena.inline.hpp

Changeset: e0edc656
Branch: fibers
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-19 12:57:44 +0000
URL:       https://git.openjdk.org/loom/commit/e0edc656240d18b4468212c38f136084a50be301

8375463: G1: Remove AtomicAccess include from files that do not use it

Reviewed-by: stefank, iwalulya

! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/hotspot/share/gc/g1/g1FullGCAdjustTask.cpp
! src/hotspot/share/gc/g1/g1HeapRegionRemSet.cpp
! src/hotspot/share/gc/g1/g1HeapRegionRemSet.hpp
! src/hotspot/share/gc/g1/g1HeapRegionRemSet.inline.hpp
! src/hotspot/share/gc/g1/g1PageBasedVirtualSpace.cpp
! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp

Changeset: 6942bb2b
Branch: fibers
Author:    Andreas Steiner <asteiner at openjdk.org>
Committer: Christoph Langer <clanger at openjdk.org>
Date:      2026-01-19 13:54:06 +0000
URL:       https://git.openjdk.org/loom/commit/6942bb2b313c2d81e95f692dd947733b1149e8b8

8374802: java/net/DatagramSocket/SendReceiveMaxSize.java fails on AIX due to small default RCVBUF size

Reviewed-by: alanb

! test/jdk/java/net/DatagramSocket/SendReceiveMaxSize.java

Changeset: e7f1f16a
Branch: fibers
Author:    Christian Hagedorn <chagedorn at openjdk.org>
Date:      2026-01-19 14:02:02 +0000
URL:       https://git.openjdk.org/loom/commit/e7f1f16a88ce239f22f86e479a5e806f531fbe31

8375271: [IR Framework] Rename IREncoding to ApplicableIRRules and driver/flag/test VM to Driver/Flag/Test VM

Reviewed-by: dfenacci, thartmann, mhaessig

! test/hotspot/jtreg/compiler/lib/ir_framework/AbstractInfo.java
! test/hotspot/jtreg/compiler/lib/ir_framework/CompLevel.java
! test/hotspot/jtreg/compiler/lib/ir_framework/IR.java
! test/hotspot/jtreg/compiler/lib/ir_framework/README.md
! test/hotspot/jtreg/compiler/lib/ir_framework/Scenario.java
! test/hotspot/jtreg/compiler/lib/ir_framework/TestFramework.java
! test/hotspot/jtreg/compiler/lib/ir_framework/driver/FlagVMProcess.java
! test/hotspot/jtreg/compiler/lib/ir_framework/driver/TestVMException.java
! test/hotspot/jtreg/compiler/lib/ir_framework/driver/TestVMProcess.java
+ test/hotspot/jtreg/compiler/lib/ir_framework/driver/irmatching/parser/ApplicableIRRulesParser.java
- test/hotspot/jtreg/compiler/lib/ir_framework/driver/irmatching/parser/IREncodingParser.java
! test/hotspot/jtreg/compiler/lib/ir_framework/driver/irmatching/parser/IRMethodBuilder.java
! test/hotspot/jtreg/compiler/lib/ir_framework/driver/irmatching/parser/TestClassParser.java
! test/hotspot/jtreg/compiler/lib/ir_framework/driver/irmatching/parser/TestMethod.java
! test/hotspot/jtreg/compiler/lib/ir_framework/driver/irmatching/parser/TestMethods.java
! test/hotspot/jtreg/compiler/lib/ir_framework/driver/irmatching/parser/VMInfo.java
! test/hotspot/jtreg/compiler/lib/ir_framework/driver/irmatching/parser/VMInfoParser.java
! test/hotspot/jtreg/compiler/lib/ir_framework/driver/irmatching/parser/hotspot/CompileQueueMessages.java
! test/hotspot/jtreg/compiler/lib/ir_framework/driver/irmatching/parser/hotspot/HotSpotPidFileParser.java
! test/hotspot/jtreg/compiler/lib/ir_framework/flag/CompilePhaseCollector.java
! test/hotspot/jtreg/compiler/lib/ir_framework/flag/FlagVM.java
! test/hotspot/jtreg/compiler/lib/ir_framework/shared/NoTestsRunException.java
! test/hotspot/jtreg/compiler/lib/ir_framework/shared/TestFrameworkSocket.java
= test/hotspot/jtreg/compiler/lib/ir_framework/test/ApplicableIRRulesPrinter.java
! test/hotspot/jtreg/compiler/lib/ir_framework/test/TestVM.java
! test/hotspot/jtreg/compiler/lib/ir_framework/test/VMInfoPrinter.java
! test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestIRMatching.java
! test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestPhaseIRMatching.java

Changeset: c44a99a7
Branch: fibers
Author:    Quan Anh Mai <qamai at openjdk.org>
Date:      2026-01-19 14:20:18 +0000
URL:       https://git.openjdk.org/loom/commit/c44a99a758f38ceea84e03905d2ffb9c1fd1987a

8374180: C2 crash in PhaseCCP::verify_type - fatal error: Not monotonic

Reviewed-by: hgreule, bmaillard, epeter

! src/hotspot/share/opto/rangeinference.hpp
! src/hotspot/share/opto/type.hpp
! test/hotspot/gtest/opto/test_rangeinference.cpp
+ test/hotspot/jtreg/compiler/ccp/TestWrongXorIWiden.java

Changeset: f2d5290c
Branch: fibers
Author:    Casper Norrbin <cnorrbin at openjdk.org>
Date:      2026-01-19 14:44:37 +0000
URL:       https://git.openjdk.org/loom/commit/f2d5290c29b0b832e64ab2b4dc04cd892a627ca2

8367319: Add os interfaces to get machine and container values separately

Reviewed-by: eosterlund, sgehwolf

! src/hotspot/os/aix/os_aix.cpp
! src/hotspot/os/bsd/os_bsd.cpp
! src/hotspot/os/linux/cgroupSubsystem_linux.cpp
! src/hotspot/os/linux/cgroupSubsystem_linux.hpp
! src/hotspot/os/linux/cgroupUtil_linux.cpp
! src/hotspot/os/linux/cgroupUtil_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
! src/hotspot/os/windows/os_windows.cpp
! src/hotspot/share/jfr/jni/jfrJniMethod.cpp
! src/hotspot/share/prims/jvm.cpp
! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/runtime/os.cpp
! src/hotspot/share/runtime/os.hpp
! test/hotspot/jtreg/containers/docker/TestCPUAwareness.java

Changeset: 496af3cf
Branch: fibers
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2026-01-19 18:05:22 +0000
URL:       https://git.openjdk.org/loom/commit/496af3cf4769b78fa0928450a87928d259511c51

8375093: Convert GlobalCounter to use Atomic<T>

Reviewed-by: dholmes, iwalulya

! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/runtime/thread.hpp
! src/hotspot/share/utilities/globalCounter.cpp
! src/hotspot/share/utilities/globalCounter.hpp
! src/hotspot/share/utilities/globalCounter.inline.hpp

Changeset: 323b1f72
Branch: fibers
Author:    Alan Bateman <alan.bateman at oracle.com>
Date:      2026-01-19 19:11:33 +0000
URL:       https://git.openjdk.org/loom/commit/323b1f72483c52e2c71e1c4eb2642032c6481b1b

Merge branch 'master' into fibers

! src/hotspot/share/prims/jvm.cpp
! src/hotspot/share/prims/jvm.cpp

Changeset: d850e56d
Branch: fibers
Author:    Alan Bateman <alan.bateman at oracle.com>
Date:      2026-01-17 14:15:04 +0000
URL:       https://git.openjdk.org/loom/commit/d850e56dca9261154dfe4b162fb2baaf8c5372ef

Remove stale sentence from summary page

! loom-docs/CustomSchedulers.md

Changeset: 96abf77b
Branch: fibers
Author:    Alan Bateman <alan.bateman at oracle.com>
Date:      2026-01-17 15:01:21 +0000
URL:       https://git.openjdk.org/loom/commit/96abf77b19b5a72e18fa8dacaf557900112a2b4e

Restore preferredCarrier parameter

! src/java.base/share/classes/java/lang/System.java
! src/java.base/share/classes/java/lang/Thread.java
! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java
! src/java.base/share/classes/sun/nio/ch/Poller.java

Changeset: 02949748
Branch: fibers
Author:    Alan Bateman <alan.bateman at oracle.com>
Date:      2026-01-19 19:12:11 +0000
URL:       https://git.openjdk.org/loom/commit/02949748d025e6f8e487a374251c139e8892a778

Fix link

! src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java

Changeset: d2439df3
Branch: fibers
Author:    Alan Bateman <alan.bateman at oracle.com>
Date:      2026-01-19 19:12:35 +0000
URL:       https://git.openjdk.org/loom/commit/d2439df34ef1cac2c1fcaf3eed0dd2aa7a2b6044

Merge loom into fibers


Changeset: 303de9a3
Branch: fibers
Author:    Xiaohong Gong <xgong at openjdk.org>
Date:      2026-01-20 01:43:40 +0000
URL:       https://git.openjdk.org/loom/commit/303de9a3f2ba93f0bbe42044483a0b48c82b70cb

8370666: VectorAPI: Add clear comments for vector relative code in c2

Reviewed-by: epeter, jbhateja, qamai

! src/hotspot/share/opto/matcher.hpp
! src/hotspot/share/opto/node.hpp
! src/hotspot/share/opto/type.cpp
! src/hotspot/share/opto/type.hpp
! src/hotspot/share/opto/vectornode.hpp

Changeset: ca6925ec
Branch: fibers
Author:    David Holmes <dholmes at openjdk.org>
Date:      2026-01-20 06:18:07 +0000
URL:       https://git.openjdk.org/loom/commit/ca6925ec6bf44cf7d4704becc194389e4c87b74f

8370112: Remove VM_Version::supports_fast_class_init_checks() in platform-specific code

Reviewed-by: shade, fyang

! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp
! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp
! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp
! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp
! src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp
! src/hotspot/cpu/riscv/templateTable_riscv.cpp
! src/hotspot/cpu/s390/sharedRuntime_s390.cpp
! src/hotspot/cpu/s390/templateTable_s390.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp
! src/hotspot/cpu/x86/templateTable_x86.cpp

Changeset: e45f5656
Branch: fibers
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2026-01-20 07:10:46 +0000
URL:       https://git.openjdk.org/loom/commit/e45f5656bc90421c9acb0cbf87164162039ddf81

8373650: Test "javax/swing/JMenuItem/6458123/ManualBug6458123.java" fails because the check icons are not aligned properly as expected

Reviewed-by: tr, dnguyen

! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java

Changeset: d9db4fb3
Branch: fibers
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-20 08:01:54 +0000
URL:       https://git.openjdk.org/loom/commit/d9db4fb36e4f90546dc3fc19b5923b8be6a2f518

8373894: G1: Count evacuation-failed garbage collections in gc cpu usage

Reviewed-by: iwalulya, kbarrett

! src/hotspot/share/gc/g1/g1Policy.cpp
! src/hotspot/share/gc/g1/g1Policy.hpp
! test/hotspot/jtreg/gc/stress/TestMultiThreadStressRSet.java

Changeset: c5f288e2
Branch: fibers
Author:    Leo Korinth <lkorinth at openjdk.org>
Date:      2026-01-20 09:30:12 +0000
URL:       https://git.openjdk.org/loom/commit/c5f288e2ae2ebe6ee4a0d39d91348f746bd0e353

8373253: Re-work InjectGCWorkerCreationFailure for future changes

Reviewed-by: stefank, tschatzl, iwalulya, sjohanss

! src/hotspot/share/gc/shared/workerThread.cpp
! src/hotspot/share/gc/shared/workerThread.hpp

Changeset: c71e0575
Branch: fibers
Author:    Alan Bateman <alan.bateman at oracle.com>
Date:      2026-01-20 09:34:26 +0000
URL:       https://git.openjdk.org/loom/commit/c71e0575bfe115ee33fc1026c3e931407e17336f

Merge branch 'master' into fibers


Changeset: c1d412eb
Branch: fibers
Author:    Alan Bateman <alan.bateman at oracle.com>
Date:      2026-01-20 09:38:10 +0000
URL:       https://git.openjdk.org/loom/commit/c1d412ebe3e43b1253f3f25ef224bec5317b1629

Throw UOE when attempting to to invoke newThread on built-in default scheduler

! src/java.base/share/classes/java/lang/System.java
! src/java.base/share/classes/java/lang/Thread.java
! src/java.base/share/classes/java/lang/ThreadBuilders.java
! src/java.base/share/classes/java/lang/VirtualThread.java

Changeset: 4ec1074f
Branch: fibers
Author:    Alan Bateman <alan.bateman at oracle.com>
Date:      2026-01-20 09:38:20 +0000
URL:       https://git.openjdk.org/loom/commit/4ec1074f0e9e95e010dabdcff5dfef7a3cc36b6c

Merge loom into fibers


Changeset: 7af3eb83
Branch: fibers
Author:    Alan Bateman <alan.bateman at oracle.com>
Date:      2026-01-20 10:41:20 +0000
URL:       https://git.openjdk.org/loom/commit/7af3eb83f2a5076bbb20f10e81c78364e87571bc

Experiment with allowing custom scheduler execute delayed tasks

! src/java.base/share/classes/java/lang/Thread.java
! src/java.base/share/classes/java/lang/VirtualThread.java

Changeset: 337c8dfc
Branch: fibers
Author:    Alan Bateman <alan.bateman at oracle.com>
Date:      2026-01-20 10:41:32 +0000
URL:       https://git.openjdk.org/loom/commit/337c8dfccbc4a9e46b323c71925ba8d42365ed96

Merge loom into fibers



From duke at openjdk.org  Tue Jan 20 11:55:34 2026
From: duke at openjdk.org (duke)
Date: Tue, 20 Jan 2026 11:55:34 GMT
Subject: git: openjdk/loom: master: 18 new changesets
Message-ID: <d342c003-5c61-407f-9e36-30590e12be6e@openjdk.org>

Changeset: a0e6f028
Branch: master
Author:    Shawn M Emery <shawn.emery at oracle.com>
Committer: Jatin Bhateja <jbhateja at openjdk.org>
Date:      2026-01-17 11:08:30 +0000
URL:       https://git.openjdk.org/loom/commit/a0e6f028a8952f61d9115f7bdf04b8a87f8ebba4

8360934: Add AVX-512 intrinsics for ML-KEM - enhancement on AVX512_VBMI

Co-authored-by: Sandhya Viswanathan <sviswanathan at openjdk.org>
Reviewed-by: jbhateja, vpaprotski

! src/hotspot/cpu/x86/stubGenerator_x86_64_kyber.cpp

Changeset: 1cdb8174
Branch: master
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
Date:      2026-01-18 07:35:12 +0000
URL:       https://git.openjdk.org/loom/commit/1cdb8174220e52c055406e0e927bc982c91ac595

8375575: AttachNotSupportedException constructor missing @since 27

Reviewed-by: liach

! src/jdk.attach/share/classes/com/sun/tools/attach/AttachNotSupportedException.java

Changeset: a67979c4
Branch: master
Author:    Guanqiang Han <ghan at openjdk.org>
Committer: David Holmes <dholmes at openjdk.org>
Date:      2026-01-19 02:33:18 +0000
URL:       https://git.openjdk.org/loom/commit/a67979c4e6dcea70e63cc79a105be12a9306c660

8375125: assert(false) failed: "Attempting to acquire lock NativeHeapTrimmer_lock/nosafepoint out of order with lock ConcurrentHashTableResize_lock/nosafepoint-2 -- possible deadlock" when using native heap trimmer

Reviewed-by: dholmes, stuefe

! src/hotspot/share/classfile/stringTable.cpp
! src/hotspot/share/classfile/symbolTable.cpp
+ test/hotspot/jtreg/runtime/os/TestTrimNativeHeapIntervalTablesCleanup.java

Changeset: 75172e06
Branch: master
Author:    Per Minborg <pminborg at openjdk.org>
Date:      2026-01-19 07:45:21 +0000
URL:       https://git.openjdk.org/loom/commit/75172e06585060e5efca080a11d8a8a51b40afed

8374717: Unclear wording in docs for recursion for List, Map and LazyConstant

Reviewed-by: rriggs

! src/java.base/share/classes/java/lang/LazyConstant.java
! src/java.base/share/classes/java/util/List.java
! src/java.base/share/classes/java/util/Map.java

Changeset: 9d7ecd51
Branch: master
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-19 08:32:03 +0000
URL:       https://git.openjdk.org/loom/commit/9d7ecd51d72a1a9f34a19c07813e8b5530e6a944

8375437: G1: Convert G1EvacFailureRegions to use Atomic<T>

Reviewed-by: stefank, iwalulya

! src/hotspot/share/gc/g1/g1EvacFailureRegions.cpp
! src/hotspot/share/gc/g1/g1EvacFailureRegions.hpp
! src/hotspot/share/gc/g1/g1EvacFailureRegions.inline.hpp

Changeset: 30f39d88
Branch: master
Author:    David Briemann <dbriemann at openjdk.org>
Date:      2026-01-19 08:54:18 +0000
URL:       https://git.openjdk.org/loom/commit/30f39d88e5af36bb6db458c03215e9fa6a31d6f3

8375530: PPC64: incorrect quick verify_method_data_pointer check causes poor performance in debug build

Reviewed-by: mdoerr, shade

! src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp

Changeset: 3e181485
Branch: master
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-19 09:02:33 +0000
URL:       https://git.openjdk.org/loom/commit/3e181485709d108ef3d1e6b595fbd95ecc8ef74a

8375439: G1: Convert G1MonotonicArena class to use Atomic<T>

Reviewed-by: stefank, iwalulya

! src/hotspot/share/gc/g1/g1MonotonicArena.cpp
! src/hotspot/share/gc/g1/g1MonotonicArena.hpp
! src/hotspot/share/gc/g1/g1MonotonicArena.inline.hpp

Changeset: e0edc656
Branch: master
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-19 12:57:44 +0000
URL:       https://git.openjdk.org/loom/commit/e0edc656240d18b4468212c38f136084a50be301

8375463: G1: Remove AtomicAccess include from files that do not use it

Reviewed-by: stefank, iwalulya

! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/hotspot/share/gc/g1/g1FullGCAdjustTask.cpp
! src/hotspot/share/gc/g1/g1HeapRegionRemSet.cpp
! src/hotspot/share/gc/g1/g1HeapRegionRemSet.hpp
! src/hotspot/share/gc/g1/g1HeapRegionRemSet.inline.hpp
! src/hotspot/share/gc/g1/g1PageBasedVirtualSpace.cpp
! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp

Changeset: 6942bb2b
Branch: master
Author:    Andreas Steiner <asteiner at openjdk.org>
Committer: Christoph Langer <clanger at openjdk.org>
Date:      2026-01-19 13:54:06 +0000
URL:       https://git.openjdk.org/loom/commit/6942bb2b313c2d81e95f692dd947733b1149e8b8

8374802: java/net/DatagramSocket/SendReceiveMaxSize.java fails on AIX due to small default RCVBUF size

Reviewed-by: alanb

! test/jdk/java/net/DatagramSocket/SendReceiveMaxSize.java

Changeset: e7f1f16a
Branch: master
Author:    Christian Hagedorn <chagedorn at openjdk.org>
Date:      2026-01-19 14:02:02 +0000
URL:       https://git.openjdk.org/loom/commit/e7f1f16a88ce239f22f86e479a5e806f531fbe31

8375271: [IR Framework] Rename IREncoding to ApplicableIRRules and driver/flag/test VM to Driver/Flag/Test VM

Reviewed-by: dfenacci, thartmann, mhaessig

! test/hotspot/jtreg/compiler/lib/ir_framework/AbstractInfo.java
! test/hotspot/jtreg/compiler/lib/ir_framework/CompLevel.java
! test/hotspot/jtreg/compiler/lib/ir_framework/IR.java
! test/hotspot/jtreg/compiler/lib/ir_framework/README.md
! test/hotspot/jtreg/compiler/lib/ir_framework/Scenario.java
! test/hotspot/jtreg/compiler/lib/ir_framework/TestFramework.java
! test/hotspot/jtreg/compiler/lib/ir_framework/driver/FlagVMProcess.java
! test/hotspot/jtreg/compiler/lib/ir_framework/driver/TestVMException.java
! test/hotspot/jtreg/compiler/lib/ir_framework/driver/TestVMProcess.java
+ test/hotspot/jtreg/compiler/lib/ir_framework/driver/irmatching/parser/ApplicableIRRulesParser.java
- test/hotspot/jtreg/compiler/lib/ir_framework/driver/irmatching/parser/IREncodingParser.java
! test/hotspot/jtreg/compiler/lib/ir_framework/driver/irmatching/parser/IRMethodBuilder.java
! test/hotspot/jtreg/compiler/lib/ir_framework/driver/irmatching/parser/TestClassParser.java
! test/hotspot/jtreg/compiler/lib/ir_framework/driver/irmatching/parser/TestMethod.java
! test/hotspot/jtreg/compiler/lib/ir_framework/driver/irmatching/parser/TestMethods.java
! test/hotspot/jtreg/compiler/lib/ir_framework/driver/irmatching/parser/VMInfo.java
! test/hotspot/jtreg/compiler/lib/ir_framework/driver/irmatching/parser/VMInfoParser.java
! test/hotspot/jtreg/compiler/lib/ir_framework/driver/irmatching/parser/hotspot/CompileQueueMessages.java
! test/hotspot/jtreg/compiler/lib/ir_framework/driver/irmatching/parser/hotspot/HotSpotPidFileParser.java
! test/hotspot/jtreg/compiler/lib/ir_framework/flag/CompilePhaseCollector.java
! test/hotspot/jtreg/compiler/lib/ir_framework/flag/FlagVM.java
! test/hotspot/jtreg/compiler/lib/ir_framework/shared/NoTestsRunException.java
! test/hotspot/jtreg/compiler/lib/ir_framework/shared/TestFrameworkSocket.java
= test/hotspot/jtreg/compiler/lib/ir_framework/test/ApplicableIRRulesPrinter.java
! test/hotspot/jtreg/compiler/lib/ir_framework/test/TestVM.java
! test/hotspot/jtreg/compiler/lib/ir_framework/test/VMInfoPrinter.java
! test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestIRMatching.java
! test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestPhaseIRMatching.java

Changeset: c44a99a7
Branch: master
Author:    Quan Anh Mai <qamai at openjdk.org>
Date:      2026-01-19 14:20:18 +0000
URL:       https://git.openjdk.org/loom/commit/c44a99a758f38ceea84e03905d2ffb9c1fd1987a

8374180: C2 crash in PhaseCCP::verify_type - fatal error: Not monotonic

Reviewed-by: hgreule, bmaillard, epeter

! src/hotspot/share/opto/rangeinference.hpp
! src/hotspot/share/opto/type.hpp
! test/hotspot/gtest/opto/test_rangeinference.cpp
+ test/hotspot/jtreg/compiler/ccp/TestWrongXorIWiden.java

Changeset: f2d5290c
Branch: master
Author:    Casper Norrbin <cnorrbin at openjdk.org>
Date:      2026-01-19 14:44:37 +0000
URL:       https://git.openjdk.org/loom/commit/f2d5290c29b0b832e64ab2b4dc04cd892a627ca2

8367319: Add os interfaces to get machine and container values separately

Reviewed-by: eosterlund, sgehwolf

! src/hotspot/os/aix/os_aix.cpp
! src/hotspot/os/bsd/os_bsd.cpp
! src/hotspot/os/linux/cgroupSubsystem_linux.cpp
! src/hotspot/os/linux/cgroupSubsystem_linux.hpp
! src/hotspot/os/linux/cgroupUtil_linux.cpp
! src/hotspot/os/linux/cgroupUtil_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
! src/hotspot/os/windows/os_windows.cpp
! src/hotspot/share/jfr/jni/jfrJniMethod.cpp
! src/hotspot/share/prims/jvm.cpp
! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/runtime/os.cpp
! src/hotspot/share/runtime/os.hpp
! test/hotspot/jtreg/containers/docker/TestCPUAwareness.java

Changeset: 496af3cf
Branch: master
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2026-01-19 18:05:22 +0000
URL:       https://git.openjdk.org/loom/commit/496af3cf4769b78fa0928450a87928d259511c51

8375093: Convert GlobalCounter to use Atomic<T>

Reviewed-by: dholmes, iwalulya

! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/runtime/thread.hpp
! src/hotspot/share/utilities/globalCounter.cpp
! src/hotspot/share/utilities/globalCounter.hpp
! src/hotspot/share/utilities/globalCounter.inline.hpp

Changeset: 303de9a3
Branch: master
Author:    Xiaohong Gong <xgong at openjdk.org>
Date:      2026-01-20 01:43:40 +0000
URL:       https://git.openjdk.org/loom/commit/303de9a3f2ba93f0bbe42044483a0b48c82b70cb

8370666: VectorAPI: Add clear comments for vector relative code in c2

Reviewed-by: epeter, jbhateja, qamai

! src/hotspot/share/opto/matcher.hpp
! src/hotspot/share/opto/node.hpp
! src/hotspot/share/opto/type.cpp
! src/hotspot/share/opto/type.hpp
! src/hotspot/share/opto/vectornode.hpp

Changeset: ca6925ec
Branch: master
Author:    David Holmes <dholmes at openjdk.org>
Date:      2026-01-20 06:18:07 +0000
URL:       https://git.openjdk.org/loom/commit/ca6925ec6bf44cf7d4704becc194389e4c87b74f

8370112: Remove VM_Version::supports_fast_class_init_checks() in platform-specific code

Reviewed-by: shade, fyang

! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp
! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp
! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp
! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp
! src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp
! src/hotspot/cpu/riscv/templateTable_riscv.cpp
! src/hotspot/cpu/s390/sharedRuntime_s390.cpp
! src/hotspot/cpu/s390/templateTable_s390.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp
! src/hotspot/cpu/x86/templateTable_x86.cpp

Changeset: e45f5656
Branch: master
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2026-01-20 07:10:46 +0000
URL:       https://git.openjdk.org/loom/commit/e45f5656bc90421c9acb0cbf87164162039ddf81

8373650: Test "javax/swing/JMenuItem/6458123/ManualBug6458123.java" fails because the check icons are not aligned properly as expected

Reviewed-by: tr, dnguyen

! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsIconFactory.java

Changeset: d9db4fb3
Branch: master
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-20 08:01:54 +0000
URL:       https://git.openjdk.org/loom/commit/d9db4fb36e4f90546dc3fc19b5923b8be6a2f518

8373894: G1: Count evacuation-failed garbage collections in gc cpu usage

Reviewed-by: iwalulya, kbarrett

! src/hotspot/share/gc/g1/g1Policy.cpp
! src/hotspot/share/gc/g1/g1Policy.hpp
! test/hotspot/jtreg/gc/stress/TestMultiThreadStressRSet.java

Changeset: c5f288e2
Branch: master
Author:    Leo Korinth <lkorinth at openjdk.org>
Date:      2026-01-20 09:30:12 +0000
URL:       https://git.openjdk.org/loom/commit/c5f288e2ae2ebe6ee4a0d39d91348f746bd0e353

8373253: Re-work InjectGCWorkerCreationFailure for future changes

Reviewed-by: stefank, tschatzl, iwalulya, sjohanss

! src/hotspot/share/gc/shared/workerThread.cpp
! src/hotspot/share/gc/shared/workerThread.hpp


From aloraini.omar at gmail.com  Thu Jan 22 08:52:55 2026
From: aloraini.omar at gmail.com (Omar Aloraini)
Date: Thu, 22 Jan 2026 11:52:55 +0300
Subject: ScopedValue inheritance with unstructured concurrency?
Message-ID: <CAJ0wWSgnPWBsspe7cvUwpyfksoAorxTzstqNN2eS+oYXj9NEyw@mail.gmail.com>

I'm using `Executors.newThreadPerTaskExecutor` where I need a set of
independent actors(threads) to interact with each other. Right now,
everytime I start a new task I have to bind all my scoped values(just one
at the moment), but in the general case, it would be useful to have an
implementation of ExecutorService that captures all(or some) ScopeValues at
task submission point(and maybe at ES construction point).

```
Task task  = ....
executorService.submit(() -> {
  ScopedValue.where(AsyncScheduledTask.VALUE, task.asRunning())
    .where(TaskControlImpl.VALUE, new TaskControlImpl(task))
    .call(() -> {
```

It would be nice to have `Exuectors.scopeCapturing(ExecutorService
delegate, ScopeValues<?>... values)` or even without the varargs. Just
capture everything(if performance is not an issue).

I can't speak for people writing web servers or frameworks. But I think it
would be useful there as well.

In addition it will make ScopedValue the universal context
propagation mechanism for both structured and unstructured cases. The
current solution used by Spring and some other libraries `
https://github.com/micrometer-metrics/context-propagation`
<https://github.com/micrometer-metrics/context-propagation>.

Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260122/cf19f6c3/attachment.htm>

From duke at openjdk.org  Thu Jan 22 16:45:28 2026
From: duke at openjdk.org (duke)
Date: Thu, 22 Jan 2026 16:45:28 GMT
Subject: git: openjdk/loom: fibers: 61 new changesets
Message-ID: <8a656495-bf9b-4316-90c0-502cb7dd3926@openjdk.org>

Changeset: afbb3a04
Branch: fibers
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-20 10:31:22 +0000
URL:       https://git.openjdk.org/loom/commit/afbb3a041545ea11ee1514d329c1a6cc4cb969d2

8375620: G1: Convert G1CardTableClaimTable to use Atomic<T>

Reviewed-by: kbarrett, shade

! src/hotspot/share/gc/g1/g1CardTableClaimTable.cpp
! src/hotspot/share/gc/g1/g1CardTableClaimTable.hpp
! src/hotspot/share/gc/g1/g1CardTableClaimTable.inline.hpp

Changeset: 8c615190
Branch: fibers
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-20 10:34:00 +0000
URL:       https://git.openjdk.org/loom/commit/8c615190e69ee6e521990595fc23197f38ad6f14

8375624: G1: Convert G1JavaThreadsListClaimer to use Atomic<T>

Reviewed-by: kbarrett, shade

! src/hotspot/share/gc/g1/g1CollectedHeap.hpp
! src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp

Changeset: fe102918
Branch: fibers
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-20 10:34:16 +0000
URL:       https://git.openjdk.org/loom/commit/fe102918dd4f33ba030c4c4301a676ac8497fd90

8375630: G1: Convert G1ConcurrentMark to use Atomic<T>

Reviewed-by: kbarrett, shade

! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp

Changeset: 3cc713fa
Branch: fibers
Author:    Jonas Norlinder <jnorlinder at openjdk.org>
Committer: David Holmes <dholmes at openjdk.org>
Date:      2026-01-20 11:40:19 +0000
URL:       https://git.openjdk.org/loom/commit/3cc713fa296dfb59bbc03f2cfd4fc7d8f4b44be2

8374945: Avoid fstat in os::open

Reviewed-by: dholmes, jsjolen, redestad

! src/hotspot/os/linux/os_linux.cpp

Changeset: 03704012
Branch: fibers
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-20 13:22:25 +0000
URL:       https://git.openjdk.org/loom/commit/037040129e82958bd023e0b24d962627e8653710

8375643: G1: Convert G1RegionMarkStatsCache to use Atomic<T>

Reviewed-by: shade, kbarrett

! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp
! src/hotspot/share/gc/g1/g1FullCollector.hpp
! src/hotspot/share/gc/g1/g1RegionMarkStatsCache.hpp
! src/hotspot/share/gc/g1/g1RegionMarkStatsCache.inline.hpp

Changeset: 5ba91fed
Branch: fibers
Author:    Christian Heilmann <christian.heilmann at zeiss.com>
Committer: Alexey Ivanov <aivanov at openjdk.org>
Date:      2026-01-20 15:00:14 +0000
URL:       https://git.openjdk.org/loom/commit/5ba91fed345b078a67ad6bead1d8893bd9289f58

8297191: [macos] Printing a page range with starting page > 1 results in missing pages

Reviewed-by: aivanov, prr

! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java
! src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/PrinterView.h
! src/java.desktop/macosx/native/libawt_lwawt/awt/PrinterView.m
! test/jdk/java/awt/print/PrinterJob/PageRanges.java

Changeset: 21dc41f7
Branch: fibers
Author:    Hai-May Chao <hchao at openjdk.org>
Date:      2026-01-20 16:16:38 +0000
URL:       https://git.openjdk.org/loom/commit/21dc41f744edd138e77970d4e25e3a7eda41621f

8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange

Co-authored-by: Jamil Nimeh <jnimeh at openjdk.org>
Co-authored-by: Weijun Wang <weijun at openjdk.org>
Reviewed-by: wetmore, mullan

+ src/java.base/share/classes/sun/security/ssl/DHasKEM.java
+ src/java.base/share/classes/sun/security/ssl/Hybrid.java
+ src/java.base/share/classes/sun/security/ssl/HybridProvider.java
! src/java.base/share/classes/sun/security/ssl/KAKeyDerivation.java
+ src/java.base/share/classes/sun/security/ssl/KEMKeyExchange.java
! src/java.base/share/classes/sun/security/ssl/KeyShareExtension.java
! src/java.base/share/classes/sun/security/ssl/NamedGroup.java
! src/java.base/share/classes/sun/security/ssl/SSLKeyExchange.java
! src/java.base/share/classes/sun/security/ssl/ServerHello.java
! src/java.base/share/classes/sun/security/x509/X509Key.java
! test/jdk/javax/net/ssl/SSLParameters/NamedGroups.java
! test/jdk/javax/net/ssl/TLSCommon/NamedGroup.java
! test/jdk/javax/net/ssl/TLSv13/ClientHelloKeyShares.java
! test/jdk/javax/net/ssl/TLSv13/HRRKeyShares.java
! test/jdk/sun/security/pkcs11/tls/fips/FipsModeTLS.java
! test/jdk/sun/security/ssl/CipherSuite/DisabledCurve.java
! test/jdk/sun/security/ssl/CipherSuite/NamedGroupsWithCipherSuite.java
! test/jdk/sun/security/ssl/CipherSuite/RestrictNamedGroup.java
! test/jdk/sun/security/ssl/CipherSuite/SupportedGroups.java
! test/micro/org/openjdk/bench/java/security/SSLHandshake.java
! test/micro/org/openjdk/bench/javax/crypto/full/KEMBench.java
! test/micro/org/openjdk/bench/javax/crypto/full/KeyPairGeneratorBench.java

Changeset: b2b4729b
Branch: fibers
Author:    Christian Stein <cstein at openjdk.org>
Date:      2026-01-20 16:28:23 +0000
URL:       https://git.openjdk.org/loom/commit/b2b4729ba2dbbb7cecb177612bd08927ccb085f2

8375015: CompletionAPITest::testDocumentation failed - AssertionFailedError: expected: <null> but was: <jshelltest.JShellTest>

Reviewed-by: jlahoda

! test/langtools/jdk/jshell/CompletionAPITest.java

Changeset: 72bf0bb6
Branch: fibers
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
Date:      2026-01-20 16:49:02 +0000
URL:       https://git.openjdk.org/loom/commit/72bf0bb6f6eaf61b3800d885733e23b7b42bf9c9

8353115: GenShen: mixed evacuation candidate regions need accurate live_data

Reviewed-by: wkemper

! src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.hpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp

Changeset: 5f8cb30f
Branch: fibers
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-20 18:16:39 +0000
URL:       https://git.openjdk.org/loom/commit/5f8cb30fc0296a2b487edf9dee63e810f4861e8e

8375626: G1: Convert G1CollectionSetChooser to use Atomic<T>

Reviewed-by: kbarrett, shade

! src/hotspot/share/gc/g1/g1CollectionSetChooser.cpp

Changeset: 42439eb6
Branch: fibers
Author:    Emanuel Peter <epeter at openjdk.org>
Date:      2026-01-20 18:30:42 +0000
URL:       https://git.openjdk.org/loom/commit/42439eb60c4488711f182d0d6ee5165b4972b99d

8374889: C2 VectorAPI: must handle impossible combination of signed cast from float

Reviewed-by: dlong, qamai

! src/hotspot/share/opto/graphKit.cpp
! src/hotspot/share/opto/graphKit.hpp
! src/hotspot/share/opto/parse1.cpp
! src/hotspot/share/opto/vectorIntrinsics.cpp
+ test/hotspot/jtreg/compiler/vectorapi/TestCastShapeBadOpc.java

Changeset: aaca0a2c
Branch: fibers
Author:    Chen Liang <liach at openjdk.org>
Date:      2026-01-20 21:54:56 +0000
URL:       https://git.openjdk.org/loom/commit/aaca0a2c1f3de06a1349ae9084e9e9dbec991421

8375742: Test java/lang/invoke/MethodHandleProxies/Driver.java does not run Unnamed.java

Reviewed-by: jvernee

! test/jdk/java/lang/invoke/MethodHandleProxies/Driver.java
! test/jdk/java/lang/invoke/MethodHandleProxies/Unnamed.java

Changeset: 4fd7595f
Branch: fibers
Author:    Naoto Sato <naoto at openjdk.org>
Date:      2026-01-20 22:45:39 +0000
URL:       https://git.openjdk.org/loom/commit/4fd7595f1b607588d9854471a701c2992c6bec60

8374905: Clarify ZonedDateTime#toString() documentation regarding omitted zero seconds

Reviewed-by: rriggs, bpb

! src/java.base/share/classes/java/time/ZonedDateTime.java

Changeset: ca3e6236
Branch: fibers
Author:    Dingli Zhang <dzhang at openjdk.org>
Date:      2026-01-20 23:48:42 +0000
URL:       https://git.openjdk.org/loom/commit/ca3e6236a28794156cc2acf697755229c47735a8

8375657: RISC-V: Need to check size in SharedRuntime::is_wide_vector

Reviewed-by: fjiang, fyang

! src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp

Changeset: f8fb7804
Branch: fibers
Author:    Valerie Peng <valeriep at openjdk.org>
Committer: bchristi <brent.christian at oracle.com>
Date:      2025-07-18 23:49:30 +0000
URL:       https://git.openjdk.org/loom/commit/f8fb78042639d4c436fdad7f501ca4ca28dfe9e3

8265429: Improve GCM encryption

Co-authored-by: Daniel Jelinski <daniel.jelinski at oracle.com>
Reviewed-by: rhalade, pkumaraswamy, ahgross, jnimeh, djelinski

! src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_crypt.c

Changeset: 9f3f960b
Branch: fibers
Author:    Jayathirth D V <jdv at openjdk.org>
Committer: bchristi <brent.christian at oracle.com>
Date:      2025-08-18 10:25:12 +0000
URL:       https://git.openjdk.org/loom/commit/9f3f960b364bad96bfcd469d7993d2aedbc020a4

8364214: Enhance polygon data support

Reviewed-by: rhalade, psadhukhan, mschoene, prr

! src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java
! src/java.desktop/share/classes/sun/java2d/pipe/SpanClipRenderer.java

Changeset: 3b6ac2af
Branch: fibers
Author:    Jayathirth D V <jdv at openjdk.org>
Committer: bchristi <brent.christian at oracle.com>
Date:      2025-08-20 03:17:34 +0000
URL:       https://git.openjdk.org/loom/commit/3b6ac2af9c8637891092955474b27e5400650dfc

8362308: Enhance Bitmap operations

Reviewed-by: mschoene, rhalade, psadhukhan, prr

! src/java.desktop/share/native/libmlib_image/mlib_ImageConvMxN_Fp.c
! src/java.desktop/share/native/libmlib_image/mlib_ImageConvMxN_ext.c
! src/java.desktop/share/native/libmlib_image/mlib_ImageConv_16ext.c
! src/java.desktop/share/native/libmlib_image/mlib_ImageConv_16nw.c
! src/java.desktop/share/native/libmlib_image/mlib_ImageConv_32nw.c
! src/java.desktop/share/native/libmlib_image/mlib_ImageConv_8ext.c
! src/java.desktop/share/native/libmlib_image/mlib_ImageConv_8nw.c
! src/java.desktop/share/native/libmlib_image/mlib_ImageConv_u16ext.c
! src/java.desktop/share/native/libmlib_image/mlib_ImageConv_u16nw.c
! src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_Bit.c
! src/java.desktop/share/native/libmlib_image/mlib_ImageScanPoly.c

Changeset: 97bd4458
Branch: fibers
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Committer: bchristi <brent.christian at oracle.com>
Date:      2025-08-26 03:07:27 +0000
URL:       https://git.openjdk.org/loom/commit/97bd4458416dffd901ad07be028a08b3d6dc4881

8365271: Improve Swing supports

Reviewed-by: tr, prr, rhalade, aivanov

! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicOptionPaneUI.java

Changeset: dc46a17f
Branch: fibers
Author:    Justin Lu <jlu at openjdk.org>
Committer: bchristi <brent.christian at oracle.com>
Date:      2025-09-03 17:23:16 +0000
URL:       https://git.openjdk.org/loom/commit/dc46a17f1e569e2ae6857eaed4b1365b6cab02e1

8365058: Enhance CopyOnWriteArraySet

Reviewed-by: rhalade, skoivu, vklang, rriggs

! src/java.base/share/classes/java/util/concurrent/CopyOnWriteArraySet.java
+ test/jdk/java/util/concurrent/CopyOnWriteArraySet/SerializationTest.java

Changeset: 3afb831a
Branch: fibers
Author:    Stuart Marks <smarks at openjdk.org>
Committer: bchristi <brent.christian at oracle.com>
Date:      2025-09-04 18:11:37 +0000
URL:       https://git.openjdk.org/loom/commit/3afb831ae45182e4219decacc355fae100a41b05

8341496: Improve JMX connections

Co-authored-by: Daniel Fuchs <dfuchs at openjdk.org>
Reviewed-by: skoivu, rhalade, coffeys, dfuchs, kevinw, jnimeh

! src/java.rmi/share/classes/javax/rmi/ssl/SslRMIClientSocketFactory.java
! test/jdk/javax/management/security/SecurityTest.java
! test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java
! test/jdk/sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java
! test/jdk/sun/management/jmxremote/bootstrap/RmiBootstrapTest.java
! test/jdk/sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java

Changeset: 84ee4f97
Branch: fibers
Author:    Renjith Kannath Pariyangad <rkannathpari at openjdk.org>
Committer: bchristi <brent.christian at oracle.com>
Date:      2025-09-10 11:56:45 +0000
URL:       https://git.openjdk.org/loom/commit/84ee4f976b1580944bd77bdbd8ccd23569bce3ac

8366446: Test java/awt/geom/ConcurrentDrawPolygonTest.java fails intermittently

Reviewed-by: jdv, aivanov, prr, rhalade

! src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java

Changeset: 7e3e35ab
Branch: fibers
Author:    Stuart Marks <smarks at openjdk.org>
Committer: bchristi <brent.christian at oracle.com>
Date:      2025-09-10 16:40:58 +0000
URL:       https://git.openjdk.org/loom/commit/7e3e35abef13ddf38d4268e1269c1d18566149ab

8367277: Fix copyright header in JMXInterfaceBindingTest.java

Reviewed-by: dfuchs, rhalade, iris, coffeys

! test/jdk/sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java

Changeset: f24fadc6
Branch: fibers
Author:    Michael McMahon <michaelm at openjdk.org>
Committer: bchristi <brent.christian at oracle.com>
Date:      2025-09-15 13:31:30 +0000
URL:       https://git.openjdk.org/loom/commit/f24fadc6240e2dcb5bcd732c91ccc03d1aa19e8a

8362632: Improve HttpServer Request handling

Reviewed-by: djelinski, dfuchs

! src/jdk.httpserver/share/classes/com/sun/net/httpserver/Headers.java
! src/jdk.httpserver/share/classes/sun/net/httpserver/ExchangeImpl.java
! src/jdk.httpserver/share/classes/sun/net/httpserver/Utils.java

Changeset: eddbd359
Branch: fibers
Author:    Harshitha Onkar <honkar at openjdk.org>
Committer: bchristi <brent.christian at oracle.com>
Date:      2025-09-24 18:05:45 +0000
URL:       https://git.openjdk.org/loom/commit/eddbd359654cf6e2a437367461231ba37ee76918

8359501: Enhance Handling of URIs

Reviewed-by: rhalade, ahgross, azvegint, prr

! src/java.desktop/macosx/classes/sun/lwawt/macosx/CDesktopPeer.java
! src/java.desktop/macosx/native/libawt_lwawt/awt/CDesktopPeer.m
! src/java.desktop/windows/classes/sun/awt/windows/WDesktopPeer.java
! src/java.desktop/windows/native/libawt/windows/awt_Desktop.cpp
! test/jdk/java/awt/Desktop/BrowseTest.java
! test/jdk/java/awt/Desktop/EditAndPrintTest/EditAndPrintTest.java

Changeset: 82e5771b
Branch: fibers
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Committer: bchristi <brent.christian at oracle.com>
Date:      2025-10-09 04:40:38 +0000
URL:       https://git.openjdk.org/loom/commit/82e5771b0be205c2ef9500ffa750bf97da21823c

8365280: Enhance JOptionPane

Reviewed-by: rhalade, prr, tr, aivanov

! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicOptionPaneUI.java
- test/jdk/javax/swing/JOptionPane/TestJOptionHTMLTag.java

Changeset: 07f981f6
Branch: fibers
Author:    Jamil Nimeh <jnimeh at openjdk.org>
Committer: bchristi <brent.christian at oracle.com>
Date:      2025-11-03 14:53:21 +0000
URL:       https://git.openjdk.org/loom/commit/07f981f6b0bb8a7e444fd744791f73853e9fa325

8368032: Enhance Certificate Checking

Reviewed-by: ahgross, coffeys, rhalade, mullan, abarashev

! src/java.base/share/classes/sun/security/provider/certpath/URICertStore.java
! src/java.base/share/conf/security/java.security
! test/jdk/sun/security/x509/URICertStore/AIACertTimeout.java
! test/jdk/sun/security/x509/URICertStore/ExtensionsWithLDAP.java

Changeset: e25a5a48
Branch: fibers
Author:    Brent Christian <bchristi at openjdk.org>
Date:      2026-01-21 01:28:38 +0000
URL:       https://git.openjdk.org/loom/commit/e25a5a4821d03680d00ab6bdbec727732add8206

Merge

Reviewed-by: kcr, prr, smarks


Changeset: a2e74957
Branch: fibers
Author:    Jayathirth D V <jdv at openjdk.org>
Date:      2026-01-21 03:12:18 +0000
URL:       https://git.openjdk.org/loom/commit/a2e749572e03dd394d123b701e163e3837472dd0

8375063: Update Libpng to 1.6.54

Reviewed-by: serb, prr

! src/java.desktop/share/legal/libpng.md
! src/java.desktop/share/native/libsplashscreen/libpng/CHANGES
! src/java.desktop/share/native/libsplashscreen/libpng/LICENSE
! src/java.desktop/share/native/libsplashscreen/libpng/README
! src/java.desktop/share/native/libsplashscreen/libpng/png.c
! src/java.desktop/share/native/libsplashscreen/libpng/png.h
! src/java.desktop/share/native/libsplashscreen/libpng/pngconf.h
! src/java.desktop/share/native/libsplashscreen/libpng/pngerror.c
! src/java.desktop/share/native/libsplashscreen/libpng/pngget.c
! src/java.desktop/share/native/libsplashscreen/libpng/pnglibconf.h
! src/java.desktop/share/native/libsplashscreen/libpng/pngmem.c
! src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h
! src/java.desktop/share/native/libsplashscreen/libpng/pngread.c
! src/java.desktop/share/native/libsplashscreen/libpng/pngrtran.c
! src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c
! src/java.desktop/share/native/libsplashscreen/libpng/pngtrans.c

Changeset: 599ed0bb
Branch: fibers
Author:    SendaoYan <syan at openjdk.org>
Date:      2026-01-21 03:39:02 +0000
URL:       https://git.openjdk.org/loom/commit/599ed0bb5fd62e26c71651bc02f198cd27636cfb

8375485: Tests in vmTestbase/nsk are failing due to missing class unloading after 8373945

Reviewed-by: lmesnik, cjplummer

! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003.java
! test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java

Changeset: a448f0b9
Branch: fibers
Author:    SendaoYan <syan at openjdk.org>
Date:      2026-01-21 03:39:26 +0000
URL:       https://git.openjdk.org/loom/commit/a448f0b9f46de35ef26994e8540b9ae242372e8d

8375668: Compiler warning implicit-const-int-float-conversion by clang23

Reviewed-by: dholmes, cnorrbin

! src/hotspot/os/linux/cgroupSubsystem_linux.hpp

Changeset: 34d6e5e0
Branch: fibers
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2026-01-21 05:56:19 +0000
URL:       https://git.openjdk.org/loom/commit/34d6e5e07b8ee43ee7f913dd47fa7c897f52e6c0

8375737: Fix -Wzero-as-null-pointer-constant warnings in arm32 code

Reviewed-by: dholmes

! src/hotspot/cpu/arm/frame_arm.cpp
! src/hotspot/cpu/arm/nativeInst_arm_32.cpp
! src/hotspot/cpu/arm/nativeInst_arm_32.hpp

Changeset: b5727d27
Branch: fibers
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2026-01-21 06:04:09 +0000
URL:       https://git.openjdk.org/loom/commit/b5727d27622e1e321733f8d0e606b366984104be

8375738: Fix -Wzero-as-null-pointer-constant warnings in MacOSX/bsd code

Reviewed-by: erikj, dholmes

! make/hotspot/lib/CompileGtest.gmk
! src/hotspot/os/bsd/memMapPrinter_macosx.cpp
! src/hotspot/os/bsd/os_bsd.cpp

Changeset: 560a92a6
Branch: fibers
Author:    Jie Fu <jiefu at openjdk.org>
Date:      2026-01-21 06:33:54 +0000
URL:       https://git.openjdk.org/loom/commit/560a92a6327221c90596bcd17a87722e4910472a

8375787: compiler/vectorapi/TestCastShapeBadOpc.java fails with release VMs

Reviewed-by: syan, lmesnik, fyang, epeter

! test/hotspot/jtreg/compiler/vectorapi/TestCastShapeBadOpc.java

Changeset: 4f87fb53
Branch: fibers
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-21 09:01:00 +0000
URL:       https://git.openjdk.org/loom/commit/4f87fb53ee5c6071fa57dfe9452eca9fe7b460ee

8375622: G1: Convert G1CodeRootSet to use Atomic<T>

Reviewed-by: shade, sjohanss

! src/hotspot/share/gc/g1/g1CodeRootSet.cpp

Changeset: b1340305
Branch: fibers
Author:    Ivan Walulya <iwalulya at openjdk.org>
Date:      2026-01-21 09:51:01 +0000
URL:       https://git.openjdk.org/loom/commit/b1340305c8f5ea53b45b8bd3bd2ebe8f74864d40

8238686: G1 may waste lots of space or fail to uncommit when observing MinHeapFreeRatio during sizing after full gc

Reviewed-by: tschatzl, sjohanss

! src/hotspot/share/gc/g1/g1Arguments.cpp

Changeset: 5c7c2f09
Branch: fibers
Author:    Francesco Andreuzzi <fandreuzzi at openjdk.org>
Date:      2026-01-21 10:42:05 +0000
URL:       https://git.openjdk.org/loom/commit/5c7c2f093b83a017970d9d05c258b4c0910bfc2c

8375717: Outdated link in jdk.jfr.internal.JVM javadoc

Reviewed-by: egahlin

! src/jdk.jfr/share/classes/jdk/jfr/internal/JVM.java

Changeset: 983ae96f
Branch: fibers
Author:    Jatin Bhateja <jbhateja at openjdk.org>
Date:      2026-01-21 11:20:18 +0000
URL:       https://git.openjdk.org/loom/commit/983ae96f60c935aa52f482d21ae6a0d947679541

8375498: [VectorAPI] Dump primary vector IR details with -XX:+TraceNewVectors

Reviewed-by: epeter

! src/hotspot/share/opto/vectorIntrinsics.cpp

Changeset: 4c9103f7
Branch: fibers
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2026-01-21 14:14:33 +0000
URL:       https://git.openjdk.org/loom/commit/4c9103f7b6c91b0f237859516ef72bb9ee27157e

8374998: Failing os::write - remove bad file

Reviewed-by: mdoerr, lucy

! src/hotspot/os/posix/perfMemory_posix.cpp

Changeset: 3033e6f4
Branch: fibers
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2026-01-21 14:55:26 +0000
URL:       https://git.openjdk.org/loom/commit/3033e6f421d0f6e0aea1d976a806d7abca7c6360

8375544: JfrSet::clear should not use memset

Reviewed-by: mgronlun

! src/hotspot/share/jfr/utilities/jfrSet.hpp

Changeset: 17086d31
Branch: fibers
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
Date:      2026-01-21 16:14:35 +0000
URL:       https://git.openjdk.org/loom/commit/17086d31196827432477391fd2921a82868eaa05

8375646: Some parser flags seem unused

Reviewed-by: jlahoda, vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java

Changeset: a0ac5b34
Branch: fibers
Author:    Damon Nguyen <dnguyen at openjdk.org>
Date:      2026-01-21 18:47:39 +0000
URL:       https://git.openjdk.org/loom/commit/a0ac5b34a742cf18d86f3ac77110bcaa00192169

8375775: JDK 26 RDP2 L10n resource files update

Reviewed-by: naoto, jlu, liach

! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_ja.properties
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties
! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_de.properties
! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_ja.properties
! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_zh_CN.properties

Changeset: 3d919ad4
Branch: fibers
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
Date:      2026-01-22 01:53:42 +0000
URL:       https://git.openjdk.org/loom/commit/3d919ad43a041eb60ce51e78831c77fd3b109aee

8373366: HandshakeState should disallow suspend ops for disabler threads
8375362: Deadlock with unmount of suspended virtual thread interrupting another virtual thread

Reviewed-by: lmesnik, pchilanomate

! src/hotspot/share/runtime/handshake.cpp
! src/hotspot/share/runtime/javaThread.cpp
! src/hotspot/share/runtime/javaThread.hpp
! src/hotspot/share/runtime/mountUnmountDisabler.cpp
! src/hotspot/share/runtime/suspendResumeManager.cpp
+ test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadStateTest2/ThreadStateTest2.java
+ test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadStateTest2/libThreadStateTest2.cpp

Changeset: 38a8309b
Branch: fibers
Author:    Ivan Walulya <iwalulya at openjdk.org>
Date:      2026-01-22 05:38:32 +0000
URL:       https://git.openjdk.org/loom/commit/38a8309b3f2544fa13448f5217e4227f0e2fe171

8341630: G1: Adopt PartialArrayState to consolidate marking stack in concurrent marking

Co-authored-by: Stefan Johansson <sjohanss at openjdk.org>
Reviewed-by: tschatzl, sjohanss

! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp
! src/hotspot/share/gc/g1/g1ConcurrentMark.inline.hpp
- src/hotspot/share/gc/g1/g1ConcurrentMarkObjArrayProcessor.cpp
- src/hotspot/share/gc/g1/g1ConcurrentMarkObjArrayProcessor.hpp
- src/hotspot/share/gc/g1/g1ConcurrentMarkObjArrayProcessor.inline.hpp
! src/hotspot/share/gc/shared/taskqueue.hpp

Changeset: 0f4d7750
Branch: fibers
Author:    Tobias Hartmann <thartmann at openjdk.org>
Date:      2026-01-22 06:56:51 +0000
URL:       https://git.openjdk.org/loom/commit/0f4d775085109981fbf00623d38da22655d04675

8375534: Debug method 'pp' should support compressed oops

Reviewed-by: vlivanov, phubner

! src/hotspot/share/utilities/debug.cpp

Changeset: f3381f0f
Branch: fibers
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-22 08:29:05 +0000
URL:       https://git.openjdk.org/loom/commit/f3381f0ffe2207e1765558f6f49e5a0280a3f920

8375314: Parallel: Crash iterating over unloaded classes for ObjectCountAfterGC event

Reviewed-by: rkennke, sjohanss, iwalulya

! src/hotspot/share/gc/g1/g1CollectedHeap.hpp
! src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp
! src/hotspot/share/gc/parallel/psParallelCompact.cpp
! src/hotspot/share/gc/parallel/psParallelCompact.hpp
! src/hotspot/share/gc/shared/collectedHeap.hpp
! src/hotspot/share/gc/shared/collectedHeap.inline.hpp
+ test/hotspot/jtreg/gc/parallel/TestObjectCountAfterGC.java

Changeset: e50bf1f2
Branch: fibers
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-22 08:29:27 +0000
URL:       https://git.openjdk.org/loom/commit/e50bf1f2a4702ef48cf16cc4f45d034a652bf358

8375616: G1: Convert G1BatchedTask to use Atomic<T>

Reviewed-by: sjohanss, kbarrett

! src/hotspot/share/gc/g1/g1BatchedTask.cpp
! src/hotspot/share/gc/g1/g1BatchedTask.hpp

Changeset: 92236ead
Branch: fibers
Author:    Quan Anh Mai <qamai at openjdk.org>
Date:      2026-01-22 08:32:01 +0000
URL:       https://git.openjdk.org/loom/commit/92236ead1dea813cf456855f0aa6b73c16e9dc70

8375618: Incorrect assert in CastLLNode::Ideal

Reviewed-by: chagedorn, dlong

! src/hotspot/share/opto/castnode.cpp
! src/hotspot/share/opto/type.cpp
! src/hotspot/share/opto/type.hpp
+ test/hotspot/jtreg/compiler/igvn/CastLLBits.java

Changeset: 63be87d7
Branch: fibers
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-22 08:35:03 +0000
URL:       https://git.openjdk.org/loom/commit/63be87d7f38a83c5fcdf59b54c6d63e0f0ca34d6

8375977: G1: Convert JVMCICleaningTask to use Atomic<T>

Reviewed-by: kbarrett

! src/hotspot/share/gc/g1/g1ParallelCleaning.cpp
! src/hotspot/share/gc/g1/g1ParallelCleaning.hpp

Changeset: 03038d80
Branch: fibers
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-22 08:35:32 +0000
URL:       https://git.openjdk.org/loom/commit/03038d802cc43b7694f554978ac9de8edca8a954

8375978: G1: Convert G1Policy to use Atomic<T>

Reviewed-by: kbarrett

! src/hotspot/share/gc/g1/g1Policy.cpp
! src/hotspot/share/gc/g1/g1Policy.hpp

Changeset: 6165daf0
Branch: fibers
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2026-01-22 08:50:11 +0000
URL:       https://git.openjdk.org/loom/commit/6165daf03c8582cca8e5b075560aa978b90f677c

8375458: Check legal folder of JDK image for unwanted files

Reviewed-by: erikj

! test/jdk/build/CheckFiles.java

Changeset: ddbd4617
Branch: fibers
Author:    Casper Norrbin <cnorrbin at openjdk.org>
Date:      2026-01-22 09:45:40 +0000
URL:       https://git.openjdk.org/loom/commit/ddbd4617a6172e3054b2afade4f304f66c79816e

8303470: containers/docker/TestMemoryAwareness.java failed with "'memory_limit_in_bytes:.*512000 k' missing from stdout/stderr"

Reviewed-by: sgehwolf, dholmes

! src/hotspot/os/linux/osContainer_linux.cpp
! test/hotspot/jtreg/ProblemList.txt

Changeset: e8eb218c
Branch: fibers
Author:    Liam Miller-Cushon <cushon at openjdk.org>
Date:      2026-01-22 10:05:05 +0000
URL:       https://git.openjdk.org/loom/commit/e8eb218ca2d05736adc4b0aefa4b17e3062959b8

8374643: Fix reference to implMethodKind in LambdaToMethod debug printf statement

Reviewed-by: vromero, liach

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
+ test/langtools/tools/javac/diags/examples/LambdaDeserializationStat.java
! test/langtools/tools/javac/lambda/SerializableObjectMethods.java
+ test/langtools/tools/javac/lambda/SerializableObjectMethods.out

Changeset: 6e9256cb
Branch: fibers
Author:    Roland Westrelin <roland at openjdk.org>
Date:      2026-01-22 10:37:26 +0000
URL:       https://git.openjdk.org/loom/commit/6e9256cb613c9a3594546a45975a81def2efcf46

8373343: C2: verify AddP base input only set for heap addresses

Reviewed-by: dlong, chagedorn, qamai

! src/hotspot/share/gc/shared/c2/barrierSetC2.cpp
! src/hotspot/share/opto/addnode.hpp
! src/hotspot/share/opto/callnode.cpp
! src/hotspot/share/opto/callnode.hpp
! src/hotspot/share/opto/escape.cpp
! src/hotspot/share/opto/graphKit.cpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/opto/macro.cpp
! src/hotspot/share/opto/macro.hpp
! src/hotspot/share/opto/macroArrayCopy.cpp
! src/hotspot/share/opto/memnode.cpp
! src/hotspot/share/opto/memnode.hpp
! src/hotspot/share/opto/parse.hpp
! src/hotspot/share/opto/parse1.cpp
! src/hotspot/share/opto/parseHelper.cpp
! src/hotspot/share/opto/subtypenode.cpp

Changeset: 0ad81fbd
Branch: fibers
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-22 11:04:09 +0000
URL:       https://git.openjdk.org/loom/commit/0ad81fbd161edbc8479e5af5c0f8d6098f6c72d1

8375541: G1: Race in G1BarrierSet::write_ref_field_post()

Reviewed-by: iwalulya, sjohanss, shade

! src/hotspot/share/gc/g1/g1BarrierSet.inline.hpp

Changeset: 66e950e9
Branch: fibers
Author:    Ivan Walulya <iwalulya at openjdk.org>
Date:      2026-01-22 11:07:42 +0000
URL:       https://git.openjdk.org/loom/commit/66e950e9b6414617952d22200831be5b0cafee85

8340470: G1: Adopt PartialArrayState to consolidate marking stack in Full GC

Co-authored-by: Stefan Johansson <sjohanss at openjdk.org>
Reviewed-by: sjohanss, tschatzl

! src/hotspot/share/gc/g1/g1FullCollector.cpp
! src/hotspot/share/gc/g1/g1FullCollector.hpp
! src/hotspot/share/gc/g1/g1FullGCMarkTask.cpp
! src/hotspot/share/gc/g1/g1FullGCMarker.cpp
! src/hotspot/share/gc/g1/g1FullGCMarker.hpp
! src/hotspot/share/gc/g1/g1FullGCMarker.inline.hpp
! src/hotspot/share/gc/g1/g1FullGCOopClosures.cpp
! src/hotspot/share/gc/g1/g1FullGCOopClosures.hpp

Changeset: 5e0ed3f4
Branch: fibers
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-22 11:51:37 +0000
URL:       https://git.openjdk.org/loom/commit/5e0ed3f408b6afd7496e0e0da207f7e372b0d446

8375982: G1: Convert G1YoungCollector helper classes to use Atomic<T>

Reviewed-by: kbarrett, shade

! src/hotspot/share/gc/g1/g1YoungCollector.cpp
! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp

Changeset: 0d1d4d07
Branch: fibers
Author:    Roland Westrelin <roland at openjdk.org>
Date:      2026-01-22 12:09:11 +0000
URL:       https://git.openjdk.org/loom/commit/0d1d4d07b9fa2368f471f30e176d446698500115

8374725: C2: assert(x_ctrl == get_late_ctrl_with_anti_dep(x->as_Load(), early_ctrl, x_ctrl)) failed: anti-dependences were already checked

Reviewed-by: chagedorn, qamai, dfenacci

! src/hotspot/share/opto/loopopts.cpp
+ test/hotspot/jtreg/compiler/loopopts/TestSinkingLoadInputOfPhi.java

Changeset: eda15aa1
Branch: fibers
Author:    Weijun Wang <weijun at openjdk.org>
Date:      2026-01-22 12:16:09 +0000
URL:       https://git.openjdk.org/loom/commit/eda15aa19c36142984edaa08850132ca6ae7a369

8277489: Rewrite JAAS UnixLoginModule with FFM

Co-authored-by: Martin Doerr <mdoerr at openjdk.org>
Reviewed-by: mdoerr, ascarpino, erikj

! make/modules/jdk.security.auth/Lib.gmk
! src/java.base/share/classes/module-info.java
! src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixLoginModule.java
! src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java
- src/jdk.security.auth/unix/native/libjaas/Unix.c
! test/jdk/com/sun/security/auth/module/AllPlatforms.java

Changeset: 025041ba
Branch: fibers
Author:    Artur Barashev <abarashev at openjdk.org>
Date:      2026-01-22 13:11:42 +0000
URL:       https://git.openjdk.org/loom/commit/025041ba04f3ae3a149b9d57d0dde4afaef37f4c

8370885: Default namedGroups values are not being filtered against algorithm constraints

Reviewed-by: hchao

! src/java.base/share/classes/sun/security/ssl/NamedGroup.java
+ test/jdk/sun/security/ssl/CipherSuite/DefaultNamedGroups.java

Changeset: 26aab3cc
Branch: fibers
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
Date:      2026-01-22 14:56:23 +0000
URL:       https://git.openjdk.org/loom/commit/26aab3cccdbcf98c329c8d67093eb2dbf4b164e5

8373120: Virtual thread stuck in BLOCKED state

Co-authored-by: Alan Bateman <alanb at openjdk.org>
Reviewed-by: alanb

! src/java.base/share/classes/java/lang/VirtualThread.java
+ test/jdk/java/lang/Thread/virtual/stress/NotifiedThenTimedOutWait.java

Changeset: c32de0f7
Branch: fibers
Author:    Alan Bateman <alan.bateman at oracle.com>
Date:      2026-01-22 14:58:50 +0000
URL:       https://git.openjdk.org/loom/commit/c32de0f76f1f493ac2b45cfa49986ea1807417b4

Merge branch 'master' into fibers

! src/java.base/share/classes/java/lang/VirtualThread.java
! src/java.base/share/classes/java/lang/VirtualThread.java


From duke at openjdk.org  Thu Jan 22 16:49:01 2026
From: duke at openjdk.org (duke)
Date: Thu, 22 Jan 2026 16:49:01 GMT
Subject: git: openjdk/loom: master: 60 new changesets
Message-ID: <3df8b048-1579-4fb3-829b-4a14898a41d1@openjdk.org>

Changeset: afbb3a04
Branch: master
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-20 10:31:22 +0000
URL:       https://git.openjdk.org/loom/commit/afbb3a041545ea11ee1514d329c1a6cc4cb969d2

8375620: G1: Convert G1CardTableClaimTable to use Atomic<T>

Reviewed-by: kbarrett, shade

! src/hotspot/share/gc/g1/g1CardTableClaimTable.cpp
! src/hotspot/share/gc/g1/g1CardTableClaimTable.hpp
! src/hotspot/share/gc/g1/g1CardTableClaimTable.inline.hpp

Changeset: 8c615190
Branch: master
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-20 10:34:00 +0000
URL:       https://git.openjdk.org/loom/commit/8c615190e69ee6e521990595fc23197f38ad6f14

8375624: G1: Convert G1JavaThreadsListClaimer to use Atomic<T>

Reviewed-by: kbarrett, shade

! src/hotspot/share/gc/g1/g1CollectedHeap.hpp
! src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp

Changeset: fe102918
Branch: master
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-20 10:34:16 +0000
URL:       https://git.openjdk.org/loom/commit/fe102918dd4f33ba030c4c4301a676ac8497fd90

8375630: G1: Convert G1ConcurrentMark to use Atomic<T>

Reviewed-by: kbarrett, shade

! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp

Changeset: 3cc713fa
Branch: master
Author:    Jonas Norlinder <jnorlinder at openjdk.org>
Committer: David Holmes <dholmes at openjdk.org>
Date:      2026-01-20 11:40:19 +0000
URL:       https://git.openjdk.org/loom/commit/3cc713fa296dfb59bbc03f2cfd4fc7d8f4b44be2

8374945: Avoid fstat in os::open

Reviewed-by: dholmes, jsjolen, redestad

! src/hotspot/os/linux/os_linux.cpp

Changeset: 03704012
Branch: master
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-20 13:22:25 +0000
URL:       https://git.openjdk.org/loom/commit/037040129e82958bd023e0b24d962627e8653710

8375643: G1: Convert G1RegionMarkStatsCache to use Atomic<T>

Reviewed-by: shade, kbarrett

! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp
! src/hotspot/share/gc/g1/g1FullCollector.hpp
! src/hotspot/share/gc/g1/g1RegionMarkStatsCache.hpp
! src/hotspot/share/gc/g1/g1RegionMarkStatsCache.inline.hpp

Changeset: 5ba91fed
Branch: master
Author:    Christian Heilmann <christian.heilmann at zeiss.com>
Committer: Alexey Ivanov <aivanov at openjdk.org>
Date:      2026-01-20 15:00:14 +0000
URL:       https://git.openjdk.org/loom/commit/5ba91fed345b078a67ad6bead1d8893bd9289f58

8297191: [macos] Printing a page range with starting page > 1 results in missing pages

Reviewed-by: aivanov, prr

! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java
! src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/PrinterView.h
! src/java.desktop/macosx/native/libawt_lwawt/awt/PrinterView.m
! test/jdk/java/awt/print/PrinterJob/PageRanges.java

Changeset: 21dc41f7
Branch: master
Author:    Hai-May Chao <hchao at openjdk.org>
Date:      2026-01-20 16:16:38 +0000
URL:       https://git.openjdk.org/loom/commit/21dc41f744edd138e77970d4e25e3a7eda41621f

8314323: Implement JEP 527: TLS 1.3 Hybrid Key Exchange

Co-authored-by: Jamil Nimeh <jnimeh at openjdk.org>
Co-authored-by: Weijun Wang <weijun at openjdk.org>
Reviewed-by: wetmore, mullan

+ src/java.base/share/classes/sun/security/ssl/DHasKEM.java
+ src/java.base/share/classes/sun/security/ssl/Hybrid.java
+ src/java.base/share/classes/sun/security/ssl/HybridProvider.java
! src/java.base/share/classes/sun/security/ssl/KAKeyDerivation.java
+ src/java.base/share/classes/sun/security/ssl/KEMKeyExchange.java
! src/java.base/share/classes/sun/security/ssl/KeyShareExtension.java
! src/java.base/share/classes/sun/security/ssl/NamedGroup.java
! src/java.base/share/classes/sun/security/ssl/SSLKeyExchange.java
! src/java.base/share/classes/sun/security/ssl/ServerHello.java
! src/java.base/share/classes/sun/security/x509/X509Key.java
! test/jdk/javax/net/ssl/SSLParameters/NamedGroups.java
! test/jdk/javax/net/ssl/TLSCommon/NamedGroup.java
! test/jdk/javax/net/ssl/TLSv13/ClientHelloKeyShares.java
! test/jdk/javax/net/ssl/TLSv13/HRRKeyShares.java
! test/jdk/sun/security/pkcs11/tls/fips/FipsModeTLS.java
! test/jdk/sun/security/ssl/CipherSuite/DisabledCurve.java
! test/jdk/sun/security/ssl/CipherSuite/NamedGroupsWithCipherSuite.java
! test/jdk/sun/security/ssl/CipherSuite/RestrictNamedGroup.java
! test/jdk/sun/security/ssl/CipherSuite/SupportedGroups.java
! test/micro/org/openjdk/bench/java/security/SSLHandshake.java
! test/micro/org/openjdk/bench/javax/crypto/full/KEMBench.java
! test/micro/org/openjdk/bench/javax/crypto/full/KeyPairGeneratorBench.java

Changeset: b2b4729b
Branch: master
Author:    Christian Stein <cstein at openjdk.org>
Date:      2026-01-20 16:28:23 +0000
URL:       https://git.openjdk.org/loom/commit/b2b4729ba2dbbb7cecb177612bd08927ccb085f2

8375015: CompletionAPITest::testDocumentation failed - AssertionFailedError: expected: <null> but was: <jshelltest.JShellTest>

Reviewed-by: jlahoda

! test/langtools/jdk/jshell/CompletionAPITest.java

Changeset: 72bf0bb6
Branch: master
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
Date:      2026-01-20 16:49:02 +0000
URL:       https://git.openjdk.org/loom/commit/72bf0bb6f6eaf61b3800d885733e23b7b42bf9c9

8353115: GenShen: mixed evacuation candidate regions need accurate live_data

Reviewed-by: wkemper

! src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.hpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp

Changeset: 5f8cb30f
Branch: master
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-20 18:16:39 +0000
URL:       https://git.openjdk.org/loom/commit/5f8cb30fc0296a2b487edf9dee63e810f4861e8e

8375626: G1: Convert G1CollectionSetChooser to use Atomic<T>

Reviewed-by: kbarrett, shade

! src/hotspot/share/gc/g1/g1CollectionSetChooser.cpp

Changeset: 42439eb6
Branch: master
Author:    Emanuel Peter <epeter at openjdk.org>
Date:      2026-01-20 18:30:42 +0000
URL:       https://git.openjdk.org/loom/commit/42439eb60c4488711f182d0d6ee5165b4972b99d

8374889: C2 VectorAPI: must handle impossible combination of signed cast from float

Reviewed-by: dlong, qamai

! src/hotspot/share/opto/graphKit.cpp
! src/hotspot/share/opto/graphKit.hpp
! src/hotspot/share/opto/parse1.cpp
! src/hotspot/share/opto/vectorIntrinsics.cpp
+ test/hotspot/jtreg/compiler/vectorapi/TestCastShapeBadOpc.java

Changeset: aaca0a2c
Branch: master
Author:    Chen Liang <liach at openjdk.org>
Date:      2026-01-20 21:54:56 +0000
URL:       https://git.openjdk.org/loom/commit/aaca0a2c1f3de06a1349ae9084e9e9dbec991421

8375742: Test java/lang/invoke/MethodHandleProxies/Driver.java does not run Unnamed.java

Reviewed-by: jvernee

! test/jdk/java/lang/invoke/MethodHandleProxies/Driver.java
! test/jdk/java/lang/invoke/MethodHandleProxies/Unnamed.java

Changeset: 4fd7595f
Branch: master
Author:    Naoto Sato <naoto at openjdk.org>
Date:      2026-01-20 22:45:39 +0000
URL:       https://git.openjdk.org/loom/commit/4fd7595f1b607588d9854471a701c2992c6bec60

8374905: Clarify ZonedDateTime#toString() documentation regarding omitted zero seconds

Reviewed-by: rriggs, bpb

! src/java.base/share/classes/java/time/ZonedDateTime.java

Changeset: ca3e6236
Branch: master
Author:    Dingli Zhang <dzhang at openjdk.org>
Date:      2026-01-20 23:48:42 +0000
URL:       https://git.openjdk.org/loom/commit/ca3e6236a28794156cc2acf697755229c47735a8

8375657: RISC-V: Need to check size in SharedRuntime::is_wide_vector

Reviewed-by: fjiang, fyang

! src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp

Changeset: f8fb7804
Branch: master
Author:    Valerie Peng <valeriep at openjdk.org>
Committer: bchristi <brent.christian at oracle.com>
Date:      2025-07-18 23:49:30 +0000
URL:       https://git.openjdk.org/loom/commit/f8fb78042639d4c436fdad7f501ca4ca28dfe9e3

8265429: Improve GCM encryption

Co-authored-by: Daniel Jelinski <daniel.jelinski at oracle.com>
Reviewed-by: rhalade, pkumaraswamy, ahgross, jnimeh, djelinski

! src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_crypt.c

Changeset: 9f3f960b
Branch: master
Author:    Jayathirth D V <jdv at openjdk.org>
Committer: bchristi <brent.christian at oracle.com>
Date:      2025-08-18 10:25:12 +0000
URL:       https://git.openjdk.org/loom/commit/9f3f960b364bad96bfcd469d7993d2aedbc020a4

8364214: Enhance polygon data support

Reviewed-by: rhalade, psadhukhan, mschoene, prr

! src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java
! src/java.desktop/share/classes/sun/java2d/pipe/SpanClipRenderer.java

Changeset: 3b6ac2af
Branch: master
Author:    Jayathirth D V <jdv at openjdk.org>
Committer: bchristi <brent.christian at oracle.com>
Date:      2025-08-20 03:17:34 +0000
URL:       https://git.openjdk.org/loom/commit/3b6ac2af9c8637891092955474b27e5400650dfc

8362308: Enhance Bitmap operations

Reviewed-by: mschoene, rhalade, psadhukhan, prr

! src/java.desktop/share/native/libmlib_image/mlib_ImageConvMxN_Fp.c
! src/java.desktop/share/native/libmlib_image/mlib_ImageConvMxN_ext.c
! src/java.desktop/share/native/libmlib_image/mlib_ImageConv_16ext.c
! src/java.desktop/share/native/libmlib_image/mlib_ImageConv_16nw.c
! src/java.desktop/share/native/libmlib_image/mlib_ImageConv_32nw.c
! src/java.desktop/share/native/libmlib_image/mlib_ImageConv_8ext.c
! src/java.desktop/share/native/libmlib_image/mlib_ImageConv_8nw.c
! src/java.desktop/share/native/libmlib_image/mlib_ImageConv_u16ext.c
! src/java.desktop/share/native/libmlib_image/mlib_ImageConv_u16nw.c
! src/java.desktop/share/native/libmlib_image/mlib_ImageLookUp_Bit.c
! src/java.desktop/share/native/libmlib_image/mlib_ImageScanPoly.c

Changeset: 97bd4458
Branch: master
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Committer: bchristi <brent.christian at oracle.com>
Date:      2025-08-26 03:07:27 +0000
URL:       https://git.openjdk.org/loom/commit/97bd4458416dffd901ad07be028a08b3d6dc4881

8365271: Improve Swing supports

Reviewed-by: tr, prr, rhalade, aivanov

! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicOptionPaneUI.java

Changeset: dc46a17f
Branch: master
Author:    Justin Lu <jlu at openjdk.org>
Committer: bchristi <brent.christian at oracle.com>
Date:      2025-09-03 17:23:16 +0000
URL:       https://git.openjdk.org/loom/commit/dc46a17f1e569e2ae6857eaed4b1365b6cab02e1

8365058: Enhance CopyOnWriteArraySet

Reviewed-by: rhalade, skoivu, vklang, rriggs

! src/java.base/share/classes/java/util/concurrent/CopyOnWriteArraySet.java
+ test/jdk/java/util/concurrent/CopyOnWriteArraySet/SerializationTest.java

Changeset: 3afb831a
Branch: master
Author:    Stuart Marks <smarks at openjdk.org>
Committer: bchristi <brent.christian at oracle.com>
Date:      2025-09-04 18:11:37 +0000
URL:       https://git.openjdk.org/loom/commit/3afb831ae45182e4219decacc355fae100a41b05

8341496: Improve JMX connections

Co-authored-by: Daniel Fuchs <dfuchs at openjdk.org>
Reviewed-by: skoivu, rhalade, coffeys, dfuchs, kevinw, jnimeh

! src/java.rmi/share/classes/javax/rmi/ssl/SslRMIClientSocketFactory.java
! test/jdk/javax/management/security/SecurityTest.java
! test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java
! test/jdk/sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java
! test/jdk/sun/management/jmxremote/bootstrap/RmiBootstrapTest.java
! test/jdk/sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java

Changeset: 84ee4f97
Branch: master
Author:    Renjith Kannath Pariyangad <rkannathpari at openjdk.org>
Committer: bchristi <brent.christian at oracle.com>
Date:      2025-09-10 11:56:45 +0000
URL:       https://git.openjdk.org/loom/commit/84ee4f976b1580944bd77bdbd8ccd23569bce3ac

8366446: Test java/awt/geom/ConcurrentDrawPolygonTest.java fails intermittently

Reviewed-by: jdv, aivanov, prr, rhalade

! src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java

Changeset: 7e3e35ab
Branch: master
Author:    Stuart Marks <smarks at openjdk.org>
Committer: bchristi <brent.christian at oracle.com>
Date:      2025-09-10 16:40:58 +0000
URL:       https://git.openjdk.org/loom/commit/7e3e35abef13ddf38d4268e1269c1d18566149ab

8367277: Fix copyright header in JMXInterfaceBindingTest.java

Reviewed-by: dfuchs, rhalade, iris, coffeys

! test/jdk/sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java

Changeset: f24fadc6
Branch: master
Author:    Michael McMahon <michaelm at openjdk.org>
Committer: bchristi <brent.christian at oracle.com>
Date:      2025-09-15 13:31:30 +0000
URL:       https://git.openjdk.org/loom/commit/f24fadc6240e2dcb5bcd732c91ccc03d1aa19e8a

8362632: Improve HttpServer Request handling

Reviewed-by: djelinski, dfuchs

! src/jdk.httpserver/share/classes/com/sun/net/httpserver/Headers.java
! src/jdk.httpserver/share/classes/sun/net/httpserver/ExchangeImpl.java
! src/jdk.httpserver/share/classes/sun/net/httpserver/Utils.java

Changeset: eddbd359
Branch: master
Author:    Harshitha Onkar <honkar at openjdk.org>
Committer: bchristi <brent.christian at oracle.com>
Date:      2025-09-24 18:05:45 +0000
URL:       https://git.openjdk.org/loom/commit/eddbd359654cf6e2a437367461231ba37ee76918

8359501: Enhance Handling of URIs

Reviewed-by: rhalade, ahgross, azvegint, prr

! src/java.desktop/macosx/classes/sun/lwawt/macosx/CDesktopPeer.java
! src/java.desktop/macosx/native/libawt_lwawt/awt/CDesktopPeer.m
! src/java.desktop/windows/classes/sun/awt/windows/WDesktopPeer.java
! src/java.desktop/windows/native/libawt/windows/awt_Desktop.cpp
! test/jdk/java/awt/Desktop/BrowseTest.java
! test/jdk/java/awt/Desktop/EditAndPrintTest/EditAndPrintTest.java

Changeset: 82e5771b
Branch: master
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Committer: bchristi <brent.christian at oracle.com>
Date:      2025-10-09 04:40:38 +0000
URL:       https://git.openjdk.org/loom/commit/82e5771b0be205c2ef9500ffa750bf97da21823c

8365280: Enhance JOptionPane

Reviewed-by: rhalade, prr, tr, aivanov

! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicOptionPaneUI.java
- test/jdk/javax/swing/JOptionPane/TestJOptionHTMLTag.java

Changeset: 07f981f6
Branch: master
Author:    Jamil Nimeh <jnimeh at openjdk.org>
Committer: bchristi <brent.christian at oracle.com>
Date:      2025-11-03 14:53:21 +0000
URL:       https://git.openjdk.org/loom/commit/07f981f6b0bb8a7e444fd744791f73853e9fa325

8368032: Enhance Certificate Checking

Reviewed-by: ahgross, coffeys, rhalade, mullan, abarashev

! src/java.base/share/classes/sun/security/provider/certpath/URICertStore.java
! src/java.base/share/conf/security/java.security
! test/jdk/sun/security/x509/URICertStore/AIACertTimeout.java
! test/jdk/sun/security/x509/URICertStore/ExtensionsWithLDAP.java

Changeset: e25a5a48
Branch: master
Author:    Brent Christian <bchristi at openjdk.org>
Date:      2026-01-21 01:28:38 +0000
URL:       https://git.openjdk.org/loom/commit/e25a5a4821d03680d00ab6bdbec727732add8206

Merge

Reviewed-by: kcr, prr, smarks


Changeset: a2e74957
Branch: master
Author:    Jayathirth D V <jdv at openjdk.org>
Date:      2026-01-21 03:12:18 +0000
URL:       https://git.openjdk.org/loom/commit/a2e749572e03dd394d123b701e163e3837472dd0

8375063: Update Libpng to 1.6.54

Reviewed-by: serb, prr

! src/java.desktop/share/legal/libpng.md
! src/java.desktop/share/native/libsplashscreen/libpng/CHANGES
! src/java.desktop/share/native/libsplashscreen/libpng/LICENSE
! src/java.desktop/share/native/libsplashscreen/libpng/README
! src/java.desktop/share/native/libsplashscreen/libpng/png.c
! src/java.desktop/share/native/libsplashscreen/libpng/png.h
! src/java.desktop/share/native/libsplashscreen/libpng/pngconf.h
! src/java.desktop/share/native/libsplashscreen/libpng/pngerror.c
! src/java.desktop/share/native/libsplashscreen/libpng/pngget.c
! src/java.desktop/share/native/libsplashscreen/libpng/pnglibconf.h
! src/java.desktop/share/native/libsplashscreen/libpng/pngmem.c
! src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h
! src/java.desktop/share/native/libsplashscreen/libpng/pngread.c
! src/java.desktop/share/native/libsplashscreen/libpng/pngrtran.c
! src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c
! src/java.desktop/share/native/libsplashscreen/libpng/pngtrans.c

Changeset: 599ed0bb
Branch: master
Author:    SendaoYan <syan at openjdk.org>
Date:      2026-01-21 03:39:02 +0000
URL:       https://git.openjdk.org/loom/commit/599ed0bb5fd62e26c71651bc02f198cd27636cfb

8375485: Tests in vmTestbase/nsk are failing due to missing class unloading after 8373945

Reviewed-by: lmesnik, cjplummer

! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003.java
! test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java

Changeset: a448f0b9
Branch: master
Author:    SendaoYan <syan at openjdk.org>
Date:      2026-01-21 03:39:26 +0000
URL:       https://git.openjdk.org/loom/commit/a448f0b9f46de35ef26994e8540b9ae242372e8d

8375668: Compiler warning implicit-const-int-float-conversion by clang23

Reviewed-by: dholmes, cnorrbin

! src/hotspot/os/linux/cgroupSubsystem_linux.hpp

Changeset: 34d6e5e0
Branch: master
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2026-01-21 05:56:19 +0000
URL:       https://git.openjdk.org/loom/commit/34d6e5e07b8ee43ee7f913dd47fa7c897f52e6c0

8375737: Fix -Wzero-as-null-pointer-constant warnings in arm32 code

Reviewed-by: dholmes

! src/hotspot/cpu/arm/frame_arm.cpp
! src/hotspot/cpu/arm/nativeInst_arm_32.cpp
! src/hotspot/cpu/arm/nativeInst_arm_32.hpp

Changeset: b5727d27
Branch: master
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2026-01-21 06:04:09 +0000
URL:       https://git.openjdk.org/loom/commit/b5727d27622e1e321733f8d0e606b366984104be

8375738: Fix -Wzero-as-null-pointer-constant warnings in MacOSX/bsd code

Reviewed-by: erikj, dholmes

! make/hotspot/lib/CompileGtest.gmk
! src/hotspot/os/bsd/memMapPrinter_macosx.cpp
! src/hotspot/os/bsd/os_bsd.cpp

Changeset: 560a92a6
Branch: master
Author:    Jie Fu <jiefu at openjdk.org>
Date:      2026-01-21 06:33:54 +0000
URL:       https://git.openjdk.org/loom/commit/560a92a6327221c90596bcd17a87722e4910472a

8375787: compiler/vectorapi/TestCastShapeBadOpc.java fails with release VMs

Reviewed-by: syan, lmesnik, fyang, epeter

! test/hotspot/jtreg/compiler/vectorapi/TestCastShapeBadOpc.java

Changeset: 4f87fb53
Branch: master
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-21 09:01:00 +0000
URL:       https://git.openjdk.org/loom/commit/4f87fb53ee5c6071fa57dfe9452eca9fe7b460ee

8375622: G1: Convert G1CodeRootSet to use Atomic<T>

Reviewed-by: shade, sjohanss

! src/hotspot/share/gc/g1/g1CodeRootSet.cpp

Changeset: b1340305
Branch: master
Author:    Ivan Walulya <iwalulya at openjdk.org>
Date:      2026-01-21 09:51:01 +0000
URL:       https://git.openjdk.org/loom/commit/b1340305c8f5ea53b45b8bd3bd2ebe8f74864d40

8238686: G1 may waste lots of space or fail to uncommit when observing MinHeapFreeRatio during sizing after full gc

Reviewed-by: tschatzl, sjohanss

! src/hotspot/share/gc/g1/g1Arguments.cpp

Changeset: 5c7c2f09
Branch: master
Author:    Francesco Andreuzzi <fandreuzzi at openjdk.org>
Date:      2026-01-21 10:42:05 +0000
URL:       https://git.openjdk.org/loom/commit/5c7c2f093b83a017970d9d05c258b4c0910bfc2c

8375717: Outdated link in jdk.jfr.internal.JVM javadoc

Reviewed-by: egahlin

! src/jdk.jfr/share/classes/jdk/jfr/internal/JVM.java

Changeset: 983ae96f
Branch: master
Author:    Jatin Bhateja <jbhateja at openjdk.org>
Date:      2026-01-21 11:20:18 +0000
URL:       https://git.openjdk.org/loom/commit/983ae96f60c935aa52f482d21ae6a0d947679541

8375498: [VectorAPI] Dump primary vector IR details with -XX:+TraceNewVectors

Reviewed-by: epeter

! src/hotspot/share/opto/vectorIntrinsics.cpp

Changeset: 4c9103f7
Branch: master
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2026-01-21 14:14:33 +0000
URL:       https://git.openjdk.org/loom/commit/4c9103f7b6c91b0f237859516ef72bb9ee27157e

8374998: Failing os::write - remove bad file

Reviewed-by: mdoerr, lucy

! src/hotspot/os/posix/perfMemory_posix.cpp

Changeset: 3033e6f4
Branch: master
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2026-01-21 14:55:26 +0000
URL:       https://git.openjdk.org/loom/commit/3033e6f421d0f6e0aea1d976a806d7abca7c6360

8375544: JfrSet::clear should not use memset

Reviewed-by: mgronlun

! src/hotspot/share/jfr/utilities/jfrSet.hpp

Changeset: 17086d31
Branch: master
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
Date:      2026-01-21 16:14:35 +0000
URL:       https://git.openjdk.org/loom/commit/17086d31196827432477391fd2921a82868eaa05

8375646: Some parser flags seem unused

Reviewed-by: jlahoda, vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java

Changeset: a0ac5b34
Branch: master
Author:    Damon Nguyen <dnguyen at openjdk.org>
Date:      2026-01-21 18:47:39 +0000
URL:       https://git.openjdk.org/loom/commit/a0ac5b34a742cf18d86f3ac77110bcaa00192169

8375775: JDK 26 RDP2 L10n resource files update

Reviewed-by: naoto, jlu, liach

! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_ja.properties
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties
! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_de.properties
! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_ja.properties
! src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_zh_CN.properties

Changeset: 3d919ad4
Branch: master
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
Date:      2026-01-22 01:53:42 +0000
URL:       https://git.openjdk.org/loom/commit/3d919ad43a041eb60ce51e78831c77fd3b109aee

8373366: HandshakeState should disallow suspend ops for disabler threads
8375362: Deadlock with unmount of suspended virtual thread interrupting another virtual thread

Reviewed-by: lmesnik, pchilanomate

! src/hotspot/share/runtime/handshake.cpp
! src/hotspot/share/runtime/javaThread.cpp
! src/hotspot/share/runtime/javaThread.hpp
! src/hotspot/share/runtime/mountUnmountDisabler.cpp
! src/hotspot/share/runtime/suspendResumeManager.cpp
+ test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadStateTest2/ThreadStateTest2.java
+ test/hotspot/jtreg/serviceability/jvmti/vthread/ThreadStateTest2/libThreadStateTest2.cpp

Changeset: 38a8309b
Branch: master
Author:    Ivan Walulya <iwalulya at openjdk.org>
Date:      2026-01-22 05:38:32 +0000
URL:       https://git.openjdk.org/loom/commit/38a8309b3f2544fa13448f5217e4227f0e2fe171

8341630: G1: Adopt PartialArrayState to consolidate marking stack in concurrent marking

Co-authored-by: Stefan Johansson <sjohanss at openjdk.org>
Reviewed-by: tschatzl, sjohanss

! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp
! src/hotspot/share/gc/g1/g1ConcurrentMark.inline.hpp
- src/hotspot/share/gc/g1/g1ConcurrentMarkObjArrayProcessor.cpp
- src/hotspot/share/gc/g1/g1ConcurrentMarkObjArrayProcessor.hpp
- src/hotspot/share/gc/g1/g1ConcurrentMarkObjArrayProcessor.inline.hpp
! src/hotspot/share/gc/shared/taskqueue.hpp

Changeset: 0f4d7750
Branch: master
Author:    Tobias Hartmann <thartmann at openjdk.org>
Date:      2026-01-22 06:56:51 +0000
URL:       https://git.openjdk.org/loom/commit/0f4d775085109981fbf00623d38da22655d04675

8375534: Debug method 'pp' should support compressed oops

Reviewed-by: vlivanov, phubner

! src/hotspot/share/utilities/debug.cpp

Changeset: f3381f0f
Branch: master
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-22 08:29:05 +0000
URL:       https://git.openjdk.org/loom/commit/f3381f0ffe2207e1765558f6f49e5a0280a3f920

8375314: Parallel: Crash iterating over unloaded classes for ObjectCountAfterGC event

Reviewed-by: rkennke, sjohanss, iwalulya

! src/hotspot/share/gc/g1/g1CollectedHeap.hpp
! src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp
! src/hotspot/share/gc/parallel/psParallelCompact.cpp
! src/hotspot/share/gc/parallel/psParallelCompact.hpp
! src/hotspot/share/gc/shared/collectedHeap.hpp
! src/hotspot/share/gc/shared/collectedHeap.inline.hpp
+ test/hotspot/jtreg/gc/parallel/TestObjectCountAfterGC.java

Changeset: e50bf1f2
Branch: master
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-22 08:29:27 +0000
URL:       https://git.openjdk.org/loom/commit/e50bf1f2a4702ef48cf16cc4f45d034a652bf358

8375616: G1: Convert G1BatchedTask to use Atomic<T>

Reviewed-by: sjohanss, kbarrett

! src/hotspot/share/gc/g1/g1BatchedTask.cpp
! src/hotspot/share/gc/g1/g1BatchedTask.hpp

Changeset: 92236ead
Branch: master
Author:    Quan Anh Mai <qamai at openjdk.org>
Date:      2026-01-22 08:32:01 +0000
URL:       https://git.openjdk.org/loom/commit/92236ead1dea813cf456855f0aa6b73c16e9dc70

8375618: Incorrect assert in CastLLNode::Ideal

Reviewed-by: chagedorn, dlong

! src/hotspot/share/opto/castnode.cpp
! src/hotspot/share/opto/type.cpp
! src/hotspot/share/opto/type.hpp
+ test/hotspot/jtreg/compiler/igvn/CastLLBits.java

Changeset: 63be87d7
Branch: master
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-22 08:35:03 +0000
URL:       https://git.openjdk.org/loom/commit/63be87d7f38a83c5fcdf59b54c6d63e0f0ca34d6

8375977: G1: Convert JVMCICleaningTask to use Atomic<T>

Reviewed-by: kbarrett

! src/hotspot/share/gc/g1/g1ParallelCleaning.cpp
! src/hotspot/share/gc/g1/g1ParallelCleaning.hpp

Changeset: 03038d80
Branch: master
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-22 08:35:32 +0000
URL:       https://git.openjdk.org/loom/commit/03038d802cc43b7694f554978ac9de8edca8a954

8375978: G1: Convert G1Policy to use Atomic<T>

Reviewed-by: kbarrett

! src/hotspot/share/gc/g1/g1Policy.cpp
! src/hotspot/share/gc/g1/g1Policy.hpp

Changeset: 6165daf0
Branch: master
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2026-01-22 08:50:11 +0000
URL:       https://git.openjdk.org/loom/commit/6165daf03c8582cca8e5b075560aa978b90f677c

8375458: Check legal folder of JDK image for unwanted files

Reviewed-by: erikj

! test/jdk/build/CheckFiles.java

Changeset: ddbd4617
Branch: master
Author:    Casper Norrbin <cnorrbin at openjdk.org>
Date:      2026-01-22 09:45:40 +0000
URL:       https://git.openjdk.org/loom/commit/ddbd4617a6172e3054b2afade4f304f66c79816e

8303470: containers/docker/TestMemoryAwareness.java failed with "'memory_limit_in_bytes:.*512000 k' missing from stdout/stderr"

Reviewed-by: sgehwolf, dholmes

! src/hotspot/os/linux/osContainer_linux.cpp
! test/hotspot/jtreg/ProblemList.txt

Changeset: e8eb218c
Branch: master
Author:    Liam Miller-Cushon <cushon at openjdk.org>
Date:      2026-01-22 10:05:05 +0000
URL:       https://git.openjdk.org/loom/commit/e8eb218ca2d05736adc4b0aefa4b17e3062959b8

8374643: Fix reference to implMethodKind in LambdaToMethod debug printf statement

Reviewed-by: vromero, liach

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
+ test/langtools/tools/javac/diags/examples/LambdaDeserializationStat.java
! test/langtools/tools/javac/lambda/SerializableObjectMethods.java
+ test/langtools/tools/javac/lambda/SerializableObjectMethods.out

Changeset: 6e9256cb
Branch: master
Author:    Roland Westrelin <roland at openjdk.org>
Date:      2026-01-22 10:37:26 +0000
URL:       https://git.openjdk.org/loom/commit/6e9256cb613c9a3594546a45975a81def2efcf46

8373343: C2: verify AddP base input only set for heap addresses

Reviewed-by: dlong, chagedorn, qamai

! src/hotspot/share/gc/shared/c2/barrierSetC2.cpp
! src/hotspot/share/opto/addnode.hpp
! src/hotspot/share/opto/callnode.cpp
! src/hotspot/share/opto/callnode.hpp
! src/hotspot/share/opto/escape.cpp
! src/hotspot/share/opto/graphKit.cpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/opto/macro.cpp
! src/hotspot/share/opto/macro.hpp
! src/hotspot/share/opto/macroArrayCopy.cpp
! src/hotspot/share/opto/memnode.cpp
! src/hotspot/share/opto/memnode.hpp
! src/hotspot/share/opto/parse.hpp
! src/hotspot/share/opto/parse1.cpp
! src/hotspot/share/opto/parseHelper.cpp
! src/hotspot/share/opto/subtypenode.cpp

Changeset: 0ad81fbd
Branch: master
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-22 11:04:09 +0000
URL:       https://git.openjdk.org/loom/commit/0ad81fbd161edbc8479e5af5c0f8d6098f6c72d1

8375541: G1: Race in G1BarrierSet::write_ref_field_post()

Reviewed-by: iwalulya, sjohanss, shade

! src/hotspot/share/gc/g1/g1BarrierSet.inline.hpp

Changeset: 66e950e9
Branch: master
Author:    Ivan Walulya <iwalulya at openjdk.org>
Date:      2026-01-22 11:07:42 +0000
URL:       https://git.openjdk.org/loom/commit/66e950e9b6414617952d22200831be5b0cafee85

8340470: G1: Adopt PartialArrayState to consolidate marking stack in Full GC

Co-authored-by: Stefan Johansson <sjohanss at openjdk.org>
Reviewed-by: sjohanss, tschatzl

! src/hotspot/share/gc/g1/g1FullCollector.cpp
! src/hotspot/share/gc/g1/g1FullCollector.hpp
! src/hotspot/share/gc/g1/g1FullGCMarkTask.cpp
! src/hotspot/share/gc/g1/g1FullGCMarker.cpp
! src/hotspot/share/gc/g1/g1FullGCMarker.hpp
! src/hotspot/share/gc/g1/g1FullGCMarker.inline.hpp
! src/hotspot/share/gc/g1/g1FullGCOopClosures.cpp
! src/hotspot/share/gc/g1/g1FullGCOopClosures.hpp

Changeset: 5e0ed3f4
Branch: master
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-22 11:51:37 +0000
URL:       https://git.openjdk.org/loom/commit/5e0ed3f408b6afd7496e0e0da207f7e372b0d446

8375982: G1: Convert G1YoungCollector helper classes to use Atomic<T>

Reviewed-by: kbarrett, shade

! src/hotspot/share/gc/g1/g1YoungCollector.cpp
! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp

Changeset: 0d1d4d07
Branch: master
Author:    Roland Westrelin <roland at openjdk.org>
Date:      2026-01-22 12:09:11 +0000
URL:       https://git.openjdk.org/loom/commit/0d1d4d07b9fa2368f471f30e176d446698500115

8374725: C2: assert(x_ctrl == get_late_ctrl_with_anti_dep(x->as_Load(), early_ctrl, x_ctrl)) failed: anti-dependences were already checked

Reviewed-by: chagedorn, qamai, dfenacci

! src/hotspot/share/opto/loopopts.cpp
+ test/hotspot/jtreg/compiler/loopopts/TestSinkingLoadInputOfPhi.java

Changeset: eda15aa1
Branch: master
Author:    Weijun Wang <weijun at openjdk.org>
Date:      2026-01-22 12:16:09 +0000
URL:       https://git.openjdk.org/loom/commit/eda15aa19c36142984edaa08850132ca6ae7a369

8277489: Rewrite JAAS UnixLoginModule with FFM

Co-authored-by: Martin Doerr <mdoerr at openjdk.org>
Reviewed-by: mdoerr, ascarpino, erikj

! make/modules/jdk.security.auth/Lib.gmk
! src/java.base/share/classes/module-info.java
! src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixLoginModule.java
! src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java
- src/jdk.security.auth/unix/native/libjaas/Unix.c
! test/jdk/com/sun/security/auth/module/AllPlatforms.java

Changeset: 025041ba
Branch: master
Author:    Artur Barashev <abarashev at openjdk.org>
Date:      2026-01-22 13:11:42 +0000
URL:       https://git.openjdk.org/loom/commit/025041ba04f3ae3a149b9d57d0dde4afaef37f4c

8370885: Default namedGroups values are not being filtered against algorithm constraints

Reviewed-by: hchao

! src/java.base/share/classes/sun/security/ssl/NamedGroup.java
+ test/jdk/sun/security/ssl/CipherSuite/DefaultNamedGroups.java

Changeset: 26aab3cc
Branch: master
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
Date:      2026-01-22 14:56:23 +0000
URL:       https://git.openjdk.org/loom/commit/26aab3cccdbcf98c329c8d67093eb2dbf4b164e5

8373120: Virtual thread stuck in BLOCKED state

Co-authored-by: Alan Bateman <alanb at openjdk.org>
Reviewed-by: alanb

! src/java.base/share/classes/java/lang/VirtualThread.java
+ test/jdk/java/lang/Thread/virtual/stress/NotifiedThenTimedOutWait.java


From jianbin at apache.org  Fri Jan 23 07:30:52 2026
From: jianbin at apache.org (Jianbin Chen)
Date: Fri, 23 Jan 2026 15:30:52 +0800
Subject: Performance Issues with Virtual Threads + ThreadLocal Caching in
 Third-Party Libraries (JDK 25)
Message-ID: <CAAMX02p3NL+8swRqxONzdy3voOg5MH3m1B7=rv3E=zgihj7uog@mail.gmail.com>

Hi everyone,

After upgrading to JDK 25 and switching to virtual threads, I've run into a
performance issue that I think is worth discussing.

When using the non-pooled style:

```java
Executors.newThreadPerTaskExecutor(Thread.ofVirtual().name("vt-",
1).factory());
```

I observed a **significant performance degradation** in workloads that rely
on ThreadLocal-based buffer pools in third-party libraries. A concrete
example is the Aerospike Java client:

https://github.com/aerospike/aerospike-client-java/blob/master/client/src/com/aerospike/client/util/ThreadLocalData.java

Because each virtual thread gets its own ThreadLocal instance, and virtual
threads are created per task (no pooling), these libraries end up
allocating fresh multi-KB byte buffers repeatedly in each new virtual
thread. This causes:

- A massive surge in short-lived object allocations
- Dramatically increased GC pressure
- Noticeably higher CPU usage

Even though virtual threads are cheap, the GC overhead ends up eating most
of the benefits we expect from virtual threads.

However, when I switched to a **pooled virtual thread executor** like this:

```java
new ThreadPoolExecutor(
    200, // corePoolSize
    Integer.MAX_VALUE,
    60, TimeUnit.SECONDS,
    new SynchronousQueue<>(),
    Thread.ofVirtual().name("vt-pool-", 1).factory()
);
```

The performance improved **dramatically**:

- At least 200 virtual threads are reused ? most ThreadLocal caches are hit
and reused
- GC pressure drops significantly
- CPU usage decreases accordingly

I ran benchmarks comparing:

1. Pure newThreadPerTaskExecutor (unpooled virtual threads)
2. The above ThreadPoolExecutor style (pooled virtual threads)

Even when I set `keepAliveTime = 0L` (so only the 200 core threads are kept
alive long-term and extras are immediately reclaimed), **the pooled version
still clearly outperformed the unpooled one**.

So my question is:

**In scenarios where third-party libraries heavily rely on ThreadLocal for
caching / buffering (and we cannot change those libraries to use object
pools instead), is explicitly pooling virtual threads (using a
ThreadPoolExecutor with virtual thread factory) considered a recommended /
acceptable workaround?**

Or are there better / more idiomatic ways to handle this kind of
compatibility issue with legacy ThreadLocal-based libraries when migrating
to virtual threads?

I have already opened a related discussion in the Dubbo project (since
Dubbo is one of the libraries affected in our stack):

https://github.com/apache/dubbo/issues/16042

Would love to hear your thoughts ? especially from people who have
experience running large-scale virtual-thread-based services with mixed
third-party dependencies.

Thanks in advance!


Best Regards.
Jianbin Chen, github-id: funky-eyes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260123/66556635/attachment.htm>

From alan.bateman at oracle.com  Fri Jan 23 09:25:51 2026
From: alan.bateman at oracle.com (Alan Bateman)
Date: Fri, 23 Jan 2026 09:25:51 +0000
Subject: Performance Issues with Virtual Threads + ThreadLocal Caching in
 Third-Party Libraries (JDK 25)
In-Reply-To: <CAAMX02p3NL+8swRqxONzdy3voOg5MH3m1B7=rv3E=zgihj7uog@mail.gmail.com>
References: <CAAMX02p3NL+8swRqxONzdy3voOg5MH3m1B7=rv3E=zgihj7uog@mail.gmail.com>
Message-ID: <fdc45c0e-ec91-4fa9-af2b-deec517849c5@oracle.com>

On 23/01/2026 07:30, Jianbin Chen wrote:
> :
>
> So my question is:
>
> **In scenarios where third-party libraries heavily rely on ThreadLocal 
> for caching / buffering (and we cannot change those libraries to use 
> object pools instead), is explicitly pooling virtual threads (using a 
> ThreadPoolExecutor with virtual thread factory) considered a 
> recommended / acceptable workaround?**
>
> Or are there better / more idiomatic ways to handle this kind of 
> compatibility issue with legacy ThreadLocal-based libraries when 
> migrating to virtual threads?
>
> I have already opened a related discussion in the Dubbo project (since 
> Dubbo is one of the libraries affected in our stack):
>
> https://github.com/apache/dubbo/issues/16042
>
> Would love to hear your thoughts ? especially from people who have 
> experience running large-scale virtual-thread-based services with 
> mixed third-party dependencies.
>

The guidelines that we put in JEP 444 [1] is to not pool virtual threads 
and to avoid caching costing resources in thread locals. Virtual threads 
support thread locals of course but that is not useful when some library 
is looking to share a costly resource between tasks that run on the same 
thread in a thread pool.

I don't know anything about Aerospike but working with the maintainers 
of that library to re-work its buffer management seems like the right 
course of action here. Your mail says "byte buffers". If this is 
ByteBuffer it might be that they are caching direct buffers as they are 
expensive to create (and managed by the GC). Maybe they could look at 
using MemorySegment (it's easy to get a ByteBuffer view of a memory 
segment) and allocate from an arena that better matches the lifecycle.

Hopefully others will share their experiences with migration as it is 
indeed challenging to migrate code developed for thread pools to work 
efficiently on virtual threads where there is 1-1 relationship between 
the task to execute and the thread.

-Alan

[1] https://openjdk.org/jeps/444#Thread-local-variables

From alan.bateman at oracle.com  Fri Jan 23 09:36:52 2026
From: alan.bateman at oracle.com (Alan Bateman)
Date: Fri, 23 Jan 2026 09:36:52 +0000
Subject: ScopedValue inheritance with unstructured concurrency?
In-Reply-To: <CAJ0wWSgnPWBsspe7cvUwpyfksoAorxTzstqNN2eS+oYXj9NEyw@mail.gmail.com>
References: <CAJ0wWSgnPWBsspe7cvUwpyfksoAorxTzstqNN2eS+oYXj9NEyw@mail.gmail.com>
Message-ID: <5f5d7cd9-379a-4cc9-805e-4de85cc67b70@oracle.com>

On 22/01/2026 08:52, Omar Aloraini wrote:
> I'm using `Executors.newThreadPerTaskExecutor` where I need a set of 
> independent?actors(threads) to interact with each other. Right now, 
> everytime I start a new task I have to bind all my scoped values(just 
> one at the moment), but in the general?case, it would be useful to 
> have an implementation of ExecutorService that captures all(or some) 
> ScopeValues at task submission point(and maybe at ES construction point).
>
> ```
> Task task? = ....
> executorService.submit(() -> {
> ? ScopedValue.where(AsyncScheduledTask.VALUE, task.asRunning())
> ? ? .where(TaskControlImpl.VALUE, new TaskControlImpl(task))
> ? ? .call(() -> {
> ```
>
> It would be nice to have `Exuectors.scopeCapturing(ExecutorService 
> delegate, ScopeValues<?>... values)` or even without the varargs. Just 
> capture everything(if performance is not an issue).
>
> I can't speak for people writing web servers or frameworks. But I 
> think it would be useful there as well.
>
> In addition it will make ScopedValue the universal context 
> propagation?mechanism for both structured and unstructured?cases. The 
> current solution used by Spring and some other libraries 
> `https://github.com/micrometer-metrics/context-propagation` 
> <https://github.com/micrometer-metrics/context-propagation>.
>
Inheritance of ScopedValues is not compatibility with unstructured use 
as there is no guarantee that the the lifetime of the ScopedValue 
binding will fully enclose the lifetime of the "child" thread.

Although expensive, I suspect inheritable thread-locals (with copy 
rather than sharing) is closer to what you are looking for.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260123/49cd7398/attachment.htm>

From jianbin at apache.org  Fri Jan 23 10:12:31 2026
From: jianbin at apache.org (Jianbin Chen)
Date: Fri, 23 Jan 2026 18:12:31 +0800
Subject: Performance Issues with Virtual Threads + ThreadLocal Caching in
 Third-Party Libraries (JDK 25)
In-Reply-To: <fdc45c0e-ec91-4fa9-af2b-deec517849c5@oracle.com>
References: <CAAMX02p3NL+8swRqxONzdy3voOg5MH3m1B7=rv3E=zgihj7uog@mail.gmail.com>
 <fdc45c0e-ec91-4fa9-af2b-deec517849c5@oracle.com>
Message-ID: <CAAMX02p8OFant2xnCJOCgBmz=s9+gmoW70-zd0GLn8X2pSmRuA@mail.gmail.com>

Hi Alan,

Thanks for your reply and for mentioning JEP 444.
I?ve gone through the guidance in JEP 444 and have some understanding of it
? which is exactly why I?m feeling a bit puzzled in practice and would
really like to hear your thoughts.

Background ? ThreadLocal example (Aerospike)
```java
private static final ThreadLocal<byte[]> BufferThreadLocal = new
ThreadLocal<byte[]>() {
    @Override
    protected byte[] initialValue() {
        return new byte[DefaultBufferSize];
    }
};
```
This Aerospike code allocates a default 8KB byte[] whenever a new thread is
created and stores it in a ThreadLocal for per-thread caching.

My concern
- With a traditional platform-thread pool, those ThreadLocal byte[]
instances are effectively reused because threads are long-lived and pooled.
- If we switch to creating a brand-new virtual thread per task (no
pooling), each virtual thread gets its own fresh ThreadLocal byte[], which
leads to many short-lived 8KB allocations.
- That raises allocation rate and GC pressure (despite collectors like
ZGC), because ThreadLocal caches aren?t reused when threads are ephemeral.

So my question is: for applications originally designed around
platform-thread pools, wouldn?t partially pooling virtual threads be
beneficial? For example, Tomcat?s default max threads is 200 ? if I keep a
pool of 200 virtual threads, then when load exceeds that core size, a
SynchronousQueue will naturally cause new virtual threads to be created on
demand. This seems to preserve the behavior that ThreadLocal-based
libraries expect, without losing the ability to expand under spikes. Since
virtual threads are very lightweight, pooling a reasonable number (e.g.,
200) seems to have negligible memory downside while retaining ThreadLocal
cache effectiveness.

Empirical test I ran
(I ran a microbenchmark comparing an unpooled per-task virtual-thread
executor and a ThreadPoolExecutor that keeps 200 core virtual threads.)

```java
public static void main(String[] args) throws InterruptedException {
    Executor executor =
Executors.newThreadPerTaskExecutor(Thread.ofVirtual().name("test-",
1).factory());
    Executor executor2 = new ThreadPoolExecutor(
        200,
        Integer.MAX_VALUE,
        0L,
        java.util.concurrent.TimeUnit.SECONDS,
        new SynchronousQueue<>(),
        Thread.ofVirtual().name("test-threadpool-", 1).factory()
    );

    // Warm-up
    for (int i = 0; i < 10100; i++) {
        executor.execute(() -> {
            // simulate I/O wait
            try { Thread.sleep(100); } catch (InterruptedException e) {
throw new RuntimeException(e); }
        });
        executor2.execute(() -> {
            // simulate I/O wait
            try { Thread.sleep(100); } catch (InterruptedException e) {
throw new RuntimeException(e); }
        });
    }

    // Ensure JIT + warm-up complete
    Thread.sleep(5000);

    long start = System.currentTimeMillis();
    CountDownLatch countDownLatch = new CountDownLatch(50000);
    for (int i = 0; i < 50000; i++) {
        executor.execute(() -> {
            try { Thread.sleep(100); countDownLatch.countDown(); } catch
(InterruptedException e) { throw new RuntimeException(e); }
        });
    }
    countDownLatch.await();
    System.out.println("thread time: " + (System.currentTimeMillis() -
start) + " ms");

    start = System.currentTimeMillis();
    CountDownLatch countDownLatch2 = new CountDownLatch(50000);
    for (int i = 0; i < 50000; i++) {
        executor2.execute(() -> {
            try { Thread.sleep(100); countDownLatch2.countDown(); } catch
(InterruptedException e) { throw new RuntimeException(e); }
        });
    }
    countDownLatch.await();
    System.out.println("thread pool time: " + (System.currentTimeMillis() -
start) + " ms");
}
```

Result summary
- In my runs, the pooled virtual-thread executor (executor2) performed
better than the unpooled per-task virtual-thread executor.
- Even when I increased load by 10x or 100x, the pooled virtual-thread
executor still showed better performance.
- In realistic workloads, it seems pooling some virtual threads reduces
allocation/GC overhead and improves throughput compared to strictly
unpooled virtual threads.

Final thought / request for feedback
- From my perspective, for systems originally tuned for platform-thread
pools, partially pooling virtual threads seems to have no obvious downside
and can restore ThreadLocal cache effectiveness used by many third-party
libraries.
- If I?ve misunderstood JEP 444 recommendations, virtual-thread semantics,
or ThreadLocal behavior, please point out what I?m missing. I?d appreciate
your guidance.

Best Regards.
Jianbin Chen, github-id: funky-eyes

Alan Bateman <alan.bateman at oracle.com> ? 2026?1?23??? 17:27???

> On 23/01/2026 07:30, Jianbin Chen wrote:
> > :
> >
> > So my question is:
> >
> > **In scenarios where third-party libraries heavily rely on ThreadLocal
> > for caching / buffering (and we cannot change those libraries to use
> > object pools instead), is explicitly pooling virtual threads (using a
> > ThreadPoolExecutor with virtual thread factory) considered a
> > recommended / acceptable workaround?**
> >
> > Or are there better / more idiomatic ways to handle this kind of
> > compatibility issue with legacy ThreadLocal-based libraries when
> > migrating to virtual threads?
> >
> > I have already opened a related discussion in the Dubbo project (since
> > Dubbo is one of the libraries affected in our stack):
> >
> > https://github.com/apache/dubbo/issues/16042
> >
> > Would love to hear your thoughts ? especially from people who have
> > experience running large-scale virtual-thread-based services with
> > mixed third-party dependencies.
> >
>
> The guidelines that we put in JEP 444 [1] is to not pool virtual threads
> and to avoid caching costing resources in thread locals. Virtual threads
> support thread locals of course but that is not useful when some library
> is looking to share a costly resource between tasks that run on the same
> thread in a thread pool.
>
> I don't know anything about Aerospike but working with the maintainers
> of that library to re-work its buffer management seems like the right
> course of action here. Your mail says "byte buffers". If this is
> ByteBuffer it might be that they are caching direct buffers as they are
> expensive to create (and managed by the GC). Maybe they could look at
> using MemorySegment (it's easy to get a ByteBuffer view of a memory
> segment) and allocate from an arena that better matches the lifecycle.
>
> Hopefully others will share their experiences with migration as it is
> indeed challenging to migrate code developed for thread pools to work
> efficiently on virtual threads where there is 1-1 relationship between
> the task to execute and the thread.
>
> -Alan
>
> [1] https://openjdk.org/jeps/444#Thread-local-variables
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260123/f57c2b4f/attachment-0001.htm>

From robaho at me.com  Fri Jan 23 12:28:00 2026
From: robaho at me.com (robert engels)
Date: Fri, 23 Jan 2026 06:28:00 -0600
Subject: Performance Issues with Virtual Threads + ThreadLocal Caching in
 Third-Party Libraries (JDK 25)
In-Reply-To: <CAAMX02p8OFant2xnCJOCgBmz=s9+gmoW70-zd0GLn8X2pSmRuA@mail.gmail.com>
References: <CAAMX02p8OFant2xnCJOCgBmz=s9+gmoW70-zd0GLn8X2pSmRuA@mail.gmail.com>
Message-ID: <D0FA7448-57F0-48DA-B28F-186AF8A1809D@me.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260123/ae145989/attachment.htm>

From jianbin at apache.org  Fri Jan 23 12:47:37 2026
From: jianbin at apache.org (Jianbin Chen)
Date: Fri, 23 Jan 2026 20:47:37 +0800
Subject: Performance Issues with Virtual Threads + ThreadLocal Caching in
 Third-Party Libraries (JDK 25)
In-Reply-To: <D0FA7448-57F0-48DA-B28F-186AF8A1809D@me.com>
References: <CAAMX02p8OFant2xnCJOCgBmz=s9+gmoW70-zd0GLn8X2pSmRuA@mail.gmail.com>
 <D0FA7448-57F0-48DA-B28F-186AF8A1809D@me.com>
Message-ID: <CAAMX02rG4eyHpS5NsHpq5vTG4xYgj8zBff4yGGcyM1V-sPMw2A@mail.gmail.com>

Hi Robert,

Thanks you, but I'm a bit confused. In the example above, I only set the
core pool size to 200 virtual threads, but for the specific test case we?re
talking about, the concurrency isn?t actually being limited by the pool
size at all. Since the maximum thread count is Integer.MAX_VALUE and it?s
using a SynchronousQueue, tasks are handed off immediately and a new thread
gets created to run them right away anyway.

Best Regards.
Jianbin Chen, github-id: funky-eyes

robert engels <robaho at me.com> ? 2026?1?23??? 20:28???

> Try using a semaphore to limit the maximum number of tasks in progress at
> anyone time - that is what is causing your memory spike. Think of it this
> way since VT threads are so cheap to create - you are essentially creating
> them all at once - making the working set size equally to the maximum.  So
> you have N * WSS, where as in the other you have POOLSIZE * WSS.
>
> On Jan 23, 2026, at 4:14?AM, Jianbin Chen <jianbin at apache.org> wrote:
>
> ?
> Hi Alan,
>
> Thanks for your reply and for mentioning JEP 444.
> I?ve gone through the guidance in JEP 444 and have some understanding of
> it ? which is exactly why I?m feeling a bit puzzled in practice and would
> really like to hear your thoughts.
>
> Background ? ThreadLocal example (Aerospike)
> ```java
> private static final ThreadLocal<byte[]> BufferThreadLocal = new
> ThreadLocal<byte[]>() {
>     @Override
>     protected byte[] initialValue() {
>         return new byte[DefaultBufferSize];
>     }
> };
> ```
> This Aerospike code allocates a default 8KB byte[] whenever a new thread
> is created and stores it in a ThreadLocal for per-thread caching.
>
> My concern
> - With a traditional platform-thread pool, those ThreadLocal byte[]
> instances are effectively reused because threads are long-lived and pooled.
> - If we switch to creating a brand-new virtual thread per task (no
> pooling), each virtual thread gets its own fresh ThreadLocal byte[], which
> leads to many short-lived 8KB allocations.
> - That raises allocation rate and GC pressure (despite collectors like
> ZGC), because ThreadLocal caches aren?t reused when threads are ephemeral.
>
> So my question is: for applications originally designed around
> platform-thread pools, wouldn?t partially pooling virtual threads be
> beneficial? For example, Tomcat?s default max threads is 200 ? if I keep a
> pool of 200 virtual threads, then when load exceeds that core size, a
> SynchronousQueue will naturally cause new virtual threads to be created on
> demand. This seems to preserve the behavior that ThreadLocal-based
> libraries expect, without losing the ability to expand under spikes. Since
> virtual threads are very lightweight, pooling a reasonable number (e.g.,
> 200) seems to have negligible memory downside while retaining ThreadLocal
> cache effectiveness.
>
> Empirical test I ran
> (I ran a microbenchmark comparing an unpooled per-task virtual-thread
> executor and a ThreadPoolExecutor that keeps 200 core virtual threads.)
>
> ```java
> public static void main(String[] args) throws InterruptedException {
>     Executor executor =
> Executors.newThreadPerTaskExecutor(Thread.ofVirtual().name("test-",
> 1).factory());
>     Executor executor2 = new ThreadPoolExecutor(
>         200,
>         Integer.MAX_VALUE,
>         0L,
>         java.util.concurrent.TimeUnit.SECONDS,
>         new SynchronousQueue<>(),
>         Thread.ofVirtual().name("test-threadpool-", 1).factory()
>     );
>
>     // Warm-up
>     for (int i = 0; i < 10100; i++) {
>         executor.execute(() -> {
>             // simulate I/O wait
>             try { Thread.sleep(100); } catch (InterruptedException e) {
> throw new RuntimeException(e); }
>         });
>         executor2.execute(() -> {
>             // simulate I/O wait
>             try { Thread.sleep(100); } catch (InterruptedException e) {
> throw new RuntimeException(e); }
>         });
>     }
>
>     // Ensure JIT + warm-up complete
>     Thread.sleep(5000);
>
>     long start = System.currentTimeMillis();
>     CountDownLatch countDownLatch = new CountDownLatch(50000);
>     for (int i = 0; i < 50000; i++) {
>         executor.execute(() -> {
>             try { Thread.sleep(100); countDownLatch.countDown(); } catch
> (InterruptedException e) { throw new RuntimeException(e); }
>         });
>     }
>     countDownLatch.await();
>     System.out.println("thread time: " + (System.currentTimeMillis() -
> start) + " ms");
>
>     start = System.currentTimeMillis();
>     CountDownLatch countDownLatch2 = new CountDownLatch(50000);
>     for (int i = 0; i < 50000; i++) {
>         executor2.execute(() -> {
>             try { Thread.sleep(100); countDownLatch2.countDown(); } catch
> (InterruptedException e) { throw new RuntimeException(e); }
>         });
>     }
>     countDownLatch.await();
>     System.out.println("thread pool time: " + (System.currentTimeMillis()
> - start) + " ms");
> }
> ```
>
> Result summary
> - In my runs, the pooled virtual-thread executor (executor2) performed
> better than the unpooled per-task virtual-thread executor.
> - Even when I increased load by 10x or 100x, the pooled virtual-thread
> executor still showed better performance.
> - In realistic workloads, it seems pooling some virtual threads reduces
> allocation/GC overhead and improves throughput compared to strictly
> unpooled virtual threads.
>
> Final thought / request for feedback
> - From my perspective, for systems originally tuned for platform-thread
> pools, partially pooling virtual threads seems to have no obvious downside
> and can restore ThreadLocal cache effectiveness used by many third-party
> libraries.
> - If I?ve misunderstood JEP 444 recommendations, virtual-thread semantics,
> or ThreadLocal behavior, please point out what I?m missing. I?d appreciate
> your guidance.
>
> Best Regards.
> Jianbin Chen, github-id: funky-eyes
>
> Alan Bateman <alan.bateman at oracle.com> ? 2026?1?23??? 17:27???
>
>> On 23/01/2026 07:30, Jianbin Chen wrote:
>> > :
>> >
>> > So my question is:
>> >
>> > **In scenarios where third-party libraries heavily rely on ThreadLocal
>> > for caching / buffering (and we cannot change those libraries to use
>> > object pools instead), is explicitly pooling virtual threads (using a
>> > ThreadPoolExecutor with virtual thread factory) considered a
>> > recommended / acceptable workaround?**
>> >
>> > Or are there better / more idiomatic ways to handle this kind of
>> > compatibility issue with legacy ThreadLocal-based libraries when
>> > migrating to virtual threads?
>> >
>> > I have already opened a related discussion in the Dubbo project (since
>> > Dubbo is one of the libraries affected in our stack):
>> >
>> > https://github.com/apache/dubbo/issues/16042
>> >
>> > Would love to hear your thoughts ? especially from people who have
>> > experience running large-scale virtual-thread-based services with
>> > mixed third-party dependencies.
>> >
>>
>> The guidelines that we put in JEP 444 [1] is to not pool virtual threads
>> and to avoid caching costing resources in thread locals. Virtual threads
>> support thread locals of course but that is not useful when some library
>> is looking to share a costly resource between tasks that run on the same
>> thread in a thread pool.
>>
>> I don't know anything about Aerospike but working with the maintainers
>> of that library to re-work its buffer management seems like the right
>> course of action here. Your mail says "byte buffers". If this is
>> ByteBuffer it might be that they are caching direct buffers as they are
>> expensive to create (and managed by the GC). Maybe they could look at
>> using MemorySegment (it's easy to get a ByteBuffer view of a memory
>> segment) and allocate from an arena that better matches the lifecycle.
>>
>> Hopefully others will share their experiences with migration as it is
>> indeed challenging to migrate code developed for thread pools to work
>> efficiently on virtual threads where there is 1-1 relationship between
>> the task to execute and the thread.
>>
>> -Alan
>>
>> [1] https://openjdk.org/jeps/444#Thread-local-variables
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260123/8eeb9a2f/attachment-0001.htm>

From robaho at me.com  Fri Jan 23 12:57:51 2026
From: robaho at me.com (robert engels)
Date: Fri, 23 Jan 2026 06:57:51 -0600
Subject: Performance Issues with Virtual Threads + ThreadLocal Caching in
 Third-Party Libraries (JDK 25)
In-Reply-To: <CAAMX02rG4eyHpS5NsHpq5vTG4xYgj8zBff4yGGcyM1V-sPMw2A@mail.gmail.com>
References: <CAAMX02rG4eyHpS5NsHpq5vTG4xYgj8zBff4yGGcyM1V-sPMw2A@mail.gmail.com>
Message-ID: <4DCFD35E-E861-4F37-AE20-FA7701260CEC@me.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260123/7869eb7b/attachment.htm>

From jianbin at apache.org  Fri Jan 23 13:42:20 2026
From: jianbin at apache.org (Jianbin Chen)
Date: Fri, 23 Jan 2026 21:42:20 +0800
Subject: Performance Issues with Virtual Threads + ThreadLocal Caching in
 Third-Party Libraries (JDK 25)
In-Reply-To: <4DCFD35E-E861-4F37-AE20-FA7701260CEC@me.com>
References: <CAAMX02rG4eyHpS5NsHpq5vTG4xYgj8zBff4yGGcyM1V-sPMw2A@mail.gmail.com>
 <4DCFD35E-E861-4F37-AE20-FA7701260CEC@me.com>
Message-ID: <CAAMX02rQ6tADgAQnyf5A6mtdMw8R0BkD-yJcSynO-rb10C6LwA@mail.gmail.com>

The question is why I need to use a semaphore to control the number of
concurrently running tasks. In my particular example, the goal is simply to
keep the concurrency level the same across different thread pool
implementations so I can fairly compare which one completes all the tasks
faster. This isn't solely about memory consumption?purely from a
**performance** perspective (e.g., total throughput or wall-clock time to
finish the workload), the same number of concurrent tasks completes
noticeably faster when using pooled virtual threads.

My email probably didn't explain this clearly enough. In reality, I have
two main questions:

1. When a third-party library uses `ThreadLocal` as a cache/pool (e.g., to
hold expensive reusable objects like connections, formatters, or parsers),
is switching to a **pooled virtual thread executor** the only viable
solution?assuming we cannot modify the third-party library code?

2. When running the exact same number of concurrent tasks, pooled virtual
threads deliver better performance.

Both questions point toward the same conclusion: for an application
originally built around a traditional platform thread pool, after upgrading
to JDK 21/25, moving to a **pooled virtual threads** approach is generally
superior to simply using non-pooled (unbounded) virtual threads.

If any part of this reasoning or conclusion is mistaken, I would really
appreciate being corrected ? thank you very much in advance for any
feedback or different experiences you can share!

Best Regards.
Jianbin Chen, github-id: funky-eyes

robert engels <robaho at me.com> ? 2026?1?23??? 20:58???

> Exactly, this is your problem. The total number of tasks will all be
> running at once in the thread per task model.
>
> On Jan 23, 2026, at 6:49?AM, Jianbin Chen <jianbin at apache.org> wrote:
>
> ?
> Hi Robert,
>
> Thanks you, but I'm a bit confused. In the example above, I only set the
> core pool size to 200 virtual threads, but for the specific test case we?re
> talking about, the concurrency isn?t actually being limited by the pool
> size at all. Since the maximum thread count is Integer.MAX_VALUE and it?s
> using a SynchronousQueue, tasks are handed off immediately and a new thread
> gets created to run them right away anyway.
>
> Best Regards.
> Jianbin Chen, github-id: funky-eyes
>
> robert engels <robaho at me.com> ? 2026?1?23??? 20:28???
>
>> Try using a semaphore to limit the maximum number of tasks in progress at
>> anyone time - that is what is causing your memory spike. Think of it this
>> way since VT threads are so cheap to create - you are essentially creating
>> them all at once - making the working set size equally to the maximum.  So
>> you have N * WSS, where as in the other you have POOLSIZE * WSS.
>>
>> On Jan 23, 2026, at 4:14?AM, Jianbin Chen <jianbin at apache.org> wrote:
>>
>> ?
>> Hi Alan,
>>
>> Thanks for your reply and for mentioning JEP 444.
>> I?ve gone through the guidance in JEP 444 and have some understanding of
>> it ? which is exactly why I?m feeling a bit puzzled in practice and would
>> really like to hear your thoughts.
>>
>> Background ? ThreadLocal example (Aerospike)
>> ```java
>> private static final ThreadLocal<byte[]> BufferThreadLocal = new
>> ThreadLocal<byte[]>() {
>>     @Override
>>     protected byte[] initialValue() {
>>         return new byte[DefaultBufferSize];
>>     }
>> };
>> ```
>> This Aerospike code allocates a default 8KB byte[] whenever a new thread
>> is created and stores it in a ThreadLocal for per-thread caching.
>>
>> My concern
>> - With a traditional platform-thread pool, those ThreadLocal byte[]
>> instances are effectively reused because threads are long-lived and pooled.
>> - If we switch to creating a brand-new virtual thread per task (no
>> pooling), each virtual thread gets its own fresh ThreadLocal byte[], which
>> leads to many short-lived 8KB allocations.
>> - That raises allocation rate and GC pressure (despite collectors like
>> ZGC), because ThreadLocal caches aren?t reused when threads are ephemeral.
>>
>> So my question is: for applications originally designed around
>> platform-thread pools, wouldn?t partially pooling virtual threads be
>> beneficial? For example, Tomcat?s default max threads is 200 ? if I keep a
>> pool of 200 virtual threads, then when load exceeds that core size, a
>> SynchronousQueue will naturally cause new virtual threads to be created on
>> demand. This seems to preserve the behavior that ThreadLocal-based
>> libraries expect, without losing the ability to expand under spikes. Since
>> virtual threads are very lightweight, pooling a reasonable number (e.g.,
>> 200) seems to have negligible memory downside while retaining ThreadLocal
>> cache effectiveness.
>>
>> Empirical test I ran
>> (I ran a microbenchmark comparing an unpooled per-task virtual-thread
>> executor and a ThreadPoolExecutor that keeps 200 core virtual threads.)
>>
>> ```java
>> public static void main(String[] args) throws InterruptedException {
>>     Executor executor =
>> Executors.newThreadPerTaskExecutor(Thread.ofVirtual().name("test-",
>> 1).factory());
>>     Executor executor2 = new ThreadPoolExecutor(
>>         200,
>>         Integer.MAX_VALUE,
>>         0L,
>>         java.util.concurrent.TimeUnit.SECONDS,
>>         new SynchronousQueue<>(),
>>         Thread.ofVirtual().name("test-threadpool-", 1).factory()
>>     );
>>
>>     // Warm-up
>>     for (int i = 0; i < 10100; i++) {
>>         executor.execute(() -> {
>>             // simulate I/O wait
>>             try { Thread.sleep(100); } catch (InterruptedException e) {
>> throw new RuntimeException(e); }
>>         });
>>         executor2.execute(() -> {
>>             // simulate I/O wait
>>             try { Thread.sleep(100); } catch (InterruptedException e) {
>> throw new RuntimeException(e); }
>>         });
>>     }
>>
>>     // Ensure JIT + warm-up complete
>>     Thread.sleep(5000);
>>
>>     long start = System.currentTimeMillis();
>>     CountDownLatch countDownLatch = new CountDownLatch(50000);
>>     for (int i = 0; i < 50000; i++) {
>>         executor.execute(() -> {
>>             try { Thread.sleep(100); countDownLatch.countDown(); } catch
>> (InterruptedException e) { throw new RuntimeException(e); }
>>         });
>>     }
>>     countDownLatch.await();
>>     System.out.println("thread time: " + (System.currentTimeMillis() -
>> start) + " ms");
>>
>>     start = System.currentTimeMillis();
>>     CountDownLatch countDownLatch2 = new CountDownLatch(50000);
>>     for (int i = 0; i < 50000; i++) {
>>         executor2.execute(() -> {
>>             try { Thread.sleep(100); countDownLatch2.countDown(); } catch
>> (InterruptedException e) { throw new RuntimeException(e); }
>>         });
>>     }
>>     countDownLatch.await();
>>     System.out.println("thread pool time: " + (System.currentTimeMillis()
>> - start) + " ms");
>> }
>> ```
>>
>> Result summary
>> - In my runs, the pooled virtual-thread executor (executor2) performed
>> better than the unpooled per-task virtual-thread executor.
>> - Even when I increased load by 10x or 100x, the pooled virtual-thread
>> executor still showed better performance.
>> - In realistic workloads, it seems pooling some virtual threads reduces
>> allocation/GC overhead and improves throughput compared to strictly
>> unpooled virtual threads.
>>
>> Final thought / request for feedback
>> - From my perspective, for systems originally tuned for platform-thread
>> pools, partially pooling virtual threads seems to have no obvious downside
>> and can restore ThreadLocal cache effectiveness used by many third-party
>> libraries.
>> - If I?ve misunderstood JEP 444 recommendations, virtual-thread
>> semantics, or ThreadLocal behavior, please point out what I?m missing. I?d
>> appreciate your guidance.
>>
>> Best Regards.
>> Jianbin Chen, github-id: funky-eyes
>>
>> Alan Bateman <alan.bateman at oracle.com> ? 2026?1?23??? 17:27???
>>
>>> On 23/01/2026 07:30, Jianbin Chen wrote:
>>> > :
>>> >
>>> > So my question is:
>>> >
>>> > **In scenarios where third-party libraries heavily rely on ThreadLocal
>>> > for caching / buffering (and we cannot change those libraries to use
>>> > object pools instead), is explicitly pooling virtual threads (using a
>>> > ThreadPoolExecutor with virtual thread factory) considered a
>>> > recommended / acceptable workaround?**
>>> >
>>> > Or are there better / more idiomatic ways to handle this kind of
>>> > compatibility issue with legacy ThreadLocal-based libraries when
>>> > migrating to virtual threads?
>>> >
>>> > I have already opened a related discussion in the Dubbo project (since
>>> > Dubbo is one of the libraries affected in our stack):
>>> >
>>> > https://github.com/apache/dubbo/issues/16042
>>> >
>>> > Would love to hear your thoughts ? especially from people who have
>>> > experience running large-scale virtual-thread-based services with
>>> > mixed third-party dependencies.
>>> >
>>>
>>> The guidelines that we put in JEP 444 [1] is to not pool virtual threads
>>> and to avoid caching costing resources in thread locals. Virtual threads
>>> support thread locals of course but that is not useful when some library
>>> is looking to share a costly resource between tasks that run on the same
>>> thread in a thread pool.
>>>
>>> I don't know anything about Aerospike but working with the maintainers
>>> of that library to re-work its buffer management seems like the right
>>> course of action here. Your mail says "byte buffers". If this is
>>> ByteBuffer it might be that they are caching direct buffers as they are
>>> expensive to create (and managed by the GC). Maybe they could look at
>>> using MemorySegment (it's easy to get a ByteBuffer view of a memory
>>> segment) and allocate from an arena that better matches the lifecycle.
>>>
>>> Hopefully others will share their experiences with migration as it is
>>> indeed challenging to migrate code developed for thread pools to work
>>> efficiently on virtual threads where there is 1-1 relationship between
>>> the task to execute and the thread.
>>>
>>> -Alan
>>>
>>> [1] https://openjdk.org/jeps/444#Thread-local-variables
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260123/103a5654/attachment-0001.htm>

From rengels at ix.netcom.com  Fri Jan 23 13:51:04 2026
From: rengels at ix.netcom.com (Robert Engels)
Date: Fri, 23 Jan 2026 07:51:04 -0600
Subject: Performance Issues with Virtual Threads + ThreadLocal Caching in
 Third-Party Libraries (JDK 25)
In-Reply-To: <CAAMX02rQ6tADgAQnyf5A6mtdMw8R0BkD-yJcSynO-rb10C6LwA@mail.gmail.com>
References: <CAAMX02rQ6tADgAQnyf5A6mtdMw8R0BkD-yJcSynO-rb10C6LwA@mail.gmail.com>
Message-ID: <EB4BBE87-1FB6-4880-AF76-6BEB182E141E@ix.netcom.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260123/9762a963/attachment.htm>

From jianbin at apache.org  Fri Jan 23 14:10:13 2026
From: jianbin at apache.org (Jianbin Chen)
Date: Fri, 23 Jan 2026 22:10:13 +0800
Subject: Performance Issues with Virtual Threads + ThreadLocal Caching in
 Third-Party Libraries (JDK 25)
In-Reply-To: <EB4BBE87-1FB6-4880-AF76-6BEB182E141E@ix.netcom.com>
References: <CAAMX02rQ6tADgAQnyf5A6mtdMw8R0BkD-yJcSynO-rb10C6LwA@mail.gmail.com>
 <EB4BBE87-1FB6-4880-AF76-6BEB182E141E@ix.netcom.com>
Message-ID: <CAAMX02o7ugTq-EuZO-dp_vhc0kHz2fp1q5RVNn7_N7JX7RvDYQ@mail.gmail.com>

I'm sorry, Robert?perhaps I didn't explain my example clearly enough.
Here's the code in question:

```java
Executor executor2 = new ThreadPoolExecutor(
    200,
    Integer.MAX_VALUE,
    0L,
    java.util.concurrent.TimeUnit.SECONDS,
    new SynchronousQueue<>(),
    Thread.ofVirtual().name("test-threadpool-", 1).factory()
);
```

In this example, the pooled virtual threads don't implement any
backpressure mechanism; they simply maintain a core pool of 200 virtual
threads. Given that the queue is a `SynchronousQueue` and the maximum pool
size is set to `Integer.MAX_VALUE`, once the concurrent tasks exceed 200,
its behavior becomes identical to that of non-pooled virtual threads.

>From my perspective, this example demonstrates that the benefits of pooling
virtual threads outweigh those of creating a new virtual thread for every
single task. In IO-bound scenarios, the virtual threads are directly reused
rather than being recreated each time, and the memory footprint of virtual
threads is far smaller than that of platform threads (which are controlled
by the `-Xss` flag). Additionally, with pooled virtual threads, the 8KB
`byte[]` cache I mentioned earlier (stored in `ThreadLocal`) can also be
reused, which further reduces overall memory usage?wouldn't you agree?

Best Regards.
Jianbin Chen, github-id: funky-eyes

Robert Engels <rengels at ix.netcom.com> ? 2026?1?23??? 21:52???

> Because VT are so efficient to create, without any back pressure they will
> all be created and running at essentially the same time (dramatically
> raising the amount of memory in use) - versus with a pool of size N you
> will have at most N running at once. In a REAL WORLD application there are
> often external limiters (like number of tcp connections) that provide a
> limit.
>
> If your tasks are purely cpu bound you should probably be using a capped
> thread pool of platform threads as it makes no sense to have more threads
> than available cores.
>
>
>
> On Jan 23, 2026, at 7:42?AM, Jianbin Chen <jianbin at apache.org> wrote:
>
> ?
> The question is why I need to use a semaphore to control the number of
> concurrently running tasks. In my particular example, the goal is simply to
> keep the concurrency level the same across different thread pool
> implementations so I can fairly compare which one completes all the tasks
> faster. This isn't solely about memory consumption?purely from a
> **performance** perspective (e.g., total throughput or wall-clock time to
> finish the workload), the same number of concurrent tasks completes
> noticeably faster when using pooled virtual threads.
>
> My email probably didn't explain this clearly enough. In reality, I have
> two main questions:
>
> 1. When a third-party library uses `ThreadLocal` as a cache/pool (e.g., to
> hold expensive reusable objects like connections, formatters, or parsers),
> is switching to a **pooled virtual thread executor** the only viable
> solution?assuming we cannot modify the third-party library code?
>
> 2. When running the exact same number of concurrent tasks, pooled virtual
> threads deliver better performance.
>
> Both questions point toward the same conclusion: for an application
> originally built around a traditional platform thread pool, after upgrading
> to JDK 21/25, moving to a **pooled virtual threads** approach is generally
> superior to simply using non-pooled (unbounded) virtual threads.
>
> If any part of this reasoning or conclusion is mistaken, I would really
> appreciate being corrected ? thank you very much in advance for any
> feedback or different experiences you can share!
>
> Best Regards.
> Jianbin Chen, github-id: funky-eyes
>
> robert engels <robaho at me.com> ? 2026?1?23??? 20:58???
>
>> Exactly, this is your problem. The total number of tasks will all be
>> running at once in the thread per task model.
>>
>> On Jan 23, 2026, at 6:49?AM, Jianbin Chen <jianbin at apache.org> wrote:
>>
>> ?
>> Hi Robert,
>>
>> Thanks you, but I'm a bit confused. In the example above, I only set the
>> core pool size to 200 virtual threads, but for the specific test case we?re
>> talking about, the concurrency isn?t actually being limited by the pool
>> size at all. Since the maximum thread count is Integer.MAX_VALUE and it?s
>> using a SynchronousQueue, tasks are handed off immediately and a new thread
>> gets created to run them right away anyway.
>>
>> Best Regards.
>> Jianbin Chen, github-id: funky-eyes
>>
>> robert engels <robaho at me.com> ? 2026?1?23??? 20:28???
>>
>>> Try using a semaphore to limit the maximum number of tasks in progress
>>> at anyone time - that is what is causing your memory spike. Think of it
>>> this way since VT threads are so cheap to create - you are essentially
>>> creating them all at once - making the working set size equally to the
>>> maximum.  So you have N * WSS, where as in the other you have POOLSIZE *
>>> WSS.
>>>
>>> On Jan 23, 2026, at 4:14?AM, Jianbin Chen <jianbin at apache.org> wrote:
>>>
>>> ?
>>> Hi Alan,
>>>
>>> Thanks for your reply and for mentioning JEP 444.
>>> I?ve gone through the guidance in JEP 444 and have some understanding of
>>> it ? which is exactly why I?m feeling a bit puzzled in practice and would
>>> really like to hear your thoughts.
>>>
>>> Background ? ThreadLocal example (Aerospike)
>>> ```java
>>> private static final ThreadLocal<byte[]> BufferThreadLocal = new
>>> ThreadLocal<byte[]>() {
>>>     @Override
>>>     protected byte[] initialValue() {
>>>         return new byte[DefaultBufferSize];
>>>     }
>>> };
>>> ```
>>> This Aerospike code allocates a default 8KB byte[] whenever a new thread
>>> is created and stores it in a ThreadLocal for per-thread caching.
>>>
>>> My concern
>>> - With a traditional platform-thread pool, those ThreadLocal byte[]
>>> instances are effectively reused because threads are long-lived and pooled.
>>> - If we switch to creating a brand-new virtual thread per task (no
>>> pooling), each virtual thread gets its own fresh ThreadLocal byte[], which
>>> leads to many short-lived 8KB allocations.
>>> - That raises allocation rate and GC pressure (despite collectors like
>>> ZGC), because ThreadLocal caches aren?t reused when threads are ephemeral.
>>>
>>> So my question is: for applications originally designed around
>>> platform-thread pools, wouldn?t partially pooling virtual threads be
>>> beneficial? For example, Tomcat?s default max threads is 200 ? if I keep a
>>> pool of 200 virtual threads, then when load exceeds that core size, a
>>> SynchronousQueue will naturally cause new virtual threads to be created on
>>> demand. This seems to preserve the behavior that ThreadLocal-based
>>> libraries expect, without losing the ability to expand under spikes. Since
>>> virtual threads are very lightweight, pooling a reasonable number (e.g.,
>>> 200) seems to have negligible memory downside while retaining ThreadLocal
>>> cache effectiveness.
>>>
>>> Empirical test I ran
>>> (I ran a microbenchmark comparing an unpooled per-task virtual-thread
>>> executor and a ThreadPoolExecutor that keeps 200 core virtual threads.)
>>>
>>> ```java
>>> public static void main(String[] args) throws InterruptedException {
>>>     Executor executor =
>>> Executors.newThreadPerTaskExecutor(Thread.ofVirtual().name("test-",
>>> 1).factory());
>>>     Executor executor2 = new ThreadPoolExecutor(
>>>         200,
>>>         Integer.MAX_VALUE,
>>>         0L,
>>>         java.util.concurrent.TimeUnit.SECONDS,
>>>         new SynchronousQueue<>(),
>>>         Thread.ofVirtual().name("test-threadpool-", 1).factory()
>>>     );
>>>
>>>     // Warm-up
>>>     for (int i = 0; i < 10100; i++) {
>>>         executor.execute(() -> {
>>>             // simulate I/O wait
>>>             try { Thread.sleep(100); } catch (InterruptedException e) {
>>> throw new RuntimeException(e); }
>>>         });
>>>         executor2.execute(() -> {
>>>             // simulate I/O wait
>>>             try { Thread.sleep(100); } catch (InterruptedException e) {
>>> throw new RuntimeException(e); }
>>>         });
>>>     }
>>>
>>>     // Ensure JIT + warm-up complete
>>>     Thread.sleep(5000);
>>>
>>>     long start = System.currentTimeMillis();
>>>     CountDownLatch countDownLatch = new CountDownLatch(50000);
>>>     for (int i = 0; i < 50000; i++) {
>>>         executor.execute(() -> {
>>>             try { Thread.sleep(100); countDownLatch.countDown(); } catch
>>> (InterruptedException e) { throw new RuntimeException(e); }
>>>         });
>>>     }
>>>     countDownLatch.await();
>>>     System.out.println("thread time: " + (System.currentTimeMillis() -
>>> start) + " ms");
>>>
>>>     start = System.currentTimeMillis();
>>>     CountDownLatch countDownLatch2 = new CountDownLatch(50000);
>>>     for (int i = 0; i < 50000; i++) {
>>>         executor2.execute(() -> {
>>>             try { Thread.sleep(100); countDownLatch2.countDown(); }
>>> catch (InterruptedException e) { throw new RuntimeException(e); }
>>>         });
>>>     }
>>>     countDownLatch.await();
>>>     System.out.println("thread pool time: " +
>>> (System.currentTimeMillis() - start) + " ms");
>>> }
>>> ```
>>>
>>> Result summary
>>> - In my runs, the pooled virtual-thread executor (executor2) performed
>>> better than the unpooled per-task virtual-thread executor.
>>> - Even when I increased load by 10x or 100x, the pooled virtual-thread
>>> executor still showed better performance.
>>> - In realistic workloads, it seems pooling some virtual threads reduces
>>> allocation/GC overhead and improves throughput compared to strictly
>>> unpooled virtual threads.
>>>
>>> Final thought / request for feedback
>>> - From my perspective, for systems originally tuned for platform-thread
>>> pools, partially pooling virtual threads seems to have no obvious downside
>>> and can restore ThreadLocal cache effectiveness used by many third-party
>>> libraries.
>>> - If I?ve misunderstood JEP 444 recommendations, virtual-thread
>>> semantics, or ThreadLocal behavior, please point out what I?m missing. I?d
>>> appreciate your guidance.
>>>
>>> Best Regards.
>>> Jianbin Chen, github-id: funky-eyes
>>>
>>> Alan Bateman <alan.bateman at oracle.com> ? 2026?1?23??? 17:27???
>>>
>>>> On 23/01/2026 07:30, Jianbin Chen wrote:
>>>> > :
>>>> >
>>>> > So my question is:
>>>> >
>>>> > **In scenarios where third-party libraries heavily rely on
>>>> ThreadLocal
>>>> > for caching / buffering (and we cannot change those libraries to use
>>>> > object pools instead), is explicitly pooling virtual threads (using a
>>>> > ThreadPoolExecutor with virtual thread factory) considered a
>>>> > recommended / acceptable workaround?**
>>>> >
>>>> > Or are there better / more idiomatic ways to handle this kind of
>>>> > compatibility issue with legacy ThreadLocal-based libraries when
>>>> > migrating to virtual threads?
>>>> >
>>>> > I have already opened a related discussion in the Dubbo project
>>>> (since
>>>> > Dubbo is one of the libraries affected in our stack):
>>>> >
>>>> > https://github.com/apache/dubbo/issues/16042
>>>> >
>>>> > Would love to hear your thoughts ? especially from people who have
>>>> > experience running large-scale virtual-thread-based services with
>>>> > mixed third-party dependencies.
>>>> >
>>>>
>>>> The guidelines that we put in JEP 444 [1] is to not pool virtual
>>>> threads
>>>> and to avoid caching costing resources in thread locals. Virtual
>>>> threads
>>>> support thread locals of course but that is not useful when some
>>>> library
>>>> is looking to share a costly resource between tasks that run on the
>>>> same
>>>> thread in a thread pool.
>>>>
>>>> I don't know anything about Aerospike but working with the maintainers
>>>> of that library to re-work its buffer management seems like the right
>>>> course of action here. Your mail says "byte buffers". If this is
>>>> ByteBuffer it might be that they are caching direct buffers as they are
>>>> expensive to create (and managed by the GC). Maybe they could look at
>>>> using MemorySegment (it's easy to get a ByteBuffer view of a memory
>>>> segment) and allocate from an arena that better matches the lifecycle.
>>>>
>>>> Hopefully others will share their experiences with migration as it is
>>>> indeed challenging to migrate code developed for thread pools to work
>>>> efficiently on virtual threads where there is 1-1 relationship between
>>>> the task to execute and the thread.
>>>>
>>>> -Alan
>>>>
>>>> [1] https://openjdk.org/jeps/444#Thread-local-variables
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260123/13f400e7/attachment-0001.htm>

From rengels at ix.netcom.com  Fri Jan 23 14:19:49 2026
From: rengels at ix.netcom.com (Robert Engels)
Date: Fri, 23 Jan 2026 08:19:49 -0600
Subject: Performance Issues with Virtual Threads + ThreadLocal Caching in
 Third-Party Libraries (JDK 25)
In-Reply-To: <CAAMX02o7ugTq-EuZO-dp_vhc0kHz2fp1q5RVNn7_N7JX7RvDYQ@mail.gmail.com>
References: <CAAMX02o7ugTq-EuZO-dp_vhc0kHz2fp1q5RVNn7_N7JX7RvDYQ@mail.gmail.com>
Message-ID: <40EFCACE-5F3F-4AF6-B8CA-9F8EEAFCD1FD@ix.netcom.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260123/53f551f6/attachment.htm>

From petereastham at gmail.com  Fri Jan 23 14:33:04 2026
From: petereastham at gmail.com (Peter Eastham)
Date: Fri, 23 Jan 2026 07:33:04 -0700
Subject: Performance Issues with Virtual Threads + ThreadLocal Caching in
 Third-Party Libraries (JDK 25)
In-Reply-To: <CAAMX02o7ugTq-EuZO-dp_vhc0kHz2fp1q5RVNn7_N7JX7RvDYQ@mail.gmail.com>
References: <CAAMX02rQ6tADgAQnyf5A6mtdMw8R0BkD-yJcSynO-rb10C6LwA@mail.gmail.com>
 <EB4BBE87-1FB6-4880-AF76-6BEB182E141E@ix.netcom.com>
 <CAAMX02o7ugTq-EuZO-dp_vhc0kHz2fp1q5RVNn7_N7JX7RvDYQ@mail.gmail.com>
Message-ID: <CAN+txM_jU0N+=XQ5KOSFAZSeWKsaSHczH07R=Nnc6Gk7XTPqWA@mail.gmail.com>

Hey Jianbin,

A java library should leverage the expected defaults for executors. This
would be a traditional threadpool for platform threads, or virtual thread
per task. This follows the principle of least surprise for the library
consumers.
Performance Conscious libraries should allow for the Executor to be
provided by the calling code. One example of that approach is the
CompletableFuture API. However some sort of Configuration Object with an
executor as a field is another approach.

If you locally optimize your library like this, that'll make it harder for
your library consumer to holistically optimize their code.

Does that make sense?
-Peter

On Fri, Jan 23, 2026 at 7:10?AM Jianbin Chen <jianbin at apache.org> wrote:

> I'm sorry, Robert?perhaps I didn't explain my example clearly enough.
> Here's the code in question:
>
> ```java
> Executor executor2 = new ThreadPoolExecutor(
>     200,
>     Integer.MAX_VALUE,
>     0L,
>     java.util.concurrent.TimeUnit.SECONDS,
>     new SynchronousQueue<>(),
>     Thread.ofVirtual().name("test-threadpool-", 1).factory()
> );
> ```
>
> In this example, the pooled virtual threads don't implement any
> backpressure mechanism; they simply maintain a core pool of 200 virtual
> threads. Given that the queue is a `SynchronousQueue` and the maximum pool
> size is set to `Integer.MAX_VALUE`, once the concurrent tasks exceed 200,
> its behavior becomes identical to that of non-pooled virtual threads.
>
> From my perspective, this example demonstrates that the benefits of
> pooling virtual threads outweigh those of creating a new virtual thread for
> every single task. In IO-bound scenarios, the virtual threads are directly
> reused rather than being recreated each time, and the memory footprint of
> virtual threads is far smaller than that of platform threads (which are
> controlled by the `-Xss` flag). Additionally, with pooled virtual threads,
> the 8KB `byte[]` cache I mentioned earlier (stored in `ThreadLocal`) can
> also be reused, which further reduces overall memory usage?wouldn't you
> agree?
>
> Best Regards.
> Jianbin Chen, github-id: funky-eyes
>
> Robert Engels <rengels at ix.netcom.com> ? 2026?1?23??? 21:52???
>
>> Because VT are so efficient to create, without any back pressure they
>> will all be created and running at essentially the same time (dramatically
>> raising the amount of memory in use) - versus with a pool of size N you
>> will have at most N running at once. In a REAL WORLD application there are
>> often external limiters (like number of tcp connections) that provide a
>> limit.
>>
>> If your tasks are purely cpu bound you should probably be using a capped
>> thread pool of platform threads as it makes no sense to have more threads
>> than available cores.
>>
>>
>>
>> On Jan 23, 2026, at 7:42?AM, Jianbin Chen <jianbin at apache.org> wrote:
>>
>> ?
>> The question is why I need to use a semaphore to control the number of
>> concurrently running tasks. In my particular example, the goal is simply to
>> keep the concurrency level the same across different thread pool
>> implementations so I can fairly compare which one completes all the tasks
>> faster. This isn't solely about memory consumption?purely from a
>> **performance** perspective (e.g., total throughput or wall-clock time to
>> finish the workload), the same number of concurrent tasks completes
>> noticeably faster when using pooled virtual threads.
>>
>> My email probably didn't explain this clearly enough. In reality, I have
>> two main questions:
>>
>> 1. When a third-party library uses `ThreadLocal` as a cache/pool (e.g.,
>> to hold expensive reusable objects like connections, formatters, or
>> parsers), is switching to a **pooled virtual thread executor** the only
>> viable solution?assuming we cannot modify the third-party library code?
>>
>> 2. When running the exact same number of concurrent tasks, pooled virtual
>> threads deliver better performance.
>>
>> Both questions point toward the same conclusion: for an application
>> originally built around a traditional platform thread pool, after upgrading
>> to JDK 21/25, moving to a **pooled virtual threads** approach is generally
>> superior to simply using non-pooled (unbounded) virtual threads.
>>
>> If any part of this reasoning or conclusion is mistaken, I would really
>> appreciate being corrected ? thank you very much in advance for any
>> feedback or different experiences you can share!
>>
>> Best Regards.
>> Jianbin Chen, github-id: funky-eyes
>>
>> robert engels <robaho at me.com> ? 2026?1?23??? 20:58???
>>
>>> Exactly, this is your problem. The total number of tasks will all be
>>> running at once in the thread per task model.
>>>
>>> On Jan 23, 2026, at 6:49?AM, Jianbin Chen <jianbin at apache.org> wrote:
>>>
>>> ?
>>> Hi Robert,
>>>
>>> Thanks you, but I'm a bit confused. In the example above, I only set the
>>> core pool size to 200 virtual threads, but for the specific test case we?re
>>> talking about, the concurrency isn?t actually being limited by the pool
>>> size at all. Since the maximum thread count is Integer.MAX_VALUE and it?s
>>> using a SynchronousQueue, tasks are handed off immediately and a new thread
>>> gets created to run them right away anyway.
>>>
>>> Best Regards.
>>> Jianbin Chen, github-id: funky-eyes
>>>
>>> robert engels <robaho at me.com> ? 2026?1?23??? 20:28???
>>>
>>>> Try using a semaphore to limit the maximum number of tasks in progress
>>>> at anyone time - that is what is causing your memory spike. Think of it
>>>> this way since VT threads are so cheap to create - you are essentially
>>>> creating them all at once - making the working set size equally to the
>>>> maximum.  So you have N * WSS, where as in the other you have POOLSIZE *
>>>> WSS.
>>>>
>>>> On Jan 23, 2026, at 4:14?AM, Jianbin Chen <jianbin at apache.org> wrote:
>>>>
>>>> ?
>>>> Hi Alan,
>>>>
>>>> Thanks for your reply and for mentioning JEP 444.
>>>> I?ve gone through the guidance in JEP 444 and have some understanding
>>>> of it ? which is exactly why I?m feeling a bit puzzled in practice and
>>>> would really like to hear your thoughts.
>>>>
>>>> Background ? ThreadLocal example (Aerospike)
>>>> ```java
>>>> private static final ThreadLocal<byte[]> BufferThreadLocal = new
>>>> ThreadLocal<byte[]>() {
>>>>     @Override
>>>>     protected byte[] initialValue() {
>>>>         return new byte[DefaultBufferSize];
>>>>     }
>>>> };
>>>> ```
>>>> This Aerospike code allocates a default 8KB byte[] whenever a new
>>>> thread is created and stores it in a ThreadLocal for per-thread caching.
>>>>
>>>> My concern
>>>> - With a traditional platform-thread pool, those ThreadLocal byte[]
>>>> instances are effectively reused because threads are long-lived and pooled.
>>>> - If we switch to creating a brand-new virtual thread per task (no
>>>> pooling), each virtual thread gets its own fresh ThreadLocal byte[], which
>>>> leads to many short-lived 8KB allocations.
>>>> - That raises allocation rate and GC pressure (despite collectors like
>>>> ZGC), because ThreadLocal caches aren?t reused when threads are ephemeral.
>>>>
>>>> So my question is: for applications originally designed around
>>>> platform-thread pools, wouldn?t partially pooling virtual threads be
>>>> beneficial? For example, Tomcat?s default max threads is 200 ? if I keep a
>>>> pool of 200 virtual threads, then when load exceeds that core size, a
>>>> SynchronousQueue will naturally cause new virtual threads to be created on
>>>> demand. This seems to preserve the behavior that ThreadLocal-based
>>>> libraries expect, without losing the ability to expand under spikes. Since
>>>> virtual threads are very lightweight, pooling a reasonable number (e.g.,
>>>> 200) seems to have negligible memory downside while retaining ThreadLocal
>>>> cache effectiveness.
>>>>
>>>> Empirical test I ran
>>>> (I ran a microbenchmark comparing an unpooled per-task virtual-thread
>>>> executor and a ThreadPoolExecutor that keeps 200 core virtual threads.)
>>>>
>>>> ```java
>>>> public static void main(String[] args) throws InterruptedException {
>>>>     Executor executor =
>>>> Executors.newThreadPerTaskExecutor(Thread.ofVirtual().name("test-",
>>>> 1).factory());
>>>>     Executor executor2 = new ThreadPoolExecutor(
>>>>         200,
>>>>         Integer.MAX_VALUE,
>>>>         0L,
>>>>         java.util.concurrent.TimeUnit.SECONDS,
>>>>         new SynchronousQueue<>(),
>>>>         Thread.ofVirtual().name("test-threadpool-", 1).factory()
>>>>     );
>>>>
>>>>     // Warm-up
>>>>     for (int i = 0; i < 10100; i++) {
>>>>         executor.execute(() -> {
>>>>             // simulate I/O wait
>>>>             try { Thread.sleep(100); } catch (InterruptedException e) {
>>>> throw new RuntimeException(e); }
>>>>         });
>>>>         executor2.execute(() -> {
>>>>             // simulate I/O wait
>>>>             try { Thread.sleep(100); } catch (InterruptedException e) {
>>>> throw new RuntimeException(e); }
>>>>         });
>>>>     }
>>>>
>>>>     // Ensure JIT + warm-up complete
>>>>     Thread.sleep(5000);
>>>>
>>>>     long start = System.currentTimeMillis();
>>>>     CountDownLatch countDownLatch = new CountDownLatch(50000);
>>>>     for (int i = 0; i < 50000; i++) {
>>>>         executor.execute(() -> {
>>>>             try { Thread.sleep(100); countDownLatch.countDown(); }
>>>> catch (InterruptedException e) { throw new RuntimeException(e); }
>>>>         });
>>>>     }
>>>>     countDownLatch.await();
>>>>     System.out.println("thread time: " + (System.currentTimeMillis() -
>>>> start) + " ms");
>>>>
>>>>     start = System.currentTimeMillis();
>>>>     CountDownLatch countDownLatch2 = new CountDownLatch(50000);
>>>>     for (int i = 0; i < 50000; i++) {
>>>>         executor2.execute(() -> {
>>>>             try { Thread.sleep(100); countDownLatch2.countDown(); }
>>>> catch (InterruptedException e) { throw new RuntimeException(e); }
>>>>         });
>>>>     }
>>>>     countDownLatch.await();
>>>>     System.out.println("thread pool time: " +
>>>> (System.currentTimeMillis() - start) + " ms");
>>>> }
>>>> ```
>>>>
>>>> Result summary
>>>> - In my runs, the pooled virtual-thread executor (executor2) performed
>>>> better than the unpooled per-task virtual-thread executor.
>>>> - Even when I increased load by 10x or 100x, the pooled virtual-thread
>>>> executor still showed better performance.
>>>> - In realistic workloads, it seems pooling some virtual threads reduces
>>>> allocation/GC overhead and improves throughput compared to strictly
>>>> unpooled virtual threads.
>>>>
>>>> Final thought / request for feedback
>>>> - From my perspective, for systems originally tuned for platform-thread
>>>> pools, partially pooling virtual threads seems to have no obvious downside
>>>> and can restore ThreadLocal cache effectiveness used by many third-party
>>>> libraries.
>>>> - If I?ve misunderstood JEP 444 recommendations, virtual-thread
>>>> semantics, or ThreadLocal behavior, please point out what I?m missing. I?d
>>>> appreciate your guidance.
>>>>
>>>> Best Regards.
>>>> Jianbin Chen, github-id: funky-eyes
>>>>
>>>> Alan Bateman <alan.bateman at oracle.com> ? 2026?1?23??? 17:27???
>>>>
>>>>> On 23/01/2026 07:30, Jianbin Chen wrote:
>>>>> > :
>>>>> >
>>>>> > So my question is:
>>>>> >
>>>>> > **In scenarios where third-party libraries heavily rely on
>>>>> ThreadLocal
>>>>> > for caching / buffering (and we cannot change those libraries to use
>>>>> > object pools instead), is explicitly pooling virtual threads (using
>>>>> a
>>>>> > ThreadPoolExecutor with virtual thread factory) considered a
>>>>> > recommended / acceptable workaround?**
>>>>> >
>>>>> > Or are there better / more idiomatic ways to handle this kind of
>>>>> > compatibility issue with legacy ThreadLocal-based libraries when
>>>>> > migrating to virtual threads?
>>>>> >
>>>>> > I have already opened a related discussion in the Dubbo project
>>>>> (since
>>>>> > Dubbo is one of the libraries affected in our stack):
>>>>> >
>>>>> > https://github.com/apache/dubbo/issues/16042
>>>>> >
>>>>> > Would love to hear your thoughts ? especially from people who have
>>>>> > experience running large-scale virtual-thread-based services with
>>>>> > mixed third-party dependencies.
>>>>> >
>>>>>
>>>>> The guidelines that we put in JEP 444 [1] is to not pool virtual
>>>>> threads
>>>>> and to avoid caching costing resources in thread locals. Virtual
>>>>> threads
>>>>> support thread locals of course but that is not useful when some
>>>>> library
>>>>> is looking to share a costly resource between tasks that run on the
>>>>> same
>>>>> thread in a thread pool.
>>>>>
>>>>> I don't know anything about Aerospike but working with the maintainers
>>>>> of that library to re-work its buffer management seems like the right
>>>>> course of action here. Your mail says "byte buffers". If this is
>>>>> ByteBuffer it might be that they are caching direct buffers as they
>>>>> are
>>>>> expensive to create (and managed by the GC). Maybe they could look at
>>>>> using MemorySegment (it's easy to get a ByteBuffer view of a memory
>>>>> segment) and allocate from an arena that better matches the lifecycle.
>>>>>
>>>>> Hopefully others will share their experiences with migration as it is
>>>>> indeed challenging to migrate code developed for thread pools to work
>>>>> efficiently on virtual threads where there is 1-1 relationship between
>>>>> the task to execute and the thread.
>>>>>
>>>>> -Alan
>>>>>
>>>>> [1] https://openjdk.org/jeps/444#Thread-local-variables
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260123/2eddc0f3/attachment-0001.htm>

From jianbin at apache.org  Fri Jan 23 14:51:58 2026
From: jianbin at apache.org (Jianbin Chen)
Date: Fri, 23 Jan 2026 22:51:58 +0800
Subject: Performance Issues with Virtual Threads + ThreadLocal Caching in
 Third-Party Libraries (JDK 25)
In-Reply-To: <40EFCACE-5F3F-4AF6-B8CA-9F8EEAFCD1FD@ix.netcom.com>
References: <CAAMX02o7ugTq-EuZO-dp_vhc0kHz2fp1q5RVNn7_N7JX7RvDYQ@mail.gmail.com>
 <40EFCACE-5F3F-4AF6-B8CA-9F8EEAFCD1FD@ix.netcom.com>
Message-ID: <CAAMX02oGPtkTfr02Lmd8RtXsupP92zAEm8E3VwMqjKqosZooqA@mail.gmail.com>

I'm sorry ? I forgot to mention the machine I used for the load test. My
server is 2 cores and 4 GB RAM, and the JVM heap was set to 2880m. Under my
test load (about 20,000 QPS), with non?pooled virtual threads you generate
at least 20,000 ? 8 KB = ~156 MB of byte[] allocations per second just from
that 8 KB buffer; that doesn't include other object allocations. With a
2880 MB heap this allocation rate already forces very frequent GC, and
frequent GC raises CPU usage, which in turn significantly increases average
response time and p99 / p999 latency.

Pooling is usually introduced to solve performance issues ? object pools
and connection pools exist to quickly reuse cached resources and improve
performance. So pooling virtual threads also yields obvious benefits,
especially for memory?constrained, I/O?bound applications (gateways,
proxies, etc.) that are sensitive to latency.

Best Regards.
Jianbin Chen, github-id: funky-eyes

Robert Engels <rengels at ix.netcom.com> ? 2026?1?23??? 22:20???

> I understand. I was trying explain how you can not use thread locals and
> maintain the performance. It?s unlikely allocating a 8k buffer is a
> performance bottleneck in a real program if the task is not cpu bound
> (depending on the granularity you make your tasks) - but 2M tasks running
> simultaneously would require 16gb of memory not including the stack.
>
> You cannot simply use the thread per task model without an understanding
> of the cpu, IO, and memory footprints of your tasks and then configure
> appropriately.
>
> On Jan 23, 2026, at 8:10?AM, Jianbin Chen <jianbin at apache.org> wrote:
>
> ?
> I'm sorry, Robert?perhaps I didn't explain my example clearly enough.
> Here's the code in question:
>
> ```java
> Executor executor2 = new ThreadPoolExecutor(
>     200,
>     Integer.MAX_VALUE,
>     0L,
>     java.util.concurrent.TimeUnit.SECONDS,
>     new SynchronousQueue<>(),
>     Thread.ofVirtual().name("test-threadpool-", 1).factory()
> );
> ```
>
> In this example, the pooled virtual threads don't implement any
> backpressure mechanism; they simply maintain a core pool of 200 virtual
> threads. Given that the queue is a `SynchronousQueue` and the maximum pool
> size is set to `Integer.MAX_VALUE`, once the concurrent tasks exceed 200,
> its behavior becomes identical to that of non-pooled virtual threads.
>
> From my perspective, this example demonstrates that the benefits of
> pooling virtual threads outweigh those of creating a new virtual thread for
> every single task. In IO-bound scenarios, the virtual threads are directly
> reused rather than being recreated each time, and the memory footprint of
> virtual threads is far smaller than that of platform threads (which are
> controlled by the `-Xss` flag). Additionally, with pooled virtual threads,
> the 8KB `byte[]` cache I mentioned earlier (stored in `ThreadLocal`) can
> also be reused, which further reduces overall memory usage?wouldn't you
> agree?
>
> Best Regards.
> Jianbin Chen, github-id: funky-eyes
>
> Robert Engels <rengels at ix.netcom.com> ? 2026?1?23??? 21:52???
>
>> Because VT are so efficient to create, without any back pressure they
>> will all be created and running at essentially the same time (dramatically
>> raising the amount of memory in use) - versus with a pool of size N you
>> will have at most N running at once. In a REAL WORLD application there are
>> often external limiters (like number of tcp connections) that provide a
>> limit.
>>
>> If your tasks are purely cpu bound you should probably be using a capped
>> thread pool of platform threads as it makes no sense to have more threads
>> than available cores.
>>
>>
>>
>> On Jan 23, 2026, at 7:42?AM, Jianbin Chen <jianbin at apache.org> wrote:
>>
>> ?
>> The question is why I need to use a semaphore to control the number of
>> concurrently running tasks. In my particular example, the goal is simply to
>> keep the concurrency level the same across different thread pool
>> implementations so I can fairly compare which one completes all the tasks
>> faster. This isn't solely about memory consumption?purely from a
>> **performance** perspective (e.g., total throughput or wall-clock time to
>> finish the workload), the same number of concurrent tasks completes
>> noticeably faster when using pooled virtual threads.
>>
>> My email probably didn't explain this clearly enough. In reality, I have
>> two main questions:
>>
>> 1. When a third-party library uses `ThreadLocal` as a cache/pool (e.g.,
>> to hold expensive reusable objects like connections, formatters, or
>> parsers), is switching to a **pooled virtual thread executor** the only
>> viable solution?assuming we cannot modify the third-party library code?
>>
>> 2. When running the exact same number of concurrent tasks, pooled virtual
>> threads deliver better performance.
>>
>> Both questions point toward the same conclusion: for an application
>> originally built around a traditional platform thread pool, after upgrading
>> to JDK 21/25, moving to a **pooled virtual threads** approach is generally
>> superior to simply using non-pooled (unbounded) virtual threads.
>>
>> If any part of this reasoning or conclusion is mistaken, I would really
>> appreciate being corrected ? thank you very much in advance for any
>> feedback or different experiences you can share!
>>
>> Best Regards.
>> Jianbin Chen, github-id: funky-eyes
>>
>> robert engels <robaho at me.com> ? 2026?1?23??? 20:58???
>>
>>> Exactly, this is your problem. The total number of tasks will all be
>>> running at once in the thread per task model.
>>>
>>> On Jan 23, 2026, at 6:49?AM, Jianbin Chen <jianbin at apache.org> wrote:
>>>
>>> ?
>>> Hi Robert,
>>>
>>> Thanks you, but I'm a bit confused. In the example above, I only set the
>>> core pool size to 200 virtual threads, but for the specific test case we?re
>>> talking about, the concurrency isn?t actually being limited by the pool
>>> size at all. Since the maximum thread count is Integer.MAX_VALUE and it?s
>>> using a SynchronousQueue, tasks are handed off immediately and a new thread
>>> gets created to run them right away anyway.
>>>
>>> Best Regards.
>>> Jianbin Chen, github-id: funky-eyes
>>>
>>> robert engels <robaho at me.com> ? 2026?1?23??? 20:28???
>>>
>>>> Try using a semaphore to limit the maximum number of tasks in progress
>>>> at anyone time - that is what is causing your memory spike. Think of it
>>>> this way since VT threads are so cheap to create - you are essentially
>>>> creating them all at once - making the working set size equally to the
>>>> maximum.  So you have N * WSS, where as in the other you have POOLSIZE *
>>>> WSS.
>>>>
>>>> On Jan 23, 2026, at 4:14?AM, Jianbin Chen <jianbin at apache.org> wrote:
>>>>
>>>> ?
>>>> Hi Alan,
>>>>
>>>> Thanks for your reply and for mentioning JEP 444.
>>>> I?ve gone through the guidance in JEP 444 and have some understanding
>>>> of it ? which is exactly why I?m feeling a bit puzzled in practice and
>>>> would really like to hear your thoughts.
>>>>
>>>> Background ? ThreadLocal example (Aerospike)
>>>> ```java
>>>> private static final ThreadLocal<byte[]> BufferThreadLocal = new
>>>> ThreadLocal<byte[]>() {
>>>>     @Override
>>>>     protected byte[] initialValue() {
>>>>         return new byte[DefaultBufferSize];
>>>>     }
>>>> };
>>>> ```
>>>> This Aerospike code allocates a default 8KB byte[] whenever a new
>>>> thread is created and stores it in a ThreadLocal for per-thread caching.
>>>>
>>>> My concern
>>>> - With a traditional platform-thread pool, those ThreadLocal byte[]
>>>> instances are effectively reused because threads are long-lived and pooled.
>>>> - If we switch to creating a brand-new virtual thread per task (no
>>>> pooling), each virtual thread gets its own fresh ThreadLocal byte[], which
>>>> leads to many short-lived 8KB allocations.
>>>> - That raises allocation rate and GC pressure (despite collectors like
>>>> ZGC), because ThreadLocal caches aren?t reused when threads are ephemeral.
>>>>
>>>> So my question is: for applications originally designed around
>>>> platform-thread pools, wouldn?t partially pooling virtual threads be
>>>> beneficial? For example, Tomcat?s default max threads is 200 ? if I keep a
>>>> pool of 200 virtual threads, then when load exceeds that core size, a
>>>> SynchronousQueue will naturally cause new virtual threads to be created on
>>>> demand. This seems to preserve the behavior that ThreadLocal-based
>>>> libraries expect, without losing the ability to expand under spikes. Since
>>>> virtual threads are very lightweight, pooling a reasonable number (e.g.,
>>>> 200) seems to have negligible memory downside while retaining ThreadLocal
>>>> cache effectiveness.
>>>>
>>>> Empirical test I ran
>>>> (I ran a microbenchmark comparing an unpooled per-task virtual-thread
>>>> executor and a ThreadPoolExecutor that keeps 200 core virtual threads.)
>>>>
>>>> ```java
>>>> public static void main(String[] args) throws InterruptedException {
>>>>     Executor executor =
>>>> Executors.newThreadPerTaskExecutor(Thread.ofVirtual().name("test-",
>>>> 1).factory());
>>>>     Executor executor2 = new ThreadPoolExecutor(
>>>>         200,
>>>>         Integer.MAX_VALUE,
>>>>         0L,
>>>>         java.util.concurrent.TimeUnit.SECONDS,
>>>>         new SynchronousQueue<>(),
>>>>         Thread.ofVirtual().name("test-threadpool-", 1).factory()
>>>>     );
>>>>
>>>>     // Warm-up
>>>>     for (int i = 0; i < 10100; i++) {
>>>>         executor.execute(() -> {
>>>>             // simulate I/O wait
>>>>             try { Thread.sleep(100); } catch (InterruptedException e) {
>>>> throw new RuntimeException(e); }
>>>>         });
>>>>         executor2.execute(() -> {
>>>>             // simulate I/O wait
>>>>             try { Thread.sleep(100); } catch (InterruptedException e) {
>>>> throw new RuntimeException(e); }
>>>>         });
>>>>     }
>>>>
>>>>     // Ensure JIT + warm-up complete
>>>>     Thread.sleep(5000);
>>>>
>>>>     long start = System.currentTimeMillis();
>>>>     CountDownLatch countDownLatch = new CountDownLatch(50000);
>>>>     for (int i = 0; i < 50000; i++) {
>>>>         executor.execute(() -> {
>>>>             try { Thread.sleep(100); countDownLatch.countDown(); }
>>>> catch (InterruptedException e) { throw new RuntimeException(e); }
>>>>         });
>>>>     }
>>>>     countDownLatch.await();
>>>>     System.out.println("thread time: " + (System.currentTimeMillis() -
>>>> start) + " ms");
>>>>
>>>>     start = System.currentTimeMillis();
>>>>     CountDownLatch countDownLatch2 = new CountDownLatch(50000);
>>>>     for (int i = 0; i < 50000; i++) {
>>>>         executor2.execute(() -> {
>>>>             try { Thread.sleep(100); countDownLatch2.countDown(); }
>>>> catch (InterruptedException e) { throw new RuntimeException(e); }
>>>>         });
>>>>     }
>>>>     countDownLatch.await();
>>>>     System.out.println("thread pool time: " +
>>>> (System.currentTimeMillis() - start) + " ms");
>>>> }
>>>> ```
>>>>
>>>> Result summary
>>>> - In my runs, the pooled virtual-thread executor (executor2) performed
>>>> better than the unpooled per-task virtual-thread executor.
>>>> - Even when I increased load by 10x or 100x, the pooled virtual-thread
>>>> executor still showed better performance.
>>>> - In realistic workloads, it seems pooling some virtual threads reduces
>>>> allocation/GC overhead and improves throughput compared to strictly
>>>> unpooled virtual threads.
>>>>
>>>> Final thought / request for feedback
>>>> - From my perspective, for systems originally tuned for platform-thread
>>>> pools, partially pooling virtual threads seems to have no obvious downside
>>>> and can restore ThreadLocal cache effectiveness used by many third-party
>>>> libraries.
>>>> - If I?ve misunderstood JEP 444 recommendations, virtual-thread
>>>> semantics, or ThreadLocal behavior, please point out what I?m missing. I?d
>>>> appreciate your guidance.
>>>>
>>>> Best Regards.
>>>> Jianbin Chen, github-id: funky-eyes
>>>>
>>>> Alan Bateman <alan.bateman at oracle.com> ? 2026?1?23??? 17:27???
>>>>
>>>>> On 23/01/2026 07:30, Jianbin Chen wrote:
>>>>> > :
>>>>> >
>>>>> > So my question is:
>>>>> >
>>>>> > **In scenarios where third-party libraries heavily rely on
>>>>> ThreadLocal
>>>>> > for caching / buffering (and we cannot change those libraries to use
>>>>> > object pools instead), is explicitly pooling virtual threads (using
>>>>> a
>>>>> > ThreadPoolExecutor with virtual thread factory) considered a
>>>>> > recommended / acceptable workaround?**
>>>>> >
>>>>> > Or are there better / more idiomatic ways to handle this kind of
>>>>> > compatibility issue with legacy ThreadLocal-based libraries when
>>>>> > migrating to virtual threads?
>>>>> >
>>>>> > I have already opened a related discussion in the Dubbo project
>>>>> (since
>>>>> > Dubbo is one of the libraries affected in our stack):
>>>>> >
>>>>> > https://github.com/apache/dubbo/issues/16042
>>>>> >
>>>>> > Would love to hear your thoughts ? especially from people who have
>>>>> > experience running large-scale virtual-thread-based services with
>>>>> > mixed third-party dependencies.
>>>>> >
>>>>>
>>>>> The guidelines that we put in JEP 444 [1] is to not pool virtual
>>>>> threads
>>>>> and to avoid caching costing resources in thread locals. Virtual
>>>>> threads
>>>>> support thread locals of course but that is not useful when some
>>>>> library
>>>>> is looking to share a costly resource between tasks that run on the
>>>>> same
>>>>> thread in a thread pool.
>>>>>
>>>>> I don't know anything about Aerospike but working with the maintainers
>>>>> of that library to re-work its buffer management seems like the right
>>>>> course of action here. Your mail says "byte buffers". If this is
>>>>> ByteBuffer it might be that they are caching direct buffers as they
>>>>> are
>>>>> expensive to create (and managed by the GC). Maybe they could look at
>>>>> using MemorySegment (it's easy to get a ByteBuffer view of a memory
>>>>> segment) and allocate from an arena that better matches the lifecycle.
>>>>>
>>>>> Hopefully others will share their experiences with migration as it is
>>>>> indeed challenging to migrate code developed for thread pools to work
>>>>> efficiently on virtual threads where there is 1-1 relationship between
>>>>> the task to execute and the thread.
>>>>>
>>>>> -Alan
>>>>>
>>>>> [1] https://openjdk.org/jeps/444#Thread-local-variables
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260123/309c5308/attachment-0001.htm>

From nigro.fra at gmail.com  Fri Jan 23 15:11:57 2026
From: nigro.fra at gmail.com (Francesco Nigro)
Date: Fri, 23 Jan 2026 16:11:57 +0100
Subject: Performance Issues with Virtual Threads + ThreadLocal Caching in
 Third-Party Libraries (JDK 25)
In-Reply-To: <CAAMX02oGPtkTfr02Lmd8RtXsupP92zAEm8E3VwMqjKqosZooqA@mail.gmail.com>
References: <CAAMX02o7ugTq-EuZO-dp_vhc0kHz2fp1q5RVNn7_N7JX7RvDYQ@mail.gmail.com>
 <40EFCACE-5F3F-4AF6-B8CA-9F8EEAFCD1FD@ix.netcom.com>
 <CAAMX02oGPtkTfr02Lmd8RtXsupP92zAEm8E3VwMqjKqosZooqA@mail.gmail.com>
Message-ID: <CAKxGtTXdvHqOVhV3PHtz5+ZiaRB8dFD2YtGQO0uH1W36gyMwOg@mail.gmail.com>

In the original code snippet I see named (with a counter) VThreads, so, be
aware of https://bugs.openjdk.org/browse/JDK-8372410

Il giorno ven 23 gen 2026 alle ore 15:52 Jianbin Chen <jianbin at apache.org>
ha scritto:

> I'm sorry ? I forgot to mention the machine I used for the load test. My
> server is 2 cores and 4 GB RAM, and the JVM heap was set to 2880m. Under my
> test load (about 20,000 QPS), with non?pooled virtual threads you generate
> at least 20,000 ? 8 KB = ~156 MB of byte[] allocations per second just from
> that 8 KB buffer; that doesn't include other object allocations. With a
> 2880 MB heap this allocation rate already forces very frequent GC, and
> frequent GC raises CPU usage, which in turn significantly increases average
> response time and p99 / p999 latency.
>
> Pooling is usually introduced to solve performance issues ? object pools
> and connection pools exist to quickly reuse cached resources and improve
> performance. So pooling virtual threads also yields obvious benefits,
> especially for memory?constrained, I/O?bound applications (gateways,
> proxies, etc.) that are sensitive to latency.
>
> Best Regards.
> Jianbin Chen, github-id: funky-eyes
>
> Robert Engels <rengels at ix.netcom.com> ? 2026?1?23??? 22:20???
>
>> I understand. I was trying explain how you can not use thread locals and
>> maintain the performance. It?s unlikely allocating a 8k buffer is a
>> performance bottleneck in a real program if the task is not cpu bound
>> (depending on the granularity you make your tasks) - but 2M tasks running
>> simultaneously would require 16gb of memory not including the stack.
>>
>> You cannot simply use the thread per task model without an understanding
>> of the cpu, IO, and memory footprints of your tasks and then configure
>> appropriately.
>>
>> On Jan 23, 2026, at 8:10?AM, Jianbin Chen <jianbin at apache.org> wrote:
>>
>> ?
>> I'm sorry, Robert?perhaps I didn't explain my example clearly enough.
>> Here's the code in question:
>>
>> ```java
>> Executor executor2 = new ThreadPoolExecutor(
>>     200,
>>     Integer.MAX_VALUE,
>>     0L,
>>     java.util.concurrent.TimeUnit.SECONDS,
>>     new SynchronousQueue<>(),
>>     Thread.ofVirtual().name("test-threadpool-", 1).factory()
>> );
>> ```
>>
>> In this example, the pooled virtual threads don't implement any
>> backpressure mechanism; they simply maintain a core pool of 200 virtual
>> threads. Given that the queue is a `SynchronousQueue` and the maximum pool
>> size is set to `Integer.MAX_VALUE`, once the concurrent tasks exceed 200,
>> its behavior becomes identical to that of non-pooled virtual threads.
>>
>> From my perspective, this example demonstrates that the benefits of
>> pooling virtual threads outweigh those of creating a new virtual thread for
>> every single task. In IO-bound scenarios, the virtual threads are directly
>> reused rather than being recreated each time, and the memory footprint of
>> virtual threads is far smaller than that of platform threads (which are
>> controlled by the `-Xss` flag). Additionally, with pooled virtual threads,
>> the 8KB `byte[]` cache I mentioned earlier (stored in `ThreadLocal`) can
>> also be reused, which further reduces overall memory usage?wouldn't you
>> agree?
>>
>> Best Regards.
>> Jianbin Chen, github-id: funky-eyes
>>
>> Robert Engels <rengels at ix.netcom.com> ? 2026?1?23??? 21:52???
>>
>>> Because VT are so efficient to create, without any back pressure they
>>> will all be created and running at essentially the same time (dramatically
>>> raising the amount of memory in use) - versus with a pool of size N you
>>> will have at most N running at once. In a REAL WORLD application there are
>>> often external limiters (like number of tcp connections) that provide a
>>> limit.
>>>
>>> If your tasks are purely cpu bound you should probably be using a capped
>>> thread pool of platform threads as it makes no sense to have more threads
>>> than available cores.
>>>
>>>
>>>
>>> On Jan 23, 2026, at 7:42?AM, Jianbin Chen <jianbin at apache.org> wrote:
>>>
>>> ?
>>> The question is why I need to use a semaphore to control the number of
>>> concurrently running tasks. In my particular example, the goal is simply to
>>> keep the concurrency level the same across different thread pool
>>> implementations so I can fairly compare which one completes all the tasks
>>> faster. This isn't solely about memory consumption?purely from a
>>> **performance** perspective (e.g., total throughput or wall-clock time to
>>> finish the workload), the same number of concurrent tasks completes
>>> noticeably faster when using pooled virtual threads.
>>>
>>> My email probably didn't explain this clearly enough. In reality, I have
>>> two main questions:
>>>
>>> 1. When a third-party library uses `ThreadLocal` as a cache/pool (e.g.,
>>> to hold expensive reusable objects like connections, formatters, or
>>> parsers), is switching to a **pooled virtual thread executor** the only
>>> viable solution?assuming we cannot modify the third-party library code?
>>>
>>> 2. When running the exact same number of concurrent tasks, pooled
>>> virtual threads deliver better performance.
>>>
>>> Both questions point toward the same conclusion: for an application
>>> originally built around a traditional platform thread pool, after upgrading
>>> to JDK 21/25, moving to a **pooled virtual threads** approach is generally
>>> superior to simply using non-pooled (unbounded) virtual threads.
>>>
>>> If any part of this reasoning or conclusion is mistaken, I would really
>>> appreciate being corrected ? thank you very much in advance for any
>>> feedback or different experiences you can share!
>>>
>>> Best Regards.
>>> Jianbin Chen, github-id: funky-eyes
>>>
>>> robert engels <robaho at me.com> ? 2026?1?23??? 20:58???
>>>
>>>> Exactly, this is your problem. The total number of tasks will all be
>>>> running at once in the thread per task model.
>>>>
>>>> On Jan 23, 2026, at 6:49?AM, Jianbin Chen <jianbin at apache.org> wrote:
>>>>
>>>> ?
>>>> Hi Robert,
>>>>
>>>> Thanks you, but I'm a bit confused. In the example above, I only set
>>>> the core pool size to 200 virtual threads, but for the specific test case
>>>> we?re talking about, the concurrency isn?t actually being limited by the
>>>> pool size at all. Since the maximum thread count is Integer.MAX_VALUE and
>>>> it?s using a SynchronousQueue, tasks are handed off immediately and a new
>>>> thread gets created to run them right away anyway.
>>>>
>>>> Best Regards.
>>>> Jianbin Chen, github-id: funky-eyes
>>>>
>>>> robert engels <robaho at me.com> ? 2026?1?23??? 20:28???
>>>>
>>>>> Try using a semaphore to limit the maximum number of tasks in progress
>>>>> at anyone time - that is what is causing your memory spike. Think of it
>>>>> this way since VT threads are so cheap to create - you are essentially
>>>>> creating them all at once - making the working set size equally to the
>>>>> maximum.  So you have N * WSS, where as in the other you have POOLSIZE *
>>>>> WSS.
>>>>>
>>>>> On Jan 23, 2026, at 4:14?AM, Jianbin Chen <jianbin at apache.org> wrote:
>>>>>
>>>>> ?
>>>>> Hi Alan,
>>>>>
>>>>> Thanks for your reply and for mentioning JEP 444.
>>>>> I?ve gone through the guidance in JEP 444 and have some understanding
>>>>> of it ? which is exactly why I?m feeling a bit puzzled in practice and
>>>>> would really like to hear your thoughts.
>>>>>
>>>>> Background ? ThreadLocal example (Aerospike)
>>>>> ```java
>>>>> private static final ThreadLocal<byte[]> BufferThreadLocal = new
>>>>> ThreadLocal<byte[]>() {
>>>>>     @Override
>>>>>     protected byte[] initialValue() {
>>>>>         return new byte[DefaultBufferSize];
>>>>>     }
>>>>> };
>>>>> ```
>>>>> This Aerospike code allocates a default 8KB byte[] whenever a new
>>>>> thread is created and stores it in a ThreadLocal for per-thread caching.
>>>>>
>>>>> My concern
>>>>> - With a traditional platform-thread pool, those ThreadLocal byte[]
>>>>> instances are effectively reused because threads are long-lived and pooled.
>>>>> - If we switch to creating a brand-new virtual thread per task (no
>>>>> pooling), each virtual thread gets its own fresh ThreadLocal byte[], which
>>>>> leads to many short-lived 8KB allocations.
>>>>> - That raises allocation rate and GC pressure (despite collectors like
>>>>> ZGC), because ThreadLocal caches aren?t reused when threads are ephemeral.
>>>>>
>>>>> So my question is: for applications originally designed around
>>>>> platform-thread pools, wouldn?t partially pooling virtual threads be
>>>>> beneficial? For example, Tomcat?s default max threads is 200 ? if I keep a
>>>>> pool of 200 virtual threads, then when load exceeds that core size, a
>>>>> SynchronousQueue will naturally cause new virtual threads to be created on
>>>>> demand. This seems to preserve the behavior that ThreadLocal-based
>>>>> libraries expect, without losing the ability to expand under spikes. Since
>>>>> virtual threads are very lightweight, pooling a reasonable number (e.g.,
>>>>> 200) seems to have negligible memory downside while retaining ThreadLocal
>>>>> cache effectiveness.
>>>>>
>>>>> Empirical test I ran
>>>>> (I ran a microbenchmark comparing an unpooled per-task virtual-thread
>>>>> executor and a ThreadPoolExecutor that keeps 200 core virtual threads.)
>>>>>
>>>>> ```java
>>>>> public static void main(String[] args) throws InterruptedException {
>>>>>     Executor executor =
>>>>> Executors.newThreadPerTaskExecutor(Thread.ofVirtual().name("test-",
>>>>> 1).factory());
>>>>>     Executor executor2 = new ThreadPoolExecutor(
>>>>>         200,
>>>>>         Integer.MAX_VALUE,
>>>>>         0L,
>>>>>         java.util.concurrent.TimeUnit.SECONDS,
>>>>>         new SynchronousQueue<>(),
>>>>>         Thread.ofVirtual().name("test-threadpool-", 1).factory()
>>>>>     );
>>>>>
>>>>>     // Warm-up
>>>>>     for (int i = 0; i < 10100; i++) {
>>>>>         executor.execute(() -> {
>>>>>             // simulate I/O wait
>>>>>             try { Thread.sleep(100); } catch (InterruptedException e)
>>>>> { throw new RuntimeException(e); }
>>>>>         });
>>>>>         executor2.execute(() -> {
>>>>>             // simulate I/O wait
>>>>>             try { Thread.sleep(100); } catch (InterruptedException e)
>>>>> { throw new RuntimeException(e); }
>>>>>         });
>>>>>     }
>>>>>
>>>>>     // Ensure JIT + warm-up complete
>>>>>     Thread.sleep(5000);
>>>>>
>>>>>     long start = System.currentTimeMillis();
>>>>>     CountDownLatch countDownLatch = new CountDownLatch(50000);
>>>>>     for (int i = 0; i < 50000; i++) {
>>>>>         executor.execute(() -> {
>>>>>             try { Thread.sleep(100); countDownLatch.countDown(); }
>>>>> catch (InterruptedException e) { throw new RuntimeException(e); }
>>>>>         });
>>>>>     }
>>>>>     countDownLatch.await();
>>>>>     System.out.println("thread time: " + (System.currentTimeMillis() -
>>>>> start) + " ms");
>>>>>
>>>>>     start = System.currentTimeMillis();
>>>>>     CountDownLatch countDownLatch2 = new CountDownLatch(50000);
>>>>>     for (int i = 0; i < 50000; i++) {
>>>>>         executor2.execute(() -> {
>>>>>             try { Thread.sleep(100); countDownLatch2.countDown(); }
>>>>> catch (InterruptedException e) { throw new RuntimeException(e); }
>>>>>         });
>>>>>     }
>>>>>     countDownLatch.await();
>>>>>     System.out.println("thread pool time: " +
>>>>> (System.currentTimeMillis() - start) + " ms");
>>>>> }
>>>>> ```
>>>>>
>>>>> Result summary
>>>>> - In my runs, the pooled virtual-thread executor (executor2) performed
>>>>> better than the unpooled per-task virtual-thread executor.
>>>>> - Even when I increased load by 10x or 100x, the pooled virtual-thread
>>>>> executor still showed better performance.
>>>>> - In realistic workloads, it seems pooling some virtual threads
>>>>> reduces allocation/GC overhead and improves throughput compared to strictly
>>>>> unpooled virtual threads.
>>>>>
>>>>> Final thought / request for feedback
>>>>> - From my perspective, for systems originally tuned for
>>>>> platform-thread pools, partially pooling virtual threads seems to have no
>>>>> obvious downside and can restore ThreadLocal cache effectiveness used by
>>>>> many third-party libraries.
>>>>> - If I?ve misunderstood JEP 444 recommendations, virtual-thread
>>>>> semantics, or ThreadLocal behavior, please point out what I?m missing. I?d
>>>>> appreciate your guidance.
>>>>>
>>>>> Best Regards.
>>>>> Jianbin Chen, github-id: funky-eyes
>>>>>
>>>>> Alan Bateman <alan.bateman at oracle.com> ? 2026?1?23??? 17:27???
>>>>>
>>>>>> On 23/01/2026 07:30, Jianbin Chen wrote:
>>>>>> > :
>>>>>> >
>>>>>> > So my question is:
>>>>>> >
>>>>>> > **In scenarios where third-party libraries heavily rely on
>>>>>> ThreadLocal
>>>>>> > for caching / buffering (and we cannot change those libraries to
>>>>>> use
>>>>>> > object pools instead), is explicitly pooling virtual threads (using
>>>>>> a
>>>>>> > ThreadPoolExecutor with virtual thread factory) considered a
>>>>>> > recommended / acceptable workaround?**
>>>>>> >
>>>>>> > Or are there better / more idiomatic ways to handle this kind of
>>>>>> > compatibility issue with legacy ThreadLocal-based libraries when
>>>>>> > migrating to virtual threads?
>>>>>> >
>>>>>> > I have already opened a related discussion in the Dubbo project
>>>>>> (since
>>>>>> > Dubbo is one of the libraries affected in our stack):
>>>>>> >
>>>>>> > https://github.com/apache/dubbo/issues/16042
>>>>>> >
>>>>>> > Would love to hear your thoughts ? especially from people who have
>>>>>> > experience running large-scale virtual-thread-based services with
>>>>>> > mixed third-party dependencies.
>>>>>> >
>>>>>>
>>>>>> The guidelines that we put in JEP 444 [1] is to not pool virtual
>>>>>> threads
>>>>>> and to avoid caching costing resources in thread locals. Virtual
>>>>>> threads
>>>>>> support thread locals of course but that is not useful when some
>>>>>> library
>>>>>> is looking to share a costly resource between tasks that run on the
>>>>>> same
>>>>>> thread in a thread pool.
>>>>>>
>>>>>> I don't know anything about Aerospike but working with the
>>>>>> maintainers
>>>>>> of that library to re-work its buffer management seems like the right
>>>>>> course of action here. Your mail says "byte buffers". If this is
>>>>>> ByteBuffer it might be that they are caching direct buffers as they
>>>>>> are
>>>>>> expensive to create (and managed by the GC). Maybe they could look at
>>>>>> using MemorySegment (it's easy to get a ByteBuffer view of a memory
>>>>>> segment) and allocate from an arena that better matches the lifecycle.
>>>>>>
>>>>>> Hopefully others will share their experiences with migration as it is
>>>>>> indeed challenging to migrate code developed for thread pools to work
>>>>>> efficiently on virtual threads where there is 1-1 relationship
>>>>>> between
>>>>>> the task to execute and the thread.
>>>>>>
>>>>>> -Alan
>>>>>>
>>>>>> [1] https://openjdk.org/jeps/444#Thread-local-variables
>>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260123/2e1ed538/attachment-0001.htm>

From jianbin at apache.org  Fri Jan 23 15:29:48 2026
From: jianbin at apache.org (Jianbin Chen)
Date: Fri, 23 Jan 2026 23:29:48 +0800
Subject: Performance Issues with Virtual Threads + ThreadLocal Caching in
 Third-Party Libraries (JDK 25)
In-Reply-To: <CAKxGtTXdvHqOVhV3PHtz5+ZiaRB8dFD2YtGQO0uH1W36gyMwOg@mail.gmail.com>
References: <CAAMX02o7ugTq-EuZO-dp_vhc0kHz2fp1q5RVNn7_N7JX7RvDYQ@mail.gmail.com>
 <40EFCACE-5F3F-4AF6-B8CA-9F8EEAFCD1FD@ix.netcom.com>
 <CAAMX02oGPtkTfr02Lmd8RtXsupP92zAEm8E3VwMqjKqosZooqA@mail.gmail.com>
 <CAKxGtTXdvHqOVhV3PHtz5+ZiaRB8dFD2YtGQO0uH1W36gyMwOg@mail.gmail.com>
Message-ID: <CAAMX02qfZjQL6Fowpu-25D-9_F5zifXMAMP=HWbtQwUsqv3+VQ@mail.gmail.com>

Hi Francesco,

I'd like to know if there's a similar issue in JDK 21?

Best Regards.
Jianbin Chen, github-id: funky-eyes

Francesco Nigro <nigro.fra at gmail.com> ? 2026?1?23??? 23:14???

> In the original code snippet I see named (with a counter) VThreads, so, be
> aware of https://bugs.openjdk.org/browse/JDK-8372410
>
> Il giorno ven 23 gen 2026 alle ore 15:52 Jianbin Chen <jianbin at apache.org>
> ha scritto:
>
>> I'm sorry ? I forgot to mention the machine I used for the load test. My
>> server is 2 cores and 4 GB RAM, and the JVM heap was set to 2880m. Under my
>> test load (about 20,000 QPS), with non?pooled virtual threads you generate
>> at least 20,000 ? 8 KB = ~156 MB of byte[] allocations per second just from
>> that 8 KB buffer; that doesn't include other object allocations. With a
>> 2880 MB heap this allocation rate already forces very frequent GC, and
>> frequent GC raises CPU usage, which in turn significantly increases average
>> response time and p99 / p999 latency.
>>
>> Pooling is usually introduced to solve performance issues ? object pools
>> and connection pools exist to quickly reuse cached resources and improve
>> performance. So pooling virtual threads also yields obvious benefits,
>> especially for memory?constrained, I/O?bound applications (gateways,
>> proxies, etc.) that are sensitive to latency.
>>
>> Best Regards.
>> Jianbin Chen, github-id: funky-eyes
>>
>> Robert Engels <rengels at ix.netcom.com> ? 2026?1?23??? 22:20???
>>
>>> I understand. I was trying explain how you can not use thread locals and
>>> maintain the performance. It?s unlikely allocating a 8k buffer is a
>>> performance bottleneck in a real program if the task is not cpu bound
>>> (depending on the granularity you make your tasks) - but 2M tasks running
>>> simultaneously would require 16gb of memory not including the stack.
>>>
>>> You cannot simply use the thread per task model without an understanding
>>> of the cpu, IO, and memory footprints of your tasks and then configure
>>> appropriately.
>>>
>>> On Jan 23, 2026, at 8:10?AM, Jianbin Chen <jianbin at apache.org> wrote:
>>>
>>> ?
>>> I'm sorry, Robert?perhaps I didn't explain my example clearly enough.
>>> Here's the code in question:
>>>
>>> ```java
>>> Executor executor2 = new ThreadPoolExecutor(
>>>     200,
>>>     Integer.MAX_VALUE,
>>>     0L,
>>>     java.util.concurrent.TimeUnit.SECONDS,
>>>     new SynchronousQueue<>(),
>>>     Thread.ofVirtual().name("test-threadpool-", 1).factory()
>>> );
>>> ```
>>>
>>> In this example, the pooled virtual threads don't implement any
>>> backpressure mechanism; they simply maintain a core pool of 200 virtual
>>> threads. Given that the queue is a `SynchronousQueue` and the maximum pool
>>> size is set to `Integer.MAX_VALUE`, once the concurrent tasks exceed 200,
>>> its behavior becomes identical to that of non-pooled virtual threads.
>>>
>>> From my perspective, this example demonstrates that the benefits of
>>> pooling virtual threads outweigh those of creating a new virtual thread for
>>> every single task. In IO-bound scenarios, the virtual threads are directly
>>> reused rather than being recreated each time, and the memory footprint of
>>> virtual threads is far smaller than that of platform threads (which are
>>> controlled by the `-Xss` flag). Additionally, with pooled virtual threads,
>>> the 8KB `byte[]` cache I mentioned earlier (stored in `ThreadLocal`) can
>>> also be reused, which further reduces overall memory usage?wouldn't you
>>> agree?
>>>
>>> Best Regards.
>>> Jianbin Chen, github-id: funky-eyes
>>>
>>> Robert Engels <rengels at ix.netcom.com> ? 2026?1?23??? 21:52???
>>>
>>>> Because VT are so efficient to create, without any back pressure they
>>>> will all be created and running at essentially the same time (dramatically
>>>> raising the amount of memory in use) - versus with a pool of size N you
>>>> will have at most N running at once. In a REAL WORLD application there are
>>>> often external limiters (like number of tcp connections) that provide a
>>>> limit.
>>>>
>>>> If your tasks are purely cpu bound you should probably be using a
>>>> capped thread pool of platform threads as it makes no sense to have more
>>>> threads than available cores.
>>>>
>>>>
>>>>
>>>> On Jan 23, 2026, at 7:42?AM, Jianbin Chen <jianbin at apache.org> wrote:
>>>>
>>>> ?
>>>> The question is why I need to use a semaphore to control the number of
>>>> concurrently running tasks. In my particular example, the goal is simply to
>>>> keep the concurrency level the same across different thread pool
>>>> implementations so I can fairly compare which one completes all the tasks
>>>> faster. This isn't solely about memory consumption?purely from a
>>>> **performance** perspective (e.g., total throughput or wall-clock time to
>>>> finish the workload), the same number of concurrent tasks completes
>>>> noticeably faster when using pooled virtual threads.
>>>>
>>>> My email probably didn't explain this clearly enough. In reality, I
>>>> have two main questions:
>>>>
>>>> 1. When a third-party library uses `ThreadLocal` as a cache/pool (e.g.,
>>>> to hold expensive reusable objects like connections, formatters, or
>>>> parsers), is switching to a **pooled virtual thread executor** the only
>>>> viable solution?assuming we cannot modify the third-party library code?
>>>>
>>>> 2. When running the exact same number of concurrent tasks, pooled
>>>> virtual threads deliver better performance.
>>>>
>>>> Both questions point toward the same conclusion: for an application
>>>> originally built around a traditional platform thread pool, after upgrading
>>>> to JDK 21/25, moving to a **pooled virtual threads** approach is generally
>>>> superior to simply using non-pooled (unbounded) virtual threads.
>>>>
>>>> If any part of this reasoning or conclusion is mistaken, I would really
>>>> appreciate being corrected ? thank you very much in advance for any
>>>> feedback or different experiences you can share!
>>>>
>>>> Best Regards.
>>>> Jianbin Chen, github-id: funky-eyes
>>>>
>>>> robert engels <robaho at me.com> ? 2026?1?23??? 20:58???
>>>>
>>>>> Exactly, this is your problem. The total number of tasks will all be
>>>>> running at once in the thread per task model.
>>>>>
>>>>> On Jan 23, 2026, at 6:49?AM, Jianbin Chen <jianbin at apache.org> wrote:
>>>>>
>>>>> ?
>>>>> Hi Robert,
>>>>>
>>>>> Thanks you, but I'm a bit confused. In the example above, I only set
>>>>> the core pool size to 200 virtual threads, but for the specific test case
>>>>> we?re talking about, the concurrency isn?t actually being limited by the
>>>>> pool size at all. Since the maximum thread count is Integer.MAX_VALUE and
>>>>> it?s using a SynchronousQueue, tasks are handed off immediately and a new
>>>>> thread gets created to run them right away anyway.
>>>>>
>>>>> Best Regards.
>>>>> Jianbin Chen, github-id: funky-eyes
>>>>>
>>>>> robert engels <robaho at me.com> ? 2026?1?23??? 20:28???
>>>>>
>>>>>> Try using a semaphore to limit the maximum number of tasks in
>>>>>> progress at anyone time - that is what is causing your memory spike. Think
>>>>>> of it this way since VT threads are so cheap to create - you are
>>>>>> essentially creating them all at once - making the working set size equally
>>>>>> to the maximum.  So you have N * WSS, where as in the other you have
>>>>>> POOLSIZE * WSS.
>>>>>>
>>>>>> On Jan 23, 2026, at 4:14?AM, Jianbin Chen <jianbin at apache.org> wrote:
>>>>>>
>>>>>> ?
>>>>>> Hi Alan,
>>>>>>
>>>>>> Thanks for your reply and for mentioning JEP 444.
>>>>>> I?ve gone through the guidance in JEP 444 and have some understanding
>>>>>> of it ? which is exactly why I?m feeling a bit puzzled in practice and
>>>>>> would really like to hear your thoughts.
>>>>>>
>>>>>> Background ? ThreadLocal example (Aerospike)
>>>>>> ```java
>>>>>> private static final ThreadLocal<byte[]> BufferThreadLocal = new
>>>>>> ThreadLocal<byte[]>() {
>>>>>>     @Override
>>>>>>     protected byte[] initialValue() {
>>>>>>         return new byte[DefaultBufferSize];
>>>>>>     }
>>>>>> };
>>>>>> ```
>>>>>> This Aerospike code allocates a default 8KB byte[] whenever a new
>>>>>> thread is created and stores it in a ThreadLocal for per-thread caching.
>>>>>>
>>>>>> My concern
>>>>>> - With a traditional platform-thread pool, those ThreadLocal byte[]
>>>>>> instances are effectively reused because threads are long-lived and pooled.
>>>>>> - If we switch to creating a brand-new virtual thread per task (no
>>>>>> pooling), each virtual thread gets its own fresh ThreadLocal byte[], which
>>>>>> leads to many short-lived 8KB allocations.
>>>>>> - That raises allocation rate and GC pressure (despite collectors
>>>>>> like ZGC), because ThreadLocal caches aren?t reused when threads are
>>>>>> ephemeral.
>>>>>>
>>>>>> So my question is: for applications originally designed around
>>>>>> platform-thread pools, wouldn?t partially pooling virtual threads be
>>>>>> beneficial? For example, Tomcat?s default max threads is 200 ? if I keep a
>>>>>> pool of 200 virtual threads, then when load exceeds that core size, a
>>>>>> SynchronousQueue will naturally cause new virtual threads to be created on
>>>>>> demand. This seems to preserve the behavior that ThreadLocal-based
>>>>>> libraries expect, without losing the ability to expand under spikes. Since
>>>>>> virtual threads are very lightweight, pooling a reasonable number (e.g.,
>>>>>> 200) seems to have negligible memory downside while retaining ThreadLocal
>>>>>> cache effectiveness.
>>>>>>
>>>>>> Empirical test I ran
>>>>>> (I ran a microbenchmark comparing an unpooled per-task virtual-thread
>>>>>> executor and a ThreadPoolExecutor that keeps 200 core virtual threads.)
>>>>>>
>>>>>> ```java
>>>>>> public static void main(String[] args) throws InterruptedException {
>>>>>>     Executor executor =
>>>>>> Executors.newThreadPerTaskExecutor(Thread.ofVirtual().name("test-",
>>>>>> 1).factory());
>>>>>>     Executor executor2 = new ThreadPoolExecutor(
>>>>>>         200,
>>>>>>         Integer.MAX_VALUE,
>>>>>>         0L,
>>>>>>         java.util.concurrent.TimeUnit.SECONDS,
>>>>>>         new SynchronousQueue<>(),
>>>>>>         Thread.ofVirtual().name("test-threadpool-", 1).factory()
>>>>>>     );
>>>>>>
>>>>>>     // Warm-up
>>>>>>     for (int i = 0; i < 10100; i++) {
>>>>>>         executor.execute(() -> {
>>>>>>             // simulate I/O wait
>>>>>>             try { Thread.sleep(100); } catch (InterruptedException e)
>>>>>> { throw new RuntimeException(e); }
>>>>>>         });
>>>>>>         executor2.execute(() -> {
>>>>>>             // simulate I/O wait
>>>>>>             try { Thread.sleep(100); } catch (InterruptedException e)
>>>>>> { throw new RuntimeException(e); }
>>>>>>         });
>>>>>>     }
>>>>>>
>>>>>>     // Ensure JIT + warm-up complete
>>>>>>     Thread.sleep(5000);
>>>>>>
>>>>>>     long start = System.currentTimeMillis();
>>>>>>     CountDownLatch countDownLatch = new CountDownLatch(50000);
>>>>>>     for (int i = 0; i < 50000; i++) {
>>>>>>         executor.execute(() -> {
>>>>>>             try { Thread.sleep(100); countDownLatch.countDown(); }
>>>>>> catch (InterruptedException e) { throw new RuntimeException(e); }
>>>>>>         });
>>>>>>     }
>>>>>>     countDownLatch.await();
>>>>>>     System.out.println("thread time: " + (System.currentTimeMillis()
>>>>>> - start) + " ms");
>>>>>>
>>>>>>     start = System.currentTimeMillis();
>>>>>>     CountDownLatch countDownLatch2 = new CountDownLatch(50000);
>>>>>>     for (int i = 0; i < 50000; i++) {
>>>>>>         executor2.execute(() -> {
>>>>>>             try { Thread.sleep(100); countDownLatch2.countDown(); }
>>>>>> catch (InterruptedException e) { throw new RuntimeException(e); }
>>>>>>         });
>>>>>>     }
>>>>>>     countDownLatch.await();
>>>>>>     System.out.println("thread pool time: " +
>>>>>> (System.currentTimeMillis() - start) + " ms");
>>>>>> }
>>>>>> ```
>>>>>>
>>>>>> Result summary
>>>>>> - In my runs, the pooled virtual-thread executor (executor2)
>>>>>> performed better than the unpooled per-task virtual-thread executor.
>>>>>> - Even when I increased load by 10x or 100x, the pooled
>>>>>> virtual-thread executor still showed better performance.
>>>>>> - In realistic workloads, it seems pooling some virtual threads
>>>>>> reduces allocation/GC overhead and improves throughput compared to strictly
>>>>>> unpooled virtual threads.
>>>>>>
>>>>>> Final thought / request for feedback
>>>>>> - From my perspective, for systems originally tuned for
>>>>>> platform-thread pools, partially pooling virtual threads seems to have no
>>>>>> obvious downside and can restore ThreadLocal cache effectiveness used by
>>>>>> many third-party libraries.
>>>>>> - If I?ve misunderstood JEP 444 recommendations, virtual-thread
>>>>>> semantics, or ThreadLocal behavior, please point out what I?m missing. I?d
>>>>>> appreciate your guidance.
>>>>>>
>>>>>> Best Regards.
>>>>>> Jianbin Chen, github-id: funky-eyes
>>>>>>
>>>>>> Alan Bateman <alan.bateman at oracle.com> ? 2026?1?23??? 17:27???
>>>>>>
>>>>>>> On 23/01/2026 07:30, Jianbin Chen wrote:
>>>>>>> > :
>>>>>>> >
>>>>>>> > So my question is:
>>>>>>> >
>>>>>>> > **In scenarios where third-party libraries heavily rely on
>>>>>>> ThreadLocal
>>>>>>> > for caching / buffering (and we cannot change those libraries to
>>>>>>> use
>>>>>>> > object pools instead), is explicitly pooling virtual threads
>>>>>>> (using a
>>>>>>> > ThreadPoolExecutor with virtual thread factory) considered a
>>>>>>> > recommended / acceptable workaround?**
>>>>>>> >
>>>>>>> > Or are there better / more idiomatic ways to handle this kind of
>>>>>>> > compatibility issue with legacy ThreadLocal-based libraries when
>>>>>>> > migrating to virtual threads?
>>>>>>> >
>>>>>>> > I have already opened a related discussion in the Dubbo project
>>>>>>> (since
>>>>>>> > Dubbo is one of the libraries affected in our stack):
>>>>>>> >
>>>>>>> > https://github.com/apache/dubbo/issues/16042
>>>>>>> >
>>>>>>> > Would love to hear your thoughts ? especially from people who have
>>>>>>> > experience running large-scale virtual-thread-based services with
>>>>>>> > mixed third-party dependencies.
>>>>>>> >
>>>>>>>
>>>>>>> The guidelines that we put in JEP 444 [1] is to not pool virtual
>>>>>>> threads
>>>>>>> and to avoid caching costing resources in thread locals. Virtual
>>>>>>> threads
>>>>>>> support thread locals of course but that is not useful when some
>>>>>>> library
>>>>>>> is looking to share a costly resource between tasks that run on the
>>>>>>> same
>>>>>>> thread in a thread pool.
>>>>>>>
>>>>>>> I don't know anything about Aerospike but working with the
>>>>>>> maintainers
>>>>>>> of that library to re-work its buffer management seems like the
>>>>>>> right
>>>>>>> course of action here. Your mail says "byte buffers". If this is
>>>>>>> ByteBuffer it might be that they are caching direct buffers as they
>>>>>>> are
>>>>>>> expensive to create (and managed by the GC). Maybe they could look
>>>>>>> at
>>>>>>> using MemorySegment (it's easy to get a ByteBuffer view of a memory
>>>>>>> segment) and allocate from an arena that better matches the
>>>>>>> lifecycle.
>>>>>>>
>>>>>>> Hopefully others will share their experiences with migration as it
>>>>>>> is
>>>>>>> indeed challenging to migrate code developed for thread pools to
>>>>>>> work
>>>>>>> efficiently on virtual threads where there is 1-1 relationship
>>>>>>> between
>>>>>>> the task to execute and the thread.
>>>>>>>
>>>>>>> -Alan
>>>>>>>
>>>>>>> [1] https://openjdk.org/jeps/444#Thread-local-variables
>>>>>>>
>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260123/2144bc96/attachment-0001.htm>

From nigro.fra at gmail.com  Fri Jan 23 15:37:17 2026
From: nigro.fra at gmail.com (Francesco Nigro)
Date: Fri, 23 Jan 2026 16:37:17 +0100
Subject: Performance Issues with Virtual Threads + ThreadLocal Caching in
 Third-Party Libraries (JDK 25)
In-Reply-To: <CAAMX02qfZjQL6Fowpu-25D-9_F5zifXMAMP=HWbtQwUsqv3+VQ@mail.gmail.com>
References: <CAAMX02o7ugTq-EuZO-dp_vhc0kHz2fp1q5RVNn7_N7JX7RvDYQ@mail.gmail.com>
 <40EFCACE-5F3F-4AF6-B8CA-9F8EEAFCD1FD@ix.netcom.com>
 <CAAMX02oGPtkTfr02Lmd8RtXsupP92zAEm8E3VwMqjKqosZooqA@mail.gmail.com>
 <CAKxGtTXdvHqOVhV3PHtz5+ZiaRB8dFD2YtGQO0uH1W36gyMwOg@mail.gmail.com>
 <CAAMX02qfZjQL6Fowpu-25D-9_F5zifXMAMP=HWbtQwUsqv3+VQ@mail.gmail.com>
Message-ID: <CAKxGtTUTUyrodMUc2RTqNv7VQj9sn7No2QPy63ZCX51_cquy3w@mail.gmail.com>

I would say, yes:
https://github.com/openjdk/jdk21/blob/890adb6410dab4606a4f26a942aed02fb2f55387/src/java.base/share/classes/java/lang/ThreadBuilders.java#L317
unless the fix will be backported - surely @Andrew Haley
<aph-open at littlepinkcloud.com> or @Alan Bateman <alan.bateman at oracle.com>
 knows

Il giorno ven 23 gen 2026 alle ore 16:32 Jianbin Chen <jianbin at apache.org>
ha scritto:

> Hi Francesco,
>
> I'd like to know if there's a similar issue in JDK 21?
>
> Best Regards.
> Jianbin Chen, github-id: funky-eyes
>
> Francesco Nigro <nigro.fra at gmail.com> ? 2026?1?23??? 23:14???
>
>> In the original code snippet I see named (with a counter) VThreads, so,
>> be aware of https://bugs.openjdk.org/browse/JDK-8372410
>>
>> Il giorno ven 23 gen 2026 alle ore 15:52 Jianbin Chen <jianbin at apache.org>
>> ha scritto:
>>
>>> I'm sorry ? I forgot to mention the machine I used for the load test. My
>>> server is 2 cores and 4 GB RAM, and the JVM heap was set to 2880m. Under my
>>> test load (about 20,000 QPS), with non?pooled virtual threads you generate
>>> at least 20,000 ? 8 KB = ~156 MB of byte[] allocations per second just from
>>> that 8 KB buffer; that doesn't include other object allocations. With a
>>> 2880 MB heap this allocation rate already forces very frequent GC, and
>>> frequent GC raises CPU usage, which in turn significantly increases average
>>> response time and p99 / p999 latency.
>>>
>>> Pooling is usually introduced to solve performance issues ? object pools
>>> and connection pools exist to quickly reuse cached resources and improve
>>> performance. So pooling virtual threads also yields obvious benefits,
>>> especially for memory?constrained, I/O?bound applications (gateways,
>>> proxies, etc.) that are sensitive to latency.
>>>
>>> Best Regards.
>>> Jianbin Chen, github-id: funky-eyes
>>>
>>> Robert Engels <rengels at ix.netcom.com> ? 2026?1?23??? 22:20???
>>>
>>>> I understand. I was trying explain how you can not use thread locals
>>>> and maintain the performance. It?s unlikely allocating a 8k buffer is a
>>>> performance bottleneck in a real program if the task is not cpu bound
>>>> (depending on the granularity you make your tasks) - but 2M tasks running
>>>> simultaneously would require 16gb of memory not including the stack.
>>>>
>>>> You cannot simply use the thread per task model without an
>>>> understanding of the cpu, IO, and memory footprints of your tasks and then
>>>> configure appropriately.
>>>>
>>>> On Jan 23, 2026, at 8:10?AM, Jianbin Chen <jianbin at apache.org> wrote:
>>>>
>>>> ?
>>>> I'm sorry, Robert?perhaps I didn't explain my example clearly enough.
>>>> Here's the code in question:
>>>>
>>>> ```java
>>>> Executor executor2 = new ThreadPoolExecutor(
>>>>     200,
>>>>     Integer.MAX_VALUE,
>>>>     0L,
>>>>     java.util.concurrent.TimeUnit.SECONDS,
>>>>     new SynchronousQueue<>(),
>>>>     Thread.ofVirtual().name("test-threadpool-", 1).factory()
>>>> );
>>>> ```
>>>>
>>>> In this example, the pooled virtual threads don't implement any
>>>> backpressure mechanism; they simply maintain a core pool of 200 virtual
>>>> threads. Given that the queue is a `SynchronousQueue` and the maximum pool
>>>> size is set to `Integer.MAX_VALUE`, once the concurrent tasks exceed 200,
>>>> its behavior becomes identical to that of non-pooled virtual threads.
>>>>
>>>> From my perspective, this example demonstrates that the benefits of
>>>> pooling virtual threads outweigh those of creating a new virtual thread for
>>>> every single task. In IO-bound scenarios, the virtual threads are directly
>>>> reused rather than being recreated each time, and the memory footprint of
>>>> virtual threads is far smaller than that of platform threads (which are
>>>> controlled by the `-Xss` flag). Additionally, with pooled virtual threads,
>>>> the 8KB `byte[]` cache I mentioned earlier (stored in `ThreadLocal`) can
>>>> also be reused, which further reduces overall memory usage?wouldn't you
>>>> agree?
>>>>
>>>> Best Regards.
>>>> Jianbin Chen, github-id: funky-eyes
>>>>
>>>> Robert Engels <rengels at ix.netcom.com> ? 2026?1?23??? 21:52???
>>>>
>>>>> Because VT are so efficient to create, without any back pressure they
>>>>> will all be created and running at essentially the same time (dramatically
>>>>> raising the amount of memory in use) - versus with a pool of size N you
>>>>> will have at most N running at once. In a REAL WORLD application there are
>>>>> often external limiters (like number of tcp connections) that provide a
>>>>> limit.
>>>>>
>>>>> If your tasks are purely cpu bound you should probably be using a
>>>>> capped thread pool of platform threads as it makes no sense to have more
>>>>> threads than available cores.
>>>>>
>>>>>
>>>>>
>>>>> On Jan 23, 2026, at 7:42?AM, Jianbin Chen <jianbin at apache.org> wrote:
>>>>>
>>>>> ?
>>>>> The question is why I need to use a semaphore to control the number of
>>>>> concurrently running tasks. In my particular example, the goal is simply to
>>>>> keep the concurrency level the same across different thread pool
>>>>> implementations so I can fairly compare which one completes all the tasks
>>>>> faster. This isn't solely about memory consumption?purely from a
>>>>> **performance** perspective (e.g., total throughput or wall-clock time to
>>>>> finish the workload), the same number of concurrent tasks completes
>>>>> noticeably faster when using pooled virtual threads.
>>>>>
>>>>> My email probably didn't explain this clearly enough. In reality, I
>>>>> have two main questions:
>>>>>
>>>>> 1. When a third-party library uses `ThreadLocal` as a cache/pool
>>>>> (e.g., to hold expensive reusable objects like connections, formatters, or
>>>>> parsers), is switching to a **pooled virtual thread executor** the only
>>>>> viable solution?assuming we cannot modify the third-party library code?
>>>>>
>>>>> 2. When running the exact same number of concurrent tasks, pooled
>>>>> virtual threads deliver better performance.
>>>>>
>>>>> Both questions point toward the same conclusion: for an application
>>>>> originally built around a traditional platform thread pool, after upgrading
>>>>> to JDK 21/25, moving to a **pooled virtual threads** approach is generally
>>>>> superior to simply using non-pooled (unbounded) virtual threads.
>>>>>
>>>>> If any part of this reasoning or conclusion is mistaken, I would
>>>>> really appreciate being corrected ? thank you very much in advance for any
>>>>> feedback or different experiences you can share!
>>>>>
>>>>> Best Regards.
>>>>> Jianbin Chen, github-id: funky-eyes
>>>>>
>>>>> robert engels <robaho at me.com> ? 2026?1?23??? 20:58???
>>>>>
>>>>>> Exactly, this is your problem. The total number of tasks will all be
>>>>>> running at once in the thread per task model.
>>>>>>
>>>>>> On Jan 23, 2026, at 6:49?AM, Jianbin Chen <jianbin at apache.org> wrote:
>>>>>>
>>>>>> ?
>>>>>> Hi Robert,
>>>>>>
>>>>>> Thanks you, but I'm a bit confused. In the example above, I only set
>>>>>> the core pool size to 200 virtual threads, but for the specific test case
>>>>>> we?re talking about, the concurrency isn?t actually being limited by the
>>>>>> pool size at all. Since the maximum thread count is Integer.MAX_VALUE and
>>>>>> it?s using a SynchronousQueue, tasks are handed off immediately and a new
>>>>>> thread gets created to run them right away anyway.
>>>>>>
>>>>>> Best Regards.
>>>>>> Jianbin Chen, github-id: funky-eyes
>>>>>>
>>>>>> robert engels <robaho at me.com> ? 2026?1?23??? 20:28???
>>>>>>
>>>>>>> Try using a semaphore to limit the maximum number of tasks in
>>>>>>> progress at anyone time - that is what is causing your memory spike. Think
>>>>>>> of it this way since VT threads are so cheap to create - you are
>>>>>>> essentially creating them all at once - making the working set size equally
>>>>>>> to the maximum.  So you have N * WSS, where as in the other you have
>>>>>>> POOLSIZE * WSS.
>>>>>>>
>>>>>>> On Jan 23, 2026, at 4:14?AM, Jianbin Chen <jianbin at apache.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>> ?
>>>>>>> Hi Alan,
>>>>>>>
>>>>>>> Thanks for your reply and for mentioning JEP 444.
>>>>>>> I?ve gone through the guidance in JEP 444 and have some
>>>>>>> understanding of it ? which is exactly why I?m feeling a bit puzzled in
>>>>>>> practice and would really like to hear your thoughts.
>>>>>>>
>>>>>>> Background ? ThreadLocal example (Aerospike)
>>>>>>> ```java
>>>>>>> private static final ThreadLocal<byte[]> BufferThreadLocal = new
>>>>>>> ThreadLocal<byte[]>() {
>>>>>>>     @Override
>>>>>>>     protected byte[] initialValue() {
>>>>>>>         return new byte[DefaultBufferSize];
>>>>>>>     }
>>>>>>> };
>>>>>>> ```
>>>>>>> This Aerospike code allocates a default 8KB byte[] whenever a new
>>>>>>> thread is created and stores it in a ThreadLocal for per-thread caching.
>>>>>>>
>>>>>>> My concern
>>>>>>> - With a traditional platform-thread pool, those ThreadLocal byte[]
>>>>>>> instances are effectively reused because threads are long-lived and pooled.
>>>>>>> - If we switch to creating a brand-new virtual thread per task (no
>>>>>>> pooling), each virtual thread gets its own fresh ThreadLocal byte[], which
>>>>>>> leads to many short-lived 8KB allocations.
>>>>>>> - That raises allocation rate and GC pressure (despite collectors
>>>>>>> like ZGC), because ThreadLocal caches aren?t reused when threads are
>>>>>>> ephemeral.
>>>>>>>
>>>>>>> So my question is: for applications originally designed around
>>>>>>> platform-thread pools, wouldn?t partially pooling virtual threads be
>>>>>>> beneficial? For example, Tomcat?s default max threads is 200 ? if I keep a
>>>>>>> pool of 200 virtual threads, then when load exceeds that core size, a
>>>>>>> SynchronousQueue will naturally cause new virtual threads to be created on
>>>>>>> demand. This seems to preserve the behavior that ThreadLocal-based
>>>>>>> libraries expect, without losing the ability to expand under spikes. Since
>>>>>>> virtual threads are very lightweight, pooling a reasonable number (e.g.,
>>>>>>> 200) seems to have negligible memory downside while retaining ThreadLocal
>>>>>>> cache effectiveness.
>>>>>>>
>>>>>>> Empirical test I ran
>>>>>>> (I ran a microbenchmark comparing an unpooled per-task
>>>>>>> virtual-thread executor and a ThreadPoolExecutor that keeps 200 core
>>>>>>> virtual threads.)
>>>>>>>
>>>>>>> ```java
>>>>>>> public static void main(String[] args) throws InterruptedException {
>>>>>>>     Executor executor =
>>>>>>> Executors.newThreadPerTaskExecutor(Thread.ofVirtual().name("test-",
>>>>>>> 1).factory());
>>>>>>>     Executor executor2 = new ThreadPoolExecutor(
>>>>>>>         200,
>>>>>>>         Integer.MAX_VALUE,
>>>>>>>         0L,
>>>>>>>         java.util.concurrent.TimeUnit.SECONDS,
>>>>>>>         new SynchronousQueue<>(),
>>>>>>>         Thread.ofVirtual().name("test-threadpool-", 1).factory()
>>>>>>>     );
>>>>>>>
>>>>>>>     // Warm-up
>>>>>>>     for (int i = 0; i < 10100; i++) {
>>>>>>>         executor.execute(() -> {
>>>>>>>             // simulate I/O wait
>>>>>>>             try { Thread.sleep(100); } catch (InterruptedException
>>>>>>> e) { throw new RuntimeException(e); }
>>>>>>>         });
>>>>>>>         executor2.execute(() -> {
>>>>>>>             // simulate I/O wait
>>>>>>>             try { Thread.sleep(100); } catch (InterruptedException
>>>>>>> e) { throw new RuntimeException(e); }
>>>>>>>         });
>>>>>>>     }
>>>>>>>
>>>>>>>     // Ensure JIT + warm-up complete
>>>>>>>     Thread.sleep(5000);
>>>>>>>
>>>>>>>     long start = System.currentTimeMillis();
>>>>>>>     CountDownLatch countDownLatch = new CountDownLatch(50000);
>>>>>>>     for (int i = 0; i < 50000; i++) {
>>>>>>>         executor.execute(() -> {
>>>>>>>             try { Thread.sleep(100); countDownLatch.countDown(); }
>>>>>>> catch (InterruptedException e) { throw new RuntimeException(e); }
>>>>>>>         });
>>>>>>>     }
>>>>>>>     countDownLatch.await();
>>>>>>>     System.out.println("thread time: " + (System.currentTimeMillis()
>>>>>>> - start) + " ms");
>>>>>>>
>>>>>>>     start = System.currentTimeMillis();
>>>>>>>     CountDownLatch countDownLatch2 = new CountDownLatch(50000);
>>>>>>>     for (int i = 0; i < 50000; i++) {
>>>>>>>         executor2.execute(() -> {
>>>>>>>             try { Thread.sleep(100); countDownLatch2.countDown(); }
>>>>>>> catch (InterruptedException e) { throw new RuntimeException(e); }
>>>>>>>         });
>>>>>>>     }
>>>>>>>     countDownLatch.await();
>>>>>>>     System.out.println("thread pool time: " +
>>>>>>> (System.currentTimeMillis() - start) + " ms");
>>>>>>> }
>>>>>>> ```
>>>>>>>
>>>>>>> Result summary
>>>>>>> - In my runs, the pooled virtual-thread executor (executor2)
>>>>>>> performed better than the unpooled per-task virtual-thread executor.
>>>>>>> - Even when I increased load by 10x or 100x, the pooled
>>>>>>> virtual-thread executor still showed better performance.
>>>>>>> - In realistic workloads, it seems pooling some virtual threads
>>>>>>> reduces allocation/GC overhead and improves throughput compared to strictly
>>>>>>> unpooled virtual threads.
>>>>>>>
>>>>>>> Final thought / request for feedback
>>>>>>> - From my perspective, for systems originally tuned for
>>>>>>> platform-thread pools, partially pooling virtual threads seems to have no
>>>>>>> obvious downside and can restore ThreadLocal cache effectiveness used by
>>>>>>> many third-party libraries.
>>>>>>> - If I?ve misunderstood JEP 444 recommendations, virtual-thread
>>>>>>> semantics, or ThreadLocal behavior, please point out what I?m missing. I?d
>>>>>>> appreciate your guidance.
>>>>>>>
>>>>>>> Best Regards.
>>>>>>> Jianbin Chen, github-id: funky-eyes
>>>>>>>
>>>>>>> Alan Bateman <alan.bateman at oracle.com> ? 2026?1?23??? 17:27???
>>>>>>>
>>>>>>>> On 23/01/2026 07:30, Jianbin Chen wrote:
>>>>>>>> > :
>>>>>>>> >
>>>>>>>> > So my question is:
>>>>>>>> >
>>>>>>>> > **In scenarios where third-party libraries heavily rely on
>>>>>>>> ThreadLocal
>>>>>>>> > for caching / buffering (and we cannot change those libraries to
>>>>>>>> use
>>>>>>>> > object pools instead), is explicitly pooling virtual threads
>>>>>>>> (using a
>>>>>>>> > ThreadPoolExecutor with virtual thread factory) considered a
>>>>>>>> > recommended / acceptable workaround?**
>>>>>>>> >
>>>>>>>> > Or are there better / more idiomatic ways to handle this kind of
>>>>>>>> > compatibility issue with legacy ThreadLocal-based libraries when
>>>>>>>> > migrating to virtual threads?
>>>>>>>> >
>>>>>>>> > I have already opened a related discussion in the Dubbo project
>>>>>>>> (since
>>>>>>>> > Dubbo is one of the libraries affected in our stack):
>>>>>>>> >
>>>>>>>> > https://github.com/apache/dubbo/issues/16042
>>>>>>>> >
>>>>>>>> > Would love to hear your thoughts ? especially from people who
>>>>>>>> have
>>>>>>>> > experience running large-scale virtual-thread-based services with
>>>>>>>> > mixed third-party dependencies.
>>>>>>>> >
>>>>>>>>
>>>>>>>> The guidelines that we put in JEP 444 [1] is to not pool virtual
>>>>>>>> threads
>>>>>>>> and to avoid caching costing resources in thread locals. Virtual
>>>>>>>> threads
>>>>>>>> support thread locals of course but that is not useful when some
>>>>>>>> library
>>>>>>>> is looking to share a costly resource between tasks that run on the
>>>>>>>> same
>>>>>>>> thread in a thread pool.
>>>>>>>>
>>>>>>>> I don't know anything about Aerospike but working with the
>>>>>>>> maintainers
>>>>>>>> of that library to re-work its buffer management seems like the
>>>>>>>> right
>>>>>>>> course of action here. Your mail says "byte buffers". If this is
>>>>>>>> ByteBuffer it might be that they are caching direct buffers as they
>>>>>>>> are
>>>>>>>> expensive to create (and managed by the GC). Maybe they could look
>>>>>>>> at
>>>>>>>> using MemorySegment (it's easy to get a ByteBuffer view of a memory
>>>>>>>> segment) and allocate from an arena that better matches the
>>>>>>>> lifecycle.
>>>>>>>>
>>>>>>>> Hopefully others will share their experiences with migration as it
>>>>>>>> is
>>>>>>>> indeed challenging to migrate code developed for thread pools to
>>>>>>>> work
>>>>>>>> efficiently on virtual threads where there is 1-1 relationship
>>>>>>>> between
>>>>>>>> the task to execute and the thread.
>>>>>>>>
>>>>>>>> -Alan
>>>>>>>>
>>>>>>>> [1] https://openjdk.org/jeps/444#Thread-local-variables
>>>>>>>>
>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260123/83bcf417/attachment-0001.htm>

From jianbin at apache.org  Fri Jan 23 15:46:48 2026
From: jianbin at apache.org (Jianbin Chen)
Date: Fri, 23 Jan 2026 23:46:48 +0800
Subject: Performance Issues with Virtual Threads + ThreadLocal Caching in
 Third-Party Libraries (JDK 25)
In-Reply-To: <CAN+txM_jU0N+=XQ5KOSFAZSeWKsaSHczH07R=Nnc6Gk7XTPqWA@mail.gmail.com>
References: <CAAMX02rQ6tADgAQnyf5A6mtdMw8R0BkD-yJcSynO-rb10C6LwA@mail.gmail.com>
 <EB4BBE87-1FB6-4880-AF76-6BEB182E141E@ix.netcom.com>
 <CAAMX02o7ugTq-EuZO-dp_vhc0kHz2fp1q5RVNn7_N7JX7RvDYQ@mail.gmail.com>
 <CAN+txM_jU0N+=XQ5KOSFAZSeWKsaSHczH07R=Nnc6Gk7XTPqWA@mail.gmail.com>
Message-ID: <CAAMX02pK5d2RDBNuo8PA62JH=AO5YPHwTvHHt=9jakHCN2qYNA@mail.gmail.com>

Hi Peter,

Thank you, I completely agree with you about the principle of least
surprise, and I also agree that making local optimizations inside a library
can make it hard for consumers to tune performance?it's like providing a
pooled thread pool with imposed maximum virtual thread limits, which will
confuse users. So I fully accept the example you gave.

What I need to emphasize is that in the scenario I'm describing I am
actually the entry point for all requests. By that I mean the thread pool I
choose at the entry?e.g., the business thread pool that Netty hands work to
after the I/O threads, or the request-handling pool in Tomcat?is the true
starting point for processing every request. Given that entry-point
threading model, wouldn't the advantages of pooling virtual threads be even
greater, as I argued?

Best Regards.
Jianbin Chen, github-id: funky-eyes

Peter Eastham <petereastham at gmail.com> ? 2026?1?23??? 22:33???

> Hey Jianbin,
>
> A java library should leverage the expected defaults for executors. This
> would be a traditional threadpool for platform threads, or virtual thread
> per task. This follows the principle of least surprise for the library
> consumers.
> Performance Conscious libraries should allow for the Executor to be
> provided by the calling code. One example of that approach is the
> CompletableFuture API. However some sort of Configuration Object with an
> executor as a field is another approach.
>
> If you locally optimize your library like this, that'll make it harder for
> your library consumer to holistically optimize their code.
>
> Does that make sense?
> -Peter
>
> On Fri, Jan 23, 2026 at 7:10?AM Jianbin Chen <jianbin at apache.org> wrote:
>
>> I'm sorry, Robert?perhaps I didn't explain my example clearly enough.
>> Here's the code in question:
>>
>> ```java
>> Executor executor2 = new ThreadPoolExecutor(
>>     200,
>>     Integer.MAX_VALUE,
>>     0L,
>>     java.util.concurrent.TimeUnit.SECONDS,
>>     new SynchronousQueue<>(),
>>     Thread.ofVirtual().name("test-threadpool-", 1).factory()
>> );
>> ```
>>
>> In this example, the pooled virtual threads don't implement any
>> backpressure mechanism; they simply maintain a core pool of 200 virtual
>> threads. Given that the queue is a `SynchronousQueue` and the maximum pool
>> size is set to `Integer.MAX_VALUE`, once the concurrent tasks exceed 200,
>> its behavior becomes identical to that of non-pooled virtual threads.
>>
>> From my perspective, this example demonstrates that the benefits of
>> pooling virtual threads outweigh those of creating a new virtual thread for
>> every single task. In IO-bound scenarios, the virtual threads are directly
>> reused rather than being recreated each time, and the memory footprint of
>> virtual threads is far smaller than that of platform threads (which are
>> controlled by the `-Xss` flag). Additionally, with pooled virtual threads,
>> the 8KB `byte[]` cache I mentioned earlier (stored in `ThreadLocal`) can
>> also be reused, which further reduces overall memory usage?wouldn't you
>> agree?
>>
>> Best Regards.
>> Jianbin Chen, github-id: funky-eyes
>>
>> Robert Engels <rengels at ix.netcom.com> ? 2026?1?23??? 21:52???
>>
>>> Because VT are so efficient to create, without any back pressure they
>>> will all be created and running at essentially the same time (dramatically
>>> raising the amount of memory in use) - versus with a pool of size N you
>>> will have at most N running at once. In a REAL WORLD application there are
>>> often external limiters (like number of tcp connections) that provide a
>>> limit.
>>>
>>> If your tasks are purely cpu bound you should probably be using a capped
>>> thread pool of platform threads as it makes no sense to have more threads
>>> than available cores.
>>>
>>>
>>>
>>> On Jan 23, 2026, at 7:42?AM, Jianbin Chen <jianbin at apache.org> wrote:
>>>
>>> ?
>>> The question is why I need to use a semaphore to control the number of
>>> concurrently running tasks. In my particular example, the goal is simply to
>>> keep the concurrency level the same across different thread pool
>>> implementations so I can fairly compare which one completes all the tasks
>>> faster. This isn't solely about memory consumption?purely from a
>>> **performance** perspective (e.g., total throughput or wall-clock time to
>>> finish the workload), the same number of concurrent tasks completes
>>> noticeably faster when using pooled virtual threads.
>>>
>>> My email probably didn't explain this clearly enough. In reality, I have
>>> two main questions:
>>>
>>> 1. When a third-party library uses `ThreadLocal` as a cache/pool (e.g.,
>>> to hold expensive reusable objects like connections, formatters, or
>>> parsers), is switching to a **pooled virtual thread executor** the only
>>> viable solution?assuming we cannot modify the third-party library code?
>>>
>>> 2. When running the exact same number of concurrent tasks, pooled
>>> virtual threads deliver better performance.
>>>
>>> Both questions point toward the same conclusion: for an application
>>> originally built around a traditional platform thread pool, after upgrading
>>> to JDK 21/25, moving to a **pooled virtual threads** approach is generally
>>> superior to simply using non-pooled (unbounded) virtual threads.
>>>
>>> If any part of this reasoning or conclusion is mistaken, I would really
>>> appreciate being corrected ? thank you very much in advance for any
>>> feedback or different experiences you can share!
>>>
>>> Best Regards.
>>> Jianbin Chen, github-id: funky-eyes
>>>
>>> robert engels <robaho at me.com> ? 2026?1?23??? 20:58???
>>>
>>>> Exactly, this is your problem. The total number of tasks will all be
>>>> running at once in the thread per task model.
>>>>
>>>> On Jan 23, 2026, at 6:49?AM, Jianbin Chen <jianbin at apache.org> wrote:
>>>>
>>>> ?
>>>> Hi Robert,
>>>>
>>>> Thanks you, but I'm a bit confused. In the example above, I only set
>>>> the core pool size to 200 virtual threads, but for the specific test case
>>>> we?re talking about, the concurrency isn?t actually being limited by the
>>>> pool size at all. Since the maximum thread count is Integer.MAX_VALUE and
>>>> it?s using a SynchronousQueue, tasks are handed off immediately and a new
>>>> thread gets created to run them right away anyway.
>>>>
>>>> Best Regards.
>>>> Jianbin Chen, github-id: funky-eyes
>>>>
>>>> robert engels <robaho at me.com> ? 2026?1?23??? 20:28???
>>>>
>>>>> Try using a semaphore to limit the maximum number of tasks in progress
>>>>> at anyone time - that is what is causing your memory spike. Think of it
>>>>> this way since VT threads are so cheap to create - you are essentially
>>>>> creating them all at once - making the working set size equally to the
>>>>> maximum.  So you have N * WSS, where as in the other you have POOLSIZE *
>>>>> WSS.
>>>>>
>>>>> On Jan 23, 2026, at 4:14?AM, Jianbin Chen <jianbin at apache.org> wrote:
>>>>>
>>>>> ?
>>>>> Hi Alan,
>>>>>
>>>>> Thanks for your reply and for mentioning JEP 444.
>>>>> I?ve gone through the guidance in JEP 444 and have some understanding
>>>>> of it ? which is exactly why I?m feeling a bit puzzled in practice and
>>>>> would really like to hear your thoughts.
>>>>>
>>>>> Background ? ThreadLocal example (Aerospike)
>>>>> ```java
>>>>> private static final ThreadLocal<byte[]> BufferThreadLocal = new
>>>>> ThreadLocal<byte[]>() {
>>>>>     @Override
>>>>>     protected byte[] initialValue() {
>>>>>         return new byte[DefaultBufferSize];
>>>>>     }
>>>>> };
>>>>> ```
>>>>> This Aerospike code allocates a default 8KB byte[] whenever a new
>>>>> thread is created and stores it in a ThreadLocal for per-thread caching.
>>>>>
>>>>> My concern
>>>>> - With a traditional platform-thread pool, those ThreadLocal byte[]
>>>>> instances are effectively reused because threads are long-lived and pooled.
>>>>> - If we switch to creating a brand-new virtual thread per task (no
>>>>> pooling), each virtual thread gets its own fresh ThreadLocal byte[], which
>>>>> leads to many short-lived 8KB allocations.
>>>>> - That raises allocation rate and GC pressure (despite collectors like
>>>>> ZGC), because ThreadLocal caches aren?t reused when threads are ephemeral.
>>>>>
>>>>> So my question is: for applications originally designed around
>>>>> platform-thread pools, wouldn?t partially pooling virtual threads be
>>>>> beneficial? For example, Tomcat?s default max threads is 200 ? if I keep a
>>>>> pool of 200 virtual threads, then when load exceeds that core size, a
>>>>> SynchronousQueue will naturally cause new virtual threads to be created on
>>>>> demand. This seems to preserve the behavior that ThreadLocal-based
>>>>> libraries expect, without losing the ability to expand under spikes. Since
>>>>> virtual threads are very lightweight, pooling a reasonable number (e.g.,
>>>>> 200) seems to have negligible memory downside while retaining ThreadLocal
>>>>> cache effectiveness.
>>>>>
>>>>> Empirical test I ran
>>>>> (I ran a microbenchmark comparing an unpooled per-task virtual-thread
>>>>> executor and a ThreadPoolExecutor that keeps 200 core virtual threads.)
>>>>>
>>>>> ```java
>>>>> public static void main(String[] args) throws InterruptedException {
>>>>>     Executor executor =
>>>>> Executors.newThreadPerTaskExecutor(Thread.ofVirtual().name("test-",
>>>>> 1).factory());
>>>>>     Executor executor2 = new ThreadPoolExecutor(
>>>>>         200,
>>>>>         Integer.MAX_VALUE,
>>>>>         0L,
>>>>>         java.util.concurrent.TimeUnit.SECONDS,
>>>>>         new SynchronousQueue<>(),
>>>>>         Thread.ofVirtual().name("test-threadpool-", 1).factory()
>>>>>     );
>>>>>
>>>>>     // Warm-up
>>>>>     for (int i = 0; i < 10100; i++) {
>>>>>         executor.execute(() -> {
>>>>>             // simulate I/O wait
>>>>>             try { Thread.sleep(100); } catch (InterruptedException e)
>>>>> { throw new RuntimeException(e); }
>>>>>         });
>>>>>         executor2.execute(() -> {
>>>>>             // simulate I/O wait
>>>>>             try { Thread.sleep(100); } catch (InterruptedException e)
>>>>> { throw new RuntimeException(e); }
>>>>>         });
>>>>>     }
>>>>>
>>>>>     // Ensure JIT + warm-up complete
>>>>>     Thread.sleep(5000);
>>>>>
>>>>>     long start = System.currentTimeMillis();
>>>>>     CountDownLatch countDownLatch = new CountDownLatch(50000);
>>>>>     for (int i = 0; i < 50000; i++) {
>>>>>         executor.execute(() -> {
>>>>>             try { Thread.sleep(100); countDownLatch.countDown(); }
>>>>> catch (InterruptedException e) { throw new RuntimeException(e); }
>>>>>         });
>>>>>     }
>>>>>     countDownLatch.await();
>>>>>     System.out.println("thread time: " + (System.currentTimeMillis() -
>>>>> start) + " ms");
>>>>>
>>>>>     start = System.currentTimeMillis();
>>>>>     CountDownLatch countDownLatch2 = new CountDownLatch(50000);
>>>>>     for (int i = 0; i < 50000; i++) {
>>>>>         executor2.execute(() -> {
>>>>>             try { Thread.sleep(100); countDownLatch2.countDown(); }
>>>>> catch (InterruptedException e) { throw new RuntimeException(e); }
>>>>>         });
>>>>>     }
>>>>>     countDownLatch.await();
>>>>>     System.out.println("thread pool time: " +
>>>>> (System.currentTimeMillis() - start) + " ms");
>>>>> }
>>>>> ```
>>>>>
>>>>> Result summary
>>>>> - In my runs, the pooled virtual-thread executor (executor2) performed
>>>>> better than the unpooled per-task virtual-thread executor.
>>>>> - Even when I increased load by 10x or 100x, the pooled virtual-thread
>>>>> executor still showed better performance.
>>>>> - In realistic workloads, it seems pooling some virtual threads
>>>>> reduces allocation/GC overhead and improves throughput compared to strictly
>>>>> unpooled virtual threads.
>>>>>
>>>>> Final thought / request for feedback
>>>>> - From my perspective, for systems originally tuned for
>>>>> platform-thread pools, partially pooling virtual threads seems to have no
>>>>> obvious downside and can restore ThreadLocal cache effectiveness used by
>>>>> many third-party libraries.
>>>>> - If I?ve misunderstood JEP 444 recommendations, virtual-thread
>>>>> semantics, or ThreadLocal behavior, please point out what I?m missing. I?d
>>>>> appreciate your guidance.
>>>>>
>>>>> Best Regards.
>>>>> Jianbin Chen, github-id: funky-eyes
>>>>>
>>>>> Alan Bateman <alan.bateman at oracle.com> ? 2026?1?23??? 17:27???
>>>>>
>>>>>> On 23/01/2026 07:30, Jianbin Chen wrote:
>>>>>> > :
>>>>>> >
>>>>>> > So my question is:
>>>>>> >
>>>>>> > **In scenarios where third-party libraries heavily rely on
>>>>>> ThreadLocal
>>>>>> > for caching / buffering (and we cannot change those libraries to
>>>>>> use
>>>>>> > object pools instead), is explicitly pooling virtual threads (using
>>>>>> a
>>>>>> > ThreadPoolExecutor with virtual thread factory) considered a
>>>>>> > recommended / acceptable workaround?**
>>>>>> >
>>>>>> > Or are there better / more idiomatic ways to handle this kind of
>>>>>> > compatibility issue with legacy ThreadLocal-based libraries when
>>>>>> > migrating to virtual threads?
>>>>>> >
>>>>>> > I have already opened a related discussion in the Dubbo project
>>>>>> (since
>>>>>> > Dubbo is one of the libraries affected in our stack):
>>>>>> >
>>>>>> > https://github.com/apache/dubbo/issues/16042
>>>>>> >
>>>>>> > Would love to hear your thoughts ? especially from people who have
>>>>>> > experience running large-scale virtual-thread-based services with
>>>>>> > mixed third-party dependencies.
>>>>>> >
>>>>>>
>>>>>> The guidelines that we put in JEP 444 [1] is to not pool virtual
>>>>>> threads
>>>>>> and to avoid caching costing resources in thread locals. Virtual
>>>>>> threads
>>>>>> support thread locals of course but that is not useful when some
>>>>>> library
>>>>>> is looking to share a costly resource between tasks that run on the
>>>>>> same
>>>>>> thread in a thread pool.
>>>>>>
>>>>>> I don't know anything about Aerospike but working with the
>>>>>> maintainers
>>>>>> of that library to re-work its buffer management seems like the right
>>>>>> course of action here. Your mail says "byte buffers". If this is
>>>>>> ByteBuffer it might be that they are caching direct buffers as they
>>>>>> are
>>>>>> expensive to create (and managed by the GC). Maybe they could look at
>>>>>> using MemorySegment (it's easy to get a ByteBuffer view of a memory
>>>>>> segment) and allocate from an arena that better matches the lifecycle.
>>>>>>
>>>>>> Hopefully others will share their experiences with migration as it is
>>>>>> indeed challenging to migrate code developed for thread pools to work
>>>>>> efficiently on virtual threads where there is 1-1 relationship
>>>>>> between
>>>>>> the task to execute and the thread.
>>>>>>
>>>>>> -Alan
>>>>>>
>>>>>> [1] https://openjdk.org/jeps/444#Thread-local-variables
>>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260123/401beffa/attachment-0001.htm>

From rengels at ix.netcom.com  Fri Jan 23 16:17:03 2026
From: rengels at ix.netcom.com (Robert Engels)
Date: Fri, 23 Jan 2026 10:17:03 -0600
Subject: Performance Issues with Virtual Threads + ThreadLocal Caching in
 Third-Party Libraries (JDK 25)
In-Reply-To: <CAAMX02pK5d2RDBNuo8PA62JH=AO5YPHwTvHHt=9jakHCN2qYNA@mail.gmail.com>
References: <CAAMX02pK5d2RDBNuo8PA62JH=AO5YPHwTvHHt=9jakHCN2qYNA@mail.gmail.com>
Message-ID: <E86411BB-3F6F-4CEA-ADC8-222E713E8058@ix.netcom.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260123/d8181470/attachment-0001.htm>

From petereastham at gmail.com  Fri Jan 23 16:53:01 2026
From: petereastham at gmail.com (Peter Eastham)
Date: Fri, 23 Jan 2026 09:53:01 -0700
Subject: Performance Issues with Virtual Threads + ThreadLocal Caching in
 Third-Party Libraries (JDK 25)
In-Reply-To: <CAAMX02pK5d2RDBNuo8PA62JH=AO5YPHwTvHHt=9jakHCN2qYNA@mail.gmail.com>
References: <CAAMX02rQ6tADgAQnyf5A6mtdMw8R0BkD-yJcSynO-rb10C6LwA@mail.gmail.com>
 <EB4BBE87-1FB6-4880-AF76-6BEB182E141E@ix.netcom.com>
 <CAAMX02o7ugTq-EuZO-dp_vhc0kHz2fp1q5RVNn7_N7JX7RvDYQ@mail.gmail.com>
 <CAN+txM_jU0N+=XQ5KOSFAZSeWKsaSHczH07R=Nnc6Gk7XTPqWA@mail.gmail.com>
 <CAAMX02pK5d2RDBNuo8PA62JH=AO5YPHwTvHHt=9jakHCN2qYNA@mail.gmail.com>
Message-ID: <CAN+txM_ya89yop3cOsMJ8Meq+nkL2acJbfPq_kFxB5VAxc9cvA@mail.gmail.com>

Hey Jianbin,

>  What I need to emphasize is that in the scenario I'm describing I am
actually the entry point for all requests ....   thread pool that Netty
hands work to after the I/O threads, or the request-handling pool in Tomcat
While Virtual Thread pooling may be tempting in these situations, if the
performance concern is the Virtual Thread Creation Overhead, then it's
better to leverage a small buffer of Virtual Threads, and to maintain that
buffer (without pooling). Since the purpose of Virtual Threads in the Web
Server Space is to let a traditional synchronous Web Server Scale past the
cap of N platform threads, and a pool of say, 10000 virtual threads is
rather "big" from an object pooling standpoint

In the case of Netty using Virtual Threads is a bit redundant, and Netty is
specifically targeting I/O Bound applications, and we can view simple CPU
tasks as "free" in that space, for example Thread Creation.

>  Given that entry-point threading model, wouldn't the advantages of
pooling virtual threads be even greater, as I argued?
It would still be on a per-application basis. I agree that pooling virtual
threads *could* be beneficial for some applications, however it's not a
clear answer because aspects like the request throughput and the underlying
hot paths will impact the JIT. And the JIT is where the real optimizations
are.

While it may seem that request entry points are hot paths, for some
application they tend to actually be rather cold, we can showcase that with
the following,
```
public void myBusinessLogic(Request req) {
      for (int index = 0;  index < 1000;  index++)  {
           System.out.printls("Some logic for the request");
           this.someHelperFunction(req);
     }
}
```
In the fake example our Request Entry path has a 1:1000 relationship with
"myBusinessLogic". so our request entry point is very cold. With that
example in mind from the Tomcat/Netty perspective it goes back to the same
principles I shared earlier.
- They should do what the industry expects (Thread Pools for Platform,
Per-Task for Virtual Threads)
- They should expose a way to configure/provide alternatives for
applications that need it.

For applications that need to limit the local concurrency, these libraries
already offer methods of that, so I'm skipping over that.


And once again you are (very likely) correct that pooling Virtual Threads
is faster overall for some use cases, it's just that being faster doesn't
translate into a straightforward recommendation for a Platform Thread Pool
-> Virtual Thread Executor Migration.

Thanks,
-Peter

On Fri, Jan 23, 2026 at 8:48?AM Jianbin Chen <jianbin at apache.org> wrote:

> Hi Peter,
>
> Thank you, I completely agree with you about the principle of least
> surprise, and I also agree that making local optimizations inside a library
> can make it hard for consumers to tune performance?it's like providing a
> pooled thread pool with imposed maximum virtual thread limits, which will
> confuse users. So I fully accept the example you gave.
>
> What I need to emphasize is that in the scenario I'm describing I am
> actually the entry point for all requests. By that I mean the thread pool I
> choose at the entry?e.g., the business thread pool that Netty hands work to
> after the I/O threads, or the request-handling pool in Tomcat?is the true
> starting point for processing every request. Given that entry-point
> threading model, wouldn't the advantages of pooling virtual threads be even
> greater, as I argued?
>
> Best Regards.
> Jianbin Chen, github-id: funky-eyes
>
> Peter Eastham <petereastham at gmail.com> ? 2026?1?23??? 22:33???
>
>> Hey Jianbin,
>>
>> A java library should leverage the expected defaults for executors. This
>> would be a traditional threadpool for platform threads, or virtual thread
>> per task. This follows the principle of least surprise for the library
>> consumers.
>> Performance Conscious libraries should allow for the Executor to be
>> provided by the calling code. One example of that approach is the
>> CompletableFuture API. However some sort of Configuration Object with an
>> executor as a field is another approach.
>>
>> If you locally optimize your library like this, that'll make it harder
>> for your library consumer to holistically optimize their code.
>>
>> Does that make sense?
>> -Peter
>>
>> On Fri, Jan 23, 2026 at 7:10?AM Jianbin Chen <jianbin at apache.org> wrote:
>>
>>> I'm sorry, Robert?perhaps I didn't explain my example clearly enough.
>>> Here's the code in question:
>>>
>>> ```java
>>> Executor executor2 = new ThreadPoolExecutor(
>>>     200,
>>>     Integer.MAX_VALUE,
>>>     0L,
>>>     java.util.concurrent.TimeUnit.SECONDS,
>>>     new SynchronousQueue<>(),
>>>     Thread.ofVirtual().name("test-threadpool-", 1).factory()
>>> );
>>> ```
>>>
>>> In this example, the pooled virtual threads don't implement any
>>> backpressure mechanism; they simply maintain a core pool of 200 virtual
>>> threads. Given that the queue is a `SynchronousQueue` and the maximum pool
>>> size is set to `Integer.MAX_VALUE`, once the concurrent tasks exceed 200,
>>> its behavior becomes identical to that of non-pooled virtual threads.
>>>
>>> From my perspective, this example demonstrates that the benefits of
>>> pooling virtual threads outweigh those of creating a new virtual thread for
>>> every single task. In IO-bound scenarios, the virtual threads are directly
>>> reused rather than being recreated each time, and the memory footprint of
>>> virtual threads is far smaller than that of platform threads (which are
>>> controlled by the `-Xss` flag). Additionally, with pooled virtual threads,
>>> the 8KB `byte[]` cache I mentioned earlier (stored in `ThreadLocal`) can
>>> also be reused, which further reduces overall memory usage?wouldn't you
>>> agree?
>>>
>>> Best Regards.
>>> Jianbin Chen, github-id: funky-eyes
>>>
>>> Robert Engels <rengels at ix.netcom.com> ? 2026?1?23??? 21:52???
>>>
>>>> Because VT are so efficient to create, without any back pressure they
>>>> will all be created and running at essentially the same time (dramatically
>>>> raising the amount of memory in use) - versus with a pool of size N you
>>>> will have at most N running at once. In a REAL WORLD application there are
>>>> often external limiters (like number of tcp connections) that provide a
>>>> limit.
>>>>
>>>> If your tasks are purely cpu bound you should probably be using a
>>>> capped thread pool of platform threads as it makes no sense to have more
>>>> threads than available cores.
>>>>
>>>>
>>>>
>>>> On Jan 23, 2026, at 7:42?AM, Jianbin Chen <jianbin at apache.org> wrote:
>>>>
>>>> ?
>>>> The question is why I need to use a semaphore to control the number of
>>>> concurrently running tasks. In my particular example, the goal is simply to
>>>> keep the concurrency level the same across different thread pool
>>>> implementations so I can fairly compare which one completes all the tasks
>>>> faster. This isn't solely about memory consumption?purely from a
>>>> **performance** perspective (e.g., total throughput or wall-clock time to
>>>> finish the workload), the same number of concurrent tasks completes
>>>> noticeably faster when using pooled virtual threads.
>>>>
>>>> My email probably didn't explain this clearly enough. In reality, I
>>>> have two main questions:
>>>>
>>>> 1. When a third-party library uses `ThreadLocal` as a cache/pool (e.g.,
>>>> to hold expensive reusable objects like connections, formatters, or
>>>> parsers), is switching to a **pooled virtual thread executor** the only
>>>> viable solution?assuming we cannot modify the third-party library code?
>>>>
>>>> 2. When running the exact same number of concurrent tasks, pooled
>>>> virtual threads deliver better performance.
>>>>
>>>> Both questions point toward the same conclusion: for an application
>>>> originally built around a traditional platform thread pool, after upgrading
>>>> to JDK 21/25, moving to a **pooled virtual threads** approach is generally
>>>> superior to simply using non-pooled (unbounded) virtual threads.
>>>>
>>>> If any part of this reasoning or conclusion is mistaken, I would really
>>>> appreciate being corrected ? thank you very much in advance for any
>>>> feedback or different experiences you can share!
>>>>
>>>> Best Regards.
>>>> Jianbin Chen, github-id: funky-eyes
>>>>
>>>> robert engels <robaho at me.com> ? 2026?1?23??? 20:58???
>>>>
>>>>> Exactly, this is your problem. The total number of tasks will all be
>>>>> running at once in the thread per task model.
>>>>>
>>>>> On Jan 23, 2026, at 6:49?AM, Jianbin Chen <jianbin at apache.org> wrote:
>>>>>
>>>>> ?
>>>>> Hi Robert,
>>>>>
>>>>> Thanks you, but I'm a bit confused. In the example above, I only set
>>>>> the core pool size to 200 virtual threads, but for the specific test case
>>>>> we?re talking about, the concurrency isn?t actually being limited by the
>>>>> pool size at all. Since the maximum thread count is Integer.MAX_VALUE and
>>>>> it?s using a SynchronousQueue, tasks are handed off immediately and a new
>>>>> thread gets created to run them right away anyway.
>>>>>
>>>>> Best Regards.
>>>>> Jianbin Chen, github-id: funky-eyes
>>>>>
>>>>> robert engels <robaho at me.com> ? 2026?1?23??? 20:28???
>>>>>
>>>>>> Try using a semaphore to limit the maximum number of tasks in
>>>>>> progress at anyone time - that is what is causing your memory spike. Think
>>>>>> of it this way since VT threads are so cheap to create - you are
>>>>>> essentially creating them all at once - making the working set size equally
>>>>>> to the maximum.  So you have N * WSS, where as in the other you have
>>>>>> POOLSIZE * WSS.
>>>>>>
>>>>>> On Jan 23, 2026, at 4:14?AM, Jianbin Chen <jianbin at apache.org> wrote:
>>>>>>
>>>>>> ?
>>>>>> Hi Alan,
>>>>>>
>>>>>> Thanks for your reply and for mentioning JEP 444.
>>>>>> I?ve gone through the guidance in JEP 444 and have some understanding
>>>>>> of it ? which is exactly why I?m feeling a bit puzzled in practice and
>>>>>> would really like to hear your thoughts.
>>>>>>
>>>>>> Background ? ThreadLocal example (Aerospike)
>>>>>> ```java
>>>>>> private static final ThreadLocal<byte[]> BufferThreadLocal = new
>>>>>> ThreadLocal<byte[]>() {
>>>>>>     @Override
>>>>>>     protected byte[] initialValue() {
>>>>>>         return new byte[DefaultBufferSize];
>>>>>>     }
>>>>>> };
>>>>>> ```
>>>>>> This Aerospike code allocates a default 8KB byte[] whenever a new
>>>>>> thread is created and stores it in a ThreadLocal for per-thread caching.
>>>>>>
>>>>>> My concern
>>>>>> - With a traditional platform-thread pool, those ThreadLocal byte[]
>>>>>> instances are effectively reused because threads are long-lived and pooled.
>>>>>> - If we switch to creating a brand-new virtual thread per task (no
>>>>>> pooling), each virtual thread gets its own fresh ThreadLocal byte[], which
>>>>>> leads to many short-lived 8KB allocations.
>>>>>> - That raises allocation rate and GC pressure (despite collectors
>>>>>> like ZGC), because ThreadLocal caches aren?t reused when threads are
>>>>>> ephemeral.
>>>>>>
>>>>>> So my question is: for applications originally designed around
>>>>>> platform-thread pools, wouldn?t partially pooling virtual threads be
>>>>>> beneficial? For example, Tomcat?s default max threads is 200 ? if I keep a
>>>>>> pool of 200 virtual threads, then when load exceeds that core size, a
>>>>>> SynchronousQueue will naturally cause new virtual threads to be created on
>>>>>> demand. This seems to preserve the behavior that ThreadLocal-based
>>>>>> libraries expect, without losing the ability to expand under spikes. Since
>>>>>> virtual threads are very lightweight, pooling a reasonable number (e.g.,
>>>>>> 200) seems to have negligible memory downside while retaining ThreadLocal
>>>>>> cache effectiveness.
>>>>>>
>>>>>> Empirical test I ran
>>>>>> (I ran a microbenchmark comparing an unpooled per-task virtual-thread
>>>>>> executor and a ThreadPoolExecutor that keeps 200 core virtual threads.)
>>>>>>
>>>>>> ```java
>>>>>> public static void main(String[] args) throws InterruptedException {
>>>>>>     Executor executor =
>>>>>> Executors.newThreadPerTaskExecutor(Thread.ofVirtual().name("test-",
>>>>>> 1).factory());
>>>>>>     Executor executor2 = new ThreadPoolExecutor(
>>>>>>         200,
>>>>>>         Integer.MAX_VALUE,
>>>>>>         0L,
>>>>>>         java.util.concurrent.TimeUnit.SECONDS,
>>>>>>         new SynchronousQueue<>(),
>>>>>>         Thread.ofVirtual().name("test-threadpool-", 1).factory()
>>>>>>     );
>>>>>>
>>>>>>     // Warm-up
>>>>>>     for (int i = 0; i < 10100; i++) {
>>>>>>         executor.execute(() -> {
>>>>>>             // simulate I/O wait
>>>>>>             try { Thread.sleep(100); } catch (InterruptedException e)
>>>>>> { throw new RuntimeException(e); }
>>>>>>         });
>>>>>>         executor2.execute(() -> {
>>>>>>             // simulate I/O wait
>>>>>>             try { Thread.sleep(100); } catch (InterruptedException e)
>>>>>> { throw new RuntimeException(e); }
>>>>>>         });
>>>>>>     }
>>>>>>
>>>>>>     // Ensure JIT + warm-up complete
>>>>>>     Thread.sleep(5000);
>>>>>>
>>>>>>     long start = System.currentTimeMillis();
>>>>>>     CountDownLatch countDownLatch = new CountDownLatch(50000);
>>>>>>     for (int i = 0; i < 50000; i++) {
>>>>>>         executor.execute(() -> {
>>>>>>             try { Thread.sleep(100); countDownLatch.countDown(); }
>>>>>> catch (InterruptedException e) { throw new RuntimeException(e); }
>>>>>>         });
>>>>>>     }
>>>>>>     countDownLatch.await();
>>>>>>     System.out.println("thread time: " + (System.currentTimeMillis()
>>>>>> - start) + " ms");
>>>>>>
>>>>>>     start = System.currentTimeMillis();
>>>>>>     CountDownLatch countDownLatch2 = new CountDownLatch(50000);
>>>>>>     for (int i = 0; i < 50000; i++) {
>>>>>>         executor2.execute(() -> {
>>>>>>             try { Thread.sleep(100); countDownLatch2.countDown(); }
>>>>>> catch (InterruptedException e) { throw new RuntimeException(e); }
>>>>>>         });
>>>>>>     }
>>>>>>     countDownLatch.await();
>>>>>>     System.out.println("thread pool time: " +
>>>>>> (System.currentTimeMillis() - start) + " ms");
>>>>>> }
>>>>>> ```
>>>>>>
>>>>>> Result summary
>>>>>> - In my runs, the pooled virtual-thread executor (executor2)
>>>>>> performed better than the unpooled per-task virtual-thread executor.
>>>>>> - Even when I increased load by 10x or 100x, the pooled
>>>>>> virtual-thread executor still showed better performance.
>>>>>> - In realistic workloads, it seems pooling some virtual threads
>>>>>> reduces allocation/GC overhead and improves throughput compared to strictly
>>>>>> unpooled virtual threads.
>>>>>>
>>>>>> Final thought / request for feedback
>>>>>> - From my perspective, for systems originally tuned for
>>>>>> platform-thread pools, partially pooling virtual threads seems to have no
>>>>>> obvious downside and can restore ThreadLocal cache effectiveness used by
>>>>>> many third-party libraries.
>>>>>> - If I?ve misunderstood JEP 444 recommendations, virtual-thread
>>>>>> semantics, or ThreadLocal behavior, please point out what I?m missing. I?d
>>>>>> appreciate your guidance.
>>>>>>
>>>>>> Best Regards.
>>>>>> Jianbin Chen, github-id: funky-eyes
>>>>>>
>>>>>> Alan Bateman <alan.bateman at oracle.com> ? 2026?1?23??? 17:27???
>>>>>>
>>>>>>> On 23/01/2026 07:30, Jianbin Chen wrote:
>>>>>>> > :
>>>>>>> >
>>>>>>> > So my question is:
>>>>>>> >
>>>>>>> > **In scenarios where third-party libraries heavily rely on
>>>>>>> ThreadLocal
>>>>>>> > for caching / buffering (and we cannot change those libraries to
>>>>>>> use
>>>>>>> > object pools instead), is explicitly pooling virtual threads
>>>>>>> (using a
>>>>>>> > ThreadPoolExecutor with virtual thread factory) considered a
>>>>>>> > recommended / acceptable workaround?**
>>>>>>> >
>>>>>>> > Or are there better / more idiomatic ways to handle this kind of
>>>>>>> > compatibility issue with legacy ThreadLocal-based libraries when
>>>>>>> > migrating to virtual threads?
>>>>>>> >
>>>>>>> > I have already opened a related discussion in the Dubbo project
>>>>>>> (since
>>>>>>> > Dubbo is one of the libraries affected in our stack):
>>>>>>> >
>>>>>>> > https://github.com/apache/dubbo/issues/16042
>>>>>>> >
>>>>>>> > Would love to hear your thoughts ? especially from people who have
>>>>>>> > experience running large-scale virtual-thread-based services with
>>>>>>> > mixed third-party dependencies.
>>>>>>> >
>>>>>>>
>>>>>>> The guidelines that we put in JEP 444 [1] is to not pool virtual
>>>>>>> threads
>>>>>>> and to avoid caching costing resources in thread locals. Virtual
>>>>>>> threads
>>>>>>> support thread locals of course but that is not useful when some
>>>>>>> library
>>>>>>> is looking to share a costly resource between tasks that run on the
>>>>>>> same
>>>>>>> thread in a thread pool.
>>>>>>>
>>>>>>> I don't know anything about Aerospike but working with the
>>>>>>> maintainers
>>>>>>> of that library to re-work its buffer management seems like the
>>>>>>> right
>>>>>>> course of action here. Your mail says "byte buffers". If this is
>>>>>>> ByteBuffer it might be that they are caching direct buffers as they
>>>>>>> are
>>>>>>> expensive to create (and managed by the GC). Maybe they could look
>>>>>>> at
>>>>>>> using MemorySegment (it's easy to get a ByteBuffer view of a memory
>>>>>>> segment) and allocate from an arena that better matches the
>>>>>>> lifecycle.
>>>>>>>
>>>>>>> Hopefully others will share their experiences with migration as it
>>>>>>> is
>>>>>>> indeed challenging to migrate code developed for thread pools to
>>>>>>> work
>>>>>>> efficiently on virtual threads where there is 1-1 relationship
>>>>>>> between
>>>>>>> the task to execute and the thread.
>>>>>>>
>>>>>>> -Alan
>>>>>>>
>>>>>>> [1] https://openjdk.org/jeps/444#Thread-local-variables
>>>>>>>
>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260123/d645d5d2/attachment-0001.htm>

From jianbin at apache.org  Sat Jan 24 05:50:20 2026
From: jianbin at apache.org (Jianbin Chen)
Date: Sat, 24 Jan 2026 13:50:20 +0800
Subject: Performance Issues with Virtual Threads + ThreadLocal Caching in
 Third-Party Libraries (JDK 25)
In-Reply-To: <CAN+txM_ya89yop3cOsMJ8Meq+nkL2acJbfPq_kFxB5VAxc9cvA@mail.gmail.com>
References: <CAAMX02rQ6tADgAQnyf5A6mtdMw8R0BkD-yJcSynO-rb10C6LwA@mail.gmail.com>
 <EB4BBE87-1FB6-4880-AF76-6BEB182E141E@ix.netcom.com>
 <CAAMX02o7ugTq-EuZO-dp_vhc0kHz2fp1q5RVNn7_N7JX7RvDYQ@mail.gmail.com>
 <CAN+txM_jU0N+=XQ5KOSFAZSeWKsaSHczH07R=Nnc6Gk7XTPqWA@mail.gmail.com>
 <CAAMX02pK5d2RDBNuo8PA62JH=AO5YPHwTvHHt=9jakHCN2qYNA@mail.gmail.com>
 <CAN+txM_ya89yop3cOsMJ8Meq+nkL2acJbfPq_kFxB5VAxc9cvA@mail.gmail.com>
Message-ID: <CAAMX02pfaDVpppsk8034E1Z5Xfpiw91UvgtVy_CpPoSWFvQXhQ@mail.gmail.com>

Hi Peter,

Thanks for the detailed examples ? I basically understand your point.
Indeed, in my scenario pooling virtual threads yields more benefit than not
pooling, because my example simulates purely I/O work. Logically, it avoids
the overhead of creating virtual threads and can be utilized directly while
core threads are still idle.

So, returning to the original discussion: although JEP 444 recommends never
pooling virtual threads, in the scenarios I encounter it is actually
acceptable to break that rule, right?

In the current Java ecosystem there are many libraries using ThreadLocal,
and ThreadLocal can be used to implement resource pooling very well. Such
schemes can auto-scale pooled resources according to the number of threads,
and they don?t require complex logic for returning or releasing resources.
ThreadLocal-based cache pools bind the cache to the thread?s lifecycle.
Therefore, when third?party libraries haven?t actively adopted the
virtual-thread features in newer JDKs, pooling virtual threads brings a net
positive benefit, correct?

Also, in languages like Go that have long supported goroutines, many
libraries pool goroutines to gain higher performance (for example, gnet).

Finally, the premise ?never pool virtual threads? assumes an ecosystem
fully based on JDK 21, right? If third?party libraries and our own code are
all developed against those new features, then the
ThreadLocal-as-cache-pool situation I described would not exist.

Peter Eastham <petereastham at gmail.com> ?2026?1?24??? 00:53???

> Hey Jianbin,
>
> >  What I need to emphasize is that in the scenario I'm describing I am
> actually the entry point for all requests ....   thread pool that Netty
> hands work to after the I/O threads, or the request-handling pool in Tomcat
> While Virtual Thread pooling may be tempting in these situations, if the
> performance concern is the Virtual Thread Creation Overhead, then it's
> better to leverage a small buffer of Virtual Threads, and to maintain that
> buffer (without pooling). Since the purpose of Virtual Threads in the Web
> Server Space is to let a traditional synchronous Web Server Scale past the
> cap of N platform threads, and a pool of say, 10000 virtual threads is
> rather "big" from an object pooling standpoint
>
> In the case of Netty using Virtual Threads is a bit redundant, and Netty
> is specifically targeting I/O Bound applications, and we can view simple
> CPU tasks as "free" in that space, for example Thread Creation.
>
> >  Given that entry-point threading model, wouldn't the advantages of
> pooling virtual threads be even greater, as I argued?
> It would still be on a per-application basis. I agree that pooling virtual
> threads *could* be beneficial for some applications, however it's not a
> clear answer because aspects like the request throughput and the underlying
> hot paths will impact the JIT. And the JIT is where the real optimizations
> are.
>
> While it may seem that request entry points are hot paths, for some
> application they tend to actually be rather cold, we can showcase that with
> the following,
> ```
> public void myBusinessLogic(Request req) {
>       for (int index = 0;  index < 1000;  index++)  {
>            System.out.printls("Some logic for the request");
>            this.someHelperFunction(req);
>      }
> }
> ```
> In the fake example our Request Entry path has a 1:1000 relationship with
> "myBusinessLogic". so our request entry point is very cold. With that
> example in mind from the Tomcat/Netty perspective it goes back to the same
> principles I shared earlier.
> - They should do what the industry expects (Thread Pools for Platform,
> Per-Task for Virtual Threads)
> - They should expose a way to configure/provide alternatives for
> applications that need it.
>
> For applications that need to limit the local concurrency, these libraries
> already offer methods of that, so I'm skipping over that.
>
>
> And once again you are (very likely) correct that pooling Virtual Threads
> is faster overall for some use cases, it's just that being faster doesn't
> translate into a straightforward recommendation for a Platform Thread Pool
> -> Virtual Thread Executor Migration.
>
> Thanks,
> -Peter
>
> On Fri, Jan 23, 2026 at 8:48?AM Jianbin Chen <jianbin at apache.org> wrote:
>
>> Hi Peter,
>>
>> Thank you, I completely agree with you about the principle of least
>> surprise, and I also agree that making local optimizations inside a library
>> can make it hard for consumers to tune performance?it's like providing a
>> pooled thread pool with imposed maximum virtual thread limits, which will
>> confuse users. So I fully accept the example you gave.
>>
>> What I need to emphasize is that in the scenario I'm describing I am
>> actually the entry point for all requests. By that I mean the thread pool I
>> choose at the entry?e.g., the business thread pool that Netty hands work to
>> after the I/O threads, or the request-handling pool in Tomcat?is the true
>> starting point for processing every request. Given that entry-point
>> threading model, wouldn't the advantages of pooling virtual threads be even
>> greater, as I argued?
>>
>> Best Regards.
>> Jianbin Chen, github-id: funky-eyes
>>
>> Peter Eastham <petereastham at gmail.com> ? 2026?1?23??? 22:33???
>>
>>> Hey Jianbin,
>>>
>>> A java library should leverage the expected defaults for executors. This
>>> would be a traditional threadpool for platform threads, or virtual thread
>>> per task. This follows the principle of least surprise for the library
>>> consumers.
>>> Performance Conscious libraries should allow for the Executor to be
>>> provided by the calling code. One example of that approach is the
>>> CompletableFuture API. However some sort of Configuration Object with an
>>> executor as a field is another approach.
>>>
>>> If you locally optimize your library like this, that'll make it harder
>>> for your library consumer to holistically optimize their code.
>>>
>>> Does that make sense?
>>> -Peter
>>>
>>> On Fri, Jan 23, 2026 at 7:10?AM Jianbin Chen <jianbin at apache.org> wrote:
>>>
>>>> I'm sorry, Robert?perhaps I didn't explain my example clearly enough.
>>>> Here's the code in question:
>>>>
>>>> ```java
>>>> Executor executor2 = new ThreadPoolExecutor(
>>>>     200,
>>>>     Integer.MAX_VALUE,
>>>>     0L,
>>>>     java.util.concurrent.TimeUnit.SECONDS,
>>>>     new SynchronousQueue<>(),
>>>>     Thread.ofVirtual().name("test-threadpool-", 1).factory()
>>>> );
>>>> ```
>>>>
>>>> In this example, the pooled virtual threads don't implement any
>>>> backpressure mechanism; they simply maintain a core pool of 200 virtual
>>>> threads. Given that the queue is a `SynchronousQueue` and the maximum pool
>>>> size is set to `Integer.MAX_VALUE`, once the concurrent tasks exceed 200,
>>>> its behavior becomes identical to that of non-pooled virtual threads.
>>>>
>>>> From my perspective, this example demonstrates that the benefits of
>>>> pooling virtual threads outweigh those of creating a new virtual thread for
>>>> every single task. In IO-bound scenarios, the virtual threads are directly
>>>> reused rather than being recreated each time, and the memory footprint of
>>>> virtual threads is far smaller than that of platform threads (which are
>>>> controlled by the `-Xss` flag). Additionally, with pooled virtual threads,
>>>> the 8KB `byte[]` cache I mentioned earlier (stored in `ThreadLocal`) can
>>>> also be reused, which further reduces overall memory usage?wouldn't you
>>>> agree?
>>>>
>>>> Best Regards.
>>>> Jianbin Chen, github-id: funky-eyes
>>>>
>>>> Robert Engels <rengels at ix.netcom.com> ? 2026?1?23??? 21:52???
>>>>
>>>>> Because VT are so efficient to create, without any back pressure they
>>>>> will all be created and running at essentially the same time (dramatically
>>>>> raising the amount of memory in use) - versus with a pool of size N you
>>>>> will have at most N running at once. In a REAL WORLD application there are
>>>>> often external limiters (like number of tcp connections) that provide a
>>>>> limit.
>>>>>
>>>>> If your tasks are purely cpu bound you should probably be using a
>>>>> capped thread pool of platform threads as it makes no sense to have more
>>>>> threads than available cores.
>>>>>
>>>>>
>>>>>
>>>>> On Jan 23, 2026, at 7:42?AM, Jianbin Chen <jianbin at apache.org> wrote:
>>>>>
>>>>> ?
>>>>> The question is why I need to use a semaphore to control the number of
>>>>> concurrently running tasks. In my particular example, the goal is simply to
>>>>> keep the concurrency level the same across different thread pool
>>>>> implementations so I can fairly compare which one completes all the tasks
>>>>> faster. This isn't solely about memory consumption?purely from a
>>>>> **performance** perspective (e.g., total throughput or wall-clock time to
>>>>> finish the workload), the same number of concurrent tasks completes
>>>>> noticeably faster when using pooled virtual threads.
>>>>>
>>>>> My email probably didn't explain this clearly enough. In reality, I
>>>>> have two main questions:
>>>>>
>>>>> 1. When a third-party library uses `ThreadLocal` as a cache/pool
>>>>> (e.g., to hold expensive reusable objects like connections, formatters, or
>>>>> parsers), is switching to a **pooled virtual thread executor** the only
>>>>> viable solution?assuming we cannot modify the third-party library code?
>>>>>
>>>>> 2. When running the exact same number of concurrent tasks, pooled
>>>>> virtual threads deliver better performance.
>>>>>
>>>>> Both questions point toward the same conclusion: for an application
>>>>> originally built around a traditional platform thread pool, after upgrading
>>>>> to JDK 21/25, moving to a **pooled virtual threads** approach is generally
>>>>> superior to simply using non-pooled (unbounded) virtual threads.
>>>>>
>>>>> If any part of this reasoning or conclusion is mistaken, I would
>>>>> really appreciate being corrected ? thank you very much in advance for any
>>>>> feedback or different experiences you can share!
>>>>>
>>>>> Best Regards.
>>>>> Jianbin Chen, github-id: funky-eyes
>>>>>
>>>>> robert engels <robaho at me.com> ? 2026?1?23??? 20:58???
>>>>>
>>>>>> Exactly, this is your problem. The total number of tasks will all be
>>>>>> running at once in the thread per task model.
>>>>>>
>>>>>> On Jan 23, 2026, at 6:49?AM, Jianbin Chen <jianbin at apache.org> wrote:
>>>>>>
>>>>>> ?
>>>>>> Hi Robert,
>>>>>>
>>>>>> Thanks you, but I'm a bit confused. In the example above, I only set
>>>>>> the core pool size to 200 virtual threads, but for the specific test case
>>>>>> we?re talking about, the concurrency isn?t actually being limited by the
>>>>>> pool size at all. Since the maximum thread count is Integer.MAX_VALUE and
>>>>>> it?s using a SynchronousQueue, tasks are handed off immediately and a new
>>>>>> thread gets created to run them right away anyway.
>>>>>>
>>>>>> Best Regards.
>>>>>> Jianbin Chen, github-id: funky-eyes
>>>>>>
>>>>>> robert engels <robaho at me.com> ? 2026?1?23??? 20:28???
>>>>>>
>>>>>>> Try using a semaphore to limit the maximum number of tasks in
>>>>>>> progress at anyone time - that is what is causing your memory spike. Think
>>>>>>> of it this way since VT threads are so cheap to create - you are
>>>>>>> essentially creating them all at once - making the working set size equally
>>>>>>> to the maximum.  So you have N * WSS, where as in the other you have
>>>>>>> POOLSIZE * WSS.
>>>>>>>
>>>>>>> On Jan 23, 2026, at 4:14?AM, Jianbin Chen <jianbin at apache.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>> ?
>>>>>>> Hi Alan,
>>>>>>>
>>>>>>> Thanks for your reply and for mentioning JEP 444.
>>>>>>> I?ve gone through the guidance in JEP 444 and have some
>>>>>>> understanding of it ? which is exactly why I?m feeling a bit puzzled in
>>>>>>> practice and would really like to hear your thoughts.
>>>>>>>
>>>>>>> Background ? ThreadLocal example (Aerospike)
>>>>>>> ```java
>>>>>>> private static final ThreadLocal<byte[]> BufferThreadLocal = new
>>>>>>> ThreadLocal<byte[]>() {
>>>>>>>     @Override
>>>>>>>     protected byte[] initialValue() {
>>>>>>>         return new byte[DefaultBufferSize];
>>>>>>>     }
>>>>>>> };
>>>>>>> ```
>>>>>>> This Aerospike code allocates a default 8KB byte[] whenever a new
>>>>>>> thread is created and stores it in a ThreadLocal for per-thread caching.
>>>>>>>
>>>>>>> My concern
>>>>>>> - With a traditional platform-thread pool, those ThreadLocal byte[]
>>>>>>> instances are effectively reused because threads are long-lived and pooled.
>>>>>>> - If we switch to creating a brand-new virtual thread per task (no
>>>>>>> pooling), each virtual thread gets its own fresh ThreadLocal byte[], which
>>>>>>> leads to many short-lived 8KB allocations.
>>>>>>> - That raises allocation rate and GC pressure (despite collectors
>>>>>>> like ZGC), because ThreadLocal caches aren?t reused when threads are
>>>>>>> ephemeral.
>>>>>>>
>>>>>>> So my question is: for applications originally designed around
>>>>>>> platform-thread pools, wouldn?t partially pooling virtual threads be
>>>>>>> beneficial? For example, Tomcat?s default max threads is 200 ? if I keep a
>>>>>>> pool of 200 virtual threads, then when load exceeds that core size, a
>>>>>>> SynchronousQueue will naturally cause new virtual threads to be created on
>>>>>>> demand. This seems to preserve the behavior that ThreadLocal-based
>>>>>>> libraries expect, without losing the ability to expand under spikes. Since
>>>>>>> virtual threads are very lightweight, pooling a reasonable number (e.g.,
>>>>>>> 200) seems to have negligible memory downside while retaining ThreadLocal
>>>>>>> cache effectiveness.
>>>>>>>
>>>>>>> Empirical test I ran
>>>>>>> (I ran a microbenchmark comparing an unpooled per-task
>>>>>>> virtual-thread executor and a ThreadPoolExecutor that keeps 200 core
>>>>>>> virtual threads.)
>>>>>>>
>>>>>>> ```java
>>>>>>> public static void main(String[] args) throws InterruptedException {
>>>>>>>     Executor executor =
>>>>>>> Executors.newThreadPerTaskExecutor(Thread.ofVirtual().name("test-",
>>>>>>> 1).factory());
>>>>>>>     Executor executor2 = new ThreadPoolExecutor(
>>>>>>>         200,
>>>>>>>         Integer.MAX_VALUE,
>>>>>>>         0L,
>>>>>>>         java.util.concurrent.TimeUnit.SECONDS,
>>>>>>>         new SynchronousQueue<>(),
>>>>>>>         Thread.ofVirtual().name("test-threadpool-", 1).factory()
>>>>>>>     );
>>>>>>>
>>>>>>>     // Warm-up
>>>>>>>     for (int i = 0; i < 10100; i++) {
>>>>>>>         executor.execute(() -> {
>>>>>>>             // simulate I/O wait
>>>>>>>             try { Thread.sleep(100); } catch (InterruptedException
>>>>>>> e) { throw new RuntimeException(e); }
>>>>>>>         });
>>>>>>>         executor2.execute(() -> {
>>>>>>>             // simulate I/O wait
>>>>>>>             try { Thread.sleep(100); } catch (InterruptedException
>>>>>>> e) { throw new RuntimeException(e); }
>>>>>>>         });
>>>>>>>     }
>>>>>>>
>>>>>>>     // Ensure JIT + warm-up complete
>>>>>>>     Thread.sleep(5000);
>>>>>>>
>>>>>>>     long start = System.currentTimeMillis();
>>>>>>>     CountDownLatch countDownLatch = new CountDownLatch(50000);
>>>>>>>     for (int i = 0; i < 50000; i++) {
>>>>>>>         executor.execute(() -> {
>>>>>>>             try { Thread.sleep(100); countDownLatch.countDown(); }
>>>>>>> catch (InterruptedException e) { throw new RuntimeException(e); }
>>>>>>>         });
>>>>>>>     }
>>>>>>>     countDownLatch.await();
>>>>>>>     System.out.println("thread time: " + (System.currentTimeMillis()
>>>>>>> - start) + " ms");
>>>>>>>
>>>>>>>     start = System.currentTimeMillis();
>>>>>>>     CountDownLatch countDownLatch2 = new CountDownLatch(50000);
>>>>>>>     for (int i = 0; i < 50000; i++) {
>>>>>>>         executor2.execute(() -> {
>>>>>>>             try { Thread.sleep(100); countDownLatch2.countDown(); }
>>>>>>> catch (InterruptedException e) { throw new RuntimeException(e); }
>>>>>>>         });
>>>>>>>     }
>>>>>>>     countDownLatch.await();
>>>>>>>     System.out.println("thread pool time: " +
>>>>>>> (System.currentTimeMillis() - start) + " ms");
>>>>>>> }
>>>>>>> ```
>>>>>>>
>>>>>>> Result summary
>>>>>>> - In my runs, the pooled virtual-thread executor (executor2)
>>>>>>> performed better than the unpooled per-task virtual-thread executor.
>>>>>>> - Even when I increased load by 10x or 100x, the pooled
>>>>>>> virtual-thread executor still showed better performance.
>>>>>>> - In realistic workloads, it seems pooling some virtual threads
>>>>>>> reduces allocation/GC overhead and improves throughput compared to strictly
>>>>>>> unpooled virtual threads.
>>>>>>>
>>>>>>> Final thought / request for feedback
>>>>>>> - From my perspective, for systems originally tuned for
>>>>>>> platform-thread pools, partially pooling virtual threads seems to have no
>>>>>>> obvious downside and can restore ThreadLocal cache effectiveness used by
>>>>>>> many third-party libraries.
>>>>>>> - If I?ve misunderstood JEP 444 recommendations, virtual-thread
>>>>>>> semantics, or ThreadLocal behavior, please point out what I?m missing. I?d
>>>>>>> appreciate your guidance.
>>>>>>>
>>>>>>> Best Regards.
>>>>>>> Jianbin Chen, github-id: funky-eyes
>>>>>>>
>>>>>>> Alan Bateman <alan.bateman at oracle.com> ? 2026?1?23??? 17:27???
>>>>>>>
>>>>>>>> On 23/01/2026 07:30, Jianbin Chen wrote:
>>>>>>>> > :
>>>>>>>> >
>>>>>>>> > So my question is:
>>>>>>>> >
>>>>>>>> > **In scenarios where third-party libraries heavily rely on
>>>>>>>> ThreadLocal
>>>>>>>> > for caching / buffering (and we cannot change those libraries to
>>>>>>>> use
>>>>>>>> > object pools instead), is explicitly pooling virtual threads
>>>>>>>> (using a
>>>>>>>> > ThreadPoolExecutor with virtual thread factory) considered a
>>>>>>>> > recommended / acceptable workaround?**
>>>>>>>> >
>>>>>>>> > Or are there better / more idiomatic ways to handle this kind of
>>>>>>>> > compatibility issue with legacy ThreadLocal-based libraries when
>>>>>>>> > migrating to virtual threads?
>>>>>>>> >
>>>>>>>> > I have already opened a related discussion in the Dubbo project
>>>>>>>> (since
>>>>>>>> > Dubbo is one of the libraries affected in our stack):
>>>>>>>> >
>>>>>>>> > https://github.com/apache/dubbo/issues/16042
>>>>>>>> >
>>>>>>>> > Would love to hear your thoughts ? especially from people who
>>>>>>>> have
>>>>>>>> > experience running large-scale virtual-thread-based services with
>>>>>>>> > mixed third-party dependencies.
>>>>>>>> >
>>>>>>>>
>>>>>>>> The guidelines that we put in JEP 444 [1] is to not pool virtual
>>>>>>>> threads
>>>>>>>> and to avoid caching costing resources in thread locals. Virtual
>>>>>>>> threads
>>>>>>>> support thread locals of course but that is not useful when some
>>>>>>>> library
>>>>>>>> is looking to share a costly resource between tasks that run on the
>>>>>>>> same
>>>>>>>> thread in a thread pool.
>>>>>>>>
>>>>>>>> I don't know anything about Aerospike but working with the
>>>>>>>> maintainers
>>>>>>>> of that library to re-work its buffer management seems like the
>>>>>>>> right
>>>>>>>> course of action here. Your mail says "byte buffers". If this is
>>>>>>>> ByteBuffer it might be that they are caching direct buffers as they
>>>>>>>> are
>>>>>>>> expensive to create (and managed by the GC). Maybe they could look
>>>>>>>> at
>>>>>>>> using MemorySegment (it's easy to get a ByteBuffer view of a memory
>>>>>>>> segment) and allocate from an arena that better matches the
>>>>>>>> lifecycle.
>>>>>>>>
>>>>>>>> Hopefully others will share their experiences with migration as it
>>>>>>>> is
>>>>>>>> indeed challenging to migrate code developed for thread pools to
>>>>>>>> work
>>>>>>>> efficiently on virtual threads where there is 1-1 relationship
>>>>>>>> between
>>>>>>>> the task to execute and the thread.
>>>>>>>>
>>>>>>>> -Alan
>>>>>>>>
>>>>>>>> [1] https://openjdk.org/jeps/444#Thread-local-variables
>>>>>>>>
>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260124/50841b24/attachment-0001.htm>

From jianbin at apache.org  Sat Jan 24 05:55:39 2026
From: jianbin at apache.org (Jianbin Chen)
Date: Sat, 24 Jan 2026 13:55:39 +0800
Subject: Performance Issues with Virtual Threads + ThreadLocal Caching in
 Third-Party Libraries (JDK 25)
In-Reply-To: <CAKxGtTUTUyrodMUc2RTqNv7VQj9sn7No2QPy63ZCX51_cquy3w@mail.gmail.com>
References: <CAAMX02o7ugTq-EuZO-dp_vhc0kHz2fp1q5RVNn7_N7JX7RvDYQ@mail.gmail.com>
 <40EFCACE-5F3F-4AF6-B8CA-9F8EEAFCD1FD@ix.netcom.com>
 <CAAMX02oGPtkTfr02Lmd8RtXsupP92zAEm8E3VwMqjKqosZooqA@mail.gmail.com>
 <CAKxGtTXdvHqOVhV3PHtz5+ZiaRB8dFD2YtGQO0uH1W36gyMwOg@mail.gmail.com>
 <CAAMX02qfZjQL6Fowpu-25D-9_F5zifXMAMP=HWbtQwUsqv3+VQ@mail.gmail.com>
 <CAKxGtTUTUyrodMUc2RTqNv7VQj9sn7No2QPy63ZCX51_cquy3w@mail.gmail.com>
Message-ID: <CAAMX02pssPDdJ2B3Hy6DSsKEYqTPhPfVJqj6Muj3RAbJy=piqA@mail.gmail.com>

Hi Francesco,

I modified my example as follows:

```java
public static void main(String[] args) throws InterruptedException {
    Executor executor = Executors.newVirtualThreadPerTaskExecutor();
    Executor executor2 = new ThreadPoolExecutor(200, Integer.MAX_VALUE, 0L,
java.util.concurrent.TimeUnit.SECONDS,
        new SynchronousQueue<>(), Thread.ofVirtual().factory());
    for (int i = 0; i < 10100; i++) {
        executor.execute(() -> {
            try {
                Thread.sleep(100);
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
        });
        executor2.execute(() -> {
            try {
                Thread.sleep(100);
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
        });
    }
    Thread.sleep(5000);
    long start = System.currentTimeMillis();
    CountDownLatch countDownLatch = new CountDownLatch(5000000);
    for (int i = 0; i < 5000000; i++) {
        executor.execute(() -> {
            try {
                Thread.sleep(100);
                countDownLatch.countDown();
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
        });
    }
    countDownLatch.await();
    System.out.println("thread time: " + (System.currentTimeMillis() -
start) + " ms");
    start = System.currentTimeMillis();
    CountDownLatch countDownLatch2 = new CountDownLatch(5000000);
    for (int i = 0; i < 5000000; i++) {
        executor2.execute(() -> {
            try {
                Thread.sleep(100);
                countDownLatch2.countDown();
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
        });
    }
    countDownLatch.await();
    System.out.println("thread pool time: " + (System.currentTimeMillis() -
start) + " ms");
}
```

I constructed the Executor directly with
Executors.newVirtualThreadPerTaskExecutor();
however, the run results still show that the pooled virtual?thread behavior
outperforms the non?pooled virtual threads.


Francesco Nigro <nigro.fra at gmail.com> ?2026?1?23??? 23:39???

> I would say, yes:
>
> https://github.com/openjdk/jdk21/blob/890adb6410dab4606a4f26a942aed02fb2f55387/src/java.base/share/classes/java/lang/ThreadBuilders.java#L317
> unless the fix will be backported - surely @Andrew Haley
> <aph-open at littlepinkcloud.com> or @Alan Bateman <alan.bateman at oracle.com>
>  knows
>
> Il giorno ven 23 gen 2026 alle ore 16:32 Jianbin Chen <jianbin at apache.org>
> ha scritto:
>
> > Hi Francesco,
> >
> > I'd like to know if there's a similar issue in JDK 21?
> >
> > Best Regards.
> > Jianbin Chen, github-id: funky-eyes
> >
> > Francesco Nigro <nigro.fra at gmail.com> ? 2026?1?23??? 23:14???
> >
> >> In the original code snippet I see named (with a counter) VThreads, so,
> >> be aware of https://bugs.openjdk.org/browse/JDK-8372410
> >>
> >> Il giorno ven 23 gen 2026 alle ore 15:52 Jianbin Chen <
> jianbin at apache.org>
> >> ha scritto:
> >>
> >>> I'm sorry ? I forgot to mention the machine I used for the load test.
> My
> >>> server is 2 cores and 4 GB RAM, and the JVM heap was set to 2880m.
> Under my
> >>> test load (about 20,000 QPS), with non?pooled virtual threads you
> generate
> >>> at least 20,000 ? 8 KB = ~156 MB of byte[] allocations per second just
> from
> >>> that 8 KB buffer; that doesn't include other object allocations. With a
> >>> 2880 MB heap this allocation rate already forces very frequent GC, and
> >>> frequent GC raises CPU usage, which in turn significantly increases
> average
> >>> response time and p99 / p999 latency.
> >>>
> >>> Pooling is usually introduced to solve performance issues ? object
> pools
> >>> and connection pools exist to quickly reuse cached resources and
> improve
> >>> performance. So pooling virtual threads also yields obvious benefits,
> >>> especially for memory?constrained, I/O?bound applications (gateways,
> >>> proxies, etc.) that are sensitive to latency.
> >>>
> >>> Best Regards.
> >>> Jianbin Chen, github-id: funky-eyes
> >>>
> >>> Robert Engels <rengels at ix.netcom.com> ? 2026?1?23??? 22:20???
> >>>
> >>>> I understand. I was trying explain how you can not use thread locals
> >>>> and maintain the performance. It?s unlikely allocating a 8k buffer is
> a
> >>>> performance bottleneck in a real program if the task is not cpu bound
> >>>> (depending on the granularity you make your tasks) - but 2M tasks
> running
> >>>> simultaneously would require 16gb of memory not including the stack.
> >>>>
> >>>> You cannot simply use the thread per task model without an
> >>>> understanding of the cpu, IO, and memory footprints of your tasks and
> then
> >>>> configure appropriately.
> >>>>
> >>>> On Jan 23, 2026, at 8:10?AM, Jianbin Chen <jianbin at apache.org> wrote:
> >>>>
> >>>> ?
> >>>> I'm sorry, Robert?perhaps I didn't explain my example clearly enough.
> >>>> Here's the code in question:
> >>>>
> >>>> ```java
> >>>> Executor executor2 = new ThreadPoolExecutor(
> >>>>     200,
> >>>>     Integer.MAX_VALUE,
> >>>>     0L,
> >>>>     java.util.concurrent.TimeUnit.SECONDS,
> >>>>     new SynchronousQueue<>(),
> >>>>     Thread.ofVirtual().name("test-threadpool-", 1).factory()
> >>>> );
> >>>> ```
> >>>>
> >>>> In this example, the pooled virtual threads don't implement any
> >>>> backpressure mechanism; they simply maintain a core pool of 200
> virtual
> >>>> threads. Given that the queue is a `SynchronousQueue` and the maximum
> pool
> >>>> size is set to `Integer.MAX_VALUE`, once the concurrent tasks exceed
> 200,
> >>>> its behavior becomes identical to that of non-pooled virtual threads.
> >>>>
> >>>> From my perspective, this example demonstrates that the benefits of
> >>>> pooling virtual threads outweigh those of creating a new virtual
> thread for
> >>>> every single task. In IO-bound scenarios, the virtual threads are
> directly
> >>>> reused rather than being recreated each time, and the memory
> footprint of
> >>>> virtual threads is far smaller than that of platform threads (which
> are
> >>>> controlled by the `-Xss` flag). Additionally, with pooled virtual
> threads,
> >>>> the 8KB `byte[]` cache I mentioned earlier (stored in `ThreadLocal`)
> can
> >>>> also be reused, which further reduces overall memory usage?wouldn't
> you
> >>>> agree?
> >>>>
> >>>> Best Regards.
> >>>> Jianbin Chen, github-id: funky-eyes
> >>>>
> >>>> Robert Engels <rengels at ix.netcom.com> ? 2026?1?23??? 21:52???
> >>>>
> >>>>> Because VT are so efficient to create, without any back pressure they
> >>>>> will all be created and running at essentially the same time
> (dramatically
> >>>>> raising the amount of memory in use) - versus with a pool of size N
> you
> >>>>> will have at most N running at once. In a REAL WORLD application
> there are
> >>>>> often external limiters (like number of tcp connections) that
> provide a
> >>>>> limit.
> >>>>>
> >>>>> If your tasks are purely cpu bound you should probably be using a
> >>>>> capped thread pool of platform threads as it makes no sense to have
> more
> >>>>> threads than available cores.
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Jan 23, 2026, at 7:42?AM, Jianbin Chen <jianbin at apache.org>
> wrote:
> >>>>>
> >>>>> ?
> >>>>> The question is why I need to use a semaphore to control the number
> of
> >>>>> concurrently running tasks. In my particular example, the goal is
> simply to
> >>>>> keep the concurrency level the same across different thread pool
> >>>>> implementations so I can fairly compare which one completes all the
> tasks
> >>>>> faster. This isn't solely about memory consumption?purely from a
> >>>>> **performance** perspective (e.g., total throughput or wall-clock
> time to
> >>>>> finish the workload), the same number of concurrent tasks completes
> >>>>> noticeably faster when using pooled virtual threads.
> >>>>>
> >>>>> My email probably didn't explain this clearly enough. In reality, I
> >>>>> have two main questions:
> >>>>>
> >>>>> 1. When a third-party library uses `ThreadLocal` as a cache/pool
> >>>>> (e.g., to hold expensive reusable objects like connections,
> formatters, or
> >>>>> parsers), is switching to a **pooled virtual thread executor** the
> only
> >>>>> viable solution?assuming we cannot modify the third-party library
> code?
> >>>>>
> >>>>> 2. When running the exact same number of concurrent tasks, pooled
> >>>>> virtual threads deliver better performance.
> >>>>>
> >>>>> Both questions point toward the same conclusion: for an application
> >>>>> originally built around a traditional platform thread pool, after
> upgrading
> >>>>> to JDK 21/25, moving to a **pooled virtual threads** approach is
> generally
> >>>>> superior to simply using non-pooled (unbounded) virtual threads.
> >>>>>
> >>>>> If any part of this reasoning or conclusion is mistaken, I would
> >>>>> really appreciate being corrected ? thank you very much in advance
> for any
> >>>>> feedback or different experiences you can share!
> >>>>>
> >>>>> Best Regards.
> >>>>> Jianbin Chen, github-id: funky-eyes
> >>>>>
> >>>>> robert engels <robaho at me.com> ? 2026?1?23??? 20:58???
> >>>>>
> >>>>>> Exactly, this is your problem. The total number of tasks will all be
> >>>>>> running at once in the thread per task model.
> >>>>>>
> >>>>>> On Jan 23, 2026, at 6:49?AM, Jianbin Chen <jianbin at apache.org>
> wrote:
> >>>>>>
> >>>>>> ?
> >>>>>> Hi Robert,
> >>>>>>
> >>>>>> Thanks you, but I'm a bit confused. In the example above, I only set
> >>>>>> the core pool size to 200 virtual threads, but for the specific
> test case
> >>>>>> we?re talking about, the concurrency isn?t actually being limited
> by the
> >>>>>> pool size at all. Since the maximum thread count is
> Integer.MAX_VALUE and
> >>>>>> it?s using a SynchronousQueue, tasks are handed off immediately and
> a new
> >>>>>> thread gets created to run them right away anyway.
> >>>>>>
> >>>>>> Best Regards.
> >>>>>> Jianbin Chen, github-id: funky-eyes
> >>>>>>
> >>>>>> robert engels <robaho at me.com> ? 2026?1?23??? 20:28???
> >>>>>>
> >>>>>>> Try using a semaphore to limit the maximum number of tasks in
> >>>>>>> progress at anyone time - that is what is causing your memory
> spike. Think
> >>>>>>> of it this way since VT threads are so cheap to create - you are
> >>>>>>> essentially creating them all at once - making the working set
> size equally
> >>>>>>> to the maximum.  So you have N * WSS, where as in the other you
> have
> >>>>>>> POOLSIZE * WSS.
> >>>>>>>
> >>>>>>> On Jan 23, 2026, at 4:14?AM, Jianbin Chen <jianbin at apache.org>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>> ?
> >>>>>>> Hi Alan,
> >>>>>>>
> >>>>>>> Thanks for your reply and for mentioning JEP 444.
> >>>>>>> I?ve gone through the guidance in JEP 444 and have some
> >>>>>>> understanding of it ? which is exactly why I?m feeling a bit
> puzzled in
> >>>>>>> practice and would really like to hear your thoughts.
> >>>>>>>
> >>>>>>> Background ? ThreadLocal example (Aerospike)
> >>>>>>> ```java
> >>>>>>> private static final ThreadLocal<byte[]> BufferThreadLocal = new
> >>>>>>> ThreadLocal<byte[]>() {
> >>>>>>>     @Override
> >>>>>>>     protected byte[] initialValue() {
> >>>>>>>         return new byte[DefaultBufferSize];
> >>>>>>>     }
> >>>>>>> };
> >>>>>>> ```
> >>>>>>> This Aerospike code allocates a default 8KB byte[] whenever a new
> >>>>>>> thread is created and stores it in a ThreadLocal for per-thread
> caching.
> >>>>>>>
> >>>>>>> My concern
> >>>>>>> - With a traditional platform-thread pool, those ThreadLocal byte[]
> >>>>>>> instances are effectively reused because threads are long-lived
> and pooled.
> >>>>>>> - If we switch to creating a brand-new virtual thread per task (no
> >>>>>>> pooling), each virtual thread gets its own fresh ThreadLocal
> byte[], which
> >>>>>>> leads to many short-lived 8KB allocations.
> >>>>>>> - That raises allocation rate and GC pressure (despite collectors
> >>>>>>> like ZGC), because ThreadLocal caches aren?t reused when threads
> are
> >>>>>>> ephemeral.
> >>>>>>>
> >>>>>>> So my question is: for applications originally designed around
> >>>>>>> platform-thread pools, wouldn?t partially pooling virtual threads
> be
> >>>>>>> beneficial? For example, Tomcat?s default max threads is 200 ? if
> I keep a
> >>>>>>> pool of 200 virtual threads, then when load exceeds that core
> size, a
> >>>>>>> SynchronousQueue will naturally cause new virtual threads to be
> created on
> >>>>>>> demand. This seems to preserve the behavior that ThreadLocal-based
> >>>>>>> libraries expect, without losing the ability to expand under
> spikes. Since
> >>>>>>> virtual threads are very lightweight, pooling a reasonable number
> (e.g.,
> >>>>>>> 200) seems to have negligible memory downside while retaining
> ThreadLocal
> >>>>>>> cache effectiveness.
> >>>>>>>
> >>>>>>> Empirical test I ran
> >>>>>>> (I ran a microbenchmark comparing an unpooled per-task
> >>>>>>> virtual-thread executor and a ThreadPoolExecutor that keeps 200
> core
> >>>>>>> virtual threads.)
> >>>>>>>
> >>>>>>> ```java
> >>>>>>> public static void main(String[] args) throws InterruptedException
> {
> >>>>>>>     Executor executor =
> >>>>>>> Executors.newThreadPerTaskExecutor(Thread.ofVirtual().name("test-",
> >>>>>>> 1).factory());
> >>>>>>>     Executor executor2 = new ThreadPoolExecutor(
> >>>>>>>         200,
> >>>>>>>         Integer.MAX_VALUE,
> >>>>>>>         0L,
> >>>>>>>         java.util.concurrent.TimeUnit.SECONDS,
> >>>>>>>         new SynchronousQueue<>(),
> >>>>>>>         Thread.ofVirtual().name("test-threadpool-", 1).factory()
> >>>>>>>     );
> >>>>>>>
> >>>>>>>     // Warm-up
> >>>>>>>     for (int i = 0; i < 10100; i++) {
> >>>>>>>         executor.execute(() -> {
> >>>>>>>             // simulate I/O wait
> >>>>>>>             try { Thread.sleep(100); } catch (InterruptedException
> >>>>>>> e) { throw new RuntimeException(e); }
> >>>>>>>         });
> >>>>>>>         executor2.execute(() -> {
> >>>>>>>             // simulate I/O wait
> >>>>>>>             try { Thread.sleep(100); } catch (InterruptedException
> >>>>>>> e) { throw new RuntimeException(e); }
> >>>>>>>         });
> >>>>>>>     }
> >>>>>>>
> >>>>>>>     // Ensure JIT + warm-up complete
> >>>>>>>     Thread.sleep(5000);
> >>>>>>>
> >>>>>>>     long start = System.currentTimeMillis();
> >>>>>>>     CountDownLatch countDownLatch = new CountDownLatch(50000);
> >>>>>>>     for (int i = 0; i < 50000; i++) {
> >>>>>>>         executor.execute(() -> {
> >>>>>>>             try { Thread.sleep(100); countDownLatch.countDown(); }
> >>>>>>> catch (InterruptedException e) { throw new RuntimeException(e); }
> >>>>>>>         });
> >>>>>>>     }
> >>>>>>>     countDownLatch.await();
> >>>>>>>     System.out.println("thread time: " +
> (System.currentTimeMillis()
> >>>>>>> - start) + " ms");
> >>>>>>>
> >>>>>>>     start = System.currentTimeMillis();
> >>>>>>>     CountDownLatch countDownLatch2 = new CountDownLatch(50000);
> >>>>>>>     for (int i = 0; i < 50000; i++) {
> >>>>>>>         executor2.execute(() -> {
> >>>>>>>             try { Thread.sleep(100); countDownLatch2.countDown(); }
> >>>>>>> catch (InterruptedException e) { throw new RuntimeException(e); }
> >>>>>>>         });
> >>>>>>>     }
> >>>>>>>     countDownLatch.await();
> >>>>>>>     System.out.println("thread pool time: " +
> >>>>>>> (System.currentTimeMillis() - start) + " ms");
> >>>>>>> }
> >>>>>>> ```
> >>>>>>>
> >>>>>>> Result summary
> >>>>>>> - In my runs, the pooled virtual-thread executor (executor2)
> >>>>>>> performed better than the unpooled per-task virtual-thread
> executor.
> >>>>>>> - Even when I increased load by 10x or 100x, the pooled
> >>>>>>> virtual-thread executor still showed better performance.
> >>>>>>> - In realistic workloads, it seems pooling some virtual threads
> >>>>>>> reduces allocation/GC overhead and improves throughput compared to
> strictly
> >>>>>>> unpooled virtual threads.
> >>>>>>>
> >>>>>>> Final thought / request for feedback
> >>>>>>> - From my perspective, for systems originally tuned for
> >>>>>>> platform-thread pools, partially pooling virtual threads seems to
> have no
> >>>>>>> obvious downside and can restore ThreadLocal cache effectiveness
> used by
> >>>>>>> many third-party libraries.
> >>>>>>> - If I?ve misunderstood JEP 444 recommendations, virtual-thread
> >>>>>>> semantics, or ThreadLocal behavior, please point out what I?m
> missing. I?d
> >>>>>>> appreciate your guidance.
> >>>>>>>
> >>>>>>> Best Regards.
> >>>>>>> Jianbin Chen, github-id: funky-eyes
> >>>>>>>
> >>>>>>> Alan Bateman <alan.bateman at oracle.com> ? 2026?1?23??? 17:27???
> >>>>>>>
> >>>>>>>> On 23/01/2026 07:30, Jianbin Chen wrote:
> >>>>>>>> > :
> >>>>>>>> >
> >>>>>>>> > So my question is:
> >>>>>>>> >
> >>>>>>>> > **In scenarios where third-party libraries heavily rely on
> >>>>>>>> ThreadLocal
> >>>>>>>> > for caching / buffering (and we cannot change those libraries to
> >>>>>>>> use
> >>>>>>>> > object pools instead), is explicitly pooling virtual threads
> >>>>>>>> (using a
> >>>>>>>> > ThreadPoolExecutor with virtual thread factory) considered a
> >>>>>>>> > recommended / acceptable workaround?**
> >>>>>>>> >
> >>>>>>>> > Or are there better / more idiomatic ways to handle this kind of
> >>>>>>>> > compatibility issue with legacy ThreadLocal-based libraries when
> >>>>>>>> > migrating to virtual threads?
> >>>>>>>> >
> >>>>>>>> > I have already opened a related discussion in the Dubbo project
> >>>>>>>> (since
> >>>>>>>> > Dubbo is one of the libraries affected in our stack):
> >>>>>>>> >
> >>>>>>>> > https://github.com/apache/dubbo/issues/16042
> >>>>>>>> >
> >>>>>>>> > Would love to hear your thoughts ? especially from people who
> >>>>>>>> have
> >>>>>>>> > experience running large-scale virtual-thread-based services
> with
> >>>>>>>> > mixed third-party dependencies.
> >>>>>>>> >
> >>>>>>>>
> >>>>>>>> The guidelines that we put in JEP 444 [1] is to not pool virtual
> >>>>>>>> threads
> >>>>>>>> and to avoid caching costing resources in thread locals. Virtual
> >>>>>>>> threads
> >>>>>>>> support thread locals of course but that is not useful when some
> >>>>>>>> library
> >>>>>>>> is looking to share a costly resource between tasks that run on
> the
> >>>>>>>> same
> >>>>>>>> thread in a thread pool.
> >>>>>>>>
> >>>>>>>> I don't know anything about Aerospike but working with the
> >>>>>>>> maintainers
> >>>>>>>> of that library to re-work its buffer management seems like the
> >>>>>>>> right
> >>>>>>>> course of action here. Your mail says "byte buffers". If this is
> >>>>>>>> ByteBuffer it might be that they are caching direct buffers as
> they
> >>>>>>>> are
> >>>>>>>> expensive to create (and managed by the GC). Maybe they could look
> >>>>>>>> at
> >>>>>>>> using MemorySegment (it's easy to get a ByteBuffer view of a
> memory
> >>>>>>>> segment) and allocate from an arena that better matches the
> >>>>>>>> lifecycle.
> >>>>>>>>
> >>>>>>>> Hopefully others will share their experiences with migration as it
> >>>>>>>> is
> >>>>>>>> indeed challenging to migrate code developed for thread pools to
> >>>>>>>> work
> >>>>>>>> efficiently on virtual threads where there is 1-1 relationship
> >>>>>>>> between
> >>>>>>>> the task to execute and the thread.
> >>>>>>>>
> >>>>>>>> -Alan
> >>>>>>>>
> >>>>>>>> [1] https://openjdk.org/jeps/444#Thread-local-variables
> >>>>>>>>
> >>>>>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260124/56ec26f8/attachment-0001.htm>

From robaho at me.com  Sat Jan 24 06:05:22 2026
From: robaho at me.com (Robert Engels)
Date: Sat, 24 Jan 2026 00:05:22 -0600
Subject: Performance Issues with Virtual Threads + ThreadLocal Caching in
 Third-Party Libraries (JDK 25)
In-Reply-To: <CAAMX02pssPDdJ2B3Hy6DSsKEYqTPhPfVJqj6Muj3RAbJy=piqA@mail.gmail.com>
References: <CAAMX02o7ugTq-EuZO-dp_vhc0kHz2fp1q5RVNn7_N7JX7RvDYQ@mail.gmail.com>
 <40EFCACE-5F3F-4AF6-B8CA-9F8EEAFCD1FD@ix.netcom.com>
 <CAAMX02oGPtkTfr02Lmd8RtXsupP92zAEm8E3VwMqjKqosZooqA@mail.gmail.com>
 <CAKxGtTXdvHqOVhV3PHtz5+ZiaRB8dFD2YtGQO0uH1W36gyMwOg@mail.gmail.com>
 <CAAMX02qfZjQL6Fowpu-25D-9_F5zifXMAMP=HWbtQwUsqv3+VQ@mail.gmail.com>
 <CAKxGtTUTUyrodMUc2RTqNv7VQj9sn7No2QPy63ZCX51_cquy3w@mail.gmail.com>
 <CAAMX02pssPDdJ2B3Hy6DSsKEYqTPhPfVJqj6Muj3RAbJy=piqA@mail.gmail.com>
Message-ID: <CCD05D30-03F0-4524-BDAA-52CAB3C80172@me.com>

No. You are incorrect. The same rules against pooling apply to Go as well. Only for VERY expensive objects should you pool - most bulk memory allocations are short lived bump allocations.

> On Jan 23, 2026, at 11:55?PM, Jianbin Chen <jianbin at apache.org> wrote:
> 
> Hi Francesco,
> 
> I modified my example as follows:
> 
> ```java
> public static void main(String[] args) throws InterruptedException {
>     Executor executor = Executors.newVirtualThreadPerTaskExecutor();
>     Executor executor2 = new ThreadPoolExecutor(200, Integer.MAX_VALUE, 0L, java.util.concurrent.TimeUnit.SECONDS,
>         new SynchronousQueue<>(), Thread.ofVirtual().factory());
>     for (int i = 0; i < 10100; i++) {
>         executor.execute(() -> {
>             try {
>                 Thread.sleep(100);
>             } catch (InterruptedException e) {
>                 throw new RuntimeException(e);
>             }
>         });
>         executor2.execute(() -> {
>             try {
>                 Thread.sleep(100);
>             } catch (InterruptedException e) {
>                 throw new RuntimeException(e);
>             }
>         });
>     }
>     Thread.sleep(5000);
>     long start = System.currentTimeMillis();
>     CountDownLatch countDownLatch = new CountDownLatch(5000000);
>     for (int i = 0; i < 5000000; i++) {
>         executor.execute(() -> {
>             try {
>                 Thread.sleep(100);
>                 countDownLatch.countDown();
>             } catch (InterruptedException e) {
>                 throw new RuntimeException(e);
>             }
>         });
>     }
>     countDownLatch.await();
>     System.out.println("thread time: " + (System.currentTimeMillis() - start) + " ms");
>     start = System.currentTimeMillis();
>     CountDownLatch countDownLatch2 = new CountDownLatch(5000000);
>     for (int i = 0; i < 5000000; i++) {
>         executor2.execute(() -> {
>             try {
>                 Thread.sleep(100);
>                 countDownLatch2.countDown();
>             } catch (InterruptedException e) {
>                 throw new RuntimeException(e);
>             }
>         });
>     }
>     countDownLatch.await();
>     System.out.println("thread pool time: " + (System.currentTimeMillis() - start) + " ms");
> }
> ```
> 
> I constructed the Executor directly with Executors.newVirtualThreadPerTaskExecutor(); 
> however, the run results still show that the pooled virtual?thread behavior outperforms the non?pooled virtual threads.
> 
> 
> Francesco Nigro <nigro.fra at gmail.com <mailto:nigro.fra at gmail.com>> ?2026?1?23??? 23:39???
>> I would say, yes:
>> https://github.com/openjdk/jdk21/blob/890adb6410dab4606a4f26a942aed02fb2f55387/src/java.base/share/classes/java/lang/ThreadBuilders.java#L317
>> unless the fix will be backported - surely @Andrew Haley
>> <aph-open at littlepinkcloud.com <mailto:aph-open at littlepinkcloud.com>> or @Alan Bateman <alan.bateman at oracle.com <mailto:alan.bateman at oracle.com>>
>>  knows
>> 
>> Il giorno ven 23 gen 2026 alle ore 16:32 Jianbin Chen <jianbin at apache.org <mailto:jianbin at apache.org>>
>> ha scritto:
>> 
>> > Hi Francesco,
>> >
>> > I'd like to know if there's a similar issue in JDK 21?
>> >
>> > Best Regards.
>> > Jianbin Chen, github-id: funky-eyes
>> >
>> > Francesco Nigro <nigro.fra at gmail.com <mailto:nigro.fra at gmail.com>> ? 2026?1?23??? 23:14???
>> >
>> >> In the original code snippet I see named (with a counter) VThreads, so,
>> >> be aware of https://bugs.openjdk.org/browse/JDK-8372410
>> >>
>> >> Il giorno ven 23 gen 2026 alle ore 15:52 Jianbin Chen <jianbin at apache.org <mailto:jianbin at apache.org>>
>> >> ha scritto:
>> >>
>> >>> I'm sorry ? I forgot to mention the machine I used for the load test. My
>> >>> server is 2 cores and 4 GB RAM, and the JVM heap was set to 2880m. Under my
>> >>> test load (about 20,000 QPS), with non?pooled virtual threads you generate
>> >>> at least 20,000 ? 8 KB = ~156 MB of byte[] allocations per second just from
>> >>> that 8 KB buffer; that doesn't include other object allocations. With a
>> >>> 2880 MB heap this allocation rate already forces very frequent GC, and
>> >>> frequent GC raises CPU usage, which in turn significantly increases average
>> >>> response time and p99 / p999 latency.
>> >>>
>> >>> Pooling is usually introduced to solve performance issues ? object pools
>> >>> and connection pools exist to quickly reuse cached resources and improve
>> >>> performance. So pooling virtual threads also yields obvious benefits,
>> >>> especially for memory?constrained, I/O?bound applications (gateways,
>> >>> proxies, etc.) that are sensitive to latency.
>> >>>
>> >>> Best Regards.
>> >>> Jianbin Chen, github-id: funky-eyes
>> >>>
>> >>> Robert Engels <rengels at ix.netcom.com <mailto:rengels at ix.netcom.com>> ? 2026?1?23??? 22:20???
>> >>>
>> >>>> I understand. I was trying explain how you can not use thread locals
>> >>>> and maintain the performance. It?s unlikely allocating a 8k buffer is a
>> >>>> performance bottleneck in a real program if the task is not cpu bound
>> >>>> (depending on the granularity you make your tasks) - but 2M tasks running
>> >>>> simultaneously would require 16gb of memory not including the stack.
>> >>>>
>> >>>> You cannot simply use the thread per task model without an
>> >>>> understanding of the cpu, IO, and memory footprints of your tasks and then
>> >>>> configure appropriately.
>> >>>>
>> >>>> On Jan 23, 2026, at 8:10?AM, Jianbin Chen <jianbin at apache.org <mailto:jianbin at apache.org>> wrote:
>> >>>>
>> >>>> ?
>> >>>> I'm sorry, Robert?perhaps I didn't explain my example clearly enough.
>> >>>> Here's the code in question:
>> >>>>
>> >>>> ```java
>> >>>> Executor executor2 = new ThreadPoolExecutor(
>> >>>>     200,
>> >>>>     Integer.MAX_VALUE,
>> >>>>     0L,
>> >>>>     java.util.concurrent.TimeUnit.SECONDS,
>> >>>>     new SynchronousQueue<>(),
>> >>>>     Thread.ofVirtual().name("test-threadpool-", 1).factory()
>> >>>> );
>> >>>> ```
>> >>>>
>> >>>> In this example, the pooled virtual threads don't implement any
>> >>>> backpressure mechanism; they simply maintain a core pool of 200 virtual
>> >>>> threads. Given that the queue is a `SynchronousQueue` and the maximum pool
>> >>>> size is set to `Integer.MAX_VALUE`, once the concurrent tasks exceed 200,
>> >>>> its behavior becomes identical to that of non-pooled virtual threads.
>> >>>>
>> >>>> From my perspective, this example demonstrates that the benefits of
>> >>>> pooling virtual threads outweigh those of creating a new virtual thread for
>> >>>> every single task. In IO-bound scenarios, the virtual threads are directly
>> >>>> reused rather than being recreated each time, and the memory footprint of
>> >>>> virtual threads is far smaller than that of platform threads (which are
>> >>>> controlled by the `-Xss` flag). Additionally, with pooled virtual threads,
>> >>>> the 8KB `byte[]` cache I mentioned earlier (stored in `ThreadLocal`) can
>> >>>> also be reused, which further reduces overall memory usage?wouldn't you
>> >>>> agree?
>> >>>>
>> >>>> Best Regards.
>> >>>> Jianbin Chen, github-id: funky-eyes
>> >>>>
>> >>>> Robert Engels <rengels at ix.netcom.com <mailto:rengels at ix.netcom.com>> ? 2026?1?23??? 21:52???
>> >>>>
>> >>>>> Because VT are so efficient to create, without any back pressure they
>> >>>>> will all be created and running at essentially the same time (dramatically
>> >>>>> raising the amount of memory in use) - versus with a pool of size N you
>> >>>>> will have at most N running at once. In a REAL WORLD application there are
>> >>>>> often external limiters (like number of tcp connections) that provide a
>> >>>>> limit.
>> >>>>>
>> >>>>> If your tasks are purely cpu bound you should probably be using a
>> >>>>> capped thread pool of platform threads as it makes no sense to have more
>> >>>>> threads than available cores.
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> On Jan 23, 2026, at 7:42?AM, Jianbin Chen <jianbin at apache.org <mailto:jianbin at apache.org>> wrote:
>> >>>>>
>> >>>>> ?
>> >>>>> The question is why I need to use a semaphore to control the number of
>> >>>>> concurrently running tasks. In my particular example, the goal is simply to
>> >>>>> keep the concurrency level the same across different thread pool
>> >>>>> implementations so I can fairly compare which one completes all the tasks
>> >>>>> faster. This isn't solely about memory consumption?purely from a
>> >>>>> **performance** perspective (e.g., total throughput or wall-clock time to
>> >>>>> finish the workload), the same number of concurrent tasks completes
>> >>>>> noticeably faster when using pooled virtual threads.
>> >>>>>
>> >>>>> My email probably didn't explain this clearly enough. In reality, I
>> >>>>> have two main questions:
>> >>>>>
>> >>>>> 1. When a third-party library uses `ThreadLocal` as a cache/pool
>> >>>>> (e.g., to hold expensive reusable objects like connections, formatters, or
>> >>>>> parsers), is switching to a **pooled virtual thread executor** the only
>> >>>>> viable solution?assuming we cannot modify the third-party library code?
>> >>>>>
>> >>>>> 2. When running the exact same number of concurrent tasks, pooled
>> >>>>> virtual threads deliver better performance.
>> >>>>>
>> >>>>> Both questions point toward the same conclusion: for an application
>> >>>>> originally built around a traditional platform thread pool, after upgrading
>> >>>>> to JDK 21/25, moving to a **pooled virtual threads** approach is generally
>> >>>>> superior to simply using non-pooled (unbounded) virtual threads.
>> >>>>>
>> >>>>> If any part of this reasoning or conclusion is mistaken, I would
>> >>>>> really appreciate being corrected ? thank you very much in advance for any
>> >>>>> feedback or different experiences you can share!
>> >>>>>
>> >>>>> Best Regards.
>> >>>>> Jianbin Chen, github-id: funky-eyes
>> >>>>>
>> >>>>> robert engels <robaho at me.com <mailto:robaho at me.com>> ? 2026?1?23??? 20:58???
>> >>>>>
>> >>>>>> Exactly, this is your problem. The total number of tasks will all be
>> >>>>>> running at once in the thread per task model.
>> >>>>>>
>> >>>>>> On Jan 23, 2026, at 6:49?AM, Jianbin Chen <jianbin at apache.org <mailto:jianbin at apache.org>> wrote:
>> >>>>>>
>> >>>>>> ?
>> >>>>>> Hi Robert,
>> >>>>>>
>> >>>>>> Thanks you, but I'm a bit confused. In the example above, I only set
>> >>>>>> the core pool size to 200 virtual threads, but for the specific test case
>> >>>>>> we?re talking about, the concurrency isn?t actually being limited by the
>> >>>>>> pool size at all. Since the maximum thread count is Integer.MAX_VALUE and
>> >>>>>> it?s using a SynchronousQueue, tasks are handed off immediately and a new
>> >>>>>> thread gets created to run them right away anyway.
>> >>>>>>
>> >>>>>> Best Regards.
>> >>>>>> Jianbin Chen, github-id: funky-eyes
>> >>>>>>
>> >>>>>> robert engels <robaho at me.com <mailto:robaho at me.com>> ? 2026?1?23??? 20:28???
>> >>>>>>
>> >>>>>>> Try using a semaphore to limit the maximum number of tasks in
>> >>>>>>> progress at anyone time - that is what is causing your memory spike. Think
>> >>>>>>> of it this way since VT threads are so cheap to create - you are
>> >>>>>>> essentially creating them all at once - making the working set size equally
>> >>>>>>> to the maximum.  So you have N * WSS, where as in the other you have
>> >>>>>>> POOLSIZE * WSS.
>> >>>>>>>
>> >>>>>>> On Jan 23, 2026, at 4:14?AM, Jianbin Chen <jianbin at apache.org <mailto:jianbin at apache.org>>
>> >>>>>>> wrote:
>> >>>>>>>
>> >>>>>>> ?
>> >>>>>>> Hi Alan,
>> >>>>>>>
>> >>>>>>> Thanks for your reply and for mentioning JEP 444.
>> >>>>>>> I?ve gone through the guidance in JEP 444 and have some
>> >>>>>>> understanding of it ? which is exactly why I?m feeling a bit puzzled in
>> >>>>>>> practice and would really like to hear your thoughts.
>> >>>>>>>
>> >>>>>>> Background ? ThreadLocal example (Aerospike)
>> >>>>>>> ```java
>> >>>>>>> private static final ThreadLocal<byte[]> BufferThreadLocal = new
>> >>>>>>> ThreadLocal<byte[]>() {
>> >>>>>>>     @Override
>> >>>>>>>     protected byte[] initialValue() {
>> >>>>>>>         return new byte[DefaultBufferSize];
>> >>>>>>>     }
>> >>>>>>> };
>> >>>>>>> ```
>> >>>>>>> This Aerospike code allocates a default 8KB byte[] whenever a new
>> >>>>>>> thread is created and stores it in a ThreadLocal for per-thread caching.
>> >>>>>>>
>> >>>>>>> My concern
>> >>>>>>> - With a traditional platform-thread pool, those ThreadLocal byte[]
>> >>>>>>> instances are effectively reused because threads are long-lived and pooled.
>> >>>>>>> - If we switch to creating a brand-new virtual thread per task (no
>> >>>>>>> pooling), each virtual thread gets its own fresh ThreadLocal byte[], which
>> >>>>>>> leads to many short-lived 8KB allocations.
>> >>>>>>> - That raises allocation rate and GC pressure (despite collectors
>> >>>>>>> like ZGC), because ThreadLocal caches aren?t reused when threads are
>> >>>>>>> ephemeral.
>> >>>>>>>
>> >>>>>>> So my question is: for applications originally designed around
>> >>>>>>> platform-thread pools, wouldn?t partially pooling virtual threads be
>> >>>>>>> beneficial? For example, Tomcat?s default max threads is 200 ? if I keep a
>> >>>>>>> pool of 200 virtual threads, then when load exceeds that core size, a
>> >>>>>>> SynchronousQueue will naturally cause new virtual threads to be created on
>> >>>>>>> demand. This seems to preserve the behavior that ThreadLocal-based
>> >>>>>>> libraries expect, without losing the ability to expand under spikes. Since
>> >>>>>>> virtual threads are very lightweight, pooling a reasonable number (e.g.,
>> >>>>>>> 200) seems to have negligible memory downside while retaining ThreadLocal
>> >>>>>>> cache effectiveness.
>> >>>>>>>
>> >>>>>>> Empirical test I ran
>> >>>>>>> (I ran a microbenchmark comparing an unpooled per-task
>> >>>>>>> virtual-thread executor and a ThreadPoolExecutor that keeps 200 core
>> >>>>>>> virtual threads.)
>> >>>>>>>
>> >>>>>>> ```java
>> >>>>>>> public static void main(String[] args) throws InterruptedException {
>> >>>>>>>     Executor executor =
>> >>>>>>> Executors.newThreadPerTaskExecutor(Thread.ofVirtual().name("test-",
>> >>>>>>> 1).factory());
>> >>>>>>>     Executor executor2 = new ThreadPoolExecutor(
>> >>>>>>>         200,
>> >>>>>>>         Integer.MAX_VALUE,
>> >>>>>>>         0L,
>> >>>>>>>         java.util.concurrent.TimeUnit.SECONDS,
>> >>>>>>>         new SynchronousQueue<>(),
>> >>>>>>>         Thread.ofVirtual().name("test-threadpool-", 1).factory()
>> >>>>>>>     );
>> >>>>>>>
>> >>>>>>>     // Warm-up
>> >>>>>>>     for (int i = 0; i < 10100; i++) {
>> >>>>>>>         executor.execute(() -> {
>> >>>>>>>             // simulate I/O wait
>> >>>>>>>             try { Thread.sleep(100); } catch (InterruptedException
>> >>>>>>> e) { throw new RuntimeException(e); }
>> >>>>>>>         });
>> >>>>>>>         executor2.execute(() -> {
>> >>>>>>>             // simulate I/O wait
>> >>>>>>>             try { Thread.sleep(100); } catch (InterruptedException
>> >>>>>>> e) { throw new RuntimeException(e); }
>> >>>>>>>         });
>> >>>>>>>     }
>> >>>>>>>
>> >>>>>>>     // Ensure JIT + warm-up complete
>> >>>>>>>     Thread.sleep(5000);
>> >>>>>>>
>> >>>>>>>     long start = System.currentTimeMillis();
>> >>>>>>>     CountDownLatch countDownLatch = new CountDownLatch(50000);
>> >>>>>>>     for (int i = 0; i < 50000; i++) {
>> >>>>>>>         executor.execute(() -> {
>> >>>>>>>             try { Thread.sleep(100); countDownLatch.countDown(); }
>> >>>>>>> catch (InterruptedException e) { throw new RuntimeException(e); }
>> >>>>>>>         });
>> >>>>>>>     }
>> >>>>>>>     countDownLatch.await();
>> >>>>>>>     System.out.println("thread time: " + (System.currentTimeMillis()
>> >>>>>>> - start) + " ms");
>> >>>>>>>
>> >>>>>>>     start = System.currentTimeMillis();
>> >>>>>>>     CountDownLatch countDownLatch2 = new CountDownLatch(50000);
>> >>>>>>>     for (int i = 0; i < 50000; i++) {
>> >>>>>>>         executor2.execute(() -> {
>> >>>>>>>             try { Thread.sleep(100); countDownLatch2.countDown(); }
>> >>>>>>> catch (InterruptedException e) { throw new RuntimeException(e); }
>> >>>>>>>         });
>> >>>>>>>     }
>> >>>>>>>     countDownLatch.await();
>> >>>>>>>     System.out.println("thread pool time: " +
>> >>>>>>> (System.currentTimeMillis() - start) + " ms");
>> >>>>>>> }
>> >>>>>>> ```
>> >>>>>>>
>> >>>>>>> Result summary
>> >>>>>>> - In my runs, the pooled virtual-thread executor (executor2)
>> >>>>>>> performed better than the unpooled per-task virtual-thread executor.
>> >>>>>>> - Even when I increased load by 10x or 100x, the pooled
>> >>>>>>> virtual-thread executor still showed better performance.
>> >>>>>>> - In realistic workloads, it seems pooling some virtual threads
>> >>>>>>> reduces allocation/GC overhead and improves throughput compared to strictly
>> >>>>>>> unpooled virtual threads.
>> >>>>>>>
>> >>>>>>> Final thought / request for feedback
>> >>>>>>> - From my perspective, for systems originally tuned for
>> >>>>>>> platform-thread pools, partially pooling virtual threads seems to have no
>> >>>>>>> obvious downside and can restore ThreadLocal cache effectiveness used by
>> >>>>>>> many third-party libraries.
>> >>>>>>> - If I?ve misunderstood JEP 444 recommendations, virtual-thread
>> >>>>>>> semantics, or ThreadLocal behavior, please point out what I?m missing. I?d
>> >>>>>>> appreciate your guidance.
>> >>>>>>>
>> >>>>>>> Best Regards.
>> >>>>>>> Jianbin Chen, github-id: funky-eyes
>> >>>>>>>
>> >>>>>>> Alan Bateman <alan.bateman at oracle.com <mailto:alan.bateman at oracle.com>> ? 2026?1?23??? 17:27???
>> >>>>>>>
>> >>>>>>>> On 23/01/2026 07:30, Jianbin Chen wrote:
>> >>>>>>>> > :
>> >>>>>>>> >
>> >>>>>>>> > So my question is:
>> >>>>>>>> >
>> >>>>>>>> > **In scenarios where third-party libraries heavily rely on
>> >>>>>>>> ThreadLocal
>> >>>>>>>> > for caching / buffering (and we cannot change those libraries to
>> >>>>>>>> use
>> >>>>>>>> > object pools instead), is explicitly pooling virtual threads
>> >>>>>>>> (using a
>> >>>>>>>> > ThreadPoolExecutor with virtual thread factory) considered a
>> >>>>>>>> > recommended / acceptable workaround?**
>> >>>>>>>> >
>> >>>>>>>> > Or are there better / more idiomatic ways to handle this kind of
>> >>>>>>>> > compatibility issue with legacy ThreadLocal-based libraries when
>> >>>>>>>> > migrating to virtual threads?
>> >>>>>>>> >
>> >>>>>>>> > I have already opened a related discussion in the Dubbo project
>> >>>>>>>> (since
>> >>>>>>>> > Dubbo is one of the libraries affected in our stack):
>> >>>>>>>> >
>> >>>>>>>> > https://github.com/apache/dubbo/issues/16042
>> >>>>>>>> >
>> >>>>>>>> > Would love to hear your thoughts ? especially from people who
>> >>>>>>>> have
>> >>>>>>>> > experience running large-scale virtual-thread-based services with
>> >>>>>>>> > mixed third-party dependencies.
>> >>>>>>>> >
>> >>>>>>>>
>> >>>>>>>> The guidelines that we put in JEP 444 [1] is to not pool virtual
>> >>>>>>>> threads
>> >>>>>>>> and to avoid caching costing resources in thread locals. Virtual
>> >>>>>>>> threads
>> >>>>>>>> support thread locals of course but that is not useful when some
>> >>>>>>>> library
>> >>>>>>>> is looking to share a costly resource between tasks that run on the
>> >>>>>>>> same
>> >>>>>>>> thread in a thread pool.
>> >>>>>>>>
>> >>>>>>>> I don't know anything about Aerospike but working with the
>> >>>>>>>> maintainers
>> >>>>>>>> of that library to re-work its buffer management seems like the
>> >>>>>>>> right
>> >>>>>>>> course of action here. Your mail says "byte buffers". If this is
>> >>>>>>>> ByteBuffer it might be that they are caching direct buffers as they
>> >>>>>>>> are
>> >>>>>>>> expensive to create (and managed by the GC). Maybe they could look
>> >>>>>>>> at
>> >>>>>>>> using MemorySegment (it's easy to get a ByteBuffer view of a memory
>> >>>>>>>> segment) and allocate from an arena that better matches the
>> >>>>>>>> lifecycle.
>> >>>>>>>>
>> >>>>>>>> Hopefully others will share their experiences with migration as it
>> >>>>>>>> is
>> >>>>>>>> indeed challenging to migrate code developed for thread pools to
>> >>>>>>>> work
>> >>>>>>>> efficiently on virtual threads where there is 1-1 relationship
>> >>>>>>>> between
>> >>>>>>>> the task to execute and the thread.
>> >>>>>>>>
>> >>>>>>>> -Alan
>> >>>>>>>>
>> >>>>>>>> [1] https://openjdk.org/jeps/444#Thread-local-variables
>> >>>>>>>>
>> >>>>>>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260124/f9a744e8/attachment-0001.htm>

From jianbin at apache.org  Sat Jan 24 06:21:30 2026
From: jianbin at apache.org (Jianbin Chen)
Date: Sat, 24 Jan 2026 14:21:30 +0800
Subject: Performance Issues with Virtual Threads + ThreadLocal Caching in
 Third-Party Libraries (JDK 25)
In-Reply-To: <E86411BB-3F6F-4CEA-ADC8-222E713E8058@ix.netcom.com>
References: <CAAMX02pK5d2RDBNuo8PA62JH=AO5YPHwTvHHt=9jakHCN2qYNA@mail.gmail.com>
 <E86411BB-3F6F-4CEA-ADC8-222E713E8058@ix.netcom.com>
Message-ID: <CAAMX02rbCHE5+mBw7H0o=FFRRa67sqVMuLxEOiNtVUxzRNPubg@mail.gmail.com>

Hi Francesco and Robert,

First, thank you both for your patient answers and replies ? I will look
into the libraries you provided and study them. But first let?s return to
the subject of this email.

When I first encountered the bottleneck with non?pooled virtual threads, it
was while designing a REST?API style proxy that translates incoming HTTP
requests into corresponding Aerospike requests (using the Aerospike
client). The relevant flow is: Netty?s I/O thread parses and constructs the
HTTP request, hands it to my business handler, and the handler constructs
the business executor using Executors.newVirtualThreadPerTaskExecutor()
(i.e., a non?pooled virtual?thread executor). That is where I discovered
the problem: my application suffered very high GC and CPU pressure because
every HTTP request allocated an 8KB byte[] that could not be reused, so the
overall behavior was sometimes worse than using platform threads.

So, I tried pooling virtual threads experimentally and found that
throughput increased noticeably. Even when concurrency exceeded my core
thread count, the use of a SynchronousQueue allowed the system to handle
traffic spikes reasonably well (although virtual threads created beyond the
core still produced unreusable 8KB byte[] allocations). Compared to a
platform thread pool, latency (RT) was smoother and CPU usage was more
stable, because when core threads were insufficient we did not pay the high
cost of creating additional platform threads that would otherwise spike CPU
and memory. In that scenario pooled virtual threads > non?pooled virtual
threads.

After that I wrote the benchmark from my earlier email, and the test still
shows pooled virtual threads outperforming non?pooled virtual threads.

So I have two questions:

1) When an application is developed against JDK 21+ and many of its
dependent third?party libraries use ThreadLocal for cachepool
implementations, is pooling virtual threads recommended (or at least
acceptable such that it breaks the JEP 444 recommendation)?

2) Why do pooled virtual threads still perform better in my examples? If
that is the case, it looks like pooling virtual threads only violates the
principle of least surprise but otherwise has no harmful effects. Moreover,
as long as the pooled virtual threads are elastically expandable rather
than fixed (for example: new ThreadPoolExecutor(200, Integer.MAX_VALUE, 0L,
TimeUnit.SECONDS, new SynchronousQueue<>(), Thread.ofVirtual().factory());
? i.e., only pooling 200 virtual threads while allowing additional threads
to grow dynamically with task demand), it seems to be all upside and no
downside.

Please correct me if any of my assumptions are wrong. Thanks.

Best regards,
Jianbin Chen

Robert Engels <rengels at ix.netcom.com> ?2026?1?24??? 00:17???

> You might want to look at https://github.com/robaho/httpserver.
> Theres some discussion on why designing systems specifically for VT is the
> way to go.
>
> Most of the high performance http servers are being rewritten specifically
> for the thread per request model since it?s far simpler, and often superior
> in performance.
>
> On Jan 23, 2026, at 9:49?AM, Jianbin Chen <jianbin at apache.org> wrote:
>
> ?
> Hi Peter,
>
> Thank you, I completely agree with you about the principle of least
> surprise, and I also agree that making local optimizations inside a library
> can make it hard for consumers to tune performance?it's like providing a
> pooled thread pool with imposed maximum virtual thread limits, which will
> confuse users. So I fully accept the example you gave.
>
> What I need to emphasize is that in the scenario I'm describing I am
> actually the entry point for all requests. By that I mean the thread pool I
> choose at the entry?e.g., the business thread pool that Netty hands work to
> after the I/O threads, or the request-handling pool in Tomcat?is the true
> starting point for processing every request. Given that entry-point
> threading model, wouldn't the advantages of pooling virtual threads be even
> greater, as I argued?
>
> Best Regards.
> Jianbin Chen, github-id: funky-eyes
>
> Peter Eastham <petereastham at gmail.com> ? 2026?1?23??? 22:33???
>
>> Hey Jianbin,
>>
>> A java library should leverage the expected defaults for executors. This
>> would be a traditional threadpool for platform threads, or virtual thread
>> per task. This follows the principle of least surprise for the library
>> consumers.
>> Performance Conscious libraries should allow for the Executor to be
>> provided by the calling code. One example of that approach is the
>> CompletableFuture API. However some sort of Configuration Object with an
>> executor as a field is another approach.
>>
>> If you locally optimize your library like this, that'll make it harder
>> for your library consumer to holistically optimize their code.
>>
>> Does that make sense?
>> -Peter
>>
>> On Fri, Jan 23, 2026 at 7:10?AM Jianbin Chen <jianbin at apache.org> wrote:
>>
>>> I'm sorry, Robert?perhaps I didn't explain my example clearly enough.
>>> Here's the code in question:
>>>
>>> ```java
>>> Executor executor2 = new ThreadPoolExecutor(
>>>     200,
>>>     Integer.MAX_VALUE,
>>>     0L,
>>>     java.util.concurrent.TimeUnit.SECONDS,
>>>     new SynchronousQueue<>(),
>>>     Thread.ofVirtual().name("test-threadpool-", 1).factory()
>>> );
>>> ```
>>>
>>> In this example, the pooled virtual threads don't implement any
>>> backpressure mechanism; they simply maintain a core pool of 200 virtual
>>> threads. Given that the queue is a `SynchronousQueue` and the maximum pool
>>> size is set to `Integer.MAX_VALUE`, once the concurrent tasks exceed 200,
>>> its behavior becomes identical to that of non-pooled virtual threads.
>>>
>>> From my perspective, this example demonstrates that the benefits of
>>> pooling virtual threads outweigh those of creating a new virtual thread for
>>> every single task. In IO-bound scenarios, the virtual threads are directly
>>> reused rather than being recreated each time, and the memory footprint of
>>> virtual threads is far smaller than that of platform threads (which are
>>> controlled by the `-Xss` flag). Additionally, with pooled virtual threads,
>>> the 8KB `byte[]` cache I mentioned earlier (stored in `ThreadLocal`) can
>>> also be reused, which further reduces overall memory usage?wouldn't you
>>> agree?
>>>
>>> Best Regards.
>>> Jianbin Chen, github-id: funky-eyes
>>>
>>> Robert Engels <rengels at ix.netcom.com> ? 2026?1?23??? 21:52???
>>>
>>>> Because VT are so efficient to create, without any back pressure they
>>>> will all be created and running at essentially the same time (dramatically
>>>> raising the amount of memory in use) - versus with a pool of size N you
>>>> will have at most N running at once. In a REAL WORLD application there are
>>>> often external limiters (like number of tcp connections) that provide a
>>>> limit.
>>>>
>>>> If your tasks are purely cpu bound you should probably be using a
>>>> capped thread pool of platform threads as it makes no sense to have more
>>>> threads than available cores.
>>>>
>>>>
>>>>
>>>> On Jan 23, 2026, at 7:42?AM, Jianbin Chen <jianbin at apache.org> wrote:
>>>>
>>>> ?
>>>> The question is why I need to use a semaphore to control the number of
>>>> concurrently running tasks. In my particular example, the goal is simply to
>>>> keep the concurrency level the same across different thread pool
>>>> implementations so I can fairly compare which one completes all the tasks
>>>> faster. This isn't solely about memory consumption?purely from a
>>>> **performance** perspective (e.g., total throughput or wall-clock time to
>>>> finish the workload), the same number of concurrent tasks completes
>>>> noticeably faster when using pooled virtual threads.
>>>>
>>>> My email probably didn't explain this clearly enough. In reality, I
>>>> have two main questions:
>>>>
>>>> 1. When a third-party library uses `ThreadLocal` as a cache/pool (e.g.,
>>>> to hold expensive reusable objects like connections, formatters, or
>>>> parsers), is switching to a **pooled virtual thread executor** the only
>>>> viable solution?assuming we cannot modify the third-party library code?
>>>>
>>>> 2. When running the exact same number of concurrent tasks, pooled
>>>> virtual threads deliver better performance.
>>>>
>>>> Both questions point toward the same conclusion: for an application
>>>> originally built around a traditional platform thread pool, after upgrading
>>>> to JDK 21/25, moving to a **pooled virtual threads** approach is generally
>>>> superior to simply using non-pooled (unbounded) virtual threads.
>>>>
>>>> If any part of this reasoning or conclusion is mistaken, I would really
>>>> appreciate being corrected ? thank you very much in advance for any
>>>> feedback or different experiences you can share!
>>>>
>>>> Best Regards.
>>>> Jianbin Chen, github-id: funky-eyes
>>>>
>>>> robert engels <robaho at me.com> ? 2026?1?23??? 20:58???
>>>>
>>>>> Exactly, this is your problem. The total number of tasks will all be
>>>>> running at once in the thread per task model.
>>>>>
>>>>> On Jan 23, 2026, at 6:49?AM, Jianbin Chen <jianbin at apache.org> wrote:
>>>>>
>>>>> ?
>>>>> Hi Robert,
>>>>>
>>>>> Thanks you, but I'm a bit confused. In the example above, I only set
>>>>> the core pool size to 200 virtual threads, but for the specific test case
>>>>> we?re talking about, the concurrency isn?t actually being limited by the
>>>>> pool size at all. Since the maximum thread count is Integer.MAX_VALUE and
>>>>> it?s using a SynchronousQueue, tasks are handed off immediately and a new
>>>>> thread gets created to run them right away anyway.
>>>>>
>>>>> Best Regards.
>>>>> Jianbin Chen, github-id: funky-eyes
>>>>>
>>>>> robert engels <robaho at me.com> ? 2026?1?23??? 20:28???
>>>>>
>>>>>> Try using a semaphore to limit the maximum number of tasks in
>>>>>> progress at anyone time - that is what is causing your memory spike. Think
>>>>>> of it this way since VT threads are so cheap to create - you are
>>>>>> essentially creating them all at once - making the working set size equally
>>>>>> to the maximum.  So you have N * WSS, where as in the other you have
>>>>>> POOLSIZE * WSS.
>>>>>>
>>>>>> On Jan 23, 2026, at 4:14?AM, Jianbin Chen <jianbin at apache.org> wrote:
>>>>>>
>>>>>> ?
>>>>>> Hi Alan,
>>>>>>
>>>>>> Thanks for your reply and for mentioning JEP 444.
>>>>>> I?ve gone through the guidance in JEP 444 and have some understanding
>>>>>> of it ? which is exactly why I?m feeling a bit puzzled in practice and
>>>>>> would really like to hear your thoughts.
>>>>>>
>>>>>> Background ? ThreadLocal example (Aerospike)
>>>>>> ```java
>>>>>> private static final ThreadLocal<byte[]> BufferThreadLocal = new
>>>>>> ThreadLocal<byte[]>() {
>>>>>>     @Override
>>>>>>     protected byte[] initialValue() {
>>>>>>         return new byte[DefaultBufferSize];
>>>>>>     }
>>>>>> };
>>>>>> ```
>>>>>> This Aerospike code allocates a default 8KB byte[] whenever a new
>>>>>> thread is created and stores it in a ThreadLocal for per-thread caching.
>>>>>>
>>>>>> My concern
>>>>>> - With a traditional platform-thread pool, those ThreadLocal byte[]
>>>>>> instances are effectively reused because threads are long-lived and pooled.
>>>>>> - If we switch to creating a brand-new virtual thread per task (no
>>>>>> pooling), each virtual thread gets its own fresh ThreadLocal byte[], which
>>>>>> leads to many short-lived 8KB allocations.
>>>>>> - That raises allocation rate and GC pressure (despite collectors
>>>>>> like ZGC), because ThreadLocal caches aren?t reused when threads are
>>>>>> ephemeral.
>>>>>>
>>>>>> So my question is: for applications originally designed around
>>>>>> platform-thread pools, wouldn?t partially pooling virtual threads be
>>>>>> beneficial? For example, Tomcat?s default max threads is 200 ? if I keep a
>>>>>> pool of 200 virtual threads, then when load exceeds that core size, a
>>>>>> SynchronousQueue will naturally cause new virtual threads to be created on
>>>>>> demand. This seems to preserve the behavior that ThreadLocal-based
>>>>>> libraries expect, without losing the ability to expand under spikes. Since
>>>>>> virtual threads are very lightweight, pooling a reasonable number (e.g.,
>>>>>> 200) seems to have negligible memory downside while retaining ThreadLocal
>>>>>> cache effectiveness.
>>>>>>
>>>>>> Empirical test I ran
>>>>>> (I ran a microbenchmark comparing an unpooled per-task virtual-thread
>>>>>> executor and a ThreadPoolExecutor that keeps 200 core virtual threads.)
>>>>>>
>>>>>> ```java
>>>>>> public static void main(String[] args) throws InterruptedException {
>>>>>>     Executor executor =
>>>>>> Executors.newThreadPerTaskExecutor(Thread.ofVirtual().name("test-",
>>>>>> 1).factory());
>>>>>>     Executor executor2 = new ThreadPoolExecutor(
>>>>>>         200,
>>>>>>         Integer.MAX_VALUE,
>>>>>>         0L,
>>>>>>         java.util.concurrent.TimeUnit.SECONDS,
>>>>>>         new SynchronousQueue<>(),
>>>>>>         Thread.ofVirtual().name("test-threadpool-", 1).factory()
>>>>>>     );
>>>>>>
>>>>>>     // Warm-up
>>>>>>     for (int i = 0; i < 10100; i++) {
>>>>>>         executor.execute(() -> {
>>>>>>             // simulate I/O wait
>>>>>>             try { Thread.sleep(100); } catch (InterruptedException e)
>>>>>> { throw new RuntimeException(e); }
>>>>>>         });
>>>>>>         executor2.execute(() -> {
>>>>>>             // simulate I/O wait
>>>>>>             try { Thread.sleep(100); } catch (InterruptedException e)
>>>>>> { throw new RuntimeException(e); }
>>>>>>         });
>>>>>>     }
>>>>>>
>>>>>>     // Ensure JIT + warm-up complete
>>>>>>     Thread.sleep(5000);
>>>>>>
>>>>>>     long start = System.currentTimeMillis();
>>>>>>     CountDownLatch countDownLatch = new CountDownLatch(50000);
>>>>>>     for (int i = 0; i < 50000; i++) {
>>>>>>         executor.execute(() -> {
>>>>>>             try { Thread.sleep(100); countDownLatch.countDown(); }
>>>>>> catch (InterruptedException e) { throw new RuntimeException(e); }
>>>>>>         });
>>>>>>     }
>>>>>>     countDownLatch.await();
>>>>>>     System.out.println("thread time: " + (System.currentTimeMillis()
>>>>>> - start) + " ms");
>>>>>>
>>>>>>     start = System.currentTimeMillis();
>>>>>>     CountDownLatch countDownLatch2 = new CountDownLatch(50000);
>>>>>>     for (int i = 0; i < 50000; i++) {
>>>>>>         executor2.execute(() -> {
>>>>>>             try { Thread.sleep(100); countDownLatch2.countDown(); }
>>>>>> catch (InterruptedException e) { throw new RuntimeException(e); }
>>>>>>         });
>>>>>>     }
>>>>>>     countDownLatch.await();
>>>>>>     System.out.println("thread pool time: " +
>>>>>> (System.currentTimeMillis() - start) + " ms");
>>>>>> }
>>>>>> ```
>>>>>>
>>>>>> Result summary
>>>>>> - In my runs, the pooled virtual-thread executor (executor2)
>>>>>> performed better than the unpooled per-task virtual-thread executor.
>>>>>> - Even when I increased load by 10x or 100x, the pooled
>>>>>> virtual-thread executor still showed better performance.
>>>>>> - In realistic workloads, it seems pooling some virtual threads
>>>>>> reduces allocation/GC overhead and improves throughput compared to strictly
>>>>>> unpooled virtual threads.
>>>>>>
>>>>>> Final thought / request for feedback
>>>>>> - From my perspective, for systems originally tuned for
>>>>>> platform-thread pools, partially pooling virtual threads seems to have no
>>>>>> obvious downside and can restore ThreadLocal cache effectiveness used by
>>>>>> many third-party libraries.
>>>>>> - If I?ve misunderstood JEP 444 recommendations, virtual-thread
>>>>>> semantics, or ThreadLocal behavior, please point out what I?m missing. I?d
>>>>>> appreciate your guidance.
>>>>>>
>>>>>> Best Regards.
>>>>>> Jianbin Chen, github-id: funky-eyes
>>>>>>
>>>>>> Alan Bateman <alan.bateman at oracle.com> ? 2026?1?23??? 17:27???
>>>>>>
>>>>>>> On 23/01/2026 07:30, Jianbin Chen wrote:
>>>>>>> > :
>>>>>>> >
>>>>>>> > So my question is:
>>>>>>> >
>>>>>>> > **In scenarios where third-party libraries heavily rely on
>>>>>>> ThreadLocal
>>>>>>> > for caching / buffering (and we cannot change those libraries to
>>>>>>> use
>>>>>>> > object pools instead), is explicitly pooling virtual threads
>>>>>>> (using a
>>>>>>> > ThreadPoolExecutor with virtual thread factory) considered a
>>>>>>> > recommended / acceptable workaround?**
>>>>>>> >
>>>>>>> > Or are there better / more idiomatic ways to handle this kind of
>>>>>>> > compatibility issue with legacy ThreadLocal-based libraries when
>>>>>>> > migrating to virtual threads?
>>>>>>> >
>>>>>>> > I have already opened a related discussion in the Dubbo project
>>>>>>> (since
>>>>>>> > Dubbo is one of the libraries affected in our stack):
>>>>>>> >
>>>>>>> > https://github.com/apache/dubbo/issues/16042
>>>>>>> >
>>>>>>> > Would love to hear your thoughts ? especially from people who have
>>>>>>> > experience running large-scale virtual-thread-based services with
>>>>>>> > mixed third-party dependencies.
>>>>>>> >
>>>>>>>
>>>>>>> The guidelines that we put in JEP 444 [1] is to not pool virtual
>>>>>>> threads
>>>>>>> and to avoid caching costing resources in thread locals. Virtual
>>>>>>> threads
>>>>>>> support thread locals of course but that is not useful when some
>>>>>>> library
>>>>>>> is looking to share a costly resource between tasks that run on the
>>>>>>> same
>>>>>>> thread in a thread pool.
>>>>>>>
>>>>>>> I don't know anything about Aerospike but working with the
>>>>>>> maintainers
>>>>>>> of that library to re-work its buffer management seems like the
>>>>>>> right
>>>>>>> course of action here. Your mail says "byte buffers". If this is
>>>>>>> ByteBuffer it might be that they are caching direct buffers as they
>>>>>>> are
>>>>>>> expensive to create (and managed by the GC). Maybe they could look
>>>>>>> at
>>>>>>> using MemorySegment (it's easy to get a ByteBuffer view of a memory
>>>>>>> segment) and allocate from an arena that better matches the
>>>>>>> lifecycle.
>>>>>>>
>>>>>>> Hopefully others will share their experiences with migration as it
>>>>>>> is
>>>>>>> indeed challenging to migrate code developed for thread pools to
>>>>>>> work
>>>>>>> efficiently on virtual threads where there is 1-1 relationship
>>>>>>> between
>>>>>>> the task to execute and the thread.
>>>>>>>
>>>>>>> -Alan
>>>>>>>
>>>>>>> [1] https://openjdk.org/jeps/444#Thread-local-variables
>>>>>>>
>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260124/1d300777/attachment-0001.htm>

From alan.bateman at oracle.com  Sat Jan 24 08:32:54 2026
From: alan.bateman at oracle.com (Alan Bateman)
Date: Sat, 24 Jan 2026 08:32:54 +0000
Subject: Performance Issues with Virtual Threads + ThreadLocal Caching in
 Third-Party Libraries (JDK 25)
In-Reply-To: <CAAMX02pssPDdJ2B3Hy6DSsKEYqTPhPfVJqj6Muj3RAbJy=piqA@mail.gmail.com>
References: <CAAMX02o7ugTq-EuZO-dp_vhc0kHz2fp1q5RVNn7_N7JX7RvDYQ@mail.gmail.com>
 <40EFCACE-5F3F-4AF6-B8CA-9F8EEAFCD1FD@ix.netcom.com>
 <CAAMX02oGPtkTfr02Lmd8RtXsupP92zAEm8E3VwMqjKqosZooqA@mail.gmail.com>
 <CAKxGtTXdvHqOVhV3PHtz5+ZiaRB8dFD2YtGQO0uH1W36gyMwOg@mail.gmail.com>
 <CAAMX02qfZjQL6Fowpu-25D-9_F5zifXMAMP=HWbtQwUsqv3+VQ@mail.gmail.com>
 <CAKxGtTUTUyrodMUc2RTqNv7VQj9sn7No2QPy63ZCX51_cquy3w@mail.gmail.com>
 <CAAMX02pssPDdJ2B3Hy6DSsKEYqTPhPfVJqj6Muj3RAbJy=piqA@mail.gmail.com>
Message-ID: <44de0c3d-ddf3-474f-aee5-dcfa06d92373@oracle.com>



On 24/01/2026 05:55, Jianbin Chen wrote:
> :
>
> I constructed the Executor directly with 
> Executors.newVirtualThreadPerTaskExecutor();
> however, the run results still show that the pooled virtual?thread 
> behavior outperforms the non?pooled virtual threads.

This looks like it is benchmarking Thread.sleep so a different topic to 
that of libraries that are caching objects in thread locals.

For the Thread.sleep test then it would easier to discuss if converted 
to a JMH benchmark as there are warmup issues in the test you included. 
Also just to note that the Thread.sleep implementation has changed 
significantly changed since JDK 21 so you will see very different 
results with JDK 25 runs (some of the messages in the discussion speak 
of JDK 21, the subject line in the mails say "JDK 25", so I'm guessing 
you might be testing both).

-Alan

From jianbin at apache.org  Sat Jan 24 13:07:54 2026
From: jianbin at apache.org (Jianbin Chen)
Date: Sat, 24 Jan 2026 21:07:54 +0800
Subject: Performance Issues with Virtual Threads + ThreadLocal Caching in
 Third-Party Libraries (JDK 25)
In-Reply-To: <44de0c3d-ddf3-474f-aee5-dcfa06d92373@oracle.com>
References: <CAAMX02o7ugTq-EuZO-dp_vhc0kHz2fp1q5RVNn7_N7JX7RvDYQ@mail.gmail.com>
 <40EFCACE-5F3F-4AF6-B8CA-9F8EEAFCD1FD@ix.netcom.com>
 <CAAMX02oGPtkTfr02Lmd8RtXsupP92zAEm8E3VwMqjKqosZooqA@mail.gmail.com>
 <CAKxGtTXdvHqOVhV3PHtz5+ZiaRB8dFD2YtGQO0uH1W36gyMwOg@mail.gmail.com>
 <CAAMX02qfZjQL6Fowpu-25D-9_F5zifXMAMP=HWbtQwUsqv3+VQ@mail.gmail.com>
 <CAKxGtTUTUyrodMUc2RTqNv7VQj9sn7No2QPy63ZCX51_cquy3w@mail.gmail.com>
 <CAAMX02pssPDdJ2B3Hy6DSsKEYqTPhPfVJqj6Muj3RAbJy=piqA@mail.gmail.com>
 <44de0c3d-ddf3-474f-aee5-dcfa06d92373@oracle.com>
Message-ID: <CAAMX02pu=o-Mtp4NePXJjiupMptNkaewFs=s7GH-DzGofEDMCA@mail.gmail.com>

Hi Alan,

I ran my example on JDK 21 because it uses Thread.sleep. In an earlier
message on the mailing list I learned that virtual?thread performance on
JDK 25 was worse for this kind of scenario compared with JDK 21, and that
the issue is supposed to be fixed in JDK 25.0.3 ? which has not been
released yet.

That said, this does not affect the main point of my message: I?m asking
for advice about using pooled virtual threads to work around third?party
libraries that implement buffer pools via ThreadLocal.

Thank you,
Jianbin Chen

Alan Bateman <alan.bateman at oracle.com> ?2026?1?24??? 16:34???

>
>
> On 24/01/2026 05:55, Jianbin Chen wrote:
> > :
> >
> > I constructed the Executor directly with
> > Executors.newVirtualThreadPerTaskExecutor();
> > however, the run results still show that the pooled virtual?thread
> > behavior outperforms the non?pooled virtual threads.
>
> This looks like it is benchmarking Thread.sleep so a different topic to
> that of libraries that are caching objects in thread locals.
>
> For the Thread.sleep test then it would easier to discuss if converted
> to a JMH benchmark as there are warmup issues in the test you included.
> Also just to note that the Thread.sleep implementation has changed
> significantly changed since JDK 21 so you will see very different
> results with JDK 25 runs (some of the messages in the discussion speak
> of JDK 21, the subject line in the mails say "JDK 25", so I'm guessing
> you might be testing both).
>
> -Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260124/1f580761/attachment.htm>

From stigdoessing at gmail.com  Sat Jan 24 16:11:01 2026
From: stigdoessing at gmail.com (=?UTF-8?Q?Stig_Rohde_D=C3=B8ssing?=)
Date: Sat, 24 Jan 2026 17:11:01 +0100
Subject: Performance Issues with Virtual Threads + ThreadLocal Caching in
 Third-Party Libraries (JDK 25)
In-Reply-To: <CAAMX02pu=o-Mtp4NePXJjiupMptNkaewFs=s7GH-DzGofEDMCA@mail.gmail.com>
References: <CAAMX02o7ugTq-EuZO-dp_vhc0kHz2fp1q5RVNn7_N7JX7RvDYQ@mail.gmail.com>
 <40EFCACE-5F3F-4AF6-B8CA-9F8EEAFCD1FD@ix.netcom.com>
 <CAAMX02oGPtkTfr02Lmd8RtXsupP92zAEm8E3VwMqjKqosZooqA@mail.gmail.com>
 <CAKxGtTXdvHqOVhV3PHtz5+ZiaRB8dFD2YtGQO0uH1W36gyMwOg@mail.gmail.com>
 <CAAMX02qfZjQL6Fowpu-25D-9_F5zifXMAMP=HWbtQwUsqv3+VQ@mail.gmail.com>
 <CAKxGtTUTUyrodMUc2RTqNv7VQj9sn7No2QPy63ZCX51_cquy3w@mail.gmail.com>
 <CAAMX02pssPDdJ2B3Hy6DSsKEYqTPhPfVJqj6Muj3RAbJy=piqA@mail.gmail.com>
 <44de0c3d-ddf3-474f-aee5-dcfa06d92373@oracle.com>
 <CAAMX02pu=o-Mtp4NePXJjiupMptNkaewFs=s7GH-DzGofEDMCA@mail.gmail.com>
Message-ID: <CAG09ER2_pUqujePiSA82b+7Cb4hw+YWJrdFDZkKLcFQ87Z=yKQ@mail.gmail.com>

Hi Jianbin,

Sorry to butt in, but I think the question you are asking is a little odd.
You have a library that uses ThreadLocals for reusing expensive resources
(buffers in this case). The way to make such a library work well with
virtual threads is to redesign the library to avoid using TLs in this
manner. For example, you could make the library keep a pool of these
resources for reuse in a non-TL structure, like concurrent
maps/lists/queues.

But once you set the limitation that the library can't be adjusted, you are
forced into awkward workarounds. This is because the main advantage of
virtual threads is to allow you to write code in a thread-per-task style,
but the presence of these TLs makes threads precious resources that must be
reused across tasks, which loses you the ability to use virtual threads in
this way.

If you are unable to adjust the library and really want to use virtual
threads for part of your code, an option is to isolate the TL-using code so
it runs on a platform thread pool. You would then write most of your code
in thread-per-task style with virtual threads, but make the virtual threads
hand off work that needs the TLs to the thread pool, blocking the virtual
thread until that work completes.

If that is not an option, and you don't want that kind of handoff, you are
forced to create a pool of threads, as you found. But at that point, I
don't really understand why you want to use virtual threads at all. Once
you are making a pool of 200 threads you reuse, it doesn't really matter if
those threads are virtual or platform threads. You are forced to abandon
the thread-per-task style either way.

I don't think there is a great solution that will let you use
thread-per-task style virtual threads with a library that uses TLs for
resource reuse. The best you are likely to be able to do is various
workarounds, with various drawbacks. It might be better to aim for
reworking the library, and sticking with platform threads until you can do
that?

Den l?r. 24. jan. 2026 kl. 14.14 skrev Jianbin Chen <jianbin at apache.org>:

> Hi Alan,
>
> I ran my example on JDK 21 because it uses Thread.sleep. In an earlier
> message on the mailing list I learned that virtual?thread performance on
> JDK 25 was worse for this kind of scenario compared with JDK 21, and that
> the issue is supposed to be fixed in JDK 25.0.3 ? which has not been
> released yet.
>
> That said, this does not affect the main point of my message: I?m asking
> for advice about using pooled virtual threads to work around third?party
> libraries that implement buffer pools via ThreadLocal.
>
> Thank you,
> Jianbin Chen
>
> Alan Bateman <alan.bateman at oracle.com> ?2026?1?24??? 16:34???
>
>>
>>
>> On 24/01/2026 05:55, Jianbin Chen wrote:
>> > :
>> >
>> > I constructed the Executor directly with
>> > Executors.newVirtualThreadPerTaskExecutor();
>> > however, the run results still show that the pooled virtual?thread
>> > behavior outperforms the non?pooled virtual threads.
>>
>> This looks like it is benchmarking Thread.sleep so a different topic to
>> that of libraries that are caching objects in thread locals.
>>
>> For the Thread.sleep test then it would easier to discuss if converted
>> to a JMH benchmark as there are warmup issues in the test you included.
>> Also just to note that the Thread.sleep implementation has changed
>> significantly changed since JDK 21 so you will see very different
>> results with JDK 25 runs (some of the messages in the discussion speak
>> of JDK 21, the subject line in the mails say "JDK 25", so I'm guessing
>> you might be testing both).
>>
>> -Alan
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260124/86814505/attachment-0001.htm>

From alan.bateman at oracle.com  Sat Jan 24 16:41:26 2026
From: alan.bateman at oracle.com (Alan Bateman)
Date: Sat, 24 Jan 2026 16:41:26 +0000
Subject: Performance Issues with Virtual Threads + ThreadLocal Caching in
 Third-Party Libraries (JDK 25)
In-Reply-To: <CAAMX02pu=o-Mtp4NePXJjiupMptNkaewFs=s7GH-DzGofEDMCA@mail.gmail.com>
References: <CAAMX02o7ugTq-EuZO-dp_vhc0kHz2fp1q5RVNn7_N7JX7RvDYQ@mail.gmail.com>
 <40EFCACE-5F3F-4AF6-B8CA-9F8EEAFCD1FD@ix.netcom.com>
 <CAAMX02oGPtkTfr02Lmd8RtXsupP92zAEm8E3VwMqjKqosZooqA@mail.gmail.com>
 <CAKxGtTXdvHqOVhV3PHtz5+ZiaRB8dFD2YtGQO0uH1W36gyMwOg@mail.gmail.com>
 <CAAMX02qfZjQL6Fowpu-25D-9_F5zifXMAMP=HWbtQwUsqv3+VQ@mail.gmail.com>
 <CAKxGtTUTUyrodMUc2RTqNv7VQj9sn7No2QPy63ZCX51_cquy3w@mail.gmail.com>
 <CAAMX02pssPDdJ2B3Hy6DSsKEYqTPhPfVJqj6Muj3RAbJy=piqA@mail.gmail.com>
 <44de0c3d-ddf3-474f-aee5-dcfa06d92373@oracle.com>
 <CAAMX02pu=o-Mtp4NePXJjiupMptNkaewFs=s7GH-DzGofEDMCA@mail.gmail.com>
Message-ID: <065caab5-ac2a-425f-91dd-cfeeafb30c58@oracle.com>



On 24/01/2026 13:07, Jianbin Chen wrote:
> Hi Alan,
>
> I ran my example on JDK 21 because it uses Thread.sleep. In an earlier 
> message on the mailing list I learned that virtual?thread performance 
> on JDK 25 was worse for this kind of scenario compared with JDK 21, 
> and that the issue is supposed to be fixed in JDK 25.0.3 ? which has 
> not been released yet.

I assume this is about JDK-8370887 [1], which may be an? issue in some 
usages but I don't think has come up in this thread. For your 
Thread.sleep benchmark then maybe you can try it with the JDK 26 EA 
builds [2] where you know that issue has been fixed. As I said, I think 
that benchmark will need a bit of work (esp. on warmup) to get useful data.


>
> That said, this does not affect the main point of my message: I?m 
> asking for advice about using pooled virtual threads to work around 
> third?party libraries that implement buffer pools via ThreadLocal
The advise is to not pool virtual threads. If a library is performing 
poorly because it assumes execution on a pooled thread then all we can 
suggest is to work with the maintainer of that library on the issue. 
Note that the JDK removed several usages of thread locals that were 
caching byte[] and other objects. That caching was beneficial a long 
time ago but not in recent recent/releases with significantly improved 
memory management and GC.

-Alan

[1] https://bugs.openjdk.org/browse/JDK-8370887
[2] https://jdk.java.net/26/

From jianbin at apache.org  Sun Jan 25 05:55:53 2026
From: jianbin at apache.org (Jianbin Chen)
Date: Sun, 25 Jan 2026 13:55:53 +0800
Subject: Performance Issues with Virtual Threads + ThreadLocal Caching in
 Third-Party Libraries (JDK 25)
In-Reply-To: <CAG09ER2_pUqujePiSA82b+7Cb4hw+YWJrdFDZkKLcFQ87Z=yKQ@mail.gmail.com>
References: <CAAMX02o7ugTq-EuZO-dp_vhc0kHz2fp1q5RVNn7_N7JX7RvDYQ@mail.gmail.com>
 <40EFCACE-5F3F-4AF6-B8CA-9F8EEAFCD1FD@ix.netcom.com>
 <CAAMX02oGPtkTfr02Lmd8RtXsupP92zAEm8E3VwMqjKqosZooqA@mail.gmail.com>
 <CAKxGtTXdvHqOVhV3PHtz5+ZiaRB8dFD2YtGQO0uH1W36gyMwOg@mail.gmail.com>
 <CAAMX02qfZjQL6Fowpu-25D-9_F5zifXMAMP=HWbtQwUsqv3+VQ@mail.gmail.com>
 <CAKxGtTUTUyrodMUc2RTqNv7VQj9sn7No2QPy63ZCX51_cquy3w@mail.gmail.com>
 <CAAMX02pssPDdJ2B3Hy6DSsKEYqTPhPfVJqj6Muj3RAbJy=piqA@mail.gmail.com>
 <44de0c3d-ddf3-474f-aee5-dcfa06d92373@oracle.com>
 <CAAMX02pu=o-Mtp4NePXJjiupMptNkaewFs=s7GH-DzGofEDMCA@mail.gmail.com>
 <CAG09ER2_pUqujePiSA82b+7Cb4hw+YWJrdFDZkKLcFQ87Z=yKQ@mail.gmail.com>
Message-ID: <CAAMX02qVUoPY7tyaGcMHej1HbhSUqcQYWw5nQY=naOamHqJpUw@mail.gmail.com>

Hi Stig,

I mostly agree with your view. My emails have been describing a specific
scenario: my application runs on JDK 25, but many of the libraries I depend
on were developed for JDK 8 or are not very actively maintained. In the
short term, pooling virtual threads seems to be the only practical
workaround; I don?t see a better alternative right now.

One correction I need to make: I did not fix the maximum size of my
virtual?thread pool. That means when the 200 core virtual threads are all
in use, the pool?s behavior becomes the same as non?pooled virtual threads
(it will create additional threads). You suggested using platform threads
instead, but platform threads have expensive context switching. In my
example, if I switch to platform threads then once the 200 core threads are
exhausted new platform threads are created, and at the moment those threads
are created CPU usage essentially spikes. If you run Java under Kubernetes
you?ll be familiar with this: creating new platform threads can instantly
consume the cgroup CPU quota, causing the process to be throttled until the
next available CPU window. Using a pooled virtual?thread solution avoids
this problem because it does not require creating costly platform threads.

Thanks,
Jianbin Chen

Stig Rohde D?ssing <stigdoessing at gmail.com> ?2026?1?25??? 00:11???

> Hi Jianbin,
>
> Sorry to butt in, but I think the question you are asking is a little odd.
> You have a library that uses ThreadLocals for reusing expensive resources
> (buffers in this case). The way to make such a library work well with
> virtual threads is to redesign the library to avoid using TLs in this
> manner. For example, you could make the library keep a pool of these
> resources for reuse in a non-TL structure, like concurrent
> maps/lists/queues.
>
> But once you set the limitation that the library can't be adjusted, you
> are forced into awkward workarounds. This is because the main advantage of
> virtual threads is to allow you to write code in a thread-per-task style,
> but the presence of these TLs makes threads precious resources that must be
> reused across tasks, which loses you the ability to use virtual threads in
> this way.
>
> If you are unable to adjust the library and really want to use virtual
> threads for part of your code, an option is to isolate the TL-using code so
> it runs on a platform thread pool. You would then write most of your code
> in thread-per-task style with virtual threads, but make the virtual threads
> hand off work that needs the TLs to the thread pool, blocking the virtual
> thread until that work completes.
>
> If that is not an option, and you don't want that kind of handoff, you are
> forced to create a pool of threads, as you found. But at that point, I
> don't really understand why you want to use virtual threads at all. Once
> you are making a pool of 200 threads you reuse, it doesn't really matter if
> those threads are virtual or platform threads. You are forced to abandon
> the thread-per-task style either way.
>
> I don't think there is a great solution that will let you use
> thread-per-task style virtual threads with a library that uses TLs for
> resource reuse. The best you are likely to be able to do is various
> workarounds, with various drawbacks. It might be better to aim for
> reworking the library, and sticking with platform threads until you can do
> that?
>
> Den l?r. 24. jan. 2026 kl. 14.14 skrev Jianbin Chen <jianbin at apache.org>:
>
>> Hi Alan,
>>
>> I ran my example on JDK 21 because it uses Thread.sleep. In an earlier
>> message on the mailing list I learned that virtual?thread performance on
>> JDK 25 was worse for this kind of scenario compared with JDK 21, and that
>> the issue is supposed to be fixed in JDK 25.0.3 ? which has not been
>> released yet.
>>
>> That said, this does not affect the main point of my message: I?m asking
>> for advice about using pooled virtual threads to work around third?party
>> libraries that implement buffer pools via ThreadLocal.
>>
>> Thank you,
>> Jianbin Chen
>>
>> Alan Bateman <alan.bateman at oracle.com> ?2026?1?24??? 16:34???
>>
>>>
>>>
>>> On 24/01/2026 05:55, Jianbin Chen wrote:
>>> > :
>>> >
>>> > I constructed the Executor directly with
>>> > Executors.newVirtualThreadPerTaskExecutor();
>>> > however, the run results still show that the pooled virtual?thread
>>> > behavior outperforms the non?pooled virtual threads.
>>>
>>> This looks like it is benchmarking Thread.sleep so a different topic to
>>> that of libraries that are caching objects in thread locals.
>>>
>>> For the Thread.sleep test then it would easier to discuss if converted
>>> to a JMH benchmark as there are warmup issues in the test you included.
>>> Also just to note that the Thread.sleep implementation has changed
>>> significantly changed since JDK 21 so you will see very different
>>> results with JDK 25 runs (some of the messages in the discussion speak
>>> of JDK 21, the subject line in the mails say "JDK 25", so I'm guessing
>>> you might be testing both).
>>>
>>> -Alan
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260125/9ccf7fdc/attachment-0001.htm>

From jianbin at apache.org  Sun Jan 25 06:11:27 2026
From: jianbin at apache.org (Jianbin Chen)
Date: Sun, 25 Jan 2026 14:11:27 +0800
Subject: Performance Issues with Virtual Threads + ThreadLocal Caching in
 Third-Party Libraries (JDK 25)
In-Reply-To: <065caab5-ac2a-425f-91dd-cfeeafb30c58@oracle.com>
References: <CAAMX02o7ugTq-EuZO-dp_vhc0kHz2fp1q5RVNn7_N7JX7RvDYQ@mail.gmail.com>
 <40EFCACE-5F3F-4AF6-B8CA-9F8EEAFCD1FD@ix.netcom.com>
 <CAAMX02oGPtkTfr02Lmd8RtXsupP92zAEm8E3VwMqjKqosZooqA@mail.gmail.com>
 <CAKxGtTXdvHqOVhV3PHtz5+ZiaRB8dFD2YtGQO0uH1W36gyMwOg@mail.gmail.com>
 <CAAMX02qfZjQL6Fowpu-25D-9_F5zifXMAMP=HWbtQwUsqv3+VQ@mail.gmail.com>
 <CAKxGtTUTUyrodMUc2RTqNv7VQj9sn7No2QPy63ZCX51_cquy3w@mail.gmail.com>
 <CAAMX02pssPDdJ2B3Hy6DSsKEYqTPhPfVJqj6Muj3RAbJy=piqA@mail.gmail.com>
 <44de0c3d-ddf3-474f-aee5-dcfa06d92373@oracle.com>
 <CAAMX02pu=o-Mtp4NePXJjiupMptNkaewFs=s7GH-DzGofEDMCA@mail.gmail.com>
 <065caab5-ac2a-425f-91dd-cfeeafb30c58@oracle.com>
Message-ID: <CAAMX02pTWXddsoJmV=Ky4oaxQXMDG=vbCJrzO5Y9=u=wWJysuA@mail.gmail.com>

Hi Alan,

Thanks for the heads up ? I?ll try running the performance tests again on
the JDK 26 EA build.

That said, let?s continue the discussion around the main topic of this
thread. I understand and largely agree with most people?s recommendations
and the reasons why virtual threads shouldn?t be pooled. However, those
recommendations generally assume that both our application and the
third?party libraries it depends on have been adapted to newer JDK features
? for example, replacing ThreadLocal?based buffer pools with proper object
pools ? and I fully appreciate the benefits of making those changes.

In reality it?s often much harder: many third?party libraries must remain
compatible with older JDK 8 users, so they are not eager to adopt newer
platform features. That leaves users like us in a difficult position. For
example, when JDK 21 shipped I eagerly adopted virtual threads, but then
suffered from issues caused by third?party libraries using synchronized,
Object.wait, etc. I traced the pinned?thread causes to such libraries ?
take apache commons?pool as an example: you can see PRs addressing
synchronized/Object.wait refactors here:
https://github.com/apache/commons-pool/pulls ? some of those PRs were
opened two or three years ago and are still unapproved. Aren?t these kinds
of problems part of the motivation behind JEP 491?

Given this reality, the only practical short?term approach available to me
appears to be a compromise: pool virtual threads but do not set a fixed
maximum thread count. That way I can both limit buffer waste (which hurts
performance) and still gain the throughput benefits of virtual threads.

Best regards,
Jianbin Chen

Alan Bateman <alan.bateman at oracle.com> ?2026?1?25??? 00:42???

>
>
> On 24/01/2026 13:07, Jianbin Chen wrote:
> > Hi Alan,
> >
> > I ran my example on JDK 21 because it uses Thread.sleep. In an earlier
> > message on the mailing list I learned that virtual?thread performance
> > on JDK 25 was worse for this kind of scenario compared with JDK 21,
> > and that the issue is supposed to be fixed in JDK 25.0.3 ? which has
> > not been released yet.
>
> I assume this is about JDK-8370887 [1], which may be an  issue in some
> usages but I don't think has come up in this thread. For your
> Thread.sleep benchmark then maybe you can try it with the JDK 26 EA
> builds [2] where you know that issue has been fixed. As I said, I think
> that benchmark will need a bit of work (esp. on warmup) to get useful data.
>
>
> >
> > That said, this does not affect the main point of my message: I?m
> > asking for advice about using pooled virtual threads to work around
> > third?party libraries that implement buffer pools via ThreadLocal
> The advise is to not pool virtual threads. If a library is performing
> poorly because it assumes execution on a pooled thread then all we can
> suggest is to work with the maintainer of that library on the issue.
> Note that the JDK removed several usages of thread locals that were
> caching byte[] and other objects. That caching was beneficial a long
> time ago but not in recent recent/releases with significantly improved
> memory management and GC.
>
> -Alan
>
> [1] https://bugs.openjdk.org/browse/JDK-8370887
> [2] https://jdk.java.net/26/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260125/f8d7c151/attachment.htm>

From robaho at me.com  Sun Jan 25 06:59:25 2026
From: robaho at me.com (robert engels)
Date: Sun, 25 Jan 2026 00:59:25 -0600
Subject: Performance Issues with Virtual Threads + ThreadLocal Caching in
 Third-Party Libraries (JDK 25)
In-Reply-To: <CAAMX02pTWXddsoJmV=Ky4oaxQXMDG=vbCJrzO5Y9=u=wWJysuA@mail.gmail.com>
References: <CAAMX02pTWXddsoJmV=Ky4oaxQXMDG=vbCJrzO5Y9=u=wWJysuA@mail.gmail.com>
Message-ID: <58198E1A-0B0C-48AF-A57E-6D36F436A002@me.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260125/dfc05627/attachment-0001.htm>

From jianbin at apache.org  Sun Jan 25 08:50:55 2026
From: jianbin at apache.org (Jianbin Chen)
Date: Sun, 25 Jan 2026 16:50:55 +0800
Subject: Performance Issues with Virtual Threads + ThreadLocal Caching in
 Third-Party Libraries (JDK 25)
In-Reply-To: <58198E1A-0B0C-48AF-A57E-6D36F436A002@me.com>
References: <CAAMX02pTWXddsoJmV=Ky4oaxQXMDG=vbCJrzO5Y9=u=wWJysuA@mail.gmail.com>
 <58198E1A-0B0C-48AF-A57E-6D36F436A002@me.com>
Message-ID: <CAAMX02p9FgVo8Xrew+4XPAHm-r=1cF180MPRTniuAiv=TZ7aBg@mail.gmail.com>

Hi Robert,

I don?t understand why you think I?m trolling. Also, you haven?t offered a
concrete solution to the real problem I?m facing. I provided many examples
? were you looking at them? Do I need to be trolling about this issue? My
example is a real?world case; do you expect me, by myself, to update all
the third?party libraries I use so they adopt newer JDK features and
guarantee they no longer use ThreadLocal? I only want to discuss whether
pooling virtual threads is a best practice when you depend on libraries
that use ThreadLocal for buffer pooling.

Regarding your concern that my example would allocate 16GB at once: I set
both Xms and Xmx to 2880m. The code is as follows:

```java
public static void main(String[] args) throws InterruptedException {
    int tasks = 2000000;
    // Create an executor that spawns a new virtual thread for each task
    Executor executor = Executors.newThreadPerTaskExecutor(
        Thread.ofVirtual().name("test-", 1).factory());

    // Create a virtual-thread-based thread pool with large max size and
SynchronousQueue
    // This allows unbounded growth when needed, but reuses idle threads up
to keepAliveTime
    Executor executor2 = new ThreadPoolExecutor(
        200,                       // core pool size
        Integer.MAX_VALUE,         // maximum pool size (effectively
unbounded)
        0,                        // keep-alive time
        java.util.concurrent.TimeUnit.SECONDS,
        new SynchronousQueue<>(),  // handoff queue ? forces new thread
creation when pool is busy
        Thread.ofVirtual().name("test-threadpool-", 1).factory());

    // Warm-up / pre-heat phase to allow JIT compilation and thread creation
    for (int i = 0; i < 10100; i++) {
        executor.execute(() -> {
            // Simulate I/O wait
            try {
                Thread.sleep(10);
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
        });

        executor2.execute(() -> {
            // Simulate I/O wait
            try {
                Thread.sleep(10);
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
        });
    }

    // Wait long enough to ensure JIT compilation and warm-up are complete
    Thread.sleep(5000);

    long start = System.currentTimeMillis();
    CountDownLatch countDownLatch = new CountDownLatch(tasks);

    for (int i = 0; i < tasks; i++) {
        executor.execute(() -> {
            // Simulate I/O wait
            try {
                Thread.sleep(100);
                countDownLatch.countDown();
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
        });
    }

    countDownLatch.await();
    System.out.println("thread time: " + (System.currentTimeMillis() -
start) + " ms tasks: " + tasks);

    start = System.currentTimeMillis();
    CountDownLatch countDownLatch2 = new CountDownLatch(tasks);

    for (int i = 0; i < tasks; i++) {
        executor2.execute(() -> {
            // Simulate I/O wait
            try {
                Thread.sleep(100);
                countDownLatch2.countDown();
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
        });
    }

    countDownLatch2.await();  // Fixed: should await countDownLatch2 (not
the first one)
    System.out.println("thread pool time: " + (System.currentTimeMillis() -
start) + " ms tasks: " + tasks);
}
```

When the number of concurrent tasks is between 100,000 and 2,000,000,
non?pooled virtual threads perform better; when it is greater than two
million or less than 100,000, the pooled approach performs better. However,
I don?t want to continue discussing this particular example.

Regards,
Jianbin Chen

robert engels <robaho at me.com> ?2026?1?25??? 14:59???

> No. You aren?t listening. Your test case is broken. It will allocate 16gb
> of heap almost immediately. I?ve tried to explain this to you multiple
> ways. I think you are trolling.
>
> On Jan 25, 2026, at 12:12?AM, Jianbin Chen <jianbin at apache.org> wrote:
>
> ?
> Hi Alan,
>
> Thanks for the heads up ? I?ll try running the performance tests again on
> the JDK 26 EA build.
>
> That said, let?s continue the discussion around the main topic of this
> thread. I understand and largely agree with most people?s recommendations
> and the reasons why virtual threads shouldn?t be pooled. However, those
> recommendations generally assume that both our application and the
> third?party libraries it depends on have been adapted to newer JDK features
> ? for example, replacing ThreadLocal?based buffer pools with proper object
> pools ? and I fully appreciate the benefits of making those changes.
>
> In reality it?s often much harder: many third?party libraries must remain
> compatible with older JDK 8 users, so they are not eager to adopt newer
> platform features. That leaves users like us in a difficult position. For
> example, when JDK 21 shipped I eagerly adopted virtual threads, but then
> suffered from issues caused by third?party libraries using synchronized,
> Object.wait, etc. I traced the pinned?thread causes to such libraries ?
> take apache commons?pool as an example: you can see PRs addressing
> synchronized/Object.wait refactors here:
> https://github.com/apache/commons-pool/pulls ? some of those PRs were
> opened two or three years ago and are still unapproved. Aren?t these kinds
> of problems part of the motivation behind JEP 491?
>
> Given this reality, the only practical short?term approach available to me
> appears to be a compromise: pool virtual threads but do not set a fixed
> maximum thread count. That way I can both limit buffer waste (which hurts
> performance) and still gain the throughput benefits of virtual threads.
>
> Best regards,
> Jianbin Chen
>
> Alan Bateman <alan.bateman at oracle.com> ?2026?1?25??? 00:42???
>
>>
>>
>> On 24/01/2026 13:07, Jianbin Chen wrote:
>> > Hi Alan,
>> >
>> > I ran my example on JDK 21 because it uses Thread.sleep. In an earlier
>> > message on the mailing list I learned that virtual?thread performance
>> > on JDK 25 was worse for this kind of scenario compared with JDK 21,
>> > and that the issue is supposed to be fixed in JDK 25.0.3 ? which has
>> > not been released yet.
>>
>> I assume this is about JDK-8370887 [1], which may be an  issue in some
>> usages but I don't think has come up in this thread. For your
>> Thread.sleep benchmark then maybe you can try it with the JDK 26 EA
>> builds [2] where you know that issue has been fixed. As I said, I think
>> that benchmark will need a bit of work (esp. on warmup) to get useful
>> data.
>>
>>
>> >
>> > That said, this does not affect the main point of my message: I?m
>> > asking for advice about using pooled virtual threads to work around
>> > third?party libraries that implement buffer pools via ThreadLocal
>> The advise is to not pool virtual threads. If a library is performing
>> poorly because it assumes execution on a pooled thread then all we can
>> suggest is to work with the maintainer of that library on the issue.
>> Note that the JDK removed several usages of thread locals that were
>> caching byte[] and other objects. That caching was beneficial a long
>> time ago but not in recent recent/releases with significantly improved
>> memory management and GC.
>>
>> -Alan
>>
>> [1] https://bugs.openjdk.org/browse/JDK-8370887
>> [2] https://jdk.java.net/26/
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260125/0af24e45/attachment.htm>

From stigdoessing at gmail.com  Sun Jan 25 10:56:09 2026
From: stigdoessing at gmail.com (=?UTF-8?Q?Stig_Rohde_D=C3=B8ssing?=)
Date: Sun, 25 Jan 2026 11:56:09 +0100
Subject: Performance Issues with Virtual Threads + ThreadLocal Caching in
 Third-Party Libraries (JDK 25)
In-Reply-To: <CAAMX02qVUoPY7tyaGcMHej1HbhSUqcQYWw5nQY=naOamHqJpUw@mail.gmail.com>
References: <CAAMX02o7ugTq-EuZO-dp_vhc0kHz2fp1q5RVNn7_N7JX7RvDYQ@mail.gmail.com>
 <40EFCACE-5F3F-4AF6-B8CA-9F8EEAFCD1FD@ix.netcom.com>
 <CAAMX02oGPtkTfr02Lmd8RtXsupP92zAEm8E3VwMqjKqosZooqA@mail.gmail.com>
 <CAKxGtTXdvHqOVhV3PHtz5+ZiaRB8dFD2YtGQO0uH1W36gyMwOg@mail.gmail.com>
 <CAAMX02qfZjQL6Fowpu-25D-9_F5zifXMAMP=HWbtQwUsqv3+VQ@mail.gmail.com>
 <CAKxGtTUTUyrodMUc2RTqNv7VQj9sn7No2QPy63ZCX51_cquy3w@mail.gmail.com>
 <CAAMX02pssPDdJ2B3Hy6DSsKEYqTPhPfVJqj6Muj3RAbJy=piqA@mail.gmail.com>
 <44de0c3d-ddf3-474f-aee5-dcfa06d92373@oracle.com>
 <CAAMX02pu=o-Mtp4NePXJjiupMptNkaewFs=s7GH-DzGofEDMCA@mail.gmail.com>
 <CAG09ER2_pUqujePiSA82b+7Cb4hw+YWJrdFDZkKLcFQ87Z=yKQ@mail.gmail.com>
 <CAAMX02qVUoPY7tyaGcMHej1HbhSUqcQYWw5nQY=naOamHqJpUw@mail.gmail.com>
Message-ID: <CAG09ER3G+13wHZY+yRZrLNA+gHx+2qUBVW+Aag553hJGh=k7LA@mail.gmail.com>

Hi Jianbin,

It might be worth considering that depending on unmaintained or poorly
maintained libraries is a risk for your application (what happens when a
vulnerability is discovered?), even before virtual threads enter the
equation.

Creating an object pool should not require any post-Java-8 features, so it
should be possible to update libraries to be virtual thread friendly
without dropping compatibility with Java 8. With a bit of abstraction, the
library could even allow sticking with TLs depending on configuration, see
for example log4j's Recycler interface
https://github.com/apache/logging-log4j2/blob/4f474b32751f4ccad67424ca585612584440cd63/log4j-layout-template-json/src/main/java/org/apache/logging/log4j/layout/template/json/util/Recycler.java

However, the question you are asking is essentially "Assuming I can't
change the libraries, is it okay to pool virtual threads as a workaround?"

The reasoning behind never pooling virtual threads, given in JEP 444, is
that virtual threads are "cheap and plentiful", allowing for the use of the
thread-per-task style rather than pooling and reusing threads. With the
libraries you are using, threads cannot be cheap and plentiful, because the
TLs make them expensive.

Assuming the libraries can't be changed, you can't use the thread-per-task
style, so you are forced into pooling. Once you are stuck with pooling, you
are asking if it's fine for the pool to create virtual threads instead of
platform threads, because virtual threads are cheaper to create when the
pool needs to scale.

And it probably is, and there probably aren't better alternatives if we
stick with your premise that the libraries can't be changed. Pooling
virtual threads isn't "against the rules", it's just not
recommended, because ideally you'd change the library rather than hacking
around the problem by pooling threads.

The drawback to this workaround is that you have to abandon the
thread-per-task style, which is where a lot of the benefit of virtual
threads comes from. You end up with something that behaves mostly like a
normal platform thread pool, except the pool can have more threads than
usual, and creating those threads is faster than usual. That's good, it's
just not *as* good as thread-per-task.

As a side note, you might want to consider limiting the pool size, or
limiting your concurrency in other ways, e.g. via semaphores. Since the TL
resources are expensive, it doesn't seem like a good idea to have no limit
on how many threads you can have active at a time.

My 2 cents on your question are that what you are doing is probably fine as
a short term workaround, but you should really consider putting the
necessary time into updating those libraries as a longer term solution. You
will end up with a better result.

Den s?n. 25. jan. 2026 kl. 06.57 skrev Jianbin Chen <jianbin at apache.org>:

> Hi Stig,
>
> I mostly agree with your view. My emails have been describing a specific
> scenario: my application runs on JDK 25, but many of the libraries I depend
> on were developed for JDK 8 or are not very actively maintained. In the
> short term, pooling virtual threads seems to be the only practical
> workaround; I don?t see a better alternative right now.
>
> One correction I need to make: I did not fix the maximum size of my
> virtual?thread pool. That means when the 200 core virtual threads are all
> in use, the pool?s behavior becomes the same as non?pooled virtual threads
> (it will create additional threads). You suggested using platform threads
> instead, but platform threads have expensive context switching. In my
> example, if I switch to platform threads then once the 200 core threads are
> exhausted new platform threads are created, and at the moment those threads
> are created CPU usage essentially spikes. If you run Java under Kubernetes
> you?ll be familiar with this: creating new platform threads can instantly
> consume the cgroup CPU quota, causing the process to be throttled until the
> next available CPU window. Using a pooled virtual?thread solution avoids
> this problem because it does not require creating costly platform threads.
>
> Thanks,
> Jianbin Chen
>
> Stig Rohde D?ssing <stigdoessing at gmail.com> ?2026?1?25??? 00:11???
>
>> Hi Jianbin,
>>
>> Sorry to butt in, but I think the question you are asking is a little
>> odd. You have a library that uses ThreadLocals for reusing expensive
>> resources (buffers in this case). The way to make such a library work well
>> with virtual threads is to redesign the library to avoid using TLs in this
>> manner. For example, you could make the library keep a pool of these
>> resources for reuse in a non-TL structure, like concurrent
>> maps/lists/queues.
>>
>> But once you set the limitation that the library can't be adjusted, you
>> are forced into awkward workarounds. This is because the main advantage of
>> virtual threads is to allow you to write code in a thread-per-task style,
>> but the presence of these TLs makes threads precious resources that must be
>> reused across tasks, which loses you the ability to use virtual threads in
>> this way.
>>
>> If you are unable to adjust the library and really want to use virtual
>> threads for part of your code, an option is to isolate the TL-using code so
>> it runs on a platform thread pool. You would then write most of your code
>> in thread-per-task style with virtual threads, but make the virtual threads
>> hand off work that needs the TLs to the thread pool, blocking the virtual
>> thread until that work completes.
>>
>> If that is not an option, and you don't want that kind of handoff, you
>> are forced to create a pool of threads, as you found. But at that point, I
>> don't really understand why you want to use virtual threads at all. Once
>> you are making a pool of 200 threads you reuse, it doesn't really matter if
>> those threads are virtual or platform threads. You are forced to abandon
>> the thread-per-task style either way.
>>
>> I don't think there is a great solution that will let you use
>> thread-per-task style virtual threads with a library that uses TLs for
>> resource reuse. The best you are likely to be able to do is various
>> workarounds, with various drawbacks. It might be better to aim for
>> reworking the library, and sticking with platform threads until you can do
>> that?
>>
>> Den l?r. 24. jan. 2026 kl. 14.14 skrev Jianbin Chen <jianbin at apache.org>:
>>
>>> Hi Alan,
>>>
>>> I ran my example on JDK 21 because it uses Thread.sleep. In an earlier
>>> message on the mailing list I learned that virtual?thread performance on
>>> JDK 25 was worse for this kind of scenario compared with JDK 21, and that
>>> the issue is supposed to be fixed in JDK 25.0.3 ? which has not been
>>> released yet.
>>>
>>> That said, this does not affect the main point of my message: I?m asking
>>> for advice about using pooled virtual threads to work around third?party
>>> libraries that implement buffer pools via ThreadLocal.
>>>
>>> Thank you,
>>> Jianbin Chen
>>>
>>> Alan Bateman <alan.bateman at oracle.com> ?2026?1?24??? 16:34???
>>>
>>>>
>>>>
>>>> On 24/01/2026 05:55, Jianbin Chen wrote:
>>>> > :
>>>> >
>>>> > I constructed the Executor directly with
>>>> > Executors.newVirtualThreadPerTaskExecutor();
>>>> > however, the run results still show that the pooled virtual?thread
>>>> > behavior outperforms the non?pooled virtual threads.
>>>>
>>>> This looks like it is benchmarking Thread.sleep so a different topic to
>>>> that of libraries that are caching objects in thread locals.
>>>>
>>>> For the Thread.sleep test then it would easier to discuss if converted
>>>> to a JMH benchmark as there are warmup issues in the test you included.
>>>> Also just to note that the Thread.sleep implementation has changed
>>>> significantly changed since JDK 21 so you will see very different
>>>> results with JDK 25 runs (some of the messages in the discussion speak
>>>> of JDK 21, the subject line in the mails say "JDK 25", so I'm guessing
>>>> you might be testing both).
>>>>
>>>> -Alan
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260125/0a5106b4/attachment-0001.htm>

From jianbin at apache.org  Sun Jan 25 12:16:35 2026
From: jianbin at apache.org (Jianbin Chen)
Date: Sun, 25 Jan 2026 20:16:35 +0800
Subject: Performance Issues with Virtual Threads + ThreadLocal Caching in
 Third-Party Libraries (JDK 25)
In-Reply-To: <CAG09ER3G+13wHZY+yRZrLNA+gHx+2qUBVW+Aag553hJGh=k7LA@mail.gmail.com>
References: <CAAMX02o7ugTq-EuZO-dp_vhc0kHz2fp1q5RVNn7_N7JX7RvDYQ@mail.gmail.com>
 <40EFCACE-5F3F-4AF6-B8CA-9F8EEAFCD1FD@ix.netcom.com>
 <CAAMX02oGPtkTfr02Lmd8RtXsupP92zAEm8E3VwMqjKqosZooqA@mail.gmail.com>
 <CAKxGtTXdvHqOVhV3PHtz5+ZiaRB8dFD2YtGQO0uH1W36gyMwOg@mail.gmail.com>
 <CAAMX02qfZjQL6Fowpu-25D-9_F5zifXMAMP=HWbtQwUsqv3+VQ@mail.gmail.com>
 <CAKxGtTUTUyrodMUc2RTqNv7VQj9sn7No2QPy63ZCX51_cquy3w@mail.gmail.com>
 <CAAMX02pssPDdJ2B3Hy6DSsKEYqTPhPfVJqj6Muj3RAbJy=piqA@mail.gmail.com>
 <44de0c3d-ddf3-474f-aee5-dcfa06d92373@oracle.com>
 <CAAMX02pu=o-Mtp4NePXJjiupMptNkaewFs=s7GH-DzGofEDMCA@mail.gmail.com>
 <CAG09ER2_pUqujePiSA82b+7Cb4hw+YWJrdFDZkKLcFQ87Z=yKQ@mail.gmail.com>
 <CAAMX02qVUoPY7tyaGcMHej1HbhSUqcQYWw5nQY=naOamHqJpUw@mail.gmail.com>
 <CAG09ER3G+13wHZY+yRZrLNA+gHx+2qUBVW+Aag553hJGh=k7LA@mail.gmail.com>
Message-ID: <CAAMX02qTuyVGuUttSfhmsCK-Uty0vgsy253UXcu=GWE-5KZfRA@mail.gmail.com>

Hi Stig,

Thank you very much, and thanks to everyone who participated in this
discussion. I have basically reached the following conclusions:

1. Replace libraries that use ThreadLocal for buffer pools, or refactor
them to object pools wherever possible.
2. If conclusion 1 cannot be completed in the short term, pooling virtual
threads appears to be the only practical option.

I will do my best to implement conclusion 1; until then I will adopt
conclusion 2 as an interim solution.

Thanks again,
Jianbin Chen

Stig Rohde D?ssing <stigdoessing at gmail.com> ?2026?1?25??? 18:58???

> Hi Jianbin,
>
> It might be worth considering that depending on unmaintained or poorly
> maintained libraries is a risk for your application (what happens when a
> vulnerability is discovered?), even before virtual threads enter the
> equation.
>
> Creating an object pool should not require any post-Java-8 features, so it
> should be possible to update libraries to be virtual thread friendly
> without dropping compatibility with Java 8. With a bit of abstraction, the
> library could even allow sticking with TLs depending on configuration, see
> for example log4j's Recycler interface
> https://github.com/apache/logging-log4j2/blob/4f474b32751f4ccad67424ca585612584440cd63/log4j-layout-template-json/src/main/java/org/apache/logging/log4j/layout/template/json/util/Recycler.java
>
> However, the question you are asking is essentially "Assuming I can't
> change the libraries, is it okay to pool virtual threads as a workaround?"
>
> The reasoning behind never pooling virtual threads, given in JEP 444, is
> that virtual threads are "cheap and plentiful", allowing for the use of the
> thread-per-task style rather than pooling and reusing threads. With the
> libraries you are using, threads cannot be cheap and plentiful, because the
> TLs make them expensive.
>
> Assuming the libraries can't be changed, you can't use the thread-per-task
> style, so you are forced into pooling. Once you are stuck with pooling, you
> are asking if it's fine for the pool to create virtual threads instead of
> platform threads, because virtual threads are cheaper to create when the
> pool needs to scale.
>
> And it probably is, and there probably aren't better alternatives if we
> stick with your premise that the libraries can't be changed. Pooling
> virtual threads isn't "against the rules", it's just not
> recommended, because ideally you'd change the library rather than hacking
> around the problem by pooling threads.
>
> The drawback to this workaround is that you have to abandon the
> thread-per-task style, which is where a lot of the benefit of virtual
> threads comes from. You end up with something that behaves mostly like a
> normal platform thread pool, except the pool can have more threads than
> usual, and creating those threads is faster than usual. That's good, it's
> just not *as* good as thread-per-task.
>
> As a side note, you might want to consider limiting the pool size, or
> limiting your concurrency in other ways, e.g. via semaphores. Since the TL
> resources are expensive, it doesn't seem like a good idea to have no limit
> on how many threads you can have active at a time.
>
> My 2 cents on your question are that what you are doing is probably fine
> as a short term workaround, but you should really consider putting the
> necessary time into updating those libraries as a longer term solution. You
> will end up with a better result.
>
> Den s?n. 25. jan. 2026 kl. 06.57 skrev Jianbin Chen <jianbin at apache.org>:
>
>> Hi Stig,
>>
>> I mostly agree with your view. My emails have been describing a specific
>> scenario: my application runs on JDK 25, but many of the libraries I depend
>> on were developed for JDK 8 or are not very actively maintained. In the
>> short term, pooling virtual threads seems to be the only practical
>> workaround; I don?t see a better alternative right now.
>>
>> One correction I need to make: I did not fix the maximum size of my
>> virtual?thread pool. That means when the 200 core virtual threads are all
>> in use, the pool?s behavior becomes the same as non?pooled virtual threads
>> (it will create additional threads). You suggested using platform threads
>> instead, but platform threads have expensive context switching. In my
>> example, if I switch to platform threads then once the 200 core threads are
>> exhausted new platform threads are created, and at the moment those threads
>> are created CPU usage essentially spikes. If you run Java under Kubernetes
>> you?ll be familiar with this: creating new platform threads can instantly
>> consume the cgroup CPU quota, causing the process to be throttled until the
>> next available CPU window. Using a pooled virtual?thread solution avoids
>> this problem because it does not require creating costly platform threads.
>>
>> Thanks,
>> Jianbin Chen
>>
>> Stig Rohde D?ssing <stigdoessing at gmail.com> ?2026?1?25??? 00:11???
>>
>>> Hi Jianbin,
>>>
>>> Sorry to butt in, but I think the question you are asking is a little
>>> odd. You have a library that uses ThreadLocals for reusing expensive
>>> resources (buffers in this case). The way to make such a library work well
>>> with virtual threads is to redesign the library to avoid using TLs in this
>>> manner. For example, you could make the library keep a pool of these
>>> resources for reuse in a non-TL structure, like concurrent
>>> maps/lists/queues.
>>>
>>> But once you set the limitation that the library can't be adjusted, you
>>> are forced into awkward workarounds. This is because the main advantage of
>>> virtual threads is to allow you to write code in a thread-per-task style,
>>> but the presence of these TLs makes threads precious resources that must be
>>> reused across tasks, which loses you the ability to use virtual threads in
>>> this way.
>>>
>>> If you are unable to adjust the library and really want to use virtual
>>> threads for part of your code, an option is to isolate the TL-using code so
>>> it runs on a platform thread pool. You would then write most of your code
>>> in thread-per-task style with virtual threads, but make the virtual threads
>>> hand off work that needs the TLs to the thread pool, blocking the virtual
>>> thread until that work completes.
>>>
>>> If that is not an option, and you don't want that kind of handoff, you
>>> are forced to create a pool of threads, as you found. But at that point, I
>>> don't really understand why you want to use virtual threads at all. Once
>>> you are making a pool of 200 threads you reuse, it doesn't really matter if
>>> those threads are virtual or platform threads. You are forced to abandon
>>> the thread-per-task style either way.
>>>
>>> I don't think there is a great solution that will let you use
>>> thread-per-task style virtual threads with a library that uses TLs for
>>> resource reuse. The best you are likely to be able to do is various
>>> workarounds, with various drawbacks. It might be better to aim for
>>> reworking the library, and sticking with platform threads until you can do
>>> that?
>>>
>>> Den l?r. 24. jan. 2026 kl. 14.14 skrev Jianbin Chen <jianbin at apache.org
>>> >:
>>>
>>>> Hi Alan,
>>>>
>>>> I ran my example on JDK 21 because it uses Thread.sleep. In an earlier
>>>> message on the mailing list I learned that virtual?thread performance on
>>>> JDK 25 was worse for this kind of scenario compared with JDK 21, and that
>>>> the issue is supposed to be fixed in JDK 25.0.3 ? which has not been
>>>> released yet.
>>>>
>>>> That said, this does not affect the main point of my message: I?m
>>>> asking for advice about using pooled virtual threads to work around
>>>> third?party libraries that implement buffer pools via ThreadLocal.
>>>>
>>>> Thank you,
>>>> Jianbin Chen
>>>>
>>>> Alan Bateman <alan.bateman at oracle.com> ?2026?1?24??? 16:34???
>>>>
>>>>>
>>>>>
>>>>> On 24/01/2026 05:55, Jianbin Chen wrote:
>>>>> > :
>>>>> >
>>>>> > I constructed the Executor directly with
>>>>> > Executors.newVirtualThreadPerTaskExecutor();
>>>>> > however, the run results still show that the pooled virtual?thread
>>>>> > behavior outperforms the non?pooled virtual threads.
>>>>>
>>>>> This looks like it is benchmarking Thread.sleep so a different topic
>>>>> to
>>>>> that of libraries that are caching objects in thread locals.
>>>>>
>>>>> For the Thread.sleep test then it would easier to discuss if converted
>>>>> to a JMH benchmark as there are warmup issues in the test you
>>>>> included.
>>>>> Also just to note that the Thread.sleep implementation has changed
>>>>> significantly changed since JDK 21 so you will see very different
>>>>> results with JDK 25 runs (some of the messages in the discussion speak
>>>>> of JDK 21, the subject line in the mails say "JDK 25", so I'm guessing
>>>>> you might be testing both).
>>>>>
>>>>> -Alan
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20260125/d2955474/attachment.htm>

From duke at openjdk.org  Thu Jan 29 08:14:42 2026
From: duke at openjdk.org (duke)
Date: Thu, 29 Jan 2026 08:14:42 GMT
Subject: git: openjdk/loom: fibers: 89 new changesets
Message-ID: <768cc606-8027-46d7-b042-a13afbc7b98d@openjdk.org>

Changeset: 07f6617e
Branch: fibers
Author:    Brian Burkhalter <bpb at openjdk.org>
Date:      2026-01-22 16:11:33 +0000
URL:       https://git.openjdk.org/loom/commit/07f6617e0b2752b538b6c43250dd0bb65fd8c695

8367284: (fs) Support current working directory target in SecureDirectoryStream.move

Reviewed-by: alanb

! src/java.base/share/classes/java/nio/file/SecureDirectoryStream.java
! src/java.base/unix/classes/sun/nio/fs/UnixSecureDirectoryStream.java
! test/jdk/java/nio/file/DirectoryStream/SecureDS.java

Changeset: 8c82b58d
Branch: fibers
Author:    Alexander Zuev <kizune at openjdk.org>
Date:      2026-01-22 16:36:24 +0000
URL:       https://git.openjdk.org/loom/commit/8c82b58db960a178566514731e1f8dcbc59b0161

8286258: [Accessibility,macOS,VoiceOver] VoiceOver reads the spinner value wrong and sometime partially

Reviewed-by: psadhukhan, asemenov

! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/NavigableTextAccessibility.h
! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/NavigableTextAccessibility.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/SpinboxAccessibility.m
+ test/jdk/javax/accessibility/JSpinner/CustomSpinnerAccessibilityTest.java

Changeset: 5dfda66e
Branch: fibers
Author:    Henry Jen <henryjen at openjdk.org>
Date:      2026-01-22 17:21:44 +0000
URL:       https://git.openjdk.org/loom/commit/5dfda66e13df5a88a66a6e4b1ae1bcd4e20ac674

8373928: 4 Dangling pointer defect groups in java.c

Reviewed-by: bpb, alanb, jpai, jwaters

! src/java.base/share/native/libjli/java.c

Changeset: 96a2649e
Branch: fibers
Author:    Hai-May Chao <hchao at openjdk.org>
Date:      2026-01-22 17:41:00 +0000
URL:       https://git.openjdk.org/loom/commit/96a2649e29b8b4ff9b65b2314d430bc7637c5c61

8373408: SHA1withECDSA is not required for ECDHE and ECDSA

Reviewed-by: djelinski, ascarpino

! src/java.base/share/classes/sun/security/ssl/JsseJce.java

Changeset: f3121d10
Branch: fibers
Author:    Phil Race <prr at openjdk.org>
Date:      2026-01-22 20:16:44 +0000
URL:       https://git.openjdk.org/loom/commit/f3121d10237a933087dde926f83a12ce826cde02

8373931: Test javax/sound/sampled/Clip/AutoCloseTimeCheck.java timed out

Reviewed-by: dholmes, dnguyen, kizune

! test/jdk/javax/sound/sampled/Clip/AutoCloseTimeCheck.java

Changeset: d6ebcf8a
Branch: fibers
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
Date:      2026-01-22 21:28:57 +0000
URL:       https://git.openjdk.org/loom/commit/d6ebcf8a4f42b8e157083be90271e0df3b631033

8357471: GenShen: Share collector reserves between young and old

Reviewed-by: wkemper

! src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahAggressiveHeuristics.cpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahAggressiveHeuristics.hpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahCompactHeuristics.cpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahCompactHeuristics.hpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahGenerationalHeuristics.cpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahGenerationalHeuristics.hpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahGlobalHeuristics.cpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahGlobalHeuristics.hpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.cpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.hpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.hpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahPassiveHeuristics.cpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahPassiveHeuristics.hpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahStaticHeuristics.cpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahStaticHeuristics.hpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahYoungHeuristics.cpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahYoungHeuristics.hpp
! src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.hpp
! src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp
! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp
! src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp
! src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp
! src/hotspot/share/gc/shenandoah/shenandoahGeneration.hpp
! src/hotspot/share/gc/shenandoah/shenandoahGenerationalFullGC.cpp
! src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp
! src/hotspot/share/gc/shenandoah/shenandoahOldGC.cpp
! src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.cpp
! src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.hpp
! src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp
! src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp
! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp
! test/hotspot/gtest/gc/shenandoah/test_shenandoahOldHeuristic.cpp

Changeset: 25d2b52a
Branch: fibers
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
Date:      2026-01-22 21:48:28 +0000
URL:       https://git.openjdk.org/loom/commit/25d2b52ab97d116024872e567c1c1ffd814616d4

8328046: Need to keep leading zeros in TlsPremasterSecret of TLS1.3 DHKeyAgreement

Reviewed-by: hchao

! src/java.base/share/classes/sun/security/ssl/KAKeyDerivation.java

Changeset: 0f087a7f
Branch: fibers
Author:    SendaoYan <syan at openjdk.org>
Date:      2026-01-23 00:57:25 +0000
URL:       https://git.openjdk.org/loom/commit/0f087a7fef2d3979badefde02a1e85351379f18c

8376051: gc/stress/TestStressG1Uncommit.java fails assertLessThan: expected that xxx < xxx

Reviewed-by: tschatzl, shade

! test/hotspot/jtreg/gc/stress/TestStressG1Uncommit.java

Changeset: 7f2aa59f
Branch: fibers
Author:    Ioi Lam <iklam at openjdk.org>
Date:      2026-01-23 06:24:47 +0000
URL:       https://git.openjdk.org/loom/commit/7f2aa59f8220f302a3f8662eeca3291dcf86d2ad

8375654: Exclude all array classes from dynamic CDS archive

Reviewed-by: kvn, vlivanov

! src/hotspot/share/cds/archiveBuilder.cpp
! test/hotspot/jtreg/ProblemList-AotJdk.txt
+ test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/ArraySuperTest.java

Changeset: 39f0e6d6
Branch: fibers
Author:    Julian Waters <jwaters at openjdk.org>
Date:      2026-01-23 07:07:51 +0000
URL:       https://git.openjdk.org/loom/commit/39f0e6d6f91bf7e75862851ca0e00fc62780f938

8375241: Simplify --with-native-debug-symbols-level option implementation

Reviewed-by: erikj, shade

! make/autoconf/flags-cflags.m4

Changeset: 315bf07b
Branch: fibers
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2026-01-23 07:40:52 +0000
URL:       https://git.openjdk.org/loom/commit/315bf07b23ad6c5f86fc8fe976abd9e9a8548404

8375119: SwitchBoostraps.enumSwitch does not throw an NPE when lookup is null in some cases

Reviewed-by: liach

! src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java
! test/jdk/java/lang/runtime/SwitchBootstrapsTest.java

Changeset: ca37dba4
Branch: fibers
Author:    Volkan Yazici <vyazici at openjdk.org>
Date:      2026-01-23 08:27:27 +0000
URL:       https://git.openjdk.org/loom/commit/ca37dba4d40bf3f71c5489829c893346faec1c56

8376089: Increase QUIC idle timeout in H3FixedThreadPoolTest to collect more diagnostic

Reviewed-by: dfuchs, jpai

! test/jdk/java/net/httpclient/http3/H3FixedThreadPoolTest.java

Changeset: fa20391e
Branch: fibers
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-23 08:31:31 +0000
URL:       https://git.openjdk.org/loom/commit/fa20391e73102a5d6a5b0a760d95a4225c673e04

8375966: G1: Convert G1UpdateRegionLivenessAndSelectForRebuildTask to use Atomic<T>

Reviewed-by: kbarrett, shade

! src/hotspot/share/gc/g1/g1ConcurrentMarkRemarkTasks.cpp
! src/hotspot/share/gc/g1/g1ConcurrentMarkRemarkTasks.hpp

Changeset: 6f6966b2
Branch: fibers
Author:    Guanqiang Han <ghan at openjdk.org>
Committer: Dean Long <dlong at openjdk.org>
Date:      2026-01-23 11:37:30 +0000
URL:       https://git.openjdk.org/loom/commit/6f6966b28b2c5a18b001be49f5db429c667d7a8f

8374862: assert(false) failed: Attempting to acquire lock MDOExtraData_lock/nosafepoint-1 out of order with lock tty_lock/tty -- possible deadlock  (running with -XX:+Verbose -XX:+WizardMode  -XX:+PrintDeoptimizationDetails)

Reviewed-by: dholmes, dlong

! src/hotspot/share/interpreter/bytecodeTracer.cpp
! src/hotspot/share/interpreter/bytecodeTracer.hpp
! src/hotspot/share/oops/method.cpp
! src/hotspot/share/oops/method.hpp
! src/hotspot/share/runtime/vframeArray.cpp
+ test/hotspot/jtreg/compiler/uncommontrap/TestDeoptDetailsLockRank.java

Changeset: 3fb118a2
Branch: fibers
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
Date:      2026-01-23 16:55:38 +0000
URL:       https://git.openjdk.org/loom/commit/3fb118a29ed68f2fbb64de45468b0f014fa01890

8375692: Hotspot container tests assert with non-ascii vendor name

Reviewed-by: naoto, dholmes, syan

! test/hotspot/jtreg/containers/docker/TestJcmd.java
! test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetricsSubgroup.java
! test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java

Changeset: 40f7a18b
Branch: fibers
Author:    Chen Liang <liach at openjdk.org>
Date:      2026-01-23 17:32:53 +0000
URL:       https://git.openjdk.org/loom/commit/40f7a18b2dbf120a95432174664fa897331e8973

8373935: Migrate java/lang/invoke tests away from TestNG

Reviewed-by: jvernee, alanb

! test/jdk/java/lang/invoke/8147078/Test8147078.java
! test/jdk/java/lang/invoke/8177146/TestMethodHandleBind.java
! test/jdk/java/lang/invoke/AccessControlTest.java
! test/jdk/java/lang/invoke/ArrayConstructorTest.java
! test/jdk/java/lang/invoke/ArrayLengthTest.java
! test/jdk/java/lang/invoke/CallerSensitiveMethodHandle.java
! test/jdk/java/lang/invoke/ClassSpecializerTest.java
! test/jdk/java/lang/invoke/CompileThresholdBootstrapTest.java
! test/jdk/java/lang/invoke/ConstantIdentityMHTest.java
! test/jdk/java/lang/invoke/DefineClassTest.java
! test/jdk/java/lang/invoke/DropArgumentsTest.java
! test/jdk/java/lang/invoke/DropLookupModeTest.java
! test/jdk/java/lang/invoke/FilterArgumentsTest.java
! test/jdk/java/lang/invoke/FindAccessTest.java
! test/jdk/java/lang/invoke/FoldTest.java
! test/jdk/java/lang/invoke/InvokeGenericTest.java
! test/jdk/java/lang/invoke/InvokeMethodHandleWithBadArgument.java
! test/jdk/java/lang/invoke/InvokeWithArgumentsTest.java
! test/jdk/java/lang/invoke/JavaDocExamplesTest.java
! test/jdk/java/lang/invoke/JavaUtilConcurrentLookupTest.java
! test/jdk/java/lang/invoke/LoopCombinatorTest.java
! test/jdk/java/lang/invoke/MethodHandleInvokeUOE.java
! test/jdk/java/lang/invoke/MethodHandleProxies/Driver.java
! test/jdk/java/lang/invoke/MethodHandleProxies/Unnamed.java
! test/jdk/java/lang/invoke/MethodHandleProxies/m1/module-info.java
! test/jdk/java/lang/invoke/MethodHandleProxies/m1/p1/Main.java
! test/jdk/java/lang/invoke/MethodHandles/TestDropReturn.java
! test/jdk/java/lang/invoke/MethodHandles/TestTableSwitch.java
! test/jdk/java/lang/invoke/MethodHandles/classData/ClassDataTest.java
! test/jdk/java/lang/invoke/MethodHandles/ensureInitialized/Main.java
! test/jdk/java/lang/invoke/MethodHandles/privateLookupIn/Driver.java
! test/jdk/java/lang/invoke/MethodHandles/privateLookupIn/test/module-info.java
! test/jdk/java/lang/invoke/MethodHandles/privateLookupIn/test/p/PrivateLookupInTests.java
! test/jdk/java/lang/invoke/MethodHandlesCollectArgsTest.java
! test/jdk/java/lang/invoke/MethodHandlesGeneralTest.java
! test/jdk/java/lang/invoke/MethodTypeTest.java
! test/jdk/java/lang/invoke/PermuteArgsReturnVoidTest.java
! test/jdk/java/lang/invoke/PermuteArgsTest.java
! test/jdk/java/lang/invoke/SpreadCollectTest.java
! test/jdk/java/lang/invoke/TestVHInvokerCaching.java
! test/jdk/java/lang/invoke/ThrowExceptionsTest.java
! test/jdk/java/lang/invoke/TryFinallyTest.java
! test/jdk/java/lang/invoke/VarArgsTest.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleBaseByteArrayTest.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleBaseTest.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleMethodReferenceTest.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessBoolean.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessByte.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessChar.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessDouble.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessFloat.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessInt.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessLong.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessModeMethodNames.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessShort.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessString.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsChar.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsDouble.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsFloat.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsInt.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsLong.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsShort.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestExact.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessBoolean.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessByte.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessChar.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessDouble.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessFloat.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessInt.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessLong.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessShort.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessString.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodTypeBoolean.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodTypeByte.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodTypeChar.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodTypeDouble.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodTypeFloat.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodTypeInt.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodTypeLong.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodTypeShort.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodTypeString.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestReflection.java
! test/jdk/java/lang/invoke/VarHandles/X-VarHandleTestAccess.java.template
! test/jdk/java/lang/invoke/VarHandles/X-VarHandleTestByteArrayView.java.template
! test/jdk/java/lang/invoke/VarHandles/X-VarHandleTestMethodHandleAccess.java.template
! test/jdk/java/lang/invoke/VarHandles/X-VarHandleTestMethodType.java.template
! test/jdk/java/lang/invoke/VarHandles/accessibility/TestFieldLookupAccessibility.java
! test/jdk/java/lang/invoke/WrongMethodTypeTest.java
! test/jdk/java/lang/invoke/accessClassAndFindClass/TestAccessClass.java
! test/jdk/java/lang/invoke/accessClassAndFindClass/TestFindClass.java
! test/jdk/java/lang/invoke/accessClassAndFindClass/TestLookup.java
! test/jdk/java/lang/invoke/callerSensitive/CallerSensitiveAccess.java
! test/jdk/java/lang/invoke/condy/BootstrapMethodJumboArgsTest.java
! test/jdk/java/lang/invoke/condy/CondyBSMException.java
! test/jdk/java/lang/invoke/condy/CondyBSMInvocation.java
! test/jdk/java/lang/invoke/condy/CondyBSMValidationTest.java
! test/jdk/java/lang/invoke/condy/CondyInterfaceWithOverpassMethods.java
! test/jdk/java/lang/invoke/condy/CondyNameValidationTest.java
! test/jdk/java/lang/invoke/condy/CondyNestedTest.java
! test/jdk/java/lang/invoke/condy/CondyRepeatFailedResolution.java
! test/jdk/java/lang/invoke/condy/CondyReturnPrimitiveTest.java
! test/jdk/java/lang/invoke/condy/CondyStaticArgumentsTest.java
! test/jdk/java/lang/invoke/condy/CondyTypeValidationTest.java
! test/jdk/java/lang/invoke/condy/CondyWithGarbageTest.java
! test/jdk/java/lang/invoke/condy/CondyWrongType.java
! test/jdk/java/lang/invoke/condy/ConstantBootstrapsTest.java
! test/jdk/java/lang/invoke/defineHiddenClass/BasicTest.java
! test/jdk/java/lang/invoke/defineHiddenClass/HiddenNestmateTest.java
! test/jdk/java/lang/invoke/defineHiddenClass/LambdaNestedInnerTest.java
! test/jdk/java/lang/invoke/defineHiddenClass/PreviewHiddenClass.java
! test/jdk/java/lang/invoke/defineHiddenClass/StaticInvocableTest.java
! test/jdk/java/lang/invoke/defineHiddenClass/TypeDescriptorTest.java
! test/jdk/java/lang/invoke/defineHiddenClass/UnloadingTest.java
! test/jdk/java/lang/invoke/findSpecial/FindSpecialTest.java
! test/jdk/java/lang/invoke/lambda/LambdaFileEncodingSerialization.java
! test/jdk/java/lang/invoke/lambda/LambdaHiddenCaller.java
! test/jdk/java/lang/invoke/lambda/LogGeneratedClassesTest.java
! test/jdk/java/lang/invoke/lambda/invokeSpecial/InvokeSpecialMethodTest.java
! test/jdk/java/lang/invoke/lambda/superProtectedMethod/InheritedProtectedMethod.java
! test/jdk/java/lang/invoke/lambda/superProtectedMethod/ProtectedMethodInOtherPackage.java
! test/jdk/java/lang/invoke/lookup/ChainedLookupTest.java
! test/jdk/java/lang/invoke/lookup/LookupClassTest.java
! test/jdk/java/lang/invoke/lookup/SpecialStatic.java
! test/jdk/java/lang/invoke/modules/Driver.java
! test/jdk/java/lang/invoke/modules/Driver1.java
! test/jdk/java/lang/invoke/modules/m1/module-info.java
! test/jdk/java/lang/invoke/modules/m1/p1/Main.java
! test/jdk/java/lang/invoke/modules/m3/jdk/test/ModuleAccessTest.java
! test/jdk/java/lang/invoke/modules/m3/module-info.java

Changeset: 2c3ad0f4
Branch: fibers
Author:    Cesar Soares Lucas <cslucas at openjdk.org>
Date:      2026-01-23 17:56:04 +0000
URL:       https://git.openjdk.org/loom/commit/2c3ad0f425c75332412a5e8e5733dd0d073a09c8

8373021: aarch64: MacroAssembler::arrays_equals reads out of bounds

Reviewed-by: rkennke, aph

! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp

Changeset: e08fb3a9
Branch: fibers
Author:    Phil Race <prr at openjdk.org>
Date:      2026-01-23 18:19:23 +0000
URL:       https://git.openjdk.org/loom/commit/e08fb3a914ac348dc691ae3fc46c6bdbc34faf46

8375221: Update code to get PrinterResolution from CUPS/IPP print service

Reviewed-by: serb, psadhukhan

! src/java.desktop/unix/classes/sun/print/AttributeClass.java
! src/java.desktop/unix/classes/sun/print/IPPPrintService.java
! src/java.desktop/unix/native/common/awt/CUPSfuncs.c
! test/jdk/javax/print/PrintablePrintDPI.java

Changeset: e88edd0b
Branch: fibers
Author:    Phil Race <prr at openjdk.org>
Date:      2026-01-23 18:53:48 +0000
URL:       https://git.openjdk.org/loom/commit/e88edd0bc63e0a39f42a6a9e1ced61a79f84ad73

8375338: sun/awt/image/ImageRepresentation/LUTCompareTest.java fails with -Xcheck:jni

Reviewed-by: aivanov, serb, krk

! src/java.desktop/share/native/libawt/awt/image/awt_ImageRep.c
! test/jdk/sun/awt/image/ImageRepresentation/LUTCompareTest.java

Changeset: e617ccd5
Branch: fibers
Author:    Phil Race <prr at openjdk.org>
Date:      2026-01-23 19:12:54 +0000
URL:       https://git.openjdk.org/loom/commit/e617ccd529657440eaf20ed68794fea6f6c07fee

8375480: Remove usage of AppContext from javax/swing/text

Reviewed-by: serb, psadhukhan

! src/java.desktop/share/classes/javax/swing/text/JTextComponent.java
! src/java.desktop/share/classes/javax/swing/text/LayoutQueue.java
! src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java
! src/java.desktop/share/classes/javax/swing/text/html/parser/DTD.java
! src/java.desktop/share/classes/javax/swing/text/html/parser/Element.java
! src/java.desktop/share/classes/javax/swing/text/html/parser/ParserDelegator.java
- test/jdk/javax/swing/Security/6938813/bug6938813.java
- test/jdk/javax/swing/text/LayoutQueue/Test6588003.java
- test/jdk/javax/swing/text/html/parser/Test8017492.java

Changeset: e5512404
Branch: fibers
Author:    Valerie Peng <valeriep at openjdk.org>
Date:      2026-01-23 19:46:40 +0000
URL:       https://git.openjdk.org/loom/commit/e55124041e0181ca14ed95dc5f94d404b7900029

8375549: ConcurrentModificationException if jdk.crypto.disabledAlgorithms has multiple entries with known oid

Reviewed-by: mullan, coffeys

! src/java.base/share/classes/sun/security/util/CryptoAlgorithmConstraints.java
+ test/jdk/javax/crypto/Cipher/TestDisabledWithOids.java

Changeset: 44b74e16
Branch: fibers
Author:    Phil Race <prr at openjdk.org>
Date:      2026-01-23 20:20:22 +0000
URL:       https://git.openjdk.org/loom/commit/44b74e165e2d3ea79397d6f1ddbef94f51ac56c7

8375351: Remove usage of AppContext from print implementation

Reviewed-by: serb, tr

! src/java.desktop/share/classes/javax/print/PrintServiceLookup.java
! src/java.desktop/share/classes/javax/print/StreamPrintServiceFactory.java
! test/jdk/javax/print/PrintServiceLookup/FlushCustomClassLoader.java

Changeset: a3b1aa9f
Branch: fibers
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
Date:      2026-01-24 08:43:37 +0000
URL:       https://git.openjdk.org/loom/commit/a3b1aa9f7dce30a1c5967cb15a5d523e3d7ea72d

8374482: SA does not handle signal handler frame in mixed jstack

Reviewed-by: cjplummer, kevinw

! src/jdk.hotspot.agent/linux/native/libsaproc/symtab.c
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/LinuxDebugger.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/LinuxDebuggerLocal.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/amd64/LinuxAMD64CFrame.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/amd64/LinuxAMD64ThreadContext.java
+ test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedCore.java

Changeset: a40dbce4
Branch: fibers
Author:    Lei Zhu <korov9.c at gmail.com>
Committer: Chen Liang <liach at openjdk.org>
Date:      2026-01-24 14:19:40 +0000
URL:       https://git.openjdk.org/loom/commit/a40dbce495db9959624b72ff619e2e7ae7f7fb8b

8374293: Jshell throws an error and crashes when using keyword Public

Reviewed-by: jlahoda

! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java
! test/langtools/jdk/jshell/SnippetHighlightTest.java

Changeset: 93255602
Branch: fibers
Author:    SendaoYan <syan at openjdk.org>
Date:      2026-01-25 01:08:31 +0000
URL:       https://git.openjdk.org/loom/commit/932556026d6d49fe6f74d4ec4afcb72448611766

8375683: Add notes for sctp tests

Reviewed-by: erikj, vyazici

! doc/testing.html
! doc/testing.md

Changeset: 38b66b12
Branch: fibers
Author:    Xiaohong Gong <xgong at openjdk.org>
Date:      2026-01-26 01:50:57 +0000
URL:       https://git.openjdk.org/loom/commit/38b66b12581a3745a37589e32aa0fc880d27b4d4

8374043: C2:  assert(_base >= VectorMask && _base <= VectorZ) failed: Not a Vector

Reviewed-by: qamai, vlivanov

! src/hotspot/share/opto/vectorIntrinsics.cpp
! src/hotspot/share/opto/vectornode.cpp

Changeset: 90b54692
Branch: fibers
Author:    Arno Zeller <azeller at openjdk.org>
Committer: Jaikiran Pai <jpai at openjdk.org>
Date:      2026-01-26 08:34:56 +0000
URL:       https://git.openjdk.org/loom/commit/90b546925397ff7cdd1591291e1b87d0bac5604a

8375999: com/sun/jndi/ldap/LdapPoolTimeoutTest.java fails sporadically on Windows

Reviewed-by: jpai, mbaesken

! test/jdk/com/sun/jndi/ldap/LdapPoolTimeoutTest.java

Changeset: 2af271e5
Branch: fibers
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-26 09:12:39 +0000
URL:       https://git.openjdk.org/loom/commit/2af271e5e64260f05c01cb94bcf95f80fd69b4ff

8375436: G1: Convert G1CardSet classes to use Atomic<T>

Reviewed-by: kbarrett, iwalulya

! src/hotspot/share/gc/g1/g1CardSet.cpp
! src/hotspot/share/gc/g1/g1CardSet.hpp
! src/hotspot/share/gc/g1/g1CardSetContainers.hpp
! src/hotspot/share/gc/g1/g1CardSetContainers.inline.hpp
! src/hotspot/share/gc/g1/g1CardSetMemory.cpp
! test/hotspot/gtest/gc/g1/test_g1CardSetContainers.cpp

Changeset: e7cadd90
Branch: fibers
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-26 09:15:32 +0000
URL:       https://git.openjdk.org/loom/commit/e7cadd90b2872364443873aa4b4b4664bcf02f4d

8375981: G1: Convert G1RemSet helper classes to use Atomic<T>

Reviewed-by: shade, iwalulya

! src/hotspot/share/gc/g1/g1RemSet.cpp

Changeset: 45970469
Branch: fibers
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-26 09:16:11 +0000
URL:       https://git.openjdk.org/loom/commit/4597046984dedfd28bd76bd00dfc4b13ccb38dd4

8375974: G1: Convert G1FullCollector to use Atomic<T>

Reviewed-by: kbarrett, iwalulya

! src/hotspot/share/gc/g1/g1FullCollector.cpp
! src/hotspot/share/gc/g1/g1FullCollector.hpp
! src/hotspot/share/gc/g1/g1FullCollector.inline.hpp

Changeset: a49986c6
Branch: fibers
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-26 09:16:41 +0000
URL:       https://git.openjdk.org/loom/commit/a49986c62f4bcc4656f4ce0c7804a96875e9b6c6

8375964: G1: Convert G1BuildCandidateRegionsTask to use Atomic<T>

Reviewed-by: shade, iwalulya

! src/hotspot/share/gc/g1/g1CollectionSetChooser.cpp

Changeset: c3360ff5
Branch: fibers
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-26 09:17:01 +0000
URL:       https://git.openjdk.org/loom/commit/c3360ff51155bdd62b758c163351f57f4b410606

8375983: G1: Convert G1ConcurrentRefineStats to use Atomic<T>

Reviewed-by: kbarrett, iwalulya

! src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp
! src/hotspot/share/gc/g1/g1ConcurrentRefineStats.cpp
! src/hotspot/share/gc/g1/g1ConcurrentRefineStats.hpp
+ src/hotspot/share/gc/g1/g1ConcurrentRefineStats.inline.hpp
! src/hotspot/share/gc/g1/g1ConcurrentRefineSweepTask.cpp
! src/hotspot/share/gc/g1/g1ConcurrentRefineSweepTask.hpp
! src/hotspot/share/gc/g1/g1ConcurrentRefineThread.cpp
! src/hotspot/share/gc/g1/g1ConcurrentRefineThread.hpp
! src/hotspot/share/gc/g1/g1Policy.cpp
! src/hotspot/share/gc/g1/g1YoungGCPreEvacuateTasks.cpp

Changeset: 0bc2dc34
Branch: fibers
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-26 09:17:22 +0000
URL:       https://git.openjdk.org/loom/commit/0bc2dc3401f01b4727077a9844194d1654c3138c

8375971: G1: Convert G1EvacStats to use Atomic<T>

Reviewed-by: iwalulya, kbarrett

! src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp
! src/hotspot/share/gc/g1/g1EvacStats.cpp
! src/hotspot/share/gc/g1/g1EvacStats.hpp
! src/hotspot/share/gc/g1/g1EvacStats.inline.hpp

Changeset: 90d065e6
Branch: fibers
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2026-01-26 09:42:49 +0000
URL:       https://git.openjdk.org/loom/commit/90d065e677535e3f7caa7507f1526062b50ecc67

8375712: Convert java/lang/runtime tests to use JUnit

Reviewed-by: liach

! test/jdk/java/lang/runtime/ExactnessConversionsSupportTest.java
! test/jdk/java/lang/runtime/ObjectMethodsTest.java
! test/jdk/java/lang/runtime/SwitchBootstrapsTest.java

Changeset: 42c0126f
Branch: fibers
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-26 09:47:52 +0000
URL:       https://git.openjdk.org/loom/commit/42c0126fb2067b5f792e99af9ad131bab7502c08

8376119: G1: Convert volatiles in G1CMMarkStack to Atomic<T>

Reviewed-by: kbarrett, iwalulya

! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp
! src/hotspot/share/gc/g1/g1ConcurrentMark.inline.hpp

Changeset: 48d63687
Branch: fibers
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-26 10:15:57 +0000
URL:       https://git.openjdk.org/loom/commit/48d636872f1bd239d12823bf2f9d4aa32384f5e5

8376293: Bad copyright header in g1ConcurrentRefineStats.inline.hpp breaks the build

Reviewed-by: mhaessig, chagedorn

! src/hotspot/share/gc/g1/g1ConcurrentRefineStats.inline.hpp

Changeset: 30675faa
Branch: fibers
Author:    Quan Anh Mai <qamai at openjdk.org>
Date:      2026-01-26 11:18:21 +0000
URL:       https://git.openjdk.org/loom/commit/30675faa67d1bbb4acc729a841493bb8311416af

8375653: C2: CmpUNode::sub is not monotonic

Reviewed-by: chagedorn, mchevalier

! src/hotspot/share/opto/subnode.cpp
+ test/hotspot/jtreg/compiler/c2/gvn/CmpUNodeValueTests.java
+ test/hotspot/jtreg/compiler/ccp/TestCmpUMonotonicity.java

Changeset: 0f1b96a5
Branch: fibers
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2026-01-26 11:38:05 +0000
URL:       https://git.openjdk.org/loom/commit/0f1b96a50a3a79fd699bf34121df8451ffa37b8f

8375684: Avoid leak in KeystoreImpl.m when using CFArrayCreateMutable

Reviewed-by: clanger

! src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m

Changeset: de5c7a9e
Branch: fibers
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2026-01-26 12:16:05 +0000
URL:       https://git.openjdk.org/loom/commit/de5c7a9e8607b2a6219d98f9b81ddce4ca92baef

8374676: ZGC: Convert zAbort to use Atomic<T>

Reviewed-by: stefank, tschatzl

! src/hotspot/share/gc/z/zAbort.cpp
! src/hotspot/share/gc/z/zAbort.hpp
! src/hotspot/share/gc/z/zAbort.inline.hpp

Changeset: 8a9127fc
Branch: fibers
Author:    Daniel Fuchs <dfuchs at openjdk.org>
Date:      2026-01-26 12:57:23 +0000
URL:       https://git.openjdk.org/loom/commit/8a9127fc2d1f8c1cba952744e1a5a7533bb03537

8376118: java/net/httpclient/StreamingBody.java fails intermittently on Windows

Reviewed-by: vyazici, jpai

! test/jdk/java/net/httpclient/StreamingBody.java

Changeset: 37cb2282
Branch: fibers
Author:    Hannes Walln?fer <hannesw at openjdk.org>
Date:      2026-01-26 13:28:04 +0000
URL:       https://git.openjdk.org/loom/commit/37cb22826a8f644c699228b8a68852b59933ead5

8373679: Link color accessibility issue in dark theme

Reviewed-by: liach, nbenalla

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/stylesheet.css
! test/langtools/jdk/javadoc/doclet/checkStylesheetClasses/CheckStylesheetClasses.java

Changeset: 319e21e9
Branch: fibers
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2026-01-26 13:44:06 +0000
URL:       https://git.openjdk.org/loom/commit/319e21e9b48b4a9646c803e23d16f0b7df827d3f

8374677: ZGC: Convert zArray to use Atomic<T>

Reviewed-by: stefank, tschatzl

! src/hotspot/share/gc/z/zArray.hpp
! src/hotspot/share/gc/z/zArray.inline.hpp

Changeset: 512f95cf
Branch: fibers
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2026-01-26 13:53:12 +0000
URL:       https://git.openjdk.org/loom/commit/512f95cf2632167149e2118853ab4d6d636fe0a3

8374678: ZGC: Convert zForwarding to use Atomic<T>

Reviewed-by: stefank, eosterlund

! src/hotspot/share/gc/z/vmStructs_z.hpp
! src/hotspot/share/gc/z/zForwarding.cpp
! src/hotspot/share/gc/z/zForwarding.hpp
! src/hotspot/share/gc/z/zForwarding.inline.hpp

Changeset: fef85ff9
Branch: fibers
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2026-01-26 14:13:48 +0000
URL:       https://git.openjdk.org/loom/commit/fef85ff932055cd5385633f3b283e6201cdcaa68

8374679: ZGC: Convert zForwardingAllocator to use Atomic<T>

Reviewed-by: stefank, tschatzl

! src/hotspot/share/gc/z/zForwardingAllocator.cpp
! src/hotspot/share/gc/z/zForwardingAllocator.hpp
! src/hotspot/share/gc/z/zForwardingAllocator.inline.hpp

Changeset: b59f49a1
Branch: fibers
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2026-01-26 14:28:39 +0000
URL:       https://git.openjdk.org/loom/commit/b59f49a1c3e370f794291a1f948e67d2651ece11

8374680: ZGC: Convert zGeneration to use Atomic<T>

Reviewed-by: stefank, tschatzl

! src/hotspot/share/gc/z/zGeneration.cpp
! src/hotspot/share/gc/z/zGeneration.hpp

Changeset: 61b722d5
Branch: fibers
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2026-01-26 14:45:24 +0000
URL:       https://git.openjdk.org/loom/commit/61b722d59a799ba943476a03be3a1c7649aa0c27

8374681: ZGC: Convert zJNICritical to use Atomic<T>

Reviewed-by: tschatzl, stefank

! src/hotspot/share/gc/z/zJNICritical.cpp
! src/hotspot/share/gc/z/zJNICritical.hpp

Changeset: 99b4e05d
Branch: fibers
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2026-01-26 15:05:24 +0000
URL:       https://git.openjdk.org/loom/commit/99b4e05d502b68844699faa025e0d5bd51135d8f

8374682: ZGC: Convert zLiveMap to use Atomic<T>

Reviewed-by: stefank, tschatzl

! src/hotspot/share/gc/z/zLiveMap.cpp
! src/hotspot/share/gc/z/zLiveMap.hpp
! src/hotspot/share/gc/z/zLiveMap.inline.hpp

Changeset: 66485675
Branch: fibers
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2026-01-26 15:14:42 +0000
URL:       https://git.openjdk.org/loom/commit/664856757405e149bb98474872938e3a62b62302

8374683: ZGC: Convert zLock to use Atomic<T>

Reviewed-by: stefank, tschatzl

! src/hotspot/share/gc/z/zLock.hpp
! src/hotspot/share/gc/z/zLock.inline.hpp

Changeset: f4607ed0
Branch: fibers
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2026-01-26 15:35:59 +0000
URL:       https://git.openjdk.org/loom/commit/f4607ed0a7ea2504c1d72dd3dab0b21e583fa0e7

8374684: ZGC: Convert zMark to use Atomic<T>

Reviewed-by: stefank, tschatzl

! src/hotspot/share/gc/z/zMark.cpp
! src/hotspot/share/gc/z/zMark.hpp

Changeset: bbae38e5
Branch: fibers
Author:    Christian Hagedorn <chagedorn at openjdk.org>
Date:      2026-01-26 16:23:30 +0000
URL:       https://git.openjdk.org/loom/commit/bbae38e510efd8877daca5118f45893bb87f6eaa

8375272: [IR Framework] Miscellaneous clean-ups

Reviewed-by: mchevalier, dfenacci, thartmann

! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/compile.hpp
! test/hotspot/jtreg/compiler/lib/ir_framework/CompilePhase.java
! test/hotspot/jtreg/compiler/lib/ir_framework/TestFramework.java
! test/hotspot/jtreg/compiler/lib/ir_framework/driver/TestVMProcess.java
! test/hotspot/jtreg/compiler/lib/ir_framework/driver/irmatching/irmethod/IRMethod.java
! test/hotspot/jtreg/compiler/lib/ir_framework/driver/irmatching/irmethod/NotCompilableIRMethod.java
! test/hotspot/jtreg/compiler/lib/ir_framework/driver/irmatching/irmethod/NotCompilableIRMethodMatchResult.java
! test/hotspot/jtreg/compiler/lib/ir_framework/driver/irmatching/parser/ApplicableIRRulesParser.java
! test/hotspot/jtreg/compiler/lib/ir_framework/driver/irmatching/parser/IRMethodBuilder.java
! test/hotspot/jtreg/compiler/lib/ir_framework/driver/irmatching/parser/TestMethod.java
+ test/hotspot/jtreg/compiler/lib/ir_framework/driver/network/testvm/java/IRRuleIds.java
! test/hotspot/jtreg/compiler/lib/ir_framework/test/TestVM.java
! test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestCheckedTests.java
! test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestSetupTests.java

Changeset: 67beb9cd
Branch: fibers
Author:    Henry Jen <henryjen at openjdk.org>
Date:      2026-01-26 16:38:12 +0000
URL:       https://git.openjdk.org/loom/commit/67beb9cd812db2af49c62c95d69f2f27d0a20af8

8373924: Remove unreferenced ImageDecompressor::image_decompressor_close

Reviewed-by: alanb

! src/java.base/share/native/libjimage/imageDecompressor.cpp
! src/java.base/share/native/libjimage/imageDecompressor.hpp

Changeset: b42861a2
Branch: fibers
Author:    Henry Jen <henryjen at openjdk.org>
Date:      2026-01-26 17:19:44 +0000
URL:       https://git.openjdk.org/loom/commit/b42861a2aa5bf5fde348cf17c5e40134148de1b4

8373699: JLink: ModuleReader should be closed in JlinkTask.getReleaseInfo(mref)

Reviewed-by: alanb

! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java

Changeset: 3220c4cb
Branch: fibers
Author:    Chen Liang <liach at openjdk.org>
Date:      2026-01-26 18:32:15 +0000
URL:       https://git.openjdk.org/loom/commit/3220c4cb431a2c4eb8bb2d60f0d5046e40af69bd

8372696: Allow boot classes to explicitly opt-in for final field trusting

Reviewed-by: jvernee, jrose, alanb

! src/hotspot/share/ci/ciField.cpp
! src/hotspot/share/ci/ciInstanceKlass.cpp
! src/hotspot/share/ci/ciInstanceKlass.hpp
! src/hotspot/share/classfile/classFileParser.cpp
! src/hotspot/share/classfile/vmSymbols.hpp
! src/hotspot/share/oops/instanceKlass.hpp
! src/hotspot/share/oops/instanceKlassFlags.hpp
! src/java.base/share/classes/java/util/Optional.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java
+ src/java.base/share/classes/jdk/internal/vm/annotation/TrustFinalFields.java
+ test/hotspot/jtreg/compiler/corelibs/OptionalFold.java

Changeset: c69275dd
Branch: fibers
Author:    Phil Race <prr at openjdk.org>
Date:      2026-01-26 18:53:39 +0000
URL:       https://git.openjdk.org/loom/commit/c69275ddfe8c1769ae82b4ba64b2d6d80bbd8683

8376232: Remove AppContext from Swing synth related classes

Reviewed-by: serb, azvegint

! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java
! src/java.desktop/share/classes/javax/swing/plaf/nimbus/Effect.java
! src/java.desktop/share/classes/javax/swing/plaf/synth/ImagePainter.java
! src/java.desktop/share/classes/javax/swing/plaf/synth/Region.java
! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthButtonUI.java
! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java
- test/jdk/javax/swing/plaf/synth/7143614/bug7143614.java
- test/jdk/javax/swing/plaf/synth/Test6660049.java

Changeset: 82bd3831
Branch: fibers
Author:    Hannes Greule <hgreule at openjdk.org>
Date:      2026-01-26 20:13:03 +0000
URL:       https://git.openjdk.org/loom/commit/82bd3831b0f1e268ae76b31a803c86094add8e92

8374538: Wrong specification of MethodHandles.constant(...)

Reviewed-by: liach, jvernee

! src/java.base/share/classes/java/lang/invoke/MethodHandles.java

Changeset: 12570be6
Branch: fibers
Author:    Damon Nguyen <dnguyen at openjdk.org>
Date:      2026-01-26 21:13:01 +0000
URL:       https://git.openjdk.org/loom/commit/12570be64ae2114587e6de4ef79f79be961023b9

8376151: Test javax/swing/JFileChooser/4966171/bug4966171.java is failing with OOME

Reviewed-by: prr, azvegint, aivanov

! test/jdk/javax/swing/JFileChooser/4966171/bug4966171.java

Changeset: fdcc122a
Branch: fibers
Author:    Chen Liang <liach at openjdk.org>
Date:      2026-01-27 00:15:13 +0000
URL:       https://git.openjdk.org/loom/commit/fdcc122a9db2f6fdeb014e9e731cd3992bb3d0f3

8376422: Run compiler/corelibs/OptionalFold.java with tiered compilation

Reviewed-by: dholmes

! test/hotspot/jtreg/compiler/corelibs/OptionalFold.java

Changeset: cba7d88c
Branch: fibers
Author:    Ioi Lam <iklam at openjdk.org>
Date:      2026-01-27 03:16:43 +0000
URL:       https://git.openjdk.org/loom/commit/cba7d88ca427984ebb27a1634aab10a62c9eede1

8374549: Extend MetaspaceClosure to cover non-MetaspaceObj types

Reviewed-by: kvn, asmehra

+ src/hotspot/share/cds/aotGrowableArray.cpp
+ src/hotspot/share/cds/aotGrowableArray.hpp
+ src/hotspot/share/cds/aotGrowableArray.inline.hpp
! src/hotspot/share/cds/aotMapLogger.cpp
! src/hotspot/share/cds/aotMapLogger.hpp
! src/hotspot/share/cds/aotMetaspace.cpp
! src/hotspot/share/cds/archiveBuilder.cpp
! src/hotspot/share/cds/archiveBuilder.hpp
! src/hotspot/share/cds/cppVtables.cpp
! src/hotspot/share/cds/cppVtables.hpp
! src/hotspot/share/cds/dumpAllocStats.hpp
! src/hotspot/share/cds/heapShared.cpp
! src/hotspot/share/classfile/classLoaderDataShared.cpp
! src/hotspot/share/classfile/classLoaderDataShared.hpp
! src/hotspot/share/classfile/moduleEntry.cpp
! src/hotspot/share/classfile/moduleEntry.hpp
! src/hotspot/share/classfile/modules.cpp
! src/hotspot/share/classfile/modules.hpp
! src/hotspot/share/classfile/packageEntry.cpp
! src/hotspot/share/classfile/packageEntry.hpp
! src/hotspot/share/memory/allocation.cpp
! src/hotspot/share/memory/allocation.hpp
! src/hotspot/share/memory/metaspaceClosure.cpp
! src/hotspot/share/memory/metaspaceClosure.hpp
+ src/hotspot/share/memory/metaspaceClosureType.hpp
! src/hotspot/share/oops/array.hpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/runtime/sharedRuntime.hpp
! src/hotspot/share/utilities/growableArray.hpp
! test/hotspot/gtest/utilities/test_metaspaceClosure.cpp

Changeset: 5c05d6f2
Branch: fibers
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2026-01-27 08:26:00 +0000
URL:       https://git.openjdk.org/loom/commit/5c05d6f230e34cf409529d87b71f768a384ae4b4

8374686: ZGC: Convert zMarkTerminate to use Atomic<T>

Reviewed-by: stefank, kbarrett

! src/hotspot/share/gc/z/zMarkTerminate.hpp
! src/hotspot/share/gc/z/zMarkTerminate.inline.hpp

Changeset: bd92c68e
Branch: fibers
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2026-01-27 08:36:41 +0000
URL:       https://git.openjdk.org/loom/commit/bd92c68ef0aa7615c62626eb6baf4496b0137cad

8374687: ZGC: Convert zNMethodTableIteration to use Atomic<T>

Reviewed-by: stefank, tschatzl

! src/hotspot/share/gc/z/zNMethodTableIteration.cpp
! src/hotspot/share/gc/z/zNMethodTableIteration.hpp

Changeset: 6fda4417
Branch: fibers
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2026-01-27 08:42:44 +0000
URL:       https://git.openjdk.org/loom/commit/6fda44172e955d4e1d181598a97902ed5b16c57b

8374690: ZGC: Convert zRelocate to use Atomic<T>

Reviewed-by: stefank, tschatzl

! src/hotspot/share/gc/z/zRelocate.cpp
! src/hotspot/share/gc/z/zRelocate.hpp

Changeset: ee2deade
Branch: fibers
Author:    Varada M <varadam at openjdk.org>
Date:      2026-01-27 10:01:02 +0000
URL:       https://git.openjdk.org/loom/commit/ee2deaded82e5fbd94aff7dd22cf2d5c57caa94e

8371187: [BigEndian Platforms] Vector lane reversal error

Reviewed-by: mdoerr, amitkumar

! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortVector.java

Changeset: e0445c09
Branch: fibers
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
Date:      2026-01-27 10:25:58 +0000
URL:       https://git.openjdk.org/loom/commit/e0445c09f7a967843a56634f72c7545446791e15

8376294: ZipFile.Source.Key should not hold on to its BasicFileAttributes instance

Reviewed-by: jpai

! src/java.base/share/classes/java/util/zip/ZipFile.java

Changeset: b1aea552
Branch: fibers
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2026-01-27 10:26:29 +0000
URL:       https://git.openjdk.org/loom/commit/b1aea5520592e835e33762e349615fe616576103

8374695: ZGC: Convert zTLABUsage to use Atomic<T>

Reviewed-by: stefank, tschatzl

! src/hotspot/share/gc/z/zTLABUsage.cpp
! src/hotspot/share/gc/z/zTLABUsage.hpp

Changeset: 4ff5f3a8
Branch: fibers
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
Date:      2026-01-27 10:28:54 +0000
URL:       https://git.openjdk.org/loom/commit/4ff5f3a8c0910e9ed9d77586bd692c469bdf3460

8376271: ZipFile comment confusingly refers to "native" ZIP file implementation

Reviewed-by: jpai

! src/java.base/share/classes/java/util/zip/ZipFile.java

Changeset: 5990165d
Branch: fibers
Author:    Afshin Zafari <azafari at openjdk.org>
Date:      2026-01-27 11:55:25 +0000
URL:       https://git.openjdk.org/loom/commit/5990165d8257f39595b4c38f4e3e8d6ebb3393e8

8358957: [ubsan]: The assert in layout_helper_boolean_diffbit() in klass.hpp needs UB to fail

Reviewed-by: dlong, jsjolen

! src/hotspot/share/oops/klass.hpp

Changeset: 528bbe79
Branch: fibers
Author:    Casper Norrbin <cnorrbin at openjdk.org>
Date:      2026-01-27 12:33:43 +0000
URL:       https://git.openjdk.org/loom/commit/528bbe7919785c50dda583277f4146b25eb4d2a4

8376302: os::Machine::used_memory reports container used memory when running containerized

Reviewed-by: eosterlund, sgehwolf

! src/hotspot/share/runtime/os.cpp

Changeset: 40d1b642
Branch: fibers
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-27 12:51:20 +0000
URL:       https://git.openjdk.org/loom/commit/40d1b642a43fbc5c6ad21417f2f9d62d99db0201

8376191: Remove AtomicAccess include from files that do not use it in gc/shared

Reviewed-by: iwalulya, stefank

! src/hotspot/share/gc/shared/oopStorageSetParState.inline.hpp
! src/hotspot/share/gc/shared/partialArrayState.cpp
! src/hotspot/share/gc/shared/partialArrayTaskStepper.inline.hpp
! src/hotspot/share/gc/shared/taskqueue.cpp
! src/hotspot/share/gc/shared/taskqueue.inline.hpp
! src/hotspot/share/gc/shared/workerThread.cpp

Changeset: 992a8ef4
Branch: fibers
Author:    Daniel Gredler <dgredler at openjdk.org>
Date:      2026-01-27 13:20:26 +0000
URL:       https://git.openjdk.org/loom/commit/992a8ef46bc0a06c70fd5f4f307dbd20e402ed33

8376226: CharsetEncoder.canEncode(CharSequence) is much slower than necessary

Reviewed-by: alanb, naoto

! src/java.base/share/classes/java/nio/charset/Charset-X-Coder.java.template
! src/java.base/share/classes/sun/nio/cs/DoubleByte.java
! src/java.base/share/classes/sun/nio/cs/ISO_8859_1.java
! src/java.base/share/classes/sun/nio/cs/SingleByte.java
! src/java.base/share/classes/sun/nio/cs/US_ASCII.java
+ test/micro/org/openjdk/bench/java/nio/CharsetCanEncode.java

Changeset: 479ac8b2
Branch: fibers
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2026-01-27 13:30:14 +0000
URL:       https://git.openjdk.org/loom/commit/479ac8b2fdfbb64d26b34ff72abd61a1ce5f6c87

8376281: Remove USE_XLC_BUILTINS macro usage in AIX code

Reviewed-by: mdoerr, clanger

! src/hotspot/os_cpu/aix_ppc/os_aix_ppc.cpp
! src/hotspot/os_cpu/aix_ppc/prefetch_aix_ppc.inline.hpp

Changeset: 64b0ae6b
Branch: fibers
Author:    Wang Haomin <wanghaomin at openjdk.org>
Committer: Erik Joelsson <erikj at openjdk.org>
Date:      2026-01-27 14:21:44 +0000
URL:       https://git.openjdk.org/loom/commit/64b0ae6be8a7b70ed4cc08333447e9b73bdcbaca

8376276: Add javafx to allowed-list of CheckFiles

Reviewed-by: erikj, kcr

! test/jdk/build/CheckFiles.java

Changeset: bbb4b0d4
Branch: fibers
Author:    Chen Liang <liach at openjdk.org>
Date:      2026-01-27 14:51:04 +0000
URL:       https://git.openjdk.org/loom/commit/bbb4b0d498900f929225233008bbdbafaae5d709

8376277: Migrate java/lang/reflect tests away from TestNG

Reviewed-by: alanb

! test/jdk/java/lang/reflect/AccessibleObject/CanAccessTest.java
! test/jdk/java/lang/reflect/AccessibleObject/ModuleSetAccessibleTest.java
! test/jdk/java/lang/reflect/AccessibleObject/TrySetAccessibleTest.java
! test/jdk/java/lang/reflect/ChainedReflection.java
! test/jdk/java/lang/reflect/DefaultMethodMembers/FilterNotMostSpecific.java
! test/jdk/java/lang/reflect/DefaultStaticTest/DefaultStaticInvokeTest.java
! test/jdk/java/lang/reflect/DefaultStaticTest/DefaultStaticTestData.java
! test/jdk/java/lang/reflect/Field/NegativeTest.java
! test/jdk/java/lang/reflect/Generics/ThreadSafety.java
! test/jdk/java/lang/reflect/IllegalArgumentsTest.java
! test/jdk/java/lang/reflect/Method/MethodArityLimit.java
! test/jdk/java/lang/reflect/MethodHandleAccessorsTest.java
! test/jdk/java/lang/reflect/Proxy/DefaultMethods.java
! test/jdk/java/lang/reflect/Proxy/HiddenProxyInterface.java
! test/jdk/java/lang/reflect/Proxy/LazyInitializationTest.java
! test/jdk/java/lang/reflect/Proxy/ProxyClassAccessTest.java
! test/jdk/java/lang/reflect/Proxy/ProxyLayerTest.java
! test/jdk/java/lang/reflect/Proxy/ProxyTest.java
! test/jdk/java/lang/reflect/Proxy/SealedInterfaceTest.java
! test/jdk/java/lang/reflect/Proxy/TestVarArgs.java
! test/jdk/java/lang/reflect/Proxy/nonPublicProxy/DefaultMethodProxy.java
! test/jdk/java/lang/reflect/annotationSharing/AnnotationSharing.java
! test/jdk/java/lang/reflect/callerCache/CustomLoaderTest.java
! test/jdk/java/lang/reflect/callerCache/ReflectionCallerCacheTest.java
! test/jdk/java/lang/reflect/records/CheckEqualityIsBasedOnFields.java
! test/jdk/java/lang/reflect/records/IsRecordTest.java
! test/jdk/java/lang/reflect/records/RecordReflectionTest.java
! test/jdk/java/lang/reflect/sealed_classes/SealedClassesReflectionTest.java

Changeset: a5d0b051
Branch: fibers
Author:    Chen Liang <liach at openjdk.org>
Date:      2026-01-27 15:04:26 +0000
URL:       https://git.openjdk.org/loom/commit/a5d0b05136e34871366441a8c8e6bda5f20c617c

8376274: JSpec preview support and output enhancement

Reviewed-by: hannesw

! make/jdk/src/classes/build/tools/taglet/JSpec.java
! src/java.base/share/classes/java/lang/runtime/ExactConversionsSupport.java

Changeset: e8048c87
Branch: fibers
Author:    Roger Riggs <rriggs at openjdk.org>
Date:      2026-01-27 16:07:45 +0000
URL:       https://git.openjdk.org/loom/commit/e8048c87bc9c152932ee59cb674bdb6670db2a56

8376509: [process] Problemlist Test java/lang/ProcessBuilder/PipelineLeaksFD.java

Reviewed-by: jpai

! test/jdk/ProblemList.txt

Changeset: eb6e74b1
Branch: fibers
Author:    Nizar Benalla <nbenalla at openjdk.org>
Date:      2026-01-27 17:14:40 +0000
URL:       https://git.openjdk.org/loom/commit/eb6e74b1fa794bf16f572d5dbce157d1cae4c505

8374176: Update --release 26 symbol information for JDK 26 build 32

Reviewed-by: liach, iris, darcy

! src/jdk.compiler/share/data/symbols/java.base-Q.sym.txt

Changeset: fa1b1d67
Branch: fibers
Author:    Chris Plummer <cjplummer at openjdk.org>
Date:      2026-01-27 20:39:35 +0000
URL:       https://git.openjdk.org/loom/commit/fa1b1d677ac492dfdd3110b9303a4c2b009046c8

8375477: CoreUtils support for SA tests should attempt to locate and unzip core files when they have been zipped

Reviewed-by: lmesnik, kevinw

! test/lib/jdk/test/lib/util/CoreUtils.java

Changeset: 1161a640
Branch: fibers
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2026-01-28 06:58:50 +0000
URL:       https://git.openjdk.org/loom/commit/1161a640abe454b47de95ed73452a78535160deb

8373239: Test java/awt/print/PrinterJob/PageRanges.java fails with incorrect selection of printed pages

Reviewed-by: prr, aivanov

! src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java
! test/jdk/java/awt/print/PrinterJob/PageRanges.java

Changeset: 88c8a55a
Branch: fibers
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2026-01-28 07:44:31 +0000
URL:       https://git.openjdk.org/loom/commit/88c8a55a4337a857ac17ffff068f730f67cf5763

8373266: Strengthen constant CardTable base accesses

Reviewed-by: tschatzl, xpeng

! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/arm/gc/shared/cardTableBarrierSetAssembler_arm.cpp
! src/hotspot/cpu/ppc/gc/shared/cardTableBarrierSetAssembler_ppc.cpp
! src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp
! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp
! src/hotspot/cpu/s390/gc/shared/cardTableBarrierSetAssembler_s390.cpp
! src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.cpp
! src/hotspot/os_cpu/linux_arm/javaThread_linux_arm.cpp
! src/hotspot/share/ci/ciUtilities.cpp
! src/hotspot/share/ci/ciUtilities.hpp
! src/hotspot/share/compiler/disassembler.cpp
! src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.cpp
! src/hotspot/share/gc/shared/c2/cardTableBarrierSetC2.cpp
! src/hotspot/share/gc/shared/cardTableBarrierSet.hpp
! src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp

Changeset: b2cd3b0d
Branch: fibers
Author:    Roland Westrelin <roland at openjdk.org>
Date:      2026-01-28 08:00:11 +0000
URL:       https://git.openjdk.org/loom/commit/b2cd3b0d48bdabacfd421dee9b9f87a003e0e09d

8350330: C2: PhaseIdealLoop::add_parse_predicate() should mirror GraphKit::add_parse_predicate()

Reviewed-by: chagedorn, qamai

! src/hotspot/share/opto/loopnode.cpp
! src/hotspot/share/opto/loopnode.hpp
+ test/hotspot/jtreg/compiler/longcountedloops/TestLoopNestTooManyTraps.java

Changeset: 4ae4ffd5
Branch: fibers
Author:    Chad Rakoczy <chadrako at amazon.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
Date:      2026-01-28 08:08:36 +0000
URL:       https://git.openjdk.org/loom/commit/4ae4ffd5a3114aa2a3832818ee30dc38d9aa2b72

8374513: AArch64: Improve receiver type profiling reliability

Reviewed-by: shade, aph

! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.hpp
! src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp
! src/hotspot/cpu/aarch64/interp_masm_aarch64.hpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp
! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp

Changeset: 6afc0d8f
Branch: fibers
Author:    Saranya Natarajan <snatarajan at openjdk.org>
Date:      2026-01-28 09:38:20 +0000
URL:       https://git.openjdk.org/loom/commit/6afc0d8f39390d474ce8ba16533c30b4c7770388

8366861: Phase AFTER_LOOP_OPTS printed even though the method has no loops

Reviewed-by: chagedorn, dfenacci

! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/compile.hpp

Changeset: 127bfc9b
Branch: fibers
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
Date:      2026-01-28 11:11:07 +0000
URL:       https://git.openjdk.org/loom/commit/127bfc9b0dd122c78e702867a88e0847ec362e68

8374926: EnableX86ECoreOpts was not enabled on some hybrid CPU

Reviewed-by: vpaprotski, dholmes

! src/hotspot/cpu/x86/vm_version_x86.cpp

Changeset: 2a465cb0
Branch: fibers
Author:    Paul H?bner <phubner at openjdk.org>
Committer: Joel Sikstr?m <jsikstro at openjdk.org>
Date:      2026-01-28 13:14:51 +0000
URL:       https://git.openjdk.org/loom/commit/2a465cb0eba6ffe397cf3ad8c1def06bf7a1e392

8371777: Clean up preferred address of G1's archive region

Reviewed-by: stefank, jsikstro

! src/hotspot/share/cds/aotMappedHeapLoader.cpp
! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/hotspot/share/gc/g1/g1CollectedHeap.hpp

Changeset: 8c86b1bb
Branch: fibers
Author:    Roger Calnan <roger.calnan at oracle.com>
Committer: Weijun Wang <weijun at openjdk.org>
Date:      2026-01-28 14:18:52 +0000
URL:       https://git.openjdk.org/loom/commit/8c86b1bb1054b565cf23156d89ee8925a4e32597

8375325: add anchors to the options in the security man pages

Reviewed-by: weijun, hchao

! src/java.base/share/man/keytool.md
! src/java.security.jgss/windows/man/kinit.md
! src/java.security.jgss/windows/man/klist.md
! src/java.security.jgss/windows/man/ktab.md
! src/jdk.jartool/share/man/jarsigner.md

Changeset: 0704f86d
Branch: fibers
Author:    Alan Bateman <alan.bateman at oracle.com>
Date:      2026-01-28 14:48:58 +0000
URL:       https://git.openjdk.org/loom/commit/0704f86d208862c8b331514c5e40815eea4ce064

Merge branch 'master' into fibers

! src/hotspot/share/classfile/vmSymbols.hpp
! test/jdk/ProblemList.txt
! src/hotspot/share/classfile/vmSymbols.hpp
! test/jdk/ProblemList.txt

Changeset: 76e48b76
Branch: fibers
Author:    Alan Bateman <alan.bateman at oracle.com>
Date:      2026-01-27 11:57:57 +0000
URL:       https://git.openjdk.org/loom/commit/76e48b7689c3891aa4f66701e15554f6ae1e9a04

Cleanup

! src/hotspot/share/classfile/javaClasses.cpp
! src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java
! src/java.base/share/classes/jdk/internal/vm/ThreadSnapshot.java
= test/micro/org/openjdk/bench/java/lang/VirtualThreadGetStackTraceWhenSpinning.java

Changeset: e55ddb31
Branch: fibers
Author:    Alan Bateman <alan.bateman at oracle.com>
Date:      2026-01-28 14:49:20 +0000
URL:       https://git.openjdk.org/loom/commit/e55ddb31c320881cedfdcd1e832cbf1d191da49b

Merge loom into fibers


Changeset: ad057a6e
Branch: fibers
Author:    Alan Bateman <alan.bateman at oracle.com>
Date:      2026-01-28 18:46:47 +0000
URL:       https://git.openjdk.org/loom/commit/ad057a6e76a9249990e0560fb234e330b867136b

Experiment with TPE

! src/java.base/share/classes/java/lang/VirtualThread.java
! src/jdk.management/share/classes/com/sun/management/internal/VirtualThreadSchedulerImpls.java

Changeset: 11fd9498
Branch: fibers
Author:    Alan Bateman <alan.bateman at oracle.com>
Date:      2026-01-28 18:47:06 +0000
URL:       https://git.openjdk.org/loom/commit/11fd9498b2c4c71fe7d6ebd6b293864eaff9f75b

Merge loom into fibers



From duke at openjdk.org  Thu Jan 29 08:19:34 2026
From: duke at openjdk.org (duke)
Date: Thu, 29 Jan 2026 08:19:34 GMT
Subject: git: openjdk/loom: master: 84 new changesets
Message-ID: <1bd332d9-258a-45d2-a060-2e5aab3153c9@openjdk.org>

Changeset: 07f6617e
Branch: master
Author:    Brian Burkhalter <bpb at openjdk.org>
Date:      2026-01-22 16:11:33 +0000
URL:       https://git.openjdk.org/loom/commit/07f6617e0b2752b538b6c43250dd0bb65fd8c695

8367284: (fs) Support current working directory target in SecureDirectoryStream.move

Reviewed-by: alanb

! src/java.base/share/classes/java/nio/file/SecureDirectoryStream.java
! src/java.base/unix/classes/sun/nio/fs/UnixSecureDirectoryStream.java
! test/jdk/java/nio/file/DirectoryStream/SecureDS.java

Changeset: 8c82b58d
Branch: master
Author:    Alexander Zuev <kizune at openjdk.org>
Date:      2026-01-22 16:36:24 +0000
URL:       https://git.openjdk.org/loom/commit/8c82b58db960a178566514731e1f8dcbc59b0161

8286258: [Accessibility,macOS,VoiceOver] VoiceOver reads the spinner value wrong and sometime partially

Reviewed-by: psadhukhan, asemenov

! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/NavigableTextAccessibility.h
! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/NavigableTextAccessibility.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/SpinboxAccessibility.m
+ test/jdk/javax/accessibility/JSpinner/CustomSpinnerAccessibilityTest.java

Changeset: 5dfda66e
Branch: master
Author:    Henry Jen <henryjen at openjdk.org>
Date:      2026-01-22 17:21:44 +0000
URL:       https://git.openjdk.org/loom/commit/5dfda66e13df5a88a66a6e4b1ae1bcd4e20ac674

8373928: 4 Dangling pointer defect groups in java.c

Reviewed-by: bpb, alanb, jpai, jwaters

! src/java.base/share/native/libjli/java.c

Changeset: 96a2649e
Branch: master
Author:    Hai-May Chao <hchao at openjdk.org>
Date:      2026-01-22 17:41:00 +0000
URL:       https://git.openjdk.org/loom/commit/96a2649e29b8b4ff9b65b2314d430bc7637c5c61

8373408: SHA1withECDSA is not required for ECDHE and ECDSA

Reviewed-by: djelinski, ascarpino

! src/java.base/share/classes/sun/security/ssl/JsseJce.java

Changeset: f3121d10
Branch: master
Author:    Phil Race <prr at openjdk.org>
Date:      2026-01-22 20:16:44 +0000
URL:       https://git.openjdk.org/loom/commit/f3121d10237a933087dde926f83a12ce826cde02

8373931: Test javax/sound/sampled/Clip/AutoCloseTimeCheck.java timed out

Reviewed-by: dholmes, dnguyen, kizune

! test/jdk/javax/sound/sampled/Clip/AutoCloseTimeCheck.java

Changeset: d6ebcf8a
Branch: master
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
Date:      2026-01-22 21:28:57 +0000
URL:       https://git.openjdk.org/loom/commit/d6ebcf8a4f42b8e157083be90271e0df3b631033

8357471: GenShen: Share collector reserves between young and old

Reviewed-by: wkemper

! src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahAggressiveHeuristics.cpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahAggressiveHeuristics.hpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahCompactHeuristics.cpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahCompactHeuristics.hpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahGenerationalHeuristics.cpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahGenerationalHeuristics.hpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahGlobalHeuristics.cpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahGlobalHeuristics.hpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.cpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.hpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.hpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahPassiveHeuristics.cpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahPassiveHeuristics.hpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahStaticHeuristics.cpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahStaticHeuristics.hpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahYoungHeuristics.cpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahYoungHeuristics.hpp
! src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.hpp
! src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp
! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp
! src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp
! src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp
! src/hotspot/share/gc/shenandoah/shenandoahGeneration.hpp
! src/hotspot/share/gc/shenandoah/shenandoahGenerationalFullGC.cpp
! src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp
! src/hotspot/share/gc/shenandoah/shenandoahOldGC.cpp
! src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.cpp
! src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.hpp
! src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp
! src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp
! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp
! test/hotspot/gtest/gc/shenandoah/test_shenandoahOldHeuristic.cpp

Changeset: 25d2b52a
Branch: master
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
Date:      2026-01-22 21:48:28 +0000
URL:       https://git.openjdk.org/loom/commit/25d2b52ab97d116024872e567c1c1ffd814616d4

8328046: Need to keep leading zeros in TlsPremasterSecret of TLS1.3 DHKeyAgreement

Reviewed-by: hchao

! src/java.base/share/classes/sun/security/ssl/KAKeyDerivation.java

Changeset: 0f087a7f
Branch: master
Author:    SendaoYan <syan at openjdk.org>
Date:      2026-01-23 00:57:25 +0000
URL:       https://git.openjdk.org/loom/commit/0f087a7fef2d3979badefde02a1e85351379f18c

8376051: gc/stress/TestStressG1Uncommit.java fails assertLessThan: expected that xxx < xxx

Reviewed-by: tschatzl, shade

! test/hotspot/jtreg/gc/stress/TestStressG1Uncommit.java

Changeset: 7f2aa59f
Branch: master
Author:    Ioi Lam <iklam at openjdk.org>
Date:      2026-01-23 06:24:47 +0000
URL:       https://git.openjdk.org/loom/commit/7f2aa59f8220f302a3f8662eeca3291dcf86d2ad

8375654: Exclude all array classes from dynamic CDS archive

Reviewed-by: kvn, vlivanov

! src/hotspot/share/cds/archiveBuilder.cpp
! test/hotspot/jtreg/ProblemList-AotJdk.txt
+ test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/ArraySuperTest.java

Changeset: 39f0e6d6
Branch: master
Author:    Julian Waters <jwaters at openjdk.org>
Date:      2026-01-23 07:07:51 +0000
URL:       https://git.openjdk.org/loom/commit/39f0e6d6f91bf7e75862851ca0e00fc62780f938

8375241: Simplify --with-native-debug-symbols-level option implementation

Reviewed-by: erikj, shade

! make/autoconf/flags-cflags.m4

Changeset: 315bf07b
Branch: master
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2026-01-23 07:40:52 +0000
URL:       https://git.openjdk.org/loom/commit/315bf07b23ad6c5f86fc8fe976abd9e9a8548404

8375119: SwitchBoostraps.enumSwitch does not throw an NPE when lookup is null in some cases

Reviewed-by: liach

! src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java
! test/jdk/java/lang/runtime/SwitchBootstrapsTest.java

Changeset: ca37dba4
Branch: master
Author:    Volkan Yazici <vyazici at openjdk.org>
Date:      2026-01-23 08:27:27 +0000
URL:       https://git.openjdk.org/loom/commit/ca37dba4d40bf3f71c5489829c893346faec1c56

8376089: Increase QUIC idle timeout in H3FixedThreadPoolTest to collect more diagnostic

Reviewed-by: dfuchs, jpai

! test/jdk/java/net/httpclient/http3/H3FixedThreadPoolTest.java

Changeset: fa20391e
Branch: master
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-23 08:31:31 +0000
URL:       https://git.openjdk.org/loom/commit/fa20391e73102a5d6a5b0a760d95a4225c673e04

8375966: G1: Convert G1UpdateRegionLivenessAndSelectForRebuildTask to use Atomic<T>

Reviewed-by: kbarrett, shade

! src/hotspot/share/gc/g1/g1ConcurrentMarkRemarkTasks.cpp
! src/hotspot/share/gc/g1/g1ConcurrentMarkRemarkTasks.hpp

Changeset: 6f6966b2
Branch: master
Author:    Guanqiang Han <ghan at openjdk.org>
Committer: Dean Long <dlong at openjdk.org>
Date:      2026-01-23 11:37:30 +0000
URL:       https://git.openjdk.org/loom/commit/6f6966b28b2c5a18b001be49f5db429c667d7a8f

8374862: assert(false) failed: Attempting to acquire lock MDOExtraData_lock/nosafepoint-1 out of order with lock tty_lock/tty -- possible deadlock  (running with -XX:+Verbose -XX:+WizardMode  -XX:+PrintDeoptimizationDetails)

Reviewed-by: dholmes, dlong

! src/hotspot/share/interpreter/bytecodeTracer.cpp
! src/hotspot/share/interpreter/bytecodeTracer.hpp
! src/hotspot/share/oops/method.cpp
! src/hotspot/share/oops/method.hpp
! src/hotspot/share/runtime/vframeArray.cpp
+ test/hotspot/jtreg/compiler/uncommontrap/TestDeoptDetailsLockRank.java

Changeset: 3fb118a2
Branch: master
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
Date:      2026-01-23 16:55:38 +0000
URL:       https://git.openjdk.org/loom/commit/3fb118a29ed68f2fbb64de45468b0f014fa01890

8375692: Hotspot container tests assert with non-ascii vendor name

Reviewed-by: naoto, dholmes, syan

! test/hotspot/jtreg/containers/docker/TestJcmd.java
! test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetricsSubgroup.java
! test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java

Changeset: 40f7a18b
Branch: master
Author:    Chen Liang <liach at openjdk.org>
Date:      2026-01-23 17:32:53 +0000
URL:       https://git.openjdk.org/loom/commit/40f7a18b2dbf120a95432174664fa897331e8973

8373935: Migrate java/lang/invoke tests away from TestNG

Reviewed-by: jvernee, alanb

! test/jdk/java/lang/invoke/8147078/Test8147078.java
! test/jdk/java/lang/invoke/8177146/TestMethodHandleBind.java
! test/jdk/java/lang/invoke/AccessControlTest.java
! test/jdk/java/lang/invoke/ArrayConstructorTest.java
! test/jdk/java/lang/invoke/ArrayLengthTest.java
! test/jdk/java/lang/invoke/CallerSensitiveMethodHandle.java
! test/jdk/java/lang/invoke/ClassSpecializerTest.java
! test/jdk/java/lang/invoke/CompileThresholdBootstrapTest.java
! test/jdk/java/lang/invoke/ConstantIdentityMHTest.java
! test/jdk/java/lang/invoke/DefineClassTest.java
! test/jdk/java/lang/invoke/DropArgumentsTest.java
! test/jdk/java/lang/invoke/DropLookupModeTest.java
! test/jdk/java/lang/invoke/FilterArgumentsTest.java
! test/jdk/java/lang/invoke/FindAccessTest.java
! test/jdk/java/lang/invoke/FoldTest.java
! test/jdk/java/lang/invoke/InvokeGenericTest.java
! test/jdk/java/lang/invoke/InvokeMethodHandleWithBadArgument.java
! test/jdk/java/lang/invoke/InvokeWithArgumentsTest.java
! test/jdk/java/lang/invoke/JavaDocExamplesTest.java
! test/jdk/java/lang/invoke/JavaUtilConcurrentLookupTest.java
! test/jdk/java/lang/invoke/LoopCombinatorTest.java
! test/jdk/java/lang/invoke/MethodHandleInvokeUOE.java
! test/jdk/java/lang/invoke/MethodHandleProxies/Driver.java
! test/jdk/java/lang/invoke/MethodHandleProxies/Unnamed.java
! test/jdk/java/lang/invoke/MethodHandleProxies/m1/module-info.java
! test/jdk/java/lang/invoke/MethodHandleProxies/m1/p1/Main.java
! test/jdk/java/lang/invoke/MethodHandles/TestDropReturn.java
! test/jdk/java/lang/invoke/MethodHandles/TestTableSwitch.java
! test/jdk/java/lang/invoke/MethodHandles/classData/ClassDataTest.java
! test/jdk/java/lang/invoke/MethodHandles/ensureInitialized/Main.java
! test/jdk/java/lang/invoke/MethodHandles/privateLookupIn/Driver.java
! test/jdk/java/lang/invoke/MethodHandles/privateLookupIn/test/module-info.java
! test/jdk/java/lang/invoke/MethodHandles/privateLookupIn/test/p/PrivateLookupInTests.java
! test/jdk/java/lang/invoke/MethodHandlesCollectArgsTest.java
! test/jdk/java/lang/invoke/MethodHandlesGeneralTest.java
! test/jdk/java/lang/invoke/MethodTypeTest.java
! test/jdk/java/lang/invoke/PermuteArgsReturnVoidTest.java
! test/jdk/java/lang/invoke/PermuteArgsTest.java
! test/jdk/java/lang/invoke/SpreadCollectTest.java
! test/jdk/java/lang/invoke/TestVHInvokerCaching.java
! test/jdk/java/lang/invoke/ThrowExceptionsTest.java
! test/jdk/java/lang/invoke/TryFinallyTest.java
! test/jdk/java/lang/invoke/VarArgsTest.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleBaseByteArrayTest.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleBaseTest.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleMethodReferenceTest.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessBoolean.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessByte.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessChar.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessDouble.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessFloat.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessInt.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessLong.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessModeMethodNames.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessShort.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessString.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsChar.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsDouble.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsFloat.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsInt.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsLong.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsShort.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestExact.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessBoolean.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessByte.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessChar.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessDouble.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessFloat.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessInt.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessLong.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessShort.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessString.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodTypeBoolean.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodTypeByte.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodTypeChar.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodTypeDouble.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodTypeFloat.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodTypeInt.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodTypeLong.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodTypeShort.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodTypeString.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestReflection.java
! test/jdk/java/lang/invoke/VarHandles/X-VarHandleTestAccess.java.template
! test/jdk/java/lang/invoke/VarHandles/X-VarHandleTestByteArrayView.java.template
! test/jdk/java/lang/invoke/VarHandles/X-VarHandleTestMethodHandleAccess.java.template
! test/jdk/java/lang/invoke/VarHandles/X-VarHandleTestMethodType.java.template
! test/jdk/java/lang/invoke/VarHandles/accessibility/TestFieldLookupAccessibility.java
! test/jdk/java/lang/invoke/WrongMethodTypeTest.java
! test/jdk/java/lang/invoke/accessClassAndFindClass/TestAccessClass.java
! test/jdk/java/lang/invoke/accessClassAndFindClass/TestFindClass.java
! test/jdk/java/lang/invoke/accessClassAndFindClass/TestLookup.java
! test/jdk/java/lang/invoke/callerSensitive/CallerSensitiveAccess.java
! test/jdk/java/lang/invoke/condy/BootstrapMethodJumboArgsTest.java
! test/jdk/java/lang/invoke/condy/CondyBSMException.java
! test/jdk/java/lang/invoke/condy/CondyBSMInvocation.java
! test/jdk/java/lang/invoke/condy/CondyBSMValidationTest.java
! test/jdk/java/lang/invoke/condy/CondyInterfaceWithOverpassMethods.java
! test/jdk/java/lang/invoke/condy/CondyNameValidationTest.java
! test/jdk/java/lang/invoke/condy/CondyNestedTest.java
! test/jdk/java/lang/invoke/condy/CondyRepeatFailedResolution.java
! test/jdk/java/lang/invoke/condy/CondyReturnPrimitiveTest.java
! test/jdk/java/lang/invoke/condy/CondyStaticArgumentsTest.java
! test/jdk/java/lang/invoke/condy/CondyTypeValidationTest.java
! test/jdk/java/lang/invoke/condy/CondyWithGarbageTest.java
! test/jdk/java/lang/invoke/condy/CondyWrongType.java
! test/jdk/java/lang/invoke/condy/ConstantBootstrapsTest.java
! test/jdk/java/lang/invoke/defineHiddenClass/BasicTest.java
! test/jdk/java/lang/invoke/defineHiddenClass/HiddenNestmateTest.java
! test/jdk/java/lang/invoke/defineHiddenClass/LambdaNestedInnerTest.java
! test/jdk/java/lang/invoke/defineHiddenClass/PreviewHiddenClass.java
! test/jdk/java/lang/invoke/defineHiddenClass/StaticInvocableTest.java
! test/jdk/java/lang/invoke/defineHiddenClass/TypeDescriptorTest.java
! test/jdk/java/lang/invoke/defineHiddenClass/UnloadingTest.java
! test/jdk/java/lang/invoke/findSpecial/FindSpecialTest.java
! test/jdk/java/lang/invoke/lambda/LambdaFileEncodingSerialization.java
! test/jdk/java/lang/invoke/lambda/LambdaHiddenCaller.java
! test/jdk/java/lang/invoke/lambda/LogGeneratedClassesTest.java
! test/jdk/java/lang/invoke/lambda/invokeSpecial/InvokeSpecialMethodTest.java
! test/jdk/java/lang/invoke/lambda/superProtectedMethod/InheritedProtectedMethod.java
! test/jdk/java/lang/invoke/lambda/superProtectedMethod/ProtectedMethodInOtherPackage.java
! test/jdk/java/lang/invoke/lookup/ChainedLookupTest.java
! test/jdk/java/lang/invoke/lookup/LookupClassTest.java
! test/jdk/java/lang/invoke/lookup/SpecialStatic.java
! test/jdk/java/lang/invoke/modules/Driver.java
! test/jdk/java/lang/invoke/modules/Driver1.java
! test/jdk/java/lang/invoke/modules/m1/module-info.java
! test/jdk/java/lang/invoke/modules/m1/p1/Main.java
! test/jdk/java/lang/invoke/modules/m3/jdk/test/ModuleAccessTest.java
! test/jdk/java/lang/invoke/modules/m3/module-info.java

Changeset: 2c3ad0f4
Branch: master
Author:    Cesar Soares Lucas <cslucas at openjdk.org>
Date:      2026-01-23 17:56:04 +0000
URL:       https://git.openjdk.org/loom/commit/2c3ad0f425c75332412a5e8e5733dd0d073a09c8

8373021: aarch64: MacroAssembler::arrays_equals reads out of bounds

Reviewed-by: rkennke, aph

! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp

Changeset: e08fb3a9
Branch: master
Author:    Phil Race <prr at openjdk.org>
Date:      2026-01-23 18:19:23 +0000
URL:       https://git.openjdk.org/loom/commit/e08fb3a914ac348dc691ae3fc46c6bdbc34faf46

8375221: Update code to get PrinterResolution from CUPS/IPP print service

Reviewed-by: serb, psadhukhan

! src/java.desktop/unix/classes/sun/print/AttributeClass.java
! src/java.desktop/unix/classes/sun/print/IPPPrintService.java
! src/java.desktop/unix/native/common/awt/CUPSfuncs.c
! test/jdk/javax/print/PrintablePrintDPI.java

Changeset: e88edd0b
Branch: master
Author:    Phil Race <prr at openjdk.org>
Date:      2026-01-23 18:53:48 +0000
URL:       https://git.openjdk.org/loom/commit/e88edd0bc63e0a39f42a6a9e1ced61a79f84ad73

8375338: sun/awt/image/ImageRepresentation/LUTCompareTest.java fails with -Xcheck:jni

Reviewed-by: aivanov, serb, krk

! src/java.desktop/share/native/libawt/awt/image/awt_ImageRep.c
! test/jdk/sun/awt/image/ImageRepresentation/LUTCompareTest.java

Changeset: e617ccd5
Branch: master
Author:    Phil Race <prr at openjdk.org>
Date:      2026-01-23 19:12:54 +0000
URL:       https://git.openjdk.org/loom/commit/e617ccd529657440eaf20ed68794fea6f6c07fee

8375480: Remove usage of AppContext from javax/swing/text

Reviewed-by: serb, psadhukhan

! src/java.desktop/share/classes/javax/swing/text/JTextComponent.java
! src/java.desktop/share/classes/javax/swing/text/LayoutQueue.java
! src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java
! src/java.desktop/share/classes/javax/swing/text/html/parser/DTD.java
! src/java.desktop/share/classes/javax/swing/text/html/parser/Element.java
! src/java.desktop/share/classes/javax/swing/text/html/parser/ParserDelegator.java
- test/jdk/javax/swing/Security/6938813/bug6938813.java
- test/jdk/javax/swing/text/LayoutQueue/Test6588003.java
- test/jdk/javax/swing/text/html/parser/Test8017492.java

Changeset: e5512404
Branch: master
Author:    Valerie Peng <valeriep at openjdk.org>
Date:      2026-01-23 19:46:40 +0000
URL:       https://git.openjdk.org/loom/commit/e55124041e0181ca14ed95dc5f94d404b7900029

8375549: ConcurrentModificationException if jdk.crypto.disabledAlgorithms has multiple entries with known oid

Reviewed-by: mullan, coffeys

! src/java.base/share/classes/sun/security/util/CryptoAlgorithmConstraints.java
+ test/jdk/javax/crypto/Cipher/TestDisabledWithOids.java

Changeset: 44b74e16
Branch: master
Author:    Phil Race <prr at openjdk.org>
Date:      2026-01-23 20:20:22 +0000
URL:       https://git.openjdk.org/loom/commit/44b74e165e2d3ea79397d6f1ddbef94f51ac56c7

8375351: Remove usage of AppContext from print implementation

Reviewed-by: serb, tr

! src/java.desktop/share/classes/javax/print/PrintServiceLookup.java
! src/java.desktop/share/classes/javax/print/StreamPrintServiceFactory.java
! test/jdk/javax/print/PrintServiceLookup/FlushCustomClassLoader.java

Changeset: a3b1aa9f
Branch: master
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
Date:      2026-01-24 08:43:37 +0000
URL:       https://git.openjdk.org/loom/commit/a3b1aa9f7dce30a1c5967cb15a5d523e3d7ea72d

8374482: SA does not handle signal handler frame in mixed jstack

Reviewed-by: cjplummer, kevinw

! src/jdk.hotspot.agent/linux/native/libsaproc/symtab.c
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/LinuxDebugger.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/LinuxDebuggerLocal.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/amd64/LinuxAMD64CFrame.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/amd64/LinuxAMD64ThreadContext.java
+ test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedCore.java

Changeset: a40dbce4
Branch: master
Author:    Lei Zhu <korov9.c at gmail.com>
Committer: Chen Liang <liach at openjdk.org>
Date:      2026-01-24 14:19:40 +0000
URL:       https://git.openjdk.org/loom/commit/a40dbce495db9959624b72ff619e2e7ae7f7fb8b

8374293: Jshell throws an error and crashes when using keyword Public

Reviewed-by: jlahoda

! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysisImpl.java
! test/langtools/jdk/jshell/SnippetHighlightTest.java

Changeset: 93255602
Branch: master
Author:    SendaoYan <syan at openjdk.org>
Date:      2026-01-25 01:08:31 +0000
URL:       https://git.openjdk.org/loom/commit/932556026d6d49fe6f74d4ec4afcb72448611766

8375683: Add notes for sctp tests

Reviewed-by: erikj, vyazici

! doc/testing.html
! doc/testing.md

Changeset: 38b66b12
Branch: master
Author:    Xiaohong Gong <xgong at openjdk.org>
Date:      2026-01-26 01:50:57 +0000
URL:       https://git.openjdk.org/loom/commit/38b66b12581a3745a37589e32aa0fc880d27b4d4

8374043: C2:  assert(_base >= VectorMask && _base <= VectorZ) failed: Not a Vector

Reviewed-by: qamai, vlivanov

! src/hotspot/share/opto/vectorIntrinsics.cpp
! src/hotspot/share/opto/vectornode.cpp

Changeset: 90b54692
Branch: master
Author:    Arno Zeller <azeller at openjdk.org>
Committer: Jaikiran Pai <jpai at openjdk.org>
Date:      2026-01-26 08:34:56 +0000
URL:       https://git.openjdk.org/loom/commit/90b546925397ff7cdd1591291e1b87d0bac5604a

8375999: com/sun/jndi/ldap/LdapPoolTimeoutTest.java fails sporadically on Windows

Reviewed-by: jpai, mbaesken

! test/jdk/com/sun/jndi/ldap/LdapPoolTimeoutTest.java

Changeset: 2af271e5
Branch: master
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-26 09:12:39 +0000
URL:       https://git.openjdk.org/loom/commit/2af271e5e64260f05c01cb94bcf95f80fd69b4ff

8375436: G1: Convert G1CardSet classes to use Atomic<T>

Reviewed-by: kbarrett, iwalulya

! src/hotspot/share/gc/g1/g1CardSet.cpp
! src/hotspot/share/gc/g1/g1CardSet.hpp
! src/hotspot/share/gc/g1/g1CardSetContainers.hpp
! src/hotspot/share/gc/g1/g1CardSetContainers.inline.hpp
! src/hotspot/share/gc/g1/g1CardSetMemory.cpp
! test/hotspot/gtest/gc/g1/test_g1CardSetContainers.cpp

Changeset: e7cadd90
Branch: master
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-26 09:15:32 +0000
URL:       https://git.openjdk.org/loom/commit/e7cadd90b2872364443873aa4b4b4664bcf02f4d

8375981: G1: Convert G1RemSet helper classes to use Atomic<T>

Reviewed-by: shade, iwalulya

! src/hotspot/share/gc/g1/g1RemSet.cpp

Changeset: 45970469
Branch: master
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-26 09:16:11 +0000
URL:       https://git.openjdk.org/loom/commit/4597046984dedfd28bd76bd00dfc4b13ccb38dd4

8375974: G1: Convert G1FullCollector to use Atomic<T>

Reviewed-by: kbarrett, iwalulya

! src/hotspot/share/gc/g1/g1FullCollector.cpp
! src/hotspot/share/gc/g1/g1FullCollector.hpp
! src/hotspot/share/gc/g1/g1FullCollector.inline.hpp

Changeset: a49986c6
Branch: master
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-26 09:16:41 +0000
URL:       https://git.openjdk.org/loom/commit/a49986c62f4bcc4656f4ce0c7804a96875e9b6c6

8375964: G1: Convert G1BuildCandidateRegionsTask to use Atomic<T>

Reviewed-by: shade, iwalulya

! src/hotspot/share/gc/g1/g1CollectionSetChooser.cpp

Changeset: c3360ff5
Branch: master
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-26 09:17:01 +0000
URL:       https://git.openjdk.org/loom/commit/c3360ff51155bdd62b758c163351f57f4b410606

8375983: G1: Convert G1ConcurrentRefineStats to use Atomic<T>

Reviewed-by: kbarrett, iwalulya

! src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp
! src/hotspot/share/gc/g1/g1ConcurrentRefineStats.cpp
! src/hotspot/share/gc/g1/g1ConcurrentRefineStats.hpp
+ src/hotspot/share/gc/g1/g1ConcurrentRefineStats.inline.hpp
! src/hotspot/share/gc/g1/g1ConcurrentRefineSweepTask.cpp
! src/hotspot/share/gc/g1/g1ConcurrentRefineSweepTask.hpp
! src/hotspot/share/gc/g1/g1ConcurrentRefineThread.cpp
! src/hotspot/share/gc/g1/g1ConcurrentRefineThread.hpp
! src/hotspot/share/gc/g1/g1Policy.cpp
! src/hotspot/share/gc/g1/g1YoungGCPreEvacuateTasks.cpp

Changeset: 0bc2dc34
Branch: master
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-26 09:17:22 +0000
URL:       https://git.openjdk.org/loom/commit/0bc2dc3401f01b4727077a9844194d1654c3138c

8375971: G1: Convert G1EvacStats to use Atomic<T>

Reviewed-by: iwalulya, kbarrett

! src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp
! src/hotspot/share/gc/g1/g1EvacStats.cpp
! src/hotspot/share/gc/g1/g1EvacStats.hpp
! src/hotspot/share/gc/g1/g1EvacStats.inline.hpp

Changeset: 90d065e6
Branch: master
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2026-01-26 09:42:49 +0000
URL:       https://git.openjdk.org/loom/commit/90d065e677535e3f7caa7507f1526062b50ecc67

8375712: Convert java/lang/runtime tests to use JUnit

Reviewed-by: liach

! test/jdk/java/lang/runtime/ExactnessConversionsSupportTest.java
! test/jdk/java/lang/runtime/ObjectMethodsTest.java
! test/jdk/java/lang/runtime/SwitchBootstrapsTest.java

Changeset: 42c0126f
Branch: master
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-26 09:47:52 +0000
URL:       https://git.openjdk.org/loom/commit/42c0126fb2067b5f792e99af9ad131bab7502c08

8376119: G1: Convert volatiles in G1CMMarkStack to Atomic<T>

Reviewed-by: kbarrett, iwalulya

! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp
! src/hotspot/share/gc/g1/g1ConcurrentMark.inline.hpp

Changeset: 48d63687
Branch: master
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-26 10:15:57 +0000
URL:       https://git.openjdk.org/loom/commit/48d636872f1bd239d12823bf2f9d4aa32384f5e5

8376293: Bad copyright header in g1ConcurrentRefineStats.inline.hpp breaks the build

Reviewed-by: mhaessig, chagedorn

! src/hotspot/share/gc/g1/g1ConcurrentRefineStats.inline.hpp

Changeset: 30675faa
Branch: master
Author:    Quan Anh Mai <qamai at openjdk.org>
Date:      2026-01-26 11:18:21 +0000
URL:       https://git.openjdk.org/loom/commit/30675faa67d1bbb4acc729a841493bb8311416af

8375653: C2: CmpUNode::sub is not monotonic

Reviewed-by: chagedorn, mchevalier

! src/hotspot/share/opto/subnode.cpp
+ test/hotspot/jtreg/compiler/c2/gvn/CmpUNodeValueTests.java
+ test/hotspot/jtreg/compiler/ccp/TestCmpUMonotonicity.java

Changeset: 0f1b96a5
Branch: master
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2026-01-26 11:38:05 +0000
URL:       https://git.openjdk.org/loom/commit/0f1b96a50a3a79fd699bf34121df8451ffa37b8f

8375684: Avoid leak in KeystoreImpl.m when using CFArrayCreateMutable

Reviewed-by: clanger

! src/java.base/macosx/native/libosxsecurity/KeystoreImpl.m

Changeset: de5c7a9e
Branch: master
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2026-01-26 12:16:05 +0000
URL:       https://git.openjdk.org/loom/commit/de5c7a9e8607b2a6219d98f9b81ddce4ca92baef

8374676: ZGC: Convert zAbort to use Atomic<T>

Reviewed-by: stefank, tschatzl

! src/hotspot/share/gc/z/zAbort.cpp
! src/hotspot/share/gc/z/zAbort.hpp
! src/hotspot/share/gc/z/zAbort.inline.hpp

Changeset: 8a9127fc
Branch: master
Author:    Daniel Fuchs <dfuchs at openjdk.org>
Date:      2026-01-26 12:57:23 +0000
URL:       https://git.openjdk.org/loom/commit/8a9127fc2d1f8c1cba952744e1a5a7533bb03537

8376118: java/net/httpclient/StreamingBody.java fails intermittently on Windows

Reviewed-by: vyazici, jpai

! test/jdk/java/net/httpclient/StreamingBody.java

Changeset: 37cb2282
Branch: master
Author:    Hannes Walln?fer <hannesw at openjdk.org>
Date:      2026-01-26 13:28:04 +0000
URL:       https://git.openjdk.org/loom/commit/37cb22826a8f644c699228b8a68852b59933ead5

8373679: Link color accessibility issue in dark theme

Reviewed-by: liach, nbenalla

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/stylesheet.css
! test/langtools/jdk/javadoc/doclet/checkStylesheetClasses/CheckStylesheetClasses.java

Changeset: 319e21e9
Branch: master
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2026-01-26 13:44:06 +0000
URL:       https://git.openjdk.org/loom/commit/319e21e9b48b4a9646c803e23d16f0b7df827d3f

8374677: ZGC: Convert zArray to use Atomic<T>

Reviewed-by: stefank, tschatzl

! src/hotspot/share/gc/z/zArray.hpp
! src/hotspot/share/gc/z/zArray.inline.hpp

Changeset: 512f95cf
Branch: master
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2026-01-26 13:53:12 +0000
URL:       https://git.openjdk.org/loom/commit/512f95cf2632167149e2118853ab4d6d636fe0a3

8374678: ZGC: Convert zForwarding to use Atomic<T>

Reviewed-by: stefank, eosterlund

! src/hotspot/share/gc/z/vmStructs_z.hpp
! src/hotspot/share/gc/z/zForwarding.cpp
! src/hotspot/share/gc/z/zForwarding.hpp
! src/hotspot/share/gc/z/zForwarding.inline.hpp

Changeset: fef85ff9
Branch: master
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2026-01-26 14:13:48 +0000
URL:       https://git.openjdk.org/loom/commit/fef85ff932055cd5385633f3b283e6201cdcaa68

8374679: ZGC: Convert zForwardingAllocator to use Atomic<T>

Reviewed-by: stefank, tschatzl

! src/hotspot/share/gc/z/zForwardingAllocator.cpp
! src/hotspot/share/gc/z/zForwardingAllocator.hpp
! src/hotspot/share/gc/z/zForwardingAllocator.inline.hpp

Changeset: b59f49a1
Branch: master
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2026-01-26 14:28:39 +0000
URL:       https://git.openjdk.org/loom/commit/b59f49a1c3e370f794291a1f948e67d2651ece11

8374680: ZGC: Convert zGeneration to use Atomic<T>

Reviewed-by: stefank, tschatzl

! src/hotspot/share/gc/z/zGeneration.cpp
! src/hotspot/share/gc/z/zGeneration.hpp

Changeset: 61b722d5
Branch: master
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2026-01-26 14:45:24 +0000
URL:       https://git.openjdk.org/loom/commit/61b722d59a799ba943476a03be3a1c7649aa0c27

8374681: ZGC: Convert zJNICritical to use Atomic<T>

Reviewed-by: tschatzl, stefank

! src/hotspot/share/gc/z/zJNICritical.cpp
! src/hotspot/share/gc/z/zJNICritical.hpp

Changeset: 99b4e05d
Branch: master
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2026-01-26 15:05:24 +0000
URL:       https://git.openjdk.org/loom/commit/99b4e05d502b68844699faa025e0d5bd51135d8f

8374682: ZGC: Convert zLiveMap to use Atomic<T>

Reviewed-by: stefank, tschatzl

! src/hotspot/share/gc/z/zLiveMap.cpp
! src/hotspot/share/gc/z/zLiveMap.hpp
! src/hotspot/share/gc/z/zLiveMap.inline.hpp

Changeset: 66485675
Branch: master
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2026-01-26 15:14:42 +0000
URL:       https://git.openjdk.org/loom/commit/664856757405e149bb98474872938e3a62b62302

8374683: ZGC: Convert zLock to use Atomic<T>

Reviewed-by: stefank, tschatzl

! src/hotspot/share/gc/z/zLock.hpp
! src/hotspot/share/gc/z/zLock.inline.hpp

Changeset: f4607ed0
Branch: master
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2026-01-26 15:35:59 +0000
URL:       https://git.openjdk.org/loom/commit/f4607ed0a7ea2504c1d72dd3dab0b21e583fa0e7

8374684: ZGC: Convert zMark to use Atomic<T>

Reviewed-by: stefank, tschatzl

! src/hotspot/share/gc/z/zMark.cpp
! src/hotspot/share/gc/z/zMark.hpp

Changeset: bbae38e5
Branch: master
Author:    Christian Hagedorn <chagedorn at openjdk.org>
Date:      2026-01-26 16:23:30 +0000
URL:       https://git.openjdk.org/loom/commit/bbae38e510efd8877daca5118f45893bb87f6eaa

8375272: [IR Framework] Miscellaneous clean-ups

Reviewed-by: mchevalier, dfenacci, thartmann

! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/compile.hpp
! test/hotspot/jtreg/compiler/lib/ir_framework/CompilePhase.java
! test/hotspot/jtreg/compiler/lib/ir_framework/TestFramework.java
! test/hotspot/jtreg/compiler/lib/ir_framework/driver/TestVMProcess.java
! test/hotspot/jtreg/compiler/lib/ir_framework/driver/irmatching/irmethod/IRMethod.java
! test/hotspot/jtreg/compiler/lib/ir_framework/driver/irmatching/irmethod/NotCompilableIRMethod.java
! test/hotspot/jtreg/compiler/lib/ir_framework/driver/irmatching/irmethod/NotCompilableIRMethodMatchResult.java
! test/hotspot/jtreg/compiler/lib/ir_framework/driver/irmatching/parser/ApplicableIRRulesParser.java
! test/hotspot/jtreg/compiler/lib/ir_framework/driver/irmatching/parser/IRMethodBuilder.java
! test/hotspot/jtreg/compiler/lib/ir_framework/driver/irmatching/parser/TestMethod.java
+ test/hotspot/jtreg/compiler/lib/ir_framework/driver/network/testvm/java/IRRuleIds.java
! test/hotspot/jtreg/compiler/lib/ir_framework/test/TestVM.java
! test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestCheckedTests.java
! test/hotspot/jtreg/testlibrary_tests/ir_framework/tests/TestSetupTests.java

Changeset: 67beb9cd
Branch: master
Author:    Henry Jen <henryjen at openjdk.org>
Date:      2026-01-26 16:38:12 +0000
URL:       https://git.openjdk.org/loom/commit/67beb9cd812db2af49c62c95d69f2f27d0a20af8

8373924: Remove unreferenced ImageDecompressor::image_decompressor_close

Reviewed-by: alanb

! src/java.base/share/native/libjimage/imageDecompressor.cpp
! src/java.base/share/native/libjimage/imageDecompressor.hpp

Changeset: b42861a2
Branch: master
Author:    Henry Jen <henryjen at openjdk.org>
Date:      2026-01-26 17:19:44 +0000
URL:       https://git.openjdk.org/loom/commit/b42861a2aa5bf5fde348cf17c5e40134148de1b4

8373699: JLink: ModuleReader should be closed in JlinkTask.getReleaseInfo(mref)

Reviewed-by: alanb

! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java

Changeset: 3220c4cb
Branch: master
Author:    Chen Liang <liach at openjdk.org>
Date:      2026-01-26 18:32:15 +0000
URL:       https://git.openjdk.org/loom/commit/3220c4cb431a2c4eb8bb2d60f0d5046e40af69bd

8372696: Allow boot classes to explicitly opt-in for final field trusting

Reviewed-by: jvernee, jrose, alanb

! src/hotspot/share/ci/ciField.cpp
! src/hotspot/share/ci/ciInstanceKlass.cpp
! src/hotspot/share/ci/ciInstanceKlass.hpp
! src/hotspot/share/classfile/classFileParser.cpp
! src/hotspot/share/classfile/vmSymbols.hpp
! src/hotspot/share/oops/instanceKlass.hpp
! src/hotspot/share/oops/instanceKlassFlags.hpp
! src/java.base/share/classes/java/util/Optional.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java
+ src/java.base/share/classes/jdk/internal/vm/annotation/TrustFinalFields.java
+ test/hotspot/jtreg/compiler/corelibs/OptionalFold.java

Changeset: c69275dd
Branch: master
Author:    Phil Race <prr at openjdk.org>
Date:      2026-01-26 18:53:39 +0000
URL:       https://git.openjdk.org/loom/commit/c69275ddfe8c1769ae82b4ba64b2d6d80bbd8683

8376232: Remove AppContext from Swing synth related classes

Reviewed-by: serb, azvegint

! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java
! src/java.desktop/share/classes/javax/swing/plaf/nimbus/Effect.java
! src/java.desktop/share/classes/javax/swing/plaf/synth/ImagePainter.java
! src/java.desktop/share/classes/javax/swing/plaf/synth/Region.java
! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthButtonUI.java
! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java
- test/jdk/javax/swing/plaf/synth/7143614/bug7143614.java
- test/jdk/javax/swing/plaf/synth/Test6660049.java

Changeset: 82bd3831
Branch: master
Author:    Hannes Greule <hgreule at openjdk.org>
Date:      2026-01-26 20:13:03 +0000
URL:       https://git.openjdk.org/loom/commit/82bd3831b0f1e268ae76b31a803c86094add8e92

8374538: Wrong specification of MethodHandles.constant(...)

Reviewed-by: liach, jvernee

! src/java.base/share/classes/java/lang/invoke/MethodHandles.java

Changeset: 12570be6
Branch: master
Author:    Damon Nguyen <dnguyen at openjdk.org>
Date:      2026-01-26 21:13:01 +0000
URL:       https://git.openjdk.org/loom/commit/12570be64ae2114587e6de4ef79f79be961023b9

8376151: Test javax/swing/JFileChooser/4966171/bug4966171.java is failing with OOME

Reviewed-by: prr, azvegint, aivanov

! test/jdk/javax/swing/JFileChooser/4966171/bug4966171.java

Changeset: fdcc122a
Branch: master
Author:    Chen Liang <liach at openjdk.org>
Date:      2026-01-27 00:15:13 +0000
URL:       https://git.openjdk.org/loom/commit/fdcc122a9db2f6fdeb014e9e731cd3992bb3d0f3

8376422: Run compiler/corelibs/OptionalFold.java with tiered compilation

Reviewed-by: dholmes

! test/hotspot/jtreg/compiler/corelibs/OptionalFold.java

Changeset: cba7d88c
Branch: master
Author:    Ioi Lam <iklam at openjdk.org>
Date:      2026-01-27 03:16:43 +0000
URL:       https://git.openjdk.org/loom/commit/cba7d88ca427984ebb27a1634aab10a62c9eede1

8374549: Extend MetaspaceClosure to cover non-MetaspaceObj types

Reviewed-by: kvn, asmehra

+ src/hotspot/share/cds/aotGrowableArray.cpp
+ src/hotspot/share/cds/aotGrowableArray.hpp
+ src/hotspot/share/cds/aotGrowableArray.inline.hpp
! src/hotspot/share/cds/aotMapLogger.cpp
! src/hotspot/share/cds/aotMapLogger.hpp
! src/hotspot/share/cds/aotMetaspace.cpp
! src/hotspot/share/cds/archiveBuilder.cpp
! src/hotspot/share/cds/archiveBuilder.hpp
! src/hotspot/share/cds/cppVtables.cpp
! src/hotspot/share/cds/cppVtables.hpp
! src/hotspot/share/cds/dumpAllocStats.hpp
! src/hotspot/share/cds/heapShared.cpp
! src/hotspot/share/classfile/classLoaderDataShared.cpp
! src/hotspot/share/classfile/classLoaderDataShared.hpp
! src/hotspot/share/classfile/moduleEntry.cpp
! src/hotspot/share/classfile/moduleEntry.hpp
! src/hotspot/share/classfile/modules.cpp
! src/hotspot/share/classfile/modules.hpp
! src/hotspot/share/classfile/packageEntry.cpp
! src/hotspot/share/classfile/packageEntry.hpp
! src/hotspot/share/memory/allocation.cpp
! src/hotspot/share/memory/allocation.hpp
! src/hotspot/share/memory/metaspaceClosure.cpp
! src/hotspot/share/memory/metaspaceClosure.hpp
+ src/hotspot/share/memory/metaspaceClosureType.hpp
! src/hotspot/share/oops/array.hpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/runtime/sharedRuntime.hpp
! src/hotspot/share/utilities/growableArray.hpp
! test/hotspot/gtest/utilities/test_metaspaceClosure.cpp

Changeset: 5c05d6f2
Branch: master
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2026-01-27 08:26:00 +0000
URL:       https://git.openjdk.org/loom/commit/5c05d6f230e34cf409529d87b71f768a384ae4b4

8374686: ZGC: Convert zMarkTerminate to use Atomic<T>

Reviewed-by: stefank, kbarrett

! src/hotspot/share/gc/z/zMarkTerminate.hpp
! src/hotspot/share/gc/z/zMarkTerminate.inline.hpp

Changeset: bd92c68e
Branch: master
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2026-01-27 08:36:41 +0000
URL:       https://git.openjdk.org/loom/commit/bd92c68ef0aa7615c62626eb6baf4496b0137cad

8374687: ZGC: Convert zNMethodTableIteration to use Atomic<T>

Reviewed-by: stefank, tschatzl

! src/hotspot/share/gc/z/zNMethodTableIteration.cpp
! src/hotspot/share/gc/z/zNMethodTableIteration.hpp

Changeset: 6fda4417
Branch: master
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2026-01-27 08:42:44 +0000
URL:       https://git.openjdk.org/loom/commit/6fda44172e955d4e1d181598a97902ed5b16c57b

8374690: ZGC: Convert zRelocate to use Atomic<T>

Reviewed-by: stefank, tschatzl

! src/hotspot/share/gc/z/zRelocate.cpp
! src/hotspot/share/gc/z/zRelocate.hpp

Changeset: ee2deade
Branch: master
Author:    Varada M <varadam at openjdk.org>
Date:      2026-01-27 10:01:02 +0000
URL:       https://git.openjdk.org/loom/commit/ee2deaded82e5fbd94aff7dd22cf2d5c57caa94e

8371187: [BigEndian Platforms] Vector lane reversal error

Reviewed-by: mdoerr, amitkumar

! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortVector.java

Changeset: e0445c09
Branch: master
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
Date:      2026-01-27 10:25:58 +0000
URL:       https://git.openjdk.org/loom/commit/e0445c09f7a967843a56634f72c7545446791e15

8376294: ZipFile.Source.Key should not hold on to its BasicFileAttributes instance

Reviewed-by: jpai

! src/java.base/share/classes/java/util/zip/ZipFile.java

Changeset: b1aea552
Branch: master
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2026-01-27 10:26:29 +0000
URL:       https://git.openjdk.org/loom/commit/b1aea5520592e835e33762e349615fe616576103

8374695: ZGC: Convert zTLABUsage to use Atomic<T>

Reviewed-by: stefank, tschatzl

! src/hotspot/share/gc/z/zTLABUsage.cpp
! src/hotspot/share/gc/z/zTLABUsage.hpp

Changeset: 4ff5f3a8
Branch: master
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
Date:      2026-01-27 10:28:54 +0000
URL:       https://git.openjdk.org/loom/commit/4ff5f3a8c0910e9ed9d77586bd692c469bdf3460

8376271: ZipFile comment confusingly refers to "native" ZIP file implementation

Reviewed-by: jpai

! src/java.base/share/classes/java/util/zip/ZipFile.java

Changeset: 5990165d
Branch: master
Author:    Afshin Zafari <azafari at openjdk.org>
Date:      2026-01-27 11:55:25 +0000
URL:       https://git.openjdk.org/loom/commit/5990165d8257f39595b4c38f4e3e8d6ebb3393e8

8358957: [ubsan]: The assert in layout_helper_boolean_diffbit() in klass.hpp needs UB to fail

Reviewed-by: dlong, jsjolen

! src/hotspot/share/oops/klass.hpp

Changeset: 528bbe79
Branch: master
Author:    Casper Norrbin <cnorrbin at openjdk.org>
Date:      2026-01-27 12:33:43 +0000
URL:       https://git.openjdk.org/loom/commit/528bbe7919785c50dda583277f4146b25eb4d2a4

8376302: os::Machine::used_memory reports container used memory when running containerized

Reviewed-by: eosterlund, sgehwolf

! src/hotspot/share/runtime/os.cpp

Changeset: 40d1b642
Branch: master
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-27 12:51:20 +0000
URL:       https://git.openjdk.org/loom/commit/40d1b642a43fbc5c6ad21417f2f9d62d99db0201

8376191: Remove AtomicAccess include from files that do not use it in gc/shared

Reviewed-by: iwalulya, stefank

! src/hotspot/share/gc/shared/oopStorageSetParState.inline.hpp
! src/hotspot/share/gc/shared/partialArrayState.cpp
! src/hotspot/share/gc/shared/partialArrayTaskStepper.inline.hpp
! src/hotspot/share/gc/shared/taskqueue.cpp
! src/hotspot/share/gc/shared/taskqueue.inline.hpp
! src/hotspot/share/gc/shared/workerThread.cpp

Changeset: 992a8ef4
Branch: master
Author:    Daniel Gredler <dgredler at openjdk.org>
Date:      2026-01-27 13:20:26 +0000
URL:       https://git.openjdk.org/loom/commit/992a8ef46bc0a06c70fd5f4f307dbd20e402ed33

8376226: CharsetEncoder.canEncode(CharSequence) is much slower than necessary

Reviewed-by: alanb, naoto

! src/java.base/share/classes/java/nio/charset/Charset-X-Coder.java.template
! src/java.base/share/classes/sun/nio/cs/DoubleByte.java
! src/java.base/share/classes/sun/nio/cs/ISO_8859_1.java
! src/java.base/share/classes/sun/nio/cs/SingleByte.java
! src/java.base/share/classes/sun/nio/cs/US_ASCII.java
+ test/micro/org/openjdk/bench/java/nio/CharsetCanEncode.java

Changeset: 479ac8b2
Branch: master
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2026-01-27 13:30:14 +0000
URL:       https://git.openjdk.org/loom/commit/479ac8b2fdfbb64d26b34ff72abd61a1ce5f6c87

8376281: Remove USE_XLC_BUILTINS macro usage in AIX code

Reviewed-by: mdoerr, clanger

! src/hotspot/os_cpu/aix_ppc/os_aix_ppc.cpp
! src/hotspot/os_cpu/aix_ppc/prefetch_aix_ppc.inline.hpp

Changeset: 64b0ae6b
Branch: master
Author:    Wang Haomin <wanghaomin at openjdk.org>
Committer: Erik Joelsson <erikj at openjdk.org>
Date:      2026-01-27 14:21:44 +0000
URL:       https://git.openjdk.org/loom/commit/64b0ae6be8a7b70ed4cc08333447e9b73bdcbaca

8376276: Add javafx to allowed-list of CheckFiles

Reviewed-by: erikj, kcr

! test/jdk/build/CheckFiles.java

Changeset: bbb4b0d4
Branch: master
Author:    Chen Liang <liach at openjdk.org>
Date:      2026-01-27 14:51:04 +0000
URL:       https://git.openjdk.org/loom/commit/bbb4b0d498900f929225233008bbdbafaae5d709

8376277: Migrate java/lang/reflect tests away from TestNG

Reviewed-by: alanb

! test/jdk/java/lang/reflect/AccessibleObject/CanAccessTest.java
! test/jdk/java/lang/reflect/AccessibleObject/ModuleSetAccessibleTest.java
! test/jdk/java/lang/reflect/AccessibleObject/TrySetAccessibleTest.java
! test/jdk/java/lang/reflect/ChainedReflection.java
! test/jdk/java/lang/reflect/DefaultMethodMembers/FilterNotMostSpecific.java
! test/jdk/java/lang/reflect/DefaultStaticTest/DefaultStaticInvokeTest.java
! test/jdk/java/lang/reflect/DefaultStaticTest/DefaultStaticTestData.java
! test/jdk/java/lang/reflect/Field/NegativeTest.java
! test/jdk/java/lang/reflect/Generics/ThreadSafety.java
! test/jdk/java/lang/reflect/IllegalArgumentsTest.java
! test/jdk/java/lang/reflect/Method/MethodArityLimit.java
! test/jdk/java/lang/reflect/MethodHandleAccessorsTest.java
! test/jdk/java/lang/reflect/Proxy/DefaultMethods.java
! test/jdk/java/lang/reflect/Proxy/HiddenProxyInterface.java
! test/jdk/java/lang/reflect/Proxy/LazyInitializationTest.java
! test/jdk/java/lang/reflect/Proxy/ProxyClassAccessTest.java
! test/jdk/java/lang/reflect/Proxy/ProxyLayerTest.java
! test/jdk/java/lang/reflect/Proxy/ProxyTest.java
! test/jdk/java/lang/reflect/Proxy/SealedInterfaceTest.java
! test/jdk/java/lang/reflect/Proxy/TestVarArgs.java
! test/jdk/java/lang/reflect/Proxy/nonPublicProxy/DefaultMethodProxy.java
! test/jdk/java/lang/reflect/annotationSharing/AnnotationSharing.java
! test/jdk/java/lang/reflect/callerCache/CustomLoaderTest.java
! test/jdk/java/lang/reflect/callerCache/ReflectionCallerCacheTest.java
! test/jdk/java/lang/reflect/records/CheckEqualityIsBasedOnFields.java
! test/jdk/java/lang/reflect/records/IsRecordTest.java
! test/jdk/java/lang/reflect/records/RecordReflectionTest.java
! test/jdk/java/lang/reflect/sealed_classes/SealedClassesReflectionTest.java

Changeset: a5d0b051
Branch: master
Author:    Chen Liang <liach at openjdk.org>
Date:      2026-01-27 15:04:26 +0000
URL:       https://git.openjdk.org/loom/commit/a5d0b05136e34871366441a8c8e6bda5f20c617c

8376274: JSpec preview support and output enhancement

Reviewed-by: hannesw

! make/jdk/src/classes/build/tools/taglet/JSpec.java
! src/java.base/share/classes/java/lang/runtime/ExactConversionsSupport.java

Changeset: e8048c87
Branch: master
Author:    Roger Riggs <rriggs at openjdk.org>
Date:      2026-01-27 16:07:45 +0000
URL:       https://git.openjdk.org/loom/commit/e8048c87bc9c152932ee59cb674bdb6670db2a56

8376509: [process] Problemlist Test java/lang/ProcessBuilder/PipelineLeaksFD.java

Reviewed-by: jpai

! test/jdk/ProblemList.txt

Changeset: eb6e74b1
Branch: master
Author:    Nizar Benalla <nbenalla at openjdk.org>
Date:      2026-01-27 17:14:40 +0000
URL:       https://git.openjdk.org/loom/commit/eb6e74b1fa794bf16f572d5dbce157d1cae4c505

8374176: Update --release 26 symbol information for JDK 26 build 32

Reviewed-by: liach, iris, darcy

! src/jdk.compiler/share/data/symbols/java.base-Q.sym.txt

Changeset: fa1b1d67
Branch: master
Author:    Chris Plummer <cjplummer at openjdk.org>
Date:      2026-01-27 20:39:35 +0000
URL:       https://git.openjdk.org/loom/commit/fa1b1d677ac492dfdd3110b9303a4c2b009046c8

8375477: CoreUtils support for SA tests should attempt to locate and unzip core files when they have been zipped

Reviewed-by: lmesnik, kevinw

! test/lib/jdk/test/lib/util/CoreUtils.java

Changeset: 1161a640
Branch: master
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2026-01-28 06:58:50 +0000
URL:       https://git.openjdk.org/loom/commit/1161a640abe454b47de95ed73452a78535160deb

8373239: Test java/awt/print/PrinterJob/PageRanges.java fails with incorrect selection of printed pages

Reviewed-by: prr, aivanov

! src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java
! test/jdk/java/awt/print/PrinterJob/PageRanges.java

Changeset: 88c8a55a
Branch: master
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2026-01-28 07:44:31 +0000
URL:       https://git.openjdk.org/loom/commit/88c8a55a4337a857ac17ffff068f730f67cf5763

8373266: Strengthen constant CardTable base accesses

Reviewed-by: tschatzl, xpeng

! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/arm/gc/shared/cardTableBarrierSetAssembler_arm.cpp
! src/hotspot/cpu/ppc/gc/shared/cardTableBarrierSetAssembler_ppc.cpp
! src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp
! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp
! src/hotspot/cpu/s390/gc/shared/cardTableBarrierSetAssembler_s390.cpp
! src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.cpp
! src/hotspot/os_cpu/linux_arm/javaThread_linux_arm.cpp
! src/hotspot/share/ci/ciUtilities.cpp
! src/hotspot/share/ci/ciUtilities.hpp
! src/hotspot/share/compiler/disassembler.cpp
! src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.cpp
! src/hotspot/share/gc/shared/c2/cardTableBarrierSetC2.cpp
! src/hotspot/share/gc/shared/cardTableBarrierSet.hpp
! src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp

Changeset: b2cd3b0d
Branch: master
Author:    Roland Westrelin <roland at openjdk.org>
Date:      2026-01-28 08:00:11 +0000
URL:       https://git.openjdk.org/loom/commit/b2cd3b0d48bdabacfd421dee9b9f87a003e0e09d

8350330: C2: PhaseIdealLoop::add_parse_predicate() should mirror GraphKit::add_parse_predicate()

Reviewed-by: chagedorn, qamai

! src/hotspot/share/opto/loopnode.cpp
! src/hotspot/share/opto/loopnode.hpp
+ test/hotspot/jtreg/compiler/longcountedloops/TestLoopNestTooManyTraps.java

Changeset: 4ae4ffd5
Branch: master
Author:    Chad Rakoczy <chadrako at amazon.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
Date:      2026-01-28 08:08:36 +0000
URL:       https://git.openjdk.org/loom/commit/4ae4ffd5a3114aa2a3832818ee30dc38d9aa2b72

8374513: AArch64: Improve receiver type profiling reliability

Reviewed-by: shade, aph

! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.hpp
! src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp
! src/hotspot/cpu/aarch64/interp_masm_aarch64.hpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp
! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp

Changeset: 6afc0d8f
Branch: master
Author:    Saranya Natarajan <snatarajan at openjdk.org>
Date:      2026-01-28 09:38:20 +0000
URL:       https://git.openjdk.org/loom/commit/6afc0d8f39390d474ce8ba16533c30b4c7770388

8366861: Phase AFTER_LOOP_OPTS printed even though the method has no loops

Reviewed-by: chagedorn, dfenacci

! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/compile.hpp

Changeset: 127bfc9b
Branch: master
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
Date:      2026-01-28 11:11:07 +0000
URL:       https://git.openjdk.org/loom/commit/127bfc9b0dd122c78e702867a88e0847ec362e68

8374926: EnableX86ECoreOpts was not enabled on some hybrid CPU

Reviewed-by: vpaprotski, dholmes

! src/hotspot/cpu/x86/vm_version_x86.cpp

Changeset: 2a465cb0
Branch: master
Author:    Paul H?bner <phubner at openjdk.org>
Committer: Joel Sikstr?m <jsikstro at openjdk.org>
Date:      2026-01-28 13:14:51 +0000
URL:       https://git.openjdk.org/loom/commit/2a465cb0eba6ffe397cf3ad8c1def06bf7a1e392

8371777: Clean up preferred address of G1's archive region

Reviewed-by: stefank, jsikstro

! src/hotspot/share/cds/aotMappedHeapLoader.cpp
! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/hotspot/share/gc/g1/g1CollectedHeap.hpp

Changeset: 8c86b1bb
Branch: master
Author:    Roger Calnan <roger.calnan at oracle.com>
Committer: Weijun Wang <weijun at openjdk.org>
Date:      2026-01-28 14:18:52 +0000
URL:       https://git.openjdk.org/loom/commit/8c86b1bb1054b565cf23156d89ee8925a4e32597

8375325: add anchors to the options in the security man pages

Reviewed-by: weijun, hchao

! src/java.base/share/man/keytool.md
! src/java.security.jgss/windows/man/kinit.md
! src/java.security.jgss/windows/man/klist.md
! src/java.security.jgss/windows/man/ktab.md
! src/jdk.jartool/share/man/jarsigner.md


From duke at openjdk.org  Fri Jan 30 17:59:23 2026
From: duke at openjdk.org (duke)
Date: Fri, 30 Jan 2026 17:59:23 GMT
Subject: git: openjdk/loom: fibers: 37 new changesets
Message-ID: <b399da80-8927-4e2b-aa2f-0069ff6731aa@openjdk.org>

Changeset: 8095e33e
Branch: fibers
Author:    Christian Stein <cstein at openjdk.org>
Date:      2026-01-28 15:02:21 +0000
URL:       https://git.openjdk.org/loom/commit/8095e33ee88759cf2fbe61e2284d95f6b7fb9a3a

8375433: jar should validate automatic module names

Reviewed-by: jvernee

! src/jdk.jartool/share/classes/sun/tools/jar/Validator.java
! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties
! test/jdk/tools/jar/ValidatorTest.java

Changeset: 0e2e66be
Branch: fibers
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2026-01-28 16:30:34 +0000
URL:       https://git.openjdk.org/loom/commit/0e2e66be2423335002a53d887df35d2348a3ec9f

8376402: Dependencies::print_statistics() and AbstractClassHierarchyWalker::print_statistics() are not called from PRODUCT code

Reviewed-by: azafari, chagedorn

! src/hotspot/share/code/dependencies.cpp
! src/hotspot/share/code/dependencies.hpp

Changeset: 50d872ad
Branch: fibers
Author:    Brian Burkhalter <bpb at openjdk.org>
Date:      2026-01-28 16:30:56 +0000
URL:       https://git.openjdk.org/loom/commit/50d872ad7ac5fa5a3406517eb53d8f61f81706df

8376419: (fs) Minor improvement of java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java

Reviewed-by: jpai

! test/jdk/java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java

Changeset: 89a18c01
Branch: fibers
Author:    Phil Race <prr at openjdk.org>
Date:      2026-01-28 17:58:15 +0000
URL:       https://git.openjdk.org/loom/commit/89a18c0108e10dc4ca4a4fa9e8718d49036f8871

8376432: Remove AppContext from sun/swing/DefaultLookup.java

Reviewed-by: psadhukhan, azvegint, aivanov

! src/java.desktop/share/classes/sun/swing/DefaultLookup.java

Changeset: 7efa3168
Branch: fibers
Author:    Phil Race <prr at openjdk.org>
Date:      2026-01-28 18:01:10 +0000
URL:       https://git.openjdk.org/loom/commit/7efa3168b706c1d061c4ee65574427ef1f50fc7b

8376434: Remove AppContext from awt ImageFetcher implementation

Reviewed-by: azvegint, aivanov

! src/java.desktop/share/classes/sun/awt/image/ImageFetcher.java

Changeset: 0722ae92
Branch: fibers
Author:    Phil Race <prr at openjdk.org>
Date:      2026-01-28 19:53:41 +0000
URL:       https://git.openjdk.org/loom/commit/0722ae926ff1327c47a922b1ca0b493a0d06526e

8376433: Remove AppContext from Swing Windows L&F implementation

Reviewed-by: serb, aivanov

! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/AnimationController.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsButtonUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsCheckBoxUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLabelUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsRadioButtonUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsToggleButtonUI.java

Changeset: 09ed8e66
Branch: fibers
Author:    Xiaolong Peng <xpeng at openjdk.org>
Date:      2026-01-28 21:28:16 +0000
URL:       https://git.openjdk.org/loom/commit/09ed8e66dc7a788763a2c7c24f54e93ec8eafedb

8376531: Genshen: Convert ShenandoahOldGeneration to use Atomic<T>

Reviewed-by: wkemper, shade

! src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.cpp
! src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.hpp

Changeset: 2529e2fe
Branch: fibers
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2026-01-29 02:30:41 +0000
URL:       https://git.openjdk.org/loom/commit/2529e2fe8dfe9685033bb0ae558266b8bc3cf95c

8376169: JPopupMenu.setInvoker(null) causes NPE

Reviewed-by: aivanov, azvegint, prr, kizune

! src/java.desktop/share/classes/javax/swing/JPopupMenu.java
! test/jdk/javax/swing/JPopupMenu/TestPopupInvoker.java

Changeset: 62c7e9ae
Branch: fibers
Author:    Phil Race <prr at openjdk.org>
Date:      2026-01-29 04:49:56 +0000
URL:       https://git.openjdk.org/loom/commit/62c7e9aefd4320d9d0cd8fa10610f59abb4de670

8376423: Test javax/swing/plaf/metal/MetalUtils/bug6190373.java failed: ClassCastException: class java.lang.Character cannot be cast to class javax.swing.Painter

Reviewed-by: aivanov, tr

! src/java.desktop/share/classes/javax/swing/UIManager.java
! src/java.desktop/share/classes/javax/swing/plaf/metal/DefaultMetalTheme.java
! src/java.desktop/share/classes/sun/swing/SwingAccessor.java
! src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
- test/jdk/javax/swing/UIManager/Test6657026.java
- test/jdk/javax/swing/plaf/metal/MetalUtils/bug6190373.java

Changeset: 19c6fdf1
Branch: fibers
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2026-01-29 06:34:02 +0000
URL:       https://git.openjdk.org/loom/commit/19c6fdf11b01308e9f99ce5666bfffcfbc453de3

8376290: SocketChannel.finishConnect() contains confusing "getsockopt" in exception message for a failed connect() on Windows

Reviewed-by: alanb

! src/java.base/unix/native/libnet/net_util_md.c
! src/java.base/windows/native/libnet/net_util_md.c
! src/java.base/windows/native/libnio/ch/Net.c
+ test/jdk/java/nio/channels/Selector/ConnectionRefusedMessage.java

Changeset: 06d1345f
Branch: fibers
Author:    Emanuel Peter <epeter at openjdk.org>
Date:      2026-01-29 08:39:10 +0000
URL:       https://git.openjdk.org/loom/commit/06d1345f2913830c273b9546c997e877f7958113

8373026: C2 SuperWord and Vector API: vector algorithms test and benchmark

Co-authored-by: Otmar Ertl <otmar.ertl at dynatrace.com>
Reviewed-by: vlivanov, jbhateja, psandoz, xgong

+ test/hotspot/jtreg/compiler/vectorization/TestVectorAlgorithms.java
+ test/hotspot/jtreg/compiler/vectorization/VectorAlgorithmsImpl.java
+ test/micro/org/openjdk/bench/vm/compiler/VectorAlgorithms.java
+ test/micro/org/openjdk/bench/vm/compiler/VectorAlgorithmsImpl.java

Changeset: 92072a93
Branch: fibers
Author:    Stefan Karlsson <stefank at openjdk.org>
Date:      2026-01-29 08:39:32 +0000
URL:       https://git.openjdk.org/loom/commit/92072a93bfeb83186df15032d425ed984d24fc52

8375747: ZGC: ZForwardingTest is unable to commit memory on Windows

Reviewed-by: jsikstro, eosterlund

! src/hotspot/share/gc/z/zAddress.inline.hpp
! test/hotspot/gtest/gc/z/test_zForwarding.cpp
! test/hotspot/gtest/gc/z/zunittest.hpp

Changeset: f9cc1042
Branch: fibers
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-29 08:54:37 +0000
URL:       https://git.openjdk.org/loom/commit/f9cc104249433eec179c98cb3fb44546254bf588

8376335: Convert PreservedMarks classes to use Atomic<T>

Reviewed-by: stefank, iwalulya

! src/hotspot/share/gc/shared/preservedMarks.cpp
! src/hotspot/share/gc/shared/preservedMarks.hpp

Changeset: 681e4ec8
Branch: fibers
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-29 08:54:59 +0000
URL:       https://git.openjdk.org/loom/commit/681e4ec8d37f4e30462b43e1c789d53525211b0a

8376350: Convert ReferenceProcessorPhaseTimes to use Atomic<T>

Reviewed-by: stefank, iwalulya

! src/hotspot/share/gc/shared/referenceProcessorPhaseTimes.cpp
! src/hotspot/share/gc/shared/referenceProcessorPhaseTimes.hpp

Changeset: f96974db
Branch: fibers
Author:    Marc Chevalier <mchevalier at openjdk.org>
Date:      2026-01-29 11:30:42 +0000
URL:       https://git.openjdk.org/loom/commit/f96974dbbd824db8d7b2bbf28f5d3b49bb005fb3

8373898: RepeatCompilation does not repeat compilation after bailout

Reviewed-by: chagedorn, bmaillard

! src/hotspot/share/compiler/compileBroker.cpp

Changeset: 48846744
Branch: fibers
Author:    Boris Ulasevich <bulasevich at openjdk.org>
Date:      2026-01-29 12:37:51 +0000
URL:       https://git.openjdk.org/loom/commit/48846744ca96ce3c6464a1a440b9e46119dfbb88

8374343: Fix SIGSEGV when lib/modules is unreadable

Reviewed-by: iklam, dholmes

! src/hotspot/share/classfile/classLoader.cpp

Changeset: e85d5d7a
Branch: fibers
Author:    Kerem Kat <krk at openjdk.org>
Committer: Quan Anh Mai <qamai at openjdk.org>
Date:      2026-01-29 12:43:48 +0000
URL:       https://git.openjdk.org/loom/commit/e85d5d7a16024f6a3eda14f1e08f72e07ae38dd0

8375010: C2 VectorAPI: assert(vbox->is_CheckCastPP()) failed: should be expanded
8374903: C2 VectorAPI: assert(vbox->as_Phi()->region() == vect->as_Phi()->region()) failed

Reviewed-by: qamai, vlivanov

! src/hotspot/share/opto/vector.cpp
+ test/hotspot/jtreg/compiler/vectorapi/VectorBoxExpandPhi.java
+ test/hotspot/jtreg/compiler/vectorapi/VectorBoxExpandProj.java

Changeset: 99119597
Branch: fibers
Author:    Ferenc Rakoczi <ferenc.r.rakoczi at oracle.com>
Committer: Weijun Wang <weijun at openjdk.org>
Date:      2026-01-29 12:52:23 +0000
URL:       https://git.openjdk.org/loom/commit/99119597aa95c1139ae2259bed5ec885a7c01269

8374755: ML-KEM's 12-bit decompression can be simplified on aarch64

Reviewed-by: adinn

! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp
! src/java.base/share/classes/com/sun/crypto/provider/ML_KEM.java

Changeset: 7c6c34e1
Branch: fibers
Author:    Kerem Kat <krk at openjdk.org>
Committer: Manuel H?ssig <mhaessig at openjdk.org>
Date:      2026-01-29 13:11:47 +0000
URL:       https://git.openjdk.org/loom/commit/7c6c34e150cf01cec5d166f6cbb8a649c75b0627

8370502: C2: segfault while adding node to IGVN worklist

Reviewed-by: mhaessig, dlong

! src/hotspot/share/opto/macro.cpp
+ test/hotspot/jtreg/compiler/c2/TestUnlockNodeNullMemprof.java

Changeset: a54ff1bf
Branch: fibers
Author:    Ioi Lam <iklam at openjdk.org>
Date:      2026-01-29 16:29:34 +0000
URL:       https://git.openjdk.org/loom/commit/a54ff1bff45e1cb30100cbaa253494c3462f7abd

8376523: Move interned strings into AOT heap roots array

Reviewed-by: kvn, shade

! src/hotspot/share/cds/aotMappedHeapLoader.cpp
! src/hotspot/share/cds/aotMetaspace.cpp
! src/hotspot/share/cds/heapShared.cpp
! src/hotspot/share/cds/heapShared.hpp
! src/hotspot/share/classfile/stringTable.cpp
! src/hotspot/share/classfile/stringTable.hpp
! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/SharedStringsStress.java

Changeset: 847b5166
Branch: fibers
Author:    Matthew Donovan <mdonovan at openjdk.org>
Date:      2026-01-29 16:44:24 +0000
URL:       https://git.openjdk.org/loom/commit/847b5166ea6322f9ff3effa62ed6d1e73a8b1122

8373018: Update OpenSSL version to 3.5.4

Reviewed-by: abarashev, weijun

! test/lib/jdk/test/lib/security/OpensslArtifactFetcher.java

Changeset: 69c868d5
Branch: fibers
Author:    Phil Race <prr at openjdk.org>
Date:      2026-01-29 18:54:39 +0000
URL:       https://git.openjdk.org/loom/commit/69c868d5b7fdeaf38d6a45b75d68bf51b6ee7188

8376510: Raster.createBandedRaster(int, int, int, int, int[], int[], Point) does not check for negative scanlineStride

Reviewed-by: serb, azvegint

! src/java.desktop/share/classes/java/awt/image/Raster.java
! test/jdk/java/awt/image/Raster/CreateRasterExceptionTest.java

Changeset: 9470aa31
Branch: fibers
Author:    Anupam Dev <adev at openjdk.org>
Committer: Phil Race <prr at openjdk.org>
Date:      2026-01-29 18:59:11 +0000
URL:       https://git.openjdk.org/loom/commit/9470aa31175b504fcef15a932825dbc9e0532234

8375011: OldJTable.java - NullPointerException when columnData is null

Reviewed-by: prr, psadhukhan, tr

- src/demo/share/jfc/TableExample/OldJTable.java

Changeset: 175bbb14
Branch: fibers
Author:    Ioi Lam <iklam at openjdk.org>
Date:      2026-01-29 22:39:32 +0000
URL:       https://git.openjdk.org/loom/commit/175bbb143e9fd2e596eb234d46ef9259f2bc4c1a

8375569: Store Java mirrors in AOT configuration file

Reviewed-by: iveresov, kvn, asmehra

! src/hotspot/share/cds/aotMappedHeapLoader.cpp
! src/hotspot/share/cds/aotMetaspace.cpp
! src/hotspot/share/cds/aotReferenceObjSupport.cpp
! src/hotspot/share/cds/cdsConfig.cpp
! src/hotspot/share/cds/cdsConfig.hpp
! src/hotspot/share/cds/heapShared.cpp
! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/classfile/stringTable.cpp
! src/hotspot/share/classfile/stringTable.hpp
! test/hotspot/jtreg/runtime/cds/appcds/aotCache/AOTMapTest.java

Changeset: 379dcb02
Branch: fibers
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
Date:      2026-01-30 02:43:57 +0000
URL:       https://git.openjdk.org/loom/commit/379dcb0266bc90fac740eaa56b8027c7273e6d76

8365313: GTK LaF does not respect system color scheme with Gnome

Reviewed-by: prr, mkartashev, kizune

! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java
! src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c
! src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.h
! src/java.desktop/unix/native/libawt_xawt/awt/gtk_interface.h
! src/java.desktop/unix/native/libawt_xawt/awt/swing_GTKEngine.c

Changeset: 9a10ccee
Branch: fibers
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2026-01-30 03:19:49 +0000
URL:       https://git.openjdk.org/loom/commit/9a10cceeafa5d332aa571f0d62acf50032a597d4

8374506: Incorrect positioning of arrow icon in parent JMenu in Windows L&F

Reviewed-by: aivanov, kizune

! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsMenuItemUI.java
+ test/jdk/javax/swing/JMenuItem/LargeMenuTextArrowIconPosition.java

Changeset: 2953e0f4
Branch: fibers
Author:    Archie Cobbs <acobbs at openjdk.org>
Date:      2026-01-30 03:43:46 +0000
URL:       https://git.openjdk.org/loom/commit/2953e0f445e147d778d4e765be0301cda6557ed5

8371162: Compiler warns about implicit cast from long to int in shift operation

Reviewed-by: vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
+ test/langtools/tools/javac/lint/AssignShift64Bits.java
! test/langtools/tools/javac/lint/ShiftOutOfRange.out

Changeset: 9fef14a6
Branch: fibers
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2026-01-30 06:15:19 +0000
URL:       https://git.openjdk.org/loom/commit/9fef14a6d3124fae3ad8b24dac5103aa611d4edb

8375571: Compiler crash when using record pattern matching with a generic type parameter shadowing a record class

Reviewed-by: vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
! test/langtools/tools/javac/patterns/DeconstructionPatternErrors.java
! test/langtools/tools/javac/patterns/DeconstructionPatternErrors.out

Changeset: 55375e98
Branch: fibers
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2026-01-30 08:31:27 +0000
URL:       https://git.openjdk.org/loom/commit/55375e98ae1672badeacaaf2f8b6f2f21ad03437

8375573: JTable ignores setPreferredWidth during initial layout when AUTO_RESIZE_LAST_COLUMN is enabled

Reviewed-by: tr

! src/java.desktop/share/classes/javax/swing/JTable.java
+ test/jdk/javax/swing/JTable/TestJTableColWidth.java

Changeset: e6437264
Branch: fibers
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2026-01-30 08:31:51 +0000
URL:       https://git.openjdk.org/loom/commit/e6437264d5e6d4aad23430b7dbdf574a12b8f57b

8376604: C2: EA should assert is_oop_field for AddP with oop outs

Reviewed-by: qamai, kvn

! src/hotspot/share/opto/escape.cpp
! src/hotspot/share/opto/escape.hpp

Changeset: 42370e22
Branch: fibers
Author:    Manuel H?ssig <mhaessig at openjdk.org>
Date:      2026-01-30 09:01:00 +0000
URL:       https://git.openjdk.org/loom/commit/42370e22c5bc4ebd40fd500a2e6e9e07f0b8bcd8

8376781: Problemlist compiler/longcountedloops/TestLoopNestTooManyTraps.java

Reviewed-by: thartmann, chagedorn

! test/hotspot/jtreg/ProblemList.txt

Changeset: e3b5b261
Branch: fibers
Author:    Guanqiang Han <ghan at openjdk.org>
Committer: Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-30 09:35:32 +0000
URL:       https://git.openjdk.org/loom/commit/e3b5b261af6acbe7ab074f301c70283b06c17d39

8376287: Crashes when using -XX:ObjArrayMarkingStride=0

Reviewed-by: tschatzl, shade

! src/hotspot/share/gc/shared/gc_globals.hpp
! src/hotspot/share/gc/shenandoah/shenandoahMark.inline.hpp

Changeset: 0a3809d3
Branch: fibers
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2026-01-30 11:33:03 +0000
URL:       https://git.openjdk.org/loom/commit/0a3809d380bcae8cb24d50886057d8586fa77f7c

8375046: C2: Incremental inlining step asserts when processing empty late inlines list

Reviewed-by: vlivanov, thartmann, kbarrett

! src/hotspot/share/opto/compile.cpp

Changeset: df8c4d6d
Branch: fibers
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
Date:      2026-01-30 13:44:48 +0000
URL:       https://git.openjdk.org/loom/commit/df8c4d6d12dacd0adfcf8c711c8671913d805309

8373604: Operations on peer reset tokens are slow

Reviewed-by: dfuchs

! src/java.net.http/share/classes/jdk/internal/net/http/quic/PeerConnIdManager.java
! src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicConnectionImpl.java
! src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicEndpoint.java
! src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicPacketReceiver.java

Changeset: d008c38c
Branch: fibers
Author:    Alan Bateman <alan.bateman at oracle.com>
Date:      2026-01-30 15:27:53 +0000
URL:       https://git.openjdk.org/loom/commit/d008c38c5a57dab4b53f7c4c7d2c08251c534731

Merge branch 'master' into fibers

! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/classfile/javaClasses.cpp

Changeset: 30386291
Branch: fibers
Author:    Alan Bateman <alan.bateman at oracle.com>
Date:      2026-01-30 14:25:22 +0000
URL:       https://git.openjdk.org/loom/commit/30386291b16b36eb776cfe1b47c3e1b29b1f394f

Add system properties to make configs easy to test

! src/java.base/share/classes/java/lang/VirtualThread.java

Changeset: bae3101e
Branch: fibers
Author:    Alan Bateman <alan.bateman at oracle.com>
Date:      2026-01-30 15:27:58 +0000
URL:       https://git.openjdk.org/loom/commit/bae3101e89b9189f45e705615b66f2bdbfae66e4

Merge loom into fibers



From duke at openjdk.org  Fri Jan 30 18:01:20 2026
From: duke at openjdk.org (duke)
Date: Fri, 30 Jan 2026 18:01:20 GMT
Subject: git: openjdk/loom: master: 34 new changesets
Message-ID: <5eb446e2-45f6-48c2-bb82-beac7b9aa5bf@openjdk.org>

Changeset: 8095e33e
Branch: master
Author:    Christian Stein <cstein at openjdk.org>
Date:      2026-01-28 15:02:21 +0000
URL:       https://git.openjdk.org/loom/commit/8095e33ee88759cf2fbe61e2284d95f6b7fb9a3a

8375433: jar should validate automatic module names

Reviewed-by: jvernee

! src/jdk.jartool/share/classes/sun/tools/jar/Validator.java
! src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties
! test/jdk/tools/jar/ValidatorTest.java

Changeset: 0e2e66be
Branch: master
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2026-01-28 16:30:34 +0000
URL:       https://git.openjdk.org/loom/commit/0e2e66be2423335002a53d887df35d2348a3ec9f

8376402: Dependencies::print_statistics() and AbstractClassHierarchyWalker::print_statistics() are not called from PRODUCT code

Reviewed-by: azafari, chagedorn

! src/hotspot/share/code/dependencies.cpp
! src/hotspot/share/code/dependencies.hpp

Changeset: 50d872ad
Branch: master
Author:    Brian Burkhalter <bpb at openjdk.org>
Date:      2026-01-28 16:30:56 +0000
URL:       https://git.openjdk.org/loom/commit/50d872ad7ac5fa5a3406517eb53d8f61f81706df

8376419: (fs) Minor improvement of java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java

Reviewed-by: jpai

! test/jdk/java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java

Changeset: 89a18c01
Branch: master
Author:    Phil Race <prr at openjdk.org>
Date:      2026-01-28 17:58:15 +0000
URL:       https://git.openjdk.org/loom/commit/89a18c0108e10dc4ca4a4fa9e8718d49036f8871

8376432: Remove AppContext from sun/swing/DefaultLookup.java

Reviewed-by: psadhukhan, azvegint, aivanov

! src/java.desktop/share/classes/sun/swing/DefaultLookup.java

Changeset: 7efa3168
Branch: master
Author:    Phil Race <prr at openjdk.org>
Date:      2026-01-28 18:01:10 +0000
URL:       https://git.openjdk.org/loom/commit/7efa3168b706c1d061c4ee65574427ef1f50fc7b

8376434: Remove AppContext from awt ImageFetcher implementation

Reviewed-by: azvegint, aivanov

! src/java.desktop/share/classes/sun/awt/image/ImageFetcher.java

Changeset: 0722ae92
Branch: master
Author:    Phil Race <prr at openjdk.org>
Date:      2026-01-28 19:53:41 +0000
URL:       https://git.openjdk.org/loom/commit/0722ae926ff1327c47a922b1ca0b493a0d06526e

8376433: Remove AppContext from Swing Windows L&F implementation

Reviewed-by: serb, aivanov

! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/AnimationController.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsButtonUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsCheckBoxUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLabelUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsRadioButtonUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsToggleButtonUI.java

Changeset: 09ed8e66
Branch: master
Author:    Xiaolong Peng <xpeng at openjdk.org>
Date:      2026-01-28 21:28:16 +0000
URL:       https://git.openjdk.org/loom/commit/09ed8e66dc7a788763a2c7c24f54e93ec8eafedb

8376531: Genshen: Convert ShenandoahOldGeneration to use Atomic<T>

Reviewed-by: wkemper, shade

! src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.cpp
! src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.hpp

Changeset: 2529e2fe
Branch: master
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2026-01-29 02:30:41 +0000
URL:       https://git.openjdk.org/loom/commit/2529e2fe8dfe9685033bb0ae558266b8bc3cf95c

8376169: JPopupMenu.setInvoker(null) causes NPE

Reviewed-by: aivanov, azvegint, prr, kizune

! src/java.desktop/share/classes/javax/swing/JPopupMenu.java
! test/jdk/javax/swing/JPopupMenu/TestPopupInvoker.java

Changeset: 62c7e9ae
Branch: master
Author:    Phil Race <prr at openjdk.org>
Date:      2026-01-29 04:49:56 +0000
URL:       https://git.openjdk.org/loom/commit/62c7e9aefd4320d9d0cd8fa10610f59abb4de670

8376423: Test javax/swing/plaf/metal/MetalUtils/bug6190373.java failed: ClassCastException: class java.lang.Character cannot be cast to class javax.swing.Painter

Reviewed-by: aivanov, tr

! src/java.desktop/share/classes/javax/swing/UIManager.java
! src/java.desktop/share/classes/javax/swing/plaf/metal/DefaultMetalTheme.java
! src/java.desktop/share/classes/sun/swing/SwingAccessor.java
! src/java.desktop/share/classes/sun/swing/SwingUtilities2.java
- test/jdk/javax/swing/UIManager/Test6657026.java
- test/jdk/javax/swing/plaf/metal/MetalUtils/bug6190373.java

Changeset: 19c6fdf1
Branch: master
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2026-01-29 06:34:02 +0000
URL:       https://git.openjdk.org/loom/commit/19c6fdf11b01308e9f99ce5666bfffcfbc453de3

8376290: SocketChannel.finishConnect() contains confusing "getsockopt" in exception message for a failed connect() on Windows

Reviewed-by: alanb

! src/java.base/unix/native/libnet/net_util_md.c
! src/java.base/windows/native/libnet/net_util_md.c
! src/java.base/windows/native/libnio/ch/Net.c
+ test/jdk/java/nio/channels/Selector/ConnectionRefusedMessage.java

Changeset: 06d1345f
Branch: master
Author:    Emanuel Peter <epeter at openjdk.org>
Date:      2026-01-29 08:39:10 +0000
URL:       https://git.openjdk.org/loom/commit/06d1345f2913830c273b9546c997e877f7958113

8373026: C2 SuperWord and Vector API: vector algorithms test and benchmark

Co-authored-by: Otmar Ertl <otmar.ertl at dynatrace.com>
Reviewed-by: vlivanov, jbhateja, psandoz, xgong

+ test/hotspot/jtreg/compiler/vectorization/TestVectorAlgorithms.java
+ test/hotspot/jtreg/compiler/vectorization/VectorAlgorithmsImpl.java
+ test/micro/org/openjdk/bench/vm/compiler/VectorAlgorithms.java
+ test/micro/org/openjdk/bench/vm/compiler/VectorAlgorithmsImpl.java

Changeset: 92072a93
Branch: master
Author:    Stefan Karlsson <stefank at openjdk.org>
Date:      2026-01-29 08:39:32 +0000
URL:       https://git.openjdk.org/loom/commit/92072a93bfeb83186df15032d425ed984d24fc52

8375747: ZGC: ZForwardingTest is unable to commit memory on Windows

Reviewed-by: jsikstro, eosterlund

! src/hotspot/share/gc/z/zAddress.inline.hpp
! test/hotspot/gtest/gc/z/test_zForwarding.cpp
! test/hotspot/gtest/gc/z/zunittest.hpp

Changeset: f9cc1042
Branch: master
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-29 08:54:37 +0000
URL:       https://git.openjdk.org/loom/commit/f9cc104249433eec179c98cb3fb44546254bf588

8376335: Convert PreservedMarks classes to use Atomic<T>

Reviewed-by: stefank, iwalulya

! src/hotspot/share/gc/shared/preservedMarks.cpp
! src/hotspot/share/gc/shared/preservedMarks.hpp

Changeset: 681e4ec8
Branch: master
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-29 08:54:59 +0000
URL:       https://git.openjdk.org/loom/commit/681e4ec8d37f4e30462b43e1c789d53525211b0a

8376350: Convert ReferenceProcessorPhaseTimes to use Atomic<T>

Reviewed-by: stefank, iwalulya

! src/hotspot/share/gc/shared/referenceProcessorPhaseTimes.cpp
! src/hotspot/share/gc/shared/referenceProcessorPhaseTimes.hpp

Changeset: f96974db
Branch: master
Author:    Marc Chevalier <mchevalier at openjdk.org>
Date:      2026-01-29 11:30:42 +0000
URL:       https://git.openjdk.org/loom/commit/f96974dbbd824db8d7b2bbf28f5d3b49bb005fb3

8373898: RepeatCompilation does not repeat compilation after bailout

Reviewed-by: chagedorn, bmaillard

! src/hotspot/share/compiler/compileBroker.cpp

Changeset: 48846744
Branch: master
Author:    Boris Ulasevich <bulasevich at openjdk.org>
Date:      2026-01-29 12:37:51 +0000
URL:       https://git.openjdk.org/loom/commit/48846744ca96ce3c6464a1a440b9e46119dfbb88

8374343: Fix SIGSEGV when lib/modules is unreadable

Reviewed-by: iklam, dholmes

! src/hotspot/share/classfile/classLoader.cpp

Changeset: e85d5d7a
Branch: master
Author:    Kerem Kat <krk at openjdk.org>
Committer: Quan Anh Mai <qamai at openjdk.org>
Date:      2026-01-29 12:43:48 +0000
URL:       https://git.openjdk.org/loom/commit/e85d5d7a16024f6a3eda14f1e08f72e07ae38dd0

8375010: C2 VectorAPI: assert(vbox->is_CheckCastPP()) failed: should be expanded
8374903: C2 VectorAPI: assert(vbox->as_Phi()->region() == vect->as_Phi()->region()) failed

Reviewed-by: qamai, vlivanov

! src/hotspot/share/opto/vector.cpp
+ test/hotspot/jtreg/compiler/vectorapi/VectorBoxExpandPhi.java
+ test/hotspot/jtreg/compiler/vectorapi/VectorBoxExpandProj.java

Changeset: 99119597
Branch: master
Author:    Ferenc Rakoczi <ferenc.r.rakoczi at oracle.com>
Committer: Weijun Wang <weijun at openjdk.org>
Date:      2026-01-29 12:52:23 +0000
URL:       https://git.openjdk.org/loom/commit/99119597aa95c1139ae2259bed5ec885a7c01269

8374755: ML-KEM's 12-bit decompression can be simplified on aarch64

Reviewed-by: adinn

! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp
! src/java.base/share/classes/com/sun/crypto/provider/ML_KEM.java

Changeset: 7c6c34e1
Branch: master
Author:    Kerem Kat <krk at openjdk.org>
Committer: Manuel H?ssig <mhaessig at openjdk.org>
Date:      2026-01-29 13:11:47 +0000
URL:       https://git.openjdk.org/loom/commit/7c6c34e150cf01cec5d166f6cbb8a649c75b0627

8370502: C2: segfault while adding node to IGVN worklist

Reviewed-by: mhaessig, dlong

! src/hotspot/share/opto/macro.cpp
+ test/hotspot/jtreg/compiler/c2/TestUnlockNodeNullMemprof.java

Changeset: a54ff1bf
Branch: master
Author:    Ioi Lam <iklam at openjdk.org>
Date:      2026-01-29 16:29:34 +0000
URL:       https://git.openjdk.org/loom/commit/a54ff1bff45e1cb30100cbaa253494c3462f7abd

8376523: Move interned strings into AOT heap roots array

Reviewed-by: kvn, shade

! src/hotspot/share/cds/aotMappedHeapLoader.cpp
! src/hotspot/share/cds/aotMetaspace.cpp
! src/hotspot/share/cds/heapShared.cpp
! src/hotspot/share/cds/heapShared.hpp
! src/hotspot/share/classfile/stringTable.cpp
! src/hotspot/share/classfile/stringTable.hpp
! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/SharedStringsStress.java

Changeset: 847b5166
Branch: master
Author:    Matthew Donovan <mdonovan at openjdk.org>
Date:      2026-01-29 16:44:24 +0000
URL:       https://git.openjdk.org/loom/commit/847b5166ea6322f9ff3effa62ed6d1e73a8b1122

8373018: Update OpenSSL version to 3.5.4

Reviewed-by: abarashev, weijun

! test/lib/jdk/test/lib/security/OpensslArtifactFetcher.java

Changeset: 69c868d5
Branch: master
Author:    Phil Race <prr at openjdk.org>
Date:      2026-01-29 18:54:39 +0000
URL:       https://git.openjdk.org/loom/commit/69c868d5b7fdeaf38d6a45b75d68bf51b6ee7188

8376510: Raster.createBandedRaster(int, int, int, int, int[], int[], Point) does not check for negative scanlineStride

Reviewed-by: serb, azvegint

! src/java.desktop/share/classes/java/awt/image/Raster.java
! test/jdk/java/awt/image/Raster/CreateRasterExceptionTest.java

Changeset: 9470aa31
Branch: master
Author:    Anupam Dev <adev at openjdk.org>
Committer: Phil Race <prr at openjdk.org>
Date:      2026-01-29 18:59:11 +0000
URL:       https://git.openjdk.org/loom/commit/9470aa31175b504fcef15a932825dbc9e0532234

8375011: OldJTable.java - NullPointerException when columnData is null

Reviewed-by: prr, psadhukhan, tr

- src/demo/share/jfc/TableExample/OldJTable.java

Changeset: 175bbb14
Branch: master
Author:    Ioi Lam <iklam at openjdk.org>
Date:      2026-01-29 22:39:32 +0000
URL:       https://git.openjdk.org/loom/commit/175bbb143e9fd2e596eb234d46ef9259f2bc4c1a

8375569: Store Java mirrors in AOT configuration file

Reviewed-by: iveresov, kvn, asmehra

! src/hotspot/share/cds/aotMappedHeapLoader.cpp
! src/hotspot/share/cds/aotMetaspace.cpp
! src/hotspot/share/cds/aotReferenceObjSupport.cpp
! src/hotspot/share/cds/cdsConfig.cpp
! src/hotspot/share/cds/cdsConfig.hpp
! src/hotspot/share/cds/heapShared.cpp
! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/classfile/stringTable.cpp
! src/hotspot/share/classfile/stringTable.hpp
! test/hotspot/jtreg/runtime/cds/appcds/aotCache/AOTMapTest.java

Changeset: 379dcb02
Branch: master
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
Date:      2026-01-30 02:43:57 +0000
URL:       https://git.openjdk.org/loom/commit/379dcb0266bc90fac740eaa56b8027c7273e6d76

8365313: GTK LaF does not respect system color scheme with Gnome

Reviewed-by: prr, mkartashev, kizune

! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java
! src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c
! src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.h
! src/java.desktop/unix/native/libawt_xawt/awt/gtk_interface.h
! src/java.desktop/unix/native/libawt_xawt/awt/swing_GTKEngine.c

Changeset: 9a10ccee
Branch: master
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2026-01-30 03:19:49 +0000
URL:       https://git.openjdk.org/loom/commit/9a10cceeafa5d332aa571f0d62acf50032a597d4

8374506: Incorrect positioning of arrow icon in parent JMenu in Windows L&F

Reviewed-by: aivanov, kizune

! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsMenuItemUI.java
+ test/jdk/javax/swing/JMenuItem/LargeMenuTextArrowIconPosition.java

Changeset: 2953e0f4
Branch: master
Author:    Archie Cobbs <acobbs at openjdk.org>
Date:      2026-01-30 03:43:46 +0000
URL:       https://git.openjdk.org/loom/commit/2953e0f445e147d778d4e765be0301cda6557ed5

8371162: Compiler warns about implicit cast from long to int in shift operation

Reviewed-by: vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
+ test/langtools/tools/javac/lint/AssignShift64Bits.java
! test/langtools/tools/javac/lint/ShiftOutOfRange.out

Changeset: 9fef14a6
Branch: master
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2026-01-30 06:15:19 +0000
URL:       https://git.openjdk.org/loom/commit/9fef14a6d3124fae3ad8b24dac5103aa611d4edb

8375571: Compiler crash when using record pattern matching with a generic type parameter shadowing a record class

Reviewed-by: vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
! test/langtools/tools/javac/patterns/DeconstructionPatternErrors.java
! test/langtools/tools/javac/patterns/DeconstructionPatternErrors.out

Changeset: 55375e98
Branch: master
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2026-01-30 08:31:27 +0000
URL:       https://git.openjdk.org/loom/commit/55375e98ae1672badeacaaf2f8b6f2f21ad03437

8375573: JTable ignores setPreferredWidth during initial layout when AUTO_RESIZE_LAST_COLUMN is enabled

Reviewed-by: tr

! src/java.desktop/share/classes/javax/swing/JTable.java
+ test/jdk/javax/swing/JTable/TestJTableColWidth.java

Changeset: e6437264
Branch: master
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2026-01-30 08:31:51 +0000
URL:       https://git.openjdk.org/loom/commit/e6437264d5e6d4aad23430b7dbdf574a12b8f57b

8376604: C2: EA should assert is_oop_field for AddP with oop outs

Reviewed-by: qamai, kvn

! src/hotspot/share/opto/escape.cpp
! src/hotspot/share/opto/escape.hpp

Changeset: 42370e22
Branch: master
Author:    Manuel H?ssig <mhaessig at openjdk.org>
Date:      2026-01-30 09:01:00 +0000
URL:       https://git.openjdk.org/loom/commit/42370e22c5bc4ebd40fd500a2e6e9e07f0b8bcd8

8376781: Problemlist compiler/longcountedloops/TestLoopNestTooManyTraps.java

Reviewed-by: thartmann, chagedorn

! test/hotspot/jtreg/ProblemList.txt

Changeset: e3b5b261
Branch: master
Author:    Guanqiang Han <ghan at openjdk.org>
Committer: Thomas Schatzl <tschatzl at openjdk.org>
Date:      2026-01-30 09:35:32 +0000
URL:       https://git.openjdk.org/loom/commit/e3b5b261af6acbe7ab074f301c70283b06c17d39

8376287: Crashes when using -XX:ObjArrayMarkingStride=0

Reviewed-by: tschatzl, shade

! src/hotspot/share/gc/shared/gc_globals.hpp
! src/hotspot/share/gc/shenandoah/shenandoahMark.inline.hpp

Changeset: 0a3809d3
Branch: master
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2026-01-30 11:33:03 +0000
URL:       https://git.openjdk.org/loom/commit/0a3809d380bcae8cb24d50886057d8586fa77f7c

8375046: C2: Incremental inlining step asserts when processing empty late inlines list

Reviewed-by: vlivanov, thartmann, kbarrett

! src/hotspot/share/opto/compile.cpp

Changeset: df8c4d6d
Branch: master
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
Date:      2026-01-30 13:44:48 +0000
URL:       https://git.openjdk.org/loom/commit/df8c4d6d12dacd0adfcf8c711c8671913d805309

8373604: Operations on peer reset tokens are slow

Reviewed-by: dfuchs

! src/java.net.http/share/classes/jdk/internal/net/http/quic/PeerConnIdManager.java
! src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicConnectionImpl.java
! src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicEndpoint.java
! src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicPacketReceiver.java