From nigro.fra at gmail.com Sat Jun 1 08:01:07 2024 From: nigro.fra at gmail.com (Francesco Nigro) Date: Sat, 1 Jun 2024 10:01:07 +0200 Subject: Virtual threads and File IO In-Reply-To: References: Message-ID: Afaik every I/O (either socket/file-related ones) as executed in place. The file related ones, unless DIRECT_IO is used, are still Vs the OS page cache, which means are not that much slower, although user-kernel-user transition is clearly in place (with its inherent cost). AFAIK this could change if io_uring is used because submission ring buffers are not meant to be used concurrently and only socket requests are actually executed in-place (unless specified differently). Il sab 1 giu 2024, 00:44 Robert Engels ha scritto: > Hi, > > An interesting question came up on the Go support channels. One of the > principle engineers stated that for local file IO, the Go routine (similar > to virtual thread) won?t release the carrier thread. > > Is this the same with Java virtual threads? Yes, local IO is typically > fast - but it is still order of magnitudes slower than memory computations > - which the virtual thread could be doing while waiting for the IO request > to be serviced. > > R -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Sat Jun 1 08:20:36 2024 From: duke at openjdk.org (duke) Date: Sat, 1 Jun 2024 08:20:36 GMT Subject: git: openjdk/loom: fibers: 40 new changesets Message-ID: <8186721e-c8b6-4f9f-89d0-23bd6765571e@openjdk.org> Changeset: 1d889e54 Author: Jatin Bhateja Date: 2024-05-30 17:14:07 +0000 URL: https://git.openjdk.org/loom/commit/1d889e54fc6d6039e68191420bb377ea560e2eaa 8332487: Regression in Crypto-AESGCMBench.encrypt (and others) after JDK-8328181 Reviewed-by: thartmann ! src/hotspot/cpu/x86/x86.ad Changeset: 922e312b Author: Chris Plummer Date: 2024-05-30 18:03:44 +0000 URL: https://git.openjdk.org/loom/commit/922e312b0ab3ac54979ffdc53a8d8338e52234df 8328611: Thread safety issue in com.sun.tools.jdi.ReferenceTypeImpl::classObject Reviewed-by: amenkov, sspitsyn ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ReferenceTypeImpl.java Changeset: 44c1845a Author: Alex Menkov Date: 2024-05-30 18:12:43 +0000 URL: https://git.openjdk.org/loom/commit/44c1845ae7fdff524d4a60a51362834cfea5c5da 8330852: All callers of JvmtiEnvBase::get_threadOop_and_JavaThread should pass current thread explicitly Reviewed-by: sspitsyn, cjplummer ! src/hotspot/share/prims/jvmtiEnv.cpp ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! src/hotspot/share/prims/jvmtiEnvBase.hpp Changeset: 11e926cf Author: Evgeny Nikitin Committer: Leonid Mesnik Date: 2024-05-30 18:21:29 +0000 URL: https://git.openjdk.org/loom/commit/11e926cf50c64d57b0dba095eb62c2be4a8a8f1e 8332777: Update JCStress test suite Reviewed-by: lmesnik ! test/hotspot/jtreg/applications/jcstress/JcstressRunner.java Changeset: b3e29db1 Author: Leonid Mesnik Date: 2024-05-30 18:21:40 +0000 URL: https://git.openjdk.org/loom/commit/b3e29db14466ccc64a2815224ecefab4cec4c775 8333108: Update vmTestbase/nsk/share/DebugeeProcess.java to don't use finalization Reviewed-by: cjplummer, sspitsyn ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/multithrd/tc04x001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VMDeathEvent/_itself_/vmdeath003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/exit/exit001.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Binder.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jdwp/Binder.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeProcess.java Changeset: ec88c6a8 Author: Chris Plummer Date: 2024-05-30 18:59:21 +0000 URL: https://git.openjdk.org/loom/commit/ec88c6a872a97cee1cde8844f5ee6834023a10c6 8332917: failure_handler should execute gdb "info threads" command on linux Reviewed-by: lmesnik, sspitsyn ! test/failure_handler/src/share/conf/linux.properties Changeset: 79f49983 Author: Joe Darcy Date: 2024-05-30 19:57:21 +0000 URL: https://git.openjdk.org/loom/commit/79f49983d3597e8ab1ffb30b23ce41ae5f298c4e 8321314: Reinstate disabling the compiler's default active annotation processing Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! test/langtools/tools/javac/6341866/T6341866.java ! test/langtools/tools/javac/diags/examples.not-yet.txt ! test/langtools/tools/javac/diags/examples/ProcUseProcOrImplicit/ProcUseProcOrImplicit.java ! test/langtools/tools/javac/processing/options/TestNoteOnImplicitProcessing.java Changeset: ffb0867e Author: Justin Lu Date: 2024-05-30 20:05:22 +0000 URL: https://git.openjdk.org/loom/commit/ffb0867e2c07b41cb7124e11fe6cf63d9471f0d2 8331485: Odd Results when Parsing Scientific Notation with Large Exponent 8331680: NumberFormat is missing some bad exponent strict parse cases Reviewed-by: naoto ! src/java.base/share/classes/java/text/DecimalFormat.java + test/jdk/java/text/Format/DecimalFormat/LargeExponentsTest.java ! test/jdk/java/text/Format/NumberFormat/LenientParseTest.java ! test/jdk/java/text/Format/NumberFormat/StrictParseTest.java Changeset: 3634a910 Author: Chris Plummer Date: 2024-05-30 20:38:38 +0000 URL: https://git.openjdk.org/loom/commit/3634a9105053717f3099982390ce2b9e564f0ac5 8332751: Broken link in VirtualMachine.html Reviewed-by: amenkov, alanb ! src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java Changeset: e304a8ae Author: Alexey Semenyuk Date: 2024-05-31 03:02:09 +0000 URL: https://git.openjdk.org/loom/commit/e304a8ae63fdec125e085bd5048d62cf555e2caa 8333307: Don't suppress jpackage logging in tests when it is detecting packaging tools in the system Reviewed-by: almatvee ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/PackageType.java Changeset: 1b7d59f1 Author: Alexey Semenyuk Date: 2024-05-31 03:05:09 +0000 URL: https://git.openjdk.org/loom/commit/1b7d59f171d0e2a3bdd234cddffac548b1f8ba57 8333303: Issues with DottedVersion class Reviewed-by: almatvee ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/DottedVersion.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/ToolValidator.java ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixAppImageFragmentBuilder.java ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixFragmentBuilder.java ! test/jdk/tools/jpackage/junit/jdk.jpackage/jdk/jpackage/internal/CompareDottedVersionTest.java ! test/jdk/tools/jpackage/junit/jdk.jpackage/jdk/jpackage/internal/DottedVersionTest.java Changeset: 2ab8ab56 Author: Jan Lahoda Date: 2024-05-31 05:54:39 +0000 URL: https://git.openjdk.org/loom/commit/2ab8ab56130ca258bf0347ea44e74a8cad3d537d 8332858: References with escapes have broken positions after they are transformed Reviewed-by: vromero, jjg ! src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java ! test/langtools/tools/javac/doctree/MarkdownTransformerPositionTest.java Changeset: 22ef827e Author: Adam Sotona Date: 2024-05-31 06:26:35 +0000 URL: https://git.openjdk.org/loom/commit/22ef827e2cc2409f21ad5c26611cb13d39b5cb3e 8320396: Class-File API ClassModel::verify should include checks from hotspot/share/classfile/classFileParser.cpp Reviewed-by: liach, mcimadamore ! src/java.base/share/classes/jdk/internal/classfile/impl/ClassPrinterImpl.java + src/java.base/share/classes/jdk/internal/classfile/impl/verifier/ParserVerifier.java ! src/java.base/share/classes/jdk/internal/classfile/impl/verifier/VerificationWrapper.java ! src/java.base/share/classes/jdk/internal/classfile/impl/verifier/VerifierImpl.java ! test/jdk/jdk/classfile/ClassPrinterTest.java ! test/jdk/jdk/classfile/VerifierSelfTest.java Changeset: ba323b51 Author: Thomas Stuefe Date: 2024-05-31 06:50:29 +0000 URL: https://git.openjdk.org/loom/commit/ba323b515d8821895356507bdb1e94df0776dd5a 8333047: Remove arena-size-workaround in jvmtiUtils.cpp Reviewed-by: jsjolen, sspitsyn ! src/hotspot/share/memory/arena.cpp ! src/hotspot/share/memory/arena.hpp ! src/hotspot/share/prims/jvmtiUtil.cpp Changeset: 95c8a69b Author: Christian Hagedorn Date: 2024-05-31 06:56:57 +0000 URL: https://git.openjdk.org/loom/commit/95c8a69b0e7a99ec0cd41aa9b6ba033fd3216695 8332032: C2: Remove ExpandSubTypeCheckAtParseTime flag Reviewed-by: thartmann, rcastanedalo ! src/hotspot/share/opto/c2_globals.hpp ! src/hotspot/share/opto/graphKit.cpp ! test/hotspot/jtreg/compiler/types/TestSubTypeCheckMacroTrichotomy.java ! test/hotspot/jtreg/compiler/types/TestSubTypeCheckWithBottomArray.java Changeset: bb4aed94 Author: Albert Mingkun Yang Date: 2024-05-31 07:58:32 +0000 URL: https://git.openjdk.org/loom/commit/bb4aed944ea511df8ddfbd50c885a271a2ea9464 8332961: Parallel: Limit PSParallelCompact::verify_complete range Reviewed-by: tschatzl, gli ! src/hotspot/share/gc/parallel/psParallelCompact.cpp Changeset: 778ad00a Author: Aggelos Biboudis Date: 2024-05-31 08:43:54 +0000 URL: https://git.openjdk.org/loom/commit/778ad00af8eafa65604135088ad7d37bf5b8fc39 8308642: Unhelpful pattern switch error: illegal fall-through to a pattern Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties Changeset: a7864af0 Author: Adam Sotona Date: 2024-05-31 08:48:14 +0000 URL: https://git.openjdk.org/loom/commit/a7864af08acbe63d09f770ca66780738260faac4 8182774: Verify code in javap Reviewed-by: mcimadamore ! src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/JavapTask.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/Options.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap.properties ! src/jdk.jdeps/share/man/javap.1 + test/langtools/tools/javap/VerificationTest.java Changeset: 7ab74c5f Author: SendaoYan Committer: Severin Gehwolf Date: 2024-05-31 10:13:57 +0000 URL: https://git.openjdk.org/loom/commit/7ab74c5f268dac82bbd36355acf8e4f3d357134c 8333200: Test containers/docker/TestPids.java fails Limit value -1 is not accepted as unlimited Reviewed-by: sgehwolf ! test/hotspot/jtreg/containers/docker/TestPids.java Changeset: d4812151 Author: Erik ?sterlund Date: 2024-05-31 12:49:22 +0000 URL: https://git.openjdk.org/loom/commit/d48121512658003f21826e037590541464141ed6 8333005: Deadlock when setting or updating the inline cache Reviewed-by: sjohanss, shade ! src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp ! src/hotspot/share/gc/shenandoah/shenandoahNMethod.cpp ! src/hotspot/share/gc/shenandoah/shenandoahNMethod.hpp ! src/hotspot/share/gc/shenandoah/shenandoahNMethod.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahUnload.cpp ! src/hotspot/share/gc/x/xNMethod.cpp ! src/hotspot/share/gc/x/xNMethod.hpp ! src/hotspot/share/gc/x/xNMethodData.cpp ! src/hotspot/share/gc/x/xNMethodData.hpp ! src/hotspot/share/gc/x/xUnload.cpp ! src/hotspot/share/gc/z/zNMethod.cpp ! src/hotspot/share/gc/z/zNMethod.hpp ! src/hotspot/share/gc/z/zNMethodData.cpp ! src/hotspot/share/gc/z/zNMethodData.hpp ! src/hotspot/share/gc/z/zUnload.cpp Changeset: 2f2dc228 Author: Erik ?sterlund Date: 2024-05-31 12:50:41 +0000 URL: https://git.openjdk.org/loom/commit/2f2dc2289bce47d8071a86215218f345cce71dba 8330981: ZGC: Should not dedup strings in the finalizer graph Reviewed-by: stefank, aboldtch, tschatzl ! src/hotspot/share/gc/x/xMark.cpp ! src/hotspot/share/gc/z/zMark.cpp Changeset: 79a78f03 Author: Zhengyu Gu Date: 2024-05-31 13:00:04 +0000 URL: https://git.openjdk.org/loom/commit/79a78f032effdae40816e7d3e2596dc2b8ef5b9f 8333129: Move ShrinkHeapInSteps flag to Serial GC Reviewed-by: dholmes, kbarrett ! src/hotspot/share/gc/serial/serial_globals.hpp ! src/hotspot/share/runtime/globals.hpp Changeset: e930bc1f Author: Hannes Walln?fer Date: 2024-05-31 13:11:23 +0000 URL: https://git.openjdk.org/loom/commit/e930bc1fbbbb0f2f8a4d03bfe7a8f4420335a8a2 8329537: Nested and enclosing classes should be linked separately in breadcrumb navigation Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassUseWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/DocFilesHandler.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Navigation.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageTreeWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageUseWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriter.java ! test/langtools/jdk/javadoc/doclet/testNavigation/TestNavigation.java Changeset: 32ee252c Author: Jan Lahoda Date: 2024-05-31 13:14:44 +0000 URL: https://git.openjdk.org/loom/commit/32ee252c455d3ddcb5954698b546ac39a40515e8 8333169: javac NullPointerException record.type Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! test/langtools/tools/javac/patterns/Exhaustiveness.java Changeset: 1e04ee6d Author: Hannes Walln?fer Date: 2024-05-31 13:19:15 +0000 URL: https://git.openjdk.org/loom/commit/1e04ee6d57d5fe84e1d202b16e8d13dc13c002ff 8331579: Reference to primitive type fails without error or warning Reviewed-by: jjg, prappo ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java ! test/langtools/jdk/javadoc/doclet/testLinkTaglet/TestLinkTagletPrimitive.java Changeset: d9e7b7e7 Author: Jaikiran Pai Date: 2024-05-31 13:43:40 +0000 URL: https://git.openjdk.org/loom/commit/d9e7b7e7da98a0170d26301a4bbd61aad0127c6e 8210471: GZIPInputStream constructor could leak an un-end()ed Inflater Reviewed-by: lancea ! src/java.base/share/classes/java/util/zip/GZIPInputStream.java + test/jdk/java/util/zip/GZIP/BasicGZIPInputStreamTest.java Changeset: 5abc0292 Author: Erik Gahlin Date: 2024-05-31 13:45:17 +0000 URL: https://git.openjdk.org/loom/commit/5abc02927b480a85fadecf8d03850604510276e4 8331877: JFR: Remove JIInliner framework Reviewed-by: mgronlun + src/jdk.jfr/share/classes/jdk/jfr/internal/JDKEvents.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/JVMUpcalls.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformRecorder.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/SecuritySupport.java - src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java - src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JIClassInstrumentation.java - src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JIInliner.java - src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JIInstrumentationMethod.java - src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JIInstrumentationTarget.java - src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JIMethodCallInliner.java - src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JIMethodInliningAdapter.java - src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JIMethodMergeAdapter.java - src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JITypeMapping.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/management/ManagementSupport.java Changeset: 914423e3 Author: Hamlin Li Date: 2024-05-31 15:01:25 +0000 URL: https://git.openjdk.org/loom/commit/914423e3b7162ad934fa4edc46ee37e0f401d27b 8332899: RISC-V: add comment and make the code more readable (if possible) in MacroAssembler::movptr Reviewed-by: rehn, fyang ! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp Changeset: 681137ca Author: Christian Stein Date: 2024-05-31 15:02:55 +0000 URL: https://git.openjdk.org/loom/commit/681137cad2b1de8a0af1dfea949439bcaf5e7500 8333131: Source launcher should work with service loader SPI Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/MemoryClassLoader.java ! test/langtools/tools/javac/launcher/ModuleSourceLauncherTests.java Changeset: e4fbb15c Author: Alex Menkov Date: 2024-05-31 17:23:56 +0000 URL: https://git.openjdk.org/loom/commit/e4fbb15c6a7b18f1ec66176080404818d3871194 8320215: HeapDumper can use DumpWriter buffer during merge Reviewed-by: sspitsyn, yyang ! src/hotspot/share/services/heapDumper.cpp ! src/hotspot/share/services/heapDumperCompression.cpp ! src/hotspot/share/services/heapDumperCompression.hpp Changeset: e650bdf4 Author: Vicente Romero Date: 2024-05-31 17:34:51 +0000 URL: https://git.openjdk.org/loom/commit/e650bdf4654a0459bb2af95f08ba42ca870642d4 8332507: compilation result depends on compilation order Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java + test/langtools/tools/javac/generics/wildcards/separate_compilation/WildcardBoundsNotReadFromClassFileTest.java Changeset: e99f6a65 Author: Maurizio Cimadamore Date: 2024-05-31 17:53:35 +0000 URL: https://git.openjdk.org/loom/commit/e99f6a65a8307e6b31a08a677914dfd20d46687f 8333236: Test java/foreign/TestAccessModes.java is timing out after passing Reviewed-by: jvernee ! src/java.base/share/classes/jdk/internal/foreign/LayoutPath.java ! src/java.base/share/classes/jdk/internal/foreign/Utils.java Changeset: 8aeada10 Author: Bernhard Urban-Forster Committer: Vladimir Kozlov Date: 2024-05-31 18:18:49 +0000 URL: https://git.openjdk.org/loom/commit/8aeada105acd143b38b02123377ef86513eee266 8331159: VM build without C2 fails after JDK-8180450 Reviewed-by: thartmann, kvn, aph ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp Changeset: 9fd0e734 Author: Alexander Matveev Date: 2024-05-31 20:30:32 +0000 URL: https://git.openjdk.org/loom/commit/9fd0e7349ebf4a49b5c0c7a16c866b5b8e626b53 8332110: [macos] jpackage tries to sign added files without the --mac-sign option Reviewed-by: asemenyuk ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppImageBuilder.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 ! test/jdk/tools/jpackage/macosx/SigningOptionsTest.java Changeset: 2cae9a03 Author: Brent Christian Date: 2024-05-31 21:29:30 +0000 URL: https://git.openjdk.org/loom/commit/2cae9a0397f4e46c6faec0a998ecad1c7015564d 8314480: Memory ordering spec updates in java.lang.ref Reviewed-by: dholmes, alanb, darcy ! src/java.base/share/classes/java/lang/ref/Cleaner.java ! src/java.base/share/classes/java/lang/ref/Reference.java ! src/java.base/share/classes/java/lang/ref/ReferenceQueue.java ! src/java.base/share/classes/java/lang/ref/package-info.java Changeset: 10eb1cb6 Author: Jonathan Gibbons Date: 2024-05-31 22:16:35 +0000 URL: https://git.openjdk.org/loom/commit/10eb1cb639095caa2636cc87c45201d4f8cf1eb4 8331879: Clean up non-standard use of /// comments in `java.base` Reviewed-by: naoto, iris, darcy ! make/modules/java.base/Java.gmk ! src/java.base/share/classes/java/lang/ClassValue.java ! src/java.base/share/classes/java/lang/String.java ! src/java.base/share/classes/java/lang/invoke/ConstantGroup.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/invoke/MethodType.java ! src/java.base/share/classes/java/util/GregorianCalendar.java ! src/java.base/share/classes/java/util/regex/CharPredicates.java ! src/java.base/share/classes/jdk/internal/icu/impl/StringPrepDataReader.java ! src/java.base/share/classes/jdk/internal/icu/lang/UCharacterDirection.java ! src/java.base/share/classes/jdk/internal/misc/Unsafe.java ! src/java.base/share/classes/jdk/internal/org/xml/sax/Attributes.java ! src/java.base/share/classes/jdk/internal/org/xml/sax/InputSource.java ! src/java.base/share/classes/jdk/internal/org/xml/sax/SAXException.java ! src/java.base/share/classes/jdk/internal/org/xml/sax/SAXParseException.java ! src/java.base/share/classes/jdk/internal/org/xml/sax/XMLReader.java ! src/java.base/share/classes/jdk/internal/org/xml/sax/helpers/DefaultHandler.java ! src/java.base/share/classes/jdk/internal/reflect/ClassFileAssembler.java ! src/java.base/share/classes/jdk/internal/util/xml/PropertiesDefaultHandler.java ! src/java.base/share/classes/sun/invoke/util/ValueConversions.java ! src/java.base/share/classes/sun/invoke/util/Wrapper.java ! src/java.base/share/classes/sun/util/BuddhistCalendar.java ! src/java.base/share/classes/sun/util/calendar/CalendarSystem.java ! src/jdk.unsupported/share/classes/sun/misc/Unsafe.java Changeset: dcdeef57 Author: Alan Bateman Date: 2024-06-01 06:24:43 +0000 URL: https://git.openjdk.org/loom/commit/dcdeef578d79e1c5fef9eeacbd75c083bdb3a1cd Merge ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp ! src/hotspot/share/prims/jvmtiEnv.cpp ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! src/hotspot/share/prims/jvmtiEnvBase.hpp ! src/hotspot/share/runtime/globals.hpp + src/jdk.jfr/share/classes/jdk/jfr/internal/JDKEvents.java ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp ! src/hotspot/share/prims/jvmtiEnv.cpp ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! src/hotspot/share/prims/jvmtiEnvBase.hpp ! src/hotspot/share/runtime/globals.hpp ! src/jdk.jfr/share/classes/jdk/jfr/internal/JDKEvents.java Changeset: 3457542d Author: Alan Bateman Date: 2024-05-31 18:45:36 +0000 URL: https://git.openjdk.org/loom/commit/3457542db06d56b94917c70a0d5a9915062c687f New stress test for monitors + test/jdk/java/lang/Thread/virtual/stress/SkynetWithMonitors.java Changeset: c6988edb Author: Alan Bateman Date: 2024-06-01 06:27:19 +0000 URL: https://git.openjdk.org/loom/commit/c6988edbaaabf6589403aef100bf6026b9199ed6 Merge Changeset: c2d41469 Author: Alan Bateman Date: 2024-06-01 06:27:45 +0000 URL: https://git.openjdk.org/loom/commit/c2d41469c9a941ae0990e1cb2f814afa4063c743 Unexclude java/foreign/TestAccessModes.java ! test/jdk/ProblemList-Virtual.txt From duke at openjdk.org Sat Jun 1 08:22:42 2024 From: duke at openjdk.org (duke) Date: Sat, 1 Jun 2024 08:22:42 GMT Subject: git: openjdk/loom: master: 36 new changesets Message-ID: <425d43f9-6de6-4b38-a10e-aab32d8f954e@openjdk.org> Changeset: 1d889e54 Author: Jatin Bhateja Date: 2024-05-30 17:14:07 +0000 URL: https://git.openjdk.org/loom/commit/1d889e54fc6d6039e68191420bb377ea560e2eaa 8332487: Regression in Crypto-AESGCMBench.encrypt (and others) after JDK-8328181 Reviewed-by: thartmann ! src/hotspot/cpu/x86/x86.ad Changeset: 922e312b Author: Chris Plummer Date: 2024-05-30 18:03:44 +0000 URL: https://git.openjdk.org/loom/commit/922e312b0ab3ac54979ffdc53a8d8338e52234df 8328611: Thread safety issue in com.sun.tools.jdi.ReferenceTypeImpl::classObject Reviewed-by: amenkov, sspitsyn ! src/jdk.jdi/share/classes/com/sun/tools/jdi/ReferenceTypeImpl.java Changeset: 44c1845a Author: Alex Menkov Date: 2024-05-30 18:12:43 +0000 URL: https://git.openjdk.org/loom/commit/44c1845ae7fdff524d4a60a51362834cfea5c5da 8330852: All callers of JvmtiEnvBase::get_threadOop_and_JavaThread should pass current thread explicitly Reviewed-by: sspitsyn, cjplummer ! src/hotspot/share/prims/jvmtiEnv.cpp ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! src/hotspot/share/prims/jvmtiEnvBase.hpp Changeset: 11e926cf Author: Evgeny Nikitin Committer: Leonid Mesnik Date: 2024-05-30 18:21:29 +0000 URL: https://git.openjdk.org/loom/commit/11e926cf50c64d57b0dba095eb62c2be4a8a8f1e 8332777: Update JCStress test suite Reviewed-by: lmesnik ! test/hotspot/jtreg/applications/jcstress/JcstressRunner.java Changeset: b3e29db1 Author: Leonid Mesnik Date: 2024-05-30 18:21:40 +0000 URL: https://git.openjdk.org/loom/commit/b3e29db14466ccc64a2815224ecefab4cec4c775 8333108: Update vmTestbase/nsk/share/DebugeeProcess.java to don't use finalization Reviewed-by: cjplummer, sspitsyn ! test/hotspot/jtreg/vmTestbase/nsk/jdi/BScenarios/multithrd/tc04x001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VMDeathEvent/_itself_/vmdeath003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/exit/exit001.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Binder.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jdwp/Binder.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeProcess.java Changeset: ec88c6a8 Author: Chris Plummer Date: 2024-05-30 18:59:21 +0000 URL: https://git.openjdk.org/loom/commit/ec88c6a872a97cee1cde8844f5ee6834023a10c6 8332917: failure_handler should execute gdb "info threads" command on linux Reviewed-by: lmesnik, sspitsyn ! test/failure_handler/src/share/conf/linux.properties Changeset: 79f49983 Author: Joe Darcy Date: 2024-05-30 19:57:21 +0000 URL: https://git.openjdk.org/loom/commit/79f49983d3597e8ab1ffb30b23ce41ae5f298c4e 8321314: Reinstate disabling the compiler's default active annotation processing Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! test/langtools/tools/javac/6341866/T6341866.java ! test/langtools/tools/javac/diags/examples.not-yet.txt ! test/langtools/tools/javac/diags/examples/ProcUseProcOrImplicit/ProcUseProcOrImplicit.java ! test/langtools/tools/javac/processing/options/TestNoteOnImplicitProcessing.java Changeset: ffb0867e Author: Justin Lu Date: 2024-05-30 20:05:22 +0000 URL: https://git.openjdk.org/loom/commit/ffb0867e2c07b41cb7124e11fe6cf63d9471f0d2 8331485: Odd Results when Parsing Scientific Notation with Large Exponent 8331680: NumberFormat is missing some bad exponent strict parse cases Reviewed-by: naoto ! src/java.base/share/classes/java/text/DecimalFormat.java + test/jdk/java/text/Format/DecimalFormat/LargeExponentsTest.java ! test/jdk/java/text/Format/NumberFormat/LenientParseTest.java ! test/jdk/java/text/Format/NumberFormat/StrictParseTest.java Changeset: 3634a910 Author: Chris Plummer Date: 2024-05-30 20:38:38 +0000 URL: https://git.openjdk.org/loom/commit/3634a9105053717f3099982390ce2b9e564f0ac5 8332751: Broken link in VirtualMachine.html Reviewed-by: amenkov, alanb ! src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java Changeset: e304a8ae Author: Alexey Semenyuk Date: 2024-05-31 03:02:09 +0000 URL: https://git.openjdk.org/loom/commit/e304a8ae63fdec125e085bd5048d62cf555e2caa 8333307: Don't suppress jpackage logging in tests when it is detecting packaging tools in the system Reviewed-by: almatvee ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/PackageType.java Changeset: 1b7d59f1 Author: Alexey Semenyuk Date: 2024-05-31 03:05:09 +0000 URL: https://git.openjdk.org/loom/commit/1b7d59f171d0e2a3bdd234cddffac548b1f8ba57 8333303: Issues with DottedVersion class Reviewed-by: almatvee ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/DottedVersion.java ! src/jdk.jpackage/share/classes/jdk/jpackage/internal/ToolValidator.java ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixAppImageFragmentBuilder.java ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixFragmentBuilder.java ! test/jdk/tools/jpackage/junit/jdk.jpackage/jdk/jpackage/internal/CompareDottedVersionTest.java ! test/jdk/tools/jpackage/junit/jdk.jpackage/jdk/jpackage/internal/DottedVersionTest.java Changeset: 2ab8ab56 Author: Jan Lahoda Date: 2024-05-31 05:54:39 +0000 URL: https://git.openjdk.org/loom/commit/2ab8ab56130ca258bf0347ea44e74a8cad3d537d 8332858: References with escapes have broken positions after they are transformed Reviewed-by: vromero, jjg ! src/jdk.internal.md/share/classes/jdk/internal/markdown/MarkdownTransformer.java ! test/langtools/tools/javac/doctree/MarkdownTransformerPositionTest.java Changeset: 22ef827e Author: Adam Sotona Date: 2024-05-31 06:26:35 +0000 URL: https://git.openjdk.org/loom/commit/22ef827e2cc2409f21ad5c26611cb13d39b5cb3e 8320396: Class-File API ClassModel::verify should include checks from hotspot/share/classfile/classFileParser.cpp Reviewed-by: liach, mcimadamore ! src/java.base/share/classes/jdk/internal/classfile/impl/ClassPrinterImpl.java + src/java.base/share/classes/jdk/internal/classfile/impl/verifier/ParserVerifier.java ! src/java.base/share/classes/jdk/internal/classfile/impl/verifier/VerificationWrapper.java ! src/java.base/share/classes/jdk/internal/classfile/impl/verifier/VerifierImpl.java ! test/jdk/jdk/classfile/ClassPrinterTest.java ! test/jdk/jdk/classfile/VerifierSelfTest.java Changeset: ba323b51 Author: Thomas Stuefe Date: 2024-05-31 06:50:29 +0000 URL: https://git.openjdk.org/loom/commit/ba323b515d8821895356507bdb1e94df0776dd5a 8333047: Remove arena-size-workaround in jvmtiUtils.cpp Reviewed-by: jsjolen, sspitsyn ! src/hotspot/share/memory/arena.cpp ! src/hotspot/share/memory/arena.hpp ! src/hotspot/share/prims/jvmtiUtil.cpp Changeset: 95c8a69b Author: Christian Hagedorn Date: 2024-05-31 06:56:57 +0000 URL: https://git.openjdk.org/loom/commit/95c8a69b0e7a99ec0cd41aa9b6ba033fd3216695 8332032: C2: Remove ExpandSubTypeCheckAtParseTime flag Reviewed-by: thartmann, rcastanedalo ! src/hotspot/share/opto/c2_globals.hpp ! src/hotspot/share/opto/graphKit.cpp ! test/hotspot/jtreg/compiler/types/TestSubTypeCheckMacroTrichotomy.java ! test/hotspot/jtreg/compiler/types/TestSubTypeCheckWithBottomArray.java Changeset: bb4aed94 Author: Albert Mingkun Yang Date: 2024-05-31 07:58:32 +0000 URL: https://git.openjdk.org/loom/commit/bb4aed944ea511df8ddfbd50c885a271a2ea9464 8332961: Parallel: Limit PSParallelCompact::verify_complete range Reviewed-by: tschatzl, gli ! src/hotspot/share/gc/parallel/psParallelCompact.cpp Changeset: 778ad00a Author: Aggelos Biboudis Date: 2024-05-31 08:43:54 +0000 URL: https://git.openjdk.org/loom/commit/778ad00af8eafa65604135088ad7d37bf5b8fc39 8308642: Unhelpful pattern switch error: illegal fall-through to a pattern Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties Changeset: a7864af0 Author: Adam Sotona Date: 2024-05-31 08:48:14 +0000 URL: https://git.openjdk.org/loom/commit/a7864af08acbe63d09f770ca66780738260faac4 8182774: Verify code in javap Reviewed-by: mcimadamore ! src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/JavapTask.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/Options.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap.properties ! src/jdk.jdeps/share/man/javap.1 + test/langtools/tools/javap/VerificationTest.java Changeset: 7ab74c5f Author: SendaoYan Committer: Severin Gehwolf Date: 2024-05-31 10:13:57 +0000 URL: https://git.openjdk.org/loom/commit/7ab74c5f268dac82bbd36355acf8e4f3d357134c 8333200: Test containers/docker/TestPids.java fails Limit value -1 is not accepted as unlimited Reviewed-by: sgehwolf ! test/hotspot/jtreg/containers/docker/TestPids.java Changeset: d4812151 Author: Erik ?sterlund Date: 2024-05-31 12:49:22 +0000 URL: https://git.openjdk.org/loom/commit/d48121512658003f21826e037590541464141ed6 8333005: Deadlock when setting or updating the inline cache Reviewed-by: sjohanss, shade ! src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp ! src/hotspot/share/gc/shenandoah/shenandoahNMethod.cpp ! src/hotspot/share/gc/shenandoah/shenandoahNMethod.hpp ! src/hotspot/share/gc/shenandoah/shenandoahNMethod.inline.hpp ! src/hotspot/share/gc/shenandoah/shenandoahUnload.cpp ! src/hotspot/share/gc/x/xNMethod.cpp ! src/hotspot/share/gc/x/xNMethod.hpp ! src/hotspot/share/gc/x/xNMethodData.cpp ! src/hotspot/share/gc/x/xNMethodData.hpp ! src/hotspot/share/gc/x/xUnload.cpp ! src/hotspot/share/gc/z/zNMethod.cpp ! src/hotspot/share/gc/z/zNMethod.hpp ! src/hotspot/share/gc/z/zNMethodData.cpp ! src/hotspot/share/gc/z/zNMethodData.hpp ! src/hotspot/share/gc/z/zUnload.cpp Changeset: 2f2dc228 Author: Erik ?sterlund Date: 2024-05-31 12:50:41 +0000 URL: https://git.openjdk.org/loom/commit/2f2dc2289bce47d8071a86215218f345cce71dba 8330981: ZGC: Should not dedup strings in the finalizer graph Reviewed-by: stefank, aboldtch, tschatzl ! src/hotspot/share/gc/x/xMark.cpp ! src/hotspot/share/gc/z/zMark.cpp Changeset: 79a78f03 Author: Zhengyu Gu Date: 2024-05-31 13:00:04 +0000 URL: https://git.openjdk.org/loom/commit/79a78f032effdae40816e7d3e2596dc2b8ef5b9f 8333129: Move ShrinkHeapInSteps flag to Serial GC Reviewed-by: dholmes, kbarrett ! src/hotspot/share/gc/serial/serial_globals.hpp ! src/hotspot/share/runtime/globals.hpp Changeset: e930bc1f Author: Hannes Walln?fer Date: 2024-05-31 13:11:23 +0000 URL: https://git.openjdk.org/loom/commit/e930bc1fbbbb0f2f8a4d03bfe7a8f4420335a8a2 8329537: Nested and enclosing classes should be linked separately in breadcrumb navigation Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassUseWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/DocFilesHandler.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Navigation.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageTreeWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageUseWriter.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriter.java ! test/langtools/jdk/javadoc/doclet/testNavigation/TestNavigation.java Changeset: 32ee252c Author: Jan Lahoda Date: 2024-05-31 13:14:44 +0000 URL: https://git.openjdk.org/loom/commit/32ee252c455d3ddcb5954698b546ac39a40515e8 8333169: javac NullPointerException record.type Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! test/langtools/tools/javac/patterns/Exhaustiveness.java Changeset: 1e04ee6d Author: Hannes Walln?fer Date: 2024-05-31 13:19:15 +0000 URL: https://git.openjdk.org/loom/commit/1e04ee6d57d5fe84e1d202b16e8d13dc13c002ff 8331579: Reference to primitive type fails without error or warning Reviewed-by: jjg, prappo ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java ! test/langtools/jdk/javadoc/doclet/testLinkTaglet/TestLinkTagletPrimitive.java Changeset: d9e7b7e7 Author: Jaikiran Pai Date: 2024-05-31 13:43:40 +0000 URL: https://git.openjdk.org/loom/commit/d9e7b7e7da98a0170d26301a4bbd61aad0127c6e 8210471: GZIPInputStream constructor could leak an un-end()ed Inflater Reviewed-by: lancea ! src/java.base/share/classes/java/util/zip/GZIPInputStream.java + test/jdk/java/util/zip/GZIP/BasicGZIPInputStreamTest.java Changeset: 5abc0292 Author: Erik Gahlin Date: 2024-05-31 13:45:17 +0000 URL: https://git.openjdk.org/loom/commit/5abc02927b480a85fadecf8d03850604510276e4 8331877: JFR: Remove JIInliner framework Reviewed-by: mgronlun + src/jdk.jfr/share/classes/jdk/jfr/internal/JDKEvents.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/JVMUpcalls.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformRecorder.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/SecuritySupport.java - src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java - src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JIClassInstrumentation.java - src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JIInliner.java - src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JIInstrumentationMethod.java - src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JIInstrumentationTarget.java - src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JIMethodCallInliner.java - src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JIMethodInliningAdapter.java - src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JIMethodMergeAdapter.java - src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JITypeMapping.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/management/ManagementSupport.java Changeset: 914423e3 Author: Hamlin Li Date: 2024-05-31 15:01:25 +0000 URL: https://git.openjdk.org/loom/commit/914423e3b7162ad934fa4edc46ee37e0f401d27b 8332899: RISC-V: add comment and make the code more readable (if possible) in MacroAssembler::movptr Reviewed-by: rehn, fyang ! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp Changeset: 681137ca Author: Christian Stein Date: 2024-05-31 15:02:55 +0000 URL: https://git.openjdk.org/loom/commit/681137cad2b1de8a0af1dfea949439bcaf5e7500 8333131: Source launcher should work with service loader SPI Reviewed-by: jjg ! src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/MemoryClassLoader.java ! test/langtools/tools/javac/launcher/ModuleSourceLauncherTests.java Changeset: e4fbb15c Author: Alex Menkov Date: 2024-05-31 17:23:56 +0000 URL: https://git.openjdk.org/loom/commit/e4fbb15c6a7b18f1ec66176080404818d3871194 8320215: HeapDumper can use DumpWriter buffer during merge Reviewed-by: sspitsyn, yyang ! src/hotspot/share/services/heapDumper.cpp ! src/hotspot/share/services/heapDumperCompression.cpp ! src/hotspot/share/services/heapDumperCompression.hpp Changeset: e650bdf4 Author: Vicente Romero Date: 2024-05-31 17:34:51 +0000 URL: https://git.openjdk.org/loom/commit/e650bdf4654a0459bb2af95f08ba42ca870642d4 8332507: compilation result depends on compilation order Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java + test/langtools/tools/javac/generics/wildcards/separate_compilation/WildcardBoundsNotReadFromClassFileTest.java Changeset: e99f6a65 Author: Maurizio Cimadamore Date: 2024-05-31 17:53:35 +0000 URL: https://git.openjdk.org/loom/commit/e99f6a65a8307e6b31a08a677914dfd20d46687f 8333236: Test java/foreign/TestAccessModes.java is timing out after passing Reviewed-by: jvernee ! src/java.base/share/classes/jdk/internal/foreign/LayoutPath.java ! src/java.base/share/classes/jdk/internal/foreign/Utils.java Changeset: 8aeada10 Author: Bernhard Urban-Forster Committer: Vladimir Kozlov Date: 2024-05-31 18:18:49 +0000 URL: https://git.openjdk.org/loom/commit/8aeada105acd143b38b02123377ef86513eee266 8331159: VM build without C2 fails after JDK-8180450 Reviewed-by: thartmann, kvn, aph ! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp Changeset: 9fd0e734 Author: Alexander Matveev Date: 2024-05-31 20:30:32 +0000 URL: https://git.openjdk.org/loom/commit/9fd0e7349ebf4a49b5c0c7a16c866b5b8e626b53 8332110: [macos] jpackage tries to sign added files without the --mac-sign option Reviewed-by: asemenyuk ! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppImageBuilder.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 ! test/jdk/tools/jpackage/macosx/SigningOptionsTest.java Changeset: 2cae9a03 Author: Brent Christian Date: 2024-05-31 21:29:30 +0000 URL: https://git.openjdk.org/loom/commit/2cae9a0397f4e46c6faec0a998ecad1c7015564d 8314480: Memory ordering spec updates in java.lang.ref Reviewed-by: dholmes, alanb, darcy ! src/java.base/share/classes/java/lang/ref/Cleaner.java ! src/java.base/share/classes/java/lang/ref/Reference.java ! src/java.base/share/classes/java/lang/ref/ReferenceQueue.java ! src/java.base/share/classes/java/lang/ref/package-info.java Changeset: 10eb1cb6 Author: Jonathan Gibbons Date: 2024-05-31 22:16:35 +0000 URL: https://git.openjdk.org/loom/commit/10eb1cb639095caa2636cc87c45201d4f8cf1eb4 8331879: Clean up non-standard use of /// comments in `java.base` Reviewed-by: naoto, iris, darcy ! make/modules/java.base/Java.gmk ! src/java.base/share/classes/java/lang/ClassValue.java ! src/java.base/share/classes/java/lang/String.java ! src/java.base/share/classes/java/lang/invoke/ConstantGroup.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleNatives.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/invoke/MethodType.java ! src/java.base/share/classes/java/util/GregorianCalendar.java ! src/java.base/share/classes/java/util/regex/CharPredicates.java ! src/java.base/share/classes/jdk/internal/icu/impl/StringPrepDataReader.java ! src/java.base/share/classes/jdk/internal/icu/lang/UCharacterDirection.java ! src/java.base/share/classes/jdk/internal/misc/Unsafe.java ! src/java.base/share/classes/jdk/internal/org/xml/sax/Attributes.java ! src/java.base/share/classes/jdk/internal/org/xml/sax/InputSource.java ! src/java.base/share/classes/jdk/internal/org/xml/sax/SAXException.java ! src/java.base/share/classes/jdk/internal/org/xml/sax/SAXParseException.java ! src/java.base/share/classes/jdk/internal/org/xml/sax/XMLReader.java ! src/java.base/share/classes/jdk/internal/org/xml/sax/helpers/DefaultHandler.java ! src/java.base/share/classes/jdk/internal/reflect/ClassFileAssembler.java ! src/java.base/share/classes/jdk/internal/util/xml/PropertiesDefaultHandler.java ! src/java.base/share/classes/sun/invoke/util/ValueConversions.java ! src/java.base/share/classes/sun/invoke/util/Wrapper.java ! src/java.base/share/classes/sun/util/BuddhistCalendar.java ! src/java.base/share/classes/sun/util/calendar/CalendarSystem.java ! src/jdk.unsupported/share/classes/sun/misc/Unsafe.java From Alan.Bateman at oracle.com Sat Jun 1 08:33:02 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 1 Jun 2024 09:33:02 +0100 Subject: Virtual threads and File IO In-Reply-To: References: Message-ID: On 31/05/2024 20:38, Robert Engels wrote: > Hi, > > An interesting question came up on the Go support channels. One of the principle engineers stated that for local file IO, the Go routine (similar to virtual thread) won?t release the carrier thread. > > Is this the same with Java virtual threads? Yes, local IO is typically fast - but it is still order of magnitudes slower than memory computations - which the virtual thread could be doing while waiting for the IO request to be serviced. > As things stand, file I/O operation do capture the carrier. For local files and most where it is almost always buffered I/O then it shouldn't be much of an issue. If files are opened for direct I/O, or with the synchronized I/O options (think O_SYNC), the target parallelism is increased for the duration of the I/O operation so there is a spare carrier available for other virtual threads to make progress. There has been exploration into using asynchronous I/O, and io_uring, for the implementations but there isn't a conclusion at this time. Main thing is the bookkeeping and overhead when doing file I/O ops that may take only a few microseconds. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From filia.aleks at gmail.com Sat Jun 1 16:56:39 2024 From: filia.aleks at gmail.com (Alex) Date: Sat, 1 Jun 2024 18:56:39 +0200 Subject: Synchronized methods and virtual threads Message-ID: Hi everyone, I have one question about the synchronized methods and virtual threads. So in Java 23 the issue with pinned threads for synchronized methods was fixed. Before this fix many projects did fixes and replaced synchronized with Lock. What is the latest recommendation? Keep replacing synchronized with Lock or wait for Java 23 and use synchronized methods? Thanks, Alex Filichkin -------------- next part -------------- An HTML attachment was scrubbed... URL: From masoud.parvari at gmail.com Sat Jun 1 17:15:28 2024 From: masoud.parvari at gmail.com (masoud parvari) Date: Sat, 1 Jun 2024 19:15:28 +0200 Subject: Synchronized methods and virtual threads In-Reply-To: References: Message-ID: The fix is in the loom repo, not in the mainline yet, and most probably won't make it to jdk 23. So replacing synchronized with ReentrantLock is still the solution. On Sat, Jun 1, 2024 at 6:57?PM Alex wrote: > Hi everyone, > I have one question about the synchronized methods and virtual threads. > So in Java 23 the issue with pinned threads for synchronized methods was > fixed. > > Before this fix many projects did fixes and replaced synchronized with > Lock. What is the latest recommendation? Keep replacing synchronized with > Lock or wait for Java 23 and use synchronized methods? > > Thanks, > > Alex Filichkin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Sun Jun 2 06:56:08 2024 From: duke at openjdk.org (duke) Date: Sun, 2 Jun 2024 06:56:08 GMT Subject: git: openjdk/loom: fibers: 2 new changesets Message-ID: <055bd615-a26a-460d-b9a9-ef55fcd3c9a1@openjdk.org> Changeset: 5e6075ee Author: Alan Bateman Date: 2024-06-02 07:52:11 +0000 URL: https://git.openjdk.org/loom/commit/5e6075ee7e280f8d2402a26ac0a55d9db1da605d Dial down stress test for debug builds ! test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALotWhenBlocked.java ! test/jdk/java/lang/Thread/virtual/stress/SkynetWithMonitors.java Changeset: f88bd1e9 Author: Alan Bateman Date: 2024-06-02 07:52:31 +0000 URL: https://git.openjdk.org/loom/commit/f88bd1e996aeba8b3581975b607a5cebb466a72f State name in comment out of date ! src/hotspot/share/runtime/objectMonitor.cpp From aph-open at littlepinkcloud.com Sun Jun 2 11:07:39 2024 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Sun, 2 Jun 2024 12:07:39 +0100 Subject: Synchronized methods and virtual threads In-Reply-To: References: Message-ID: On 6/1/24 17:56, Alex wrote: > Before this fix many projects did fixes and replaced synchronized with Lock. What is the latest recommendation? Keep replacing synchronized with Lock or wait for Java 23 and use synchronized methods? I'd use Lock for the future. Synchronized plays very badly with Value Objects, for example. Being able to synchronize on any object is something of a legacy feature. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From cay.horstmann at gmail.com Mon Jun 3 07:20:59 2024 From: cay.horstmann at gmail.com (Cay Horstmann) Date: Mon, 3 Jun 2024 09:20:59 +0200 Subject: Synchronized methods and virtual threads In-Reply-To: References: Message-ID: <0b7d6292-18b8-48d0-92f7-78ff926f0c62@gmail.com> On 02/06/2024 13.07, Andrew Haley wrote: > On 6/1/24 17:56, Alex wrote: >> Before this fix many projects did fixes and replaced synchronized with Lock. What is the latest recommendation? Keep replacing synchronized with Lock or wait for Java 23 and use synchronized methods? > > I'd use Lock for the future. Synchronized plays very badly with Value > Objects, for example. Being able to synchronize on any object is something > of a legacy feature. At least since Java 5, synchronized(obj) has been a code smell. A class with synchronized methods can be appropriate when carefully designed. (Of course, value classes cannot have synchronized methods.) -- Cay S. Horstmann | https://horstmann.com From duke at openjdk.org Mon Jun 3 12:43:02 2024 From: duke at openjdk.org (duke) Date: Mon, 3 Jun 2024 12:43:02 GMT Subject: git: openjdk/loom: fibers: 2 new changesets Message-ID: <100ee210-adf0-4f07-8f99-5cfe53e9a242@openjdk.org> Changeset: 9f03281d Author: Alan Bateman Date: 2024-06-03 08:12:34 +0000 URL: https://git.openjdk.org/loom/commit/9f03281db6a21c1d0228ad2c9c44ddd14ed14896 Update test to be suitable for test1, plus stress testing with debug builds + test/jdk/java/lang/Thread/virtual/stress/Skynet100kWithMonitors.java - test/jdk/java/lang/Thread/virtual/stress/SkynetWithMonitors.java Changeset: a7874964 Author: Alan Bateman Date: 2024-06-03 13:40:05 +0000 URL: https://git.openjdk.org/loom/commit/a7874964263400d38f65046d6a10f56e8d97b423 Re-enable serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! test/hotspot/jtreg/serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java From cay at horstmann.com Mon Jun 3 13:23:20 2024 From: cay at horstmann.com (Cay Horstmann) Date: Mon, 3 Jun 2024 15:23:20 +0200 Subject: Synchronized methods and virtual threads In-Reply-To: <56A377DC-0A10-4691-A587-8D0E9926DD80@icloud.com> References: <0b7d6292-18b8-48d0-92f7-78ff926f0c62@gmail.com> <56A377DC-0A10-4691-A587-8D0E9926DD80@icloud.com> Message-ID: <35a733db-5b8c-4427-94e9-0c485a66ca18@horstmann.com> I am not talking about synchronized methods but about block statements (JLS 14.19). synchronized (obj) { } On 03/06/2024 14.31, robert engels wrote: > Reference for synchronized being a code smell? > > Synchronized methods can be much more efficient than locks as the runtime can optimize them away, bias locking, etc. > >> On Jun 3, 2024, at 2:21?AM, Cay Horstmann wrote: >> >> ?On 02/06/2024 13.07, Andrew Haley wrote: >>>> On 6/1/24 17:56, Alex wrote: >>>> Before this fix many projects did fixes and replaced synchronized with Lock. What is the latest recommendation? Keep replacing synchronized with Lock or wait for Java 23 and use synchronized methods? >>> I'd use Lock for the future. Synchronized plays very badly with Value >>> Objects, for example. Being able to synchronize on any object is something >>> of a legacy feature. >> >> At least since Java 5, synchronized(obj) has been a code smell. A class with synchronized methods can be appropriate when carefully designed. (Of course, value classes cannot have synchronized methods.) >> >> -- >> >> Cay S. Horstmann | https://horstmann.com -- -- Cay S. Horstmann | https://horstmann.com From robaho at icloud.com Mon Jun 3 12:31:26 2024 From: robaho at icloud.com (robert engels) Date: Mon, 3 Jun 2024 07:31:26 -0500 Subject: Synchronized methods and virtual threads In-Reply-To: <0b7d6292-18b8-48d0-92f7-78ff926f0c62@gmail.com> References: <0b7d6292-18b8-48d0-92f7-78ff926f0c62@gmail.com> Message-ID: <56A377DC-0A10-4691-A587-8D0E9926DD80@icloud.com> Reference for synchronized being a code smell? Synchronized methods can be much more efficient than locks as the runtime can optimize them away, bias locking, etc. > On Jun 3, 2024, at 2:21?AM, Cay Horstmann wrote: > > ?On 02/06/2024 13.07, Andrew Haley wrote: >>> On 6/1/24 17:56, Alex wrote: >>> Before this fix many projects did fixes and replaced synchronized with Lock. What is the latest recommendation? Keep replacing synchronized with Lock or wait for Java 23 and use synchronized methods? >> I'd use Lock for the future. Synchronized plays very badly with Value >> Objects, for example. Being able to synchronize on any object is something >> of a legacy feature. > > At least since Java 5, synchronized(obj) has been a code smell. A class with synchronized methods can be appropriate when carefully designed. (Of course, value classes cannot have synchronized methods.) > > -- > > Cay S. Horstmann | https://horstmann.com From robaho at icloud.com Mon Jun 3 13:26:40 2024 From: robaho at icloud.com (robert engels) Date: Mon, 3 Jun 2024 08:26:40 -0500 Subject: Synchronized methods and virtual threads In-Reply-To: <35a733db-5b8c-4427-94e9-0c485a66ca18@horstmann.com> References: <35a733db-5b8c-4427-94e9-0c485a66ca18@horstmann.com> Message-ID: <2869D8AF-5CC4-4197-B395-3493030AB625@icloud.com> They are one and the same when they lock on the object itself. Synchronized block statements allow the lock duration to be minimized while maintaining the natural code structure (I.e not adding additional methods). > On Jun 3, 2024, at 8:24?AM, Cay Horstmann wrote: > > ?I am not talking about synchronized methods but about block statements (JLS 14.19). > > synchronized (obj) { > > } > >> On 03/06/2024 14.31, robert engels wrote: >> Reference for synchronized being a code smell? >> Synchronized methods can be much more efficient than locks as the runtime can optimize them away, bias locking, etc. >>>> On Jun 3, 2024, at 2:21?AM, Cay Horstmann wrote: >>> >>> ?On 02/06/2024 13.07, Andrew Haley wrote: >>>>> On 6/1/24 17:56, Alex wrote: >>>>> Before this fix many projects did fixes and replaced synchronized with Lock. What is the latest recommendation? Keep replacing synchronized with Lock or wait for Java 23 and use synchronized methods? >>>> I'd use Lock for the future. Synchronized plays very badly with Value >>>> Objects, for example. Being able to synchronize on any object is something >>>> of a legacy feature. >>> >>> At least since Java 5, synchronized(obj) has been a code smell. A class with synchronized methods can be appropriate when carefully designed. (Of course, value classes cannot have synchronized methods.) >>> >>> -- >>> >>> Cay S. Horstmann | https://horstmann.com > > -- > > -- > > Cay S. Horstmann | https://horstmann.com From robaho at icloud.com Mon Jun 3 14:03:48 2024 From: robaho at icloud.com (Robert Engels) Date: Mon, 3 Jun 2024 09:03:48 -0500 Subject: Virtual threads and File IO In-Reply-To: References: Message-ID: Here is an interesting case study on async file IO under Linux http://blog.lighttpd.net/articles/2006/11/12/lighty-1-5-0-and-linux-aio/ > On May 31, 2024, at 6:22 PM, robert engels wrote: > > I looked into the code. Seems Java is the same. I looked into it - and seems for many workloads async file IO can improve efficiency by 80%. > >> On May 31, 2024, at 5:45?PM, Robert Engels wrote: >> >> ?Hi, >> >> An interesting question came up on the Go support channels. One of the principle engineers stated that for local file IO, the Go routine (similar to virtual thread) won?t release the carrier thread. >> >> Is this the same with Java virtual threads? Yes, local IO is typically fast - but it is still order of magnitudes slower than memory computations - which the virtual thread could be doing while waiting for the IO request to be serviced. >> >> R From pedro.lamarao at prodist.com.br Mon Jun 3 14:28:26 2024 From: pedro.lamarao at prodist.com.br (=?UTF-8?Q?Pedro_Lamar=C3=A3o?=) Date: Mon, 3 Jun 2024 11:28:26 -0300 Subject: Virtual threads and File IO In-Reply-To: References: Message-ID: Linux sendfile and Windows TransmitFile are very specific beasts. If you are sending files to sockets, yes, that should be the best the system can do. For general file I/O in Linux, the API called AIO with aio_read and aio_write is no good. These communicate completion asynchronously via UNIX signals. Linux I/O rings seem to be the way forward, but do not seem ready for general production yet. Some cloud providers disable it because of a history of security bugs. Pedro. Em seg., 3 de jun. de 2024 ?s 11:06, Robert Engels escreveu: > Here is an interesting case study on async file IO under Linux > http://blog.lighttpd.net/articles/2006/11/12/lighty-1-5-0-and-linux-aio/ > > > On May 31, 2024, at 6:22 PM, robert engels wrote: > > > > I looked into the code. Seems Java is the same. I looked into it - and > seems for many workloads async file IO can improve efficiency by 80%. > > > >> On May 31, 2024, at 5:45?PM, Robert Engels wrote: > >> > >> ?Hi, > >> > >> An interesting question came up on the Go support channels. One of the > principle engineers stated that for local file IO, the Go routine (similar > to virtual thread) won?t release the carrier thread. > >> > >> Is this the same with Java virtual threads? Yes, local IO is typically > fast - but it is still order of magnitudes slower than memory computations > - which the virtual thread could be doing while waiting for the IO request > to be serviced. > >> > >> R > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph-open at littlepinkcloud.com Mon Jun 3 14:34:19 2024 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Mon, 3 Jun 2024 15:34:19 +0100 Subject: Synchronized methods and virtual threads In-Reply-To: <56A377DC-0A10-4691-A587-8D0E9926DD80@icloud.com> References: <0b7d6292-18b8-48d0-92f7-78ff926f0c62@gmail.com> <56A377DC-0A10-4691-A587-8D0E9926DD80@icloud.com> Message-ID: <1da4d20c-965c-43b8-9c5f-06412ae12d24@littlepinkcloud.com> On 6/3/24 13:31, robert engels wrote: > Reference for synchronized being a code smell? I'm not sure about any reference, but locking on arbitrary objects makes it hard to reason about a program. At least Locks are explicit locks, as advertised in their type. > Synchronized methods can be much more efficient than locks as > the runtime can optimize them away, "Much more" is a bit of a stretch here, but admittedly they do have better throughput in the mostly-uncontended case. But re locks, I'm going to quote Nir Shavit: "The main tools for handling concurrency in today's programming languages are locks, software constructs that allow sequences of loads and stores to access data in a mutually exclusive manner. Indeed, lock-based programs have been known to deliver amazing performance on multicore architectures. However, it is becoming clear that, while using locks will allow us to continue to reduce the time it takes programs to run, they will cause the time it takes us to write and maintain our programs to shoot back up. "The heart of the problem is, perhaps, that no one really knows how to organize and maintain large systems that rely on locking. Locks are not modular and do not compose, and the association between locks and data is established mostly by convention. Ultimately, the association exists only in the mind of the programmer, and may be documented only in comments." > bias locking, etc. It can't use biased locking any more. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From robaho at icloud.com Mon Jun 3 14:40:32 2024 From: robaho at icloud.com (Robert Engels) Date: Mon, 3 Jun 2024 09:40:32 -0500 Subject: Virtual threads and File IO In-Reply-To: References: Message-ID: <465FAA7B-D8F5-4E04-B809-59853A346F66@icloud.com> Agree. It was only offered as evidence that async handling can offer huge rewards. Since the case study distinguished between socket and file async it was a good example imo. > On Jun 3, 2024, at 9:28 AM, Pedro Lamar?o wrote: > > Linux sendfile and Windows TransmitFile are very specific beasts. > If you are sending files to sockets, yes, that should be the best the system can do. > For general file I/O in Linux, the API called AIO with aio_read and aio_write is no good. > These communicate completion asynchronously via UNIX signals. > Linux I/O rings seem to be the way forward, but do not seem ready for general production yet. > Some cloud providers disable it because of a history of security bugs. > Pedro. > > Em seg., 3 de jun. de 2024 ?s 11:06, Robert Engels > escreveu: > Here is an interesting case study on async file IO under Linux http://blog.lighttpd.net/articles/2006/11/12/lighty-1-5-0-and-linux-aio/ > > > On May 31, 2024, at 6:22 PM, robert engels > wrote: > > > > I looked into the code. Seems Java is the same. I looked into it - and seems for many workloads async file IO can improve efficiency by 80%. > > > >> On May 31, 2024, at 5:45?PM, Robert Engels > wrote: > >> > >> ?Hi, > >> > >> An interesting question came up on the Go support channels. One of the principle engineers stated that for local file IO, the Go routine (similar to virtual thread) won?t release the carrier thread. > >> > >> Is this the same with Java virtual threads? Yes, local IO is typically fast - but it is still order of magnitudes slower than memory computations - which the virtual thread could be doing while waiting for the IO request to be serviced. > >> > >> R > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at icloud.com Mon Jun 3 14:48:49 2024 From: robaho at icloud.com (Robert Engels) Date: Mon, 3 Jun 2024 09:48:49 -0500 Subject: Synchronized methods and virtual threads In-Reply-To: <1da4d20c-965c-43b8-9c5f-06412ae12d24@littlepinkcloud.com> References: <0b7d6292-18b8-48d0-92f7-78ff926f0c62@gmail.com> <56A377DC-0A10-4691-A587-8D0E9926DD80@icloud.com> <1da4d20c-965c-43b8-9c5f-06412ae12d24@littlepinkcloud.com> Message-ID: <2B510F82-CDEE-43B1-8072-6AD32AD514CA@icloud.com> Is there an issue that removes it, I only see https://bugs.openjdk.org/browse/JDK-8235256 which has it still enabled. Regardless, unless this was changed as well, the object monitors can shared and elided - something that a Lock instance cannot - making Object monitors far more memory efficient and performant. There may only be a few instances where large volume object locking is necessary, and you could probably redesign to use arenas, but the built-in locking primitives were foundational in Java?s genesis imo. As to Nir Shavit, not sure I agree - developers have successfully built large-scale locking systems for quite a long time. You can try and go the CSP route of Go - but that often falls down in performance, and/or uses locks anyway. > On Jun 3, 2024, at 9:34 AM, Andrew Haley wrote: > > On 6/3/24 13:31, robert engels wrote: > > Reference for synchronized being a code smell? > > I'm not sure about any reference, but locking on arbitrary > objects makes it hard to reason about a program. At least Locks > are explicit locks, as advertised in their type. > > > Synchronized methods can be much more efficient than locks as > > the runtime can optimize them away, > > "Much more" is a bit of a stretch here, but admittedly they do > have better throughput in the mostly-uncontended case. > > But re locks, I'm going to quote Nir Shavit: > > "The main tools for handling concurrency in today's programming > languages are locks, software constructs that allow sequences of > loads and stores to access data in a mutually exclusive manner. > Indeed, lock-based programs have been known to deliver amazing > performance on multicore architectures. However, it is becoming > clear that, while using locks will allow us to continue to reduce > the time it takes programs to run, they will cause the time it > takes us to write and maintain our programs to shoot back up. > > "The heart of the problem is, perhaps, that no one really knows > how to organize and maintain large systems that rely on locking. > Locks are not modular and do not compose, and the association > between locks and data is established mostly by convention. > Ultimately, the association exists only in the mind of the > programmer, and may be documented only in comments." > > > bias locking, etc. > > It can't use biased locking any more. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon Jun 3 14:59:53 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 3 Jun 2024 15:59:53 +0100 Subject: Synchronized methods and virtual threads In-Reply-To: <2B510F82-CDEE-43B1-8072-6AD32AD514CA@icloud.com> References: <0b7d6292-18b8-48d0-92f7-78ff926f0c62@gmail.com> <56A377DC-0A10-4691-A587-8D0E9926DD80@icloud.com> <1da4d20c-965c-43b8-9c5f-06412ae12d24@littlepinkcloud.com> <2B510F82-CDEE-43B1-8072-6AD32AD514CA@icloud.com> Message-ID: <5f874a48-7b03-4018-ac71-ac010a3a23ce@oracle.com> On 03/06/2024 15:48, Robert Engels wrote: > Is there an issue that removes it, I only see > https://bugs.openjdk.org/browse/JDK-8235256?which has it still enabled. The follow-up to remove, and obsolete the associated VM options, was in JDK 18 [1]. -Alan [1] https://bugs.openjdk.org/browse/JDK-8256425 From robaho at icloud.com Mon Jun 3 15:31:55 2024 From: robaho at icloud.com (Robert Engels) Date: Mon, 3 Jun 2024 10:31:55 -0500 Subject: Synchronized methods and virtual threads In-Reply-To: <5f874a48-7b03-4018-ac71-ac010a3a23ce@oracle.com> References: <0b7d6292-18b8-48d0-92f7-78ff926f0c62@gmail.com> <56A377DC-0A10-4691-A587-8D0E9926DD80@icloud.com> <1da4d20c-965c-43b8-9c5f-06412ae12d24@littlepinkcloud.com> <2B510F82-CDEE-43B1-8072-6AD32AD514CA@icloud.com> <5f874a48-7b03-4018-ac71-ac010a3a23ce@oracle.com> Message-ID: Thanks. Interesting decision. I hope object monitors do not go away. I would think that the VT implementation could be even more performant. > On Jun 3, 2024, at 9:59 AM, Alan Bateman wrote: > > On 03/06/2024 15:48, Robert Engels wrote: >> Is there an issue that removes it, I only see https://bugs.openjdk.org/browse/JDK-8235256 which has it still enabled. > > The follow-up to remove, and obsolete the associated VM options, was in JDK 18 [1]. > > -Alan > > [1] https://bugs.openjdk.org/browse/JDK-8256425 From duke at openjdk.org Mon Jun 3 15:36:17 2024 From: duke at openjdk.org (duke) Date: Mon, 3 Jun 2024 15:36:17 GMT Subject: git: openjdk/loom: fibers: Sync up ForkJoinPool from pull/19131 Message-ID: <1e0fa46a-e804-48b9-87cb-c9e540c4d873@openjdk.org> Changeset: fff23f21 Author: Alan Bateman Date: 2024-06-03 16:34:11 +0000 URL: https://git.openjdk.org/loom/commit/fff23f21cf97feb2d8334500a19c73a52ee308d0 Sync up ForkJoinPool from pull/19131 ! src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java From cay.horstmann at gmail.com Mon Jun 3 20:09:20 2024 From: cay.horstmann at gmail.com (Cay Horstmann) Date: Mon, 3 Jun 2024 22:09:20 +0200 Subject: Synchronized methods and virtual threads In-Reply-To: <2869D8AF-5CC4-4197-B395-3493030AB625@icloud.com> References: <35a733db-5b8c-4427-94e9-0c485a66ca18@horstmann.com> <2869D8AF-5CC4-4197-B395-3493030AB625@icloud.com> Message-ID: A bit of history. The motivation for synchronized methods was to bring Per Brinch Hansen's monitor construct to a mainstream language. In a monitor, all methods are synchronized, and you have mechanisms that in Java are called wait/notifyAll. The way this was done in Java is a bit odd. Why have a lock for potentially every instance, when most classes clearly aren't monitors? And why allow public data and a mix of synchronized and non-synchronized methods? And why make the lock be "this" so it leaks to the public? Per Brinch Hansen wasn't amused: "It is astonishing to me that Java 's insecure parallelism is taken seriously by the programming community, a quarter of a century after the invention of monitors and Concurrent Pascal. It has no merit." Still, with a bit of discipline, you can implement a monitor in Java. As long as nobody does "client-side locking" with synchronized (obj) { ... } And sure, if a method does synchronized (this) for a shorter time than the whole method, that's cool too as an optimization. But that has not been a mainstream thing for a long time. How many synchronized methods do you find in j.u.c.ConcurrentHashMap? Now, admittedly, there are several instances of synchronized (someSeeminglyRandomObject) in the implementation. Also, check out the use of lock objects in Writer/PrintWriter. It's complicated. Nothing wrong with an expert using synchronized because it performs better. But that begs the question. Why does it perform better? Objects typed as locks are surely more suitable as locks than any old object. Their performance should be on par with intrinsic locks. Cheers, Cay On 03/06/2024 15.26, robert engels wrote: > They are one and the same when they lock on the object itself. Synchronized block statements allow the lock duration to be minimized while maintaining the natural code structure (I.e not adding additional methods). > >> On Jun 3, 2024, at 8:24?AM, Cay Horstmann wrote: >> >> ?I am not talking about synchronized methods but about block statements (JLS 14.19). >> >> synchronized (obj) { >> >> } >> >>> On 03/06/2024 14.31, robert engels wrote: >>> Reference for synchronized being a code smell? >>> Synchronized methods can be much more efficient than locks as the runtime can optimize them away, bias locking, etc. >>>>> On Jun 3, 2024, at 2:21?AM, Cay Horstmann wrote: >>>> >>>> ?On 02/06/2024 13.07, Andrew Haley wrote: >>>>>> On 6/1/24 17:56, Alex wrote: >>>>>> Before this fix many projects did fixes and replaced synchronized with Lock. What is the latest recommendation? Keep replacing synchronized with Lock or wait for Java 23 and use synchronized methods? >>>>> I'd use Lock for the future. Synchronized plays very badly with Value >>>>> Objects, for example. Being able to synchronize on any object is something >>>>> of a legacy feature. >>>> >>>> At least since Java 5, synchronized(obj) has been a code smell. A class with synchronized methods can be appropriate when carefully designed. (Of course, value classes cannot have synchronized methods.) >>>> >>>> -- >>>> >>>> Cay S. Horstmann | https://horstmann.com >> >> -- >> >> -- >> >> Cay S. Horstmann | https://horstmann.com -- -- Cay S. Horstmann | https://horstmann.com From robaho at icloud.com Mon Jun 3 20:23:49 2024 From: robaho at icloud.com (Robert Engels) Date: Mon, 3 Jun 2024 15:23:49 -0500 Subject: Synchronized methods and virtual threads In-Reply-To: References: <35a733db-5b8c-4427-94e9-0c485a66ca18@horstmann.com> <2869D8AF-5CC4-4197-B395-3493030AB625@icloud.com> Message-ID: Sure. People used synchronized to create ?lock objects? long before java.util.concurrent - routinely for higher level debugging. You have to also remember a bit of history regarding when Java was created and the relative performance of the machines then. Having an intrinsic lock that the JVM could optimize was highly beneficial - especially when there was no optimizing JIT. There is a LOT of code in the JVM/JDK that uses synchronized... Implementing j.u.c requires compiler/intrinsics/atomics/LockSupport - basically making these objects special anyway. I don?t know of any Java developer that had a problem using synchronized. That being said, if j.u.c can achieve the performance of monitors then the only reason to support it is backward compatibility. Tbh, I am not a fan of the loosey-goosey release every 6 months change anything in Java the way the wind blows mentality. The only aspects that allowed Java to succeed were backwards compatibility and cross platform (and then the JIT for performance) - my opinion of course. > On Jun 3, 2024, at 3:09 PM, Cay Horstmann wrote: > > A bit of history. The motivation for synchronized methods was to bring Per Brinch Hansen's monitor construct to a mainstream language. In a monitor, all methods are synchronized, and you have mechanisms that in Java are called wait/notifyAll. The way this was done in Java is a bit odd. Why have a lock for potentially every instance, when most classes clearly aren't monitors? And why allow public data and a mix of synchronized and non-synchronized methods? And why make the lock be "this" so it leaks to the public? Per Brinch Hansen wasn't amused: "It is astonishing to me that Java 's insecure parallelism is taken seriously by the programming community, a quarter of a century after the invention of monitors and Concurrent Pascal. It has no merit." > > Still, with a bit of discipline, you can implement a monitor in Java. As long as nobody does "client-side locking" with synchronized (obj) { ... } And sure, if a method does synchronized (this) for a shorter time than the whole method, that's cool too as an optimization. > > But that has not been a mainstream thing for a long time. How many synchronized methods do you find in j.u.c.ConcurrentHashMap? > > Now, admittedly, there are several instances of synchronized (someSeeminglyRandomObject) in the implementation. Also, check out the use of lock objects in Writer/PrintWriter. It's complicated. > > Nothing wrong with an expert using synchronized because it performs better. But that begs the question. Why does it perform better? Objects typed as locks are surely more suitable as locks than any old object. Their performance should be on par with intrinsic locks. > > Cheers, > > Cay > > On 03/06/2024 15.26, robert engels wrote: >> They are one and the same when they lock on the object itself. Synchronized block statements allow the lock duration to be minimized while maintaining the natural code structure (I.e not adding additional methods). >>> On Jun 3, 2024, at 8:24?AM, Cay Horstmann wrote: >>> >>> ?I am not talking about synchronized methods but about block statements (JLS 14.19). >>> >>> synchronized (obj) { >>> >>> } >>> >>>> On 03/06/2024 14.31, robert engels wrote: >>>> Reference for synchronized being a code smell? >>>> Synchronized methods can be much more efficient than locks as the runtime can optimize them away, bias locking, etc. >>>>>> On Jun 3, 2024, at 2:21?AM, Cay Horstmann wrote: >>>>> >>>>> ?On 02/06/2024 13.07, Andrew Haley wrote: >>>>>>> On 6/1/24 17:56, Alex wrote: >>>>>>> Before this fix many projects did fixes and replaced synchronized with Lock. What is the latest recommendation? Keep replacing synchronized with Lock or wait for Java 23 and use synchronized methods? >>>>>> I'd use Lock for the future. Synchronized plays very badly with Value >>>>>> Objects, for example. Being able to synchronize on any object is something >>>>>> of a legacy feature. >>>>> >>>>> At least since Java 5, synchronized(obj) has been a code smell. A class with synchronized methods can be appropriate when carefully designed. (Of course, value classes cannot have synchronized methods.) >>>>> >>>>> -- >>>>> >>>>> Cay S. Horstmann | https://horstmann.com >>> >>> -- >>> >>> -- >>> >>> Cay S. Horstmann | https://horstmann.com > > -- > > -- > > Cay S. Horstmann | https://horstmann.com From ron.pressler at oracle.com Mon Jun 3 23:16:10 2024 From: ron.pressler at oracle.com (Ron Pressler) Date: Mon, 3 Jun 2024 23:16:10 +0000 Subject: Synchronized methods and virtual threads In-Reply-To: References: <35a733db-5b8c-4427-94e9-0c485a66ca18@horstmann.com> <2869D8AF-5CC4-4197-B395-3493030AB625@icloud.com> Message-ID: <1D5D5C2D-8DE2-4403-8735-E85AAA1FAE65@oracle.com> > On 3 Jun 2024, at 21:23, Robert Engels wrote: > > Sure. People used synchronized to create ?lock objects? long before java.util.concurrent - routinely for higher level debugging. > > You have to also remember a bit of history regarding when Java was created and the relative performance of the machines then. Having an intrinsic lock that the JVM could optimize was highly beneficial - especially when there was no optimizing JIT. The reason for native monitors wasn?t performance (they predate the JIT compiler) but what, at the time, was believed to be a natural programming model. It was that early ubiquitous use of synchronized (Vector, Hashtable, StringBuffer, and quite a few old IO methods) that necessitated special optimisation, not the other way around. Over the years, native monitors have caused quite a bit of pain to the VM?s implementors ? to this day ? and the ultimate goal is to replace them with a Java implementation (i.e. effectively redirect their implementation to j.u.c). > There is a LOT of code in the JVM/JDK that uses synchronized? Implementing j.u.c requires compiler/intrinsics/atomics/LockSupport - basically making these objects special anyway. I don?t know of any Java developer that had a problem using synchronized. That being said, if j.u.c can achieve the performance of monitors then the only reason to support it is backward compatibility. Replacing synchronized with j.u.c locks may be unnecessary busy-work, in some cases it?s easier to rely on some native VM functionality in JDK classes because they?re loaded early in the process?s initialisation (JDK classes are sometimes under more severe restrictions than user classes for that reason), and in some cases the synchronization object is public and so part of the API. Changing it could cause binary incompatibilities. But we certainly don?t consider them superior. We would encourage new code to use j.u.c locks (that?s where current and future enhancements would be focused) unless there?s a very good reason not to do that. > > Tbh, I am not a fan of the loosey-goosey release every 6 months change anything in Java the way the wind blows mentality. The only aspects that allowed Java to succeed were backwards compatibility and cross platform (and then the JIT for performance) - my opinion of course. The way backward compatibility works in Java ? and it works very effectively ? is that anything that is part of the specification (or non-SE JDK APIs) enjoys a very high degree of backward compatibility (and removals undergo the deprecation process), while anything that is not explicitly specified must not be relied upon, and is subject to change at any time. That is the only way users can enjoy both backward compatibility and enhancements. In particular, specific optimisations or techniques employed by the JVM can and do change drastically over time. There are macro- and micro-benchmarks that should not regress on average, and performance over a wide range of programs should generally improve over time, but code should absolutely not rely on the JVM optimising things tomorrow the same way it does today. Writing code that deliberately relies on unspecified behaviour, i.e. behaviour that is not now nor has ever been subject to any promise of backward compatibility ? whether it?s a specific optimisation or some functionality ? means accepting the responsibility to maintain and modify that code as the unspecified behaviour changes (just as we strive to do with such code in the JDK). ? Ron From robaho at icloud.com Mon Jun 3 23:27:04 2024 From: robaho at icloud.com (Robert Engels) Date: Mon, 3 Jun 2024 18:27:04 -0500 Subject: Synchronized methods and virtual threads In-Reply-To: <1D5D5C2D-8DE2-4403-8735-E85AAA1FAE65@oracle.com> References: <35a733db-5b8c-4427-94e9-0c485a66ca18@horstmann.com> <2869D8AF-5CC4-4197-B395-3493030AB625@icloud.com> <1D5D5C2D-8DE2-4403-8735-E85AAA1FAE65@oracle.com> Message-ID: <2AD20FF7-2659-48FA-89DF-502164BC7677@icloud.com> I am not sure I agree. I believe they were built into the language for first class concurrency and performance, otherwise they could have been implemented even then as a Semaphore written in Java with additional low-level methods like those in LockSupport, but the interpreted runtime would have made using these Semaphores extremely inefficient. If you are going to have a built in Thread class, you need some sort of mutex to make a Thread usable. See https://link.springer.com/article/10.1007/s11023-023-09632-2 > On Jun 3, 2024, at 6:16 PM, Ron Pressler wrote: > > > >> On 3 Jun 2024, at 21:23, Robert Engels wrote: >> >> Sure. People used synchronized to create ?lock objects? long before java.util.concurrent - routinely for higher level debugging. >> >> You have to also remember a bit of history regarding when Java was created and the relative performance of the machines then. Having an intrinsic lock that the JVM could optimize was highly beneficial - especially when there was no optimizing JIT. > > The reason for native monitors wasn?t performance (they predate the JIT compiler) but what, at the time, was believed to be a natural programming model. It was that early ubiquitous use of synchronized (Vector, Hashtable, StringBuffer, and quite a few old IO methods) that necessitated special optimisation, not the other way around. Over the years, native monitors have caused quite a bit of pain to the VM?s implementors ? to this day ? and the ultimate goal is to replace them with a Java implementation (i.e. effectively redirect their implementation to j.u.c). > >> There is a LOT of code in the JVM/JDK that uses synchronized? Implementing j.u.c requires compiler/intrinsics/atomics/LockSupport - basically making these objects special anyway. I don?t know of any Java developer that had a problem using synchronized. That being said, if j.u.c can achieve the performance of monitors then the only reason to support it is backward compatibility. > > Replacing synchronized with j.u.c locks may be unnecessary busy-work, in some cases it?s easier to rely on some native VM functionality in JDK classes because they?re loaded early in the process?s initialisation (JDK classes are sometimes under more severe restrictions than user classes for that reason), and in some cases the synchronization object is public and so part of the API. Changing it could cause binary incompatibilities. But we certainly don?t consider them superior. We would encourage new code to use j.u.c locks (that?s where current and future enhancements would be focused) unless there?s a very good reason not to do that. > >> >> Tbh, I am not a fan of the loosey-goosey release every 6 months change anything in Java the way the wind blows mentality. The only aspects that allowed Java to succeed were backwards compatibility and cross platform (and then the JIT for performance) - my opinion of course. > > The way backward compatibility works in Java ? and it works very effectively ? is that anything that is part of the specification (or non-SE JDK APIs) enjoys a very high degree of backward compatibility (and removals undergo the deprecation process), while anything that is not explicitly specified must not be relied upon, and is subject to change at any time. That is the only way users can enjoy both backward compatibility and enhancements. In particular, specific optimisations or techniques employed by the JVM can and do change drastically over time. There are macro- and micro-benchmarks that should not regress on average, and performance over a wide range of programs should generally improve over time, but code should absolutely not rely on the JVM optimising things tomorrow the same way it does today. Writing code that deliberately relies on unspecified behaviour, i.e. behaviour that is not now nor has ever been subject to any promise of backward compatibility ? whether it?s a specific optimisation or some functionality ? means accepting the responsibility to maintain and modify that code as the unspecified behaviour changes (just as we strive to do with such code in the JDK). > > ? Ron From aph-open at littlepinkcloud.com Tue Jun 4 08:06:08 2024 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Tue, 4 Jun 2024 09:06:08 +0100 Subject: Synchronized methods and virtual threads In-Reply-To: References: <35a733db-5b8c-4427-94e9-0c485a66ca18@horstmann.com> <2869D8AF-5CC4-4197-B395-3493030AB625@icloud.com> Message-ID: <26186938-71d0-4ee5-8b3f-1cf2d51b04d6@littlepinkcloud.com> On 6/3/24 21:09, Cay Horstmann wrote: > And why make the lock be "this" so it leaks to the public? Per > Brinch Hansen wasn't amused: "It is astonishing to me that Java 's > insecure parallelism is taken seriously by the programming > community, a quarter of a century after the invention of monitors > and Concurrent Pascal. It has no merit." Oh, I'd never seen that comment! Thanks for the reference. > Nothing wrong with an expert using synchronized because it performs > better. But that begs the question. Why does it perform better? > Objects typed as locks are surely more suitable as locks than any > old object. Their performance should be on par with intrinsic locks. It's an interesting question. I think the real answer to that is because java.util.concurrent locks are a pure library feature. The virtual machine doesn't know anything about their properties so can't, for example, do lock coarsening. But in principle, sure, the same optimizations could be done. However, there would always have to be a link from an object to its lock, which is a small overhead. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From oleksandr.otenko at gmail.com Tue Jun 4 08:56:52 2024 From: oleksandr.otenko at gmail.com (Alex Otenko) Date: Tue, 4 Jun 2024 09:56:52 +0100 Subject: Synchronized methods and virtual threads In-Reply-To: <26186938-71d0-4ee5-8b3f-1cf2d51b04d6@littlepinkcloud.com> References: <35a733db-5b8c-4427-94e9-0c485a66ca18@horstmann.com> <2869D8AF-5CC4-4197-B395-3493030AB625@icloud.com> <26186938-71d0-4ee5-8b3f-1cf2d51b04d6@littlepinkcloud.com> Message-ID: I think it is not about performance, but language support of correctness. So to speak, the language provides statements to build programs that are obviously sequentially consistent. (With the caveat that deadlocks probably are evidence of the execution that is not sequentially consistent) On Tue, 4 Jun 2024, 09:06 Andrew Haley, wrote: > On 6/3/24 21:09, Cay Horstmann wrote: > > > And why make the lock be "this" so it leaks to the public? Per > > Brinch Hansen wasn't amused: "It is astonishing to me that Java 's > > insecure parallelism is taken seriously by the programming > > community, a quarter of a century after the invention of monitors > > and Concurrent Pascal. It has no merit." > > Oh, I'd never seen that comment! Thanks for the reference. > > > Nothing wrong with an expert using synchronized because it performs > > better. But that begs the question. Why does it perform better? > > Objects typed as locks are surely more suitable as locks than any > > old object. Their performance should be on par with intrinsic locks. > > It's an interesting question. I think the real answer to that is > because java.util.concurrent locks are a pure library feature. The > virtual machine doesn't know anything about their properties so can't, > for example, do lock coarsening. But in principle, sure, the same > optimizations could be done. However, there would always have to be > a link from an object to its lock, which is a small overhead. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph-open at littlepinkcloud.com Tue Jun 4 09:21:04 2024 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Tue, 4 Jun 2024 10:21:04 +0100 Subject: Synchronized methods and virtual threads In-Reply-To: References: <35a733db-5b8c-4427-94e9-0c485a66ca18@horstmann.com> <2869D8AF-5CC4-4197-B395-3493030AB625@icloud.com> <26186938-71d0-4ee5-8b3f-1cf2d51b04d6@littlepinkcloud.com> Message-ID: <91c0a0cd-7227-40db-93cf-1d029e9d8937@littlepinkcloud.com> On 6/4/24 09:56, Alex Otenko wrote: > I think it is not about performance, but language support of correctness. > > So to speak, the language provides statements to build programs that are obviously sequentially consistent. (With the caveat that deadlocks probably are evidence of the execution that is not sequentially consistent) What are you replying to? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From oleksandr.otenko at gmail.com Tue Jun 4 09:24:08 2024 From: oleksandr.otenko at gmail.com (Alex Otenko) Date: Tue, 4 Jun 2024 10:24:08 +0100 Subject: Synchronized methods and virtual threads In-Reply-To: <91c0a0cd-7227-40db-93cf-1d029e9d8937@littlepinkcloud.com> References: <35a733db-5b8c-4427-94e9-0c485a66ca18@horstmann.com> <2869D8AF-5CC4-4197-B395-3493030AB625@icloud.com> <26186938-71d0-4ee5-8b3f-1cf2d51b04d6@littlepinkcloud.com> <91c0a0cd-7227-40db-93cf-1d029e9d8937@littlepinkcloud.com> Message-ID: Uh....just a general comment on the topic why synchronized was "better". It looked like folks focused on performance and potential optimizations specifically that the VM can or cannot do. On Tue, 4 Jun 2024, 10:21 Andrew Haley, wrote: > On 6/4/24 09:56, Alex Otenko wrote: > > I think it is not about performance, but language support of correctness. > > > > So to speak, the language provides statements to build programs that are > obviously sequentially consistent. (With the caveat that deadlocks probably > are evidence of the execution that is not sequentially consistent) > > What are you replying to? > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at icloud.com Tue Jun 4 11:48:06 2024 From: robaho at icloud.com (robert engels) Date: Tue, 4 Jun 2024 06:48:06 -0500 Subject: Synchronized methods and virtual threads In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From hepin.p at alibaba-inc.com Tue Jun 4 13:29:57 2024 From: hepin.p at alibaba-inc.com (=?UTF-8?B?5L2V5ZOBKOiZjum4oyk=?=) Date: Tue, 04 Jun 2024 21:29:57 +0800 Subject: =?UTF-8?B?VmlydHVhbCB0aHJlYWQgaGFuZyBhbmQgYWxsIHRocmVhZHMgc3RvcCBydW5uaW5nIG9uIEpE?= =?UTF-8?B?SzIx?= Message-ID: Hi, we are using Virtual threads on JDK21.0.2, and find it can stop running, all threads stopped/hung, and we can't even call thread dump. We try to separate the Virtual Thread's scheduler with reflections. but that does not work too. Our userbase are pretty simple: A: VT Executor backing by 128-sized ThreadPoolExecutor for running java code with `CompletableFuture.get` B: VT Executor backing by 64-sized ThreadPoolExecutor for retrieving data with HTTP client, with max concurrency to 3000 (virtual threads) Even if A and B are using Different backing ThreadPool, they all stop responding? ```java public static Executor virtualize(final String prefix, final boolean enabled, final Executor executor) { if (!enabled) { return executor; } try { final var builder = Thread.ofVirtual(); if (executor != null) { final var clazz = builder.getClass(); final var privateLookup = MethodHandles.privateLookupIn(clazz, lookup); final var schedulerFieldSetter = privateLookup.findSetter(clazz, "scheduler", Executor.class); schedulerFieldSetter.invoke(builder, executor); } builder.name(prefix + "-virtual-thread-", 0L); final var factory = builder.factory(); return Executors.newThreadPerTaskExecutor(factory); } catch (Throwable e) { log.error("Error when virtualize a executor", e); return executor; } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From hepin.p at alibaba-inc.com Tue Jun 4 13:32:25 2024 From: hepin.p at alibaba-inc.com (=?UTF-8?B?5L2V5ZOBKOiZjum4oyk=?=) Date: Tue, 04 Jun 2024 21:32:25 +0800 Subject: =?UTF-8?B?5Zue5aSN77yaVmlydHVhbCB0aHJlYWQgaGFuZyBhbmQgYWxsIHRocmVhZHMgc3RvcCBydW5u?= =?UTF-8?B?aW5nIG9uIEpESzIx?= In-Reply-To: References: Message-ID: <70c15f7e-2f02-4ad8-8832-505a2f6d9024.hepin.p@alibaba-inc.com> eg: the code below, seems like the VM is corrupted private static final ThreadPoolExecutor EXECUTOR = new ThreadPoolExecutor( 128, 128, 60, TimeUnit.SECONDS, new LinkedBlockingDeque<>(), new NamedThreadFactory("OrderedTaskRunnerCarrier")); static { EXECUTOR.prestartAllCoreThreads(); } private static final Executor VTExecutor = VirtualThreadSupport.virtualize( "OrderedTaskRunner", false, EXECUTOR); ------------------------------------------------------------------ ??????(??) ?????2024?6?4?(???) 21:29 ????loom-dev ????Virtual thread hang and all threads stop running on JDK21 Hi, we are using Virtual threads on JDK21.0.2, and find it can stop running, all threads stopped/hung, and we can't even call thread dump. We try to separate the Virtual Thread's scheduler with reflections. but that does not work too. Our userbase are pretty simple: A: VT Executor backing by 128-sized ThreadPoolExecutor for running java code with `CompletableFuture.get` B: VT Executor backing by 64-sized ThreadPoolExecutor for retrieving data with HTTP client, with max concurrency to 3000 (virtual threads) Even if A and B are using Different backing ThreadPool, they all stop responding? ```java public static Executor virtualize(final String prefix, final boolean enabled, final Executor executor) { if (!enabled) { return executor; } try { final var builder = Thread.ofVirtual(); if (executor != null) { final var clazz = builder.getClass(); final var privateLookup = MethodHandles.privateLookupIn(clazz, lookup); final var schedulerFieldSetter = privateLookup.findSetter(clazz, "scheduler", Executor.class); schedulerFieldSetter.invoke(builder, executor); } builder.name(prefix + "-virtual-thread-", 0L); final var factory = builder.factory(); return Executors.newThreadPerTaskExecutor(factory); } catch (Throwable e) { log.error("Error when virtualize a executor", e); return executor; } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From rengels at ix.netcom.com Tue Jun 4 13:44:37 2024 From: rengels at ix.netcom.com (robert engels) Date: Tue, 4 Jun 2024 08:44:37 -0500 Subject: Virtual thread hang and all threads stop running on JDK21 In-Reply-To: References: Message-ID: What are you trying to do? I am pretty sure the current scheduler is tied directly to the implementation and if you change it, I am not surprised that things don?t work. The default scheduler creates instances of CarrierThread which has special properties. It is doubtful yours does. > On Jun 4, 2024, at 8:29 AM, ??(??) wrote: > > > Hi, we are using Virtual threads on JDK21.0.2, and find it can stop running, all threads stopped/hung, and we can't even call thread dump. > We try to separate the Virtual Thread's scheduler with reflections. but that does not work too. > > Our userbase are pretty simple: > A: VT Executor backing by 128-sized ThreadPoolExecutor for running java code with `CompletableFuture.get` > B: VT Executor backing by 64-sized ThreadPoolExecutor for retrieving data with HTTP client, with max concurrency to 3000 (virtual threads) > > Even if A and B are using Different backing ThreadPool, they all stop responding? > > > > ```java > public static Executor virtualize(final String prefix, > final boolean enabled, > final Executor executor) { > if (!enabled) { > return executor; > } > try { > final var builder = Thread.ofVirtual(); > if (executor != null) { > final var clazz = builder.getClass(); > final var privateLookup = MethodHandles.privateLookupIn(clazz, lookup); > final var schedulerFieldSetter = privateLookup.findSetter(clazz, "scheduler", Executor.class); > schedulerFieldSetter.invoke(builder, executor); > } > builder.name(prefix + "-virtual-thread-", 0L); > final var factory = builder.factory(); > return Executors.newThreadPerTaskExecutor(factory); > } catch (Throwable e) { > log.error("Error when virtualize a executor", e); > return executor; > } > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Jun 4 13:45:23 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 4 Jun 2024 14:45:23 +0100 Subject: Virtual thread hang and all threads stop running on JDK21 In-Reply-To: References: Message-ID: On 04/06/2024 14:29, ??(??) wrote: > > Hi, we are using Virtual threads on JDK21.0.2, and find it can stop > running, all threads stopped/hung, and we can't even call thread dump. > We try to separate the Virtual Thread's scheduler with reflections. > but that does not work too. > > Our userbase are pretty simple: > A: VT Executor backing by 128-sized ThreadPoolExecutor for running > java code with `CompletableFuture.get` > B: VT Executor backing by 64-sized ThreadPoolExecutor for retrieving > data with HTTP client, with max concurrency to 3000 (virtual threads) > > Even if A and B are using Different backing ThreadPool, they all stop > responding? > There isn't much to go on here. There isn't any support at this time for custom schedulers so I can't tell if the hang is when you use the default scheduler or only when you use reflection to hack in and set your own? Also when you say "thread dump", do you mean the HotSpot VM thread dump (ctrl-\, jstack, jcmd Thread.print) or do you mean the thread dump that prints all virtual threads (jcmd Thread.dump_to_file)? -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rengels at ix.netcom.com Tue Jun 4 14:00:58 2024 From: rengels at ix.netcom.com (robert engels) Date: Tue, 4 Jun 2024 09:00:58 -0500 Subject: Virtual thread hang and all threads stop running on JDK21 In-Reply-To: References: Message-ID: If you look at the Blocker class, if your virtual thread carrier thread is not an instance of CarrierThread, then code like this will not do what is expected: public static long begin() { if (VM.isBooted() && currentCarrierThread() instanceof CarrierThread ct && !ct.inBlocking()) { ct.beginBlocking(); boolean completed = false; try { long comp = ForkJoinPools.beginCompensatedBlock(ct.getPool()); assert currentCarrierThread() == ct; completed = true; return comp; } finally { if (!completed) { ct.endBlocking(); } } } return -1; } I am surprised that anything works at all. You may have success if you make your executor create instances of CarrierThread - which is public. > On Jun 4, 2024, at 8:44 AM, robert engels wrote: > > What are you trying to do? I am pretty sure the current scheduler is tied directly to the implementation and if you change it, I am not surprised that things don?t work. The default scheduler creates instances of CarrierThread which has special properties. It is doubtful yours does. > >> On Jun 4, 2024, at 8:29 AM, ??(??) > wrote: >> >> >> Hi, we are using Virtual threads on JDK21.0.2, and find it can stop running, all threads stopped/hung, and we can't even call thread dump. >> We try to separate the Virtual Thread's scheduler with reflections. but that does not work too. >> >> Our userbase are pretty simple: >> A: VT Executor backing by 128-sized ThreadPoolExecutor for running java code with `CompletableFuture.get` >> B: VT Executor backing by 64-sized ThreadPoolExecutor for retrieving data with HTTP client, with max concurrency to 3000 (virtual threads) >> >> Even if A and B are using Different backing ThreadPool, they all stop responding? >> >> >> >> ```java >> public static Executor virtualize(final String prefix, >> final boolean enabled, >> final Executor executor) { >> if (!enabled) { >> return executor; >> } >> try { >> final var builder = Thread.ofVirtual(); >> if (executor != null) { >> final var clazz = builder.getClass(); >> final var privateLookup = MethodHandles.privateLookupIn(clazz, lookup); >> final var schedulerFieldSetter = privateLookup.findSetter(clazz, "scheduler", Executor.class); >> schedulerFieldSetter.invoke(builder, executor); >> } >> builder.name(prefix + "-virtual-thread-", 0L); >> final var factory = builder.factory(); >> return Executors.newThreadPerTaskExecutor(factory); >> } catch (Throwable e) { >> log.error("Error when virtualize a executor", e); >> return executor; >> } >> } >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rengels at ix.netcom.com Tue Jun 4 14:07:39 2024 From: rengels at ix.netcom.com (robert engels) Date: Tue, 4 Jun 2024 09:07:39 -0500 Subject: Virtual thread hang and all threads stop running on JDK21 In-Reply-To: References: Message-ID: This might cause everything to hang - because if all ?carriers? in the pool end up blocked, no compensation threads will be added, leading to carrier thread starvation. Not saying that is the underlying cause though. What you are doing seems very risky at this point in release cycle of virtual threads. I would return to my original question of what are you trying to accomplish and maybe people can help with a simpler and supported way of doing that. > On Jun 4, 2024, at 9:00 AM, robert engels wrote: > > If you look at the Blocker class, if your virtual thread carrier thread is not an instance of CarrierThread, then code like this will not do what is expected: > > public static long begin() { > if (VM.isBooted() > && currentCarrierThread() instanceof CarrierThread ct && !ct.inBlocking()) { > ct.beginBlocking(); > boolean completed = false; > try { > long comp = ForkJoinPools.beginCompensatedBlock(ct.getPool()); > assert currentCarrierThread() == ct; > completed = true; > return comp; > } finally { > if (!completed) { > ct.endBlocking(); > } > } > } > return -1; > } > > I am surprised that anything works at all. You may have success if you make your executor create instances of CarrierThread - which is public. > > >> On Jun 4, 2024, at 8:44 AM, robert engels > wrote: >> >> What are you trying to do? I am pretty sure the current scheduler is tied directly to the implementation and if you change it, I am not surprised that things don?t work. The default scheduler creates instances of CarrierThread which has special properties. It is doubtful yours does. >> >>> On Jun 4, 2024, at 8:29 AM, ??(??) > wrote: >>> >>> >>> Hi, we are using Virtual threads on JDK21.0.2, and find it can stop running, all threads stopped/hung, and we can't even call thread dump. >>> We try to separate the Virtual Thread's scheduler with reflections. but that does not work too. >>> >>> Our userbase are pretty simple: >>> A: VT Executor backing by 128-sized ThreadPoolExecutor for running java code with `CompletableFuture.get` >>> B: VT Executor backing by 64-sized ThreadPoolExecutor for retrieving data with HTTP client, with max concurrency to 3000 (virtual threads) >>> >>> Even if A and B are using Different backing ThreadPool, they all stop responding? >>> >>> >>> >>> ```java >>> public static Executor virtualize(final String prefix, >>> final boolean enabled, >>> final Executor executor) { >>> if (!enabled) { >>> return executor; >>> } >>> try { >>> final var builder = Thread.ofVirtual(); >>> if (executor != null) { >>> final var clazz = builder.getClass(); >>> final var privateLookup = MethodHandles.privateLookupIn(clazz, lookup); >>> final var schedulerFieldSetter = privateLookup.findSetter(clazz, "scheduler", Executor.class); >>> schedulerFieldSetter.invoke(builder, executor); >>> } >>> builder.name(prefix + "-virtual-thread-", 0L); >>> final var factory = builder.factory(); >>> return Executors.newThreadPerTaskExecutor(factory); >>> } catch (Throwable e) { >>> log.error("Error when virtualize a executor", e); >>> return executor; >>> } >>> } >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imediava at gmail.com Tue Jun 4 20:52:02 2024 From: imediava at gmail.com (=?UTF-8?Q?I=C3=B1igo_Mediavilla?=) Date: Tue, 4 Jun 2024 22:52:02 +0200 Subject: 8330846: (jstack) Add stacks of mounted virtual threads Message-ID: Hello, While there's ongoing work on: https://github.com/openjdk/jdk/pull/19482 to add the stack trace of mounted virtual threads to the `jcmd Thread.print` command, I'm starting to think about how I could do to print the stack trace for virtual threads from `jstack` but I'm not sure about what would be the best approach, so I'd be happy to get people's thoughts on the topic. Based on what I've seen `jstack` seems to fetch a ThreadList of JavaThreads and then relies on a bunch of Java code that uses attribute offsets to get the values of certain attributes of the JavaThread in the VM. With those attributes the java code can obtain the data that it requires about the threads, their monitors and also to get the latest frame in the stack to be able to iterate the stack. If I were to follow the same principle, I'd have to replicate the code that was added to the VM to read the stack chunks of virtual threads in Java, knowing that it looks like that the JVM code had to be written for multiple CPU architectures, I'm a bit concern about how complex following that approach would be. I considered following the approach used by `ThreadDumper.java`, that relies on `ThreadContainers` to get the virtual threads and then iterates over `Thread.getStackTrace` for the virtual thread. But I don't think that would work because I don't think the `ThreadContainers` can be accessed from `Jstack`. So I'm basically a bit blocked, and I think that I'd need some help from people that have followed loom more closely and have a clearer view of things and can probably provide me with hints on how to approach the problem differently. Thanks in advance for your help. Best ??igo Mediavilla Saiz -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at icloud.com Tue Jun 4 21:16:41 2024 From: robaho at icloud.com (Robert Engels) Date: Tue, 4 Jun 2024 16:16:41 -0500 Subject: 8330846: (jstack) Add stacks of mounted virtual threads In-Reply-To: References: Message-ID: I looked through this, and I don?t think the there is anything needed other than this PR. Eventually jstack creates a VM_PrintThreads command which calls the threads.cpp code. > On Jun 4, 2024, at 3:52 PM, I?igo Mediavilla wrote: > > Hello, > > While there's ongoing work on: > > https://github.com/openjdk/jdk/pull/19482 > > to add the stack trace of mounted virtual threads to the `jcmd Thread.print` command, I'm starting to think about how I could do to print the stack trace for virtual threads from `jstack` but I'm not sure about what would be the best approach, so I'd be happy to get people's thoughts on the topic. > > Based on what I've seen `jstack` seems to fetch a ThreadList of JavaThreads and then relies on a bunch of Java code that uses attribute offsets to get the values of certain attributes of the JavaThread in the VM. With those attributes the java code can obtain the data that it requires about the threads, their monitors and also to get the latest frame in the stack to be able to iterate the stack. If I were to follow the same principle, I'd have to replicate the code that was added to the VM to read the stack chunks of virtual threads in Java, knowing that it looks like that the JVM code had to be written for multiple CPU architectures, I'm a bit concern about how complex following that approach would be. > > I considered following the approach used by `ThreadDumper.java`, that relies on `ThreadContainers` to get the virtual threads and then iterates over `Thread.getStackTrace` for the virtual thread. But I don't think that would work because I don't think the `ThreadContainers` can be accessed from `Jstack`. > > So I'm basically a bit blocked, and I think that I'd need some help from people that have followed loom more closely and have a clearer view of things and can probably provide me with hints on how to approach the problem differently. > > Thanks in advance for your help. > > Best > > ??igo Mediavilla Saiz > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Tue Jun 4 23:22:43 2024 From: cushon at google.com (Liam Miller-Cushon) Date: Tue, 4 Jun 2024 16:22:43 -0700 Subject: Performance of pooling virtual threads vs. semaphores In-Reply-To: References: Message-ID: Hi, Thanks for the comments. There's more to dig into here and to respond to, but I have a few notes for now. re: whether the question is about making this code faster or why case (2) scales weirdly, it's sort of both--we're interested in understanding (2) better, but if (2) is expected to be expensive compared to pushing back, that's helpful. To provide some more color on the real-world program that inspired the question, it's the Bazel build system (https://github.com/google/bazel). Bazel constructs a graph of build 'actions', where each node is a command to run during the build (for example a call to javac that takes some source files and classpath jars as inputs, and produces class file outputs). The current approach uses a pool of physical threads to execute actions. Actions can block on IO, and especially on RPCs to remote machines that are performing build steps. The goal is to use virtual threads to make the actions async, and to replace the limit on the number of concurrent actions with a dynamic limit based on the availability of other resources (memory, and the number of in-flight RPCs to remote build machines). As a first step, Chi was trying to get a baseline where the virtual thread-based implementation used the same concurrency limit as the previous approach, ideally with roughly the same CPU overhead. I have more benchmarking results from the original machine using one of the approaches that was suggested, of limiting the number of in-flight virtual threads using a ThreadFactory with a semaphore. The new strategy (4) uses less CPU than strategy (2) where all of the virtual threads are started at the same time, but still uses more CPU than the thread pooling approach in (3). With strategy 4 as: ``` case 4 -> { var factorySem = new Semaphore(parallelism); ThreadFactory tf = (Runnable r) -> { try { factorySem.acquire(); } catch (InterruptedException ex) { throw new IllegalStateException("interrupted"); } return Thread.ofVirtual().unstarted(() -> { try { r.run(); } finally { factorySem.release(); } }); }; executor = Executors.newThreadPerTaskExecutor(tf); ``` The results are: # 128 CPUs Benchmark 1: java Main -- 1 10000 Time (mean ? ?): 719.7 ms ? 45.9 ms [User: 23732.3 ms, System: 1155.3 ms] Range (min ? max): 651.1 ms ? 794.0 ms 10 runs Benchmark 2: java Main -- 2 10000 Time (mean ? ?): 635.8 ms ? 66.9 ms [User: 21271.1 ms, System: 1685.1 ms] Range (min ? max): 565.5 ms ? 769.6 ms 10 runs Benchmark 3: java Main -- 3 10000 Time (mean ? ?): 486.2 ms ? 9.3 ms [User: 10804.0 ms, System: 1181.6 ms] Range (min ? max): 464.5 ms ? 495.1 ms 10 runs Benchmark 4: java Main -- 4 10000 Time (mean ? ?): 479.9 ms ? 3.7 ms [User: 8366.7 ms, System: 1201.9 ms] Range (min ? max): 474.8 ms ? 488.0 ms 10 runs Summary java Main -- 4 10000 ran 1.01 ? 0.02 times faster than java Main -- 3 10000 1.32 ? 0.14 times faster than java Main -- 2 10000 1.50 ? 0.10 times faster than java Main -- 1 10000 Benchmark 1: java Main -- 1 100000 Time (mean ? ?): 3.803 s ? 0.044 s [User: 41.227 s, System: 2.418 s] Range (min ? max): 3.737 s ? 3.874 s 10 runs Benchmark 2: java Main -- 2 100000 Time (mean ? ?): 3.761 s ? 0.063 s [User: 53.494 s, System: 3.380 s] Range (min ? max): 3.651 s ? 3.848 s 10 runs Benchmark 3: java Main -- 3 100000 Time (mean ? ?): 3.555 s ? 0.040 s [User: 20.824 s, System: 2.350 s] Range (min ? max): 3.529 s ? 3.667 s 10 runs Benchmark 4: java Main -- 4 100000 Time (mean ? ?): 3.558 s ? 0.011 s [User: 28.272 s, System: 3.018 s] Range (min ? max): 3.544 s ? 3.581 s 10 runs Summary java Main -- 3 100000 ran 1.00 ? 0.01 times faster than java Main -- 4 100000 1.06 ? 0.02 times faster than java Main -- 2 100000 1.07 ? 0.02 times faster than java Main -- 1 100000 Benchmark 1: java Main -- 1 1000000 Time (mean ? ?): 34.182 s ? 0.020 s [User: 165.208 s, System: 15.016 s] Range (min ? max): 34.148 s ? 34.205 s 10 runs Benchmark 2: java Main -- 2 1000000 Time (mean ? ?): 34.917 s ? 0.270 s [User: 335.774 s, System: 23.993 s] Range (min ? max): 34.575 s ? 35.457 s 10 runs Benchmark 3: java Main -- 3 1000000 Time (mean ? ?): 36.146 s ? 3.468 s [User: 163.926 s, System: 10.816 s] Range (min ? max): 34.209 s ? 45.588 s 10 runs Benchmark 4: java Main -- 4 1000000 Time (mean ? ?): 34.390 s ? 0.051 s [User: 216.980 s, System: 22.147 s] Range (min ? max): 34.303 s ? 34.446 s 10 runs Summary java Main -- 1 1000000 ran 1.01 ? 0.00 times faster than java Main -- 4 1000000 1.02 ? 0.01 times faster than java Main -- 2 1000000 1.06 ? 0.10 times faster than java Main -- 3 1000000 # 16 CPUs Benchmark 1: java Main -- 1 10000 Time (mean ? ?): 825.6 ms ? 50.6 ms [User: 6863.7 ms, System: 779.8 ms] Range (min ? max): 745.2 ms ? 936.4 ms 10 runs Benchmark 2: java Main -- 2 10000 Time (mean ? ?): 515.7 ms ? 8.4 ms [User: 4591.8 ms, System: 274.2 ms] Range (min ? max): 502.7 ms ? 532.9 ms 10 runs Benchmark 3: java Main -- 3 10000 Time (mean ? ?): 494.8 ms ? 34.9 ms [User: 3751.9 ms, System: 190.6 ms] Range (min ? max): 463.3 ms ? 580.0 ms 10 runs Benchmark 4: java Main -- 4 10000 Time (mean ? ?): 473.2 ms ? 7.5 ms [User: 3851.2 ms, System: 248.5 ms] Range (min ? max): 464.1 ms ? 483.3 ms 10 runs Summary java Main -- 4 10000 ran 1.05 ? 0.08 times faster than java Main -- 3 10000 1.09 ? 0.02 times faster than java Main -- 2 10000 1.74 ? 0.11 times faster than java Main -- 1 10000 Benchmark 1: java Main -- 1 100000 Time (mean ? ?): 3.949 s ? 0.099 s [User: 32.922 s, System: 2.386 s] Range (min ? max): 3.882 s ? 4.222 s 10 runs Benchmark 2: java Main -- 2 100000 Time (mean ? ?): 3.739 s ? 0.063 s [User: 31.259 s, System: 2.117 s] Range (min ? max): 3.661 s ? 3.832 s 10 runs Benchmark 3: java Main -- 3 100000 Time (mean ? ?): 5.106 s ? 0.990 s [User: 20.897 s, System: 0.686 s] Range (min ? max): 3.955 s ? 7.679 s 10 runs Benchmark 4: java Main -- 4 100000 Time (mean ? ?): 3.570 s ? 0.013 s [User: 27.292 s, System: 1.807 s] Range (min ? max): 3.557 s ? 3.594 s 10 runs Summary java Main -- 4 100000 ran 1.05 ? 0.02 times faster than java Main -- 2 100000 1.11 ? 0.03 times faster than java Main -- 1 100000 1.43 ? 0.28 times faster than java Main -- 3 100000 Benchmark 1: java Main -- 1 1000000 Time (mean ? ?): 34.536 s ? 0.076 s [User: 263.045 s, System: 16.227 s] Range (min ? max): 34.457 s ? 34.717 s 10 runs Benchmark 2: java Main -- 2 1000000 Time (mean ? ?): 35.257 s ? 0.191 s [User: 285.159 s, System: 19.702 s] Range (min ? max): 35.015 s ? 35.561 s 10 runs Benchmark 3: java Main -- 3 1000000 Time (mean ? ?): 60.157 s ? 10.130 s [User: 171.901 s, System: 3.902 s] Range (min ? max): 46.437 s ? 74.799 s 10 runs Benchmark 4: java Main -- 4 1000000 Time (mean ? ?): 34.370 s ? 0.067 s [User: 256.460 s, System: 19.605 s] Range (min ? max): 34.299 s ? 34.455 s 10 runs Summary java Main -- 4 1000000 ran 1.00 ? 0.00 times faster than java Main -- 1 1000000 1.03 ? 0.01 times faster than java Main -- 2 1000000 1.75 ? 0.29 times faster than java Main -- 3 1000000 On Thu, May 30, 2024 at 11:22?AM Ron Pressler wrote: > > > > On 28 May 2024, at 23:43, Liam Miller-Cushon wrote: > > > > Hello, > > > > JEP 444 [1] and the docs in [2] mention that virtual threads should not > be pooled, and suggest semaphores as one possible alternative. > > > > My colleague Chi Wang has been investigating virtual thread performance, > and has found that creating one virtual thread per task and synchronizing > on a semaphore can result in worse performance on machines with large > numbers of cores. > > > > A benchmark run on a 128 core machine is included below. It submits > numTasks tasks to the executor determined by the strategy. The task itself > is mixed with CPU and I/O work (simulated by fibonacci and sleep). The > parallelism is set to 600 for all strategies. > > > > * Strategy 1 is the baseline where it just submits all the tasks to a > ForkJoinPool whose pool size is 600. > > * Strategy 2 uses the method suggested by JEP 444. > > * Strategy 3 uses a fixed thread pool of 600 backed by virtual threads. > > > > Note that, with 100K and 1M tasks, strategy 2 has a CPU time regression > that seems to increase with the number of cores. This result can be > reproduced on the real-world program that is being migrated to a > virtual-thread-per-task model. > > > > Diffing the cpu profile between strategy 1 and strategy 2 showed that > most of the CPU regression comes from method > `java.util.concurrent.ForkJoinPool.scan(java.util.concurrent.ForkJoinPool$WorkQueue, > long, int)`. > > > > Are there any ideas for why the semaphore strategy uses more CPU than > pooling virtual threads on machines with a large number of cores? > > My first guess would be that what?s being compared here is not the same > algorithm. In strategy 2, you spawn a bunch of different threads that do a > tiny bit of work before starting the task, while in the other strategies > the algorithm is different. > > In a realistic workload you will have a number of threads serving > requests, and then they may want to access a concurrency-limited resource. > I think you can try to simulate that by simulating, say, 1000 tasks running > in some large thread pool and then each of them would submit one subtasks > to a fixed thread pool of size 10. For virtual threads, have 1000 virtual > threads that try to acquire a semaphore with 10 leases. > > Can you try that? At least then we?ll be comparing oranges to oranges. > > ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at icloud.com Tue Jun 4 23:34:57 2024 From: robaho at icloud.com (Robert Engels) Date: Tue, 4 Jun 2024 18:34:57 -0500 Subject: Performance of pooling virtual threads vs. semaphores In-Reply-To: References: Message-ID: <18EB247B-8B78-4F45-B9C0-4785E2E3F775@icloud.com> I know I sent a bunch of replies, but did you by chance run the tests using the VirtualThreadExecutorService that doesn?t have the semaphore? But, more importantly, as I also pointed out, something seems way off in the timings. I don?t think the 128 core machine is actually 128 available cores - the timings are way too high. With this test you should get a nearly linear increase in performance as the number of carrier threads increase. The tests here aren?t even close. I am guessing these are virtual cores backed by their own scheduler on a shared VM. With virtual threads the number of carrier threads needs to match the real available cores or you will waste CPU with thrashing of the scheduler. > On Jun 4, 2024, at 6:22 PM, Liam Miller-Cushon wrote: > > Hi, > > Thanks for the comments. There's more to dig into here and to respond to, but I have a few notes for now. > > re: whether the question is about making this code faster or why case (2) scales weirdly, it's sort of both--we're interested in understanding (2) better, but if (2) is expected to be expensive compared to pushing back, that's helpful. > > To provide some more color on the real-world program that inspired the question, it's the Bazel build system (https://github.com/google/bazel ). Bazel constructs a graph of build 'actions', where each node is a command to run during the build (for example a call to javac that takes some source files and classpath jars as inputs, and produces class file outputs). The current approach uses a pool of physical threads to execute actions. Actions can block on IO, and especially on RPCs to remote machines that are performing build steps. The goal is to use virtual threads to make the actions async, and to replace the limit on the number of concurrent actions with a dynamic limit based on the availability of other resources (memory, and the number of in-flight RPCs to remote build machines). As a first step, Chi was trying to get a baseline where the virtual thread-based implementation used the same concurrency limit as the previous approach, ideally with roughly the same CPU overhead. > > I have more benchmarking results from the original machine using one of the approaches that was suggested, of limiting the number of in-flight virtual threads using a ThreadFactory with a semaphore. The new strategy (4) uses less CPU than strategy (2) where all of the virtual threads are started at the same time, but still uses more CPU than the thread pooling approach in (3). > > With strategy 4 as: > > ``` > case 4 -> { > var factorySem = new Semaphore(parallelism); > ThreadFactory tf = (Runnable r) -> { > try { > factorySem.acquire(); > } catch (InterruptedException ex) { > throw new IllegalStateException("interrupted"); > } > return Thread.ofVirtual().unstarted(() -> > { > try { > r.run(); > } finally { > factorySem.release(); > } > }); > }; > executor = Executors.newThreadPerTaskExecutor(tf); > ``` > > The results are: > > # 128 CPUs > > Benchmark 1: java Main -- 1 10000 > Time (mean ? ?): 719.7 ms ? 45.9 ms [User: 23732.3 ms, System: 1155.3 ms] > Range (min ? max): 651.1 ms ? 794.0 ms 10 runs > > Benchmark 2: java Main -- 2 10000 > Time (mean ? ?): 635.8 ms ? 66.9 ms [User: 21271.1 ms, System: 1685.1 ms] > Range (min ? max): 565.5 ms ? 769.6 ms 10 runs > > Benchmark 3: java Main -- 3 10000 > Time (mean ? ?): 486.2 ms ? 9.3 ms [User: 10804.0 ms, System: 1181.6 ms] > Range (min ? max): 464.5 ms ? 495.1 ms 10 runs > > Benchmark 4: java Main -- 4 10000 > Time (mean ? ?): 479.9 ms ? 3.7 ms [User: 8366.7 ms, System: 1201.9 ms] > Range (min ? max): 474.8 ms ? 488.0 ms 10 runs > > Summary > java Main -- 4 10000 ran > 1.01 ? 0.02 times faster than java Main -- 3 10000 > 1.32 ? 0.14 times faster than java Main -- 2 10000 > 1.50 ? 0.10 times faster than java Main -- 1 10000 > > Benchmark 1: java Main -- 1 100000 > Time (mean ? ?): 3.803 s ? 0.044 s [User: 41.227 s, System: 2.418 s] > Range (min ? max): 3.737 s ? 3.874 s 10 runs > > Benchmark 2: java Main -- 2 100000 > Time (mean ? ?): 3.761 s ? 0.063 s [User: 53.494 s, System: 3.380 s] > Range (min ? max): 3.651 s ? 3.848 s 10 runs > > Benchmark 3: java Main -- 3 100000 > Time (mean ? ?): 3.555 s ? 0.040 s [User: 20.824 s, System: 2.350 s] > Range (min ? max): 3.529 s ? 3.667 s 10 runs > > Benchmark 4: java Main -- 4 100000 > Time (mean ? ?): 3.558 s ? 0.011 s [User: 28.272 s, System: 3.018 s] > Range (min ? max): 3.544 s ? 3.581 s 10 runs > > Summary > java Main -- 3 100000 ran > 1.00 ? 0.01 times faster than java Main -- 4 100000 > 1.06 ? 0.02 times faster than java Main -- 2 100000 > 1.07 ? 0.02 times faster than java Main -- 1 100000 > > Benchmark 1: java Main -- 1 1000000 > Time (mean ? ?): 34.182 s ? 0.020 s [User: 165.208 s, System: 15.016 s] > Range (min ? max): 34.148 s ? 34.205 s 10 runs > > Benchmark 2: java Main -- 2 1000000 > Time (mean ? ?): 34.917 s ? 0.270 s [User: 335.774 s, System: 23.993 s] > Range (min ? max): 34.575 s ? 35.457 s 10 runs > > Benchmark 3: java Main -- 3 1000000 > Time (mean ? ?): 36.146 s ? 3.468 s [User: 163.926 s, System: 10.816 s] > Range (min ? max): 34.209 s ? 45.588 s 10 runs > > Benchmark 4: java Main -- 4 1000000 > Time (mean ? ?): 34.390 s ? 0.051 s [User: 216.980 s, System: 22.147 s] > Range (min ? max): 34.303 s ? 34.446 s 10 runs > > Summary > java Main -- 1 1000000 ran > 1.01 ? 0.00 times faster than java Main -- 4 1000000 > 1.02 ? 0.01 times faster than java Main -- 2 1000000 > 1.06 ? 0.10 times faster than java Main -- 3 1000000 > > > # 16 CPUs > > Benchmark 1: java Main -- 1 10000 > Time (mean ? ?): 825.6 ms ? 50.6 ms [User: 6863.7 ms, System: 779.8 ms] > Range (min ? max): 745.2 ms ? 936.4 ms 10 runs > > Benchmark 2: java Main -- 2 10000 > Time (mean ? ?): 515.7 ms ? 8.4 ms [User: 4591.8 ms, System: 274.2 ms] > Range (min ? max): 502.7 ms ? 532.9 ms 10 runs > > Benchmark 3: java Main -- 3 10000 > Time (mean ? ?): 494.8 ms ? 34.9 ms [User: 3751.9 ms, System: 190.6 ms] > Range (min ? max): 463.3 ms ? 580.0 ms 10 runs > > Benchmark 4: java Main -- 4 10000 > Time (mean ? ?): 473.2 ms ? 7.5 ms [User: 3851.2 ms, System: 248.5 ms] > Range (min ? max): 464.1 ms ? 483.3 ms 10 runs > > Summary > > java Main -- 4 10000 ran > 1.05 ? 0.08 times faster than java Main -- 3 10000 > 1.09 ? 0.02 times faster than java Main -- 2 10000 > 1.74 ? 0.11 times faster than java Main -- 1 10000 > > Benchmark 1: java Main -- 1 100000 > Time (mean ? ?): 3.949 s ? 0.099 s [User: 32.922 s, System: 2.386 s] > Range (min ? max): 3.882 s ? 4.222 s 10 runs > > Benchmark 2: java Main -- 2 100000 > Time (mean ? ?): 3.739 s ? 0.063 s [User: 31.259 s, System: 2.117 s] > Range (min ? max): 3.661 s ? 3.832 s 10 runs > > Benchmark 3: java Main -- 3 100000 > Time (mean ? ?): 5.106 s ? 0.990 s [User: 20.897 s, System: 0.686 s] > Range (min ? max): 3.955 s ? 7.679 s 10 runs > > Benchmark 4: java Main -- 4 100000 > Time (mean ? ?): 3.570 s ? 0.013 s [User: 27.292 s, System: 1.807 s] > Range (min ? max): 3.557 s ? 3.594 s 10 runs > > Summary > > java Main -- 4 100000 ran > 1.05 ? 0.02 times faster than java Main -- 2 100000 > 1.11 ? 0.03 times faster than java Main -- 1 100000 > 1.43 ? 0.28 times faster than java Main -- 3 100000 > > Benchmark 1: java Main -- 1 1000000 > Time (mean ? ?): 34.536 s ? 0.076 s [User: 263.045 s, System: 16.227 s] > Range (min ? max): 34.457 s ? 34.717 s 10 runs > > Benchmark 2: java Main -- 2 1000000 > Time (mean ? ?): 35.257 s ? 0.191 s [User: 285.159 s, System: 19.702 s] > Range (min ? max): 35.015 s ? 35.561 s 10 runs > > Benchmark 3: java Main -- 3 1000000 > Time (mean ? ?): 60.157 s ? 10.130 s [User: 171.901 s, System: 3.902 s] > Range (min ? max): 46.437 s ? 74.799 s 10 runs > > Benchmark 4: java Main -- 4 1000000 > Time (mean ? ?): 34.370 s ? 0.067 s [User: 256.460 s, System: 19.605 s] > Range (min ? max): 34.299 s ? 34.455 s 10 runs > > Summary > java Main -- 4 1000000 ran > 1.00 ? 0.00 times faster than java Main -- 1 1000000 > 1.03 ? 0.01 times faster than java Main -- 2 1000000 > 1.75 ? 0.29 times faster than java Main -- 3 1000000 > > On Thu, May 30, 2024 at 11:22?AM Ron Pressler > wrote: > > > > On 28 May 2024, at 23:43, Liam Miller-Cushon > wrote: > > > > Hello, > > > > JEP 444 [1] and the docs in [2] mention that virtual threads should not be pooled, and suggest semaphores as one possible alternative. > > > > My colleague Chi Wang has been investigating virtual thread performance, and has found that creating one virtual thread per task and synchronizing on a semaphore can result in worse performance on machines with large numbers of cores. > > > > A benchmark run on a 128 core machine is included below. It submits numTasks tasks to the executor determined by the strategy. The task itself is mixed with CPU and I/O work (simulated by fibonacci and sleep). The parallelism is set to 600 for all strategies. > > > > * Strategy 1 is the baseline where it just submits all the tasks to a ForkJoinPool whose pool size is 600. > > * Strategy 2 uses the method suggested by JEP 444. > > * Strategy 3 uses a fixed thread pool of 600 backed by virtual threads. > > > > Note that, with 100K and 1M tasks, strategy 2 has a CPU time regression that seems to increase with the number of cores. This result can be reproduced on the real-world program that is being migrated to a virtual-thread-per-task model. > > > > Diffing the cpu profile between strategy 1 and strategy 2 showed that most of the CPU regression comes from method `java.util.concurrent.ForkJoinPool.scan(java.util.concurrent.ForkJoinPool$WorkQueue, long, int)`. > > > > Are there any ideas for why the semaphore strategy uses more CPU than pooling virtual threads on machines with a large number of cores? > > My first guess would be that what?s being compared here is not the same algorithm. In strategy 2, you spawn a bunch of different threads that do a tiny bit of work before starting the task, while in the other strategies the algorithm is different. > > In a realistic workload you will have a number of threads serving requests, and then they may want to access a concurrency-limited resource. I think you can try to simulate that by simulating, say, 1000 tasks running in some large thread pool and then each of them would submit one subtasks to a fixed thread pool of size 10. For virtual threads, have 1000 virtual threads that try to acquire a semaphore with 10 leases. > > Can you try that? At least then we?ll be comparing oranges to oranges. > > ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Wed Jun 5 00:16:32 2024 From: cushon at google.com (Liam Miller-Cushon) Date: Tue, 4 Jun 2024 17:16:32 -0700 Subject: Performance of pooling virtual threads vs. semaphores In-Reply-To: <18EB247B-8B78-4F45-B9C0-4785E2E3F775@icloud.com> References: <18EB247B-8B78-4F45-B9C0-4785E2E3F775@icloud.com> Message-ID: Yes, I think the Ryzen 3995WX has 64 real cores, 128 was with hyperthreading enabled. I don't have numbers from it yet (it isn't my machine), I'll get numbers with hyperthreading disabled and with your VirtualThreadExecutorService approach from [1] and report back. [1] https://mail.openjdk.org/pipermail/loom-dev/2024-May/006627.html On Tue, Jun 4, 2024 at 4:35?PM Robert Engels wrote: > I know I sent a bunch of replies, but did you by chance run the tests > using the VirtualThreadExecutorService that doesn?t have the semaphore? > > But, more importantly, as I also pointed out, something seems way off in > the timings. I don?t think the 128 core machine is actually 128 available > cores - the timings are way too high. With this test you should get a > nearly linear increase in performance as the number of carrier threads > increase. The tests here aren?t even close. I am guessing these are virtual > cores backed by their own scheduler on a shared VM. > > With virtual threads the number of carrier threads needs to match the real > available cores or you will waste CPU with thrashing of the scheduler. > > > On Jun 4, 2024, at 6:22 PM, Liam Miller-Cushon wrote: > > Hi, > > Thanks for the comments. There's more to dig into here and to respond to, > but I have a few notes for now. > > re: whether the question is about making this code faster or why case (2) > scales weirdly, it's sort of both--we're interested in understanding (2) > better, but if (2) is expected to be expensive compared to pushing back, > that's helpful. > > To provide some more color on the real-world program that inspired the > question, it's the Bazel build system (https://github.com/google/bazel). > Bazel constructs a graph of build 'actions', where each node is a command > to run during the build (for example a call to javac that takes some source > files and classpath jars as inputs, and produces class file outputs). The > current approach uses a pool of physical threads to execute actions. > Actions can block on IO, and especially on RPCs to remote machines that are > performing build steps. The goal is to use virtual threads to make the > actions async, and to replace the limit on the number of concurrent actions > with a dynamic limit based on the availability of other resources (memory, > and the number of in-flight RPCs to remote build machines). As a first > step, Chi was trying to get a baseline where the virtual thread-based > implementation used the same concurrency limit as the previous approach, > ideally with roughly the same CPU overhead. > > I have more benchmarking results from the original machine using one of > the approaches that was suggested, of limiting the number of in-flight > virtual threads using a ThreadFactory with a semaphore. The new strategy > (4) uses less CPU than strategy (2) where all of the virtual threads are > started at the same time, but still uses more CPU than the thread pooling > approach in (3). > > With strategy 4 as: > > ``` > case 4 -> { > var factorySem = new Semaphore(parallelism); > ThreadFactory tf = (Runnable r) -> { > try { > factorySem.acquire(); > } catch (InterruptedException ex) { > throw new IllegalStateException("interrupted"); > } > return Thread.ofVirtual().unstarted(() -> > { > try { > r.run(); > } finally { > factorySem.release(); > } > }); > }; > executor = Executors.newThreadPerTaskExecutor(tf); > ``` > > The results are: > > # 128 CPUs > > Benchmark 1: java Main -- 1 10000 > Time (mean ? ?): 719.7 ms ? 45.9 ms [User: 23732.3 ms, System: > 1155.3 ms] > Range (min ? max): 651.1 ms ? 794.0 ms 10 runs > > Benchmark 2: java Main -- 2 10000 > Time (mean ? ?): 635.8 ms ? 66.9 ms [User: 21271.1 ms, System: > 1685.1 ms] > Range (min ? max): 565.5 ms ? 769.6 ms 10 runs > > Benchmark 3: java Main -- 3 10000 > Time (mean ? ?): 486.2 ms ? 9.3 ms [User: 10804.0 ms, System: > 1181.6 ms] > Range (min ? max): 464.5 ms ? 495.1 ms 10 runs > > Benchmark 4: java Main -- 4 10000 > Time (mean ? ?): 479.9 ms ? 3.7 ms [User: 8366.7 ms, System: > 1201.9 ms] > Range (min ? max): 474.8 ms ? 488.0 ms 10 runs > > Summary > java Main -- 4 10000 ran > 1.01 ? 0.02 times faster than java Main -- 3 10000 > 1.32 ? 0.14 times faster than java Main -- 2 10000 > 1.50 ? 0.10 times faster than java Main -- 1 10000 > > Benchmark 1: java Main -- 1 100000 > Time (mean ? ?): 3.803 s ? 0.044 s [User: 41.227 s, System: > 2.418 s] > Range (min ? max): 3.737 s ? 3.874 s 10 runs > > Benchmark 2: java Main -- 2 100000 > Time (mean ? ?): 3.761 s ? 0.063 s [User: 53.494 s, System: > 3.380 s] > Range (min ? max): 3.651 s ? 3.848 s 10 runs > > Benchmark 3: java Main -- 3 100000 > Time (mean ? ?): 3.555 s ? 0.040 s [User: 20.824 s, System: > 2.350 s] > Range (min ? max): 3.529 s ? 3.667 s 10 runs > > Benchmark 4: java Main -- 4 100000 > Time (mean ? ?): 3.558 s ? 0.011 s [User: 28.272 s, System: > 3.018 s] > Range (min ? max): 3.544 s ? 3.581 s 10 runs > > Summary > java Main -- 3 100000 ran > 1.00 ? 0.01 times faster than java Main -- 4 100000 > 1.06 ? 0.02 times faster than java Main -- 2 100000 > 1.07 ? 0.02 times faster than java Main -- 1 100000 > > Benchmark 1: java Main -- 1 1000000 > Time (mean ? ?): 34.182 s ? 0.020 s [User: 165.208 s, System: > 15.016 s] > Range (min ? max): 34.148 s ? 34.205 s 10 runs > > Benchmark 2: java Main -- 2 1000000 > Time (mean ? ?): 34.917 s ? 0.270 s [User: 335.774 s, System: > 23.993 s] > Range (min ? max): 34.575 s ? 35.457 s 10 runs > > Benchmark 3: java Main -- 3 1000000 > Time (mean ? ?): 36.146 s ? 3.468 s [User: 163.926 s, System: > 10.816 s] > Range (min ? max): 34.209 s ? 45.588 s 10 runs > > Benchmark 4: java Main -- 4 1000000 > Time (mean ? ?): 34.390 s ? 0.051 s [User: 216.980 s, System: > 22.147 s] > Range (min ? max): 34.303 s ? 34.446 s 10 runs > > Summary > java Main -- 1 1000000 ran > 1.01 ? 0.00 times faster than java Main -- 4 1000000 > 1.02 ? 0.01 times faster than java Main -- 2 1000000 > 1.06 ? 0.10 times faster than java Main -- 3 1000000 > > > # 16 CPUs > > Benchmark 1: java Main -- 1 10000 > Time (mean ? ?): 825.6 ms ? 50.6 ms [User: 6863.7 ms, System: > 779.8 ms] > Range (min ? max): 745.2 ms ? 936.4 ms 10 runs > > Benchmark 2: java Main -- 2 10000 > Time (mean ? ?): 515.7 ms ? 8.4 ms [User: 4591.8 ms, System: > 274.2 ms] > Range (min ? max): 502.7 ms ? 532.9 ms 10 runs > > Benchmark 3: java Main -- 3 10000 > Time (mean ? ?): 494.8 ms ? 34.9 ms [User: 3751.9 ms, System: > 190.6 ms] > Range (min ? max): 463.3 ms ? 580.0 ms 10 runs > > Benchmark 4: java Main -- 4 10000 > Time (mean ? ?): 473.2 ms ? 7.5 ms [User: 3851.2 ms, System: > 248.5 ms] > Range (min ? max): 464.1 ms ? 483.3 ms 10 runs > > Summary > > java Main -- 4 10000 ran > 1.05 ? 0.08 times faster than java Main -- 3 10000 > 1.09 ? 0.02 times faster than java Main -- 2 10000 > 1.74 ? 0.11 times faster than java Main -- 1 10000 > > Benchmark 1: java Main -- 1 100000 > Time (mean ? ?): 3.949 s ? 0.099 s [User: 32.922 s, System: > 2.386 s] > Range (min ? max): 3.882 s ? 4.222 s 10 runs > > Benchmark 2: java Main -- 2 100000 > Time (mean ? ?): 3.739 s ? 0.063 s [User: 31.259 s, System: > 2.117 s] > Range (min ? max): 3.661 s ? 3.832 s 10 runs > > Benchmark 3: java Main -- 3 100000 > Time (mean ? ?): 5.106 s ? 0.990 s [User: 20.897 s, System: > 0.686 s] > Range (min ? max): 3.955 s ? 7.679 s 10 runs > > Benchmark 4: java Main -- 4 100000 > Time (mean ? ?): 3.570 s ? 0.013 s [User: 27.292 s, System: > 1.807 s] > Range (min ? max): 3.557 s ? 3.594 s 10 runs > > Summary > > java Main -- 4 100000 ran > 1.05 ? 0.02 times faster than java Main -- 2 100000 > 1.11 ? 0.03 times faster than java Main -- 1 100000 > 1.43 ? 0.28 times faster than java Main -- 3 100000 > > Benchmark 1: java Main -- 1 1000000 > Time (mean ? ?): 34.536 s ? 0.076 s [User: 263.045 s, System: > 16.227 s] > Range (min ? max): 34.457 s ? 34.717 s 10 runs > > Benchmark 2: java Main -- 2 1000000 > Time (mean ? ?): 35.257 s ? 0.191 s [User: 285.159 s, System: > 19.702 s] > Range (min ? max): 35.015 s ? 35.561 s 10 runs > > Benchmark 3: java Main -- 3 1000000 > Time (mean ? ?): 60.157 s ? 10.130 s [User: 171.901 s, System: > 3.902 s] > Range (min ? max): 46.437 s ? 74.799 s 10 runs > > Benchmark 4: java Main -- 4 1000000 > Time (mean ? ?): 34.370 s ? 0.067 s [User: 256.460 s, System: > 19.605 s] > Range (min ? max): 34.299 s ? 34.455 s 10 runs > > Summary > java Main -- 4 1000000 ran > 1.00 ? 0.00 times faster than java Main -- 1 1000000 > 1.03 ? 0.01 times faster than java Main -- 2 1000000 > 1.75 ? 0.29 times faster than java Main -- 3 1000000 > > On Thu, May 30, 2024 at 11:22?AM Ron Pressler > wrote: > >> >> >> > On 28 May 2024, at 23:43, Liam Miller-Cushon wrote: >> > >> > Hello, >> > >> > JEP 444 [1] and the docs in [2] mention that virtual threads should not >> be pooled, and suggest semaphores as one possible alternative. >> > >> > My colleague Chi Wang has been investigating virtual thread >> performance, and has found that creating one virtual thread per task and >> synchronizing on a semaphore can result in worse performance on machines >> with large numbers of cores. >> > >> > A benchmark run on a 128 core machine is included below. It submits >> numTasks tasks to the executor determined by the strategy. The task itself >> is mixed with CPU and I/O work (simulated by fibonacci and sleep). The >> parallelism is set to 600 for all strategies. >> > >> > * Strategy 1 is the baseline where it just submits all the tasks to a >> ForkJoinPool whose pool size is 600. >> > * Strategy 2 uses the method suggested by JEP 444. >> > * Strategy 3 uses a fixed thread pool of 600 backed by virtual threads. >> > >> > Note that, with 100K and 1M tasks, strategy 2 has a CPU time regression >> that seems to increase with the number of cores. This result can be >> reproduced on the real-world program that is being migrated to a >> virtual-thread-per-task model. >> > >> > Diffing the cpu profile between strategy 1 and strategy 2 showed that >> most of the CPU regression comes from method >> `java.util.concurrent.ForkJoinPool.scan(java.util.concurrent.ForkJoinPool$WorkQueue, >> long, int)`. >> > >> > Are there any ideas for why the semaphore strategy uses more CPU than >> pooling virtual threads on machines with a large number of cores? >> >> My first guess would be that what?s being compared here is not the same >> algorithm. In strategy 2, you spawn a bunch of different threads that do a >> tiny bit of work before starting the task, while in the other strategies >> the algorithm is different. >> >> In a realistic workload you will have a number of threads serving >> requests, and then they may want to access a concurrency-limited resource. >> I think you can try to simulate that by simulating, say, 1000 tasks running >> in some large thread pool and then each of them would submit one subtasks >> to a fixed thread pool of size 10. For virtual threads, have 1000 virtual >> threads that try to acquire a semaphore with 10 leases. >> >> Can you try that? At least then we?ll be comparing oranges to oranges. >> >> ? Ron > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed Jun 5 04:52:29 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 5 Jun 2024 05:52:29 +0100 Subject: 8330846: (jstack) Add stacks of mounted virtual threads In-Reply-To: References: Message-ID: <67efe07c-e0fe-42be-b94b-6e92da02a419@oracle.com> On 04/06/2024 21:52, I?igo Mediavilla wrote: > Hello, > > While there's ongoing work on: > > https://github.com/openjdk/jdk/pull/19482 > > to add the stack trace of mounted virtual threads to the `jcmd > Thread.print` command, I'm starting to think about how I could do to > print the stack trace for virtual threads from `jstack` but I'm not > sure about what would be the best approach, so I'd be happy to get > people's thoughts on the topic. JDK-8330846 is about showing the stack traces of mounted virtual threads, I don't think pull/19482 should be expanded to do anything else. For the PR then I think you are just waiting for Thomas Stuefe's change with support for automatic indentation and of course converging on some details of the output. If you are asking if it should include the stack traces of unmounted virtual threads then we decided some time ago to not do that. The Thread.print commands runs as a VM operation so the at a safepoint. Adding more work to that, to walk the heap to find virtual thread objects, would just increase the STW time. The other issue is that the output (text format) doesn't scale to hundreds of thousands of threads. You might ask about de-duplication but that is just adding more overhead to the thread dump and may be better left to tools that process the thread dump. These are issues/reasons for Thread.dump_to_file. It uses the tree of thread groupings to find all threads. -Alan From imediava at gmail.com Wed Jun 5 06:45:13 2024 From: imediava at gmail.com (=?UTF-8?Q?I=C3=B1igo_Mediavilla?=) Date: Wed, 5 Jun 2024 08:45:13 +0200 Subject: 8330846: (jstack) Add stacks of mounted virtual threads In-Reply-To: <67efe07c-e0fe-42be-b94b-6e92da02a419@oracle.com> References: <67efe07c-e0fe-42be-b94b-6e92da02a419@oracle.com> Message-ID: Thanks, Alan. Sorry, I wasn't clear in my message. I wasn't thinking about including unmounted threads in the output of `Thread.print`, I agree with you that besides the formatting things that still need to be fixed there's no need to add more changes to the `Thread.print` command in the context of 8330846. My doubts were related to the fact that 8330846 also refers to including the stack of mounted threads in the output of `jstack` and I'm not sure about what's the best way to implement that. In my previous message, I explained some approaches that I looked into to have mounted virtual threads in `jstack` but I'm not sure about them. ??igo On Wed, Jun 5, 2024 at 6:52?AM Alan Bateman wrote: > On 04/06/2024 21:52, I?igo Mediavilla wrote: > > Hello, > > > > While there's ongoing work on: > > > > https://github.com/openjdk/jdk/pull/19482 > > > > to add the stack trace of mounted virtual threads to the `jcmd > > Thread.print` command, I'm starting to think about how I could do to > > print the stack trace for virtual threads from `jstack` but I'm not > > sure about what would be the best approach, so I'd be happy to get > > people's thoughts on the topic. > > JDK-8330846 is about showing the stack traces of mounted virtual > threads, I don't think pull/19482 should be expanded to do anything > else. For the PR then I think you are just waiting for Thomas Stuefe's > change with support for automatic indentation and of course converging > on some details of the output. > > If you are asking if it should include the stack traces of unmounted > virtual threads then we decided some time ago to not do that. The > Thread.print commands runs as a VM operation so the at a safepoint. > Adding more work to that, to walk the heap to find virtual thread > objects, would just increase the STW time. The other issue is that the > output (text format) doesn't scale to hundreds of thousands of threads. > You might ask about de-duplication but that is just adding more overhead > to the thread dump and may be better left to tools that process the > thread dump. These are issues/reasons for Thread.dump_to_file. It uses > the tree of thread groupings to find all threads. > > -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed Jun 5 06:50:28 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 5 Jun 2024 07:50:28 +0100 Subject: 8330846: (jstack) Add stacks of mounted virtual threads In-Reply-To: References: <67efe07c-e0fe-42be-b94b-6e92da02a419@oracle.com> Message-ID: <3a474064-f46a-4f7f-8f95-7b0d8139f3e7@oracle.com> On 05/06/2024 07:45, I?igo Mediavilla wrote: > Thanks, Alan. Sorry, I wasn't clear in my message. I wasn't thinking > about including unmounted threads in the output of `Thread.print`, I > agree with you that besides the formatting things that still need to > be fixed there's no need to add more changes to the `Thread.print` > command in the context of 8330846. > > My doubts were related to the fact that 8330846 also refers to > including the stack of mounted threads in the output of `jstack` and > I'm not sure about what's the best way to implement that. In my > previous message, I explained some approaches that I looked into to > have mounted virtual threads in `jstack` but I'm not sure about them. jstack is the equivalent of jcmd Thread.print so I don't think there is anything to do. -Alan From hepin.p at alibaba-inc.com Wed Jun 5 09:37:50 2024 From: hepin.p at alibaba-inc.com (=?UTF-8?B?5L2V5ZOBKOiZjum4oyk=?=) Date: Wed, 05 Jun 2024 17:37:50 +0800 Subject: =?UTF-8?B?5Zue5aSN77yaVmlydHVhbCB0aHJlYWQgaGFuZyBhbmQgYWxsIHRocmVhZHMgc3RvcCBydW5u?= =?UTF-8?B?aW5nIG9uIEpESzIx?= In-Reply-To: References: Message-ID: Thanks, 1. it hung when we are sharing the common usage of the Virtualthread (the default scheduler) cross two modules. 2. after that, I try to hack the virtual thread builder with separated ThreadPoolExecutor. 3. but still , it hung. when it hung, `jcmd Thread.print` prints nothing. and dump programly print nothing too. After switch back to normal thread, it never hang. Some information: module A is using `Object.notifyAll, Object.wait` and module B is using `CompletableFuture.get` (may > 100 times in one rune) I was thinking if that could be a problem of notification missing, where in Module A, the concurrency is 3000? protected by a semaphore, but the underling Carrier Thread is only 128, and 3000 > 128. public void init() { // ???? VTExecutor.execute(() -> { for (; ; ) { try { Thread.sleep(IDLE_SLEEP_TIME); } catch (InterruptedException e) { // ignore } log.info( "BlockableVirtualThreadExecutor completed tasks:[{}] inflight tasks:[{}] semaphore available permits: [{}]", completedTaskCounter.get(), inflightTaskCounter.get(), semaphore.availablePermits()); } }); } When it hung, this code will never prints any more. public static void jstack(OutputStream stream) throws Exception { ThreadMXBean threadMXBean = ManagementFactory.getThreadMXBean(); long[] allThreadIds = threadMXBean.getAllThreadIds(); ThreadInfo[] threadInfos = threadMXBean.getThreadInfo(allThreadIds, true, true); for (ThreadInfo threadInfo : threadInfos) { if (threadInfo != null) { stream.write(printThreadInfoDepth(threadInfo, 1000).getBytes()); } } } ------------------------------------------------------------------ ????Alan Bateman ?????2024?6?4?(???) 21:45 ????"??(??)"; "loom-dev" ????Re: Virtual thread hang and all threads stop running on JDK21 On 04/06/2024 14:29, ??(??) wrote: Hi, we are using Virtual threads on JDK21.0.2, and find it can stop running, all threads stopped/hung, and we can't even call thread dump. We try to separate the Virtual Thread's scheduler with reflections. but that does not work too. Our userbase are pretty simple: A: VT Executor backing by 128-sized ThreadPoolExecutor for running java code with `CompletableFuture.get` B: VT Executor backing by 64-sized ThreadPoolExecutor for retrieving data with HTTP client, with max concurrency to 3000 (virtual threads) Even if A and B are using Different backing ThreadPool, they all stop responding? There isn't much to go on here. There isn't any support at this time for custom schedulers so I can't tell if the hang is when you use the default scheduler or only when you use reflection to hack in and set your own? Also when you say "thread dump", do you mean the HotSpot VM thread dump (ctrl-\, jstack, jcmd Thread.print) or do you mean the thread dump that prints all virtual threads (jcmd Thread.dump_to_file)? -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From hepin.p at alibaba-inc.com Wed Jun 5 09:47:59 2024 From: hepin.p at alibaba-inc.com (=?UTF-8?B?5L2V5ZOBKOiZjum4oyk=?=) Date: Wed, 05 Jun 2024 17:47:59 +0800 Subject: =?UTF-8?B?5Zue5aSN77yaVmlydHVhbCB0aHJlYWQgaGFuZyBhbmQgYWxsIHRocmVhZHMgc3RvcCBydW5u?= =?UTF-8?B?aW5nIG9uIEpESzIx?= In-Reply-To: References: Message-ID: <31ed4a10-643e-486d-b878-4b4c172eacf7.hepin.p@alibaba-inc.com> > I am surprised that anything works at all. You may have success if you make your executor create instances of CarrierThread - which is public. Thanks, but the `CarrierThread` needs a ForkJoinPool, but I'm using TheadPoolExecutor, have to adapt that. ------------------------------------------------------------------ ??????(??) ?????2024?6?5?(???) 17:37 ????Alan Bateman; "??(??)"; "loom-dev" ???????Virtual thread hang and all threads stop running on JDK21 Thanks, 1. it hung when we are sharing the common usage of the Virtualthread (the default scheduler) cross two modules. 2. after that, I try to hack the virtual thread builder with separated ThreadPoolExecutor. 3. but still , it hung. when it hung, `jcmd Thread.print` prints nothing. and dump programly print nothing too. After switch back to normal thread, it never hang. Some information: module A is using `Object.notifyAll, Object.wait` and module B is using `CompletableFuture.get` (may > 100 times in one rune) I was thinking if that could be a problem of notification missing, where in Module A, the concurrency is 3000? protected by a semaphore, but the underling Carrier Thread is only 128, and 3000 > 128. public void init() { // ???? VTExecutor.execute(() -> { for (; ; ) { try { Thread.sleep(IDLE_SLEEP_TIME); } catch (InterruptedException e) { // ignore } log.info( "BlockableVirtualThreadExecutor completed tasks:[{}] inflight tasks:[{}] semaphore available permits: [{}]", completedTaskCounter.get(), inflightTaskCounter.get(), semaphore.availablePermits()); } }); } When it hung, this code will never prints any more. public static void jstack(OutputStream stream) throws Exception { ThreadMXBean threadMXBean = ManagementFactory.getThreadMXBean(); long[] allThreadIds = threadMXBean.getAllThreadIds(); ThreadInfo[] threadInfos = threadMXBean.getThreadInfo(allThreadIds, true, true); for (ThreadInfo threadInfo : threadInfos) { if (threadInfo != null) { stream.write(printThreadInfoDepth(threadInfo, 1000).getBytes()); } } } ------------------------------------------------------------------ ????Alan Bateman ?????2024?6?4?(???) 21:45 ????"??(??)"; "loom-dev" ????Re: Virtual thread hang and all threads stop running on JDK21 On 04/06/2024 14:29, ??(??) wrote: Hi, we are using Virtual threads on JDK21.0.2, and find it can stop running, all threads stopped/hung, and we can't even call thread dump. We try to separate the Virtual Thread's scheduler with reflections. but that does not work too. Our userbase are pretty simple: A: VT Executor backing by 128-sized ThreadPoolExecutor for running java code with `CompletableFuture.get` B: VT Executor backing by 64-sized ThreadPoolExecutor for retrieving data with HTTP client, with max concurrency to 3000 (virtual threads) Even if A and B are using Different backing ThreadPool, they all stop responding? There isn't much to go on here. There isn't any support at this time for custom schedulers so I can't tell if the hang is when you use the default scheduler or only when you use reflection to hack in and set your own? Also when you say "thread dump", do you mean the HotSpot VM thread dump (ctrl-\, jstack, jcmd Thread.print) or do you mean the thread dump that prints all virtual threads (jcmd Thread.dump_to_file)? -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From hepin.p at alibaba-inc.com Wed Jun 5 09:54:17 2024 From: hepin.p at alibaba-inc.com (=?UTF-8?B?5L2V5ZOBKOiZjum4oyk=?=) Date: Wed, 05 Jun 2024 17:54:17 +0800 Subject: =?UTF-8?B?5Zue5aSN77yaVmlydHVhbCB0aHJlYWQgaGFuZyBhbmQgYWxsIHRocmVhZHMgc3RvcCBydW5u?= =?UTF-8?B?aW5nIG9uIEpESzIx?= In-Reply-To: References: Message-ID: <2396c334-80a9-4188-8c78-56954a9f076a.hepin.p@alibaba-inc.com> > What you are doing seems very risky at this point in release cycle of virtual threads. I would return to my original question of what are you trying to accomplish and maybe people can help with a simpler and supported way of doing that. What I want to do: Using virtual thread to make code simpler, otherwise I have to make use of `Future.reduce/traverse` thing, and make code faster (blocking HTTP client)/ What's unexpected, when it hang, the JVM makes no progress , jcmd no responding too. ------------------------------------------------------------------ ????robert engels ?????2024?6?4?(???) 22:07 ????"??(??)" ????"loom-dev" ????Re: Virtual thread hang and all threads stop running on JDK21 This might cause everything to hang - because if all ?carriers? in the pool end up blocked, no compensation threads will be added, leading to carrier thread starvation. Not saying that is the underlying cause though. What you are doing seems very risky at this point in release cycle of virtual threads. I would return to my original question of what are you trying to accomplish and maybe people can help with a simpler and supported way of doing that. On Jun 4, 2024, at 9:00 AM, robert engels > wrote: If you look at the Blocker class, if your virtual thread carrier thread is not an instance of CarrierThread, then code like this will not do what is expected: public static long begin() { if (VM.isBooted() && currentCarrierThread() instanceof CarrierThread ct && !ct.inBlocking()) { ct.beginBlocking(); boolean completed = false; try { long comp = ForkJoinPools.beginCompensatedBlock(ct.getPool()); assert currentCarrierThread() == ct; completed = true; return comp; } finally { if (!completed) { ct.endBlocking(); } } } return -1; } I am surprised that anything works at all. You may have success if you make your executor create instances of CarrierThread - which is public. On Jun 4, 2024, at 8:44 AM, robert engels > wrote: What are you trying to do? I am pretty sure the current scheduler is tied directly to the implementation and if you change it, I am not surprised that things don?t work. The default scheduler creates instances of CarrierThread which has special properties. It is doubtful yours does. On Jun 4, 2024, at 8:29 AM, ??(??) > wrote: Hi, we are using Virtual threads on JDK21.0.2, and find it can stop running, all threads stopped/hung, and we can't even call thread dump. We try to separate the Virtual Thread's scheduler with reflections. but that does not work too. Our userbase are pretty simple: A: VT Executor backing by 128-sized ThreadPoolExecutor for running java code with `CompletableFuture.get` B: VT Executor backing by 64-sized ThreadPoolExecutor for retrieving data with HTTP client, with max concurrency to 3000 (virtual threads) Even if A and B are using Different backing ThreadPool, they all stop responding? ```java public static Executor virtualize(final String prefix, final boolean enabled, final Executor executor) { if (!enabled) { return executor; } try { final var builder = Thread.ofVirtual(); if (executor != null) { final var clazz = builder.getClass(); final var privateLookup = MethodHandles.privateLookupIn(clazz, lookup); final var schedulerFieldSetter = privateLookup.findSetter(clazz, "scheduler", Executor.class); schedulerFieldSetter.invoke(builder, executor); } builder.name(prefix + "-virtual-thread-", 0L); final var factory = builder.factory(); return Executors.newThreadPerTaskExecutor(factory); } catch (Throwable e) { log.error("Error when virtualize a executor", e); return executor; } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed Jun 5 10:00:07 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 5 Jun 2024 11:00:07 +0100 Subject: =?UTF-8?B?UmU6IOWbnuWkje+8mlZpcnR1YWwgdGhyZWFkIGhhbmcgYW5kIGFsbCB0?= =?UTF-8?Q?hreads_stop_running_on_JDK21?= In-Reply-To: References: Message-ID: <77f87b07-a270-4ce6-b503-017c3254cc15@oracle.com> On 05/06/2024 10:37, ??(??) wrote: > Thanks, > 1. it hung when we are sharing the common usage of the Virtualthread > (the default scheduler) cross two modules. > 2. after that, I try to hack the virtual thread builder with separated > ThreadPoolExecutor. > 3. but still , it hung. > > when it hung, `jcmd Thread.print` prints nothing. and dump programly > print nothing too. > > After switch back to normal thread, it never hang. > Some information: > module A is using `Object.notifyAll, Object.wait` and module B is > using `CompletableFuture.get` (may > 100 times in one rune) > I was thinking if that could be a problem of notification missing, > where in Module A, the concurrency is 3000? protected by a semaphore, > but the underling Carrier Thread is only 128, and 3000 > 128. If it's using synchronized/Object.wait then this may be related to pinning. When there is both object monitors and j.u.concurrent locks in play then it's possible to create deadlock scenarios due to starvation, or selecting a successor or thread to wakeup and the thread can't continue because there are no carriers available. Object.wait will temporarily increase parallelism to smooth and help some cases but it may not help you here, and does nothing when the scheduler has been changed to be something other than a ForkJoinPool instance. When you say "prints nothing" then you mean this literally or do you mean that jcmd is hung too? If so that's a hint that may be the lock for standard output is held by a virtual thread that can't continue because there are no carriers available. It would be interesting to try the latest Loom EA builds which has changes to the object monitor implementation that doesn't pin. Would you have time to try these builds out? -Alan [1] https://jdk.java.net/loom/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Wed Jun 5 10:04:35 2024 From: duke at openjdk.org (duke) Date: Wed, 5 Jun 2024 10:04:35 GMT Subject: git: openjdk/loom: fibers: 52 new changesets Message-ID: <2fd5a1c9-b8be-427e-8276-fe8d6c3f14be@openjdk.org> Changeset: c0ce7d87 Author: John Jiang Date: 2024-06-01 05:58:00 +0000 URL: https://git.openjdk.org/loom/commit/c0ce7d871f09df6bf4a21be3579f3f39a49a77bd 8333046: Clean codes in sun.security.util.math Reviewed-by: weijun ! src/java.base/share/classes/sun/security/util/math/IntegerMontgomeryFieldModuloP.java ! src/java.base/share/classes/sun/security/util/math/intpoly/IntegerPolynomial.java ! src/java.base/share/classes/sun/security/util/math/intpoly/MontgomeryIntegerPolynomialP256.java ! test/jdk/com/sun/security/ec/ECOperationsKATTest.java ! test/jdk/com/sun/security/util/math/intpoly/IntegerPolynomialTest.java ! test/jdk/com/sun/security/util/math/intpoly/MontgomeryPolynomialFuzzTest.java Changeset: d29d5bfb Author: Thomas Stuefe Date: 2024-06-01 08:19:07 +0000 URL: https://git.openjdk.org/loom/commit/d29d5bfb7fae35cb9f025c5a20e551a1391e38aa 8333290: NMT report should not print Metaspace info if Metaspace is not yet initialized Reviewed-by: stefank, dholmes ! src/hotspot/share/memory/metaspace/runningCounters.cpp ! src/hotspot/share/nmt/memReporter.cpp Changeset: 51b2f806 Author: SendaoYan Committer: Serguei Spitsyn Date: 2024-06-01 11:31:19 +0000 URL: https://git.openjdk.org/loom/commit/51b2f80627adc1ca9f8335c3c028109a7018a8be 8332923: ObjectMonitorUsage.java failed with unexpected waiter_count Co-authored-by: Jiawei Tang Reviewed-by: sspitsyn, alanb, amitkumar ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! src/hotspot/share/runtime/threads.cpp Changeset: 24530022 Author: Alexey Semenyuk Date: 2024-06-01 12:31:25 +0000 URL: https://git.openjdk.org/loom/commit/24530022d066763f7573f5c6d2030a30dc55afa6 8331977: Crash: SIGSEGV in dlerror() Reviewed-by: almatvee ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/HelloApp.java ! test/jdk/tools/jpackage/macosx/ArgumentsFilteringTest.java ! test/jdk/tools/jpackage/share/ArgumentsTest.java ! test/jdk/tools/jpackage/share/jdk/jpackage/tests/MainClassTest.java ! test/jdk/tools/jpackage/windows/WinRenameTest.java Changeset: 4785461f Author: Jaikiran Pai Date: 2024-06-02 01:07:27 +0000 URL: https://git.openjdk.org/loom/commit/4785461f61d8f5c7444d2e6fd90f1e083dbc6fe4 7022325: TEST_BUG: test/java/util/zip/ZipFile/ReadLongZipFileName.java leaks files if it fails Reviewed-by: lancea ! test/jdk/java/util/zip/ZipFile/ReadLongZipFileName.java Changeset: 8338946a Author: David Holmes Date: 2024-06-02 20:08:17 +0000 URL: https://git.openjdk.org/loom/commit/8338946a6d765eab9cd7a6cbc24c865a9cd355e7 8332935: Crash: assert(*lastPtr != 0) failed: Mismatched JNINativeInterface tables, check for new entries Reviewed-by: dcubed, stuefe ! src/hotspot/share/prims/jniCheck.cpp Changeset: 769b3e48 Author: Claes Redestad Date: 2024-06-02 20:29:03 +0000 URL: https://git.openjdk.org/loom/commit/769b3e48ea97a13756cf096ae235d7434c0cae34 8333182: Add truncated tracing mode for TraceBytecodes Reviewed-by: dholmes, fparain, coleenp ! src/hotspot/share/interpreter/bytecodeTracer.cpp ! src/hotspot/share/runtime/globals.hpp Changeset: cfe91ed3 Author: Gui Cao Committer: Fei Yang Date: 2024-06-03 01:44:16 +0000 URL: https://git.openjdk.org/loom/commit/cfe91ed39c9a0c8e8b16e142ee8cf3a90a6c69c3 8333276: RISC-V: client VM build failure after JDK-8241503 Reviewed-by: fyang ! src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp ! src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.hpp Changeset: a4c7be86 Author: Gui Cao Committer: Fei Yang Date: 2024-06-03 01:48:10 +0000 URL: https://git.openjdk.org/loom/commit/a4c7be862cc6dc121efb6c1c283236a588259c8f 8333006: RISC-V: C2: Support vector-scalar and vector-immediate arithmetic instructions Reviewed-by: fyang, fjiang ! src/hotspot/cpu/riscv/riscv.ad ! src/hotspot/cpu/riscv/riscv_v.ad Changeset: 75220da2 Author: Gui Cao Committer: Fei Yang Date: 2024-06-03 04:42:44 +0000 URL: https://git.openjdk.org/loom/commit/75220da26f647c6f3dabc05cea81cefaf3a1e195 8333154: RISC-V: Add support for primitive array C1 clone intrinsic Reviewed-by: fyang ! src/hotspot/cpu/riscv/c1_LIRAssembler_arraycopy_riscv.cpp ! src/hotspot/cpu/riscv/c1_LIRAssembler_riscv.cpp ! src/hotspot/cpu/riscv/c1_LIRGenerator_riscv.cpp ! src/hotspot/cpu/riscv/c1_MacroAssembler_riscv.cpp ! src/hotspot/cpu/riscv/c1_MacroAssembler_riscv.hpp ! src/hotspot/share/c1/c1_Compiler.cpp ! src/hotspot/share/c1/c1_LIR.cpp Changeset: 7c83d7ab Author: Christian Hagedorn Date: 2024-06-03 06:41:33 +0000 URL: https://git.openjdk.org/loom/commit/7c83d7ab53f1f761a88a1d248b9a2f14980ef702 8333366: C2: CmpU3Nodes are not pushed back to worklist in PhaseCCP leading to non-fixpoint assertion failure Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/phaseX.cpp + test/hotspot/jtreg/compiler/ccp/TestPushCmpU3Node.java Changeset: d2d78ad1 Author: Alexander Zvegintsev Date: 2024-06-03 07:12:06 +0000 URL: https://git.openjdk.org/loom/commit/d2d78ad18e0b5d2a6a62f9c97ceec5592fa1de2e 8280990: [XWayland] XTest emulated mouse click does not bring window to front Reviewed-by: avu, psadhukhan, kizune ! test/jdk/java/awt/Modal/ToFront/FrameToFrontModelessTest.java ! test/jdk/java/awt/Modal/helpers/TestDialog.java ! test/jdk/java/awt/Modal/helpers/TestFrame.java Changeset: e0ac8249 Author: Roberto Casta?eda Lozano Date: 2024-06-03 07:37:17 +0000 URL: https://git.openjdk.org/loom/commit/e0ac8249f54222cc5efe49d5ed1068fed3073ba0 8332959: C2: ZGC fails with 'Incorrect load shift' when invoking Object.clone() reflectively on an array Co-authored-by: Axel Boldt-Christmas Reviewed-by: kvn, thartmann, aboldtch ! src/hotspot/share/opto/library_call.cpp ! test/hotspot/jtreg/compiler/arraycopy/TestObjectArrayClone.java Changeset: 91101f0d Author: SendaoYan Committer: Aleksey Shipilev Date: 2024-06-03 08:12:22 +0000 URL: https://git.openjdk.org/loom/commit/91101f0d4fc8e06d0d74e06361db6ac87efeeb8e 8333353: Delete extra empty line in CodeBlob.java Reviewed-by: cjplummer, lmesnik ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeBlob.java Changeset: 5ed0d52c Author: Thomas Schatzl Date: 2024-06-03 09:25:37 +0000 URL: https://git.openjdk.org/loom/commit/5ed0d52c8424dd2e7f1ac2404e9fabb40c8402b8 8332936: Test vmTestbase/metaspace/gc/watermark_70_80/TestDescription.java fails with no GC's recorded Reviewed-by: stefank, ayang ! test/hotspot/jtreg/vmTestbase/metaspace/gc/watermark_0_1/TestDescription.java ! test/hotspot/jtreg/vmTestbase/metaspace/gc/watermark_10_20/TestDescription.java ! test/hotspot/jtreg/vmTestbase/metaspace/gc/watermark_70_80/TestDescription.java ! test/hotspot/jtreg/vmTestbase/metaspace/gc/watermark_99_100/TestDescription.java Changeset: b1015862 Author: Thomas Stuefe Date: 2024-06-03 09:26:50 +0000 URL: https://git.openjdk.org/loom/commit/b10158624bd0cfe009f0fe7f2a06ee08e654766b 8332514: Allow class space size to be larger than 3GB Reviewed-by: iklam, dholmes ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/runtime/globals.hpp ! test/hotspot/jtreg/runtime/CompressedOops/CompressedClassSpaceSize.java Changeset: f0bffbce Author: Magnus Ihse Bursie Date: 2024-06-03 10:03:42 +0000 URL: https://git.openjdk.org/loom/commit/f0bffbce35bb06e724857e8651dd429c4f9df284 8333301: Remove static builds using --enable-static-build Reviewed-by: sgehwolf, erikj - make/BuildStatic.gmk ! make/Main.gmk ! make/autoconf/flags-cflags.m4 ! make/autoconf/jdk-options.m4 ! make/autoconf/jvm-features.m4 ! make/autoconf/spec.gmk.template ! make/autoconf/toolchain.m4 ! make/common/JdkNativeCompilation.gmk ! make/common/NativeCompilation.gmk ! make/common/modules/LauncherCommon.gmk ! make/common/native/Link.gmk ! make/hotspot/lib/JvmFeatures.gmk ! make/modules/java.base/Lib.gmk ! make/modules/jdk.jdwp.agent/Lib.gmk Changeset: d07e530d Author: SendaoYan Committer: Julian Waters Date: 2024-06-03 12:07:11 +0000 URL: https://git.openjdk.org/loom/commit/d07e530d33360dae687552a6dfbe26408f3fb58e 8333128: Linux x86_32 configure fail with --with-hsdis=binutils --with-binutils-src Reviewed-by: shade, jwaters, ihse ! make/autoconf/lib-hsdis.m4 Changeset: 1c514b34 Author: Prasanta Sadhukhan Date: 2024-06-03 13:00:23 +0000 URL: https://git.openjdk.org/loom/commit/1c514b34c0260823e70f209996ac933a76ac34c2 8325435: [macos] Menu or JPopupMenu not closed when main window is resized Reviewed-by: azvegint ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m + test/jdk/javax/swing/JMenu/TestUngrab.java Changeset: 27af19d9 Author: John Engebretson Committer: Aleksey Shipilev Date: 2024-06-03 13:38:48 +0000 URL: https://git.openjdk.org/loom/commit/27af19d921a5cf15f5146471b58961815690b4f2 8332586: Avoid cloning empty arrays in java.lang.reflect.{Method,Constructor} Reviewed-by: shade, rriggs, liach ! src/java.base/share/classes/java/lang/reflect/Constructor.java ! src/java.base/share/classes/java/lang/reflect/Method.java + test/micro/org/openjdk/bench/java/lang/reflect/ConstructorBenchmark.java + test/micro/org/openjdk/bench/java/lang/reflect/MethodBenchmark.java Changeset: 1f9e6290 Author: Christian Hagedorn Date: 2024-06-03 14:03:34 +0000 URL: https://git.openjdk.org/loom/commit/1f9e62904c624b12bd344d2ef3021eb5d3377197 8333434: IGV: Print loop node for PHASE_BEFORE/AFTER_CLOOPS Reviewed-by: thartmann, rcastanedalo ! src/hotspot/share/opto/loopnode.cpp Changeset: 4de62073 Author: Albert Mingkun Yang Date: 2024-06-03 15:40:47 +0000 URL: https://git.openjdk.org/loom/commit/4de620732f03c71fec3e1c233947742d334c88ad 8333229: Parallel: Rename ParMarkBitMap::_region_start to _heap_start Reviewed-by: tschatzl ! src/hotspot/share/gc/parallel/parMarkBitMap.cpp ! src/hotspot/share/gc/parallel/parMarkBitMap.hpp ! src/hotspot/share/gc/parallel/parMarkBitMap.inline.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.hpp Changeset: 9686e804 Author: Naoto Sato Date: 2024-06-03 15:52:21 +0000 URL: https://git.openjdk.org/loom/commit/9686e804a2b058955ff88149c54a0a7896c0a2eb 8333103: Re-examine the console provider loading Reviewed-by: redestad, jpai ! src/java.base/share/classes/java/io/Console.java Changeset: 6dac8d64 Author: Justin Lu Date: 2024-06-03 22:00:31 +0000 URL: https://git.openjdk.org/loom/commit/6dac8d64527b4e9ade783b99f82fbecd81c426a6 8332424: Update IANA Language Subtag Registry to Version 2024-05-16 Reviewed-by: naoto, iris ! src/java.base/share/data/lsrdata/language-subtag-registry.txt ! test/jdk/java/util/Locale/LanguageSubtagRegistryTest.java Changeset: 1512011e Author: Sonia Zaldana Calles Committer: David Holmes Date: 2024-06-04 01:33:59 +0000 URL: https://git.openjdk.org/loom/commit/1512011eaf24e056974d2d1485152ab3c8960743 8332123: [nmt] Move mallocLimit code to the nmt subdir Reviewed-by: dholmes, stuefe = src/hotspot/share/nmt/mallocLimit.cpp = src/hotspot/share/nmt/mallocLimit.hpp ! src/hotspot/share/nmt/mallocTracker.cpp ! src/hotspot/share/nmt/mallocTracker.inline.hpp ! src/hotspot/share/nmt/memTracker.cpp ! test/hotspot/gtest/nmt/test_nmt_malloclimit.cpp Changeset: d230b303 Author: Jaikiran Pai Date: 2024-06-04 01:53:18 +0000 URL: https://git.openjdk.org/loom/commit/d230b30353f59135287436b09949b80e9fd73a93 8333398: Uncomment the commented test in test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarAPI.java Reviewed-by: iris, lancea ! test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarAPI.java Changeset: c7d2a5c1 Author: Alexander Scherbatiy Date: 2024-06-04 03:12:40 +0000 URL: https://git.openjdk.org/loom/commit/c7d2a5c1c4e86955100f4c40170dc25222abd07f 8314070: javax.print: Support IPP output-bin attribute extension Reviewed-by: psadhukhan, prr ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m + src/java.desktop/share/classes/javax/print/attribute/standard/OutputBin.java ! src/java.desktop/share/classes/javax/print/attribute/standard/package-info.java + src/java.desktop/share/classes/sun/print/CustomOutputBin.java ! src/java.desktop/share/classes/sun/print/PSPrinterJob.java ! src/java.desktop/share/classes/sun/print/RasterPrinterJob.java ! src/java.desktop/share/classes/sun/print/ServiceDialog.java ! src/java.desktop/share/classes/sun/print/resources/serviceui.properties ! src/java.desktop/share/classes/sun/print/resources/serviceui_de.properties ! src/java.desktop/share/classes/sun/print/resources/serviceui_es.properties ! src/java.desktop/share/classes/sun/print/resources/serviceui_fr.properties ! src/java.desktop/share/classes/sun/print/resources/serviceui_it.properties ! src/java.desktop/share/classes/sun/print/resources/serviceui_ja.properties ! src/java.desktop/share/classes/sun/print/resources/serviceui_ko.properties ! src/java.desktop/share/classes/sun/print/resources/serviceui_pt_BR.properties ! src/java.desktop/share/classes/sun/print/resources/serviceui_sv.properties ! src/java.desktop/share/classes/sun/print/resources/serviceui_zh_CN.properties ! src/java.desktop/share/classes/sun/print/resources/serviceui_zh_TW.properties ! src/java.desktop/unix/classes/sun/print/CUPSPrinter.java ! src/java.desktop/unix/classes/sun/print/IPPPrintService.java ! src/java.desktop/unix/native/common/awt/CUPSfuncs.c + test/jdk/javax/print/attribute/CheckSupportedOutputBinsTest.java + test/jdk/javax/print/attribute/OutputBinAttributePrintDialogTest.java + test/jdk/javax/print/attribute/OutputBinAttributeTest.java Changeset: 29e10e45 Author: Vladimir Ivanov Date: 2024-06-04 04:02:49 +0000 URL: https://git.openjdk.org/loom/commit/29e10e4582c1a844a6db4c42ba01bd1d6d4dfd52 8332547: Unloaded signature classes in DirectMethodHandles Reviewed-by: jvernee, liach ! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java ! src/java.base/share/classes/java/lang/invoke/MemberName.java ! src/java.base/share/classes/sun/invoke/util/VerifyAccess.java + test/hotspot/jtreg/compiler/runtime/unloaded/TestUnloadedSignatureClass.java Changeset: ca307263 Author: Jayathirth D V Date: 2024-06-04 05:11:41 +0000 URL: https://git.openjdk.org/loom/commit/ca3072635215755766575b4eb70dc6267969a550 8332866: Crash in ImageIO JPEG decoding when MEM_STATS in enabled Reviewed-by: abhiscxk, psadhukhan ! src/java.desktop/share/native/libjavajpeg/imageioJPEG.c Changeset: 67d6f3ca Author: Emanuel Peter Date: 2024-06-04 06:20:31 +0000 URL: https://git.openjdk.org/loom/commit/67d6f3ca9e8d1312c9e3a85dbe19903619f59064 8332905: C2 SuperWord: bad AD file, with RotateRightV and first operand not a pack Reviewed-by: chagedorn, thartmann ! src/hotspot/share/opto/superword.cpp ! test/hotspot/jtreg/compiler/vectorization/runner/ArrayShiftOpTest.java Changeset: 454660d3 Author: Hamlin Li Date: 2024-06-04 07:04:57 +0000 URL: https://git.openjdk.org/loom/commit/454660d361e39f362ff0e10a5c2389af910cca23 8332900: RISC-V: refactor nativeInst_riscv.cpp and macroAssembler_riscv.cpp Reviewed-by: fyang, luhenry ! src/hotspot/cpu/riscv/gc/z/zBarrierSetAssembler_riscv.cpp ! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp ! src/hotspot/cpu/riscv/macroAssembler_riscv.hpp ! src/hotspot/cpu/riscv/nativeInst_riscv.cpp ! src/hotspot/cpu/riscv/nativeInst_riscv.hpp ! src/hotspot/cpu/riscv/relocInfo_riscv.cpp Changeset: c7495fb3 Author: Albert Mingkun Yang Date: 2024-06-04 07:56:55 +0000 URL: https://git.openjdk.org/loom/commit/c7495fb35d7736815d5777ab776ace013f9d50b5 8333444: Parallel: Inline PSParallelCompact::mark_obj Reviewed-by: tschatzl ! src/hotspot/share/gc/parallel/psCompactionManager.inline.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.inline.hpp Changeset: 64bbae75 Author: Christian Hagedorn Date: 2024-06-04 09:47:08 +0000 URL: https://git.openjdk.org/loom/commit/64bbae75121ccf80c02a0960e2db62eb558052e6 8333394: C2: assert(bol->is_Opaque4() || bol->is_OpaqueInitializedAssertionPredicate()) failed: Opaque node of non-null-check or of Initialized Assertion Predicate Reviewed-by: thartmann, roland ! src/hotspot/share/opto/loopTransform.cpp + test/hotspot/jtreg/compiler/predicates/assertion/TestIfWithPhiInput.java Changeset: 0f4154a9 Author: Johan Sj?len Date: 2024-06-04 10:53:26 +0000 URL: https://git.openjdk.org/loom/commit/0f4154a9e9805534595feccc53a4a1abf20f99ae 8331193: Return references when possible in GrowableArray Reviewed-by: stefank, kbarrett, epeter ! src/hotspot/share/utilities/growableArray.hpp ! test/hotspot/gtest/utilities/test_growableArray.cpp Changeset: 9ee741d1 Author: Nizar Benalla Committer: Michael McMahon Date: 2024-06-04 11:38:54 +0000 URL: https://git.openjdk.org/loom/commit/9ee741d1e55c2520b28a5e3ca0604073d81d0059 8332015: since-checker - Add @ since tags to jdk.httpserver Reviewed-by: alanb, dfuchs, michaelm ! src/jdk.httpserver/share/classes/com/sun/net/httpserver/BasicAuthenticator.java ! src/jdk.httpserver/share/classes/com/sun/net/httpserver/spi/package-info.java Changeset: 8d3de45f Author: Jan Lahoda Date: 2024-06-04 11:54:49 +0000 URL: https://git.openjdk.org/loom/commit/8d3de45f4dfd60dc4e2f210cb0c085fcf6efb8e2 8325168: JShell should support Markdown comments Reviewed-by: jjg - src/jdk.compiler/share/classes/jdk/internal/shellsupport/doc/JavadocHelper.java ! src/jdk.compiler/share/classes/module-info.java = src/jdk.jshell/share/classes/jdk/internal/shellsupport/doc/JavadocFormatter.java + src/jdk.jshell/share/classes/jdk/internal/shellsupport/doc/JavadocHelper.java = src/jdk.jshell/share/classes/jdk/internal/shellsupport/doc/resources/javadocformatter.properties ! src/jdk.jshell/share/classes/module-info.java ! test/langtools/jdk/internal/shellsupport/doc/FullJavadocHelperTest.java ! test/langtools/jdk/internal/shellsupport/doc/JavadocFormatterTest.java ! test/langtools/jdk/internal/shellsupport/doc/JavadocHelperTest.java Changeset: 664c993c Author: Vladimir Kozlov Date: 2024-06-04 16:36:39 +0000 URL: https://git.openjdk.org/loom/commit/664c993c41753843293388a6ff1481a94a5b4c22 8331731: ubsan: relocInfo.cpp:155:30: runtime error: applying non-zero offset to null pointer Co-authored-by: Axel Boldt-Christmas Co-authored-by: Dean Long Reviewed-by: mdoerr, thartmann, mbaesken ! src/hotspot/share/asm/codeBuffer.cpp ! src/hotspot/share/code/relocInfo.cpp Changeset: 4a1cdd5b Author: Albert Mingkun Yang Date: 2024-06-04 16:39:03 +0000 URL: https://git.openjdk.org/loom/commit/4a1cdd5ba947ffc88c1100966e68826eb35ed441 8333486: Parallel: Remove unused methods in psParallelCompact Reviewed-by: tschatzl ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/gc/parallel/psParallelCompact.hpp Changeset: 31f70391 Author: Calvin Cheung Date: 2024-06-04 16:43:08 +0000 URL: https://git.openjdk.org/loom/commit/31f70391e5f22ff5803d16b52c1e1248b6253d8c 8316131: runtime/cds/appcds/TestParallelGCWithCDS.java fails with JNI error Reviewed-by: dholmes, iklam ! test/hotspot/jtreg/runtime/cds/appcds/TestParallelGCWithCDS.java Changeset: e0bab786 Author: Nizar Benalla Committer: Jaikiran Pai Date: 2024-06-04 16:51:39 +0000 URL: https://git.openjdk.org/loom/commit/e0bab786402d70e9a74d1816c029c772ea01f697 8326951: since-checker - missing @ since tags Reviewed-by: jpai ! src/java.base/share/classes/java/io/PrintStream.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/reflect/MalformedParameterizedTypeException.java ! src/java.base/share/classes/java/nio/MappedByteBuffer.java ! src/java.base/share/classes/java/util/Properties.java ! src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java ! src/java.base/share/classes/java/util/zip/Deflater.java Changeset: b101dcb6 Author: David M. Lloyd Committer: Adam Sotona Date: 2024-06-04 16:57:59 +0000 URL: https://git.openjdk.org/loom/commit/b101dcb609eae00b406f387cd90e58487d5868df 8333312: Incorrect since tags on new ClassReader and ConstantPool methods Reviewed-by: liach, asotona ! src/java.base/share/classes/java/lang/classfile/ClassReader.java ! src/java.base/share/classes/java/lang/classfile/constantpool/ConstantPool.java Changeset: dce97031 Author: Vladimir Kozlov Date: 2024-06-04 16:58:21 +0000 URL: https://git.openjdk.org/loom/commit/dce97031555dcf689fecda16e444e7e8e9d5b270 8333226: Regressions 2-3% in Compress ZGC after 8331253 Reviewed-by: chagedorn, thartmann ! src/hotspot/cpu/aarch64/gc/z/zBarrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/ppc/gc/z/zBarrierSetAssembler_ppc.cpp ! src/hotspot/cpu/x86/gc/z/zBarrierSetAssembler_x86.cpp ! src/hotspot/share/asm/codeBuffer.cpp ! src/hotspot/share/asm/codeBuffer.hpp ! src/hotspot/share/ci/ciMethod.cpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/opto/output.cpp Changeset: 612b6896 Author: Liam Miller-Cushon Date: 2024-06-04 17:18:53 +0000 URL: https://git.openjdk.org/loom/commit/612b6896d28cebf61ef024709ff3afb5e3ee0dde 8043226: Better diagnostics for non-applicable type annotations Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Printer.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/langtools/ProblemList.txt ! test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotatePackages.java ! test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotatePackages.out ! test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.java ! test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.out ! test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass2.java ! test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass2.out ! test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass3.java ! test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass3.out ! test/langtools/tools/javac/annotations/typeAnnotations/newlocations/RepeatingTypeAnnotations.java ! test/langtools/tools/javac/annotations/typeAnnotations/newlocations/RepeatingTypeAnnotations.out ! test/langtools/tools/javac/diags/examples/CantAnnotateScoping.java ! test/langtools/tools/javac/diags/examples/CantAnnotateScoping1.java Changeset: a706e35b Author: Hannes Walln?fer Date: 2024-06-04 17:21:33 +0000 URL: https://git.openjdk.org/loom/commit/a706e35b12addff987b489059be8f240c60fae75 8332039: Cannot invoke "com.sun.source.util.DocTreePath.getTreePath()" because "path" is null Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/CommentHelper.java ! test/langtools/jdk/javadoc/doclet/testSinceTag/TestSinceTag.java Changeset: 244f6ac2 Author: Leonid Mesnik Date: 2024-06-04 19:18:41 +0000 URL: https://git.openjdk.org/loom/commit/244f6ac222fa98fba4fb99bf5bccd36e3e6c5de1 8307824: Clean up Finalizable.java and finalize terminology in vmTestbase/nsk/share Reviewed-by: sspitsyn, cjplummer ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VMOutOfMemoryException/VMOutOfMemoryException001/VMOutOfMemoryException001t.java - test/hotspot/jtreg/vmTestbase/nsk/share/Finalizable.java - test/hotspot/jtreg/vmTestbase/nsk/share/FinalizableObject.java - test/hotspot/jtreg/vmTestbase/nsk/share/Finalizer.java ! test/hotspot/jtreg/vmTestbase/nsk/share/MainWrapper.java ! test/hotspot/jtreg/vmTestbase/nsk/share/aod/DummyTargetApplication.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeBinder.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeProcess.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jpda/IOPipe.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jpda/SocketIOPipe.java Changeset: 67b9a081 Author: Joe Darcy Date: 2024-06-05 00:56:25 +0000 URL: https://git.openjdk.org/loom/commit/67b9a081391d6ef775581d65da4b3cc302aa8dd8 8333586: Improve syntax of @see tags in javax.lang.model Reviewed-by: iris, jjg ! src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor7.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor8.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor9.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor7.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor8.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor9.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor7.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor8.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor9.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor7.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor8.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor9.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementScanner14.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementScanner7.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementScanner8.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementScanner9.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor7.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor8.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor9.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor7.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor8.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor9.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitor7.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitor8.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitor9.java ! src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor7.java ! src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor8.java ! src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor9.java Changeset: d8261279 Author: lingjun.cg Committer: Denghui Dong Date: 2024-06-05 01:51:20 +0000 URL: https://git.openjdk.org/loom/commit/d826127970bd2ae8bf4cacc3c55634dc5af307c4 8333462: Performance regression of new DecimalFormat() when compare to jdk11 Reviewed-by: liach, naoto, jlu ! src/java.base/share/classes/java/text/DecimalFormatSymbols.java Changeset: 9db7c950 Author: Joe Wang Date: 2024-06-05 02:52:55 +0000 URL: https://git.openjdk.org/loom/commit/9db7c950190853513f4c2afa0efa9a4ff72b60d7 8332750: Broken link in CatalogFeatures.html Reviewed-by: lancea, iris, naoto ! src/java.xml/share/classes/javax/xml/catalog/CatalogFeatures.java Changeset: 7dbd0338 Author: SendaoYan Committer: Tobias Hartmann Date: 2024-06-05 05:09:53 +0000 URL: https://git.openjdk.org/loom/commit/7dbd03388eef9cddbab6a622338b00ce250be3dc 8332499: Gtest codestrings.validate_vm fail on linux x64 when hsdis is present Reviewed-by: thartmann, chagedorn ! test/hotspot/gtest/code/test_codestrings.cpp Changeset: d3c21c16 Author: Alan Bateman Date: 2024-06-05 06:51:26 +0000 URL: https://git.openjdk.org/loom/commit/d3c21c169f24bb93566706fc6be5f101118bf33d Merge ! src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/threads.cpp ! test/langtools/ProblemList.txt ! src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/threads.cpp ! test/langtools/ProblemList.txt Changeset: ffb73c21 Author: Alan Bateman Date: 2024-06-05 07:05:35 +0000 URL: https://git.openjdk.org/loom/commit/ffb73c214fad629339959936e9074f00eefc7d99 Test improvements ! test/jdk/java/lang/Thread/virtual/MonitorWaitNotify.java = test/jdk/java/lang/Thread/virtual/RetryMonitorEnterWhenPinned.java - test/jdk/java/lang/Thread/virtual/stress/RaceWaitTimeout.java + test/jdk/java/lang/Thread/virtual/stress/TimedWaitALot.java Changeset: 33740739 Author: Alan Bateman Date: 2024-06-05 07:05:46 +0000 URL: https://git.openjdk.org/loom/commit/3374073903eb5295c3dc93dd4685223ad6ea3158 Merge From duke at openjdk.org Wed Jun 5 10:07:20 2024 From: duke at openjdk.org (duke) Date: Wed, 5 Jun 2024 10:07:20 GMT Subject: git: openjdk/loom: master: 49 new changesets Message-ID: <2adcfb28-a586-4dc2-b117-71682a50bcf8@openjdk.org> Changeset: c0ce7d87 Author: John Jiang Date: 2024-06-01 05:58:00 +0000 URL: https://git.openjdk.org/loom/commit/c0ce7d871f09df6bf4a21be3579f3f39a49a77bd 8333046: Clean codes in sun.security.util.math Reviewed-by: weijun ! src/java.base/share/classes/sun/security/util/math/IntegerMontgomeryFieldModuloP.java ! src/java.base/share/classes/sun/security/util/math/intpoly/IntegerPolynomial.java ! src/java.base/share/classes/sun/security/util/math/intpoly/MontgomeryIntegerPolynomialP256.java ! test/jdk/com/sun/security/ec/ECOperationsKATTest.java ! test/jdk/com/sun/security/util/math/intpoly/IntegerPolynomialTest.java ! test/jdk/com/sun/security/util/math/intpoly/MontgomeryPolynomialFuzzTest.java Changeset: d29d5bfb Author: Thomas Stuefe Date: 2024-06-01 08:19:07 +0000 URL: https://git.openjdk.org/loom/commit/d29d5bfb7fae35cb9f025c5a20e551a1391e38aa 8333290: NMT report should not print Metaspace info if Metaspace is not yet initialized Reviewed-by: stefank, dholmes ! src/hotspot/share/memory/metaspace/runningCounters.cpp ! src/hotspot/share/nmt/memReporter.cpp Changeset: 51b2f806 Author: SendaoYan Committer: Serguei Spitsyn Date: 2024-06-01 11:31:19 +0000 URL: https://git.openjdk.org/loom/commit/51b2f80627adc1ca9f8335c3c028109a7018a8be 8332923: ObjectMonitorUsage.java failed with unexpected waiter_count Co-authored-by: Jiawei Tang Reviewed-by: sspitsyn, alanb, amitkumar ! src/hotspot/share/prims/jvmtiEnvBase.cpp ! src/hotspot/share/runtime/threads.cpp Changeset: 24530022 Author: Alexey Semenyuk Date: 2024-06-01 12:31:25 +0000 URL: https://git.openjdk.org/loom/commit/24530022d066763f7573f5c6d2030a30dc55afa6 8331977: Crash: SIGSEGV in dlerror() Reviewed-by: almatvee ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/HelloApp.java ! test/jdk/tools/jpackage/macosx/ArgumentsFilteringTest.java ! test/jdk/tools/jpackage/share/ArgumentsTest.java ! test/jdk/tools/jpackage/share/jdk/jpackage/tests/MainClassTest.java ! test/jdk/tools/jpackage/windows/WinRenameTest.java Changeset: 4785461f Author: Jaikiran Pai Date: 2024-06-02 01:07:27 +0000 URL: https://git.openjdk.org/loom/commit/4785461f61d8f5c7444d2e6fd90f1e083dbc6fe4 7022325: TEST_BUG: test/java/util/zip/ZipFile/ReadLongZipFileName.java leaks files if it fails Reviewed-by: lancea ! test/jdk/java/util/zip/ZipFile/ReadLongZipFileName.java Changeset: 8338946a Author: David Holmes Date: 2024-06-02 20:08:17 +0000 URL: https://git.openjdk.org/loom/commit/8338946a6d765eab9cd7a6cbc24c865a9cd355e7 8332935: Crash: assert(*lastPtr != 0) failed: Mismatched JNINativeInterface tables, check for new entries Reviewed-by: dcubed, stuefe ! src/hotspot/share/prims/jniCheck.cpp Changeset: 769b3e48 Author: Claes Redestad Date: 2024-06-02 20:29:03 +0000 URL: https://git.openjdk.org/loom/commit/769b3e48ea97a13756cf096ae235d7434c0cae34 8333182: Add truncated tracing mode for TraceBytecodes Reviewed-by: dholmes, fparain, coleenp ! src/hotspot/share/interpreter/bytecodeTracer.cpp ! src/hotspot/share/runtime/globals.hpp Changeset: cfe91ed3 Author: Gui Cao Committer: Fei Yang Date: 2024-06-03 01:44:16 +0000 URL: https://git.openjdk.org/loom/commit/cfe91ed39c9a0c8e8b16e142ee8cf3a90a6c69c3 8333276: RISC-V: client VM build failure after JDK-8241503 Reviewed-by: fyang ! src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp ! src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.hpp Changeset: a4c7be86 Author: Gui Cao Committer: Fei Yang Date: 2024-06-03 01:48:10 +0000 URL: https://git.openjdk.org/loom/commit/a4c7be862cc6dc121efb6c1c283236a588259c8f 8333006: RISC-V: C2: Support vector-scalar and vector-immediate arithmetic instructions Reviewed-by: fyang, fjiang ! src/hotspot/cpu/riscv/riscv.ad ! src/hotspot/cpu/riscv/riscv_v.ad Changeset: 75220da2 Author: Gui Cao Committer: Fei Yang Date: 2024-06-03 04:42:44 +0000 URL: https://git.openjdk.org/loom/commit/75220da26f647c6f3dabc05cea81cefaf3a1e195 8333154: RISC-V: Add support for primitive array C1 clone intrinsic Reviewed-by: fyang ! src/hotspot/cpu/riscv/c1_LIRAssembler_arraycopy_riscv.cpp ! src/hotspot/cpu/riscv/c1_LIRAssembler_riscv.cpp ! src/hotspot/cpu/riscv/c1_LIRGenerator_riscv.cpp ! src/hotspot/cpu/riscv/c1_MacroAssembler_riscv.cpp ! src/hotspot/cpu/riscv/c1_MacroAssembler_riscv.hpp ! src/hotspot/share/c1/c1_Compiler.cpp ! src/hotspot/share/c1/c1_LIR.cpp Changeset: 7c83d7ab Author: Christian Hagedorn Date: 2024-06-03 06:41:33 +0000 URL: https://git.openjdk.org/loom/commit/7c83d7ab53f1f761a88a1d248b9a2f14980ef702 8333366: C2: CmpU3Nodes are not pushed back to worklist in PhaseCCP leading to non-fixpoint assertion failure Reviewed-by: kvn, thartmann ! src/hotspot/share/opto/phaseX.cpp + test/hotspot/jtreg/compiler/ccp/TestPushCmpU3Node.java Changeset: d2d78ad1 Author: Alexander Zvegintsev Date: 2024-06-03 07:12:06 +0000 URL: https://git.openjdk.org/loom/commit/d2d78ad18e0b5d2a6a62f9c97ceec5592fa1de2e 8280990: [XWayland] XTest emulated mouse click does not bring window to front Reviewed-by: avu, psadhukhan, kizune ! test/jdk/java/awt/Modal/ToFront/FrameToFrontModelessTest.java ! test/jdk/java/awt/Modal/helpers/TestDialog.java ! test/jdk/java/awt/Modal/helpers/TestFrame.java Changeset: e0ac8249 Author: Roberto Casta?eda Lozano Date: 2024-06-03 07:37:17 +0000 URL: https://git.openjdk.org/loom/commit/e0ac8249f54222cc5efe49d5ed1068fed3073ba0 8332959: C2: ZGC fails with 'Incorrect load shift' when invoking Object.clone() reflectively on an array Co-authored-by: Axel Boldt-Christmas Reviewed-by: kvn, thartmann, aboldtch ! src/hotspot/share/opto/library_call.cpp ! test/hotspot/jtreg/compiler/arraycopy/TestObjectArrayClone.java Changeset: 91101f0d Author: SendaoYan Committer: Aleksey Shipilev Date: 2024-06-03 08:12:22 +0000 URL: https://git.openjdk.org/loom/commit/91101f0d4fc8e06d0d74e06361db6ac87efeeb8e 8333353: Delete extra empty line in CodeBlob.java Reviewed-by: cjplummer, lmesnik ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/CodeBlob.java Changeset: 5ed0d52c Author: Thomas Schatzl Date: 2024-06-03 09:25:37 +0000 URL: https://git.openjdk.org/loom/commit/5ed0d52c8424dd2e7f1ac2404e9fabb40c8402b8 8332936: Test vmTestbase/metaspace/gc/watermark_70_80/TestDescription.java fails with no GC's recorded Reviewed-by: stefank, ayang ! test/hotspot/jtreg/vmTestbase/metaspace/gc/watermark_0_1/TestDescription.java ! test/hotspot/jtreg/vmTestbase/metaspace/gc/watermark_10_20/TestDescription.java ! test/hotspot/jtreg/vmTestbase/metaspace/gc/watermark_70_80/TestDescription.java ! test/hotspot/jtreg/vmTestbase/metaspace/gc/watermark_99_100/TestDescription.java Changeset: b1015862 Author: Thomas Stuefe Date: 2024-06-03 09:26:50 +0000 URL: https://git.openjdk.org/loom/commit/b10158624bd0cfe009f0fe7f2a06ee08e654766b 8332514: Allow class space size to be larger than 3GB Reviewed-by: iklam, dholmes ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/runtime/globals.hpp ! test/hotspot/jtreg/runtime/CompressedOops/CompressedClassSpaceSize.java Changeset: f0bffbce Author: Magnus Ihse Bursie Date: 2024-06-03 10:03:42 +0000 URL: https://git.openjdk.org/loom/commit/f0bffbce35bb06e724857e8651dd429c4f9df284 8333301: Remove static builds using --enable-static-build Reviewed-by: sgehwolf, erikj - make/BuildStatic.gmk ! make/Main.gmk ! make/autoconf/flags-cflags.m4 ! make/autoconf/jdk-options.m4 ! make/autoconf/jvm-features.m4 ! make/autoconf/spec.gmk.template ! make/autoconf/toolchain.m4 ! make/common/JdkNativeCompilation.gmk ! make/common/NativeCompilation.gmk ! make/common/modules/LauncherCommon.gmk ! make/common/native/Link.gmk ! make/hotspot/lib/JvmFeatures.gmk ! make/modules/java.base/Lib.gmk ! make/modules/jdk.jdwp.agent/Lib.gmk Changeset: d07e530d Author: SendaoYan Committer: Julian Waters Date: 2024-06-03 12:07:11 +0000 URL: https://git.openjdk.org/loom/commit/d07e530d33360dae687552a6dfbe26408f3fb58e 8333128: Linux x86_32 configure fail with --with-hsdis=binutils --with-binutils-src Reviewed-by: shade, jwaters, ihse ! make/autoconf/lib-hsdis.m4 Changeset: 1c514b34 Author: Prasanta Sadhukhan Date: 2024-06-03 13:00:23 +0000 URL: https://git.openjdk.org/loom/commit/1c514b34c0260823e70f209996ac933a76ac34c2 8325435: [macos] Menu or JPopupMenu not closed when main window is resized Reviewed-by: azvegint ! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m + test/jdk/javax/swing/JMenu/TestUngrab.java Changeset: 27af19d9 Author: John Engebretson Committer: Aleksey Shipilev Date: 2024-06-03 13:38:48 +0000 URL: https://git.openjdk.org/loom/commit/27af19d921a5cf15f5146471b58961815690b4f2 8332586: Avoid cloning empty arrays in java.lang.reflect.{Method,Constructor} Reviewed-by: shade, rriggs, liach ! src/java.base/share/classes/java/lang/reflect/Constructor.java ! src/java.base/share/classes/java/lang/reflect/Method.java + test/micro/org/openjdk/bench/java/lang/reflect/ConstructorBenchmark.java + test/micro/org/openjdk/bench/java/lang/reflect/MethodBenchmark.java Changeset: 1f9e6290 Author: Christian Hagedorn Date: 2024-06-03 14:03:34 +0000 URL: https://git.openjdk.org/loom/commit/1f9e62904c624b12bd344d2ef3021eb5d3377197 8333434: IGV: Print loop node for PHASE_BEFORE/AFTER_CLOOPS Reviewed-by: thartmann, rcastanedalo ! src/hotspot/share/opto/loopnode.cpp Changeset: 4de62073 Author: Albert Mingkun Yang Date: 2024-06-03 15:40:47 +0000 URL: https://git.openjdk.org/loom/commit/4de620732f03c71fec3e1c233947742d334c88ad 8333229: Parallel: Rename ParMarkBitMap::_region_start to _heap_start Reviewed-by: tschatzl ! src/hotspot/share/gc/parallel/parMarkBitMap.cpp ! src/hotspot/share/gc/parallel/parMarkBitMap.hpp ! src/hotspot/share/gc/parallel/parMarkBitMap.inline.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.hpp Changeset: 9686e804 Author: Naoto Sato Date: 2024-06-03 15:52:21 +0000 URL: https://git.openjdk.org/loom/commit/9686e804a2b058955ff88149c54a0a7896c0a2eb 8333103: Re-examine the console provider loading Reviewed-by: redestad, jpai ! src/java.base/share/classes/java/io/Console.java Changeset: 6dac8d64 Author: Justin Lu Date: 2024-06-03 22:00:31 +0000 URL: https://git.openjdk.org/loom/commit/6dac8d64527b4e9ade783b99f82fbecd81c426a6 8332424: Update IANA Language Subtag Registry to Version 2024-05-16 Reviewed-by: naoto, iris ! src/java.base/share/data/lsrdata/language-subtag-registry.txt ! test/jdk/java/util/Locale/LanguageSubtagRegistryTest.java Changeset: 1512011e Author: Sonia Zaldana Calles Committer: David Holmes Date: 2024-06-04 01:33:59 +0000 URL: https://git.openjdk.org/loom/commit/1512011eaf24e056974d2d1485152ab3c8960743 8332123: [nmt] Move mallocLimit code to the nmt subdir Reviewed-by: dholmes, stuefe = src/hotspot/share/nmt/mallocLimit.cpp = src/hotspot/share/nmt/mallocLimit.hpp ! src/hotspot/share/nmt/mallocTracker.cpp ! src/hotspot/share/nmt/mallocTracker.inline.hpp ! src/hotspot/share/nmt/memTracker.cpp ! test/hotspot/gtest/nmt/test_nmt_malloclimit.cpp Changeset: d230b303 Author: Jaikiran Pai Date: 2024-06-04 01:53:18 +0000 URL: https://git.openjdk.org/loom/commit/d230b30353f59135287436b09949b80e9fd73a93 8333398: Uncomment the commented test in test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarAPI.java Reviewed-by: iris, lancea ! test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarAPI.java Changeset: c7d2a5c1 Author: Alexander Scherbatiy Date: 2024-06-04 03:12:40 +0000 URL: https://git.openjdk.org/loom/commit/c7d2a5c1c4e86955100f4c40170dc25222abd07f 8314070: javax.print: Support IPP output-bin attribute extension Reviewed-by: psadhukhan, prr ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java ! src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m + src/java.desktop/share/classes/javax/print/attribute/standard/OutputBin.java ! src/java.desktop/share/classes/javax/print/attribute/standard/package-info.java + src/java.desktop/share/classes/sun/print/CustomOutputBin.java ! src/java.desktop/share/classes/sun/print/PSPrinterJob.java ! src/java.desktop/share/classes/sun/print/RasterPrinterJob.java ! src/java.desktop/share/classes/sun/print/ServiceDialog.java ! src/java.desktop/share/classes/sun/print/resources/serviceui.properties ! src/java.desktop/share/classes/sun/print/resources/serviceui_de.properties ! src/java.desktop/share/classes/sun/print/resources/serviceui_es.properties ! src/java.desktop/share/classes/sun/print/resources/serviceui_fr.properties ! src/java.desktop/share/classes/sun/print/resources/serviceui_it.properties ! src/java.desktop/share/classes/sun/print/resources/serviceui_ja.properties ! src/java.desktop/share/classes/sun/print/resources/serviceui_ko.properties ! src/java.desktop/share/classes/sun/print/resources/serviceui_pt_BR.properties ! src/java.desktop/share/classes/sun/print/resources/serviceui_sv.properties ! src/java.desktop/share/classes/sun/print/resources/serviceui_zh_CN.properties ! src/java.desktop/share/classes/sun/print/resources/serviceui_zh_TW.properties ! src/java.desktop/unix/classes/sun/print/CUPSPrinter.java ! src/java.desktop/unix/classes/sun/print/IPPPrintService.java ! src/java.desktop/unix/native/common/awt/CUPSfuncs.c + test/jdk/javax/print/attribute/CheckSupportedOutputBinsTest.java + test/jdk/javax/print/attribute/OutputBinAttributePrintDialogTest.java + test/jdk/javax/print/attribute/OutputBinAttributeTest.java Changeset: 29e10e45 Author: Vladimir Ivanov Date: 2024-06-04 04:02:49 +0000 URL: https://git.openjdk.org/loom/commit/29e10e4582c1a844a6db4c42ba01bd1d6d4dfd52 8332547: Unloaded signature classes in DirectMethodHandles Reviewed-by: jvernee, liach ! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java ! src/java.base/share/classes/java/lang/invoke/MemberName.java ! src/java.base/share/classes/sun/invoke/util/VerifyAccess.java + test/hotspot/jtreg/compiler/runtime/unloaded/TestUnloadedSignatureClass.java Changeset: ca307263 Author: Jayathirth D V Date: 2024-06-04 05:11:41 +0000 URL: https://git.openjdk.org/loom/commit/ca3072635215755766575b4eb70dc6267969a550 8332866: Crash in ImageIO JPEG decoding when MEM_STATS in enabled Reviewed-by: abhiscxk, psadhukhan ! src/java.desktop/share/native/libjavajpeg/imageioJPEG.c Changeset: 67d6f3ca Author: Emanuel Peter Date: 2024-06-04 06:20:31 +0000 URL: https://git.openjdk.org/loom/commit/67d6f3ca9e8d1312c9e3a85dbe19903619f59064 8332905: C2 SuperWord: bad AD file, with RotateRightV and first operand not a pack Reviewed-by: chagedorn, thartmann ! src/hotspot/share/opto/superword.cpp ! test/hotspot/jtreg/compiler/vectorization/runner/ArrayShiftOpTest.java Changeset: 454660d3 Author: Hamlin Li Date: 2024-06-04 07:04:57 +0000 URL: https://git.openjdk.org/loom/commit/454660d361e39f362ff0e10a5c2389af910cca23 8332900: RISC-V: refactor nativeInst_riscv.cpp and macroAssembler_riscv.cpp Reviewed-by: fyang, luhenry ! src/hotspot/cpu/riscv/gc/z/zBarrierSetAssembler_riscv.cpp ! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp ! src/hotspot/cpu/riscv/macroAssembler_riscv.hpp ! src/hotspot/cpu/riscv/nativeInst_riscv.cpp ! src/hotspot/cpu/riscv/nativeInst_riscv.hpp ! src/hotspot/cpu/riscv/relocInfo_riscv.cpp Changeset: c7495fb3 Author: Albert Mingkun Yang Date: 2024-06-04 07:56:55 +0000 URL: https://git.openjdk.org/loom/commit/c7495fb35d7736815d5777ab776ace013f9d50b5 8333444: Parallel: Inline PSParallelCompact::mark_obj Reviewed-by: tschatzl ! src/hotspot/share/gc/parallel/psCompactionManager.inline.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.inline.hpp Changeset: 64bbae75 Author: Christian Hagedorn Date: 2024-06-04 09:47:08 +0000 URL: https://git.openjdk.org/loom/commit/64bbae75121ccf80c02a0960e2db62eb558052e6 8333394: C2: assert(bol->is_Opaque4() || bol->is_OpaqueInitializedAssertionPredicate()) failed: Opaque node of non-null-check or of Initialized Assertion Predicate Reviewed-by: thartmann, roland ! src/hotspot/share/opto/loopTransform.cpp + test/hotspot/jtreg/compiler/predicates/assertion/TestIfWithPhiInput.java Changeset: 0f4154a9 Author: Johan Sj?len Date: 2024-06-04 10:53:26 +0000 URL: https://git.openjdk.org/loom/commit/0f4154a9e9805534595feccc53a4a1abf20f99ae 8331193: Return references when possible in GrowableArray Reviewed-by: stefank, kbarrett, epeter ! src/hotspot/share/utilities/growableArray.hpp ! test/hotspot/gtest/utilities/test_growableArray.cpp Changeset: 9ee741d1 Author: Nizar Benalla Committer: Michael McMahon Date: 2024-06-04 11:38:54 +0000 URL: https://git.openjdk.org/loom/commit/9ee741d1e55c2520b28a5e3ca0604073d81d0059 8332015: since-checker - Add @ since tags to jdk.httpserver Reviewed-by: alanb, dfuchs, michaelm ! src/jdk.httpserver/share/classes/com/sun/net/httpserver/BasicAuthenticator.java ! src/jdk.httpserver/share/classes/com/sun/net/httpserver/spi/package-info.java Changeset: 8d3de45f Author: Jan Lahoda Date: 2024-06-04 11:54:49 +0000 URL: https://git.openjdk.org/loom/commit/8d3de45f4dfd60dc4e2f210cb0c085fcf6efb8e2 8325168: JShell should support Markdown comments Reviewed-by: jjg - src/jdk.compiler/share/classes/jdk/internal/shellsupport/doc/JavadocHelper.java ! src/jdk.compiler/share/classes/module-info.java = src/jdk.jshell/share/classes/jdk/internal/shellsupport/doc/JavadocFormatter.java + src/jdk.jshell/share/classes/jdk/internal/shellsupport/doc/JavadocHelper.java = src/jdk.jshell/share/classes/jdk/internal/shellsupport/doc/resources/javadocformatter.properties ! src/jdk.jshell/share/classes/module-info.java ! test/langtools/jdk/internal/shellsupport/doc/FullJavadocHelperTest.java ! test/langtools/jdk/internal/shellsupport/doc/JavadocFormatterTest.java ! test/langtools/jdk/internal/shellsupport/doc/JavadocHelperTest.java Changeset: 664c993c Author: Vladimir Kozlov Date: 2024-06-04 16:36:39 +0000 URL: https://git.openjdk.org/loom/commit/664c993c41753843293388a6ff1481a94a5b4c22 8331731: ubsan: relocInfo.cpp:155:30: runtime error: applying non-zero offset to null pointer Co-authored-by: Axel Boldt-Christmas Co-authored-by: Dean Long Reviewed-by: mdoerr, thartmann, mbaesken ! src/hotspot/share/asm/codeBuffer.cpp ! src/hotspot/share/code/relocInfo.cpp Changeset: 4a1cdd5b Author: Albert Mingkun Yang Date: 2024-06-04 16:39:03 +0000 URL: https://git.openjdk.org/loom/commit/4a1cdd5ba947ffc88c1100966e68826eb35ed441 8333486: Parallel: Remove unused methods in psParallelCompact Reviewed-by: tschatzl ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/gc/parallel/psParallelCompact.hpp Changeset: 31f70391 Author: Calvin Cheung Date: 2024-06-04 16:43:08 +0000 URL: https://git.openjdk.org/loom/commit/31f70391e5f22ff5803d16b52c1e1248b6253d8c 8316131: runtime/cds/appcds/TestParallelGCWithCDS.java fails with JNI error Reviewed-by: dholmes, iklam ! test/hotspot/jtreg/runtime/cds/appcds/TestParallelGCWithCDS.java Changeset: e0bab786 Author: Nizar Benalla Committer: Jaikiran Pai Date: 2024-06-04 16:51:39 +0000 URL: https://git.openjdk.org/loom/commit/e0bab786402d70e9a74d1816c029c772ea01f697 8326951: since-checker - missing @ since tags Reviewed-by: jpai ! src/java.base/share/classes/java/io/PrintStream.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/reflect/MalformedParameterizedTypeException.java ! src/java.base/share/classes/java/nio/MappedByteBuffer.java ! src/java.base/share/classes/java/util/Properties.java ! src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java ! src/java.base/share/classes/java/util/zip/Deflater.java Changeset: b101dcb6 Author: David M. Lloyd Committer: Adam Sotona Date: 2024-06-04 16:57:59 +0000 URL: https://git.openjdk.org/loom/commit/b101dcb609eae00b406f387cd90e58487d5868df 8333312: Incorrect since tags on new ClassReader and ConstantPool methods Reviewed-by: liach, asotona ! src/java.base/share/classes/java/lang/classfile/ClassReader.java ! src/java.base/share/classes/java/lang/classfile/constantpool/ConstantPool.java Changeset: dce97031 Author: Vladimir Kozlov Date: 2024-06-04 16:58:21 +0000 URL: https://git.openjdk.org/loom/commit/dce97031555dcf689fecda16e444e7e8e9d5b270 8333226: Regressions 2-3% in Compress ZGC after 8331253 Reviewed-by: chagedorn, thartmann ! src/hotspot/cpu/aarch64/gc/z/zBarrierSetAssembler_aarch64.cpp ! src/hotspot/cpu/ppc/gc/z/zBarrierSetAssembler_ppc.cpp ! src/hotspot/cpu/x86/gc/z/zBarrierSetAssembler_x86.cpp ! src/hotspot/share/asm/codeBuffer.cpp ! src/hotspot/share/asm/codeBuffer.hpp ! src/hotspot/share/ci/ciMethod.cpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/opto/output.cpp Changeset: 612b6896 Author: Liam Miller-Cushon Date: 2024-06-04 17:18:53 +0000 URL: https://git.openjdk.org/loom/commit/612b6896d28cebf61ef024709ff3afb5e3ee0dde 8043226: Better diagnostics for non-applicable type annotations Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Printer.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/langtools/ProblemList.txt ! test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotatePackages.java ! test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotatePackages.out ! test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.java ! test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.out ! test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass2.java ! test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass2.out ! test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass3.java ! test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass3.out ! test/langtools/tools/javac/annotations/typeAnnotations/newlocations/RepeatingTypeAnnotations.java ! test/langtools/tools/javac/annotations/typeAnnotations/newlocations/RepeatingTypeAnnotations.out ! test/langtools/tools/javac/diags/examples/CantAnnotateScoping.java ! test/langtools/tools/javac/diags/examples/CantAnnotateScoping1.java Changeset: a706e35b Author: Hannes Walln?fer Date: 2024-06-04 17:21:33 +0000 URL: https://git.openjdk.org/loom/commit/a706e35b12addff987b489059be8f240c60fae75 8332039: Cannot invoke "com.sun.source.util.DocTreePath.getTreePath()" because "path" is null Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/CommentHelper.java ! test/langtools/jdk/javadoc/doclet/testSinceTag/TestSinceTag.java Changeset: 244f6ac2 Author: Leonid Mesnik Date: 2024-06-04 19:18:41 +0000 URL: https://git.openjdk.org/loom/commit/244f6ac222fa98fba4fb99bf5bccd36e3e6c5de1 8307824: Clean up Finalizable.java and finalize terminology in vmTestbase/nsk/share Reviewed-by: sspitsyn, cjplummer ! test/hotspot/jtreg/vmTestbase/nsk/jdi/VMOutOfMemoryException/VMOutOfMemoryException001/VMOutOfMemoryException001t.java - test/hotspot/jtreg/vmTestbase/nsk/share/Finalizable.java - test/hotspot/jtreg/vmTestbase/nsk/share/FinalizableObject.java - test/hotspot/jtreg/vmTestbase/nsk/share/Finalizer.java ! test/hotspot/jtreg/vmTestbase/nsk/share/MainWrapper.java ! test/hotspot/jtreg/vmTestbase/nsk/share/aod/DummyTargetApplication.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeBinder.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeProcess.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jpda/IOPipe.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jpda/SocketIOPipe.java Changeset: 67b9a081 Author: Joe Darcy Date: 2024-06-05 00:56:25 +0000 URL: https://git.openjdk.org/loom/commit/67b9a081391d6ef775581d65da4b3cc302aa8dd8 8333586: Improve syntax of @see tags in javax.lang.model Reviewed-by: iris, jjg ! src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor7.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor8.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor9.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor7.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor8.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor9.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor7.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor8.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor9.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor7.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor8.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor9.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementScanner14.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementScanner7.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementScanner8.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementScanner9.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor7.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor8.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor9.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor7.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor8.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor9.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitor7.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitor8.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitor9.java ! src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor7.java ! src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor8.java ! src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor9.java Changeset: d8261279 Author: lingjun.cg Committer: Denghui Dong Date: 2024-06-05 01:51:20 +0000 URL: https://git.openjdk.org/loom/commit/d826127970bd2ae8bf4cacc3c55634dc5af307c4 8333462: Performance regression of new DecimalFormat() when compare to jdk11 Reviewed-by: liach, naoto, jlu ! src/java.base/share/classes/java/text/DecimalFormatSymbols.java Changeset: 9db7c950 Author: Joe Wang Date: 2024-06-05 02:52:55 +0000 URL: https://git.openjdk.org/loom/commit/9db7c950190853513f4c2afa0efa9a4ff72b60d7 8332750: Broken link in CatalogFeatures.html Reviewed-by: lancea, iris, naoto ! src/java.xml/share/classes/javax/xml/catalog/CatalogFeatures.java Changeset: 7dbd0338 Author: SendaoYan Committer: Tobias Hartmann Date: 2024-06-05 05:09:53 +0000 URL: https://git.openjdk.org/loom/commit/7dbd03388eef9cddbab6a622338b00ce250be3dc 8332499: Gtest codestrings.validate_vm fail on linux x64 when hsdis is present Reviewed-by: thartmann, chagedorn ! test/hotspot/gtest/code/test_codestrings.cpp From hepin.p at alibaba-inc.com Wed Jun 5 10:18:19 2024 From: hepin.p at alibaba-inc.com (=?UTF-8?B?5L2V5ZOBKOiZjum4oyk=?=) Date: Wed, 05 Jun 2024 18:18:19 +0800 Subject: =?UTF-8?B?5Zue5aSN77ya5Zue5aSN77yaVmlydHVhbCB0aHJlYWQgaGFuZyBhbmQgYWxsIHRocmVhZHMg?= =?UTF-8?B?c3RvcCBydW5uaW5nIG9uIEpESzIx?= In-Reply-To: <77f87b07-a270-4ce6-b503-017c3254cc15@oracle.com> References: <77f87b07-a270-4ce6-b503-017c3254cc15@oracle.com> Message-ID: <3a11a569-a904-4e93-bf95-7cbc58816a1f.hepin.p@alibaba-inc.com> Yes, even jcmd is hung, we are currently want to switch back to the forkJoinPool and increase the jdk.virtualThreadScheduler.maxPoolSize and jdk.virtualThreadScheduler.parallelism > our total max concurrency. I have several system is using Virtual thread, but only this one cause problem. ------------------------------------------------------------------ ????Alan Bateman ?????2024?6?5?(???) 18:00 ????"??(??)"; "loom-dev" ????Re: ???Virtual thread hang and all threads stop running on JDK21 On 05/06/2024 10:37, ??(??) wrote: Thanks, 1. it hung when we are sharing the common usage of the Virtualthread (the default scheduler) cross two modules. 2. after that, I try to hack the virtual thread builder with separated ThreadPoolExecutor. 3. but still , it hung. when it hung, `jcmd Thread.print` prints nothing. and dump programly print nothing too. After switch back to normal thread, it never hang. Some information: module A is using `Object.notifyAll, Object.wait` and module B is using `CompletableFuture.get` (may > 100 times in one rune) I was thinking if that could be a problem of notification missing, where in Module A, the concurrency is 3000? protected by a semaphore, but the underling Carrier Thread is only 128, and 3000 > 128. If it's using synchronized/Object.wait then this may be related to pinning. When there is both object monitors and j.u.concurrent locks in play then it's possible to create deadlock scenarios due to starvation, or selecting a successor or thread to wakeup and the thread can't continue because there are no carriers available. Object.wait will temporarily increase parallelism to smooth and help some cases but it may not help you here, and does nothing when the scheduler has been changed to be something other than a ForkJoinPool instance. When you say "prints nothing" then you mean this literally or do you mean that jcmd is hung too? If so that's a hint that may be the lock for standard output is held by a virtual thread that can't continue because there are no carriers available. It would be interesting to try the latest Loom EA builds which has changes to the object monitor implementation that doesn't pin. Would you have time to try these builds out? -Alan [1] https://jdk.java.net/loom/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Wed Jun 5 13:50:43 2024 From: duke at openjdk.org (duke) Date: Wed, 5 Jun 2024 13:50:43 GMT Subject: git: openjdk/loom: fibers: 10 new changesets Message-ID: <684adbbf-963e-46e4-8f50-8622b7ed1e15@openjdk.org> Changeset: 1f094672 Author: Jan Lahoda Date: 2024-06-05 05:45:59 +0000 URL: https://git.openjdk.org/loom/commit/1f09467230971d6458918ec19ffeb259b8c028a3 8327368: javac crash when computing exhaustiveness checks Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java ! test/langtools/tools/javac/patterns/Exhaustiveness.java Changeset: 4369856c Author: Jaikiran Pai Date: 2024-06-05 06:35:46 +0000 URL: https://git.openjdk.org/loom/commit/4369856c6dbef15b5d73aa1da07216f372a01294 8333130: MakeJAR2.sh uses hard-coded JDK version Reviewed-by: lancea, darcy, sspitsyn, amenkov - test/jdk/java/lang/instrument/MakeJAR2.sh ! test/jdk/java/lang/instrument/NativeMethodPrefixAgent.java ! test/jdk/java/lang/instrument/NativeMethodPrefixApp.java ! test/jdk/java/lang/instrument/RetransformAgent.java ! test/jdk/java/lang/instrument/RetransformApp.java Changeset: d0052c03 Author: Matthias Baesken Date: 2024-06-05 07:11:27 +0000 URL: https://git.openjdk.org/loom/commit/d0052c032cc1927e7e92f04cfedab20e0c4e0293 8333326: Linux Alpine build fails after 8302744 Reviewed-by: sgehwolf, clanger, stuefe ! test/hotspot/gtest/runtime/test_cgroupSubsystem_linux.cpp Changeset: 3944e673 Author: Johan Sj?len Date: 2024-06-05 07:53:48 +0000 URL: https://git.openjdk.org/loom/commit/3944e67366601b6f748df1c5f93f184a7cb23ec3 8312132: Add tracking of multiple address spaces in NMT Co-authored-by: Thomas Stuefe Reviewed-by: stefank, stuefe ! src/hotspot/share/gc/z/zInitialize.cpp ! src/hotspot/share/gc/z/zNMT.cpp ! src/hotspot/share/gc/z/zNMT.hpp ! src/hotspot/share/nmt/memBaseline.cpp ! src/hotspot/share/nmt/memReporter.cpp ! src/hotspot/share/nmt/memReporter.hpp ! src/hotspot/share/nmt/memTracker.cpp ! src/hotspot/share/nmt/memTracker.hpp + src/hotspot/share/nmt/memoryFileTracker.cpp + src/hotspot/share/nmt/memoryFileTracker.hpp + src/hotspot/share/nmt/nmtNativeCallStackStorage.hpp + src/hotspot/share/nmt/nmtTreap.hpp ! src/hotspot/share/nmt/virtualMemoryTracker.hpp + src/hotspot/share/nmt/vmatree.cpp + src/hotspot/share/nmt/vmatree.hpp ! src/hotspot/share/utilities/nativeCallStack.hpp + test/hotspot/gtest/nmt/test_nmt_memoryfiletracker.cpp + test/hotspot/gtest/nmt/test_nmt_nativecallstackstorage.cpp + test/hotspot/gtest/nmt/test_nmt_treap.cpp + test/hotspot/gtest/nmt/test_vmatree.cpp ! test/hotspot/jtreg/gc/z/TestZNMT.java Changeset: 3cbdf8d4 Author: Albert Mingkun Yang Date: 2024-06-05 08:54:53 +0000 URL: https://git.openjdk.org/loom/commit/3cbdf8d4d4604c92d3760ba4e069216564306bcf 8333554: Parallel: Remove unused PSParallelCompact::is_in Reviewed-by: tschatzl ! src/hotspot/share/gc/parallel/parMarkBitMap.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.inline.hpp Changeset: 8e903eeb Author: Erik Gahlin Date: 2024-06-05 12:35:24 +0000 URL: https://git.openjdk.org/loom/commit/8e903eeb1fa04130fa7f154870ffcb1eae36c070 8331896: JFR: Improve check for JDK classes Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/internal/JVMUpcalls.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/MetadataRepository.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/MirrorEvents.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/TypeLibrary.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/periodic/JDKEventTask.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/util/Utils.java Changeset: 765ad0e4 Author: Hannes Walln?fer Date: 2024-06-05 12:39:56 +0000 URL: https://git.openjdk.org/loom/commit/765ad0e40bc522de4b2821ccc60b9139faf7376f 8331947: Preview creates checkbox for JEP-less preview feature Reviewed-by: liach, prappo ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/WorkArounds.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DeprecatedAPIListBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/NewAPIBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/PreviewAPIListBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/RestrictedAPIListBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/SummaryAPIListBuilder.java ! test/langtools/jdk/javadoc/doclet/testPreview/TestPreview.java ! test/langtools/jdk/javadoc/doclet/testPreview/api/preview/NoPreview.java Changeset: 2c1b311f Author: Matthias Baesken Date: 2024-06-05 12:45:26 +0000 URL: https://git.openjdk.org/loom/commit/2c1b311f81319cee1af574526a91424c2577b78c 8331854: ubsan: copy.hpp:218:10: runtime error: addition of unsigned offset to 0x7fc2b4024518 overflowed to 0x7fc2b4024510 Reviewed-by: kvn, clanger ! src/hotspot/share/utilities/copy.hpp Changeset: 789f704d Author: Doug Lea
Date: 2024-06-05 13:02:15 +0000 URL: https://git.openjdk.org/loom/commit/789f704d9ab5aaf87193f508859c4c9a528d7779 8322732: ForkJoinPool may underutilize cores in async mode 8327854: Test java/util/stream/test/org/openjdk/tests/java/util/stream/WhileOpStatefulTest.java failed with RuntimeException Reviewed-by: alanb ! src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java + test/jdk/java/util/concurrent/forkjoin/Starvation.java Changeset: 675efff0 Author: Alan Bateman Date: 2024-06-05 14:12:05 +0000 URL: https://git.openjdk.org/loom/commit/675efff0bfb342d7386e54dfbf87551c0640f685 Merge ! src/jdk.jfr/share/classes/jdk/jfr/internal/MirrorEvents.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/MirrorEvents.java From duke at openjdk.org Wed Jun 5 13:51:15 2024 From: duke at openjdk.org (duke) Date: Wed, 5 Jun 2024 13:51:15 GMT Subject: git: openjdk/loom: master: 9 new changesets Message-ID: <6125e89e-3556-4581-a302-0f2bfca53056@openjdk.org> Changeset: 1f094672 Author: Jan Lahoda Date: 2024-06-05 05:45:59 +0000 URL: https://git.openjdk.org/loom/commit/1f09467230971d6458918ec19ffeb259b8c028a3 8327368: javac crash when computing exhaustiveness checks Reviewed-by: vromero ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java ! test/langtools/tools/javac/patterns/Exhaustiveness.java Changeset: 4369856c Author: Jaikiran Pai Date: 2024-06-05 06:35:46 +0000 URL: https://git.openjdk.org/loom/commit/4369856c6dbef15b5d73aa1da07216f372a01294 8333130: MakeJAR2.sh uses hard-coded JDK version Reviewed-by: lancea, darcy, sspitsyn, amenkov - test/jdk/java/lang/instrument/MakeJAR2.sh ! test/jdk/java/lang/instrument/NativeMethodPrefixAgent.java ! test/jdk/java/lang/instrument/NativeMethodPrefixApp.java ! test/jdk/java/lang/instrument/RetransformAgent.java ! test/jdk/java/lang/instrument/RetransformApp.java Changeset: d0052c03 Author: Matthias Baesken Date: 2024-06-05 07:11:27 +0000 URL: https://git.openjdk.org/loom/commit/d0052c032cc1927e7e92f04cfedab20e0c4e0293 8333326: Linux Alpine build fails after 8302744 Reviewed-by: sgehwolf, clanger, stuefe ! test/hotspot/gtest/runtime/test_cgroupSubsystem_linux.cpp Changeset: 3944e673 Author: Johan Sj?len Date: 2024-06-05 07:53:48 +0000 URL: https://git.openjdk.org/loom/commit/3944e67366601b6f748df1c5f93f184a7cb23ec3 8312132: Add tracking of multiple address spaces in NMT Co-authored-by: Thomas Stuefe Reviewed-by: stefank, stuefe ! src/hotspot/share/gc/z/zInitialize.cpp ! src/hotspot/share/gc/z/zNMT.cpp ! src/hotspot/share/gc/z/zNMT.hpp ! src/hotspot/share/nmt/memBaseline.cpp ! src/hotspot/share/nmt/memReporter.cpp ! src/hotspot/share/nmt/memReporter.hpp ! src/hotspot/share/nmt/memTracker.cpp ! src/hotspot/share/nmt/memTracker.hpp + src/hotspot/share/nmt/memoryFileTracker.cpp + src/hotspot/share/nmt/memoryFileTracker.hpp + src/hotspot/share/nmt/nmtNativeCallStackStorage.hpp + src/hotspot/share/nmt/nmtTreap.hpp ! src/hotspot/share/nmt/virtualMemoryTracker.hpp + src/hotspot/share/nmt/vmatree.cpp + src/hotspot/share/nmt/vmatree.hpp ! src/hotspot/share/utilities/nativeCallStack.hpp + test/hotspot/gtest/nmt/test_nmt_memoryfiletracker.cpp + test/hotspot/gtest/nmt/test_nmt_nativecallstackstorage.cpp + test/hotspot/gtest/nmt/test_nmt_treap.cpp + test/hotspot/gtest/nmt/test_vmatree.cpp ! test/hotspot/jtreg/gc/z/TestZNMT.java Changeset: 3cbdf8d4 Author: Albert Mingkun Yang Date: 2024-06-05 08:54:53 +0000 URL: https://git.openjdk.org/loom/commit/3cbdf8d4d4604c92d3760ba4e069216564306bcf 8333554: Parallel: Remove unused PSParallelCompact::is_in Reviewed-by: tschatzl ! src/hotspot/share/gc/parallel/parMarkBitMap.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.inline.hpp Changeset: 8e903eeb Author: Erik Gahlin Date: 2024-06-05 12:35:24 +0000 URL: https://git.openjdk.org/loom/commit/8e903eeb1fa04130fa7f154870ffcb1eae36c070 8331896: JFR: Improve check for JDK classes Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/internal/JVMUpcalls.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/MetadataRepository.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/MirrorEvents.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/TypeLibrary.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/periodic/JDKEventTask.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/util/Utils.java Changeset: 765ad0e4 Author: Hannes Walln?fer Date: 2024-06-05 12:39:56 +0000 URL: https://git.openjdk.org/loom/commit/765ad0e40bc522de4b2821ccc60b9139faf7376f 8331947: Preview creates checkbox for JEP-less preview feature Reviewed-by: liach, prappo ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/WorkArounds.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DeprecatedAPIListBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/NewAPIBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/PreviewAPIListBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/RestrictedAPIListBuilder.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/SummaryAPIListBuilder.java ! test/langtools/jdk/javadoc/doclet/testPreview/TestPreview.java ! test/langtools/jdk/javadoc/doclet/testPreview/api/preview/NoPreview.java Changeset: 2c1b311f Author: Matthias Baesken Date: 2024-06-05 12:45:26 +0000 URL: https://git.openjdk.org/loom/commit/2c1b311f81319cee1af574526a91424c2577b78c 8331854: ubsan: copy.hpp:218:10: runtime error: addition of unsigned offset to 0x7fc2b4024518 overflowed to 0x7fc2b4024510 Reviewed-by: kvn, clanger ! src/hotspot/share/utilities/copy.hpp Changeset: 789f704d Author: Doug Lea
Date: 2024-06-05 13:02:15 +0000 URL: https://git.openjdk.org/loom/commit/789f704d9ab5aaf87193f508859c4c9a528d7779 8322732: ForkJoinPool may underutilize cores in async mode 8327854: Test java/util/stream/test/org/openjdk/tests/java/util/stream/WhileOpStatefulTest.java failed with RuntimeException Reviewed-by: alanb ! src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java + test/jdk/java/util/concurrent/forkjoin/Starvation.java From robaho at icloud.com Wed Jun 5 14:03:09 2024 From: robaho at icloud.com (Robert Engels) Date: Wed, 5 Jun 2024 09:03:09 -0500 Subject: Performance of pooling virtual threads vs. semaphores In-Reply-To: References: <18EB247B-8B78-4F45-B9C0-4785E2E3F775@icloud.com> Message-ID: Thinking about this some more, the numbers are as expected. It doesn?t matter if you have 16 cores or 128 cores - the wall time will be the same. All of the tasks are essentially ?waiting? nearly 100% of the time. Assume the wall time per task is 20 ms. If you have 1_000_000 tasks and you can execute 600 at the same time it will be (1_000_000 / 600) * 20 ms = 33 secs, which is basically what the wall time is in every case. If you look at the CPU (user & system) time - which in this case equates to the scheduler time + overhead (e.g. semaphore handling): java Main -- 4 1000000 153.96s user 4.66s system 432% cpu 36.678 total java Main -- 3 1000000 149.55s user 4.68s system 414% cpu 37.184 total It is 5 seconds on 1 million tasks, or an additional overhead of 5 microseconds on a task that takes 20 ms, or 0.025%. When the number of carrier threads is increased beyond the physical cores, it is a different story: java -Djdk.virtualThreadScheduler.parallelism=128 Main -- 4 1000000 189.07s user 11.25s system 522% cpu 38.345 total java -Djdk.virtualThreadScheduler.parallelism=128 Main -- 3 1000000 151.15s user 4.25s system 417% cpu 37.242 total and the flame graphs tell an interesting story. With the pooled thread executor, when a thread completes a task it checks if there is a ready task to grab before going to sleep (the two different fibonacci peaks and the different execution paths), but in the new thread per task model that is not an option, so instead, the fork-join carrier pool needs to wake up to look for a VT ready to run virtual thread (thus the much higher system time). In the first test above (parallelism default), there are so few carrier threads and 600 virtual threads, so there is almost always a VT ready to run, so the scheduler is not parking/waking. > On Jun 4, 2024, at 7:16 PM, Liam Miller-Cushon wrote: > > Yes, I think the Ryzen 3995WX has 64 real cores, 128 was with hyperthreading enabled. > > I don't have numbers from it yet (it isn't my machine), I'll get numbers with hyperthreading disabled and with your VirtualThreadExecutorService approach from [1] and report back. > > [1] https://mail.openjdk.org/pipermail/loom-dev/2024-May/006627.html > On Tue, Jun 4, 2024 at 4:35?PM Robert Engels > wrote: > I know I sent a bunch of replies, but did you by chance run the tests using the VirtualThreadExecutorService that doesn?t have the semaphore? > > But, more importantly, as I also pointed out, something seems way off in the timings. I don?t think the 128 core machine is actually 128 available cores - the timings are way too high. With this test you should get a nearly linear increase in performance as the number of carrier threads increase. The tests here aren?t even close. I am guessing these are virtual cores backed by their own scheduler on a shared VM. > > With virtual threads the number of carrier threads needs to match the real available cores or you will waste CPU with thrashing of the scheduler. > > >> On Jun 4, 2024, at 6:22 PM, Liam Miller-Cushon > wrote: >> >> Hi, >> >> Thanks for the comments. There's more to dig into here and to respond to, but I have a few notes for now. >> >> re: whether the question is about making this code faster or why case (2) scales weirdly, it's sort of both--we're interested in understanding (2) better, but if (2) is expected to be expensive compared to pushing back, that's helpful. >> >> To provide some more color on the real-world program that inspired the question, it's the Bazel build system (https://github.com/google/bazel ). Bazel constructs a graph of build 'actions', where each node is a command to run during the build (for example a call to javac that takes some source files and classpath jars as inputs, and produces class file outputs). The current approach uses a pool of physical threads to execute actions. Actions can block on IO, and especially on RPCs to remote machines that are performing build steps. The goal is to use virtual threads to make the actions async, and to replace the limit on the number of concurrent actions with a dynamic limit based on the availability of other resources (memory, and the number of in-flight RPCs to remote build machines). As a first step, Chi was trying to get a baseline where the virtual thread-based implementation used the same concurrency limit as the previous approach, ideally with roughly the same CPU overhead. >> >> I have more benchmarking results from the original machine using one of the approaches that was suggested, of limiting the number of in-flight virtual threads using a ThreadFactory with a semaphore. The new strategy (4) uses less CPU than strategy (2) where all of the virtual threads are started at the same time, but still uses more CPU than the thread pooling approach in (3). >> >> With strategy 4 as: >> >> ``` >> case 4 -> { >> var factorySem = new Semaphore(parallelism); >> ThreadFactory tf = (Runnable r) -> { >> try { >> factorySem.acquire(); >> } catch (InterruptedException ex) { >> throw new IllegalStateException("interrupted"); >> } >> return Thread.ofVirtual().unstarted(() -> >> { >> try { >> r.run(); >> } finally { >> factorySem.release(); >> } >> }); >> }; >> executor = Executors.newThreadPerTaskExecutor(tf); >> ``` >> >> The results are: >> >> # 128 CPUs >> >> Benchmark 1: java Main -- 1 10000 >> Time (mean ? ?): 719.7 ms ? 45.9 ms [User: 23732.3 ms, System: 1155.3 ms] >> Range (min ? max): 651.1 ms ? 794.0 ms 10 runs >> >> Benchmark 2: java Main -- 2 10000 >> Time (mean ? ?): 635.8 ms ? 66.9 ms [User: 21271.1 ms, System: 1685.1 ms] >> Range (min ? max): 565.5 ms ? 769.6 ms 10 runs >> >> Benchmark 3: java Main -- 3 10000 >> Time (mean ? ?): 486.2 ms ? 9.3 ms [User: 10804.0 ms, System: 1181.6 ms] >> Range (min ? max): 464.5 ms ? 495.1 ms 10 runs >> >> Benchmark 4: java Main -- 4 10000 >> Time (mean ? ?): 479.9 ms ? 3.7 ms [User: 8366.7 ms, System: 1201.9 ms] >> Range (min ? max): 474.8 ms ? 488.0 ms 10 runs >> >> Summary >> java Main -- 4 10000 ran >> 1.01 ? 0.02 times faster than java Main -- 3 10000 >> 1.32 ? 0.14 times faster than java Main -- 2 10000 >> 1.50 ? 0.10 times faster than java Main -- 1 10000 >> >> Benchmark 1: java Main -- 1 100000 >> Time (mean ? ?): 3.803 s ? 0.044 s [User: 41.227 s, System: 2.418 s] >> Range (min ? max): 3.737 s ? 3.874 s 10 runs >> >> Benchmark 2: java Main -- 2 100000 >> Time (mean ? ?): 3.761 s ? 0.063 s [User: 53.494 s, System: 3.380 s] >> Range (min ? max): 3.651 s ? 3.848 s 10 runs >> >> Benchmark 3: java Main -- 3 100000 >> Time (mean ? ?): 3.555 s ? 0.040 s [User: 20.824 s, System: 2.350 s] >> Range (min ? max): 3.529 s ? 3.667 s 10 runs >> >> Benchmark 4: java Main -- 4 100000 >> Time (mean ? ?): 3.558 s ? 0.011 s [User: 28.272 s, System: 3.018 s] >> Range (min ? max): 3.544 s ? 3.581 s 10 runs >> >> Summary >> java Main -- 3 100000 ran >> 1.00 ? 0.01 times faster than java Main -- 4 100000 >> 1.06 ? 0.02 times faster than java Main -- 2 100000 >> 1.07 ? 0.02 times faster than java Main -- 1 100000 >> >> Benchmark 1: java Main -- 1 1000000 >> Time (mean ? ?): 34.182 s ? 0.020 s [User: 165.208 s, System: 15.016 s] >> Range (min ? max): 34.148 s ? 34.205 s 10 runs >> >> Benchmark 2: java Main -- 2 1000000 >> Time (mean ? ?): 34.917 s ? 0.270 s [User: 335.774 s, System: 23.993 s] >> Range (min ? max): 34.575 s ? 35.457 s 10 runs >> >> Benchmark 3: java Main -- 3 1000000 >> Time (mean ? ?): 36.146 s ? 3.468 s [User: 163.926 s, System: 10.816 s] >> Range (min ? max): 34.209 s ? 45.588 s 10 runs >> >> Benchmark 4: java Main -- 4 1000000 >> Time (mean ? ?): 34.390 s ? 0.051 s [User: 216.980 s, System: 22.147 s] >> Range (min ? max): 34.303 s ? 34.446 s 10 runs >> >> Summary >> java Main -- 1 1000000 ran >> 1.01 ? 0.00 times faster than java Main -- 4 1000000 >> 1.02 ? 0.01 times faster than java Main -- 2 1000000 >> 1.06 ? 0.10 times faster than java Main -- 3 1000000 >> >> >> # 16 CPUs >> >> Benchmark 1: java Main -- 1 10000 >> Time (mean ? ?): 825.6 ms ? 50.6 ms [User: 6863.7 ms, System: 779.8 ms] >> Range (min ? max): 745.2 ms ? 936.4 ms 10 runs >> >> Benchmark 2: java Main -- 2 10000 >> Time (mean ? ?): 515.7 ms ? 8.4 ms [User: 4591.8 ms, System: 274.2 ms] >> Range (min ? max): 502.7 ms ? 532.9 ms 10 runs >> >> Benchmark 3: java Main -- 3 10000 >> Time (mean ? ?): 494.8 ms ? 34.9 ms [User: 3751.9 ms, System: 190.6 ms] >> Range (min ? max): 463.3 ms ? 580.0 ms 10 runs >> >> Benchmark 4: java Main -- 4 10000 >> Time (mean ? ?): 473.2 ms ? 7.5 ms [User: 3851.2 ms, System: 248.5 ms] >> Range (min ? max): 464.1 ms ? 483.3 ms 10 runs >> >> Summary >> >> java Main -- 4 10000 ran >> 1.05 ? 0.08 times faster than java Main -- 3 10000 >> 1.09 ? 0.02 times faster than java Main -- 2 10000 >> 1.74 ? 0.11 times faster than java Main -- 1 10000 >> >> Benchmark 1: java Main -- 1 100000 >> Time (mean ? ?): 3.949 s ? 0.099 s [User: 32.922 s, System: 2.386 s] >> Range (min ? max): 3.882 s ? 4.222 s 10 runs >> >> Benchmark 2: java Main -- 2 100000 >> Time (mean ? ?): 3.739 s ? 0.063 s [User: 31.259 s, System: 2.117 s] >> Range (min ? max): 3.661 s ? 3.832 s 10 runs >> >> Benchmark 3: java Main -- 3 100000 >> Time (mean ? ?): 5.106 s ? 0.990 s [User: 20.897 s, System: 0.686 s] >> Range (min ? max): 3.955 s ? 7.679 s 10 runs >> >> Benchmark 4: java Main -- 4 100000 >> Time (mean ? ?): 3.570 s ? 0.013 s [User: 27.292 s, System: 1.807 s] >> Range (min ? max): 3.557 s ? 3.594 s 10 runs >> >> Summary >> >> java Main -- 4 100000 ran >> 1.05 ? 0.02 times faster than java Main -- 2 100000 >> 1.11 ? 0.03 times faster than java Main -- 1 100000 >> 1.43 ? 0.28 times faster than java Main -- 3 100000 >> >> Benchmark 1: java Main -- 1 1000000 >> Time (mean ? ?): 34.536 s ? 0.076 s [User: 263.045 s, System: 16.227 s] >> Range (min ? max): 34.457 s ? 34.717 s 10 runs >> >> Benchmark 2: java Main -- 2 1000000 >> Time (mean ? ?): 35.257 s ? 0.191 s [User: 285.159 s, System: 19.702 s] >> Range (min ? max): 35.015 s ? 35.561 s 10 runs >> >> Benchmark 3: java Main -- 3 1000000 >> Time (mean ? ?): 60.157 s ? 10.130 s [User: 171.901 s, System: 3.902 s] >> Range (min ? max): 46.437 s ? 74.799 s 10 runs >> >> Benchmark 4: java Main -- 4 1000000 >> Time (mean ? ?): 34.370 s ? 0.067 s [User: 256.460 s, System: 19.605 s] >> Range (min ? max): 34.299 s ? 34.455 s 10 runs >> >> Summary >> java Main -- 4 1000000 ran >> 1.00 ? 0.00 times faster than java Main -- 1 1000000 >> 1.03 ? 0.01 times faster than java Main -- 2 1000000 >> 1.75 ? 0.29 times faster than java Main -- 3 1000000 >> >> On Thu, May 30, 2024 at 11:22?AM Ron Pressler > wrote: >> >> >> > On 28 May 2024, at 23:43, Liam Miller-Cushon > wrote: >> > >> > Hello, >> > >> > JEP 444 [1] and the docs in [2] mention that virtual threads should not be pooled, and suggest semaphores as one possible alternative. >> > >> > My colleague Chi Wang has been investigating virtual thread performance, and has found that creating one virtual thread per task and synchronizing on a semaphore can result in worse performance on machines with large numbers of cores. >> > >> > A benchmark run on a 128 core machine is included below. It submits numTasks tasks to the executor determined by the strategy. The task itself is mixed with CPU and I/O work (simulated by fibonacci and sleep). The parallelism is set to 600 for all strategies. >> > >> > * Strategy 1 is the baseline where it just submits all the tasks to a ForkJoinPool whose pool size is 600. >> > * Strategy 2 uses the method suggested by JEP 444. >> > * Strategy 3 uses a fixed thread pool of 600 backed by virtual threads. >> > >> > Note that, with 100K and 1M tasks, strategy 2 has a CPU time regression that seems to increase with the number of cores. This result can be reproduced on the real-world program that is being migrated to a virtual-thread-per-task model. >> > >> > Diffing the cpu profile between strategy 1 and strategy 2 showed that most of the CPU regression comes from method `java.util.concurrent.ForkJoinPool.scan(java.util.concurrent.ForkJoinPool$WorkQueue, long, int)`. >> > >> > Are there any ideas for why the semaphore strategy uses more CPU than pooling virtual threads on machines with a large number of cores? >> >> My first guess would be that what?s being compared here is not the same algorithm. In strategy 2, you spawn a bunch of different threads that do a tiny bit of work before starting the task, while in the other strategies the algorithm is different. >> >> In a realistic workload you will have a number of threads serving requests, and then they may want to access a concurrency-limited resource. I think you can try to simulate that by simulating, say, 1000 tasks running in some large thread pool and then each of them would submit one subtasks to a fixed thread pool of size 10. For virtual threads, have 1000 virtual threads that try to acquire a semaphore with 10 leases. >> >> Can you try that? At least then we?ll be comparing oranges to oranges. >> >> ? Ron > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PastedGraphic-2.tiff Type: image/tiff Size: 111674 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PastedGraphic-3.tiff Type: image/tiff Size: 121258 bytes Desc: not available URL: From ron.pressler at oracle.com Wed Jun 5 21:27:17 2024 From: ron.pressler at oracle.com (Ron Pressler) Date: Wed, 5 Jun 2024 21:27:17 +0000 Subject: [External] : Re: Performance of pooling virtual threads vs. semaphores In-Reply-To: References: Message-ID: I think we may be getting into the particulars of the scheduler?s implementation. Because the tasks are submitted to the executor from the main thread, in the thread-per-task case these would be N external submissions to the scheduler (where N is the total number of tasks), while in the pool case there are only P (parallelism) external submissions. External and internal submissions are treated differently by the scheduler, the former requiring a more active scan. The assumption of FJPool ? both in the computational parallel streams case and in the virtual threads case ? is that the interesting interactions and dependencies among the tasks mean that most submissions would be internal and would be handled more efficiently. If I understand the intended use-case correctly, you?re also aiming for such a graph with interesting interactions, but that is not what the microbenchmark is measuring. My recommendation, therefore, would be to try something more graph-like, with interesting dependencies among the tasks, and just use a semaphore somewhere ? not even necessarily in the thread factory. It is nearly impossible to extrapolate from such a microbenchmark to a use case that, from the perspective of the scheduler, has a very different behaviour. I would add that when it comes to concurrency and scheduling there are often big differences between microbenchmarks and the actual workload, and the algorithm can try to optimise to one class (things commonly done in microbenchmarks) or the other (more common real workloads), but unfortunately not both. So it?s always best to measure something that is as similar as possible to the actual workload and not risk extrapolations that may not be valid. ? Ron > On 5 Jun 2024, at 00:22, Liam Miller-Cushon wrote: > > Hi, > > Thanks for the comments. There's more to dig into here and to respond to, but I have a few notes for now. > > re: whether the question is about making this code faster or why case (2) scales weirdly, it's sort of both--we're interested in understanding (2) better, but if (2) is expected to be expensive compared to pushing back, that's helpful. > > To provide some more color on the real-world program that inspired the question, it's the Bazel build system (https://github.com/google/bazel). Bazel constructs a graph of build 'actions', where each node is a command to run during the build (for example a call to javac that takes some source files and classpath jars as inputs, and produces class file outputs). The current approach uses a pool of physical threads to execute actions. Actions can block on IO, and especially on RPCs to remote machines that are performing build steps. The goal is to use virtual threads to make the actions async, and to replace the limit on the number of concurrent actions with a dynamic limit based on the availability of other resources (memory, and the number of in-flight RPCs to remote build machines). As a first step, Chi was trying to get a baseline where the virtual thread-based implementation used the same concurrency limit as the previous approach, ideally with roughly the same CPU overhead. > > I have more benchmarking results from the original machine using one of the approaches that was suggested, of limiting the number of in-flight virtual threads using a ThreadFactory with a semaphore. The new strategy (4) uses less CPU than strategy (2) where all of the virtual threads are started at the same time, but still uses more CPU than the thread pooling approach in (3). > > With strategy 4 as: > > ``` > case 4 -> { > var factorySem = new Semaphore(parallelism); > ThreadFactory tf = (Runnable r) -> { > try { > factorySem.acquire(); > } catch (InterruptedException ex) { > throw new IllegalStateException("interrupted"); > } > return Thread.ofVirtual().unstarted(() -> > { > try { > r.run(); > } finally { > factorySem.release(); > } > }); > }; > executor = Executors.newThreadPerTaskExecutor(tf); > ``` > > The results are: > > # 128 CPUs > > Benchmark 1: java Main -- 1 10000 > Time (mean ? ?): 719.7 ms ? 45.9 ms [User: 23732.3 ms, System: 1155.3 ms] > Range (min ? max): 651.1 ms ? 794.0 ms 10 runs > > Benchmark 2: java Main -- 2 10000 > Time (mean ? ?): 635.8 ms ? 66.9 ms [User: 21271.1 ms, System: 1685.1 ms] > Range (min ? max): 565.5 ms ? 769.6 ms 10 runs > > Benchmark 3: java Main -- 3 10000 > Time (mean ? ?): 486.2 ms ? 9.3 ms [User: 10804.0 ms, System: 1181.6 ms] > Range (min ? max): 464.5 ms ? 495.1 ms 10 runs > > Benchmark 4: java Main -- 4 10000 > Time (mean ? ?): 479.9 ms ? 3.7 ms [User: 8366.7 ms, System: 1201.9 ms] > Range (min ? max): 474.8 ms ? 488.0 ms 10 runs > > Summary > java Main -- 4 10000 ran > 1.01 ? 0.02 times faster than java Main -- 3 10000 > 1.32 ? 0.14 times faster than java Main -- 2 10000 > 1.50 ? 0.10 times faster than java Main -- 1 10000 > > Benchmark 1: java Main -- 1 100000 > Time (mean ? ?): 3.803 s ? 0.044 s [User: 41.227 s, System: 2.418 s] > Range (min ? max): 3.737 s ? 3.874 s 10 runs > > Benchmark 2: java Main -- 2 100000 > Time (mean ? ?): 3.761 s ? 0.063 s [User: 53.494 s, System: 3.380 s] > Range (min ? max): 3.651 s ? 3.848 s 10 runs > > Benchmark 3: java Main -- 3 100000 > Time (mean ? ?): 3.555 s ? 0.040 s [User: 20.824 s, System: 2.350 s] > Range (min ? max): 3.529 s ? 3.667 s 10 runs > > Benchmark 4: java Main -- 4 100000 > Time (mean ? ?): 3.558 s ? 0.011 s [User: 28.272 s, System: 3.018 s] > Range (min ? max): 3.544 s ? 3.581 s 10 runs > > Summary > java Main -- 3 100000 ran > 1.00 ? 0.01 times faster than java Main -- 4 100000 > 1.06 ? 0.02 times faster than java Main -- 2 100000 > 1.07 ? 0.02 times faster than java Main -- 1 100000 > > Benchmark 1: java Main -- 1 1000000 > Time (mean ? ?): 34.182 s ? 0.020 s [User: 165.208 s, System: 15.016 s] > Range (min ? max): 34.148 s ? 34.205 s 10 runs > > Benchmark 2: java Main -- 2 1000000 > Time (mean ? ?): 34.917 s ? 0.270 s [User: 335.774 s, System: 23.993 s] > Range (min ? max): 34.575 s ? 35.457 s 10 runs > > Benchmark 3: java Main -- 3 1000000 > Time (mean ? ?): 36.146 s ? 3.468 s [User: 163.926 s, System: 10.816 s] > Range (min ? max): 34.209 s ? 45.588 s 10 runs > > Benchmark 4: java Main -- 4 1000000 > Time (mean ? ?): 34.390 s ? 0.051 s [User: 216.980 s, System: 22.147 s] > Range (min ? max): 34.303 s ? 34.446 s 10 runs > > Summary > java Main -- 1 1000000 ran > 1.01 ? 0.00 times faster than java Main -- 4 1000000 > 1.02 ? 0.01 times faster than java Main -- 2 1000000 > 1.06 ? 0.10 times faster than java Main -- 3 1000000 > > > # 16 CPUs > > Benchmark 1: java Main -- 1 10000 > Time (mean ? ?): 825.6 ms ? 50.6 ms [User: 6863.7 ms, System: 779.8 ms] > Range (min ? max): 745.2 ms ? 936.4 ms 10 runs > > Benchmark 2: java Main -- 2 10000 > Time (mean ? ?): 515.7 ms ? 8.4 ms [User: 4591.8 ms, System: 274.2 ms] > Range (min ? max): 502.7 ms ? 532.9 ms 10 runs > > Benchmark 3: java Main -- 3 10000 > Time (mean ? ?): 494.8 ms ? 34.9 ms [User: 3751.9 ms, System: 190.6 ms] > Range (min ? max): 463.3 ms ? 580.0 ms 10 runs > > Benchmark 4: java Main -- 4 10000 > Time (mean ? ?): 473.2 ms ? 7.5 ms [User: 3851.2 ms, System: 248.5 ms] > Range (min ? max): 464.1 ms ? 483.3 ms 10 runs > > Summary > > java Main -- 4 10000 ran > 1.05 ? 0.08 times faster than java Main -- 3 10000 > 1.09 ? 0.02 times faster than java Main -- 2 10000 > 1.74 ? 0.11 times faster than java Main -- 1 10000 > > Benchmark 1: java Main -- 1 100000 > Time (mean ? ?): 3.949 s ? 0.099 s [User: 32.922 s, System: 2.386 s] > Range (min ? max): 3.882 s ? 4.222 s 10 runs > > Benchmark 2: java Main -- 2 100000 > Time (mean ? ?): 3.739 s ? 0.063 s [User: 31.259 s, System: 2.117 s] > Range (min ? max): 3.661 s ? 3.832 s 10 runs > > Benchmark 3: java Main -- 3 100000 > Time (mean ? ?): 5.106 s ? 0.990 s [User: 20.897 s, System: 0.686 s] > Range (min ? max): 3.955 s ? 7.679 s 10 runs > > Benchmark 4: java Main -- 4 100000 > Time (mean ? ?): 3.570 s ? 0.013 s [User: 27.292 s, System: 1.807 s] > Range (min ? max): 3.557 s ? 3.594 s 10 runs > > Summary > > java Main -- 4 100000 ran > 1.05 ? 0.02 times faster than java Main -- 2 100000 > 1.11 ? 0.03 times faster than java Main -- 1 100000 > 1.43 ? 0.28 times faster than java Main -- 3 100000 > > Benchmark 1: java Main -- 1 1000000 > Time (mean ? ?): 34.536 s ? 0.076 s [User: 263.045 s, System: 16.227 s] > Range (min ? max): 34.457 s ? 34.717 s 10 runs > > Benchmark 2: java Main -- 2 1000000 > Time (mean ? ?): 35.257 s ? 0.191 s [User: 285.159 s, System: 19.702 s] > Range (min ? max): 35.015 s ? 35.561 s 10 runs > > Benchmark 3: java Main -- 3 1000000 > Time (mean ? ?): 60.157 s ? 10.130 s [User: 171.901 s, System: 3.902 s] > Range (min ? max): 46.437 s ? 74.799 s 10 runs > > Benchmark 4: java Main -- 4 1000000 > Time (mean ? ?): 34.370 s ? 0.067 s [User: 256.460 s, System: 19.605 s] > Range (min ? max): 34.299 s ? 34.455 s 10 runs > > Summary > java Main -- 4 1000000 ran > 1.00 ? 0.00 times faster than java Main -- 1 1000000 > 1.03 ? 0.01 times faster than java Main -- 2 1000000 > 1.75 ? 0.29 times faster than java Main -- 3 1000000 > > On Thu, May 30, 2024 at 11:22?AM Ron Pressler wrote: > > > > On 28 May 2024, at 23:43, Liam Miller-Cushon wrote: > > > > Hello, > > > > JEP 444 [1] and the docs in [2] mention that virtual threads should not be pooled, and suggest semaphores as one possible alternative. > > > > My colleague Chi Wang has been investigating virtual thread performance, and has found that creating one virtual thread per task and synchronizing on a semaphore can result in worse performance on machines with large numbers of cores. > > > > A benchmark run on a 128 core machine is included below. It submits numTasks tasks to the executor determined by the strategy. The task itself is mixed with CPU and I/O work (simulated by fibonacci and sleep). The parallelism is set to 600 for all strategies. > > > > * Strategy 1 is the baseline where it just submits all the tasks to a ForkJoinPool whose pool size is 600. > > * Strategy 2 uses the method suggested by JEP 444. > > * Strategy 3 uses a fixed thread pool of 600 backed by virtual threads. > > > > Note that, with 100K and 1M tasks, strategy 2 has a CPU time regression that seems to increase with the number of cores. This result can be reproduced on the real-world program that is being migrated to a virtual-thread-per-task model. > > > > Diffing the cpu profile between strategy 1 and strategy 2 showed that most of the CPU regression comes from method `java.util.concurrent.ForkJoinPool.scan(java.util.concurrent.ForkJoinPool$WorkQueue, long, int)`. > > > > Are there any ideas for why the semaphore strategy uses more CPU than pooling virtual threads on machines with a large number of cores? > > My first guess would be that what?s being compared here is not the same algorithm. In strategy 2, you spawn a bunch of different threads that do a tiny bit of work before starting the task, while in the other strategies the algorithm is different. > > In a realistic workload you will have a number of threads serving requests, and then they may want to access a concurrency-limited resource. I think you can try to simulate that by simulating, say, 1000 tasks running in some large thread pool and then each of them would submit one subtasks to a fixed thread pool of size 10. For virtual threads, have 1000 virtual threads that try to acquire a semaphore with 10 leases. > > Can you try that? At least then we?ll be comparing oranges to oranges. > > ? Ron From marcin.grzejszczak at gmail.com Wed Jun 5 21:31:05 2024 From: marcin.grzejszczak at gmail.com (Marcin Grzejszczak) Date: Wed, 5 Jun 2024 22:31:05 +0100 Subject: ScopedValue.runWhere not returning scope Message-ID: Hi, I apologize if this is not a proper place to ask this question, in which case please point me where to the place where I should ask it. Also I apologize if I sent this email twice cause I had some bizarre issues with my mailbox. I'm Marcin and I'm co-maintaining the Micrometer project [1] part of which is the Micrometer Observation API with which we are instrumenting libraries also in the domain of distributed tracing. What happens there is that when a scope is opened for a span [2], thread local entries are set, e.g. MDC has a correlation identifier attached (called trace id) and once the scope is closed, the MDC gets cleared [3]. The span API allows you to achieve this by opening a scope (e.g. pseudocode: `Scope scope = span.openScope()`) and later on you close the scope with `scope.close()`. This kind of code is often called within frameworks that give you some sort of a handler / listener mechanism [4] that is being called around actual user code invocation (you have methods like e.g. `before(...)`, `after(...)`). The current ScopedValue API doesn't allow that. Let me show that using the following example: Let's say that we have an interface called a Handler ``` interface Handler { /** * Called before actual method execution * @param map mutable map to pass between methods */ void before(Map map); /** * Called after actual method execution * @param exception potential exception - can be null * @param map mutable map to pass between methods */ void after(Exception exception, Map map) throws Exception; } ``` Then let's say that we have a "Proxy" class that wraps the user code execution with the Handler ``` class Proxy { private final Handler handler; Proxy(Handler handler) { this.handler = handler; } void run(Runnable runnable) throws Exception { Map map = new HashMap<>(); Exception exception = null; handler.before(map); try { runnable.run(); } catch (Exception ex) { exception = ex; throw ex; } finally { handler.after(exception, map); } } } ``` Then we have an implementation that uses ThreadLocal and a "scope" in a form of Closeable that will be opened in "before" and closed in "after". This is a simplification of the distributed tracing case. ``` class ThreadLocalValueHandler implements Handler { static final ThreadLocal threadLocal = new ThreadLocal<>(); @Override public void before(Map map) { threadLocal.set("foo"); // simulates setting span in scope Closeable scope = threadLocal::remove; // simulates setting of span in scope map.put("scope", scope); } @Override public void after(Exception exception, Map map) throws Exception { Closeable scope = (Closeable) map.get("scope"); scope.close(); // simulates closing the span scope } } ``` Now when we run it together we could get sth like this ``` public static void main(String[] args) throws Exception { new Proxy(new ThreadLocalValueHandler()).run(() -> { System.out.println("HELLO [" + ThreadLocalValueHandler.threadLocal.get() + "]"); }); System.out.println("Goodbye [" + ThreadLocalValueHandler.threadLocal.get() + "]"); } ``` And the output would be ``` HELLO [foo] Goodbye [null] ``` I am wondering what if I don't want to use a ThreadLocal but ScopeValue? Is it the tool to solve this problem? Current API allows me to run a lambda within a scope through `ScopedValue.runWhere(scopedValue, "foo", () -> {})`. But what if I wanted to separate this into 2 steps, the scope opening and closing? There is the `StructuredTaskScope` but I have trouble understanding how that could be used for that matter. Thank you. [1] - https://micrometer.io/ [2] - https://github.com/openzipkin/brave/blob/6.0.3/brave/src/main/java/brave/Tracer.java#L395-L403 [3] - https://github.com/openzipkin/brave/blob/6.0.3/context/slf4j/src/main/java/brave/context/slf4j/MDCScopeDecorator.java#L61-L74 [4] - https://github.com/micrometer-metrics/micrometer/blob/v1.13.0/micrometer-observation/src/main/java/io/micrometer/observation/ObservationHandler.java#L59-L71 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rengels at ix.netcom.com Wed Jun 5 21:58:20 2024 From: rengels at ix.netcom.com (robert engels) Date: Wed, 5 Jun 2024 16:58:20 -0500 Subject: [External] : Re: Performance of pooling virtual threads vs. semaphores In-Reply-To: References: Message-ID: <2F3CF9FB-AB62-4EFD-A4C0-CF489F905873@ix.netcom.com> Hi Ron, When you say "most submissions would be internal? is that under the assumption that in a thread per request model, the number of times the thread ?blocks? would X for each request, meaning there would be N*X internal submissions for every N requests. So if you had requests with a low number of blocks (context switches) then pooling the virtual threads would be better? > On Jun 5, 2024, at 4:27 PM, Ron Pressler wrote: > > I think we may be getting into the particulars of the scheduler?s implementation. > Because the tasks are submitted to the executor from the main thread, in the thread-per-task case these would be N external submissions to the scheduler (where N is the total number of tasks), while in the pool case there are only P (parallelism) external submissions. External and internal submissions are treated differently by the scheduler, the former requiring a more active scan. > > The assumption of FJPool ? both in the computational parallel streams case and in the virtual threads case ? is that the interesting interactions and dependencies among the tasks mean that most submissions would be internal and would be handled more efficiently. > > If I understand the intended use-case correctly, you?re also aiming for such a graph with interesting interactions, but that is not what the microbenchmark is measuring. My recommendation, therefore, would be to try something more graph-like, with interesting dependencies among the tasks, and just use a semaphore somewhere ? not even necessarily in the thread factory. It is nearly impossible to extrapolate from such a microbenchmark to a use case that, from the perspective of the scheduler, has a very different behaviour. > > I would add that when it comes to concurrency and scheduling there are often big differences between microbenchmarks and the actual workload, and the algorithm can try to optimise to one class (things commonly done in microbenchmarks) or the other (more common real workloads), but unfortunately not both. So it?s always best to measure something that is as similar as possible to the actual workload and not risk extrapolations that may not be valid. > > ? Ron > >> On 5 Jun 2024, at 00:22, Liam Miller-Cushon wrote: >> >> Hi, >> >> Thanks for the comments. There's more to dig into here and to respond to, but I have a few notes for now. >> >> re: whether the question is about making this code faster or why case (2) scales weirdly, it's sort of both--we're interested in understanding (2) better, but if (2) is expected to be expensive compared to pushing back, that's helpful. >> >> To provide some more color on the real-world program that inspired the question, it's the Bazel build system (https://github.com/google/bazel). Bazel constructs a graph of build 'actions', where each node is a command to run during the build (for example a call to javac that takes some source files and classpath jars as inputs, and produces class file outputs). The current approach uses a pool of physical threads to execute actions. Actions can block on IO, and especially on RPCs to remote machines that are performing build steps. The goal is to use virtual threads to make the actions async, and to replace the limit on the number of concurrent actions with a dynamic limit based on the availability of other resources (memory, and the number of in-flight RPCs to remote build machines). As a first step, Chi was trying to get a baseline where the virtual thread-based implementation used the same concurrency limit as the previous approach, ideally with roughly the same CPU overhead. >> >> I have more benchmarking results from the original machine using one of the approaches that was suggested, of limiting the number of in-flight virtual threads using a ThreadFactory with a semaphore. The new strategy (4) uses less CPU than strategy (2) where all of the virtual threads are started at the same time, but still uses more CPU than the thread pooling approach in (3). >> >> With strategy 4 as: >> >> ``` >> case 4 -> { >> var factorySem = new Semaphore(parallelism); >> ThreadFactory tf = (Runnable r) -> { >> try { >> factorySem.acquire(); >> } catch (InterruptedException ex) { >> throw new IllegalStateException("interrupted"); >> } >> return Thread.ofVirtual().unstarted(() -> >> { >> try { >> r.run(); >> } finally { >> factorySem.release(); >> } >> }); >> }; >> executor = Executors.newThreadPerTaskExecutor(tf); >> ``` >> >> The results are: >> >> # 128 CPUs >> >> Benchmark 1: java Main -- 1 10000 >> Time (mean ? ?): 719.7 ms ? 45.9 ms [User: 23732.3 ms, System: 1155.3 ms] >> Range (min ? max): 651.1 ms ? 794.0 ms 10 runs >> >> Benchmark 2: java Main -- 2 10000 >> Time (mean ? ?): 635.8 ms ? 66.9 ms [User: 21271.1 ms, System: 1685.1 ms] >> Range (min ? max): 565.5 ms ? 769.6 ms 10 runs >> >> Benchmark 3: java Main -- 3 10000 >> Time (mean ? ?): 486.2 ms ? 9.3 ms [User: 10804.0 ms, System: 1181.6 ms] >> Range (min ? max): 464.5 ms ? 495.1 ms 10 runs >> >> Benchmark 4: java Main -- 4 10000 >> Time (mean ? ?): 479.9 ms ? 3.7 ms [User: 8366.7 ms, System: 1201.9 ms] >> Range (min ? max): 474.8 ms ? 488.0 ms 10 runs >> >> Summary >> java Main -- 4 10000 ran >> 1.01 ? 0.02 times faster than java Main -- 3 10000 >> 1.32 ? 0.14 times faster than java Main -- 2 10000 >> 1.50 ? 0.10 times faster than java Main -- 1 10000 >> >> Benchmark 1: java Main -- 1 100000 >> Time (mean ? ?): 3.803 s ? 0.044 s [User: 41.227 s, System: 2.418 s] >> Range (min ? max): 3.737 s ? 3.874 s 10 runs >> >> Benchmark 2: java Main -- 2 100000 >> Time (mean ? ?): 3.761 s ? 0.063 s [User: 53.494 s, System: 3.380 s] >> Range (min ? max): 3.651 s ? 3.848 s 10 runs >> >> Benchmark 3: java Main -- 3 100000 >> Time (mean ? ?): 3.555 s ? 0.040 s [User: 20.824 s, System: 2.350 s] >> Range (min ? max): 3.529 s ? 3.667 s 10 runs >> >> Benchmark 4: java Main -- 4 100000 >> Time (mean ? ?): 3.558 s ? 0.011 s [User: 28.272 s, System: 3.018 s] >> Range (min ? max): 3.544 s ? 3.581 s 10 runs >> >> Summary >> java Main -- 3 100000 ran >> 1.00 ? 0.01 times faster than java Main -- 4 100000 >> 1.06 ? 0.02 times faster than java Main -- 2 100000 >> 1.07 ? 0.02 times faster than java Main -- 1 100000 >> >> Benchmark 1: java Main -- 1 1000000 >> Time (mean ? ?): 34.182 s ? 0.020 s [User: 165.208 s, System: 15.016 s] >> Range (min ? max): 34.148 s ? 34.205 s 10 runs >> >> Benchmark 2: java Main -- 2 1000000 >> Time (mean ? ?): 34.917 s ? 0.270 s [User: 335.774 s, System: 23.993 s] >> Range (min ? max): 34.575 s ? 35.457 s 10 runs >> >> Benchmark 3: java Main -- 3 1000000 >> Time (mean ? ?): 36.146 s ? 3.468 s [User: 163.926 s, System: 10.816 s] >> Range (min ? max): 34.209 s ? 45.588 s 10 runs >> >> Benchmark 4: java Main -- 4 1000000 >> Time (mean ? ?): 34.390 s ? 0.051 s [User: 216.980 s, System: 22.147 s] >> Range (min ? max): 34.303 s ? 34.446 s 10 runs >> >> Summary >> java Main -- 1 1000000 ran >> 1.01 ? 0.00 times faster than java Main -- 4 1000000 >> 1.02 ? 0.01 times faster than java Main -- 2 1000000 >> 1.06 ? 0.10 times faster than java Main -- 3 1000000 >> >> >> # 16 CPUs >> >> Benchmark 1: java Main -- 1 10000 >> Time (mean ? ?): 825.6 ms ? 50.6 ms [User: 6863.7 ms, System: 779.8 ms] >> Range (min ? max): 745.2 ms ? 936.4 ms 10 runs >> >> Benchmark 2: java Main -- 2 10000 >> Time (mean ? ?): 515.7 ms ? 8.4 ms [User: 4591.8 ms, System: 274.2 ms] >> Range (min ? max): 502.7 ms ? 532.9 ms 10 runs >> >> Benchmark 3: java Main -- 3 10000 >> Time (mean ? ?): 494.8 ms ? 34.9 ms [User: 3751.9 ms, System: 190.6 ms] >> Range (min ? max): 463.3 ms ? 580.0 ms 10 runs >> >> Benchmark 4: java Main -- 4 10000 >> Time (mean ? ?): 473.2 ms ? 7.5 ms [User: 3851.2 ms, System: 248.5 ms] >> Range (min ? max): 464.1 ms ? 483.3 ms 10 runs >> >> Summary >> >> java Main -- 4 10000 ran >> 1.05 ? 0.08 times faster than java Main -- 3 10000 >> 1.09 ? 0.02 times faster than java Main -- 2 10000 >> 1.74 ? 0.11 times faster than java Main -- 1 10000 >> >> Benchmark 1: java Main -- 1 100000 >> Time (mean ? ?): 3.949 s ? 0.099 s [User: 32.922 s, System: 2.386 s] >> Range (min ? max): 3.882 s ? 4.222 s 10 runs >> >> Benchmark 2: java Main -- 2 100000 >> Time (mean ? ?): 3.739 s ? 0.063 s [User: 31.259 s, System: 2.117 s] >> Range (min ? max): 3.661 s ? 3.832 s 10 runs >> >> Benchmark 3: java Main -- 3 100000 >> Time (mean ? ?): 5.106 s ? 0.990 s [User: 20.897 s, System: 0.686 s] >> Range (min ? max): 3.955 s ? 7.679 s 10 runs >> >> Benchmark 4: java Main -- 4 100000 >> Time (mean ? ?): 3.570 s ? 0.013 s [User: 27.292 s, System: 1.807 s] >> Range (min ? max): 3.557 s ? 3.594 s 10 runs >> >> Summary >> >> java Main -- 4 100000 ran >> 1.05 ? 0.02 times faster than java Main -- 2 100000 >> 1.11 ? 0.03 times faster than java Main -- 1 100000 >> 1.43 ? 0.28 times faster than java Main -- 3 100000 >> >> Benchmark 1: java Main -- 1 1000000 >> Time (mean ? ?): 34.536 s ? 0.076 s [User: 263.045 s, System: 16.227 s] >> Range (min ? max): 34.457 s ? 34.717 s 10 runs >> >> Benchmark 2: java Main -- 2 1000000 >> Time (mean ? ?): 35.257 s ? 0.191 s [User: 285.159 s, System: 19.702 s] >> Range (min ? max): 35.015 s ? 35.561 s 10 runs >> >> Benchmark 3: java Main -- 3 1000000 >> Time (mean ? ?): 60.157 s ? 10.130 s [User: 171.901 s, System: 3.902 s] >> Range (min ? max): 46.437 s ? 74.799 s 10 runs >> >> Benchmark 4: java Main -- 4 1000000 >> Time (mean ? ?): 34.370 s ? 0.067 s [User: 256.460 s, System: 19.605 s] >> Range (min ? max): 34.299 s ? 34.455 s 10 runs >> >> Summary >> java Main -- 4 1000000 ran >> 1.00 ? 0.00 times faster than java Main -- 1 1000000 >> 1.03 ? 0.01 times faster than java Main -- 2 1000000 >> 1.75 ? 0.29 times faster than java Main -- 3 1000000 >> >> On Thu, May 30, 2024 at 11:22?AM Ron Pressler wrote: >> >> >>> On 28 May 2024, at 23:43, Liam Miller-Cushon wrote: >>> >>> Hello, >>> >>> JEP 444 [1] and the docs in [2] mention that virtual threads should not be pooled, and suggest semaphores as one possible alternative. >>> >>> My colleague Chi Wang has been investigating virtual thread performance, and has found that creating one virtual thread per task and synchronizing on a semaphore can result in worse performance on machines with large numbers of cores. >>> >>> A benchmark run on a 128 core machine is included below. It submits numTasks tasks to the executor determined by the strategy. The task itself is mixed with CPU and I/O work (simulated by fibonacci and sleep). The parallelism is set to 600 for all strategies. >>> >>> * Strategy 1 is the baseline where it just submits all the tasks to a ForkJoinPool whose pool size is 600. >>> * Strategy 2 uses the method suggested by JEP 444. >>> * Strategy 3 uses a fixed thread pool of 600 backed by virtual threads. >>> >>> Note that, with 100K and 1M tasks, strategy 2 has a CPU time regression that seems to increase with the number of cores. This result can be reproduced on the real-world program that is being migrated to a virtual-thread-per-task model. >>> >>> Diffing the cpu profile between strategy 1 and strategy 2 showed that most of the CPU regression comes from method `java.util.concurrent.ForkJoinPool.scan(java.util.concurrent.ForkJoinPool$WorkQueue, long, int)`. >>> >>> Are there any ideas for why the semaphore strategy uses more CPU than pooling virtual threads on machines with a large number of cores? >> >> My first guess would be that what?s being compared here is not the same algorithm. In strategy 2, you spawn a bunch of different threads that do a tiny bit of work before starting the task, while in the other strategies the algorithm is different. >> >> In a realistic workload you will have a number of threads serving requests, and then they may want to access a concurrency-limited resource. I think you can try to simulate that by simulating, say, 1000 tasks running in some large thread pool and then each of them would submit one subtasks to a fixed thread pool of size 10. For virtual threads, have 1000 virtual threads that try to acquire a semaphore with 10 leases. >> >> Can you try that? At least then we?ll be comparing oranges to oranges. >> >> ? Ron > From ron.pressler at oracle.com Thu Jun 6 01:02:35 2024 From: ron.pressler at oracle.com (Ron Pressler) Date: Thu, 6 Jun 2024 01:02:35 +0000 Subject: [External] : Re: Performance of pooling virtual threads vs. semaphores In-Reply-To: <2F3CF9FB-AB62-4EFD-A4C0-CF489F905873@ix.netcom.com> References: <2F3CF9FB-AB62-4EFD-A4C0-CF489F905873@ix.netcom.com> Message-ID: > On 5 Jun 2024, at 22:58, robert engels wrote: > > Hi Ron, > > When you say "most submissions would be internal? is that under the assumption that in a thread per request model, the number of times the thread ?blocks? would X for each request, meaning there would be N*X internal submissions for every N requests. > > So if you had requests with a low number of blocks (context switches) then pooling the virtual threads would be better? > No, virtual threads should never be pooled. I can?t even know if external submissions play a role in the behaviour difference here, only this microbenchmark doesn?t resemble the intended realistic workload in that regard and it?s very hard to extrapolate from microbenchmarks. If this aspect does cause a significant difference, then if that patterns happens to be common in realistic workloads, then we?ll have a reason to properly profile them and then change the scheduling algorithm accordingly. In any event, you should never write less idiomatic code to exploit an accidental and undocumented ? and therefore quite possibly a temporary one. Idiomatic code is always more likely to be the target of future improvement, and unidiomatic code is more likely to suffer because it?s less likely to be profiled and optimised. From time to time we see some strange code that?s causing an issue and we ask the authors why they wrote code like that and they say that it?s to enjoy some benefit due to some undocumented implementation detail of the runtime?s, only that implementation changed three years ago... ? Ron From rengels at ix.netcom.com Thu Jun 6 01:27:47 2024 From: rengels at ix.netcom.com (robert engels) Date: Wed, 5 Jun 2024 20:27:47 -0500 Subject: [External] : Re: Performance of pooling virtual threads vs. semaphores In-Reply-To: References: <2F3CF9FB-AB62-4EFD-A4C0-CF489F905873@ix.netcom.com> Message-ID: <11711A18-C0B6-4F0C-ADB5-5B50E74D28AB@ix.netcom.com> Totally agree, but then I guess I don?t understand how ?most submissions would be internal? holds. It seems there is an unstated expectation of the workloads used with virtual threads. It may be as simple as ?use virtual threads when your workload looks this??, ?use pooled virtual threads when your workload looks like this??, use ?platform threads??, etc. I?m not saying anything needs to change, only that I think more clarity on these dynamics would help. And it is totally ok to say ?for now??. Just my two cents. > On Jun 5, 2024, at 8:02 PM, Ron Pressler wrote: > > > >> On 5 Jun 2024, at 22:58, robert engels wrote: >> >> Hi Ron, >> >> When you say "most submissions would be internal? is that under the assumption that in a thread per request model, the number of times the thread ?blocks? would X for each request, meaning there would be N*X internal submissions for every N requests. >> >> So if you had requests with a low number of blocks (context switches) then pooling the virtual threads would be better? >> > > No, virtual threads should never be pooled. > > I can?t even know if external submissions play a role in the behaviour difference here, only this microbenchmark doesn?t resemble the intended realistic workload in that regard and it?s very hard to extrapolate from microbenchmarks. > > If this aspect does cause a significant difference, then if that patterns happens to be common in realistic workloads, then we?ll have a reason to properly profile them and then change the scheduling algorithm accordingly. In any event, you should never write less idiomatic code to exploit an accidental and undocumented ? and therefore quite possibly a temporary one. > > Idiomatic code is always more likely to be the target of future improvement, and unidiomatic code is more likely to suffer because it?s less likely to be profiled and optimised. From time to time we see some strange code that?s causing an issue and we ask the authors why they wrote code like that and they say that it?s to enjoy some benefit due to some undocumented implementation detail of the runtime?s, only that implementation changed three years ago... > > ? Ron > > > From rengels at ix.netcom.com Thu Jun 6 01:30:16 2024 From: rengels at ix.netcom.com (robert engels) Date: Wed, 5 Jun 2024 20:30:16 -0500 Subject: [External] : Re: Performance of pooling virtual threads vs. semaphores In-Reply-To: <11711A18-C0B6-4F0C-ADB5-5B50E74D28AB@ix.netcom.com> References: <2F3CF9FB-AB62-4EFD-A4C0-CF489F905873@ix.netcom.com> <11711A18-C0B6-4F0C-ADB5-5B50E74D28AB@ix.netcom.com> Message-ID: (Sorry, I know you just said ?never use pool vt?? I meant it as a possibility in the face of new information, review, etc.). > On Jun 5, 2024, at 8:27 PM, robert engels wrote: > > Totally agree, but then I guess I don?t understand how ?most submissions would be internal? holds. It seems there is an unstated expectation of the workloads used with virtual threads. It may be as simple as ?use virtual threads when your workload looks this??, ?use pooled virtual threads when your workload looks like this??, use ?platform threads??, etc. > > I?m not saying anything needs to change, only that I think more clarity on these dynamics would help. And it is totally ok to say ?for now??. > > Just my two cents. > > >> On Jun 5, 2024, at 8:02 PM, Ron Pressler wrote: >> >> >> >>> On 5 Jun 2024, at 22:58, robert engels wrote: >>> >>> Hi Ron, >>> >>> When you say "most submissions would be internal? is that under the assumption that in a thread per request model, the number of times the thread ?blocks? would X for each request, meaning there would be N*X internal submissions for every N requests. >>> >>> So if you had requests with a low number of blocks (context switches) then pooling the virtual threads would be better? >>> >> >> No, virtual threads should never be pooled. >> >> I can?t even know if external submissions play a role in the behaviour difference here, only this microbenchmark doesn?t resemble the intended realistic workload in that regard and it?s very hard to extrapolate from microbenchmarks. >> >> If this aspect does cause a significant difference, then if that patterns happens to be common in realistic workloads, then we?ll have a reason to properly profile them and then change the scheduling algorithm accordingly. In any event, you should never write less idiomatic code to exploit an accidental and undocumented ? and therefore quite possibly a temporary one. >> >> Idiomatic code is always more likely to be the target of future improvement, and unidiomatic code is more likely to suffer because it?s less likely to be profiled and optimised. From time to time we see some strange code that?s causing an issue and we ask the authors why they wrote code like that and they say that it?s to enjoy some benefit due to some undocumented implementation detail of the runtime?s, only that implementation changed three years ago... >> >> ? Ron >> >> >> > From aph-open at littlepinkcloud.com Thu Jun 6 08:16:46 2024 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Thu, 6 Jun 2024 09:16:46 +0100 Subject: ScopedValue.runWhere not returning scope In-Reply-To: References: Message-ID: <03b69bde-3f90-428c-aa94-b147a8a18819@littlepinkcloud.com> On 6/5/24 22:31, Marcin Grzejszczak wrote: > I am wondering what if I don't want to use a ThreadLocal but > ScopeValue? Is it the tool to solve this problem? Current API allows > me to run a lambda within a scope through > `ScopedValue.runWhere(scopedValue, "foo", () -> {})`. But what if I > wanted to separate this into 2 steps, the scope opening and closing? The structured nature of a scoped value is a part of its essential design. It is the main difference between scoped values and thread-local variables. If you consider an execution of a program as a downwards-growing stack, a scoped value is bound to some value at one point in the stack, and the bound value is visible to all frames below that point. That is all: there's no need to consider scopes opening and closing. It's true that this decision makes scoped values less versatile than thread-local variables, but on the other hand the hard guarantees it provides make programs easier to reason about. On balance, we consider the latter more important than the former. We did consider (and even implement) an API with open() and close() methods, but we discarded it in order to make the use you describe impossible. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From duke at openjdk.org Thu Jun 6 10:59:36 2024 From: duke at openjdk.org (duke) Date: Thu, 6 Jun 2024 10:59:36 GMT Subject: git: openjdk/loom: fibers: 28 new changesets Message-ID: <56b29b3f-04c7-460e-a021-38b8419e0f79@openjdk.org> Changeset: cbb6747e Author: Sonia Zaldana Calles Committer: Jaikiran Pai Date: 2024-06-05 13:12:30 +0000 URL: https://git.openjdk.org/loom/commit/cbb6747e6b9ce7e2b9e0ffb0a1f9499f7e0e13b0 8329581: Java launcher no longer prints a stack trace 8329420: Java 22 (and 23) launcher calls default constructor although main() is static 8330864: No error message when ExceptionInInitializerError thrown in static initializer Reviewed-by: stuefe ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/java.base/share/native/libjli/java.c ! test/jdk/tools/launcher/InstanceMainTest.java + test/jdk/tools/launcher/LauncherExceptionTest.java Changeset: 6882b381 Author: Jaikiran Pai Date: 2024-06-05 14:03:29 +0000 URL: https://git.openjdk.org/loom/commit/6882b381e8662b5c134d3a1868c357eeb3523ea8 8333590: UnmodifiableHeaders.toString() returns a value that represents empty headers Reviewed-by: dfuchs, michaelm ! src/jdk.httpserver/share/classes/sun/net/httpserver/UnmodifiableHeaders.java ! test/jdk/com/sun/net/httpserver/UnmodifiableHeadersTest.java Changeset: 9a8096fe Author: Sonia Zaldana Calles Committer: Thomas Stuefe Date: 2024-06-05 14:14:14 +0000 URL: https://git.openjdk.org/loom/commit/9a8096feb82991784cabede823f0248fe2f41e53 8330047: ASAN build error with gcc 13 Reviewed-by: aboldtch, stuefe ! src/hotspot/share/gc/z/zMarkStack.hpp Changeset: 326dbb1b Author: Viktor Klang Date: 2024-06-05 14:40:04 +0000 URL: https://git.openjdk.org/loom/commit/326dbb1b139dd1ec1b8605339b91697cdf49da9a 8312436: CompletableFuture never completes when 'Throwable.toString()' method throws Exception Reviewed-by: alanb ! src/java.base/share/classes/java/util/concurrent/CompletableFuture.java ! test/jdk/java/util/concurrent/tck/CompletableFutureTest.java Changeset: d85b0ca5 Author: Adam Sotona Date: 2024-06-05 15:33:03 +0000 URL: https://git.openjdk.org/loom/commit/d85b0ca5cdc1820a886c46bf555b2051fed7f167 8332457: Examine startup overheads from JDK-8294961 8229959: Convert proxy class to use constant dynamic Reviewed-by: liach, redestad ! src/java.base/share/classes/java/lang/constant/ConstantDescs.java ! src/java.base/share/classes/java/lang/reflect/Proxy.java ! src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java ! src/java.base/share/classes/jdk/internal/classfile/impl/StackMapDecoder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java ! src/java.base/share/classes/jdk/internal/constant/ConstantUtils.java ! src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java ! src/java.base/share/classes/jdk/internal/constant/ReferenceClassDescImpl.java + test/micro/org/openjdk/bench/java/lang/reflect/ProxyGenBench.java Changeset: c5c08678 Author: Christian Hagedorn Date: 2024-06-05 15:37:31 +0000 URL: https://git.openjdk.org/loom/commit/c5c0867881a43c81e88453274ac12e45454685a4 8333252: C2: assert(assertion_predicate_has_loop_opaque_node(iff)) failed: must find OpaqueLoop* nodes Reviewed-by: kvn, epeter ! src/hotspot/share/opto/loopPredicate.cpp + test/hotspot/jtreg/compiler/predicates/assertion/TestTemplateWithoutOpaqueLoopNodes.java Changeset: 7acfba28 Author: Mark Sheppard Date: 2024-06-05 15:47:52 +0000 URL: https://git.openjdk.org/loom/commit/7acfba288ff4d1f43cc36506b2bd2d32107b00c2 8327650: Test java/nio/channels/DatagramChannel/StressNativeSignal.java timed out Reviewed-by: bpb ! test/jdk/java/nio/channels/DatagramChannel/StressNativeSignal.java Changeset: d7d1afb0 Author: Jaikiran Pai Date: 2024-06-05 15:55:20 +0000 URL: https://git.openjdk.org/loom/commit/d7d1afb0a84e771870e9f43e08c4a63c8fdccdd9 8206447: InflaterInputStream.skip receives long but it's limited to Integer.MAX_VALUE Reviewed-by: lancea, alanb ! src/java.base/share/classes/java/util/zip/DeflaterInputStream.java ! src/java.base/share/classes/java/util/zip/InflaterInputStream.java Changeset: 438121be Author: Sonia Zaldana Calles Committer: Thomas Stuefe Date: 2024-06-05 15:58:59 +0000 URL: https://git.openjdk.org/loom/commit/438121be6bdb085fa13ad14ec53b09ecdbd4757d 8332785: Replace naked uses of UseSharedSpaces with CDSConfig::is_using_archive Reviewed-by: dholmes, stuefe, sspitsyn ! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp ! src/hotspot/os/posix/vmError_posix.cpp ! src/hotspot/os/windows/vmError_windows.cpp ! src/hotspot/share/cds/cdsConfig.cpp ! src/hotspot/share/cds/dynamicArchive.cpp ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/cds/heapShared.cpp ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/classfile/classLoader.cpp ! src/hotspot/share/classfile/classLoaderDataShared.cpp ! src/hotspot/share/classfile/classLoaderExt.cpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/moduleEntry.cpp ! src/hotspot/share/classfile/packageEntry.cpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/classfile/vmClasses.cpp ! src/hotspot/share/classfile/vmSymbols.cpp ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp ! src/hotspot/share/memory/metaspace.cpp ! src/hotspot/share/memory/metaspace/metaspaceReporter.cpp ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/oops/arrayKlass.cpp ! src/hotspot/share/oops/constantPool.cpp ! src/hotspot/share/oops/instanceClassLoaderKlass.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceMirrorKlass.cpp ! src/hotspot/share/oops/instanceRefKlass.cpp ! src/hotspot/share/oops/instanceStackChunkKlass.cpp ! src/hotspot/share/oops/klass.cpp ! src/hotspot/share/prims/jvmtiRedefineClasses.cpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/abstract_vm_version.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/services/diagnosticCommand.cpp Changeset: 5dcb7a62 Author: Abhishek Kumar Date: 2024-06-05 16:03:35 +0000 URL: https://git.openjdk.org/loom/commit/5dcb7a627e1cfb360719a25722588180e5de9d09 8160755: bug6492108.java test fails with exception Image comparison failed at (0, 0) for image 4 in GTK L&F Reviewed-by: aivanov, dnguyen, tr ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java + test/jdk/com/sun/java/swing/plaf/gtk/bug6492108.java Changeset: f73922b2 Author: Leonid Mesnik Date: 2024-06-05 16:05:20 +0000 URL: https://git.openjdk.org/loom/commit/f73922b27d126314fc3127ee25aa40b6258c8a6b 8333235: vmTestbase/nsk/jdb/kill/kill001/kill001.java fails with C1 Reviewed-by: cjplummer, sspitsyn ! test/hotspot/jtreg/vmTestbase/nsk/jdb/kill/kill001/kill001a.java Changeset: 9b3694c4 Author: Andrew Haley Date: 2024-06-05 17:09:55 +0000 URL: https://git.openjdk.org/loom/commit/9b3694c4fcc3cf46c0d827427ae8aadb477e8e22 8319822: Use a linear-time algorithm for assert_different_registers() Reviewed-by: kbarrett, stefank, stuefe ! src/hotspot/cpu/aarch64/register_aarch64.hpp ! src/hotspot/cpu/x86/register_x86.hpp ! src/hotspot/share/asm/register.hpp ! src/hotspot/share/utilities/population_count.hpp Changeset: f7dbb98f Author: Jan Lahoda Date: 2024-06-05 17:20:44 +0000 URL: https://git.openjdk.org/loom/commit/f7dbb98fe69eb98f8544577d81550b4fd817864b 8333086: Using Console.println is unnecessarily slow due to JLine initalization Reviewed-by: asotona, naoto ! src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java + test/jdk/jdk/internal/jline/LazyJdkConsoleProvider.java Changeset: 4c09d9f8 Author: Jatin Bhateja Date: 2024-06-05 18:36:49 +0000 URL: https://git.openjdk.org/loom/commit/4c09d9f8280092949a9fe0f26ee516e699f7ba84 8332119: Incorrect IllegalArgumentException for C2 compiled permute kernel Reviewed-by: sviswanathan, kvn ! src/hotspot/share/opto/library_call.hpp ! src/hotspot/share/opto/vectorIntrinsics.cpp + test/hotspot/jtreg/compiler/vectorapi/TestTwoVectorPermute.java Changeset: 7564949a Author: Liam Miller-Cushon Date: 2024-06-05 19:10:13 +0000 URL: https://git.openjdk.org/loom/commit/7564949a56b533b9d955ff5feee75afd18e51f74 8291643: Consider omitting type annotations from type error diagnostics Reviewed-by: vromero ! make/langtools/tools/propertiesparser/parser/MessageType.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/JCDiagnostic.java + test/langtools/tools/javac/annotations/typeAnnotations/failures/IncompatibleTypes.java + test/langtools/tools/javac/annotations/typeAnnotations/failures/IncompatibleTypes.out ! test/langtools/tools/javac/lambda/LambdaConv25.out ! test/langtools/tools/javac/warnings/6747671/T6747671.out Changeset: 60ea17e8 Author: Serguei Spitsyn Date: 2024-06-05 21:46:41 +0000 URL: https://git.openjdk.org/loom/commit/60ea17e8482936a6acbc442bb1be199e01008072 8311177: Switching to interpreter only mode in carrier thread can lead to crashes Reviewed-by: pchilanomate, amenkov ! src/hotspot/share/prims/jvmtiEventController.cpp ! src/hotspot/share/prims/jvmtiEventController.hpp ! src/hotspot/share/prims/jvmtiThreadState.cpp ! src/hotspot/share/prims/jvmtiThreadState.hpp ! src/hotspot/share/prims/jvmtiThreadState.inline.hpp ! src/hotspot/share/runtime/javaThread.cpp + test/hotspot/jtreg/serviceability/jvmti/vthread/CarrierThreadEventNotification/CarrierThreadEventNotification.java + test/hotspot/jtreg/serviceability/jvmti/vthread/CarrierThreadEventNotification/libCarrierThreadEventNotification.cpp ! test/hotspot/jtreg/serviceability/jvmti/vthread/MethodExitTest/libMethodExitTest.cpp Changeset: ca939075 Author: David Holmes Date: 2024-06-06 00:15:43 +0000 URL: https://git.openjdk.org/loom/commit/ca9390755bc652251bdcfd9ec2a583680a63fddf 8256828: ostream::print_cr() truncates buffer in copy-through case Reviewed-by: stuefe, matsaave ! src/hotspot/share/utilities/ostream.cpp ! src/hotspot/share/utilities/ostream.hpp ! test/hotspot/gtest/utilities/test_ostream.cpp Changeset: 30894126 Author: Serguei Spitsyn Date: 2024-06-06 04:20:59 +0000 URL: https://git.openjdk.org/loom/commit/30894126a4ba8bc41c333c923ff3007503257688 8326716: JVMTI spec: clarify what nullptr means for C/C++ developers Reviewed-by: kbarrett, cjplummer ! src/hotspot/share/prims/jvmti.xml ! src/hotspot/share/prims/jvmti.xsl ! src/hotspot/share/prims/jvmtiEnv.xsl ! src/hotspot/share/prims/jvmtiLib.xsl Changeset: b3f540d3 Author: Jan Lahoda Date: 2024-06-06 04:43:36 +0000 URL: https://git.openjdk.org/loom/commit/b3f540d354c4a4e2f2199019a2b880a373699560 8332921: Ctrl+C does not call shutdown hooks after JLine upgrade Reviewed-by: asotona, vromero ! src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java Changeset: b351b5f6 Author: Cesar Soares Lucas Committer: Tobias Hartmann Date: 2024-06-06 05:21:09 +0000 URL: https://git.openjdk.org/loom/commit/b351b5f60ed836e6e21aa4ce5681e573a6057eb6 8331736: C2: Live Node limit exceeded limit after JDK-8316991 Reviewed-by: thartmann, chagedorn ! src/hotspot/share/opto/escape.cpp + test/hotspot/jtreg/compiler/c2/TestScalarReplacementMaxLiveNodes.java Changeset: 6f690a5b Author: Tobias Hartmann Date: 2024-06-06 05:39:28 +0000 URL: https://git.openjdk.org/loom/commit/6f690a5b01c3d438ba0a2a848a3909e43db650d8 8333177: Invalid value used for enum Cell in ciTypeFlow::get_start_state Reviewed-by: kvn, chagedorn ! src/hotspot/share/ci/ciTypeFlow.cpp Changeset: 8f078532 Author: Kuai Wei Committer: Julian Waters Date: 2024-06-06 06:25:43 +0000 URL: https://git.openjdk.org/loom/commit/8f0785325d54fb5b68867788d1fa3b20a238eaad 8333410: [AArch64] Clean unused classes in nativeInst_aarch64.hpp Reviewed-by: aph, chagedorn ! src/hotspot/cpu/aarch64/nativeInst_aarch64.cpp ! src/hotspot/cpu/aarch64/nativeInst_aarch64.hpp Changeset: 7ef28312 Author: Christian Hagedorn Date: 2024-06-06 06:58:05 +0000 URL: https://git.openjdk.org/loom/commit/7ef283129388413b362942fb45af48d1f7393b67 8333644: C2: assert(is_Bool()) failed: invalid node class: Phi Reviewed-by: thartmann, kvn ! src/hotspot/share/opto/loopopts.cpp ! test/hotspot/jtreg/compiler/predicates/assertion/TestOpaqueInitializedAssertionPredicateNode.java Changeset: c7d2841f Author: Nizar Benalla Committer: Jaikiran Pai Date: 2024-06-06 07:27:58 +0000 URL: https://git.openjdk.org/loom/commit/c7d2841fb4ac97c0edec175cf37abd90167ea56e 8332070: Convert package.html files in `java.management` to package-info.java Reviewed-by: alanb + src/java.management/share/classes/java/lang/management/package-info.java - src/java.management/share/classes/java/lang/management/package.html + src/java.management/share/classes/javax/management/loading/package-info.java - src/java.management/share/classes/javax/management/loading/package.html + src/java.management/share/classes/javax/management/modelmbean/package-info.java - src/java.management/share/classes/javax/management/modelmbean/package.html + src/java.management/share/classes/javax/management/monitor/package-info.java - src/java.management/share/classes/javax/management/monitor/package.html + src/java.management/share/classes/javax/management/openmbean/package-info.java - src/java.management/share/classes/javax/management/openmbean/package.html + src/java.management/share/classes/javax/management/package-info.java - src/java.management/share/classes/javax/management/package.html + src/java.management/share/classes/javax/management/relation/package-info.java - src/java.management/share/classes/javax/management/relation/package.html + src/java.management/share/classes/javax/management/remote/package-info.java - src/java.management/share/classes/javax/management/remote/package.html + src/java.management/share/classes/javax/management/timer/package-info.java - src/java.management/share/classes/javax/management/timer/package.html Changeset: 880c6b42 Author: Matthias Baesken Date: 2024-06-06 07:46:35 +0000 URL: https://git.openjdk.org/loom/commit/880c6b42ba74884690daa5c23f6605876f29aece 8333178: ubsan: jvmti_tools.cpp:149:16: runtime error: null pointer passed as argument 2, which is declared to never be null Reviewed-by: cjplummer, sspitsyn ! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp Changeset: d232a67b Author: Alan Bateman Date: 2024-06-06 09:20:25 +0000 URL: https://git.openjdk.org/loom/commit/d232a67b9d651a449d07b72e884455e9975bf1f1 Merge ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceStackChunkKlass.cpp ! src/hotspot/share/opto/library_call.hpp ! src/hotspot/share/prims/jvmtiThreadState.cpp ! src/hotspot/share/runtime/javaThread.cpp ! src/hotspot/share/services/diagnosticCommand.cpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceStackChunkKlass.cpp ! src/hotspot/share/opto/library_call.hpp ! src/hotspot/share/prims/jvmtiThreadState.cpp ! src/hotspot/share/runtime/javaThread.cpp ! src/hotspot/share/services/diagnosticCommand.cpp Changeset: b2b4a867 Author: Alan Bateman Date: 2024-06-06 11:32:35 +0000 URL: https://git.openjdk.org/loom/commit/b2b4a86703271cf2c52b4cc1763f501e0d549019 Fix up enter_interp_only_mode usages ! src/hotspot/share/prims/jvmtiExport.cpp ! src/hotspot/share/runtime/continuationFreezeThaw.cpp Changeset: fe211bb4 Author: Alan Bateman Date: 2024-06-06 11:33:27 +0000 URL: https://git.openjdk.org/loom/commit/fe211bb49980c0810ad524cb570d9c8e794df402 JNIEnv can't be saved as static ! test/hotspot/jtreg/serviceability/jvmti/events/MonitorContendedEnter/mcontenter01/libmcontenter01.cpp ! test/hotspot/jtreg/serviceability/jvmti/events/MonitorContendedEntered/mcontentered01/libmcontentered01.cpp ! test/hotspot/jtreg/serviceability/jvmti/events/MonitorWaited/monitorwaited01/libmonitorwaited01.cpp ! test/hotspot/jtreg/serviceability/jvmti/events/MonitorWaited/monitorwaited01/monitorwaited01.java From ron.pressler at oracle.com Thu Jun 6 11:01:59 2024 From: ron.pressler at oracle.com (Ron Pressler) Date: Thu, 6 Jun 2024 11:01:59 +0000 Subject: [External] : Re: Performance of pooling virtual threads vs. semaphores In-Reply-To: <11711A18-C0B6-4F0C-ADB5-5B50E74D28AB@ix.netcom.com> References: <2F3CF9FB-AB62-4EFD-A4C0-CF489F905873@ix.netcom.com> <11711A18-C0B6-4F0C-ADB5-5B50E74D28AB@ix.netcom.com> Message-ID: > On 6 Jun 2024, at 02:27, robert engels wrote: > > Totally agree, but then I guess I don?t understand how ?most submissions would be internal? holds. It seems there is an unstated expectation of the workloads used with virtual threads. It may be as simple as ?use virtual threads when your workload looks this??, ?use pooled virtual threads when your workload looks like this??, use ?platform threads??, etc. > > I?m not saying anything needs to change, only that I think more clarity on these dynamics would help. And it is totally ok to say ?for now??. > > Just my two cents. > To be clear, I don?t know if external submissions play a role here, only that this is one glaring aspect in which the benchmark differs quite significantly from the intended workload, and because we ultimately care about the actual workload ? not a microbenchmark ? if we were to spend time analysing performance, we?d rather do it on something that is more likely to help that goal. As to your question, the scheduler privileges internal submissions somewhat because that tends to help real-world programs. In other words, it responds to what programs do, not the other way around. So I don?t think you should take that into account when using virtual threads. External submissions are also perfectly fine, they typically happen as a result of some external IO event, and they tend to mix with internal submissions. I wouldn?t worry about it, and I certainly can?t give performance advice on hypothetical workloads; there are too many variables. The only general advice is: use virtual threads when there are many (let?s say thousands and upward) of concurrent tasks (i.e. tasks whose lifetimes naturally overlap), and give each task its own virtual thread. When the number of concurrent tasks is small (as is often the case in parallel computation workloads) then there is a chance that directly managing platform threads would perform better. But that?s just general, approximate advice. For best performance always profile your program and optimise based on its specific profile. ? Ron From duke at openjdk.org Thu Jun 6 11:01:04 2024 From: duke at openjdk.org (duke) Date: Thu, 6 Jun 2024 11:01:04 GMT Subject: git: openjdk/loom: master: 25 new changesets Message-ID: Changeset: cbb6747e Author: Sonia Zaldana Calles Committer: Jaikiran Pai Date: 2024-06-05 13:12:30 +0000 URL: https://git.openjdk.org/loom/commit/cbb6747e6b9ce7e2b9e0ffb0a1f9499f7e0e13b0 8329581: Java launcher no longer prints a stack trace 8329420: Java 22 (and 23) launcher calls default constructor although main() is static 8330864: No error message when ExceptionInInitializerError thrown in static initializer Reviewed-by: stuefe ! src/java.base/share/classes/sun/launcher/LauncherHelper.java ! src/java.base/share/native/libjli/java.c ! test/jdk/tools/launcher/InstanceMainTest.java + test/jdk/tools/launcher/LauncherExceptionTest.java Changeset: 6882b381 Author: Jaikiran Pai Date: 2024-06-05 14:03:29 +0000 URL: https://git.openjdk.org/loom/commit/6882b381e8662b5c134d3a1868c357eeb3523ea8 8333590: UnmodifiableHeaders.toString() returns a value that represents empty headers Reviewed-by: dfuchs, michaelm ! src/jdk.httpserver/share/classes/sun/net/httpserver/UnmodifiableHeaders.java ! test/jdk/com/sun/net/httpserver/UnmodifiableHeadersTest.java Changeset: 9a8096fe Author: Sonia Zaldana Calles Committer: Thomas Stuefe Date: 2024-06-05 14:14:14 +0000 URL: https://git.openjdk.org/loom/commit/9a8096feb82991784cabede823f0248fe2f41e53 8330047: ASAN build error with gcc 13 Reviewed-by: aboldtch, stuefe ! src/hotspot/share/gc/z/zMarkStack.hpp Changeset: 326dbb1b Author: Viktor Klang Date: 2024-06-05 14:40:04 +0000 URL: https://git.openjdk.org/loom/commit/326dbb1b139dd1ec1b8605339b91697cdf49da9a 8312436: CompletableFuture never completes when 'Throwable.toString()' method throws Exception Reviewed-by: alanb ! src/java.base/share/classes/java/util/concurrent/CompletableFuture.java ! test/jdk/java/util/concurrent/tck/CompletableFutureTest.java Changeset: d85b0ca5 Author: Adam Sotona Date: 2024-06-05 15:33:03 +0000 URL: https://git.openjdk.org/loom/commit/d85b0ca5cdc1820a886c46bf555b2051fed7f167 8332457: Examine startup overheads from JDK-8294961 8229959: Convert proxy class to use constant dynamic Reviewed-by: liach, redestad ! src/java.base/share/classes/java/lang/constant/ConstantDescs.java ! src/java.base/share/classes/java/lang/reflect/Proxy.java ! src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java ! src/java.base/share/classes/jdk/internal/classfile/impl/StackMapDecoder.java ! src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java ! src/java.base/share/classes/jdk/internal/constant/ConstantUtils.java ! src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java ! src/java.base/share/classes/jdk/internal/constant/ReferenceClassDescImpl.java + test/micro/org/openjdk/bench/java/lang/reflect/ProxyGenBench.java Changeset: c5c08678 Author: Christian Hagedorn Date: 2024-06-05 15:37:31 +0000 URL: https://git.openjdk.org/loom/commit/c5c0867881a43c81e88453274ac12e45454685a4 8333252: C2: assert(assertion_predicate_has_loop_opaque_node(iff)) failed: must find OpaqueLoop* nodes Reviewed-by: kvn, epeter ! src/hotspot/share/opto/loopPredicate.cpp + test/hotspot/jtreg/compiler/predicates/assertion/TestTemplateWithoutOpaqueLoopNodes.java Changeset: 7acfba28 Author: Mark Sheppard Date: 2024-06-05 15:47:52 +0000 URL: https://git.openjdk.org/loom/commit/7acfba288ff4d1f43cc36506b2bd2d32107b00c2 8327650: Test java/nio/channels/DatagramChannel/StressNativeSignal.java timed out Reviewed-by: bpb ! test/jdk/java/nio/channels/DatagramChannel/StressNativeSignal.java Changeset: d7d1afb0 Author: Jaikiran Pai Date: 2024-06-05 15:55:20 +0000 URL: https://git.openjdk.org/loom/commit/d7d1afb0a84e771870e9f43e08c4a63c8fdccdd9 8206447: InflaterInputStream.skip receives long but it's limited to Integer.MAX_VALUE Reviewed-by: lancea, alanb ! src/java.base/share/classes/java/util/zip/DeflaterInputStream.java ! src/java.base/share/classes/java/util/zip/InflaterInputStream.java Changeset: 438121be Author: Sonia Zaldana Calles Committer: Thomas Stuefe Date: 2024-06-05 15:58:59 +0000 URL: https://git.openjdk.org/loom/commit/438121be6bdb085fa13ad14ec53b09ecdbd4757d 8332785: Replace naked uses of UseSharedSpaces with CDSConfig::is_using_archive Reviewed-by: dholmes, stuefe, sspitsyn ! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp ! src/hotspot/os/posix/vmError_posix.cpp ! src/hotspot/os/windows/vmError_windows.cpp ! src/hotspot/share/cds/cdsConfig.cpp ! src/hotspot/share/cds/dynamicArchive.cpp ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/cds/heapShared.cpp ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/classfile/classLoader.cpp ! src/hotspot/share/classfile/classLoaderDataShared.cpp ! src/hotspot/share/classfile/classLoaderExt.cpp ! src/hotspot/share/classfile/javaClasses.cpp ! src/hotspot/share/classfile/moduleEntry.cpp ! src/hotspot/share/classfile/packageEntry.cpp ! src/hotspot/share/classfile/systemDictionary.cpp ! src/hotspot/share/classfile/systemDictionaryShared.cpp ! src/hotspot/share/classfile/vmClasses.cpp ! src/hotspot/share/classfile/vmSymbols.cpp ! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp ! src/hotspot/share/memory/metaspace.cpp ! src/hotspot/share/memory/metaspace/metaspaceReporter.cpp ! src/hotspot/share/memory/universe.cpp ! src/hotspot/share/oops/arrayKlass.cpp ! src/hotspot/share/oops/constantPool.cpp ! src/hotspot/share/oops/instanceClassLoaderKlass.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/instanceMirrorKlass.cpp ! src/hotspot/share/oops/instanceRefKlass.cpp ! src/hotspot/share/oops/instanceStackChunkKlass.cpp ! src/hotspot/share/oops/klass.cpp ! src/hotspot/share/prims/jvmtiRedefineClasses.cpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/abstract_vm_version.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/services/diagnosticCommand.cpp Changeset: 5dcb7a62 Author: Abhishek Kumar Date: 2024-06-05 16:03:35 +0000 URL: https://git.openjdk.org/loom/commit/5dcb7a627e1cfb360719a25722588180e5de9d09 8160755: bug6492108.java test fails with exception Image comparison failed at (0, 0) for image 4 in GTK L&F Reviewed-by: aivanov, dnguyen, tr ! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKStyle.java + test/jdk/com/sun/java/swing/plaf/gtk/bug6492108.java Changeset: f73922b2 Author: Leonid Mesnik Date: 2024-06-05 16:05:20 +0000 URL: https://git.openjdk.org/loom/commit/f73922b27d126314fc3127ee25aa40b6258c8a6b 8333235: vmTestbase/nsk/jdb/kill/kill001/kill001.java fails with C1 Reviewed-by: cjplummer, sspitsyn ! test/hotspot/jtreg/vmTestbase/nsk/jdb/kill/kill001/kill001a.java Changeset: 9b3694c4 Author: Andrew Haley Date: 2024-06-05 17:09:55 +0000 URL: https://git.openjdk.org/loom/commit/9b3694c4fcc3cf46c0d827427ae8aadb477e8e22 8319822: Use a linear-time algorithm for assert_different_registers() Reviewed-by: kbarrett, stefank, stuefe ! src/hotspot/cpu/aarch64/register_aarch64.hpp ! src/hotspot/cpu/x86/register_x86.hpp ! src/hotspot/share/asm/register.hpp ! src/hotspot/share/utilities/population_count.hpp Changeset: f7dbb98f Author: Jan Lahoda Date: 2024-06-05 17:20:44 +0000 URL: https://git.openjdk.org/loom/commit/f7dbb98fe69eb98f8544577d81550b4fd817864b 8333086: Using Console.println is unnecessarily slow due to JLine initalization Reviewed-by: asotona, naoto ! src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java + test/jdk/jdk/internal/jline/LazyJdkConsoleProvider.java Changeset: 4c09d9f8 Author: Jatin Bhateja Date: 2024-06-05 18:36:49 +0000 URL: https://git.openjdk.org/loom/commit/4c09d9f8280092949a9fe0f26ee516e699f7ba84 8332119: Incorrect IllegalArgumentException for C2 compiled permute kernel Reviewed-by: sviswanathan, kvn ! src/hotspot/share/opto/library_call.hpp ! src/hotspot/share/opto/vectorIntrinsics.cpp + test/hotspot/jtreg/compiler/vectorapi/TestTwoVectorPermute.java Changeset: 7564949a Author: Liam Miller-Cushon Date: 2024-06-05 19:10:13 +0000 URL: https://git.openjdk.org/loom/commit/7564949a56b533b9d955ff5feee75afd18e51f74 8291643: Consider omitting type annotations from type error diagnostics Reviewed-by: vromero ! make/langtools/tools/propertiesparser/parser/MessageType.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/util/JCDiagnostic.java + test/langtools/tools/javac/annotations/typeAnnotations/failures/IncompatibleTypes.java + test/langtools/tools/javac/annotations/typeAnnotations/failures/IncompatibleTypes.out ! test/langtools/tools/javac/lambda/LambdaConv25.out ! test/langtools/tools/javac/warnings/6747671/T6747671.out Changeset: 60ea17e8 Author: Serguei Spitsyn Date: 2024-06-05 21:46:41 +0000 URL: https://git.openjdk.org/loom/commit/60ea17e8482936a6acbc442bb1be199e01008072 8311177: Switching to interpreter only mode in carrier thread can lead to crashes Reviewed-by: pchilanomate, amenkov ! src/hotspot/share/prims/jvmtiEventController.cpp ! src/hotspot/share/prims/jvmtiEventController.hpp ! src/hotspot/share/prims/jvmtiThreadState.cpp ! src/hotspot/share/prims/jvmtiThreadState.hpp ! src/hotspot/share/prims/jvmtiThreadState.inline.hpp ! src/hotspot/share/runtime/javaThread.cpp + test/hotspot/jtreg/serviceability/jvmti/vthread/CarrierThreadEventNotification/CarrierThreadEventNotification.java + test/hotspot/jtreg/serviceability/jvmti/vthread/CarrierThreadEventNotification/libCarrierThreadEventNotification.cpp ! test/hotspot/jtreg/serviceability/jvmti/vthread/MethodExitTest/libMethodExitTest.cpp Changeset: ca939075 Author: David Holmes Date: 2024-06-06 00:15:43 +0000 URL: https://git.openjdk.org/loom/commit/ca9390755bc652251bdcfd9ec2a583680a63fddf 8256828: ostream::print_cr() truncates buffer in copy-through case Reviewed-by: stuefe, matsaave ! src/hotspot/share/utilities/ostream.cpp ! src/hotspot/share/utilities/ostream.hpp ! test/hotspot/gtest/utilities/test_ostream.cpp Changeset: 30894126 Author: Serguei Spitsyn Date: 2024-06-06 04:20:59 +0000 URL: https://git.openjdk.org/loom/commit/30894126a4ba8bc41c333c923ff3007503257688 8326716: JVMTI spec: clarify what nullptr means for C/C++ developers Reviewed-by: kbarrett, cjplummer ! src/hotspot/share/prims/jvmti.xml ! src/hotspot/share/prims/jvmti.xsl ! src/hotspot/share/prims/jvmtiEnv.xsl ! src/hotspot/share/prims/jvmtiLib.xsl Changeset: b3f540d3 Author: Jan Lahoda Date: 2024-06-06 04:43:36 +0000 URL: https://git.openjdk.org/loom/commit/b3f540d354c4a4e2f2199019a2b880a373699560 8332921: Ctrl+C does not call shutdown hooks after JLine upgrade Reviewed-by: asotona, vromero ! src/jdk.internal.le/share/classes/jdk/internal/org/jline/JdkConsoleProviderImpl.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java Changeset: b351b5f6 Author: Cesar Soares Lucas Committer: Tobias Hartmann Date: 2024-06-06 05:21:09 +0000 URL: https://git.openjdk.org/loom/commit/b351b5f60ed836e6e21aa4ce5681e573a6057eb6 8331736: C2: Live Node limit exceeded limit after JDK-8316991 Reviewed-by: thartmann, chagedorn ! src/hotspot/share/opto/escape.cpp + test/hotspot/jtreg/compiler/c2/TestScalarReplacementMaxLiveNodes.java Changeset: 6f690a5b Author: Tobias Hartmann Date: 2024-06-06 05:39:28 +0000 URL: https://git.openjdk.org/loom/commit/6f690a5b01c3d438ba0a2a848a3909e43db650d8 8333177: Invalid value used for enum Cell in ciTypeFlow::get_start_state Reviewed-by: kvn, chagedorn ! src/hotspot/share/ci/ciTypeFlow.cpp Changeset: 8f078532 Author: Kuai Wei Committer: Julian Waters Date: 2024-06-06 06:25:43 +0000 URL: https://git.openjdk.org/loom/commit/8f0785325d54fb5b68867788d1fa3b20a238eaad 8333410: [AArch64] Clean unused classes in nativeInst_aarch64.hpp Reviewed-by: aph, chagedorn ! src/hotspot/cpu/aarch64/nativeInst_aarch64.cpp ! src/hotspot/cpu/aarch64/nativeInst_aarch64.hpp Changeset: 7ef28312 Author: Christian Hagedorn Date: 2024-06-06 06:58:05 +0000 URL: https://git.openjdk.org/loom/commit/7ef283129388413b362942fb45af48d1f7393b67 8333644: C2: assert(is_Bool()) failed: invalid node class: Phi Reviewed-by: thartmann, kvn ! src/hotspot/share/opto/loopopts.cpp ! test/hotspot/jtreg/compiler/predicates/assertion/TestOpaqueInitializedAssertionPredicateNode.java Changeset: c7d2841f Author: Nizar Benalla Committer: Jaikiran Pai Date: 2024-06-06 07:27:58 +0000 URL: https://git.openjdk.org/loom/commit/c7d2841fb4ac97c0edec175cf37abd90167ea56e 8332070: Convert package.html files in `java.management` to package-info.java Reviewed-by: alanb + src/java.management/share/classes/java/lang/management/package-info.java - src/java.management/share/classes/java/lang/management/package.html + src/java.management/share/classes/javax/management/loading/package-info.java - src/java.management/share/classes/javax/management/loading/package.html + src/java.management/share/classes/javax/management/modelmbean/package-info.java - src/java.management/share/classes/javax/management/modelmbean/package.html + src/java.management/share/classes/javax/management/monitor/package-info.java - src/java.management/share/classes/javax/management/monitor/package.html + src/java.management/share/classes/javax/management/openmbean/package-info.java - src/java.management/share/classes/javax/management/openmbean/package.html + src/java.management/share/classes/javax/management/package-info.java - src/java.management/share/classes/javax/management/package.html + src/java.management/share/classes/javax/management/relation/package-info.java - src/java.management/share/classes/javax/management/relation/package.html + src/java.management/share/classes/javax/management/remote/package-info.java - src/java.management/share/classes/javax/management/remote/package.html + src/java.management/share/classes/javax/management/timer/package-info.java - src/java.management/share/classes/javax/management/timer/package.html Changeset: 880c6b42 Author: Matthias Baesken Date: 2024-06-06 07:46:35 +0000 URL: https://git.openjdk.org/loom/commit/880c6b42ba74884690daa5c23f6605876f29aece 8333178: ubsan: jvmti_tools.cpp:149:16: runtime error: null pointer passed as argument 2, which is declared to never be null Reviewed-by: cjplummer, sspitsyn ! test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/jvmti_tools.cpp From marcin.grzejszczak at gmail.com Thu Jun 6 20:53:59 2024 From: marcin.grzejszczak at gmail.com (Marcin Grzejszczak) Date: Thu, 6 Jun 2024 22:53:59 +0200 Subject: ScopedValue.runWhere not returning scope In-Reply-To: <03b69bde-3f90-428c-aa94-b147a8a18819@littlepinkcloud.com> References: <03b69bde-3f90-428c-aa94-b147a8a18819@littlepinkcloud.com> Message-ID: Thank you for this great discussion! > If you consider an execution of a program as a downwards-growing stack, a scoped value is bound to some value at one point in the stack, and the bound value is visible to all frames below that point. That is all: there's no need to consider scopes opening and closing. In theory that's true. But if we take into consideration frameworks like Brave [1], Micrometer [2], OpenTelemetry [3] , Apache Camel [4], Apache Skywalking [5] etc. (so those that work with distributed tracing) that theoretical viewpoint does not hold. It would be a gigantic shame if they would need to always rely on ThreadLocals instead of being able to use the ScopedValues mechanism. > It's true that this decision makes scoped values less versatile than thread-local variables, but on the other hand the hard guarantees it provides make programs easier to reason about. On balance, we consider the latter more important than the former. I completely agree with that however for library instrumentors this separation is extremely important. Also that would cancel out all libraries that want to use scoped values and work in an SPI model where users can add functionalities in an isolated fashion (separate before and after logic). It would require all of the frameworks that I mentioned to completely rewrite their internals so that the user's code execution would be wrapped in a e.g. `ScopedValue.runWhere`. > We did consider (and even implement) an API with open() and close() methods, but we discarded it in order to make the use you describe impossible I understand that with great power comes great responsibility and you want to guard users from cases like "opening and not closing". I fully understand that because I've been working in the domain of distributed tracing for a decade now and I've seen that particular scenario happen every now and then. It's not a common situation though. Since you've already implemented it once then you did see reasons for doing that. Is there a chance to come back to that discussion? What would need to happen to reopen that conversation once again? [1] https://github.com/openzipkin/brave/blob/6.0.3/brave/src/main/java/brave/Tracer.java#L576-L594 [2] https://github.com/micrometer-metrics/micrometer/blob/v1.13.0/micrometer-observation/src/main/java/io/micrometer/observation/Observation.java#L838-L904 [3] https://github.com/open-telemetry/opentelemetry-java/blob/v1.38.0/context/src/main/java/io/opentelemetry/context/Context.java#L200-L203 [4] https://github.com/apache/camel/blob/camel-4.6.0/components/camel-tracing/src/main/java/org/apache/camel/tracing/ActiveSpanManager.java#L136-L144 [5] https://skywalking.apache.org/docs/skywalking-java/next/en/setup/service-agent/java-agent/application-toolkit-tracer/ (AFAIR upon creation Span is made current and needs to be then closed) Pozdrawiam / Best regards, Marcin Grzejszczak https://marcin.grzejszczak.pl https://toomuchcoding.com czw., 6 cze 2024 o 10:48 Andrew Haley napisa?(a): > On 6/5/24 22:31, Marcin Grzejszczak wrote: > > > I am wondering what if I don't want to use a ThreadLocal but > > ScopeValue? Is it the tool to solve this problem? Current API allows > > me to run a lambda within a scope through > > `ScopedValue.runWhere(scopedValue, "foo", () -> {})`. But what if I > > wanted to separate this into 2 steps, the scope opening and closing? > > The structured nature of a scoped value is a part of its essential > design. It is the main difference between scoped values and > thread-local variables. > > If you consider an execution of a program as a downwards-growing > stack, a scoped value is bound to some value at one point in the > stack, and the bound value is visible to all frames below that point. > That is all: there's no need to consider scopes opening and closing. > > It's true that this decision makes scoped values less versatile than > thread-local variables, but on the other hand the hard guarantees it > provides make programs easier to reason about. On balance, we consider > the latter more important than the former. > > We did consider (and even implement) an API with open() and close() > methods, but we discarded it in order to make the use you describe > impossible. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > Nie zawiera wirus?w.www.avg.com <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at google.com Fri Jun 7 00:51:01 2024 From: cushon at google.com (Liam Miller-Cushon) Date: Thu, 6 Jun 2024 17:51:01 -0700 Subject: pluggable schedulers Message-ID: Hi, There were some mentions of 'pluggable schedulers' in the early Loom docs [1][2] that would have allowed users to replace ForkJoinPool with a custom scheduler, but it wasn't included in the later proposals. I found a mention on loom-dev@ in 2022 that they were 'being worked on but were not delivered in JEP 425' [3]. I'm curious what became of that idea--is it still possible future work, or was a decision made not to support that at some point? Thanks, Liam [1] https://cr.openjdk.org/~rpressler/loom/Loom-Proposal.html [2] https://cr.openjdk.org/~rpressler/loom/loom/sol1_part1.html#scheduling [3] https://mail.openjdk.org/pipermail/loom-dev/2022-July.txt -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Jun 7 04:37:45 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 7 Jun 2024 05:37:45 +0100 Subject: pluggable schedulers In-Reply-To: References: Message-ID: <1d507d1d-7539-48b6-9610-c4f640afab0f@oracle.com> On 07/06/2024 01:51, Liam Miller-Cushon wrote: > Hi, > > There were some mentions of 'pluggable schedulers' in the early Loom > docs [1][2] that would have allowed users to replace ForkJoinPool with > a custom scheduler, but it wasn't included in the later proposals. I > found a mention on loom-dev@ in 2022 that they were 'being worked on > but were not delivered in JEP 425' [3]. > > I'm curious what became of that idea--is it still possible future > work, or was a decision made not to support that at some point? It's a feature that we have to be very cautious about. The EA builds exposed a prototype API for a long time but there wasn't much feedback. Definitely not enough usage to help decide what hooks to expose. The API (not the implementation support)? was pulled when preparing the proposal for the main line (JEP 425). There is interest in some areas to explore the topic again, just nothing definite (no JEP) at this time. -Alan From duke at openjdk.org Fri Jun 7 05:47:46 2024 From: duke at openjdk.org (duke) Date: Fri, 7 Jun 2024 05:47:46 GMT Subject: git: openjdk/loom: fibers: 16 new changesets Message-ID: <301fb410-5762-470b-9bed-41720b178bbe@openjdk.org> Changeset: 1a50bd09 Author: Erik Gahlin Date: 2024-06-06 09:57:30 +0000 URL: https://git.openjdk.org/loom/commit/1a50bd09ef7abfa3709edb388c7dbb003d483561 8322568: JFR: Improve metadata for IEEE rounding mode fields Reviewed-by: mgronlun ! src/hotspot/share/jfr/metadata/metadata.xml ! src/hotspot/share/jfr/support/jfrNativeLibraryLoadEvent.cpp Changeset: f15d423f Author: Saint Wesonga Committer: David Holmes Date: 2024-06-06 11:55:43 +0000 URL: https://git.openjdk.org/loom/commit/f15d423fb5451c7c8f2d1007235ebf8aa79a403e 6942632: Hotspot should be able to use more than 64 logical processors on Windows Reviewed-by: jsjolen, dholmes ! make/test/JtregNativeHotspot.gmk ! src/hotspot/os/windows/globals_windows.hpp ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/os/windows/os_windows.hpp ! test/hotspot/gtest/runtime/test_os_windows.cpp ! test/hotspot/jtreg/TEST.groups + test/hotspot/jtreg/gtest/WindowsProcessorGroups.java + test/hotspot/jtreg/runtime/os/windows/GetAvailableProcessors.java + test/hotspot/jtreg/runtime/os/windows/TestAvailableProcessors.java + test/hotspot/jtreg/runtime/os/windows/exeGetProcessorInfo.c Changeset: 8de5d201 Author: Matthias Baesken Date: 2024-06-06 12:27:26 +0000 URL: https://git.openjdk.org/loom/commit/8de5d2014a87d58d389eb8400f619d1b1fa3abe7 8332865: ubsan: os::attempt_reserve_memory_between reports overflow Reviewed-by: stuefe, clanger ! src/hotspot/share/runtime/os.cpp Changeset: 33fd6ae9 Author: Vladimir Kozlov Date: 2024-06-06 13:41:51 +0000 URL: https://git.openjdk.org/loom/commit/33fd6ae98638d2a4b33d18cc4acee4f0daaa9b35 8333622: ubsan: relocInfo_x86.cpp:101:56: runtime error: pointer index expression with base (-1) overflowed Reviewed-by: thartmann, chagedorn ! src/hotspot/cpu/x86/relocInfo_x86.cpp Changeset: 606df441 Author: Galder Zamarre?o Committer: Martin Doerr Date: 2024-06-06 15:02:22 +0000 URL: https://git.openjdk.org/loom/commit/606df441410a69034b4c113e85ce21937d1a0808 8332670: C1 clone intrinsic needs memory barriers Reviewed-by: shade, thartmann, aph ! src/hotspot/share/c1/c1_GraphBuilder.cpp Changeset: 02f24041 Author: Jorn Vernee Date: 2024-06-06 15:18:18 +0000 URL: https://git.openjdk.org/loom/commit/02f240415cbda5f67a91af50d5974fb001104170 8333560: -Xlint:restricted does not work with --release Co-authored-by: Jan Lahoda Reviewed-by: vromero, mcimadamore ! make/langtools/src/classes/build/tools/symbolgenerator/CreateSymbols.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! test/langtools/tools/javac/RestrictedMethods.java ! test/langtools/tools/javac/RestrictedMethods.out Changeset: d02cb742 Author: Daniel Fuchs Date: 2024-06-06 15:19:50 +0000 URL: https://git.openjdk.org/loom/commit/d02cb742f79e88c6438ca58a6357fe432fb286cb 8333270: HandlersOnComplexResetUpdate and HandlersOnComplexUpdate tests fail with "Unexpected reference" if timeoutFactor is less than 1/3 Reviewed-by: jpai ! test/jdk/java/util/logging/LogManager/Configuration/updateConfiguration/HandlersOnComplexResetUpdate.java ! test/jdk/java/util/logging/LogManager/Configuration/updateConfiguration/HandlersOnComplexUpdate.java Changeset: 487c4771 Author: Emanuel Peter Date: 2024-06-06 15:21:31 +0000 URL: https://git.openjdk.org/loom/commit/487c4771818999749bfd507ab85777795bba0832 8333647: C2 SuperWord: some additional PopulateIndex tests Reviewed-by: kvn, chagedorn ! test/hotspot/jtreg/compiler/vectorization/runner/ArrayIndexFillTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/ArrayShiftOpTest.java Changeset: 9b436d04 Author: Martin Doerr Date: 2024-06-06 15:34:46 +0000 URL: https://git.openjdk.org/loom/commit/9b436d048ec92f74ec6812ae20fde21751927d4b 8333674: Disable CollectorPolicy.young_min_ergo_vm for PPC64 Reviewed-by: mbaesken, zgu ! test/hotspot/gtest/gc/shared/test_collectorPolicy.cpp Changeset: 054362ab Author: Abhishek Kumar Date: 2024-06-06 15:53:09 +0000 URL: https://git.openjdk.org/loom/commit/054362abe040938b87eb1a1cab8a0a94540e0667 8332550: [macos] Voice Over: java.awt.IllegalComponentStateException: component must be showing on the screen to determine its location Reviewed-by: asemenov, kizune, achung ! src/java.desktop/share/classes/javax/swing/table/JTableHeader.java Changeset: e183f543 Author: Alan Bateman Date: 2024-06-06 17:32:57 +0000 URL: https://git.openjdk.org/loom/commit/e183f5434fd092b914ae77905ed4dd5145f3d1f9 Merge ! make/test/JtregNativeHotspot.gmk ! src/hotspot/share/jfr/metadata/metadata.xml ! test/hotspot/jtreg/TEST.groups ! make/test/JtregNativeHotspot.gmk ! src/hotspot/share/jfr/metadata/metadata.xml ! test/hotspot/jtreg/TEST.groups Changeset: 75dc2f85 Author: Joe Darcy Committer: Jesper Wilhelmsson Date: 2024-06-06 16:01:57 +0000 URL: https://git.openjdk.org/loom/commit/75dc2f8518d0adea30f7065d6732b807c0220756 8330182: Start of release updates for JDK 24 8330183: Add SourceVersion.RELEASE_24 8330184: Add source 24 and target 24 to javac Reviewed-by: iris, vromero, asotona, dholmes ! .jcheck/conf ! make/conf/version-numbers.conf ! src/hotspot/share/classfile/classFileParser.cpp ! src/java.base/share/classes/java/lang/classfile/ClassFile.java ! src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/Opcodes.java ! src/java.compiler/share/classes/javax/lang/model/SourceVersion.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitorPreview.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitorPreview.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitorPreview.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitorPreview.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementScanner14.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementScannerPreview.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitorPreview.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitorPreview.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitorPreview.java ! src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitorPreview.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassFile.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Target.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java + src/jdk.compiler/share/data/symbols/java.base-N.sym.txt + src/jdk.compiler/share/data/symbols/java.compiler-N.sym.txt + src/jdk.compiler/share/data/symbols/java.desktop-N.sym.txt + src/jdk.compiler/share/data/symbols/java.management-N.sym.txt + src/jdk.compiler/share/data/symbols/java.management.rmi-N.sym.txt + src/jdk.compiler/share/data/symbols/jdk.compiler-N.sym.txt + src/jdk.compiler/share/data/symbols/jdk.httpserver-N.sym.txt + src/jdk.compiler/share/data/symbols/jdk.incubator.foreign-N.sym.txt + src/jdk.compiler/share/data/symbols/jdk.javadoc-N.sym.txt + src/jdk.compiler/share/data/symbols/jdk.jshell-N.sym.txt + src/jdk.compiler/share/data/symbols/jdk.localedata-N.sym.txt + src/jdk.compiler/share/data/symbols/jdk.unsupported-N.sym.txt ! src/jdk.compiler/share/data/symbols/symbols ! test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java ! test/langtools/tools/javac/api/TestGetSourceVersions.java ! test/langtools/tools/javac/classfiles/ClassVersionChecker.java ! test/langtools/tools/javac/lib/JavacTestingAbstractProcessor.java ! test/langtools/tools/javac/preview/classReaderTest/Client.nopreview.out ! test/langtools/tools/javac/preview/classReaderTest/Client.preview.out ! test/langtools/tools/javac/versions/Versions.java Changeset: 2a37764e Author: Kevin Rushforth Committer: Jesper Wilhelmsson Date: 2024-06-06 17:29:58 +0000 URL: https://git.openjdk.org/loom/commit/2a37764e7428d579a3080e62681f1c9c9f816c1e 8333743: Change .jcheck/conf branches property to match valid branches Reviewed-by: erikj, iris ! .jcheck/conf Changeset: 6238bc8d Author: Justin Lu Date: 2024-06-06 20:34:46 +0000 URL: https://git.openjdk.org/loom/commit/6238bc8da2abe7a1f0cdd98c0af01e9ba1869ec3 8333456: CompactNumberFormat integer parsing fails when string has no suffix Reviewed-by: naoto ! src/java.base/share/classes/java/text/CompactNumberFormat.java ! test/jdk/java/text/Format/NumberFormat/LenientParseTest.java Changeset: d8af5894 Author: Jaikiran Pai Date: 2024-06-07 00:35:51 +0000 URL: https://git.openjdk.org/loom/commit/d8af58941b5dedb9774c0971895c4924e57ac28b 8026127: Deflater/Inflater documentation incomplete/misleading Reviewed-by: lancea ! src/java.base/share/classes/java/util/zip/Deflater.java ! src/java.base/share/classes/java/util/zip/Inflater.java + src/java.base/share/classes/java/util/zip/snippet-files/Snippets.java Changeset: 5438d0d4 Author: Alan Bateman Date: 2024-06-07 05:14:58 +0000 URL: https://git.openjdk.org/loom/commit/5438d0d4ee51943b17246164ce7865a605eecd60 Merge ! .jcheck/conf ! .jcheck/conf From duke at openjdk.org Fri Jun 7 05:48:34 2024 From: duke at openjdk.org (duke) Date: Fri, 7 Jun 2024 05:48:34 GMT Subject: git: openjdk/loom: master: 14 new changesets Message-ID: <119a57c8-3f8b-4b2a-82d1-bd881a20cf1d@openjdk.org> Changeset: 1a50bd09 Author: Erik Gahlin Date: 2024-06-06 09:57:30 +0000 URL: https://git.openjdk.org/loom/commit/1a50bd09ef7abfa3709edb388c7dbb003d483561 8322568: JFR: Improve metadata for IEEE rounding mode fields Reviewed-by: mgronlun ! src/hotspot/share/jfr/metadata/metadata.xml ! src/hotspot/share/jfr/support/jfrNativeLibraryLoadEvent.cpp Changeset: f15d423f Author: Saint Wesonga Committer: David Holmes Date: 2024-06-06 11:55:43 +0000 URL: https://git.openjdk.org/loom/commit/f15d423fb5451c7c8f2d1007235ebf8aa79a403e 6942632: Hotspot should be able to use more than 64 logical processors on Windows Reviewed-by: jsjolen, dholmes ! make/test/JtregNativeHotspot.gmk ! src/hotspot/os/windows/globals_windows.hpp ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/os/windows/os_windows.hpp ! test/hotspot/gtest/runtime/test_os_windows.cpp ! test/hotspot/jtreg/TEST.groups + test/hotspot/jtreg/gtest/WindowsProcessorGroups.java + test/hotspot/jtreg/runtime/os/windows/GetAvailableProcessors.java + test/hotspot/jtreg/runtime/os/windows/TestAvailableProcessors.java + test/hotspot/jtreg/runtime/os/windows/exeGetProcessorInfo.c Changeset: 8de5d201 Author: Matthias Baesken Date: 2024-06-06 12:27:26 +0000 URL: https://git.openjdk.org/loom/commit/8de5d2014a87d58d389eb8400f619d1b1fa3abe7 8332865: ubsan: os::attempt_reserve_memory_between reports overflow Reviewed-by: stuefe, clanger ! src/hotspot/share/runtime/os.cpp Changeset: 33fd6ae9 Author: Vladimir Kozlov Date: 2024-06-06 13:41:51 +0000 URL: https://git.openjdk.org/loom/commit/33fd6ae98638d2a4b33d18cc4acee4f0daaa9b35 8333622: ubsan: relocInfo_x86.cpp:101:56: runtime error: pointer index expression with base (-1) overflowed Reviewed-by: thartmann, chagedorn ! src/hotspot/cpu/x86/relocInfo_x86.cpp Changeset: 606df441 Author: Galder Zamarre?o Committer: Martin Doerr Date: 2024-06-06 15:02:22 +0000 URL: https://git.openjdk.org/loom/commit/606df441410a69034b4c113e85ce21937d1a0808 8332670: C1 clone intrinsic needs memory barriers Reviewed-by: shade, thartmann, aph ! src/hotspot/share/c1/c1_GraphBuilder.cpp Changeset: 02f24041 Author: Jorn Vernee Date: 2024-06-06 15:18:18 +0000 URL: https://git.openjdk.org/loom/commit/02f240415cbda5f67a91af50d5974fb001104170 8333560: -Xlint:restricted does not work with --release Co-authored-by: Jan Lahoda Reviewed-by: vromero, mcimadamore ! make/langtools/src/classes/build/tools/symbolgenerator/CreateSymbols.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! test/langtools/tools/javac/RestrictedMethods.java ! test/langtools/tools/javac/RestrictedMethods.out Changeset: d02cb742 Author: Daniel Fuchs Date: 2024-06-06 15:19:50 +0000 URL: https://git.openjdk.org/loom/commit/d02cb742f79e88c6438ca58a6357fe432fb286cb 8333270: HandlersOnComplexResetUpdate and HandlersOnComplexUpdate tests fail with "Unexpected reference" if timeoutFactor is less than 1/3 Reviewed-by: jpai ! test/jdk/java/util/logging/LogManager/Configuration/updateConfiguration/HandlersOnComplexResetUpdate.java ! test/jdk/java/util/logging/LogManager/Configuration/updateConfiguration/HandlersOnComplexUpdate.java Changeset: 487c4771 Author: Emanuel Peter Date: 2024-06-06 15:21:31 +0000 URL: https://git.openjdk.org/loom/commit/487c4771818999749bfd507ab85777795bba0832 8333647: C2 SuperWord: some additional PopulateIndex tests Reviewed-by: kvn, chagedorn ! test/hotspot/jtreg/compiler/vectorization/runner/ArrayIndexFillTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/ArrayShiftOpTest.java Changeset: 9b436d04 Author: Martin Doerr Date: 2024-06-06 15:34:46 +0000 URL: https://git.openjdk.org/loom/commit/9b436d048ec92f74ec6812ae20fde21751927d4b 8333674: Disable CollectorPolicy.young_min_ergo_vm for PPC64 Reviewed-by: mbaesken, zgu ! test/hotspot/gtest/gc/shared/test_collectorPolicy.cpp Changeset: 054362ab Author: Abhishek Kumar Date: 2024-06-06 15:53:09 +0000 URL: https://git.openjdk.org/loom/commit/054362abe040938b87eb1a1cab8a0a94540e0667 8332550: [macos] Voice Over: java.awt.IllegalComponentStateException: component must be showing on the screen to determine its location Reviewed-by: asemenov, kizune, achung ! src/java.desktop/share/classes/javax/swing/table/JTableHeader.java Changeset: 75dc2f85 Author: Joe Darcy Committer: Jesper Wilhelmsson Date: 2024-06-06 16:01:57 +0000 URL: https://git.openjdk.org/loom/commit/75dc2f8518d0adea30f7065d6732b807c0220756 8330182: Start of release updates for JDK 24 8330183: Add SourceVersion.RELEASE_24 8330184: Add source 24 and target 24 to javac Reviewed-by: iris, vromero, asotona, dholmes ! .jcheck/conf ! make/conf/version-numbers.conf ! src/hotspot/share/classfile/classFileParser.cpp ! src/java.base/share/classes/java/lang/classfile/ClassFile.java ! src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java ! src/java.base/share/classes/jdk/internal/org/objectweb/asm/Opcodes.java ! src/java.compiler/share/classes/javax/lang/model/SourceVersion.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitorPreview.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitorPreview.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitorPreview.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitorPreview.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementScanner14.java ! src/java.compiler/share/classes/javax/lang/model/util/ElementScannerPreview.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitorPreview.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitorPreview.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitorPreview.java ! src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor14.java ! src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitorPreview.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassFile.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Target.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java + src/jdk.compiler/share/data/symbols/java.base-N.sym.txt + src/jdk.compiler/share/data/symbols/java.compiler-N.sym.txt + src/jdk.compiler/share/data/symbols/java.desktop-N.sym.txt + src/jdk.compiler/share/data/symbols/java.management-N.sym.txt + src/jdk.compiler/share/data/symbols/java.management.rmi-N.sym.txt + src/jdk.compiler/share/data/symbols/jdk.compiler-N.sym.txt + src/jdk.compiler/share/data/symbols/jdk.httpserver-N.sym.txt + src/jdk.compiler/share/data/symbols/jdk.incubator.foreign-N.sym.txt + src/jdk.compiler/share/data/symbols/jdk.javadoc-N.sym.txt + src/jdk.compiler/share/data/symbols/jdk.jshell-N.sym.txt + src/jdk.compiler/share/data/symbols/jdk.localedata-N.sym.txt + src/jdk.compiler/share/data/symbols/jdk.unsupported-N.sym.txt ! src/jdk.compiler/share/data/symbols/symbols ! test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java ! test/langtools/tools/javac/api/TestGetSourceVersions.java ! test/langtools/tools/javac/classfiles/ClassVersionChecker.java ! test/langtools/tools/javac/lib/JavacTestingAbstractProcessor.java ! test/langtools/tools/javac/preview/classReaderTest/Client.nopreview.out ! test/langtools/tools/javac/preview/classReaderTest/Client.preview.out ! test/langtools/tools/javac/versions/Versions.java Changeset: 2a37764e Author: Kevin Rushforth Committer: Jesper Wilhelmsson Date: 2024-06-06 17:29:58 +0000 URL: https://git.openjdk.org/loom/commit/2a37764e7428d579a3080e62681f1c9c9f816c1e 8333743: Change .jcheck/conf branches property to match valid branches Reviewed-by: erikj, iris ! .jcheck/conf Changeset: 6238bc8d Author: Justin Lu Date: 2024-06-06 20:34:46 +0000 URL: https://git.openjdk.org/loom/commit/6238bc8da2abe7a1f0cdd98c0af01e9ba1869ec3 8333456: CompactNumberFormat integer parsing fails when string has no suffix Reviewed-by: naoto ! src/java.base/share/classes/java/text/CompactNumberFormat.java ! test/jdk/java/text/Format/NumberFormat/LenientParseTest.java Changeset: d8af5894 Author: Jaikiran Pai Date: 2024-06-07 00:35:51 +0000 URL: https://git.openjdk.org/loom/commit/d8af58941b5dedb9774c0971895c4924e57ac28b 8026127: Deflater/Inflater documentation incomplete/misleading Reviewed-by: lancea ! src/java.base/share/classes/java/util/zip/Deflater.java ! src/java.base/share/classes/java/util/zip/Inflater.java + src/java.base/share/classes/java/util/zip/snippet-files/Snippets.java From Alan.Bateman at oracle.com Fri Jun 7 08:02:00 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 7 Jun 2024 09:02:00 +0100 Subject: ScopedValue.runWhere not returning scope In-Reply-To: References: <03b69bde-3f90-428c-aa94-b147a8a18819@littlepinkcloud.com> Message-ID: <3fa62a93-8389-4582-81e7-661d15c2e94d@oracle.com> On 06/06/2024 21:53, Marcin Grzejszczak wrote: > : > > I understand that with great power comes great responsibility and you > want to guard users from cases like "opening and not closing". It's deeper than that. It's about the lifetime of the value and the security and robustness guarantees that go with that. I read your initial mail about instrumentation use-cases, you may need to define that a bit more as it's not clear if this is about bytecode instrumentation to add hooks for telemetry or something else.? In your Proxy example it looks like the user's runnable operation is called from Proxy.run. It's not immediately clear from that example why it's not using ScopedValue.runWhere where ScopedValue's value is the map. -Alan From aph-open at littlepinkcloud.com Fri Jun 7 09:17:26 2024 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Fri, 7 Jun 2024 10:17:26 +0100 Subject: ScopedValue.runWhere not returning scope In-Reply-To: References: <03b69bde-3f90-428c-aa94-b147a8a18819@littlepinkcloud.com> Message-ID: <5574ba45-9798-46e2-b8e5-4f96c99d6062@littlepinkcloud.com> Hi, On 6/6/24 21:53, Marcin Grzejszczak wrote: > > If you consider an execution of a program as a downwards-growing > > stack, a scoped value is bound to some value at one point in the > > stack, and the bound value is visible to all frames below that > > point. That is all: there's no need to consider scopes opening > > and closing. > > In theory that's true. But if we take into consideration frameworks > like Brave [1], Micrometer [2], OpenTelemetry [3] , Apache Camel > [4], Apache Skywalking [5] etc. (so those that work with distributed > tracing) that theoretical viewpoint does not hold. It would be a > gigantic shame if they would need to always rely on ThreadLocals > instead of being able to use the ScopedValues mechanism. I don't understand this. Why would it be a shame? The differences between scoped values and thread-local variables are that scoped values are one-way from caller to callee and strictly nested. The use pattern that you are presenting loses those properties that make scoped values distinct. If you need an unstructured context object you've got a solution already, thread-local variables. Why do you want to use scoped values? > > It's true that this decision makes scoped values less versatile > > than thread-local variables, but on the other hand the hard > > guarantees it provides make programs easier to reason about. On > > balance, we consider the latter more important than the former. > > I completely agree with that however for library instrumentors this > separation is extremely important. Also that would cancel out all > libraries that want to use scoped values and work in an SPI model > where users can add functionalities in an isolated fashion (separate > before and after logic). Can you explain that a little more? Why can't isolated functionality be added without separate before and after logic? > It would require all of the frameworks that I mentioned to > completely rewrite their internals so that the user's code execution > would be wrapped in a e.g. `ScopedValue.runWhere`. That's true. > > We did consider (and even implement) an API with open() and > > close() methods, but we discarded it in order to make the use you > > describe impossible > > I understand that with great power comes great responsibility and > you want to guard users from cases like "opening and not closing". Exactly, and it makes a difference to code quality when we know that a scoped value cannot change during the lifetime of a method, even if other methods are called or if a (virtual) thread is suspended and resumed. A scoped value is effectively constant for the lifetime of a method. Out of curiosity, what do you think should happen, specification wise, if scoped value bindings are closed out of order? > I fully understand that because I've been working in the domain of > distributed tracing for a decade now and I've seen that particular > scenario happen every now and then. It's not a common situation > though. Since you've already implemented it once then you did see > reasons for doing that. Is there a chance to come back to that > discussion? What would need to happen to reopen that conversation > once again? Given that it would lose the most fundamental distinction between thread-local variables and scoped values, I'd say that it'd take some kind of miracle. The point of any structured programming construct is to restrict programmers. Any program may be written with conditional jumps, but we don't do that any more because it makes programs hard to reason about. Anything that you can do with a scoped value you can also do with a thread-local variable, albeit a little less efficiently. The added efficiency of scoped values is a direct result of the restrictions that we place on the way they may be used. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From marcin.grzejszczak at gmail.com Fri Jun 7 13:03:09 2024 From: marcin.grzejszczak at gmail.com (Marcin Grzejszczak) Date: Fri, 7 Jun 2024 13:03:09 +0000 Subject: ScopedValue.runWhere not returning scope In-Reply-To: <5574ba45-9798-46e2-b8e5-4f96c99d6062@littlepinkcloud.com> References: <03b69bde-3f90-428c-aa94-b147a8a18819@littlepinkcloud.com> <5574ba45-9798-46e2-b8e5-4f96c99d6062@littlepinkcloud.com> Message-ID: > I read your initial mail about instrumentation use-cases, you may need to define that a bit more as it's not clear if this is about bytecode instrumentation to add hooks for telemetry or something else. In your Proxy example it looks like the user's runnable operation is called from Proxy.run. It's not immediately clear from that example why it's not using ScopedValue.runWhere where ScopedValue's value is the map. This is not bytecode instrumentation. Let me try to be more specific. Different libraries give users options to run some code before and after some processing is happening. They do that by giving some interceptor interfaces that the user can implement. Such solutions are available in Apache CXF [1], Apache Commons for Http client [2], Datasource Proxy [3], Jersey [4][5], R2DbcProxy [6] etc. Let me provide the same example again but using HTTP terms. Interceptor ``` interface Interceptor { /** * Called before actual method execution * @param map mutable request to pass between methods */ void before(Map map); /** * Called after actual method execution * @param exception potential exception - can be null * @param map mutable request to pass between methods */ void after(Exception exception, Map map) throws Exception; } ``` ThreadLocalInterceptor ``` class ThreadLocalInterceptor implements Interceptor { static final ThreadLocal threadLocal = new ThreadLocal<>(); @Override public void before(Map map) { threadLocal.set("foo"); Closeable scope = threadLocal::remove; map.put("scope", scope); } @Override public void after(Exception exception, Map map) throws Exception { Closeable scope = (Closeable) map.get("scope"); scope.close(); } } ``` RestClient ``` class RestClient { private final Interceptor interceptor; RestClient(Interceptor interceptor) { this.interceptor = interceptor; } void makeAnHttpCall() throws Exception { Map request = new HashMap<>(); Exception exception = null; interceptor.before(request); // E.g. enrich MDC with some values try { // Log sth out - MDC could be enriched with values with the interceptor // in case of Distributed Tracing MDC get enriched with Span and Trace Ids. // Then they are available in the logs. For simplicity, I'm using System.out System.out.println("HELLO [" + ThreadLocalInterceptor.threadLocal.get() + "]"); // MDC would be enriched and logs would contain that set value httpCall(); } catch (Exception ex) { exception = ex; throw ex; } finally { interceptor.after(exception, request); // e.g. clear MDC } } void httpCall() { // Make an HTTP call } } ``` App ``` public class App { public static void main(String[] args) throws Exception { new RestClient(new ThreadLocalInterceptor()).makeAnHttpCall(); System.out.println("Goodbye [" + ThreadLocalInterceptor.threadLocal.get() + "]"); } } ``` > It's not immediately clear from that example why it's not ScopedValue.runWhere where ScopedValue's value is the map. What if the code doesn't want to have direct dependencies to the latest JDK but still needs to support older versions? Typically library maintainers would extract an interface and have a separate module that would be running e.g. JDK21 with an implementation that would use ScopedValues. That's what I meant by the SPI approach. > I don't understand this. Why would it be a shame? The differences between scoped values and thread-local variables are that scoped values are one-way from caller to callee and strictly nested. The use pattern that you are presenting loses those properties that make scoped values distinct. If you need an unstructured context object you've got a solution already, thread-local variables. Why do you want to use scoped values? Because I want to leverage the performance benefit. Maybe I misinterpreted the use case for Scoped Values but my assumption was that when using Scoped Values I will get better performance in comparison to the pure Thread Local approach. In e.g. distributed tracing or security you often need to access current span or current principal and those are retrieved from Thread Local. Each Thread Local call is costly. > Can you explain that a little more? Why can't isolated functionality be added without separate before and after logic? I mentioned that above but I'll try to rephrase it. There are already solutions such as Apache CXF [1], Apache Commons for Http client [2], Datasource Proxy [3], Jersey [4][5], R2DbcProxy [6] that work with such interceptors. All that code would have to be rewritten. I'm not saying that this is not feasible but let's be realistic. Also if all of those libraries wouldn't rewrite their code then distributed tracing would be broken. If one service is not working then instead of one correlation you will get two or more. > Out of curiosity, what do you think should happen, specification wise, if scoped value bindings are closed out of order? That's a fantastic question and I of course had such issues before. If they close out of order then scope hierarchy breaks and you might have memory leaks. That's because scopes know about their parents and wrong parents might be set, and some will never be closed. In Brave [7] you have misalignment assertion errors (only when assertions are turned on) [7] and in OpenTelemetry they are not closing such misaligned scopes [8]. From the spec perspective honestly I don't know what the best solution is. I would have to invest time in doing a proper pros and cons analysis. Of course when someone is manually taking care of opening and closing scopes they must close the scope properly. It's the same case as with all of the Closeables and Autocloseables. > The point of any structured programming construct is to restrict programmers. Any program may be written with conditional jumps, but we don't do that any more because it makes programs hard to reason about. Anything that you can do with a scoped value you can also do with a thread-local variable, albeit a little less efficiently. The added efficiency of scoped values is a direct result of the restrictions that we place on the way they may be used. I mean if there's no distinction in terms of performance between Scoped Values and Thread Locals then we should just need to ensure that there's an interop between Thread Locals and Scoped Values and current implementations could stay on Thread Locals. But I thought that the very idea is to use Scoped Values preferably with Virtual Threads to have best performance in comparison to using Thread Locals. Maybe I made a mistake in this assumption? [1] - https://cxf.apache.org/docs/interceptors.html [2] - https://hc.apache.org/httpcomponents-core-4.4.x/current/httpcore/apidocs/org/apache/http/HttpRequestInterceptor.html (there's one for response too) [3] - https://github.com/jdbc-observations/datasource-proxy/blob/datasource-proxy-1.10/src/main/java/net/ttddyy/dsproxy/listener/QueryExecutionListener.java [4] - https://github.com/eclipse-ee4j/jersey/blob/3.1.7/core-server/src/main/java/org/glassfish/jersey/server/monitoring/ApplicationEventListener.java [5] - https://github.com/eclipse-ee4j/jersey/blob/3.1.7/core-server/src/main/java/org/glassfish/jersey/server/monitoring/RequestEventListener.java [6] - https://github.com/r2dbc/r2dbc-proxy/blob/v1.1.5.RELEASE/src/main/java/io/r2dbc/proxy/listener/ProxyExecutionListener.java [7] - https://github.com/openzipkin/brave/blob/6.0.3/brave/src/main/java/brave/propagation/ThreadLocalSpan.java#L155 [8] - https://github.com/open-telemetry/opentelemetry-java/blob/v1.39.0/context/src/main/java/io/opentelemetry/context/ThreadLocalContextStorage.java#L48 Pozdrawiam / Best regards, Marcin Grzejszczak https://marcin.grzejszczak.pl https://toomuchcoding.com pt., 7 cze 2024 o 09:17 Andrew Haley napisa?(a): > Hi, > > On 6/6/24 21:53, Marcin Grzejszczak wrote: > > > > If you consider an execution of a program as a downwards-growing > > > stack, a scoped value is bound to some value at one point in the > > > stack, and the bound value is visible to all frames below that > > > point. That is all: there's no need to consider scopes opening > > > and closing. > > > > In theory that's true. But if we take into consideration frameworks > > like Brave [1], Micrometer [2], OpenTelemetry [3] , Apache Camel > > [4], Apache Skywalking [5] etc. (so those that work with distributed > > tracing) that theoretical viewpoint does not hold. It would be a > > gigantic shame if they would need to always rely on ThreadLocals > > instead of being able to use the ScopedValues mechanism. > > I don't understand this. Why would it be a shame? The differences > between scoped values and thread-local variables are that scoped > values are one-way from caller to callee and strictly nested. The use > pattern that you are presenting loses those properties that make > scoped values distinct. If you need an unstructured context object > you've got a solution already, thread-local variables. Why do you want > to use scoped values? > > > > It's true that this decision makes scoped values less versatile > > > than thread-local variables, but on the other hand the hard > > > guarantees it provides make programs easier to reason about. On > > > balance, we consider the latter more important than the former. > > > > I completely agree with that however for library instrumentors this > > separation is extremely important. Also that would cancel out all > > libraries that want to use scoped values and work in an SPI model > > where users can add functionalities in an isolated fashion (separate > > before and after logic). > > Can you explain that a little more? Why can't isolated functionality > be added without separate before and after logic? > > > It would require all of the frameworks that I mentioned to > > completely rewrite their internals so that the user's code execution > > would be wrapped in a e.g. `ScopedValue.runWhere`. > > That's true. > > > > We did consider (and even implement) an API with open() and > > > close() methods, but we discarded it in order to make the use you > > > describe impossible > > > > I understand that with great power comes great responsibility and > > you want to guard users from cases like "opening and not closing". > > Exactly, and it makes a difference to code quality when we know that a > scoped value cannot change during the lifetime of a method, even if > other methods are called or if a (virtual) thread is suspended and > resumed. A scoped value is effectively constant for the lifetime of a > method. > > Out of curiosity, what do you think should happen, specification wise, > if scoped value bindings are closed out of order? > > > I fully understand that because I've been working in the domain of > > distributed tracing for a decade now and I've seen that particular > > scenario happen every now and then. It's not a common situation > > though. Since you've already implemented it once then you did see > > reasons for doing that. Is there a chance to come back to that > > discussion? What would need to happen to reopen that conversation > > once again? > > Given that it would lose the most fundamental distinction between > thread-local variables and scoped values, I'd say that it'd take some > kind of miracle. > > The point of any structured programming construct is to restrict > programmers. Any program may be written with conditional jumps, but we > don't do that any more because it makes programs hard to reason about. > Anything that you can do with a scoped value you can also do with a > thread-local variable, albeit a little less efficiently. The added > efficiency of scoped values is a direct result of the restrictions > that we place on the way they may be used. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pedro.lamarao at prodist.com.br Fri Jun 7 14:52:16 2024 From: pedro.lamarao at prodist.com.br (=?UTF-8?Q?Pedro_Lamar=C3=A3o?=) Date: Fri, 7 Jun 2024 11:52:16 -0300 Subject: ScopedValue.runWhere not returning scope In-Reply-To: References: <03b69bde-3f90-428c-aa94-b147a8a18819@littlepinkcloud.com> <5574ba45-9798-46e2-b8e5-4f96c99d6062@littlepinkcloud.com> Message-ID: Em sex., 7 de jun. de 2024 ?s 10:05, Marcin Grzejszczak < marcin.grzejszczak at gmail.com> escreveu: > > Can you explain that a little more? Why can't isolated functionality be > added without separate before and after logic? > > I mentioned that above but I'll try to rephrase it. There are already > solutions such as Apache CXF [1], Apache Commons for Http client [2], > Datasource Proxy [3], Jersey [4][5], R2DbcProxy [6] that work with such > interceptors. All that code would have to be rewritten. I'm not saying that > this is not feasible but let's be realistic. Also if all of those libraries > wouldn't rewrite their code then distributed tracing would be broken. If > one service is not working then instead of one correlation you will get two > or more. > In AspectJ`s terms, interceptors such as these are equivalent to before and after advice. To enable something like a ScopedValueInterceptor, it seems to me sufficient to extend this scheme to include around advices. The handler of AroundInterceptors would pass a proceed object to the around advice. ScopedValueAroundInterceptor would do whatever it wants to do, call scopedValue.runWhere, then call proceed inside that scope. If a design like this was deemed overkill before, perhaps its time has arrived. -- Pedro Lamar?o -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcin.grzejszczak at gmail.com Fri Jun 7 15:02:06 2024 From: marcin.grzejszczak at gmail.com (Marcin Grzejszczak) Date: Fri, 7 Jun 2024 15:02:06 +0000 Subject: ScopedValue.runWhere not returning scope In-Reply-To: References: <03b69bde-3f90-428c-aa94-b147a8a18819@littlepinkcloud.com> <5574ba45-9798-46e2-b8e5-4f96c99d6062@littlepinkcloud.com> Message-ID: > In AspectJ`s terms, interceptors such as these are equivalent to before and after advice. Correct. > To enable something like a ScopedValueInterceptor, it seems to me sufficient to extend this scheme to include around advice. The handler of AroundInterceptors would pass a proceed object to the around advice. ScopedValueAroundInterceptor would do whatever it wants to do, call scopedValue.runWhere, then call proceed inside that scope. Agreed. For this scenario preferably one could use the around advice. That's in the case of an ideal solution where all projects are green fields. But we're not in such a state. > If a design like this was deemed overkill before, perhaps its time has arrived. I wonder if the solution that the library maintainers should be required to migrate to a new design is the proper one. I've only listed 8 projects that Micrometer Observation instruments but I'm pretty sure that there are more. I wonder if such an ask to redesign the API wouldn't be an overkill? Pozdrawiam / Best regards, Marcin Grzejszczak https://marcin.grzejszczak.pl https://toomuchcoding.com pt., 7 cze 2024 o 14:52 Pedro Lamar?o napisa?(a): > Em sex., 7 de jun. de 2024 ?s 10:05, Marcin Grzejszczak < > marcin.grzejszczak at gmail.com> escreveu: > > >> > Can you explain that a little more? Why can't isolated functionality be >> added without separate before and after logic? >> >> I mentioned that above but I'll try to rephrase it. There are already >> solutions such as Apache CXF [1], Apache Commons for Http client [2], >> Datasource Proxy [3], Jersey [4][5], R2DbcProxy [6] that work with such >> interceptors. All that code would have to be rewritten. I'm not saying that >> this is not feasible but let's be realistic. Also if all of those libraries >> wouldn't rewrite their code then distributed tracing would be broken. If >> one service is not working then instead of one correlation you will get two >> or more. >> > > In AspectJ`s terms, interceptors such as these are equivalent to before > and after advice. > To enable something like a ScopedValueInterceptor, it seems to me > sufficient to extend this scheme to include around advices. > The handler of AroundInterceptors would pass a proceed object to the > around advice. > ScopedValueAroundInterceptor would do whatever it wants to do, call > scopedValue.runWhere, then call proceed inside that scope. > If a design like this was deemed overkill before, perhaps its time has > arrived. > > -- > Pedro Lamar?o > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at icloud.com Fri Jun 7 15:11:39 2024 From: robaho at icloud.com (robert engels) Date: Fri, 7 Jun 2024 10:11:39 -0500 Subject: ScopedValue.runWhere not returning scope In-Reply-To: References: Message-ID: <1CF028EA-21DF-4A6A-B171-F82A6AFD0CB8@icloud.com> An HTML attachment was scrubbed... URL: From marcin.grzejszczak at gmail.com Fri Jun 7 15:14:42 2024 From: marcin.grzejszczak at gmail.com (Marcin Grzejszczak) Date: Fri, 7 Jun 2024 15:14:42 +0000 Subject: ScopedValue.runWhere not returning scope In-Reply-To: <1CF028EA-21DF-4A6A-B171-F82A6AFD0CB8@icloud.com> References: <1CF028EA-21DF-4A6A-B171-F82A6AFD0CB8@icloud.com> Message-ID: > I am struggling to understand the concern. If you have a TL based solution just stick with it. If the people are changing their code to use VT then they are probably redesigning anyway - e.g. removing any async. Let me quote one of my previous replies: "I mean if there's no distinction in terms of performance between Scoped Values and Thread Locals then we should just need to ensure that there's an interop between Thread Locals and Scoped Values and current implementations could stay on Thread Locals. But I thought that the very idea is to use Scoped Values preferably with Virtual Threads to have best performance in comparison to using Thread Locals. Maybe I made a mistake in this assumption?". > If they are redesigning they can use an interceptor based solution that is designed for scoped variables. That would require a lot of libraries to redesign their API. I'm not saying this is a bad thing but that might be a lot of work on many different projects. Also some libraries will migrate, some won't so there needs to be an interop between TL and SV. Pozdrawiam / Best regards, Marcin Grzejszczak https://marcin.grzejszczak.pl https://toomuchcoding.com pt., 7 cze 2024 o 15:11 robert engels napisa?(a): > I am struggling to understand the concern. If you have a TL based solution > just stick with it. If the people are changing their code to use VT then > they are probably redesigning anyway - e.g. removing any async. > > If they are redesigning they can use an interceptor based solution that is > designed for scoped variables. > > On Jun 7, 2024, at 10:03?AM, Marcin Grzejszczak < > marcin.grzejszczak at gmail.com> wrote: > > ? > > In AspectJ`s terms, interceptors such as these are equivalent to before > and after advice. > > Correct. > > > To enable something like a ScopedValueInterceptor, it seems to me > sufficient to extend this scheme to include around advice. The handler of > AroundInterceptors would pass a proceed object to the around advice. > ScopedValueAroundInterceptor would do whatever it wants to do, call > scopedValue.runWhere, then call proceed inside that scope. > > Agreed. For this scenario preferably one could use the around advice. > That's in the case of an ideal solution where all projects are green > fields. But we're not in such a state. > > > If a design like this was deemed overkill before, perhaps its time has > arrived. > > I wonder if the solution that the library maintainers should be required > to migrate to a new design is the proper one. I've only listed 8 projects > that Micrometer Observation instruments but I'm pretty sure that there are > more. I wonder if such an ask to redesign the API wouldn't be an overkill? > > Pozdrawiam / Best regards, > Marcin Grzejszczak > > https://marcin.grzejszczak.pl > https://toomuchcoding.com > > > pt., 7 cze 2024 o 14:52 Pedro Lamar?o > napisa?(a): > >> Em sex., 7 de jun. de 2024 ?s 10:05, Marcin Grzejszczak < >> marcin.grzejszczak at gmail.com> escreveu: >> >> >>> > Can you explain that a little more? Why can't isolated functionality >>> be added without separate before and after logic? >>> >>> I mentioned that above but I'll try to rephrase it. There are already >>> solutions such as Apache CXF [1], Apache Commons for Http client [2], >>> Datasource Proxy [3], Jersey [4][5], R2DbcProxy [6] that work with such >>> interceptors. All that code would have to be rewritten. I'm not saying that >>> this is not feasible but let's be realistic. Also if all of those libraries >>> wouldn't rewrite their code then distributed tracing would be broken. If >>> one service is not working then instead of one correlation you will get two >>> or more. >>> >> >> In AspectJ`s terms, interceptors such as these are equivalent to before >> and after advice. >> To enable something like a ScopedValueInterceptor, it seems to me >> sufficient to extend this scheme to include around advices. >> The handler of AroundInterceptors would pass a proceed object to the >> around advice. >> ScopedValueAroundInterceptor would do whatever it wants to do, call >> scopedValue.runWhere, then call proceed inside that scope. >> If a design like this was deemed overkill before, perhaps its time has >> arrived. >> >> -- >> Pedro Lamar?o >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at icloud.com Fri Jun 7 15:39:23 2024 From: robaho at icloud.com (robert engels) Date: Fri, 7 Jun 2024 10:39:23 -0500 Subject: ScopedValue.runWhere not returning scope In-Reply-To: References: Message-ID: <872DA66A-CBCB-4FB3-A029-429FBBB53B53@icloud.com> An HTML attachment was scrubbed... URL: From cushon at google.com Fri Jun 7 18:55:06 2024 From: cushon at google.com (Liam Miller-Cushon) Date: Fri, 7 Jun 2024 11:55:06 -0700 Subject: pluggable schedulers In-Reply-To: <1d507d1d-7539-48b6-9610-c4f640afab0f@oracle.com> References: <1d507d1d-7539-48b6-9610-c4f640afab0f@oracle.com> Message-ID: Thanks Alan! It looks like this is the commit that removed the prototype? https://github.com/openjdk/loom/commit/cad26ce74c98e28854f02106117fe03741f69ba0 I'll see if that's enough to experiment with, and will report back if I have any feedback in case that's useful if this is revisited in the future. On Thu, Jun 6, 2024 at 9:37?PM Alan Bateman wrote: > On 07/06/2024 01:51, Liam Miller-Cushon wrote: > > Hi, > > > > There were some mentions of 'pluggable schedulers' in the early Loom > > docs [1][2] that would have allowed users to replace ForkJoinPool with > > a custom scheduler, but it wasn't included in the later proposals. I > > found a mention on loom-dev@ in 2022 that they were 'being worked on > > but were not delivered in JEP 425' [3]. > > > > I'm curious what became of that idea--is it still possible future > > work, or was a decision made not to support that at some point? > > It's a feature that we have to be very cautious about. The EA builds > exposed a prototype API for a long time but there wasn't much feedback. > Definitely not enough usage to help decide what hooks to expose. The API > (not the implementation support) was pulled when preparing the proposal > for the main line (JEP 425). There is interest in some areas to explore > the topic again, just nothing definite (no JEP) at this time. > > -Alan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Sat Jun 8 17:02:32 2024 From: duke at openjdk.org (duke) Date: Sat, 8 Jun 2024 17:02:32 GMT Subject: git: openjdk/loom: fibers: 27 new changesets Message-ID: <7c1c3568-4786-41a6-8064-a56a5a2c05cc@openjdk.org> Changeset: 944aeb81 Author: Emanuel Peter Date: 2024-06-07 05:01:23 +0000 URL: https://git.openjdk.org/loom/commit/944aeb81b16e3e7a3019cafdefe67b797fa6be96 8325155: C2 SuperWord: remove alignment boundaries Reviewed-by: chagedorn, kvn ! src/hotspot/share/opto/superword.cpp ! src/hotspot/share/opto/superword.hpp ! src/hotspot/share/opto/traceAutoVectorizationTag.hpp ! src/hotspot/share/opto/vectorization.cpp ! src/hotspot/share/opto/vectorization.hpp + test/hotspot/jtreg/compiler/loopopts/superword/TestCompatibleUseDefTypeSize.java ! test/hotspot/jtreg/compiler/loopopts/superword/TestSplitPacks.java Changeset: e5383d71 Author: Emanuel Peter Date: 2024-06-07 05:04:11 +0000 URL: https://git.openjdk.org/loom/commit/e5383d710c0727181a2f0b569a881de2492e3683 8333713: C2 SuperWord: cleanup in vectornode.cpp/hpp Reviewed-by: chagedorn, kvn ! src/hotspot/share/opto/vectornode.cpp ! src/hotspot/share/opto/vectornode.hpp Changeset: b4beda21 Author: Emanuel Peter Date: 2024-06-07 05:07:03 +0000 URL: https://git.openjdk.org/loom/commit/b4beda21b487886b022e04766e140e6d1df1038a 8332537: C2: High memory usage reported for compiler/loopopts/superword/TestAlignVectorFuzzer.java Reviewed-by: kvn, thartmann, stuefe ! test/hotspot/jtreg/compiler/loopopts/superword/TestAlignVectorFuzzer.java Changeset: f7862bd6 Author: Richard Reingruber Date: 2024-06-07 06:16:03 +0000 URL: https://git.openjdk.org/loom/commit/f7862bd6b9994814c6dfd43d471122408601f288 8331311: C2: Big Endian Port of 8318446: optimize stores into primitive arrays by combining values into larger store Reviewed-by: epeter, kvn ! src/hotspot/share/opto/memnode.cpp ! test/hotspot/jtreg/compiler/c2/TestMergeStores.java ! test/hotspot/jtreg/compiler/lib/ir_framework/test/IREncodingPrinter.java Changeset: 8ffc35d1 Author: Matthias Baesken Date: 2024-06-07 07:12:55 +0000 URL: https://git.openjdk.org/loom/commit/8ffc35d117846a7a2aa08afed662273d2f887770 8333724: Problem list security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java#teliasonerarootcav1 Reviewed-by: lucy, serb ! test/jdk/ProblemList.txt Changeset: bf7f1c41 Author: Thomas Stuefe Date: 2024-06-07 07:34:58 +0000 URL: https://git.openjdk.org/loom/commit/bf7f1c41cc2a2b98775301bc377a4c6e1340a736 8333211: NMT Reports: replace manual indentation handling with auto indent Reviewed-by: jsjolen, asmehra ! src/hotspot/share/memory/arena.hpp ! src/hotspot/share/nmt/memReporter.cpp ! src/hotspot/share/nmt/memReporter.hpp ! src/hotspot/share/nmt/memoryFileTracker.cpp ! src/hotspot/share/utilities/nativeCallStack.cpp ! src/hotspot/share/utilities/nativeCallStack.hpp ! src/hotspot/share/utilities/ostream.cpp ! src/hotspot/share/utilities/ostream.hpp ! test/hotspot/gtest/utilities/test_ostream.cpp Changeset: a2030fff Author: Albert Mingkun Yang Date: 2024-06-07 08:12:38 +0000 URL: https://git.openjdk.org/loom/commit/a2030fff9833aba40e8c7c177151a30a0812a250 8332516: Serial: Always sample promoted bytes to avoid getting stuck in Full GCs Reviewed-by: iwalulya, tschatzl ! src/hotspot/share/gc/serial/serialHeap.cpp ! src/hotspot/share/gc/serial/serialHeap.hpp ! src/hotspot/share/gc/serial/tenuredGeneration.cpp ! src/hotspot/share/gc/serial/tenuredGeneration.hpp Changeset: 6968770b Author: Varada M Committer: Amit Kumar Date: 2024-06-07 08:24:15 +0000 URL: https://git.openjdk.org/loom/commit/6968770b1e918c74fc009e3562a827bb4acbe2d7 8331935: Add support for primitive array C1 clone intrinsic in PPC Reviewed-by: mdoerr, amitkumar ! src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp ! src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp ! src/hotspot/cpu/ppc/c1_MacroAssembler_ppc.cpp ! src/hotspot/cpu/ppc/c1_MacroAssembler_ppc.hpp ! src/hotspot/share/c1/c1_Compiler.cpp ! src/hotspot/share/c1/c1_LIR.cpp Changeset: 40b2fbd8 Author: Varada M Committer: Martin Doerr Date: 2024-06-07 08:50:41 +0000 URL: https://git.openjdk.org/loom/commit/40b2fbd8207404961d3d23375b288cceafc3f902 8331733: [PPC64] saving and restoring CR is not needed at most places Reviewed-by: mdoerr, amitkumar ! src/hotspot/cpu/ppc/downcallLinker_ppc.cpp ! src/hotspot/cpu/ppc/gc/g1/g1BarrierSetAssembler_ppc.cpp ! src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp ! src/hotspot/cpu/ppc/gc/x/xBarrierSetAssembler_ppc.cpp ! src/hotspot/cpu/ppc/gc/z/zBarrierSetAssembler_ppc.cpp ! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp ! src/hotspot/cpu/ppc/macroAssembler_ppc.hpp ! src/hotspot/cpu/ppc/methodHandles_ppc.cpp ! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp ! src/hotspot/cpu/ppc/stubGenerator_ppc.cpp ! src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp Changeset: 486dee2c Author: Johan Sj?len Date: 2024-06-07 12:17:52 +0000 URL: https://git.openjdk.org/loom/commit/486dee2cf420981b4c8111c24c5fbd27aceb238b 8333653: Remove MallocHeader::get_stack Reviewed-by: stuefe ! src/hotspot/share/nmt/mallocHeader.cpp ! src/hotspot/share/nmt/mallocHeader.hpp ! src/hotspot/share/nmt/mallocSiteTable.hpp ! src/hotspot/share/nmt/mallocTracker.cpp Changeset: d130d2f4 Author: SendaoYan Committer: Julian Waters Date: 2024-06-07 13:36:05 +0000 URL: https://git.openjdk.org/loom/commit/d130d2f4f46d37a2b924343de19d012c129b0a55 8333477: Delete extra empty spaces in Makefiles Reviewed-by: erikj, chagedorn, liach, jwaters ! src/jdk.hotspot.agent/test/libproc/Makefile ! src/utils/LogCompilation/Makefile ! test/jdk/java/rmi/reliability/benchmark/bench/Makefile ! test/jdk/java/rmi/reliability/benchmark/bench/rmi/Makefile ! test/jdk/javax/crypto/SecretKeyFactory/evilprov/Makefile Changeset: d744059b Author: Claes Redestad Date: 2024-06-07 14:50:29 +0000 URL: https://git.openjdk.org/loom/commit/d744059b5b3e944bee53536de6f404666e45e8e5 8333774: Avoid eagerly loading various EmptySpliterator classes Reviewed-by: liach, pminborg ! src/java.base/share/classes/java/util/Spliterators.java Changeset: ee82346b Author: Jorn Vernee Date: 2024-06-07 15:40:59 +0000 URL: https://git.openjdk.org/loom/commit/ee82346bd5ecf3024d6dc7b7529598099483a42c 8325984: 4 jcstress tests are failing in Tier6 4 times each Reviewed-by: shade ! test/hotspot/jtreg/ProblemList.txt Changeset: 25ad8623 Author: Naoto Sato Date: 2024-06-07 16:22:02 +0000 URL: https://git.openjdk.org/loom/commit/25ad86234a7cd6e606b273f3e63351aa07c567a3 8332161: Test restoring echo in the Console implementation (java.base) Reviewed-by: joehw, prappo + test/jdk/java/io/Console/RestoreEchoTest.java + test/jdk/java/io/Console/restoreEcho.exp Changeset: 8e72d7cf Author: Scott Gibbons Committer: Jatin Bhateja Date: 2024-06-07 17:02:14 +0000 URL: https://git.openjdk.org/loom/commit/8e72d7cf8e7dfc7eb9e66bc562f125f947e37f49 8320448: Accelerate IndexOf using AVX2 Reviewed-by: epeter, kvn, sviswanathan ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.hpp + src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.hpp ! src/hotspot/cpu/x86/stubRoutines_x86.hpp ! src/hotspot/share/opto/escape.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/opto/runtime.cpp ! src/hotspot/share/opto/runtime.hpp ! src/hotspot/share/runtime/stubRoutines.cpp ! src/hotspot/share/runtime/stubRoutines.hpp ! test/jdk/TEST.ROOT + test/jdk/java/lang/String/IndexOf.java + test/jdk/java/lang/StringBuffer/ECoreIndexOf.java + test/micro/org/openjdk/bench/java/lang/StringIndexOfHuge.java Changeset: 512b2b4f Author: Sonia Zaldana Calles Committer: Thomas Stuefe Date: 2024-06-07 17:36:30 +0000 URL: https://git.openjdk.org/loom/commit/512b2b4f141f9a202984150b0427372e1a409a50 8330420: Inverted use of DisplayVMOutputToStderr in ostream_exit Reviewed-by: jsjolen, stuefe ! src/hotspot/share/utilities/ostream.cpp Changeset: 17bd483f Author: Alex Menkov Date: 2024-06-07 19:30:37 +0000 URL: https://git.openjdk.org/loom/commit/17bd483ff01e463cef45824f0c1296a8f3e782c8 8333680: com/sun/tools/attach/BasicTests.java fails with "SocketException: Permission denied: connect" Reviewed-by: sspitsyn, kevinw, lmesnik ! test/jdk/com/sun/tools/attach/Agent.java ! test/jdk/com/sun/tools/attach/BasicTests.java ! test/jdk/com/sun/tools/attach/RedefineAgent.java Changeset: c37d02ae Author: Elif Aslan Committer: Paul Hohensee Date: 2024-06-07 19:32:57 +0000 URL: https://git.openjdk.org/loom/commit/c37d02aef38da178fcf56e3c5cccc41cc5175421 8312412: Uninitialized klassVtable::_verify_count field Reviewed-by: shade, phh ! src/hotspot/share/oops/klassVtable.hpp Changeset: 18e7d7b5 Author: Neethu Prasad Committer: Paul Hohensee Date: 2024-06-07 20:03:10 +0000 URL: https://git.openjdk.org/loom/commit/18e7d7b5e710b24e49b995777906a197e35795e6 8333716: Shenandoah: Check for disarmed method before taking the nmethod lock Reviewed-by: shade, ysr, wkemper ! src/hotspot/share/gc/shenandoah/shenandoahBarrierSetNMethod.cpp Changeset: cf677c90 Author: Joe Darcy Date: 2024-06-07 20:38:17 +0000 URL: https://git.openjdk.org/loom/commit/cf677c901e70d98404ec9cc3d75a93926e02fcd2 8333823: Update --release 23 symbol information for JDK 23 build 26 Reviewed-by: iris, jjg ! src/jdk.compiler/share/data/symbols/java.base-N.sym.txt ! src/jdk.compiler/share/data/symbols/java.desktop-N.sym.txt ! src/jdk.compiler/share/data/symbols/jdk.jshell-N.sym.txt Changeset: a6fc2f83 Author: Amit Kumar Date: 2024-06-08 04:41:45 +0000 URL: https://git.openjdk.org/loom/commit/a6fc2f839a5e494b940ee473cbd942ec5f884324 8333412: [s390x] Add support for branch on count instruction Reviewed-by: lucy, mdoerr ! src/hotspot/cpu/s390/assembler_s390.hpp ! src/hotspot/cpu/s390/assembler_s390.inline.hpp Changeset: 79d3f4c8 Author: Alan Bateman Date: 2024-06-08 14:59:59 +0000 URL: https://git.openjdk.org/loom/commit/79d3f4c8b5f476896b1ed26313930f8fc9480e5e Merge ! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp ! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp ! src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.hpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.hpp ! src/hotspot/cpu/x86/stubRoutines_x86.hpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/runtime/stubRoutines.cpp ! src/hotspot/share/runtime/stubRoutines.hpp ! test/hotspot/jtreg/ProblemList.txt ! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp ! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp ! src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.hpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ! src/hotspot/cpu/x86/stubGenerator_x86_64.hpp ! src/hotspot/cpu/x86/stubRoutines_x86.hpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/runtime/stubRoutines.cpp ! src/hotspot/share/runtime/stubRoutines.hpp ! test/hotspot/jtreg/ProblemList.txt Changeset: 818bfc92 Author: Alan Bateman Date: 2024-06-07 10:27:33 +0000 URL: https://git.openjdk.org/loom/commit/818bfc9204bb545254d08136f96ad5fce2d83c65 Better output from stress tests to help diagnose timeouts ! test/jdk/java/lang/Thread/virtual/MonitorsTest.java + test/jdk/java/lang/Thread/virtual/stress/CompletableFutureTimedGet.java ! test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALotWhenBlocked.java ! test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java ! test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALotWithTimedWait.java ! test/jdk/java/lang/Thread/virtual/stress/PinALot.java ! test/jdk/java/lang/Thread/virtual/stress/PingPong.java ! test/jdk/java/lang/Thread/virtual/stress/Skynet.java ! test/jdk/java/lang/Thread/virtual/stress/Skynet100kWithMonitors.java ! test/jdk/java/lang/Thread/virtual/stress/SleepALot.java - test/jdk/java/lang/Thread/virtual/stress/TimedGet.java ! test/jdk/java/lang/Thread/virtual/stress/YieldALot.java Changeset: 73c8d1d0 Author: Alan Bateman Date: 2024-06-07 18:01:01 +0000 URL: https://git.openjdk.org/loom/commit/73c8d1d018652ba95e3b5d165803979f2fbe4537 Retry submit when unpark fails with OOME ! src/java.base/share/classes/java/lang/VirtualThread.java ! src/java.base/share/classes/sun/nio/ch/Poller.java ! test/jdk/java/lang/Thread/virtual/CustomScheduler.java Changeset: 698bcad9 Author: Alan Bateman Date: 2024-06-07 18:02:42 +0000 URL: https://git.openjdk.org/loom/commit/698bcad92a9ed004919be1514349edef3014ac73 Remove sun/security/ssl/SSLSessionImpl/ResumptionUpdateBoundValues.java from exclude list ! test/jdk/ProblemList-Virtual.txt Changeset: 5f51a99b Author: Alan Bateman Date: 2024-06-08 10:12:17 +0000 URL: https://git.openjdk.org/loom/commit/5f51a99be3b92a65e6c424b15f00fd63774abc98 Whitespace ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java Changeset: a147e545 Author: Alan Bateman Date: 2024-06-08 15:02:53 +0000 URL: https://git.openjdk.org/loom/commit/a147e54503381496a85efe16e0bbc8e20913abd1 Merge From marcin.grzejszczak at gmail.com Mon Jun 10 14:48:13 2024 From: marcin.grzejszczak at gmail.com (Marcin Grzejszczak) Date: Mon, 10 Jun 2024 14:48:13 +0000 Subject: ScopedValue.runWhere not returning scope In-Reply-To: <872DA66A-CBCB-4FB3-A029-429FBBB53B53@icloud.com> References: <872DA66A-CBCB-4FB3-A029-429FBBB53B53@icloud.com> Message-ID: OK, but can we confirm some assumptions first? Do I understand correctly that ScopedValues will be significantly faster than Thread Locals? If that's the case just by returning a Scope object instead of expecting a lambda all the tracing libraries and all instrumentations that are out there will not need a major redesign. I think that it's worthwhile to consider such an option in that scenario. Pozdrawiam / Best regards, Marcin Grzejszczak https://marcin.grzejszczak.pl https://toomuchcoding.com pt., 7 cze 2024 o 15:39 robert engels napisa?(a): > My understanding is that the only performance downside to TL is due to the > sheer number of threads possible vs a platform thread solution. Most likely > existing tracing solutions are not designed to support this anyway - it > would orders of magnitude more tracing information to track and > disseminate. If the tracing solution already supports high volume async > requests it?s doubtful it uses TL based solutions as the would be needless > overhead. > > If you don?t redesign the software to take advantage of VT then it won?t > matter. > > I expect someone will design a VT optimized tracing solution though. I > also expect the TL based solutions will still work though - maybe not > optimally. > > On Jun 7, 2024, at 10:15?AM, Marcin Grzejszczak < > marcin.grzejszczak at gmail.com> wrote: > > ? > > I am struggling to understand the concern. If you have a TL based > solution just stick with it. If the people are changing their code to use > VT then they are probably redesigning anyway - e.g. removing any async. > > Let me quote one of my previous replies: "I mean if there's no distinction > in terms of performance between Scoped Values and Thread Locals then we > should just need to ensure that there's an interop between Thread Locals > and Scoped Values and current implementations could stay on Thread Locals. > But I thought that the very idea is to use Scoped Values preferably with > Virtual Threads to have best performance in comparison to using Thread > Locals. Maybe I made a mistake in this assumption?". > > > If they are redesigning they can use an interceptor based solution that > is designed for scoped variables. > > That would require a lot of libraries to redesign their API. I'm not > saying this is a bad thing but that might be a lot of work on many > different projects. Also some libraries will migrate, some won't so there > needs to be an interop between TL and SV. > > Pozdrawiam / Best regards, > Marcin Grzejszczak > > https://marcin.grzejszczak.pl > https://toomuchcoding.com > > > pt., 7 cze 2024 o 15:11 robert engels napisa?(a): > >> I am struggling to understand the concern. If you have a TL based >> solution just stick with it. If the people are changing their code to use >> VT then they are probably redesigning anyway - e.g. removing any async. >> >> If they are redesigning they can use an interceptor based solution that >> is designed for scoped variables. >> >> On Jun 7, 2024, at 10:03?AM, Marcin Grzejszczak < >> marcin.grzejszczak at gmail.com> wrote: >> >> ? >> > In AspectJ`s terms, interceptors such as these are equivalent to before >> and after advice. >> >> Correct. >> >> > To enable something like a ScopedValueInterceptor, it seems to me >> sufficient to extend this scheme to include around advice. The handler of >> AroundInterceptors would pass a proceed object to the around advice. >> ScopedValueAroundInterceptor would do whatever it wants to do, call >> scopedValue.runWhere, then call proceed inside that scope. >> >> Agreed. For this scenario preferably one could use the around advice. >> That's in the case of an ideal solution where all projects are green >> fields. But we're not in such a state. >> >> > If a design like this was deemed overkill before, perhaps its time has >> arrived. >> >> I wonder if the solution that the library maintainers should be required >> to migrate to a new design is the proper one. I've only listed 8 projects >> that Micrometer Observation instruments but I'm pretty sure that there are >> more. I wonder if such an ask to redesign the API wouldn't be an overkill? >> >> Pozdrawiam / Best regards, >> Marcin Grzejszczak >> >> https://marcin.grzejszczak.pl >> https://toomuchcoding.com >> >> >> pt., 7 cze 2024 o 14:52 Pedro Lamar?o >> napisa?(a): >> >>> Em sex., 7 de jun. de 2024 ?s 10:05, Marcin Grzejszczak < >>> marcin.grzejszczak at gmail.com> escreveu: >>> >>> >>>> > Can you explain that a little more? Why can't isolated functionality >>>> be added without separate before and after logic? >>>> >>>> I mentioned that above but I'll try to rephrase it. There are already >>>> solutions such as Apache CXF [1], Apache Commons for Http client [2], >>>> Datasource Proxy [3], Jersey [4][5], R2DbcProxy [6] that work with such >>>> interceptors. All that code would have to be rewritten. I'm not saying that >>>> this is not feasible but let's be realistic. Also if all of those libraries >>>> wouldn't rewrite their code then distributed tracing would be broken. If >>>> one service is not working then instead of one correlation you will get two >>>> or more. >>>> >>> >>> In AspectJ`s terms, interceptors such as these are equivalent to before >>> and after advice. >>> To enable something like a ScopedValueInterceptor, it seems to me >>> sufficient to extend this scheme to include around advices. >>> The handler of AroundInterceptors would pass a proceed object to the >>> around advice. >>> ScopedValueAroundInterceptor would do whatever it wants to do, call >>> scopedValue.runWhere, then call proceed inside that scope. >>> If a design like this was deemed overkill before, perhaps its time has >>> arrived. >>> >>> -- >>> Pedro Lamar?o >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at icloud.com Mon Jun 10 15:13:55 2024 From: robaho at icloud.com (Robert Engels) Date: Mon, 10 Jun 2024 10:13:55 -0500 Subject: ScopedValue.runWhere not returning scope In-Reply-To: References: <872DA66A-CBCB-4FB3-A029-429FBBB53B53@icloud.com> Message-ID: I?m sorry, I am not following your reasoning. If they are not redesigning their applications to use VT threads, there is no reason to change anything. The number of threads will stay the same, and the difference in performance between TL and SV won?t have any significance. If they redesign their applications to use VT - then there could potentially be millions of threads/requests - all unique - so it needs a different sort of tracing methodology anyway - regardless of whether scoped values perform better than thread locals - so they will need a different tracing library/api. Just presenting this data is a challenge. I suggest you look at Go and its tracing facilities. It is a problem there as well for these situations. It?s not a trivial problem to solve (visualizing/using tracing data from potentially millions of active threads). Same goes with debugging. Check out github.com/robaho/goanalyzer and the linked issues. As to the specific question as to whether SV will outperform TL, I gather the answer is ?it depends? (and Ron/Alan are certainly the authoritative persons). But reading the JEP, https://openjdk.org/jeps/446 it seems clear that the performance gains are from immutability (easier sharing, lower memory footprint vs inherited TL) and the aspects related to having potentially millions of them - which brings me back to my original point. From the JEP... "In general, we advise migration to scoped values when the purpose of a thread-local variable aligns with the goal of a scoped value: one-way transmission of unchanging data.? - which doesn?t appear to align with a tracing library, but it probably depends on how it used/implemented. > On Jun 10, 2024, at 9:48 AM, Marcin Grzejszczak wrote: > > OK, but can we confirm some assumptions first? > > Do I understand correctly that ScopedValues will be significantly faster than Thread Locals? If that's the case just by returning a Scope object instead of expecting a lambda all the tracing libraries and all instrumentations that are out there will not need a major redesign. I think that it's worthwhile to consider such an option in that scenario. > > Pozdrawiam / Best regards, > Marcin Grzejszczak > > https://marcin.grzejszczak.pl > https://toomuchcoding.com > > pt., 7 cze 2024 o 15:39 robert engels > napisa?(a): > My understanding is that the only performance downside to TL is due to the sheer number of threads possible vs a platform thread solution. Most likely existing tracing solutions are not designed to support this anyway - it would orders of magnitude more tracing information to track and disseminate. If the tracing solution already supports high volume async requests it?s doubtful it uses TL based solutions as the would be needless overhead. > > If you don?t redesign the software to take advantage of VT then it won?t matter. > > I expect someone will design a VT optimized tracing solution though. I also expect the TL based solutions will still work though - maybe not optimally. > >> On Jun 7, 2024, at 10:15?AM, Marcin Grzejszczak > wrote: >> >> ? >> > I am struggling to understand the concern. If you have a TL based solution just stick with it. If the people are changing their code to use VT then they are probably redesigning anyway - e.g. removing any async. >> >> Let me quote one of my previous replies: "I mean if there's no distinction in terms of performance between Scoped Values and Thread Locals then we should just need to ensure that there's an interop between Thread Locals and Scoped Values and current implementations could stay on Thread Locals. But I thought that the very idea is to use Scoped Values preferably with Virtual Threads to have best performance in comparison to using Thread Locals. Maybe I made a mistake in this assumption?". >> >> > If they are redesigning they can use an interceptor based solution that is designed for scoped variables. >> >> That would require a lot of libraries to redesign their API. I'm not saying this is a bad thing but that might be a lot of work on many different projects. Also some libraries will migrate, some won't so there needs to be an interop between TL and SV. >> >> Pozdrawiam / Best regards, >> Marcin Grzejszczak >> >> https://marcin.grzejszczak.pl >> https://toomuchcoding.com >> >> pt., 7 cze 2024 o 15:11 robert engels > napisa?(a): >> I am struggling to understand the concern. If you have a TL based solution just stick with it. If the people are changing their code to use VT then they are probably redesigning anyway - e.g. removing any async. >> >> If they are redesigning they can use an interceptor based solution that is designed for scoped variables. >> >>> On Jun 7, 2024, at 10:03?AM, Marcin Grzejszczak > wrote: >>> >>> ? >>> > In AspectJ`s terms, interceptors such as these are equivalent to before and after advice. >>> >>> Correct. >>> >>> > To enable something like a ScopedValueInterceptor, it seems to me sufficient to extend this scheme to include around advice. The handler of AroundInterceptors would pass a proceed object to the around advice. ScopedValueAroundInterceptor would do whatever it wants to do, call scopedValue.runWhere, then call proceed inside that scope. >>> >>> Agreed. For this scenario preferably one could use the around advice. That's in the case of an ideal solution where all projects are green fields. But we're not in such a state. >>> >>> > If a design like this was deemed overkill before, perhaps its time has arrived. >>> >>> I wonder if the solution that the library maintainers should be required to migrate to a new design is the proper one. I've only listed 8 projects that Micrometer Observation instruments but I'm pretty sure that there are more. I wonder if such an ask to redesign the API wouldn't be an overkill? >>> >>> Pozdrawiam / Best regards, >>> Marcin Grzejszczak >>> >>> https://marcin.grzejszczak.pl >>> https://toomuchcoding.com >>> >>> pt., 7 cze 2024 o 14:52 Pedro Lamar?o > napisa?(a): >>> Em sex., 7 de jun. de 2024 ?s 10:05, Marcin Grzejszczak > escreveu: >>> >>> > Can you explain that a little more? Why can't isolated functionality be added without separate before and after logic? >>> >>> I mentioned that above but I'll try to rephrase it. There are already solutions such as Apache CXF [1], Apache Commons for Http client [2], Datasource Proxy [3], Jersey [4][5], R2DbcProxy [6] that work with such interceptors. All that code would have to be rewritten. I'm not saying that this is not feasible but let's be realistic. Also if all of those libraries wouldn't rewrite their code then distributed tracing would be broken. If one service is not working then instead of one correlation you will get two or more. >>> >>> In AspectJ`s terms, interceptors such as these are equivalent to before and after advice. >>> To enable something like a ScopedValueInterceptor, it seems to me sufficient to extend this scheme to include around advices. >>> The handler of AroundInterceptors would pass a proceed object to the around advice. >>> ScopedValueAroundInterceptor would do whatever it wants to do, call scopedValue.runWhere, then call proceed inside that scope. >>> If a design like this was deemed overkill before, perhaps its time has arrived. >>> >>> -- >>> Pedro Lamar?o -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph-open at littlepinkcloud.com Mon Jun 10 16:18:27 2024 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Mon, 10 Jun 2024 17:18:27 +0100 Subject: ScopedValue.runWhere not returning scope In-Reply-To: References: <872DA66A-CBCB-4FB3-A029-429FBBB53B53@icloud.com> Message-ID: On 6/10/24 15:48, Marcin Grzejszczak wrote: > Do I understand correctly that ScopedValues will be significantly faster > than Thread Locals? In some cases, yes. > If that's the case just by returning a Scope object > instead of expecting a lambda all the tracing libraries and all > instrumentations that are out there will not need a major redesign. I think > that it's worthwhile to consider such an option in that scenario. I don't understand this. What would a Scope object look like? What would you do with one? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From marcin.grzejszczak at gmail.com Mon Jun 10 16:21:56 2024 From: marcin.grzejszczak at gmail.com (Marcin Grzejszczak) Date: Mon, 10 Jun 2024 16:21:56 +0000 Subject: ScopedValue.runWhere not returning scope In-Reply-To: <907a0f81-ae09-4d43-addf-503b10959c3e@littlepinkcloud.com> References: <872DA66A-CBCB-4FB3-A029-429FBBB53B53@icloud.com> <907a0f81-ae09-4d43-addf-503b10959c3e@littlepinkcloud.com> Message-ID: > What would a Scope object look like? What would you do with one? Essentially it would be Closeable. I would store it in e.g. `onScopeOpened` and then pass it onto `onScopeClosed` and close it there. Pozdrawiam / Best regards, Marcin Grzejszczak https://marcin.grzejszczak.pl https://toomuchcoding.com pon., 10 cze 2024 o 16:17 Andrew Haley napisa?(a): > On 6/10/24 15:48, Marcin Grzejszczak wrote: > > Do I understand correctly that ScopedValues will be significantly faster > > than Thread Locals? > > In some cases, yes. > > > If that's the case just by returning a Scope object > > instead of expecting a lambda all the tracing libraries and all > > instrumentations that are out there will not need a major redesign. I > think > > that it's worthwhile to consider such an option in that scenario. > > I don't understand this. > > What would a Scope object look like? What would you do with one? > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at icloud.com Mon Jun 10 16:25:34 2024 From: robaho at icloud.com (Robert Engels) Date: Mon, 10 Jun 2024 11:25:34 -0500 Subject: ScopedValue.runWhere not returning scope In-Reply-To: References: <872DA66A-CBCB-4FB3-A029-429FBBB53B53@icloud.com> <907a0f81-ae09-4d43-addf-503b10959c3e@littlepinkcloud.com> Message-ID: I think the question is more - what are the threads doing with this object between the open and close. This is what controls whether or not the object can be immutable - which from my reading is the general design/limitation of a scoped variable. > On Jun 10, 2024, at 11:21 AM, Marcin Grzejszczak wrote: > > > What would a Scope object look like? What would you do with one? > > Essentially it would be Closeable. I would store it in e.g. `onScopeOpened` and then pass it onto `onScopeClosed` and close it there. > > Pozdrawiam / Best regards, > Marcin Grzejszczak > > https://marcin.grzejszczak.pl > https://toomuchcoding.com > > pon., 10 cze 2024 o 16:17 Andrew Haley > napisa?(a): > On 6/10/24 15:48, Marcin Grzejszczak wrote: > > Do I understand correctly that ScopedValues will be significantly faster > > than Thread Locals? > > In some cases, yes. > > > If that's the case just by returning a Scope object > > instead of expecting a lambda all the tracing libraries and all > > instrumentations that are out there will not need a major redesign. I think > > that it's worthwhile to consider such an option in that scenario. > > I don't understand this. > > What would a Scope object look like? What would you do with one? > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Mon Jun 10 17:16:29 2024 From: duke at openjdk.org (duke) Date: Mon, 10 Jun 2024 17:16:29 GMT Subject: git: openjdk/loom: fibers: 2 new changesets Message-ID: <7c4911cf-04ce-4e82-a0c7-0c0ab5b46338@openjdk.org> Changeset: 6fe34720 Author: Alan Bateman Date: 2024-06-10 16:19:50 +0000 URL: https://git.openjdk.org/loom/commit/6fe34720b4128198cd70756f6748371146232bfe Rename test = test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALotWhenBlocking.java = test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALotWhenParking.java Changeset: 8cb757a7 Author: Alan Bateman Date: 2024-06-10 17:06:24 +0000 URL: https://git.openjdk.org/loom/commit/8cb757a7b172abddac8b4744c35b34b4a91abf72 Test ThreadMXBean.getThreadInfo.getLockedMonitors with monitors entered in native + test/jdk/java/lang/management/ThreadMXBean/LockedMonitorInNative.java + test/jdk/java/lang/management/ThreadMXBean/libLockedMonitorInNative.c From aph-open at littlepinkcloud.com Mon Jun 10 17:29:16 2024 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Mon, 10 Jun 2024 18:29:16 +0100 Subject: ScopedValue.runWhere not returning scope In-Reply-To: References: <872DA66A-CBCB-4FB3-A029-429FBBB53B53@icloud.com> <907a0f81-ae09-4d43-addf-503b10959c3e@littlepinkcloud.com> Message-ID: On 6/10/24 17:25, Robert Engels wrote: > I think the question is more - what are the threads doing with this > object between the open and close. This is what controls whether or not > the object can be immutable - which from my reading is the general > design/limitation of a scoped variable. Exactly. So something (what?) returns a Scope object. But that can't change the current scoped value context. Here's a fundamental property of a scoped value: The result of aScopedValue.get() does not ever change within the execution context of a method. Sure, its value might get overridden in the context of a callee, but when that callee returns the scoped value has its original value. So, in this code final ScopedValue aScopedValue = ...; final var x = aScopedValue.get(); // Any Java code at all... final var y = aScopedValue.get(); assert(x == y); // Always succeeds That is to say, you can read a scoped value, put it in a local, and use that local, and it is a hard guarantee that will have exactly the same effect as repeatedly calling aScopedValue.get() . -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From robaho at icloud.com Mon Jun 10 17:34:01 2024 From: robaho at icloud.com (Robert Engels) Date: Mon, 10 Jun 2024 12:34:01 -0500 Subject: ScopedValue.runWhere not returning scope In-Reply-To: References: <872DA66A-CBCB-4FB3-A029-429FBBB53B53@icloud.com> <907a0f81-ae09-4d43-addf-503b10959c3e@littlepinkcloud.com> Message-ID: But x == y does not require immutability, .e.g: final ScopedValue aScopedValue = ? Recorder r = aScopedValue.get(); r.recordSomeValue(); final Recorder = aScopedValue.get(); r.close() -> e.g. writes values to server? so the scoped value is not immutable, only the reference is constant. This doesn?t match the JEP or I am misunderstanding it. > final ScopedValue aScopedValue = ...; > final var x = aScopedValue.get(); > // Any Java code at all... > final var y = aScopedValue.get(); > On Jun 10, 2024, at 12:29 PM, Andrew Haley wrote: > > On 6/10/24 17:25, Robert Engels wrote: >> I think the question is more - what are the threads doing with this >> object between the open and close. This is what controls whether or not >> the object can be immutable - which from my reading is the general >> design/limitation of a scoped variable. > > Exactly. So something (what?) returns a Scope object. But that can't change > the current scoped value context. > > Here's a fundamental property of a scoped value: > > The result of aScopedValue.get() does not ever change within the execution > context of a method. Sure, its value might get overridden in the context of a > callee, but when that callee returns the scoped value has its original > value. > > So, in this code > > final ScopedValue aScopedValue = ...; > final var x = aScopedValue.get(); > // Any Java code at all... > final var y = aScopedValue.get(); > > assert(x == y); // Always succeeds > > That is to say, you can read a scoped value, put it in a local, and use > that local, and it is a hard guarantee that will have exactly the same > effect as repeatedly calling aScopedValue.get() . > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From marcin.grzejszczak at gmail.com Mon Jun 10 20:44:57 2024 From: marcin.grzejszczak at gmail.com (Marcin Grzejszczak) Date: Mon, 10 Jun 2024 22:44:57 +0200 Subject: ScopedValue.runWhere not returning scope In-Reply-To: References: <872DA66A-CBCB-4FB3-A029-429FBBB53B53@icloud.com> <907a0f81-ae09-4d43-addf-503b10959c3e@littlepinkcloud.com> Message-ID: I'm sorry but I think I'm just very bad at explaining. What I'm just trying to say is that the only thing that I think would be beneficial in terms of the api changes is that instead of passing the lambda that is doing all the safe keeping for the user (because it limits what can be done because of the usage of lambda) one would be able to literally do the same but not through the lambda but through manual start and stop. The rest of the assumptions would remain the same regardless of whether one using a lambda or not. I look at my request in a way as if you could do try with resources or manually call close in the finally block. In our scenario either the user passws the lambda or manually create the scope, runs the code (lambda) and closes the scope. Scope opening and closing would do exactly the same what it's being done under the hood when you call the lambda version. Pozdrawiam / Best regards, Marcin Grzejszczak https://marcin.grzejszczak.pl https://toomuchcoding.com On Mon, 10 Jun 2024 at 19:34, Robert Engels wrote: > But x == y does not require immutability, .e.g: > > final ScopedValue aScopedValue = ? > > Recorder r = aScopedValue.get(); > > r.recordSomeValue(); > > final Recorder = aScopedValue.get(); > > r.close() -> e.g. writes values to server? > > so the scoped value is not immutable, only the reference is constant. > > This doesn?t match the JEP or I am misunderstanding it. > > > final ScopedValue aScopedValue = ...; > > final var x = aScopedValue.get(); > > // Any Java code at all... > > final var y = aScopedValue.get(); > > > > > On Jun 10, 2024, at 12:29 PM, Andrew Haley > wrote: > > > > On 6/10/24 17:25, Robert Engels wrote: > >> I think the question is more - what are the threads doing with this > >> object between the open and close. This is what controls whether or not > >> the object can be immutable - which from my reading is the general > >> design/limitation of a scoped variable. > > > > Exactly. So something (what?) returns a Scope object. But that can't > change > > the current scoped value context. > > > > Here's a fundamental property of a scoped value: > > > > The result of aScopedValue.get() does not ever change within the > execution > > context of a method. Sure, its value might get overridden in the > context of a > > callee, but when that callee returns the scoped value has its original > > value. > > > > So, in this code > > > > final ScopedValue aScopedValue = ...; > > final var x = aScopedValue.get(); > > // Any Java code at all... > > final var y = aScopedValue.get(); > > > > assert(x == y); // Always succeeds > > > > That is to say, you can read a scoped value, put it in a local, and use > > that local, and it is a hard guarantee that will have exactly the same > > effect as repeatedly calling aScopedValue.get() . > > > > -- > > Andrew Haley (he/him) > > Java Platform Lead Engineer > > Red Hat UK Ltd. > > https://keybase.io/andrewhaley > > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at icloud.com Mon Jun 10 21:11:47 2024 From: robaho at icloud.com (Robert Engels) Date: Mon, 10 Jun 2024 16:11:47 -0500 Subject: ScopedValue.runWhere not returning scope In-Reply-To: References: <872DA66A-CBCB-4FB3-A029-429FBBB53B53@icloud.com> <907a0f81-ae09-4d43-addf-503b10959c3e@littlepinkcloud.com> Message-ID: <8894C63C-B1EF-416E-B557-E3E1F1745FE4@icloud.com> i think the problem may be your reference to ?using a lambda?. I am not sure what that has to do with tracing libraries or thread locals. Most tracing libraries (ignore byte code instrumentation) work like this: void topLevelRequestHandler(Request r,Response) { getTracingContext().setRequestId(r.getId()); ? eventually call myFunction() which is traced ... } void myFunction(?) { getTracingContext().startMethod(?myFunction?,?); ? do work ? getTracingContext().endMethod(?myFunction?,?.); } or void myFunction() { // using AutoClosable try(getTracingContext().start(???) { ... do work ... } } getTracingContext() will usually use a TL to get the context associated with the current execution. This eliminates the need to pass a context instance as a parameter of every method. It probably use an InheritableTL to handle the case of spawning additional threads to do some of the request handling. You can rewrite the above without using TL by creating the TracingContext instance in the top level, and passing it as a parameter to every function below. This is how Go handles this. A scoped variable is still backed by a map of VT -> instance, but it can be a bit more efficient when passing to sub tasks or methods - I believe it can avoid performing the map lookup multiple times. If I were to rewrite the above using scoped variables, I THINK it would look something like: private static final ScopedValue X = ScopedValue.newInstance(); void topLevelRequestHandler(Request r,Response) { ScopedValue.where(X,new TracingContext(r.getRequestId())).run(() -> myFunction(?); } void myFunction() { X.in(?myFunction?,...); ? do work ... X.out(?myFunction?,...); } X.in() could return an AutoClosable, so you would have: void myFunction() { try(X.in(?myFunction?,...)) { ? do work ? } } which would ?work?, but something more complicated, where X would be rebound as you went deeper in the call stack might be better. BUT ? ScopedValue instances are supposed to be immutable, and in() and out() would be mutating the TracingContext() (most likely, it could defer to some other linked object or service call). Maybe the JEP meant to state the reference is immutable - i.e. you cannot change it directly, only using ScopedVariable.where(?) and whether that is OK I don?t know. I am guessing for usability it would not be a private static instance, but rather a public static global - which is a problem in itself. > On Jun 10, 2024, at 3:44 PM, Marcin Grzejszczak wrote: > > I'm sorry but I think I'm just very bad at explaining. > > What I'm just trying to say is that the only thing that I think would be beneficial in terms of the api changes is that instead of passing the lambda that is doing all the safe keeping for the user (because it limits what can be done because of the usage of lambda) one would be able to literally do the same but not through the lambda but through manual start and stop. The rest of the assumptions would remain the same regardless of whether one using a lambda or not. > > I look at my request in a way as if you could do try with resources or manually call close in the finally block. In our scenario either the user passws the lambda or manually create the scope, runs the code (lambda) and closes the scope. Scope opening and closing would do exactly the same what it's being done under the hood when you call the lambda version. > > Pozdrawiam / Best regards, > Marcin Grzejszczak > > https://marcin.grzejszczak.pl > https://toomuchcoding.com > > > On Mon, 10 Jun 2024 at 19:34, Robert Engels > wrote: > But x == y does not require immutability, .e.g: > > final ScopedValue aScopedValue = ? > > Recorder r = aScopedValue.get(); > > r.recordSomeValue(); > > final Recorder = aScopedValue.get(); > > r.close() -> e.g. writes values to server? > > so the scoped value is not immutable, only the reference is constant. > > This doesn?t match the JEP or I am misunderstanding it. > > > final ScopedValue aScopedValue = ...; > > final var x = aScopedValue.get(); > > // Any Java code at all... > > final var y = aScopedValue.get(); > > > > > On Jun 10, 2024, at 12:29 PM, Andrew Haley > wrote: > > > > On 6/10/24 17:25, Robert Engels wrote: > >> I think the question is more - what are the threads doing with this > >> object between the open and close. This is what controls whether or not > >> the object can be immutable - which from my reading is the general > >> design/limitation of a scoped variable. > > > > Exactly. So something (what?) returns a Scope object. But that can't change > > the current scoped value context. > > > > Here's a fundamental property of a scoped value: > > > > The result of aScopedValue.get() does not ever change within the execution > > context of a method. Sure, its value might get overridden in the context of a > > callee, but when that callee returns the scoped value has its original > > value. > > > > So, in this code > > > > final ScopedValue aScopedValue = ...; > > final var x = aScopedValue.get(); > > // Any Java code at all... > > final var y = aScopedValue.get(); > > > > assert(x == y); // Always succeeds > > > > That is to say, you can read a scoped value, put it in a local, and use > > that local, and it is a hard guarantee that will have exactly the same > > effect as repeatedly calling aScopedValue.get() . > > > > -- > > Andrew Haley (he/him) > > Java Platform Lead Engineer > > Red Hat UK Ltd. > > > https://keybase.io/andrewhaley > > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at icloud.com Mon Jun 10 21:43:19 2024 From: robaho at icloud.com (Robert Engels) Date: Mon, 10 Jun 2024 16:43:19 -0500 Subject: ScopedValue.runWhere not returning scope In-Reply-To: <8894C63C-B1EF-416E-B557-E3E1F1745FE4@icloud.com> References: <872DA66A-CBCB-4FB3-A029-429FBBB53B53@icloud.com> <907a0f81-ae09-4d43-addf-503b10959c3e@littlepinkcloud.com> <8894C63C-B1EF-416E-B557-E3E1F1745FE4@icloud.com> Message-ID: Minor correction, the ScopedValue code should be similar to X.get().in(?myFunction?,?) > On Jun 10, 2024, at 4:11 PM, Robert Engels wrote: > > i think the problem may be your reference to ?using a lambda?. I am not sure what that has to do with tracing libraries or thread locals. > > Most tracing libraries (ignore byte code instrumentation) work like this: > > void topLevelRequestHandler(Request r,Response) { > getTracingContext().setRequestId(r.getId()); > > ? eventually call myFunction() which is traced ... > } > > void myFunction(?) { > getTracingContext().startMethod(?myFunction?,?); > ? do work ? > getTracingContext().endMethod(?myFunction?,?.); > } > > or > > void myFunction() { > // using AutoClosable > try(getTracingContext().start(???) { > ... do work ... > } > } > > getTracingContext() will usually use a TL to get the context associated with the current execution. This eliminates the need to pass a context instance as a parameter of every method. It probably use an InheritableTL to handle the case of spawning additional threads to do some of the request handling. > > You can rewrite the above without using TL by creating the TracingContext instance in the top level, and passing it as a parameter to every function below. This is how Go handles this. > > A scoped variable is still backed by a map of VT -> instance, but it can be a bit more efficient when passing to sub tasks or methods - I believe it can avoid performing the map lookup multiple times. > > If I were to rewrite the above using scoped variables, I THINK it would look something like: > > private static final ScopedValue X = ScopedValue.newInstance(); > > void topLevelRequestHandler(Request r,Response) { > ScopedValue.where(X,new TracingContext(r.getRequestId())).run(() -> myFunction(?); > } > > void myFunction() { > X.in(?myFunction?,...); > ? do work ... > X.out(?myFunction?,...); > } > > X.in() could return an AutoClosable, so you would have: > > void myFunction() { > try(X.in(?myFunction?,...)) { > ? do work ? > } > } > > which would ?work?, but something more complicated, where X would be rebound as you went deeper in the call stack might be better. > > BUT ? ScopedValue instances are supposed to be immutable, and in() and out() would be mutating the TracingContext() (most likely, it could defer to some other linked object or service call). Maybe the JEP meant to state the reference is immutable - i.e. you cannot change it directly, only using ScopedVariable.where(?) > > and whether that is OK I don?t know. I am guessing for usability it would not be a private static instance, but rather a public static global - which is a problem in itself. > >> On Jun 10, 2024, at 3:44 PM, Marcin Grzejszczak > wrote: >> >> I'm sorry but I think I'm just very bad at explaining. >> >> What I'm just trying to say is that the only thing that I think would be beneficial in terms of the api changes is that instead of passing the lambda that is doing all the safe keeping for the user (because it limits what can be done because of the usage of lambda) one would be able to literally do the same but not through the lambda but through manual start and stop. The rest of the assumptions would remain the same regardless of whether one using a lambda or not. >> >> I look at my request in a way as if you could do try with resources or manually call close in the finally block. In our scenario either the user passws the lambda or manually create the scope, runs the code (lambda) and closes the scope. Scope opening and closing would do exactly the same what it's being done under the hood when you call the lambda version. >> >> Pozdrawiam / Best regards, >> Marcin Grzejszczak >> >> https://marcin.grzejszczak.pl >> https://toomuchcoding.com >> >> >> On Mon, 10 Jun 2024 at 19:34, Robert Engels > wrote: >> But x == y does not require immutability, .e.g: >> >> final ScopedValue aScopedValue = ? >> >> Recorder r = aScopedValue.get(); >> >> r.recordSomeValue(); >> >> final Recorder = aScopedValue.get(); >> >> r.close() -> e.g. writes values to server? >> >> so the scoped value is not immutable, only the reference is constant. >> >> This doesn?t match the JEP or I am misunderstanding it. >> >> > final ScopedValue aScopedValue = ...; >> > final var x = aScopedValue.get(); >> > // Any Java code at all... >> > final var y = aScopedValue.get(); >> >> >> >> > On Jun 10, 2024, at 12:29 PM, Andrew Haley > wrote: >> > >> > On 6/10/24 17:25, Robert Engels wrote: >> >> I think the question is more - what are the threads doing with this >> >> object between the open and close. This is what controls whether or not >> >> the object can be immutable - which from my reading is the general >> >> design/limitation of a scoped variable. >> > >> > Exactly. So something (what?) returns a Scope object. But that can't change >> > the current scoped value context. >> > >> > Here's a fundamental property of a scoped value: >> > >> > The result of aScopedValue.get() does not ever change within the execution >> > context of a method. Sure, its value might get overridden in the context of a >> > callee, but when that callee returns the scoped value has its original >> > value. >> > >> > So, in this code >> > >> > final ScopedValue aScopedValue = ...; >> > final var x = aScopedValue.get(); >> > // Any Java code at all... >> > final var y = aScopedValue.get(); >> > >> > assert(x == y); // Always succeeds >> > >> > That is to say, you can read a scoped value, put it in a local, and use >> > that local, and it is a hard guarantee that will have exactly the same >> > effect as repeatedly calling aScopedValue.get() . >> > >> > -- >> > Andrew Haley (he/him) >> > Java Platform Lead Engineer >> > Red Hat UK Ltd. > >> > https://keybase.io/andrewhaley >> > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pedro.lamarao at prodist.com.br Mon Jun 10 22:40:46 2024 From: pedro.lamarao at prodist.com.br (=?UTF-8?Q?Pedro_Lamar=C3=A3o?=) Date: Mon, 10 Jun 2024 19:40:46 -0300 Subject: ScopedValue.runWhere not returning scope In-Reply-To: References: <872DA66A-CBCB-4FB3-A029-429FBBB53B53@icloud.com> <907a0f81-ae09-4d43-addf-503b10959c3e@littlepinkcloud.com> Message-ID: Em seg., 10 de jun. de 2024 ?s 17:47, Marcin Grzejszczak < marcin.grzejszczak at gmail.com> escreveu: > What I'm just trying to say is that the only thing that I think would be > beneficial in terms of the api changes is that instead of passing the > lambda that is doing all the safe keeping for the user (because it limits > what can be done because of the usage of lambda) one would be able to > literally do the same but not through the lambda but through manual start > and stop. The rest of the assumptions would remain the same regardless of > whether one using a lambda or not. > This benefit of having ScopedValues "plug and play" into some interceptor architecture would come at the cost of removing the structural guarantee that ScopedValues scopes are entered and left correctly. That guarantee would be degraded to a user requirement, which the platform would *not* be allowed to assume at the risk of undefined behaviour -- what happens if a super scope is closed before a sub scope? -- Pedro Lamar?o -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Tue Jun 11 01:59:02 2024 From: duke at openjdk.org (duke) Date: Tue, 11 Jun 2024 01:59:02 GMT Subject: git: openjdk/loom: fibers: 2 new changesets Message-ID: <1e567e92-4887-4ba5-9556-281187bc88f4@openjdk.org> Changeset: 7e3d8eea Author: Patricio Chilano Mateo Date: 2024-06-10 15:46:41 +0000 URL: https://git.openjdk.org/loom/commit/7e3d8eea266b8cd59be97f2e1d62c5a49af8015c Fix key for getting ObjectMonitorLinkedList ! src/hotspot/share/runtime/vmOperations.cpp ! test/jdk/java/lang/management/ThreadMXBean/LockedMonitorInNative.java Changeset: 9414e94a Author: Patricio Chilano Mateo Date: 2024-06-10 18:24:22 +0000 URL: https://git.openjdk.org/loom/commit/9414e94a63dbb614756b4459b059e0a87c4316c1 Problemlist LockedMonitorInNative.java with virtual wrapper ! test/jdk/ProblemList-Virtual.txt From imediava at gmail.com Tue Jun 11 07:12:43 2024 From: imediava at gmail.com (=?UTF-8?Q?I=C3=B1igo_Mediavilla?=) Date: Tue, 11 Jun 2024 09:12:43 +0200 Subject: Gentle bump for a new round of reviews for JDK-8330846 Message-ID: Hello, Would it be possible to get a new round of reviews for my PR: https://github.com/openjdk/jdk/pull/19482, that tackles JDK-8330846 ? For the update, my take is that the PR could be ready as-is with possible changes to the way that indentation is handled that could come up on a separate PR that is already on the pipe. Thanks in advance for your help Kind regards ??igo Mediavilla Saiz -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Tue Jun 11 08:44:41 2024 From: duke at openjdk.org (duke) Date: Tue, 11 Jun 2024 08:44:41 GMT Subject: git: openjdk/loom: fibers: 23 new changesets Message-ID: <67de83f7-30b1-488d-82b3-4cbe5d543fd1@openjdk.org> Changeset: 8d2f9e57 Author: Chen Liang Committer: Claes Redestad Date: 2024-06-08 13:05:36 +0000 URL: https://git.openjdk.org/loom/commit/8d2f9e57c3797c01c84df007f4d2bfdcd645d0c0 8333749: Consolidate ConstantDesc conversion in java.base Co-authored-by: Claes Redestad Reviewed-by: redestad, jvernee ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/java/lang/classfile/ClassFile.java ! src/java.base/share/classes/java/lang/constant/ClassDesc.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java ! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java ! src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java ! src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java ! src/java.base/share/classes/jdk/internal/classfile/impl/ClassHierarchyImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java ! src/java.base/share/classes/jdk/internal/constant/ConstantUtils.java ! src/java.base/share/classes/jdk/internal/constant/ReferenceClassDescImpl.java ! src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java ! src/java.base/share/classes/sun/invoke/util/Wrapper.java Changeset: a9413973 Author: Jatin Bhateja Date: 2024-06-09 00:47:23 +0000 URL: https://git.openjdk.org/loom/commit/a941397327972f130e683167a1b429f17603df46 8329031: CPUID feature detection for Advanced Performance Extensions (Intel? APX) Reviewed-by: sviswanathan, kvn ! src/hotspot/cpu/x86/globals_x86.hpp ! src/hotspot/cpu/x86/vm_version_x86.cpp ! src/hotspot/cpu/x86/vm_version_x86.hpp ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp ! src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/amd64/AMD64.java ! test/lib-test/jdk/test/whitebox/CPUInfoTest.java Changeset: de55db23 Author: Matthias Baesken Date: 2024-06-10 08:14:23 +0000 URL: https://git.openjdk.org/loom/commit/de55db2352f84c101f8197ee7aca80d72807fbc5 8333522: JFR SwapSpace event might read wrong free swap space size Reviewed-by: sgehwolf, lucy ! src/hotspot/os/linux/os_linux.cpp Changeset: 8aa35cac Author: Shaojin Wen Committer: Claes Redestad Date: 2024-06-10 08:18:27 +0000 URL: https://git.openjdk.org/loom/commit/8aa35cacfcc94d261de102b628eb954c71eae98e 8333833: Remove the use of ByteArrayLittleEndian from UUID::toString Reviewed-by: liach, redestad ! src/java.base/share/classes/java/util/UUID.java ! src/java.base/share/classes/jdk/internal/util/HexDigits.java Changeset: 83b34410 Author: Thomas Stuefe Date: 2024-06-10 09:00:05 +0000 URL: https://git.openjdk.org/loom/commit/83b34410e326c47f357a37c3a337b7dedb8cbbda 8322811: jcmd System.dump_map help info has conflicting statements Reviewed-by: dholmes, kevinw ! src/hotspot/share/services/diagnosticCommand.cpp Changeset: 5f9d3e3a Author: Volker Simonis Date: 2024-06-10 09:37:43 +0000 URL: https://git.openjdk.org/loom/commit/5f9d3e3af8342592242cb304b2c219508d56ed3a 8333722: Fix CompilerDirectives for non-compiler JVM variants Reviewed-by: kvn ! src/hotspot/share/compiler/compilerDirectives.cpp Changeset: 7b43a8cd Author: Claes Redestad Date: 2024-06-10 10:05:14 +0000 URL: https://git.openjdk.org/loom/commit/7b43a8cd7c663facbe490f889838d7ead0eba0f9 8333824: Unused ClassValue in VarHandles Reviewed-by: mcimadamore ! src/java.base/share/classes/java/lang/invoke/VarHandles.java Changeset: e22fc121 Author: Thomas Stuefe Date: 2024-06-10 12:33:32 +0000 URL: https://git.openjdk.org/loom/commit/e22fc121aed56dad2eedfdc3a53f2a655c3b200b 8333775: Small improvement to outputStream auto-indentation mode Reviewed-by: jsjolen, mbaesken ! src/hotspot/share/nmt/memReporter.cpp ! src/hotspot/share/nmt/memReporter.hpp ! src/hotspot/share/utilities/ostream.cpp ! src/hotspot/share/utilities/ostream.hpp ! test/hotspot/gtest/utilities/test_ostream.cpp Changeset: ec1664e8 Author: Daniel Fuchs Date: 2024-06-10 12:44:36 +0000 URL: https://git.openjdk.org/loom/commit/ec1664e8c9413890ce2dae5c2dbbce3449d67882 8333804: java/net/httpclient/ForbiddenHeadTest.java threw an exception with 0 failures Reviewed-by: jpai ! test/jdk/java/net/httpclient/ForbiddenHeadTest.java Changeset: e7dc76b5 Author: Alan Bateman Date: 2024-06-10 12:47:09 +0000 URL: https://git.openjdk.org/loom/commit/e7dc76b5776e05082281fb640d1592479cfe9e6b 8333849: (dc) DatagramChannel send/receive fails with UOE if buffer backed by memory segment allocated from shared arena Reviewed-by: dfuchs ! src/java.base/share/classes/sun/nio/ch/DatagramChannelImpl.java + test/jdk/java/nio/channels/etc/MemorySegments.java Changeset: 2a242db0 Author: Kuai Wei Committer: Aleksey Shipilev Date: 2024-06-10 12:57:03 +0000 URL: https://git.openjdk.org/loom/commit/2a242db01ed1d502affa4a954e601266fa98dfbe 8325821: [REDO] use "dmb.ishst+dmb.ishld" for release barrier Reviewed-by: shade, aph ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/globals_aarch64.hpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp ! src/hotspot/share/asm/codeBuffer.cpp ! src/hotspot/share/asm/codeBuffer.hpp ! test/hotspot/gtest/aarch64/test_assembler_aarch64.cpp + test/micro/org/openjdk/bench/vm/compiler/FinalFieldInitialize.java Changeset: e0afe0b5 Author: Sonia Zaldana Calles Committer: Thomas Stuefe Date: 2024-06-10 13:41:56 +0000 URL: https://git.openjdk.org/loom/commit/e0afe0b5e4f9bfa1f608be98e0a4f3bb4a7e4d30 8326085: Remove unnecessary UpcallContext constructor Reviewed-by: kbarrett, stuefe ! src/hotspot/share/prims/upcallLinker.cpp Changeset: ce5727df Author: Gui Cao Committer: Fei Yang Date: 2024-06-10 13:44:43 +0000 URL: https://git.openjdk.org/loom/commit/ce5727df4436425b24b89f24c6e6b708575ec7c6 8333652: RISC-V: compiler/vectorapi/VectorGatherMaskFoldingTest.java fails when using RVV Reviewed-by: fyang ! src/hotspot/cpu/riscv/assembler_riscv.hpp ! src/hotspot/cpu/riscv/riscv_v.ad Changeset: 6ea28fb3 Author: Albert Mingkun Yang Date: 2024-06-10 15:23:32 +0000 URL: https://git.openjdk.org/loom/commit/6ea28fb30ce7d48e2f053cb9faf4f2a5dba52b06 8333641: Serial: Remove Generation::supports_tlab_allocation Reviewed-by: tschatzl ! src/hotspot/share/gc/serial/defNewGeneration.hpp ! src/hotspot/share/gc/serial/generation.hpp ! src/hotspot/share/gc/serial/serialHeap.cpp ! src/hotspot/share/gc/serial/tenuredGeneration.hpp Changeset: b68609f8 Author: Albert Mingkun Yang Date: 2024-06-10 15:23:41 +0000 URL: https://git.openjdk.org/loom/commit/b68609f80d629846870c45d34046d8c47941003b 8333779: Parallel: Remove Summary phase related debug print during Full GC Reviewed-by: tschatzl ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/gc/parallel/psParallelCompact.hpp - test/hotspot/gtest/gc/parallel/test_psParallelCompact.cpp Changeset: b2547620 Author: Matthew Donovan Date: 2024-06-10 15:41:30 +0000 URL: https://git.openjdk.org/loom/commit/b25476200ab8bea4f25a671d5b9351662d11c5b4 8333829: ProblemList sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java due to JDK-8333317 Reviewed-by: mullan ! test/jdk/ProblemList.txt Changeset: 13642cb4 Author: Joe Darcy Date: 2024-06-10 17:15:32 +0000 URL: https://git.openjdk.org/loom/commit/13642cb4b8895ad07b2249c9e215a6a037e5cf71 8333828: Use value javadoc tag in java.lang.{Float, Double} Reviewed-by: liach, rgiulietti ! src/java.base/share/classes/java/lang/Double.java ! src/java.base/share/classes/java/lang/Float.java Changeset: 96911537 Author: Vladimir Kozlov Date: 2024-06-10 17:58:22 +0000 URL: https://git.openjdk.org/loom/commit/96911537557dd95cd11598cd9a9f4e64e05e6aac 8329141: Obsolete RTM flags and code Reviewed-by: chagedorn ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.hpp ! src/hotspot/cpu/x86/globalDefinitions_x86.hpp ! src/hotspot/cpu/x86/globals_x86.hpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/cpu/x86/vm_version_x86.cpp ! src/hotspot/cpu/x86/x86_32.ad ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/share/adlc/output_c.cpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciEnv.hpp ! src/hotspot/share/ci/ciMethodData.hpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/compiler/compilerDefinitions.hpp ! src/hotspot/share/compiler/compilerOracle.hpp ! src/hotspot/share/oops/methodData.cpp ! src/hotspot/share/oops/methodData.hpp ! src/hotspot/share/opto/c2_globals.hpp ! src/hotspot/share/opto/classes.hpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/locknode.cpp ! src/hotspot/share/opto/locknode.hpp ! src/hotspot/share/opto/loopTransform.cpp ! src/hotspot/share/opto/machnode.hpp ! src/hotspot/share/opto/macro.cpp ! src/hotspot/share/opto/opaquenode.cpp ! src/hotspot/share/opto/opaquenode.hpp ! src/hotspot/share/opto/output.cpp ! src/hotspot/share/opto/output.hpp ! src/hotspot/share/opto/parse.hpp ! src/hotspot/share/opto/parse1.cpp ! src/hotspot/share/opto/runtime.cpp ! src/hotspot/share/opto/runtime.hpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/deoptimization.cpp ! src/hotspot/share/runtime/deoptimization.hpp ! src/hotspot/share/runtime/flags/jvmFlagConstraintsCompiler.cpp ! src/hotspot/share/runtime/flags/jvmFlagConstraintsCompiler.hpp ! src/hotspot/share/runtime/java.cpp - src/hotspot/share/runtime/rtmLocking.cpp - src/hotspot/share/runtime/rtmLocking.hpp ! src/hotspot/share/runtime/threads.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/java.base/share/man/java.1 ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/TEST.groups - test/hotspot/jtreg/compiler/rtm/cli/RTMGenericCommandLineOptionTest.java - test/hotspot/jtreg/compiler/rtm/cli/RTMLockingAwareTest.java - test/hotspot/jtreg/compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsBase.java - test/hotspot/jtreg/compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsOptionOnSupportedConfig.java - test/hotspot/jtreg/compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsOptionOnUnsupportedConfig.java - test/hotspot/jtreg/compiler/rtm/cli/TestRTMAbortThresholdOption.java - test/hotspot/jtreg/compiler/rtm/cli/TestRTMLockingCalculationDelayOption.java - test/hotspot/jtreg/compiler/rtm/cli/TestRTMLockingThresholdOption.java - test/hotspot/jtreg/compiler/rtm/cli/TestRTMRetryCountOption.java - test/hotspot/jtreg/compiler/rtm/cli/TestRTMSpinLoopCountOption.java - test/hotspot/jtreg/compiler/rtm/cli/TestRTMTotalCountIncrRateOptionOnSupportedConfig.java - test/hotspot/jtreg/compiler/rtm/cli/TestUseRTMDeoptOptionOnSupportedConfig.java - test/hotspot/jtreg/compiler/rtm/cli/TestUseRTMDeoptOptionOnUnsupportedConfig.java - test/hotspot/jtreg/compiler/rtm/cli/TestUseRTMForStackLocksOptionOnSupportedConfig.java - test/hotspot/jtreg/compiler/rtm/cli/TestUseRTMForStackLocksOptionOnUnsupportedConfig.java - test/hotspot/jtreg/compiler/rtm/cli/TestUseRTMLockingOptionOnSupportedConfig.java - test/hotspot/jtreg/compiler/rtm/cli/TestUseRTMLockingOptionOnUnsupportedCPU.java - test/hotspot/jtreg/compiler/rtm/cli/TestUseRTMLockingOptionOnUnsupportedVM.java - test/hotspot/jtreg/compiler/rtm/cli/TestUseRTMXendForLockBusyOption.java - test/hotspot/jtreg/compiler/rtm/locking/TestRTMAbortRatio.java - test/hotspot/jtreg/compiler/rtm/locking/TestRTMAbortThreshold.java - test/hotspot/jtreg/compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java - test/hotspot/jtreg/compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java - test/hotspot/jtreg/compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java - test/hotspot/jtreg/compiler/rtm/locking/TestRTMLockingCalculationDelay.java - test/hotspot/jtreg/compiler/rtm/locking/TestRTMLockingThreshold.java - test/hotspot/jtreg/compiler/rtm/locking/TestRTMRetryCount.java - test/hotspot/jtreg/compiler/rtm/locking/TestRTMSpinLoopCount.java - test/hotspot/jtreg/compiler/rtm/locking/TestRTMTotalCountIncrRate.java - test/hotspot/jtreg/compiler/rtm/locking/TestUseRTMAfterLockInflation.java - test/hotspot/jtreg/compiler/rtm/locking/TestUseRTMDeopt.java - test/hotspot/jtreg/compiler/rtm/locking/TestUseRTMForInflatedLocks.java - test/hotspot/jtreg/compiler/rtm/locking/TestUseRTMForStackLocks.java - test/hotspot/jtreg/compiler/rtm/locking/TestUseRTMXendForLockBusy.java - test/hotspot/jtreg/compiler/rtm/method_options/TestNoRTMLockElidingOption.java - test/hotspot/jtreg/compiler/rtm/method_options/TestUseRTMLockElidingOption.java - test/hotspot/jtreg/compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java - test/hotspot/jtreg/compiler/testlibrary/rtm/AbortProvoker.java - test/hotspot/jtreg/compiler/testlibrary/rtm/AbortType.java - test/hotspot/jtreg/compiler/testlibrary/rtm/BufferOverflowProvoker.java - test/hotspot/jtreg/compiler/testlibrary/rtm/BusyLock.java - test/hotspot/jtreg/compiler/testlibrary/rtm/CompilableTest.java - test/hotspot/jtreg/compiler/testlibrary/rtm/MemoryConflictProvoker.java - test/hotspot/jtreg/compiler/testlibrary/rtm/NestedAbortProvoker.java - test/hotspot/jtreg/compiler/testlibrary/rtm/RTMLockingStatistics.java - test/hotspot/jtreg/compiler/testlibrary/rtm/RTMTestBase.java - test/hotspot/jtreg/compiler/testlibrary/rtm/XAbortProvoker.java - test/hotspot/jtreg/compiler/testlibrary/rtm/libXAbortProvoker.c Changeset: 3a01b47a Author: David Holmes Date: 2024-06-11 01:05:19 +0000 URL: https://git.openjdk.org/loom/commit/3a01b47ac97714608356ce3faf797c37dc63e9af 8330205: Initial troff manpage generation for JDK 24 Reviewed-by: alanb, iris ! src/java.base/share/man/java.1 ! src/java.base/share/man/keytool.1 ! src/java.rmi/share/man/rmiregistry.1 ! src/java.scripting/share/man/jrunscript.1 ! src/jdk.compiler/share/man/javac.1 ! src/jdk.compiler/share/man/serialver.1 ! src/jdk.hotspot.agent/share/man/jhsdb.1 ! src/jdk.httpserver/share/man/jwebserver.1 ! src/jdk.jartool/share/man/jar.1 ! src/jdk.jartool/share/man/jarsigner.1 ! src/jdk.javadoc/share/man/javadoc.1 ! src/jdk.jcmd/share/man/jcmd.1 ! src/jdk.jcmd/share/man/jinfo.1 ! src/jdk.jcmd/share/man/jmap.1 ! src/jdk.jcmd/share/man/jps.1 ! src/jdk.jcmd/share/man/jstack.1 ! src/jdk.jcmd/share/man/jstat.1 ! src/jdk.jconsole/share/man/jconsole.1 ! src/jdk.jdeps/share/man/javap.1 ! src/jdk.jdeps/share/man/jdeprscan.1 ! src/jdk.jdeps/share/man/jdeps.1 ! src/jdk.jdi/share/man/jdb.1 ! src/jdk.jfr/share/man/jfr.1 ! src/jdk.jlink/share/man/jlink.1 ! src/jdk.jlink/share/man/jmod.1 ! src/jdk.jpackage/share/man/jpackage.1 ! src/jdk.jshell/share/man/jshell.1 ! src/jdk.jstatd/share/man/jstatd.1 Changeset: 41c88bc3 Author: Jaikiran Pai Date: 2024-06-11 03:48:03 +0000 URL: https://git.openjdk.org/loom/commit/41c88bc395ab8c927bcafca9dc6c8a77de72dfc7 8333756: java/lang/instrument/NativeMethodPrefixApp.java failed due to missing intrinsic Reviewed-by: amenkov, cjplummer ! test/jdk/java/lang/instrument/NativeMethodPrefixApp.java Changeset: fe9c63cf Author: Serguei Spitsyn Date: 2024-06-11 05:35:33 +0000 URL: https://git.openjdk.org/loom/commit/fe9c63cf73db7833646345e362cbda020ac403d1 8333931: Problemlist serviceability/jvmti/vthread/CarrierThreadEventNotification Reviewed-by: serb ! test/hotspot/jtreg/ProblemList.txt Changeset: 4d6064a7 Author: Robbin Ehn Date: 2024-06-11 05:48:16 +0000 URL: https://git.openjdk.org/loom/commit/4d6064a76003addf38e6eb6b925dad8043581768 8333649: Allow different NativeCall encodings Reviewed-by: kvn, mli ! src/hotspot/cpu/aarch64/nativeInst_aarch64.hpp ! src/hotspot/cpu/arm/nativeInst_arm_32.hpp ! src/hotspot/cpu/ppc/nativeInst_ppc.hpp ! src/hotspot/cpu/riscv/nativeInst_riscv.hpp ! src/hotspot/cpu/s390/nativeInst_s390.hpp ! src/hotspot/cpu/x86/nativeInst_x86.hpp ! src/hotspot/cpu/zero/nativeInst_zero.hpp ! src/hotspot/share/code/nmethod.inline.hpp ! src/hotspot/share/opto/output.cpp Changeset: 37636c80 Author: Alan Bateman Date: 2024-06-11 07:46:57 +0000 URL: https://git.openjdk.org/loom/commit/37636c80a2ec2e68e315c5f3cabc26d9ab9085b5 Merge ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.hpp ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/cpu/x86/vm_version_x86.hpp ! src/hotspot/cpu/x86/x86_32.ad ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/runtime/deoptimization.cpp ! src/hotspot/share/runtime/threads.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/services/diagnosticCommand.cpp ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/TEST.groups ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.hpp ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/cpu/x86/vm_version_x86.hpp ! src/hotspot/cpu/x86/x86_32.ad ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/runtime/deoptimization.cpp ! src/hotspot/share/runtime/threads.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/hotspot/share/services/diagnosticCommand.cpp ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/TEST.groups From duke at openjdk.org Tue Jun 11 08:45:53 2024 From: duke at openjdk.org (duke) Date: Tue, 11 Jun 2024 08:45:53 GMT Subject: git: openjdk/loom: master: 22 new changesets Message-ID: Changeset: 8d2f9e57 Author: Chen Liang Committer: Claes Redestad Date: 2024-06-08 13:05:36 +0000 URL: https://git.openjdk.org/loom/commit/8d2f9e57c3797c01c84df007f4d2bfdcd645d0c0 8333749: Consolidate ConstantDesc conversion in java.base Co-authored-by: Claes Redestad Reviewed-by: redestad, jvernee ! src/java.base/share/classes/java/lang/Class.java ! src/java.base/share/classes/java/lang/classfile/ClassFile.java ! src/java.base/share/classes/java/lang/constant/ClassDesc.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java ! src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java ! src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java ! src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java ! src/java.base/share/classes/jdk/internal/classfile/impl/ClassHierarchyImpl.java ! src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java ! src/java.base/share/classes/jdk/internal/constant/ConstantUtils.java ! src/java.base/share/classes/jdk/internal/constant/ReferenceClassDescImpl.java ! src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java ! src/java.base/share/classes/sun/invoke/util/Wrapper.java Changeset: a9413973 Author: Jatin Bhateja Date: 2024-06-09 00:47:23 +0000 URL: https://git.openjdk.org/loom/commit/a941397327972f130e683167a1b429f17603df46 8329031: CPUID feature detection for Advanced Performance Extensions (Intel? APX) Reviewed-by: sviswanathan, kvn ! src/hotspot/cpu/x86/globals_x86.hpp ! src/hotspot/cpu/x86/vm_version_x86.cpp ! src/hotspot/cpu/x86/vm_version_x86.hpp ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp ! src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/amd64/AMD64.java ! test/lib-test/jdk/test/whitebox/CPUInfoTest.java Changeset: de55db23 Author: Matthias Baesken Date: 2024-06-10 08:14:23 +0000 URL: https://git.openjdk.org/loom/commit/de55db2352f84c101f8197ee7aca80d72807fbc5 8333522: JFR SwapSpace event might read wrong free swap space size Reviewed-by: sgehwolf, lucy ! src/hotspot/os/linux/os_linux.cpp Changeset: 8aa35cac Author: Shaojin Wen Committer: Claes Redestad Date: 2024-06-10 08:18:27 +0000 URL: https://git.openjdk.org/loom/commit/8aa35cacfcc94d261de102b628eb954c71eae98e 8333833: Remove the use of ByteArrayLittleEndian from UUID::toString Reviewed-by: liach, redestad ! src/java.base/share/classes/java/util/UUID.java ! src/java.base/share/classes/jdk/internal/util/HexDigits.java Changeset: 83b34410 Author: Thomas Stuefe Date: 2024-06-10 09:00:05 +0000 URL: https://git.openjdk.org/loom/commit/83b34410e326c47f357a37c3a337b7dedb8cbbda 8322811: jcmd System.dump_map help info has conflicting statements Reviewed-by: dholmes, kevinw ! src/hotspot/share/services/diagnosticCommand.cpp Changeset: 5f9d3e3a Author: Volker Simonis Date: 2024-06-10 09:37:43 +0000 URL: https://git.openjdk.org/loom/commit/5f9d3e3af8342592242cb304b2c219508d56ed3a 8333722: Fix CompilerDirectives for non-compiler JVM variants Reviewed-by: kvn ! src/hotspot/share/compiler/compilerDirectives.cpp Changeset: 7b43a8cd Author: Claes Redestad Date: 2024-06-10 10:05:14 +0000 URL: https://git.openjdk.org/loom/commit/7b43a8cd7c663facbe490f889838d7ead0eba0f9 8333824: Unused ClassValue in VarHandles Reviewed-by: mcimadamore ! src/java.base/share/classes/java/lang/invoke/VarHandles.java Changeset: e22fc121 Author: Thomas Stuefe Date: 2024-06-10 12:33:32 +0000 URL: https://git.openjdk.org/loom/commit/e22fc121aed56dad2eedfdc3a53f2a655c3b200b 8333775: Small improvement to outputStream auto-indentation mode Reviewed-by: jsjolen, mbaesken ! src/hotspot/share/nmt/memReporter.cpp ! src/hotspot/share/nmt/memReporter.hpp ! src/hotspot/share/utilities/ostream.cpp ! src/hotspot/share/utilities/ostream.hpp ! test/hotspot/gtest/utilities/test_ostream.cpp Changeset: ec1664e8 Author: Daniel Fuchs Date: 2024-06-10 12:44:36 +0000 URL: https://git.openjdk.org/loom/commit/ec1664e8c9413890ce2dae5c2dbbce3449d67882 8333804: java/net/httpclient/ForbiddenHeadTest.java threw an exception with 0 failures Reviewed-by: jpai ! test/jdk/java/net/httpclient/ForbiddenHeadTest.java Changeset: e7dc76b5 Author: Alan Bateman Date: 2024-06-10 12:47:09 +0000 URL: https://git.openjdk.org/loom/commit/e7dc76b5776e05082281fb640d1592479cfe9e6b 8333849: (dc) DatagramChannel send/receive fails with UOE if buffer backed by memory segment allocated from shared arena Reviewed-by: dfuchs ! src/java.base/share/classes/sun/nio/ch/DatagramChannelImpl.java + test/jdk/java/nio/channels/etc/MemorySegments.java Changeset: 2a242db0 Author: Kuai Wei Committer: Aleksey Shipilev Date: 2024-06-10 12:57:03 +0000 URL: https://git.openjdk.org/loom/commit/2a242db01ed1d502affa4a954e601266fa98dfbe 8325821: [REDO] use "dmb.ishst+dmb.ishld" for release barrier Reviewed-by: shade, aph ! src/hotspot/cpu/aarch64/aarch64.ad ! src/hotspot/cpu/aarch64/globals_aarch64.hpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp ! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp ! src/hotspot/cpu/aarch64/vm_version_aarch64.cpp ! src/hotspot/share/asm/codeBuffer.cpp ! src/hotspot/share/asm/codeBuffer.hpp ! test/hotspot/gtest/aarch64/test_assembler_aarch64.cpp + test/micro/org/openjdk/bench/vm/compiler/FinalFieldInitialize.java Changeset: e0afe0b5 Author: Sonia Zaldana Calles Committer: Thomas Stuefe Date: 2024-06-10 13:41:56 +0000 URL: https://git.openjdk.org/loom/commit/e0afe0b5e4f9bfa1f608be98e0a4f3bb4a7e4d30 8326085: Remove unnecessary UpcallContext constructor Reviewed-by: kbarrett, stuefe ! src/hotspot/share/prims/upcallLinker.cpp Changeset: ce5727df Author: Gui Cao Committer: Fei Yang Date: 2024-06-10 13:44:43 +0000 URL: https://git.openjdk.org/loom/commit/ce5727df4436425b24b89f24c6e6b708575ec7c6 8333652: RISC-V: compiler/vectorapi/VectorGatherMaskFoldingTest.java fails when using RVV Reviewed-by: fyang ! src/hotspot/cpu/riscv/assembler_riscv.hpp ! src/hotspot/cpu/riscv/riscv_v.ad Changeset: 6ea28fb3 Author: Albert Mingkun Yang Date: 2024-06-10 15:23:32 +0000 URL: https://git.openjdk.org/loom/commit/6ea28fb30ce7d48e2f053cb9faf4f2a5dba52b06 8333641: Serial: Remove Generation::supports_tlab_allocation Reviewed-by: tschatzl ! src/hotspot/share/gc/serial/defNewGeneration.hpp ! src/hotspot/share/gc/serial/generation.hpp ! src/hotspot/share/gc/serial/serialHeap.cpp ! src/hotspot/share/gc/serial/tenuredGeneration.hpp Changeset: b68609f8 Author: Albert Mingkun Yang Date: 2024-06-10 15:23:41 +0000 URL: https://git.openjdk.org/loom/commit/b68609f80d629846870c45d34046d8c47941003b 8333779: Parallel: Remove Summary phase related debug print during Full GC Reviewed-by: tschatzl ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/gc/parallel/psParallelCompact.hpp - test/hotspot/gtest/gc/parallel/test_psParallelCompact.cpp Changeset: b2547620 Author: Matthew Donovan Date: 2024-06-10 15:41:30 +0000 URL: https://git.openjdk.org/loom/commit/b25476200ab8bea4f25a671d5b9351662d11c5b4 8333829: ProblemList sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java due to JDK-8333317 Reviewed-by: mullan ! test/jdk/ProblemList.txt Changeset: 13642cb4 Author: Joe Darcy Date: 2024-06-10 17:15:32 +0000 URL: https://git.openjdk.org/loom/commit/13642cb4b8895ad07b2249c9e215a6a037e5cf71 8333828: Use value javadoc tag in java.lang.{Float, Double} Reviewed-by: liach, rgiulietti ! src/java.base/share/classes/java/lang/Double.java ! src/java.base/share/classes/java/lang/Float.java Changeset: 96911537 Author: Vladimir Kozlov Date: 2024-06-10 17:58:22 +0000 URL: https://git.openjdk.org/loom/commit/96911537557dd95cd11598cd9a9f4e64e05e6aac 8329141: Obsolete RTM flags and code Reviewed-by: chagedorn ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp ! src/hotspot/cpu/x86/c2_MacroAssembler_x86.hpp ! src/hotspot/cpu/x86/globalDefinitions_x86.hpp ! src/hotspot/cpu/x86/globals_x86.hpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/cpu/x86/vm_version_x86.cpp ! src/hotspot/cpu/x86/x86_32.ad ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/share/adlc/output_c.cpp ! src/hotspot/share/ci/ciEnv.cpp ! src/hotspot/share/ci/ciEnv.hpp ! src/hotspot/share/ci/ciMethodData.hpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/compiler/compilerDefinitions.hpp ! src/hotspot/share/compiler/compilerOracle.hpp ! src/hotspot/share/oops/methodData.cpp ! src/hotspot/share/oops/methodData.hpp ! src/hotspot/share/opto/c2_globals.hpp ! src/hotspot/share/opto/classes.hpp ! src/hotspot/share/opto/compile.cpp ! src/hotspot/share/opto/compile.hpp ! src/hotspot/share/opto/graphKit.cpp ! src/hotspot/share/opto/locknode.cpp ! src/hotspot/share/opto/locknode.hpp ! src/hotspot/share/opto/loopTransform.cpp ! src/hotspot/share/opto/machnode.hpp ! src/hotspot/share/opto/macro.cpp ! src/hotspot/share/opto/opaquenode.cpp ! src/hotspot/share/opto/opaquenode.hpp ! src/hotspot/share/opto/output.cpp ! src/hotspot/share/opto/output.hpp ! src/hotspot/share/opto/parse.hpp ! src/hotspot/share/opto/parse1.cpp ! src/hotspot/share/opto/runtime.cpp ! src/hotspot/share/opto/runtime.hpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/deoptimization.cpp ! src/hotspot/share/runtime/deoptimization.hpp ! src/hotspot/share/runtime/flags/jvmFlagConstraintsCompiler.cpp ! src/hotspot/share/runtime/flags/jvmFlagConstraintsCompiler.hpp ! src/hotspot/share/runtime/java.cpp - src/hotspot/share/runtime/rtmLocking.cpp - src/hotspot/share/runtime/rtmLocking.hpp ! src/hotspot/share/runtime/threads.cpp ! src/hotspot/share/runtime/vmStructs.cpp ! src/java.base/share/man/java.1 ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/TEST.groups - test/hotspot/jtreg/compiler/rtm/cli/RTMGenericCommandLineOptionTest.java - test/hotspot/jtreg/compiler/rtm/cli/RTMLockingAwareTest.java - test/hotspot/jtreg/compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsBase.java - test/hotspot/jtreg/compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsOptionOnSupportedConfig.java - test/hotspot/jtreg/compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsOptionOnUnsupportedConfig.java - test/hotspot/jtreg/compiler/rtm/cli/TestRTMAbortThresholdOption.java - test/hotspot/jtreg/compiler/rtm/cli/TestRTMLockingCalculationDelayOption.java - test/hotspot/jtreg/compiler/rtm/cli/TestRTMLockingThresholdOption.java - test/hotspot/jtreg/compiler/rtm/cli/TestRTMRetryCountOption.java - test/hotspot/jtreg/compiler/rtm/cli/TestRTMSpinLoopCountOption.java - test/hotspot/jtreg/compiler/rtm/cli/TestRTMTotalCountIncrRateOptionOnSupportedConfig.java - test/hotspot/jtreg/compiler/rtm/cli/TestUseRTMDeoptOptionOnSupportedConfig.java - test/hotspot/jtreg/compiler/rtm/cli/TestUseRTMDeoptOptionOnUnsupportedConfig.java - test/hotspot/jtreg/compiler/rtm/cli/TestUseRTMForStackLocksOptionOnSupportedConfig.java - test/hotspot/jtreg/compiler/rtm/cli/TestUseRTMForStackLocksOptionOnUnsupportedConfig.java - test/hotspot/jtreg/compiler/rtm/cli/TestUseRTMLockingOptionOnSupportedConfig.java - test/hotspot/jtreg/compiler/rtm/cli/TestUseRTMLockingOptionOnUnsupportedCPU.java - test/hotspot/jtreg/compiler/rtm/cli/TestUseRTMLockingOptionOnUnsupportedVM.java - test/hotspot/jtreg/compiler/rtm/cli/TestUseRTMXendForLockBusyOption.java - test/hotspot/jtreg/compiler/rtm/locking/TestRTMAbortRatio.java - test/hotspot/jtreg/compiler/rtm/locking/TestRTMAbortThreshold.java - test/hotspot/jtreg/compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java - test/hotspot/jtreg/compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java - test/hotspot/jtreg/compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java - test/hotspot/jtreg/compiler/rtm/locking/TestRTMLockingCalculationDelay.java - test/hotspot/jtreg/compiler/rtm/locking/TestRTMLockingThreshold.java - test/hotspot/jtreg/compiler/rtm/locking/TestRTMRetryCount.java - test/hotspot/jtreg/compiler/rtm/locking/TestRTMSpinLoopCount.java - test/hotspot/jtreg/compiler/rtm/locking/TestRTMTotalCountIncrRate.java - test/hotspot/jtreg/compiler/rtm/locking/TestUseRTMAfterLockInflation.java - test/hotspot/jtreg/compiler/rtm/locking/TestUseRTMDeopt.java - test/hotspot/jtreg/compiler/rtm/locking/TestUseRTMForInflatedLocks.java - test/hotspot/jtreg/compiler/rtm/locking/TestUseRTMForStackLocks.java - test/hotspot/jtreg/compiler/rtm/locking/TestUseRTMXendForLockBusy.java - test/hotspot/jtreg/compiler/rtm/method_options/TestNoRTMLockElidingOption.java - test/hotspot/jtreg/compiler/rtm/method_options/TestUseRTMLockElidingOption.java - test/hotspot/jtreg/compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java - test/hotspot/jtreg/compiler/testlibrary/rtm/AbortProvoker.java - test/hotspot/jtreg/compiler/testlibrary/rtm/AbortType.java - test/hotspot/jtreg/compiler/testlibrary/rtm/BufferOverflowProvoker.java - test/hotspot/jtreg/compiler/testlibrary/rtm/BusyLock.java - test/hotspot/jtreg/compiler/testlibrary/rtm/CompilableTest.java - test/hotspot/jtreg/compiler/testlibrary/rtm/MemoryConflictProvoker.java - test/hotspot/jtreg/compiler/testlibrary/rtm/NestedAbortProvoker.java - test/hotspot/jtreg/compiler/testlibrary/rtm/RTMLockingStatistics.java - test/hotspot/jtreg/compiler/testlibrary/rtm/RTMTestBase.java - test/hotspot/jtreg/compiler/testlibrary/rtm/XAbortProvoker.java - test/hotspot/jtreg/compiler/testlibrary/rtm/libXAbortProvoker.c Changeset: 3a01b47a Author: David Holmes Date: 2024-06-11 01:05:19 +0000 URL: https://git.openjdk.org/loom/commit/3a01b47ac97714608356ce3faf797c37dc63e9af 8330205: Initial troff manpage generation for JDK 24 Reviewed-by: alanb, iris ! src/java.base/share/man/java.1 ! src/java.base/share/man/keytool.1 ! src/java.rmi/share/man/rmiregistry.1 ! src/java.scripting/share/man/jrunscript.1 ! src/jdk.compiler/share/man/javac.1 ! src/jdk.compiler/share/man/serialver.1 ! src/jdk.hotspot.agent/share/man/jhsdb.1 ! src/jdk.httpserver/share/man/jwebserver.1 ! src/jdk.jartool/share/man/jar.1 ! src/jdk.jartool/share/man/jarsigner.1 ! src/jdk.javadoc/share/man/javadoc.1 ! src/jdk.jcmd/share/man/jcmd.1 ! src/jdk.jcmd/share/man/jinfo.1 ! src/jdk.jcmd/share/man/jmap.1 ! src/jdk.jcmd/share/man/jps.1 ! src/jdk.jcmd/share/man/jstack.1 ! src/jdk.jcmd/share/man/jstat.1 ! src/jdk.jconsole/share/man/jconsole.1 ! src/jdk.jdeps/share/man/javap.1 ! src/jdk.jdeps/share/man/jdeprscan.1 ! src/jdk.jdeps/share/man/jdeps.1 ! src/jdk.jdi/share/man/jdb.1 ! src/jdk.jfr/share/man/jfr.1 ! src/jdk.jlink/share/man/jlink.1 ! src/jdk.jlink/share/man/jmod.1 ! src/jdk.jpackage/share/man/jpackage.1 ! src/jdk.jshell/share/man/jshell.1 ! src/jdk.jstatd/share/man/jstatd.1 Changeset: 41c88bc3 Author: Jaikiran Pai Date: 2024-06-11 03:48:03 +0000 URL: https://git.openjdk.org/loom/commit/41c88bc395ab8c927bcafca9dc6c8a77de72dfc7 8333756: java/lang/instrument/NativeMethodPrefixApp.java failed due to missing intrinsic Reviewed-by: amenkov, cjplummer ! test/jdk/java/lang/instrument/NativeMethodPrefixApp.java Changeset: fe9c63cf Author: Serguei Spitsyn Date: 2024-06-11 05:35:33 +0000 URL: https://git.openjdk.org/loom/commit/fe9c63cf73db7833646345e362cbda020ac403d1 8333931: Problemlist serviceability/jvmti/vthread/CarrierThreadEventNotification Reviewed-by: serb ! test/hotspot/jtreg/ProblemList.txt Changeset: 4d6064a7 Author: Robbin Ehn Date: 2024-06-11 05:48:16 +0000 URL: https://git.openjdk.org/loom/commit/4d6064a76003addf38e6eb6b925dad8043581768 8333649: Allow different NativeCall encodings Reviewed-by: kvn, mli ! src/hotspot/cpu/aarch64/nativeInst_aarch64.hpp ! src/hotspot/cpu/arm/nativeInst_arm_32.hpp ! src/hotspot/cpu/ppc/nativeInst_ppc.hpp ! src/hotspot/cpu/riscv/nativeInst_riscv.hpp ! src/hotspot/cpu/s390/nativeInst_s390.hpp ! src/hotspot/cpu/x86/nativeInst_x86.hpp ! src/hotspot/cpu/zero/nativeInst_zero.hpp ! src/hotspot/share/code/nmethod.inline.hpp ! src/hotspot/share/opto/output.cpp From aph-open at littlepinkcloud.com Tue Jun 11 08:57:26 2024 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Tue, 11 Jun 2024 09:57:26 +0100 Subject: ScopedValue.runWhere not returning scope In-Reply-To: References: <872DA66A-CBCB-4FB3-A029-429FBBB53B53@icloud.com> <907a0f81-ae09-4d43-addf-503b10959c3e@littlepinkcloud.com> Message-ID: <260d27bf-0855-4b27-8ebc-b54955ff41a0@littlepinkcloud.com> On 6/10/24 18:34, Robert Engels wrote: > so the scoped value is not immutable, only the reference is constant. > > This doesn?t match the JEP or I am misunderstanding it. Think of a scoped value as being like a final local reference variable. It is immutable, clearly, but its referent is not. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph-open at littlepinkcloud.com Tue Jun 11 09:00:10 2024 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Tue, 11 Jun 2024 10:00:10 +0100 Subject: ScopedValue.runWhere not returning scope In-Reply-To: References: <872DA66A-CBCB-4FB3-A029-429FBBB53B53@icloud.com> <907a0f81-ae09-4d43-addf-503b10959c3e@littlepinkcloud.com> Message-ID: <62c1f68b-d754-4e3f-8736-45fa77c746da@littlepinkcloud.com> On 6/10/24 21:44, Marcin Grzejszczak wrote: > I'm sorry but I think I'm just very bad at explaining. So why not produce an example of how it would be used? As far as I can see, your proposal fails to ensure the property in the case I posted/ -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph-open at littlepinkcloud.com Tue Jun 11 09:04:11 2024 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Tue, 11 Jun 2024 10:04:11 +0100 Subject: ScopedValue.runWhere not returning scope In-Reply-To: References: <872DA66A-CBCB-4FB3-A029-429FBBB53B53@icloud.com> <907a0f81-ae09-4d43-addf-503b10959c3e@littlepinkcloud.com> Message-ID: <1edd29bb-47c7-498e-98d2-e50b95ba2a68@littlepinkcloud.com> On 6/10/24 23:40, Pedro Lamar?o wrote: > This benefit of having ScopedValues "plug and play" into some interceptor > architecture would come at the cost of removing the structural guarantee > that ScopedValues scopes are entered and left correctly. > That guarantee would be degraded to a user requirement, which the platform > would*not* be allowed to assume at the risk of undefined behaviour -- what > happens if a super scope is closed before a sub scope? Absolutely, yes. Thank you. It's better to have an API where some incorrect usages cannot even be expressed than an API that has to do runtime checking for those incorrect usages. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From marcin.grzejszczak at gmail.com Tue Jun 11 10:32:20 2024 From: marcin.grzejszczak at gmail.com (Marcin Grzejszczak) Date: Tue, 11 Jun 2024 10:32:20 +0000 Subject: ScopedValue.runWhere not returning scope In-Reply-To: <260d27bf-0855-4b27-8ebc-b54955ff41a0@littlepinkcloud.com> References: <872DA66A-CBCB-4FB3-A029-429FBBB53B53@icloud.com> <907a0f81-ae09-4d43-addf-503b10959c3e@littlepinkcloud.com> <260d27bf-0855-4b27-8ebc-b54955ff41a0@littlepinkcloud.com> Message-ID: > This benefit of having ScopedValues "plug and play" into some interceptor architecture would come at the cost of removing the structural guarantee that ScopedValues scopes are entered and left correctly. That guarantee would be degraded to a user requirement, which the platform would *not* be allowed to assume at the risk of undefined behaviour -- what happens if a super scope is closed before a sub scope? I've already described that in one of the previous answers. It's already a problem in tools like Brave or OpenTelemetry. We give users the option to operate on scopes and they indeed may mess it up. But users rarely need to actually use that API, typically they do try with resources and we very rarely have any issues reported for that matter. Again, "with great power comes great responsibility", users normally wouldn't be using that API, rather library instrumentors would. Can they break sth? Of course they can, but then they just fix it. I don't understand the problem here. On the other hand we (library creators) will be asked by the users about "our support of Scoped Values" and we will need to rewrite everything in 2 places - our libraries plus the instrumented libraries to add that support. > You can rewrite the above without using TL by creating the TracingContext instance in the top level, and passing it as a parameter to every function below. This is how Go handles this. Yes, of course I can rewrite everything to make things work with SV. My ask is not to require the library instrumentors to change their current implementation. I've been working with tracing libraries (Spring Cloud Sleuth, OpenZipkin Brave, Micrometer Tracing, OpenTelemetry) for the past decade and it's not a trivial task not only from the point of view of creating a tracing library but also adding instrumentations in other projects. > So why not produce an example of how it would be used? As far as I can see, your proposal fails to ensure the property in the case I posted/ I've created samples at the very beginning with the before and after interceptor. I obviously know that I could rewrite the interceptor to become an around one but my point is that it's not an ideal solution to require instrumentors to rewrite everything. Also I still see this whole discussion as having two ways of doing the same thing. Current approach: ScopedValue.runWhere(scopedValue, someValue, () -> { codeToRun(); }); Proposed approach: try(Scope scope = ScopedValue.openScope(scopedValue, someValue)) { codeToRun(); } I understand that in the proposed approach one can mess things up, I really do. But library instrumentors and tracing library creators would benefit from that sort of API. Also I've asked a different question... What if the users want to leverage the ScopedValues to get the current span information (or current principal from security point of view) but also they are using TL based libraries? How would the interop look like? Let's assume that they put into the current scope a span that they want to have within that scope, we would need all the tracer libraries (and security components and others that use the same mechanism) to be ScopeValue aware. Would they first try to read SV and then if that's not there a TL? They would need to most likely read SV and populate TL if the SV value is present so that other components that still rely on TL would work. That would have to also work the other way round, if a TL based library sets a value (e.g. span) then maybe the ScopedValue should be created with a scope for that new value? Pozdrawiam / Best regards, Marcin Grzejszczak https://marcin.grzejszczak.pl https://toomuchcoding.com wt., 11 cze 2024 o 09:07 Andrew Haley napisa?(a): > On 6/10/24 18:34, Robert Engels wrote: > > so the scoped value is not immutable, only the reference is constant. > > > > This doesn?t match the JEP or I am misunderstanding it. > > Think of a scoped value as being like a final local reference variable. It > is > immutable, clearly, but its referent is not. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at icloud.com Tue Jun 11 10:50:36 2024 From: robaho at icloud.com (robert engels) Date: Tue, 11 Jun 2024 05:50:36 -0500 Subject: ScopedValue.runWhere not returning scope In-Reply-To: References: Message-ID: <6ECF6FD2-7F15-4CBE-93B7-B5996095AC94@icloud.com> An HTML attachment was scrubbed... URL: From aph-open at littlepinkcloud.com Tue Jun 11 12:35:44 2024 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Tue, 11 Jun 2024 13:35:44 +0100 Subject: ScopedValue.runWhere not returning scope In-Reply-To: References: <872DA66A-CBCB-4FB3-A029-429FBBB53B53@icloud.com> <907a0f81-ae09-4d43-addf-503b10959c3e@littlepinkcloud.com> <260d27bf-0855-4b27-8ebc-b54955ff41a0@littlepinkcloud.com> Message-ID: <34ae418e-f1bb-4f30-aea6-32cf727b6e46@littlepinkcloud.com> On 6/11/24 11:32, Marcin Grzejszczak wrote: >> So why not produce an example of how it would be used? As far as I can >> see, your proposal fails to ensure the property in the case I posted/ > > I've created samples at the very beginning with the before and after > interceptor. I obviously know that I could rewrite the interceptor > to become an around one but my point is that it's not an ideal > solution to require instrumentors to rewrite everything. Also I > still see this whole discussion as having two ways of doing the same > thing. Current approach: > > ScopedValue.runWhere(scopedValue, someValue, () -> { > codeToRun(); > }); > > Proposed approach: > > try(Scope scope = ScopedValue.openScope(scopedValue, someValue)) { > codeToRun(); This API fails the test I provided: final ScopedValue aScopedValue = ...; final var x = aScopedValue.get(); ScopedValue.openScope(aScopedValue, someValue); final var y = aScopedValue.get(); assert(x == y); // Always succeeds In other words, scoped values would no longer be strictly scoped. That's what the "scoped" means in the name "scoped values". Strict scoping is a fundamental property. > } > > I understand that in the proposed approach one can mess things up, I > really do. But library instrumentors and tracing library creators > would benefit from that sort of API. If we were planning to deprecate thread-local variables I think this argument might have some merit. But we're not. They're not going away. > Also I've asked a different question... What if the users want to > leverage the ScopedValues to get the current span information (or > current principal from security point of view) but also they are > using TL based libraries? How would the interop look like? As the JEP says, scoped values do not replace all uses of thread-local variables. There are still some cases where thread-local variables will be used, and this looks like one of them. > Let's assume that they put into the current scope a span that they > want to have within that scope, we would need all the tracer > libraries (and security components and others that use the same > mechanism) to be ScopeValue aware. Would they first try to read SV > and then if that's not there a TL? Yes, I think so. > They would need to most likely read SV and populate TL if the SV > value is present so that other components that still rely on TL > would work. That would have to also work the other way round, if a > TL based library sets a value (e.g. span) then maybe the ScopedValue > should be created with a scope for that new value? I'm not sure how that'd work in general, but there's nothing to stop entry points for a library from doing so, and it might be a good idea. Something like: if (someThreadLocal.get() != NOTHING) { where(someScopedValue, someThreadLocal.get()).run(realEntry); } else { realEntry.run(); } -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From robaho at icloud.com Tue Jun 11 15:25:01 2024 From: robaho at icloud.com (Robert Engels) Date: Tue, 11 Jun 2024 10:25:01 -0500 Subject: ScopedValue.runWhere not returning scope In-Reply-To: <34ae418e-f1bb-4f30-aea6-32cf727b6e46@littlepinkcloud.com> References: <872DA66A-CBCB-4FB3-A029-429FBBB53B53@icloud.com> <907a0f81-ae09-4d43-addf-503b10959c3e@littlepinkcloud.com> <260d27bf-0855-4b27-8ebc-b54955ff41a0@littlepinkcloud.com> <34ae418e-f1bb-4f30-aea6-32cf727b6e46@littlepinkcloud.com> Message-ID: <8E60140A-AACD-452E-8BA7-7E86AB4A7D24@icloud.com> I posted a minimalist ?tracing library? using ScopedValue here https://github.com/robaho/scope_trace I think it is a fairly trivial change for tracing libraries to support ScopeValue instead of ThreadLocal if they wished to. > On Jun 11, 2024, at 7:35 AM, Andrew Haley wrote: > > On 6/11/24 11:32, Marcin Grzejszczak wrote: > > >> So why not produce an example of how it would be used? As far as I can > >> see, your proposal fails to ensure the property in the case I posted/ > > > > I've created samples at the very beginning with the before and after > > interceptor. I obviously know that I could rewrite the interceptor > > to become an around one but my point is that it's not an ideal > > solution to require instrumentors to rewrite everything. Also I > > still see this whole discussion as having two ways of doing the same > > thing. Current approach: > > > > ScopedValue.runWhere(scopedValue, someValue, () -> { > > codeToRun(); > > }); > > > > Proposed approach: > > > > try(Scope scope = ScopedValue.openScope(scopedValue, someValue)) { > > codeToRun(); > > This API fails the test I provided: > > final ScopedValue aScopedValue = ...; > final var x = aScopedValue.get(); > ScopedValue.openScope(aScopedValue, someValue); > final var y = aScopedValue.get(); > > assert(x == y); // Always succeeds > > In other words, scoped values would no longer be strictly scoped. > That's what the "scoped" means in the name "scoped values". Strict > scoping is a fundamental property. > > > } > > > > I understand that in the proposed approach one can mess things up, I > > really do. But library instrumentors and tracing library creators > > would benefit from that sort of API. > > If we were planning to deprecate thread-local variables I think this > argument might have some merit. But we're not. They're not going away. > > > Also I've asked a different question... What if the users want to > > leverage the ScopedValues to get the current span information (or > > current principal from security point of view) but also they are > > using TL based libraries? How would the interop look like? > > As the JEP says, scoped values do not replace all uses of thread-local > variables. There are still some cases where thread-local variables > will be used, and this looks like one of them. > > > Let's assume that they put into the current scope a span that they > > want to have within that scope, we would need all the tracer > > libraries (and security components and others that use the same > > mechanism) to be ScopeValue aware. Would they first try to read SV > > and then if that's not there a TL? > > Yes, I think so. > > > They would need to most likely read SV and populate TL if the SV > > value is present so that other components that still rely on TL > > would work. That would have to also work the other way round, if a > > TL based library sets a value (e.g. span) then maybe the ScopedValue > > should be created with a scope for that new value? > > I'm not sure how that'd work in general, but there's nothing to stop > entry points for a library from doing so, and it might be a good idea. > Something like: > > if (someThreadLocal.get() != NOTHING) { > where(someScopedValue, someThreadLocal.get()).run(realEntry); > } else { > realEntry.run(); > } > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From werner.randelshofer at fibermail.ch Tue Jun 11 15:32:59 2024 From: werner.randelshofer at fibermail.ch (Werner Randelshofer) Date: Tue, 11 Jun 2024 17:32:59 +0200 Subject: Question about StructuredTaskScope.joinUntil(Instant) In-Reply-To: <439D398A-5972-49CE-8C06-1E6E05D92E60@fibermail.ch> References: <439D398A-5972-49CE-8C06-1E6E05D92E60@fibermail.ch> Message-ID: I have solved my problem. :-) I have now implemented a subclass of StructuredTaskScope, which allows to specify a deadline in System.nanoTime() units. With this design, the deadline is independent from external resources (like NTP time servers) over which the Java process has no control. See code below. With best regards, Werner package org.example.structuredconcurrency; import java.time.Duration; import java.util.concurrent.StructuredTaskScope; import java.util.concurrent.ThreadFactory; import java.util.concurrent.TimeoutException; /** * A {@link StructuredTaskScope} that supports a deadline given in {@link System#nanoTime()}. * * @param the type of the structured task scope */ public class StructuredTaskScopeNanoTime extends StructuredTaskScope { /** * Creates an unnamed structured task scope that creates virtual threads. The task * scope is owned by the current thread. */ public StructuredTaskScopeNanoTime() { } /** * Creates a structured task scope with the given name and thread factory. * * @param name the name of the task scope, can be null * @param factory the thread factory */ public StructuredTaskScopeNanoTime(String name, ThreadFactory factory) { super(name, factory); } /** * Wait for all subtasks started in this task scope to finish or the task scope to * shut down, up to the given deadline. * * @param deadlineNanoTime the deadline given in {@link System#nanoTime()} units * @return this task scope * @throws IllegalStateException if this task scope is closed * @throws WrongThreadException if the current thread is not the task scope owner * @throws InterruptedException if interrupted while waiting * @throws TimeoutException if the deadline is reached while waiting */ public StructuredTaskScopeNanoTime joinUntilNanoTime(long deadlineNanoTime) throws InterruptedException, TimeoutException { fork(() -> { Thread.sleep(Duration.ofNanos(deadlineNanoTime - System.nanoTime())); shutdown(); return null; }); join(); return this; } } From duke at openjdk.org Tue Jun 11 16:16:23 2024 From: duke at openjdk.org (duke) Date: Tue, 11 Jun 2024 16:16:23 GMT Subject: git: openjdk/loom: fibers: 2 new changesets Message-ID: <69a67aa7-06d1-4861-b472-fb905f39c5a5@openjdk.org> Changeset: 0eefa8cc Author: Alan Bateman Date: 2024-06-11 12:21:17 +0000 URL: https://git.openjdk.org/loom/commit/0eefa8cc4304167e9b3026b16a25969f73bf0285 Expand testing of info returned by java.lang.management.ThreadInfo + test/jdk/java/lang/Thread/virtual/CarrierThreadInfo.java - test/jdk/java/lang/Thread/virtual/CarrierThreadWaits.java Changeset: b32dc1d9 Author: Alan Bateman Date: 2024-06-11 15:21:06 +0000 URL: https://git.openjdk.org/loom/commit/b32dc1d9bd35865dad3b21110c7602505137814c Add new test for Thread.holdsLock ! test/jdk/java/lang/Thread/virtual/ThreadAPI.java From duke at openjdk.org Wed Jun 12 01:56:47 2024 From: duke at openjdk.org (duke) Date: Wed, 12 Jun 2024 01:56:47 GMT Subject: git: openjdk/loom: fibers: 2 new changesets Message-ID: <0a23ae3a-3330-4b96-b941-a41e7267caea@openjdk.org> Changeset: f6436b68 Author: Patricio Chilano Mateo Date: 2024-06-11 20:15:38 +0000 URL: https://git.openjdk.org/loom/commit/f6436b687eee1bebc797a7df213c5b70bdea5acb use oop to get thread id ! src/hotspot/share/runtime/vmOperations.cpp ! test/jdk/ProblemList-Virtual.txt Changeset: 318f31c5 Author: Patricio Chilano Mateo Date: 2024-06-11 20:17:42 +0000 URL: https://git.openjdk.org/loom/commit/318f31c5acdcf69699108392304888eb5b4a165d fix race with GC threads ! src/hotspot/share/runtime/continuationFreezeThaw.cpp From marcin.grzejszczak at gmail.com Wed Jun 12 09:02:31 2024 From: marcin.grzejszczak at gmail.com (Marcin Grzejszczak) Date: Wed, 12 Jun 2024 09:02:31 +0000 Subject: ScopedValue.runWhere not returning scope In-Reply-To: <34ae418e-f1bb-4f30-aea6-32cf727b6e46@littlepinkcloud.com> References: <872DA66A-CBCB-4FB3-A029-429FBBB53B53@icloud.com> <907a0f81-ae09-4d43-addf-503b10959c3e@littlepinkcloud.com> <260d27bf-0855-4b27-8ebc-b54955ff41a0@littlepinkcloud.com> <34ae418e-f1bb-4f30-aea6-32cf727b6e46@littlepinkcloud.com> Message-ID: > This API fails the test I provided: > final ScopedValue aScopedValue = ...; > final var x = aScopedValue.get(); > ScopedValue.openScope(aScopedValue, someValue); > final var y = aScopedValue.get(); > assert(x == y); // Always succeeds > In other words, scoped values would no longer be strictly scoped. > That's what the "scoped" means in the name "scoped values". Strict > scoping is a fundamental property. I mean you have not closed the scopes so no wonder it works as you presented. I'm literally suggesting an option to allow manual control of scopes. Of course people can mess up the opening and closing of scopes, I do understand that. Anyways, the equivalent of... ScopedValue.runWhere(scopedValue, 1 () -> { codeToRun(); // scoped value equal to 1 ScopedValue.runWhere(scopedValue, 2, () -> { codeToRun(); // scoped value equal to 1 }); // scoped value equal to 1 }); // scoped value not having a value ... would be: try(Scope scope1 = ScopedValue.openScope(scopedValue, 1)) { codeToRun(); // scoped value equal to 1 try(Scope scope2 = ScopedValue.openScope(scopedValue, 2)) { codeToRun(); // scoped value equal to 2 } // scoped value equal to 1 } // scoped value not having a value I'm happy that we agree that there has to be an interop between TL and SV, so here I have no other comments. Pozdrawiam / Best regards, Marcin Grzejszczak https://marcin.grzejszczak.pl https://toomuchcoding.com wt., 11 cze 2024 o 12:35 Andrew Haley napisa?(a): > On 6/11/24 11:32, Marcin Grzejszczak wrote: > > >> So why not produce an example of how it would be used? As far as I can > >> see, your proposal fails to ensure the property in the case I posted/ > > > > I've created samples at the very beginning with the before and after > > interceptor. I obviously know that I could rewrite the interceptor > > to become an around one but my point is that it's not an ideal > > solution to require instrumentors to rewrite everything. Also I > > still see this whole discussion as having two ways of doing the same > > thing. Current approach: > > > > ScopedValue.runWhere(scopedValue, someValue, () -> { > > codeToRun(); > > }); > > > > Proposed approach: > > > > try(Scope scope = ScopedValue.openScope(scopedValue, someValue)) { > > codeToRun(); > > This API fails the test I provided: > > final ScopedValue aScopedValue = ...; > final var x = aScopedValue.get(); > ScopedValue.openScope(aScopedValue, someValue); > final var y = aScopedValue.get(); > > assert(x == y); // Always succeeds > > In other words, scoped values would no longer be strictly scoped. > That's what the "scoped" means in the name "scoped values". Strict > scoping is a fundamental property. > > > } > > > > I understand that in the proposed approach one can mess things up, I > > really do. But library instrumentors and tracing library creators > > would benefit from that sort of API. > > If we were planning to deprecate thread-local variables I think this > argument might have some merit. But we're not. They're not going away. > > > Also I've asked a different question... What if the users want to > > leverage the ScopedValues to get the current span information (or > > current principal from security point of view) but also they are > > using TL based libraries? How would the interop look like? > > As the JEP says, scoped values do not replace all uses of thread-local > variables. There are still some cases where thread-local variables > will be used, and this looks like one of them. > > > Let's assume that they put into the current scope a span that they > > want to have within that scope, we would need all the tracer > > libraries (and security components and others that use the same > > mechanism) to be ScopeValue aware. Would they first try to read SV > > and then if that's not there a TL? > > Yes, I think so. > > > They would need to most likely read SV and populate TL if the SV > > value is present so that other components that still rely on TL > > would work. That would have to also work the other way round, if a > > TL based library sets a value (e.g. span) then maybe the ScopedValue > > should be created with a scope for that new value? > > I'm not sure how that'd work in general, but there's nothing to stop > entry points for a library from doing so, and it might be a good idea. > Something like: > > if (someThreadLocal.get() != NOTHING) { > where(someScopedValue, someThreadLocal.get()).run(realEntry); > } else { > realEntry.run(); > } > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcin.grzejszczak at gmail.com Wed Jun 12 09:06:30 2024 From: marcin.grzejszczak at gmail.com (Marcin Grzejszczak) Date: Wed, 12 Jun 2024 09:06:30 +0000 Subject: ScopedValue.runWhere not returning scope In-Reply-To: <8E60140A-AACD-452E-8BA7-7E86AB4A7D24@icloud.com> References: <872DA66A-CBCB-4FB3-A029-429FBBB53B53@icloud.com> <907a0f81-ae09-4d43-addf-503b10959c3e@littlepinkcloud.com> <260d27bf-0855-4b27-8ebc-b54955ff41a0@littlepinkcloud.com> <34ae418e-f1bb-4f30-aea6-32cf727b6e46@littlepinkcloud.com> <8E60140A-AACD-452E-8BA7-7E86AB4A7D24@icloud.com> Message-ID: > I posted a minimalist ?tracing library? using ScopedValue here https://github.com/robaho/scope_trace Thanks for doing the example. >I think it is a fairly trivial change for tracing libraries to support ScopeValue instead of ThreadLocal if they wished to. As I presented by showing AFAIR 6 projects, not every single time the change would be trivial. Not all libraries give you the option to instrument the actual runnable (like an around aspect). Sometimes you have only before and after. Again, let me emphasise, I'm not saying that changing these libraries would not be possible. I'm saying that it wouldn't always be trivial and would require changes in various different projects. Pozdrawiam / Best regards, Marcin Grzejszczak https://marcin.grzejszczak.pl https://toomuchcoding.com wt., 11 cze 2024 o 15:25 Robert Engels napisa?(a): > I posted a minimalist ?tracing library? using ScopedValue here > https://github.com/robaho/scope_trace > > I think it is a fairly trivial change for tracing libraries to support > ScopeValue instead of ThreadLocal if they wished to. > > > On Jun 11, 2024, at 7:35 AM, Andrew Haley > wrote: > > On 6/11/24 11:32, Marcin Grzejszczak wrote: > > >> So why not produce an example of how it would be used? As far as I can > >> see, your proposal fails to ensure the property in the case I posted/ > > > > I've created samples at the very beginning with the before and after > > interceptor. I obviously know that I could rewrite the interceptor > > to become an around one but my point is that it's not an ideal > > solution to require instrumentors to rewrite everything. Also I > > still see this whole discussion as having two ways of doing the same > > thing. Current approach: > > > > ScopedValue.runWhere(scopedValue, someValue, () -> { > > codeToRun(); > > }); > > > > Proposed approach: > > > > try(Scope scope = ScopedValue.openScope(scopedValue, someValue)) { > > codeToRun(); > > This API fails the test I provided: > > final ScopedValue aScopedValue = ...; > final var x = aScopedValue.get(); > ScopedValue.openScope(aScopedValue, someValue); > final var y = aScopedValue.get(); > > assert(x == y); // Always succeeds > > In other words, scoped values would no longer be strictly scoped. > That's what the "scoped" means in the name "scoped values". Strict > scoping is a fundamental property. > > > } > > > > I understand that in the proposed approach one can mess things up, I > > really do. But library instrumentors and tracing library creators > > would benefit from that sort of API. > > If we were planning to deprecate thread-local variables I think this > argument might have some merit. But we're not. They're not going away. > > > Also I've asked a different question... What if the users want to > > leverage the ScopedValues to get the current span information (or > > current principal from security point of view) but also they are > > using TL based libraries? How would the interop look like? > > As the JEP says, scoped values do not replace all uses of thread-local > variables. There are still some cases where thread-local variables > will be used, and this looks like one of them. > > > Let's assume that they put into the current scope a span that they > > want to have within that scope, we would need all the tracer > > libraries (and security components and others that use the same > > mechanism) to be ScopeValue aware. Would they first try to read SV > > and then if that's not there a TL? > > Yes, I think so. > > > They would need to most likely read SV and populate TL if the SV > > value is present so that other components that still rely on TL > > would work. That would have to also work the other way round, if a > > TL based library sets a value (e.g. span) then maybe the ScopedValue > > should be created with a scope for that new value? > > I'm not sure how that'd work in general, but there's nothing to stop > entry points for a library from doing so, and it might be a good idea. > Something like: > > if (someThreadLocal.get() != NOTHING) { > where(someScopedValue, someThreadLocal.get()).run(realEntry); > } else { > realEntry.run(); > } > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcin.grzejszczak at gmail.com Wed Jun 12 10:26:29 2024 From: marcin.grzejszczak at gmail.com (Marcin Grzejszczak) Date: Wed, 12 Jun 2024 10:26:29 +0000 Subject: ScopedValue.runWhere not returning scope In-Reply-To: References: <872DA66A-CBCB-4FB3-A029-429FBBB53B53@icloud.com> <907a0f81-ae09-4d43-addf-503b10959c3e@littlepinkcloud.com> <260d27bf-0855-4b27-8ebc-b54955ff41a0@littlepinkcloud.com> <34ae418e-f1bb-4f30-aea6-32cf727b6e46@littlepinkcloud.com> Message-ID: I made a typo, let me fix it Anyways, the equivalent of... ScopedValue.runWhere(scopedValue, 1 () -> { codeToRun(); // scoped value equal to 1 ScopedValue.runWhere(scopedValue, 2, () -> { codeToRun(); // scoped value equal to 2 <-- here was a typo }); // scoped value equal to 1 }); // scoped value not having a value ... would be: try(Scope scope1 = ScopedValue.openScope(scopedValue, 1)) { codeToRun(); // scoped value equal to 1 try(Scope scope2 = ScopedValue.openScope(scopedValue, 2)) { codeToRun(); // scoped value equal to 2 } // scoped value equal to 1 } // scoped value not having a value Pozdrawiam / Best regards, Marcin Grzejszczak https://marcin.grzejszczak.pl https://toomuchcoding.com ?r., 12 cze 2024 o 09:02 Marcin Grzejszczak napisa?(a): > > This API fails the test I provided: > > > final ScopedValue aScopedValue = ...; > > final var x = aScopedValue.get(); > > ScopedValue.openScope(aScopedValue, someValue); > > final var y = aScopedValue.get(); > > > assert(x == y); // Always succeeds > > > In other words, scoped values would no longer be strictly scoped. > > That's what the "scoped" means in the name "scoped values". Strict > > scoping is a fundamental property. > > I mean you have not closed the scopes so no wonder it works as you > presented. I'm literally suggesting an option to allow manual control of > scopes. Of course people can mess up the opening and closing of scopes, I > do understand that. > > Anyways, the equivalent of... > > ScopedValue.runWhere(scopedValue, 1 () -> { > codeToRun(); // scoped value equal to 1 > ScopedValue.runWhere(scopedValue, 2, () -> { > codeToRun(); // scoped value equal to 1 > }); > // scoped value equal to 1 > }); > // scoped value not having a value > > ... would be: > > try(Scope scope1 = ScopedValue.openScope(scopedValue, 1)) { > codeToRun(); // scoped value equal to 1 > try(Scope scope2 = ScopedValue.openScope(scopedValue, 2)) { > codeToRun(); // scoped value equal to 2 > } > // scoped value equal to 1 > } > // scoped value not having a value > > I'm happy that we agree that there has to be an interop between TL and SV, > so here I have no other comments. > > Pozdrawiam / Best regards, > Marcin Grzejszczak > > https://marcin.grzejszczak.pl > https://toomuchcoding.com > > > wt., 11 cze 2024 o 12:35 Andrew Haley > napisa?(a): > >> On 6/11/24 11:32, Marcin Grzejszczak wrote: >> >> >> So why not produce an example of how it would be used? As far as I can >> >> see, your proposal fails to ensure the property in the case I posted/ >> > >> > I've created samples at the very beginning with the before and after >> > interceptor. I obviously know that I could rewrite the interceptor >> > to become an around one but my point is that it's not an ideal >> > solution to require instrumentors to rewrite everything. Also I >> > still see this whole discussion as having two ways of doing the same >> > thing. Current approach: >> > >> > ScopedValue.runWhere(scopedValue, someValue, () -> { >> > codeToRun(); >> > }); >> > >> > Proposed approach: >> > >> > try(Scope scope = ScopedValue.openScope(scopedValue, someValue)) { >> > codeToRun(); >> >> This API fails the test I provided: >> >> final ScopedValue aScopedValue = ...; >> final var x = aScopedValue.get(); >> ScopedValue.openScope(aScopedValue, someValue); >> final var y = aScopedValue.get(); >> >> assert(x == y); // Always succeeds >> >> In other words, scoped values would no longer be strictly scoped. >> That's what the "scoped" means in the name "scoped values". Strict >> scoping is a fundamental property. >> >> > } >> > >> > I understand that in the proposed approach one can mess things up, I >> > really do. But library instrumentors and tracing library creators >> > would benefit from that sort of API. >> >> If we were planning to deprecate thread-local variables I think this >> argument might have some merit. But we're not. They're not going away. >> >> > Also I've asked a different question... What if the users want to >> > leverage the ScopedValues to get the current span information (or >> > current principal from security point of view) but also they are >> > using TL based libraries? How would the interop look like? >> >> As the JEP says, scoped values do not replace all uses of thread-local >> variables. There are still some cases where thread-local variables >> will be used, and this looks like one of them. >> >> > Let's assume that they put into the current scope a span that they >> > want to have within that scope, we would need all the tracer >> > libraries (and security components and others that use the same >> > mechanism) to be ScopeValue aware. Would they first try to read SV >> > and then if that's not there a TL? >> >> Yes, I think so. >> >> > They would need to most likely read SV and populate TL if the SV >> > value is present so that other components that still rely on TL >> > would work. That would have to also work the other way round, if a >> > TL based library sets a value (e.g. span) then maybe the ScopedValue >> > should be created with a scope for that new value? >> >> I'm not sure how that'd work in general, but there's nothing to stop >> entry points for a library from doing so, and it might be a good idea. >> Something like: >> >> if (someThreadLocal.get() != NOTHING) { >> where(someScopedValue, someThreadLocal.get()).run(realEntry); >> } else { >> realEntry.run(); >> } >> >> -- >> Andrew Haley (he/him) >> Java Platform Lead Engineer >> Red Hat UK Ltd. >> https://keybase.io/andrewhaley >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at icloud.com Wed Jun 12 12:16:26 2024 From: robaho at icloud.com (robert engels) Date: Wed, 12 Jun 2024 07:16:26 -0500 Subject: ScopedValue.runWhere not returning scope Message-ID: An HTML attachment was scrubbed... URL: From robaho at icloud.com Wed Jun 12 12:55:23 2024 From: robaho at icloud.com (robert engels) Date: Wed, 12 Jun 2024 07:55:23 -0500 Subject: ScopedValue.runWhere not returning scope In-Reply-To: References: Message-ID: <11CF3C9C-8300-43BA-8241-DBE0BF4AB5DA@icloud.com> An HTML attachment was scrubbed... URL: From marcin.grzejszczak at gmail.com Thu Jun 13 09:48:27 2024 From: marcin.grzejszczak at gmail.com (Marcin Grzejszczak) Date: Thu, 13 Jun 2024 09:48:27 +0000 Subject: ScopedValue.runWhere not returning scope In-Reply-To: <11CF3C9C-8300-43BA-8241-DBE0BF4AB5DA@icloud.com> References: <11CF3C9C-8300-43BA-8241-DBE0BF4AB5DA@icloud.com> Message-ID: Robert, in that exact class that you're showing (the `ThreadLocalCurrentTraceContext` [1] ) you have the method @Override public Scope newScope(@Nullable TraceContext currentSpan) { final TraceContext previous = local.get(); local.set(currentSpan); Scope result = previous != null ? new RevertToPreviousScope(local, previous) : revertToNull; return decorateScope(currentSpan, result); } That very class extends the CurrentTraceContext that requires to define how you create a new Scope. How will that work with Scoped Values? [1] - https://github.com/openzipkin/brave/blob/6.0.3/brave/src/main/java/brave/propagation/ThreadLocalCurrentTraceContext.java Pozdrawiam / Best regards, Marcin Grzejszczak https://marcin.grzejszczak.pl https://toomuchcoding.com ?r., 12 cze 2024 o 12:55 robert engels napisa?(a): > Also, looking at brave, they seem to understand the various ways of > managing the current context. See > https://github.com/openzipkin/brave/tree/master/brave/src/main/java/brave/propagation > > and so plugging into this a context based on a ScopedValue seems trivial > (see notes in TraceContextThreadLocal) > > I would expect other libraries have similar features. > > On Jun 12, 2024, at 7:17?AM, robert engels wrote: > > ? > ? > ? > ? > ? > The code I provided will also work with before/after only tracers - the > around is a simplification of this. > > Wrapping of the Runnable would happen the same way all instrumentation is > done: manually, byte code manipulation, or dynamic proxies. > > The SV vs TL is only how the current context is obtained. It is trivial to > change between the two. > > I think it would be helpful if you created a project that uses the aspects > that demonstrates your perceived problem rather than the abstract > solutions. This feels like an XY problem. > > Or do nothing, TLs are not going away. > > > > > On Jun 12, 2024, at 4:07?AM, Marcin Grzejszczak < > marcin.grzejszczak at gmail.com> wrote: > > ? > > I posted a minimalist ?tracing library? using ScopedValue here > https://github.com/robaho/scope_trace > > Thanks for doing the example. > > >I think it is a fairly trivial change for tracing libraries to support > ScopeValue instead of ThreadLocal if they wished to. > > As I presented by showing AFAIR 6 projects, not every single time the > change would be trivial. Not all libraries give you the option to > instrument the actual runnable (like an around aspect). Sometimes you have > only before and after. Again, let me emphasise, I'm not saying that > changing these libraries would not be possible. I'm saying that it wouldn't > always be trivial and would require changes in various different projects. > > Pozdrawiam / Best regards, > Marcin Grzejszczak > > https://marcin.grzejszczak.pl > https://toomuchcoding.com > > > wt., 11 cze 2024 o 15:25 Robert Engels napisa?(a): > >> I posted a minimalist ?tracing library? using ScopedValue here >> https://github.com/robaho/scope_trace >> >> I think it is a fairly trivial change for tracing libraries to support >> ScopeValue instead of ThreadLocal if they wished to. >> >> >> On Jun 11, 2024, at 7:35 AM, Andrew Haley >> wrote: >> >> On 6/11/24 11:32, Marcin Grzejszczak wrote: >> >> >> So why not produce an example of how it would be used? As far as I can >> >> see, your proposal fails to ensure the property in the case I posted/ >> > >> > I've created samples at the very beginning with the before and after >> > interceptor. I obviously know that I could rewrite the interceptor >> > to become an around one but my point is that it's not an ideal >> > solution to require instrumentors to rewrite everything. Also I >> > still see this whole discussion as having two ways of doing the same >> > thing. Current approach: >> > >> > ScopedValue.runWhere(scopedValue, someValue, () -> { >> > codeToRun(); >> > }); >> > >> > Proposed approach: >> > >> > try(Scope scope = ScopedValue.openScope(scopedValue, someValue)) { >> > codeToRun(); >> >> This API fails the test I provided: >> >> final ScopedValue aScopedValue = ...; >> final var x = aScopedValue.get(); >> ScopedValue.openScope(aScopedValue, someValue); >> final var y = aScopedValue.get(); >> >> assert(x == y); // Always succeeds >> >> In other words, scoped values would no longer be strictly scoped. >> That's what the "scoped" means in the name "scoped values". Strict >> scoping is a fundamental property. >> >> > } >> > >> > I understand that in the proposed approach one can mess things up, I >> > really do. But library instrumentors and tracing library creators >> > would benefit from that sort of API. >> >> If we were planning to deprecate thread-local variables I think this >> argument might have some merit. But we're not. They're not going away. >> >> > Also I've asked a different question... What if the users want to >> > leverage the ScopedValues to get the current span information (or >> > current principal from security point of view) but also they are >> > using TL based libraries? How would the interop look like? >> >> As the JEP says, scoped values do not replace all uses of thread-local >> variables. There are still some cases where thread-local variables >> will be used, and this looks like one of them. >> >> > Let's assume that they put into the current scope a span that they >> > want to have within that scope, we would need all the tracer >> > libraries (and security components and others that use the same >> > mechanism) to be ScopeValue aware. Would they first try to read SV >> > and then if that's not there a TL? >> >> Yes, I think so. >> >> > They would need to most likely read SV and populate TL if the SV >> > value is present so that other components that still rely on TL >> > would work. That would have to also work the other way round, if a >> > TL based library sets a value (e.g. span) then maybe the ScopedValue >> > should be created with a scope for that new value? >> >> I'm not sure how that'd work in general, but there's nothing to stop >> entry points for a library from doing so, and it might be a good idea. >> Something like: >> >> if (someThreadLocal.get() != NOTHING) { >> where(someScopedValue, someThreadLocal.get()).run(realEntry); >> } else { >> realEntry.run(); >> } >> >> -- >> Andrew Haley (he/him) >> Java Platform Lead Engineer >> Red Hat UK Ltd. >> https://keybase.io/andrewhaley >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Thu Jun 13 10:35:51 2024 From: duke at openjdk.org (duke) Date: Thu, 13 Jun 2024 10:35:51 GMT Subject: git: openjdk/loom: fibers: 32 new changesets Message-ID: <3309a06a-0541-4ac6-9a0c-020278543a4f@openjdk.org> Changeset: badf1cb9 Author: Albert Mingkun Yang Date: 2024-06-11 06:57:05 +0000 URL: https://git.openjdk.org/loom/commit/badf1cb9ce9dcae6cca92046f7cc1231067ca799 8331675: gtest CollectorPolicy.young_min_ergo_vm fails after 8272364 Reviewed-by: tschatzl, zgu, gli ! test/hotspot/gtest/gc/shared/test_collectorPolicy.cpp Changeset: 0e4d4a0c Author: Bhavana Kilambi Committer: Emanuel Peter Date: 2024-06-11 07:16:56 +0000 URL: https://git.openjdk.org/loom/commit/0e4d4a0c3150c01d927bd69cc578cea053cf16b3 8320725: AArch64: C2: Add "requires_strict_order" flag for floating-point add and mul reduction Co-authored-by: Eric Liu Reviewed-by: gli, epeter, aph ! src/hotspot/cpu/aarch64/aarch64_vector.ad ! src/hotspot/cpu/aarch64/aarch64_vector_ad.m4 ! src/hotspot/share/opto/loopnode.hpp ! src/hotspot/share/opto/loopopts.cpp ! src/hotspot/share/opto/node.hpp ! src/hotspot/share/opto/vectorIntrinsics.cpp ! src/hotspot/share/opto/vectornode.cpp ! src/hotspot/share/opto/vectornode.hpp + test/hotspot/jtreg/compiler/loopopts/superword/TestVectorFPReduction.java + test/hotspot/jtreg/compiler/vectorapi/TestVectorAddMulReduction.java Changeset: 788b876e Author: Albert Mingkun Yang Date: 2024-06-11 07:53:53 +0000 URL: https://git.openjdk.org/loom/commit/788b876ebd631bdaea99954196eae47b18c49e86 8333917: G1: Refactor G1CollectedHeap::register_old_region_with_region_attr Reviewed-by: gli, tschatzl ! src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp Changeset: 93f3918e Author: Albert Mingkun Yang Date: 2024-06-11 08:37:47 +0000 URL: https://git.openjdk.org/loom/commit/93f3918ee16fd4360f1d57c379a4bdc4baa88f2b 8333954: Parallel: Remove unused arguments of type ParCompactionManager* Reviewed-by: iwalulya ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/gc/parallel/psParallelCompact.hpp Changeset: 28437459 Author: Albert Mingkun Yang Date: 2024-06-11 11:23:53 +0000 URL: https://git.openjdk.org/loom/commit/28437459fb78eda616d50917580c10ed16a4aeff 8333972: Parallel: Remove unused methods in PSOldGen Reviewed-by: iwalulya ! src/hotspot/share/gc/parallel/psOldGen.hpp Changeset: ef101f1b Author: Christian Hagedorn Date: 2024-06-11 11:32:12 +0000 URL: https://git.openjdk.org/loom/commit/ef101f1bf20f2813f855af4bc4eb317565175208 8332920: C2: Partial Peeling is wrongly applied for CmpU with negative limit Reviewed-by: kvn, thartmann, epeter ! src/hotspot/share/opto/loopopts.cpp + test/hotspot/jtreg/compiler/loopopts/TestPartialPeelAtUnsignedTestsNegativeLimit.java Changeset: aaaa86b5 Author: Renjith Kannath Pariyangad Committer: Alexey Ivanov Date: 2024-06-11 11:47:19 +0000 URL: https://git.openjdk.org/loom/commit/aaaa86b57172d45d1126c50efc270c6e49aba7a5 8333360: PrintNullString.java doesn't use float arguments Reviewed-by: aivanov, abhiscxk, achung ! test/jdk/java/awt/print/PrinterJob/PrintNullString.java Changeset: b77bd5fd Author: Daniel Jeli?ski Date: 2024-06-11 17:34:09 +0000 URL: https://git.openjdk.org/loom/commit/b77bd5fd6a6f7ddbed90300fba790da4fb683275 8333742: ProcessImpl and ProcessHandleImpl may mishandle processes that exit with code 259 Reviewed-by: rriggs ! src/java.base/windows/classes/java/lang/ProcessImpl.java ! src/java.base/windows/native/libjava/ProcessHandleImpl_win.c ! src/java.base/windows/native/libjava/ProcessImpl_md.c ! test/jdk/java/lang/ProcessHandle/OnExitTest.java Changeset: 7ed8a5c4 Author: Leonid Mesnik Date: 2024-06-11 18:40:20 +0000 URL: https://git.openjdk.org/loom/commit/7ed8a5c431e1cba34167896f8d331caf594852ef 8333841: Add more logging into setfldw001 tests Reviewed-by: cjplummer, amenkov, sspitsyn ! test/hotspot/jtreg/ProblemList-Xcomp.txt ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldAccessWatch/setfldw001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldAccessWatch/setfldw001/setfldw001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw001/setfmodw001.cpp Changeset: bbd3b1d8 Author: Alexandre Iline Date: 2024-06-11 20:10:46 +0000 URL: https://git.openjdk.org/loom/commit/bbd3b1d812da997347fca4c06e22794285ab00d3 8334036: Update JCov for class file version 68 Reviewed-by: alanb, erikj ! make/conf/jib-profiles.js Changeset: 56e8e607 Author: Leonid Mesnik Date: 2024-06-11 21:03:20 +0000 URL: https://git.openjdk.org/loom/commit/56e8e60792b23bc101f46b497dcc9d3c76855384 8330534: Update nsk/jdwp tests to use driver instead of othervm Reviewed-by: sspitsyn, cjplummer ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ArrayReference/GetValues/getvalues001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ArrayReference/GetValues/getvalues001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ArrayReference/GetValues/getvalues002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ArrayReference/GetValues/getvalues002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ArrayReference/Length/length001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ArrayReference/Length/length001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ArrayReference/SetValues/setvalues001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ArrayReference/SetValues/setvalues001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ArrayType/NewInstance/newinstance001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ArrayType/NewInstance/newinstance001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ClassLoaderReference/VisibleClasses/visibclasses001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ClassLoaderReference/VisibleClasses/visibclasses001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ClassObjectReference/ReflectedType/reflectype001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ClassObjectReference/ReflectedType/reflectype001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ClassType/InvokeMethod/invokemeth001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ClassType/InvokeMethod/invokemeth001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ClassType/NewInstance/newinst001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ClassType/NewInstance/newinst001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ClassType/SetValues/setvalues001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ClassType/SetValues/setvalues001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ClassType/Superclass/superclass001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ClassType/Superclass/superclass001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/BREAKPOINT/breakpoint001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/BREAKPOINT/breakpoint001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/CLASS_PREPARE/clsprepare001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/CLASS_PREPARE/clsprepare001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/CLASS_UNLOAD/clsunload001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/CLASS_UNLOAD/clsunload001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/Composite/composite001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/Composite/composite001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/EXCEPTION/exception001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/EXCEPTION/exception001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/FIELD_ACCESS/fldaccess001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/FIELD_ACCESS/fldaccess001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/FIELD_MODIFICATION/fldmodification001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/FIELD_MODIFICATION/fldmodification001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/METHOD_ENTRY/methentry001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/METHOD_ENTRY/methentry001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/METHOD_EXIT/methexit001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/METHOD_EXIT/methexit001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/SINGLE_STEP/singlestep001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/SINGLE_STEP/singlestep001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/SINGLE_STEP/singlestep002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/SINGLE_STEP/singlestep002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/SINGLE_STEP/singlestep003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/SINGLE_STEP/singlestep003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/THREAD_DEATH/thrdeath001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/THREAD_DEATH/thrdeath001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/THREAD_START/thrstart001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/THREAD_START/thrstart001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/VM_DEATH/vmdeath001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/VM_DEATH/vmdeath001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/VM_DEATH/vmdeath002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/VM_DEATH/vmdeath002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/VM_START/vmstart001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/VM_START/vmstart001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/EventRequest/Clear/clear001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/EventRequest/Clear/clear001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/EventRequest/ClearAllBreakpoints/clrallbreakp001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/EventRequest/ClearAllBreakpoints/clrallbreakp001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/EventRequest/ClearAllBreakpoints/clrallbreakp002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/EventRequest/ClearAllBreakpoints/clrallbreakp002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/EventRequest/ClearAllBreakpoints/clrallbreakp003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/EventRequest/ClearAllBreakpoints/clrallbreakp003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/EventRequest/Set/set001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/EventRequest/Set/set001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/EventRequest/Set/set002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/EventRequest/Set/set002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Method/Bytecodes/bytecodes001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Method/Bytecodes/bytecodes001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Method/IsObsolete/isobsolete001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Method/IsObsolete/isobsolete001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Method/IsObsolete/isobsolete002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Method/IsObsolete/isobsolete002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Method/LineTable/linetable001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Method/LineTable/linetable001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Method/VariableTable/vartable001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Method/VariableTable/vartable001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Method/VariableTableWithGeneric/vartblwithgen001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Method/VariableTableWithGeneric/vartblwithgen001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ObjectReference/DisableCollection/disablecol001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ObjectReference/DisableCollection/disablecol001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ObjectReference/EnableCollection/enablecol001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ObjectReference/EnableCollection/enablecol001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ObjectReference/GetValues/getvalues001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ObjectReference/GetValues/getvalues001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ObjectReference/InvokeMethod/invokemeth001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ObjectReference/InvokeMethod/invokemeth001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ObjectReference/IsCollected/iscollected001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ObjectReference/IsCollected/iscollected001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ObjectReference/MonitorInfo/monitorinfo001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ObjectReference/MonitorInfo/monitorinfo001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ObjectReference/ReferenceType/referencetype001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ObjectReference/ReferenceType/referencetype001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ObjectReference/ReferringObjects/referringObjects001/referringObjects001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ObjectReference/ReferringObjects/referringObjects002/referringObjects002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ObjectReference/SetValues/setvalues001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ObjectReference/SetValues/setvalues001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/ClassLoader/classloader001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/ClassLoader/classloader001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/ClassObject/classobj001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/ClassObject/classobj001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/Fields/fields001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/Fields/fields001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/FieldsWithGeneric/fldwithgeneric001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/FieldsWithGeneric/fldwithgeneric001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/GetValues/getvalues001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/GetValues/getvalues001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/Instances/instances001/instances001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/Instances/instances002/instances002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/Interfaces/interfaces001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/Interfaces/interfaces001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/Methods/methods001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/Methods/methods001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/MethodsWithGeneric/methwithgeneric001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/MethodsWithGeneric/methwithgeneric001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/Modifiers/modifiers001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/Modifiers/modifiers001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/NestedTypes/nestedtypes001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/NestedTypes/nestedtypes001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/Signature/signature001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/Signature/signature001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/SignatureWithGeneric/sigwithgeneric001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/SignatureWithGeneric/sigwithgeneric001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/SourceDebugExtension/srcdebugext001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/SourceDebugExtension/srcdebugext001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/SourceFile/srcfile001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/SourceFile/srcfile001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/Status/status001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/Status/status001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/StackFrame/GetValues/getvalues001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/StackFrame/GetValues/getvalues001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/StackFrame/PopFrames/popframes001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/StackFrame/PopFrames/popframes001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/StackFrame/SetValues/setvalues001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/StackFrame/SetValues/setvalues001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/StackFrame/ThisObject/thisobject001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/StackFrame/ThisObject/thisobject001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/StringReference/Value/value001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/StringReference/Value/value001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadGroupReference/Children/children001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadGroupReference/Children/children001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadGroupReference/Name/name001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadGroupReference/Name/name001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadGroupReference/Parent/parent001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadGroupReference/Parent/parent001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/CurrentContendedMonitor/curcontmonitor001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/CurrentContendedMonitor/curcontmonitor001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/ForceEarlyReturn/forceEarlyReturn001/forceEarlyReturn001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/ForceEarlyReturn/forceEarlyReturn002/forceEarlyReturn002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/FrameCount/framecnt001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/FrameCount/framecnt001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/Frames/frames001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/Frames/frames001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/Interrupt/interrupt001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/Interrupt/interrupt001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/Name/name001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/Name/name001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/OwnedMonitors/ownmonitors001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/OwnedMonitors/ownmonitors001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/OwnedMonitorsStackDepthInfo/ownedMonitorsStackDepthInfo001/ownedMonitorsStackDepthInfo001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/OwnedMonitorsStackDepthInfo/ownedMonitorsStackDepthInfo002/ownedMonitorsStackDepthInfo002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/Resume/resume001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/Resume/resume001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/Status/status001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/Status/status001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/Stop/stop001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/Stop/stop001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/Suspend/suspend001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/Suspend/suspend001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/SuspendCount/suspendcnt001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/SuspendCount/suspendcnt001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/ThreadGroup/threadgroup001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/ThreadGroup/threadgroup001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/AllClasses/allclasses001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/AllClasses/allclasses001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/AllClassesWithGeneric/allclswithgeneric001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/AllClassesWithGeneric/allclswithgeneric001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/AllThreads/allthreads001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/AllThreads/allthreads001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/Capabilities/capabilities001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/Capabilities/capabilities001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/CapabilitiesNew/capabilitiesnew001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/CapabilitiesNew/capabilitiesnew001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/ClassPaths/classpaths001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/ClassPaths/classpaths001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/ClassesBySignature/classbysig001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/ClassesBySignature/classbysig001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/CreateString/createstr001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/CreateString/createstr001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/Dispose/dispose001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/Dispose/dispose001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/DisposeObjects/disposeobj001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/DisposeObjects/disposeobj001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/Exit/exit001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/Exit/exit001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/HoldEvents/holdevents001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/HoldEvents/holdevents001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/HoldEvents/holdevents002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/IDSizes/idsizes001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/IDSizes/idsizes001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/InstanceCounts/instanceCounts001/instanceCounts001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/RedefineClasses/redefinecls001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/RedefineClasses/redefinecls001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/ReleaseEvents/releaseevents001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/ReleaseEvents/releaseevents001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/ReleaseEvents/releaseevents002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/ReleaseEvents/releaseevents002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/Resume/resume001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/Resume/resume001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/SetDefaultStratum/setdefstrat001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/SetDefaultStratum/setdefstrat001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/TopLevelThreadGroups/threadgroups001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/TopLevelThreadGroups/threadgroups001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/Version/version001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/Version/version001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/Version/version002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/Version/version002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeBinder.java Changeset: a7205cc6 Author: William Kemper Date: 2024-06-11 22:09:52 +0000 URL: https://git.openjdk.org/loom/commit/a7205cc6512796466fefe17d171082995e0966de 8333926: Shenandoah: Lower default immediate garbage threshold Reviewed-by: kdnilsen, ysr ! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp Changeset: 1c80ddb8 Author: Prasanta Sadhukhan Date: 2024-06-12 05:32:06 +0000 URL: https://git.openjdk.org/loom/commit/1c80ddb8efdb883623652b20849413b602c10c36 8333940: Ensure javax/swing/TestUngrab.java run on all platforms Reviewed-by: tr ! test/jdk/javax/swing/JMenu/TestUngrab.java Changeset: bd046d9b Author: Jaikiran Pai Date: 2024-06-12 05:36:30 +0000 URL: https://git.openjdk.org/loom/commit/bd046d9b9e79e4eea89c72af358961ef6e98e660 8222884: ConcurrentClassDescLookup.java times out intermittently Reviewed-by: rriggs, mbaesken ! test/jdk/java/io/Serializable/concurrentClassDescLookup/ConcurrentClassDescLookup.java Changeset: abbf45b5 Author: Matthias Baesken Date: 2024-06-12 06:18:31 +0000 URL: https://git.openjdk.org/loom/commit/abbf45b57edf2f5bf9a3f2fa408f35a43ebe9bb9 8332699: ubsan: jfrEventSetting.inline.hpp:31:43: runtime error: index 163 out of bounds for type 'jfrNativeEventSetting [162]' Reviewed-by: jbechberger, stuefe ! make/src/classes/build/tools/jfr/GenerateJfrFiles.java Changeset: a7e4ab93 Author: Matthias Baesken Date: 2024-06-12 07:06:29 +0000 URL: https://git.openjdk.org/loom/commit/a7e4ab9300730c32f6cf0dafd48f5e093f4ac0be 8333730: ubsan: FieldIndices/libFieldIndicesTest.cpp:276:11: runtime error: null pointer passed as argument 2, which is declared to never be null Reviewed-by: cjplummer, amenkov ! test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp Changeset: a0318bc8 Author: Tobias Hartmann Date: 2024-06-12 09:18:53 +0000 URL: https://git.openjdk.org/loom/commit/a0318bc873f019b6d11571cfd4113ca8cc183b9c 8334077: Fix problem list entries for compiler tests Reviewed-by: chagedorn ! test/hotspot/jtreg/ProblemList.txt Changeset: c80e2eb3 Author: Per Minborg Date: 2024-06-12 09:35:48 +0000 URL: https://git.openjdk.org/loom/commit/c80e2eb35c4eb03f17a2a31e979e5c369453e203 8333886: Explicitly specify that asSlice and reinterpret return a memory segment backed by the same region of memory. Reviewed-by: jvernee, mcimadamore ! src/java.base/share/classes/java/lang/foreign/MemorySegment.java Changeset: bd750b6b Author: Doug Simon Date: 2024-06-12 10:03:39 +0000 URL: https://git.openjdk.org/loom/commit/bd750b6b783101a3b992a25e7bc64777bb08de18 8319933: Disable tests for JDK-8280481 on Graal Reviewed-by: chagedorn ! test/hotspot/jtreg/compiler/sharedstubs/SharedStubToInterpTest.java Changeset: 81ca0ece Author: Daniel Fuchs Date: 2024-06-12 10:53:08 +0000 URL: https://git.openjdk.org/loom/commit/81ca0ece2e69477b3d22a40c51e044d56e13b6e4 8334028: HttpClient: NPE thrown from assert statement Reviewed-by: jpai ! src/java.net.http/share/classes/jdk/internal/net/http/ResponseSubscribers.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java ! test/jdk/java/net/httpclient/BodySubscribersTest.java Changeset: 81083a0e Author: Daniel Fuchs Date: 2024-06-12 11:29:58 +0000 URL: https://git.openjdk.org/loom/commit/81083a0e10d9c92f5247ae256e170709014b596b 8299487: Test java/net/httpclient/whitebox/SSLTubeTestDriver.java timed out Reviewed-by: jpai ! test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/SSLTubeTest.java Changeset: 5a8a9fdf Author: Amit Kumar Date: 2024-06-12 13:24:58 +0000 URL: https://git.openjdk.org/loom/commit/5a8a9fdfa599e8939a5c6675883a92c869474979 8333382: [s390x] Enhance popcnt Instruction to use Z15 facilities Reviewed-by: lucy, aph ! src/hotspot/cpu/s390/assembler_s390.hpp ! src/hotspot/cpu/s390/assembler_s390.inline.hpp ! src/hotspot/cpu/s390/macroAssembler_s390.cpp ! src/hotspot/cpu/s390/macroAssembler_s390.hpp ! src/hotspot/cpu/s390/s390.ad + test/micro/org/openjdk/bench/vm/compiler/PopCount.java Changeset: 2c9185eb Author: Fei Gao Date: 2024-06-12 13:29:45 +0000 URL: https://git.openjdk.org/loom/commit/2c9185eb81c9dfcc30d160a6254089c474b56b0d 8321308: AArch64: Fix matching predication for cbz/cbnz Reviewed-by: fyang, adinn, aph ! src/hotspot/cpu/aarch64/aarch64.ad + test/hotspot/jtreg/compiler/c2/irTests/TestArrLenCheckOptimization.java ! test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java Changeset: ba67ad63 Author: Alexey Semenyuk Date: 2024-06-12 13:37:03 +0000 URL: https://git.openjdk.org/loom/commit/ba67ad63ae7d7d399e41ab258576123fb6d9502c 8319457: Update jpackage to support WiX v4 and v5 on Windows Reviewed-by: almatvee ! make/modules/jdk.jpackage/Java.gmk ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixAppImageFragmentBuilder.java ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixFragmentBuilder.java ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixPipeline.java + src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixSourceConverter.java ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixTool.java + src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixToolset.java ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixUiFragmentBuilder.java ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/InstallDirNotEmptyDlg.wxs ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_de.wxl ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_en.wxl ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_ja.wxl ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_zh_CN.wxl ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources.properties ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_de.properties ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_ja.properties ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_zh_CN.properties ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/overrides.wxi + src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/wix3-to-wix4-conv.xsl ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/WindowsHelper.java ! test/jdk/tools/jpackage/windows/WinL10nTest.java Changeset: 2c1da6c6 Author: Axel Boldt-Christmas Date: 2024-06-12 14:06:53 +0000 URL: https://git.openjdk.org/loom/commit/2c1da6c6fa2e50856ea71c0e266961171bee1037 8332139: SymbolTableHash::Node allocations allocates twice the required memory Reviewed-by: iwalulya, coleenp ! src/hotspot/share/classfile/symbolTable.cpp ! src/hotspot/share/oops/symbol.hpp ! src/hotspot/share/utilities/concurrentHashTable.hpp ! src/hotspot/share/utilities/concurrentHashTable.inline.hpp Changeset: b697b48a Author: Alisen Chung Date: 2024-06-12 18:44:07 +0000 URL: https://git.openjdk.org/loom/commit/b697b48a0133458983caea4acc6de8de3e56d356 8315655: [macos] Right click and dragging over a component with a popup menu will open the popup Reviewed-by: dnguyen, psadhukhan ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CTrayIcon.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/NSEvent.java + test/jdk/javax/swing/JPopupMenu/MouseDragPopupTest.java Changeset: 74468bc1 Author: Ben Perez Committer: Sean Mullan Date: 2024-06-12 18:59:26 +0000 URL: https://git.openjdk.org/loom/commit/74468bc1f3aff7f53b91e342711dc095d97fdfed 8209092: Remove outdated wording from RC5ParameterSpec Reviewed-by: mullan ! src/java.base/share/classes/javax/crypto/spec/RC5ParameterSpec.java Changeset: fcedde80 Author: Inigo Mediavilla Saiz Committer: David Holmes Date: 2024-06-12 23:18:27 +0000 URL: https://git.openjdk.org/loom/commit/fcedde804277af5a26febdcfb7817858d72f01ab 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump Reviewed-by: dholmes, alanb ! src/hotspot/share/runtime/threads.cpp + test/hotspot/jtreg/serviceability/dcmd/thread/PrintMountedVirtualThread.java Changeset: 238162a3 Author: David Holmes Date: 2024-06-13 02:53:48 +0000 URL: https://git.openjdk.org/loom/commit/238162a3b8ce307659420661903a7f8ac1f06979 8322064: Remove expired flags in JDK 24 Reviewed-by: kvn, stuefe ! src/hotspot/share/runtime/arguments.cpp ! src/java.base/share/man/java.1 Changeset: 301bd708 Author: Abhishek Kumar Date: 2024-06-13 04:49:58 +0000 URL: https://git.openjdk.org/loom/commit/301bd7085654328f941c462bc786e995051d1a9c 8311110: multichar warning in WinAccessBridge.cpp Reviewed-by: djelinski, jwaters, prr ! src/jdk.accessibility/windows/native/libwindowsaccessbridge/WinAccessBridge.cpp Changeset: 90f632a0 Author: Alan Bateman Date: 2024-06-13 07:01:15 +0000 URL: https://git.openjdk.org/loom/commit/90f632a0b0c677f0d315c7af48b54e87a39d6776 Merge ! src/hotspot/cpu/s390/macroAssembler_s390.cpp ! src/hotspot/share/runtime/threads.cpp ! test/hotspot/jtreg/ProblemList-Xcomp.txt ! test/hotspot/jtreg/ProblemList.txt ! src/hotspot/cpu/s390/macroAssembler_s390.cpp ! src/hotspot/share/runtime/threads.cpp ! test/hotspot/jtreg/ProblemList-Xcomp.txt ! test/hotspot/jtreg/ProblemList.txt Changeset: fae437a8 Author: Alan Bateman Date: 2024-06-13 11:32:16 +0000 URL: https://git.openjdk.org/loom/commit/fae437a85dbac02548433e9578e8fee01efaadea Exclude serviceability/dcmd/thread/PrintMountedVirtualThread.jav ! test/hotspot/jtreg/ProblemList-Virtual.txt From duke at openjdk.org Thu Jun 13 10:37:35 2024 From: duke at openjdk.org (duke) Date: Thu, 13 Jun 2024 10:37:35 GMT Subject: git: openjdk/loom: master: 30 new changesets Message-ID: <0f085143-c763-4bb7-829b-e565b35af978@openjdk.org> Changeset: badf1cb9 Author: Albert Mingkun Yang Date: 2024-06-11 06:57:05 +0000 URL: https://git.openjdk.org/loom/commit/badf1cb9ce9dcae6cca92046f7cc1231067ca799 8331675: gtest CollectorPolicy.young_min_ergo_vm fails after 8272364 Reviewed-by: tschatzl, zgu, gli ! test/hotspot/gtest/gc/shared/test_collectorPolicy.cpp Changeset: 0e4d4a0c Author: Bhavana Kilambi Committer: Emanuel Peter Date: 2024-06-11 07:16:56 +0000 URL: https://git.openjdk.org/loom/commit/0e4d4a0c3150c01d927bd69cc578cea053cf16b3 8320725: AArch64: C2: Add "requires_strict_order" flag for floating-point add and mul reduction Co-authored-by: Eric Liu Reviewed-by: gli, epeter, aph ! src/hotspot/cpu/aarch64/aarch64_vector.ad ! src/hotspot/cpu/aarch64/aarch64_vector_ad.m4 ! src/hotspot/share/opto/loopnode.hpp ! src/hotspot/share/opto/loopopts.cpp ! src/hotspot/share/opto/node.hpp ! src/hotspot/share/opto/vectorIntrinsics.cpp ! src/hotspot/share/opto/vectornode.cpp ! src/hotspot/share/opto/vectornode.hpp + test/hotspot/jtreg/compiler/loopopts/superword/TestVectorFPReduction.java + test/hotspot/jtreg/compiler/vectorapi/TestVectorAddMulReduction.java Changeset: 788b876e Author: Albert Mingkun Yang Date: 2024-06-11 07:53:53 +0000 URL: https://git.openjdk.org/loom/commit/788b876ebd631bdaea99954196eae47b18c49e86 8333917: G1: Refactor G1CollectedHeap::register_old_region_with_region_attr Reviewed-by: gli, tschatzl ! src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp Changeset: 93f3918e Author: Albert Mingkun Yang Date: 2024-06-11 08:37:47 +0000 URL: https://git.openjdk.org/loom/commit/93f3918ee16fd4360f1d57c379a4bdc4baa88f2b 8333954: Parallel: Remove unused arguments of type ParCompactionManager* Reviewed-by: iwalulya ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/gc/parallel/psParallelCompact.hpp Changeset: 28437459 Author: Albert Mingkun Yang Date: 2024-06-11 11:23:53 +0000 URL: https://git.openjdk.org/loom/commit/28437459fb78eda616d50917580c10ed16a4aeff 8333972: Parallel: Remove unused methods in PSOldGen Reviewed-by: iwalulya ! src/hotspot/share/gc/parallel/psOldGen.hpp Changeset: ef101f1b Author: Christian Hagedorn Date: 2024-06-11 11:32:12 +0000 URL: https://git.openjdk.org/loom/commit/ef101f1bf20f2813f855af4bc4eb317565175208 8332920: C2: Partial Peeling is wrongly applied for CmpU with negative limit Reviewed-by: kvn, thartmann, epeter ! src/hotspot/share/opto/loopopts.cpp + test/hotspot/jtreg/compiler/loopopts/TestPartialPeelAtUnsignedTestsNegativeLimit.java Changeset: aaaa86b5 Author: Renjith Kannath Pariyangad Committer: Alexey Ivanov Date: 2024-06-11 11:47:19 +0000 URL: https://git.openjdk.org/loom/commit/aaaa86b57172d45d1126c50efc270c6e49aba7a5 8333360: PrintNullString.java doesn't use float arguments Reviewed-by: aivanov, abhiscxk, achung ! test/jdk/java/awt/print/PrinterJob/PrintNullString.java Changeset: b77bd5fd Author: Daniel Jeli?ski Date: 2024-06-11 17:34:09 +0000 URL: https://git.openjdk.org/loom/commit/b77bd5fd6a6f7ddbed90300fba790da4fb683275 8333742: ProcessImpl and ProcessHandleImpl may mishandle processes that exit with code 259 Reviewed-by: rriggs ! src/java.base/windows/classes/java/lang/ProcessImpl.java ! src/java.base/windows/native/libjava/ProcessHandleImpl_win.c ! src/java.base/windows/native/libjava/ProcessImpl_md.c ! test/jdk/java/lang/ProcessHandle/OnExitTest.java Changeset: 7ed8a5c4 Author: Leonid Mesnik Date: 2024-06-11 18:40:20 +0000 URL: https://git.openjdk.org/loom/commit/7ed8a5c431e1cba34167896f8d331caf594852ef 8333841: Add more logging into setfldw001 tests Reviewed-by: cjplummer, amenkov, sspitsyn ! test/hotspot/jtreg/ProblemList-Xcomp.txt ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldAccessWatch/setfldw001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldAccessWatch/setfldw001/setfldw001.cpp ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/SetFieldModificationWatch/setfmodw001/setfmodw001.cpp Changeset: bbd3b1d8 Author: Alexandre Iline Date: 2024-06-11 20:10:46 +0000 URL: https://git.openjdk.org/loom/commit/bbd3b1d812da997347fca4c06e22794285ab00d3 8334036: Update JCov for class file version 68 Reviewed-by: alanb, erikj ! make/conf/jib-profiles.js Changeset: 56e8e607 Author: Leonid Mesnik Date: 2024-06-11 21:03:20 +0000 URL: https://git.openjdk.org/loom/commit/56e8e60792b23bc101f46b497dcc9d3c76855384 8330534: Update nsk/jdwp tests to use driver instead of othervm Reviewed-by: sspitsyn, cjplummer ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ArrayReference/GetValues/getvalues001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ArrayReference/GetValues/getvalues001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ArrayReference/GetValues/getvalues002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ArrayReference/GetValues/getvalues002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ArrayReference/Length/length001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ArrayReference/Length/length001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ArrayReference/SetValues/setvalues001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ArrayReference/SetValues/setvalues001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ArrayType/NewInstance/newinstance001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ArrayType/NewInstance/newinstance001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ClassLoaderReference/VisibleClasses/visibclasses001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ClassLoaderReference/VisibleClasses/visibclasses001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ClassObjectReference/ReflectedType/reflectype001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ClassObjectReference/ReflectedType/reflectype001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ClassType/InvokeMethod/invokemeth001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ClassType/InvokeMethod/invokemeth001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ClassType/NewInstance/newinst001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ClassType/NewInstance/newinst001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ClassType/SetValues/setvalues001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ClassType/SetValues/setvalues001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ClassType/Superclass/superclass001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ClassType/Superclass/superclass001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/BREAKPOINT/breakpoint001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/BREAKPOINT/breakpoint001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/CLASS_PREPARE/clsprepare001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/CLASS_PREPARE/clsprepare001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/CLASS_UNLOAD/clsunload001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/CLASS_UNLOAD/clsunload001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/Composite/composite001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/Composite/composite001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/EXCEPTION/exception001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/EXCEPTION/exception001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/FIELD_ACCESS/fldaccess001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/FIELD_ACCESS/fldaccess001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/FIELD_MODIFICATION/fldmodification001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/FIELD_MODIFICATION/fldmodification001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/METHOD_ENTRY/methentry001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/METHOD_ENTRY/methentry001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/METHOD_EXIT/methexit001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/METHOD_EXIT/methexit001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/SINGLE_STEP/singlestep001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/SINGLE_STEP/singlestep001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/SINGLE_STEP/singlestep002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/SINGLE_STEP/singlestep002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/SINGLE_STEP/singlestep003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/SINGLE_STEP/singlestep003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/THREAD_DEATH/thrdeath001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/THREAD_DEATH/thrdeath001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/THREAD_START/thrstart001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/THREAD_START/thrstart001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/VM_DEATH/vmdeath001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/VM_DEATH/vmdeath001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/VM_DEATH/vmdeath002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/VM_DEATH/vmdeath002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/VM_START/vmstart001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Event/VM_START/vmstart001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/EventRequest/Clear/clear001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/EventRequest/Clear/clear001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/EventRequest/ClearAllBreakpoints/clrallbreakp001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/EventRequest/ClearAllBreakpoints/clrallbreakp001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/EventRequest/ClearAllBreakpoints/clrallbreakp002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/EventRequest/ClearAllBreakpoints/clrallbreakp002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/EventRequest/ClearAllBreakpoints/clrallbreakp003.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/EventRequest/ClearAllBreakpoints/clrallbreakp003/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/EventRequest/Set/set001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/EventRequest/Set/set001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/EventRequest/Set/set002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/EventRequest/Set/set002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Method/Bytecodes/bytecodes001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Method/Bytecodes/bytecodes001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Method/IsObsolete/isobsolete001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Method/IsObsolete/isobsolete001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Method/IsObsolete/isobsolete002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Method/IsObsolete/isobsolete002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Method/LineTable/linetable001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Method/LineTable/linetable001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Method/VariableTable/vartable001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Method/VariableTable/vartable001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Method/VariableTableWithGeneric/vartblwithgen001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/Method/VariableTableWithGeneric/vartblwithgen001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ObjectReference/DisableCollection/disablecol001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ObjectReference/DisableCollection/disablecol001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ObjectReference/EnableCollection/enablecol001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ObjectReference/EnableCollection/enablecol001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ObjectReference/GetValues/getvalues001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ObjectReference/GetValues/getvalues001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ObjectReference/InvokeMethod/invokemeth001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ObjectReference/InvokeMethod/invokemeth001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ObjectReference/IsCollected/iscollected001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ObjectReference/IsCollected/iscollected001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ObjectReference/MonitorInfo/monitorinfo001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ObjectReference/MonitorInfo/monitorinfo001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ObjectReference/ReferenceType/referencetype001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ObjectReference/ReferenceType/referencetype001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ObjectReference/ReferringObjects/referringObjects001/referringObjects001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ObjectReference/ReferringObjects/referringObjects002/referringObjects002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ObjectReference/SetValues/setvalues001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ObjectReference/SetValues/setvalues001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/ClassLoader/classloader001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/ClassLoader/classloader001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/ClassObject/classobj001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/ClassObject/classobj001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/Fields/fields001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/Fields/fields001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/FieldsWithGeneric/fldwithgeneric001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/FieldsWithGeneric/fldwithgeneric001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/GetValues/getvalues001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/GetValues/getvalues001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/Instances/instances001/instances001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/Instances/instances002/instances002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/Interfaces/interfaces001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/Interfaces/interfaces001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/Methods/methods001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/Methods/methods001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/MethodsWithGeneric/methwithgeneric001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/MethodsWithGeneric/methwithgeneric001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/Modifiers/modifiers001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/Modifiers/modifiers001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/NestedTypes/nestedtypes001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/NestedTypes/nestedtypes001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/Signature/signature001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/Signature/signature001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/SignatureWithGeneric/sigwithgeneric001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/SignatureWithGeneric/sigwithgeneric001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/SourceDebugExtension/srcdebugext001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/SourceDebugExtension/srcdebugext001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/SourceFile/srcfile001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/SourceFile/srcfile001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/Status/status001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/Status/status001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/StackFrame/GetValues/getvalues001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/StackFrame/GetValues/getvalues001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/StackFrame/PopFrames/popframes001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/StackFrame/PopFrames/popframes001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/StackFrame/SetValues/setvalues001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/StackFrame/SetValues/setvalues001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/StackFrame/ThisObject/thisobject001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/StackFrame/ThisObject/thisobject001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/StringReference/Value/value001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/StringReference/Value/value001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadGroupReference/Children/children001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadGroupReference/Children/children001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadGroupReference/Name/name001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadGroupReference/Name/name001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadGroupReference/Parent/parent001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadGroupReference/Parent/parent001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/CurrentContendedMonitor/curcontmonitor001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/CurrentContendedMonitor/curcontmonitor001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/ForceEarlyReturn/forceEarlyReturn001/forceEarlyReturn001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/ForceEarlyReturn/forceEarlyReturn002/forceEarlyReturn002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/FrameCount/framecnt001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/FrameCount/framecnt001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/Frames/frames001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/Frames/frames001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/Interrupt/interrupt001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/Interrupt/interrupt001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/Name/name001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/Name/name001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/OwnedMonitors/ownmonitors001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/OwnedMonitors/ownmonitors001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/OwnedMonitorsStackDepthInfo/ownedMonitorsStackDepthInfo001/ownedMonitorsStackDepthInfo001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/OwnedMonitorsStackDepthInfo/ownedMonitorsStackDepthInfo002/ownedMonitorsStackDepthInfo002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/Resume/resume001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/Resume/resume001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/Status/status001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/Status/status001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/Stop/stop001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/Stop/stop001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/Suspend/suspend001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/Suspend/suspend001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/SuspendCount/suspendcnt001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/SuspendCount/suspendcnt001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/ThreadGroup/threadgroup001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/ThreadReference/ThreadGroup/threadgroup001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/AllClasses/allclasses001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/AllClasses/allclasses001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/AllClassesWithGeneric/allclswithgeneric001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/AllClassesWithGeneric/allclswithgeneric001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/AllThreads/allthreads001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/AllThreads/allthreads001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/Capabilities/capabilities001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/Capabilities/capabilities001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/CapabilitiesNew/capabilitiesnew001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/CapabilitiesNew/capabilitiesnew001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/ClassPaths/classpaths001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/ClassPaths/classpaths001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/ClassesBySignature/classbysig001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/ClassesBySignature/classbysig001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/CreateString/createstr001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/CreateString/createstr001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/Dispose/dispose001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/Dispose/dispose001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/DisposeObjects/disposeobj001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/DisposeObjects/disposeobj001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/Exit/exit001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/Exit/exit001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/HoldEvents/holdevents001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/HoldEvents/holdevents001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/HoldEvents/holdevents002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/IDSizes/idsizes001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/IDSizes/idsizes001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/InstanceCounts/instanceCounts001/instanceCounts001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/RedefineClasses/redefinecls001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/RedefineClasses/redefinecls001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/ReleaseEvents/releaseevents001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/ReleaseEvents/releaseevents001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/ReleaseEvents/releaseevents002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/ReleaseEvents/releaseevents002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/Resume/resume001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/Resume/resume001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/SetDefaultStratum/setdefstrat001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/SetDefaultStratum/setdefstrat001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/TopLevelThreadGroups/threadgroups001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/TopLevelThreadGroups/threadgroups001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/Version/version001.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/Version/version001/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/Version/version002.java ! test/hotspot/jtreg/vmTestbase/nsk/jdwp/VirtualMachine/Version/version002/TestDescription.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeBinder.java Changeset: a7205cc6 Author: William Kemper Date: 2024-06-11 22:09:52 +0000 URL: https://git.openjdk.org/loom/commit/a7205cc6512796466fefe17d171082995e0966de 8333926: Shenandoah: Lower default immediate garbage threshold Reviewed-by: kdnilsen, ysr ! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp Changeset: 1c80ddb8 Author: Prasanta Sadhukhan Date: 2024-06-12 05:32:06 +0000 URL: https://git.openjdk.org/loom/commit/1c80ddb8efdb883623652b20849413b602c10c36 8333940: Ensure javax/swing/TestUngrab.java run on all platforms Reviewed-by: tr ! test/jdk/javax/swing/JMenu/TestUngrab.java Changeset: bd046d9b Author: Jaikiran Pai Date: 2024-06-12 05:36:30 +0000 URL: https://git.openjdk.org/loom/commit/bd046d9b9e79e4eea89c72af358961ef6e98e660 8222884: ConcurrentClassDescLookup.java times out intermittently Reviewed-by: rriggs, mbaesken ! test/jdk/java/io/Serializable/concurrentClassDescLookup/ConcurrentClassDescLookup.java Changeset: abbf45b5 Author: Matthias Baesken Date: 2024-06-12 06:18:31 +0000 URL: https://git.openjdk.org/loom/commit/abbf45b57edf2f5bf9a3f2fa408f35a43ebe9bb9 8332699: ubsan: jfrEventSetting.inline.hpp:31:43: runtime error: index 163 out of bounds for type 'jfrNativeEventSetting [162]' Reviewed-by: jbechberger, stuefe ! make/src/classes/build/tools/jfr/GenerateJfrFiles.java Changeset: a7e4ab93 Author: Matthias Baesken Date: 2024-06-12 07:06:29 +0000 URL: https://git.openjdk.org/loom/commit/a7e4ab9300730c32f6cf0dafd48f5e093f4ac0be 8333730: ubsan: FieldIndices/libFieldIndicesTest.cpp:276:11: runtime error: null pointer passed as argument 2, which is declared to never be null Reviewed-by: cjplummer, amenkov ! test/hotspot/jtreg/serviceability/jvmti/FollowReferences/FieldIndices/libFieldIndicesTest.cpp Changeset: a0318bc8 Author: Tobias Hartmann Date: 2024-06-12 09:18:53 +0000 URL: https://git.openjdk.org/loom/commit/a0318bc873f019b6d11571cfd4113ca8cc183b9c 8334077: Fix problem list entries for compiler tests Reviewed-by: chagedorn ! test/hotspot/jtreg/ProblemList.txt Changeset: c80e2eb3 Author: Per Minborg Date: 2024-06-12 09:35:48 +0000 URL: https://git.openjdk.org/loom/commit/c80e2eb35c4eb03f17a2a31e979e5c369453e203 8333886: Explicitly specify that asSlice and reinterpret return a memory segment backed by the same region of memory. Reviewed-by: jvernee, mcimadamore ! src/java.base/share/classes/java/lang/foreign/MemorySegment.java Changeset: bd750b6b Author: Doug Simon Date: 2024-06-12 10:03:39 +0000 URL: https://git.openjdk.org/loom/commit/bd750b6b783101a3b992a25e7bc64777bb08de18 8319933: Disable tests for JDK-8280481 on Graal Reviewed-by: chagedorn ! test/hotspot/jtreg/compiler/sharedstubs/SharedStubToInterpTest.java Changeset: 81ca0ece Author: Daniel Fuchs Date: 2024-06-12 10:53:08 +0000 URL: https://git.openjdk.org/loom/commit/81ca0ece2e69477b3d22a40c51e044d56e13b6e4 8334028: HttpClient: NPE thrown from assert statement Reviewed-by: jpai ! src/java.net.http/share/classes/jdk/internal/net/http/ResponseSubscribers.java ! src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java ! test/jdk/java/net/httpclient/BodySubscribersTest.java Changeset: 81083a0e Author: Daniel Fuchs Date: 2024-06-12 11:29:58 +0000 URL: https://git.openjdk.org/loom/commit/81083a0e10d9c92f5247ae256e170709014b596b 8299487: Test java/net/httpclient/whitebox/SSLTubeTestDriver.java timed out Reviewed-by: jpai ! test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/SSLTubeTest.java Changeset: 5a8a9fdf Author: Amit Kumar Date: 2024-06-12 13:24:58 +0000 URL: https://git.openjdk.org/loom/commit/5a8a9fdfa599e8939a5c6675883a92c869474979 8333382: [s390x] Enhance popcnt Instruction to use Z15 facilities Reviewed-by: lucy, aph ! src/hotspot/cpu/s390/assembler_s390.hpp ! src/hotspot/cpu/s390/assembler_s390.inline.hpp ! src/hotspot/cpu/s390/macroAssembler_s390.cpp ! src/hotspot/cpu/s390/macroAssembler_s390.hpp ! src/hotspot/cpu/s390/s390.ad + test/micro/org/openjdk/bench/vm/compiler/PopCount.java Changeset: 2c9185eb Author: Fei Gao Date: 2024-06-12 13:29:45 +0000 URL: https://git.openjdk.org/loom/commit/2c9185eb81c9dfcc30d160a6254089c474b56b0d 8321308: AArch64: Fix matching predication for cbz/cbnz Reviewed-by: fyang, adinn, aph ! src/hotspot/cpu/aarch64/aarch64.ad + test/hotspot/jtreg/compiler/c2/irTests/TestArrLenCheckOptimization.java ! test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java Changeset: ba67ad63 Author: Alexey Semenyuk Date: 2024-06-12 13:37:03 +0000 URL: https://git.openjdk.org/loom/commit/ba67ad63ae7d7d399e41ab258576123fb6d9502c 8319457: Update jpackage to support WiX v4 and v5 on Windows Reviewed-by: almatvee ! make/modules/jdk.jpackage/Java.gmk ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixAppImageFragmentBuilder.java ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixFragmentBuilder.java ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixPipeline.java + src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixSourceConverter.java ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixTool.java + src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixToolset.java ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixUiFragmentBuilder.java ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/InstallDirNotEmptyDlg.wxs ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_de.wxl ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_en.wxl ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_ja.wxl ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_zh_CN.wxl ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources.properties ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_de.properties ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_ja.properties ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_zh_CN.properties ! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/overrides.wxi + src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/wix3-to-wix4-conv.xsl ! test/jdk/tools/jpackage/helpers/jdk/jpackage/test/WindowsHelper.java ! test/jdk/tools/jpackage/windows/WinL10nTest.java Changeset: 2c1da6c6 Author: Axel Boldt-Christmas Date: 2024-06-12 14:06:53 +0000 URL: https://git.openjdk.org/loom/commit/2c1da6c6fa2e50856ea71c0e266961171bee1037 8332139: SymbolTableHash::Node allocations allocates twice the required memory Reviewed-by: iwalulya, coleenp ! src/hotspot/share/classfile/symbolTable.cpp ! src/hotspot/share/oops/symbol.hpp ! src/hotspot/share/utilities/concurrentHashTable.hpp ! src/hotspot/share/utilities/concurrentHashTable.inline.hpp Changeset: b697b48a Author: Alisen Chung Date: 2024-06-12 18:44:07 +0000 URL: https://git.openjdk.org/loom/commit/b697b48a0133458983caea4acc6de8de3e56d356 8315655: [macos] Right click and dragging over a component with a popup menu will open the popup Reviewed-by: dnguyen, psadhukhan ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CTrayIcon.java ! src/java.desktop/macosx/classes/sun/lwawt/macosx/NSEvent.java + test/jdk/javax/swing/JPopupMenu/MouseDragPopupTest.java Changeset: 74468bc1 Author: Ben Perez Committer: Sean Mullan Date: 2024-06-12 18:59:26 +0000 URL: https://git.openjdk.org/loom/commit/74468bc1f3aff7f53b91e342711dc095d97fdfed 8209092: Remove outdated wording from RC5ParameterSpec Reviewed-by: mullan ! src/java.base/share/classes/javax/crypto/spec/RC5ParameterSpec.java Changeset: fcedde80 Author: Inigo Mediavilla Saiz Committer: David Holmes Date: 2024-06-12 23:18:27 +0000 URL: https://git.openjdk.org/loom/commit/fcedde804277af5a26febdcfb7817858d72f01ab 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump Reviewed-by: dholmes, alanb ! src/hotspot/share/runtime/threads.cpp + test/hotspot/jtreg/serviceability/dcmd/thread/PrintMountedVirtualThread.java Changeset: 238162a3 Author: David Holmes Date: 2024-06-13 02:53:48 +0000 URL: https://git.openjdk.org/loom/commit/238162a3b8ce307659420661903a7f8ac1f06979 8322064: Remove expired flags in JDK 24 Reviewed-by: kvn, stuefe ! src/hotspot/share/runtime/arguments.cpp ! src/java.base/share/man/java.1 Changeset: 301bd708 Author: Abhishek Kumar Date: 2024-06-13 04:49:58 +0000 URL: https://git.openjdk.org/loom/commit/301bd7085654328f941c462bc786e995051d1a9c 8311110: multichar warning in WinAccessBridge.cpp Reviewed-by: djelinski, jwaters, prr ! src/jdk.accessibility/windows/native/libwindowsaccessbridge/WinAccessBridge.cpp From robaho at icloud.com Thu Jun 13 15:03:21 2024 From: robaho at icloud.com (Robert Engels) Date: Thu, 13 Jun 2024 10:03:21 -0500 Subject: ScopedValue.runWhere not returning scope In-Reply-To: References: <11CF3C9C-8300-43BA-8241-DBE0BF4AB5DA@icloud.com> Message-ID: Marcin, A few of things: 1. If you look at the javadoc at the top of CurrentTraceContext.java: "This makes a given span the current span by placing it in scope (usually but not always a thread local scope).? and then farther down in the Default class: "static thread local ensures we have one context per thread, as opposed to one per thread-tracer. This means all tracer instances will be able to see any tracer's contexts. The trade-off of this (instance-based reference) vs the reverse: trace contexts are not separated by tracer by default. For example, to make a trace invisible to another tracer, you have to use a non-default implementation." It is an implementation detail whether or not a ThreadLocal is used. So for Scoped tracers, it may be that the easiest implementation is ?private? traces. Whether or not a system is ok with private tracers is system dependent. 2. More importantly, If every thread execution VT or PT has a ScopedValue> Y available, it is trivial to replace ThreadLocal with Y.get().set(x), and Y.get().get(). Given the above it is straightforward to create a concrete implementation of CurrentTraceContext that uses a ScopedValue rather than ThreadLocal. The only other change to the framework would be to ensure that every Thread created sets up the scope variable X, in order to allow shared tracers using ScopedValues. Which goes back to my original point - if the system authors are re-architecting to use VirtualThreads effectively, they can make the minor changes required to the ?thread starting? required by their chosen tracing library. It is most likely a single line code change. 3. More importantly, if you use VT effectively, you are talking about orders of magnitude more ?trace contexts? (in the default brave handler they are shared by thread so they are highly limited since the only effective Java threading implementation prior to VT required pooled threads) which reinforces my point about the increase in the volume of unique data is the major problem for existing tracing libraries, which will probably require architectural changes anyway. 4. Lastly, as has been pointed out, TL are not going away, so the existing libraries will ?work? - except possibly fail given point 3. > On Jun 13, 2024, at 4:48 AM, Marcin Grzejszczak wrote: > > Robert, in that exact class that you're showing (the `ThreadLocalCurrentTraceContext` [1] ) you have the method > > @Override public Scope newScope(@Nullable TraceContext currentSpan) { > final TraceContext previous = local.get(); > local.set(currentSpan); > Scope result = previous != null ? new RevertToPreviousScope(local, previous) : revertToNull; > return decorateScope(currentSpan, result); > } > > That very class extends the CurrentTraceContext that requires to define how you create a new Scope. How will that work with Scoped Values? > > [1] - https://github.com/openzipkin/brave/blob/6.0.3/brave/src/main/java/brave/propagation/ThreadLocalCurrentTraceContext.java > > Pozdrawiam / Best regards, > Marcin Grzejszczak > > https://marcin.grzejszczak.pl > https://toomuchcoding.com > > ?r., 12 cze 2024 o 12:55 robert engels > napisa?(a): > Also, looking at brave, they seem to understand the various ways of managing the current context. See https://github.com/openzipkin/brave/tree/master/brave/src/main/java/brave/propagation > > and so plugging into this a context based on a ScopedValue seems trivial (see notes in TraceContextThreadLocal) > > I would expect other libraries have similar features. > >> On Jun 12, 2024, at 7:17?AM, robert engels > wrote: >> >> ? >> ? >> ? >> ? >> ? >> The code I provided will also work with before/after only tracers - the around is a simplification of this. >> >> Wrapping of the Runnable would happen the same way all instrumentation is done: manually, byte code manipulation, or dynamic proxies. >> >> The SV vs TL is only how the current context is obtained. It is trivial to change between the two. >> >> I think it would be helpful if you created a project that uses the aspects that demonstrates your perceived problem rather than the abstract solutions. This feels like an XY problem. >> >> Or do nothing, TLs are not going away. >> >> >> >> >>> On Jun 12, 2024, at 4:07?AM, Marcin Grzejszczak > wrote: >>> >>> ? >>> > I posted a minimalist ?tracing library? using ScopedValue here https://github.com/robaho/scope_trace >>> >>> Thanks for doing the example. >>> >>> >I think it is a fairly trivial change for tracing libraries to support ScopeValue instead of ThreadLocal if they wished to. >>> >>> As I presented by showing AFAIR 6 projects, not every single time the change would be trivial. Not all libraries give you the option to instrument the actual runnable (like an around aspect). Sometimes you have only before and after. Again, let me emphasise, I'm not saying that changing these libraries would not be possible. I'm saying that it wouldn't always be trivial and would require changes in various different projects. >>> >>> Pozdrawiam / Best regards, >>> Marcin Grzejszczak >>> >>> https://marcin.grzejszczak.pl >>> https://toomuchcoding.com >>> >>> wt., 11 cze 2024 o 15:25 Robert Engels > napisa?(a): >>> I posted a minimalist ?tracing library? using ScopedValue here https://github.com/robaho/scope_trace >>> >>> I think it is a fairly trivial change for tracing libraries to support ScopeValue instead of ThreadLocal if they wished to. >>> >>> >>>> On Jun 11, 2024, at 7:35 AM, Andrew Haley > wrote: >>>> >>>> On 6/11/24 11:32, Marcin Grzejszczak wrote: >>>> >>>> >> So why not produce an example of how it would be used? As far as I can >>>> >> see, your proposal fails to ensure the property in the case I posted/ >>>> > >>>> > I've created samples at the very beginning with the before and after >>>> > interceptor. I obviously know that I could rewrite the interceptor >>>> > to become an around one but my point is that it's not an ideal >>>> > solution to require instrumentors to rewrite everything. Also I >>>> > still see this whole discussion as having two ways of doing the same >>>> > thing. Current approach: >>>> > >>>> > ScopedValue.runWhere(scopedValue, someValue, () -> { >>>> > codeToRun(); >>>> > }); >>>> > >>>> > Proposed approach: >>>> > >>>> > try(Scope scope = ScopedValue.openScope(scopedValue, someValue)) { >>>> > codeToRun(); >>>> >>>> This API fails the test I provided: >>>> >>>> final ScopedValue aScopedValue = ...; >>>> final var x = aScopedValue.get(); >>>> ScopedValue.openScope(aScopedValue, someValue); >>>> final var y = aScopedValue.get(); >>>> >>>> assert(x == y); // Always succeeds >>>> >>>> In other words, scoped values would no longer be strictly scoped. >>>> That's what the "scoped" means in the name "scoped values". Strict >>>> scoping is a fundamental property. >>>> >>>> > } >>>> > >>>> > I understand that in the proposed approach one can mess things up, I >>>> > really do. But library instrumentors and tracing library creators >>>> > would benefit from that sort of API. >>>> >>>> If we were planning to deprecate thread-local variables I think this >>>> argument might have some merit. But we're not. They're not going away. >>>> >>>> > Also I've asked a different question... What if the users want to >>>> > leverage the ScopedValues to get the current span information (or >>>> > current principal from security point of view) but also they are >>>> > using TL based libraries? How would the interop look like? >>>> >>>> As the JEP says, scoped values do not replace all uses of thread-local >>>> variables. There are still some cases where thread-local variables >>>> will be used, and this looks like one of them. >>>> >>>> > Let's assume that they put into the current scope a span that they >>>> > want to have within that scope, we would need all the tracer >>>> > libraries (and security components and others that use the same >>>> > mechanism) to be ScopeValue aware. Would they first try to read SV >>>> > and then if that's not there a TL? >>>> >>>> Yes, I think so. >>>> >>>> > They would need to most likely read SV and populate TL if the SV >>>> > value is present so that other components that still rely on TL >>>> > would work. That would have to also work the other way round, if a >>>> > TL based library sets a value (e.g. span) then maybe the ScopedValue >>>> > should be created with a scope for that new value? >>>> >>>> I'm not sure how that'd work in general, but there's nothing to stop >>>> entry points for a library from doing so, and it might be a good idea. >>>> Something like: >>>> >>>> if (someThreadLocal.get() != NOTHING) { >>>> where(someScopedValue, someThreadLocal.get()).run(realEntry); >>>> } else { >>>> realEntry.run(); >>>> } >>>> >>>> -- >>>> Andrew Haley (he/him) >>>> Java Platform Lead Engineer >>>> Red Hat UK Ltd. > >>>> https://keybase.io/andrewhaley >>>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph-open at littlepinkcloud.com Thu Jun 13 19:23:22 2024 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Thu, 13 Jun 2024 20:23:22 +0100 Subject: ScopedValue.runWhere not returning scope In-Reply-To: References: <11CF3C9C-8300-43BA-8241-DBE0BF4AB5DA@icloud.com> Message-ID: <6558b613-b05a-42ad-9296-fb32bccdc863@littlepinkcloud.com> On 6/13/24 16:03, Robert Engels wrote: > 3. More importantly, if you use VT effectively, you are talking about > orders of magnitude more ?trace contexts? (in the default brave handler > they are shared by thread so they are highly limited since the only > effective Java threading implementation prior to VT required pooled > threads) which reinforces my point about the increase in the volume of > unique data is the major problem for existing tracing libraries, which > will probably require architectural changes anyway. Definitely, yes. If you need to create a context for every virtual thread, scoped values versus thread-local variables is the least of your problems. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From duke at openjdk.org Fri Jun 14 16:23:32 2024 From: duke at openjdk.org (duke) Date: Fri, 14 Jun 2024 16:23:32 GMT Subject: git: openjdk/loom: fibers: 4 new changesets Message-ID: Changeset: 801d29d3 Author: Alan Bateman Date: 2024-06-13 12:34:14 +0000 URL: https://git.openjdk.org/loom/commit/801d29d34374d3c081d15b04c8e1087f711ecbfa Disallow j.l.Object to be redefined due to native frame resume entry ! src/hotspot/share/prims/jvmtiRedefineClasses.cpp ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/TEST.quick-groups ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002/newclass02/java.base/java/lang/Object.java ! test/jdk/java/lang/instrument/TraceUsageAgent.java Changeset: 05d9389b Author: Alan Bateman Date: 2024-06-13 16:08:19 +0000 URL: https://git.openjdk.org/loom/commit/05d9389b98ba3e1736575a332abd395173c88fa5 Restore to main line ! test/hotspot/jtreg/serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java Changeset: 6c95d20f Author: Alan Bateman Date: 2024-06-14 12:03:34 +0000 URL: https://git.openjdk.org/loom/commit/6c95d20f26fb423cfbee2a3839458f1bfb2c6a4f Test improvements + cleanup ! test/jdk/java/lang/Thread/virtual/CarrierThreadInfo.java ! test/jdk/java/lang/Thread/virtual/CustomScheduler.java - test/jdk/java/lang/Thread/virtual/GetStackTrace.java - test/jdk/java/lang/Thread/virtual/GetStackTraceWhenRunnable.java ! test/jdk/java/lang/Thread/virtual/JfrEvents.java ! test/jdk/java/lang/Thread/virtual/MonitorEnterExit.java ! test/jdk/java/lang/Thread/virtual/MonitorWaitNotify.java ! test/jdk/java/lang/Thread/virtual/MonitorsTest.java ! test/jdk/java/lang/Thread/virtual/ParkWithFixedThreadPool.java ! test/jdk/java/lang/Thread/virtual/Reflection.java + test/jdk/java/lang/Thread/virtual/StackFrames.java - test/jdk/java/lang/Thread/virtual/StackTraces.java ! test/jdk/java/lang/Thread/virtual/SynchronizedNative.java ! test/jdk/java/lang/Thread/virtual/ThreadAPI.java - test/jdk/java/lang/Thread/virtual/ThreadBuilders.java ! test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALotWhenParking.java ! test/jdk/java/lang/management/ThreadMXBean/VirtualThreads.java + test/lib/jdk/test/lib/thread/CustomSchedulers.java Changeset: 3dd7c14c Author: Alan Bateman Date: 2024-06-14 17:19:39 +0000 URL: https://git.openjdk.org/loom/commit/3dd7c14c01c26199d846b98a33df38488d308e24 Configure failure handler to run jcmd Thread.vthread_scheduler ! test/failure_handler/src/share/conf/common.properties From marcin.grzejszczak at gmail.com Mon Jun 17 10:57:10 2024 From: marcin.grzejszczak at gmail.com (Marcin Grzejszczak) Date: Mon, 17 Jun 2024 10:57:10 +0000 Subject: ScopedValue.runWhere not returning scope In-Reply-To: References: <11CF3C9C-8300-43BA-8241-DBE0BF4AB5DA@icloud.com> Message-ID: > It is an implementation detail whether or not a ThreadLocal is used. So for Scoped tracers, it may be that the easiest implementation is ?private? traces. Whether or not a system is ok with private tracers is system dependent. True, but the API and its usage implies usage of Scopes. Usage of Scopes that get opened and closed seem to be incompatible with SV API. > 2. More importantly, If every thread execution VT or PT has a ScopedValue> Y available, it is trivial to replace ThreadLocal with Y.get().set(x), and Y.get().get(). All libraries that use scoping mechanisms will need to be adopted to support the around aspect syntax instead of the current one, plus all of its usages will need to be changed. I'm not saying this is terribly complicated but it's a lot of changes in a lot of places. BTW I think we're having 2 conversations here. I'm saying that this will be a burden to us, library creators and instrumentors and you're saying that changing this will be trivial and we should change our code anyways to be compatible with the new architecture. > 3. More importantly, if you use VT effectively, you are talking about orders of magnitude more ?trace contexts? (in the default brave handler they are shared by thread so they are highly limited since the only effective Java threading implementation prior to VT required pooled threads) which reinforces my point about the increase in the volume of unique data is the major problem for existing tracing libraries, which will probably require architectural changes anyway. Can you elaborate on this? In general I imagine that you will have a VT per e.g. a request. Through the lifecycle of that request you will have a new trace formed of many spans. There will be 1 current span active per VT which means that when asked for a SV current value that particular span will be returned. > 4. Lastly, as has been pointed out, TL are not going away, so the existing libraries will ?work? - except possibly fail given point 3. We might need to explicitly state that SV are not supported by tracing libraries. That means that when a user puts a scope in a scoped variable, unless we create some sort of a bridge between SV and TL, that value will not be honored. Also, unless some serious architecture change won't be done to tracer libraries users will not be able to fully benefit from performance improvements of VT + SV vs TL. I think I've presented that opinion in this thread multiple times. Pozdrawiam / Best regards, Marcin Grzejszczak https://marcin.grzejszczak.pl https://toomuchcoding.com czw., 13 cze 2024 o 15:03 Robert Engels napisa?(a): > Marcin, > > A few of things: > > 1. If you look at the javadoc at the top of CurrentTraceContext.java: > > *"This makes a given span the current span by placing it in scope (usually > but not always a thread local scope).?* > > and then farther down in the Default class: > > *"static thread local ensures we have one context per thread, as opposed > to one per thread-tracer. This means all tracer instances will be able to > see any tracer's contexts.* > > *The trade-off of this (instance-based reference) vs the reverse: trace > contexts are not separated by tracer by default. For example, to make a > trace invisible to another tracer, you have to use a non-default > implementation."* > > It is an implementation detail whether or not a ThreadLocal is used. So > for Scoped tracers, it may be that the easiest implementation is ?private? > traces. Whether or not a system is ok with private tracers is system > dependent. > > 2. More importantly, If every thread execution VT or PT has a > ScopedValue> Y available, it is trivial to replace > ThreadLocal with Y.get().set(x), and Y.get().get(). > > Given the above it is straightforward to create a concrete implementation > of CurrentTraceContext that uses a ScopedValue rather than ThreadLocal. The > only other change to the framework would be to ensure that every Thread > created sets up the scope variable X, in order to allow shared tracers > using ScopedValues. > > Which goes back to my original point - if the system authors are > re-architecting to use VirtualThreads effectively, they can make the minor > changes required to the ?thread starting? required by their chosen tracing > library. It is most likely a single line code change. > > 3. More importantly, if you use VT effectively, you are talking about > orders of magnitude more ?trace contexts? (in the default brave handler > they are shared by thread so they are highly limited since the only > effective Java threading implementation prior to VT required pooled > threads) which reinforces my point about the increase in the volume of > unique data is the major problem for existing tracing libraries, which will > probably require architectural changes anyway. > > 4. Lastly, as has been pointed out, TL are not going away, so the existing > libraries will ?work? - except possibly fail given point 3. > > > On Jun 13, 2024, at 4:48 AM, Marcin Grzejszczak < > marcin.grzejszczak at gmail.com> wrote: > > Robert, in that exact class that you're showing (the > `ThreadLocalCurrentTraceContext` [1] ) you have the method > > @Override public Scope newScope(@Nullable TraceContext currentSpan) { > final TraceContext previous = local.get(); > local.set(currentSpan); > Scope result = previous != null ? new RevertToPreviousScope(local, > previous) : revertToNull; > return decorateScope(currentSpan, result); > } > > That very class extends the CurrentTraceContext that requires to define > how you create a new Scope. How will that work with Scoped Values? > > [1] - > https://github.com/openzipkin/brave/blob/6.0.3/brave/src/main/java/brave/propagation/ThreadLocalCurrentTraceContext.java > > Pozdrawiam / Best regards, > Marcin Grzejszczak > > https://marcin.grzejszczak.pl > https://toomuchcoding.com > > > ?r., 12 cze 2024 o 12:55 robert engels napisa?(a): > >> Also, looking at brave, they seem to understand the various ways of >> managing the current context. See >> https://github.com/openzipkin/brave/tree/master/brave/src/main/java/brave/propagation >> >> and so plugging into this a context based on a ScopedValue seems trivial >> (see notes in TraceContextThreadLocal) >> >> I would expect other libraries have similar features. >> >> On Jun 12, 2024, at 7:17?AM, robert engels wrote: >> >> ? >> ? >> ? >> ? >> ? >> The code I provided will also work with before/after only tracers - the >> around is a simplification of this. >> >> Wrapping of the Runnable would happen the same way all instrumentation is >> done: manually, byte code manipulation, or dynamic proxies. >> >> The SV vs TL is only how the current context is obtained. It is trivial >> to change between the two. >> >> I think it would be helpful if you created a project that uses the >> aspects that demonstrates your perceived problem rather than the abstract >> solutions. This feels like an XY problem. >> >> Or do nothing, TLs are not going away. >> >> >> >> >> On Jun 12, 2024, at 4:07?AM, Marcin Grzejszczak < >> marcin.grzejszczak at gmail.com> wrote: >> >> ? >> > I posted a minimalist ?tracing library? using ScopedValue here >> https://github.com/robaho/scope_trace >> >> Thanks for doing the example. >> >> >I think it is a fairly trivial change for tracing libraries to support >> ScopeValue instead of ThreadLocal if they wished to. >> >> As I presented by showing AFAIR 6 projects, not every single time the >> change would be trivial. Not all libraries give you the option to >> instrument the actual runnable (like an around aspect). Sometimes you have >> only before and after. Again, let me emphasise, I'm not saying that >> changing these libraries would not be possible. I'm saying that it wouldn't >> always be trivial and would require changes in various different projects. >> >> Pozdrawiam / Best regards, >> Marcin Grzejszczak >> >> https://marcin.grzejszczak.pl >> https://toomuchcoding.com >> >> >> wt., 11 cze 2024 o 15:25 Robert Engels napisa?(a): >> >>> I posted a minimalist ?tracing library? using ScopedValue here >>> https://github.com/robaho/scope_trace >>> >>> I think it is a fairly trivial change for tracing libraries to support >>> ScopeValue instead of ThreadLocal if they wished to. >>> >>> >>> On Jun 11, 2024, at 7:35 AM, Andrew Haley >>> wrote: >>> >>> On 6/11/24 11:32, Marcin Grzejszczak wrote: >>> >>> >> So why not produce an example of how it would be used? As far as I can >>> >> see, your proposal fails to ensure the property in the case I posted/ >>> > >>> > I've created samples at the very beginning with the before and after >>> > interceptor. I obviously know that I could rewrite the interceptor >>> > to become an around one but my point is that it's not an ideal >>> > solution to require instrumentors to rewrite everything. Also I >>> > still see this whole discussion as having two ways of doing the same >>> > thing. Current approach: >>> > >>> > ScopedValue.runWhere(scopedValue, someValue, () -> { >>> > codeToRun(); >>> > }); >>> > >>> > Proposed approach: >>> > >>> > try(Scope scope = ScopedValue.openScope(scopedValue, someValue)) { >>> > codeToRun(); >>> >>> This API fails the test I provided: >>> >>> final ScopedValue aScopedValue = ...; >>> final var x = aScopedValue.get(); >>> ScopedValue.openScope(aScopedValue, someValue); >>> final var y = aScopedValue.get(); >>> >>> assert(x == y); // Always succeeds >>> >>> In other words, scoped values would no longer be strictly scoped. >>> That's what the "scoped" means in the name "scoped values". Strict >>> scoping is a fundamental property. >>> >>> > } >>> > >>> > I understand that in the proposed approach one can mess things up, I >>> > really do. But library instrumentors and tracing library creators >>> > would benefit from that sort of API. >>> >>> If we were planning to deprecate thread-local variables I think this >>> argument might have some merit. But we're not. They're not going away. >>> >>> > Also I've asked a different question... What if the users want to >>> > leverage the ScopedValues to get the current span information (or >>> > current principal from security point of view) but also they are >>> > using TL based libraries? How would the interop look like? >>> >>> As the JEP says, scoped values do not replace all uses of thread-local >>> variables. There are still some cases where thread-local variables >>> will be used, and this looks like one of them. >>> >>> > Let's assume that they put into the current scope a span that they >>> > want to have within that scope, we would need all the tracer >>> > libraries (and security components and others that use the same >>> > mechanism) to be ScopeValue aware. Would they first try to read SV >>> > and then if that's not there a TL? >>> >>> Yes, I think so. >>> >>> > They would need to most likely read SV and populate TL if the SV >>> > value is present so that other components that still rely on TL >>> > would work. That would have to also work the other way round, if a >>> > TL based library sets a value (e.g. span) then maybe the ScopedValue >>> > should be created with a scope for that new value? >>> >>> I'm not sure how that'd work in general, but there's nothing to stop >>> entry points for a library from doing so, and it might be a good idea. >>> Something like: >>> >>> if (someThreadLocal.get() != NOTHING) { >>> where(someScopedValue, someThreadLocal.get()).run(realEntry); >>> } else { >>> realEntry.run(); >>> } >>> >>> -- >>> Andrew Haley (he/him) >>> Java Platform Lead Engineer >>> Red Hat UK Ltd. >>> https://keybase.io/andrewhaley >>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 >>> >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcin.grzejszczak at gmail.com Mon Jun 17 10:57:34 2024 From: marcin.grzejszczak at gmail.com (Marcin Grzejszczak) Date: Mon, 17 Jun 2024 10:57:34 +0000 Subject: ScopedValue.runWhere not returning scope In-Reply-To: <6558b613-b05a-42ad-9296-fb32bccdc863@littlepinkcloud.com> References: <11CF3C9C-8300-43BA-8241-DBE0BF4AB5DA@icloud.com> <6558b613-b05a-42ad-9296-fb32bccdc863@littlepinkcloud.com> Message-ID: > Definitely, yes. If you need to create a context for every virtual thread, scoped values versus thread-local variables is the least of your problems. Can you elaborate please? Pozdrawiam / Best regards, Marcin Grzejszczak https://marcin.grzejszczak.pl https://toomuchcoding.com czw., 13 cze 2024 o 19:23 Andrew Haley napisa?(a): > On 6/13/24 16:03, Robert Engels wrote: > > 3. More importantly, if you use VT effectively, you are talking about > > orders of magnitude more ?trace contexts? (in the default brave handler > > they are shared by thread so they are highly limited since the only > > effective Java threading implementation prior to VT required pooled > > threads) which reinforces my point about the increase in the volume of > > unique data is the major problem for existing tracing libraries, which > > will probably require architectural changes anyway. > > Definitely, yes. If you need to create a context for every virtual thread, > scoped values versus thread-local variables is the least of your problems. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at icloud.com Mon Jun 17 12:01:08 2024 From: robaho at icloud.com (robert engels) Date: Mon, 17 Jun 2024 07:01:08 -0500 Subject: ScopedValue.runWhere not returning scope In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From robaho at icloud.com Mon Jun 17 14:14:08 2024 From: robaho at icloud.com (Robert Engels) Date: Mon, 17 Jun 2024 09:14:08 -0500 Subject: ScopedValue.runWhere not returning scope In-Reply-To: References: Message-ID: I updated the github.com/robaho/scope_trace code to demonstrate before/after tracing using ScopedValues. There are no ThreadLocals in the code. It works fine. The problem with open/close semantics is that it is easy to close the scopes out of order - which corrupts the tracing information. Again referring to brave, look at https://github.com/openzipkin/brave/blob/69003dfc811418f0dbc42e9e17ff880ebe1f4b02/instrumentation/mysql/src/main/java/brave/mysql/TracingStatementInterceptor.java#L39 This is an example of before/after tracing. It REQUIRES that the preStatement() and postStatment() will ALWAYS be executed in the correct sequence (with no intervening spans left open). Notice also Span span = ThreadLocalSpan.CURRENT_TRACER.next(); This code would need to changed regardless, most likely to something like Brave.currentTracer() which would be able to obtain the current tracer appropriately. I don?t see how adding open/close to ScopedValue values would alleviate this. I am guessing most libraries have these hard-coded dependencies on ThreadLocal. Thus, someone will write a VirtualThread/ScopedValue ?native? tracing library, and that will be what people use - or developers will need to modify their libraries to use ScopedValues in an APPROPRIATE manner. You seem to believe that a tracing library user will want to create a new span on every ScopedValue.runWhere() - I don?t think that is the case - as it will generate a lot of noise. ?scope values? are not only for tracing scopes. > On Jun 17, 2024, at 7:01 AM, robert engels wrote: > > Your statements like ?a user puts a scope in a SV won?t be honored?. Of course not. I think you are trying to conflate scoped values with tracing scopes. They are not the same thing and can?t be treated as such due to the volume. > > The user will manage scopes for tracing the way they do now. It is an implementation detail on how the tracing library manages these scopes. They currently use thread locals. As I?ve pointed out several times the library can use a scoped value to carry the scope context - and mange the active scopes within in > > You are trying to make the scoped values be able to support tracing directly. I don?t believe that was ever a design goal. > >> On Jun 17, 2024, at 5:59?AM, Marcin Grzejszczak wrote: >> >> ? >> > Definitely, yes. If you need to create a context for every virtual thread, scoped values versus thread-local variables is the least of your problems. >> >> Can you elaborate please? >> >> Pozdrawiam / Best regards, >> Marcin Grzejszczak >> >> https://marcin.grzejszczak.pl >> https://toomuchcoding.com >> >> czw., 13 cze 2024 o 19:23 Andrew Haley > napisa?(a): >> On 6/13/24 16:03, Robert Engels wrote: >> > 3. More importantly, if you use VT effectively, you are talking about >> > orders of magnitude more ?trace contexts? (in the default brave handler >> > they are shared by thread so they are highly limited since the only >> > effective Java threading implementation prior to VT required pooled >> > threads) which reinforces my point about the increase in the volume of >> > unique data is the major problem for existing tracing libraries, which >> > will probably require architectural changes anyway. >> >> Definitely, yes. If you need to create a context for every virtual thread, >> scoped values versus thread-local variables is the least of your problems. >> >> -- >> Andrew Haley (he/him) >> Java Platform Lead Engineer >> Red Hat UK Ltd. > >> https://keybase.io/andrewhaley >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcin.grzejszczak at gmail.com Mon Jun 17 14:43:11 2024 From: marcin.grzejszczak at gmail.com (Marcin Grzejszczak) Date: Mon, 17 Jun 2024 14:43:11 +0000 Subject: ScopedValue.runWhere not returning scope In-Reply-To: References: Message-ID: > I updated the github.com/robaho/scope_trace code to demonstrate before/after tracing using ScopedValues. There are no ThreadLocals in the code. It works fine. Thanks for doing this, I really appreciate it! You create a SV at the beginning when the "request" is received. Try to create a "span" with a new SV for the JDBC statement. With how JDBC is being instrumented you actually don't have a handle on when and how the JDBC code is called. You only have access to BEFORE and AFTER. So in the BEFORE you would create a new span, put it in scope so that e.g. MDC get enriched with tracing data so that you will have subsequent logs with span and trace ids and then in the afterStatement you would stop the scope, clear MDC and close that new span. I think that over the course of those 40 emails or so we're talking all the time about the same thing. You're trying to convince me that it's enough to create a SV at the beginning of code execution and wrap the actual execution in the runWhere which is not the case. When you do that you have in fact 1 span per request and then you just retrieve it in all your methods, there's no span nesting, no parent-child relationship. In a normal application you would have 1 span for getting the request, at least 1 span for the JDBC call and 1 for each of the http calls. In your case you have 1 span for all 4. > The problem with open/close semantics is that it is easy to close the scopes out of order - which corrupts the tracing information. Yes, I mentioned that a couple of times already. > Again referring to brave, look at https://github.com/openzipkin/brave/blob/69003dfc811418f0dbc42e9e17ff880ebe1f4b02/instrumentation/mysql/src/main/java/brave/mysql/TracingStatementInterceptor.java#L39 This line creates a new span, whose parent was the current one in ThreadLocal and it also puts the newly created span in ThreadLocal. That's because the ThreadLocalSpan is being used. You don't have to use that API, you could create a span and put it in scope, that way the information about the underlying ThreadLocal storage mechanism wouldn't leak. > This is an example of before/after tracing. It REQUIRES that the preStatement() and postStatment() will ALWAYS be executed in the correct sequence (with no intervening spans left open). Looking at the above what happens is that in pre, a new span is created and put in thread local. It is then closed in the post and removed from ThreadLocal. That's not what you're doing in beforeStatement and afterStatement in your example. > This code would need to changed regardless, most likely to something like Brave.currentTracer() which would be able to obtain the current tracer appropriately. I don?t see how adding open/close to ScopedValue values would alleviate this. Typically this information gets passed via a constructor. Most likely in this case some JDBC SPI is being called and that class is instantiated without any dependencies. > I am guessing most libraries have these hard-coded dependencies on ThreadLocal. They do not. They use abstractions with scopes. Micrometer Observation gets the current observation from an ObservationRegistry. Underneath the default implementation does look into TL but it could look into SV. > Thus, someone will write a VirtualThread/ScopedValue ?native? tracing library, and that will be what people use - or developers will need to modify their libraries to use ScopedValues in an APPROPRIATE manner. I'm trying to agree with you what APPROPRIATE means because I still don't understand because I think we're comparing apples to oranges at this point. > You seem to believe that a tracing library user will want to create a new span on every ScopedValue.runWhere() - I don?t think that is the case - as it will generate a lot of noise. I know a few things about tracing libraries and instrumenting projects because I've been doing it for a decade. I never said that you should create a span on every runWhere. Assuming that tracing libraries would be using SV then I can imagine that when a Span would be put in scope then if it's not there in scope already then runWhere should be run. Pozdrawiam / Best regards, Marcin Grzejszczak https://marcin.grzejszczak.pl https://toomuchcoding.com pon., 17 cze 2024 o 14:14 Robert Engels napisa?(a): > I updated the github.com/robaho/scope_trace code to demonstrate > before/after tracing using ScopedValues. There are no ThreadLocals in the > code. It works fine. > > The problem with open/close semantics is that it is easy to close the > scopes out of order - which corrupts the tracing information. > > Again referring to brave, look at > https://github.com/openzipkin/brave/blob/69003dfc811418f0dbc42e9e17ff880ebe1f4b02/instrumentation/mysql/src/main/java/brave/mysql/TracingStatementInterceptor.java#L39 > > This is an example of before/after tracing. It REQUIRES that the > preStatement() and postStatment() will ALWAYS be executed in the correct > sequence (with no intervening spans left open). > > Notice also > > Span span = ThreadLocalSpan.CURRENT_TRACER.next(); > > This code would need to changed regardless, most likely to something like > Brave.currentTracer() which would be able to obtain the current tracer > appropriately. *I don?t see how adding open/close to ScopedValue values > would alleviate this.* > > I am guessing most libraries have these hard-coded dependencies on > ThreadLocal. > > Thus, someone will write a VirtualThread/ScopedValue ?native? tracing > library, and that will be what people use - or developers will need to > modify their libraries to use ScopedValues in an APPROPRIATE manner. You > seem to believe that a tracing library user will want to create a new span > on every ScopedValue.runWhere() - I don?t think that is the case - as it > will generate a lot of noise. > > ?scope values? are not only for tracing scopes. > > > On Jun 17, 2024, at 7:01 AM, robert engels wrote: > > Your statements like ?a user puts a scope in a SV won?t be honored?. Of > course not. I think you are trying to conflate scoped values with tracing > scopes. They are not the same thing and can?t be treated as such due to the > volume. > > The user will manage scopes for tracing the way they do now. It is an > implementation detail on how the tracing library manages these scopes. They > currently use thread locals. As I?ve pointed out several times the library > can use a scoped value to carry the scope context - and mange the active > scopes within in > > You are trying to make the scoped values be able to support tracing > directly. I don?t believe that was ever a design goal. > > On Jun 17, 2024, at 5:59?AM, Marcin Grzejszczak < > marcin.grzejszczak at gmail.com> wrote: > > ? > > Definitely, yes. If you need to create a context for every virtual > thread, scoped values versus thread-local variables is the least of your > problems. > > Can you elaborate please? > > Pozdrawiam / Best regards, > Marcin Grzejszczak > > https://marcin.grzejszczak.pl > https://toomuchcoding.com > > > czw., 13 cze 2024 o 19:23 Andrew Haley > napisa?(a): > >> On 6/13/24 16:03, Robert Engels wrote: >> > 3. More importantly, if you use VT effectively, you are talking about >> > orders of magnitude more ?trace contexts? (in the default brave handler >> > they are shared by thread so they are highly limited since the only >> > effective Java threading implementation prior to VT required pooled >> > threads) which reinforces my point about the increase in the volume of >> > unique data is the major problem for existing tracing libraries, which >> > will probably require architectural changes anyway. >> >> Definitely, yes. If you need to create a context for every virtual thread, >> scoped values versus thread-local variables is the least of your problems. >> >> -- >> Andrew Haley (he/him) >> Java Platform Lead Engineer >> Red Hat UK Ltd. >> https://keybase.io/andrewhaley >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at icloud.com Mon Jun 17 15:14:41 2024 From: robaho at icloud.com (Robert Engels) Date: Mon, 17 Jun 2024 10:14:41 -0500 Subject: ScopedValue.runWhere not returning scope In-Reply-To: References: Message-ID: That is not correct. There is a ?trace context? per request at the top. The ?trace context? supports nested spans (which I call scopes). I have changed the name to Span to make this clearer, and I also added Span tag support. If the parentScopeId ==-1, then you are at the top-level (request). As an example: request 409, event Event[start=1718636994650, end=1718636994650, description=open span making jdbc call, spanId=3824, parentSpanId=-1], duration 0ms request 409, event Event[start=1718636994650, end=1718636994650, description=call jdbc, spanId=3824, parentSpanId=825], duration 0ms request 409, event Event[start=1718636994650, end=1718636994650, description=close span making jdbc call, spanId=3824, parentSpanId=825], duration 0ms request 409, event Event[start=1718636994494, end=1718636994650, description=close span handleRequest, spanId=825, parentSpanId=-1], duration 156ms request 148, event Event[start=1718636994487, end=1718636994598, description=close span handleRequest, spanId=299, parentSpanId=-1], duration 111ms request 409, total duration 166ms request 786, total duration 167ms request 75, event Event[start=1718636994485, end=1718636994655, description=close span handleRequest, spanId=149, parentSpanId=-1], duration 170ms request 148, total duration 119ms request 452, total duration 171ms request 75, total duration 177ms request 496, event Event[start=1718636994602, end=1718636994602, description=call jdbc, spanId=3367, parentSpanId=1000], duration 0ms request 496, event Event[start=1718636994602, end=1718636994602, description=close span making jdbc call, spanId=3367, parentSpanId=1000], duration 0ms request 496, event Event[start=1718636994495, end=1718636994602, description=close span handleRequest, spanId=1000, parentSpanId=-1], duration 107ms request 496, total duration 117ms request 635, event Event[start=1718636994497, end=1718636994658, description=close span handleRequest, spanId=1301, parentSpanId=-1], duration 161ms request 308, total duration 176ms request 576, event Event[start=1718636994658, end=1718636994658, description=close span making jdbc call, spanId=3901, parentSpanId=1163], duration 0ms request 635, total duration 171ms request 576, event Event[start=1718636994497, end=1718636994658, description=close span handleRequest, spanId=1163, parentSpanId=-1], duration 161ms request 267, event Event[start=1718636994658, end=1718636994658, description=call jdbc, spanId=3899, parentSpanId=538], duration 0ms > Looking at the above what happens is that in pre, a new span is created and put in thread local. It is then closed in the post and removed from ThreadLocal. That's not what you're doing in beforeStatement and afterStatement in your example. Right, because we don?t want to use thread locals!!!. The code I posted supports nested spans. If you are using a ThreadLocal.CURRENT_TRACER - you only have a single value per thread - so either the spans are chained, or there is a stack. I guarantee I can implement a full tracing library without using ThreadLocal and have it support nested spans, etc. How can I guarantee this? Because, you can implement tracing by passing ?context? as a parameter to every method. If you read the ScopedValue documentation it states that the purpose of ScopedValue is to avoid needing to pass these method parameters. So given that, you can replace callMethod(context,parm1?) with callMethod(parm1,?). A tracing library is trivially implemented with a Context parameter. There is absolutely no need to add open/close semantics to ScopedValue to support tracing libraries. > On Jun 17, 2024, at 9:43 AM, Marcin Grzejszczak wrote: > > > I updated the github.com/robaho/scope_trace code to demonstrate before/after tracing using ScopedValues. There are no ThreadLocals in the code. It works fine. > > Thanks for doing this, I really appreciate it! > > You create a SV at the beginning when the "request" is received. Try to create a "span" with a new SV for the JDBC statement. With how JDBC is being instrumented you actually don't have a handle on when and how the JDBC code is called. You only have access to BEFORE and AFTER. So in the BEFORE you would create a new span, put it in scope so that e.g. MDC get enriched with tracing data so that you will have subsequent logs with span and trace ids and then in the afterStatement you would stop the scope, clear MDC and close that new span. > > I think that over the course of those 40 emails or so we're talking all the time about the same thing. You're trying to convince me that it's enough to create a SV at the beginning of code execution and wrap the actual execution in the runWhere which is not the case. When you do that you have in fact 1 span per request and then you just retrieve it in all your methods, there's no span nesting, no parent-child relationship. > > In a normal application you would have 1 span for getting the request, at least 1 span for the JDBC call and 1 for each of the http calls. In your case you have 1 span for all 4. > > > The problem with open/close semantics is that it is easy to close the scopes out of order - which corrupts the tracing information. > > Yes, I mentioned that a couple of times already. > > > Again referring to brave, look at https://github.com/openzipkin/brave/blob/69003dfc811418f0dbc42e9e17ff880ebe1f4b02/instrumentation/mysql/src/main/java/brave/mysql/TracingStatementInterceptor.java#L39 > > This line creates a new span, whose parent was the current one in ThreadLocal and it also puts the newly created span in ThreadLocal. That's because the ThreadLocalSpan is being used. You don't have to use that API, you could create a span and put it in scope, that way the information about the underlying ThreadLocal storage mechanism wouldn't leak. > > > This is an example of before/after tracing. It REQUIRES that the preStatement() and postStatment() will ALWAYS be executed in the correct sequence (with no intervening spans left open). > > Looking at the above what happens is that in pre, a new span is created and put in thread local. It is then closed in the post and removed from ThreadLocal. That's not what you're doing in beforeStatement and afterStatement in your example. > > > This code would need to changed regardless, most likely to something like Brave.currentTracer() which would be able to obtain the current tracer appropriately. I don?t see how adding open/close to ScopedValue values would alleviate this. > > Typically this information gets passed via a constructor. Most likely in this case some JDBC SPI is being called and that class is instantiated without any dependencies. > > > I am guessing most libraries have these hard-coded dependencies on ThreadLocal. > > They do not. They use abstractions with scopes. Micrometer Observation gets the current observation from an ObservationRegistry. Underneath the default implementation does look into TL but it could look into SV. > > > Thus, someone will write a VirtualThread/ScopedValue ?native? tracing library, and that will be what people use - or developers will need to modify their libraries to use ScopedValues in an APPROPRIATE manner. > > I'm trying to agree with you what APPROPRIATE means because I still don't understand because I think we're comparing apples to oranges at this point. > > > You seem to believe that a tracing library user will want to create a new span on every ScopedValue.runWhere() - I don?t think that is the case - as it will generate a lot of noise. > > I know a few things about tracing libraries and instrumenting projects because I've been doing it for a decade. I never said that you should create a span on every runWhere. Assuming that tracing libraries would be using SV then I can imagine that when a Span would be put in scope then if it's not there in scope already then runWhere should be run. > > Pozdrawiam / Best regards, > Marcin Grzejszczak > > https://marcin.grzejszczak.pl > https://toomuchcoding.com > > pon., 17 cze 2024 o 14:14 Robert Engels > napisa?(a): > I updated the github.com/robaho/scope_trace code to demonstrate before/after tracing using ScopedValues. There are no ThreadLocals in the code. It works fine. > > The problem with open/close semantics is that it is easy to close the scopes out of order - which corrupts the tracing information. > > Again referring to brave, look at https://github.com/openzipkin/brave/blob/69003dfc811418f0dbc42e9e17ff880ebe1f4b02/instrumentation/mysql/src/main/java/brave/mysql/TracingStatementInterceptor.java#L39 > > This is an example of before/after tracing. It REQUIRES that the preStatement() and postStatment() will ALWAYS be executed in the correct sequence (with no intervening spans left open). > > Notice also > > Span span = ThreadLocalSpan.CURRENT_TRACER.next(); > > This code would need to changed regardless, most likely to something like Brave.currentTracer() which would be able to obtain the current tracer appropriately. I don?t see how adding open/close to ScopedValue values would alleviate this. > > I am guessing most libraries have these hard-coded dependencies on ThreadLocal. > > Thus, someone will write a VirtualThread/ScopedValue ?native? tracing library, and that will be what people use - or developers will need to modify their libraries to use ScopedValues in an APPROPRIATE manner. You seem to believe that a tracing library user will want to create a new span on every ScopedValue.runWhere() - I don?t think that is the case - as it will generate a lot of noise. > > ?scope values? are not only for tracing scopes. > > >> On Jun 17, 2024, at 7:01 AM, robert engels > wrote: >> >> Your statements like ?a user puts a scope in a SV won?t be honored?. Of course not. I think you are trying to conflate scoped values with tracing scopes. They are not the same thing and can?t be treated as such due to the volume. >> >> The user will manage scopes for tracing the way they do now. It is an implementation detail on how the tracing library manages these scopes. They currently use thread locals. As I?ve pointed out several times the library can use a scoped value to carry the scope context - and mange the active scopes within in >> >> You are trying to make the scoped values be able to support tracing directly. I don?t believe that was ever a design goal. >> >>> On Jun 17, 2024, at 5:59?AM, Marcin Grzejszczak > wrote: >>> >>> ? >>> > Definitely, yes. If you need to create a context for every virtual thread, scoped values versus thread-local variables is the least of your problems. >>> >>> Can you elaborate please? >>> >>> Pozdrawiam / Best regards, >>> Marcin Grzejszczak >>> >>> https://marcin.grzejszczak.pl >>> https://toomuchcoding.com >>> >>> czw., 13 cze 2024 o 19:23 Andrew Haley > napisa?(a): >>> On 6/13/24 16:03, Robert Engels wrote: >>> > 3. More importantly, if you use VT effectively, you are talking about >>> > orders of magnitude more ?trace contexts? (in the default brave handler >>> > they are shared by thread so they are highly limited since the only >>> > effective Java threading implementation prior to VT required pooled >>> > threads) which reinforces my point about the increase in the volume of >>> > unique data is the major problem for existing tracing libraries, which >>> > will probably require architectural changes anyway. >>> >>> Definitely, yes. If you need to create a context for every virtual thread, >>> scoped values versus thread-local variables is the least of your problems. >>> >>> -- >>> Andrew Haley (he/him) >>> Java Platform Lead Engineer >>> Red Hat UK Ltd. > >>> https://keybase.io/andrewhaley >>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcin.grzejszczak at gmail.com Mon Jun 17 15:19:10 2024 From: marcin.grzejszczak at gmail.com (Marcin Grzejszczak) Date: Mon, 17 Jun 2024 15:19:10 +0000 Subject: ScopedValue.runWhere not returning scope In-Reply-To: References: Message-ID: > Right, because we don?t want to use thread locals!!!. The code I posted supports nested spans. If you are using a ThreadLocal.CURRENT_TRACER - you only have a single value per thread - so either the spans are chained, or there is a stack. I never said that I want you to use thread locals!!! From the beginning I want to implement everything using Scoped Values but I don't want to need to rewrite all my code. Neither as a library implementor nor in the instrumented projects. > I guarantee I can implement a full tracing library without using ThreadLocal and have it support nested spans, etc. How can I guarantee this? Because, you can implement tracing by passing ?context? as a parameter to every method. If you read the ScopedValue documentation it states that the purpose of ScopedValue is to avoid needing to pass these method parameters. So given that, you can replace callMethod(context,parm1?) with callMethod(parm1,?). A tracing library is trivially implemented with a Context parameter. I fully believe you but I don't want to need to rewrite everything! > There is absolutely no need to add open/close semantics to ScopedValue to support tracing libraries. Maybe someone else can do better at explaining this, I give up. I understand that this CAN be done. I just doubt that forcing us to rewrite all of our code even in a trivial fashion is OK, but I understood the message. Pozdrawiam / Best regards, Marcin Grzejszczak https://marcin.grzejszczak.pl https://toomuchcoding.com pon., 17 cze 2024 o 15:14 Robert Engels napisa?(a): > That is not correct. There is a ?trace context? per request at the top. > The ?trace context? supports nested spans (which I call scopes). I have > changed the name to Span to make this clearer, and I also added Span tag > support. If the parentScopeId ==-1, then you are at the top-level > (request). As an example: > > request 409, event Event[start=1718636994650, end=1718636994650, > description=open span making jdbc call, spanId=3824, parentSpanId=-1], > duration 0ms > request 409, event Event[start=1718636994650, end=1718636994650, > description=call jdbc, spanId=3824, *parentSpanId=825*], duration 0ms > request 409, event Event[start=1718636994650, end=1718636994650, > description=close span making jdbc call, spanId=3824, *parentSpanId=825*], > duration 0ms > request 409, event Event[start=1718636994494, end=1718636994650, > description=close span handleRequest, spanId=825, parentSpanId=-1], > duration 156ms > request 148, event Event[start=1718636994487, end=1718636994598, > description=close span handleRequest, spanId=299, parentSpanId=-1], > duration 111ms > request 409, total duration 166ms > request 786, total duration 167ms > request 75, event Event[start=1718636994485, end=1718636994655, > description=close span handleRequest, spanId=149, parentSpanId=-1], > duration 170ms > request 148, total duration 119ms > request 452, total duration 171ms > request 75, total duration 177ms > request 496, event Event[start=1718636994602, end=1718636994602, > description=call jdbc, spanId=3367, parentSpanId=1000], duration 0ms > request 496, event Event[start=1718636994602, end=1718636994602, > description=close span making jdbc call, spanId=3367, parentSpanId=1000], > duration 0ms > *request 496*, event Event[start=1718636994495, end=1718636994602, > description=close span handleRequest, spanId=1000, *parentSpanId=-1*], > duration 107ms > request 496, total duration 117ms > request 635, event Event[start=1718636994497, end=1718636994658, > description=close span handleRequest, spanId=1301, parentSpanId=-1], > duration 161ms > request 308, total duration 176ms > request 576, event Event[start=1718636994658, end=1718636994658, > description=close span making jdbc call, spanId=3901, parentSpanId=1163], > duration 0ms > request 635, total duration 171ms > request 576, event Event[start=1718636994497, end=1718636994658, > description=close span handleRequest, spanId=1163, parentSpanId=-1], > duration 161ms > request 267, event Event[start=1718636994658, end=1718636994658, > description=call jdbc, spanId=3899, parentSpanId=538], duration 0ms > > > Looking at the above what happens is that in pre, a new span is created > and put in thread local. It is then closed in the post and removed from > ThreadLocal. That's not what you're doing in beforeStatement and > afterStatement in your example. > > > Right, because we don?t want to use thread locals!!!. The code I posted > supports nested spans. If you are using a ThreadLocal.CURRENT_TRACER - you > only have a single value per thread - so either the spans are chained, or > there is a stack. > > I guarantee I can implement a full tracing library without using > ThreadLocal and have it support nested spans, etc. How can I guarantee > this? Because, you can implement tracing by passing ?context? as a > parameter to every method. If you read the ScopedValue documentation it > states that the purpose of ScopedValue is to avoid needing to pass these > method parameters. So given that, you can replace > callMethod(context,parm1?) with callMethod(parm1,?). A tracing library is > trivially implemented with a Context parameter. > > There is absolutely no need to add open/close semantics to ScopedValue to > support tracing libraries. > > > On Jun 17, 2024, at 9:43 AM, Marcin Grzejszczak < > marcin.grzejszczak at gmail.com> wrote: > > > I updated the github.com/robaho/scope_trace code to demonstrate > before/after tracing using ScopedValues. There are no ThreadLocals in the > code. It works fine. > > Thanks for doing this, I really appreciate it! > > You create a SV at the beginning when the "request" is received. Try to > create a "span" with a new SV for the JDBC statement. With how JDBC is > being instrumented you actually don't have a handle on when and how the > JDBC code is called. You only have access to BEFORE and AFTER. So in the > BEFORE you would create a new span, put it in scope so that e.g. MDC get > enriched with tracing data so that you will have subsequent logs with span > and trace ids and then in the afterStatement you would stop the scope, > clear MDC and close that new span. > > I think that over the course of those 40 emails or so we're talking all > the time about the same thing. You're trying to convince me that it's > enough to create a SV at the beginning of code execution and wrap the > actual execution in the runWhere which is not the case. When you do that > you have in fact 1 span per request and then you just retrieve it in all > your methods, there's no span nesting, no parent-child relationship. > > In a normal application you would have 1 span for getting the request, at > least 1 span for the JDBC call and 1 for each of the http calls. In your > case you have 1 span for all 4. > > > The problem with open/close semantics is that it is easy to close the > scopes out of order - which corrupts the tracing information. > > Yes, I mentioned that a couple of times already. > > > Again referring to brave, look at > https://github.com/openzipkin/brave/blob/69003dfc811418f0dbc42e9e17ff880ebe1f4b02/instrumentation/mysql/src/main/java/brave/mysql/TracingStatementInterceptor.java#L39 > > This line creates a new span, whose parent was the current one in > ThreadLocal and it also puts the newly created span in ThreadLocal. That's > because the ThreadLocalSpan is being used. You don't have to use that API, > you could create a span and put it in scope, that way the information about > the underlying ThreadLocal storage mechanism wouldn't leak. > > > This is an example of before/after tracing. It REQUIRES that the > preStatement() and postStatment() will ALWAYS be executed in the correct > sequence (with no intervening spans left open). > > Looking at the above what happens is that in pre, a new span is created > and put in thread local. It is then closed in the post and removed from > ThreadLocal. That's not what you're doing in beforeStatement and > afterStatement in your example. > > > This code would need to changed regardless, most likely to something > like Brave.currentTracer() which would be able to obtain the current tracer > appropriately. I don?t see how adding open/close to ScopedValue values > would alleviate this. > > Typically this information gets passed via a constructor. Most likely in > this case some JDBC SPI is being called and that class is instantiated > without any dependencies. > > > I am guessing most libraries have these hard-coded dependencies on > ThreadLocal. > > They do not. They use abstractions with scopes. Micrometer Observation > gets the current observation from an ObservationRegistry. Underneath the > default implementation does look into TL but it could look into SV. > > > Thus, someone will write a VirtualThread/ScopedValue ?native? tracing > library, and that will be what people use - or developers will need to > modify their libraries to use ScopedValues in an APPROPRIATE manner. > > I'm trying to agree with you what APPROPRIATE means because I still don't > understand because I think we're comparing apples to oranges at this point. > > > You seem to believe that a tracing library user will want to create a > new span on every ScopedValue.runWhere() - I don?t think that is the case - > as it will generate a lot of noise. > > I know a few things about tracing libraries and instrumenting projects > because I've been doing it for a decade. I never said that you should > create a span on every runWhere. Assuming that tracing libraries would be > using SV then I can imagine that when a Span would be put in scope then if > it's not there in scope already then runWhere should be run. > > Pozdrawiam / Best regards, > Marcin Grzejszczak > > https://marcin.grzejszczak.pl > https://toomuchcoding.com > > > pon., 17 cze 2024 o 14:14 Robert Engels napisa?(a): > >> I updated the github.com/robaho/scope_trace code to demonstrate >> before/after tracing using ScopedValues. There are no ThreadLocals in the >> code. It works fine. >> >> The problem with open/close semantics is that it is easy to close the >> scopes out of order - which corrupts the tracing information. >> >> Again referring to brave, look at >> https://github.com/openzipkin/brave/blob/69003dfc811418f0dbc42e9e17ff880ebe1f4b02/instrumentation/mysql/src/main/java/brave/mysql/TracingStatementInterceptor.java#L39 >> >> This is an example of before/after tracing. It REQUIRES that the >> preStatement() and postStatment() will ALWAYS be executed in the correct >> sequence (with no intervening spans left open). >> >> Notice also >> >> Span span = ThreadLocalSpan.CURRENT_TRACER.next(); >> >> This code would need to changed regardless, most likely to something like >> Brave.currentTracer() which would be able to obtain the current tracer >> appropriately. *I don?t see how adding open/close to ScopedValue values >> would alleviate this.* >> >> I am guessing most libraries have these hard-coded dependencies on >> ThreadLocal. >> >> Thus, someone will write a VirtualThread/ScopedValue ?native? tracing >> library, and that will be what people use - or developers will need to >> modify their libraries to use ScopedValues in an APPROPRIATE manner. You >> seem to believe that a tracing library user will want to create a new span >> on every ScopedValue.runWhere() - I don?t think that is the case - as it >> will generate a lot of noise. >> >> ?scope values? are not only for tracing scopes. >> >> >> On Jun 17, 2024, at 7:01 AM, robert engels wrote: >> >> Your statements like ?a user puts a scope in a SV won?t be honored?. Of >> course not. I think you are trying to conflate scoped values with tracing >> scopes. They are not the same thing and can?t be treated as such due to the >> volume. >> >> The user will manage scopes for tracing the way they do now. It is an >> implementation detail on how the tracing library manages these scopes. They >> currently use thread locals. As I?ve pointed out several times the library >> can use a scoped value to carry the scope context - and mange the active >> scopes within in >> >> You are trying to make the scoped values be able to support tracing >> directly. I don?t believe that was ever a design goal. >> >> On Jun 17, 2024, at 5:59?AM, Marcin Grzejszczak < >> marcin.grzejszczak at gmail.com> wrote: >> >> ? >> > Definitely, yes. If you need to create a context for every virtual >> thread, scoped values versus thread-local variables is the least of your >> problems. >> >> Can you elaborate please? >> >> Pozdrawiam / Best regards, >> Marcin Grzejszczak >> >> https://marcin.grzejszczak.pl >> https://toomuchcoding.com >> >> >> czw., 13 cze 2024 o 19:23 Andrew Haley >> napisa?(a): >> >>> On 6/13/24 16:03, Robert Engels wrote: >>> > 3. More importantly, if you use VT effectively, you are talking about >>> > orders of magnitude more ?trace contexts? (in the default brave handler >>> > they are shared by thread so they are highly limited since the only >>> > effective Java threading implementation prior to VT required pooled >>> > threads) which reinforces my point about the increase in the volume of >>> > unique data is the major problem for existing tracing libraries, which >>> > will probably require architectural changes anyway. >>> >>> Definitely, yes. If you need to create a context for every virtual >>> thread, >>> scoped values versus thread-local variables is the least of your >>> problems. >>> >>> -- >>> Andrew Haley (he/him) >>> Java Platform Lead Engineer >>> Red Hat UK Ltd. >>> https://keybase.io/andrewhaley >>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at icloud.com Mon Jun 17 16:08:32 2024 From: robaho at icloud.com (Robert Engels) Date: Mon, 17 Jun 2024 11:08:32 -0500 Subject: ScopedValue.runWhere not returning scope In-Reply-To: References: Message-ID: <63FFA410-CC1A-43F7-99FB-97A17F730C5B@icloud.com> To be clear, I have no control whatsoever over what does or does not happen with Java. I am only stating my opinion - and trying to help! > From the beginning I want to implement everything using Scoped Values but I don't want to need to rewrite all my code. Neither as a library implementor nor in the instrumented projects. I do think it is strange that you want to take advantage of a new api, but you don?t want to do any work to do so??? This wouldn?t be an api change then, it would be a performance optimization behind the scenes. A primary purpose of the ScopedValue api addition is the automatic closing of the ScopeValue for better resource management in a VirtualThread system. Your requested changes eliminate a (the?) primary purpose of the api change! So, if you don?t want this, continue with ThreadLocal. Still, if the tracing library code is properly structured I would doubt it would be more than a global search and replace in the library to switch from ThreadLocal to ScopedValues. You keep stating ?rewrite all of our code? without providing any evidence of why that would be the case. It is highly doubtful any instrumented projects would need to change. I looked at how the tracing support is done with Spring and the proxies and that is certainly wouldn?t be required there. If you wanted no changes to instrumented projects whatsoever, you would need to use the ?check if ScopedValue context exists, if not use context from ThreadLocal? design as was suggested - which is meaningless overhead compared to the overhead of tracing itself. And if the instrumented project is being changed to use VirtualThreads it SHOULD be changed at the same time to update the tracing library setup code. I updated the my code to demonstrate the fallback to ThreadLocal when the top-level ScopedValue context is not available. I also updated the code to work when the ScopedValue setup is not performed. I am pretty sure it works the way most tracing libraries are interfaced with. I still think you are stuck and looking at the problem the wrong way. The code I shared emits all of the data to performed nested traces and analysis. event Event[start=1718639998618, end=1718639998807, description=close span handleRequest, span=SpanID 1985, tags [request 943],parent SpanId -1], duration 189ms event Event[start=1718639998709, end=1718639998709, description=open span callServer2, span=SpanID 6021, tags [],parent SpanId 1943], duration 0ms event Event[start=1718639998709, end=1718639998807, description=close span callServer2, span=SpanID 6021, tags [],parent SpanId 1943], duration 98ms event Event[start=1718639998807, end=1718639998807, description=open span making jdbc call, span=SpanID 7920, tags [jdbc],parent SpanId 1943], duration 0ms event Event[start=1718639998807, end=1718639998807, description=call jdbc, span=SpanID 7920, tags [jdbc],parent SpanId 1943], duration 0ms event Event[start=1718639998617, end=1718639998722, description=close span handleRequest, span=SpanID 1872, tags [request 885],parent SpanId -1], duration 105ms event Event[start=1718639998808, end=1718639998808, description=open span making jdbc call, span=SpanID 7921, tags [jdbc],parent SpanId 1715], duration 0ms event Event[start=1718639998808, end=1718639998808, description=call jdbc, span=SpanID 7921, tags [jdbc],parent SpanId 1715], duration 0ms event Event[start=1718639998808, end=1718639998808, description=close span making jdbc call, span=SpanID 7921, tags [jdbc],parent SpanId 1715], duration 0ms event Event[start=1718639998597, end=1718639998722, description=close span handleRequest, span=SpanID 71, tags [request 35],parent SpanId -1], duration 125ms > On Jun 17, 2024, at 10:19 AM, Marcin Grzejszczak wrote: > > > Right, because we don?t want to use thread locals!!!. The code I posted supports nested spans. If you are using a ThreadLocal.CURRENT_TRACER - you only have a single value per thread - so either the spans are chained, or there is a stack. > > I never said that I want you to use thread locals!!! From the beginning I want to implement everything using Scoped Values but I don't want to need to rewrite all my code. Neither as a library implementor nor in the instrumented projects. > > > I guarantee I can implement a full tracing library without using ThreadLocal and have it support nested spans, etc. How can I guarantee this? Because, you can implement tracing by passing ?context? as a parameter to every method. If you read the ScopedValue documentation it states that the purpose of ScopedValue is to avoid needing to pass these method parameters. So given that, you can replace callMethod(context,parm1?) with callMethod(parm1,?). A tracing library is trivially implemented with a Context parameter. > > I fully believe you but I don't want to need to rewrite everything! > > > There is absolutely no need to add open/close semantics to ScopedValue to support tracing libraries. > > Maybe someone else can do better at explaining this, I give up. I understand that this CAN be done. I just doubt that forcing us to rewrite all of our code even in a trivial fashion is OK, but I understood the message. > > Pozdrawiam / Best regards, > Marcin Grzejszczak > > https://marcin.grzejszczak.pl > https://toomuchcoding.com > > pon., 17 cze 2024 o 15:14 Robert Engels > napisa?(a): > That is not correct. There is a ?trace context? per request at the top. The ?trace context? supports nested spans (which I call scopes). I have changed the name to Span to make this clearer, and I also added Span tag support. If the parentScopeId ==-1, then you are at the top-level (request). As an example: > > request 409, event Event[start=1718636994650, end=1718636994650, description=open span making jdbc call, spanId=3824, parentSpanId=-1], duration 0ms > request 409, event Event[start=1718636994650, end=1718636994650, description=call jdbc, spanId=3824, parentSpanId=825], duration 0ms > request 409, event Event[start=1718636994650, end=1718636994650, description=close span making jdbc call, spanId=3824, parentSpanId=825], duration 0ms > request 409, event Event[start=1718636994494, end=1718636994650, description=close span handleRequest, spanId=825, parentSpanId=-1], duration 156ms > request 148, event Event[start=1718636994487, end=1718636994598, description=close span handleRequest, spanId=299, parentSpanId=-1], duration 111ms > request 409, total duration 166ms > request 786, total duration 167ms > request 75, event Event[start=1718636994485, end=1718636994655, description=close span handleRequest, spanId=149, parentSpanId=-1], duration 170ms > request 148, total duration 119ms > request 452, total duration 171ms > request 75, total duration 177ms > request 496, event Event[start=1718636994602, end=1718636994602, description=call jdbc, spanId=3367, parentSpanId=1000], duration 0ms > request 496, event Event[start=1718636994602, end=1718636994602, description=close span making jdbc call, spanId=3367, parentSpanId=1000], duration 0ms > request 496, event Event[start=1718636994495, end=1718636994602, description=close span handleRequest, spanId=1000, parentSpanId=-1], duration 107ms > request 496, total duration 117ms > request 635, event Event[start=1718636994497, end=1718636994658, description=close span handleRequest, spanId=1301, parentSpanId=-1], duration 161ms > request 308, total duration 176ms > request 576, event Event[start=1718636994658, end=1718636994658, description=close span making jdbc call, spanId=3901, parentSpanId=1163], duration 0ms > request 635, total duration 171ms > request 576, event Event[start=1718636994497, end=1718636994658, description=close span handleRequest, spanId=1163, parentSpanId=-1], duration 161ms > request 267, event Event[start=1718636994658, end=1718636994658, description=call jdbc, spanId=3899, parentSpanId=538], duration 0ms > > >> Looking at the above what happens is that in pre, a new span is created and put in thread local. It is then closed in the post and removed from ThreadLocal. That's not what you're doing in beforeStatement and afterStatement in your example. > > Right, because we don?t want to use thread locals!!!. The code I posted supports nested spans. If you are using a ThreadLocal.CURRENT_TRACER - you only have a single value per thread - so either the spans are chained, or there is a stack. > > I guarantee I can implement a full tracing library without using ThreadLocal and have it support nested spans, etc. How can I guarantee this? Because, you can implement tracing by passing ?context? as a parameter to every method. If you read the ScopedValue documentation it states that the purpose of ScopedValue is to avoid needing to pass these method parameters. So given that, you can replace callMethod(context,parm1?) with callMethod(parm1,?). A tracing library is trivially implemented with a Context parameter. > > There is absolutely no need to add open/close semantics to ScopedValue to support tracing libraries. > > >> On Jun 17, 2024, at 9:43 AM, Marcin Grzejszczak > wrote: >> >> > I updated the github.com/robaho/scope_trace code to demonstrate before/after tracing using ScopedValues. There are no ThreadLocals in the code. It works fine. >> >> Thanks for doing this, I really appreciate it! >> >> You create a SV at the beginning when the "request" is received. Try to create a "span" with a new SV for the JDBC statement. With how JDBC is being instrumented you actually don't have a handle on when and how the JDBC code is called. You only have access to BEFORE and AFTER. So in the BEFORE you would create a new span, put it in scope so that e.g. MDC get enriched with tracing data so that you will have subsequent logs with span and trace ids and then in the afterStatement you would stop the scope, clear MDC and close that new span. >> >> I think that over the course of those 40 emails or so we're talking all the time about the same thing. You're trying to convince me that it's enough to create a SV at the beginning of code execution and wrap the actual execution in the runWhere which is not the case. When you do that you have in fact 1 span per request and then you just retrieve it in all your methods, there's no span nesting, no parent-child relationship. >> >> In a normal application you would have 1 span for getting the request, at least 1 span for the JDBC call and 1 for each of the http calls. In your case you have 1 span for all 4. >> >> > The problem with open/close semantics is that it is easy to close the scopes out of order - which corrupts the tracing information. >> >> Yes, I mentioned that a couple of times already. >> >> > Again referring to brave, look at https://github.com/openzipkin/brave/blob/69003dfc811418f0dbc42e9e17ff880ebe1f4b02/instrumentation/mysql/src/main/java/brave/mysql/TracingStatementInterceptor.java#L39 >> >> This line creates a new span, whose parent was the current one in ThreadLocal and it also puts the newly created span in ThreadLocal. That's because the ThreadLocalSpan is being used. You don't have to use that API, you could create a span and put it in scope, that way the information about the underlying ThreadLocal storage mechanism wouldn't leak. >> >> > This is an example of before/after tracing. It REQUIRES that the preStatement() and postStatment() will ALWAYS be executed in the correct sequence (with no intervening spans left open). >> >> Looking at the above what happens is that in pre, a new span is created and put in thread local. It is then closed in the post and removed from ThreadLocal. That's not what you're doing in beforeStatement and afterStatement in your example. >> >> > This code would need to changed regardless, most likely to something like Brave.currentTracer() which would be able to obtain the current tracer appropriately. I don?t see how adding open/close to ScopedValue values would alleviate this. >> >> Typically this information gets passed via a constructor. Most likely in this case some JDBC SPI is being called and that class is instantiated without any dependencies. >> >> > I am guessing most libraries have these hard-coded dependencies on ThreadLocal. >> >> They do not. They use abstractions with scopes. Micrometer Observation gets the current observation from an ObservationRegistry. Underneath the default implementation does look into TL but it could look into SV. >> >> > Thus, someone will write a VirtualThread/ScopedValue ?native? tracing library, and that will be what people use - or developers will need to modify their libraries to use ScopedValues in an APPROPRIATE manner. >> >> I'm trying to agree with you what APPROPRIATE means because I still don't understand because I think we're comparing apples to oranges at this point. >> >> > You seem to believe that a tracing library user will want to create a new span on every ScopedValue.runWhere() - I don?t think that is the case - as it will generate a lot of noise. >> >> I know a few things about tracing libraries and instrumenting projects because I've been doing it for a decade. I never said that you should create a span on every runWhere. Assuming that tracing libraries would be using SV then I can imagine that when a Span would be put in scope then if it's not there in scope already then runWhere should be run. >> >> Pozdrawiam / Best regards, >> Marcin Grzejszczak >> >> https://marcin.grzejszczak.pl >> https://toomuchcoding.com >> >> pon., 17 cze 2024 o 14:14 Robert Engels > napisa?(a): >> I updated the github.com/robaho/scope_trace code to demonstrate before/after tracing using ScopedValues. There are no ThreadLocals in the code. It works fine. >> >> The problem with open/close semantics is that it is easy to close the scopes out of order - which corrupts the tracing information. >> >> Again referring to brave, look at https://github.com/openzipkin/brave/blob/69003dfc811418f0dbc42e9e17ff880ebe1f4b02/instrumentation/mysql/src/main/java/brave/mysql/TracingStatementInterceptor.java#L39 >> >> This is an example of before/after tracing. It REQUIRES that the preStatement() and postStatment() will ALWAYS be executed in the correct sequence (with no intervening spans left open). >> >> Notice also >> >> Span span = ThreadLocalSpan.CURRENT_TRACER.next(); >> >> This code would need to changed regardless, most likely to something like Brave.currentTracer() which would be able to obtain the current tracer appropriately. I don?t see how adding open/close to ScopedValue values would alleviate this. >> >> I am guessing most libraries have these hard-coded dependencies on ThreadLocal. >> >> Thus, someone will write a VirtualThread/ScopedValue ?native? tracing library, and that will be what people use - or developers will need to modify their libraries to use ScopedValues in an APPROPRIATE manner. You seem to believe that a tracing library user will want to create a new span on every ScopedValue.runWhere() - I don?t think that is the case - as it will generate a lot of noise. >> >> ?scope values? are not only for tracing scopes. >> >> >>> On Jun 17, 2024, at 7:01 AM, robert engels > wrote: >>> >>> Your statements like ?a user puts a scope in a SV won?t be honored?. Of course not. I think you are trying to conflate scoped values with tracing scopes. They are not the same thing and can?t be treated as such due to the volume. >>> >>> The user will manage scopes for tracing the way they do now. It is an implementation detail on how the tracing library manages these scopes. They currently use thread locals. As I?ve pointed out several times the library can use a scoped value to carry the scope context - and mange the active scopes within in >>> >>> You are trying to make the scoped values be able to support tracing directly. I don?t believe that was ever a design goal. >>> >>>> On Jun 17, 2024, at 5:59?AM, Marcin Grzejszczak > wrote: >>>> >>>> ? >>>> > Definitely, yes. If you need to create a context for every virtual thread, scoped values versus thread-local variables is the least of your problems. >>>> >>>> Can you elaborate please? >>>> >>>> Pozdrawiam / Best regards, >>>> Marcin Grzejszczak >>>> >>>> https://marcin.grzejszczak.pl >>>> https://toomuchcoding.com >>>> >>>> czw., 13 cze 2024 o 19:23 Andrew Haley > napisa?(a): >>>> On 6/13/24 16:03, Robert Engels wrote: >>>> > 3. More importantly, if you use VT effectively, you are talking about >>>> > orders of magnitude more ?trace contexts? (in the default brave handler >>>> > they are shared by thread so they are highly limited since the only >>>> > effective Java threading implementation prior to VT required pooled >>>> > threads) which reinforces my point about the increase in the volume of >>>> > unique data is the major problem for existing tracing libraries, which >>>> > will probably require architectural changes anyway. >>>> >>>> Definitely, yes. If you need to create a context for every virtual thread, >>>> scoped values versus thread-local variables is the least of your problems. >>>> >>>> -- >>>> Andrew Haley (he/him) >>>> Java Platform Lead Engineer >>>> Red Hat UK Ltd. > >>>> https://keybase.io/andrewhaley >>>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 >>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Mon Jun 17 19:30:15 2024 From: duke at openjdk.org (duke) Date: Mon, 17 Jun 2024 19:30:15 GMT Subject: git: openjdk/loom: fibers: 40 new changesets Message-ID: Changeset: 5d2a19de Author: Emanuel Peter Date: 2024-06-13 06:35:26 +0000 URL: https://git.openjdk.org/loom/commit/5d2a19def154b81c8ebada5594e080fe76c5ffee 8333684: C2 SuperWord: multiple smaller refactorings in preparation for JDK-8332163 Reviewed-by: chagedorn, kvn ! src/hotspot/share/opto/phasetype.hpp ! src/hotspot/share/opto/superword.cpp ! src/hotspot/share/opto/superword.hpp ! src/hotspot/share/opto/vectorization.hpp ! src/hotspot/share/opto/vectornode.cpp ! src/hotspot/share/opto/vectornode.hpp Changeset: 5528ad74 Author: Thomas Stuefe Date: 2024-06-13 08:38:04 +0000 URL: https://git.openjdk.org/loom/commit/5528ad74902fa4f4ec621d70e7e7d85f4ac1d780 8334179: VMATreeTest.TestConsistencyWithSimpleTracker_vm runs 50+ seconds Reviewed-by: jsjolen ! test/hotspot/gtest/nmt/test_vmatree.cpp Changeset: 57b64814 Author: Matthias Baesken Date: 2024-06-13 12:45:32 +0000 URL: https://git.openjdk.org/loom/commit/57b6481449612529615484a313d8b85ccf23e287 8333277: ubsan: mlib_ImageScanPoly.c:292:43: runtime error: division by zero Reviewed-by: prr ! src/java.desktop/share/native/libmlib_image/mlib_ImageScanPoly.c Changeset: f8c657f6 Author: Matthias Baesken Date: 2024-06-13 13:13:19 +0000 URL: https://git.openjdk.org/loom/commit/f8c657f6716c0de747be16814b55c3886bedf2d2 8334123: log the opening of Type 1 fonts Reviewed-by: prr ! src/java.desktop/share/classes/sun/font/Type1Font.java Changeset: f5213671 Author: Christoph Langer Date: 2024-06-13 13:14:54 +0000 URL: https://git.openjdk.org/loom/commit/f5213671f7b636b32bb93c78e43696a61cd69bae 8211847: [aix] java/lang/ProcessHandle/InfoTest.java fails: "reported cputime less than expected" Reviewed-by: stuefe ! test/jdk/ProblemList.txt Changeset: 9d8439c1 Author: Christoph Langer Date: 2024-06-13 13:16:38 +0000 URL: https://git.openjdk.org/loom/commit/9d8439c10780c3a0169c2675955a0506518f44fb 8211854: [aix] java/net/ServerSocket/AcceptInheritHandle.java fails: read times out Reviewed-by: dfuchs, jpai ! test/jdk/ProblemList.txt Changeset: 0d3a3771 Author: Matthias Baesken Date: 2024-06-13 14:02:01 +0000 URL: https://git.openjdk.org/loom/commit/0d3a3771c3777d3dd1fec8dc8faed5fd02b06830 8333887: ubsan: unsafe.cpp:247:13: runtime error: store to null pointer of type 'volatile int' Reviewed-by: lucy, mdoerr ! src/hotspot/share/prims/unsafe.cpp Changeset: 9ed8629e Author: Jayathirth D V Date: 2024-06-13 15:50:53 +0000 URL: https://git.openjdk.org/loom/commit/9ed8629e5d5e7b811c354cc1daf1ce5429eb184e 8333801: Typos in @code references of BufferedImage and JTableHeader Reviewed-by: abhiscxk, prr ! src/java.desktop/share/classes/java/awt/image/BufferedImage.java ! src/java.desktop/share/classes/javax/swing/table/JTableHeader.java ! test/jdk/javax/swing/JTabbedPane/4361477/bug4361477.java Changeset: 814cf879 Author: Larry Cable Committer: Kevin Walls Date: 2024-06-13 16:28:04 +0000 URL: https://git.openjdk.org/loom/commit/814cf8793097ef03a15068589c22a59ac5966430 8313562: hsperfdata should export module path and "launcher" metadata Reviewed-by: dholmes, kevinw ! src/hotspot/share/runtime/statSampler.cpp ! src/hotspot/share/runtime/statSampler.hpp Changeset: cff048c7 Author: Viktor Klang Date: 2024-06-13 16:30:27 +0000 URL: https://git.openjdk.org/loom/commit/cff048c7354dd947a3946d262f4752a55b7e2a43 8334162: Gatherer.defaultCombiner has an erronous @see-link Reviewed-by: jpai, alanb ! src/java.base/share/classes/java/util/stream/Gatherer.java Changeset: b09a4516 Author: Emanuel Peter Date: 2024-06-13 18:11:36 +0000 URL: https://git.openjdk.org/loom/commit/b09a45163ccc566b4f7653c2e9030e359396c90f 8333840: C2 SuperWord: wrong result for MulAddS2I when inputs permuted Reviewed-by: kvn, chagedorn ! src/hotspot/share/opto/superword.cpp ! src/hotspot/share/opto/superword.hpp ! test/hotspot/jtreg/compiler/loopopts/superword/TestMulAddS2I.java Changeset: 6462b873 Author: Sonia Zaldana Calles Committer: Thomas Stuefe Date: 2024-06-13 19:38:39 +0000 URL: https://git.openjdk.org/loom/commit/6462b873366ddc4ca2601ab4b6852522060c1395 8333685: Make update-copyright-year script more useful Reviewed-by: erikj, stuefe ! make/scripts/update_copyright_year.sh Changeset: 0721dbe4 Author: Marc R. Hoffmann Committer: Phil Race Date: 2024-06-13 19:44:10 +0000 URL: https://git.openjdk.org/loom/commit/0721dbe44234d0b3ec9733943230e83b2e479063 8334032: javax.print: Missing @since tag in new class OutputBin Reviewed-by: prr ! src/java.desktop/share/classes/javax/print/attribute/standard/OutputBin.java Changeset: bb7ef030 Author: Raffaello Giulietti Date: 2024-06-13 20:55:48 +0000 URL: https://git.openjdk.org/loom/commit/bb7ef03077fb91169b5505e3500093b848aece0f 8333599: Improve description of \b matcher in j.u.r.Pattern Reviewed-by: smarks, alanb ! src/java.base/share/classes/java/util/regex/Pattern.java Changeset: c4702ca8 Author: Damon Nguyen Date: 2024-06-13 21:27:56 +0000 URL: https://git.openjdk.org/loom/commit/c4702ca8c026e2d265aca0126fd3fb7bc5bb392a 8333827: JDK 23 RDP1 L10n resource files update Reviewed-by: achung, jlu, naoto, joehw, prappo, cjplummer, asemenyuk, prr ! src/java.base/share/classes/sun/launcher/resources/launcher_de.properties ! src/java.base/share/classes/sun/launcher/resources/launcher_ja.properties ! src/java.base/share/classes/sun/launcher/resources/launcher_zh_CN.properties ! src/java.desktop/share/classes/sun/print/resources/serviceui_zh_CN.properties ! 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/msg/XMLMessages_ja.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_CN.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_de.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties ! 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_de.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.compiler/share/classes/com/sun/tools/javac/resources/launcher_de.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher_ja.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher_zh_CN.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_de.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_ja.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_zh_CN.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_de.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_ja.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_zh_CN.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc_de.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc_ja.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc_zh_CN.properties ! src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_de.properties ! src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap_de.properties ! src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap_ja.properties ! src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap_zh_CN.properties ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java ! 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/windows/classes/jdk/jpackage/internal/resources/WinResources_de.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 Changeset: eb2488fd Author: Calvin Cheung Date: 2024-06-14 01:18:30 +0000 URL: https://git.openjdk.org/loom/commit/eb2488fd1781af49d936348d5f75731de2006ce7 8330198: Add some class loading related perf counters to measure VM startup Co-authored-by: Vladimir Ivanov Reviewed-by: iklam, dholmes ! src/hotspot/share/cds/dynamicArchive.cpp ! src/hotspot/share/classfile/classLoader.cpp ! src/hotspot/share/classfile/classLoader.hpp ! src/hotspot/share/interpreter/linkResolver.cpp ! src/hotspot/share/logging/logTag.hpp ! src/hotspot/share/oops/constantPool.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/java.cpp ! src/hotspot/share/runtime/perfData.cpp ! src/hotspot/share/runtime/perfData.hpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/threads.cpp Changeset: b818679e Author: Ioi Lam Date: 2024-06-14 06:06:24 +0000 URL: https://git.openjdk.org/loom/commit/b818679ebafff6adb2be4edbe21245882a751d2e 8293980: Resolve CONSTANT_FieldRef at CDS dump time Reviewed-by: erikj, matsaave, heidinga ! make/GenerateLinkOptData.gmk ! src/hotspot/share/cds/archiveBuilder.cpp ! src/hotspot/share/cds/archiveBuilder.hpp ! src/hotspot/share/cds/archiveUtils.cpp ! src/hotspot/share/cds/classListParser.cpp ! src/hotspot/share/cds/classListParser.hpp ! src/hotspot/share/cds/classListWriter.cpp ! src/hotspot/share/cds/classListWriter.hpp ! src/hotspot/share/cds/classPrelinker.cpp ! src/hotspot/share/cds/classPrelinker.hpp ! src/hotspot/share/cds/dumpAllocStats.cpp ! src/hotspot/share/cds/dumpAllocStats.hpp ! src/hotspot/share/cds/lambdaFormInvokers.hpp + src/hotspot/share/cds/lambdaFormInvokers.inline.hpp ! src/hotspot/share/interpreter/interpreterRuntime.cpp ! src/hotspot/share/interpreter/interpreterRuntime.hpp ! src/hotspot/share/interpreter/linkResolver.cpp ! src/hotspot/share/interpreter/linkResolver.hpp ! src/hotspot/share/oops/constantPool.cpp ! src/hotspot/share/oops/constantPool.hpp ! src/hotspot/share/oops/cpCache.cpp ! src/hotspot/share/oops/cpCache.hpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/resolvedFieldEntry.cpp ! src/hotspot/share/oops/resolvedFieldEntry.hpp ! src/hotspot/share/oops/resolvedIndyEntry.cpp ! src/hotspot/share/oops/resolvedIndyEntry.hpp ! src/hotspot/share/oops/resolvedMethodEntry.cpp ! src/hotspot/share/oops/resolvedMethodEntry.hpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/runtime/java.cpp ! test/hotspot/jtreg/TEST.groups + test/hotspot/jtreg/runtime/cds/appcds/resolvedConstants/ResolvedConstants.java + test/hotspot/jtreg/runtime/cds/appcds/resolvedConstants/ResolvedPutField.java + test/hotspot/jtreg/runtime/cds/appcds/resolvedConstants/ResolvedPutFieldHelper.jasm Changeset: 6861766b Author: Matthias Baesken Date: 2024-06-14 07:13:22 +0000 URL: https://git.openjdk.org/loom/commit/6861766b638c5135ba40f261d78d9731954ce5ab 8332818: ubsan: archiveHeapLoader.cpp:70:27: runtime error: applying non-zero offset 18446744073707454464 to null pointer Reviewed-by: stuefe, lucy ! src/hotspot/share/cds/archiveHeapLoader.cpp Changeset: 9b0a5c5c Author: Gui Cao Committer: Damon Fenacci Date: 2024-06-14 09:19:04 +0000 URL: https://git.openjdk.org/loom/commit/9b0a5c5cd056262fab99525e9260762b617152a3 8333248: VectorGatherMaskFoldingTest.java failed when maximum vector bits is 64 Reviewed-by: dfenacci, fyang ! test/hotspot/jtreg/compiler/vectorapi/VectorGatherMaskFoldingTest.java Changeset: cc64aeac Author: Robert Toyonaga Committer: Thomas Stuefe Date: 2024-06-14 09:32:52 +0000 URL: https://git.openjdk.org/loom/commit/cc64aeac47917f20a6d70e9796f0de9aa165ce62 8332400: isspace argument should be a valid unsigned char Reviewed-by: dholmes, amitkumar, stuefe, jwaters ! src/hotspot/os/linux/cgroupSubsystem_linux.cpp ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/services/diagnosticFramework.cpp ! src/java.base/share/native/libjli/args.c ! src/jdk.hotspot.agent/linux/native/libsaproc/ps_proc.c ! src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c ! src/jdk.jpackage/share/native/common/ErrorHandling.cpp Changeset: efab48c0 Author: Jaikiran Pai Date: 2024-06-14 12:48:43 +0000 URL: https://git.openjdk.org/loom/commit/efab48c06554476eae7a7bd946dee033d16a9c38 8333714: Cleanup the usages of CHECK_EXCEPTION_NULL_FAIL macro in java launcher Reviewed-by: alanb ! src/java.base/share/native/libjli/java.c Changeset: b5212d7b Author: Roland Westrelin Date: 2024-06-14 13:50:21 +0000 URL: https://git.openjdk.org/loom/commit/b5212d7bfe78b18c18e45c42c724a22365709328 8328107: Shenandoah/C2: TestVerifyLoopOptimizations test failure Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp + test/hotspot/jtreg/gc/shenandoah/compiler/TestBarrierOnLoopBackedge.java Changeset: dae0bda9 Author: Archie Cobbs Committer: Vicente Romero Date: 2024-06-14 14:53:05 +0000 URL: https://git.openjdk.org/loom/commit/dae0bda9d0096c25d6378561ab2d09df05f381cf 8334252: Verifier error for lambda declared in early construction context Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/langtools/tools/javac/SuperInit/LambdaOuterCapture.java Changeset: 548e95a6 Author: Leonid Mesnik Date: 2024-06-14 15:32:04 +0000 URL: https://git.openjdk.org/loom/commit/548e95a689d63e97ddbdfe7dd7df3a2e3377046c 8330702: Update failure handler to don't generate Error message if cores actions are empty Reviewed-by: sspitsyn ! test/failure_handler/src/share/classes/jdk/test/failurehandler/action/ActionSet.java ! test/failure_handler/src/share/conf/windows.properties Changeset: 8464ce6d Author: Leonid Mesnik Date: 2024-06-14 15:32:19 +0000 URL: https://git.openjdk.org/loom/commit/8464ce6db5cbd5d50ac2a2bcba905b7255f510f5 8332113: Update nsk.share.Log to be always verbose Reviewed-by: sspitsyn, cjplummer ! test/hotspot/jtreg/vmTestbase/nsk/share/Log.java Changeset: 31e8deba Author: Liming Liu Committer: Thomas Stuefe Date: 2024-06-17 06:16:26 +0000 URL: https://git.openjdk.org/loom/commit/31e8debae63e008da79e403bcb870a7be631af2c 8324781: runtime/Thread/TestAlwaysPreTouchStacks.java failed with Expected a higher ratio between stack committed and reserved 8325218: gc/parallel/TestAlwaysPreTouchBehavior.java fails Reviewed-by: stefank, jsjolen, stuefe ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/gc/parallel/TestAlwaysPreTouchBehavior.java ! test/hotspot/jtreg/runtime/Thread/TestAlwaysPreTouchStacks.java Changeset: 29b63928 Author: Emanuel Peter Date: 2024-06-17 06:58:55 +0000 URL: https://git.openjdk.org/loom/commit/29b63928387a8b6ab387057cb3eac4771b1bfff1 8334228: C2 SuperWord: fix JDK-24 regression in VPointer::cmp_for_sort after JDK-8325155 Reviewed-by: chagedorn, kvn ! src/hotspot/share/opto/vectorization.cpp + test/hotspot/jtreg/compiler/vectorization/TestOffsetSorting.java Changeset: 7b38bfea Author: Emanuel Peter Date: 2024-06-17 07:00:03 +0000 URL: https://git.openjdk.org/loom/commit/7b38bfea331437ad99277032de7fce939303abc8 8333729: C2 SuperWord: remove some @requires usages in test/hotspot/jtreg/compiler/loopopts/superword Reviewed-by: chagedorn, kvn ! test/hotspot/jtreg/compiler/loopopts/superword/CoLocatePackMemoryState.java ! test/hotspot/jtreg/compiler/loopopts/superword/RedTest_long.java ! test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java ! test/hotspot/jtreg/compiler/loopopts/superword/TestAlignVector.java ! test/hotspot/jtreg/compiler/loopopts/superword/TestAlignVectorFuzzer.java ! test/hotspot/jtreg/compiler/loopopts/superword/TestCyclicDependency.java ! test/hotspot/jtreg/compiler/loopopts/superword/TestDependencyOffsets.java ! test/hotspot/jtreg/compiler/loopopts/superword/TestGeneralizedReductions.java ! test/hotspot/jtreg/compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java ! test/hotspot/jtreg/compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency2.java ! test/hotspot/jtreg/compiler/loopopts/superword/TestLargeCompilation.java ! test/hotspot/jtreg/compiler/loopopts/superword/TestLargeScaleAndStride.java ! test/hotspot/jtreg/compiler/loopopts/superword/TestMovingLoadBeforeStore.java ! test/hotspot/jtreg/compiler/loopopts/superword/TestMulAddS2I.java ! test/hotspot/jtreg/compiler/loopopts/superword/TestPeeledReductionNode.java ! test/hotspot/jtreg/compiler/loopopts/superword/TestPickFirstMemoryState.java ! test/hotspot/jtreg/compiler/loopopts/superword/TestPickLastMemoryState.java ! test/hotspot/jtreg/compiler/loopopts/superword/TestScheduleReordersScalarMemops.java ! test/hotspot/jtreg/compiler/loopopts/superword/TestSplitPacks.java ! test/hotspot/jtreg/compiler/loopopts/superword/TestUnorderedReduction.java ! test/hotspot/jtreg/compiler/loopopts/superword/TestUnorderedReductionPartialVectorization.java ! test/hotspot/jtreg/compiler/loopopts/superword/Vec_MulAddS2I.java Changeset: 5e09397b Author: Matthias Baesken Date: 2024-06-17 08:06:20 +0000 URL: https://git.openjdk.org/loom/commit/5e09397bf6244c98204180f53a2891604d2843d1 8334222: exclude containers/cgroup/PlainRead.java Reviewed-by: lucy ! test/hotspot/jtreg/ProblemList.txt Changeset: d751441b Author: Aleksey Shipilev Date: 2024-06-17 08:23:39 +0000 URL: https://git.openjdk.org/loom/commit/d751441b76ef41880c77b48372c491f9558f1c68 8330586: GHA: Drop additional gcc/glibc packages installation for x86_32 Reviewed-by: ihse ! .github/workflows/main.yml Changeset: 113a2c02 Author: Matthias Baesken Date: 2024-06-17 08:57:57 +0000 URL: https://git.openjdk.org/loom/commit/113a2c028dc3b9abb6229d5f0b812b54a9b61011 8332903: ubsan: opto/output.cpp:1002:18: runtime error: load of value 171, which is not a valid value for type 'bool' Reviewed-by: kvn, mdoerr ! src/hotspot/cpu/ppc/ppc.ad Changeset: 0d1080d1 Author: Martin Doerr Date: 2024-06-17 09:30:48 +0000 URL: https://git.openjdk.org/loom/commit/0d1080d194c596dc74dd8b173b18b14cc71e1b52 8331117: [PPC64] secondary_super_cache does not scale well Reviewed-by: rrich, amitkumar ! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp ! src/hotspot/cpu/ppc/macroAssembler_ppc.hpp ! src/hotspot/cpu/ppc/ppc.ad ! src/hotspot/cpu/ppc/stubGenerator_ppc.cpp ! src/hotspot/cpu/ppc/vm_version_ppc.cpp ! src/hotspot/cpu/ppc/vm_version_ppc.hpp Changeset: ef7923e1 Author: Gui Cao Committer: Fei Yang Date: 2024-06-17 11:35:41 +0000 URL: https://git.openjdk.org/loom/commit/ef7923e1277ce86c6e5331871f1031c28bf82e31 8334078: RISC-V: TestIntVect.java fails after JDK-8332153 when running without RVV Reviewed-by: fyang, mli ! src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp ! test/hotspot/jtreg/compiler/c2/cr7200264/TestIntVect.java ! test/hotspot/jtreg/compiler/c2/irTests/TestVectorizeURShiftSubword.java ! test/hotspot/jtreg/compiler/intrinsics/TestBitShuffleOpers.java ! test/hotspot/jtreg/compiler/intrinsics/chacha/TestChaCha20.java ! test/hotspot/jtreg/compiler/lib/ir_framework/test/IREncodingPrinter.java ! test/hotspot/jtreg/compiler/vectorapi/reshape/TestVectorCastRVV.java ! test/hotspot/jtreg/compiler/vectorization/TestSignumVector.java ! test/hotspot/jtreg/compiler/vectorization/runner/ArrayShiftOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicByteOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicCharOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicIntOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicLongOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicShortOpTest.java Changeset: cdf22b13 Author: Markus Gr?nlund Date: 2024-06-17 12:57:09 +0000 URL: https://git.openjdk.org/loom/commit/cdf22b13204456b589349500bef0e9d48af44e83 8326715: ZGC: RunThese24H fails with ExitCode 139 during shutdown Reviewed-by: egahlin ! src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp ! src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.hpp ! src/hotspot/share/jfr/leakprofiler/sampling/objectSample.hpp ! src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.cpp ! src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointWriter.hpp + src/hotspot/share/jfr/recorder/storage/jfrReferenceCountedStorage.cpp + src/hotspot/share/jfr/recorder/storage/jfrReferenceCountedStorage.hpp ! src/hotspot/share/jfr/support/jfrDeprecationEventWriter.cpp ! src/hotspot/share/jfr/support/jfrDeprecationEventWriter.hpp ! src/hotspot/share/jfr/support/jfrDeprecationManager.cpp ! src/hotspot/share/jfr/support/jfrDeprecationManager.hpp Changeset: c94af6f9 Author: Albert Mingkun Yang Date: 2024-06-17 15:50:55 +0000 URL: https://git.openjdk.org/loom/commit/c94af6f943c179553d1827550847b93491d47506 8333962: Obsolete OldSize Reviewed-by: dholmes, zgu ! src/hotspot/share/gc/serial/tenuredGeneration.cpp ! src/hotspot/share/gc/shared/gc_globals.hpp ! src/hotspot/share/gc/shared/genArguments.cpp ! src/hotspot/share/gc/shared/genArguments.hpp ! src/hotspot/share/runtime/arguments.cpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! test/hotspot/gtest/gc/shared/test_collectorPolicy.cpp ! test/hotspot/jtreg/gc/arguments/TestMaxHeapSizeTools.java ! test/hotspot/jtreg/gc/arguments/TestMaxNewSize.java ! test/hotspot/jtreg/gc/g1/TestInvalidateArrayCopy.java ! test/hotspot/jtreg/gc/g1/plab/lib/PLABUtils.java ! test/hotspot/jtreg/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java ! test/hotspot/jtreg/vmTestbase/gc/huge/quicklook/largeheap/MemOptions/MemOptionsTest.java ! test/jdk/jdk/jfr/event/runtime/TestSizeTFlags.java ! test/jdk/sun/tools/jhsdb/heapconfig/JMapHeapConfigTest.java Changeset: 801bf15f Author: Thomas Stuefe Date: 2024-06-17 17:27:01 +0000 URL: https://git.openjdk.org/loom/commit/801bf15f02ca47c3547eb677079d7d2f3af1de8c 8332105: Exploded JDK does not include CDS Reviewed-by: dholmes, iklam ! src/hotspot/share/prims/whitebox.cpp ! test/hotspot/jtreg/runtime/CompressedOops/CompressedCPUSpecificClassSpaceReservation.java Changeset: db913f5e Author: Alan Bateman Date: 2024-06-17 18:40:12 +0000 URL: https://git.openjdk.org/loom/commit/db913f5e6e87d857bb0691be252142a3efb235e5 Merge ! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp ! src/hotspot/share/interpreter/interpreterRuntime.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/threads.cpp ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/TEST.groups ! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp ! src/hotspot/share/interpreter/interpreterRuntime.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/threads.cpp ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/TEST.groups Changeset: 81c22e38 Author: Alan Bateman Date: 2024-06-15 09:27:57 +0000 URL: https://git.openjdk.org/loom/commit/81c22e3871941bcdf01bf17703a2d9ba69504ebb Rename test lib class ! test/jdk/java/lang/Thread/virtual/CarrierThreadInfo.java ! test/jdk/java/lang/Thread/virtual/CustomScheduler.java ! test/jdk/java/lang/Thread/virtual/JfrEvents.java ! test/jdk/java/lang/Thread/virtual/MonitorEnterExit.java ! test/jdk/java/lang/Thread/virtual/MonitorWaitNotify.java ! test/jdk/java/lang/Thread/virtual/MonitorsTest.java ! test/jdk/java/lang/Thread/virtual/ParkWithFixedThreadPool.java ! test/jdk/java/lang/Thread/virtual/Reflection.java ! test/jdk/java/lang/Thread/virtual/StackFrames.java ! test/jdk/java/lang/Thread/virtual/SynchronizedNative.java ! test/jdk/java/lang/Thread/virtual/ThreadAPI.java ! test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALotWhenParking.java ! test/jdk/java/lang/management/ThreadMXBean/VirtualThreads.java = test/lib/jdk/test/lib/thread/VThreadScheduler.java Changeset: 5df1f042 Author: Alan Bateman Date: 2024-06-17 18:37:49 +0000 URL: https://git.openjdk.org/loom/commit/5df1f04235381e02afc99476d1a3c59815793e92 Temporary property to configure scheduler, not for main line ! src/java.base/share/classes/java/lang/VirtualThread.java Changeset: 676d72a8 Author: Alan Bateman Date: 2024-06-17 19:31:22 +0000 URL: https://git.openjdk.org/loom/commit/676d72a8ad0fd16434433714fee8691ac6f0eda9 Merge From duke at openjdk.org Mon Jun 17 19:32:15 2024 From: duke at openjdk.org (duke) Date: Mon, 17 Jun 2024 19:32:15 GMT Subject: git: openjdk/loom: master: 36 new changesets Message-ID: <2b1f99dd-b48a-45f7-b078-4a14c14c86f2@openjdk.org> Changeset: 5d2a19de Author: Emanuel Peter Date: 2024-06-13 06:35:26 +0000 URL: https://git.openjdk.org/loom/commit/5d2a19def154b81c8ebada5594e080fe76c5ffee 8333684: C2 SuperWord: multiple smaller refactorings in preparation for JDK-8332163 Reviewed-by: chagedorn, kvn ! src/hotspot/share/opto/phasetype.hpp ! src/hotspot/share/opto/superword.cpp ! src/hotspot/share/opto/superword.hpp ! src/hotspot/share/opto/vectorization.hpp ! src/hotspot/share/opto/vectornode.cpp ! src/hotspot/share/opto/vectornode.hpp Changeset: 5528ad74 Author: Thomas Stuefe Date: 2024-06-13 08:38:04 +0000 URL: https://git.openjdk.org/loom/commit/5528ad74902fa4f4ec621d70e7e7d85f4ac1d780 8334179: VMATreeTest.TestConsistencyWithSimpleTracker_vm runs 50+ seconds Reviewed-by: jsjolen ! test/hotspot/gtest/nmt/test_vmatree.cpp Changeset: 57b64814 Author: Matthias Baesken Date: 2024-06-13 12:45:32 +0000 URL: https://git.openjdk.org/loom/commit/57b6481449612529615484a313d8b85ccf23e287 8333277: ubsan: mlib_ImageScanPoly.c:292:43: runtime error: division by zero Reviewed-by: prr ! src/java.desktop/share/native/libmlib_image/mlib_ImageScanPoly.c Changeset: f8c657f6 Author: Matthias Baesken Date: 2024-06-13 13:13:19 +0000 URL: https://git.openjdk.org/loom/commit/f8c657f6716c0de747be16814b55c3886bedf2d2 8334123: log the opening of Type 1 fonts Reviewed-by: prr ! src/java.desktop/share/classes/sun/font/Type1Font.java Changeset: f5213671 Author: Christoph Langer Date: 2024-06-13 13:14:54 +0000 URL: https://git.openjdk.org/loom/commit/f5213671f7b636b32bb93c78e43696a61cd69bae 8211847: [aix] java/lang/ProcessHandle/InfoTest.java fails: "reported cputime less than expected" Reviewed-by: stuefe ! test/jdk/ProblemList.txt Changeset: 9d8439c1 Author: Christoph Langer Date: 2024-06-13 13:16:38 +0000 URL: https://git.openjdk.org/loom/commit/9d8439c10780c3a0169c2675955a0506518f44fb 8211854: [aix] java/net/ServerSocket/AcceptInheritHandle.java fails: read times out Reviewed-by: dfuchs, jpai ! test/jdk/ProblemList.txt Changeset: 0d3a3771 Author: Matthias Baesken Date: 2024-06-13 14:02:01 +0000 URL: https://git.openjdk.org/loom/commit/0d3a3771c3777d3dd1fec8dc8faed5fd02b06830 8333887: ubsan: unsafe.cpp:247:13: runtime error: store to null pointer of type 'volatile int' Reviewed-by: lucy, mdoerr ! src/hotspot/share/prims/unsafe.cpp Changeset: 9ed8629e Author: Jayathirth D V Date: 2024-06-13 15:50:53 +0000 URL: https://git.openjdk.org/loom/commit/9ed8629e5d5e7b811c354cc1daf1ce5429eb184e 8333801: Typos in @code references of BufferedImage and JTableHeader Reviewed-by: abhiscxk, prr ! src/java.desktop/share/classes/java/awt/image/BufferedImage.java ! src/java.desktop/share/classes/javax/swing/table/JTableHeader.java ! test/jdk/javax/swing/JTabbedPane/4361477/bug4361477.java Changeset: 814cf879 Author: Larry Cable Committer: Kevin Walls Date: 2024-06-13 16:28:04 +0000 URL: https://git.openjdk.org/loom/commit/814cf8793097ef03a15068589c22a59ac5966430 8313562: hsperfdata should export module path and "launcher" metadata Reviewed-by: dholmes, kevinw ! src/hotspot/share/runtime/statSampler.cpp ! src/hotspot/share/runtime/statSampler.hpp Changeset: cff048c7 Author: Viktor Klang Date: 2024-06-13 16:30:27 +0000 URL: https://git.openjdk.org/loom/commit/cff048c7354dd947a3946d262f4752a55b7e2a43 8334162: Gatherer.defaultCombiner has an erronous @see-link Reviewed-by: jpai, alanb ! src/java.base/share/classes/java/util/stream/Gatherer.java Changeset: b09a4516 Author: Emanuel Peter Date: 2024-06-13 18:11:36 +0000 URL: https://git.openjdk.org/loom/commit/b09a45163ccc566b4f7653c2e9030e359396c90f 8333840: C2 SuperWord: wrong result for MulAddS2I when inputs permuted Reviewed-by: kvn, chagedorn ! src/hotspot/share/opto/superword.cpp ! src/hotspot/share/opto/superword.hpp ! test/hotspot/jtreg/compiler/loopopts/superword/TestMulAddS2I.java Changeset: 6462b873 Author: Sonia Zaldana Calles Committer: Thomas Stuefe Date: 2024-06-13 19:38:39 +0000 URL: https://git.openjdk.org/loom/commit/6462b873366ddc4ca2601ab4b6852522060c1395 8333685: Make update-copyright-year script more useful Reviewed-by: erikj, stuefe ! make/scripts/update_copyright_year.sh Changeset: 0721dbe4 Author: Marc R. Hoffmann Committer: Phil Race Date: 2024-06-13 19:44:10 +0000 URL: https://git.openjdk.org/loom/commit/0721dbe44234d0b3ec9733943230e83b2e479063 8334032: javax.print: Missing @since tag in new class OutputBin Reviewed-by: prr ! src/java.desktop/share/classes/javax/print/attribute/standard/OutputBin.java Changeset: bb7ef030 Author: Raffaello Giulietti Date: 2024-06-13 20:55:48 +0000 URL: https://git.openjdk.org/loom/commit/bb7ef03077fb91169b5505e3500093b848aece0f 8333599: Improve description of \b matcher in j.u.r.Pattern Reviewed-by: smarks, alanb ! src/java.base/share/classes/java/util/regex/Pattern.java Changeset: c4702ca8 Author: Damon Nguyen Date: 2024-06-13 21:27:56 +0000 URL: https://git.openjdk.org/loom/commit/c4702ca8c026e2d265aca0126fd3fb7bc5bb392a 8333827: JDK 23 RDP1 L10n resource files update Reviewed-by: achung, jlu, naoto, joehw, prappo, cjplummer, asemenyuk, prr ! src/java.base/share/classes/sun/launcher/resources/launcher_de.properties ! src/java.base/share/classes/sun/launcher/resources/launcher_ja.properties ! src/java.base/share/classes/sun/launcher/resources/launcher_zh_CN.properties ! src/java.desktop/share/classes/sun/print/resources/serviceui_zh_CN.properties ! 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/msg/XMLMessages_ja.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_CN.properties ! src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_de.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_de.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties ! 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_de.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.compiler/share/classes/com/sun/tools/javac/resources/launcher_de.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher_ja.properties ! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher_zh_CN.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_de.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_ja.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_zh_CN.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_de.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_ja.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_zh_CN.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc_de.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc_ja.properties ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/resources/javadoc_zh_CN.properties ! src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_de.properties ! src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap_de.properties ! src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap_ja.properties ! src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap_zh_CN.properties ! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java ! 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/windows/classes/jdk/jpackage/internal/resources/WinResources_de.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 Changeset: eb2488fd Author: Calvin Cheung Date: 2024-06-14 01:18:30 +0000 URL: https://git.openjdk.org/loom/commit/eb2488fd1781af49d936348d5f75731de2006ce7 8330198: Add some class loading related perf counters to measure VM startup Co-authored-by: Vladimir Ivanov Reviewed-by: iklam, dholmes ! src/hotspot/share/cds/dynamicArchive.cpp ! src/hotspot/share/classfile/classLoader.cpp ! src/hotspot/share/classfile/classLoader.hpp ! src/hotspot/share/interpreter/linkResolver.cpp ! src/hotspot/share/logging/logTag.hpp ! src/hotspot/share/oops/constantPool.cpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/method.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/java.cpp ! src/hotspot/share/runtime/perfData.cpp ! src/hotspot/share/runtime/perfData.hpp ! src/hotspot/share/runtime/sharedRuntime.cpp ! src/hotspot/share/runtime/threads.cpp Changeset: b818679e Author: Ioi Lam Date: 2024-06-14 06:06:24 +0000 URL: https://git.openjdk.org/loom/commit/b818679ebafff6adb2be4edbe21245882a751d2e 8293980: Resolve CONSTANT_FieldRef at CDS dump time Reviewed-by: erikj, matsaave, heidinga ! make/GenerateLinkOptData.gmk ! src/hotspot/share/cds/archiveBuilder.cpp ! src/hotspot/share/cds/archiveBuilder.hpp ! src/hotspot/share/cds/archiveUtils.cpp ! src/hotspot/share/cds/classListParser.cpp ! src/hotspot/share/cds/classListParser.hpp ! src/hotspot/share/cds/classListWriter.cpp ! src/hotspot/share/cds/classListWriter.hpp ! src/hotspot/share/cds/classPrelinker.cpp ! src/hotspot/share/cds/classPrelinker.hpp ! src/hotspot/share/cds/dumpAllocStats.cpp ! src/hotspot/share/cds/dumpAllocStats.hpp ! src/hotspot/share/cds/lambdaFormInvokers.hpp + src/hotspot/share/cds/lambdaFormInvokers.inline.hpp ! src/hotspot/share/interpreter/interpreterRuntime.cpp ! src/hotspot/share/interpreter/interpreterRuntime.hpp ! src/hotspot/share/interpreter/linkResolver.cpp ! src/hotspot/share/interpreter/linkResolver.hpp ! src/hotspot/share/oops/constantPool.cpp ! src/hotspot/share/oops/constantPool.hpp ! src/hotspot/share/oops/cpCache.cpp ! src/hotspot/share/oops/cpCache.hpp ! src/hotspot/share/oops/instanceKlass.cpp ! src/hotspot/share/oops/resolvedFieldEntry.cpp ! src/hotspot/share/oops/resolvedFieldEntry.hpp ! src/hotspot/share/oops/resolvedIndyEntry.cpp ! src/hotspot/share/oops/resolvedIndyEntry.hpp ! src/hotspot/share/oops/resolvedMethodEntry.cpp ! src/hotspot/share/oops/resolvedMethodEntry.hpp ! src/hotspot/share/prims/jvm.cpp ! src/hotspot/share/runtime/java.cpp ! test/hotspot/jtreg/TEST.groups + test/hotspot/jtreg/runtime/cds/appcds/resolvedConstants/ResolvedConstants.java + test/hotspot/jtreg/runtime/cds/appcds/resolvedConstants/ResolvedPutField.java + test/hotspot/jtreg/runtime/cds/appcds/resolvedConstants/ResolvedPutFieldHelper.jasm Changeset: 6861766b Author: Matthias Baesken Date: 2024-06-14 07:13:22 +0000 URL: https://git.openjdk.org/loom/commit/6861766b638c5135ba40f261d78d9731954ce5ab 8332818: ubsan: archiveHeapLoader.cpp:70:27: runtime error: applying non-zero offset 18446744073707454464 to null pointer Reviewed-by: stuefe, lucy ! src/hotspot/share/cds/archiveHeapLoader.cpp Changeset: 9b0a5c5c Author: Gui Cao Committer: Damon Fenacci Date: 2024-06-14 09:19:04 +0000 URL: https://git.openjdk.org/loom/commit/9b0a5c5cd056262fab99525e9260762b617152a3 8333248: VectorGatherMaskFoldingTest.java failed when maximum vector bits is 64 Reviewed-by: dfenacci, fyang ! test/hotspot/jtreg/compiler/vectorapi/VectorGatherMaskFoldingTest.java Changeset: cc64aeac Author: Robert Toyonaga Committer: Thomas Stuefe Date: 2024-06-14 09:32:52 +0000 URL: https://git.openjdk.org/loom/commit/cc64aeac47917f20a6d70e9796f0de9aa165ce62 8332400: isspace argument should be a valid unsigned char Reviewed-by: dholmes, amitkumar, stuefe, jwaters ! src/hotspot/os/linux/cgroupSubsystem_linux.cpp ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/services/diagnosticFramework.cpp ! src/java.base/share/native/libjli/args.c ! src/jdk.hotspot.agent/linux/native/libsaproc/ps_proc.c ! src/jdk.jdwp.agent/unix/native/libjdwp/exec_md.c ! src/jdk.jpackage/share/native/common/ErrorHandling.cpp Changeset: efab48c0 Author: Jaikiran Pai Date: 2024-06-14 12:48:43 +0000 URL: https://git.openjdk.org/loom/commit/efab48c06554476eae7a7bd946dee033d16a9c38 8333714: Cleanup the usages of CHECK_EXCEPTION_NULL_FAIL macro in java launcher Reviewed-by: alanb ! src/java.base/share/native/libjli/java.c Changeset: b5212d7b Author: Roland Westrelin Date: 2024-06-14 13:50:21 +0000 URL: https://git.openjdk.org/loom/commit/b5212d7bfe78b18c18e45c42c724a22365709328 8328107: Shenandoah/C2: TestVerifyLoopOptimizations test failure Reviewed-by: shade ! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp + test/hotspot/jtreg/gc/shenandoah/compiler/TestBarrierOnLoopBackedge.java Changeset: dae0bda9 Author: Archie Cobbs Committer: Vicente Romero Date: 2024-06-14 14:53:05 +0000 URL: https://git.openjdk.org/loom/commit/dae0bda9d0096c25d6378561ab2d09df05f381cf 8334252: Verifier error for lambda declared in early construction context Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/langtools/tools/javac/SuperInit/LambdaOuterCapture.java Changeset: 548e95a6 Author: Leonid Mesnik Date: 2024-06-14 15:32:04 +0000 URL: https://git.openjdk.org/loom/commit/548e95a689d63e97ddbdfe7dd7df3a2e3377046c 8330702: Update failure handler to don't generate Error message if cores actions are empty Reviewed-by: sspitsyn ! test/failure_handler/src/share/classes/jdk/test/failurehandler/action/ActionSet.java ! test/failure_handler/src/share/conf/windows.properties Changeset: 8464ce6d Author: Leonid Mesnik Date: 2024-06-14 15:32:19 +0000 URL: https://git.openjdk.org/loom/commit/8464ce6db5cbd5d50ac2a2bcba905b7255f510f5 8332113: Update nsk.share.Log to be always verbose Reviewed-by: sspitsyn, cjplummer ! test/hotspot/jtreg/vmTestbase/nsk/share/Log.java Changeset: 31e8deba Author: Liming Liu Committer: Thomas Stuefe Date: 2024-06-17 06:16:26 +0000 URL: https://git.openjdk.org/loom/commit/31e8debae63e008da79e403bcb870a7be631af2c 8324781: runtime/Thread/TestAlwaysPreTouchStacks.java failed with Expected a higher ratio between stack committed and reserved 8325218: gc/parallel/TestAlwaysPreTouchBehavior.java fails Reviewed-by: stefank, jsjolen, stuefe ! test/hotspot/jtreg/ProblemList.txt ! test/hotspot/jtreg/gc/parallel/TestAlwaysPreTouchBehavior.java ! test/hotspot/jtreg/runtime/Thread/TestAlwaysPreTouchStacks.java Changeset: 29b63928 Author: Emanuel Peter Date: 2024-06-17 06:58:55 +0000 URL: https://git.openjdk.org/loom/commit/29b63928387a8b6ab387057cb3eac4771b1bfff1 8334228: C2 SuperWord: fix JDK-24 regression in VPointer::cmp_for_sort after JDK-8325155 Reviewed-by: chagedorn, kvn ! src/hotspot/share/opto/vectorization.cpp + test/hotspot/jtreg/compiler/vectorization/TestOffsetSorting.java Changeset: 7b38bfea Author: Emanuel Peter Date: 2024-06-17 07:00:03 +0000 URL: https://git.openjdk.org/loom/commit/7b38bfea331437ad99277032de7fce939303abc8 8333729: C2 SuperWord: remove some @requires usages in test/hotspot/jtreg/compiler/loopopts/superword Reviewed-by: chagedorn, kvn ! test/hotspot/jtreg/compiler/loopopts/superword/CoLocatePackMemoryState.java ! test/hotspot/jtreg/compiler/loopopts/superword/RedTest_long.java ! test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java ! test/hotspot/jtreg/compiler/loopopts/superword/TestAlignVector.java ! test/hotspot/jtreg/compiler/loopopts/superword/TestAlignVectorFuzzer.java ! test/hotspot/jtreg/compiler/loopopts/superword/TestCyclicDependency.java ! test/hotspot/jtreg/compiler/loopopts/superword/TestDependencyOffsets.java ! test/hotspot/jtreg/compiler/loopopts/superword/TestGeneralizedReductions.java ! test/hotspot/jtreg/compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java ! test/hotspot/jtreg/compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency2.java ! test/hotspot/jtreg/compiler/loopopts/superword/TestLargeCompilation.java ! test/hotspot/jtreg/compiler/loopopts/superword/TestLargeScaleAndStride.java ! test/hotspot/jtreg/compiler/loopopts/superword/TestMovingLoadBeforeStore.java ! test/hotspot/jtreg/compiler/loopopts/superword/TestMulAddS2I.java ! test/hotspot/jtreg/compiler/loopopts/superword/TestPeeledReductionNode.java ! test/hotspot/jtreg/compiler/loopopts/superword/TestPickFirstMemoryState.java ! test/hotspot/jtreg/compiler/loopopts/superword/TestPickLastMemoryState.java ! test/hotspot/jtreg/compiler/loopopts/superword/TestScheduleReordersScalarMemops.java ! test/hotspot/jtreg/compiler/loopopts/superword/TestSplitPacks.java ! test/hotspot/jtreg/compiler/loopopts/superword/TestUnorderedReduction.java ! test/hotspot/jtreg/compiler/loopopts/superword/TestUnorderedReductionPartialVectorization.java ! test/hotspot/jtreg/compiler/loopopts/superword/Vec_MulAddS2I.java Changeset: 5e09397b Author: Matthias Baesken Date: 2024-06-17 08:06:20 +0000 URL: https://git.openjdk.org/loom/commit/5e09397bf6244c98204180f53a2891604d2843d1 8334222: exclude containers/cgroup/PlainRead.java Reviewed-by: lucy ! test/hotspot/jtreg/ProblemList.txt Changeset: d751441b Author: Aleksey Shipilev Date: 2024-06-17 08:23:39 +0000 URL: https://git.openjdk.org/loom/commit/d751441b76ef41880c77b48372c491f9558f1c68 8330586: GHA: Drop additional gcc/glibc packages installation for x86_32 Reviewed-by: ihse ! .github/workflows/main.yml Changeset: 113a2c02 Author: Matthias Baesken Date: 2024-06-17 08:57:57 +0000 URL: https://git.openjdk.org/loom/commit/113a2c028dc3b9abb6229d5f0b812b54a9b61011 8332903: ubsan: opto/output.cpp:1002:18: runtime error: load of value 171, which is not a valid value for type 'bool' Reviewed-by: kvn, mdoerr ! src/hotspot/cpu/ppc/ppc.ad Changeset: 0d1080d1 Author: Martin Doerr Date: 2024-06-17 09:30:48 +0000 URL: https://git.openjdk.org/loom/commit/0d1080d194c596dc74dd8b173b18b14cc71e1b52 8331117: [PPC64] secondary_super_cache does not scale well Reviewed-by: rrich, amitkumar ! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp ! src/hotspot/cpu/ppc/macroAssembler_ppc.hpp ! src/hotspot/cpu/ppc/ppc.ad ! src/hotspot/cpu/ppc/stubGenerator_ppc.cpp ! src/hotspot/cpu/ppc/vm_version_ppc.cpp ! src/hotspot/cpu/ppc/vm_version_ppc.hpp Changeset: ef7923e1 Author: Gui Cao Committer: Fei Yang Date: 2024-06-17 11:35:41 +0000 URL: https://git.openjdk.org/loom/commit/ef7923e1277ce86c6e5331871f1031c28bf82e31 8334078: RISC-V: TestIntVect.java fails after JDK-8332153 when running without RVV Reviewed-by: fyang, mli ! src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp ! test/hotspot/jtreg/compiler/c2/cr7200264/TestIntVect.java ! test/hotspot/jtreg/compiler/c2/irTests/TestVectorizeURShiftSubword.java ! test/hotspot/jtreg/compiler/intrinsics/TestBitShuffleOpers.java ! test/hotspot/jtreg/compiler/intrinsics/chacha/TestChaCha20.java ! test/hotspot/jtreg/compiler/lib/ir_framework/test/IREncodingPrinter.java ! test/hotspot/jtreg/compiler/vectorapi/reshape/TestVectorCastRVV.java ! test/hotspot/jtreg/compiler/vectorization/TestSignumVector.java ! test/hotspot/jtreg/compiler/vectorization/runner/ArrayShiftOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicByteOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicCharOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicIntOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicLongOpTest.java ! test/hotspot/jtreg/compiler/vectorization/runner/BasicShortOpTest.java Changeset: cdf22b13 Author: Markus Gr?nlund Date: 2024-06-17 12:57:09 +0000 URL: https://git.openjdk.org/loom/commit/cdf22b13204456b589349500bef0e9d48af44e83 8326715: ZGC: RunThese24H fails with ExitCode 139 during shutdown Reviewed-by: egahlin ! src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp ! src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.hpp ! src/hotspot/share/jfr/leakprofiler/sampling/objectSample.hpp ! src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.cpp ! src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointWriter.hpp + src/hotspot/share/jfr/recorder/storage/jfrReferenceCountedStorage.cpp + src/hotspot/share/jfr/recorder/storage/jfrReferenceCountedStorage.hpp ! src/hotspot/share/jfr/support/jfrDeprecationEventWriter.cpp ! src/hotspot/share/jfr/support/jfrDeprecationEventWriter.hpp ! src/hotspot/share/jfr/support/jfrDeprecationManager.cpp ! src/hotspot/share/jfr/support/jfrDeprecationManager.hpp Changeset: c94af6f9 Author: Albert Mingkun Yang Date: 2024-06-17 15:50:55 +0000 URL: https://git.openjdk.org/loom/commit/c94af6f943c179553d1827550847b93491d47506 8333962: Obsolete OldSize Reviewed-by: dholmes, zgu ! src/hotspot/share/gc/serial/tenuredGeneration.cpp ! src/hotspot/share/gc/shared/gc_globals.hpp ! src/hotspot/share/gc/shared/genArguments.cpp ! src/hotspot/share/gc/shared/genArguments.hpp ! src/hotspot/share/runtime/arguments.cpp ! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/HeapSummary.java ! test/hotspot/gtest/gc/shared/test_collectorPolicy.cpp ! test/hotspot/jtreg/gc/arguments/TestMaxHeapSizeTools.java ! test/hotspot/jtreg/gc/arguments/TestMaxNewSize.java ! test/hotspot/jtreg/gc/g1/TestInvalidateArrayCopy.java ! test/hotspot/jtreg/gc/g1/plab/lib/PLABUtils.java ! test/hotspot/jtreg/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java ! test/hotspot/jtreg/vmTestbase/gc/huge/quicklook/largeheap/MemOptions/MemOptionsTest.java ! test/jdk/jdk/jfr/event/runtime/TestSizeTFlags.java ! test/jdk/sun/tools/jhsdb/heapconfig/JMapHeapConfigTest.java Changeset: 801bf15f Author: Thomas Stuefe Date: 2024-06-17 17:27:01 +0000 URL: https://git.openjdk.org/loom/commit/801bf15f02ca47c3547eb677079d7d2f3af1de8c 8332105: Exploded JDK does not include CDS Reviewed-by: dholmes, iklam ! src/hotspot/share/prims/whitebox.cpp ! test/hotspot/jtreg/runtime/CompressedOops/CompressedCPUSpecificClassSpaceReservation.java From aph-open at littlepinkcloud.com Tue Jun 18 08:43:55 2024 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Tue, 18 Jun 2024 09:43:55 +0100 Subject: ScopedValue.runWhere not returning scope In-Reply-To: References: <63FFA410-CC1A-43F7-99FB-97A17F730C5B@icloud.com> Message-ID: <6a921089-9c5a-46ca-80c5-e19a90aa2cf0@littlepinkcloud.com> On 6/17/24 23:15, Robert Engels wrote: > The ?tracing context? is going to be shared across all of the tasks (via > the ScopedValue). So if a task does TracingContext.get().newSpan() it > will clobber other tasks doing the same - i.e. push/pop cannot work. - > in terms of the ?current span? - since the ScopedValue is shared. Like this, no? import static ScopedValue.where; ... try (var scope = new StructuredTaskScope()) { where(CONTEXT, new TraceContext()).run(scope.fork(() -> childTask1())); ... } -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From robaho at icloud.com Tue Jun 18 10:11:55 2024 From: robaho at icloud.com (robert engels) Date: Tue, 18 Jun 2024 05:11:55 -0500 Subject: ScopedValue.runWhere not returning scope In-Reply-To: <6a921089-9c5a-46ca-80c5-e19a90aa2cf0@littlepinkcloud.com> References: <6a921089-9c5a-46ca-80c5-e19a90aa2cf0@littlepinkcloud.com> Message-ID: <376DE986-9389-409F-927B-2BB7115406A1@icloud.com> When a fork always uses a new context it?s fine. I was trying to make it work with no user code changes for tracing. The branch I posted does this with a subclass of the StructuredScope which could be injected by a framework. > On Jun 18, 2024, at 3:45?AM, Andrew Haley wrote: > > ?On 6/17/24 23:15, Robert Engels wrote: >> The ?tracing context? is going to be shared across all of the tasks (via >> the ScopedValue). So if a task does TracingContext.get().newSpan() it >> will clobber other tasks doing the same - i.e. push/pop cannot work. - >> in terms of the ?current span? - since the ScopedValue is shared. > > Like this, no? > > import static ScopedValue.where; > ... > > try (var scope = new StructuredTaskScope()) { > > where(CONTEXT, new TraceContext()).run(scope.fork(() -> childTask1())); > ... > } > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From duke at openjdk.org Wed Jun 19 05:40:36 2024 From: duke at openjdk.org (duke) Date: Wed, 19 Jun 2024 05:40:36 GMT Subject: git: openjdk/loom: fibers: 22 new changesets Message-ID: <9b5f61b0-a4a2-4cd5-91fe-36eefe797e2d@openjdk.org> Changeset: ba5a4670 Author: Phil Race Date: 2024-06-17 19:37:32 +0000 URL: https://git.openjdk.org/loom/commit/ba5a4670b8ad86fefb41a939752754bf36aac9dc 8332854: Unable to build openjdk with --with-harfbuzz=system Reviewed-by: jwaters, erikj, jdv, ihse ! make/modules/java.desktop/lib/ClientLibraries.gmk Changeset: e95f0928 Author: Gui Cao Committer: Fei Yang Date: 2024-06-18 05:24:33 +0000 URL: https://git.openjdk.org/loom/commit/e95f092862307c248bbd93e7026cbd92053fb4c9 8333964: RISC-V: C2: Check "requires_strict_order" flag for floating-point add reduction Reviewed-by: fyang ! src/hotspot/cpu/riscv/riscv_v.ad ! test/hotspot/jtreg/compiler/loopopts/superword/TestVectorFPReduction.java ! test/hotspot/jtreg/compiler/vectorapi/TestVectorAddMulReduction.java Changeset: 0199fee4 Author: Martin Doerr Date: 2024-06-18 06:48:26 +0000 URL: https://git.openjdk.org/loom/commit/0199fee431e0dccdd570b38595ea29c760dbed44 8333639: ubsan: cppVtables.cpp:81:55: runtime error: index 14 out of bounds for type 'long int [1]' Reviewed-by: aboldtch, mbaesken, kbarrett ! src/hotspot/share/cds/cppVtables.cpp Changeset: 99fefec0 Author: Christian Stein Date: 2024-06-18 07:25:17 +0000 URL: https://git.openjdk.org/loom/commit/99fefec092f49cd759f93aa75e008cfa06d2a183 8331431: Update to use jtreg 7.4 Reviewed-by: ihse, erikj, jpai ! make/autoconf/lib-tests.m4 ! make/conf/github-actions.conf ! make/conf/jib-profiles.js ! test/hotspot/jtreg/TEST.ROOT ! test/jaxp/TEST.ROOT ! test/jdk/TEST.ROOT ! test/langtools/TEST.ROOT ! test/lib-test/TEST.ROOT Changeset: 0665195e Author: Albert Mingkun Yang Date: 2024-06-18 08:27:26 +0000 URL: https://git.openjdk.org/loom/commit/0665195e59889c3f8dc5ade6521d6ca2eb4ca8b4 8334293: G1: Refactor G1ConcurrentMark::update_top_at_rebuild_start Reviewed-by: tschatzl, iwalulya ! src/hotspot/share/gc/g1/g1ConcurrentMark.inline.hpp ! src/hotspot/share/gc/g1/g1RemSetTrackingPolicy.cpp ! src/hotspot/share/gc/g1/g1RemSetTrackingPolicy.hpp Changeset: b42fe86e Author: Albert Mingkun Yang Date: 2024-06-18 08:33:02 +0000 URL: https://git.openjdk.org/loom/commit/b42fe86e817ec6975c869f46922797f546734ee0 8334097: Parallel: Obsolete HeapFirstMaximumCompactionCount Reviewed-by: tschatzl, dholmes ! src/hotspot/share/gc/parallel/parallel_globals.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/runtime/arguments.cpp Changeset: d4c13737 Author: Archie Cobbs Committer: Maurizio Cimadamore Date: 2024-06-18 08:42:44 +0000 URL: https://git.openjdk.org/loom/commit/d4c13737171b7ab7a8a29a69fa9965f8363c5aee 8334043: VerifyError when inner class is accessed in prologue Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/langtools/tools/javac/SuperInit/EarlyAssignments.java ! test/langtools/tools/javac/SuperInit/EarlyAssignments.out Changeset: 614b99a8 Author: Roberto Casta?eda Lozano Date: 2024-06-18 09:48:31 +0000 URL: https://git.openjdk.org/loom/commit/614b99a8f8360dc0a6a018f06fb336c6883f0f4a 8334442: Temporarily disable return type assertion to reduce noise in testing Reviewed-by: thartmann, chagedorn ! src/hotspot/share/opto/parse1.cpp Changeset: 472b935b Author: SendaoYan Committer: Pavel Rappo Date: 2024-06-18 10:24:43 +0000 URL: https://git.openjdk.org/loom/commit/472b935b442f7f925b665c7de91eda77f3dcbe8b 8334332: TestIOException.java fails if run by root Reviewed-by: prappo ! test/langtools/jdk/javadoc/doclet/testIOException/TestIOException.java Changeset: fa401f37 Author: Roland Westrelin Date: 2024-06-18 12:08:57 +0000 URL: https://git.openjdk.org/loom/commit/fa401f37dffe7bde27e562065dfd24381d5237cc 8333805: Replaying compilation with null static final fields results in a crash Reviewed-by: thartmann, dlong ! src/hotspot/share/ci/ciInstanceKlass.cpp ! src/hotspot/share/ci/ciReplay.cpp + test/hotspot/jtreg/compiler/ciReplay/TestNullStaticField.java Changeset: e681b4e9 Author: nibjen Committer: Sean Mullan Date: 2024-06-18 13:28:37 +0000 URL: https://git.openjdk.org/loom/commit/e681b4e9b3ae24f45d8c6adab4105df39e6b8a92 8332524: Instead of printing "TLSv1.3," it is showing "TLS13" Reviewed-by: mullan ! src/java.base/share/classes/sun/security/ssl/ClientHello.java Changeset: 91bd85d6 Author: Chen Liang Date: 2024-06-18 13:51:50 +0000 URL: https://git.openjdk.org/loom/commit/91bd85d65dff9cea91b88da7ef241be5c7b85f94 8333854: IllegalAccessError with proxies after JDK-8332457 Reviewed-by: redestad, asotona ! src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java + test/jdk/java/lang/reflect/Proxy/NonPublicMethodTypeTest.java Changeset: 8bc2fbe5 Author: Sonia Zaldana Calles Committer: Thomas Stuefe Date: 2024-06-18 14:05:11 +0000 URL: https://git.openjdk.org/loom/commit/8bc2fbe57893b110fdb5fd567df4615e7833e5ae 8333769: Pretouching tests dont test pretouching Reviewed-by: stuefe, asmehra ! src/hotspot/os/aix/os_aix.cpp ! src/hotspot/os/bsd/os_bsd.cpp ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/os.hpp + test/hotspot/jtreg/gc/TestAlwaysPreTouchBehavior.java - test/hotspot/jtreg/gc/parallel/TestAlwaysPreTouchBehavior.java ! test/lib/jdk/test/whitebox/WhiteBox.java Changeset: 6f860f8f Author: Vladimir Kozlov Date: 2024-06-18 14:48:46 +0000 URL: https://git.openjdk.org/loom/commit/6f860f8f6f69369130ed79e71255005b5beed45a 8334430: Clean up nativeInst_x86.* Reviewed-by: jwaters, jiefu ! src/hotspot/cpu/x86/nativeInst_x86.cpp ! src/hotspot/cpu/x86/nativeInst_x86.hpp Changeset: e965d70a Author: Emanuel Peter Date: 2024-06-18 16:15:09 +0000 URL: https://git.openjdk.org/loom/commit/e965d70a7425bec78620a2ca8bfaca3c392edf6a 8333876: C2 SuperWord: regression after JDK-8325155: failed: internal connection Reviewed-by: kvn, roland ! src/hotspot/share/opto/superword.cpp + test/hotspot/jtreg/compiler/loopopts/superword/TestParallelReduction.java Changeset: cec7ba3f Author: Alan Bateman Date: 2024-06-18 19:50:36 +0000 URL: https://git.openjdk.org/loom/commit/cec7ba3fd445822f2b4f02556d9f7d164c35933f Merge Changeset: 15b94726 Author: Alan Bateman Date: 2024-06-18 19:41:13 +0000 URL: https://git.openjdk.org/loom/commit/15b94726dcf5d996aef73d0ab3a93b1a284a04d2 Rename Policy ! src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java ! test/jdk/java/lang/ScopedValue/StressStackOverflow.java ! test/jdk/java/util/concurrent/StructuredTaskScope/StressCancellation.java ! test/jdk/java/util/concurrent/StructuredTaskScope/StructuredTaskScopeTest.java ! test/jdk/java/util/concurrent/StructuredTaskScope/StructuredThreadDumpTest.java ! test/jdk/java/util/concurrent/StructuredTaskScope/WithScopedValue.java Changeset: 19ddb2e9 Author: Alan Bateman Date: 2024-06-18 19:42:38 +0000 URL: https://git.openjdk.org/loom/commit/19ddb2e9f7bc9449b38f04b2f588bd929a297266 Carrying/Mounted line in thread dump may print the wrong thread ID ! src/hotspot/share/runtime/javaThread.cpp ! src/hotspot/share/runtime/threads.cpp ! test/hotspot/jtreg/ProblemList-Virtual.txt ! test/hotspot/jtreg/ProblemList.txt Changeset: 0f75690c Author: Alan Bateman Date: 2024-06-18 19:43:23 +0000 URL: https://git.openjdk.org/loom/commit/0f75690cf7a1cc128944c8329c24f3c184645962 recheckInterval wakeup not compatible with async getStackTrace ! src/java.base/share/classes/java/lang/VirtualThread.java Changeset: b5c98f2a Author: Alan Bateman Date: 2024-06-18 19:49:20 +0000 URL: https://git.openjdk.org/loom/commit/b5c98f2a2c052317fb3a0ef13b08d6b77610c166 Exclude SA tests on macsox-aarch64 ! test/hotspot/jtreg/ProblemList.txt Changeset: f3f46ae9 Author: Alan Bateman Date: 2024-06-18 19:50:48 +0000 URL: https://git.openjdk.org/loom/commit/f3f46ae9fd8fca4a955940a4b561dc8827d27980 Merge Changeset: 96a8302e Author: Alan Bateman Date: 2024-06-18 20:32:57 +0000 URL: https://git.openjdk.org/loom/commit/96a8302e00f4c710026d7ca7b12e8e9052fef5bd Fix test ! test/jdk/javax/security/auth/Subject/CallAsWithScopedValue.java From duke at openjdk.org Wed Jun 19 05:41:32 2024 From: duke at openjdk.org (duke) Date: Wed, 19 Jun 2024 05:41:32 GMT Subject: git: openjdk/loom: master: 15 new changesets Message-ID: <8aedb0dd-a4a2-485d-bde1-fd59ef8f8eff@openjdk.org> Changeset: ba5a4670 Author: Phil Race Date: 2024-06-17 19:37:32 +0000 URL: https://git.openjdk.org/loom/commit/ba5a4670b8ad86fefb41a939752754bf36aac9dc 8332854: Unable to build openjdk with --with-harfbuzz=system Reviewed-by: jwaters, erikj, jdv, ihse ! make/modules/java.desktop/lib/ClientLibraries.gmk Changeset: e95f0928 Author: Gui Cao Committer: Fei Yang Date: 2024-06-18 05:24:33 +0000 URL: https://git.openjdk.org/loom/commit/e95f092862307c248bbd93e7026cbd92053fb4c9 8333964: RISC-V: C2: Check "requires_strict_order" flag for floating-point add reduction Reviewed-by: fyang ! src/hotspot/cpu/riscv/riscv_v.ad ! test/hotspot/jtreg/compiler/loopopts/superword/TestVectorFPReduction.java ! test/hotspot/jtreg/compiler/vectorapi/TestVectorAddMulReduction.java Changeset: 0199fee4 Author: Martin Doerr Date: 2024-06-18 06:48:26 +0000 URL: https://git.openjdk.org/loom/commit/0199fee431e0dccdd570b38595ea29c760dbed44 8333639: ubsan: cppVtables.cpp:81:55: runtime error: index 14 out of bounds for type 'long int [1]' Reviewed-by: aboldtch, mbaesken, kbarrett ! src/hotspot/share/cds/cppVtables.cpp Changeset: 99fefec0 Author: Christian Stein Date: 2024-06-18 07:25:17 +0000 URL: https://git.openjdk.org/loom/commit/99fefec092f49cd759f93aa75e008cfa06d2a183 8331431: Update to use jtreg 7.4 Reviewed-by: ihse, erikj, jpai ! make/autoconf/lib-tests.m4 ! make/conf/github-actions.conf ! make/conf/jib-profiles.js ! test/hotspot/jtreg/TEST.ROOT ! test/jaxp/TEST.ROOT ! test/jdk/TEST.ROOT ! test/langtools/TEST.ROOT ! test/lib-test/TEST.ROOT Changeset: 0665195e Author: Albert Mingkun Yang Date: 2024-06-18 08:27:26 +0000 URL: https://git.openjdk.org/loom/commit/0665195e59889c3f8dc5ade6521d6ca2eb4ca8b4 8334293: G1: Refactor G1ConcurrentMark::update_top_at_rebuild_start Reviewed-by: tschatzl, iwalulya ! src/hotspot/share/gc/g1/g1ConcurrentMark.inline.hpp ! src/hotspot/share/gc/g1/g1RemSetTrackingPolicy.cpp ! src/hotspot/share/gc/g1/g1RemSetTrackingPolicy.hpp Changeset: b42fe86e Author: Albert Mingkun Yang Date: 2024-06-18 08:33:02 +0000 URL: https://git.openjdk.org/loom/commit/b42fe86e817ec6975c869f46922797f546734ee0 8334097: Parallel: Obsolete HeapFirstMaximumCompactionCount Reviewed-by: tschatzl, dholmes ! src/hotspot/share/gc/parallel/parallel_globals.hpp ! src/hotspot/share/gc/parallel/psParallelCompact.cpp ! src/hotspot/share/runtime/arguments.cpp Changeset: d4c13737 Author: Archie Cobbs Committer: Maurizio Cimadamore Date: 2024-06-18 08:42:44 +0000 URL: https://git.openjdk.org/loom/commit/d4c13737171b7ab7a8a29a69fa9965f8363c5aee 8334043: VerifyError when inner class is accessed in prologue Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/langtools/tools/javac/SuperInit/EarlyAssignments.java ! test/langtools/tools/javac/SuperInit/EarlyAssignments.out Changeset: 614b99a8 Author: Roberto Casta?eda Lozano Date: 2024-06-18 09:48:31 +0000 URL: https://git.openjdk.org/loom/commit/614b99a8f8360dc0a6a018f06fb336c6883f0f4a 8334442: Temporarily disable return type assertion to reduce noise in testing Reviewed-by: thartmann, chagedorn ! src/hotspot/share/opto/parse1.cpp Changeset: 472b935b Author: SendaoYan Committer: Pavel Rappo Date: 2024-06-18 10:24:43 +0000 URL: https://git.openjdk.org/loom/commit/472b935b442f7f925b665c7de91eda77f3dcbe8b 8334332: TestIOException.java fails if run by root Reviewed-by: prappo ! test/langtools/jdk/javadoc/doclet/testIOException/TestIOException.java Changeset: fa401f37 Author: Roland Westrelin Date: 2024-06-18 12:08:57 +0000 URL: https://git.openjdk.org/loom/commit/fa401f37dffe7bde27e562065dfd24381d5237cc 8333805: Replaying compilation with null static final fields results in a crash Reviewed-by: thartmann, dlong ! src/hotspot/share/ci/ciInstanceKlass.cpp ! src/hotspot/share/ci/ciReplay.cpp + test/hotspot/jtreg/compiler/ciReplay/TestNullStaticField.java Changeset: e681b4e9 Author: nibjen Committer: Sean Mullan Date: 2024-06-18 13:28:37 +0000 URL: https://git.openjdk.org/loom/commit/e681b4e9b3ae24f45d8c6adab4105df39e6b8a92 8332524: Instead of printing "TLSv1.3," it is showing "TLS13" Reviewed-by: mullan ! src/java.base/share/classes/sun/security/ssl/ClientHello.java Changeset: 91bd85d6 Author: Chen Liang Date: 2024-06-18 13:51:50 +0000 URL: https://git.openjdk.org/loom/commit/91bd85d65dff9cea91b88da7ef241be5c7b85f94 8333854: IllegalAccessError with proxies after JDK-8332457 Reviewed-by: redestad, asotona ! src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java + test/jdk/java/lang/reflect/Proxy/NonPublicMethodTypeTest.java Changeset: 8bc2fbe5 Author: Sonia Zaldana Calles Committer: Thomas Stuefe Date: 2024-06-18 14:05:11 +0000 URL: https://git.openjdk.org/loom/commit/8bc2fbe57893b110fdb5fd567df4615e7833e5ae 8333769: Pretouching tests dont test pretouching Reviewed-by: stuefe, asmehra ! src/hotspot/os/aix/os_aix.cpp ! src/hotspot/os/bsd/os_bsd.cpp ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/share/prims/whitebox.cpp ! src/hotspot/share/runtime/os.hpp + test/hotspot/jtreg/gc/TestAlwaysPreTouchBehavior.java - test/hotspot/jtreg/gc/parallel/TestAlwaysPreTouchBehavior.java ! test/lib/jdk/test/whitebox/WhiteBox.java Changeset: 6f860f8f Author: Vladimir Kozlov Date: 2024-06-18 14:48:46 +0000 URL: https://git.openjdk.org/loom/commit/6f860f8f6f69369130ed79e71255005b5beed45a 8334430: Clean up nativeInst_x86.* Reviewed-by: jwaters, jiefu ! src/hotspot/cpu/x86/nativeInst_x86.cpp ! src/hotspot/cpu/x86/nativeInst_x86.hpp Changeset: e965d70a Author: Emanuel Peter Date: 2024-06-18 16:15:09 +0000 URL: https://git.openjdk.org/loom/commit/e965d70a7425bec78620a2ca8bfaca3c392edf6a 8333876: C2 SuperWord: regression after JDK-8325155: failed: internal connection Reviewed-by: kvn, roland ! src/hotspot/share/opto/superword.cpp + test/hotspot/jtreg/compiler/loopopts/superword/TestParallelReduction.java From marcin.grzejszczak at gmail.com Wed Jun 19 14:43:19 2024 From: marcin.grzejszczak at gmail.com (Marcin Grzejszczak) Date: Wed, 19 Jun 2024 14:43:19 +0000 Subject: ScopedValue.runWhere not returning scope In-Reply-To: <63FFA410-CC1A-43F7-99FB-97A17F730C5B@icloud.com> References: <63FFA410-CC1A-43F7-99FB-97A17F730C5B@icloud.com> Message-ID: > To be clear, I have no control whatsoever over what does or does not happen with Java. I am only stating my opinion - and trying to help! I'm really happy about that. We're talking about a complicated problem and I'm sure we'll reach some compromise whatever that will be ;) > I do think it is strange that you want to take advantage of a new api, but you don?t want to do any work to do so??? This wouldn?t be an api change then, it would be a performance optimization behind the scenes. A primary purpose of the ScopedValue api addition is the automatic closing of the ScopeValue for better resource management in a VirtualThread system. Your requested changes eliminate a (the?) primary purpose of the api change! So, if you don?t want this, continue with ThreadLocal. That's a very interesting point. As a developer I shouldn't care whether ThreadLocal or ScopedVariable is being used. Let's say that I have an MVC application and would like to have better performance so I would just configure my framework (e.g. Spring Boot) to use Virtual Threads. Hopefully we are in agreement here that this is the intended use case of Virtual Threads - improve performance. Now, correct me if I'm wrong, but in order to maintain that performance gain behind the scenes Scoped Values would be used to retrieve the information about e.g. the current span (for tracing). As a user I don't care what is happening under the hood. From the point of view of the library creator I very much do. If the only purpose of Scoped Values is to allow a value to be there for the life of a runnable / callable then indeed this whole discussion is pointless. However we are already asked by our users whether we will support Scoped Values and I'm pretty sure that their assumption is that it will work in a transparent way (i.e. again they won't care about whether TL or SV are used under the hood - they want performance gains). Assumption that everyone has to do some migration to use this feature is acceptable, but still if only the scope would be returned by this API, no changes would be required. I think we constantly go in circles with this and I still do not understand why is it such a big problem (I understood the topic of security, but I'm personally not convinced that this is such a big deal; it's similar to a case if someone didn't close a stream or something like that. If they don't they will have problems too) > Still, if the tracing library code is properly structured I would doubt it would be more than a global search and replace in the library to switch from ThreadLocal to ScopedValues. You keep stating ?rewrite all of our code? without providing any evidence of why that would be the case. For Micrometer Observation I need to introduce new API that instead of allowing to create a Scope and close it I need to create new API that works more or less like FilterChain and Filters for HTTP (we have an analogous approach of ObservationHandlers that would need to work with HandlerChain). In the Micrometer repo only I need to do 60+ changes of the API usage. Of course I can't break compatibility so I need to leave the old API. Plus I need to add new ObservationHandler methods and not break compatibility. That's only for Micrometer Observation. I will need to have similar changes in Micrometer Tracing plus Brave and OpenTelemetry. Only after all of these projects are changed will we have to go to all the projects that actually use us to change their usage to the new one. I don't have to mention that for all of these changes we need to ensure that compatibility will not be broken and that things will work with and without Scoped Values. There also must be a TL and SV interop because not everyone will use SV only. For me it sounds like a lot of work. > It is highly doubtful any instrumented projects would need to change. I looked at how the tracing support is done with Spring and the proxies and that is certainly wouldn?t be required there. I'm sorry but in the vast majority of cases it was me doing or co-authoring the Spring instrumentation (plus dozens of other projects) and what you wrote is not entirely correct. Micrometer Observation API is being used to do the instrumentation. You can check an example here [1]. No proxies are being involved. > If you wanted no changes to instrumented projects whatsoever, you would need to use the ?check if ScopedValue context exists, if not use context from ThreadLocal? design as was suggested - which is meaningless overhead compared to the overhead of tracing itself. And if the instrumented project is being changed to use VirtualThreads it SHOULD be changed at the same time to update the tracing library setup code. So do I understand correctly that you should either use TL or SV ? No library will migrate directly to use only this or that. There must be some bridging or an option to use gradual migration. > I updated the my code to demonstrate the fallback to ThreadLocal when the top-level ScopedValue context is not available. > I also updated the code to work when the ScopedValue setup is not performed. I am pretty sure it works the way most tracing libraries are interfaced with. I looked at your sample and have a couple of comments: - You assume that you know what the entry port to your application is (a "request" comes in). You can't assume that in a production application. You might have an MVC app but maybe you have a command line application. We would have to try to guess all those entry points so that we wrap these calls in `where(...)` - Your approach is equivalent to creation of a TL entry that is mutable and all the scopes are put there inside that entry. I'm not saying this is wrong but tracing libraries do not work like this. Maybe they need to be rewritten completely to work like that? I will need to think about this but this would require major rewrite of Micrometer Tracing, Brave and Opentelemetry which I highly doubt would happen. - I understand that the SV will contain the TraceContext. The span from TraceContext can be shared between threads. How will you guard that span against concurrent writes? > I still think you are stuck and looking at the problem the wrong way. That is possible. The problem I have is that as I see it when SVs become GA, users will ask us, library creators to have tracing work with SV and it won't work out of the box unless we tell them to use TL. That might be the proper answer but I'm trying to find a solution that would be beneficial for the community. [1] - https://github.com/spring-projects/spring-framework/blob/v6.1.9/spring-web/src/main/java/org/springframework/web/filter/ServerHttpObservationFilter.java#L102-L128 Pozdrawiam / Best regards, Marcin Grzejszczak https://marcin.grzejszczak.pl https://toomuchcoding.com pon., 17 cze 2024 o 16:08 Robert Engels napisa?(a): > To be clear, I have no control whatsoever over what does or does not > happen with Java. I am only stating my opinion - and trying to help! > > From the beginning I want to implement everything using Scoped Values but > I don't want to need to rewrite all my code. Neither as a library > implementor nor in the instrumented projects. > > > I do think it is strange that you want to take advantage of a new api, but > you don?t want to do any work to do so??? This wouldn?t be an api change > then, it would be a performance optimization behind the scenes. A primary > purpose of the ScopedValue api addition is the automatic closing of the > ScopeValue for better resource management in a VirtualThread system. *Your > requested changes eliminate a (the?) primary purpose of the api change!* > So, if you don?t want this, continue with ThreadLocal. > > Still, if the tracing library code is properly structured I would doubt it > would be more than a global search and replace in the library to switch > from ThreadLocal to ScopedValues. You keep stating ?*rewrite all of our > code*? without providing any evidence of why that would be the case. > > It is highly doubtful any instrumented projects would need to change. I > looked at how the tracing support is done with Spring and the proxies and > that is certainly wouldn?t be required there. > > If you wanted no changes to instrumented projects whatsoever, you would > need to use the ?check if ScopedValue context exists, if not use context > from ThreadLocal? design as was suggested - which is meaningless overhead > compared to the overhead of tracing itself. And if the instrumented project > is being changed to use VirtualThreads it SHOULD be changed at the same > time to update the tracing library setup code. > > I updated the my code to demonstrate the fallback to ThreadLocal when the > top-level ScopedValue context is not available. > > I also updated the code to work when the ScopedValue setup is not > performed. I am pretty sure it works the way most tracing libraries are > interfaced with. > > I still think you are stuck and looking at the problem the wrong way. > > The code I shared emits all of the data to performed nested traces and > analysis. > > event Event[start=1718639998618, end=1718639998807, description=close span > handleRequest, span=SpanID 1985, tags [request 943],parent SpanId -1], > duration 189ms > event Event[start=1718639998709, end=1718639998709, description=open span > callServer2, span=SpanID 6021, tags [],parent SpanId 1943], duration 0ms > event Event[start=1718639998709, end=1718639998807, description=close span > callServer2, span=SpanID 6021, tags [],parent SpanId 1943], duration 98ms > event Event[start=1718639998807, end=1718639998807, description=open span > making jdbc call, span=SpanID 7920, tags [jdbc],parent SpanId 1943], > duration 0ms > event Event[start=1718639998807, end=1718639998807, description=call jdbc, > span=SpanID 7920, tags [jdbc],parent SpanId 1943], duration 0ms > event Event[start=1718639998617, end=1718639998722, description=close span > handleRequest, span=SpanID 1872, tags [request 885],parent SpanId -1], > duration 105ms > event Event[start=1718639998808, end=1718639998808, description=open span > making jdbc call, span=SpanID 7921, tags [jdbc],parent SpanId 1715], > duration 0ms > event Event[start=1718639998808, end=1718639998808, description=call jdbc, > span=SpanID 7921, tags [jdbc],parent SpanId 1715], duration 0ms > event Event[start=1718639998808, end=1718639998808, description=close span > making jdbc call, span=SpanID 7921, tags [jdbc],parent SpanId 1715], > duration 0ms > event Event[start=1718639998597, end=1718639998722, description=close span > handleRequest, span=SpanID 71, tags [request 35],parent SpanId -1], > duration 125ms > > > > On Jun 17, 2024, at 10:19 AM, Marcin Grzejszczak < > marcin.grzejszczak at gmail.com> wrote: > > > Right, because we don?t want to use thread locals!!!. The code I posted > supports nested spans. If you are using a ThreadLocal.CURRENT_TRACER - you > only have a single value per thread - so either the spans are chained, or > there is a stack. > > I never said that I want you to use thread locals!!! From the beginning I > want to implement everything using Scoped Values but I don't want to need > to rewrite all my code. Neither as a library implementor nor in the > instrumented projects. > > > I guarantee I can implement a full tracing library without using > ThreadLocal and have it support nested spans, etc. How can I guarantee > this? Because, you can implement tracing by passing ?context? as a > parameter to every method. If you read the ScopedValue documentation it > states that the purpose of ScopedValue is to avoid needing to pass these > method parameters. So given that, you can replace > callMethod(context,parm1?) with callMethod(parm1,?). A tracing library is > trivially implemented with a Context parameter. > > I fully believe you but I don't want to need to rewrite everything! > > > There is absolutely no need to add open/close semantics to ScopedValue > to support tracing libraries. > > Maybe someone else can do better at explaining this, I give up. I > understand that this CAN be done. I just doubt that forcing us to rewrite > all of our code even in a trivial fashion is OK, but I understood the > message. > > Pozdrawiam / Best regards, > Marcin Grzejszczak > > https://marcin.grzejszczak.pl > https://toomuchcoding.com > > > pon., 17 cze 2024 o 15:14 Robert Engels napisa?(a): > >> That is not correct. There is a ?trace context? per request at the top. >> The ?trace context? supports nested spans (which I call scopes). I have >> changed the name to Span to make this clearer, and I also added Span tag >> support. If the parentScopeId ==-1, then you are at the top-level >> (request). As an example: >> >> request 409, event Event[start=1718636994650, end=1718636994650, >> description=open span making jdbc call, spanId=3824, parentSpanId=-1], >> duration 0ms >> request 409, event Event[start=1718636994650, end=1718636994650, >> description=call jdbc, spanId=3824, *parentSpanId=825*], duration 0ms >> request 409, event Event[start=1718636994650, end=1718636994650, >> description=close span making jdbc call, spanId=3824, *parentSpanId=825*], >> duration 0ms >> request 409, event Event[start=1718636994494, end=1718636994650, >> description=close span handleRequest, spanId=825, parentSpanId=-1], >> duration 156ms >> request 148, event Event[start=1718636994487, end=1718636994598, >> description=close span handleRequest, spanId=299, parentSpanId=-1], >> duration 111ms >> request 409, total duration 166ms >> request 786, total duration 167ms >> request 75, event Event[start=1718636994485, end=1718636994655, >> description=close span handleRequest, spanId=149, parentSpanId=-1], >> duration 170ms >> request 148, total duration 119ms >> request 452, total duration 171ms >> request 75, total duration 177ms >> request 496, event Event[start=1718636994602, end=1718636994602, >> description=call jdbc, spanId=3367, parentSpanId=1000], duration 0ms >> request 496, event Event[start=1718636994602, end=1718636994602, >> description=close span making jdbc call, spanId=3367, parentSpanId=1000], >> duration 0ms >> *request 496*, event Event[start=1718636994495, end=1718636994602, >> description=close span handleRequest, spanId=1000, *parentSpanId=-1*], >> duration 107ms >> request 496, total duration 117ms >> request 635, event Event[start=1718636994497, end=1718636994658, >> description=close span handleRequest, spanId=1301, parentSpanId=-1], >> duration 161ms >> request 308, total duration 176ms >> request 576, event Event[start=1718636994658, end=1718636994658, >> description=close span making jdbc call, spanId=3901, parentSpanId=1163], >> duration 0ms >> request 635, total duration 171ms >> request 576, event Event[start=1718636994497, end=1718636994658, >> description=close span handleRequest, spanId=1163, parentSpanId=-1], >> duration 161ms >> request 267, event Event[start=1718636994658, end=1718636994658, >> description=call jdbc, spanId=3899, parentSpanId=538], duration 0ms >> >> >> Looking at the above what happens is that in pre, a new span is created >> and put in thread local. It is then closed in the post and removed from >> ThreadLocal. That's not what you're doing in beforeStatement and >> afterStatement in your example. >> >> >> Right, because we don?t want to use thread locals!!!. The code I posted >> supports nested spans. If you are using a ThreadLocal.CURRENT_TRACER - you >> only have a single value per thread - so either the spans are chained, or >> there is a stack. >> >> I guarantee I can implement a full tracing library without using >> ThreadLocal and have it support nested spans, etc. How can I guarantee >> this? Because, you can implement tracing by passing ?context? as a >> parameter to every method. If you read the ScopedValue documentation it >> states that the purpose of ScopedValue is to avoid needing to pass these >> method parameters. So given that, you can replace >> callMethod(context,parm1?) with callMethod(parm1,?). A tracing library is >> trivially implemented with a Context parameter. >> >> There is absolutely no need to add open/close semantics to ScopedValue to >> support tracing libraries. >> >> >> On Jun 17, 2024, at 9:43 AM, Marcin Grzejszczak < >> marcin.grzejszczak at gmail.com> wrote: >> >> > I updated the github.com/robaho/scope_trace code to demonstrate >> before/after tracing using ScopedValues. There are no ThreadLocals in the >> code. It works fine. >> >> Thanks for doing this, I really appreciate it! >> >> You create a SV at the beginning when the "request" is received. Try to >> create a "span" with a new SV for the JDBC statement. With how JDBC is >> being instrumented you actually don't have a handle on when and how the >> JDBC code is called. You only have access to BEFORE and AFTER. So in the >> BEFORE you would create a new span, put it in scope so that e.g. MDC get >> enriched with tracing data so that you will have subsequent logs with span >> and trace ids and then in the afterStatement you would stop the scope, >> clear MDC and close that new span. >> >> I think that over the course of those 40 emails or so we're talking all >> the time about the same thing. You're trying to convince me that it's >> enough to create a SV at the beginning of code execution and wrap the >> actual execution in the runWhere which is not the case. When you do that >> you have in fact 1 span per request and then you just retrieve it in all >> your methods, there's no span nesting, no parent-child relationship. >> >> In a normal application you would have 1 span for getting the request, at >> least 1 span for the JDBC call and 1 for each of the http calls. In your >> case you have 1 span for all 4. >> >> > The problem with open/close semantics is that it is easy to close the >> scopes out of order - which corrupts the tracing information. >> >> Yes, I mentioned that a couple of times already. >> >> > Again referring to brave, look at >> https://github.com/openzipkin/brave/blob/69003dfc811418f0dbc42e9e17ff880ebe1f4b02/instrumentation/mysql/src/main/java/brave/mysql/TracingStatementInterceptor.java#L39 >> >> This line creates a new span, whose parent was the current one in >> ThreadLocal and it also puts the newly created span in ThreadLocal. That's >> because the ThreadLocalSpan is being used. You don't have to use that API, >> you could create a span and put it in scope, that way the information about >> the underlying ThreadLocal storage mechanism wouldn't leak. >> >> > This is an example of before/after tracing. It REQUIRES that the >> preStatement() and postStatment() will ALWAYS be executed in the correct >> sequence (with no intervening spans left open). >> >> Looking at the above what happens is that in pre, a new span is created >> and put in thread local. It is then closed in the post and removed from >> ThreadLocal. That's not what you're doing in beforeStatement and >> afterStatement in your example. >> >> > This code would need to changed regardless, most likely to something >> like Brave.currentTracer() which would be able to obtain the current tracer >> appropriately. I don?t see how adding open/close to ScopedValue values >> would alleviate this. >> >> Typically this information gets passed via a constructor. Most likely in >> this case some JDBC SPI is being called and that class is instantiated >> without any dependencies. >> >> > I am guessing most libraries have these hard-coded dependencies on >> ThreadLocal. >> >> They do not. They use abstractions with scopes. Micrometer Observation >> gets the current observation from an ObservationRegistry. Underneath the >> default implementation does look into TL but it could look into SV. >> >> > Thus, someone will write a VirtualThread/ScopedValue ?native? tracing >> library, and that will be what people use - or developers will need to >> modify their libraries to use ScopedValues in an APPROPRIATE manner. >> >> I'm trying to agree with you what APPROPRIATE means because I still don't >> understand because I think we're comparing apples to oranges at this point. >> >> > You seem to believe that a tracing library user will want to create a >> new span on every ScopedValue.runWhere() - I don?t think that is the case - >> as it will generate a lot of noise. >> >> I know a few things about tracing libraries and instrumenting projects >> because I've been doing it for a decade. I never said that you should >> create a span on every runWhere. Assuming that tracing libraries would be >> using SV then I can imagine that when a Span would be put in scope then if >> it's not there in scope already then runWhere should be run. >> >> Pozdrawiam / Best regards, >> Marcin Grzejszczak >> >> https://marcin.grzejszczak.pl >> https://toomuchcoding.com >> >> >> pon., 17 cze 2024 o 14:14 Robert Engels napisa?(a): >> >>> I updated the github.com/robaho/scope_trace code to demonstrate >>> before/after tracing using ScopedValues. There are no ThreadLocals in the >>> code. It works fine. >>> >>> The problem with open/close semantics is that it is easy to close the >>> scopes out of order - which corrupts the tracing information. >>> >>> Again referring to brave, look at >>> https://github.com/openzipkin/brave/blob/69003dfc811418f0dbc42e9e17ff880ebe1f4b02/instrumentation/mysql/src/main/java/brave/mysql/TracingStatementInterceptor.java#L39 >>> >>> This is an example of before/after tracing. It REQUIRES that the >>> preStatement() and postStatment() will ALWAYS be executed in the correct >>> sequence (with no intervening spans left open). >>> >>> Notice also >>> >>> Span span = ThreadLocalSpan.CURRENT_TRACER.next(); >>> >>> This code would need to changed regardless, most likely to something >>> like Brave.currentTracer() which would be able to obtain the current tracer >>> appropriately. *I don?t see how adding open/close to ScopedValue values >>> would alleviate this.* >>> >>> I am guessing most libraries have these hard-coded dependencies on >>> ThreadLocal. >>> >>> Thus, someone will write a VirtualThread/ScopedValue ?native? tracing >>> library, and that will be what people use - or developers will need to >>> modify their libraries to use ScopedValues in an APPROPRIATE manner. You >>> seem to believe that a tracing library user will want to create a new span >>> on every ScopedValue.runWhere() - I don?t think that is the case - as it >>> will generate a lot of noise. >>> >>> ?scope values? are not only for tracing scopes. >>> >>> >>> On Jun 17, 2024, at 7:01 AM, robert engels wrote: >>> >>> Your statements like ?a user puts a scope in a SV won?t be honored?. Of >>> course not. I think you are trying to conflate scoped values with tracing >>> scopes. They are not the same thing and can?t be treated as such due to the >>> volume. >>> >>> The user will manage scopes for tracing the way they do now. It is an >>> implementation detail on how the tracing library manages these scopes. They >>> currently use thread locals. As I?ve pointed out several times the library >>> can use a scoped value to carry the scope context - and mange the active >>> scopes within in >>> >>> You are trying to make the scoped values be able to support tracing >>> directly. I don?t believe that was ever a design goal. >>> >>> On Jun 17, 2024, at 5:59?AM, Marcin Grzejszczak < >>> marcin.grzejszczak at gmail.com> wrote: >>> >>> ? >>> > Definitely, yes. If you need to create a context for every virtual >>> thread, scoped values versus thread-local variables is the least of your >>> problems. >>> >>> Can you elaborate please? >>> >>> Pozdrawiam / Best regards, >>> Marcin Grzejszczak >>> >>> https://marcin.grzejszczak.pl >>> https://toomuchcoding.com >>> >>> >>> czw., 13 cze 2024 o 19:23 Andrew Haley >>> napisa?(a): >>> >>>> On 6/13/24 16:03, Robert Engels wrote: >>>> > 3. More importantly, if you use VT effectively, you are talking about >>>> > orders of magnitude more ?trace contexts? (in the default brave >>>> handler >>>> > they are shared by thread so they are highly limited since the only >>>> > effective Java threading implementation prior to VT required pooled >>>> > threads) which reinforces my point about the increase in the volume of >>>> > unique data is the major problem for existing tracing libraries, which >>>> > will probably require architectural changes anyway. >>>> >>>> Definitely, yes. If you need to create a context for every virtual >>>> thread, >>>> scoped values versus thread-local variables is the least of your >>>> problems. >>>> >>>> -- >>>> Andrew Haley (he/him) >>>> Java Platform Lead Engineer >>>> Red Hat UK Ltd. >>>> https://keybase.io/andrewhaley >>>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pedro.lamarao at prodist.com.br Wed Jun 19 15:19:26 2024 From: pedro.lamarao at prodist.com.br (=?UTF-8?Q?Pedro_Lamar=C3=A3o?=) Date: Wed, 19 Jun 2024 12:19:26 -0300 Subject: ScopedValue.runWhere not returning scope In-Reply-To: References: <63FFA410-CC1A-43F7-99FB-97A17F730C5B@icloud.com> Message-ID: Em qua., 19 de jun. de 2024 ?s 11:45, Marcin Grzejszczak < marcin.grzejszczak at gmail.com> escreveu: > Assumption that everyone has to do some migration to use this feature is > acceptable, but still if only the scope would be returned by this API, no > changes would be required. I think we constantly go in circles with this > and I still do not understand why is it such a big problem (I understood > the topic of security, but I'm personally not convinced that this is such a > big deal; it's similar to a case if someone didn't close a stream or > something like that. If they don't they will have problems too) > The following is based on my understanding formed by reading this list, reading the JEPs, and also putting some time reading the implementation (for a reason unrelated with this discussion.) I am neither a maintainer of this software nor an authority on this matter. If my tone is inappropriate, I apologize in advance. This disclaimer was written after my "brain dump". Failing to close a ScopedValue scope is nothing like failing to close a FileInputStream. The consequence of failing to close a FileInputStream is a delay in the prompt release of operating system resources that will eventually be released by a finalizer or a Cleaner, a "resource leak" kind of defect. The consequence of failing to close a ScopedValue scope is an "undefined behaviour" kind of defect. ScopedValues, previously called ExtentLocals, are all about "call scopes", and behave like a parallel "call stack". ScopedValue scopes do not stack in some abstract philosophical sense, they very concretely stack onto each other, in memory. Closing an inner scope before closing the outer scope is like having a "stack" and pulling out the middle element. The meaning of ScopedValue.get would become "undefined" in such a case. Designed like this, the implementation would be required to *not* assume scopes are entered and left in the correct order, with the inevitable consequences in the set of optimizations allowed. Additionally, ScopedLocals would no longer be reference-immutable from the perspective of a "call scope" -- ScopedValue.get would not be idempotent from the perspective of a "call scope" -- with the inevitable consequences on the set of optimizations allowed. Neither virtual threads nor scoped locals are "plug and play" replacements for platform threads and thread locals. Perhaps the choice of having virtual threads be API-compatible with platform threads is inducing this intuition. -- Pedro Lamar?o -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcin.grzejszczak at gmail.com Wed Jun 19 15:34:29 2024 From: marcin.grzejszczak at gmail.com (Marcin Grzejszczak) Date: Wed, 19 Jun 2024 17:34:29 +0200 Subject: ScopedValue.runWhere not returning scope In-Reply-To: References: <63FFA410-CC1A-43F7-99FB-97A17F730C5B@icloud.com> Message-ID: Hey, Your point about streams not being the same is a valid one. That was an incomparable example. Regardless, in the tracing world we had this issue of potentially not closing the scopes since day one and the users just learned how to use the api properly. We also have given them api alternatives that take in a lambda so that they don't have to worry about it. If I'm making the mistake that you can assume the equivalence of the two approaches and instead there should be dedicated support for either of them (like reactive and non reactive programming), I would like to hear that so that we can start planning the whole rewrite of the api (rewrite or adding new api). Pozdrawiam / Best regards, Marcin Grzejszczak https://marcin.grzejszczak.pl https://toomuchcoding.com On Wed, 19 Jun 2024 at 17:19, Pedro Lamar?o wrote: > Em qua., 19 de jun. de 2024 ?s 11:45, Marcin Grzejszczak < > marcin.grzejszczak at gmail.com> escreveu: > > >> Assumption that everyone has to do some migration to use this feature is >> acceptable, but still if only the scope would be returned by this API, no >> changes would be required. I think we constantly go in circles with this >> and I still do not understand why is it such a big problem (I understood >> the topic of security, but I'm personally not convinced that this is such a >> big deal; it's similar to a case if someone didn't close a stream or >> something like that. If they don't they will have problems too) >> > > The following is based on my understanding formed by reading this list, > reading the JEPs, and also putting some time reading the implementation > (for a reason unrelated with this discussion.) I am neither a maintainer of > this software nor an authority on this matter. If my tone is inappropriate, > I apologize in advance. This disclaimer was written after my "brain dump". > > Failing to close a ScopedValue scope is nothing like failing to close a > FileInputStream. > The consequence of failing to close a FileInputStream is a delay in the > prompt release of operating system resources that will eventually be > released by a finalizer or a Cleaner, a "resource leak" kind of defect. > The consequence of failing to close a ScopedValue scope is an "undefined > behaviour" kind of defect. > ScopedValues, previously called ExtentLocals, are all about "call scopes", > and behave like a parallel "call stack". > ScopedValue scopes do not stack in some abstract philosophical sense, they > very concretely stack onto each other, in memory. > Closing an inner scope before closing the outer scope is like having a > "stack" and pulling out the middle element. > The meaning of ScopedValue.get would become "undefined" in such a case. > Designed like this, the implementation would be required to *not* assume > scopes are entered and left in the correct order, with the inevitable > consequences in the set of optimizations allowed. > Additionally, ScopedLocals would no longer be reference-immutable from the > perspective of a "call scope" -- ScopedValue.get would not be idempotent > from the perspective of a "call scope" -- with the inevitable consequences > on the set of optimizations allowed. > Neither virtual threads nor scoped locals are "plug and play" replacements > for platform threads and thread locals. > Perhaps the choice of having virtual threads be API-compatible with > platform threads is inducing this intuition. > > -- > Pedro Lamar?o > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pedro.lamarao at prodist.com.br Wed Jun 19 15:50:53 2024 From: pedro.lamarao at prodist.com.br (=?UTF-8?Q?Pedro_Lamar=C3=A3o?=) Date: Wed, 19 Jun 2024 12:50:53 -0300 Subject: ScopedValue.runWhere not returning scope In-Reply-To: References: <63FFA410-CC1A-43F7-99FB-97A17F730C5B@icloud.com> Message-ID: Em qua., 19 de jun. de 2024 ?s 12:34, Marcin Grzejszczak < marcin.grzejszczak at gmail.com> escreveu: > If I'm making the mistake that you can assume the equivalence of the two > approaches and instead there should be dedicated support for either of them > (like reactive and non reactive programming), I would like to hear that so > that we can start planning the whole rewrite of the api (rewrite or adding > new api). > Consider this about virtual threads, which the Loom team is frequently seen explaining. Typically, a "threads" application sets up a thread pool to intermediate the distribution of tasks to threads, allowing a seemingly unbounded task set to run onto a fixed size set of task processors. If one finds-and-replaces this platform thread pool with a virtual thread pool, all else remaining exactly the same, expecting the performance to become better may lead to disappointment. Virtual threads are not "same but better" threads; they are different threads, optimal for certain threading architectures, not optimal for others. The mantra for virtual threads is "do not pool virtual threads". Consider this about ScopedValues. One of the optimizations that the proposed design allows is caching. Because, from the perspective of a "call scope", the result of ScopedValue.get is idempotent, the implementation is allowed to cache this value. One may even hope that the VM would optimize out getter calls in hot code, if not this day then some day. -- Pedro Lamar?o -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph-open at littlepinkcloud.com Wed Jun 19 16:20:46 2024 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Wed, 19 Jun 2024 17:20:46 +0100 Subject: ScopedValue.runWhere not returning scope In-Reply-To: References: <63FFA410-CC1A-43F7-99FB-97A17F730C5B@icloud.com> Message-ID: On 6/19/24 16:50, Pedro Lamar?o wrote: > > Consider this about ScopedValues. > One of the optimizations that the proposed design allows is caching. > Because, from the perspective of a "call scope", the result of ScopedValue.get is idempotent, the implementation is allowed to cache this value. > One may even hope that the VM would optimize out getter calls in hot code, if not this day then some day. We mostly do this, but can do more. Consider this example, where we map some native memory, do stuff, then unmap the memory: public void runWithMappedRegion(Runnable r) { MemoryRegion mappedRegion = mmapNewMemoryRegion(1_000_000); // m now contains a handle to 1 megabyte of mapped memory where(CURRENT_REGION, mappedRegion).run(r); // Within the dynamic scope of r mappedRegion.unmap(); } class MemoryRegionAccess { public static Something readMemoryAt(long index) { MemoryRegion mappedRegion = CURRENT_REGION.get(); // ... Do stuff with mappedRegion ... } // more accessors } CURRENT_REGION is static final. Any code running when there is a current mapped region can use the static accessors in MemoryRegionAccess to access the memory. Any threads forked from stuctured concurrency inside a runWithMappedRegion can access the region too. We know, for certain, that we will never unmap that region unless all of its users have finished with it. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From robaho at icloud.com Wed Jun 19 20:02:57 2024 From: robaho at icloud.com (Robert Engels) Date: Wed, 19 Jun 2024 15:02:57 -0500 Subject: ScopedValue.runWhere not returning scope In-Reply-To: References: <63FFA410-CC1A-43F7-99FB-97A17F730C5B@icloud.com> Message-ID: > Now, correct me if I'm wrong, but in order to maintain that performance gain behind the scenes Scoped Values would be used to retrieve the information about e.g. the current span (for tracing). I don?t think this is the case, as long as you are not leaking the TL, the performance overhead vs SV will be negligible for a tracing library. It is one extra indirection (I think). > If the only purpose of Scoped Values is to allow a value to be there for the life of a runnable / callable then indeed this whole discussion is pointless. It is not the only purpose, but I think it is the primary one. Also, by making them non-writable / i.e. not shared up, they are safer - no one down the stack can change the value a caller sees. > so I would just configure my framework (e.g. Spring Boot) to use Virtual Threads. > You assume that you know what the entry port to your application is (a "request" comes in). You can't assume that in a production application. You might have an MVC app but maybe you have a command line application. We would have to try to guess all those entry points so that we wrap these calls in `where(...)` ?somewhere? is is occurring. It must. Something needs to assign/create the ?request id? is in order to have the trace. Wherever that is, must change, or maybe not - if you are using a framework it probably only changes in the framework. You still have never fully stated what ?our customers will ask us if we support SV? means. This thread has a lot of conversation, and I don?t think you?ve answered this. It can mean several different things. Even for a framework like Spring to ?support virtual threads? - work needs to be done. You can?t just ?turn it on?. Many frameworks use async IO which should be removed, or thread pooling which should be removed. Configuring a tracing library designed for virtual threads is just another part of this support of VT. > No proxies are being involved. Of course not in this case, you are referring to HTTP requests through servlets/filters - there is no need to use proxies. Look at the tracing support for Spring AOP. It is a different story. See https://docs.spring.io/spring-framework/docs/1.2.3/reference/aop.html and section 5.1.3. Proxies are certainly used for Spring AOP (at least at the time of that writing but I see no reason why they would change it). > The span from TraceContext can be shared between threads. How will you guard that span against concurrent writes? If you review the code, the TracingContext uses a ConcurrentLinkedQueue for the events for this exact reason. I would not shared the Span between threads, and if you are using the TaskScope it will create a new child context linked to the parent context. What I provided is a POC, but it is seems to me with some clean-up it would work fine in an SV native tracing library. Even SV uses a small TL behind the scenes - a local TL in the TraceContext may be necessary but you would get the automatic clean-up. > On Jun 19, 2024, at 9:43 AM, Marcin Grzejszczak wrote: > > > To be clear, I have no control whatsoever over what does or does not happen with Java. I am only stating my opinion - and trying to help! > > I'm really happy about that. We're talking about a complicated problem and I'm sure we'll reach some compromise whatever that will be ;) > > > I do think it is strange that you want to take advantage of a new api, but you don?t want to do any work to do so??? This wouldn?t be an api change then, it would be a performance optimization behind the scenes. A primary purpose of the ScopedValue api addition is the automatic closing of the ScopeValue for better resource management in a VirtualThread system. Your requested changes eliminate a (the?) primary purpose of the api change! So, if you don?t want this, continue with ThreadLocal. > > That's a very interesting point. > > As a developer I shouldn't care whether ThreadLocal or ScopedVariable is being used. Let's say that I have an MVC application and would like to have better performance so I would just configure my framework (e.g. Spring Boot) to use Virtual Threads. Hopefully we are in agreement here that this is the intended use case of Virtual Threads - improve performance. Now, correct me if I'm wrong, but in order to maintain that performance gain behind the scenes Scoped Values would be used to retrieve the information about e.g. the current span (for tracing). As a user I don't care what is happening under the hood. From the point of view of the library creator I very much do. > > If the only purpose of Scoped Values is to allow a value to be there for the life of a runnable / callable then indeed this whole discussion is pointless. However we are already asked by our users whether we will support Scoped Values and I'm pretty sure that their assumption is that it will work in a transparent way (i.e. again they won't care about whether TL or SV are used under the hood - they want performance gains). > > Assumption that everyone has to do some migration to use this feature is acceptable, but still if only the scope would be returned by this API, no changes would be required. I think we constantly go in circles with this and I still do not understand why is it such a big problem (I understood the topic of security, but I'm personally not convinced that this is such a big deal; it's similar to a case if someone didn't close a stream or something like that. If they don't they will have problems too) > > > Still, if the tracing library code is properly structured I would doubt it would be more than a global search and replace in the library to switch from ThreadLocal to ScopedValues. You keep stating ?rewrite all of our code? without providing any evidence of why that would be the case. > > For Micrometer Observation I need to introduce new API that instead of allowing to create a Scope and close it I need to create new API that works more or less like FilterChain and Filters for HTTP (we have an analogous approach of ObservationHandlers that would need to work with HandlerChain). In the Micrometer repo only I need to do 60+ changes of the API usage. Of course I can't break compatibility so I need to leave the old API. Plus I need to add new ObservationHandler methods and not break compatibility. That's only for Micrometer Observation. I will need to have similar changes in Micrometer Tracing plus Brave and OpenTelemetry. Only after all of these projects are changed will we have to go to all the projects that actually use us to change their usage to the new one. > > I don't have to mention that for all of these changes we need to ensure that compatibility will not be broken and that things will work with and without Scoped Values. There also must be a TL and SV interop because not everyone will use SV only. For me it sounds like a lot of work. > > > It is highly doubtful any instrumented projects would need to change. I looked at how the tracing support is done with Spring and the proxies and that is certainly wouldn?t be required there. > > I'm sorry but in the vast majority of cases it was me doing or co-authoring the Spring instrumentation (plus dozens of other projects) and what you wrote is not entirely correct. Micrometer Observation API is being used to do the instrumentation. You can check an example here [1]. No proxies are being involved. > > > If you wanted no changes to instrumented projects whatsoever, you would need to use the ?check if ScopedValue context exists, if not use context from ThreadLocal? design as was suggested - which is meaningless overhead compared to the overhead of tracing itself. And if the instrumented project is being changed to use VirtualThreads it SHOULD be changed at the same time to update the tracing library setup code. > > So do I understand correctly that you should either use TL or SV ? No library will migrate directly to use only this or that. There must be some bridging or an option to use gradual migration. > > > I updated the my code to demonstrate the fallback to ThreadLocal when the top-level ScopedValue context is not available. > > I also updated the code to work when the ScopedValue setup is not performed. I am pretty sure it works the way most tracing libraries are interfaced with. > > I looked at your sample and have a couple of comments: > - You assume that you know what the entry port to your application is (a "request" comes in). You can't assume that in a production application. You might have an MVC app but maybe you have a command line application. We would have to try to guess all those entry points so that we wrap these calls in `where(...)` > - Your approach is equivalent to creation of a TL entry that is mutable and all the scopes are put there inside that entry. I'm not saying this is wrong but tracing libraries do not work like this. Maybe they need to be rewritten completely to work like that? I will need to think about this but this would require major rewrite of Micrometer Tracing, Brave and Opentelemetry which I highly doubt would happen. > - I understand that the SV will contain the TraceContext. The span from TraceContext can be shared between threads. How will you guard that span against concurrent writes? > > > I still think you are stuck and looking at the problem the wrong way. > > That is possible. The problem I have is that as I see it when SVs become GA, users will ask us, library creators to have tracing work with SV and it won't work out of the box unless we tell them to use TL. That might be the proper answer but I'm trying to find a solution that would be beneficial for the community. > > [1] - https://github.com/spring-projects/spring-framework/blob/v6.1.9/spring-web/src/main/java/org/springframework/web/filter/ServerHttpObservationFilter.java#L102-L128 > > Pozdrawiam / Best regards, > Marcin Grzejszczak > > https://marcin.grzejszczak.pl > https://toomuchcoding.com > > pon., 17 cze 2024 o 16:08 Robert Engels > napisa?(a): > To be clear, I have no control whatsoever over what does or does not happen with Java. I am only stating my opinion - and trying to help! > >> From the beginning I want to implement everything using Scoped Values but I don't want to need to rewrite all my code. Neither as a library implementor nor in the instrumented projects. > > I do think it is strange that you want to take advantage of a new api, but you don?t want to do any work to do so??? This wouldn?t be an api change then, it would be a performance optimization behind the scenes. A primary purpose of the ScopedValue api addition is the automatic closing of the ScopeValue for better resource management in a VirtualThread system. Your requested changes eliminate a (the?) primary purpose of the api change! So, if you don?t want this, continue with ThreadLocal. > > Still, if the tracing library code is properly structured I would doubt it would be more than a global search and replace in the library to switch from ThreadLocal to ScopedValues. You keep stating ?rewrite all of our code? without providing any evidence of why that would be the case. > > It is highly doubtful any instrumented projects would need to change. I looked at how the tracing support is done with Spring and the proxies and that is certainly wouldn?t be required there. > > If you wanted no changes to instrumented projects whatsoever, you would need to use the ?check if ScopedValue context exists, if not use context from ThreadLocal? design as was suggested - which is meaningless overhead compared to the overhead of tracing itself. And if the instrumented project is being changed to use VirtualThreads it SHOULD be changed at the same time to update the tracing library setup code. > > I updated the my code to demonstrate the fallback to ThreadLocal when the top-level ScopedValue context is not available. > > I also updated the code to work when the ScopedValue setup is not performed. I am pretty sure it works the way most tracing libraries are interfaced with. > > I still think you are stuck and looking at the problem the wrong way. > > The code I shared emits all of the data to performed nested traces and analysis. > > event Event[start=1718639998618, end=1718639998807, description=close span handleRequest, span=SpanID 1985, tags [request 943],parent SpanId -1], duration 189ms > event Event[start=1718639998709, end=1718639998709, description=open span callServer2, span=SpanID 6021, tags [],parent SpanId 1943], duration 0ms > event Event[start=1718639998709, end=1718639998807, description=close span callServer2, span=SpanID 6021, tags [],parent SpanId 1943], duration 98ms > event Event[start=1718639998807, end=1718639998807, description=open span making jdbc call, span=SpanID 7920, tags [jdbc],parent SpanId 1943], duration 0ms > event Event[start=1718639998807, end=1718639998807, description=call jdbc, span=SpanID 7920, tags [jdbc],parent SpanId 1943], duration 0ms > event Event[start=1718639998617, end=1718639998722, description=close span handleRequest, span=SpanID 1872, tags [request 885],parent SpanId -1], duration 105ms > event Event[start=1718639998808, end=1718639998808, description=open span making jdbc call, span=SpanID 7921, tags [jdbc],parent SpanId 1715], duration 0ms > event Event[start=1718639998808, end=1718639998808, description=call jdbc, span=SpanID 7921, tags [jdbc],parent SpanId 1715], duration 0ms > event Event[start=1718639998808, end=1718639998808, description=close span making jdbc call, span=SpanID 7921, tags [jdbc],parent SpanId 1715], duration 0ms > event Event[start=1718639998597, end=1718639998722, description=close span handleRequest, span=SpanID 71, tags [request 35],parent SpanId -1], duration 125ms > > > >> On Jun 17, 2024, at 10:19 AM, Marcin Grzejszczak > wrote: >> >> > Right, because we don?t want to use thread locals!!!. The code I posted supports nested spans. If you are using a ThreadLocal.CURRENT_TRACER - you only have a single value per thread - so either the spans are chained, or there is a stack. >> >> I never said that I want you to use thread locals!!! From the beginning I want to implement everything using Scoped Values but I don't want to need to rewrite all my code. Neither as a library implementor nor in the instrumented projects. >> >> > I guarantee I can implement a full tracing library without using ThreadLocal and have it support nested spans, etc. How can I guarantee this? Because, you can implement tracing by passing ?context? as a parameter to every method. If you read the ScopedValue documentation it states that the purpose of ScopedValue is to avoid needing to pass these method parameters. So given that, you can replace callMethod(context,parm1?) with callMethod(parm1,?). A tracing library is trivially implemented with a Context parameter. >> >> I fully believe you but I don't want to need to rewrite everything! >> >> > There is absolutely no need to add open/close semantics to ScopedValue to support tracing libraries. >> >> Maybe someone else can do better at explaining this, I give up. I understand that this CAN be done. I just doubt that forcing us to rewrite all of our code even in a trivial fashion is OK, but I understood the message. >> >> Pozdrawiam / Best regards, >> Marcin Grzejszczak >> >> https://marcin.grzejszczak.pl >> https://toomuchcoding.com >> >> pon., 17 cze 2024 o 15:14 Robert Engels > napisa?(a): >> That is not correct. There is a ?trace context? per request at the top. The ?trace context? supports nested spans (which I call scopes). I have changed the name to Span to make this clearer, and I also added Span tag support. If the parentScopeId ==-1, then you are at the top-level (request). As an example: >> >> request 409, event Event[start=1718636994650, end=1718636994650, description=open span making jdbc call, spanId=3824, parentSpanId=-1], duration 0ms >> request 409, event Event[start=1718636994650, end=1718636994650, description=call jdbc, spanId=3824, parentSpanId=825], duration 0ms >> request 409, event Event[start=1718636994650, end=1718636994650, description=close span making jdbc call, spanId=3824, parentSpanId=825], duration 0ms >> request 409, event Event[start=1718636994494, end=1718636994650, description=close span handleRequest, spanId=825, parentSpanId=-1], duration 156ms >> request 148, event Event[start=1718636994487, end=1718636994598, description=close span handleRequest, spanId=299, parentSpanId=-1], duration 111ms >> request 409, total duration 166ms >> request 786, total duration 167ms >> request 75, event Event[start=1718636994485, end=1718636994655, description=close span handleRequest, spanId=149, parentSpanId=-1], duration 170ms >> request 148, total duration 119ms >> request 452, total duration 171ms >> request 75, total duration 177ms >> request 496, event Event[start=1718636994602, end=1718636994602, description=call jdbc, spanId=3367, parentSpanId=1000], duration 0ms >> request 496, event Event[start=1718636994602, end=1718636994602, description=close span making jdbc call, spanId=3367, parentSpanId=1000], duration 0ms >> request 496, event Event[start=1718636994495, end=1718636994602, description=close span handleRequest, spanId=1000, parentSpanId=-1], duration 107ms >> request 496, total duration 117ms >> request 635, event Event[start=1718636994497, end=1718636994658, description=close span handleRequest, spanId=1301, parentSpanId=-1], duration 161ms >> request 308, total duration 176ms >> request 576, event Event[start=1718636994658, end=1718636994658, description=close span making jdbc call, spanId=3901, parentSpanId=1163], duration 0ms >> request 635, total duration 171ms >> request 576, event Event[start=1718636994497, end=1718636994658, description=close span handleRequest, spanId=1163, parentSpanId=-1], duration 161ms >> request 267, event Event[start=1718636994658, end=1718636994658, description=call jdbc, spanId=3899, parentSpanId=538], duration 0ms >> >> >>> Looking at the above what happens is that in pre, a new span is created and put in thread local. It is then closed in the post and removed from ThreadLocal. That's not what you're doing in beforeStatement and afterStatement in your example. >> >> Right, because we don?t want to use thread locals!!!. The code I posted supports nested spans. If you are using a ThreadLocal.CURRENT_TRACER - you only have a single value per thread - so either the spans are chained, or there is a stack. >> >> I guarantee I can implement a full tracing library without using ThreadLocal and have it support nested spans, etc. How can I guarantee this? Because, you can implement tracing by passing ?context? as a parameter to every method. If you read the ScopedValue documentation it states that the purpose of ScopedValue is to avoid needing to pass these method parameters. So given that, you can replace callMethod(context,parm1?) with callMethod(parm1,?). A tracing library is trivially implemented with a Context parameter. >> >> There is absolutely no need to add open/close semantics to ScopedValue to support tracing libraries. >> >> >>> On Jun 17, 2024, at 9:43 AM, Marcin Grzejszczak > wrote: >>> >>> > I updated the github.com/robaho/scope_trace code to demonstrate before/after tracing using ScopedValues. There are no ThreadLocals in the code. It works fine. >>> >>> Thanks for doing this, I really appreciate it! >>> >>> You create a SV at the beginning when the "request" is received. Try to create a "span" with a new SV for the JDBC statement. With how JDBC is being instrumented you actually don't have a handle on when and how the JDBC code is called. You only have access to BEFORE and AFTER. So in the BEFORE you would create a new span, put it in scope so that e.g. MDC get enriched with tracing data so that you will have subsequent logs with span and trace ids and then in the afterStatement you would stop the scope, clear MDC and close that new span. >>> >>> I think that over the course of those 40 emails or so we're talking all the time about the same thing. You're trying to convince me that it's enough to create a SV at the beginning of code execution and wrap the actual execution in the runWhere which is not the case. When you do that you have in fact 1 span per request and then you just retrieve it in all your methods, there's no span nesting, no parent-child relationship. >>> >>> In a normal application you would have 1 span for getting the request, at least 1 span for the JDBC call and 1 for each of the http calls. In your case you have 1 span for all 4. >>> >>> > The problem with open/close semantics is that it is easy to close the scopes out of order - which corrupts the tracing information. >>> >>> Yes, I mentioned that a couple of times already. >>> >>> > Again referring to brave, look at https://github.com/openzipkin/brave/blob/69003dfc811418f0dbc42e9e17ff880ebe1f4b02/instrumentation/mysql/src/main/java/brave/mysql/TracingStatementInterceptor.java#L39 >>> >>> This line creates a new span, whose parent was the current one in ThreadLocal and it also puts the newly created span in ThreadLocal. That's because the ThreadLocalSpan is being used. You don't have to use that API, you could create a span and put it in scope, that way the information about the underlying ThreadLocal storage mechanism wouldn't leak. >>> >>> > This is an example of before/after tracing. It REQUIRES that the preStatement() and postStatment() will ALWAYS be executed in the correct sequence (with no intervening spans left open). >>> >>> Looking at the above what happens is that in pre, a new span is created and put in thread local. It is then closed in the post and removed from ThreadLocal. That's not what you're doing in beforeStatement and afterStatement in your example. >>> >>> > This code would need to changed regardless, most likely to something like Brave.currentTracer() which would be able to obtain the current tracer appropriately. I don?t see how adding open/close to ScopedValue values would alleviate this. >>> >>> Typically this information gets passed via a constructor. Most likely in this case some JDBC SPI is being called and that class is instantiated without any dependencies. >>> >>> > I am guessing most libraries have these hard-coded dependencies on ThreadLocal. >>> >>> They do not. They use abstractions with scopes. Micrometer Observation gets the current observation from an ObservationRegistry. Underneath the default implementation does look into TL but it could look into SV. >>> >>> > Thus, someone will write a VirtualThread/ScopedValue ?native? tracing library, and that will be what people use - or developers will need to modify their libraries to use ScopedValues in an APPROPRIATE manner. >>> >>> I'm trying to agree with you what APPROPRIATE means because I still don't understand because I think we're comparing apples to oranges at this point. >>> >>> > You seem to believe that a tracing library user will want to create a new span on every ScopedValue.runWhere() - I don?t think that is the case - as it will generate a lot of noise. >>> >>> I know a few things about tracing libraries and instrumenting projects because I've been doing it for a decade. I never said that you should create a span on every runWhere. Assuming that tracing libraries would be using SV then I can imagine that when a Span would be put in scope then if it's not there in scope already then runWhere should be run. >>> >>> Pozdrawiam / Best regards, >>> Marcin Grzejszczak >>> >>> https://marcin.grzejszczak.pl >>> https://toomuchcoding.com >>> >>> pon., 17 cze 2024 o 14:14 Robert Engels > napisa?(a): >>> I updated the github.com/robaho/scope_trace code to demonstrate before/after tracing using ScopedValues. There are no ThreadLocals in the code. It works fine. >>> >>> The problem with open/close semantics is that it is easy to close the scopes out of order - which corrupts the tracing information. >>> >>> Again referring to brave, look at https://github.com/openzipkin/brave/blob/69003dfc811418f0dbc42e9e17ff880ebe1f4b02/instrumentation/mysql/src/main/java/brave/mysql/TracingStatementInterceptor.java#L39 >>> >>> This is an example of before/after tracing. It REQUIRES that the preStatement() and postStatment() will ALWAYS be executed in the correct sequence (with no intervening spans left open). >>> >>> Notice also >>> >>> Span span = ThreadLocalSpan.CURRENT_TRACER.next(); >>> >>> This code would need to changed regardless, most likely to something like Brave.currentTracer() which would be able to obtain the current tracer appropriately. I don?t see how adding open/close to ScopedValue values would alleviate this. >>> >>> I am guessing most libraries have these hard-coded dependencies on ThreadLocal. >>> >>> Thus, someone will write a VirtualThread/ScopedValue ?native? tracing library, and that will be what people use - or developers will need to modify their libraries to use ScopedValues in an APPROPRIATE manner. You seem to believe that a tracing library user will want to create a new span on every ScopedValue.runWhere() - I don?t think that is the case - as it will generate a lot of noise. >>> >>> ?scope values? are not only for tracing scopes. >>> >>> >>>> On Jun 17, 2024, at 7:01 AM, robert engels > wrote: >>>> >>>> Your statements like ?a user puts a scope in a SV won?t be honored?. Of course not. I think you are trying to conflate scoped values with tracing scopes. They are not the same thing and can?t be treated as such due to the volume. >>>> >>>> The user will manage scopes for tracing the way they do now. It is an implementation detail on how the tracing library manages these scopes. They currently use thread locals. As I?ve pointed out several times the library can use a scoped value to carry the scope context - and mange the active scopes within in >>>> >>>> You are trying to make the scoped values be able to support tracing directly. I don?t believe that was ever a design goal. >>>> >>>>> On Jun 17, 2024, at 5:59?AM, Marcin Grzejszczak > wrote: >>>>> >>>>> ? >>>>> > Definitely, yes. If you need to create a context for every virtual thread, scoped values versus thread-local variables is the least of your problems. >>>>> >>>>> Can you elaborate please? >>>>> >>>>> Pozdrawiam / Best regards, >>>>> Marcin Grzejszczak >>>>> >>>>> https://marcin.grzejszczak.pl >>>>> https://toomuchcoding.com >>>>> >>>>> czw., 13 cze 2024 o 19:23 Andrew Haley > napisa?(a): >>>>> On 6/13/24 16:03, Robert Engels wrote: >>>>> > 3. More importantly, if you use VT effectively, you are talking about >>>>> > orders of magnitude more ?trace contexts? (in the default brave handler >>>>> > they are shared by thread so they are highly limited since the only >>>>> > effective Java threading implementation prior to VT required pooled >>>>> > threads) which reinforces my point about the increase in the volume of >>>>> > unique data is the major problem for existing tracing libraries, which >>>>> > will probably require architectural changes anyway. >>>>> >>>>> Definitely, yes. If you need to create a context for every virtual thread, >>>>> scoped values versus thread-local variables is the least of your problems. >>>>> >>>>> -- >>>>> Andrew Haley (he/him) >>>>> Java Platform Lead Engineer >>>>> Red Hat UK Ltd. > >>>>> https://keybase.io/andrewhaley >>>>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 >>>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Thu Jun 20 05:19:01 2024 From: duke at openjdk.org (duke) Date: Thu, 20 Jun 2024 05:19:01 GMT Subject: git: openjdk/loom: fibers: 16 new changesets Message-ID: <17ee9b16-1a2a-431c-93a0-7f4c70c9689e@openjdk.org> Changeset: 2ce85d96 Author: Alisen Chung Date: 2024-06-18 21:31:16 +0000 URL: https://git.openjdk.org/loom/commit/2ce85d96352cef4910cb6a5c2d9b174ca9d8a4e4 8291472: [macos] jawt 1.4 lock/unlock not supported Reviewed-by: serb ! src/java.desktop/macosx/native/libjawt/jawt.m Changeset: e227c7e3 Author: Archie Cobbs Committer: Maurizio Cimadamore Date: 2024-06-18 23:23:39 +0000 URL: https://git.openjdk.org/loom/commit/e227c7e37d4de0656f013f3a936b1acfa56cc2e0 8334258: Compiler erronousely allows access to instance variable in argument expression of a constructor invocation Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java + test/langtools/tools/javac/SuperInit/EarlyAssignmentNoPreview1.java + test/langtools/tools/javac/SuperInit/EarlyAssignmentNoPreview1.out + test/langtools/tools/javac/SuperInit/EarlyAssignmentNoPreview2.java + test/langtools/tools/javac/SuperInit/EarlyAssignmentNoPreview2.out + test/langtools/tools/javac/SuperInit/EarlyAssignmentNoPreview3.java + test/langtools/tools/javac/SuperInit/EarlyAssignmentNoPreview3.out Changeset: 48621ae1 Author: Christian Hagedorn Date: 2024-06-19 06:45:04 +0000 URL: https://git.openjdk.org/loom/commit/48621ae193ef70b2fae4dcb7ddc524f349beb131 8331168: Introduce PredicateEntryIterator to iterate through predicate entries Reviewed-by: roland, kvn ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/loopnode.hpp ! src/hotspot/share/opto/loopopts.cpp ! src/hotspot/share/opto/predicates.cpp ! src/hotspot/share/opto/predicates.hpp Changeset: 2165a053 Author: Yudi Zheng Date: 2024-06-19 09:04:12 +0000 URL: https://git.openjdk.org/loom/commit/2165a053e8bf56220af8ef1ef50708364f555931 8334399: [JVMCI] Implement JVMCICompiler::is_intrinsic_supported Reviewed-by: dnsimon ! src/hotspot/share/jvmci/jvmciCompiler.cpp ! src/hotspot/share/jvmci/jvmciCompiler.hpp ! src/hotspot/share/jvmci/jvmciEnv.cpp ! src/hotspot/share/jvmci/jvmciEnv.hpp ! src/hotspot/share/jvmci/jvmciJavaClasses.hpp ! src/hotspot/share/jvmci/jvmciRuntime.cpp ! src/hotspot/share/jvmci/jvmciRuntime.hpp ! src/hotspot/share/jvmci/vmSymbols_jvmci.hpp ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotJVMCIRuntime.java ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotVMConfigStore.java ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/runtime/JVMCICompiler.java Changeset: 07ebda54 Author: Inigo Mediavilla Saiz Committer: David Holmes Date: 2024-06-19 10:35:32 +0000 URL: https://git.openjdk.org/loom/commit/07ebda54f290cc17c6682abd26ceca2868488a63 8334215: serviceability/dcmd/thread/PrintMountedVirtualThread.java failing with JTREG_TEST_THREAD_FACTORY=Virtual Reviewed-by: dholmes ! src/hotspot/share/runtime/threads.cpp ! test/hotspot/jtreg/serviceability/dcmd/thread/PrintMountedVirtualThread.java Changeset: 7b3a96d5 Author: Archie Cobbs Committer: Maurizio Cimadamore Date: 2024-06-19 10:45:34 +0000 URL: https://git.openjdk.org/loom/commit/7b3a96d57023e8a7cf495e2d7c551976f0e5656b 8334488: Improve error for illegal early access from nested class Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java ! test/langtools/tools/javac/AnonymousClass/AnonymousInSuperCallNegTest.out ! test/langtools/tools/javac/LocalClassCtorPrologue.out + test/langtools/tools/javac/SuperInit/EarlyInnerAccessErrorMessageTest.java + test/langtools/tools/javac/SuperInit/EarlyInnerAccessErrorMessageTest.out ! test/langtools/tools/javac/SuperInit/EarlyLocalClass.out Changeset: 50bed6c6 Author: Daniel Fuchs Date: 2024-06-19 10:54:13 +0000 URL: https://git.openjdk.org/loom/commit/50bed6c67b1edd7736bdf79308d135a4e1047ff0 8334297: (so) java/nio/channels/SocketChannel/OpenLeak.java should not depend on SecurityManager Reviewed-by: alanb ! test/jdk/java/nio/channels/SocketChannel/OpenLeak.java Changeset: 5f5cbafa Author: Alan Bateman Date: 2024-06-19 11:57:27 +0000 URL: https://git.openjdk.org/loom/commit/5f5cbafa3315eb14b5d39b07e52e545241de6926 Merge ! src/hotspot/share/runtime/threads.cpp ! src/hotspot/share/runtime/threads.cpp Changeset: 60acb49d Author: Alan Bateman Date: 2024-06-19 12:06:47 +0000 URL: https://git.openjdk.org/loom/commit/60acb49df5cee62d885525cd8cc3835e4e6a4105 Remove serviceability/dcmd/thread/PrintMountedVirtualThread.java from exclude list ! test/hotspot/jtreg/ProblemList.txt Changeset: 01ee4241 Author: Adam Sotona Date: 2024-06-19 15:15:30 +0000 URL: https://git.openjdk.org/loom/commit/01ee4241b76e78ca67803c4b083fcedecef1c96c 8294960: Convert java.base/java.lang.invoke package to use the Classfile API to generate lambdas and method handles Co-authored-by: Claes Redestad Reviewed-by: redestad, liach ! src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java ! src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java ! src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java ! src/java.base/share/classes/java/lang/invoke/LambdaForm.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/invoke/MethodType.java ! src/java.base/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java ! src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java ! test/hotspot/jtreg/ProblemList.txt Changeset: 856931d0 Author: Erik Gahlin Date: 2024-06-19 16:23:22 +0000 URL: https://git.openjdk.org/loom/commit/856931d01f14b1c665c04e05d5637b8237c56988 8304732: jdk/jfr/api/consumer/recordingstream/TestStop.java failed again with "Expected outer stream to have 3 events" Reviewed-by: mgronlun ! src/hotspot/share/jfr/jni/jfrJniMethod.cpp ! src/hotspot/share/jfr/jni/jfrJniMethod.hpp ! src/hotspot/share/jfr/jni/jfrJniMethodRegistration.cpp ! src/hotspot/share/jfr/recorder/repository/jfrChunk.cpp ! src/hotspot/share/jfr/recorder/repository/jfrChunk.hpp ! src/hotspot/share/jfr/support/jfrIntrinsics.hpp ! src/hotspot/share/runtime/objectMonitor.cpp + src/jdk.jfr/share/classes/jdk/jfr/internal/HiddenWait.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/JVM.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/JVMSupport.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/MetadataRepository.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/AbstractEventStream.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/EventDirectoryStream.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/EventFileStream.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/management/StreamBarrier.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/util/Utils.java ! test/jdk/jdk/jfr/api/consumer/recordingstream/TestStop.java Changeset: bcf4bb48 Author: Kevin Walls Date: 2024-06-19 16:35:20 +0000 URL: https://git.openjdk.org/loom/commit/bcf4bb4882e06d8c52f6eb4e9c4e027ba0622c5f 8333344: JMX attaching of Subject does not work when security manager not allowed Reviewed-by: weijun, dfuchs ! src/java.base/share/classes/module-info.java ! src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java ! src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java ! src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java ! src/java.management/share/classes/javax/management/monitor/Monitor.java ! test/jdk/javax/management/monitor/StartStopTest.java ! test/jdk/javax/management/monitor/ThreadPoolAccTest.java = test/jdk/javax/management/monitor/all.policy ! test/jdk/javax/management/remote/mandatory/notif/NotificationAccessControllerTest.java ! test/jdk/javax/management/remote/mandatory/notif/NotificationEmissionTest.java ! test/jdk/javax/management/remote/mandatory/passwordAccessFile/NonJMXPrincipalsTest.java ! test/jdk/javax/management/remote/mandatory/passwordAccessFile/PasswordAccessFileTest.java ! test/jdk/javax/management/remote/mandatory/passwordAuthenticator/RMIAltAuthTest.java ! test/jdk/javax/management/remote/mandatory/passwordAuthenticator/RMIPasswdAuthTest.java ! test/jdk/javax/management/remote/mandatory/passwordAuthenticator/SimpleStandard.java ! test/jdk/javax/management/security/AuthorizationTest.java ! test/jdk/sun/management/jmxremote/bootstrap/RmiBootstrapTest.java Changeset: 03dc1c00 Author: Alan Bateman Date: 2024-06-19 17:58:32 +0000 URL: https://git.openjdk.org/loom/commit/03dc1c00c6a7f412a55056b5f5f7b65be44a7b2c Merge ! src/hotspot/share/runtime/objectMonitor.cpp ! test/hotspot/jtreg/ProblemList.txt ! src/hotspot/share/runtime/objectMonitor.cpp ! test/hotspot/jtreg/ProblemList.txt Changeset: b575389f Author: Alan Bateman Date: 2024-06-19 20:49:30 +0000 URL: https://git.openjdk.org/loom/commit/b575389f9c2e8b7868ee4a688227a372ed19a97b Rename vthread_scheduler to vthread_info ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/services/diagnosticCommand.cpp ! src/hotspot/share/services/diagnosticCommand.hpp ! 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/jdk/internal/vm/VMSupport.java ! src/java.base/share/classes/sun/nio/ch/Poller.java + src/java.base/share/classes/sun/nio/ch/PollerInfo.java ! test/failure_handler/src/share/conf/common.properties + test/hotspot/jtreg/serviceability/dcmd/thread/VThreadInfoTest.java - test/hotspot/jtreg/serviceability/dcmd/thread/VThreadSchedulerTest.java Changeset: d2bf2998 Author: Alan Bateman Date: 2024-06-19 20:49:46 +0000 URL: https://git.openjdk.org/loom/commit/d2bf2998f4a1a68a633886c01ab93973613ffe0c Merge Changeset: 42b30f13 Author: Alan Bateman Date: 2024-06-20 06:16:58 +0000 URL: https://git.openjdk.org/loom/commit/42b30f13ff0c84967450b976e630384dc8b3bfca Test matching wrong output ! test/hotspot/jtreg/serviceability/dcmd/thread/VThreadInfoTest.java From duke at openjdk.org Thu Jun 20 05:19:35 2024 From: duke at openjdk.org (duke) Date: Thu, 20 Jun 2024 05:19:35 GMT Subject: git: openjdk/loom: master: 10 new changesets Message-ID: Changeset: 2ce85d96 Author: Alisen Chung Date: 2024-06-18 21:31:16 +0000 URL: https://git.openjdk.org/loom/commit/2ce85d96352cef4910cb6a5c2d9b174ca9d8a4e4 8291472: [macos] jawt 1.4 lock/unlock not supported Reviewed-by: serb ! src/java.desktop/macosx/native/libjawt/jawt.m Changeset: e227c7e3 Author: Archie Cobbs Committer: Maurizio Cimadamore Date: 2024-06-18 23:23:39 +0000 URL: https://git.openjdk.org/loom/commit/e227c7e37d4de0656f013f3a936b1acfa56cc2e0 8334258: Compiler erronousely allows access to instance variable in argument expression of a constructor invocation Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java + test/langtools/tools/javac/SuperInit/EarlyAssignmentNoPreview1.java + test/langtools/tools/javac/SuperInit/EarlyAssignmentNoPreview1.out + test/langtools/tools/javac/SuperInit/EarlyAssignmentNoPreview2.java + test/langtools/tools/javac/SuperInit/EarlyAssignmentNoPreview2.out + test/langtools/tools/javac/SuperInit/EarlyAssignmentNoPreview3.java + test/langtools/tools/javac/SuperInit/EarlyAssignmentNoPreview3.out Changeset: 48621ae1 Author: Christian Hagedorn Date: 2024-06-19 06:45:04 +0000 URL: https://git.openjdk.org/loom/commit/48621ae193ef70b2fae4dcb7ddc524f349beb131 8331168: Introduce PredicateEntryIterator to iterate through predicate entries Reviewed-by: roland, kvn ! src/hotspot/share/opto/loopnode.cpp ! src/hotspot/share/opto/loopnode.hpp ! src/hotspot/share/opto/loopopts.cpp ! src/hotspot/share/opto/predicates.cpp ! src/hotspot/share/opto/predicates.hpp Changeset: 2165a053 Author: Yudi Zheng Date: 2024-06-19 09:04:12 +0000 URL: https://git.openjdk.org/loom/commit/2165a053e8bf56220af8ef1ef50708364f555931 8334399: [JVMCI] Implement JVMCICompiler::is_intrinsic_supported Reviewed-by: dnsimon ! src/hotspot/share/jvmci/jvmciCompiler.cpp ! src/hotspot/share/jvmci/jvmciCompiler.hpp ! src/hotspot/share/jvmci/jvmciEnv.cpp ! src/hotspot/share/jvmci/jvmciEnv.hpp ! src/hotspot/share/jvmci/jvmciJavaClasses.hpp ! src/hotspot/share/jvmci/jvmciRuntime.cpp ! src/hotspot/share/jvmci/jvmciRuntime.hpp ! src/hotspot/share/jvmci/vmSymbols_jvmci.hpp ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotJVMCIRuntime.java ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotVMConfigStore.java ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/runtime/JVMCICompiler.java Changeset: 07ebda54 Author: Inigo Mediavilla Saiz Committer: David Holmes Date: 2024-06-19 10:35:32 +0000 URL: https://git.openjdk.org/loom/commit/07ebda54f290cc17c6682abd26ceca2868488a63 8334215: serviceability/dcmd/thread/PrintMountedVirtualThread.java failing with JTREG_TEST_THREAD_FACTORY=Virtual Reviewed-by: dholmes ! src/hotspot/share/runtime/threads.cpp ! test/hotspot/jtreg/serviceability/dcmd/thread/PrintMountedVirtualThread.java Changeset: 7b3a96d5 Author: Archie Cobbs Committer: Maurizio Cimadamore Date: 2024-06-19 10:45:34 +0000 URL: https://git.openjdk.org/loom/commit/7b3a96d57023e8a7cf495e2d7c551976f0e5656b 8334488: Improve error for illegal early access from nested class Reviewed-by: mcimadamore ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java ! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java ! test/langtools/tools/javac/AnonymousClass/AnonymousInSuperCallNegTest.out ! test/langtools/tools/javac/LocalClassCtorPrologue.out + test/langtools/tools/javac/SuperInit/EarlyInnerAccessErrorMessageTest.java + test/langtools/tools/javac/SuperInit/EarlyInnerAccessErrorMessageTest.out ! test/langtools/tools/javac/SuperInit/EarlyLocalClass.out Changeset: 50bed6c6 Author: Daniel Fuchs Date: 2024-06-19 10:54:13 +0000 URL: https://git.openjdk.org/loom/commit/50bed6c67b1edd7736bdf79308d135a4e1047ff0 8334297: (so) java/nio/channels/SocketChannel/OpenLeak.java should not depend on SecurityManager Reviewed-by: alanb ! test/jdk/java/nio/channels/SocketChannel/OpenLeak.java Changeset: 01ee4241 Author: Adam Sotona Date: 2024-06-19 15:15:30 +0000 URL: https://git.openjdk.org/loom/commit/01ee4241b76e78ca67803c4b083fcedecef1c96c 8294960: Convert java.base/java.lang.invoke package to use the Classfile API to generate lambdas and method handles Co-authored-by: Claes Redestad Reviewed-by: redestad, liach ! src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java ! src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java ! src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java ! src/java.base/share/classes/java/lang/invoke/LambdaForm.java ! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/java.base/share/classes/java/lang/invoke/MethodHandles.java ! src/java.base/share/classes/java/lang/invoke/MethodType.java ! src/java.base/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java ! src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java ! test/hotspot/jtreg/ProblemList.txt Changeset: 856931d0 Author: Erik Gahlin Date: 2024-06-19 16:23:22 +0000 URL: https://git.openjdk.org/loom/commit/856931d01f14b1c665c04e05d5637b8237c56988 8304732: jdk/jfr/api/consumer/recordingstream/TestStop.java failed again with "Expected outer stream to have 3 events" Reviewed-by: mgronlun ! src/hotspot/share/jfr/jni/jfrJniMethod.cpp ! src/hotspot/share/jfr/jni/jfrJniMethod.hpp ! src/hotspot/share/jfr/jni/jfrJniMethodRegistration.cpp ! src/hotspot/share/jfr/recorder/repository/jfrChunk.cpp ! src/hotspot/share/jfr/recorder/repository/jfrChunk.hpp ! src/hotspot/share/jfr/support/jfrIntrinsics.hpp ! src/hotspot/share/runtime/objectMonitor.cpp + src/jdk.jfr/share/classes/jdk/jfr/internal/HiddenWait.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/JVM.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/JVMSupport.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/MetadataRepository.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/AbstractEventStream.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/EventDirectoryStream.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/EventFileStream.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/management/StreamBarrier.java ! src/jdk.jfr/share/classes/jdk/jfr/internal/util/Utils.java ! test/jdk/jdk/jfr/api/consumer/recordingstream/TestStop.java Changeset: bcf4bb48 Author: Kevin Walls Date: 2024-06-19 16:35:20 +0000 URL: https://git.openjdk.org/loom/commit/bcf4bb4882e06d8c52f6eb4e9c4e027ba0622c5f 8333344: JMX attaching of Subject does not work when security manager not allowed Reviewed-by: weijun, dfuchs ! src/java.base/share/classes/module-info.java ! src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java ! src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java ! src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java ! src/java.management/share/classes/javax/management/monitor/Monitor.java ! test/jdk/javax/management/monitor/StartStopTest.java ! test/jdk/javax/management/monitor/ThreadPoolAccTest.java = test/jdk/javax/management/monitor/all.policy ! test/jdk/javax/management/remote/mandatory/notif/NotificationAccessControllerTest.java ! test/jdk/javax/management/remote/mandatory/notif/NotificationEmissionTest.java ! test/jdk/javax/management/remote/mandatory/passwordAccessFile/NonJMXPrincipalsTest.java ! test/jdk/javax/management/remote/mandatory/passwordAccessFile/PasswordAccessFileTest.java ! test/jdk/javax/management/remote/mandatory/passwordAuthenticator/RMIAltAuthTest.java ! test/jdk/javax/management/remote/mandatory/passwordAuthenticator/RMIPasswdAuthTest.java ! test/jdk/javax/management/remote/mandatory/passwordAuthenticator/SimpleStandard.java ! test/jdk/javax/management/security/AuthorizationTest.java ! test/jdk/sun/management/jmxremote/bootstrap/RmiBootstrapTest.java From marcin.grzejszczak at gmail.com Thu Jun 20 12:42:51 2024 From: marcin.grzejszczak at gmail.com (Marcin Grzejszczak) Date: Thu, 20 Jun 2024 12:42:51 +0000 Subject: ScopedValue.runWhere not returning scope In-Reply-To: References: <63FFA410-CC1A-43F7-99FB-97A17F730C5B@icloud.com> Message-ID: > I don?t think this is the case, as long as you are not leaking the TL, the performance overhead vs SV will be negligible for a tracing library. It is one extra indirection (I think). So Virtual Threads with Thread Locals will work as fast as Virtual Threads with Scope Values? I doubt that this is true especially after reading the JEP: "Introduce scoped values, which enable a method to share immutable data both with its callees within a thread, and with child threads. Scoped values are easier to reason about than thread-local variables. They also have lower space and time costs, especially when used together with virtual threads (JEP 444) and structured concurrency (JEP 480). This is a preview API." > It is not the only purpose, but I think it is the primary one. Also, by making them non-writable / i.e. not shared up, they are safer - no one down the stack can change the value a caller sees. I still would like to get the answer from the JDK maintainers if my arguments (which I think I presented a lot) would allow it to consider opening the API to the idea of giving the library maintainers more control. I doubt it that the final users (people writing actual business code) would ever use the scoping API. > ?somewhere? is is occurring. It must. Something needs to assign/create the ?request id? is in order to have the trace. Wherever that is, must change, or maybe not - if you are using a framework it probably only changes in the framework. Yes but the framework might not know about it. Library maintainers know that they will be instrumenting libraries, they don't always know if they are at the beginning of the call stack or not. > You still have never fully stated what ?our customers will ask us if we support SV? means. This thread has a lot of conversation, and I don?t think you?ve answered this. It can mean several different things. In Micrometer we already have such issue [1] and I'm pretty sure in Spring there are similar ones. > Even for a framework like Spring to ?support virtual threads? - work needs to be done. You can?t just ?turn it on?. Many frameworks use async IO which should be removed, or thread pooling which should be removed. Configuring a tracing library designed for virtual threads is just another part of this support of VT. It's not about configuring it. Tracing libraries would need to be completely rewritten. That's what I'm trying to say from the very beginning. > Look at the tracing support for Spring AOP. It is a different story. See https://docs.spring.io/spring-framework/docs/1.2.3/reference/aop.html and section 5.1.3. Proxies are certainly used for Spring AOP (at least at the time of that writing but I see no reason why they would change it). Like I said it the last time. I've co-authored / reviewed instrumentation of Spring components with Micrometer Observation so I do know what I'm talking about. You're pointing to a Spring Framework version 1.2.3 and we have 6.x now so you're pointing to an outdated doc. Also please believe me that we are not using proxies for observability in Spring. I know that because like I say again, I co-authored / reviewed most of these instrumentations. > If you review the code, the TracingContext uses a ConcurrentLinkedQueue for the events for this exact reason. I would not shared the Span between threads, and if you are using the TaskScope it will create a new child context linked to the parent context. I understand. > What I provided is a POC, but it is seems to me with some clean-up it would work fine in an SV native tracing library. Even SV uses a small TL behind the scenes - a local TL in the TraceContext may be necessary but you would get the automatic clean-up. I understand that you think this would be the case. I actually started implementing this in Micrometer Observation and still there's Micrometer Tracing and OpenTelemetry and Brave. If you think this is feasible you can look at Brave and try to prototype the solution. I will look into doing that too but IMO it's not possible without doing massive changes in the API. [1] - https://github.com/micrometer-metrics/context-propagation/issues/108 Pozdrawiam / Best regards, Marcin Grzejszczak https://marcin.grzejszczak.pl https://toomuchcoding.com ?r., 19 cze 2024 o 20:03 Robert Engels napisa?(a): > Now, correct me if I'm wrong, but in order to maintain that performance > gain behind the scenes Scoped Values would be used to retrieve the > information about e.g. the current span (for tracing). > > > I don?t think this is the case, as long as you are not leaking the TL, the > performance overhead vs SV will be negligible for a tracing library. It is > one extra indirection (I think). > > If the only purpose of Scoped Values is to allow a value to be there for > the life of a runnable / callable then indeed this whole discussion is > pointless. > > > It is not the only purpose, but I think it is the primary one. Also, by > making them non-writable / i.e. not shared up, they are safer - no one down > the stack can change the value a caller sees. > > so I would just configure my framework (e.g. Spring Boot) to use Virtual > Threads. > > > You assume that you know what the entry port to your application is (a > "request" comes in). You can't assume that in a production application. You > might have an MVC app but maybe you have a command line application. We > would have to try to guess all those entry points so that we wrap these > calls in `where(...)` > > > ?somewhere? is is occurring. It must. Something needs to assign/create the > ?request id? is in order to have the trace. Wherever that is, must change, > or maybe not - if you are using a framework it probably only changes in the > framework. > > You still have never fully stated what ?our customers will ask us if we > support SV? means. This thread has a lot of conversation, and I don?t think > you?ve answered this. It can mean several different things. > > Even for a framework like Spring to ?support virtual threads? - work needs > to be done. You can?t just ?turn it on?. Many frameworks use async IO which > should be removed, or thread pooling which should be removed. Configuring a > tracing library designed for virtual threads is just another part of this > support of VT. > > No proxies are being involved. > > > Of course not in this case, you are referring to HTTP requests through > servlets/filters - there is no need to use proxies. > > Look at the tracing support for Spring AOP. It is a different story. See > https://docs.spring.io/spring-framework/docs/1.2.3/reference/aop.html and > section 5.1.3. Proxies are certainly used for Spring AOP (at least at the > time of that writing but I see no reason why they would change it). > > The span from TraceContext can be shared between threads. How will you > guard that span against concurrent writes? > > > If you review the code, the TracingContext uses a ConcurrentLinkedQueue > for the events for this exact reason. I would not shared the Span between > threads, and if you are using the TaskScope it will create a new child > context linked to the parent context. > > What I provided is a POC, but it is seems to me with some clean-up it > would work fine in an SV native tracing library. Even SV uses a small TL > behind the scenes - a local TL in the TraceContext may be necessary but you > would get the automatic clean-up. > > > On Jun 19, 2024, at 9:43 AM, Marcin Grzejszczak < > marcin.grzejszczak at gmail.com> wrote: > > > To be clear, I have no control whatsoever over what does or does not > happen with Java. I am only stating my opinion - and trying to help! > > I'm really happy about that. We're talking about a complicated problem and > I'm sure we'll reach some compromise whatever that will be ;) > > > I do think it is strange that you want to take advantage of a new api, > but you don?t want to do any work to do so??? This wouldn?t be an api > change then, it would be a performance optimization behind the scenes. A > primary purpose of the ScopedValue api addition is the automatic closing of > the ScopeValue for better resource management in a VirtualThread system. > Your requested changes eliminate a (the?) primary purpose of the api > change! So, if you don?t want this, continue with ThreadLocal. > > That's a very interesting point. > > As a developer I shouldn't care whether ThreadLocal or ScopedVariable is > being used. Let's say that I have an MVC application and would like to have > better performance so I would just configure my framework (e.g. Spring > Boot) to use Virtual Threads. Hopefully we are in agreement here that this > is the intended use case of Virtual Threads - improve performance. Now, > correct me if I'm wrong, but in order to maintain that performance gain > behind the scenes Scoped Values would be used to retrieve the information > about e.g. the current span (for tracing). As a user I don't care what is > happening under the hood. From the point of view of the library creator I > very much do. > > If the only purpose of Scoped Values is to allow a value to be there for > the life of a runnable / callable then indeed this whole discussion is > pointless. However we are already asked by our users whether we will > support Scoped Values and I'm pretty sure that their assumption is that it > will work in a transparent way (i.e. again they won't care about whether TL > or SV are used under the hood - they want performance gains). > > Assumption that everyone has to do some migration to use this feature is > acceptable, but still if only the scope would be returned by this API, no > changes would be required. I think we constantly go in circles with this > and I still do not understand why is it such a big problem (I understood > the topic of security, but I'm personally not convinced that this is such a > big deal; it's similar to a case if someone didn't close a stream or > something like that. If they don't they will have problems too) > > > Still, if the tracing library code is properly structured I would doubt > it would be more than a global search and replace in the library to switch > from ThreadLocal to ScopedValues. You keep stating ?rewrite all of our > code? without providing any evidence of why that would be the case. > > For Micrometer Observation I need to introduce new API that instead of > allowing to create a Scope and close it I need to create new API that works > more or less like FilterChain and Filters for HTTP (we have an analogous > approach of ObservationHandlers that would need to work with HandlerChain). > In the Micrometer repo only I need to do 60+ changes of the API usage. Of > course I can't break compatibility so I need to leave the old API. Plus I > need to add new ObservationHandler methods and not break compatibility. > That's only for Micrometer Observation. I will need to have similar changes > in Micrometer Tracing plus Brave and OpenTelemetry. Only after all of these > projects are changed will we have to go to all the projects that actually > use us to change their usage to the new one. > > I don't have to mention that for all of these changes we need to ensure > that compatibility will not be broken and that things will work with and > without Scoped Values. There also must be a TL and SV interop because not > everyone will use SV only. For me it sounds like a lot of work. > > > It is highly doubtful any instrumented projects would need to change. I > looked at how the tracing support is done with Spring and the proxies and > that is certainly wouldn?t be required there. > > I'm sorry but in the vast majority of cases it was me doing or > co-authoring the Spring instrumentation (plus dozens of other projects) and > what you wrote is not entirely correct. Micrometer Observation API is being > used to do the instrumentation. You can check an example here [1]. No > proxies are being involved. > > > If you wanted no changes to instrumented projects whatsoever, you would > need to use the ?check if ScopedValue context exists, if not use context > from ThreadLocal? design as was suggested - which is meaningless overhead > compared to the overhead of tracing itself. And if the instrumented project > is being changed to use VirtualThreads it SHOULD be changed at the same > time to update the tracing library setup code. > > So do I understand correctly that you should either use TL or SV ? No > library will migrate directly to use only this or that. There must be some > bridging or an option to use gradual migration. > > > I updated the my code to demonstrate the fallback to ThreadLocal when > the top-level ScopedValue context is not available. > > I also updated the code to work when the ScopedValue setup is not > performed. I am pretty sure it works the way most tracing libraries are > interfaced with. > > I looked at your sample and have a couple of comments: > - You assume that you know what the entry port to your application is (a > "request" comes in). You can't assume that in a production application. You > might have an MVC app but maybe you have a command line application. We > would have to try to guess all those entry points so that we wrap these > calls in `where(...)` > - Your approach is equivalent to creation of a TL entry that is mutable > and all the scopes are put there inside that entry. I'm not saying this is > wrong but tracing libraries do not work like this. Maybe they need to be > rewritten completely to work like that? I will need to think about this but > this would require major rewrite of Micrometer Tracing, Brave and > Opentelemetry which I highly doubt would happen. > - I understand that the SV will contain the TraceContext. The span from > TraceContext can be shared between threads. How will you guard that span > against concurrent writes? > > > I still think you are stuck and looking at the problem the wrong way. > > That is possible. The problem I have is that as I see it when SVs become > GA, users will ask us, library creators to have tracing work with SV and it > won't work out of the box unless we tell them to use TL. That might be the > proper answer but I'm trying to find a solution that would be beneficial > for the community. > > [1] - > https://github.com/spring-projects/spring-framework/blob/v6.1.9/spring-web/src/main/java/org/springframework/web/filter/ServerHttpObservationFilter.java#L102-L128 > > Pozdrawiam / Best regards, > Marcin Grzejszczak > > https://marcin.grzejszczak.pl > https://toomuchcoding.com > > > pon., 17 cze 2024 o 16:08 Robert Engels napisa?(a): > >> To be clear, I have no control whatsoever over what does or does not >> happen with Java. I am only stating my opinion - and trying to help! >> >> From the beginning I want to implement everything using Scoped Values but >> I don't want to need to rewrite all my code. Neither as a library >> implementor nor in the instrumented projects. >> >> >> I do think it is strange that you want to take advantage of a new api, >> but you don?t want to do any work to do so??? This wouldn?t be an api >> change then, it would be a performance optimization behind the scenes. A >> primary purpose of the ScopedValue api addition is the automatic closing of >> the ScopeValue for better resource management in a VirtualThread system. *Your >> requested changes eliminate a (the?) primary purpose of the api change!* >> So, if you don?t want this, continue with ThreadLocal. >> >> Still, if the tracing library code is properly structured I would doubt >> it would be more than a global search and replace in the library to switch >> from ThreadLocal to ScopedValues. You keep stating ?*rewrite all of our >> code*? without providing any evidence of why that would be the case. >> >> It is highly doubtful any instrumented projects would need to change. I >> looked at how the tracing support is done with Spring and the proxies and >> that is certainly wouldn?t be required there. >> >> If you wanted no changes to instrumented projects whatsoever, you would >> need to use the ?check if ScopedValue context exists, if not use context >> from ThreadLocal? design as was suggested - which is meaningless overhead >> compared to the overhead of tracing itself. And if the instrumented project >> is being changed to use VirtualThreads it SHOULD be changed at the same >> time to update the tracing library setup code. >> >> I updated the my code to demonstrate the fallback to ThreadLocal when the >> top-level ScopedValue context is not available. >> >> I also updated the code to work when the ScopedValue setup is not >> performed. I am pretty sure it works the way most tracing libraries are >> interfaced with. >> >> I still think you are stuck and looking at the problem the wrong way. >> >> The code I shared emits all of the data to performed nested traces and >> analysis. >> >> event Event[start=1718639998618, end=1718639998807, description=close >> span handleRequest, span=SpanID 1985, tags [request 943],parent SpanId -1], >> duration 189ms >> event Event[start=1718639998709, end=1718639998709, description=open span >> callServer2, span=SpanID 6021, tags [],parent SpanId 1943], duration 0ms >> event Event[start=1718639998709, end=1718639998807, description=close >> span callServer2, span=SpanID 6021, tags [],parent SpanId 1943], duration >> 98ms >> event Event[start=1718639998807, end=1718639998807, description=open span >> making jdbc call, span=SpanID 7920, tags [jdbc],parent SpanId 1943], >> duration 0ms >> event Event[start=1718639998807, end=1718639998807, description=call >> jdbc, span=SpanID 7920, tags [jdbc],parent SpanId 1943], duration 0ms >> event Event[start=1718639998617, end=1718639998722, description=close >> span handleRequest, span=SpanID 1872, tags [request 885],parent SpanId -1], >> duration 105ms >> event Event[start=1718639998808, end=1718639998808, description=open span >> making jdbc call, span=SpanID 7921, tags [jdbc],parent SpanId 1715], >> duration 0ms >> event Event[start=1718639998808, end=1718639998808, description=call >> jdbc, span=SpanID 7921, tags [jdbc],parent SpanId 1715], duration 0ms >> event Event[start=1718639998808, end=1718639998808, description=close >> span making jdbc call, span=SpanID 7921, tags [jdbc],parent SpanId 1715], >> duration 0ms >> event Event[start=1718639998597, end=1718639998722, description=close >> span handleRequest, span=SpanID 71, tags [request 35],parent SpanId -1], >> duration 125ms >> >> >> >> On Jun 17, 2024, at 10:19 AM, Marcin Grzejszczak < >> marcin.grzejszczak at gmail.com> wrote: >> >> > Right, because we don?t want to use thread locals!!!. The code I posted >> supports nested spans. If you are using a ThreadLocal.CURRENT_TRACER - you >> only have a single value per thread - so either the spans are chained, or >> there is a stack. >> >> I never said that I want you to use thread locals!!! From the beginning I >> want to implement everything using Scoped Values but I don't want to need >> to rewrite all my code. Neither as a library implementor nor in the >> instrumented projects. >> >> > I guarantee I can implement a full tracing library without using >> ThreadLocal and have it support nested spans, etc. How can I guarantee >> this? Because, you can implement tracing by passing ?context? as a >> parameter to every method. If you read the ScopedValue documentation it >> states that the purpose of ScopedValue is to avoid needing to pass these >> method parameters. So given that, you can replace >> callMethod(context,parm1?) with callMethod(parm1,?). A tracing library is >> trivially implemented with a Context parameter. >> >> I fully believe you but I don't want to need to rewrite everything! >> >> > There is absolutely no need to add open/close semantics to ScopedValue >> to support tracing libraries. >> >> Maybe someone else can do better at explaining this, I give up. I >> understand that this CAN be done. I just doubt that forcing us to rewrite >> all of our code even in a trivial fashion is OK, but I understood the >> message. >> >> Pozdrawiam / Best regards, >> Marcin Grzejszczak >> >> https://marcin.grzejszczak.pl >> https://toomuchcoding.com >> >> >> pon., 17 cze 2024 o 15:14 Robert Engels napisa?(a): >> >>> That is not correct. There is a ?trace context? per request at the top. >>> The ?trace context? supports nested spans (which I call scopes). I have >>> changed the name to Span to make this clearer, and I also added Span tag >>> support. If the parentScopeId ==-1, then you are at the top-level >>> (request). As an example: >>> >>> request 409, event Event[start=1718636994650, end=1718636994650, >>> description=open span making jdbc call, spanId=3824, parentSpanId=-1], >>> duration 0ms >>> request 409, event Event[start=1718636994650, end=1718636994650, >>> description=call jdbc, spanId=3824, *parentSpanId=825*], duration 0ms >>> request 409, event Event[start=1718636994650, end=1718636994650, >>> description=close span making jdbc call, spanId=3824, *parentSpanId=825*], >>> duration 0ms >>> request 409, event Event[start=1718636994494, end=1718636994650, >>> description=close span handleRequest, spanId=825, parentSpanId=-1], >>> duration 156ms >>> request 148, event Event[start=1718636994487, end=1718636994598, >>> description=close span handleRequest, spanId=299, parentSpanId=-1], >>> duration 111ms >>> request 409, total duration 166ms >>> request 786, total duration 167ms >>> request 75, event Event[start=1718636994485, end=1718636994655, >>> description=close span handleRequest, spanId=149, parentSpanId=-1], >>> duration 170ms >>> request 148, total duration 119ms >>> request 452, total duration 171ms >>> request 75, total duration 177ms >>> request 496, event Event[start=1718636994602, end=1718636994602, >>> description=call jdbc, spanId=3367, parentSpanId=1000], duration 0ms >>> request 496, event Event[start=1718636994602, end=1718636994602, >>> description=close span making jdbc call, spanId=3367, parentSpanId=1000], >>> duration 0ms >>> *request 496*, event Event[start=1718636994495, end=1718636994602, >>> description=close span handleRequest, spanId=1000, *parentSpanId=-1*], >>> duration 107ms >>> request 496, total duration 117ms >>> request 635, event Event[start=1718636994497, end=1718636994658, >>> description=close span handleRequest, spanId=1301, parentSpanId=-1], >>> duration 161ms >>> request 308, total duration 176ms >>> request 576, event Event[start=1718636994658, end=1718636994658, >>> description=close span making jdbc call, spanId=3901, parentSpanId=1163], >>> duration 0ms >>> request 635, total duration 171ms >>> request 576, event Event[start=1718636994497, end=1718636994658, >>> description=close span handleRequest, spanId=1163, parentSpanId=-1], >>> duration 161ms >>> request 267, event Event[start=1718636994658, end=1718636994658, >>> description=call jdbc, spanId=3899, parentSpanId=538], duration 0ms >>> >>> >>> Looking at the above what happens is that in pre, a new span is created >>> and put in thread local. It is then closed in the post and removed from >>> ThreadLocal. That's not what you're doing in beforeStatement and >>> afterStatement in your example. >>> >>> >>> Right, because we don?t want to use thread locals!!!. The code I posted >>> supports nested spans. If you are using a ThreadLocal.CURRENT_TRACER - you >>> only have a single value per thread - so either the spans are chained, or >>> there is a stack. >>> >>> I guarantee I can implement a full tracing library without using >>> ThreadLocal and have it support nested spans, etc. How can I guarantee >>> this? Because, you can implement tracing by passing ?context? as a >>> parameter to every method. If you read the ScopedValue documentation it >>> states that the purpose of ScopedValue is to avoid needing to pass these >>> method parameters. So given that, you can replace >>> callMethod(context,parm1?) with callMethod(parm1,?). A tracing library is >>> trivially implemented with a Context parameter. >>> >>> There is absolutely no need to add open/close semantics to ScopedValue >>> to support tracing libraries. >>> >>> >>> On Jun 17, 2024, at 9:43 AM, Marcin Grzejszczak < >>> marcin.grzejszczak at gmail.com> wrote: >>> >>> > I updated the github.com/robaho/scope_trace code to demonstrate >>> before/after tracing using ScopedValues. There are no ThreadLocals in the >>> code. It works fine. >>> >>> Thanks for doing this, I really appreciate it! >>> >>> You create a SV at the beginning when the "request" is received. Try to >>> create a "span" with a new SV for the JDBC statement. With how JDBC is >>> being instrumented you actually don't have a handle on when and how the >>> JDBC code is called. You only have access to BEFORE and AFTER. So in the >>> BEFORE you would create a new span, put it in scope so that e.g. MDC get >>> enriched with tracing data so that you will have subsequent logs with span >>> and trace ids and then in the afterStatement you would stop the scope, >>> clear MDC and close that new span. >>> >>> I think that over the course of those 40 emails or so we're talking all >>> the time about the same thing. You're trying to convince me that it's >>> enough to create a SV at the beginning of code execution and wrap the >>> actual execution in the runWhere which is not the case. When you do that >>> you have in fact 1 span per request and then you just retrieve it in all >>> your methods, there's no span nesting, no parent-child relationship. >>> >>> In a normal application you would have 1 span for getting the request, >>> at least 1 span for the JDBC call and 1 for each of the http calls. In your >>> case you have 1 span for all 4. >>> >>> > The problem with open/close semantics is that it is easy to close the >>> scopes out of order - which corrupts the tracing information. >>> >>> Yes, I mentioned that a couple of times already. >>> >>> > Again referring to brave, look at >>> https://github.com/openzipkin/brave/blob/69003dfc811418f0dbc42e9e17ff880ebe1f4b02/instrumentation/mysql/src/main/java/brave/mysql/TracingStatementInterceptor.java#L39 >>> >>> This line creates a new span, whose parent was the current one in >>> ThreadLocal and it also puts the newly created span in ThreadLocal. That's >>> because the ThreadLocalSpan is being used. You don't have to use that API, >>> you could create a span and put it in scope, that way the information about >>> the underlying ThreadLocal storage mechanism wouldn't leak. >>> >>> > This is an example of before/after tracing. It REQUIRES that the >>> preStatement() and postStatment() will ALWAYS be executed in the correct >>> sequence (with no intervening spans left open). >>> >>> Looking at the above what happens is that in pre, a new span is created >>> and put in thread local. It is then closed in the post and removed from >>> ThreadLocal. That's not what you're doing in beforeStatement and >>> afterStatement in your example. >>> >>> > This code would need to changed regardless, most likely to something >>> like Brave.currentTracer() which would be able to obtain the current tracer >>> appropriately. I don?t see how adding open/close to ScopedValue values >>> would alleviate this. >>> >>> Typically this information gets passed via a constructor. Most likely in >>> this case some JDBC SPI is being called and that class is instantiated >>> without any dependencies. >>> >>> > I am guessing most libraries have these hard-coded dependencies on >>> ThreadLocal. >>> >>> They do not. They use abstractions with scopes. Micrometer Observation >>> gets the current observation from an ObservationRegistry. Underneath the >>> default implementation does look into TL but it could look into SV. >>> >>> > Thus, someone will write a VirtualThread/ScopedValue ?native? tracing >>> library, and that will be what people use - or developers will need to >>> modify their libraries to use ScopedValues in an APPROPRIATE manner. >>> >>> I'm trying to agree with you what APPROPRIATE means because I still >>> don't understand because I think we're comparing apples to oranges at this >>> point. >>> >>> > You seem to believe that a tracing library user will want to create a >>> new span on every ScopedValue.runWhere() - I don?t think that is the case - >>> as it will generate a lot of noise. >>> >>> I know a few things about tracing libraries and instrumenting projects >>> because I've been doing it for a decade. I never said that you should >>> create a span on every runWhere. Assuming that tracing libraries would be >>> using SV then I can imagine that when a Span would be put in scope then if >>> it's not there in scope already then runWhere should be run. >>> >>> Pozdrawiam / Best regards, >>> Marcin Grzejszczak >>> >>> https://marcin.grzejszczak.pl >>> https://toomuchcoding.com >>> >>> >>> pon., 17 cze 2024 o 14:14 Robert Engels napisa?(a): >>> >>>> I updated the github.com/robaho/scope_trace code to demonstrate >>>> before/after tracing using ScopedValues. There are no ThreadLocals in the >>>> code. It works fine. >>>> >>>> The problem with open/close semantics is that it is easy to close the >>>> scopes out of order - which corrupts the tracing information. >>>> >>>> Again referring to brave, look at >>>> https://github.com/openzipkin/brave/blob/69003dfc811418f0dbc42e9e17ff880ebe1f4b02/instrumentation/mysql/src/main/java/brave/mysql/TracingStatementInterceptor.java#L39 >>>> >>>> This is an example of before/after tracing. It REQUIRES that the >>>> preStatement() and postStatment() will ALWAYS be executed in the correct >>>> sequence (with no intervening spans left open). >>>> >>>> Notice also >>>> >>>> Span span = ThreadLocalSpan.CURRENT_TRACER.next(); >>>> >>>> This code would need to changed regardless, most likely to something >>>> like Brave.currentTracer() which would be able to obtain the current tracer >>>> appropriately. *I don?t see how adding open/close to ScopedValue >>>> values would alleviate this.* >>>> >>>> I am guessing most libraries have these hard-coded dependencies on >>>> ThreadLocal. >>>> >>>> Thus, someone will write a VirtualThread/ScopedValue ?native? tracing >>>> library, and that will be what people use - or developers will need to >>>> modify their libraries to use ScopedValues in an APPROPRIATE manner. You >>>> seem to believe that a tracing library user will want to create a new span >>>> on every ScopedValue.runWhere() - I don?t think that is the case - as it >>>> will generate a lot of noise. >>>> >>>> ?scope values? are not only for tracing scopes. >>>> >>>> >>>> On Jun 17, 2024, at 7:01 AM, robert engels wrote: >>>> >>>> Your statements like ?a user puts a scope in a SV won?t be honored?. Of >>>> course not. I think you are trying to conflate scoped values with tracing >>>> scopes. They are not the same thing and can?t be treated as such due to the >>>> volume. >>>> >>>> The user will manage scopes for tracing the way they do now. It is an >>>> implementation detail on how the tracing library manages these scopes. They >>>> currently use thread locals. As I?ve pointed out several times the library >>>> can use a scoped value to carry the scope context - and mange the active >>>> scopes within in >>>> >>>> You are trying to make the scoped values be able to support tracing >>>> directly. I don?t believe that was ever a design goal. >>>> >>>> On Jun 17, 2024, at 5:59?AM, Marcin Grzejszczak < >>>> marcin.grzejszczak at gmail.com> wrote: >>>> >>>> ? >>>> > Definitely, yes. If you need to create a context for every virtual >>>> thread, scoped values versus thread-local variables is the least of your >>>> problems. >>>> >>>> Can you elaborate please? >>>> >>>> Pozdrawiam / Best regards, >>>> Marcin Grzejszczak >>>> >>>> https://marcin.grzejszczak.pl >>>> https://toomuchcoding.com >>>> >>>> >>>> czw., 13 cze 2024 o 19:23 Andrew Haley >>>> napisa?(a): >>>> >>>>> On 6/13/24 16:03, Robert Engels wrote: >>>>> > 3. More importantly, if you use VT effectively, you are talking about >>>>> > orders of magnitude more ?trace contexts? (in the default brave >>>>> handler >>>>> > they are shared by thread so they are highly limited since the only >>>>> > effective Java threading implementation prior to VT required pooled >>>>> > threads) which reinforces my point about the increase in the volume >>>>> of >>>>> > unique data is the major problem for existing tracing libraries, >>>>> which >>>>> > will probably require architectural changes anyway. >>>>> >>>>> Definitely, yes. If you need to create a context for every virtual >>>>> thread, >>>>> scoped values versus thread-local variables is the least of your >>>>> problems. >>>>> >>>>> -- >>>>> Andrew Haley (he/him) >>>>> Java Platform Lead Engineer >>>>> Red Hat UK Ltd. >>>>> https://keybase.io/andrewhaley >>>>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 >>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at icloud.com Thu Jun 20 12:54:58 2024 From: robaho at icloud.com (robert engels) Date: Thu, 20 Jun 2024 07:54:58 -0500 Subject: ScopedValue.runWhere not returning scope In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From robaho at icloud.com Thu Jun 20 13:57:39 2024 From: robaho at icloud.com (Robert Engels) Date: Thu, 20 Jun 2024 08:57:39 -0500 Subject: ScopedValue.runWhere not returning scope In-Reply-To: References: <63FFA410-CC1A-43F7-99FB-97A17F730C5B@icloud.com> Message-ID: <70BCABBF-ECB2-422E-A157-DC2AC451723E@icloud.com> Did not mean to be short. I?d like to address your other points: > So Virtual Threads with Thread Locals will work as fast as Virtual Threads with Scope Values? I doubt that this is true? If there is any performance gain, it is due to the property of them being immutable and shared - something your api changes are trying to discard - so this is somewhat circular reasoning. > Yes but the framework might not know about it. Then the user level code does. Somewhere changes will need to be made. My reading of the Spring AOP docs tell me it could have SV support without changing a line of user code. As I?ve mentioned many times, and others have concurred, VirtualThreads are not designed to ?just turn them on and watch the performance improvement!? There is still architectural work that needs to be done to use them effectively. (e.g. in low concurrency they perform worse than platform threads). > In Micrometer we already have such issue... That doesn?t answer the question of what does ?our customers will ask us if we support SV? means. Does supporting SV means all tracing related context is in a SV? Does it mean that a library using SV performs better than one using TL. > believe me that we are not using proxies for observability in Spring Maybe we are talking about different things, but the current docs for Spring AOP states they specifically use proxies and why: https://docs.spring.io/spring-framework/reference/core/aop/introduction-proxies.html Which makes perfect sense to me. Whenever you have existing layering (servlets, remote interfaces, etc.) you can put the AOP integration there - no need to inject. Same with libraries that support before/after callbacks - you just need to access the context to link the calls. Rather than setting this in a TL, you can just as easily use thread id + method name, etc to create the key to link the calls. There are requirements about call order scoping anyway - or you will have leaks. > it's not possible without doing massive changes in the API The entire brave codebase is only 27k lines and 181 files. I suspect the entire change set would be much less than 2k lines of code to have a true SV based distributed tracing library. This is not a substantial amount of work to do things properly. Looking through the ?instrumentation? directory of nearly 50k LOC - all(?) calls defer to the library - so I would expect zero changes there. Anyway, you are welcome to continue to hang your hat on an SV api change, but to me it would be a bad change outside of the purpose of SV, so my guess it will be a difficult effort to convince others smarter than me to do so. > On Jun 20, 2024, at 7:42 AM, Marcin Grzejszczak wrote: > > > I don?t think this is the case, as long as you are not leaking the TL, the performance overhead vs SV will be negligible for a tracing library. It is one extra indirection (I think). > > So Virtual Threads with Thread Locals will work as fast as Virtual Threads with Scope Values? I doubt that this is true especially after reading the JEP: "Introduce scoped values, which enable a method to share immutable data both with its callees within a thread, and with child threads. Scoped values are easier to reason about than thread-local variables. They also have lower space and time costs, especially when used together with virtual threads (JEP 444) and structured concurrency (JEP 480). This is a preview API." > > > It is not the only purpose, but I think it is the primary one. Also, by making them non-writable / i.e. not shared up, they are safer - no one down the stack can change the value a caller sees. > > I still would like to get the answer from the JDK maintainers if my arguments (which I think I presented a lot) would allow it to consider opening the API to the idea of giving the library maintainers more control. I doubt it that the final users (people writing actual business code) would ever use the scoping API. > > > ?somewhere? is is occurring. It must. Something needs to assign/create the ?request id? is in order to have the trace. Wherever that is, must change, or maybe not - if you are using a framework it probably only changes in the framework. > > Yes but the framework might not know about it. Library maintainers know that they will be instrumenting libraries, they don't always know if they are at the beginning of the call stack or not. > > > You still have never fully stated what ?our customers will ask us if we support SV? means. This thread has a lot of conversation, and I don?t think you?ve answered this. It can mean several different things. > > In Micrometer we already have such issue [1] and I'm pretty sure in Spring there are similar ones. > > > Even for a framework like Spring to ?support virtual threads? - work needs to be done. You can?t just ?turn it on?. Many frameworks use async IO which should be removed, or thread pooling which should be removed. Configuring a tracing library designed for virtual threads is just another part of this support of VT. > > It's not about configuring it. Tracing libraries would need to be completely rewritten. That's what I'm trying to say from the very beginning. > > > Look at the tracing support for Spring AOP. It is a different story. See https://docs.spring.io/spring-framework/docs/1.2.3/reference/aop.html and section 5.1.3. Proxies are certainly used for Spring AOP (at least at the time of that writing but I see no reason why they would change it). > > Like I said it the last time. I've co-authored / reviewed instrumentation of Spring components with Micrometer Observation so I do know what I'm talking about. You're pointing to a Spring Framework version 1.2.3 and we have 6.x now so you're pointing to an outdated doc. Also please believe me that we are not using proxies for observability in Spring. I know that because like I say again, I co-authored / reviewed most of these instrumentations. > > > If you review the code, the TracingContext uses a ConcurrentLinkedQueue for the events for this exact reason. I would not shared the Span between threads, and if you are using the TaskScope it will create a new child context linked to the parent context. > > I understand. > > > What I provided is a POC, but it is seems to me with some clean-up it would work fine in an SV native tracing library. Even SV uses a small TL behind the scenes - a local TL in the TraceContext may be necessary but you would get the automatic clean-up. > > I understand that you think this would be the case. I actually started implementing this in Micrometer Observation and still there's Micrometer Tracing and OpenTelemetry and Brave. If you think this is feasible you can look at Brave and try to prototype the solution. I will look into doing that too but IMO it's not possible without doing massive changes in the API. > > [1] - https://github.com/micrometer-metrics/context-propagation/issues/108 > > > Pozdrawiam / Best regards, > Marcin Grzejszczak > > https://marcin.grzejszczak.pl > https://toomuchcoding.com > > ?r., 19 cze 2024 o 20:03 Robert Engels > napisa?(a): >> Now, correct me if I'm wrong, but in order to maintain that performance gain behind the scenes Scoped Values would be used to retrieve the information about e.g. the current span (for tracing). > > I don?t think this is the case, as long as you are not leaking the TL, the performance overhead vs SV will be negligible for a tracing library. It is one extra indirection (I think). > >> If the only purpose of Scoped Values is to allow a value to be there for the life of a runnable / callable then indeed this whole discussion is pointless. > > It is not the only purpose, but I think it is the primary one. Also, by making them non-writable / i.e. not shared up, they are safer - no one down the stack can change the value a caller sees. > >> so I would just configure my framework (e.g. Spring Boot) to use Virtual Threads. > >> You assume that you know what the entry port to your application is (a "request" comes in). You can't assume that in a production application. You might have an MVC app but maybe you have a command line application. We would have to try to guess all those entry points so that we wrap these calls in `where(...)` > > ?somewhere? is is occurring. It must. Something needs to assign/create the ?request id? is in order to have the trace. Wherever that is, must change, or maybe not - if you are using a framework it probably only changes in the framework. > > You still have never fully stated what ?our customers will ask us if we support SV? means. This thread has a lot of conversation, and I don?t think you?ve answered this. It can mean several different things. > > Even for a framework like Spring to ?support virtual threads? - work needs to be done. You can?t just ?turn it on?. Many frameworks use async IO which should be removed, or thread pooling which should be removed. Configuring a tracing library designed for virtual threads is just another part of this support of VT. > >> No proxies are being involved. > > Of course not in this case, you are referring to HTTP requests through servlets/filters - there is no need to use proxies. > > Look at the tracing support for Spring AOP. It is a different story. See https://docs.spring.io/spring-framework/docs/1.2.3/reference/aop.html and section 5.1.3. Proxies are certainly used for Spring AOP (at least at the time of that writing but I see no reason why they would change it). > >> The span from TraceContext can be shared between threads. How will you guard that span against concurrent writes? > > If you review the code, the TracingContext uses a ConcurrentLinkedQueue for the events for this exact reason. I would not shared the Span between threads, and if you are using the TaskScope it will create a new child context linked to the parent context. > > What I provided is a POC, but it is seems to me with some clean-up it would work fine in an SV native tracing library. Even SV uses a small TL behind the scenes - a local TL in the TraceContext may be necessary but you would get the automatic clean-up. > > >> On Jun 19, 2024, at 9:43 AM, Marcin Grzejszczak > wrote: >> >> > To be clear, I have no control whatsoever over what does or does not happen with Java. I am only stating my opinion - and trying to help! >> >> I'm really happy about that. We're talking about a complicated problem and I'm sure we'll reach some compromise whatever that will be ;) >> >> > I do think it is strange that you want to take advantage of a new api, but you don?t want to do any work to do so??? This wouldn?t be an api change then, it would be a performance optimization behind the scenes. A primary purpose of the ScopedValue api addition is the automatic closing of the ScopeValue for better resource management in a VirtualThread system. Your requested changes eliminate a (the?) primary purpose of the api change! So, if you don?t want this, continue with ThreadLocal. >> >> That's a very interesting point. >> >> As a developer I shouldn't care whether ThreadLocal or ScopedVariable is being used. Let's say that I have an MVC application and would like to have better performance so I would just configure my framework (e.g. Spring Boot) to use Virtual Threads. Hopefully we are in agreement here that this is the intended use case of Virtual Threads - improve performance. Now, correct me if I'm wrong, but in order to maintain that performance gain behind the scenes Scoped Values would be used to retrieve the information about e.g. the current span (for tracing). As a user I don't care what is happening under the hood. From the point of view of the library creator I very much do. >> >> If the only purpose of Scoped Values is to allow a value to be there for the life of a runnable / callable then indeed this whole discussion is pointless. However we are already asked by our users whether we will support Scoped Values and I'm pretty sure that their assumption is that it will work in a transparent way (i.e. again they won't care about whether TL or SV are used under the hood - they want performance gains). >> >> Assumption that everyone has to do some migration to use this feature is acceptable, but still if only the scope would be returned by this API, no changes would be required. I think we constantly go in circles with this and I still do not understand why is it such a big problem (I understood the topic of security, but I'm personally not convinced that this is such a big deal; it's similar to a case if someone didn't close a stream or something like that. If they don't they will have problems too) >> >> > Still, if the tracing library code is properly structured I would doubt it would be more than a global search and replace in the library to switch from ThreadLocal to ScopedValues. You keep stating ?rewrite all of our code? without providing any evidence of why that would be the case. >> >> For Micrometer Observation I need to introduce new API that instead of allowing to create a Scope and close it I need to create new API that works more or less like FilterChain and Filters for HTTP (we have an analogous approach of ObservationHandlers that would need to work with HandlerChain). In the Micrometer repo only I need to do 60+ changes of the API usage. Of course I can't break compatibility so I need to leave the old API. Plus I need to add new ObservationHandler methods and not break compatibility. That's only for Micrometer Observation. I will need to have similar changes in Micrometer Tracing plus Brave and OpenTelemetry. Only after all of these projects are changed will we have to go to all the projects that actually use us to change their usage to the new one. >> >> I don't have to mention that for all of these changes we need to ensure that compatibility will not be broken and that things will work with and without Scoped Values. There also must be a TL and SV interop because not everyone will use SV only. For me it sounds like a lot of work. >> >> > It is highly doubtful any instrumented projects would need to change. I looked at how the tracing support is done with Spring and the proxies and that is certainly wouldn?t be required there. >> >> I'm sorry but in the vast majority of cases it was me doing or co-authoring the Spring instrumentation (plus dozens of other projects) and what you wrote is not entirely correct. Micrometer Observation API is being used to do the instrumentation. You can check an example here [1]. No proxies are being involved. >> >> > If you wanted no changes to instrumented projects whatsoever, you would need to use the ?check if ScopedValue context exists, if not use context from ThreadLocal? design as was suggested - which is meaningless overhead compared to the overhead of tracing itself. And if the instrumented project is being changed to use VirtualThreads it SHOULD be changed at the same time to update the tracing library setup code. >> >> So do I understand correctly that you should either use TL or SV ? No library will migrate directly to use only this or that. There must be some bridging or an option to use gradual migration. >> >> > I updated the my code to demonstrate the fallback to ThreadLocal when the top-level ScopedValue context is not available. >> > I also updated the code to work when the ScopedValue setup is not performed. I am pretty sure it works the way most tracing libraries are interfaced with. >> >> I looked at your sample and have a couple of comments: >> - You assume that you know what the entry port to your application is (a "request" comes in). You can't assume that in a production application. You might have an MVC app but maybe you have a command line application. We would have to try to guess all those entry points so that we wrap these calls in `where(...)` >> - Your approach is equivalent to creation of a TL entry that is mutable and all the scopes are put there inside that entry. I'm not saying this is wrong but tracing libraries do not work like this. Maybe they need to be rewritten completely to work like that? I will need to think about this but this would require major rewrite of Micrometer Tracing, Brave and Opentelemetry which I highly doubt would happen. >> - I understand that the SV will contain the TraceContext. The span from TraceContext can be shared between threads. How will you guard that span against concurrent writes? >> >> > I still think you are stuck and looking at the problem the wrong way. >> >> That is possible. The problem I have is that as I see it when SVs become GA, users will ask us, library creators to have tracing work with SV and it won't work out of the box unless we tell them to use TL. That might be the proper answer but I'm trying to find a solution that would be beneficial for the community. >> >> [1] - https://github.com/spring-projects/spring-framework/blob/v6.1.9/spring-web/src/main/java/org/springframework/web/filter/ServerHttpObservationFilter.java#L102-L128 >> >> Pozdrawiam / Best regards, >> Marcin Grzejszczak >> >> https://marcin.grzejszczak.pl >> https://toomuchcoding.com >> >> pon., 17 cze 2024 o 16:08 Robert Engels > napisa?(a): >> To be clear, I have no control whatsoever over what does or does not happen with Java. I am only stating my opinion - and trying to help! >> >>> From the beginning I want to implement everything using Scoped Values but I don't want to need to rewrite all my code. Neither as a library implementor nor in the instrumented projects. >> >> I do think it is strange that you want to take advantage of a new api, but you don?t want to do any work to do so??? This wouldn?t be an api change then, it would be a performance optimization behind the scenes. A primary purpose of the ScopedValue api addition is the automatic closing of the ScopeValue for better resource management in a VirtualThread system. Your requested changes eliminate a (the?) primary purpose of the api change! So, if you don?t want this, continue with ThreadLocal. >> >> Still, if the tracing library code is properly structured I would doubt it would be more than a global search and replace in the library to switch from ThreadLocal to ScopedValues. You keep stating ?rewrite all of our code? without providing any evidence of why that would be the case. >> >> It is highly doubtful any instrumented projects would need to change. I looked at how the tracing support is done with Spring and the proxies and that is certainly wouldn?t be required there. >> >> If you wanted no changes to instrumented projects whatsoever, you would need to use the ?check if ScopedValue context exists, if not use context from ThreadLocal? design as was suggested - which is meaningless overhead compared to the overhead of tracing itself. And if the instrumented project is being changed to use VirtualThreads it SHOULD be changed at the same time to update the tracing library setup code. >> >> I updated the my code to demonstrate the fallback to ThreadLocal when the top-level ScopedValue context is not available. >> >> I also updated the code to work when the ScopedValue setup is not performed. I am pretty sure it works the way most tracing libraries are interfaced with. >> >> I still think you are stuck and looking at the problem the wrong way. >> >> The code I shared emits all of the data to performed nested traces and analysis. >> >> event Event[start=1718639998618, end=1718639998807, description=close span handleRequest, span=SpanID 1985, tags [request 943],parent SpanId -1], duration 189ms >> event Event[start=1718639998709, end=1718639998709, description=open span callServer2, span=SpanID 6021, tags [],parent SpanId 1943], duration 0ms >> event Event[start=1718639998709, end=1718639998807, description=close span callServer2, span=SpanID 6021, tags [],parent SpanId 1943], duration 98ms >> event Event[start=1718639998807, end=1718639998807, description=open span making jdbc call, span=SpanID 7920, tags [jdbc],parent SpanId 1943], duration 0ms >> event Event[start=1718639998807, end=1718639998807, description=call jdbc, span=SpanID 7920, tags [jdbc],parent SpanId 1943], duration 0ms >> event Event[start=1718639998617, end=1718639998722, description=close span handleRequest, span=SpanID 1872, tags [request 885],parent SpanId -1], duration 105ms >> event Event[start=1718639998808, end=1718639998808, description=open span making jdbc call, span=SpanID 7921, tags [jdbc],parent SpanId 1715], duration 0ms >> event Event[start=1718639998808, end=1718639998808, description=call jdbc, span=SpanID 7921, tags [jdbc],parent SpanId 1715], duration 0ms >> event Event[start=1718639998808, end=1718639998808, description=close span making jdbc call, span=SpanID 7921, tags [jdbc],parent SpanId 1715], duration 0ms >> event Event[start=1718639998597, end=1718639998722, description=close span handleRequest, span=SpanID 71, tags [request 35],parent SpanId -1], duration 125ms >> >> >> >>> On Jun 17, 2024, at 10:19 AM, Marcin Grzejszczak > wrote: >>> >>> > Right, because we don?t want to use thread locals!!!. The code I posted supports nested spans. If you are using a ThreadLocal.CURRENT_TRACER - you only have a single value per thread - so either the spans are chained, or there is a stack. >>> >>> I never said that I want you to use thread locals!!! From the beginning I want to implement everything using Scoped Values but I don't want to need to rewrite all my code. Neither as a library implementor nor in the instrumented projects. >>> >>> > I guarantee I can implement a full tracing library without using ThreadLocal and have it support nested spans, etc. How can I guarantee this? Because, you can implement tracing by passing ?context? as a parameter to every method. If you read the ScopedValue documentation it states that the purpose of ScopedValue is to avoid needing to pass these method parameters. So given that, you can replace callMethod(context,parm1?) with callMethod(parm1,?). A tracing library is trivially implemented with a Context parameter. >>> >>> I fully believe you but I don't want to need to rewrite everything! >>> >>> > There is absolutely no need to add open/close semantics to ScopedValue to support tracing libraries. >>> >>> Maybe someone else can do better at explaining this, I give up. I understand that this CAN be done. I just doubt that forcing us to rewrite all of our code even in a trivial fashion is OK, but I understood the message. >>> >>> Pozdrawiam / Best regards, >>> Marcin Grzejszczak >>> >>> https://marcin.grzejszczak.pl >>> https://toomuchcoding.com >>> >>> pon., 17 cze 2024 o 15:14 Robert Engels > napisa?(a): >>> That is not correct. There is a ?trace context? per request at the top. The ?trace context? supports nested spans (which I call scopes). I have changed the name to Span to make this clearer, and I also added Span tag support. If the parentScopeId ==-1, then you are at the top-level (request). As an example: >>> >>> request 409, event Event[start=1718636994650, end=1718636994650, description=open span making jdbc call, spanId=3824, parentSpanId=-1], duration 0ms >>> request 409, event Event[start=1718636994650, end=1718636994650, description=call jdbc, spanId=3824, parentSpanId=825], duration 0ms >>> request 409, event Event[start=1718636994650, end=1718636994650, description=close span making jdbc call, spanId=3824, parentSpanId=825], duration 0ms >>> request 409, event Event[start=1718636994494, end=1718636994650, description=close span handleRequest, spanId=825, parentSpanId=-1], duration 156ms >>> request 148, event Event[start=1718636994487, end=1718636994598, description=close span handleRequest, spanId=299, parentSpanId=-1], duration 111ms >>> request 409, total duration 166ms >>> request 786, total duration 167ms >>> request 75, event Event[start=1718636994485, end=1718636994655, description=close span handleRequest, spanId=149, parentSpanId=-1], duration 170ms >>> request 148, total duration 119ms >>> request 452, total duration 171ms >>> request 75, total duration 177ms >>> request 496, event Event[start=1718636994602, end=1718636994602, description=call jdbc, spanId=3367, parentSpanId=1000], duration 0ms >>> request 496, event Event[start=1718636994602, end=1718636994602, description=close span making jdbc call, spanId=3367, parentSpanId=1000], duration 0ms >>> request 496, event Event[start=1718636994495, end=1718636994602, description=close span handleRequest, spanId=1000, parentSpanId=-1], duration 107ms >>> request 496, total duration 117ms >>> request 635, event Event[start=1718636994497, end=1718636994658, description=close span handleRequest, spanId=1301, parentSpanId=-1], duration 161ms >>> request 308, total duration 176ms >>> request 576, event Event[start=1718636994658, end=1718636994658, description=close span making jdbc call, spanId=3901, parentSpanId=1163], duration 0ms >>> request 635, total duration 171ms >>> request 576, event Event[start=1718636994497, end=1718636994658, description=close span handleRequest, spanId=1163, parentSpanId=-1], duration 161ms >>> request 267, event Event[start=1718636994658, end=1718636994658, description=call jdbc, spanId=3899, parentSpanId=538], duration 0ms >>> >>> >>>> Looking at the above what happens is that in pre, a new span is created and put in thread local. It is then closed in the post and removed from ThreadLocal. That's not what you're doing in beforeStatement and afterStatement in your example. >>> >>> Right, because we don?t want to use thread locals!!!. The code I posted supports nested spans. If you are using a ThreadLocal.CURRENT_TRACER - you only have a single value per thread - so either the spans are chained, or there is a stack. >>> >>> I guarantee I can implement a full tracing library without using ThreadLocal and have it support nested spans, etc. How can I guarantee this? Because, you can implement tracing by passing ?context? as a parameter to every method. If you read the ScopedValue documentation it states that the purpose of ScopedValue is to avoid needing to pass these method parameters. So given that, you can replace callMethod(context,parm1?) with callMethod(parm1,?). A tracing library is trivially implemented with a Context parameter. >>> >>> There is absolutely no need to add open/close semantics to ScopedValue to support tracing libraries. >>> >>> >>>> On Jun 17, 2024, at 9:43 AM, Marcin Grzejszczak > wrote: >>>> >>>> > I updated the github.com/robaho/scope_trace code to demonstrate before/after tracing using ScopedValues. There are no ThreadLocals in the code. It works fine. >>>> >>>> Thanks for doing this, I really appreciate it! >>>> >>>> You create a SV at the beginning when the "request" is received. Try to create a "span" with a new SV for the JDBC statement. With how JDBC is being instrumented you actually don't have a handle on when and how the JDBC code is called. You only have access to BEFORE and AFTER. So in the BEFORE you would create a new span, put it in scope so that e.g. MDC get enriched with tracing data so that you will have subsequent logs with span and trace ids and then in the afterStatement you would stop the scope, clear MDC and close that new span. >>>> >>>> I think that over the course of those 40 emails or so we're talking all the time about the same thing. You're trying to convince me that it's enough to create a SV at the beginning of code execution and wrap the actual execution in the runWhere which is not the case. When you do that you have in fact 1 span per request and then you just retrieve it in all your methods, there's no span nesting, no parent-child relationship. >>>> >>>> In a normal application you would have 1 span for getting the request, at least 1 span for the JDBC call and 1 for each of the http calls. In your case you have 1 span for all 4. >>>> >>>> > The problem with open/close semantics is that it is easy to close the scopes out of order - which corrupts the tracing information. >>>> >>>> Yes, I mentioned that a couple of times already. >>>> >>>> > Again referring to brave, look at https://github.com/openzipkin/brave/blob/69003dfc811418f0dbc42e9e17ff880ebe1f4b02/instrumentation/mysql/src/main/java/brave/mysql/TracingStatementInterceptor.java#L39 >>>> >>>> This line creates a new span, whose parent was the current one in ThreadLocal and it also puts the newly created span in ThreadLocal. That's because the ThreadLocalSpan is being used. You don't have to use that API, you could create a span and put it in scope, that way the information about the underlying ThreadLocal storage mechanism wouldn't leak. >>>> >>>> > This is an example of before/after tracing. It REQUIRES that the preStatement() and postStatment() will ALWAYS be executed in the correct sequence (with no intervening spans left open). >>>> >>>> Looking at the above what happens is that in pre, a new span is created and put in thread local. It is then closed in the post and removed from ThreadLocal. That's not what you're doing in beforeStatement and afterStatement in your example. >>>> >>>> > This code would need to changed regardless, most likely to something like Brave.currentTracer() which would be able to obtain the current tracer appropriately. I don?t see how adding open/close to ScopedValue values would alleviate this. >>>> >>>> Typically this information gets passed via a constructor. Most likely in this case some JDBC SPI is being called and that class is instantiated without any dependencies. >>>> >>>> > I am guessing most libraries have these hard-coded dependencies on ThreadLocal. >>>> >>>> They do not. They use abstractions with scopes. Micrometer Observation gets the current observation from an ObservationRegistry. Underneath the default implementation does look into TL but it could look into SV. >>>> >>>> > Thus, someone will write a VirtualThread/ScopedValue ?native? tracing library, and that will be what people use - or developers will need to modify their libraries to use ScopedValues in an APPROPRIATE manner. >>>> >>>> I'm trying to agree with you what APPROPRIATE means because I still don't understand because I think we're comparing apples to oranges at this point. >>>> >>>> > You seem to believe that a tracing library user will want to create a new span on every ScopedValue.runWhere() - I don?t think that is the case - as it will generate a lot of noise. >>>> >>>> I know a few things about tracing libraries and instrumenting projects because I've been doing it for a decade. I never said that you should create a span on every runWhere. Assuming that tracing libraries would be using SV then I can imagine that when a Span would be put in scope then if it's not there in scope already then runWhere should be run. >>>> >>>> Pozdrawiam / Best regards, >>>> Marcin Grzejszczak >>>> >>>> https://marcin.grzejszczak.pl >>>> https://toomuchcoding.com >>>> >>>> pon., 17 cze 2024 o 14:14 Robert Engels > napisa?(a): >>>> I updated the github.com/robaho/scope_trace code to demonstrate before/after tracing using ScopedValues. There are no ThreadLocals in the code. It works fine. >>>> >>>> The problem with open/close semantics is that it is easy to close the scopes out of order - which corrupts the tracing information. >>>> >>>> Again referring to brave, look at https://github.com/openzipkin/brave/blob/69003dfc811418f0dbc42e9e17ff880ebe1f4b02/instrumentation/mysql/src/main/java/brave/mysql/TracingStatementInterceptor.java#L39 >>>> >>>> This is an example of before/after tracing. It REQUIRES that the preStatement() and postStatment() will ALWAYS be executed in the correct sequence (with no intervening spans left open). >>>> >>>> Notice also >>>> >>>> Span span = ThreadLocalSpan.CURRENT_TRACER.next(); >>>> >>>> This code would need to changed regardless, most likely to something like Brave.currentTracer() which would be able to obtain the current tracer appropriately. I don?t see how adding open/close to ScopedValue values would alleviate this. >>>> >>>> I am guessing most libraries have these hard-coded dependencies on ThreadLocal. >>>> >>>> Thus, someone will write a VirtualThread/ScopedValue ?native? tracing library, and that will be what people use - or developers will need to modify their libraries to use ScopedValues in an APPROPRIATE manner. You seem to believe that a tracing library user will want to create a new span on every ScopedValue.runWhere() - I don?t think that is the case - as it will generate a lot of noise. >>>> >>>> ?scope values? are not only for tracing scopes. >>>> >>>> >>>>> On Jun 17, 2024, at 7:01 AM, robert engels > wrote: >>>>> >>>>> Your statements like ?a user puts a scope in a SV won?t be honored?. Of course not. I think you are trying to conflate scoped values with tracing scopes. They are not the same thing and can?t be treated as such due to the volume. >>>>> >>>>> The user will manage scopes for tracing the way they do now. It is an implementation detail on how the tracing library manages these scopes. They currently use thread locals. As I?ve pointed out several times the library can use a scoped value to carry the scope context - and mange the active scopes within in >>>>> >>>>> You are trying to make the scoped values be able to support tracing directly. I don?t believe that was ever a design goal. >>>>> >>>>>> On Jun 17, 2024, at 5:59?AM, Marcin Grzejszczak > wrote: >>>>>> >>>>>> ? >>>>>> > Definitely, yes. If you need to create a context for every virtual thread, scoped values versus thread-local variables is the least of your problems. >>>>>> >>>>>> Can you elaborate please? >>>>>> >>>>>> Pozdrawiam / Best regards, >>>>>> Marcin Grzejszczak >>>>>> >>>>>> https://marcin.grzejszczak.pl >>>>>> https://toomuchcoding.com >>>>>> >>>>>> czw., 13 cze 2024 o 19:23 Andrew Haley > napisa?(a): >>>>>> On 6/13/24 16:03, Robert Engels wrote: >>>>>> > 3. More importantly, if you use VT effectively, you are talking about >>>>>> > orders of magnitude more ?trace contexts? (in the default brave handler >>>>>> > they are shared by thread so they are highly limited since the only >>>>>> > effective Java threading implementation prior to VT required pooled >>>>>> > threads) which reinforces my point about the increase in the volume of >>>>>> > unique data is the major problem for existing tracing libraries, which >>>>>> > will probably require architectural changes anyway. >>>>>> >>>>>> Definitely, yes. If you need to create a context for every virtual thread, >>>>>> scoped values versus thread-local variables is the least of your problems. >>>>>> >>>>>> -- >>>>>> Andrew Haley (he/him) >>>>>> Java Platform Lead Engineer >>>>>> Red Hat UK Ltd. > >>>>>> https://keybase.io/andrewhaley >>>>>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 >>>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yuval.l at securithings.com Fri Jun 21 07:21:44 2024 From: yuval.l at securithings.com (Yuval Lombard) Date: Fri, 21 Jun 2024 10:21:44 +0300 Subject: Changes to Obect monitors Message-ID: Hey team, You have probably been asked about this a lot already, so I am sorry if I raise it again. Will the fixes to the Object monitor be released in first jdk23 release? and if not what is your estimation for it? Thanks, Yuval -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph-open at littlepinkcloud.com Fri Jun 21 07:57:53 2024 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Fri, 21 Jun 2024 08:57:53 +0100 Subject: ScopedValue.runWhere not returning scope In-Reply-To: References: <63FFA410-CC1A-43F7-99FB-97A17F730C5B@icloud.com> Message-ID: On 6/20/24 13:42, Marcin Grzejszczak wrote: > > I still would like to get the answer from the JDK maintainers if my arguments (which I think I presented a lot) would allow it to consider opening the API to the idea of giving the library maintainers more control. Who did you think you'd been talking to? On 6/20/24 14:57, Robert Engels wrote: > > If there is any performance gain, it is due to the property of them being immutable and shared - something your api changes are trying to discard Yes. This. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From alan.bateman at oracle.com Fri Jun 21 08:09:33 2024 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 21 Jun 2024 09:09:33 +0100 Subject: Changes to Obect monitors In-Reply-To: References: Message-ID: <4a27fcfe-5dea-4401-9f1c-bb35dbd4a70c@oracle.com> On 21/06/2024 08:21, Yuval Lombard wrote: > Hey team, > > You have probably been asked about this a lot already, so I am sorry > if I raise it again. > > Will the fixes to the Object monitor be released in first jdk23 > release? and if not what is your estimation for it? > JDK 23 is already in ramp down so not JDK 23. There is more work required on performance and a few other issues but I think looking quite good for soon after JDK 23. We hope to get more people testing the EA builds as the changes are significant. -Alan From marcin.grzejszczak at gmail.com Fri Jun 21 08:11:39 2024 From: marcin.grzejszczak at gmail.com (Marcin Grzejszczak) Date: Fri, 21 Jun 2024 10:11:39 +0200 Subject: ScopedValue.runWhere not returning scope In-Reply-To: References: <63FFA410-CC1A-43F7-99FB-97A17F730C5B@icloud.com> Message-ID: > Who did you think you'd been talking to? I'm sorry, but you don't have to be unpleasant. I thought that this mailing list should be used for exactly the reason related to giving feedback on preview features such as scoped values. I understand that this thread is extremely long but the problem is complex in my opinion. If you're unwilling to continue this discussion of get feedback about the features you're working on then just say so. Afair some people in this thread stated that they are not working on the JDK. Some, like you, if I'm not mistaken, have not addressed most of my arguments. I've only heard that for security reasons (scopes could be opened and closed out of order) and immutability (I don't understand how the api changes would modify that. It simply allows me to have more control. What currently is called in the lambda would be manually called by me. There are no changes here unless I'm mistaken) you are reluctant to consider my feedback. You have all right to do that, I don't have a problem with that, but I'd just prefer to have a final, definite answer so that I can plan changes in tracing libraries accordingly. Pozdrawiam / Best regards, Marcin Grzejszczak https://marcin.grzejszczak.pl https://toomuchcoding.com On Fri, 21 Jun 2024 at 09:57, Andrew Haley wrote: > On 6/20/24 13:42, Marcin Grzejszczak wrote: > > > > I still would like to get the answer from the JDK maintainers if my > arguments (which I think I presented a lot) would allow it to consider > opening the API to the idea of giving the library maintainers more control. > > Who did you think you'd been talking to? > > On 6/20/24 14:57, Robert Engels wrote: > > > > If there is any performance gain, it is due to the property of them > being immutable and shared - something your api changes are trying to > discard > > Yes. This. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hepin.p at alibaba-inc.com Fri Jun 21 11:33:47 2024 From: hepin.p at alibaba-inc.com (=?UTF-8?B?5L2V5ZOBKOiZjum4oyk=?=) Date: Fri, 21 Jun 2024 19:33:47 +0800 Subject: =?UTF-8?B?5Zue5aSN77ya5Zue5aSN77yaVmlydHVhbCB0aHJlYWQgaGFuZyBhbmQgYWxsIHRocmVhZHMg?= =?UTF-8?B?c3RvcCBydW5uaW5nIG9uIEpESzIx?= In-Reply-To: <3a11a569-a904-4e93-bf95-7cbc58816a1f.hepin.p@alibaba-inc.com> References: <3a11a569-a904-4e93-bf95-7cbc58816a1f.hepin.p@alibaba-inc.com> Message-ID: <09abc3e4-6f09-4f22-95a6-88eda34a229a.hepin.p@alibaba-inc.com> hi team, we have found the root cause. the root cause is because the class loading of in both Netty's EventLoop and our taskRunner (virtualthread), and the threads are blocked when there are many virtual threads. A fix of limit the number of virtualthreads and increase the parallisim > max virtual threads fix the problem. We successfully dump the jcmd when switch to openjdk, and thanks for the help. ------------------------------------------------------------------ ??????(??) ?????2024?6?5?(???) 18:18 ????Alan Bateman; "??(??)"; "loom-dev" ??????????Virtual thread hang and all threads stop running on JDK21 Yes, even jcmd is hung, we are currently want to switch back to the forkJoinPool and increase the jdk.virtualThreadScheduler.maxPoolSize and jdk.virtualThreadScheduler.parallelism > our total max concurrency. I have several system is using Virtual thread, but only this one cause problem. ------------------------------------------------------------------ ????Alan Bateman ?????2024?6?5?(???) 18:00 ????"??(??)"; "loom-dev" ????Re: ???Virtual thread hang and all threads stop running on JDK21 On 05/06/2024 10:37, ??(??) wrote: Thanks, 1. it hung when we are sharing the common usage of the Virtualthread (the default scheduler) cross two modules. 2. after that, I try to hack the virtual thread builder with separated ThreadPoolExecutor. 3. but still , it hung. when it hung, `jcmd Thread.print` prints nothing. and dump programly print nothing too. After switch back to normal thread, it never hang. Some information: module A is using `Object.notifyAll, Object.wait` and module B is using `CompletableFuture.get` (may > 100 times in one rune) I was thinking if that could be a problem of notification missing, where in Module A, the concurrency is 3000? protected by a semaphore, but the underling Carrier Thread is only 128, and 3000 > 128. If it's using synchronized/Object.wait then this may be related to pinning. When there is both object monitors and j.u.concurrent locks in play then it's possible to create deadlock scenarios due to starvation, or selecting a successor or thread to wakeup and the thread can't continue because there are no carriers available. Object.wait will temporarily increase parallelism to smooth and help some cases but it may not help you here, and does nothing when the scheduler has been changed to be something other than a ForkJoinPool instance. When you say "prints nothing" then you mean this literally or do you mean that jcmd is hung too? If so that's a hint that may be the lock for standard output is held by a virtual thread that can't continue because there are no carriers available. It would be interesting to try the latest Loom EA builds which has changes to the object monitor implementation that doesn't pin. Would you have time to try these builds out? -Alan [1] https://jdk.java.net/loom/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hepin.p at alibaba-inc.com Fri Jun 21 11:46:39 2024 From: hepin.p at alibaba-inc.com (=?UTF-8?B?5L2V5ZOBKOiZjum4oyk=?=) Date: Fri, 21 Jun 2024 19:46:39 +0800 Subject: =?UTF-8?B?Q2FuIHZpcnR1YWwgdGhyZWFkIGdldCBiZXR0ZXIgc3VwcG9ydCBmb3IgTWFwL1JlZHVjZSBs?= =?UTF-8?B?aWtlIHRoaW5nPw==?= Message-ID: The current implementation always adds the task to the tail, but what if a map/reduce like work, which mean a fork() maybe better for performance/latency , but that will reduce some fairness. -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Fri Jun 21 12:47:51 2024 From: duke at openjdk.org (duke) Date: Fri, 21 Jun 2024 12:47:51 GMT Subject: git: openjdk/loom: fibers: 15 new changesets Message-ID: Changeset: 504b4d93 Author: Alan Bateman Date: 2024-06-20 09:29:08 +0000 URL: https://git.openjdk.org/loom/commit/504b4d9360fd0215f534d57e476aaa321c37d47d GetObjectMonitorUsage can run again ! test/hotspot/jtreg/ProblemList-Virtual.txt Changeset: 86161ebc Author: Alan Bateman Date: 2024-06-20 17:50:40 +0000 URL: https://git.openjdk.org/loom/commit/86161ebcb03da15c94508484888295b56d94535a Exclude TestMixedGCLiveThreshold.java on Windows with jtreg wrapper ! test/hotspot/jtreg/ProblemList-Virtual.txt Changeset: 78682fe7 Author: Magnus Ihse Bursie Date: 2024-06-19 19:12:31 +0000 URL: https://git.openjdk.org/loom/commit/78682fe78e18268b1857855c3595b4d118808c66 8329288: Update Visual Studio visibility support for POSIX functions Reviewed-by: kbarrett ! make/autoconf/flags-cflags.m4 Changeset: 4e58d8c8 Author: Joe Darcy Date: 2024-06-19 23:23:52 +0000 URL: https://git.openjdk.org/loom/commit/4e58d8c897d845cfa73780264481da174d46acb4 8309821: Link to hidden classes section in Class specification for Class::isHidden Reviewed-by: iris, rriggs ! src/java.base/share/classes/java/lang/Class.java Changeset: b211929e Author: Sonia Zaldana Calles Committer: David Holmes Date: 2024-06-20 01:36:05 +0000 URL: https://git.openjdk.org/loom/commit/b211929e05c0acdf7343c3edd025749d573c67b3 8334570: Problem list gc/TestAlwaysPreTouchBehavior.java Reviewed-by: ayang, tschatzl ! test/hotspot/jtreg/ProblemList.txt Changeset: fad6644e Author: Sibabrata Sahoo Date: 2024-06-20 04:18:39 +0000 URL: https://git.openjdk.org/loom/commit/fad6644eabbad6b6d3472206d9db946408aca612 8333754: Add a Test against ECDSA and ECDH NIST Test vector Reviewed-by: ascarpino + test/jdk/sun/security/ec/ECDHPrimitive.java + test/jdk/sun/security/ec/ECDSAPrimitive.java + test/jdk/sun/security/ec/KAS_ECC_CDH_PrimitiveTest.txt + test/jdk/sun/security/ec/SigGen-1.txt Changeset: 2d4185f4 Author: Erik ?sterlund Date: 2024-06-20 05:23:08 +0000 URL: https://git.openjdk.org/loom/commit/2d4185f4f1def7c32d1a556521e26ec656234220 8332717: ZGC: Division by zero in heuristics Reviewed-by: aboldtch, shade ! src/hotspot/share/gc/z/zDirector.cpp Changeset: ff302409 Author: Matthias Baesken Date: 2024-06-20 06:15:19 +0000 URL: https://git.openjdk.org/loom/commit/ff30240926224b2f98e173bcd606c157af788919 8334239: Introduce macro for ubsan method/function exclusions Reviewed-by: stefank, stuefe, kbarrett ! src/hotspot/share/cds/archiveHeapLoader.cpp ! src/hotspot/share/prims/unsafe.cpp + src/hotspot/share/sanitizers/ub.hpp ! src/hotspot/share/utilities/vmError.cpp Changeset: d7dad50a Author: Roland Westrelin Date: 2024-06-20 07:14:01 +0000 URL: https://git.openjdk.org/loom/commit/d7dad50af5df356089101ca440fca5232fadb81e 8334544: C2: wrong control assigned in PhaseIdealLoop::clone_assertion_predicate_for_unswitched_loops() Reviewed-by: chagedorn, thartmann ! src/hotspot/share/opto/loopPredicate.cpp Changeset: cabd1046 Author: Sonia Zaldana Calles Committer: Severin Gehwolf Date: 2024-06-20 08:28:06 +0000 URL: https://git.openjdk.org/loom/commit/cabd1046d08865f122663d18708d40e5c885c1c3 8334164: The fix for JDK-8322811 should use _filename.is_set() rather than strcmp() Reviewed-by: dholmes, cjplummer ! src/hotspot/share/services/diagnosticCommand.cpp Changeset: c6f3bf4b Author: Thomas Stuefe Date: 2024-06-20 08:30:52 +0000 URL: https://git.openjdk.org/loom/commit/c6f3bf4bd61405c2ed374b15ef82cc987f52cd52 8334026: Provide a diagnostic PrintMemoryMapAtExit switch on Linux Reviewed-by: dholmes, mbaesken ! src/hotspot/os/linux/globals_linux.hpp ! src/hotspot/share/nmt/memMapPrinter.cpp ! src/hotspot/share/runtime/java.cpp + test/hotspot/jtreg/runtime/NMT/PrintMemoryMapAtExitTest.java Changeset: 3b820641 Author: Alan Bateman Date: 2024-06-21 07:29:17 +0000 URL: https://git.openjdk.org/loom/commit/3b820641832324135e65a5d38d8d4aac549a7747 Merge ! src/hotspot/share/services/diagnosticCommand.cpp ! test/hotspot/jtreg/ProblemList.txt ! src/hotspot/share/services/diagnosticCommand.cpp ! test/hotspot/jtreg/ProblemList.txt Changeset: e7ed0ba4 Author: Alan Bateman Date: 2024-06-21 11:22:34 +0000 URL: https://git.openjdk.org/loom/commit/e7ed0ba4d74c2a9bdf0cccb246112641752eda7e Rename to jcmd Thread.vthread_summary, expand test ! src/hotspot/share/classfile/vmSymbols.hpp ! src/hotspot/share/services/diagnosticCommand.cpp ! src/hotspot/share/services/diagnosticCommand.hpp ! 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/jdk/internal/vm/VMSupport.java + src/java.base/share/classes/jdk/internal/vm/VThreadSummary.java ! src/java.base/share/classes/sun/nio/ch/Poller.java - src/java.base/share/classes/sun/nio/ch/PollerInfo.java - test/hotspot/jtreg/serviceability/dcmd/thread/VThreadInfoTest.java + test/hotspot/jtreg/serviceability/dcmd/thread/VThreadSummaryTest.java Changeset: 0c085c7f Author: Alan Bateman Date: 2024-06-21 12:21:33 +0000 URL: https://git.openjdk.org/loom/commit/0c085c7f21214a7c40e659fa0e3044387b422f71 Fix exclude of gc//g1/TestMixedGCLiveThreshold.java#25percent ! test/hotspot/jtreg/ProblemList-Virtual.txt Changeset: b1a4b39e Author: Alan Bateman Date: 2024-06-21 13:36:49 +0000 URL: https://git.openjdk.org/loom/commit/b1a4b39e0a89933bd674c8a16f290740c08e2a6d Exclude serviceability/sa/TestJmapCore.java on macosx-aarch64 to reduce noise ! test/hotspot/jtreg/ProblemList.txt From duke at openjdk.org Fri Jun 21 12:48:21 2024 From: duke at openjdk.org (duke) Date: Fri, 21 Jun 2024 12:48:21 GMT Subject: git: openjdk/loom: master: 9 new changesets Message-ID: <06c49286-7daa-4b9e-ba7c-70ab9f49b47f@openjdk.org> Changeset: 78682fe7 Author: Magnus Ihse Bursie Date: 2024-06-19 19:12:31 +0000 URL: https://git.openjdk.org/loom/commit/78682fe78e18268b1857855c3595b4d118808c66 8329288: Update Visual Studio visibility support for POSIX functions Reviewed-by: kbarrett ! make/autoconf/flags-cflags.m4 Changeset: 4e58d8c8 Author: Joe Darcy Date: 2024-06-19 23:23:52 +0000 URL: https://git.openjdk.org/loom/commit/4e58d8c897d845cfa73780264481da174d46acb4 8309821: Link to hidden classes section in Class specification for Class::isHidden Reviewed-by: iris, rriggs ! src/java.base/share/classes/java/lang/Class.java Changeset: b211929e Author: Sonia Zaldana Calles Committer: David Holmes Date: 2024-06-20 01:36:05 +0000 URL: https://git.openjdk.org/loom/commit/b211929e05c0acdf7343c3edd025749d573c67b3 8334570: Problem list gc/TestAlwaysPreTouchBehavior.java Reviewed-by: ayang, tschatzl ! test/hotspot/jtreg/ProblemList.txt Changeset: fad6644e Author: Sibabrata Sahoo Date: 2024-06-20 04:18:39 +0000 URL: https://git.openjdk.org/loom/commit/fad6644eabbad6b6d3472206d9db946408aca612 8333754: Add a Test against ECDSA and ECDH NIST Test vector Reviewed-by: ascarpino + test/jdk/sun/security/ec/ECDHPrimitive.java + test/jdk/sun/security/ec/ECDSAPrimitive.java + test/jdk/sun/security/ec/KAS_ECC_CDH_PrimitiveTest.txt + test/jdk/sun/security/ec/SigGen-1.txt Changeset: 2d4185f4 Author: Erik ?sterlund Date: 2024-06-20 05:23:08 +0000 URL: https://git.openjdk.org/loom/commit/2d4185f4f1def7c32d1a556521e26ec656234220 8332717: ZGC: Division by zero in heuristics Reviewed-by: aboldtch, shade ! src/hotspot/share/gc/z/zDirector.cpp Changeset: ff302409 Author: Matthias Baesken Date: 2024-06-20 06:15:19 +0000 URL: https://git.openjdk.org/loom/commit/ff30240926224b2f98e173bcd606c157af788919 8334239: Introduce macro for ubsan method/function exclusions Reviewed-by: stefank, stuefe, kbarrett ! src/hotspot/share/cds/archiveHeapLoader.cpp ! src/hotspot/share/prims/unsafe.cpp + src/hotspot/share/sanitizers/ub.hpp ! src/hotspot/share/utilities/vmError.cpp Changeset: d7dad50a Author: Roland Westrelin Date: 2024-06-20 07:14:01 +0000 URL: https://git.openjdk.org/loom/commit/d7dad50af5df356089101ca440fca5232fadb81e 8334544: C2: wrong control assigned in PhaseIdealLoop::clone_assertion_predicate_for_unswitched_loops() Reviewed-by: chagedorn, thartmann ! src/hotspot/share/opto/loopPredicate.cpp Changeset: cabd1046 Author: Sonia Zaldana Calles Committer: Severin Gehwolf Date: 2024-06-20 08:28:06 +0000 URL: https://git.openjdk.org/loom/commit/cabd1046d08865f122663d18708d40e5c885c1c3 8334164: The fix for JDK-8322811 should use _filename.is_set() rather than strcmp() Reviewed-by: dholmes, cjplummer ! src/hotspot/share/services/diagnosticCommand.cpp Changeset: c6f3bf4b Author: Thomas Stuefe Date: 2024-06-20 08:30:52 +0000 URL: https://git.openjdk.org/loom/commit/c6f3bf4bd61405c2ed374b15ef82cc987f52cd52 8334026: Provide a diagnostic PrintMemoryMapAtExit switch on Linux Reviewed-by: dholmes, mbaesken ! src/hotspot/os/linux/globals_linux.hpp ! src/hotspot/share/nmt/memMapPrinter.cpp ! src/hotspot/share/runtime/java.cpp + test/hotspot/jtreg/runtime/NMT/PrintMemoryMapAtExitTest.java From aph-open at littlepinkcloud.com Fri Jun 21 12:51:07 2024 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Fri, 21 Jun 2024 13:51:07 +0100 Subject: ScopedValue.runWhere not returning scope In-Reply-To: References: <63FFA410-CC1A-43F7-99FB-97A17F730C5B@icloud.com> Message-ID: On 6/21/24 09:11, Marcin Grzejszczak wrote: > > Who did you think you'd been talking to? > > I'm sorry, but you don't have to be unpleasant. I thought it was a fair question. > I thought that this mailing list should be used for exactly the > reason related to giving feedback on preview features such as scoped > values. I understand that this thread is extremely long but the > problem is complex in my opinion. If you're unwilling to continue > this discussion of get feedback about the features you're working on > then just say so. It is. What you're hearing here is disagreement. That is the exact opposite of unwillingness to have a discussion. It is participation. > Afair some people in this thread stated that they are not working on > the JDK. Some, like you, if I'm not mistaken, have not addressed > most of my arguments. You are mistaken. I believe I've addressed them. > I've only heard that for security reasons (scopes could be opened > and closed out of order) Yes. That is very important. > and immutability (I don't understand how the api changes would > modify that. If you can set a value, then call a method that sets a new binding for that value, and that value is different after the method returns, then the value has changed. You've lost immutability. > It simply allows me to have more control. The purpose of (shallow) immutability and one-way transmission of data from caller to callee is to *restrict* and limit control. Just as the purpose of structured programming is to restrict the generality of goto statements in order to make programs easier to reason about. > What currently is called in the lambda would be manually called by > me. There are no changes here unless I'm mistaken) you are reluctant > to consider my feedback. Of course I've considered it. Not only have I considered it, I have responded here, at length. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From marcin.grzejszczak at gmail.com Fri Jun 21 13:02:32 2024 From: marcin.grzejszczak at gmail.com (Marcin Grzejszczak) Date: Fri, 21 Jun 2024 15:02:32 +0200 Subject: ScopedValue.runWhere not returning scope In-Reply-To: References: <63FFA410-CC1A-43F7-99FB-97A17F730C5B@icloud.com> Message-ID: Thank you for the response. >From my perspective we can consider this thread closed. Pozdrawiam / Best regards, Marcin Grzejszczak https://marcin.grzejszczak.pl https://toomuchcoding.com On Fri, 21 Jun 2024 at 14:51, Andrew Haley wrote: > On 6/21/24 09:11, Marcin Grzejszczak wrote: > > > Who did you think you'd been talking to? > > > > I'm sorry, but you don't have to be unpleasant. > > I thought it was a fair question. > > > I thought that this mailing list should be used for exactly the > > reason related to giving feedback on preview features such as scoped > > values. I understand that this thread is extremely long but the > > problem is complex in my opinion. If you're unwilling to continue > > this discussion of get feedback about the features you're working on > > then just say so. > > It is. What you're hearing here is disagreement. That is the exact > opposite of unwillingness to have a discussion. It is participation. > > > Afair some people in this thread stated that they are not working on > > the JDK. Some, like you, if I'm not mistaken, have not addressed > > most of my arguments. > > You are mistaken. I believe I've addressed them. > > > I've only heard that for security reasons (scopes could be opened > > and closed out of order) > > Yes. That is very important. > > > and immutability (I don't understand how the api changes would > > modify that. > > If you can set a value, then call a method that sets a new binding for > that value, and that value is different after the method returns, then > the value has changed. You've lost immutability. > > > It simply allows me to have more control. > > The purpose of (shallow) immutability and one-way transmission of data > from caller to callee is to *restrict* and limit control. Just as the > purpose of structured programming is to restrict the generality of > goto statements in order to make programs easier to reason about. > > > What currently is called in the lambda would be manually called by > > me. There are no changes here unless I'm mistaken) you are reluctant > > to consider my feedback. > > Of course I've considered it. Not only have I considered it, I have > responded here, at length. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Jun 21 14:30:35 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 21 Jun 2024 15:30:35 +0100 Subject: Can virtual thread get better support for Map/Reduce like thing? In-Reply-To: References: Message-ID: <26b2a310-91db-473a-a476-422500a4b7ab@oracle.com> On 21/06/2024 12:46, ??(??) wrote: > The current implementation always adds the task to the tail, but what > if a map/reduce like work, which mean a fork() maybe better for > performance/latency , but that will reduce some fairness. If you are building the JDK yourself then you should be try it out. It would be interesting to share your results. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.swift at gmail.com Fri Jun 21 15:57:47 2024 From: matthew.swift at gmail.com (Matthew Swift) Date: Fri, 21 Jun 2024 17:57:47 +0200 Subject: Experience of adding JDK21 virtual thread support to a DB application Message-ID: Hello, This email is the first of a couple of emails that I'll send sharing our experiences of adding support for virtual threads in a high-performance distributed database. It gives some background, as well as focusing on the migration challenges, rather than the actual usage of virtual threads. The second email will focus on our experience when using virtual threads and, in particular, the recent JDK23 Loom EA build ( https://mail.openjdk.org/pipermail/loom-dev/2024-May/006632.html). The third email focuses on a couple of enhancement requests, although some have already been discussed before on this list. Before continuing, I'd like to say a big thank you to those of you who are working on the virtual thread support in Java. My colleagues and I feel that it is an absolute *game-changer* for writing complex scalable applications. Well done! Summary of application architecture =================================== * distributed high-scale Directory Service exposing LDAP and REST frontends for accessing 100s of millions of identities with sub-millisecond response times * NIO2 based network IO layer, including dedicated IO threads using AsynchronousChannelGroup * IO threads hand-off requests for processing to an executor service, originally implemented using fixed-sized ThreadPoolExecutor * requests are processed synchronously by the executor. Most query and/or update an embedded key-value DB (Oracle Berkeley DB Java Edition), but in some cases may call out to external services when proxying * extensive use of RxJava throughout, mostly due to the need to implement end-to-end backpressure when acting as a proxy. Motivation to use virtual threads ================================= * all the reasons cited in JEP 444! :-) Although RxJava is an amazing asynchronous library, it still suffers from the problems associated with asynchronous programming, such as steep learning curve and difficulties diagnosing problems * hard to tune for heterogeneous types of load. CPU intensive requests (e.g. reads) prefer small numbers of threads, otherwise throughput degrades significantly due to excessive context switching. IO intensive requests (e.g. writes) prefer more threads in order to maximize resource utilization * requirement to implement features that artificially delay requests, such as rate limiting. It would be so much easier if we could just use Semaphores and other blocking primitives. How did the migration go? ========================= * good so far :-) * we can now use virtual threads for core processing with JDK>=21 when a run-time feature flag is enabled (still uses ThreadPoolExecutor otherwise) * network listeners are still NIO2 + RxJava: will be migrated next to use blocking IO (incl. SSL), followed by removal of RxJava * as predicted, we initially encountered thread-pinning and deadlocks due to synchronization, as well as significant numbers of carrier threads due to use of Object.wait(). File IO was guarded by locking at a higher level, so I don't think it was directly causing expansion of the carrier thread pool * migration was particularly problematic in our third-party embedded key-value DB, which was using synchronization and Object.wait() extensively as part of its locking design. We were forced to fork the library in order to make the necessary changes. This was pretty straightforward though. ReentrantLock vs synchronized ============================= When NOT using virtual threads we have noticed a ~8% throughput reduction in one of our multi-index write stress tests which appears to be due to contention on a single critical section responsible for serializing access to the embedded DB's transaction log. Profiling shows this critical section is being entered approximately 500K/s across 16 threads. When the critical section is protected with synchronized() I get the following results once warmed up: ------------------------------------------------------------------------------- | Throughput | Response Time | | | (ops/second) | (milliseconds) | | | recent average | recent average 99.9% 99.99% 99.999% | err/sec | ------------------------------------------------------------------------------- ... | 9002.6 9002.8 | 4.433 4.432 40.63 94.37 114.29 | 0.0 | | 9132.8 9014.6 | 4.370 4.426 40.37 87.56 114.29 | 0.0 | Yet when the synchronized block is replaced with a ReentrantLock: ------------------------------------------------------------------------------- | Throughput | Response Time | | | (ops/second) | (milliseconds) | | | recent average | recent average 99.9% 99.99% 99.999% | err/sec | ------------------------------------------------------------------------------- ... | 8431.2 8378.4 | 4.733 4.763 51.12 114.82 122.16 | 0.0 | | 8200.4 8342.8 | 4.866 4.784 46.66 114.29 122.16 | 0.0 | These results are on my laptop (Intel i9-13900H with 10 cores, Linux 6.5, JDK 21.0.3), but we see similar regressions on larger older machines in our labs. Also worthy of note is that the context switching rate increases from around 180K/s when using synchronized() to 300K/s when using ReentrantLock. I know that ReentrantLock is supposed to be a little bit less efficient in highly contended situations, but I was surprised by an 8-10% impact. Is that expected? Analyzing contention using JFR.view =================================== On a related note, I attempted to use the new JFR.view command to analyze the lock contention in both situations: jcmd JFR.view contention-by-site verbose=true Sadly, it only analyzes JavaMonitorEnter JFR events and completely ignores Thread park events, so I was unable to analyze contention due to ReentrantLock using this tool. Here's the query JFR.view uses: COLUMN 'StackTrace', 'Count', 'Avg.', 'Max.' SELECT stackTrace AS S, COUNT(*), AVERAGE(duration), MAXIMUM(duration) AS M FROM JavaMonitorEnter GROUP BY S ORDER BY M Do you think this is a bug/RFE? If so, what's the best way to proceed in your opinion? It would be great if tools like JFR.view had better support for j.u.c primitives given that virtual threads will encourage increased usage of them. Kind regards, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From rengels at ix.netcom.com Fri Jun 21 16:51:19 2024 From: rengels at ix.netcom.com (robert engels) Date: Fri, 21 Jun 2024 11:51:19 -0500 Subject: Experience of adding JDK21 virtual thread support to a DB application In-Reply-To: References: Message-ID: I agree that I don?t think JFR is intelligent about the locks. Maybe create your own sub-class of ReentrentLock and emit custom JFR events? Otherwise there appears to be too much noise with the Fork-Join pool. > On Jun 21, 2024, at 10:57 AM, Matthew Swift wrote: > > Hello, > > This email is the first of a couple of emails that I'll send sharing our experiences of adding support for virtual threads in a high-performance distributed database. It gives some background, as well as focusing on the migration challenges, rather than the actual usage of virtual threads. The second email will focus on our experience when using virtual threads and, in particular, the recent JDK23 Loom EA build (https://mail.openjdk.org/pipermail/loom-dev/2024-May/006632.html ). The third email focuses on a couple of enhancement requests, although some have already been discussed before on this list. > > Before continuing, I'd like to say a big thank you to those of you who are working on the virtual thread support in Java. My colleagues and I feel that it is an absolute *game-changer* for writing complex scalable applications. Well done! > > Summary of application architecture > =================================== > > * distributed high-scale Directory Service exposing LDAP and REST frontends for accessing 100s of millions of identities with sub-millisecond response times > * NIO2 based network IO layer, including dedicated IO threads using AsynchronousChannelGroup > * IO threads hand-off requests for processing to an executor service, originally implemented using fixed-sized ThreadPoolExecutor > * requests are processed synchronously by the executor. Most query and/or update an embedded key-value DB (Oracle Berkeley DB Java Edition), but in some cases may call out to external services when proxying > * extensive use of RxJava throughout, mostly due to the need to implement end-to-end backpressure when acting as a proxy. > > Motivation to use virtual threads > ================================= > > * all the reasons cited in JEP 444! :-) Although RxJava is an amazing asynchronous library, it still suffers from the problems associated with asynchronous programming, such as steep learning curve and difficulties diagnosing problems > * hard to tune for heterogeneous types of load. CPU intensive requests (e.g. reads) prefer small numbers of threads, otherwise throughput degrades significantly due to excessive context switching. IO intensive requests (e.g. writes) prefer more threads in order to maximize resource utilization > * requirement to implement features that artificially delay requests, such as rate limiting. It would be so much easier if we could just use Semaphores and other blocking primitives. > > How did the migration go? > ========================= > > * good so far :-) > * we can now use virtual threads for core processing with JDK>=21 when a run-time feature flag is enabled (still uses ThreadPoolExecutor otherwise) > * network listeners are still NIO2 + RxJava: will be migrated next to use blocking IO (incl. SSL), followed by removal of RxJava > * as predicted, we initially encountered thread-pinning and deadlocks due to synchronization, as well as significant numbers of carrier threads due to use of Object.wait(). File IO was guarded by locking at a higher level, so I don't think it was directly causing expansion of the carrier thread pool > * migration was particularly problematic in our third-party embedded key-value DB, which was using synchronization and Object.wait() extensively as part of its locking design. We were forced to fork the library in order to make the necessary changes. This was pretty straightforward though. > > ReentrantLock vs synchronized > ============================= > > When NOT using virtual threads we have noticed a ~8% throughput reduction in one of our multi-index write stress tests which appears to be due to contention on a single critical section responsible for serializing access to the embedded DB's transaction log. > Profiling shows this critical section is being entered approximately 500K/s across 16 threads. When the critical section is protected with synchronized() I get the following results once warmed up: > > ------------------------------------------------------------------------------- > | Throughput | Response Time | | > | (ops/second) | (milliseconds) | | > | recent average | recent average 99.9% 99.99% 99.999% | err/sec | > ------------------------------------------------------------------------------- > ... > | 9002.6 9002.8 | 4.433 4.432 40.63 94.37 114.29 | 0.0 | > | 9132.8 9014.6 | 4.370 4.426 40.37 87.56 114.29 | 0.0 | > > Yet when the synchronized block is replaced with a ReentrantLock: > > ------------------------------------------------------------------------------- > | Throughput | Response Time | | > | (ops/second) | (milliseconds) | | > | recent average | recent average 99.9% 99.99% 99.999% | err/sec | > ------------------------------------------------------------------------------- > ... > | 8431.2 8378.4 | 4.733 4.763 51.12 114.82 122.16 | 0.0 | > | 8200.4 8342.8 | 4.866 4.784 46.66 114.29 122.16 | 0.0 | > > These results are on my laptop (Intel i9-13900H with 10 cores, Linux 6.5, JDK 21.0.3), but we see similar regressions on larger older machines in our labs. Also worthy of note is that the context switching rate increases from around 180K/s when using synchronized() to 300K/s when using ReentrantLock. I know that ReentrantLock is supposed to be a little bit less efficient in highly contended situations, but I was surprised by an 8-10% impact. Is that expected? > > Analyzing contention using JFR.view > =================================== > > On a related note, I attempted to use the new JFR.view command to analyze the lock contention in both situations: > > jcmd JFR.view contention-by-site verbose=true > > Sadly, it only analyzes JavaMonitorEnter JFR events and completely ignores Thread park events, so I was unable to analyze contention due to ReentrantLock using this tool. Here's the query JFR.view uses: > > COLUMN 'StackTrace', 'Count', 'Avg.', 'Max.' SELECT stackTrace AS S, COUNT(*), AVERAGE(duration), MAXIMUM(duration) AS M FROM JavaMonitorEnter GROUP BY S ORDER BY M > > Do you think this is a bug/RFE? If so, what's the best way to proceed in your opinion? It would be great if tools like JFR.view had better support for j.u.c primitives given that virtual threads will encourage increased usage of them. > > Kind regards, > Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.swift at gmail.com Fri Jun 21 17:05:18 2024 From: matthew.swift at gmail.com (Matthew Swift) Date: Fri, 21 Jun 2024 19:05:18 +0200 Subject: Experience using virtual threads in EA 23-loom+4-102 Message-ID: Hello again, As promised, here is my second (shorter I hope!) email sharing feedback on the recent Loom EA build (23-loom+4-102). If follows up on my previous email https://mail.openjdk.org/pipermail/loom-dev/2024-June/006788.html. I performed some experiments using the same application described in my previous email. However, in order to properly test the improvements to Object monitors (synchronized blocks and Object.wait()) I reverted all of the thread-pinning related changes that I had made in order to support virtual threads with JDK21. Specifically, I reverted the changes converting uses of monitors to ReentrantLock. I'm pleased to say that this EA build looks extremely promising! :-) ### Experiment #1: read stress test * platform threads: 215K/s throughput, CPU 14% idle * virtual threads: 235K/s throughput, CPU 5% idle. Comment: there's a slight throughput improvement, but CPU utilization is slightly higher too. Presumably this is due to the number of carrier threads being closely matched to the number of CPUs (I noticed significantly less context switching with v threads). ### Experiment #2: heavily indexed write stress test, with 40 clients * platform threads: 9300/s throughput, CPU 27% idle * virtual threads: 8800/s throughput, CPU 24% idle. Comment: there is a ~5% performance degradation using virtual threads. This is better than the degradation I observed in my previous email after switching to ReentrantLock though. ### Experiment #3: extreme heavy indexed write stress test, with 120 clients * platform threads: 1450/s throughput * virtual threads: 1450/s throughput (i.e. about the same). Comment: This test is intended to stress the internal locking mechanisms as much as possible and expose any pinning problems. With JDK21 virtual threads the test would sometimes deadlock and thread dumps would show 100+ fork join carrier threads. This is no longer the case with the EA build. It looks really solid. This test does expose one important difference between platform threads and virtual threads though. Let's take a look at the response times: Platform threads: ------------------------------------------------------------------------------- | Throughput | Response Time | | | (ops/second) | (milliseconds) | | | recent average | recent average 99.9% 99.99% 99.999% | err/sec | ------------------------------------------------------------------------------- ... | 1442.6 1606.6 | 83.097 74.683 448.79 599.79 721.42 | 0.0 | | 1480.8 1594.0 | 81.125 75.282 442.50 599.79 721.42 | 0.0 | Virtual threads: ------------------------------------------------------------------------------- | Throughput | Response Time | | | (ops/second) | (milliseconds) | | | recent average | recent average 99.9% 99.99% 99.999% | err/sec | ------------------------------------------------------------------------------- ... | 1445.4 1645.3 | 81.375 72.623 3170.89 4798.28 8925.48 | 0.0 | | 1442.2 1625.0 | 81.047 73.371 3154.12 4798.28 6106.91 | 0.0 | The outliers with virtual threads are much much higher. Could this be due to potential starvation when rescheduling virtual threads in the fork join pool? Cheers, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From rengels at ix.netcom.com Fri Jun 21 17:29:34 2024 From: rengels at ix.netcom.com (robert engels) Date: Fri, 21 Jun 2024 12:29:34 -0500 Subject: Experience using virtual threads in EA 23-loom+4-102 In-Reply-To: References: Message-ID: <6A9FDAD8-3507-4952-A47C-B8CC57C8AD2E@ix.netcom.com> Hi, Just an fyi, until you get into the order of 1k, 10k, etc. concurrent clients - I would expect platform threads to outperform virtual threads by quite a bit (best case be the same). Modern OS?s routinely handle thousands of active threads. (My OSX desktop with 4 true cores has nearly 5k threads running). Also, if you can saturate your CPUs or local IO bus, adding more threads isn?t going to help. VirtualThreads shine when the request handler is fanning out to multiple remote services. Regards, Robert > On Jun 21, 2024, at 12:05 PM, Matthew Swift wrote: > > Hello again, > > As promised, here is my second (shorter I hope!) email sharing feedback on the recent Loom EA build (23-loom+4-102). If follows up on my previous email https://mail.openjdk.org/pipermail/loom-dev/2024-June/006788.html . > > I performed some experiments using the same application described in my previous email. However, in order to properly test the improvements to Object monitors (synchronized blocks and Object.wait()) I reverted all of the thread-pinning related changes that I had made in order to support virtual threads with JDK21. Specifically, I reverted the changes converting uses of monitors to ReentrantLock. > > I'm pleased to say that this EA build looks extremely promising! :-) > > ### Experiment #1: read stress test > > * platform threads: 215K/s throughput, CPU 14% idle > * virtual threads: 235K/s throughput, CPU 5% idle. > > Comment: there's a slight throughput improvement, but CPU utilization is slightly higher too. Presumably this is due to the number of carrier threads being closely matched to the number of CPUs (I noticed significantly less context switching with v threads). > > ### Experiment #2: heavily indexed write stress test, with 40 clients > > * platform threads: 9300/s throughput, CPU 27% idle > * virtual threads: 8800/s throughput, CPU 24% idle. > > Comment: there is a ~5% performance degradation using virtual threads. This is better than the degradation I observed in my previous email after switching to ReentrantLock though. > > ### Experiment #3: extreme heavy indexed write stress test, with 120 clients > > * platform threads: 1450/s throughput > * virtual threads: 1450/s throughput (i.e. about the same). > > Comment: > > This test is intended to stress the internal locking mechanisms as much as possible and expose any pinning problems. > With JDK21 virtual threads the test would sometimes deadlock and thread dumps would show 100+ fork join carrier threads. > This is no longer the case with the EA build. It looks really solid. > > This test does expose one important difference between platform threads and virtual threads though. Let's take a look at the response times: > > Platform threads: > > ------------------------------------------------------------------------------- > | Throughput | Response Time | | > | (ops/second) | (milliseconds) | | > | recent average | recent average 99.9% 99.99% 99.999% | err/sec | > ------------------------------------------------------------------------------- > ... > | 1442.6 1606.6 | 83.097 74.683 448.79 599.79 721.42 | 0.0 | > | 1480.8 1594.0 | 81.125 75.282 442.50 599.79 721.42 | 0.0 | > > Virtual threads: > > ------------------------------------------------------------------------------- > | Throughput | Response Time | | > | (ops/second) | (milliseconds) | | > | recent average | recent average 99.9% 99.99% 99.999% | err/sec | > ------------------------------------------------------------------------------- > ... > | 1445.4 1645.3 | 81.375 72.623 3170.89 4798.28 8925.48 | 0.0 | > | 1442.2 1625.0 | 81.047 73.371 3154.12 4798.28 6106.91 | 0.0 | > > The outliers with virtual threads are much much higher. Could this be due to potential starvation when rescheduling virtual threads in the fork join pool? > > Cheers, > Matt > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Jun 21 18:45:21 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 21 Jun 2024 19:45:21 +0100 Subject: Experience of adding JDK21 virtual thread support to a DB application In-Reply-To: References: Message-ID: <56b44eca-ae6f-4168-884c-7b1a2a29955e@oracle.com> On 21/06/2024 16:57, Matthew Swift wrote: > : > > These results are on my laptop (Intel i9-13900H with 10 cores, Linux > 6.5, JDK 21.0.3), but we see similar regressions on larger older > machines in our labs. Also worthy of note is that the context > switching rate increases from around 180K/s when using synchronized() > to 300K/s when using ReentrantLock. I know that ReentrantLock is > supposed to be a little bit less efficient in highly contended > situations, but I was surprised by an 8-10% impact. Is that expected? One thing that might be part of this is that a contented monitor enter does a small amount of spinning. Sergey Kuksenko may have some comments on this as he has some proposals on this at one point. -Alan From Alan.Bateman at oracle.com Fri Jun 21 18:47:35 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 21 Jun 2024 19:47:35 +0100 Subject: Experience using virtual threads in EA 23-loom+4-102 In-Reply-To: References: Message-ID: On 21/06/2024 18:05, Matthew Swift wrote: > Hello again, > > As promised, here is my second (shorter I hope!) email sharing > feedback on the recent Loom EA build (23-loom+4-102). Thank you for taking the time to write down your experiences, this is exactly the type of feedback that helps. > : > > ### Experiment #1: read stress test For #1 and #2, would it be correct to say that there is a lot of monitor contention? Your first mail talked about contention in the "multi-index write stress test" but I can't tell if this corresponds to #2 or #3 in thesecond mail. This is currently a performance/latency issue with the unblocking of virtual threads that were blocked on monitors (or Object.wait). That is being looked into and may contribute to some of what you are seeing. > : > > > Comment: > > This test is intended to stress the internal locking mechanisms as > much as possible and expose any pinning problems. > With JDK21 virtual threads the test would sometimes deadlock and > thread dumps would show 100+ fork join carrier threads. > This is no longer the case with the EA build. It looks really solid. That's good to see. > > : > > The outliers with virtual threads are much much higher. Could this be > due to potential starvation when rescheduling virtual threads in the > fork join pool? > It's hard to say. The current EA builds doesn't have the final ForkJoinPool change that went into JDK 23, we'll refresh the EA build soon. Another thing is that virtual threads that were blocked on a monitor are pushed to an unowned submission queue so they may not continue immediately if it a lot of other virtual thread parking/unparking going on - this might change with the monitor unblocking perf issue I mentioned. Another possibility is that unfairness that can happen when many threads are trying to enter. In your EA builds then the output from `jcmd Thread.vthread_scheduler` might help as it shows a count of the number of tasks (=threads) in the submission queues. -Alan From hepin.p at alibaba-inc.com Sat Jun 22 05:50:27 2024 From: hepin.p at alibaba-inc.com (=?UTF-8?B?5L2V5ZOBKOiZjum4oyk=?=) Date: Sat, 22 Jun 2024 13:50:27 +0800 Subject: =?UTF-8?B?5Zue5aSN77yaQ2FuIHZpcnR1YWwgdGhyZWFkIGdldCBiZXR0ZXIgc3VwcG9ydCBmb3IgTWFw?= =?UTF-8?B?L1JlZHVjZSBsaWtlIHRoaW5nPw==?= In-Reply-To: <26b2a310-91db-473a-a476-422500a4b7ab@oracle.com> References: <26b2a310-91db-473a-a476-422500a4b7ab@oracle.com> Message-ID: <4d785ee9-0159-4fe1-b210-ee322447f180.hepin.p@alibaba-inc.com> thanks, Because with the current implementation, for a job like I Need translate every json properties inside a JsonObject with VirtualThread ,which returns a CompletableFuture, and to collect the final result , I need do a `future.get` in the parent VT. if I have a 1000+ properties, then 1000+ mount and unmount maybe happen when it interleave with others, it can increase the total time ------------------------------------------------------------------ ????Alan Bateman ?????2024?6?21?(???) 22:30 ????"??(??)"; "loom-dev" ????Re: Can virtual thread get better support for Map/Reduce like thing? On 21/06/2024 12:46, ??(??) wrote: The current implementation always adds the task to the tail, but what if a map/reduce like work, which mean a fork() maybe better for performance/latency , but that will reduce some fairness. If you are building the JDK yourself then you should be try it out. It would be interesting to share your results. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From hepin.p at alibaba-inc.com Sat Jun 22 05:57:24 2024 From: hepin.p at alibaba-inc.com (=?UTF-8?B?5L2V5ZOBKOiZjum4oyk=?=) Date: Sat, 22 Jun 2024 13:57:24 +0800 Subject: =?UTF-8?B?5Zue5aSN77ya5Zue5aSN77yaVmlydHVhbCB0aHJlYWQgaGFuZyBhbmQgYWxsIHRocmVhZHMg?= =?UTF-8?B?c3RvcCBydW5uaW5nIG9uIEpESzIx?= In-Reply-To: <09abc3e4-6f09-4f22-95a6-88eda34a229a.hepin.p@alibaba-inc.com> References: <09abc3e4-6f09-4f22-95a6-88eda34a229a.hepin.p@alibaba-inc.com> Message-ID: <1da8bb5d-85fd-4dc4-84ef-3f9073432cf5.hepin.p@alibaba-inc.com> Is it possible make the classloading use the reentrantlock insteadOf Synchronize in the JDK23 release? that will helps a lot. https://docs.oracle.com/javase/specs/jls/se9/html/jls-12.html#jls-12.4:~:text=Synchronize%20on%20the%20initialization%20lock%2C%20LC%2C%20for%20C.%20This%20involves%20waiting%20until%20the%20current%20thread%20can%20acquire%20LC ------------------------------------------------------------------ ??????(??) ?????2024?6?21?(???) 19:33 ????"??(??)"; Alan Bateman; "loom-dev" ??????????Virtual thread hang and all threads stop running on JDK21 hi team, we have found the root cause. the root cause is because the class loading of in both Netty's EventLoop and our taskRunner (virtualthread), and the threads are blocked when there are many virtual threads. A fix of limit the number of virtualthreads and increase the parallisim > max virtual threads fix the problem. We successfully dump the jcmd when switch to openjdk, and thanks for the help. ------------------------------------------------------------------ ??????(??) ?????2024?6?5?(???) 18:18 ????Alan Bateman; "??(??)"; "loom-dev" ??????????Virtual thread hang and all threads stop running on JDK21 Yes, even jcmd is hung, we are currently want to switch back to the forkJoinPool and increase the jdk.virtualThreadScheduler.maxPoolSize and jdk.virtualThreadScheduler.parallelism > our total max concurrency. I have several system is using Virtual thread, but only this one cause problem. ------------------------------------------------------------------ ????Alan Bateman ?????2024?6?5?(???) 18:00 ????"??(??)"; "loom-dev" ????Re: ???Virtual thread hang and all threads stop running on JDK21 On 05/06/2024 10:37, ??(??) wrote: Thanks, 1. it hung when we are sharing the common usage of the Virtualthread (the default scheduler) cross two modules. 2. after that, I try to hack the virtual thread builder with separated ThreadPoolExecutor. 3. but still , it hung. when it hung, `jcmd Thread.print` prints nothing. and dump programly print nothing too. After switch back to normal thread, it never hang. Some information: module A is using `Object.notifyAll, Object.wait` and module B is using `CompletableFuture.get` (may > 100 times in one rune) I was thinking if that could be a problem of notification missing, where in Module A, the concurrency is 3000? protected by a semaphore, but the underling Carrier Thread is only 128, and 3000 > 128. If it's using synchronized/Object.wait then this may be related to pinning. When there is both object monitors and j.u.concurrent locks in play then it's possible to create deadlock scenarios due to starvation, or selecting a successor or thread to wakeup and the thread can't continue because there are no carriers available. Object.wait will temporarily increase parallelism to smooth and help some cases but it may not help you here, and does nothing when the scheduler has been changed to be something other than a ForkJoinPool instance. When you say "prints nothing" then you mean this literally or do you mean that jcmd is hung too? If so that's a hint that may be the lock for standard output is held by a virtual thread that can't continue because there are no carriers available. It would be interesting to try the latest Loom EA builds which has changes to the object monitor implementation that doesn't pin. Would you have time to try these builds out? -Alan [1] https://jdk.java.net/loom/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hepin.p at alibaba-inc.com Sat Jun 22 06:02:45 2024 From: hepin.p at alibaba-inc.com (=?UTF-8?B?5L2V5ZOBKOiZjum4oyk=?=) Date: Sat, 22 Jun 2024 14:02:45 +0800 Subject: =?UTF-8?B?5Zue5aSN77yaQ2hhbmdlcyB0byBPYmVjdCBtb25pdG9ycw==?= In-Reply-To: <4a27fcfe-5dea-4401-9f1c-bb35dbd4a70c@oracle.com> References: <4a27fcfe-5dea-4401-9f1c-bb35dbd4a70c@oracle.com> Message-ID: Is it possible to include it in JDK23 behind a flag? Thanks ------------------------------------------------------------------ ????alan.bateman ?????2024?6?21?(???) 16:09 ????Yuval Lombard; "loom-dev" ????Re: Changes to Obect monitors On 21/06/2024 08:21, Yuval Lombard wrote: > Hey team, > > You have probably been asked about this a lot already, so I am sorry > if I raise it again. > > Will the fixes to the Object monitor be released in first jdk23 > release? and if not what is your estimation for it? > JDK 23 is already in ramp down so not JDK 23. There is more work required on performance and a few other issues but I think looking quite good for soon after JDK 23. We hope to get more people testing the EA builds as the changes are significant. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From masoud.parvari at gmail.com Sat Jun 22 08:54:04 2024 From: masoud.parvari at gmail.com (masoud parvari) Date: Sat, 22 Jun 2024 10:54:04 +0200 Subject: =?UTF-8?Q?Re=3A_=E5=9B=9E=E5=A4=8D=EF=BC=9AVirtual_thread_hang_and_all_threads_sto?= =?UTF-8?Q?p_running_on_JDK21?= In-Reply-To: <1da8bb5d-85fd-4dc4-84ef-3f9073432cf5.hepin.p@alibaba-inc.com> References: <09abc3e4-6f09-4f22-95a6-88eda34a229a.hepin.p@alibaba-inc.com> <1da8bb5d-85fd-4dc4-84ef-3f9073432cf5.hepin.p@alibaba-inc.com> Message-ID: In class loading/initialization cases, the underlying issue is that pinning happens because there are native frames in the stack, so replacing the synchronized with a j.u.c lock will still lead to the same issue. On Sat, Jun 22, 2024 at 9:27?AM ??(??) wrote: > Is it possible make the classloading use the reentrantlock insteadOf > Synchronize > in > the JDK23 release? that will helps a lot. > > https://docs.oracle.com/javase/specs/jls/se9/html/jls-12.html#jls-12.4:~:text=Synchronize%20on%20the%20initialization%20lock%2C%20LC%2C%20for%20C.%20This%20involves%20waiting%20until%20the%20current%20thread%20can%20acquire%20LC > > ------------------------------------------------------------------ > ??????(??) > ?????2024?6?21?(???) 19:33 > ????"??(??)"; Alan Bateman< > Alan.Bateman at oracle.com>; "loom-dev" > ? ????????Virtual thread hang and all threads stop running on JDK21 > > hi team, we have found the root cause. > the root cause is because the class loading of in both Netty's EventLoop > and our taskRunner (virtualthread), and the threads are blocked when there > are many virtual threads. > > A fix of limit the number of virtualthreads and increase the parallisim > > max virtual threads fix the problem. > > We successfully dump the jcmd when switch to openjdk, and thanks for the > help. > > ------------------------------------------------------------------ > ??????(??) > ?????2024?6?5?(???) 18:18 > ????Alan Bateman; "??(??)"< > hepin.p at alibaba-inc.com>; "loom-dev" > ? ????????Virtual thread hang and all threads stop running on JDK21 > > Yes, even jcmd is hung, we are currently want to switch back to the > forkJoinPool and increase the jdk.virtualThreadScheduler.maxPoolSize and > jdk.virtualThreadScheduler.parallelism > our total max concurrency. > > I have several system is using Virtual thread, but only this one cause > problem. > > > ------------------------------------------------------------------ > ????Alan Bateman > ?????2024?6?5?(???) 18:00 > ????"??(??)"; "loom-dev" > ? ??Re: ???Virtual thread hang and all threads stop running on JDK21 > > On 05/06/2024 10:37, ??(??) wrote: > Thanks, > 1. it hung when we are sharing the common usage of the Virtualthread (the > default scheduler) cross two modules. > 2. after that, I try to hack the virtual thread builder with separated > ThreadPoolExecutor. > 3. but still , it hung. > > when it hung, `jcmd Thread.print` prints nothing. and dump programly > print nothing too. > > After switch back to normal thread, it never hang. > Some information: > module A is using `Object.notifyAll, Object.wait` and module B is using > `CompletableFuture.get` (may > 100 times in one rune) > I was thinking if that could be a problem of notification missing, where > in Module A, the concurrency is 3000? protected by a semaphore, but the > underling Carrier Thread is only 128, and 3000 > 128. > > If it's using synchronized/Object.wait then this may be related to > pinning. When there is both object monitors and j.u.concurrent locks in > play then it's possible to create deadlock scenarios due to starvation, or > selecting a successor or thread to wakeup and the thread can't continue > because there are no carriers available. Object.wait will temporarily > increase parallelism to smooth and help some cases but it may not help you > here, and does nothing when the scheduler has been changed to be something > other than a ForkJoinPool instance. > > When you say "prints nothing" then you mean this literally or do you mean > that jcmd is hung too? If so that's a hint that may be the lock for > standard output is held by a virtual thread that can't continue because > there are no carriers available. > > It would be interesting to try the latest Loom EA builds which has changes > to the object monitor implementation that doesn't pin. Would you have time > to try these builds out? > > -Alan > > [1] https://jdk.java.net/loom/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Sat Jun 22 09:22:09 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 22 Jun 2024 10:22:09 +0100 Subject: =?UTF-8?B?UmU6IOWbnuWkje+8mlZpcnR1YWwgdGhyZWFkIGhhbmcgYW5kIGFsbCB0?= =?UTF-8?Q?hreads_stop_running_on_JDK21?= In-Reply-To: References: <09abc3e4-6f09-4f22-95a6-88eda34a229a.hepin.p@alibaba-inc.com> <1da8bb5d-85fd-4dc4-84ef-3f9073432cf5.hepin.p@alibaba-inc.com> Message-ID: <15844001-89d0-4485-a0d4-6952c5fef715@oracle.com> On 22/06/2024 09:54, masoud parvari wrote: > In class loading/initialization cases, the underlying issue is that > pinning?happens because there are native frames?in the stack, so > replacing the synchronized with a j.u.c lock will still lead to the > same issue. > That's right, and there are a couple of scenarios there, to be looked into after the object monitor issues are out of the way. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Sat Jun 22 13:45:09 2024 From: duke at openjdk.org (duke) Date: Sat, 22 Jun 2024 13:45:09 GMT Subject: git: openjdk/loom: fibers: 33 new changesets Message-ID: <30c926fc-62c6-42b2-8e81-88a2d0b22579@openjdk.org> Changeset: 6e99459a Author: Alan Bateman Date: 2024-06-22 07:22:17 +0000 URL: https://git.openjdk.org/loom/commit/6e99459ab6e682fdf04ecf4a0b3b2441c0c40115 TestMixedGCLiveThreshold.java still running ! test/hotspot/jtreg/ProblemList-Virtual.txt Changeset: 64208462 Author: Hamlin Li Date: 2024-06-20 10:10:54 +0000 URL: https://git.openjdk.org/loom/commit/642084629a9a793a055cba8a950fdb61b7450093 8334396: RISC-V: verify perf of ReverseBytesI/L Reviewed-by: fyang, rehn ! src/hotspot/cpu/riscv/riscv.ad ! src/hotspot/cpu/riscv/riscv_b.ad Changeset: 5cad0b4d Author: Nizar Benalla Committer: Chen Liang Date: 2024-06-20 11:53:02 +0000 URL: https://git.openjdk.org/loom/commit/5cad0b4df7f5ccb6d462dc948c2ea5ad5da6e2ed 8322708: Global HTML attributes are not allowed Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/HtmlTag.java + test/langtools/jdk/javadoc/doclet/TestGlobalHtml/TestGlobalHtml.java + test/langtools/jdk/javadoc/doclet/TestGlobalHtml/pkg1/C1.java Changeset: 001d6860 Author: Gui Cao Committer: Hamlin Li Date: 2024-06-20 13:45:31 +0000 URL: https://git.openjdk.org/loom/commit/001d6860199436c5fb14bd681d640d462b472015 8332587: RISC-V: secondary_super_cache does not scale well Reviewed-by: mli, fyang ! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp ! src/hotspot/cpu/riscv/macroAssembler_riscv.hpp ! src/hotspot/cpu/riscv/riscv.ad ! src/hotspot/cpu/riscv/stubGenerator_riscv.cpp ! src/hotspot/cpu/riscv/vm_version_riscv.hpp Changeset: 9ef86da5 Author: Abhishek Kumar Date: 2024-06-20 15:42:17 +0000 URL: https://git.openjdk.org/loom/commit/9ef86da5f8e2579fa1fdf40b4a6f556882e1177d 8334170: bug6492108.java test failed with exception Image comparison failed at (0, 0) for image 4 Reviewed-by: aivanov, azvegint ! test/jdk/com/sun/java/swing/plaf/gtk/bug6492108.java Changeset: 99e4d77a Author: Leonid Mesnik Date: 2024-06-20 15:43:44 +0000 URL: https://git.openjdk.org/loom/commit/99e4d77aac72cdddb4973805d28c225f17ea965f 8333117: Remove support of remote and manual debuggee launchers Reviewed-by: cjplummer ! test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Debuggee.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Launcher.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/ArgumentHandler.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Binder.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jdwp/Binder.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jdwp/Debugee.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeArgumentHandler.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeBinder.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeProcess.java Changeset: a81e1bf1 Author: Leonid Mesnik Date: 2024-06-20 15:43:56 +0000 URL: https://git.openjdk.org/loom/commit/a81e1bf1e1a6f00280b9be987c03fe20915fd52c 8332252: Clean up vmTestbase/vm/share Reviewed-by: cjplummer ! test/hotspot/jtreg/vmTestbase/gc/gctests/LoadUnloadGC/LoadUnloadGC.java = test/hotspot/jtreg/vmTestbase/gc/gctests/LoadUnloadGC/MemoryPoolFinder.java ! test/hotspot/jtreg/vmTestbase/metaspace/gc/HighWaterMarkTest.java = test/hotspot/jtreg/vmTestbase/metaspace/share/HeapOOMEException.java = test/hotspot/jtreg/vmTestbase/metaspace/share/TriggerUnloadingByFillingMetaspace.java = test/hotspot/jtreg/vmTestbase/metaspace/share/TriggerUnloadingHelper.java = test/hotspot/jtreg/vmTestbase/metaspace/share/TriggerUnloadingWithWhiteBox.java ! test/hotspot/jtreg/vmTestbase/metaspace/staticReferences/StaticReferences.java ! test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/common/PerformChecksHelper.java ! test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/common/StressHierarchyBaseClass.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t004/hs203t004.java ! test/hotspot/jtreg/vmTestbase/vm/compiler/complog/share/LogCompilationTest.java = test/hotspot/jtreg/vmTestbase/vm/compiler/complog/share/ProcessExecutor.java = test/hotspot/jtreg/vmTestbase/vm/compiler/complog/share/StreamListener.java = test/hotspot/jtreg/vmTestbase/vm/compiler/complog/share/StreamLogger.java = test/hotspot/jtreg/vmTestbase/vm/compiler/complog/share/StreamReader.java ! test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/func/findByName/Test.java ! test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/share/StressClassLoadingTest.java ! test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/stress/byteMutation/Test.java ! test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/stress/oome/heap/Test.java ! test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/stress/oome/metaspace/Test.java ! test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/stress/parallelLoad/Test.java ! test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/stress/gc/lotsOfCallSites/Test.java ! test/hotspot/jtreg/vmTestbase/vm/mlvm/share/CustomClassLoaders.java = test/hotspot/jtreg/vmTestbase/vm/mlvm/share/FileUtils.java ! test/hotspot/jtreg/vmTestbase/vm/mlvm/share/MlvmTestExecutor.java - test/hotspot/jtreg/vmTestbase/vm/share/CommentedFileReader.java ! test/hotspot/jtreg/vmTestbase/vm/share/ProcessUtils.cpp ! test/hotspot/jtreg/vmTestbase/vm/share/ProcessUtils.java - test/hotspot/jtreg/vmTestbase/vm/share/RandomEx.java - test/hotspot/jtreg/vmTestbase/vm/share/StringUtils.java - test/hotspot/jtreg/vmTestbase/vm/share/UnsafeAccess.java - test/hotspot/jtreg/vmTestbase/vm/share/VMRuntimeEnvUtils.java - test/hotspot/jtreg/vmTestbase/vm/share/monitoring/data/MemoryManagerData.java - test/hotspot/jtreg/vmTestbase/vm/share/monitoring/data/MemoryPoolData.java - test/hotspot/jtreg/vmTestbase/vm/share/monitoring/data/MemoryUsageData.java - test/hotspot/jtreg/vmTestbase/vm/share/process/CmdExecutor.java - test/hotspot/jtreg/vmTestbase/vm/share/process/MessageInput.java - test/hotspot/jtreg/vmTestbase/vm/share/process/MessageOutput.java - test/hotspot/jtreg/vmTestbase/vm/share/process/ProcessHandler.java - test/hotspot/jtreg/vmTestbase/vm/share/process/StreamMessageInput.java - test/hotspot/jtreg/vmTestbase/vm/share/process/StreamMessageOutput.java - test/hotspot/jtreg/vmTestbase/vm/share/transform/AbstractClassFileTransformer.java - test/hotspot/jtreg/vmTestbase/vm/share/transform/AnnotationAppender.java - test/hotspot/jtreg/vmTestbase/vm/share/transform/TransformingClassLoader.java Changeset: 1b1dba80 Author: Pavel Rappo Date: 2024-06-20 16:28:48 +0000 URL: https://git.openjdk.org/loom/commit/1b1dba8082969244effa86ac03c6053b3b0ddc43 8333358: java/io/IO/IO.java test fails intermittently Reviewed-by: naoto ! test/jdk/java/io/IO/IO.java ! test/jdk/java/io/IO/input.exp ! test/jdk/java/io/IO/output.exp Changeset: 265a0f55 Author: Naoto Sato Date: 2024-06-20 17:01:17 +0000 URL: https://git.openjdk.org/loom/commit/265a0f5547d0ddb220391aef679c122768f02a00 8334490: Normalize string with locale invariant `toLowerCase()` Reviewed-by: jlu, dfuchs, lancea, rriggs ! test/lib/jdk/test/lib/Platform.java Changeset: de8ee977 Author: SendaoYan Committer: Naoto Sato Date: 2024-06-20 18:04:58 +0000 URL: https://git.openjdk.org/loom/commit/de8ee97718d7e12b541b310cf5b67f3e10e91ad9 8334333: MissingResourceCauseTestRun.java fails if run by root Reviewed-by: naoto, jlu ! test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTestRun.java Changeset: 187710e1 Author: Tom Rodriguez Date: 2024-06-20 18:46:36 +0000 URL: https://git.openjdk.org/loom/commit/187710e1c1714ba28c7802efd4f7bb32a366d79d 8333300: [JVMCI] add support for generational ZGC Reviewed-by: dnsimon, kvn, eosterlund ! src/hotspot/cpu/aarch64/jvmciCodeInstaller_aarch64.cpp ! src/hotspot/cpu/riscv/jvmciCodeInstaller_riscv.cpp ! src/hotspot/cpu/x86/jvmciCodeInstaller_x86.cpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/gc/z/zBarrier.hpp ! src/hotspot/share/gc/z/zBarrier.inline.hpp ! src/hotspot/share/gc/z/zBarrierSetRuntime.cpp ! src/hotspot/share/gc/z/zBarrierSetRuntime.hpp ! src/hotspot/share/jvmci/jvmciCodeInstaller.cpp ! src/hotspot/share/jvmci/jvmciCodeInstaller.hpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.hpp ! src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp ! src/hotspot/share/jvmci/jvmciRuntime.cpp ! src/hotspot/share/jvmci/jvmci_globals.cpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp Changeset: 4b4a483b Author: Coleen Phillimore Date: 2024-06-20 19:03:50 +0000 URL: https://git.openjdk.org/loom/commit/4b4a483b6fe7a6fcfdfe6f68faac29099a64c982 8330699: Obsolete -XX:+UseEmptySlotsInSupers Reviewed-by: shade, fparain, dholmes ! src/hotspot/share/classfile/fieldLayoutBuilder.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp - test/hotspot/jtreg/runtime/FieldLayout/OldLayoutCheck.java Changeset: e5de26dd Author: Jatin Bhateja Date: 2024-06-20 23:35:15 +0000 URL: https://git.openjdk.org/loom/commit/e5de26ddf0550da9e6d074d5b9ab4a943170adca 8329032: C2 compiler register allocation support for APX EGPRs Reviewed-by: kvn, sviswanathan ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/cpu/x86/assembler_x86.hpp ! src/hotspot/cpu/x86/c1_Defs_x86.hpp ! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp ! src/hotspot/cpu/x86/c1_Runtime1_x86.cpp ! src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp ! src/hotspot/cpu/x86/gc/x/xBarrierSetAssembler_x86.cpp ! src/hotspot/cpu/x86/globals_x86.hpp ! src/hotspot/cpu/x86/jvmciCodeInstaller_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/methodHandles_x86.cpp ! src/hotspot/cpu/x86/nativeInst_x86.cpp ! src/hotspot/cpu/x86/nativeInst_x86.hpp ! src/hotspot/cpu/x86/register_x86.cpp ! src/hotspot/cpu/x86/register_x86.hpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/cpu/x86/upcallLinker_x86_64.cpp ! src/hotspot/cpu/x86/vm_version_x86.cpp ! src/hotspot/cpu/x86/vm_version_x86.hpp ! src/hotspot/cpu/x86/vmreg_x86.hpp ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp ! src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/amd64/AMD64.java Changeset: 880e458a Author: Vladimir Kozlov Date: 2024-06-21 00:24:55 +0000 URL: https://git.openjdk.org/loom/commit/880e458a1072589ae199cc9204dcce9eab0f4eaa 8333819: Move embedded external addresses from relocation info into separate global table Reviewed-by: dlong ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/code/oopRecorder.cpp ! src/hotspot/share/code/oopRecorder.hpp ! src/hotspot/share/code/relocInfo.cpp ! src/hotspot/share/runtime/init.cpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp Changeset: 6a5cb0b2 Author: Matthias Baesken Date: 2024-06-21 07:04:26 +0000 URL: https://git.openjdk.org/loom/commit/6a5cb0b2c49cb390ce8b87fd977ee79572df90fc 8334567: [test] runtime/os/TestTracePageSizes move ppc handling Reviewed-by: stuefe, lucy ! test/hotspot/jtreg/runtime/os/TestTracePageSizes.java Changeset: bdd96604 Author: Erik Gahlin Date: 2024-06-21 07:36:02 +0000 URL: https://git.openjdk.org/loom/commit/bdd96604ae55ba0cd3cd3363e2ba44205d8aa3aa 8323196: jdk/jfr/api/consumer/filestream/TestOrdered.java failed with "Events are not ordered! Reuse = false" Reviewed-by: mgronlun ! test/jdk/jdk/jfr/api/consumer/filestream/TestOrdered.java Changeset: ed149062 Author: Matthias Baesken Date: 2024-06-21 08:38:42 +0000 URL: https://git.openjdk.org/loom/commit/ed149062d0e8407710f083aa85d28d27c4a45ecc 8333361: ubsan,test : libHeapMonitorTest.cpp:518:9: runtime error: null pointer passed as argument 2, which is declared to never be null Reviewed-by: asteiner, lucy, amenkov ! test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/libHeapMonitorTest.cpp Changeset: d2bebffb Author: Daniel Fuchs Date: 2024-06-21 09:43:49 +0000 URL: https://git.openjdk.org/loom/commit/d2bebffb1fd26fae4526afd33a818ee776b7102e 8327370: (ch) sun.nio.ch.Poller.register throws AssertionError Co-authored-by: Alan Bateman Reviewed-by: alanb, jpai, djelinski ! src/java.base/share/classes/sun/nio/ch/Poller.java Changeset: 711e7238 Author: Tejesh R Date: 2024-06-21 10:36:05 +0000 URL: https://git.openjdk.org/loom/commit/711e7238196a4ef9211ed4cca15c7c1d774df019 6967482: TAB-key does not work in JTables after selecting details-view in JFileChooser 8166352: FilePane.createDetailsView() removes JTable TAB, SHIFT-TAB functionality Reviewed-by: achung, prr ! src/java.desktop/share/classes/sun/swing/FilePane.java + test/jdk/javax/swing/JFileChooser/TABTestONFCExit.java Changeset: 08ace27d Author: Archie Cobbs Committer: Jan Lahoda Date: 2024-06-21 10:44:51 +0000 URL: https://git.openjdk.org/loom/commit/08ace27da1d9cd215c77471eabf41417ff6282d2 8332314: Add window size configuration option to JavaShellToolBuilder interface Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellToolBuilder.java ! src/jdk.jshell/share/classes/jdk/jshell/tool/JavaShellToolBuilder.java Changeset: dbf5a9a4 Author: Doug Simon Date: 2024-06-21 13:43:03 +0000 URL: https://git.openjdk.org/loom/commit/dbf5a9a4006020ddebcce89692ce8826b6b2db46 8334706: [JVMCI] APX registers incorrectly exposed on AMD64 Reviewed-by: yzheng, never ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/amd64/AMD64.java ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/code/Architecture.java Changeset: 9f8de221 Author: Kevin Walls Date: 2024-06-21 13:51:06 +0000 URL: https://git.openjdk.org/loom/commit/9f8de221d7f0186718411ab3f5217e3883237e84 8327793: Deprecate jstatd for removal Reviewed-by: alanb, cjplummer ! src/jdk.jstatd/share/classes/module-info.java ! src/jdk.jstatd/share/classes/sun/tools/jstatd/Jstatd.java ! test/jdk/sun/tools/jstatd/JstatdTest.java Changeset: 75bea280 Author: Ferenc Rakoczi Committer: Weijun Wang Date: 2024-06-21 14:16:23 +0000 URL: https://git.openjdk.org/loom/commit/75bea280b9adb6dac9fefafbb3f4b212f100fbb5 8333867: SHA3 performance can be improved Reviewed-by: kvn, valeriep ! src/hotspot/share/opto/library_call.cpp ! src/java.base/share/classes/sun/security/provider/DigestBase.java ! src/java.base/share/classes/sun/security/provider/SHA3.java Changeset: c41293a7 Author: Jie Fu Date: 2024-06-21 14:23:38 +0000 URL: https://git.openjdk.org/loom/commit/c41293a70834a79c79e859ebcdb8869884ac87dc 8334695: Fix build failure without zgc after JDK-8333300 Reviewed-by: dnsimon, chagedorn ! src/hotspot/cpu/x86/jvmciCodeInstaller_x86.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.hpp ! src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp Changeset: 93d98027 Author: SendaoYan Committer: Amit Kumar Date: 2024-06-21 15:48:38 +0000 URL: https://git.openjdk.org/loom/commit/93d98027649615afeeeb6a9510230d9655a74a8f 8334715: [riscv] Mixed use of tab and whitespace in riscv.ad Reviewed-by: chagedorn, amitkumar ! src/hotspot/cpu/riscv/riscv.ad Changeset: 8e1d2b09 Author: Rajan Halade Date: 2024-06-21 16:37:57 +0000 URL: https://git.openjdk.org/loom/commit/8e1d2b091c9a311d98a0b886a803fb18d4405d8a 8334441: Mark tests in jdk_security_infra group as manual Reviewed-by: clanger, mullan ! test/jdk/ProblemList.txt ! test/jdk/TEST.groups ! test/jdk/security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java ! test/jdk/security/infra/java/security/cert/CertPathValidator/certification/CertignaCA.java ! test/jdk/security/infra/java/security/cert/CertPathValidator/certification/DTrustCA.java ! test/jdk/security/infra/java/security/cert/CertPathValidator/certification/DigicertCSRootG5.java ! test/jdk/security/infra/java/security/cert/CertPathValidator/certification/EmSignRootG2CA.java ! test/jdk/security/infra/java/security/cert/CertPathValidator/certification/HaricaCA.java ! test/jdk/security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java ! test/jdk/security/infra/javax/net/ssl/HttpsURLConnectionTest.java Changeset: 689cee3d Author: Prasanta Sadhukhan Date: 2024-06-21 18:02:57 +0000 URL: https://git.openjdk.org/loom/commit/689cee3d0950e15e88a1f6738bfded00655dca9c 8334509: Cancelling PageDialog does not return the same PageFormat object Reviewed-by: aivanov, prr ! src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp + test/jdk/java/awt/print/PrinterJob/PageDialogCancelTest.java Changeset: 1ff5acda Author: Nizar Benalla Committer: Phil Race Date: 2024-06-21 20:13:26 +0000 URL: https://git.openjdk.org/loom/commit/1ff5acdafff1ccd3e64c70eebbfbff75e0d783eb 8332099: since-checker - Add @ since to package-info in jdk.jsobject Reviewed-by: prr ! src/jdk.jsobject/share/classes/netscape/javascript/package-info.java Changeset: 7e55ed3b Author: Chen Liang Date: 2024-06-21 22:38:38 +0000 URL: https://git.openjdk.org/loom/commit/7e55ed3b106ed08956d2d38b7c99fb81704667c9 8333748: javap crash - Fatal error: Unmatched bit position 0x2 for location CLASS Reviewed-by: asotona ! src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/BasicWriter.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java + test/langtools/tools/javap/UndefinedAccessFlagTest.java Changeset: 68a81bc9 Author: Alan Bateman Date: 2024-06-22 09:50:58 +0000 URL: https://git.openjdk.org/loom/commit/68a81bc99384ff3c9101e44419e875968bf6d160 Merge ! src/hotspot/cpu/x86/c1_Runtime1_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/cpu/x86/vm_version_x86.hpp ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/runtime/globals.hpp ! src/java.base/share/classes/sun/nio/ch/Poller.java ! src/hotspot/cpu/x86/c1_Runtime1_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/cpu/x86/vm_version_x86.hpp ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp ! src/hotspot/share/opto/library_call.cpp ! src/hotspot/share/runtime/globals.hpp ! src/java.base/share/classes/sun/nio/ch/Poller.java Changeset: bb89a132 Author: Alan Bateman Date: 2024-06-21 15:21:34 +0000 URL: https://git.openjdk.org/loom/commit/bb89a132dbce31513ad6a44af9e01d6f1ef2b1d6 JVMTI may access thread group before it is created ! src/java.base/share/classes/java/lang/VirtualThread.java Changeset: c97fcf33 Author: Alan Bateman Date: 2024-06-22 09:51:12 +0000 URL: https://git.openjdk.org/loom/commit/c97fcf33395a73a07991103aa45ee01889ce2a6e Merge Changeset: 8f12e5d8 Author: Alan Bateman Date: 2024-06-22 14:41:53 +0000 URL: https://git.openjdk.org/loom/commit/8f12e5d86fe7db4e77e7fa7c4d86db88162eccd3 GetStackTraceALotWhenBlocking#0 is for release builds only ! test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALotWhenBlocking.java ! test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALotWhenParking.java From duke at openjdk.org Sat Jun 22 13:46:43 2024 From: duke at openjdk.org (duke) Date: Sat, 22 Jun 2024 13:46:43 GMT Subject: git: openjdk/loom: master: 28 new changesets Message-ID: <2a38d3ea-5a55-4653-a73a-82fa97047a1e@openjdk.org> Changeset: 64208462 Author: Hamlin Li Date: 2024-06-20 10:10:54 +0000 URL: https://git.openjdk.org/loom/commit/642084629a9a793a055cba8a950fdb61b7450093 8334396: RISC-V: verify perf of ReverseBytesI/L Reviewed-by: fyang, rehn ! src/hotspot/cpu/riscv/riscv.ad ! src/hotspot/cpu/riscv/riscv_b.ad Changeset: 5cad0b4d Author: Nizar Benalla Committer: Chen Liang Date: 2024-06-20 11:53:02 +0000 URL: https://git.openjdk.org/loom/commit/5cad0b4df7f5ccb6d462dc948c2ea5ad5da6e2ed 8322708: Global HTML attributes are not allowed Reviewed-by: jjg ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java ! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/HtmlTag.java + test/langtools/jdk/javadoc/doclet/TestGlobalHtml/TestGlobalHtml.java + test/langtools/jdk/javadoc/doclet/TestGlobalHtml/pkg1/C1.java Changeset: 001d6860 Author: Gui Cao Committer: Hamlin Li Date: 2024-06-20 13:45:31 +0000 URL: https://git.openjdk.org/loom/commit/001d6860199436c5fb14bd681d640d462b472015 8332587: RISC-V: secondary_super_cache does not scale well Reviewed-by: mli, fyang ! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp ! src/hotspot/cpu/riscv/macroAssembler_riscv.hpp ! src/hotspot/cpu/riscv/riscv.ad ! src/hotspot/cpu/riscv/stubGenerator_riscv.cpp ! src/hotspot/cpu/riscv/vm_version_riscv.hpp Changeset: 9ef86da5 Author: Abhishek Kumar Date: 2024-06-20 15:42:17 +0000 URL: https://git.openjdk.org/loom/commit/9ef86da5f8e2579fa1fdf40b4a6f556882e1177d 8334170: bug6492108.java test failed with exception Image comparison failed at (0, 0) for image 4 Reviewed-by: aivanov, azvegint ! test/jdk/com/sun/java/swing/plaf/gtk/bug6492108.java Changeset: 99e4d77a Author: Leonid Mesnik Date: 2024-06-20 15:43:44 +0000 URL: https://git.openjdk.org/loom/commit/99e4d77aac72cdddb4973805d28c225f17ea965f 8333117: Remove support of remote and manual debuggee launchers Reviewed-by: cjplummer ! test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Debuggee.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Launcher.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/ArgumentHandler.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Binder.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jdwp/Binder.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jdwp/Debugee.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeArgumentHandler.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeBinder.java ! test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeProcess.java Changeset: a81e1bf1 Author: Leonid Mesnik Date: 2024-06-20 15:43:56 +0000 URL: https://git.openjdk.org/loom/commit/a81e1bf1e1a6f00280b9be987c03fe20915fd52c 8332252: Clean up vmTestbase/vm/share Reviewed-by: cjplummer ! test/hotspot/jtreg/vmTestbase/gc/gctests/LoadUnloadGC/LoadUnloadGC.java = test/hotspot/jtreg/vmTestbase/gc/gctests/LoadUnloadGC/MemoryPoolFinder.java ! test/hotspot/jtreg/vmTestbase/metaspace/gc/HighWaterMarkTest.java = test/hotspot/jtreg/vmTestbase/metaspace/share/HeapOOMEException.java = test/hotspot/jtreg/vmTestbase/metaspace/share/TriggerUnloadingByFillingMetaspace.java = test/hotspot/jtreg/vmTestbase/metaspace/share/TriggerUnloadingHelper.java = test/hotspot/jtreg/vmTestbase/metaspace/share/TriggerUnloadingWithWhiteBox.java ! test/hotspot/jtreg/vmTestbase/metaspace/staticReferences/StaticReferences.java ! test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/common/PerformChecksHelper.java ! test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/common/StressHierarchyBaseClass.java ! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t004/hs203t004.java ! test/hotspot/jtreg/vmTestbase/vm/compiler/complog/share/LogCompilationTest.java = test/hotspot/jtreg/vmTestbase/vm/compiler/complog/share/ProcessExecutor.java = test/hotspot/jtreg/vmTestbase/vm/compiler/complog/share/StreamListener.java = test/hotspot/jtreg/vmTestbase/vm/compiler/complog/share/StreamLogger.java = test/hotspot/jtreg/vmTestbase/vm/compiler/complog/share/StreamReader.java ! test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/func/findByName/Test.java ! test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/share/StressClassLoadingTest.java ! test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/stress/byteMutation/Test.java ! test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/stress/oome/heap/Test.java ! test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/stress/oome/metaspace/Test.java ! test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/stress/parallelLoad/Test.java ! test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/stress/gc/lotsOfCallSites/Test.java ! test/hotspot/jtreg/vmTestbase/vm/mlvm/share/CustomClassLoaders.java = test/hotspot/jtreg/vmTestbase/vm/mlvm/share/FileUtils.java ! test/hotspot/jtreg/vmTestbase/vm/mlvm/share/MlvmTestExecutor.java - test/hotspot/jtreg/vmTestbase/vm/share/CommentedFileReader.java ! test/hotspot/jtreg/vmTestbase/vm/share/ProcessUtils.cpp ! test/hotspot/jtreg/vmTestbase/vm/share/ProcessUtils.java - test/hotspot/jtreg/vmTestbase/vm/share/RandomEx.java - test/hotspot/jtreg/vmTestbase/vm/share/StringUtils.java - test/hotspot/jtreg/vmTestbase/vm/share/UnsafeAccess.java - test/hotspot/jtreg/vmTestbase/vm/share/VMRuntimeEnvUtils.java - test/hotspot/jtreg/vmTestbase/vm/share/monitoring/data/MemoryManagerData.java - test/hotspot/jtreg/vmTestbase/vm/share/monitoring/data/MemoryPoolData.java - test/hotspot/jtreg/vmTestbase/vm/share/monitoring/data/MemoryUsageData.java - test/hotspot/jtreg/vmTestbase/vm/share/process/CmdExecutor.java - test/hotspot/jtreg/vmTestbase/vm/share/process/MessageInput.java - test/hotspot/jtreg/vmTestbase/vm/share/process/MessageOutput.java - test/hotspot/jtreg/vmTestbase/vm/share/process/ProcessHandler.java - test/hotspot/jtreg/vmTestbase/vm/share/process/StreamMessageInput.java - test/hotspot/jtreg/vmTestbase/vm/share/process/StreamMessageOutput.java - test/hotspot/jtreg/vmTestbase/vm/share/transform/AbstractClassFileTransformer.java - test/hotspot/jtreg/vmTestbase/vm/share/transform/AnnotationAppender.java - test/hotspot/jtreg/vmTestbase/vm/share/transform/TransformingClassLoader.java Changeset: 1b1dba80 Author: Pavel Rappo Date: 2024-06-20 16:28:48 +0000 URL: https://git.openjdk.org/loom/commit/1b1dba8082969244effa86ac03c6053b3b0ddc43 8333358: java/io/IO/IO.java test fails intermittently Reviewed-by: naoto ! test/jdk/java/io/IO/IO.java ! test/jdk/java/io/IO/input.exp ! test/jdk/java/io/IO/output.exp Changeset: 265a0f55 Author: Naoto Sato Date: 2024-06-20 17:01:17 +0000 URL: https://git.openjdk.org/loom/commit/265a0f5547d0ddb220391aef679c122768f02a00 8334490: Normalize string with locale invariant `toLowerCase()` Reviewed-by: jlu, dfuchs, lancea, rriggs ! test/lib/jdk/test/lib/Platform.java Changeset: de8ee977 Author: SendaoYan Committer: Naoto Sato Date: 2024-06-20 18:04:58 +0000 URL: https://git.openjdk.org/loom/commit/de8ee97718d7e12b541b310cf5b67f3e10e91ad9 8334333: MissingResourceCauseTestRun.java fails if run by root Reviewed-by: naoto, jlu ! test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTestRun.java Changeset: 187710e1 Author: Tom Rodriguez Date: 2024-06-20 18:46:36 +0000 URL: https://git.openjdk.org/loom/commit/187710e1c1714ba28c7802efd4f7bb32a366d79d 8333300: [JVMCI] add support for generational ZGC Reviewed-by: dnsimon, kvn, eosterlund ! src/hotspot/cpu/aarch64/jvmciCodeInstaller_aarch64.cpp ! src/hotspot/cpu/riscv/jvmciCodeInstaller_riscv.cpp ! src/hotspot/cpu/x86/jvmciCodeInstaller_x86.cpp ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/gc/z/zBarrier.hpp ! src/hotspot/share/gc/z/zBarrier.inline.hpp ! src/hotspot/share/gc/z/zBarrierSetRuntime.cpp ! src/hotspot/share/gc/z/zBarrierSetRuntime.hpp ! src/hotspot/share/jvmci/jvmciCodeInstaller.cpp ! src/hotspot/share/jvmci/jvmciCodeInstaller.hpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.hpp ! src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp ! src/hotspot/share/jvmci/jvmciRuntime.cpp ! src/hotspot/share/jvmci/jvmci_globals.cpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp Changeset: 4b4a483b Author: Coleen Phillimore Date: 2024-06-20 19:03:50 +0000 URL: https://git.openjdk.org/loom/commit/4b4a483b6fe7a6fcfdfe6f68faac29099a64c982 8330699: Obsolete -XX:+UseEmptySlotsInSupers Reviewed-by: shade, fparain, dholmes ! src/hotspot/share/classfile/fieldLayoutBuilder.cpp ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp - test/hotspot/jtreg/runtime/FieldLayout/OldLayoutCheck.java Changeset: e5de26dd Author: Jatin Bhateja Date: 2024-06-20 23:35:15 +0000 URL: https://git.openjdk.org/loom/commit/e5de26ddf0550da9e6d074d5b9ab4a943170adca 8329032: C2 compiler register allocation support for APX EGPRs Reviewed-by: kvn, sviswanathan ! src/hotspot/cpu/x86/assembler_x86.cpp ! src/hotspot/cpu/x86/assembler_x86.hpp ! src/hotspot/cpu/x86/c1_Defs_x86.hpp ! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp ! src/hotspot/cpu/x86/c1_Runtime1_x86.cpp ! src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp ! src/hotspot/cpu/x86/gc/x/xBarrierSetAssembler_x86.cpp ! src/hotspot/cpu/x86/globals_x86.hpp ! src/hotspot/cpu/x86/jvmciCodeInstaller_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.cpp ! src/hotspot/cpu/x86/macroAssembler_x86.hpp ! src/hotspot/cpu/x86/methodHandles_x86.cpp ! src/hotspot/cpu/x86/nativeInst_x86.cpp ! src/hotspot/cpu/x86/nativeInst_x86.hpp ! src/hotspot/cpu/x86/register_x86.cpp ! src/hotspot/cpu/x86/register_x86.hpp ! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp ! src/hotspot/cpu/x86/upcallLinker_x86_64.cpp ! src/hotspot/cpu/x86/vm_version_x86.cpp ! src/hotspot/cpu/x86/vm_version_x86.hpp ! src/hotspot/cpu/x86/vmreg_x86.hpp ! src/hotspot/cpu/x86/x86_64.ad ! src/hotspot/os/windows/os_windows.cpp ! src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp ! src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/amd64/AMD64.java Changeset: 880e458a Author: Vladimir Kozlov Date: 2024-06-21 00:24:55 +0000 URL: https://git.openjdk.org/loom/commit/880e458a1072589ae199cc9204dcce9eab0f4eaa 8333819: Move embedded external addresses from relocation info into separate global table Reviewed-by: dlong ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/code/nmethod.hpp ! src/hotspot/share/code/oopRecorder.cpp ! src/hotspot/share/code/oopRecorder.hpp ! src/hotspot/share/code/relocInfo.cpp ! src/hotspot/share/runtime/init.cpp ! src/hotspot/share/runtime/mutexLocker.cpp ! src/hotspot/share/runtime/mutexLocker.hpp Changeset: 6a5cb0b2 Author: Matthias Baesken Date: 2024-06-21 07:04:26 +0000 URL: https://git.openjdk.org/loom/commit/6a5cb0b2c49cb390ce8b87fd977ee79572df90fc 8334567: [test] runtime/os/TestTracePageSizes move ppc handling Reviewed-by: stuefe, lucy ! test/hotspot/jtreg/runtime/os/TestTracePageSizes.java Changeset: bdd96604 Author: Erik Gahlin Date: 2024-06-21 07:36:02 +0000 URL: https://git.openjdk.org/loom/commit/bdd96604ae55ba0cd3cd3363e2ba44205d8aa3aa 8323196: jdk/jfr/api/consumer/filestream/TestOrdered.java failed with "Events are not ordered! Reuse = false" Reviewed-by: mgronlun ! test/jdk/jdk/jfr/api/consumer/filestream/TestOrdered.java Changeset: ed149062 Author: Matthias Baesken Date: 2024-06-21 08:38:42 +0000 URL: https://git.openjdk.org/loom/commit/ed149062d0e8407710f083aa85d28d27c4a45ecc 8333361: ubsan,test : libHeapMonitorTest.cpp:518:9: runtime error: null pointer passed as argument 2, which is declared to never be null Reviewed-by: asteiner, lucy, amenkov ! test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/libHeapMonitorTest.cpp Changeset: d2bebffb Author: Daniel Fuchs Date: 2024-06-21 09:43:49 +0000 URL: https://git.openjdk.org/loom/commit/d2bebffb1fd26fae4526afd33a818ee776b7102e 8327370: (ch) sun.nio.ch.Poller.register throws AssertionError Co-authored-by: Alan Bateman Reviewed-by: alanb, jpai, djelinski ! src/java.base/share/classes/sun/nio/ch/Poller.java Changeset: 711e7238 Author: Tejesh R Date: 2024-06-21 10:36:05 +0000 URL: https://git.openjdk.org/loom/commit/711e7238196a4ef9211ed4cca15c7c1d774df019 6967482: TAB-key does not work in JTables after selecting details-view in JFileChooser 8166352: FilePane.createDetailsView() removes JTable TAB, SHIFT-TAB functionality Reviewed-by: achung, prr ! src/java.desktop/share/classes/sun/swing/FilePane.java + test/jdk/javax/swing/JFileChooser/TABTestONFCExit.java Changeset: 08ace27d Author: Archie Cobbs Committer: Jan Lahoda Date: 2024-06-21 10:44:51 +0000 URL: https://git.openjdk.org/loom/commit/08ace27da1d9cd215c77471eabf41417ff6282d2 8332314: Add window size configuration option to JavaShellToolBuilder interface Reviewed-by: jlahoda ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java ! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellToolBuilder.java ! src/jdk.jshell/share/classes/jdk/jshell/tool/JavaShellToolBuilder.java Changeset: dbf5a9a4 Author: Doug Simon Date: 2024-06-21 13:43:03 +0000 URL: https://git.openjdk.org/loom/commit/dbf5a9a4006020ddebcce89692ce8826b6b2db46 8334706: [JVMCI] APX registers incorrectly exposed on AMD64 Reviewed-by: yzheng, never ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/amd64/AMD64.java ! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/code/Architecture.java Changeset: 9f8de221 Author: Kevin Walls Date: 2024-06-21 13:51:06 +0000 URL: https://git.openjdk.org/loom/commit/9f8de221d7f0186718411ab3f5217e3883237e84 8327793: Deprecate jstatd for removal Reviewed-by: alanb, cjplummer ! src/jdk.jstatd/share/classes/module-info.java ! src/jdk.jstatd/share/classes/sun/tools/jstatd/Jstatd.java ! test/jdk/sun/tools/jstatd/JstatdTest.java Changeset: 75bea280 Author: Ferenc Rakoczi Committer: Weijun Wang Date: 2024-06-21 14:16:23 +0000 URL: https://git.openjdk.org/loom/commit/75bea280b9adb6dac9fefafbb3f4b212f100fbb5 8333867: SHA3 performance can be improved Reviewed-by: kvn, valeriep ! src/hotspot/share/opto/library_call.cpp ! src/java.base/share/classes/sun/security/provider/DigestBase.java ! src/java.base/share/classes/sun/security/provider/SHA3.java Changeset: c41293a7 Author: Jie Fu Date: 2024-06-21 14:23:38 +0000 URL: https://git.openjdk.org/loom/commit/c41293a70834a79c79e859ebcdb8869884ac87dc 8334695: Fix build failure without zgc after JDK-8333300 Reviewed-by: dnsimon, chagedorn ! src/hotspot/cpu/x86/jvmciCodeInstaller_x86.cpp ! src/hotspot/share/jvmci/jvmciCompilerToVM.hpp ! src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp ! src/hotspot/share/jvmci/vmStructs_jvmci.cpp Changeset: 93d98027 Author: SendaoYan Committer: Amit Kumar Date: 2024-06-21 15:48:38 +0000 URL: https://git.openjdk.org/loom/commit/93d98027649615afeeeb6a9510230d9655a74a8f 8334715: [riscv] Mixed use of tab and whitespace in riscv.ad Reviewed-by: chagedorn, amitkumar ! src/hotspot/cpu/riscv/riscv.ad Changeset: 8e1d2b09 Author: Rajan Halade Date: 2024-06-21 16:37:57 +0000 URL: https://git.openjdk.org/loom/commit/8e1d2b091c9a311d98a0b886a803fb18d4405d8a 8334441: Mark tests in jdk_security_infra group as manual Reviewed-by: clanger, mullan ! test/jdk/ProblemList.txt ! test/jdk/TEST.groups ! test/jdk/security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java ! test/jdk/security/infra/java/security/cert/CertPathValidator/certification/CertignaCA.java ! test/jdk/security/infra/java/security/cert/CertPathValidator/certification/DTrustCA.java ! test/jdk/security/infra/java/security/cert/CertPathValidator/certification/DigicertCSRootG5.java ! test/jdk/security/infra/java/security/cert/CertPathValidator/certification/EmSignRootG2CA.java ! test/jdk/security/infra/java/security/cert/CertPathValidator/certification/HaricaCA.java ! test/jdk/security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java ! test/jdk/security/infra/javax/net/ssl/HttpsURLConnectionTest.java Changeset: 689cee3d Author: Prasanta Sadhukhan Date: 2024-06-21 18:02:57 +0000 URL: https://git.openjdk.org/loom/commit/689cee3d0950e15e88a1f6738bfded00655dca9c 8334509: Cancelling PageDialog does not return the same PageFormat object Reviewed-by: aivanov, prr ! src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp + test/jdk/java/awt/print/PrinterJob/PageDialogCancelTest.java Changeset: 1ff5acda Author: Nizar Benalla Committer: Phil Race Date: 2024-06-21 20:13:26 +0000 URL: https://git.openjdk.org/loom/commit/1ff5acdafff1ccd3e64c70eebbfbff75e0d783eb 8332099: since-checker - Add @ since to package-info in jdk.jsobject Reviewed-by: prr ! src/jdk.jsobject/share/classes/netscape/javascript/package-info.java Changeset: 7e55ed3b Author: Chen Liang Date: 2024-06-21 22:38:38 +0000 URL: https://git.openjdk.org/loom/commit/7e55ed3b106ed08956d2d38b7c99fb81704667c9 8333748: javap crash - Fatal error: Unmatched bit position 0x2 for location CLASS Reviewed-by: asotona ! src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/BasicWriter.java ! src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java + test/langtools/tools/javap/UndefinedAccessFlagTest.java From hepin.p at alibaba-inc.com Sun Jun 23 08:30:18 2024 From: hepin.p at alibaba-inc.com (=?UTF-8?B?5L2V5ZOBKOiZjum4oyk=?=) Date: Sun, 23 Jun 2024 16:30:18 +0800 Subject: =?UTF-8?B?5Zue5aSN77ya5Zue5aSN77yaVmlydHVhbCB0aHJlYWQgaGFuZyBhbmQgYWxsIHRocmVhZHMg?= =?UTF-8?B?c3RvcCBydW5uaW5nIG9uIEpESzIx?= In-Reply-To: <15844001-89d0-4485-a0d4-6952c5fef715@oracle.com> References: <15844001-89d0-4485-a0d4-6952c5fef715@oracle.com> Message-ID: Thanks for the clarification ------------------------------------------------------------------ ????Alan Bateman ?????2024?6?22?(???) 17:22 ????masoud parvari; "??(??)" ????"loom-dev" ????Re: ???Virtual thread hang and all threads stop running on JDK21 On 22/06/2024 09:54, masoud parvari wrote: In class loading/initialization cases, the underlying issue is that pinning happens because there are native frames in the stack, so replacing the synchronized with a j.u.c lock will still lead to the same issue. That's right, and there are a couple of scenarios there, to be looked into after the object monitor issues are out of the way. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.swift at gmail.com Mon Jun 24 15:53:37 2024 From: matthew.swift at gmail.com (Matthew Swift) Date: Mon, 24 Jun 2024 17:53:37 +0200 Subject: Experience of adding JDK21 virtual thread support to a DB application In-Reply-To: References: Message-ID: Good point about the FJ related noise. I hadn't thought of that. There's probably a wider question of which thread "park" events are considered to be contention or not. Clearly a thread waiting to poll something from a blocking queue isn't experiencing contention, nor is a thread waiting on a CountDownLatch. A thread waiting to acquire a Semaphore may be considered to be contended, similar to a ReentrantLock (is a blocked call to LinkedBlockingQueue#put() contention?). In other words, despite understanding why the JFR "contention" views only consider intrinsic locks, as a user I still feel that the names of the views are a bit misleading, given that they only summarize a subset of the contention in an application. Cheers, Matt On Fri, 21 Jun 2024 at 18:51, robert engels wrote: > I agree that I don?t think JFR is intelligent about the locks. > > Maybe create your own sub-class of ReentrentLock and emit custom JFR > events? > > Otherwise there appears to be too much noise with the Fork-Join pool. > > ... > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.swift at gmail.com Mon Jun 24 15:58:50 2024 From: matthew.swift at gmail.com (Matthew Swift) Date: Mon, 24 Jun 2024 17:58:50 +0200 Subject: Experience of adding JDK21 virtual thread support to a DB application In-Reply-To: <56b44eca-ae6f-4168-884c-7b1a2a29955e@oracle.com> References: <56b44eca-ae6f-4168-884c-7b1a2a29955e@oracle.com> Message-ID: It looks like AbstractQueuedSynchronizer#acquire(...) does appear to do some spinning IIUC, but it's probably quite different to the spinning strategy used by contended monitors. I'm just guessing though. On Fri, 21 Jun 2024 at 20:45, Alan Bateman wrote: > > > On 21/06/2024 16:57, Matthew Swift wrote: > > : > > > > These results are on my laptop (Intel i9-13900H with 10 cores, Linux > > 6.5, JDK 21.0.3), but we see similar regressions on larger older > > machines in our labs. Also worthy of note is that the context > > switching rate increases from around 180K/s when using synchronized() > > to 300K/s when using ReentrantLock. I know that ReentrantLock is > > supposed to be a little bit less efficient in highly contended > > situations, but I was surprised by an 8-10% impact. Is that expected? > > One thing that might be part of this is that a contented monitor enter > does a small amount of spinning. Sergey Kuksenko may have some comments > on this as he has some proposals on this at one point. > > -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.swift at gmail.com Mon Jun 24 17:05:17 2024 From: matthew.swift at gmail.com (Matthew Swift) Date: Mon, 24 Jun 2024 19:05:17 +0200 Subject: Experience using virtual threads in EA 23-loom+4-102 In-Reply-To: <6A9FDAD8-3507-4952-A47C-B8CC57C8AD2E@ix.netcom.com> References: <6A9FDAD8-3507-4952-A47C-B8CC57C8AD2E@ix.netcom.com> Message-ID: Thanks Robert. The main issue we face with our application is that the client load can vary substantially over time. For example, we might experience a lot of CPU intensive authentication traffic (e.g. PBKDF2 hashing) in the morning, but then a lot of IO bound traffic at other times. It's hard to find the ideal number of worker threads: many threads work well for IO bound traffic, as you say, but sacrifices performance when the load is more CPU bound. On my 10 core (20 hyper threads) laptop, I observe nearly a 15-20% drop in throughput when subjecting the server to 1200 concurrent CPU bound requests, but a much smaller drop when using virtual threads: * 10 platform threads: ~260K requests/s (note: this is too few threads for more IO bound traffic) * 40 platform threads: ~220K requests/s * 1200 platform threads: ~220K requests/s (note: this would be the equivalent of a one platform thread per request) * virtual threads: 252K requests/s (note: FJ pool defaults to 20 on my laptop - I didn't try disabling hyperthreading). I find the "one size fits all" provided by virtual threads to be much easier for developers and our users alike. I don't have to worry about complex architectures involving split thread pools (one for CPU, one for IO), etc. We also have to deal with slow misbehaving clients, which has meant use of async IO and hard to debug call-back hell :-) All of this goes away with virtual threads as it will allow us to use simpler blocking network IO and a simple one thread per request design that is much more tolerant to heterogeneous traffic patterns. It also opens up the possibility of future enhancements that would definitely shine with virtual threads as you suggest. For example, modern hashing algorithms, such as Argon2, can take hundreds of milliseconds of computation, which is simply too costly to scale horizontally in the data layer. We want to offload this to an external elastic compute service, but we could very quickly have thousands of blocked platform threads with response times this high. Cheers, Matt On Fri, 21 Jun 2024 at 19:29, robert engels wrote: > Hi, > > Just an fyi, until you get into the order of 1k, 10k, etc. concurrent > clients - I would expect platform threads to outperform virtual threads by > quite a bit (best case be the same). Modern OS?s routinely handle thousands > of active threads. (My OSX desktop with 4 true cores has nearly 5k threads > running). > > Also, if you can saturate your CPUs or local IO bus, adding more threads > isn?t going to help. VirtualThreads shine when the request handler is > fanning out to multiple remote services. > > Regards, > Robert > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.swift at gmail.com Mon Jun 24 17:24:27 2024 From: matthew.swift at gmail.com (Matthew Swift) Date: Mon, 24 Jun 2024 19:24:27 +0200 Subject: Experience using virtual threads in EA 23-loom+4-102 In-Reply-To: References: Message-ID: Hi Alan, Thanks for your reply. Responses inline below... > > > As promised, here is my second (shorter I hope!) email sharing > > feedback on the recent Loom EA build (23-loom+4-102). > > Thank you for taking the time to write down your experiences, this is > exactly the type of feedback that helps. > It's a pleasure. > > > : > > > > ### Experiment #1: read stress test > > For #1 and #2, would it be correct to say that there is a lot of monitor > contention? Your first mail talked about contention in the "multi-index > write stress test" but I can't tell if this corresponds to #2 or #3 in > thesecond mail. > > Sorry if it wasn't clear. Experiment #1 is a read saturation test. There's very little monitor contention and the test is pretty much CPU bound. Experiment #2 corresponds to the multi-index write stress test in my first message. This experiment uses transactions where each txn updates around 60 DB records, some of which are quite hot. The DB txn log critical section is entered for every record update (i.e. 60 times per txn in this test). Experiment #3 is just an extreme version of experiment #2, which updates around 400 DB records per transaction, and therefore enters the txn log critical section ~400 times per txn. > This is currently a performance/latency issue with the unblocking of > virtual threads that were blocked on monitors (or Object.wait). That is > being looked into and may contribute to some of what you are seeing. > > Ok, that's great to hear. I'd be interested in testing any more EA builds that attempt to address this. > > ... > > > > > > : > > > > The outliers with virtual threads are much much higher. Could this be > > due to potential starvation when rescheduling virtual threads in the > > fork join pool? > > > It's hard to say. The current EA builds doesn't have the final > ForkJoinPool change that went into JDK 23, we'll refresh the EA build > soon. Another thing is that virtual threads that were blocked on a > monitor are pushed to an unowned submission queue so they may not > continue immediately if it a lot of other virtual thread > parking/unparking going on - this might change with the monitor > unblocking perf issue I mentioned. Another possibility is that > unfairness that can happen when many threads are trying to enter. In > your EA builds then the output from `jcmd > Thread.vthread_scheduler` might help as it shows a count of the number > of tasks (=threads) in the submission queues. > > I reran the test and executed the above command once per second for 10 seconds: $ for i in 1 2 3 4 5 6 7 8 9 10; do jcmd DirectoryServer Thread.vthread_scheduler; sleep 1; done 110886: java.util.concurrent.ForkJoinPool at 3a7204cd[Running, parallelism = 20, size = 20, active = 13, running = 0, steals = 17676052, tasks = 0, submissions = 0] 110886: java.util.concurrent.ForkJoinPool at 3a7204cd[Running, parallelism = 20, size = 20, active = 16, running = 0, steals = 17784106, tasks = 1, submissions = 0] 110886: java.util.concurrent.ForkJoinPool at 3a7204cd[Running, parallelism = 20, size = 20, active = 20, running = 1, steals = 17887000, tasks = 1, submissions = 0] 110886: java.util.concurrent.ForkJoinPool at 3a7204cd[Running, parallelism = 20, size = 20, active = 15, running = 1, steals = 17984238, tasks = 1, submissions = 0] 110886: java.util.concurrent.ForkJoinPool at 3a7204cd[Running, parallelism = 20, size = 20, active = 9, running = 0, steals = 18082247, tasks = 0, submissions = 0] 110886: java.util.concurrent.ForkJoinPool at 3a7204cd[Running, parallelism = 20, size = 20, active = 9, running = 0, steals = 18201916, tasks = 0, submissions = 0] 110886: java.util.concurrent.ForkJoinPool at 3a7204cd[Running, parallelism = 20, size = 20, active = 20, running = 0, steals = 18302449, tasks = 2, submissions = 0] 110886: java.util.concurrent.ForkJoinPool at 3a7204cd[Running, parallelism = 20, size = 20, active = 1, running = 0, steals = 18416910, tasks = 0, submissions = 0] 110886: java.util.concurrent.ForkJoinPool at 3a7204cd[Running, parallelism = 20, size = 20, active = 13, running = 0, steals = 18516576, tasks = 0, submissions = 0] 110886: java.util.concurrent.ForkJoinPool at 3a7204cd[Running, parallelism = 20, size = 20, active = 14, running = 0, steals = 18602916, tasks = 0, submissions = 0] I won't pretend to understand what this means :-) Cheers, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at icloud.com Mon Jun 24 20:12:45 2024 From: robaho at icloud.com (Robert Engels) Date: Mon, 24 Jun 2024 15:12:45 -0500 Subject: Experience using virtual threads in EA 23-loom+4-102 In-Reply-To: References: <6A9FDAD8-3507-4952-A47C-B8CC57C8AD2E@ix.netcom.com> Message-ID: <11DD9614-B571-45E9-9C33-EBB9279E7663@icloud.com> I still think it might be helpful to use virtual threads for all connections (simplicity!) - but when to perform the cpu intensive work like hashing, put a callable/future on a ?cpu only? executor with a capped number of platform threads and join(). It should be a trivial refactor of the code. The problem with using VT for everything is that a VT is not time-sliced, so you could quickly consume all of the carrier threads and then you make no progress on the IO (fan out) requests - which is especially bad if they are simply calling out to other servers (less bad if doing lots of local disk io). > On Jun 24, 2024, at 12:05 PM, Matthew Swift wrote: > > Thanks Robert. > > The main issue we face with our application is that the client load can vary substantially over time. For example, we might experience a lot of CPU intensive authentication traffic (e.g. PBKDF2 hashing) in the morning, but then a lot of IO bound traffic at other times. It's hard to find the ideal number of worker threads: many threads work well for IO bound traffic, as you say, but sacrifices performance when the load is more CPU bound. On my 10 core (20 hyper threads) laptop, I observe nearly a 15-20% drop in throughput when subjecting the server to 1200 concurrent CPU bound requests, but a much smaller drop when using virtual threads: > > * 10 platform threads: ~260K requests/s (note: this is too few threads for more IO bound traffic) > * 40 platform threads: ~220K requests/s > * 1200 platform threads: ~220K requests/s (note: this would be the equivalent of a one platform thread per request) > * virtual threads: 252K requests/s (note: FJ pool defaults to 20 on my laptop - I didn't try disabling hyperthreading). > > I find the "one size fits all" provided by virtual threads to be much easier for developers and our users alike. I don't have to worry about complex architectures involving split thread pools (one for CPU, one for IO), etc. We also have to deal with slow misbehaving clients, which has meant use of async IO and hard to debug call-back hell :-) All of this goes away with virtual threads as it will allow us to use simpler blocking network IO and a simple one thread per request design that is much more tolerant to heterogeneous traffic patterns. > > It also opens up the possibility of future enhancements that would definitely shine with virtual threads as you suggest. For example, modern hashing algorithms, such as Argon2, can take hundreds of milliseconds of computation, which is simply too costly to scale horizontally in the data layer. We want to offload this to an external elastic compute service, but we could very quickly have thousands of blocked platform threads with response times this high. > > Cheers, > Matt > > > On Fri, 21 Jun 2024 at 19:29, robert engels > wrote: > Hi, > > Just an fyi, until you get into the order of 1k, 10k, etc. concurrent clients - I would expect platform threads to outperform virtual threads by quite a bit (best case be the same). Modern OS?s routinely handle thousands of active threads. (My OSX desktop with 4 true cores has nearly 5k threads running). > > Also, if you can saturate your CPUs or local IO bus, adding more threads isn?t going to help. VirtualThreads shine when the request handler is fanning out to multiple remote services. > > Regards, > Robert > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at me.com Mon Jun 24 22:03:50 2024 From: robaho at me.com (Robert Engels) Date: Mon, 24 Jun 2024 17:03:50 -0500 Subject: Interesting profile session Message-ID: <777E865C-A9CA-46C8-B057-EB9D9448E4DE@me.com> Hi all, I am working on optimizing a web server design for virtual threads. The test essentially hits an endpoint and returns a string. As written, after sending the string it performs a flush() - most likely sending lots of very small tcp packets. The client from another machine uses concurrent overlapping connections. It you look at the attached profile (captured with the Java async profiler), you can see that the vast majority of the time is spent in the scheduler - often waiting for work. ns percent samples top ---------- ------- ------- --- 927730000 17.50% 92773 write 865420000 16.32% 86542 __psynch_cvwait 664940000 12.54% 66494 kevent 532900000 10.05% 53290 swtch_pri 324830000 6.13% 32483 read 221610000 4.18% 22161 __psynch_cvsignal 98940000 1.87% 9894 java.util.concurrent.ForkJoinPool.awaitWork 58630000 1.11% 5863 jdk.internal.misc.Unsafe.park The read & write are expected but I was surprised at how much time is attributed to the scheduler. With the virtual thread per task executor, this represented: Thread Stats Avg Stdev Max +/- Stdev Latency 14.63ms 5.36ms 239.72ms 97.28% Req/Sec 1.12k 140.56 5.07k 89.83% Requests/sec: 71064.54 Transfer/sec: 9.62MB If I configure the server with a pooled platform thread executor of 64 threads, I get: Thread Stats Avg Stdev Max +/- Stdev Latency 0.87ms 2.81ms 403.37ms 99.45% Req/Sec 12.95k 5.09k 24.13k 76.87% Requests/sec: 77251.91 Transfer/sec: 10.46MB The VT latency is a couple of orders of magnitude higher than the platform latency. I suspect that what is happening is that the virtual threads are parking waiting for work too soon - or that the read & writes are always causing a context switch - regardless of if the call is very short (room in the kernel socket buffers). Can you suggest any remedies? It feels like the scheduler needs some heuristics on average call time to determine and a spin loop to avoid this sort of thing. I have attached the VT and platform profiler data. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PastedGraphic-4.png Type: image/png Size: 3607 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PastedGraphic-3.png Type: image/png Size: 6592 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- --- Execution profile --- Total samples : 530212 GC_active : 16 (0.00%) unknown_Java : 7856 (1.48%) skipped : 22 (0.00%) --- 543460000 ns (10.25%), 54346 samples [ 0] kevent [ 1] sun.nio.ch.KQueue.poll [ 2] sun.nio.ch.KQueuePoller.poll [ 3] sun.nio.ch.Poller.poll [ 4] sun.nio.ch.Poller.pollLoop [ 5] sun.nio.ch.Poller$$Lambda.0x00000001340f1b78.run [ 6] java.lang.Thread.runWith [ 7] java.lang.Thread.run [ 8] jdk.internal.misc.InnocuousThread.run --- 532680000 ns (10.05%), 53268 samples [ 0] swtch_pri [ 1] java.lang.Thread.yield0 [ 2] java.lang.Thread.yield [ 3] java.util.concurrent.LinkedTransferQueue.awaitMatch [ 4] java.util.concurrent.LinkedTransferQueue.xfer [ 5] java.util.concurrent.LinkedTransferQueue.take [ 6] sun.nio.ch.Poller.updateLoop [ 7] sun.nio.ch.Poller$$Lambda.0x00000001340f1fb8.run [ 8] java.lang.Thread.runWith [ 9] java.lang.Thread.run [10] jdk.internal.misc.InnocuousThread.run --- 217460000 ns (4.10%), 21746 samples [ 0] write [ 1] sun.nio.ch.SocketDispatcher.write0 [ 2] sun.nio.ch.SocketDispatcher.write [ 3] sun.nio.ch.NioSocketImpl.tryWrite [ 4] sun.nio.ch.NioSocketImpl.implWrite [ 5] sun.nio.ch.NioSocketImpl.write [ 6] sun.nio.ch.NioSocketImpl$2.write [ 7] java.net.Socket$SocketOutputStream.write [ 8] robaho.net.httpserver.HttpConnection$ActivityTimerOutputStream.write [ 9] java.io.BufferedOutputStream.flushBuffer [10] java.io.BufferedOutputStream.implFlush [11] java.io.BufferedOutputStream.flush [12] java.io.FilterOutputStream.flush [13] robaho.net.httpserver.FixedLengthOutputStream.close [14] robaho.net.httpserver.PlaceholderOutputStream.close [15] benchmarks.Server.lambda$createPlaintextHandler$0 [16] benchmarks.Server$$Lambda.0x0000000134004ac0.handle [17] com.sun.net.httpserver.Filter$Chain.doFilter [18] robaho.net.httpserver.AuthFilter.doFilter [19] com.sun.net.httpserver.Filter$Chain.doFilter [20] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [21] com.sun.net.httpserver.Filter$Chain.doFilter [22] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [23] robaho.net.httpserver.ServerImpl$Exchange.run [24] jdk.internal.vm.Continuation.enterSpecial [25] jdk.internal.vm.Continuation.run [26] java.lang.VirtualThread.runContinuation [27] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [28] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [29] java.util.concurrent.ForkJoinTask.doExec [30] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [31] java.util.concurrent.ForkJoinPool.scan [32] java.util.concurrent.ForkJoinPool.runWorker [33] java.util.concurrent.ForkJoinWorkerThread.run --- 202940000 ns (3.83%), 20294 samples [ 0] write [ 1] sun.nio.ch.SocketDispatcher.write0 [ 2] sun.nio.ch.SocketDispatcher.write [ 3] sun.nio.ch.NioSocketImpl.tryWrite [ 4] sun.nio.ch.NioSocketImpl.implWrite [ 5] sun.nio.ch.NioSocketImpl.write [ 6] sun.nio.ch.NioSocketImpl$2.write [ 7] java.net.Socket$SocketOutputStream.write [ 8] robaho.net.httpserver.HttpConnection$ActivityTimerOutputStream.write [ 9] java.io.BufferedOutputStream.flushBuffer [10] java.io.BufferedOutputStream.implFlush [11] java.io.BufferedOutputStream.flush [12] java.io.FilterOutputStream.flush [13] robaho.net.httpserver.FixedLengthOutputStream.close [14] robaho.net.httpserver.PlaceholderOutputStream.close [15] benchmarks.Server.lambda$createPlaintextHandler$0 [16] benchmarks.Server$$Lambda.0x0000000134004ac0.handle [17] com.sun.net.httpserver.Filter$Chain.doFilter [18] robaho.net.httpserver.AuthFilter.doFilter [19] com.sun.net.httpserver.Filter$Chain.doFilter [20] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [21] com.sun.net.httpserver.Filter$Chain.doFilter [22] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [23] robaho.net.httpserver.ServerImpl$Exchange.run [24] jdk.internal.vm.Continuation.enterSpecial [25] jdk.internal.vm.Continuation.run [26] java.lang.VirtualThread.runContinuation [27] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [28] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [29] java.util.concurrent.ForkJoinTask.doExec [30] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [31] java.util.concurrent.ForkJoinPool.scan [32] java.util.concurrent.ForkJoinPool.runWorker [33] java.util.concurrent.ForkJoinWorkerThread.run --- 166830000 ns (3.15%), 16683 samples [ 0] __psynch_cvwait [ 1] Parker::park [ 2] Unsafe_Park [ 3] jdk.internal.misc.Unsafe.park [ 4] java.util.concurrent.locks.LockSupport.park [ 5] java.util.concurrent.LinkedTransferQueue$Node.block [ 6] java.util.concurrent.ForkJoinPool.unmanagedBlock [ 7] java.util.concurrent.ForkJoinPool.managedBlock [ 8] java.util.concurrent.LinkedTransferQueue.awaitMatch [ 9] java.util.concurrent.LinkedTransferQueue.xfer [10] java.util.concurrent.LinkedTransferQueue.take [11] sun.nio.ch.Poller.updateLoop [12] sun.nio.ch.Poller$$Lambda.0x00000001340f1fb8.run [13] java.lang.Thread.runWith [14] java.lang.Thread.run [15] jdk.internal.misc.InnocuousThread.run --- 159630000 ns (3.01%), 15963 samples [ 0] __psynch_cvwait [ 1] Parker::park [ 2] Unsafe_Park [ 3] jdk.internal.misc.Unsafe.park [ 4] java.util.concurrent.locks.LockSupport.park [ 5] java.util.concurrent.ForkJoinPool.awaitWork [ 6] java.util.concurrent.ForkJoinPool.runWorker [ 7] java.util.concurrent.ForkJoinWorkerThread.run --- 143430000 ns (2.71%), 14343 samples [ 0] __psynch_cvwait [ 1] Parker::park [ 2] Unsafe_Park [ 3] jdk.internal.misc.Unsafe.park [ 4] java.util.concurrent.locks.LockSupport.park [ 5] java.util.concurrent.ForkJoinPool.awaitWork [ 6] java.util.concurrent.ForkJoinPool.runWorker [ 7] java.util.concurrent.ForkJoinWorkerThread.run --- 129370000 ns (2.44%), 12937 samples [ 0] write [ 1] sun.nio.ch.SocketDispatcher.write0 [ 2] sun.nio.ch.SocketDispatcher.write [ 3] sun.nio.ch.NioSocketImpl.tryWrite [ 4] sun.nio.ch.NioSocketImpl.implWrite [ 5] sun.nio.ch.NioSocketImpl.write [ 6] sun.nio.ch.NioSocketImpl$2.write [ 7] java.net.Socket$SocketOutputStream.write [ 8] robaho.net.httpserver.HttpConnection$ActivityTimerOutputStream.write [ 9] java.io.BufferedOutputStream.flushBuffer [10] java.io.BufferedOutputStream.implFlush [11] java.io.BufferedOutputStream.flush [12] java.io.FilterOutputStream.flush [13] robaho.net.httpserver.FixedLengthOutputStream.close [14] robaho.net.httpserver.PlaceholderOutputStream.close [15] benchmarks.Server.lambda$createPlaintextHandler$0 [16] benchmarks.Server$$Lambda.0x0000000134004ac0.handle [17] com.sun.net.httpserver.Filter$Chain.doFilter [18] robaho.net.httpserver.AuthFilter.doFilter [19] com.sun.net.httpserver.Filter$Chain.doFilter [20] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [21] com.sun.net.httpserver.Filter$Chain.doFilter [22] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [23] robaho.net.httpserver.ServerImpl$Exchange.run [24] jdk.internal.vm.Continuation.enterSpecial [25] jdk.internal.vm.Continuation.run [26] java.lang.VirtualThread.runContinuation [27] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [28] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [29] java.util.concurrent.ForkJoinTask.doExec [30] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [31] java.util.concurrent.ForkJoinPool.scan [32] java.util.concurrent.ForkJoinPool.runWorker [33] java.util.concurrent.ForkJoinWorkerThread.run --- 121470000 ns (2.29%), 12147 samples [ 0] kevent [ 1] sun.nio.ch.KQueue.register [ 2] sun.nio.ch.KQueuePoller.implRegister [ 3] sun.nio.ch.Poller.updateLoop [ 4] sun.nio.ch.Poller$$Lambda.0x00000001340f1fb8.run [ 5] java.lang.Thread.runWith [ 6] java.lang.Thread.run [ 7] jdk.internal.misc.InnocuousThread.run --- 120730000 ns (2.28%), 12073 samples [ 0] write [ 1] sun.nio.ch.SocketDispatcher.write0 [ 2] sun.nio.ch.SocketDispatcher.write [ 3] sun.nio.ch.NioSocketImpl.tryWrite [ 4] sun.nio.ch.NioSocketImpl.implWrite [ 5] sun.nio.ch.NioSocketImpl.write [ 6] sun.nio.ch.NioSocketImpl$2.write [ 7] java.net.Socket$SocketOutputStream.write [ 8] robaho.net.httpserver.HttpConnection$ActivityTimerOutputStream.write [ 9] java.io.BufferedOutputStream.flushBuffer [10] java.io.BufferedOutputStream.implFlush [11] java.io.BufferedOutputStream.flush [12] java.io.FilterOutputStream.flush [13] robaho.net.httpserver.FixedLengthOutputStream.close [14] robaho.net.httpserver.PlaceholderOutputStream.close [15] benchmarks.Server.lambda$createPlaintextHandler$0 [16] benchmarks.Server$$Lambda.0x0000000134004ac0.handle [17] com.sun.net.httpserver.Filter$Chain.doFilter [18] robaho.net.httpserver.AuthFilter.doFilter [19] com.sun.net.httpserver.Filter$Chain.doFilter [20] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [21] com.sun.net.httpserver.Filter$Chain.doFilter [22] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [23] robaho.net.httpserver.ServerImpl$Exchange.run [24] jdk.internal.vm.Continuation.enterSpecial [25] jdk.internal.vm.Continuation.run [26] java.lang.VirtualThread.runContinuation [27] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [28] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [29] java.util.concurrent.ForkJoinTask.doExec [30] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [31] java.util.concurrent.ForkJoinPool.scan [32] java.util.concurrent.ForkJoinPool.runWorker [33] java.util.concurrent.ForkJoinWorkerThread.run --- 115960000 ns (2.19%), 11596 samples [ 0] write [ 1] sun.nio.ch.SocketDispatcher.write0 [ 2] sun.nio.ch.SocketDispatcher.write [ 3] sun.nio.ch.NioSocketImpl.tryWrite [ 4] sun.nio.ch.NioSocketImpl.implWrite [ 5] sun.nio.ch.NioSocketImpl.write [ 6] sun.nio.ch.NioSocketImpl$2.write [ 7] java.net.Socket$SocketOutputStream.write [ 8] robaho.net.httpserver.HttpConnection$ActivityTimerOutputStream.write [ 9] java.io.BufferedOutputStream.flushBuffer [10] java.io.BufferedOutputStream.implFlush [11] java.io.BufferedOutputStream.flush [12] java.io.FilterOutputStream.flush [13] robaho.net.httpserver.FixedLengthOutputStream.close [14] robaho.net.httpserver.PlaceholderOutputStream.close [15] benchmarks.Server.lambda$createPlaintextHandler$0 [16] benchmarks.Server$$Lambda.0x0000000134004ac0.handle [17] com.sun.net.httpserver.Filter$Chain.doFilter [18] robaho.net.httpserver.AuthFilter.doFilter [19] com.sun.net.httpserver.Filter$Chain.doFilter [20] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [21] com.sun.net.httpserver.Filter$Chain.doFilter [22] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [23] robaho.net.httpserver.ServerImpl$Exchange.run [24] jdk.internal.vm.Continuation.enterSpecial [25] jdk.internal.vm.Continuation.run [26] java.lang.VirtualThread.runContinuation [27] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [28] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [29] java.util.concurrent.ForkJoinTask.doExec [30] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [31] java.util.concurrent.ForkJoinPool.scan [32] java.util.concurrent.ForkJoinPool.runWorker [33] java.util.concurrent.ForkJoinWorkerThread.run --- 115070000 ns (2.17%), 11507 samples [ 0] write [ 1] sun.nio.ch.SocketDispatcher.write0 [ 2] sun.nio.ch.SocketDispatcher.write [ 3] sun.nio.ch.NioSocketImpl.tryWrite [ 4] sun.nio.ch.NioSocketImpl.implWrite [ 5] sun.nio.ch.NioSocketImpl.write [ 6] sun.nio.ch.NioSocketImpl$2.write [ 7] java.net.Socket$SocketOutputStream.write [ 8] robaho.net.httpserver.HttpConnection$ActivityTimerOutputStream.write [ 9] java.io.BufferedOutputStream.flushBuffer [10] java.io.BufferedOutputStream.implFlush [11] java.io.BufferedOutputStream.flush [12] java.io.FilterOutputStream.flush [13] robaho.net.httpserver.FixedLengthOutputStream.close [14] robaho.net.httpserver.PlaceholderOutputStream.close [15] benchmarks.Server.lambda$createPlaintextHandler$0 [16] benchmarks.Server$$Lambda.0x0000000134004ac0.handle [17] com.sun.net.httpserver.Filter$Chain.doFilter [18] robaho.net.httpserver.AuthFilter.doFilter [19] com.sun.net.httpserver.Filter$Chain.doFilter [20] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [21] com.sun.net.httpserver.Filter$Chain.doFilter [22] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [23] robaho.net.httpserver.ServerImpl$Exchange.run [24] jdk.internal.vm.Continuation.enterSpecial [25] jdk.internal.vm.Continuation.run [26] java.lang.VirtualThread.runContinuation [27] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [28] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [29] java.util.concurrent.ForkJoinTask.doExec [30] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [31] java.util.concurrent.ForkJoinPool.scan [32] java.util.concurrent.ForkJoinPool.runWorker [33] java.util.concurrent.ForkJoinWorkerThread.run --- 99040000 ns (1.87%), 9904 samples [ 0] __psynch_cvwait [ 1] Parker::park [ 2] Unsafe_Park [ 3] jdk.internal.misc.Unsafe.park [ 4] java.util.concurrent.locks.LockSupport.park [ 5] java.util.concurrent.ForkJoinPool.awaitWork [ 6] java.util.concurrent.ForkJoinPool.runWorker [ 7] java.util.concurrent.ForkJoinWorkerThread.run --- 97110000 ns (1.83%), 9711 samples [ 0] __psynch_cvwait [ 1] Parker::park [ 2] Unsafe_Park [ 3] jdk.internal.misc.Unsafe.park [ 4] java.util.concurrent.locks.LockSupport.park [ 5] java.util.concurrent.ForkJoinPool.awaitWork [ 6] java.util.concurrent.ForkJoinPool.runWorker [ 7] java.util.concurrent.ForkJoinWorkerThread.run --- 96660000 ns (1.82%), 9666 samples [ 0] __psynch_cvsignal [ 1] Unsafe_Unpark [ 2] jdk.internal.misc.Unsafe.unpark [ 3] java.util.concurrent.locks.LockSupport.unpark [ 4] java.util.concurrent.ForkJoinPool.signalWork [ 5] java.util.concurrent.ForkJoinPool$WorkQueue.push [ 6] java.util.concurrent.ForkJoinPool.poolSubmit [ 7] java.util.concurrent.ForkJoinPool.execute [ 8] java.lang.VirtualThread.submitRunContinuation [ 9] java.lang.VirtualThread.unpark [10] java.lang.System$2.unparkVirtualThread [11] jdk.internal.misc.VirtualThreads.unpark [12] java.util.concurrent.locks.LockSupport.unpark [13] sun.nio.ch.Poller.wakeup [14] sun.nio.ch.Poller.polled [15] sun.nio.ch.KQueuePoller.poll [16] sun.nio.ch.Poller.poll [17] sun.nio.ch.Poller.pollLoop [18] sun.nio.ch.Poller$$Lambda.0x00000001340f1b78.run [19] java.lang.Thread.runWith [20] java.lang.Thread.run [21] jdk.internal.misc.InnocuousThread.run --- 77830000 ns (1.47%), 7783 samples [ 0] __psynch_cvwait [ 1] Parker::park [ 2] Unsafe_Park [ 3] jdk.internal.misc.Unsafe.park [ 4] java.util.concurrent.locks.LockSupport.park [ 5] java.util.concurrent.ForkJoinPool.awaitWork [ 6] java.util.concurrent.ForkJoinPool.runWorker [ 7] java.util.concurrent.ForkJoinWorkerThread.run --- 77300000 ns (1.46%), 7730 samples [ 0] __psynch_cvwait [ 1] Parker::park [ 2] Unsafe_Park [ 3] jdk.internal.misc.Unsafe.park [ 4] java.util.concurrent.locks.LockSupport.park [ 5] java.util.concurrent.ForkJoinPool.awaitWork [ 6] java.util.concurrent.ForkJoinPool.runWorker [ 7] java.util.concurrent.ForkJoinWorkerThread.run --- 59200000 ns (1.12%), 5920 samples [ 0] read [ 1] sun.nio.ch.SocketDispatcher.read0 [ 2] sun.nio.ch.SocketDispatcher.read [ 3] sun.nio.ch.NioSocketImpl.tryRead [ 4] sun.nio.ch.NioSocketImpl.implRead [ 5] sun.nio.ch.NioSocketImpl.read [ 6] sun.nio.ch.NioSocketImpl$1.read [ 7] java.net.Socket$SocketInputStream.read [ 8] java.io.FilterInputStream.read [ 9] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [10] robaho.net.httpserver.NoSyncBufferedInputStream.fill [11] robaho.net.httpserver.NoSyncBufferedInputStream.read [12] robaho.net.httpserver.Request.readLine [13] robaho.net.httpserver.Request. [14] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [15] robaho.net.httpserver.ServerImpl$Exchange.run [16] jdk.internal.vm.Continuation.enterSpecial [17] jdk.internal.vm.Continuation.run [18] java.lang.VirtualThread.runContinuation [19] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [20] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [21] java.util.concurrent.ForkJoinTask.doExec [22] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [23] java.util.concurrent.ForkJoinPool.scan [24] java.util.concurrent.ForkJoinPool.runWorker [25] java.util.concurrent.ForkJoinWorkerThread.run --- 50520000 ns (0.95%), 5052 samples [ 0] read [ 1] sun.nio.ch.SocketDispatcher.read0 [ 2] sun.nio.ch.SocketDispatcher.read [ 3] sun.nio.ch.NioSocketImpl.tryRead [ 4] sun.nio.ch.NioSocketImpl.implRead [ 5] sun.nio.ch.NioSocketImpl.read [ 6] sun.nio.ch.NioSocketImpl$1.read [ 7] java.net.Socket$SocketInputStream.read [ 8] java.io.FilterInputStream.read [ 9] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [10] robaho.net.httpserver.NoSyncBufferedInputStream.fill [11] robaho.net.httpserver.NoSyncBufferedInputStream.read [12] robaho.net.httpserver.Request.readLine [13] robaho.net.httpserver.Request. [14] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [15] robaho.net.httpserver.ServerImpl$Exchange.run [16] jdk.internal.vm.Continuation.enterSpecial [17] jdk.internal.vm.Continuation.run [18] java.lang.VirtualThread.runContinuation [19] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [20] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [21] java.util.concurrent.ForkJoinTask.doExec [22] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [23] java.util.concurrent.ForkJoinPool.scan [24] java.util.concurrent.ForkJoinPool.runWorker [25] java.util.concurrent.ForkJoinWorkerThread.run --- 39240000 ns (0.74%), 3924 samples [ 0] sun.nio.ch.KQueue.poll [ 1] sun.nio.ch.KQueuePoller.poll [ 2] sun.nio.ch.Poller.poll [ 3] sun.nio.ch.Poller.pollLoop [ 4] sun.nio.ch.Poller$$Lambda.0x00000001340f1b78.run [ 5] java.lang.Thread.runWith [ 6] java.lang.Thread.run [ 7] jdk.internal.misc.InnocuousThread.run --- 38970000 ns (0.74%), 3897 samples [ 0] java.util.concurrent.ForkJoinPool.awaitWork [ 1] java.util.concurrent.ForkJoinPool.runWorker [ 2] java.util.concurrent.ForkJoinWorkerThread.run --- 32670000 ns (0.62%), 3267 samples [ 0] read [ 1] sun.nio.ch.SocketDispatcher.read0 [ 2] sun.nio.ch.SocketDispatcher.read [ 3] sun.nio.ch.NioSocketImpl.tryRead [ 4] sun.nio.ch.NioSocketImpl.implRead [ 5] sun.nio.ch.NioSocketImpl.read [ 6] sun.nio.ch.NioSocketImpl$1.read [ 7] java.net.Socket$SocketInputStream.read [ 8] java.io.FilterInputStream.read [ 9] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [10] robaho.net.httpserver.NoSyncBufferedInputStream.fill [11] robaho.net.httpserver.NoSyncBufferedInputStream.read [12] robaho.net.httpserver.Request.readLine [13] robaho.net.httpserver.Request. [14] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [15] robaho.net.httpserver.ServerImpl$Exchange.run [16] jdk.internal.vm.Continuation.enterSpecial [17] jdk.internal.vm.Continuation.run [18] java.lang.VirtualThread.runContinuation [19] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [20] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [21] java.util.concurrent.ForkJoinTask.doExec [22] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [23] java.util.concurrent.ForkJoinPool.scan [24] java.util.concurrent.ForkJoinPool.runWorker [25] java.util.concurrent.ForkJoinWorkerThread.run --- 31960000 ns (0.60%), 3196 samples [ 0] read [ 1] sun.nio.ch.SocketDispatcher.read0 [ 2] sun.nio.ch.SocketDispatcher.read [ 3] sun.nio.ch.NioSocketImpl.tryRead [ 4] sun.nio.ch.NioSocketImpl.implRead [ 5] sun.nio.ch.NioSocketImpl.read [ 6] sun.nio.ch.NioSocketImpl$1.read [ 7] java.net.Socket$SocketInputStream.read [ 8] java.io.FilterInputStream.read [ 9] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [10] robaho.net.httpserver.NoSyncBufferedInputStream.fill [11] robaho.net.httpserver.NoSyncBufferedInputStream.read [12] robaho.net.httpserver.Request.readLine [13] robaho.net.httpserver.Request. [14] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [15] robaho.net.httpserver.ServerImpl$Exchange.run [16] jdk.internal.vm.Continuation.enterSpecial [17] jdk.internal.vm.Continuation.run [18] java.lang.VirtualThread.runContinuation [19] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [20] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [21] java.util.concurrent.ForkJoinTask.doExec [22] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [23] java.util.concurrent.ForkJoinPool.scan [24] java.util.concurrent.ForkJoinPool.runWorker [25] java.util.concurrent.ForkJoinWorkerThread.run --- 31320000 ns (0.59%), 3132 samples [ 0] read [ 1] sun.nio.ch.SocketDispatcher.read0 [ 2] sun.nio.ch.SocketDispatcher.read [ 3] sun.nio.ch.NioSocketImpl.tryRead [ 4] sun.nio.ch.NioSocketImpl.implRead [ 5] sun.nio.ch.NioSocketImpl.read [ 6] sun.nio.ch.NioSocketImpl$1.read [ 7] java.net.Socket$SocketInputStream.read [ 8] java.io.FilterInputStream.read [ 9] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [10] robaho.net.httpserver.NoSyncBufferedInputStream.fill [11] robaho.net.httpserver.NoSyncBufferedInputStream.read [12] robaho.net.httpserver.Request.readLine [13] robaho.net.httpserver.Request. [14] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [15] robaho.net.httpserver.ServerImpl$Exchange.run [16] jdk.internal.vm.Continuation.enterSpecial [17] jdk.internal.vm.Continuation.run [18] java.lang.VirtualThread.runContinuation [19] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [20] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [21] java.util.concurrent.ForkJoinTask.doExec [22] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [23] java.util.concurrent.ForkJoinPool.scan [24] java.util.concurrent.ForkJoinPool.runWorker [25] java.util.concurrent.ForkJoinWorkerThread.run --- 28890000 ns (0.54%), 2889 samples [ 0] read [ 1] sun.nio.ch.SocketDispatcher.read0 [ 2] sun.nio.ch.SocketDispatcher.read [ 3] sun.nio.ch.NioSocketImpl.tryRead [ 4] sun.nio.ch.NioSocketImpl.implRead [ 5] sun.nio.ch.NioSocketImpl.read [ 6] sun.nio.ch.NioSocketImpl$1.read [ 7] java.net.Socket$SocketInputStream.read [ 8] java.io.FilterInputStream.read [ 9] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [10] robaho.net.httpserver.NoSyncBufferedInputStream.fill [11] robaho.net.httpserver.NoSyncBufferedInputStream.read [12] robaho.net.httpserver.Request.readLine [13] robaho.net.httpserver.Request. [14] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [15] robaho.net.httpserver.ServerImpl$Exchange.run [16] jdk.internal.vm.Continuation.enterSpecial [17] jdk.internal.vm.Continuation.run [18] java.lang.VirtualThread.runContinuation [19] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [20] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [21] java.util.concurrent.ForkJoinTask.doExec [22] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [23] java.util.concurrent.ForkJoinPool.scan [24] java.util.concurrent.ForkJoinPool.runWorker [25] java.util.concurrent.ForkJoinWorkerThread.run --- 22570000 ns (0.43%), 2257 samples [ 0] __psynch_cvsignal [ 1] Unsafe_Unpark [ 2] jdk.internal.misc.Unsafe.unpark [ 3] java.util.concurrent.locks.LockSupport.unpark [ 4] java.util.concurrent.ForkJoinPool.signalWork [ 5] java.util.concurrent.ForkJoinPool.scan [ 6] java.util.concurrent.ForkJoinPool.runWorker [ 7] java.util.concurrent.ForkJoinWorkerThread.run --- 21060000 ns (0.40%), 2106 samples [ 0] jdk.internal.misc.Unsafe.park [ 1] java.util.concurrent.locks.LockSupport.park [ 2] java.util.concurrent.ForkJoinPool.awaitWork [ 3] java.util.concurrent.ForkJoinPool.runWorker [ 4] java.util.concurrent.ForkJoinWorkerThread.run --- 20710000 ns (0.39%), 2071 samples [ 0] read [ 1] sun.nio.ch.SocketDispatcher.read0 [ 2] sun.nio.ch.SocketDispatcher.read [ 3] sun.nio.ch.NioSocketImpl.tryRead [ 4] sun.nio.ch.NioSocketImpl.implRead [ 5] sun.nio.ch.NioSocketImpl.read [ 6] sun.nio.ch.NioSocketImpl$1.read [ 7] java.net.Socket$SocketInputStream.read [ 8] java.io.FilterInputStream.read [ 9] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [10] robaho.net.httpserver.NoSyncBufferedInputStream.fill [11] robaho.net.httpserver.NoSyncBufferedInputStream.read [12] robaho.net.httpserver.Request.readLine [13] robaho.net.httpserver.Request. [14] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [15] robaho.net.httpserver.ServerImpl$Exchange.run [16] jdk.internal.vm.Continuation.enterSpecial [17] jdk.internal.vm.Continuation.run [18] java.lang.VirtualThread.runContinuation [19] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [20] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [21] java.util.concurrent.ForkJoinTask.doExec [22] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [23] java.util.concurrent.ForkJoinPool.scan [24] java.util.concurrent.ForkJoinPool.runWorker [25] java.util.concurrent.ForkJoinWorkerThread.run --- 19720000 ns (0.37%), 1972 samples [ 0] read [ 1] sun.nio.ch.SocketDispatcher.read0 [ 2] sun.nio.ch.SocketDispatcher.read [ 3] sun.nio.ch.NioSocketImpl.tryRead [ 4] sun.nio.ch.NioSocketImpl.implRead [ 5] sun.nio.ch.NioSocketImpl.read [ 6] sun.nio.ch.NioSocketImpl$1.read [ 7] java.net.Socket$SocketInputStream.read [ 8] java.io.FilterInputStream.read [ 9] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [10] robaho.net.httpserver.NoSyncBufferedInputStream.fill [11] robaho.net.httpserver.NoSyncBufferedInputStream.read [12] robaho.net.httpserver.Request.readLine [13] robaho.net.httpserver.Request. [14] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [15] robaho.net.httpserver.ServerImpl$Exchange.run [16] jdk.internal.vm.Continuation.enterSpecial [17] jdk.internal.vm.Continuation.run [18] java.lang.VirtualThread.runContinuation [19] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [20] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [21] java.util.concurrent.ForkJoinTask.doExec [22] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [23] java.util.concurrent.ForkJoinPool.scan [24] java.util.concurrent.ForkJoinPool.runWorker [25] java.util.concurrent.ForkJoinWorkerThread.run --- 18860000 ns (0.36%), 1886 samples [ 0] __psynch_cvsignal [ 1] Unsafe_Unpark [ 2] jdk.internal.misc.Unsafe.unpark [ 3] java.util.concurrent.locks.LockSupport.unpark [ 4] java.util.concurrent.ForkJoinPool.signalWork [ 5] java.util.concurrent.ForkJoinPool.scan [ 6] java.util.concurrent.ForkJoinPool.runWorker [ 7] java.util.concurrent.ForkJoinWorkerThread.run --- 15280000 ns (0.29%), 1528 samples [ 0] java.lang.Thread.yield0 [ 1] java.lang.Thread.yield [ 2] java.util.concurrent.LinkedTransferQueue.awaitMatch [ 3] java.util.concurrent.LinkedTransferQueue.xfer [ 4] java.util.concurrent.LinkedTransferQueue.take [ 5] sun.nio.ch.Poller.updateLoop [ 6] sun.nio.ch.Poller$$Lambda.0x00000001340f1fb8.run [ 7] java.lang.Thread.runWith [ 8] java.lang.Thread.run [ 9] jdk.internal.misc.InnocuousThread.run --- 13490000 ns (0.25%), 1349 samples [ 0] java.util.concurrent.ForkJoinPool.awaitWork [ 1] java.util.concurrent.ForkJoinPool.runWorker [ 2] java.util.concurrent.ForkJoinWorkerThread.run --- 13050000 ns (0.25%), 1305 samples [ 0] __psynch_cvsignal [ 1] Unsafe_Unpark [ 2] jdk.internal.misc.Unsafe.unpark [ 3] java.util.concurrent.locks.LockSupport.unpark [ 4] java.util.concurrent.ForkJoinPool.signalWork [ 5] java.util.concurrent.ForkJoinPool.scan [ 6] java.util.concurrent.ForkJoinPool.runWorker [ 7] java.util.concurrent.ForkJoinWorkerThread.run --- 12910000 ns (0.24%), 1291 samples [ 0] java.util.concurrent.ForkJoinPool.awaitWork [ 1] java.util.concurrent.ForkJoinPool.runWorker [ 2] java.util.concurrent.ForkJoinWorkerThread.run --- 12660000 ns (0.24%), 1266 samples [ 0] sun.nio.ch.Poller.wakeup [ 1] sun.nio.ch.Poller.polled [ 2] sun.nio.ch.KQueuePoller.poll [ 3] sun.nio.ch.Poller.poll [ 4] sun.nio.ch.Poller.pollLoop [ 5] sun.nio.ch.Poller$$Lambda.0x00000001340f1b78.run [ 6] java.lang.Thread.runWith [ 7] java.lang.Thread.run [ 8] jdk.internal.misc.InnocuousThread.run --- 12430000 ns (0.23%), 1243 samples [ 0] __psynch_cvsignal [ 1] Unsafe_Unpark [ 2] jdk.internal.misc.Unsafe.unpark [ 3] java.util.concurrent.locks.LockSupport.unpark [ 4] java.util.concurrent.ForkJoinPool.signalWork [ 5] java.util.concurrent.ForkJoinPool.scan [ 6] java.util.concurrent.ForkJoinPool.runWorker [ 7] java.util.concurrent.ForkJoinWorkerThread.run --- 11820000 ns (0.22%), 1182 samples [ 0] __psynch_cvsignal [ 1] Unsafe_Unpark [ 2] jdk.internal.misc.Unsafe.unpark [ 3] java.util.concurrent.locks.LockSupport.unpark [ 4] java.util.concurrent.ForkJoinPool.signalWork [ 5] java.util.concurrent.ForkJoinPool.scan [ 6] java.util.concurrent.ForkJoinPool.runWorker [ 7] java.util.concurrent.ForkJoinWorkerThread.run --- 11540000 ns (0.22%), 1154 samples [ 0] read [ 1] sun.nio.ch.SocketDispatcher.read0 [ 2] sun.nio.ch.SocketDispatcher.read [ 3] sun.nio.ch.NioSocketImpl.tryRead [ 4] sun.nio.ch.NioSocketImpl.implRead [ 5] sun.nio.ch.NioSocketImpl.read [ 6] sun.nio.ch.NioSocketImpl$1.read [ 7] java.net.Socket$SocketInputStream.read [ 8] java.io.FilterInputStream.read [ 9] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [10] robaho.net.httpserver.NoSyncBufferedInputStream.fill [11] robaho.net.httpserver.NoSyncBufferedInputStream.read [12] robaho.net.httpserver.Request.readLine [13] robaho.net.httpserver.Request. [14] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [15] robaho.net.httpserver.ServerImpl$Exchange.run [16] jdk.internal.vm.Continuation.enterSpecial [17] jdk.internal.vm.Continuation.run [18] java.lang.VirtualThread.runContinuation [19] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [20] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [21] java.util.concurrent.ForkJoinTask.doExec [22] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [23] java.util.concurrent.ForkJoinPool.scan [24] java.util.concurrent.ForkJoinPool.runWorker [25] java.util.concurrent.ForkJoinWorkerThread.run --- 11220000 ns (0.21%), 1122 samples [ 0] __psynch_cvwait [ 1] Parker::park [ 2] Unsafe_Park [ 3] jdk.internal.misc.Unsafe.park [ 4] java.util.concurrent.locks.LockSupport.parkUntil [ 5] java.util.concurrent.ForkJoinPool.awaitWork [ 6] java.util.concurrent.ForkJoinPool.runWorker [ 7] java.util.concurrent.ForkJoinWorkerThread.run --- 10880000 ns (0.21%), 1088 samples [ 0] read [ 1] sun.nio.ch.SocketDispatcher.read0 [ 2] sun.nio.ch.SocketDispatcher.read [ 3] sun.nio.ch.NioSocketImpl.tryRead [ 4] sun.nio.ch.NioSocketImpl.implRead [ 5] sun.nio.ch.NioSocketImpl.read [ 6] sun.nio.ch.NioSocketImpl$1.read [ 7] java.net.Socket$SocketInputStream.read [ 8] java.io.FilterInputStream.read [ 9] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [10] robaho.net.httpserver.NoSyncBufferedInputStream.fill [11] robaho.net.httpserver.NoSyncBufferedInputStream.read [12] robaho.net.httpserver.Request.readLine [13] robaho.net.httpserver.Request. [14] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [15] robaho.net.httpserver.ServerImpl$Exchange.run [16] jdk.internal.vm.Continuation.enterSpecial [17] jdk.internal.vm.Continuation.run [18] java.lang.VirtualThread.runContinuation [19] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [20] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [21] java.util.concurrent.ForkJoinTask.doExec [22] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [23] java.util.concurrent.ForkJoinPool.scan [24] java.util.concurrent.ForkJoinPool.runWorker [25] java.util.concurrent.ForkJoinWorkerThread.run --- 10750000 ns (0.20%), 1075 samples [ 0] read [ 1] sun.nio.ch.SocketDispatcher.read0 [ 2] sun.nio.ch.SocketDispatcher.read [ 3] sun.nio.ch.NioSocketImpl.tryRead [ 4] sun.nio.ch.NioSocketImpl.implRead [ 5] sun.nio.ch.NioSocketImpl.read [ 6] sun.nio.ch.NioSocketImpl$1.read [ 7] java.net.Socket$SocketInputStream.read [ 8] java.io.FilterInputStream.read [ 9] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [10] robaho.net.httpserver.NoSyncBufferedInputStream.fill [11] robaho.net.httpserver.NoSyncBufferedInputStream.read [12] robaho.net.httpserver.Request.readLine [13] robaho.net.httpserver.Request. [14] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [15] robaho.net.httpserver.ServerImpl$Exchange.run [16] jdk.internal.vm.Continuation.enterSpecial [17] jdk.internal.vm.Continuation.run [18] java.lang.VirtualThread.runContinuation [19] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [20] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [21] java.util.concurrent.ForkJoinTask.doExec [22] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [23] java.util.concurrent.ForkJoinPool.scan [24] java.util.concurrent.ForkJoinPool.runWorker [25] java.util.concurrent.ForkJoinWorkerThread.run --- 10730000 ns (0.20%), 1073 samples [ 0] java.util.concurrent.ConcurrentHashMap.tabAt [ 1] java.util.concurrent.ConcurrentHashMap.replaceNode [ 2] java.util.concurrent.ConcurrentHashMap.remove [ 3] sun.nio.ch.Poller.wakeup [ 4] sun.nio.ch.Poller.polled [ 5] sun.nio.ch.KQueuePoller.poll [ 6] sun.nio.ch.Poller.poll [ 7] sun.nio.ch.Poller.pollLoop [ 8] sun.nio.ch.Poller$$Lambda.0x00000001340f1b78.run [ 9] java.lang.Thread.runWith [10] java.lang.Thread.run [11] jdk.internal.misc.InnocuousThread.run --- 10210000 ns (0.19%), 1021 samples [ 0] read [ 1] sun.nio.ch.SocketDispatcher.read0 [ 2] sun.nio.ch.SocketDispatcher.read [ 3] sun.nio.ch.NioSocketImpl.tryRead [ 4] sun.nio.ch.NioSocketImpl.implRead [ 5] sun.nio.ch.NioSocketImpl.read [ 6] sun.nio.ch.NioSocketImpl$1.read [ 7] java.net.Socket$SocketInputStream.read [ 8] java.io.FilterInputStream.read [ 9] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [10] robaho.net.httpserver.NoSyncBufferedInputStream.fill [11] robaho.net.httpserver.NoSyncBufferedInputStream.read [12] robaho.net.httpserver.Request.readLine [13] robaho.net.httpserver.Request. [14] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [15] robaho.net.httpserver.ServerImpl$Exchange.run [16] jdk.internal.vm.Continuation.enterSpecial [17] jdk.internal.vm.Continuation.run [18] java.lang.VirtualThread.runContinuation [19] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [20] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [21] java.util.concurrent.ForkJoinTask.doExec [22] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [23] java.util.concurrent.ForkJoinPool.scan [24] java.util.concurrent.ForkJoinPool.runWorker [25] java.util.concurrent.ForkJoinWorkerThread.run --- 10200000 ns (0.19%), 1020 samples [ 0] __psynch_cvsignal [ 1] Unsafe_Unpark [ 2] jdk.internal.misc.Unsafe.unpark [ 3] java.util.concurrent.locks.LockSupport.unpark [ 4] java.util.concurrent.LinkedTransferQueue$Node.tryMatch [ 5] java.util.concurrent.LinkedTransferQueue.xfer [ 6] java.util.concurrent.LinkedTransferQueue.add [ 7] sun.nio.ch.Poller.registerAsync [ 8] sun.nio.ch.Poller.pollIndirect [ 9] sun.nio.ch.Poller.poll [10] sun.nio.ch.Poller.poll [11] sun.nio.ch.NioSocketImpl.park [12] sun.nio.ch.NioSocketImpl.park [13] sun.nio.ch.NioSocketImpl.implRead [14] sun.nio.ch.NioSocketImpl.read [15] sun.nio.ch.NioSocketImpl$1.read [16] java.net.Socket$SocketInputStream.read [17] java.io.FilterInputStream.read [18] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [19] robaho.net.httpserver.NoSyncBufferedInputStream.fill [20] robaho.net.httpserver.NoSyncBufferedInputStream.read [21] robaho.net.httpserver.Request.readLine [22] robaho.net.httpserver.Request. [23] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [24] robaho.net.httpserver.ServerImpl$Exchange.run [25] jdk.internal.vm.Continuation.enterSpecial [26] jdk.internal.vm.Continuation.run [27] java.lang.VirtualThread.runContinuation [28] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [29] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [30] java.util.concurrent.ForkJoinTask.doExec [31] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [32] java.util.concurrent.ForkJoinPool.scan [33] java.util.concurrent.ForkJoinPool.runWorker [34] java.util.concurrent.ForkJoinWorkerThread.run --- 9630000 ns (0.18%), 963 samples [ 0] jdk.internal.misc.Unsafe.park [ 1] java.util.concurrent.locks.LockSupport.park [ 2] java.util.concurrent.LinkedTransferQueue$Node.block [ 3] java.util.concurrent.ForkJoinPool.unmanagedBlock [ 4] java.util.concurrent.ForkJoinPool.managedBlock [ 5] java.util.concurrent.LinkedTransferQueue.awaitMatch [ 6] java.util.concurrent.LinkedTransferQueue.xfer [ 7] java.util.concurrent.LinkedTransferQueue.take [ 8] sun.nio.ch.Poller.updateLoop [ 9] sun.nio.ch.Poller$$Lambda.0x00000001340f1fb8.run [10] java.lang.Thread.runWith [11] java.lang.Thread.run [12] jdk.internal.misc.InnocuousThread.run --- 9470000 ns (0.18%), 947 samples [ 0] __psynch_cvsignal [ 1] Unsafe_Unpark [ 2] jdk.internal.misc.Unsafe.unpark [ 3] java.util.concurrent.locks.LockSupport.unpark [ 4] java.util.concurrent.ForkJoinPool.signalWork [ 5] java.util.concurrent.ForkJoinPool.scan [ 6] java.util.concurrent.ForkJoinPool.runWorker [ 7] java.util.concurrent.ForkJoinWorkerThread.run --- 9300000 ns (0.18%), 930 samples [ 0] __psynch_cvwait [ 1] Parker::park [ 2] Unsafe_Park [ 3] jdk.internal.misc.Unsafe.park [ 4] java.util.concurrent.locks.LockSupport.parkUntil [ 5] java.util.concurrent.ForkJoinPool.awaitWork [ 6] java.util.concurrent.ForkJoinPool.runWorker [ 7] java.util.concurrent.ForkJoinWorkerThread.run --- 9180000 ns (0.17%), 918 samples [ 0] java.lang.VirtualThread.unpark [ 1] java.lang.System$2.unparkVirtualThread [ 2] jdk.internal.misc.VirtualThreads.unpark [ 3] java.util.concurrent.locks.LockSupport.unpark [ 4] sun.nio.ch.Poller.wakeup [ 5] sun.nio.ch.Poller.polled [ 6] sun.nio.ch.KQueuePoller.poll [ 7] sun.nio.ch.Poller.poll [ 8] sun.nio.ch.Poller.pollLoop [ 9] sun.nio.ch.Poller$$Lambda.0x00000001340f1b78.run [10] java.lang.Thread.runWith [11] java.lang.Thread.run [12] jdk.internal.misc.InnocuousThread.run --- 8520000 ns (0.16%), 852 samples [ 0] java.util.concurrent.ForkJoinPool.awaitWork [ 1] java.util.concurrent.ForkJoinPool.runWorker [ 2] java.util.concurrent.ForkJoinWorkerThread.run --- 8510000 ns (0.16%), 851 samples [ 0] java.util.concurrent.ForkJoinPool.awaitWork [ 1] java.util.concurrent.ForkJoinPool.runWorker [ 2] java.util.concurrent.ForkJoinWorkerThread.run --- 7490000 ns (0.14%), 749 samples [ 0] _platform_memmove$VARIANT$Haswell [ 1] Thaw >::thaw_fast [ 2] long* thaw > [ 3] Cont thaw [ 4] [unknown_Java] --- 6640000 ns (0.13%), 664 samples [ 0] __psynch_cvsignal [ 1] Unsafe_Unpark [ 2] jdk.internal.misc.Unsafe.unpark [ 3] java.util.concurrent.locks.LockSupport.unpark [ 4] java.util.concurrent.LinkedTransferQueue$Node.tryMatch [ 5] java.util.concurrent.LinkedTransferQueue.xfer [ 6] java.util.concurrent.LinkedTransferQueue.add [ 7] sun.nio.ch.Poller.registerAsync [ 8] sun.nio.ch.Poller.pollIndirect [ 9] sun.nio.ch.Poller.poll [10] sun.nio.ch.Poller.poll [11] sun.nio.ch.NioSocketImpl.park [12] sun.nio.ch.NioSocketImpl.park [13] sun.nio.ch.NioSocketImpl.implRead [14] sun.nio.ch.NioSocketImpl.read [15] sun.nio.ch.NioSocketImpl$1.read [16] java.net.Socket$SocketInputStream.read [17] java.io.FilterInputStream.read [18] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [19] robaho.net.httpserver.NoSyncBufferedInputStream.fill [20] robaho.net.httpserver.NoSyncBufferedInputStream.read [21] robaho.net.httpserver.Request.readLine [22] robaho.net.httpserver.Request. [23] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [24] robaho.net.httpserver.ServerImpl$Exchange.run [25] jdk.internal.vm.Continuation.enterSpecial [26] jdk.internal.vm.Continuation.run [27] java.lang.VirtualThread.runContinuation [28] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [29] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [30] java.util.concurrent.ForkJoinTask.doExec [31] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [32] java.util.concurrent.ForkJoinPool.scan [33] java.util.concurrent.ForkJoinPool.runWorker [34] java.util.concurrent.ForkJoinWorkerThread.run --- 6550000 ns (0.12%), 655 samples [ 0] Continuation::prepare_thaw [ 1] Cont thaw [ 2] [unknown_Java] --- 6240000 ns (0.12%), 624 samples [ 0] __psynch_cvsignal [ 1] Unsafe_Unpark [ 2] jdk.internal.misc.Unsafe.unpark [ 3] java.util.concurrent.locks.LockSupport.unpark [ 4] java.util.concurrent.LinkedTransferQueue$Node.tryMatch [ 5] java.util.concurrent.LinkedTransferQueue.xfer [ 6] java.util.concurrent.LinkedTransferQueue.add [ 7] sun.nio.ch.Poller.registerAsync [ 8] sun.nio.ch.Poller.pollIndirect [ 9] sun.nio.ch.Poller.poll [10] sun.nio.ch.Poller.poll [11] sun.nio.ch.NioSocketImpl.park [12] sun.nio.ch.NioSocketImpl.park [13] sun.nio.ch.NioSocketImpl.implRead [14] sun.nio.ch.NioSocketImpl.read [15] sun.nio.ch.NioSocketImpl$1.read [16] java.net.Socket$SocketInputStream.read [17] java.io.FilterInputStream.read [18] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [19] robaho.net.httpserver.NoSyncBufferedInputStream.fill [20] robaho.net.httpserver.NoSyncBufferedInputStream.read [21] robaho.net.httpserver.Request.readLine [22] robaho.net.httpserver.Request. [23] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [24] robaho.net.httpserver.ServerImpl$Exchange.run [25] jdk.internal.vm.Continuation.enterSpecial [26] jdk.internal.vm.Continuation.run [27] java.lang.VirtualThread.runContinuation [28] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [29] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [30] java.util.concurrent.ForkJoinTask.doExec [31] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [32] java.util.concurrent.ForkJoinPool.scan [33] java.util.concurrent.ForkJoinPool.runWorker [34] java.util.concurrent.ForkJoinWorkerThread.run --- 6150000 ns (0.12%), 615 samples [ 0] jdk.internal.misc.Unsafe.park [ 1] java.util.concurrent.locks.LockSupport.park [ 2] java.util.concurrent.ForkJoinPool.awaitWork [ 3] java.util.concurrent.ForkJoinPool.runWorker [ 4] java.util.concurrent.ForkJoinWorkerThread.run --- 6150000 ns (0.12%), 615 samples [ 0] __psynch_cvwait [ 1] Parker::park [ 2] Unsafe_Park [ 3] jdk.internal.misc.Unsafe.park [ 4] java.util.concurrent.locks.LockSupport.parkUntil [ 5] java.util.concurrent.ForkJoinPool.awaitWork [ 6] java.util.concurrent.ForkJoinPool.runWorker [ 7] java.util.concurrent.ForkJoinWorkerThread.run --- 6000000 ns (0.11%), 600 samples [ 0] jdk.internal.misc.Unsafe.park [ 1] java.util.concurrent.locks.LockSupport.park [ 2] java.util.concurrent.ForkJoinPool.awaitWork [ 3] java.util.concurrent.ForkJoinPool.runWorker [ 4] java.util.concurrent.ForkJoinWorkerThread.run --- 5930000 ns (0.11%), 593 samples [ 0] __psynch_cvwait [ 1] Parker::park [ 2] Unsafe_Park [ 3] jdk.internal.misc.Unsafe.park [ 4] java.util.concurrent.locks.LockSupport.parkUntil [ 5] java.util.concurrent.ForkJoinPool.awaitWork [ 6] java.util.concurrent.ForkJoinPool.runWorker [ 7] java.util.concurrent.ForkJoinWorkerThread.run --- 5830000 ns (0.11%), 583 samples [ 0] jdk.internal.misc.Unsafe.park [ 1] java.util.concurrent.locks.LockSupport.park [ 2] java.util.concurrent.ForkJoinPool.awaitWork [ 3] java.util.concurrent.ForkJoinPool.runWorker [ 4] java.util.concurrent.ForkJoinWorkerThread.run --- 5800000 ns (0.11%), 580 samples [ 0] write [ 1] sun.nio.ch.SocketDispatcher.write0 [ 2] sun.nio.ch.SocketDispatcher.write [ 3] sun.nio.ch.NioSocketImpl.tryWrite [ 4] sun.nio.ch.NioSocketImpl.implWrite [ 5] sun.nio.ch.NioSocketImpl.write [ 6] sun.nio.ch.NioSocketImpl$2.write [ 7] java.net.Socket$SocketOutputStream.write [ 8] robaho.net.httpserver.HttpConnection$ActivityTimerOutputStream.write [ 9] java.io.BufferedOutputStream.flushBuffer [10] java.io.BufferedOutputStream.implFlush [11] java.io.BufferedOutputStream.flush [12] java.io.FilterOutputStream.flush [13] robaho.net.httpserver.FixedLengthOutputStream.close [14] robaho.net.httpserver.PlaceholderOutputStream.close [15] benchmarks.Server.lambda$createPlaintextHandler$0 [16] benchmarks.Server$$Lambda.0x0000000134004ac0.handle [17] com.sun.net.httpserver.Filter$Chain.doFilter [18] robaho.net.httpserver.AuthFilter.doFilter [19] com.sun.net.httpserver.Filter$Chain.doFilter [20] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [21] com.sun.net.httpserver.Filter$Chain.doFilter [22] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [23] jdk.internal.vm.Continuation.enterSpecial [24] jdk.internal.vm.Continuation.run [25] java.lang.VirtualThread.runContinuation [26] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [27] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [28] java.util.concurrent.ForkJoinTask.doExec [29] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [30] java.util.concurrent.ForkJoinPool.scan [31] java.util.concurrent.ForkJoinPool.runWorker [32] java.util.concurrent.ForkJoinWorkerThread.run --- 5780000 ns (0.11%), 578 samples [ 0] write [ 1] sun.nio.ch.SocketDispatcher.write0 [ 2] sun.nio.ch.SocketDispatcher.write [ 3] sun.nio.ch.NioSocketImpl.tryWrite [ 4] sun.nio.ch.NioSocketImpl.implWrite [ 5] sun.nio.ch.NioSocketImpl.write [ 6] sun.nio.ch.NioSocketImpl$2.write [ 7] java.net.Socket$SocketOutputStream.write [ 8] robaho.net.httpserver.HttpConnection$ActivityTimerOutputStream.write [ 9] java.io.BufferedOutputStream.flushBuffer [10] java.io.BufferedOutputStream.implFlush [11] java.io.BufferedOutputStream.flush [12] java.io.FilterOutputStream.flush [13] robaho.net.httpserver.FixedLengthOutputStream.close [14] robaho.net.httpserver.PlaceholderOutputStream.close [15] benchmarks.Server.lambda$createPlaintextHandler$0 [16] benchmarks.Server$$Lambda.0x0000000134004ac0.handle [17] com.sun.net.httpserver.Filter$Chain.doFilter [18] robaho.net.httpserver.AuthFilter.doFilter [19] com.sun.net.httpserver.Filter$Chain.doFilter [20] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [21] com.sun.net.httpserver.Filter$Chain.doFilter [22] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [23] jdk.internal.vm.Continuation.enterSpecial [24] jdk.internal.vm.Continuation.run [25] java.lang.VirtualThread.runContinuation [26] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [27] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [28] java.util.concurrent.ForkJoinTask.doExec [29] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [30] java.util.concurrent.ForkJoinPool.scan [31] java.util.concurrent.ForkJoinPool.runWorker [32] java.util.concurrent.ForkJoinWorkerThread.run --- 5450000 ns (0.10%), 545 samples [ 0] java.util.concurrent.ForkJoinPool.scan [ 1] java.util.concurrent.ForkJoinPool.runWorker [ 2] java.util.concurrent.ForkJoinWorkerThread.run --- 5430000 ns (0.10%), 543 samples [ 0] __psynch_cvsignal [ 1] Unsafe_Unpark [ 2] jdk.internal.misc.Unsafe.unpark [ 3] java.util.concurrent.locks.LockSupport.unpark [ 4] java.util.concurrent.LinkedTransferQueue$Node.tryMatch [ 5] java.util.concurrent.LinkedTransferQueue.xfer [ 6] java.util.concurrent.LinkedTransferQueue.add [ 7] sun.nio.ch.Poller.registerAsync [ 8] sun.nio.ch.Poller.pollIndirect [ 9] sun.nio.ch.Poller.poll [10] sun.nio.ch.Poller.poll [11] sun.nio.ch.NioSocketImpl.park [12] sun.nio.ch.NioSocketImpl.park [13] sun.nio.ch.NioSocketImpl.implRead [14] sun.nio.ch.NioSocketImpl.read [15] sun.nio.ch.NioSocketImpl$1.read [16] java.net.Socket$SocketInputStream.read [17] java.io.FilterInputStream.read [18] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [19] robaho.net.httpserver.NoSyncBufferedInputStream.fill [20] robaho.net.httpserver.NoSyncBufferedInputStream.read [21] robaho.net.httpserver.Request.readLine [22] robaho.net.httpserver.Request. [23] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [24] robaho.net.httpserver.ServerImpl$Exchange.run [25] jdk.internal.vm.Continuation.enterSpecial [26] jdk.internal.vm.Continuation.run [27] java.lang.VirtualThread.runContinuation [28] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [29] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [30] java.util.concurrent.ForkJoinTask.doExec [31] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [32] java.util.concurrent.ForkJoinPool.scan [33] java.util.concurrent.ForkJoinPool.runWorker [34] java.util.concurrent.ForkJoinWorkerThread.run --- 5200000 ns (0.10%), 520 samples [ 0] jdk.internal.misc.Unsafe.unpark [ 1] java.util.concurrent.locks.LockSupport.unpark [ 2] java.util.concurrent.ForkJoinPool.signalWork [ 3] java.util.concurrent.ForkJoinPool$WorkQueue.push [ 4] java.util.concurrent.ForkJoinPool.poolSubmit [ 5] java.util.concurrent.ForkJoinPool.execute [ 6] java.lang.VirtualThread.submitRunContinuation [ 7] java.lang.VirtualThread.unpark [ 8] java.lang.System$2.unparkVirtualThread [ 9] jdk.internal.misc.VirtualThreads.unpark [10] java.util.concurrent.locks.LockSupport.unpark [11] sun.nio.ch.Poller.wakeup [12] sun.nio.ch.Poller.polled [13] sun.nio.ch.KQueuePoller.poll [14] sun.nio.ch.Poller.poll [15] sun.nio.ch.Poller.pollLoop [16] sun.nio.ch.Poller$$Lambda.0x00000001340f1b78.run [17] java.lang.Thread.runWith [18] java.lang.Thread.run [19] jdk.internal.misc.InnocuousThread.run --- 5120000 ns (0.10%), 512 samples [ 0] sun.nio.ch.SocketDispatcher.write0 [ 1] sun.nio.ch.SocketDispatcher.write [ 2] sun.nio.ch.NioSocketImpl.tryWrite [ 3] sun.nio.ch.NioSocketImpl.implWrite [ 4] sun.nio.ch.NioSocketImpl.write [ 5] sun.nio.ch.NioSocketImpl$2.write [ 6] java.net.Socket$SocketOutputStream.write [ 7] robaho.net.httpserver.HttpConnection$ActivityTimerOutputStream.write [ 8] java.io.BufferedOutputStream.flushBuffer [ 9] java.io.BufferedOutputStream.implFlush [10] java.io.BufferedOutputStream.flush [11] java.io.FilterOutputStream.flush [12] robaho.net.httpserver.FixedLengthOutputStream.close [13] robaho.net.httpserver.PlaceholderOutputStream.close [14] benchmarks.Server.lambda$createPlaintextHandler$0 [15] benchmarks.Server$$Lambda.0x0000000134004ac0.handle [16] com.sun.net.httpserver.Filter$Chain.doFilter [17] robaho.net.httpserver.AuthFilter.doFilter [18] com.sun.net.httpserver.Filter$Chain.doFilter [19] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [20] com.sun.net.httpserver.Filter$Chain.doFilter [21] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [22] robaho.net.httpserver.ServerImpl$Exchange.run [23] jdk.internal.vm.Continuation.enterSpecial [24] jdk.internal.vm.Continuation.run [25] java.lang.VirtualThread.runContinuation [26] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [27] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [28] java.util.concurrent.ForkJoinTask.doExec [29] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [30] java.util.concurrent.ForkJoinPool.scan [31] java.util.concurrent.ForkJoinPool.runWorker [32] java.util.concurrent.ForkJoinWorkerThread.run --- 5020000 ns (0.09%), 502 samples [ 0] __psynch_cvwait [ 1] Parker::park [ 2] Unsafe_Park [ 3] jdk.internal.misc.Unsafe.park [ 4] java.util.concurrent.locks.LockSupport.parkUntil [ 5] java.util.concurrent.ForkJoinPool.awaitWork [ 6] java.util.concurrent.ForkJoinPool.runWorker [ 7] java.util.concurrent.ForkJoinWorkerThread.run --- 5010000 ns (0.09%), 501 samples [ 0] jdk.internal.misc.Unsafe.park [ 1] java.util.concurrent.locks.LockSupport.park [ 2] java.util.concurrent.ForkJoinPool.awaitWork [ 3] java.util.concurrent.ForkJoinPool.runWorker [ 4] java.util.concurrent.ForkJoinWorkerThread.run --- 4810000 ns (0.09%), 481 samples [ 0] sched_yield [ 1] java.lang.Thread.yield0 [ 2] java.lang.Thread.yield [ 3] java.util.concurrent.LinkedTransferQueue.awaitMatch [ 4] java.util.concurrent.LinkedTransferQueue.xfer [ 5] java.util.concurrent.LinkedTransferQueue.take [ 6] sun.nio.ch.Poller.updateLoop [ 7] sun.nio.ch.Poller$$Lambda.0x00000001340f1fb8.run [ 8] java.lang.Thread.runWith [ 9] java.lang.Thread.run [10] jdk.internal.misc.InnocuousThread.run --- 4810000 ns (0.09%), 481 samples [ 0] robaho.net.httpserver.ExchangeImpl.bytes [ 1] robaho.net.httpserver.ExchangeImpl.write [ 2] robaho.net.httpserver.ExchangeImpl.sendResponseHeaders [ 3] robaho.net.httpserver.HttpExchangeImpl.sendResponseHeaders [ 4] benchmarks.Server.lambda$createPlaintextHandler$0 [ 5] benchmarks.Server$$Lambda.0x0000000134004ac0.handle [ 6] com.sun.net.httpserver.Filter$Chain.doFilter [ 7] robaho.net.httpserver.AuthFilter.doFilter [ 8] com.sun.net.httpserver.Filter$Chain.doFilter [ 9] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [10] com.sun.net.httpserver.Filter$Chain.doFilter [11] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [12] robaho.net.httpserver.ServerImpl$Exchange.run [13] jdk.internal.vm.Continuation.enterSpecial [14] jdk.internal.vm.Continuation.run [15] java.lang.VirtualThread.runContinuation [16] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [17] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [18] java.util.concurrent.ForkJoinTask.doExec [19] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [20] java.util.concurrent.ForkJoinPool.scan [21] java.util.concurrent.ForkJoinPool.runWorker [22] java.util.concurrent.ForkJoinWorkerThread.run --- 4620000 ns (0.09%), 462 samples [ 0] robaho.net.httpserver.Request. [ 1] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [ 2] robaho.net.httpserver.ServerImpl$Exchange.run [ 3] jdk.internal.vm.Continuation.enterSpecial [ 4] jdk.internal.vm.Continuation.run [ 5] java.lang.VirtualThread.runContinuation [ 6] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [ 7] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [ 8] java.util.concurrent.ForkJoinTask.doExec [ 9] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [10] java.util.concurrent.ForkJoinPool.scan [11] java.util.concurrent.ForkJoinPool.runWorker [12] java.util.concurrent.ForkJoinWorkerThread.run --- 4610000 ns (0.09%), 461 samples [ 0] itable stub [ 1] java.time.format.DateTimeFormatterBuilder$CompositePrinterParser.format [ 2] java.time.format.DateTimeFormatter.formatTo [ 3] java.time.format.DateTimeFormatter.format [ 4] robaho.net.httpserver.ExchangeImpl.sendResponseHeaders [ 5] robaho.net.httpserver.HttpExchangeImpl.sendResponseHeaders [ 6] benchmarks.Server.lambda$createPlaintextHandler$0 [ 7] benchmarks.Server$$Lambda.0x0000000134004ac0.handle [ 8] com.sun.net.httpserver.Filter$Chain.doFilter [ 9] robaho.net.httpserver.AuthFilter.doFilter [10] com.sun.net.httpserver.Filter$Chain.doFilter [11] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [12] com.sun.net.httpserver.Filter$Chain.doFilter [13] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [14] robaho.net.httpserver.ServerImpl$Exchange.run [15] jdk.internal.vm.Continuation.enterSpecial [16] jdk.internal.vm.Continuation.run [17] java.lang.VirtualThread.runContinuation [18] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [19] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [20] java.util.concurrent.ForkJoinTask.doExec [21] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [22] java.util.concurrent.ForkJoinPool.scan [23] java.util.concurrent.ForkJoinPool.runWorker [24] java.util.concurrent.ForkJoinWorkerThread.run --- 4570000 ns (0.09%), 457 samples [ 0] __psynch_cvsignal [ 1] Unsafe_Unpark [ 2] jdk.internal.misc.Unsafe.unpark [ 3] java.util.concurrent.locks.LockSupport.unpark [ 4] java.util.concurrent.LinkedTransferQueue$Node.tryMatch [ 5] java.util.concurrent.LinkedTransferQueue.xfer [ 6] java.util.concurrent.LinkedTransferQueue.add [ 7] sun.nio.ch.Poller.registerAsync [ 8] sun.nio.ch.Poller.pollIndirect [ 9] sun.nio.ch.Poller.poll [10] sun.nio.ch.Poller.poll [11] sun.nio.ch.NioSocketImpl.park [12] sun.nio.ch.NioSocketImpl.park [13] sun.nio.ch.NioSocketImpl.implRead [14] sun.nio.ch.NioSocketImpl.read [15] sun.nio.ch.NioSocketImpl$1.read [16] java.net.Socket$SocketInputStream.read [17] java.io.FilterInputStream.read [18] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [19] robaho.net.httpserver.NoSyncBufferedInputStream.fill [20] robaho.net.httpserver.NoSyncBufferedInputStream.read [21] robaho.net.httpserver.Request.readLine [22] robaho.net.httpserver.Request. [23] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [24] robaho.net.httpserver.ServerImpl$Exchange.run [25] jdk.internal.vm.Continuation.enterSpecial [26] jdk.internal.vm.Continuation.run [27] java.lang.VirtualThread.runContinuation [28] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [29] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [30] java.util.concurrent.ForkJoinTask.doExec [31] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [32] java.util.concurrent.ForkJoinPool.scan [33] java.util.concurrent.ForkJoinPool.runWorker [34] java.util.concurrent.ForkJoinWorkerThread.run --- 4550000 ns (0.09%), 455 samples [ 0] sun.nio.ch.KQueue.register [ 1] sun.nio.ch.KQueuePoller.implRegister [ 2] sun.nio.ch.Poller.updateLoop [ 3] sun.nio.ch.Poller$$Lambda.0x00000001340f1fb8.run [ 4] java.lang.Thread.runWith [ 5] java.lang.Thread.run [ 6] jdk.internal.misc.InnocuousThread.run --- 4440000 ns (0.08%), 444 samples [ 0] robaho.net.httpserver.ExchangeImpl.bytes [ 1] robaho.net.httpserver.ExchangeImpl.write [ 2] robaho.net.httpserver.ExchangeImpl.sendResponseHeaders [ 3] robaho.net.httpserver.HttpExchangeImpl.sendResponseHeaders [ 4] benchmarks.Server.lambda$createPlaintextHandler$0 [ 5] benchmarks.Server$$Lambda.0x0000000134004ac0.handle [ 6] com.sun.net.httpserver.Filter$Chain.doFilter [ 7] robaho.net.httpserver.AuthFilter.doFilter [ 8] com.sun.net.httpserver.Filter$Chain.doFilter [ 9] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [10] com.sun.net.httpserver.Filter$Chain.doFilter [11] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [12] robaho.net.httpserver.ServerImpl$Exchange.run [13] jdk.internal.vm.Continuation.enterSpecial [14] jdk.internal.vm.Continuation.run [15] java.lang.VirtualThread.runContinuation [16] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [17] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [18] java.util.concurrent.ForkJoinTask.doExec [19] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [20] java.util.concurrent.ForkJoinPool.scan [21] java.util.concurrent.ForkJoinPool.runWorker [22] java.util.concurrent.ForkJoinWorkerThread.run --- 4440000 ns (0.08%), 444 samples [ 0] sun.nio.ch.SocketDispatcher.write0 [ 1] sun.nio.ch.SocketDispatcher.write [ 2] sun.nio.ch.NioSocketImpl.tryWrite [ 3] sun.nio.ch.NioSocketImpl.implWrite [ 4] sun.nio.ch.NioSocketImpl.write [ 5] sun.nio.ch.NioSocketImpl$2.write [ 6] java.net.Socket$SocketOutputStream.write [ 7] robaho.net.httpserver.HttpConnection$ActivityTimerOutputStream.write [ 8] java.io.BufferedOutputStream.flushBuffer [ 9] java.io.BufferedOutputStream.implFlush [10] java.io.BufferedOutputStream.flush [11] java.io.FilterOutputStream.flush [12] robaho.net.httpserver.FixedLengthOutputStream.close [13] robaho.net.httpserver.PlaceholderOutputStream.close [14] benchmarks.Server.lambda$createPlaintextHandler$0 [15] benchmarks.Server$$Lambda.0x0000000134004ac0.handle [16] com.sun.net.httpserver.Filter$Chain.doFilter [17] robaho.net.httpserver.AuthFilter.doFilter [18] com.sun.net.httpserver.Filter$Chain.doFilter [19] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [20] com.sun.net.httpserver.Filter$Chain.doFilter [21] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [22] robaho.net.httpserver.ServerImpl$Exchange.run [23] jdk.internal.vm.Continuation.enterSpecial [24] jdk.internal.vm.Continuation.run [25] java.lang.VirtualThread.runContinuation [26] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [27] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [28] java.util.concurrent.ForkJoinTask.doExec [29] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [30] java.util.concurrent.ForkJoinPool.scan [31] java.util.concurrent.ForkJoinPool.runWorker [32] java.util.concurrent.ForkJoinWorkerThread.run --- 4360000 ns (0.08%), 436 samples [ 0] sun.nio.ch.Poller.registerAsync [ 1] sun.nio.ch.Poller.pollIndirect [ 2] sun.nio.ch.Poller.poll [ 3] sun.nio.ch.Poller.poll [ 4] sun.nio.ch.NioSocketImpl.park [ 5] sun.nio.ch.NioSocketImpl.park [ 6] sun.nio.ch.NioSocketImpl.implRead [ 7] sun.nio.ch.NioSocketImpl.read [ 8] sun.nio.ch.NioSocketImpl$1.read [ 9] java.net.Socket$SocketInputStream.read [10] java.io.FilterInputStream.read [11] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [12] robaho.net.httpserver.NoSyncBufferedInputStream.fill [13] robaho.net.httpserver.NoSyncBufferedInputStream.read [14] robaho.net.httpserver.Request.readLine [15] robaho.net.httpserver.Request. [16] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [17] robaho.net.httpserver.ServerImpl$Exchange.run [18] jdk.internal.vm.Continuation.enterSpecial [19] jdk.internal.vm.Continuation.run [20] java.lang.VirtualThread.runContinuation [21] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [22] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [23] java.util.concurrent.ForkJoinTask.doExec [24] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [25] java.util.concurrent.ForkJoinPool.scan [26] java.util.concurrent.ForkJoinPool.runWorker [27] java.util.concurrent.ForkJoinWorkerThread.run --- 4280000 ns (0.08%), 428 samples [ 0] Java_sun_nio_ch_KQueue_poll [ 1] sun.nio.ch.KQueue.poll [ 2] sun.nio.ch.KQueuePoller.poll [ 3] sun.nio.ch.Poller.poll [ 4] sun.nio.ch.Poller.pollLoop [ 5] sun.nio.ch.Poller$$Lambda.0x00000001340f1b78.run [ 6] java.lang.Thread.runWith [ 7] java.lang.Thread.run [ 8] jdk.internal.misc.InnocuousThread.run --- 4170000 ns (0.08%), 417 samples [ 0] __psynch_cvwait [ 1] Parker::park [ 2] Unsafe_Park [ 3] jdk.internal.misc.Unsafe.park [ 4] java.util.concurrent.locks.LockSupport.parkUntil [ 5] java.util.concurrent.ForkJoinPool.awaitWork [ 6] java.util.concurrent.ForkJoinPool.runWorker [ 7] java.util.concurrent.ForkJoinWorkerThread.run --- 3950000 ns (0.07%), 395 samples [ 0] sun.nio.ch.Poller.registerAsync [ 1] sun.nio.ch.Poller.pollIndirect [ 2] sun.nio.ch.Poller.poll [ 3] sun.nio.ch.Poller.poll [ 4] sun.nio.ch.NioSocketImpl.park [ 5] sun.nio.ch.NioSocketImpl.park [ 6] sun.nio.ch.NioSocketImpl.implRead [ 7] sun.nio.ch.NioSocketImpl.read [ 8] sun.nio.ch.NioSocketImpl$1.read [ 9] java.net.Socket$SocketInputStream.read [10] java.io.FilterInputStream.read [11] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [12] robaho.net.httpserver.NoSyncBufferedInputStream.fill [13] robaho.net.httpserver.NoSyncBufferedInputStream.read [14] robaho.net.httpserver.Request.readLine [15] robaho.net.httpserver.Request. [16] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [17] robaho.net.httpserver.ServerImpl$Exchange.run [18] jdk.internal.vm.Continuation.enterSpecial [19] jdk.internal.vm.Continuation.run [20] java.lang.VirtualThread.runContinuation [21] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [22] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [23] java.util.concurrent.ForkJoinTask.doExec [24] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [25] java.util.concurrent.ForkJoinPool.scan [26] java.util.concurrent.ForkJoinPool.runWorker [27] java.util.concurrent.ForkJoinWorkerThread.run --- 3890000 ns (0.07%), 389 samples [ 0] robaho.net.httpserver.Request. [ 1] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [ 2] robaho.net.httpserver.ServerImpl$Exchange.run [ 3] jdk.internal.vm.Continuation.enterSpecial [ 4] jdk.internal.vm.Continuation.run [ 5] java.lang.VirtualThread.runContinuation [ 6] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [ 7] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [ 8] java.util.concurrent.ForkJoinTask.doExec [ 9] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [10] java.util.concurrent.ForkJoinPool.scan [11] java.util.concurrent.ForkJoinPool.runWorker [12] java.util.concurrent.ForkJoinWorkerThread.run --- 3800000 ns (0.07%), 380 samples [ 0] itable stub [ 1] java.time.format.DateTimeFormatterBuilder$CompositePrinterParser.format [ 2] java.time.format.DateTimeFormatter.formatTo [ 3] java.time.format.DateTimeFormatter.format [ 4] robaho.net.httpserver.ExchangeImpl.sendResponseHeaders [ 5] robaho.net.httpserver.HttpExchangeImpl.sendResponseHeaders [ 6] benchmarks.Server.lambda$createPlaintextHandler$0 [ 7] benchmarks.Server$$Lambda.0x0000000134004ac0.handle [ 8] com.sun.net.httpserver.Filter$Chain.doFilter [ 9] robaho.net.httpserver.AuthFilter.doFilter [10] com.sun.net.httpserver.Filter$Chain.doFilter [11] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [12] com.sun.net.httpserver.Filter$Chain.doFilter [13] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [14] robaho.net.httpserver.ServerImpl$Exchange.run [15] jdk.internal.vm.Continuation.enterSpecial [16] jdk.internal.vm.Continuation.run [17] java.lang.VirtualThread.runContinuation [18] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [19] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [20] java.util.concurrent.ForkJoinTask.doExec [21] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [22] java.util.concurrent.ForkJoinPool.scan [23] java.util.concurrent.ForkJoinPool.runWorker [24] java.util.concurrent.ForkJoinWorkerThread.run --- 3550000 ns (0.07%), 355 samples [ 0] Java_sun_nio_ch_KQueue_register [ 1] sun.nio.ch.KQueue.register [ 2] sun.nio.ch.KQueuePoller.implRegister [ 3] sun.nio.ch.Poller.updateLoop [ 4] sun.nio.ch.Poller$$Lambda.0x00000001340f1fb8.run [ 5] java.lang.Thread.runWith [ 6] java.lang.Thread.run [ 7] jdk.internal.misc.InnocuousThread.run --- 3530000 ns (0.07%), 353 samples [ 0] write [ 1] sun.nio.ch.SocketDispatcher.write0 [ 2] sun.nio.ch.SocketDispatcher.write [ 3] sun.nio.ch.NioSocketImpl.tryWrite [ 4] sun.nio.ch.NioSocketImpl.implWrite [ 5] sun.nio.ch.NioSocketImpl.write [ 6] sun.nio.ch.NioSocketImpl$2.write [ 7] java.net.Socket$SocketOutputStream.write [ 8] robaho.net.httpserver.HttpConnection$ActivityTimerOutputStream.write [ 9] java.io.BufferedOutputStream.flushBuffer [10] java.io.BufferedOutputStream.implFlush [11] java.io.BufferedOutputStream.flush [12] java.io.FilterOutputStream.flush [13] robaho.net.httpserver.FixedLengthOutputStream.close [14] robaho.net.httpserver.PlaceholderOutputStream.close [15] benchmarks.Server.lambda$createPlaintextHandler$0 [16] benchmarks.Server$$Lambda.0x0000000134004ac0.handle [17] com.sun.net.httpserver.Filter$Chain.doFilter [18] robaho.net.httpserver.AuthFilter.doFilter [19] com.sun.net.httpserver.Filter$Chain.doFilter [20] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [21] com.sun.net.httpserver.Filter$Chain.doFilter [22] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [23] jdk.internal.vm.Continuation.enterSpecial [24] jdk.internal.vm.Continuation.run [25] java.lang.VirtualThread.runContinuation [26] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [27] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [28] java.util.concurrent.ForkJoinTask.doExec [29] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [30] java.util.concurrent.ForkJoinPool.scan [31] java.util.concurrent.ForkJoinPool.runWorker [32] java.util.concurrent.ForkJoinWorkerThread.run --- 3530000 ns (0.07%), 353 samples [ 0] robaho.net.httpserver.Request. [ 1] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [ 2] robaho.net.httpserver.ServerImpl$Exchange.run [ 3] jdk.internal.vm.Continuation.enterSpecial [ 4] jdk.internal.vm.Continuation.run [ 5] java.lang.VirtualThread.runContinuation [ 6] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [ 7] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [ 8] java.util.concurrent.ForkJoinTask.doExec [ 9] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [10] java.util.concurrent.ForkJoinPool.scan [11] java.util.concurrent.ForkJoinPool.runWorker [12] java.util.concurrent.ForkJoinWorkerThread.run --- 3530000 ns (0.07%), 353 samples [ 0] java.util.concurrent.ForkJoinPool.scan [ 1] java.util.concurrent.ForkJoinPool.runWorker [ 2] java.util.concurrent.ForkJoinWorkerThread.run --- 3360000 ns (0.06%), 336 samples [ 0] __psynch_cvsignal [ 1] Unsafe_Unpark [ 2] jdk.internal.misc.Unsafe.unpark [ 3] java.util.concurrent.locks.LockSupport.unpark [ 4] java.util.concurrent.LinkedTransferQueue$Node.tryMatch [ 5] java.util.concurrent.LinkedTransferQueue.xfer [ 6] java.util.concurrent.LinkedTransferQueue.add [ 7] sun.nio.ch.Poller.registerAsync [ 8] sun.nio.ch.Poller.pollIndirect [ 9] sun.nio.ch.Poller.poll [10] sun.nio.ch.Poller.poll [11] sun.nio.ch.NioSocketImpl.park [12] sun.nio.ch.NioSocketImpl.park [13] sun.nio.ch.NioSocketImpl.implRead [14] sun.nio.ch.NioSocketImpl.read [15] sun.nio.ch.NioSocketImpl$1.read [16] java.net.Socket$SocketInputStream.read [17] java.io.FilterInputStream.read [18] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [19] robaho.net.httpserver.NoSyncBufferedInputStream.fill [20] robaho.net.httpserver.NoSyncBufferedInputStream.read [21] robaho.net.httpserver.Request.readLine [22] robaho.net.httpserver.Request. [23] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [24] robaho.net.httpserver.ServerImpl$Exchange.run [25] jdk.internal.vm.Continuation.enterSpecial [26] jdk.internal.vm.Continuation.run [27] java.lang.VirtualThread.runContinuation [28] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [29] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [30] java.util.concurrent.ForkJoinTask.doExec [31] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [32] java.util.concurrent.ForkJoinPool.scan [33] java.util.concurrent.ForkJoinPool.runWorker [34] java.util.concurrent.ForkJoinWorkerThread.run --- 3310000 ns (0.06%), 331 samples [ 0] robaho.net.httpserver.Request. [ 1] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [ 2] robaho.net.httpserver.ServerImpl$Exchange.run [ 3] jdk.internal.vm.Continuation.enterSpecial [ 4] jdk.internal.vm.Continuation.run [ 5] java.lang.VirtualThread.runContinuation [ 6] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [ 7] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [ 8] java.util.concurrent.ForkJoinTask.doExec [ 9] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [10] java.util.concurrent.ForkJoinPool.scan [11] java.util.concurrent.ForkJoinPool.runWorker [12] java.util.concurrent.ForkJoinWorkerThread.run --- 3250000 ns (0.06%), 325 samples [ 0] write [ 1] sun.nio.ch.SocketDispatcher.write0 [ 2] sun.nio.ch.SocketDispatcher.write [ 3] sun.nio.ch.NioSocketImpl.tryWrite [ 4] sun.nio.ch.NioSocketImpl.implWrite [ 5] sun.nio.ch.NioSocketImpl.write [ 6] sun.nio.ch.NioSocketImpl$2.write [ 7] java.net.Socket$SocketOutputStream.write [ 8] robaho.net.httpserver.HttpConnection$ActivityTimerOutputStream.write [ 9] java.io.BufferedOutputStream.flushBuffer [10] java.io.BufferedOutputStream.implFlush [11] java.io.BufferedOutputStream.flush [12] java.io.FilterOutputStream.flush [13] robaho.net.httpserver.FixedLengthOutputStream.close [14] robaho.net.httpserver.PlaceholderOutputStream.close [15] benchmarks.Server.lambda$createPlaintextHandler$0 [16] benchmarks.Server$$Lambda.0x0000000134004ac0.handle [17] com.sun.net.httpserver.Filter$Chain.doFilter [18] robaho.net.httpserver.AuthFilter.doFilter [19] com.sun.net.httpserver.Filter$Chain.doFilter [20] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [21] com.sun.net.httpserver.Filter$Chain.doFilter [22] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [23] jdk.internal.vm.Continuation.enterSpecial [24] jdk.internal.vm.Continuation.run [25] java.lang.VirtualThread.runContinuation [26] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [27] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [28] java.util.concurrent.ForkJoinTask.doExec [29] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [30] java.util.concurrent.ForkJoinPool.scan [31] java.util.concurrent.ForkJoinPool.runWorker [32] java.util.concurrent.ForkJoinWorkerThread.run --- 3250000 ns (0.06%), 325 samples [ 0] write [ 1] sun.nio.ch.SocketDispatcher.write0 [ 2] sun.nio.ch.SocketDispatcher.write [ 3] sun.nio.ch.NioSocketImpl.tryWrite [ 4] sun.nio.ch.NioSocketImpl.implWrite [ 5] sun.nio.ch.NioSocketImpl.write [ 6] sun.nio.ch.NioSocketImpl$2.write [ 7] java.net.Socket$SocketOutputStream.write [ 8] robaho.net.httpserver.HttpConnection$ActivityTimerOutputStream.write [ 9] java.io.BufferedOutputStream.flushBuffer [10] java.io.BufferedOutputStream.implFlush [11] java.io.BufferedOutputStream.flush [12] java.io.FilterOutputStream.flush [13] robaho.net.httpserver.FixedLengthOutputStream.close [14] robaho.net.httpserver.PlaceholderOutputStream.close [15] benchmarks.Server.lambda$createPlaintextHandler$0 [16] benchmarks.Server$$Lambda.0x0000000134004ac0.handle [17] com.sun.net.httpserver.Filter$Chain.doFilter [18] robaho.net.httpserver.AuthFilter.doFilter [19] com.sun.net.httpserver.Filter$Chain.doFilter [20] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [21] com.sun.net.httpserver.Filter$Chain.doFilter [22] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [23] jdk.internal.vm.Continuation.enterSpecial [24] jdk.internal.vm.Continuation.run [25] java.lang.VirtualThread.runContinuation [26] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [27] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [28] java.util.concurrent.ForkJoinTask.doExec [29] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [30] java.util.concurrent.ForkJoinPool.scan [31] java.util.concurrent.ForkJoinPool.runWorker [32] java.util.concurrent.ForkJoinWorkerThread.run --- 3230000 ns (0.06%), 323 samples [ 0] FastThreadsListHandle::FastThreadsListHandle [ 1] Unsafe_Unpark [ 2] jdk.internal.misc.Unsafe.unpark [ 3] java.util.concurrent.locks.LockSupport.unpark [ 4] java.util.concurrent.ForkJoinPool.signalWork [ 5] java.util.concurrent.ForkJoinPool$WorkQueue.push [ 6] java.util.concurrent.ForkJoinPool.poolSubmit [ 7] java.util.concurrent.ForkJoinPool.execute [ 8] java.lang.VirtualThread.submitRunContinuation [ 9] java.lang.VirtualThread.unpark [10] java.lang.System$2.unparkVirtualThread [11] jdk.internal.misc.VirtualThreads.unpark [12] java.util.concurrent.locks.LockSupport.unpark [13] sun.nio.ch.Poller.wakeup [14] sun.nio.ch.Poller.polled [15] sun.nio.ch.KQueuePoller.poll [16] sun.nio.ch.Poller.poll [17] sun.nio.ch.Poller.pollLoop [18] sun.nio.ch.Poller$$Lambda.0x00000001340f1b78.run [19] java.lang.Thread.runWith [20] java.lang.Thread.run [21] jdk.internal.misc.InnocuousThread.run --- 3050000 ns (0.06%), 305 samples [ 0] write [ 1] sun.nio.ch.SocketDispatcher.write0 [ 2] sun.nio.ch.SocketDispatcher.write [ 3] sun.nio.ch.NioSocketImpl.tryWrite [ 4] sun.nio.ch.NioSocketImpl.implWrite [ 5] sun.nio.ch.NioSocketImpl.write [ 6] sun.nio.ch.NioSocketImpl$2.write [ 7] java.net.Socket$SocketOutputStream.write [ 8] robaho.net.httpserver.HttpConnection$ActivityTimerOutputStream.write [ 9] java.io.BufferedOutputStream.flushBuffer [10] java.io.BufferedOutputStream.implFlush [11] java.io.BufferedOutputStream.flush [12] java.io.FilterOutputStream.flush [13] robaho.net.httpserver.FixedLengthOutputStream.close [14] robaho.net.httpserver.PlaceholderOutputStream.close [15] benchmarks.Server.lambda$createPlaintextHandler$0 [16] benchmarks.Server$$Lambda.0x0000000134004ac0.handle [17] com.sun.net.httpserver.Filter$Chain.doFilter [18] robaho.net.httpserver.AuthFilter.doFilter [19] com.sun.net.httpserver.Filter$Chain.doFilter [20] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [21] com.sun.net.httpserver.Filter$Chain.doFilter [22] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [23] jdk.internal.vm.Continuation.enterSpecial [24] jdk.internal.vm.Continuation.run [25] java.lang.VirtualThread.runContinuation [26] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [27] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [28] java.util.concurrent.ForkJoinTask.doExec [29] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [30] java.util.concurrent.ForkJoinPool.scan [31] java.util.concurrent.ForkJoinPool.runWorker [32] java.util.concurrent.ForkJoinWorkerThread.run --- 3030000 ns (0.06%), 303 samples [ 0] java.util.concurrent.ForkJoinPool$WorkQueue.push [ 1] java.util.concurrent.ForkJoinPool.poolSubmit [ 2] java.util.concurrent.ForkJoinPool.execute [ 3] java.lang.VirtualThread.submitRunContinuation [ 4] java.lang.VirtualThread.unpark [ 5] java.lang.System$2.unparkVirtualThread [ 6] jdk.internal.misc.VirtualThreads.unpark [ 7] java.util.concurrent.locks.LockSupport.unpark [ 8] sun.nio.ch.Poller.wakeup [ 9] sun.nio.ch.Poller.polled [10] sun.nio.ch.KQueuePoller.poll [11] sun.nio.ch.Poller.poll [12] sun.nio.ch.Poller.pollLoop [13] sun.nio.ch.Poller$$Lambda.0x00000001340f1b78.run [14] java.lang.Thread.runWith [15] java.lang.Thread.run [16] jdk.internal.misc.InnocuousThread.run --- 3010000 ns (0.06%), 301 samples [ 0] robaho.net.httpserver.ExchangeImpl.bytes [ 1] robaho.net.httpserver.ExchangeImpl.write [ 2] robaho.net.httpserver.ExchangeImpl.sendResponseHeaders [ 3] robaho.net.httpserver.HttpExchangeImpl.sendResponseHeaders [ 4] benchmarks.Server.lambda$createPlaintextHandler$0 [ 5] benchmarks.Server$$Lambda.0x0000000134004ac0.handle [ 6] com.sun.net.httpserver.Filter$Chain.doFilter [ 7] robaho.net.httpserver.AuthFilter.doFilter [ 8] com.sun.net.httpserver.Filter$Chain.doFilter [ 9] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [10] com.sun.net.httpserver.Filter$Chain.doFilter [11] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [12] robaho.net.httpserver.ServerImpl$Exchange.run [13] jdk.internal.vm.Continuation.enterSpecial [14] jdk.internal.vm.Continuation.run [15] java.lang.VirtualThread.runContinuation [16] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [17] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [18] java.util.concurrent.ForkJoinTask.doExec [19] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [20] java.util.concurrent.ForkJoinPool.scan [21] java.util.concurrent.ForkJoinPool.runWorker [22] java.util.concurrent.ForkJoinWorkerThread.run --- 2950000 ns (0.06%), 295 samples [ 0] robaho.net.httpserver.ExchangeImpl.bytes [ 1] robaho.net.httpserver.ExchangeImpl.write [ 2] robaho.net.httpserver.ExchangeImpl.sendResponseHeaders [ 3] robaho.net.httpserver.HttpExchangeImpl.sendResponseHeaders [ 4] benchmarks.Server.lambda$createPlaintextHandler$0 [ 5] benchmarks.Server$$Lambda.0x0000000134004ac0.handle [ 6] com.sun.net.httpserver.Filter$Chain.doFilter [ 7] robaho.net.httpserver.AuthFilter.doFilter [ 8] com.sun.net.httpserver.Filter$Chain.doFilter [ 9] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [10] com.sun.net.httpserver.Filter$Chain.doFilter [11] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [12] robaho.net.httpserver.ServerImpl$Exchange.run [13] jdk.internal.vm.Continuation.enterSpecial [14] jdk.internal.vm.Continuation.run [15] java.lang.VirtualThread.runContinuation [16] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [17] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [18] java.util.concurrent.ForkJoinTask.doExec [19] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [20] java.util.concurrent.ForkJoinPool.scan [21] java.util.concurrent.ForkJoinPool.runWorker [22] java.util.concurrent.ForkJoinWorkerThread.run --- 2880000 ns (0.05%), 288 samples [ 0] java.lang.ref.Reference.refersTo [ 1] java.lang.ThreadLocal$ThreadLocalMap.getEntry [ 2] java.lang.ThreadLocal.get [ 3] java.lang.ThreadLocal.getCarrierThreadLocal [ 4] java.lang.System$2.getCarrierThreadLocal [ 5] jdk.internal.misc.CarrierThreadLocal.get [ 6] sun.nio.ch.Util.getTemporaryDirectBuffer [ 7] sun.nio.ch.NioSocketImpl.tryWrite [ 8] sun.nio.ch.NioSocketImpl.implWrite [ 9] sun.nio.ch.NioSocketImpl.write [10] sun.nio.ch.NioSocketImpl$2.write [11] java.net.Socket$SocketOutputStream.write [12] robaho.net.httpserver.HttpConnection$ActivityTimerOutputStream.write [13] java.io.BufferedOutputStream.flushBuffer [14] java.io.BufferedOutputStream.implFlush [15] java.io.BufferedOutputStream.flush [16] java.io.FilterOutputStream.flush [17] robaho.net.httpserver.FixedLengthOutputStream.close [18] robaho.net.httpserver.PlaceholderOutputStream.close [19] benchmarks.Server.lambda$createPlaintextHandler$0 [20] benchmarks.Server$$Lambda.0x0000000134004ac0.handle [21] com.sun.net.httpserver.Filter$Chain.doFilter [22] robaho.net.httpserver.AuthFilter.doFilter [23] com.sun.net.httpserver.Filter$Chain.doFilter [24] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [25] com.sun.net.httpserver.Filter$Chain.doFilter [26] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [27] robaho.net.httpserver.ServerImpl$Exchange.run [28] jdk.internal.vm.Continuation.enterSpecial [29] jdk.internal.vm.Continuation.run [30] java.lang.VirtualThread.runContinuation [31] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [32] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [33] java.util.concurrent.ForkJoinTask.doExec [34] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [35] java.util.concurrent.ForkJoinPool.scan [36] java.util.concurrent.ForkJoinPool.runWorker [37] java.util.concurrent.ForkJoinWorkerThread.run --- 2870000 ns (0.05%), 287 samples [ 0] robaho.net.httpserver.ExchangeImpl.write [ 1] robaho.net.httpserver.ExchangeImpl.sendResponseHeaders [ 2] robaho.net.httpserver.HttpExchangeImpl.sendResponseHeaders [ 3] benchmarks.Server.lambda$createPlaintextHandler$0 [ 4] benchmarks.Server$$Lambda.0x0000000134004ac0.handle [ 5] com.sun.net.httpserver.Filter$Chain.doFilter [ 6] robaho.net.httpserver.AuthFilter.doFilter [ 7] com.sun.net.httpserver.Filter$Chain.doFilter [ 8] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [ 9] com.sun.net.httpserver.Filter$Chain.doFilter [10] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [11] robaho.net.httpserver.ServerImpl$Exchange.run [12] jdk.internal.vm.Continuation.enterSpecial [13] jdk.internal.vm.Continuation.run [14] java.lang.VirtualThread.runContinuation [15] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [16] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [17] java.util.concurrent.ForkJoinTask.doExec [18] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [19] java.util.concurrent.ForkJoinPool.scan [20] java.util.concurrent.ForkJoinPool.runWorker [21] java.util.concurrent.ForkJoinWorkerThread.run --- 2870000 ns (0.05%), 287 samples [ 0] robaho.net.httpserver.ExchangeImpl.write [ 1] robaho.net.httpserver.ExchangeImpl.sendResponseHeaders [ 2] robaho.net.httpserver.HttpExchangeImpl.sendResponseHeaders [ 3] benchmarks.Server.lambda$createPlaintextHandler$0 [ 4] benchmarks.Server$$Lambda.0x0000000134004ac0.handle [ 5] com.sun.net.httpserver.Filter$Chain.doFilter [ 6] robaho.net.httpserver.AuthFilter.doFilter [ 7] com.sun.net.httpserver.Filter$Chain.doFilter [ 8] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [ 9] com.sun.net.httpserver.Filter$Chain.doFilter [10] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [11] robaho.net.httpserver.ServerImpl$Exchange.run [12] jdk.internal.vm.Continuation.enterSpecial [13] jdk.internal.vm.Continuation.run [14] java.lang.VirtualThread.runContinuation [15] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [16] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [17] java.util.concurrent.ForkJoinTask.doExec [18] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [19] java.util.concurrent.ForkJoinPool.scan [20] java.util.concurrent.ForkJoinPool.runWorker [21] java.util.concurrent.ForkJoinWorkerThread.run --- 2810000 ns (0.05%), 281 samples [ 0] robaho.net.httpserver.Request.readLine [ 1] robaho.net.httpserver.Request. [ 2] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [ 3] robaho.net.httpserver.ServerImpl$Exchange.run [ 4] jdk.internal.vm.Continuation.enterSpecial [ 5] jdk.internal.vm.Continuation.run [ 6] java.lang.VirtualThread.runContinuation [ 7] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [ 8] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [ 9] java.util.concurrent.ForkJoinTask.doExec [10] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [11] java.util.concurrent.ForkJoinPool.scan [12] java.util.concurrent.ForkJoinPool.runWorker [13] java.util.concurrent.ForkJoinWorkerThread.run --- 2790000 ns (0.05%), 279 samples [ 0] robaho.net.httpserver.ExchangeImpl.bytes [ 1] robaho.net.httpserver.ExchangeImpl.write [ 2] robaho.net.httpserver.ExchangeImpl.sendResponseHeaders [ 3] robaho.net.httpserver.HttpExchangeImpl.sendResponseHeaders [ 4] benchmarks.Server.lambda$createPlaintextHandler$0 [ 5] benchmarks.Server$$Lambda.0x0000000134004ac0.handle [ 6] com.sun.net.httpserver.Filter$Chain.doFilter [ 7] robaho.net.httpserver.AuthFilter.doFilter [ 8] com.sun.net.httpserver.Filter$Chain.doFilter [ 9] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [10] com.sun.net.httpserver.Filter$Chain.doFilter [11] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [12] robaho.net.httpserver.ServerImpl$Exchange.run [13] jdk.internal.vm.Continuation.enterSpecial [14] jdk.internal.vm.Continuation.run [15] java.lang.VirtualThread.runContinuation [16] java.lang.VirtualThread$$Lambda.0x00000001340b44c0.run [17] java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec [18] java.util.concurrent.ForkJoinTask.doExec [19] java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec [20] java.util.concurrent.ForkJoinPool.scan [21] java.util.concurrent.ForkJoinPool.runWorker [22] java.util.concurrent.ForkJoinWorkerThread.run --- 2770000 ns (0.05%), 277 samples [ 0] Unsafe_Unpark [ 1] jdk.internal.misc.Unsafe.unpark [ 2] java.util.concurrent.locks.LockSupport.unpark [ 3] java.util.concurrent.ForkJoinPool.signalWork [ 4] java.util.concurrent.ForkJoinPool$WorkQueue.push [ 5] java.util.concurrent.ForkJoinPool.poolSubmit [ 6] java.util.concurrent.ForkJoinPool.execute [ 7] java.lang.VirtualThread.submitRunContinuation [ 8] java.lang.VirtualThread.unpark [ 9] java.lang.System$2.unparkVirtualThread [10] jdk.internal.misc.VirtualThreads.unpark [11] java.util.concurrent.locks.LockSupport.unpark [12] sun.nio.ch.Poller.wakeup [13] sun.nio.ch.Poller.polled [14] sun.nio.ch.KQueuePoller.poll [15] sun.nio.ch.Poller.poll [16] sun.nio.ch.Poller.pollLoop [17] sun.nio.ch.Poller$$Lambda.0x00000001340f1b78.run [18] java.lang.Thread.runWith [19] java.lang.Thread.run [20] jdk.internal.misc.InnocuousThread.run ns percent samples top ---------- ------- ------- --- 927730000 17.50% 92773 write 865420000 16.32% 86542 __psynch_cvwait 664940000 12.54% 66494 kevent 532900000 10.05% 53290 swtch_pri 324830000 6.13% 32483 read 221610000 4.18% 22161 __psynch_cvsignal 98940000 1.87% 9894 java.util.concurrent.ForkJoinPool.awaitWork 58630000 1.11% 5863 jdk.internal.misc.Unsafe.park 47650000 0.90% 4765 java.util.HashMap.getNode 44500000 0.84% 4450 com.sun.net.httpserver.Headers.normalize 39440000 0.74% 3944 sun.nio.ch.KQueue.poll 35860000 0.68% 3586 java.util.concurrent.ForkJoinPool.scan 35420000 0.67% 3542 robaho.net.httpserver.Request. 35290000 0.67% 3529 robaho.net.httpserver.ExchangeImpl.bytes 31160000 0.59% 3116 robaho.net.httpserver.Request.headers 25620000 0.48% 2562 _platform_memmove$VARIANT$Haswell 23450000 0.44% 2345 sun.nio.ch.SocketDispatcher.read0 23140000 0.44% 2314 sun.nio.ch.SocketDispatcher.write0 21470000 0.40% 2147 robaho.net.httpserver.Request.readLine 20030000 0.38% 2003 java.util.HashMap.put 18600000 0.35% 1860 itable stub 18530000 0.35% 1853 sun.nio.ch.Poller.registerAsync 18260000 0.34% 1826 robaho.net.httpserver.ServerImpl$Exchange.runPerRequest 17400000 0.33% 1740 java.util.HashMap$HashIterator.nextNode 17210000 0.32% 1721 java.lang.ref.Reference.refersTo 16840000 0.32% 1684 java.time.format.DateTimeFormatterBuilder$NumberPrinterParser.format 16090000 0.30% 1609 java.util.concurrent.ConcurrentHashMap.tabAt 15920000 0.30% 1592 java.lang.Thread.yield0 15840000 0.30% 1584 Continuation::prepare_thaw 15400000 0.29% 1540 com.sun.net.httpserver.Headers.checkValue 14800000 0.28% 1480 JavaThread::rebind_to_jvmti_thread_state_of 13990000 0.26% 1399 sun.nio.ch.Poller.wakeup 13940000 0.26% 1394 jbyte_disjoint_arraycopy 13410000 0.25% 1341 robaho.net.httpserver.ExchangeImpl.write 12360000 0.23% 1236 java.util.HashMap.putVal 12210000 0.23% 1221 tlv_get_addr 12180000 0.23% 1218 robaho.net.httpserver.NoSyncBufferedInputStream.read 11870000 0.22% 1187 robaho.net.httpserver.ExchangeImpl.sendResponseHeaders 11420000 0.22% 1142 java.util.concurrent.ConcurrentHashMap.replaceNode 10930000 0.21% 1093 robaho.net.httpserver.ContextList.findContext 10800000 0.20% 1080 _pthread_cond_wait 10710000 0.20% 1071 jdk.internal.misc.Unsafe.unpark 10610000 0.20% 1061 Parker::park 10520000 0.20% 1052 G1CollectedHeap::requires_barriers 10380000 0.20% 1038 java.lang.VirtualThread.unpark 10160000 0.19% 1016 java.time.format.DateTimeTextProvider.findStore 10110000 0.19% 1011 jdk.internal.util.Preconditions.checkFromIndexSize 10000000 0.19% 1000 pthread_mutex_lock 9530000 0.18% 953 FastThreadsListHandle::FastThreadsListHandle 9380000 0.18% 938 com.sun.net.httpserver.Headers.put 9340000 0.18% 934 java.util.HashMap.resize 9330000 0.18% 933 java.lang.Integer.stringSize 9190000 0.17% 919 robaho.net.httpserver.LeftOverInputStream.drain 9060000 0.17% 906 java.lang.StringLatin1.indexOf 9000000 0.17% 900 JvmtiVTMSTransitionDisabler::start_VTMS_transition 8880000 0.17% 888 AccessInternal::PostRuntimeDispatch, (AccessInternal::BarrierType)0, 548964ull>::oop_access_barrier 8390000 0.16% 839 java.lang.AbstractStringBuilder.ensureCapacityInternal 8340000 0.16% 834 robaho.net.httpserver.ExchangeImpl. 8190000 0.15% 819 java.lang.VirtualThread.yieldContinuation 8150000 0.15% 815 Config<(oop_kind)0, G1BarrierSet>::freeze 8130000 0.15% 813 Unsafe_Park 7970000 0.15% 797 java.util.HashMap$HashIterator. 7830000 0.15% 783 pthread_mutex_trylock 7630000 0.14% 763 java.lang.String.hashCode 7560000 0.14% 756 java.io.BufferedOutputStream.growIfNeeded 7530000 0.14% 753 sun.nio.ch.NioSocketImpl.write 7380000 0.14% 738 AccessInternal::PostRuntimeDispatch, (AccessInternal::BarrierType)1, 286822ull>::oop_access_barrier 7320000 0.14% 732 java.util.concurrent.LinkedTransferQueue.xfer 7180000 0.14% 718 java.util.concurrent.ForkJoinPool.signalWork 7020000 0.13% 702 java.lang.invoke.VarHandleReferences$FieldInstanceReadWrite.compareAndSet 6880000 0.13% 688 __commpage_gettimeofday_internal 6860000 0.13% 686 AccessInternal::PostRuntimeDispatch, (AccessInternal::BarrierType)3, 286822ull>::oop_access_barrier 6780000 0.13% 678 java.util.concurrent.locks.AbstractQueuedSynchronizer.signalNext 6580000 0.12% 658 Java_sun_nio_ch_SocketDispatcher_write0 6550000 0.12% 655 com.sun.net.httpserver.Headers.getFirst 6500000 0.12% 650 AccessInternal::PostRuntimeDispatch, (AccessInternal::BarrierType)2, 548964ull>::oop_access_barrier 6260000 0.12% 626 clock_gettime 6130000 0.12% 613 HandleMark::initialize 6080000 0.11% 608 JNIHandles::make_local 6050000 0.11% 605 java.lang.StringLatin1.toChars 5980000 0.11% 598 com.sun.net.httpserver.Headers.containsKey 5970000 0.11% 597 jdk.internal.misc.Unsafe.getAndBitwiseOrInt 5870000 0.11% 587 __psynch_mutexwait 5860000 0.11% 586 sched_yield 5830000 0.11% 583 Unsafe_Unpark 5790000 0.11% 579 java.lang.System$2.setScopedValueCache 5770000 0.11% 577 fdval 5760000 0.11% 576 pthread_cond_signal 5490000 0.10% 549 mach_absolute_time 5450000 0.10% 545 pthread_mutex_unlock 5290000 0.10% 529 sun.nio.ch.KQueue.register 5180000 0.10% 518 robaho.net.httpserver.AuthFilter.doFilter 5110000 0.10% 511 jdk.internal.vm.Continuation.yield 4890000 0.09% 489 com.sun.net.httpserver.Headers.add 4830000 0.09% 483 Java_sun_nio_ch_KQueue_poll 4820000 0.09% 482 __commpage_gettimeofday 4800000 0.09% 480 com.sun.net.httpserver.Filter$Chain.doFilter 4770000 0.09% 477 Java_sun_nio_ch_SocketDispatcher_read0 4620000 0.09% 462 robaho.net.httpserver.NoSyncBufferedInputStream.fill 4610000 0.09% 461 java.util.concurrent.ConcurrentHashMap.addCount 4570000 0.09% 457 java.util.concurrent.ForkJoinPool$WorkQueue.push 4550000 0.09% 455 jlong_disjoint_arraycopy 4530000 0.09% 453 SafeThreadsListPtr::release_stable_list 4490000 0.08% 449 java_lang_Thread::set_is_in_VTMS_transition 4480000 0.08% 448 java.lang.StringLatin1.hashCode 4460000 0.08% 446 jshort_disjoint_arraycopy 4430000 0.08% 443 java.lang.ThreadLocal.getCarrierThreadLocal 4430000 0.08% 443 JavaThread::threadObj 4370000 0.08% 437 java.util.concurrent.ForkJoinPool$WorkQueue.casSlotToNull 4320000 0.08% 432 java.net.URI.match 4270000 0.08% 427 SafepointMechanism::update_poll_values 4220000 0.08% 422 pthread_testcancel 4210000 0.08% 421 jdk.internal.misc.Unsafe.compareAndSetBoolean 4170000 0.08% 417 java.lang.CharacterDataLatin1.equalsIgnoreCase 4100000 0.08% 410 sun.nio.ch.NioSocketImpl.endRead 4100000 0.08% 410 long* thaw > 4070000 0.08% 407 java.util.concurrent.locks.AbstractQueuedSynchronizer.compareAndSetState 4000000 0.08% 400 java.lang.StringLatin1.toLowerCase 3890000 0.07% 389 sun.nio.ch.Util$BufferCache.offerFirst 3890000 0.07% 389 Java_sun_nio_ch_KQueue_register 3870000 0.07% 387 _pthread_cond_updateval 3840000 0.07% 384 java.util.LinkedList.linkLast 3830000 0.07% 383 java.time.format.DateTimePrintContext.adjust 3770000 0.07% 377 java.util.logging.Logger.isLoggable 3620000 0.07% 362 SharedRuntime::notify_jvmti_vthread_unmount 3560000 0.07% 356 HandleMark::~HandleMark 3550000 0.07% 355 robaho.net.httpserver.Request.consume 3540000 0.07% 354 java.time.format.DateTimeFormatterBuilder$CompositePrinterParser.format 3530000 0.07% 353 java.lang.ThreadLocal$ThreadLocalMap.getEntry 3460000 0.07% 346 java.util.concurrent.locks.ReentrantLock$Sync.lock 3430000 0.06% 343 JNIHandleBlock::allocate_handle 3390000 0.06% 339 java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec 3380000 0.06% 338 robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read 3290000 0.06% 329 _pthread_exit_if_canceled 3270000 0.06% 327 jdk.internal.misc.Unsafe.checkPrimitivePointer 3250000 0.06% 325 gettimeofday 3190000 0.06% 319 java.lang.VirtualThread.state 3160000 0.06% 316 java.lang.VirtualThread.runContinuation 3160000 0.06% 316 JavaThreadParkedState::JavaThreadParkedState 3110000 0.06% 311 java.time.format.DateTimeFormatterBuilder$ZoneTextPrinterParser.format 3090000 0.06% 309 java.util.concurrent.ConcurrentHashMap.casTabAt 3070000 0.06% 307 __gettimeofday 3060000 0.06% 306 ZThread::~ZThread 2990000 0.06% 299 java.net.URI$Parser.scan 2980000 0.06% 298 java.util.Locale.equals 2980000 0.06% 298 vtable stub 2940000 0.06% 294 robaho.net.httpserver.ServerImpl$Exchange.run 2920000 0.06% 292 jdk.internal.vm.Continuation.doYield 2910000 0.05% 291 java.lang.StringLatin1.charAt 2910000 0.05% 291 java.lang.String.isLatin1 2900000 0.05% 290 FreezeBase::freeze_fast_existing_chunk 2880000 0.05% 288 java.net.URI$Parser.parse 2860000 0.05% 286 JNI_OnLoad 2830000 0.05% 283 convertReturnVal 2790000 0.05% 279 java_lang_Thread::set_thread_status 2760000 0.05% 276 SharedRuntime::notify_jvmti_vthread_mount 2750000 0.05% 275 java.lang.Class.getComponentType 2730000 0.05% 273 java.lang.VirtualThread.compareAndSetState 2720000 0.05% 272 vectorizedMismatch 2710000 0.05% 271 java.util.concurrent.locks.AbstractQueuedSynchronizer.release 2680000 0.05% 268 java.lang.StringBuffer.toString 2650000 0.05% 265 JavaThread::set_is_in_VTMS_transition 2630000 0.05% 263 java.util.concurrent.ForkJoinPool$WorkQueue.tryPoll 2630000 0.05% 263 java.lang.StringLatin1.regionMatchesCI 2610000 0.05% 261 java.lang.Integer.getChars 2590000 0.05% 259 java.util.concurrent.LinkedTransferQueue.awaitMatch 2590000 0.05% 259 jdk.internal.misc.VM.getNanoTimeAdjustment 2580000 0.05% 258 sun.nio.ch.Poller$Request.finish 2580000 0.05% 258 advance_directory.cold.1 2580000 0.05% 258 java.lang.String. 2570000 0.05% 257 java.util.concurrent.ConcurrentHashMap.putVal 2550000 0.05% 255 jbyte_arraycopy 2540000 0.05% 254 java.util.HashMap.get 2490000 0.05% 249 java.lang.AbstractStringBuilder. 2480000 0.05% 248 jint_disjoint_arraycopy 2420000 0.05% 242 java.time.format.DateTimeFormatterBuilder$CharLiteralPrinterParser.format 2420000 0.05% 242 jdk.internal.vm.Continuation.yield0 2420000 0.05% 242 robaho.net.httpserver.HttpExchangeImpl.sendResponseHeaders 2380000 0.04% 238 java.util.concurrent.LinkedTransferQueue.skipDeadNodesNearHead 2360000 0.04% 236 java.util.concurrent.ForkJoinPool.runWorker 2320000 0.04% 232 robaho.net.httpserver.FixedLengthOutputStream.close 2270000 0.04% 227 os::javaTimeMillis 2260000 0.04% 226 java.util.concurrent.ConcurrentHashMap.get 2260000 0.04% 226 int freeze > 2240000 0.04% 224 java.lang.ref.Reference.refersToImpl 2230000 0.04% 223 java.io.FilterOutputStream.flush 2200000 0.04% 220 java.time.Instant.create 2200000 0.04% 220 JvmtiThreadState::set_thread 2180000 0.04% 218 java.lang.Integer.hashCode 2150000 0.04% 215 _os_semaphore_wait.cold.1 2100000 0.04% 210 JvmtiVTMSTransitionDisabler::finish_VTMS_transition 2050000 0.04% 205 semaphore_wait_trap 2040000 0.04% 204 Thaw >::thaw_fast 2040000 0.04% 204 java.util.concurrent.locks.AbstractQueuedSynchronizer.getState 2040000 0.04% 204 JvmtiVTMSTransitionDisabler::VTMS_vthread_mount 1970000 0.04% 197 cerror_nocancel 1960000 0.04% 196 ThreadsListHandle::~ThreadsListHandle 1950000 0.04% 195 oopDesc::address_field 1940000 0.04% 194 JVM_GetNanoTimeAdjustment 1930000 0.04% 193 java.lang.Long.getChars -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- --- Execution profile --- Total samples : 243127 GC_active : 234 (0.10%) unknown_Java : 1329 (0.55%) not_walkable_Java : 1 (0.00%) --- 181510000 ns (7.47%), 18151 samples [ 0] read [ 1] sun.nio.ch.SocketDispatcher.read0 [ 2] sun.nio.ch.SocketDispatcher.read [ 3] sun.nio.ch.NioSocketImpl.tryRead [ 4] sun.nio.ch.NioSocketImpl.implRead [ 5] sun.nio.ch.NioSocketImpl.read [ 6] sun.nio.ch.NioSocketImpl$1.read [ 7] java.net.Socket$SocketInputStream.read [ 8] java.io.FilterInputStream.read [ 9] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [10] robaho.net.httpserver.NoSyncBufferedInputStream.fill [11] robaho.net.httpserver.NoSyncBufferedInputStream.read [12] robaho.net.httpserver.Request.readLine [13] robaho.net.httpserver.Request. [14] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [15] robaho.net.httpserver.ServerImpl$Exchange.run [16] java.util.concurrent.ThreadPoolExecutor.runWorker [17] java.util.concurrent.ThreadPoolExecutor$Worker.run [18] java.lang.Thread.runWith [19] java.lang.Thread.run --- 155670000 ns (6.40%), 15567 samples [ 0] read [ 1] sun.nio.ch.SocketDispatcher.read0 [ 2] sun.nio.ch.SocketDispatcher.read [ 3] sun.nio.ch.NioSocketImpl.tryRead [ 4] sun.nio.ch.NioSocketImpl.implRead [ 5] sun.nio.ch.NioSocketImpl.read [ 6] sun.nio.ch.NioSocketImpl$1.read [ 7] java.net.Socket$SocketInputStream.read [ 8] java.io.FilterInputStream.read [ 9] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [10] robaho.net.httpserver.NoSyncBufferedInputStream.fill [11] robaho.net.httpserver.NoSyncBufferedInputStream.read [12] robaho.net.httpserver.Request.readLine [13] robaho.net.httpserver.Request. [14] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [15] robaho.net.httpserver.ServerImpl$Exchange.run [16] java.util.concurrent.ThreadPoolExecutor.runWorker [17] java.util.concurrent.ThreadPoolExecutor$Worker.run [18] java.lang.Thread.runWith [19] java.lang.Thread.run --- 151570000 ns (6.23%), 15157 samples [ 0] write [ 1] sun.nio.ch.SocketDispatcher.write0 [ 2] sun.nio.ch.SocketDispatcher.write [ 3] sun.nio.ch.NioSocketImpl.tryWrite [ 4] sun.nio.ch.NioSocketImpl.implWrite [ 5] sun.nio.ch.NioSocketImpl.write [ 6] sun.nio.ch.NioSocketImpl$2.write [ 7] java.net.Socket$SocketOutputStream.write [ 8] robaho.net.httpserver.HttpConnection$ActivityTimerOutputStream.write [ 9] java.io.BufferedOutputStream.flushBuffer [10] java.io.BufferedOutputStream.implFlush [11] java.io.BufferedOutputStream.flush [12] java.io.FilterOutputStream.flush [13] robaho.net.httpserver.FixedLengthOutputStream.close [14] robaho.net.httpserver.PlaceholderOutputStream.close [15] benchmarks.Server.lambda$createPlaintextHandler$0 [16] benchmarks.Server$$Lambda.0x0000000138004ac0.handle [17] com.sun.net.httpserver.Filter$Chain.doFilter [18] robaho.net.httpserver.AuthFilter.doFilter [19] com.sun.net.httpserver.Filter$Chain.doFilter [20] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [21] com.sun.net.httpserver.Filter$Chain.doFilter [22] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [23] robaho.net.httpserver.ServerImpl$Exchange.run [24] java.util.concurrent.ThreadPoolExecutor.runWorker [25] java.util.concurrent.ThreadPoolExecutor$Worker.run [26] java.lang.Thread.runWith [27] java.lang.Thread.run --- 139710000 ns (5.75%), 13971 samples [ 0] write [ 1] sun.nio.ch.SocketDispatcher.write0 [ 2] sun.nio.ch.SocketDispatcher.write [ 3] sun.nio.ch.NioSocketImpl.tryWrite [ 4] sun.nio.ch.NioSocketImpl.implWrite [ 5] sun.nio.ch.NioSocketImpl.write [ 6] sun.nio.ch.NioSocketImpl$2.write [ 7] java.net.Socket$SocketOutputStream.write [ 8] robaho.net.httpserver.HttpConnection$ActivityTimerOutputStream.write [ 9] java.io.BufferedOutputStream.flushBuffer [10] java.io.BufferedOutputStream.implFlush [11] java.io.BufferedOutputStream.flush [12] java.io.FilterOutputStream.flush [13] robaho.net.httpserver.FixedLengthOutputStream.close [14] robaho.net.httpserver.PlaceholderOutputStream.close [15] benchmarks.Server.lambda$createPlaintextHandler$0 [16] benchmarks.Server$$Lambda.0x0000000138004ac0.handle [17] com.sun.net.httpserver.Filter$Chain.doFilter [18] robaho.net.httpserver.AuthFilter.doFilter [19] com.sun.net.httpserver.Filter$Chain.doFilter [20] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [21] com.sun.net.httpserver.Filter$Chain.doFilter [22] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [23] robaho.net.httpserver.ServerImpl$Exchange.run [24] java.util.concurrent.ThreadPoolExecutor.runWorker [25] java.util.concurrent.ThreadPoolExecutor$Worker.run [26] java.lang.Thread.runWith [27] java.lang.Thread.run --- 78090000 ns (3.21%), 7809 samples [ 0] read [ 1] sun.nio.ch.SocketDispatcher.read0 [ 2] sun.nio.ch.SocketDispatcher.read [ 3] sun.nio.ch.NioSocketImpl.tryRead [ 4] sun.nio.ch.NioSocketImpl.implRead [ 5] sun.nio.ch.NioSocketImpl.read [ 6] sun.nio.ch.NioSocketImpl$1.read [ 7] java.net.Socket$SocketInputStream.read [ 8] java.io.FilterInputStream.read [ 9] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [10] robaho.net.httpserver.NoSyncBufferedInputStream.fill [11] robaho.net.httpserver.NoSyncBufferedInputStream.read [12] robaho.net.httpserver.Request.readLine [13] robaho.net.httpserver.Request. [14] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [15] robaho.net.httpserver.ServerImpl$Exchange.run [16] java.util.concurrent.ThreadPoolExecutor.runWorker [17] java.util.concurrent.ThreadPoolExecutor$Worker.run [18] java.lang.Thread.runWith [19] java.lang.Thread.run --- 76740000 ns (3.16%), 7674 samples [ 0] write [ 1] sun.nio.ch.SocketDispatcher.write0 [ 2] sun.nio.ch.SocketDispatcher.write [ 3] sun.nio.ch.NioSocketImpl.tryWrite [ 4] sun.nio.ch.NioSocketImpl.implWrite [ 5] sun.nio.ch.NioSocketImpl.write [ 6] sun.nio.ch.NioSocketImpl$2.write [ 7] java.net.Socket$SocketOutputStream.write [ 8] robaho.net.httpserver.HttpConnection$ActivityTimerOutputStream.write [ 9] java.io.BufferedOutputStream.flushBuffer [10] java.io.BufferedOutputStream.implFlush [11] java.io.BufferedOutputStream.flush [12] java.io.FilterOutputStream.flush [13] robaho.net.httpserver.FixedLengthOutputStream.close [14] robaho.net.httpserver.PlaceholderOutputStream.close [15] benchmarks.Server.lambda$createPlaintextHandler$0 [16] benchmarks.Server$$Lambda.0x0000000138004ac0.handle [17] com.sun.net.httpserver.Filter$Chain.doFilter [18] robaho.net.httpserver.AuthFilter.doFilter [19] com.sun.net.httpserver.Filter$Chain.doFilter [20] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [21] com.sun.net.httpserver.Filter$Chain.doFilter [22] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [23] robaho.net.httpserver.ServerImpl$Exchange.run [24] java.util.concurrent.ThreadPoolExecutor.runWorker [25] java.util.concurrent.ThreadPoolExecutor$Worker.run [26] java.lang.Thread.runWith [27] java.lang.Thread.run --- 64800000 ns (2.67%), 6480 samples [ 0] read [ 1] sun.nio.ch.SocketDispatcher.read0 [ 2] sun.nio.ch.SocketDispatcher.read [ 3] sun.nio.ch.NioSocketImpl.tryRead [ 4] sun.nio.ch.NioSocketImpl.implRead [ 5] sun.nio.ch.NioSocketImpl.read [ 6] sun.nio.ch.NioSocketImpl$1.read [ 7] java.net.Socket$SocketInputStream.read [ 8] java.io.FilterInputStream.read [ 9] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [10] robaho.net.httpserver.NoSyncBufferedInputStream.fill [11] robaho.net.httpserver.NoSyncBufferedInputStream.read [12] robaho.net.httpserver.Request.readLine [13] robaho.net.httpserver.Request. [14] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [15] robaho.net.httpserver.ServerImpl$Exchange.run [16] java.util.concurrent.ThreadPoolExecutor.runWorker [17] java.util.concurrent.ThreadPoolExecutor$Worker.run [18] java.lang.Thread.runWith [19] java.lang.Thread.run --- 64310000 ns (2.65%), 6431 samples [ 0] read [ 1] sun.nio.ch.SocketDispatcher.read0 [ 2] sun.nio.ch.SocketDispatcher.read [ 3] sun.nio.ch.NioSocketImpl.tryRead [ 4] sun.nio.ch.NioSocketImpl.implRead [ 5] sun.nio.ch.NioSocketImpl.read [ 6] sun.nio.ch.NioSocketImpl$1.read [ 7] java.net.Socket$SocketInputStream.read [ 8] java.io.FilterInputStream.read [ 9] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [10] robaho.net.httpserver.NoSyncBufferedInputStream.fill [11] robaho.net.httpserver.NoSyncBufferedInputStream.read [12] robaho.net.httpserver.Request.readLine [13] robaho.net.httpserver.Request. [14] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [15] robaho.net.httpserver.ServerImpl$Exchange.run [16] java.util.concurrent.ThreadPoolExecutor.runWorker [17] java.util.concurrent.ThreadPoolExecutor$Worker.run [18] java.lang.Thread.runWith [19] java.lang.Thread.run --- 62700000 ns (2.58%), 6270 samples [ 0] write [ 1] sun.nio.ch.SocketDispatcher.write0 [ 2] sun.nio.ch.SocketDispatcher.write [ 3] sun.nio.ch.NioSocketImpl.tryWrite [ 4] sun.nio.ch.NioSocketImpl.implWrite [ 5] sun.nio.ch.NioSocketImpl.write [ 6] sun.nio.ch.NioSocketImpl$2.write [ 7] java.net.Socket$SocketOutputStream.write [ 8] robaho.net.httpserver.HttpConnection$ActivityTimerOutputStream.write [ 9] java.io.BufferedOutputStream.flushBuffer [10] java.io.BufferedOutputStream.implFlush [11] java.io.BufferedOutputStream.flush [12] java.io.FilterOutputStream.flush [13] robaho.net.httpserver.FixedLengthOutputStream.close [14] robaho.net.httpserver.PlaceholderOutputStream.close [15] benchmarks.Server.lambda$createPlaintextHandler$0 [16] benchmarks.Server$$Lambda.0x0000000138004ac0.handle [17] com.sun.net.httpserver.Filter$Chain.doFilter [18] robaho.net.httpserver.AuthFilter.doFilter [19] com.sun.net.httpserver.Filter$Chain.doFilter [20] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [21] com.sun.net.httpserver.Filter$Chain.doFilter [22] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [23] robaho.net.httpserver.ServerImpl$Exchange.run [24] java.util.concurrent.ThreadPoolExecutor.runWorker [25] java.util.concurrent.ThreadPoolExecutor$Worker.run [26] java.lang.Thread.runWith [27] java.lang.Thread.run --- 62650000 ns (2.58%), 6265 samples [ 0] read [ 1] sun.nio.ch.SocketDispatcher.read0 [ 2] sun.nio.ch.SocketDispatcher.read [ 3] sun.nio.ch.NioSocketImpl.tryRead [ 4] sun.nio.ch.NioSocketImpl.implRead [ 5] sun.nio.ch.NioSocketImpl.read [ 6] sun.nio.ch.NioSocketImpl$1.read [ 7] java.net.Socket$SocketInputStream.read [ 8] java.io.FilterInputStream.read [ 9] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [10] robaho.net.httpserver.NoSyncBufferedInputStream.fill [11] robaho.net.httpserver.NoSyncBufferedInputStream.read [12] robaho.net.httpserver.Request.readLine [13] robaho.net.httpserver.Request. [14] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [15] robaho.net.httpserver.ServerImpl$Exchange.run [16] java.util.concurrent.ThreadPoolExecutor.runWorker [17] java.util.concurrent.ThreadPoolExecutor$Worker.run [18] java.lang.Thread.runWith [19] java.lang.Thread.run --- 62330000 ns (2.56%), 6233 samples [ 0] write [ 1] sun.nio.ch.SocketDispatcher.write0 [ 2] sun.nio.ch.SocketDispatcher.write [ 3] sun.nio.ch.NioSocketImpl.tryWrite [ 4] sun.nio.ch.NioSocketImpl.implWrite [ 5] sun.nio.ch.NioSocketImpl.write [ 6] sun.nio.ch.NioSocketImpl$2.write [ 7] java.net.Socket$SocketOutputStream.write [ 8] robaho.net.httpserver.HttpConnection$ActivityTimerOutputStream.write [ 9] java.io.BufferedOutputStream.flushBuffer [10] java.io.BufferedOutputStream.implFlush [11] java.io.BufferedOutputStream.flush [12] java.io.FilterOutputStream.flush [13] robaho.net.httpserver.FixedLengthOutputStream.close [14] robaho.net.httpserver.PlaceholderOutputStream.close [15] benchmarks.Server.lambda$createPlaintextHandler$0 [16] benchmarks.Server$$Lambda.0x0000000138004ac0.handle [17] com.sun.net.httpserver.Filter$Chain.doFilter [18] robaho.net.httpserver.AuthFilter.doFilter [19] com.sun.net.httpserver.Filter$Chain.doFilter [20] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [21] com.sun.net.httpserver.Filter$Chain.doFilter [22] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [23] robaho.net.httpserver.ServerImpl$Exchange.run [24] java.util.concurrent.ThreadPoolExecutor.runWorker [25] java.util.concurrent.ThreadPoolExecutor$Worker.run [26] java.lang.Thread.runWith [27] java.lang.Thread.run --- 62320000 ns (2.56%), 6232 samples [ 0] write [ 1] sun.nio.ch.SocketDispatcher.write0 [ 2] sun.nio.ch.SocketDispatcher.write [ 3] sun.nio.ch.NioSocketImpl.tryWrite [ 4] sun.nio.ch.NioSocketImpl.implWrite [ 5] sun.nio.ch.NioSocketImpl.write [ 6] sun.nio.ch.NioSocketImpl$2.write [ 7] java.net.Socket$SocketOutputStream.write [ 8] robaho.net.httpserver.HttpConnection$ActivityTimerOutputStream.write [ 9] java.io.BufferedOutputStream.flushBuffer [10] java.io.BufferedOutputStream.implFlush [11] java.io.BufferedOutputStream.flush [12] java.io.FilterOutputStream.flush [13] robaho.net.httpserver.FixedLengthOutputStream.close [14] robaho.net.httpserver.PlaceholderOutputStream.close [15] benchmarks.Server.lambda$createPlaintextHandler$0 [16] benchmarks.Server$$Lambda.0x0000000138004ac0.handle [17] com.sun.net.httpserver.Filter$Chain.doFilter [18] robaho.net.httpserver.AuthFilter.doFilter [19] com.sun.net.httpserver.Filter$Chain.doFilter [20] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [21] com.sun.net.httpserver.Filter$Chain.doFilter [22] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [23] robaho.net.httpserver.ServerImpl$Exchange.run [24] java.util.concurrent.ThreadPoolExecutor.runWorker [25] java.util.concurrent.ThreadPoolExecutor$Worker.run [26] java.lang.Thread.runWith [27] java.lang.Thread.run --- 52050000 ns (2.14%), 5205 samples [ 0] read [ 1] sun.nio.ch.SocketDispatcher.read0 [ 2] sun.nio.ch.SocketDispatcher.read [ 3] sun.nio.ch.NioSocketImpl.tryRead [ 4] sun.nio.ch.NioSocketImpl.implRead [ 5] sun.nio.ch.NioSocketImpl.read [ 6] sun.nio.ch.NioSocketImpl$1.read [ 7] java.net.Socket$SocketInputStream.read [ 8] java.io.FilterInputStream.read [ 9] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [10] robaho.net.httpserver.NoSyncBufferedInputStream.fill [11] robaho.net.httpserver.NoSyncBufferedInputStream.read [12] robaho.net.httpserver.Request.readLine [13] robaho.net.httpserver.Request. [14] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [15] robaho.net.httpserver.ServerImpl$Exchange.run [16] java.util.concurrent.ThreadPoolExecutor.runWorker [17] java.util.concurrent.ThreadPoolExecutor$Worker.run [18] java.lang.Thread.runWith [19] java.lang.Thread.run --- 51700000 ns (2.13%), 5170 samples [ 0] read [ 1] sun.nio.ch.SocketDispatcher.read0 [ 2] sun.nio.ch.SocketDispatcher.read [ 3] sun.nio.ch.NioSocketImpl.tryRead [ 4] sun.nio.ch.NioSocketImpl.implRead [ 5] sun.nio.ch.NioSocketImpl.read [ 6] sun.nio.ch.NioSocketImpl$1.read [ 7] java.net.Socket$SocketInputStream.read [ 8] java.io.FilterInputStream.read [ 9] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [10] robaho.net.httpserver.NoSyncBufferedInputStream.fill [11] robaho.net.httpserver.NoSyncBufferedInputStream.read [12] robaho.net.httpserver.Request.readLine [13] robaho.net.httpserver.Request. [14] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [15] robaho.net.httpserver.ServerImpl$Exchange.run [16] java.util.concurrent.ThreadPoolExecutor.runWorker [17] java.util.concurrent.ThreadPoolExecutor$Worker.run [18] java.lang.Thread.runWith [19] java.lang.Thread.run --- 51240000 ns (2.11%), 5124 samples [ 0] write [ 1] sun.nio.ch.SocketDispatcher.write0 [ 2] sun.nio.ch.SocketDispatcher.write [ 3] sun.nio.ch.NioSocketImpl.tryWrite [ 4] sun.nio.ch.NioSocketImpl.implWrite [ 5] sun.nio.ch.NioSocketImpl.write [ 6] sun.nio.ch.NioSocketImpl$2.write [ 7] java.net.Socket$SocketOutputStream.write [ 8] robaho.net.httpserver.HttpConnection$ActivityTimerOutputStream.write [ 9] java.io.BufferedOutputStream.flushBuffer [10] java.io.BufferedOutputStream.implFlush [11] java.io.BufferedOutputStream.flush [12] java.io.FilterOutputStream.flush [13] robaho.net.httpserver.FixedLengthOutputStream.close [14] robaho.net.httpserver.PlaceholderOutputStream.close [15] benchmarks.Server.lambda$createPlaintextHandler$0 [16] benchmarks.Server$$Lambda.0x0000000138004ac0.handle [17] com.sun.net.httpserver.Filter$Chain.doFilter [18] robaho.net.httpserver.AuthFilter.doFilter [19] com.sun.net.httpserver.Filter$Chain.doFilter [20] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [21] com.sun.net.httpserver.Filter$Chain.doFilter [22] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [23] robaho.net.httpserver.ServerImpl$Exchange.run [24] java.util.concurrent.ThreadPoolExecutor.runWorker [25] java.util.concurrent.ThreadPoolExecutor$Worker.run [26] java.lang.Thread.runWith [27] java.lang.Thread.run --- 50930000 ns (2.09%), 5093 samples [ 0] read [ 1] sun.nio.ch.SocketDispatcher.read0 [ 2] sun.nio.ch.SocketDispatcher.read [ 3] sun.nio.ch.NioSocketImpl.tryRead [ 4] sun.nio.ch.NioSocketImpl.implRead [ 5] sun.nio.ch.NioSocketImpl.read [ 6] sun.nio.ch.NioSocketImpl$1.read [ 7] java.net.Socket$SocketInputStream.read [ 8] java.io.FilterInputStream.read [ 9] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [10] robaho.net.httpserver.NoSyncBufferedInputStream.fill [11] robaho.net.httpserver.NoSyncBufferedInputStream.read [12] robaho.net.httpserver.Request.readLine [13] robaho.net.httpserver.Request. [14] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [15] robaho.net.httpserver.ServerImpl$Exchange.run [16] java.util.concurrent.ThreadPoolExecutor.runWorker [17] java.util.concurrent.ThreadPoolExecutor$Worker.run [18] java.lang.Thread.runWith [19] java.lang.Thread.run --- 50550000 ns (2.08%), 5055 samples [ 0] write [ 1] sun.nio.ch.SocketDispatcher.write0 [ 2] sun.nio.ch.SocketDispatcher.write [ 3] sun.nio.ch.NioSocketImpl.tryWrite [ 4] sun.nio.ch.NioSocketImpl.implWrite [ 5] sun.nio.ch.NioSocketImpl.write [ 6] sun.nio.ch.NioSocketImpl$2.write [ 7] java.net.Socket$SocketOutputStream.write [ 8] robaho.net.httpserver.HttpConnection$ActivityTimerOutputStream.write [ 9] java.io.BufferedOutputStream.flushBuffer [10] java.io.BufferedOutputStream.implFlush [11] java.io.BufferedOutputStream.flush [12] java.io.FilterOutputStream.flush [13] robaho.net.httpserver.FixedLengthOutputStream.close [14] robaho.net.httpserver.PlaceholderOutputStream.close [15] benchmarks.Server.lambda$createPlaintextHandler$0 [16] benchmarks.Server$$Lambda.0x0000000138004ac0.handle [17] com.sun.net.httpserver.Filter$Chain.doFilter [18] robaho.net.httpserver.AuthFilter.doFilter [19] com.sun.net.httpserver.Filter$Chain.doFilter [20] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [21] com.sun.net.httpserver.Filter$Chain.doFilter [22] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [23] robaho.net.httpserver.ServerImpl$Exchange.run [24] java.util.concurrent.ThreadPoolExecutor.runWorker [25] java.util.concurrent.ThreadPoolExecutor$Worker.run [26] java.lang.Thread.runWith [27] java.lang.Thread.run --- 50400000 ns (2.07%), 5040 samples [ 0] write [ 1] sun.nio.ch.SocketDispatcher.write0 [ 2] sun.nio.ch.SocketDispatcher.write [ 3] sun.nio.ch.NioSocketImpl.tryWrite [ 4] sun.nio.ch.NioSocketImpl.implWrite [ 5] sun.nio.ch.NioSocketImpl.write [ 6] sun.nio.ch.NioSocketImpl$2.write [ 7] java.net.Socket$SocketOutputStream.write [ 8] robaho.net.httpserver.HttpConnection$ActivityTimerOutputStream.write [ 9] java.io.BufferedOutputStream.flushBuffer [10] java.io.BufferedOutputStream.implFlush [11] java.io.BufferedOutputStream.flush [12] java.io.FilterOutputStream.flush [13] robaho.net.httpserver.FixedLengthOutputStream.close [14] robaho.net.httpserver.PlaceholderOutputStream.close [15] benchmarks.Server.lambda$createPlaintextHandler$0 [16] benchmarks.Server$$Lambda.0x0000000138004ac0.handle [17] com.sun.net.httpserver.Filter$Chain.doFilter [18] robaho.net.httpserver.AuthFilter.doFilter [19] com.sun.net.httpserver.Filter$Chain.doFilter [20] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [21] com.sun.net.httpserver.Filter$Chain.doFilter [22] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [23] robaho.net.httpserver.ServerImpl$Exchange.run [24] java.util.concurrent.ThreadPoolExecutor.runWorker [25] java.util.concurrent.ThreadPoolExecutor$Worker.run [26] java.lang.Thread.runWith [27] java.lang.Thread.run --- 39170000 ns (1.61%), 3917 samples [ 0] read [ 1] sun.nio.ch.SocketDispatcher.read0 [ 2] sun.nio.ch.SocketDispatcher.read [ 3] sun.nio.ch.NioSocketImpl.tryRead [ 4] sun.nio.ch.NioSocketImpl.implRead [ 5] sun.nio.ch.NioSocketImpl.read [ 6] sun.nio.ch.NioSocketImpl$1.read [ 7] java.net.Socket$SocketInputStream.read [ 8] java.io.FilterInputStream.read [ 9] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [10] robaho.net.httpserver.NoSyncBufferedInputStream.fill [11] robaho.net.httpserver.NoSyncBufferedInputStream.read [12] robaho.net.httpserver.Request.readLine [13] robaho.net.httpserver.Request. [14] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [15] robaho.net.httpserver.ServerImpl$Exchange.run [16] java.util.concurrent.ThreadPoolExecutor.runWorker [17] java.util.concurrent.ThreadPoolExecutor$Worker.run [18] java.lang.Thread.runWith [19] java.lang.Thread.run --- 38470000 ns (1.58%), 3847 samples [ 0] write [ 1] sun.nio.ch.SocketDispatcher.write0 [ 2] sun.nio.ch.SocketDispatcher.write [ 3] sun.nio.ch.NioSocketImpl.tryWrite [ 4] sun.nio.ch.NioSocketImpl.implWrite [ 5] sun.nio.ch.NioSocketImpl.write [ 6] sun.nio.ch.NioSocketImpl$2.write [ 7] java.net.Socket$SocketOutputStream.write [ 8] robaho.net.httpserver.HttpConnection$ActivityTimerOutputStream.write [ 9] java.io.BufferedOutputStream.flushBuffer [10] java.io.BufferedOutputStream.implFlush [11] java.io.BufferedOutputStream.flush [12] java.io.FilterOutputStream.flush [13] robaho.net.httpserver.FixedLengthOutputStream.close [14] robaho.net.httpserver.PlaceholderOutputStream.close [15] benchmarks.Server.lambda$createPlaintextHandler$0 [16] benchmarks.Server$$Lambda.0x0000000138004ac0.handle [17] com.sun.net.httpserver.Filter$Chain.doFilter [18] robaho.net.httpserver.AuthFilter.doFilter [19] com.sun.net.httpserver.Filter$Chain.doFilter [20] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [21] com.sun.net.httpserver.Filter$Chain.doFilter [22] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [23] robaho.net.httpserver.ServerImpl$Exchange.run [24] java.util.concurrent.ThreadPoolExecutor.runWorker [25] java.util.concurrent.ThreadPoolExecutor$Worker.run [26] java.lang.Thread.runWith [27] java.lang.Thread.run --- 37610000 ns (1.55%), 3761 samples [ 0] write [ 1] sun.nio.ch.SocketDispatcher.write0 [ 2] sun.nio.ch.SocketDispatcher.write [ 3] sun.nio.ch.NioSocketImpl.tryWrite [ 4] sun.nio.ch.NioSocketImpl.implWrite [ 5] sun.nio.ch.NioSocketImpl.write [ 6] sun.nio.ch.NioSocketImpl$2.write [ 7] java.net.Socket$SocketOutputStream.write [ 8] robaho.net.httpserver.HttpConnection$ActivityTimerOutputStream.write [ 9] java.io.BufferedOutputStream.flushBuffer [10] java.io.BufferedOutputStream.implFlush [11] java.io.BufferedOutputStream.flush [12] java.io.FilterOutputStream.flush [13] robaho.net.httpserver.FixedLengthOutputStream.close [14] robaho.net.httpserver.PlaceholderOutputStream.close [15] benchmarks.Server.lambda$createPlaintextHandler$0 [16] benchmarks.Server$$Lambda.0x0000000138004ac0.handle [17] com.sun.net.httpserver.Filter$Chain.doFilter [18] robaho.net.httpserver.AuthFilter.doFilter [19] com.sun.net.httpserver.Filter$Chain.doFilter [20] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [21] com.sun.net.httpserver.Filter$Chain.doFilter [22] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [23] robaho.net.httpserver.ServerImpl$Exchange.run [24] java.util.concurrent.ThreadPoolExecutor.runWorker [25] java.util.concurrent.ThreadPoolExecutor$Worker.run [26] java.lang.Thread.runWith [27] java.lang.Thread.run --- 26150000 ns (1.08%), 2615 samples [ 0] read [ 1] sun.nio.ch.SocketDispatcher.read0 [ 2] sun.nio.ch.SocketDispatcher.read [ 3] sun.nio.ch.NioSocketImpl.tryRead [ 4] sun.nio.ch.NioSocketImpl.implRead [ 5] sun.nio.ch.NioSocketImpl.read [ 6] sun.nio.ch.NioSocketImpl$1.read [ 7] java.net.Socket$SocketInputStream.read [ 8] java.io.FilterInputStream.read [ 9] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [10] robaho.net.httpserver.NoSyncBufferedInputStream.fill [11] robaho.net.httpserver.NoSyncBufferedInputStream.read [12] robaho.net.httpserver.Request.readLine [13] robaho.net.httpserver.Request. [14] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [15] robaho.net.httpserver.ServerImpl$Exchange.run [16] java.util.concurrent.ThreadPoolExecutor.runWorker [17] java.util.concurrent.ThreadPoolExecutor$Worker.run [18] java.lang.Thread.runWith [19] java.lang.Thread.run --- 25590000 ns (1.05%), 2559 samples [ 0] write [ 1] sun.nio.ch.SocketDispatcher.write0 [ 2] sun.nio.ch.SocketDispatcher.write [ 3] sun.nio.ch.NioSocketImpl.tryWrite [ 4] sun.nio.ch.NioSocketImpl.implWrite [ 5] sun.nio.ch.NioSocketImpl.write [ 6] sun.nio.ch.NioSocketImpl$2.write [ 7] java.net.Socket$SocketOutputStream.write [ 8] robaho.net.httpserver.HttpConnection$ActivityTimerOutputStream.write [ 9] java.io.BufferedOutputStream.flushBuffer [10] java.io.BufferedOutputStream.implFlush [11] java.io.BufferedOutputStream.flush [12] java.io.FilterOutputStream.flush [13] robaho.net.httpserver.FixedLengthOutputStream.close [14] robaho.net.httpserver.PlaceholderOutputStream.close [15] benchmarks.Server.lambda$createPlaintextHandler$0 [16] benchmarks.Server$$Lambda.0x0000000138004ac0.handle [17] com.sun.net.httpserver.Filter$Chain.doFilter [18] robaho.net.httpserver.AuthFilter.doFilter [19] com.sun.net.httpserver.Filter$Chain.doFilter [20] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [21] com.sun.net.httpserver.Filter$Chain.doFilter [22] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [23] robaho.net.httpserver.ServerImpl$Exchange.run [24] java.util.concurrent.ThreadPoolExecutor.runWorker [25] java.util.concurrent.ThreadPoolExecutor$Worker.run [26] java.lang.Thread.runWith [27] java.lang.Thread.run --- 11320000 ns (0.47%), 1132 samples [ 0] sun.nio.ch.SocketDispatcher.read0 [ 1] sun.nio.ch.SocketDispatcher.read [ 2] sun.nio.ch.NioSocketImpl.tryRead [ 3] sun.nio.ch.NioSocketImpl.implRead [ 4] sun.nio.ch.NioSocketImpl.read [ 5] sun.nio.ch.NioSocketImpl$1.read [ 6] java.net.Socket$SocketInputStream.read [ 7] java.io.FilterInputStream.read [ 8] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [ 9] robaho.net.httpserver.NoSyncBufferedInputStream.fill [10] robaho.net.httpserver.NoSyncBufferedInputStream.read [11] robaho.net.httpserver.Request.readLine [12] robaho.net.httpserver.Request. [13] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [14] robaho.net.httpserver.ServerImpl$Exchange.run [15] java.util.concurrent.ThreadPoolExecutor.runWorker [16] java.util.concurrent.ThreadPoolExecutor$Worker.run [17] java.lang.Thread.runWith [18] java.lang.Thread.run --- 10360000 ns (0.43%), 1036 samples [ 0] sun.nio.ch.SocketDispatcher.read0 [ 1] sun.nio.ch.SocketDispatcher.read [ 2] sun.nio.ch.NioSocketImpl.tryRead [ 3] sun.nio.ch.NioSocketImpl.implRead [ 4] sun.nio.ch.NioSocketImpl.read [ 5] sun.nio.ch.NioSocketImpl$1.read [ 6] java.net.Socket$SocketInputStream.read [ 7] java.io.FilterInputStream.read [ 8] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [ 9] robaho.net.httpserver.NoSyncBufferedInputStream.fill [10] robaho.net.httpserver.NoSyncBufferedInputStream.read [11] robaho.net.httpserver.Request.readLine [12] robaho.net.httpserver.Request. [13] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [14] robaho.net.httpserver.ServerImpl$Exchange.run [15] java.util.concurrent.ThreadPoolExecutor.runWorker [16] java.util.concurrent.ThreadPoolExecutor$Worker.run [17] java.lang.Thread.runWith [18] java.lang.Thread.run --- 5750000 ns (0.24%), 575 samples [ 0] robaho.net.httpserver.NoSyncBufferedInputStream.getBufIfOpen [ 1] robaho.net.httpserver.NoSyncBufferedInputStream.read [ 2] robaho.net.httpserver.Request.readLine [ 3] robaho.net.httpserver.Request. [ 4] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [ 5] robaho.net.httpserver.ServerImpl$Exchange.run [ 6] java.util.concurrent.ThreadPoolExecutor.runWorker [ 7] java.util.concurrent.ThreadPoolExecutor$Worker.run [ 8] java.lang.Thread.runWith [ 9] java.lang.Thread.run --- 5270000 ns (0.22%), 527 samples [ 0] java.lang.StringBuffer. [ 1] robaho.net.httpserver.Request.readLine [ 2] robaho.net.httpserver.Request. [ 3] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [ 4] robaho.net.httpserver.ServerImpl$Exchange.run [ 5] java.util.concurrent.ThreadPoolExecutor.runWorker [ 6] java.util.concurrent.ThreadPoolExecutor$Worker.run [ 7] java.lang.Thread.runWith [ 8] java.lang.Thread.run --- 5210000 ns (0.21%), 521 samples [ 0] java.lang.StringBuffer. [ 1] robaho.net.httpserver.Request.readLine [ 2] robaho.net.httpserver.Request. [ 3] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [ 4] robaho.net.httpserver.ServerImpl$Exchange.run [ 5] java.util.concurrent.ThreadPoolExecutor.runWorker [ 6] java.util.concurrent.ThreadPoolExecutor$Worker.run [ 7] java.lang.Thread.runWith [ 8] java.lang.Thread.run --- 5110000 ns (0.21%), 511 samples [ 0] java.net.URI. [ 1] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [ 2] robaho.net.httpserver.ServerImpl$Exchange.run [ 3] java.util.concurrent.ThreadPoolExecutor.runWorker [ 4] java.util.concurrent.ThreadPoolExecutor$Worker.run [ 5] java.lang.Thread.runWith [ 6] java.lang.Thread.run --- 5080000 ns (0.21%), 508 samples [ 0] sun.nio.ch.SocketDispatcher.read0 [ 1] sun.nio.ch.SocketDispatcher.read [ 2] sun.nio.ch.NioSocketImpl.tryRead [ 3] sun.nio.ch.NioSocketImpl.implRead [ 4] sun.nio.ch.NioSocketImpl.read [ 5] sun.nio.ch.NioSocketImpl$1.read [ 6] java.net.Socket$SocketInputStream.read [ 7] java.io.FilterInputStream.read [ 8] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [ 9] robaho.net.httpserver.NoSyncBufferedInputStream.fill [10] robaho.net.httpserver.NoSyncBufferedInputStream.read [11] robaho.net.httpserver.Request.readLine [12] robaho.net.httpserver.Request. [13] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [14] robaho.net.httpserver.ServerImpl$Exchange.run [15] java.util.concurrent.ThreadPoolExecutor.runWorker [16] java.util.concurrent.ThreadPoolExecutor$Worker.run [17] java.lang.Thread.runWith [18] java.lang.Thread.run --- 4790000 ns (0.20%), 479 samples [ 0] robaho.net.httpserver.NoSyncBufferedInputStream.getBufIfOpen [ 1] robaho.net.httpserver.NoSyncBufferedInputStream.read [ 2] robaho.net.httpserver.Request.readLine [ 3] robaho.net.httpserver.Request. [ 4] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [ 5] robaho.net.httpserver.ServerImpl$Exchange.run [ 6] java.util.concurrent.ThreadPoolExecutor.runWorker [ 7] java.util.concurrent.ThreadPoolExecutor$Worker.run [ 8] java.lang.Thread.runWith [ 9] java.lang.Thread.run --- 4580000 ns (0.19%), 458 samples [ 0] sun.nio.ch.SocketDispatcher.read0 [ 1] sun.nio.ch.SocketDispatcher.read [ 2] sun.nio.ch.NioSocketImpl.tryRead [ 3] sun.nio.ch.NioSocketImpl.implRead [ 4] sun.nio.ch.NioSocketImpl.read [ 5] sun.nio.ch.NioSocketImpl$1.read [ 6] java.net.Socket$SocketInputStream.read [ 7] java.io.FilterInputStream.read [ 8] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [ 9] robaho.net.httpserver.NoSyncBufferedInputStream.fill [10] robaho.net.httpserver.NoSyncBufferedInputStream.read [11] robaho.net.httpserver.Request.readLine [12] robaho.net.httpserver.Request. [13] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [14] robaho.net.httpserver.ServerImpl$Exchange.run [15] java.util.concurrent.ThreadPoolExecutor.runWorker [16] java.util.concurrent.ThreadPoolExecutor$Worker.run [17] java.lang.Thread.runWith [18] java.lang.Thread.run --- 4360000 ns (0.18%), 436 samples [ 0] sun.nio.ch.SocketDispatcher.read0 [ 1] sun.nio.ch.SocketDispatcher.read [ 2] sun.nio.ch.NioSocketImpl.tryRead [ 3] sun.nio.ch.NioSocketImpl.implRead [ 4] sun.nio.ch.NioSocketImpl.read [ 5] sun.nio.ch.NioSocketImpl$1.read [ 6] java.net.Socket$SocketInputStream.read [ 7] java.io.FilterInputStream.read [ 8] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [ 9] robaho.net.httpserver.NoSyncBufferedInputStream.fill [10] robaho.net.httpserver.NoSyncBufferedInputStream.read [11] robaho.net.httpserver.Request.readLine [12] robaho.net.httpserver.Request. [13] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [14] robaho.net.httpserver.ServerImpl$Exchange.run [15] java.util.concurrent.ThreadPoolExecutor.runWorker [16] java.util.concurrent.ThreadPoolExecutor$Worker.run [17] java.lang.Thread.runWith [18] java.lang.Thread.run --- 4280000 ns (0.18%), 428 samples [ 0] sun.nio.ch.SocketDispatcher.read0 [ 1] sun.nio.ch.SocketDispatcher.read [ 2] sun.nio.ch.NioSocketImpl.tryRead [ 3] sun.nio.ch.NioSocketImpl.implRead [ 4] sun.nio.ch.NioSocketImpl.read [ 5] sun.nio.ch.NioSocketImpl$1.read [ 6] java.net.Socket$SocketInputStream.read [ 7] java.io.FilterInputStream.read [ 8] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [ 9] robaho.net.httpserver.NoSyncBufferedInputStream.fill [10] robaho.net.httpserver.NoSyncBufferedInputStream.read [11] robaho.net.httpserver.Request.readLine [12] robaho.net.httpserver.Request. [13] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [14] robaho.net.httpserver.ServerImpl$Exchange.run [15] java.util.concurrent.ThreadPoolExecutor.runWorker [16] java.util.concurrent.ThreadPoolExecutor$Worker.run [17] java.lang.Thread.runWith [18] java.lang.Thread.run --- 3600000 ns (0.15%), 360 samples [ 0] itable stub [ 1] java.time.format.DateTimeFormatterBuilder$CompositePrinterParser.format [ 2] java.time.format.DateTimeFormatter.formatTo [ 3] java.time.format.DateTimeFormatter.format [ 4] robaho.net.httpserver.ExchangeImpl.sendResponseHeaders [ 5] robaho.net.httpserver.HttpExchangeImpl.sendResponseHeaders [ 6] benchmarks.Server.lambda$createPlaintextHandler$0 [ 7] benchmarks.Server$$Lambda.0x0000000138004ac0.handle [ 8] com.sun.net.httpserver.Filter$Chain.doFilter [ 9] robaho.net.httpserver.AuthFilter.doFilter [10] com.sun.net.httpserver.Filter$Chain.doFilter [11] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [12] com.sun.net.httpserver.Filter$Chain.doFilter [13] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [14] robaho.net.httpserver.ServerImpl$Exchange.run [15] java.util.concurrent.ThreadPoolExecutor.runWorker [16] java.util.concurrent.ThreadPoolExecutor$Worker.run [17] java.lang.Thread.runWith [18] java.lang.Thread.run --- 3530000 ns (0.15%), 353 samples [ 0] sun.nio.ch.SocketDispatcher.write0 [ 1] sun.nio.ch.SocketDispatcher.write [ 2] sun.nio.ch.NioSocketImpl.tryWrite [ 3] sun.nio.ch.NioSocketImpl.implWrite [ 4] sun.nio.ch.NioSocketImpl.write [ 5] sun.nio.ch.NioSocketImpl$2.write [ 6] java.net.Socket$SocketOutputStream.write [ 7] robaho.net.httpserver.HttpConnection$ActivityTimerOutputStream.write [ 8] java.io.BufferedOutputStream.flushBuffer [ 9] java.io.BufferedOutputStream.implFlush [10] java.io.BufferedOutputStream.flush [11] java.io.FilterOutputStream.flush [12] robaho.net.httpserver.FixedLengthOutputStream.close [13] robaho.net.httpserver.PlaceholderOutputStream.close [14] benchmarks.Server.lambda$createPlaintextHandler$0 [15] benchmarks.Server$$Lambda.0x0000000138004ac0.handle [16] com.sun.net.httpserver.Filter$Chain.doFilter [17] robaho.net.httpserver.AuthFilter.doFilter [18] com.sun.net.httpserver.Filter$Chain.doFilter [19] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [20] com.sun.net.httpserver.Filter$Chain.doFilter [21] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [22] robaho.net.httpserver.ServerImpl$Exchange.run [23] java.util.concurrent.ThreadPoolExecutor.runWorker [24] java.util.concurrent.ThreadPoolExecutor$Worker.run [25] java.lang.Thread.runWith [26] java.lang.Thread.run --- 3440000 ns (0.14%), 344 samples [ 0] java.net.URI. [ 1] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [ 2] robaho.net.httpserver.ServerImpl$Exchange.run [ 3] java.util.concurrent.ThreadPoolExecutor.runWorker [ 4] java.util.concurrent.ThreadPoolExecutor$Worker.run [ 5] java.lang.Thread.runWith [ 6] java.lang.Thread.run --- 3390000 ns (0.14%), 339 samples [ 0] robaho.net.httpserver.ExchangeImpl.bytes [ 1] robaho.net.httpserver.ExchangeImpl.write [ 2] robaho.net.httpserver.ExchangeImpl.sendResponseHeaders [ 3] robaho.net.httpserver.HttpExchangeImpl.sendResponseHeaders [ 4] benchmarks.Server.lambda$createPlaintextHandler$0 [ 5] benchmarks.Server$$Lambda.0x0000000138004ac0.handle [ 6] com.sun.net.httpserver.Filter$Chain.doFilter [ 7] robaho.net.httpserver.AuthFilter.doFilter [ 8] com.sun.net.httpserver.Filter$Chain.doFilter [ 9] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [10] com.sun.net.httpserver.Filter$Chain.doFilter [11] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [12] robaho.net.httpserver.ServerImpl$Exchange.run [13] java.util.concurrent.ThreadPoolExecutor.runWorker [14] java.util.concurrent.ThreadPoolExecutor$Worker.run [15] java.lang.Thread.runWith [16] java.lang.Thread.run --- 3360000 ns (0.14%), 336 samples [ 0] sun.nio.ch.SocketDispatcher.read0 [ 1] sun.nio.ch.SocketDispatcher.read [ 2] sun.nio.ch.NioSocketImpl.tryRead [ 3] sun.nio.ch.NioSocketImpl.implRead [ 4] sun.nio.ch.NioSocketImpl.read [ 5] sun.nio.ch.NioSocketImpl$1.read [ 6] java.net.Socket$SocketInputStream.read [ 7] java.io.FilterInputStream.read [ 8] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [ 9] robaho.net.httpserver.NoSyncBufferedInputStream.fill [10] robaho.net.httpserver.NoSyncBufferedInputStream.read [11] robaho.net.httpserver.Request.readLine [12] robaho.net.httpserver.Request. [13] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [14] robaho.net.httpserver.ServerImpl$Exchange.run [15] java.util.concurrent.ThreadPoolExecutor.runWorker [16] java.util.concurrent.ThreadPoolExecutor$Worker.run [17] java.lang.Thread.runWith [18] java.lang.Thread.run --- 3350000 ns (0.14%), 335 samples [ 0] sun.nio.ch.SocketDispatcher.read0 [ 1] sun.nio.ch.SocketDispatcher.read [ 2] sun.nio.ch.NioSocketImpl.tryRead [ 3] sun.nio.ch.NioSocketImpl.implRead [ 4] sun.nio.ch.NioSocketImpl.read [ 5] sun.nio.ch.NioSocketImpl$1.read [ 6] java.net.Socket$SocketInputStream.read [ 7] java.io.FilterInputStream.read [ 8] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [ 9] robaho.net.httpserver.NoSyncBufferedInputStream.fill [10] robaho.net.httpserver.NoSyncBufferedInputStream.read [11] robaho.net.httpserver.Request.readLine [12] robaho.net.httpserver.Request. [13] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [14] robaho.net.httpserver.ServerImpl$Exchange.run [15] java.util.concurrent.ThreadPoolExecutor.runWorker [16] java.util.concurrent.ThreadPoolExecutor$Worker.run [17] java.lang.Thread.runWith [18] java.lang.Thread.run --- 3210000 ns (0.13%), 321 samples [ 0] sun.nio.ch.SocketDispatcher.read0 [ 1] sun.nio.ch.SocketDispatcher.read [ 2] sun.nio.ch.NioSocketImpl.tryRead [ 3] sun.nio.ch.NioSocketImpl.implRead [ 4] sun.nio.ch.NioSocketImpl.read [ 5] sun.nio.ch.NioSocketImpl$1.read [ 6] java.net.Socket$SocketInputStream.read [ 7] java.io.FilterInputStream.read [ 8] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [ 9] robaho.net.httpserver.NoSyncBufferedInputStream.fill [10] robaho.net.httpserver.NoSyncBufferedInputStream.read [11] robaho.net.httpserver.Request.readLine [12] robaho.net.httpserver.Request. [13] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [14] robaho.net.httpserver.ServerImpl$Exchange.run [15] java.util.concurrent.ThreadPoolExecutor.runWorker [16] java.util.concurrent.ThreadPoolExecutor$Worker.run [17] java.lang.Thread.runWith [18] java.lang.Thread.run --- 3130000 ns (0.13%), 313 samples [ 0] close [ 1] sun.nio.ch.UnixDispatcher.close0 [ 2] sun.nio.ch.SocketDispatcher.close [ 3] sun.nio.ch.NioSocketImpl.lambda$closerFor$0 [ 4] sun.nio.ch.NioSocketImpl$$Lambda.0x000000013804e7f8.run [ 5] jdk.internal.ref.CleanerImpl$PhantomCleanableRef.performCleanup [ 6] jdk.internal.ref.PhantomCleanable.clean [ 7] sun.nio.ch.NioSocketImpl.tryClose [ 8] sun.nio.ch.NioSocketImpl.close [ 9] java.net.Socket.close [10] java.net.Socket$SocketInputStream.close [11] java.io.FilterInputStream.close [12] java.io.FilterInputStream.close [13] robaho.net.httpserver.NoSyncBufferedInputStream.close [14] robaho.net.httpserver.HttpConnection.close [15] robaho.net.httpserver.ServerImpl.closeConnection [16] robaho.net.httpserver.ServerImpl$ConnectionCleanerTask.run [17] java.util.TimerThread.mainLoop [18] java.util.TimerThread.run --- 3080000 ns (0.13%), 308 samples [ 0] robaho.net.httpserver.Request.consume [ 1] robaho.net.httpserver.Request.readLine [ 2] robaho.net.httpserver.Request. [ 3] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [ 4] robaho.net.httpserver.ServerImpl$Exchange.run [ 5] java.util.concurrent.ThreadPoolExecutor.runWorker [ 6] java.util.concurrent.ThreadPoolExecutor$Worker.run [ 7] java.lang.Thread.runWith [ 8] java.lang.Thread.run --- 3070000 ns (0.13%), 307 samples [ 0] robaho.net.httpserver.Request.consume [ 1] robaho.net.httpserver.Request.readLine [ 2] robaho.net.httpserver.Request. [ 3] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [ 4] robaho.net.httpserver.ServerImpl$Exchange.run [ 5] java.util.concurrent.ThreadPoolExecutor.runWorker [ 6] java.util.concurrent.ThreadPoolExecutor$Worker.run [ 7] java.lang.Thread.runWith [ 8] java.lang.Thread.run --- 3020000 ns (0.12%), 302 samples [ 0] sun.nio.ch.SocketDispatcher.write0 [ 1] sun.nio.ch.SocketDispatcher.write [ 2] sun.nio.ch.NioSocketImpl.tryWrite [ 3] sun.nio.ch.NioSocketImpl.implWrite [ 4] sun.nio.ch.NioSocketImpl.write [ 5] sun.nio.ch.NioSocketImpl$2.write [ 6] java.net.Socket$SocketOutputStream.write [ 7] robaho.net.httpserver.HttpConnection$ActivityTimerOutputStream.write [ 8] java.io.BufferedOutputStream.flushBuffer [ 9] java.io.BufferedOutputStream.implFlush [10] java.io.BufferedOutputStream.flush [11] java.io.FilterOutputStream.flush [12] robaho.net.httpserver.FixedLengthOutputStream.close [13] robaho.net.httpserver.PlaceholderOutputStream.close [14] benchmarks.Server.lambda$createPlaintextHandler$0 [15] benchmarks.Server$$Lambda.0x0000000138004ac0.handle [16] com.sun.net.httpserver.Filter$Chain.doFilter [17] robaho.net.httpserver.AuthFilter.doFilter [18] com.sun.net.httpserver.Filter$Chain.doFilter [19] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [20] com.sun.net.httpserver.Filter$Chain.doFilter [21] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [22] robaho.net.httpserver.ServerImpl$Exchange.run [23] java.util.concurrent.ThreadPoolExecutor.runWorker [24] java.util.concurrent.ThreadPoolExecutor$Worker.run [25] java.lang.Thread.runWith [26] java.lang.Thread.run --- 2950000 ns (0.12%), 295 samples [ 0] robaho.net.httpserver.ExchangeImpl.bytes [ 1] robaho.net.httpserver.ExchangeImpl.write [ 2] robaho.net.httpserver.ExchangeImpl.sendResponseHeaders [ 3] robaho.net.httpserver.HttpExchangeImpl.sendResponseHeaders [ 4] benchmarks.Server.lambda$createPlaintextHandler$0 [ 5] benchmarks.Server$$Lambda.0x0000000138004ac0.handle [ 6] com.sun.net.httpserver.Filter$Chain.doFilter [ 7] robaho.net.httpserver.AuthFilter.doFilter [ 8] com.sun.net.httpserver.Filter$Chain.doFilter [ 9] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [10] com.sun.net.httpserver.Filter$Chain.doFilter [11] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [12] robaho.net.httpserver.ServerImpl$Exchange.run [13] java.util.concurrent.ThreadPoolExecutor.runWorker [14] java.util.concurrent.ThreadPoolExecutor$Worker.run [15] java.lang.Thread.runWith [16] java.lang.Thread.run --- 2950000 ns (0.12%), 295 samples [ 0] itable stub [ 1] java.time.format.DateTimeFormatterBuilder$CompositePrinterParser.format [ 2] java.time.format.DateTimeFormatter.formatTo [ 3] java.time.format.DateTimeFormatter.format [ 4] robaho.net.httpserver.ExchangeImpl.sendResponseHeaders [ 5] robaho.net.httpserver.HttpExchangeImpl.sendResponseHeaders [ 6] benchmarks.Server.lambda$createPlaintextHandler$0 [ 7] benchmarks.Server$$Lambda.0x0000000138004ac0.handle [ 8] com.sun.net.httpserver.Filter$Chain.doFilter [ 9] robaho.net.httpserver.AuthFilter.doFilter [10] com.sun.net.httpserver.Filter$Chain.doFilter [11] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [12] com.sun.net.httpserver.Filter$Chain.doFilter [13] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [14] robaho.net.httpserver.ServerImpl$Exchange.run [15] java.util.concurrent.ThreadPoolExecutor.runWorker [16] java.util.concurrent.ThreadPoolExecutor$Worker.run [17] java.lang.Thread.runWith [18] java.lang.Thread.run --- 2740000 ns (0.11%), 274 samples [ 0] com.sun.net.httpserver.Headers.add [ 1] benchmarks.Server.lambda$createPlaintextHandler$0 [ 2] benchmarks.Server$$Lambda.0x0000000138004ac0.handle [ 3] com.sun.net.httpserver.Filter$Chain.doFilter [ 4] robaho.net.httpserver.AuthFilter.doFilter [ 5] com.sun.net.httpserver.Filter$Chain.doFilter [ 6] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [ 7] com.sun.net.httpserver.Filter$Chain.doFilter [ 8] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [ 9] robaho.net.httpserver.ServerImpl$Exchange.run [10] java.util.concurrent.ThreadPoolExecutor.runWorker [11] java.util.concurrent.ThreadPoolExecutor$Worker.run [12] java.lang.Thread.runWith [13] java.lang.Thread.run --- 2720000 ns (0.11%), 272 samples [ 0] robaho.net.httpserver.Request.headers [ 1] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [ 2] robaho.net.httpserver.ServerImpl$Exchange.run [ 3] java.util.concurrent.ThreadPoolExecutor.runWorker [ 4] java.util.concurrent.ThreadPoolExecutor$Worker.run [ 5] java.lang.Thread.runWith [ 6] java.lang.Thread.run --- 2680000 ns (0.11%), 268 samples [ 0] sun.nio.ch.SocketDispatcher.read0 [ 1] sun.nio.ch.SocketDispatcher.read [ 2] sun.nio.ch.NioSocketImpl.tryRead [ 3] sun.nio.ch.NioSocketImpl.implRead [ 4] sun.nio.ch.NioSocketImpl.read [ 5] sun.nio.ch.NioSocketImpl$1.read [ 6] java.net.Socket$SocketInputStream.read [ 7] java.io.FilterInputStream.read [ 8] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [ 9] robaho.net.httpserver.NoSyncBufferedInputStream.fill [10] robaho.net.httpserver.NoSyncBufferedInputStream.read [11] robaho.net.httpserver.Request.readLine [12] robaho.net.httpserver.Request. [13] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [14] robaho.net.httpserver.ServerImpl$Exchange.run [15] java.util.concurrent.ThreadPoolExecutor.runWorker [16] java.util.concurrent.ThreadPoolExecutor$Worker.run [17] java.lang.Thread.runWith [18] java.lang.Thread.run --- 2520000 ns (0.10%), 252 samples [ 0] com.sun.net.httpserver.Headers.get [ 1] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [ 2] robaho.net.httpserver.ServerImpl$Exchange.run [ 3] java.util.concurrent.ThreadPoolExecutor.runWorker [ 4] java.util.concurrent.ThreadPoolExecutor$Worker.run [ 5] java.lang.Thread.runWith [ 6] java.lang.Thread.run --- 2370000 ns (0.10%), 237 samples [ 0] com.sun.net.httpserver.Headers.add [ 1] benchmarks.Server.lambda$createPlaintextHandler$0 [ 2] benchmarks.Server$$Lambda.0x0000000138004ac0.handle [ 3] com.sun.net.httpserver.Filter$Chain.doFilter [ 4] robaho.net.httpserver.AuthFilter.doFilter [ 5] com.sun.net.httpserver.Filter$Chain.doFilter [ 6] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [ 7] com.sun.net.httpserver.Filter$Chain.doFilter [ 8] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [ 9] robaho.net.httpserver.ServerImpl$Exchange.run [10] java.util.concurrent.ThreadPoolExecutor.runWorker [11] java.util.concurrent.ThreadPoolExecutor$Worker.run [12] java.lang.Thread.runWith [13] java.lang.Thread.run --- 2290000 ns (0.09%), 229 samples [ 0] java.lang.AbstractStringBuilder.appendChars [ 1] java.lang.AbstractStringBuilder.append [ 2] java.lang.StringBuffer.append [ 3] robaho.net.httpserver.Request.readLine [ 4] robaho.net.httpserver.Request. [ 5] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [ 6] robaho.net.httpserver.ServerImpl$Exchange.run [ 7] java.util.concurrent.ThreadPoolExecutor.runWorker [ 8] java.util.concurrent.ThreadPoolExecutor$Worker.run [ 9] java.lang.Thread.runWith [10] java.lang.Thread.run --- 2250000 ns (0.09%), 225 samples [ 0] robaho.net.httpserver.Request.headers [ 1] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [ 2] robaho.net.httpserver.ServerImpl$Exchange.run [ 3] java.util.concurrent.ThreadPoolExecutor.runWorker [ 4] java.util.concurrent.ThreadPoolExecutor$Worker.run [ 5] java.lang.Thread.runWith [ 6] java.lang.Thread.run --- 2150000 ns (0.09%), 215 samples [ 0] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [ 1] robaho.net.httpserver.ServerImpl$Exchange.run [ 2] java.util.concurrent.ThreadPoolExecutor.runWorker [ 3] java.util.concurrent.ThreadPoolExecutor$Worker.run [ 4] java.lang.Thread.runWith [ 5] java.lang.Thread.run --- 2110000 ns (0.09%), 211 samples [ 0] robaho.net.httpserver.Request.readLine [ 1] robaho.net.httpserver.Request. [ 2] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [ 3] robaho.net.httpserver.ServerImpl$Exchange.run [ 4] java.util.concurrent.ThreadPoolExecutor.runWorker [ 5] java.util.concurrent.ThreadPoolExecutor$Worker.run [ 6] java.lang.Thread.runWith [ 7] java.lang.Thread.run --- 2100000 ns (0.09%), 210 samples [ 0] robaho.net.httpserver.ExchangeImpl.write [ 1] robaho.net.httpserver.ExchangeImpl.sendResponseHeaders [ 2] robaho.net.httpserver.HttpExchangeImpl.sendResponseHeaders [ 3] benchmarks.Server.lambda$createPlaintextHandler$0 [ 4] benchmarks.Server$$Lambda.0x0000000138004ac0.handle [ 5] com.sun.net.httpserver.Filter$Chain.doFilter [ 6] robaho.net.httpserver.AuthFilter.doFilter [ 7] com.sun.net.httpserver.Filter$Chain.doFilter [ 8] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [ 9] com.sun.net.httpserver.Filter$Chain.doFilter [10] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [11] robaho.net.httpserver.ServerImpl$Exchange.run [12] java.util.concurrent.ThreadPoolExecutor.runWorker [13] java.util.concurrent.ThreadPoolExecutor$Worker.run [14] java.lang.Thread.runWith [15] java.lang.Thread.run --- 2030000 ns (0.08%), 203 samples [ 0] com.sun.net.httpserver.Headers.get [ 1] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [ 2] robaho.net.httpserver.ServerImpl$Exchange.run [ 3] java.util.concurrent.ThreadPoolExecutor.runWorker [ 4] java.util.concurrent.ThreadPoolExecutor$Worker.run [ 5] java.lang.Thread.runWith [ 6] java.lang.Thread.run --- 1980000 ns (0.08%), 198 samples [ 0] robaho.net.httpserver.ExchangeImpl.bytes [ 1] robaho.net.httpserver.ExchangeImpl.write [ 2] robaho.net.httpserver.ExchangeImpl.sendResponseHeaders [ 3] robaho.net.httpserver.HttpExchangeImpl.sendResponseHeaders [ 4] benchmarks.Server.lambda$createPlaintextHandler$0 [ 5] benchmarks.Server$$Lambda.0x0000000138004ac0.handle [ 6] com.sun.net.httpserver.Filter$Chain.doFilter [ 7] robaho.net.httpserver.AuthFilter.doFilter [ 8] com.sun.net.httpserver.Filter$Chain.doFilter [ 9] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [10] com.sun.net.httpserver.Filter$Chain.doFilter [11] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [12] robaho.net.httpserver.ServerImpl$Exchange.run [13] java.util.concurrent.ThreadPoolExecutor.runWorker [14] java.util.concurrent.ThreadPoolExecutor$Worker.run [15] java.lang.Thread.runWith [16] java.lang.Thread.run --- 1910000 ns (0.08%), 191 samples [ 0] robaho.net.httpserver.Request.readLine [ 1] robaho.net.httpserver.Request. [ 2] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [ 3] robaho.net.httpserver.ServerImpl$Exchange.run [ 4] java.util.concurrent.ThreadPoolExecutor.runWorker [ 5] java.util.concurrent.ThreadPoolExecutor$Worker.run [ 6] java.lang.Thread.runWith [ 7] java.lang.Thread.run --- 1910000 ns (0.08%), 191 samples [ 0] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [ 1] robaho.net.httpserver.ServerImpl$Exchange.run [ 2] java.util.concurrent.ThreadPoolExecutor.runWorker [ 3] java.util.concurrent.ThreadPoolExecutor$Worker.run [ 4] java.lang.Thread.runWith [ 5] java.lang.Thread.run --- 1890000 ns (0.08%), 189 samples [ 0] robaho.net.httpserver.NoSyncBufferedInputStream.getBufIfOpen [ 1] robaho.net.httpserver.NoSyncBufferedInputStream.read [ 2] robaho.net.httpserver.Request.readLine [ 3] robaho.net.httpserver.Request. [ 4] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [ 5] robaho.net.httpserver.ServerImpl$Exchange.run [ 6] java.util.concurrent.ThreadPoolExecutor.runWorker [ 7] java.util.concurrent.ThreadPoolExecutor$Worker.run [ 8] java.lang.Thread.runWith [ 9] java.lang.Thread.run --- 1860000 ns (0.08%), 186 samples [ 0] robaho.net.httpserver.NoSyncBufferedInputStream.getBufIfOpen [ 1] robaho.net.httpserver.NoSyncBufferedInputStream.read [ 2] robaho.net.httpserver.Request.readLine [ 3] robaho.net.httpserver.Request. [ 4] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [ 5] robaho.net.httpserver.ServerImpl$Exchange.run [ 6] java.util.concurrent.ThreadPoolExecutor.runWorker [ 7] java.util.concurrent.ThreadPoolExecutor$Worker.run [ 8] java.lang.Thread.runWith [ 9] java.lang.Thread.run --- 1850000 ns (0.08%), 185 samples [ 0] sun.nio.ch.NativeThread.current [ 1] sun.nio.ch.NioSocketImpl.beginWrite [ 2] sun.nio.ch.NioSocketImpl.implWrite [ 3] sun.nio.ch.NioSocketImpl.write [ 4] sun.nio.ch.NioSocketImpl$2.write [ 5] java.net.Socket$SocketOutputStream.write [ 6] robaho.net.httpserver.HttpConnection$ActivityTimerOutputStream.write [ 7] java.io.BufferedOutputStream.flushBuffer [ 8] java.io.BufferedOutputStream.implFlush [ 9] java.io.BufferedOutputStream.flush [10] java.io.FilterOutputStream.flush [11] robaho.net.httpserver.FixedLengthOutputStream.close [12] robaho.net.httpserver.PlaceholderOutputStream.close [13] benchmarks.Server.lambda$createPlaintextHandler$0 [14] benchmarks.Server$$Lambda.0x0000000138004ac0.handle [15] com.sun.net.httpserver.Filter$Chain.doFilter [16] robaho.net.httpserver.AuthFilter.doFilter [17] com.sun.net.httpserver.Filter$Chain.doFilter [18] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [19] com.sun.net.httpserver.Filter$Chain.doFilter [20] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [21] robaho.net.httpserver.ServerImpl$Exchange.run [22] java.util.concurrent.ThreadPoolExecutor.runWorker [23] java.util.concurrent.ThreadPoolExecutor$Worker.run [24] java.lang.Thread.runWith [25] java.lang.Thread.run --- 1840000 ns (0.08%), 184 samples [ 0] com.sun.net.httpserver.Headers.put [ 1] [unknown_Java] --- 1750000 ns (0.07%), 175 samples [ 0] sun.nio.ch.NativeThread.current [ 1] sun.nio.ch.NioSocketImpl.beginWrite [ 2] sun.nio.ch.NioSocketImpl.implWrite [ 3] sun.nio.ch.NioSocketImpl.write [ 4] sun.nio.ch.NioSocketImpl$2.write [ 5] java.net.Socket$SocketOutputStream.write [ 6] robaho.net.httpserver.HttpConnection$ActivityTimerOutputStream.write [ 7] java.io.BufferedOutputStream.flushBuffer [ 8] java.io.BufferedOutputStream.implFlush [ 9] java.io.BufferedOutputStream.flush [10] java.io.FilterOutputStream.flush [11] robaho.net.httpserver.FixedLengthOutputStream.close [12] robaho.net.httpserver.PlaceholderOutputStream.close [13] benchmarks.Server.lambda$createPlaintextHandler$0 [14] benchmarks.Server$$Lambda.0x0000000138004ac0.handle [15] com.sun.net.httpserver.Filter$Chain.doFilter [16] robaho.net.httpserver.AuthFilter.doFilter [17] com.sun.net.httpserver.Filter$Chain.doFilter [18] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [19] com.sun.net.httpserver.Filter$Chain.doFilter [20] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [21] robaho.net.httpserver.ServerImpl$Exchange.run [22] java.util.concurrent.ThreadPoolExecutor.runWorker [23] java.util.concurrent.ThreadPoolExecutor$Worker.run [24] java.lang.Thread.runWith [25] java.lang.Thread.run --- 1720000 ns (0.07%), 172 samples [ 0] com.sun.net.httpserver.Headers.getFirst [ 1] [unknown_Java] --- 1710000 ns (0.07%), 171 samples [ 0] java.lang.AbstractStringBuilder.appendChars [ 1] java.lang.AbstractStringBuilder.append [ 2] java.lang.StringBuffer.append [ 3] robaho.net.httpserver.Request.readLine [ 4] robaho.net.httpserver.Request. [ 5] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [ 6] robaho.net.httpserver.ServerImpl$Exchange.run [ 7] java.util.concurrent.ThreadPoolExecutor.runWorker [ 8] java.util.concurrent.ThreadPoolExecutor$Worker.run [ 9] java.lang.Thread.runWith [10] java.lang.Thread.run --- 1690000 ns (0.07%), 169 samples [ 0] Java_sun_nio_ch_SocketDispatcher_read0 [ 1] sun.nio.ch.SocketDispatcher.read0 [ 2] sun.nio.ch.SocketDispatcher.read [ 3] sun.nio.ch.NioSocketImpl.tryRead [ 4] sun.nio.ch.NioSocketImpl.implRead [ 5] sun.nio.ch.NioSocketImpl.read [ 6] sun.nio.ch.NioSocketImpl$1.read [ 7] java.net.Socket$SocketInputStream.read [ 8] java.io.FilterInputStream.read [ 9] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [10] robaho.net.httpserver.NoSyncBufferedInputStream.fill [11] robaho.net.httpserver.NoSyncBufferedInputStream.read [12] robaho.net.httpserver.Request.readLine [13] robaho.net.httpserver.Request. [14] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [15] robaho.net.httpserver.ServerImpl$Exchange.run [16] java.util.concurrent.ThreadPoolExecutor.runWorker [17] java.util.concurrent.ThreadPoolExecutor$Worker.run [18] java.lang.Thread.runWith [19] java.lang.Thread.run --- 1680000 ns (0.07%), 168 samples [ 0] sun.nio.ch.SocketDispatcher.read0 [ 1] sun.nio.ch.SocketDispatcher.read [ 2] sun.nio.ch.NioSocketImpl.tryRead [ 3] sun.nio.ch.NioSocketImpl.implRead [ 4] sun.nio.ch.NioSocketImpl.read [ 5] sun.nio.ch.NioSocketImpl$1.read [ 6] java.net.Socket$SocketInputStream.read [ 7] java.io.FilterInputStream.read [ 8] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [ 9] robaho.net.httpserver.NoSyncBufferedInputStream.fill [10] robaho.net.httpserver.NoSyncBufferedInputStream.read [11] robaho.net.httpserver.Request.readLine [12] robaho.net.httpserver.Request. [13] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [14] robaho.net.httpserver.ServerImpl$Exchange.run [15] java.util.concurrent.ThreadPoolExecutor.runWorker [16] java.util.concurrent.ThreadPoolExecutor$Worker.run [17] java.lang.Thread.runWith [18] java.lang.Thread.run --- 1670000 ns (0.07%), 167 samples [ 0] robaho.net.httpserver.Request.headers [ 1] [unknown_Java] --- 1660000 ns (0.07%), 166 samples [ 0] java.time.format.DateTimeFormatterBuilder$NumberPrinterParser.format [ 1] java.time.format.DateTimeFormatterBuilder$CompositePrinterParser.format [ 2] java.time.format.DateTimeFormatter.formatTo [ 3] java.time.format.DateTimeFormatter.format [ 4] robaho.net.httpserver.ExchangeImpl.sendResponseHeaders [ 5] robaho.net.httpserver.HttpExchangeImpl.sendResponseHeaders [ 6] benchmarks.Server.lambda$createPlaintextHandler$0 [ 7] benchmarks.Server$$Lambda.0x0000000138004ac0.handle [ 8] com.sun.net.httpserver.Filter$Chain.doFilter [ 9] robaho.net.httpserver.AuthFilter.doFilter [10] com.sun.net.httpserver.Filter$Chain.doFilter [11] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [12] com.sun.net.httpserver.Filter$Chain.doFilter [13] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [14] robaho.net.httpserver.ServerImpl$Exchange.run [15] java.util.concurrent.ThreadPoolExecutor.runWorker [16] java.util.concurrent.ThreadPoolExecutor$Worker.run [17] java.lang.Thread.runWith [18] java.lang.Thread.run --- 1640000 ns (0.07%), 164 samples [ 0] robaho.net.httpserver.ExchangeImpl.write [ 1] robaho.net.httpserver.ExchangeImpl.sendResponseHeaders [ 2] robaho.net.httpserver.HttpExchangeImpl.sendResponseHeaders [ 3] benchmarks.Server.lambda$createPlaintextHandler$0 [ 4] benchmarks.Server$$Lambda.0x0000000138004ac0.handle [ 5] com.sun.net.httpserver.Filter$Chain.doFilter [ 6] robaho.net.httpserver.AuthFilter.doFilter [ 7] com.sun.net.httpserver.Filter$Chain.doFilter [ 8] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [ 9] com.sun.net.httpserver.Filter$Chain.doFilter [10] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [11] robaho.net.httpserver.ServerImpl$Exchange.run [12] java.util.concurrent.ThreadPoolExecutor.runWorker [13] java.util.concurrent.ThreadPoolExecutor$Worker.run [14] java.lang.Thread.runWith [15] java.lang.Thread.run --- 1640000 ns (0.07%), 164 samples [ 0] robaho.net.httpserver.NoSyncBufferedInputStream.getBufIfOpen [ 1] robaho.net.httpserver.NoSyncBufferedInputStream.read [ 2] robaho.net.httpserver.Request.readLine [ 3] robaho.net.httpserver.Request. [ 4] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [ 5] robaho.net.httpserver.ServerImpl$Exchange.run [ 6] java.util.concurrent.ThreadPoolExecutor.runWorker [ 7] java.util.concurrent.ThreadPoolExecutor$Worker.run [ 8] java.lang.Thread.runWith [ 9] java.lang.Thread.run --- 1600000 ns (0.07%), 160 samples [ 0] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [ 1] robaho.net.httpserver.ServerImpl$Exchange.run [ 2] java.util.concurrent.ThreadPoolExecutor.runWorker [ 3] java.util.concurrent.ThreadPoolExecutor$Worker.run [ 4] java.lang.Thread.runWith [ 5] java.lang.Thread.run --- 1600000 ns (0.07%), 160 samples [ 0] Java_sun_nio_ch_SocketDispatcher_read0 [ 1] sun.nio.ch.SocketDispatcher.read0 [ 2] sun.nio.ch.SocketDispatcher.read [ 3] sun.nio.ch.NioSocketImpl.tryRead [ 4] sun.nio.ch.NioSocketImpl.implRead [ 5] sun.nio.ch.NioSocketImpl.read [ 6] sun.nio.ch.NioSocketImpl$1.read [ 7] java.net.Socket$SocketInputStream.read [ 8] java.io.FilterInputStream.read [ 9] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [10] robaho.net.httpserver.NoSyncBufferedInputStream.fill [11] robaho.net.httpserver.NoSyncBufferedInputStream.read [12] robaho.net.httpserver.Request.readLine [13] robaho.net.httpserver.Request. [14] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [15] robaho.net.httpserver.ServerImpl$Exchange.run [16] java.util.concurrent.ThreadPoolExecutor.runWorker [17] java.util.concurrent.ThreadPoolExecutor$Worker.run [18] java.lang.Thread.runWith [19] java.lang.Thread.run --- 1600000 ns (0.07%), 160 samples [ 0] com.sun.net.httpserver.Headers.getFirst [ 1] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [ 2] robaho.net.httpserver.ServerImpl$Exchange.run [ 3] java.util.concurrent.ThreadPoolExecutor.runWorker [ 4] java.util.concurrent.ThreadPoolExecutor$Worker.run [ 5] java.lang.Thread.runWith [ 6] java.lang.Thread.run --- 1600000 ns (0.07%), 160 samples [ 0] itable stub [ 1] java.time.format.DateTimeFormatterBuilder$CompositePrinterParser.format [ 2] java.time.format.DateTimeFormatter.formatTo [ 3] java.time.format.DateTimeFormatter.format [ 4] robaho.net.httpserver.ExchangeImpl.sendResponseHeaders [ 5] robaho.net.httpserver.HttpExchangeImpl.sendResponseHeaders [ 6] benchmarks.Server.lambda$createPlaintextHandler$0 [ 7] benchmarks.Server$$Lambda.0x0000000138004ac0.handle [ 8] com.sun.net.httpserver.Filter$Chain.doFilter [ 9] robaho.net.httpserver.AuthFilter.doFilter [10] com.sun.net.httpserver.Filter$Chain.doFilter [11] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [12] com.sun.net.httpserver.Filter$Chain.doFilter [13] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [14] robaho.net.httpserver.ServerImpl$Exchange.run [15] java.util.concurrent.ThreadPoolExecutor.runWorker [16] java.util.concurrent.ThreadPoolExecutor$Worker.run [17] java.lang.Thread.runWith [18] java.lang.Thread.run --- 1580000 ns (0.06%), 158 samples [ 0] java.lang.StringBuffer. [ 1] robaho.net.httpserver.Request.readLine [ 2] robaho.net.httpserver.Request. [ 3] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [ 4] robaho.net.httpserver.ServerImpl$Exchange.run [ 5] java.util.concurrent.ThreadPoolExecutor.runWorker [ 6] java.util.concurrent.ThreadPoolExecutor$Worker.run [ 7] java.lang.Thread.runWith [ 8] java.lang.Thread.run --- 1580000 ns (0.06%), 158 samples [ 0] java.lang.StringBuffer. [ 1] robaho.net.httpserver.Request.readLine [ 2] robaho.net.httpserver.Request. [ 3] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [ 4] robaho.net.httpserver.ServerImpl$Exchange.run [ 5] java.util.concurrent.ThreadPoolExecutor.runWorker [ 6] java.util.concurrent.ThreadPoolExecutor$Worker.run [ 7] java.lang.Thread.runWith [ 8] java.lang.Thread.run --- 1550000 ns (0.06%), 155 samples [ 0] java.net.URI$Parser.scan [ 1] java.net.URI$Parser.parseHierarchical [ 2] java.net.URI$Parser.parse [ 3] java.net.URI. [ 4] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [ 5] robaho.net.httpserver.ServerImpl$Exchange.run [ 6] java.util.concurrent.ThreadPoolExecutor.runWorker [ 7] java.util.concurrent.ThreadPoolExecutor$Worker.run [ 8] java.lang.Thread.runWith [ 9] java.lang.Thread.run --- 1540000 ns (0.06%), 154 samples [ 0] robaho.net.httpserver.Request.headers [ 1] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [ 2] robaho.net.httpserver.ServerImpl$Exchange.run [ 3] java.util.concurrent.ThreadPoolExecutor.runWorker [ 4] java.util.concurrent.ThreadPoolExecutor$Worker.run [ 5] java.lang.Thread.runWith [ 6] java.lang.Thread.run --- 1540000 ns (0.06%), 154 samples [ 0] robaho.net.httpserver.ExchangeImpl.bytes [ 1] robaho.net.httpserver.ExchangeImpl.write [ 2] robaho.net.httpserver.ExchangeImpl.sendResponseHeaders [ 3] robaho.net.httpserver.HttpExchangeImpl.sendResponseHeaders [ 4] benchmarks.Server.lambda$createPlaintextHandler$0 [ 5] benchmarks.Server$$Lambda.0x0000000138004ac0.handle [ 6] com.sun.net.httpserver.Filter$Chain.doFilter [ 7] robaho.net.httpserver.AuthFilter.doFilter [ 8] com.sun.net.httpserver.Filter$Chain.doFilter [ 9] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [10] com.sun.net.httpserver.Filter$Chain.doFilter [11] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [12] robaho.net.httpserver.ServerImpl$Exchange.run [13] java.util.concurrent.ThreadPoolExecutor.runWorker [14] java.util.concurrent.ThreadPoolExecutor$Worker.run [15] java.lang.Thread.runWith [16] java.lang.Thread.run --- 1530000 ns (0.06%), 153 samples [ 0] java.lang.StringBuffer. [ 1] robaho.net.httpserver.Request.readLine [ 2] robaho.net.httpserver.Request. [ 3] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [ 4] robaho.net.httpserver.ServerImpl$Exchange.run [ 5] java.util.concurrent.ThreadPoolExecutor.runWorker [ 6] java.util.concurrent.ThreadPoolExecutor$Worker.run [ 7] java.lang.Thread.runWith [ 8] java.lang.Thread.run --- 1530000 ns (0.06%), 153 samples [ 0] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [ 1] robaho.net.httpserver.ServerImpl$Exchange.run [ 2] java.util.concurrent.ThreadPoolExecutor.runWorker [ 3] java.util.concurrent.ThreadPoolExecutor$Worker.run [ 4] java.lang.Thread.runWith [ 5] java.lang.Thread.run --- 1520000 ns (0.06%), 152 samples [ 0] sun.nio.ch.SocketDispatcher.write0 [ 1] sun.nio.ch.SocketDispatcher.write [ 2] sun.nio.ch.NioSocketImpl.tryWrite [ 3] sun.nio.ch.NioSocketImpl.implWrite [ 4] sun.nio.ch.NioSocketImpl.write [ 5] sun.nio.ch.NioSocketImpl$2.write [ 6] java.net.Socket$SocketOutputStream.write [ 7] robaho.net.httpserver.HttpConnection$ActivityTimerOutputStream.write [ 8] java.io.BufferedOutputStream.flushBuffer [ 9] java.io.BufferedOutputStream.implFlush [10] java.io.BufferedOutputStream.flush [11] java.io.FilterOutputStream.flush [12] robaho.net.httpserver.FixedLengthOutputStream.close [13] robaho.net.httpserver.PlaceholderOutputStream.close [14] benchmarks.Server.lambda$createPlaintextHandler$0 [15] benchmarks.Server$$Lambda.0x0000000138004ac0.handle [16] com.sun.net.httpserver.Filter$Chain.doFilter [17] robaho.net.httpserver.AuthFilter.doFilter [18] com.sun.net.httpserver.Filter$Chain.doFilter [19] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [20] com.sun.net.httpserver.Filter$Chain.doFilter [21] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [22] robaho.net.httpserver.ServerImpl$Exchange.run [23] java.util.concurrent.ThreadPoolExecutor.runWorker [24] java.util.concurrent.ThreadPoolExecutor$Worker.run [25] java.lang.Thread.runWith [26] java.lang.Thread.run --- 1520000 ns (0.06%), 152 samples [ 0] sun.nio.ch.SocketDispatcher.write0 [ 1] sun.nio.ch.SocketDispatcher.write [ 2] sun.nio.ch.NioSocketImpl.tryWrite [ 3] sun.nio.ch.NioSocketImpl.implWrite [ 4] sun.nio.ch.NioSocketImpl.write [ 5] sun.nio.ch.NioSocketImpl$2.write [ 6] java.net.Socket$SocketOutputStream.write [ 7] robaho.net.httpserver.HttpConnection$ActivityTimerOutputStream.write [ 8] java.io.BufferedOutputStream.flushBuffer [ 9] java.io.BufferedOutputStream.implFlush [10] java.io.BufferedOutputStream.flush [11] java.io.FilterOutputStream.flush [12] robaho.net.httpserver.FixedLengthOutputStream.close [13] robaho.net.httpserver.PlaceholderOutputStream.close [14] benchmarks.Server.lambda$createPlaintextHandler$0 [15] benchmarks.Server$$Lambda.0x0000000138004ac0.handle [16] com.sun.net.httpserver.Filter$Chain.doFilter [17] robaho.net.httpserver.AuthFilter.doFilter [18] com.sun.net.httpserver.Filter$Chain.doFilter [19] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [20] com.sun.net.httpserver.Filter$Chain.doFilter [21] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [22] robaho.net.httpserver.ServerImpl$Exchange.run [23] java.util.concurrent.ThreadPoolExecutor.runWorker [24] java.util.concurrent.ThreadPoolExecutor$Worker.run [25] java.lang.Thread.runWith [26] java.lang.Thread.run --- 1500000 ns (0.06%), 150 samples [ 0] java.time.Clock.currentInstant [ 1] java.time.Instant.now [ 2] robaho.net.httpserver.ExchangeImpl.sendResponseHeaders [ 3] robaho.net.httpserver.HttpExchangeImpl.sendResponseHeaders [ 4] benchmarks.Server.lambda$createPlaintextHandler$0 [ 5] benchmarks.Server$$Lambda.0x0000000138004ac0.handle [ 6] com.sun.net.httpserver.Filter$Chain.doFilter [ 7] robaho.net.httpserver.AuthFilter.doFilter [ 8] com.sun.net.httpserver.Filter$Chain.doFilter [ 9] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [10] com.sun.net.httpserver.Filter$Chain.doFilter [11] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [12] robaho.net.httpserver.ServerImpl$Exchange.run [13] java.util.concurrent.ThreadPoolExecutor.runWorker [14] java.util.concurrent.ThreadPoolExecutor$Worker.run [15] java.lang.Thread.runWith [16] java.lang.Thread.run --- 1460000 ns (0.06%), 146 samples [ 0] java.util.HashMap$HashIterator.nextNode [ 1] java.util.HashMap$EntryIterator.next [ 2] java.util.HashMap$EntryIterator.next [ 3] robaho.net.httpserver.ExchangeImpl.write [ 4] robaho.net.httpserver.ExchangeImpl.sendResponseHeaders [ 5] robaho.net.httpserver.HttpExchangeImpl.sendResponseHeaders [ 6] benchmarks.Server.lambda$createPlaintextHandler$0 [ 7] benchmarks.Server$$Lambda.0x0000000138004ac0.handle [ 8] com.sun.net.httpserver.Filter$Chain.doFilter [ 9] robaho.net.httpserver.AuthFilter.doFilter [10] com.sun.net.httpserver.Filter$Chain.doFilter [11] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [12] com.sun.net.httpserver.Filter$Chain.doFilter [13] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [14] robaho.net.httpserver.ServerImpl$Exchange.run [15] java.util.concurrent.ThreadPoolExecutor.runWorker [16] java.util.concurrent.ThreadPoolExecutor$Worker.run [17] java.lang.Thread.runWith [18] java.lang.Thread.run --- 1440000 ns (0.06%), 144 samples [ 0] robaho.net.httpserver.ExchangeImpl.bytes [ 1] robaho.net.httpserver.ExchangeImpl.write [ 2] robaho.net.httpserver.ExchangeImpl.sendResponseHeaders [ 3] robaho.net.httpserver.HttpExchangeImpl.sendResponseHeaders [ 4] benchmarks.Server.lambda$createPlaintextHandler$0 [ 5] benchmarks.Server$$Lambda.0x0000000138004ac0.handle [ 6] com.sun.net.httpserver.Filter$Chain.doFilter [ 7] robaho.net.httpserver.AuthFilter.doFilter [ 8] com.sun.net.httpserver.Filter$Chain.doFilter [ 9] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [10] com.sun.net.httpserver.Filter$Chain.doFilter [11] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [12] robaho.net.httpserver.ServerImpl$Exchange.run [13] java.util.concurrent.ThreadPoolExecutor.runWorker [14] java.util.concurrent.ThreadPoolExecutor$Worker.run [15] java.lang.Thread.runWith [16] java.lang.Thread.run --- 1440000 ns (0.06%), 144 samples [ 0] java.time.format.DateTimeFormatterBuilder$NumberPrinterParser.format [ 1] java.time.format.DateTimeFormatterBuilder$CompositePrinterParser.format [ 2] java.time.format.DateTimeFormatter.formatTo [ 3] java.time.format.DateTimeFormatter.format [ 4] robaho.net.httpserver.ExchangeImpl.sendResponseHeaders [ 5] robaho.net.httpserver.HttpExchangeImpl.sendResponseHeaders [ 6] benchmarks.Server.lambda$createPlaintextHandler$0 [ 7] benchmarks.Server$$Lambda.0x0000000138004ac0.handle [ 8] com.sun.net.httpserver.Filter$Chain.doFilter [ 9] robaho.net.httpserver.AuthFilter.doFilter [10] com.sun.net.httpserver.Filter$Chain.doFilter [11] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [12] com.sun.net.httpserver.Filter$Chain.doFilter [13] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [14] robaho.net.httpserver.ServerImpl$Exchange.run [15] java.util.concurrent.ThreadPoolExecutor.runWorker [16] java.util.concurrent.ThreadPoolExecutor$Worker.run [17] java.lang.Thread.runWith [18] java.lang.Thread.run --- 1430000 ns (0.06%), 143 samples [ 0] sun.nio.ch.SocketDispatcher.write0 [ 1] sun.nio.ch.SocketDispatcher.write [ 2] sun.nio.ch.NioSocketImpl.tryWrite [ 3] sun.nio.ch.NioSocketImpl.implWrite [ 4] sun.nio.ch.NioSocketImpl.write [ 5] sun.nio.ch.NioSocketImpl$2.write [ 6] java.net.Socket$SocketOutputStream.write [ 7] robaho.net.httpserver.HttpConnection$ActivityTimerOutputStream.write [ 8] java.io.BufferedOutputStream.flushBuffer [ 9] java.io.BufferedOutputStream.implFlush [10] java.io.BufferedOutputStream.flush [11] java.io.FilterOutputStream.flush [12] robaho.net.httpserver.FixedLengthOutputStream.close [13] robaho.net.httpserver.PlaceholderOutputStream.close [14] benchmarks.Server.lambda$createPlaintextHandler$0 [15] benchmarks.Server$$Lambda.0x0000000138004ac0.handle [16] com.sun.net.httpserver.Filter$Chain.doFilter [17] robaho.net.httpserver.AuthFilter.doFilter [18] com.sun.net.httpserver.Filter$Chain.doFilter [19] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [20] com.sun.net.httpserver.Filter$Chain.doFilter [21] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [22] robaho.net.httpserver.ServerImpl$Exchange.run [23] java.util.concurrent.ThreadPoolExecutor.runWorker [24] java.util.concurrent.ThreadPoolExecutor$Worker.run [25] java.lang.Thread.runWith [26] java.lang.Thread.run --- 1430000 ns (0.06%), 143 samples [ 0] robaho.net.httpserver.NoSyncBufferedInputStream.getBufIfOpen [ 1] robaho.net.httpserver.NoSyncBufferedInputStream.read [ 2] robaho.net.httpserver.Request.readLine [ 3] robaho.net.httpserver.Request. [ 4] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [ 5] robaho.net.httpserver.ServerImpl$Exchange.run [ 6] java.util.concurrent.ThreadPoolExecutor.runWorker [ 7] java.util.concurrent.ThreadPoolExecutor$Worker.run [ 8] java.lang.Thread.runWith [ 9] java.lang.Thread.run --- 1420000 ns (0.06%), 142 samples [ 0] com.sun.net.httpserver.Headers.normalize [ 1] com.sun.net.httpserver.Headers.containsKey [ 2] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [ 3] robaho.net.httpserver.ServerImpl$Exchange.run [ 4] java.util.concurrent.ThreadPoolExecutor.runWorker [ 5] java.util.concurrent.ThreadPoolExecutor$Worker.run [ 6] java.lang.Thread.runWith [ 7] java.lang.Thread.run --- 1420000 ns (0.06%), 142 samples [ 0] com.sun.net.httpserver.Headers.normalize [ 1] com.sun.net.httpserver.Headers.containsKey [ 2] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [ 3] robaho.net.httpserver.ServerImpl$Exchange.run [ 4] java.util.concurrent.ThreadPoolExecutor.runWorker [ 5] java.util.concurrent.ThreadPoolExecutor$Worker.run [ 6] java.lang.Thread.runWith [ 7] java.lang.Thread.run --- 1410000 ns (0.06%), 141 samples [ 0] accept [ 1] sun.nio.ch.Net.accept [ 2] sun.nio.ch.NioSocketImpl.accept [ 3] java.net.ServerSocket.implAccept [ 4] java.net.ServerSocket.platformImplAccept [ 5] java.net.ServerSocket.implAccept [ 6] java.net.ServerSocket.implAccept [ 7] java.net.ServerSocket.accept [ 8] robaho.net.httpserver.ServerImpl$Dispatcher.run [ 9] java.lang.Thread.runWith [10] java.lang.Thread.run --- 1410000 ns (0.06%), 141 samples [ 0] java.net.URI$Parser.scan [ 1] java.net.URI$Parser.parseHierarchical [ 2] java.net.URI$Parser.parse [ 3] java.net.URI. [ 4] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [ 5] robaho.net.httpserver.ServerImpl$Exchange.run [ 6] java.util.concurrent.ThreadPoolExecutor.runWorker [ 7] java.util.concurrent.ThreadPoolExecutor$Worker.run [ 8] java.lang.Thread.runWith [ 9] java.lang.Thread.run --- 1410000 ns (0.06%), 141 samples [ 0] java.util.HashMap$HashIterator.nextNode [ 1] java.util.HashMap$EntryIterator.next [ 2] java.util.HashMap$EntryIterator.next [ 3] robaho.net.httpserver.ExchangeImpl.write [ 4] robaho.net.httpserver.ExchangeImpl.sendResponseHeaders [ 5] robaho.net.httpserver.HttpExchangeImpl.sendResponseHeaders [ 6] benchmarks.Server.lambda$createPlaintextHandler$0 [ 7] benchmarks.Server$$Lambda.0x0000000138004ac0.handle [ 8] com.sun.net.httpserver.Filter$Chain.doFilter [ 9] robaho.net.httpserver.AuthFilter.doFilter [10] com.sun.net.httpserver.Filter$Chain.doFilter [11] robaho.net.httpserver.ServerImpl$Exchange$LinkHandler.handle [12] com.sun.net.httpserver.Filter$Chain.doFilter [13] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [14] robaho.net.httpserver.ServerImpl$Exchange.run [15] java.util.concurrent.ThreadPoolExecutor.runWorker [16] java.util.concurrent.ThreadPoolExecutor$Worker.run [17] java.lang.Thread.runWith [18] java.lang.Thread.run --- 1400000 ns (0.06%), 140 samples [ 0] shutdown [ 1] sun.nio.ch.Net.shutdown [ 2] sun.nio.ch.NioSocketImpl.close [ 3] java.net.Socket.close [ 4] java.net.Socket$SocketInputStream.close [ 5] java.io.FilterInputStream.close [ 6] java.io.FilterInputStream.close [ 7] robaho.net.httpserver.NoSyncBufferedInputStream.close [ 8] robaho.net.httpserver.HttpConnection.close [ 9] robaho.net.httpserver.ServerImpl.closeConnection [10] robaho.net.httpserver.ServerImpl$ConnectionCleanerTask.run [11] java.util.TimerThread.mainLoop [12] java.util.TimerThread.run --- 1400000 ns (0.06%), 140 samples [ 0] sun.nio.ch.NativeThread.current [ 1] sun.nio.ch.NioSocketImpl.beginRead [ 2] sun.nio.ch.NioSocketImpl.implRead [ 3] sun.nio.ch.NioSocketImpl.read [ 4] sun.nio.ch.NioSocketImpl$1.read [ 5] java.net.Socket$SocketInputStream.read [ 6] java.io.FilterInputStream.read [ 7] robaho.net.httpserver.HttpConnection$ActivityTimerInputStream.read [ 8] robaho.net.httpserver.NoSyncBufferedInputStream.fill [ 9] robaho.net.httpserver.NoSyncBufferedInputStream.read [10] robaho.net.httpserver.Request.readLine [11] robaho.net.httpserver.Request. [12] robaho.net.httpserver.ServerImpl$Exchange.runPerRequest [13] robaho.net.httpserver.ServerImpl$Exchange.run [14] java.util.concurrent.ThreadPoolExecutor.runWorker [15] java.util.concurrent.ThreadPoolExecutor$Worker.run [16] java.lang.Thread.runWith [17] java.lang.Thread.run ns percent samples top ---------- ------- ------- --- 829170000 34.10% 82917 read 809480000 33.29% 80948 write 55780000 2.29% 5578 sun.nio.ch.SocketDispatcher.read0 28550000 1.17% 2855 robaho.net.httpserver.ExchangeImpl.bytes 28170000 1.16% 2817 com.sun.net.httpserver.Headers.normalize 25400000 1.04% 2540 robaho.net.httpserver.ServerImpl$Exchange.runPerRequest 23850000 0.98% 2385 robaho.net.httpserver.Request.headers 23430000 0.96% 2343 com.sun.net.httpserver.Headers.add 21580000 0.89% 2158 robaho.net.httpserver.NoSyncBufferedInputStream.getBufIfOpen 20310000 0.84% 2031 sun.nio.ch.SocketDispatcher.write0 18940000 0.78% 1894 java.lang.StringBuffer. 16660000 0.69% 1666 java.util.HashMap.put 16230000 0.67% 1623 itable stub 16190000 0.67% 1619 sun.nio.ch.NativeThread.current 16120000 0.66% 1612 java.util.HashMap$HashIterator.nextNode 14820000 0.61% 1482 com.sun.net.httpserver.Headers.getFirst 14000000 0.58% 1400 java.net.URI. 12530000 0.52% 1253 com.sun.net.httpserver.Headers.get 12030000 0.49% 1203 java.util.HashMap.putVal 11270000 0.46% 1127 robaho.net.httpserver.Request.consume 10590000 0.44% 1059 com.sun.net.httpserver.Filter$Chain.doFilter 9820000 0.40% 982 robaho.net.httpserver.Request.readLine 9770000 0.40% 977 java.time.format.DateTimeFormatterBuilder$NumberPrinterParser.format 9750000 0.40% 975 jbyte_disjoint_arraycopy 9410000 0.39% 941 pthread_self 9360000 0.38% 936 robaho.net.httpserver.ExchangeImpl.write 9260000 0.38% 926 java.util.concurrent.ConcurrentHashMap.get 9000000 0.37% 900 java.util.HashMap.getNode 8570000 0.35% 857 Java_sun_nio_ch_SocketDispatcher_read0 8420000 0.35% 842 java.lang.AbstractStringBuilder.appendChars 8360000 0.34% 836 java.util.concurrent.locks.ReentrantLock$NonfairSync.initialTryLock 8000000 0.33% 800 java.net.URI$Parser.scan 7690000 0.32% 769 com.sun.net.httpserver.Headers.checkValue 7230000 0.30% 723 java.lang.ThreadLocal$ThreadLocalMap.getEntry 7140000 0.29% 714 java.time.Clock.currentInstant 7080000 0.29% 708 com.sun.net.httpserver.Headers.put 6890000 0.28% 689 robaho.net.httpserver.ExchangeImpl.sendResponseHeaders 6810000 0.28% 681 java.util.HashMap.resize 6660000 0.27% 666 Java_sun_nio_ch_SocketDispatcher_write0 6230000 0.26% 623 com.sun.net.httpserver.Headers.set 6030000 0.25% 603 java.lang.Long.getChars 5590000 0.23% 559 java.time.ZonedDateTime.getLong 5390000 0.22% 539 jdk.internal.misc.Unsafe.checkPrimitiveArray 5360000 0.22% 536 robaho.net.httpserver.ContextList.findContext 5170000 0.21% 517 jdk.internal.misc.Unsafe.checkPointer 4840000 0.20% 484 java.time.LocalDate.ofEpochDay 4800000 0.20% 480 java.time.format.DateTimeTextProvider.findStore 4600000 0.19% 460 java.util.Locale.equals 4440000 0.18% 444 jint_disjoint_arraycopy 4400000 0.18% 440 sun.nio.ch.NioSocketImpl.write 4270000 0.18% 427 __commpage_gettimeofday_internal 4230000 0.17% 423 fdval 4170000 0.17% 417 java.time.format.DateTimeFormatterBuilder$ZoneTextPrinterParser.format 4160000 0.17% 416 java.lang.Class.getComponentType 4080000 0.17% 408 robaho.net.httpserver.websockets.WebSocketHandler.isWebsocketRequested 3940000 0.16% 394 robaho.net.httpserver.ExchangeImpl. 3940000 0.16% 394 java.lang.StringLatin1.toChars 3920000 0.16% 392 mach_absolute_time 3880000 0.16% 388 jlong_disjoint_arraycopy 3780000 0.16% 378 java.util.HashMap$HashIterator. 3750000 0.15% 375 jdk.internal.util.ArraysSupport.mismatch 3720000 0.15% 372 __commpage_gettimeofday 3640000 0.15% 364 clock_gettime 3460000 0.14% 346 java.util.Objects.checkFromIndexSize 3460000 0.14% 346 java.lang.StringLatin1.toLowerCase 3410000 0.14% 341 robaho.net.httpserver.NoSyncBufferedInputStream.read 3400000 0.14% 340 semaphore_wait_trap 3130000 0.13% 313 close 3120000 0.13% 312 java.lang.Integer.getChars 3020000 0.12% 302 java.lang.StringLatin1.newString 2930000 0.12% 293 java.net.URI.decode 2720000 0.11% 272 java.time.format.DateTimeFormatterBuilder$CompositePrinterParser.format 2620000 0.11% 262 java.lang.Math.floorMod 2540000 0.10% 254 sun.nio.ch.Util.isBufferTooLarge 2390000 0.10% 239 sun.nio.ch.NativeThread.current0 2370000 0.10% 237 JVM_GetNanoTimeAdjustment 2260000 0.09% 226 convertReturnVal 2260000 0.09% 226 vectorizedMismatch 2240000 0.09% 224 jshort_disjoint_arraycopy 2210000 0.09% 221 java.lang.AbstractStringBuilder.ensureCapacityInternal 2210000 0.09% 221 java.time.DayOfWeek.of 2160000 0.09% 216 sun.nio.ch.Util$BufferCache.get 2130000 0.09% 213 java.net.URI.match 2090000 0.09% 209 robaho.net.httpserver.AuthFilter.doFilter 2080000 0.09% 208 java.util.Objects.equals 2020000 0.08% 202 java.lang.AbstractStringBuilder. 2000000 0.08% 200 java.time.format.DateTimeFormatterBuilder$CharLiteralPrinterParser.format 1910000 0.08% 191 robaho.net.httpserver.Utils.isValidName 1840000 0.08% 184 java.time.format.DateTimeFormatterBuilder$TextPrinterParser.format 1750000 0.07% 175 java.lang.Integer.stringSize 1720000 0.07% 172 java.time.format.DateTimePrintContext.adjust 1710000 0.07% 171 java.time.format.DateTimePrintContext. 1670000 0.07% 167 com.sun.net.httpserver.Headers.containsKey 1660000 0.07% 166 jbyte_arraycopy 1650000 0.07% 165 java.lang.StringLatin1.regionMatchesCI 1650000 0.07% 165 gettimeofday 1580000 0.06% 158 jdk.internal.misc.VM.getNanoTimeAdjustment 1570000 0.06% 157 java.net.URI$Parser.parseHierarchical 1560000 0.06% 156 java.nio.DirectByteBuffer.base 1560000 0.06% 156 java.time.format.DateTimeTextProvider.createEntry 1540000 0.06% 154 JNI_OnLoad 1530000 0.06% 153 _platform_bzero$VARIANT$Haswell 1520000 0.06% 152 jdk.internal.misc.Unsafe.checkOffset 1520000 0.06% 152 jdk.internal.misc.CarrierThreadLocal.get 1500000 0.06% 150 java.time.LocalDate.toEpochDay 1480000 0.06% 148 robaho.net.httpserver.ServerImpl$Exchange.run 1480000 0.06% 148 robaho.net.httpserver.Code.msg 1420000 0.06% 142 java.lang.StringLatin1.indexOf 1410000 0.06% 141 accept 1400000 0.06% 140 shutdown 1320000 0.05% 132 java.lang.System$2.getCarrierThreadLocal 1250000 0.05% 125 java.time.format.DateTimeFormatterBuilder$ZoneTextPrinterParser.getDisplayName 1220000 0.05% 122 Java_sun_nio_ch_NativeThread_current0 1160000 0.05% 116 java.net.URI$Parser.parse 1150000 0.05% 115 java.time.chrono.ChronoZonedDateTime.toEpochSecond 1090000 0.04% 109 java.time.LocalDate.get0 1060000 0.04% 106 tlv_get_addr 1060000 0.04% 106 jdk.internal.misc.Unsafe.copyMemory 1050000 0.04% 105 java.util.concurrent.locks.AbstractQueuedSynchronizer.signalNext 1050000 0.04% 105 advance_directory.cold.1 1040000 0.04% 104 __psynch_mutexwait 1020000 0.04% 102 MemAllocator::allocate 950000 0.04% 95 jdk.internal.util.Preconditions.checkFromIndexSize 890000 0.04% 89 java.lang.StringBuilder.append 880000 0.04% 88 sun.nio.ch.SocketDispatcher.read 880000 0.04% 88 OptoRuntime::new_array_C 860000 0.04% 86 java.nio.MappedByteBuffer.position 840000 0.03% 84 robaho.net.httpserver.HttpExchangeImpl.sendResponseHeaders 820000 0.03% 82 os::javaTimeMillis 790000 0.03% 79 __psynch_cvwait 780000 0.03% 78 HandleMark::initialize 730000 0.03% 73 ObjArrayAllocator::initialize 690000 0.03% 69 java.time.LocalDate.getDayOfWeek 610000 0.03% 61 java.nio.MappedByteBuffer.limit 590000 0.02% 59 SharedRuntime::on_slowpath_allocation_exit 580000 0.02% 58 _platform_memset$VARIANT$Haswell 530000 0.02% 53 java.util.concurrent.CopyOnWriteArrayList$COWIterator.next 530000 0.02% 53 JfrObjectAllocationSample::send_event 530000 0.02% 53 java.time.ZoneId.equals 520000 0.02% 52 HandleMark::~HandleMark 520000 0.02% 52 com.sun.net.httpserver.Headers. 510000 0.02% 51 unsafe_arraycopy 500000 0.02% 50 G1Allocator::unsafe_max_tlab_alloc 500000 0.02% 50 _platform_memmove$VARIANT$Haswell 490000 0.02% 49 Klass::check_array_allocation_length 470000 0.02% 47 semaphore_signal_trap 460000 0.02% 46 java.nio.ByteBuffer.putArray 460000 0.02% 46 OptoRuntime::new_instance_C 460000 0.02% 46 ZThread::~ZThread 440000 0.02% 44 java.lang.AbstractStringBuilder.newCapacity 420000 0.02% 42 TypeArrayKlass::allocate_common 400000 0.02% 40 CardTableBarrierSet::on_slowpath_allocation_exit 380000 0.02% 38 G1CollectedHeap::fill_with_dummy_object 370000 0.02% 37 os::javaTimeSystemUTC 360000 0.01% 36 jdk.internal.misc.Unsafe.checkNativeAddress 340000 0.01% 34 MemAllocator::Allocation::notify_allocation 340000 0.01% 34 jdk.internal.misc.ScopedMemoryAccess.copyMemoryInternal 330000 0.01% 33 G1NUMA::index_of_current_thread 330000 0.01% 33 ObjectSampler::is_created 320000 0.01% 32 getsockopt 310000 0.01% 31 com.sun.net.httpserver.Headers$$Lambda.0x0000000138013100.accept 310000 0.01% 31 getsockname 290000 0.01% 29 G1CollectedHeap::attempt_allocation 290000 0.01% 29 __psynch_mutexdrop 280000 0.01% 28 CodeCache::find_blob 270000 0.01% 27 AllocTracer::send_allocation_in_new_tlab 270000 0.01% 27 JfrAllocationTracer::JfrAllocationTracer 270000 0.01% 27 CollectedHeap::array_allocate 260000 0.01% 26 sun.nio.ch.SocketDispatcher.write 230000 0.01% 23 LeakProfiler::is_running 230000 0.01% 23 frame::sender_for_compiled_frame 220000 0.01% 22 MemAllocator::mem_allocate_inside_tlab_slow 220000 0.01% 22 java.util.concurrent.ConcurrentHashMap.computeIfAbsent 220000 0.01% 22 G1ParScanThreadState::do_copy_to_survivor_space 220000 0.01% 22 java.nio.MappedByteBuffer.rewind 210000 0.01% 21 oopFactory::new_typeArray 190000 0.01% 19 ThreadLocalAllocBuffer::fill 190000 0.01% 19 HeapRegion::fill_with_dummy_object 190000 0.01% 19 __fcntl 190000 0.01% 19 _os_semaphore_wait.cold.1 180000 0.01% 18 G1CardTable::g1_mark_as_young 170000 0.01% 17 jint_arraycopy 170000 0.01% 17 ObjAllocator::initialize 170000 0.01% 17 G1CollectedHeap::mem_allocate 170000 0.01% 17 OptoRuntime::new_array_nozero_C 170000 0.01% 17 G1CollectedHeap::allocate_new_tlab 160000 0.01% 16 ThreadLocalAllocBuffer::retire_before_allocation 150000 0.01% 15 G1ParScanThreadState::trim_queue_to_threshold 150000 0.01% 15 robaho.net.httpserver.ServerImpl$Dispatcher.run 150000 0.01% 15 jdk.internal.util.ArraysSupport.newLength 140000 0.01% 14 CollectedHeap::fill_with_object 130000 0.01% 13 CodeHeap::find_blob 130000 0.01% 13 sun.nio.ch.Util$BufferCache.next 120000 0.00% 12 os::javaTimeNanos 120000 0.00% 12 G1CollectedHeap::attempt_allocation_slow 120000 0.00% 12 void G1ScanEvacuatedObjClosure::do_oop_work 120000 0.00% 12 robaho.net.httpserver.HttpConnection. 110000 0.00% 11 ThreadLocalAllocBuffer::end_reserve 110000 0.00% 11 AccessInternal::PostRuntimeDispatch, (AccessInternal::BarrierType)2, 598116ull>::oop_access_barrier 110000 0.00% 11 ClassLoaderData::holder -------------- next part -------------- An HTML attachment was scrubbed... URL: From dannyt at netflix.com Tue Jun 25 01:13:37 2024 From: dannyt at netflix.com (Danny Thomas) Date: Tue, 25 Jun 2024 11:13:37 +1000 Subject: Real-world Pinning/ReentrantLock deadlock Message-ID: Hi folks, We ran into a real-world deadlock with virtual threads and Micrometer, Brave/Zipkin. In short, there are two paths to CountBoundedQueue.offer[1] for finishing a span. RealSpan.finish[2] has a synchronized block, RealScopedSpan.finish[3] doesn't. If a virtual thread using RealScopedSpan is next line for the lock, but all carriers are currently occupied by pinned VTs in RealSpan.finish, the application will deadlock: https://gist.github.com/DanielThomas/dddd850f7e491cac3a2dd734978f4267 Looking forward to the locking improvements! Cheers, Danny [1] https://github.com/openzipkin/zipkin-reporter-java/blob/519133204bc5a56a5286c6f40facc10c76270b5f/core/src/main/java/zipkin2/reporter/internal/CountBoundedQueue.java#L71-L93 [2] https://github.com/openzipkin/brave/blob/69003dfc811418f0dbc42e9e17ff880ebe1f4b02/brave/src/main/java/brave/RealSpan.java#L132-L136 [3] https://github.com/openzipkin/brave/blob/69003dfc811418f0dbc42e9e17ff880ebe1f4b02/brave/src/main/java/brave/RealScopedSpan.java#L62-L65 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hepin.p at alibaba-inc.com Tue Jun 25 04:05:54 2024 From: hepin.p at alibaba-inc.com (=?UTF-8?B?5L2V5ZOBKOiZjum4oyk=?=) Date: Tue, 25 Jun 2024 12:05:54 +0800 Subject: =?UTF-8?B?5Zue5aSN77ya5Zue5aSN77yaVmlydHVhbCB0aHJlYWQgaGFuZyBhbmQgYWxsIHRocmVhZHMg?= =?UTF-8?B?c3RvcCBydW5uaW5nIG9uIEpESzIx?= In-Reply-To: References: Message-ID: <69889f55-3e40-4de4-b363-dbc0850febde.hepin.p@alibaba-inc.com> The code below will dead lock -Djdk.virtualThreadScheduler.parallelism=1 -Djdk.virtualThreadScheduler.maxPoolSize=1 -Djdk.virtualThreadScheduler.minRunnable=1 public class VTTest { static final CountDownLatch countDownLatch = new CountDownLatch(1); static final ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor(); public static void main(String[] args) throws IOException { executor.execute(() -> { try { Thread.sleep(1000); } catch (InterruptedException e) { throw new RuntimeException(e); } countDownLatch.countDown(); }); executor.execute(InnerSleepClass::hello); System.in.read(); } private static class InnerSleepClass { static { try { countDownLatch.await(); System.out.println("exit count down."); } catch (InterruptedException e) { throw new RuntimeException(e); } } static void hello() { System.out.println("hello"); } } } ------------------------------------------------------------------ ??????(??) ?????2024?6?23?(???) 16:30 ????Alan Bateman; masoud parvari; "??(??)" ????"loom-dev" ??????????Virtual thread hang and all threads stop running on JDK21 Thanks for the clarification ------------------------------------------------------------------ ????Alan Bateman ?????2024?6?22?(???) 17:22 ????masoud parvari; "??(??)" ????"loom-dev" ????Re: ???Virtual thread hang and all threads stop running on JDK21 On 22/06/2024 09:54, masoud parvari wrote: In class loading/initialization cases, the underlying issue is that pinning happens because there are native frames in the stack, so replacing the synchronized with a j.u.c lock will still lead to the same issue. That's right, and there are a couple of scenarios there, to be looked into after the object monitor issues are out of the way. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Jun 25 06:21:13 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 25 Jun 2024 07:21:13 +0100 Subject: Real-world Pinning/ReentrantLock deadlock In-Reply-To: References: Message-ID: On 25/06/2024 02:13, Danny Thomas wrote: > Hi folks, > > We ran into a real-world deadlock with virtual threads and Micrometer, > Brave/Zipkin. In short, there are two paths to > CountBoundedQueue.offer[1] for finishing a span. RealSpan.finish[2] > has a synchronized block, RealScopedSpan.finish[3] doesn't. If a > virtual thread using RealScopedSpan is next line for the lock, but all > carriers are currently occupied by?pinned VTs in RealSpan.finish, the > application will deadlock: > > https://gist.github.com/DanielThomas/dddd850f7e491cac3a2dd734978f4267 > > Looking forward to the locking improvements! > Yes, if a j.u.concurrent lock is sometimes acquired by threads holding a monitor and at other times by threads that aren't holding a monitor then deadlock is possible when all carriers are pinned and the selected successor is unmounted. Have you, or your team, tried the early access build [1] with the changes for object monitors yet? -Alan [1] https://jdk.java.net/loom/ From Alan.Bateman at oracle.com Tue Jun 25 06:26:01 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 25 Jun 2024 07:26:01 +0100 Subject: =?UTF-8?B?UmU6IOWbnuWkje+8muWbnuWkje+8mlZpcnR1YWwgdGhyZWFkIGhhbmcg?= =?UTF-8?Q?and_all_threads_stop_running_on_JDK21?= In-Reply-To: <69889f55-3e40-4de4-b363-dbc0850febde.hepin.p@alibaba-inc.com> References: <69889f55-3e40-4de4-b363-dbc0850febde.hepin.p@alibaba-inc.com> Message-ID: On 25/06/2024 05:05, ??(??) wrote: > The code below will dead lock > > > -Djdk.virtualThreadScheduler.parallelism=1 > -Djdk.virtualThreadScheduler.maxPoolSize=1 > -Djdk.virtualThreadScheduler.minRunnable=1 > Right now, class initializer execute with some VM frames on the stack so the thread is pinned. The priority right is object monitors but class loading and initialization is something that needs to be re-examined next. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Jun 25 08:12:59 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 25 Jun 2024 09:12:59 +0100 Subject: Interesting profile session In-Reply-To: <777E865C-A9CA-46C8-B057-EB9D9448E4DE@me.com> References: <777E865C-A9CA-46C8-B057-EB9D9448E4DE@me.com> Message-ID: <62c21cea-d76e-44c1-a887-e7f8836d285d@oracle.com> On 24/06/2024 23:03, Robert Engels wrote: > > The VT latency is a couple of orders of magnitude higher than the > platform latency. > > I suspect that what is happening is that the virtual threads are > parking waiting for work too soon - or that the read & writes are > always causing a context switch - regardless of if the call is very > short (room in the kernel socket buffers). > > Can you suggest any remedies? It feels like the scheduler needs some > heuristics on average call time to determine and a spin loop to avoid > this sort of thing. > There may be a combination of things here. From the stack traces, this looks like JDK 21 + macOS. There has been significant changes to both the scheduler (ForkJoinPool) and the I/O poller mechanism since then.? Would you have time to out the latest EA build [1] to see if you get similar latency? It would be interesting to see data with -Djdk.pollerMode=1 and 2 (the default on macOS is "a"). Also would be useful to see `jcmd Thread.vthread_summary` output while the benchmark is running as that will reveal more about the scheduler and how many virtual threads are blocked on socket I/O. [1] https://jdk.java.net/loom/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From viktor.klang at oracle.com Tue Jun 25 09:31:05 2024 From: viktor.klang at oracle.com (Viktor Klang) Date: Tue, 25 Jun 2024 09:31:05 +0000 Subject: Experience using virtual threads in EA 23-loom+4-102 In-Reply-To: <11DD9614-B571-45E9-9C33-EBB9279E7663@icloud.com> References: <6A9FDAD8-3507-4952-A47C-B8CC57C8AD2E@ix.netcom.com> <11DD9614-B571-45E9-9C33-EBB9279E7663@icloud.com> Message-ID: It's important to remember that all of this is capped by Little's Law, Queuing Theory, Amdahl's Law (or rather, Universal Scalability Law). There's always going to be a tension between prioritizing finishing already started work and starting to process new work, and the less information there is about what the work entails, the less sophistication can be applied to achieve optimality. As with all scalability-testing, it is important to be able to control tail latencies (i.e. avoiding optimizing for p50 at the expense of p90), which is only possible by either doing less work (load shedding, graceful degradation, or equivalent) or diverting work (dynamic scaling, nearest-gateway-routing, or equivalent). At the end of the day, optimization tends to improve efficiency, alas there's always going to be a bottleneck which defines the ceiling for what is currently possible. Identifying said bottleneck (remember that it can move, depending on where most pressure is applied), tends to yield the best information on where to spend the most effort. Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle ________________________________ From: loom-dev on behalf of Robert Engels Sent: Monday, 24 June 2024 22:12 To: Matthew Swift Cc: loom-dev at openjdk.org Subject: Re: Experience using virtual threads in EA 23-loom+4-102 I still think it might be helpful to use virtual threads for all connections (simplicity!) - but when to perform the cpu intensive work like hashing, put a callable/future on a ?cpu only? executor with a capped number of platform threads and join(). It should be a trivial refactor of the code. The problem with using VT for everything is that a VT is not time-sliced, so you could quickly consume all of the carrier threads and then you make no progress on the IO (fan out) requests - which is especially bad if they are simply calling out to other servers (less bad if doing lots of local disk io). On Jun 24, 2024, at 12:05 PM, Matthew Swift > wrote: Thanks Robert. The main issue we face with our application is that the client load can vary substantially over time. For example, we might experience a lot of CPU intensive authentication traffic (e.g. PBKDF2 hashing) in the morning, but then a lot of IO bound traffic at other times. It's hard to find the ideal number of worker threads: many threads work well for IO bound traffic, as you say, but sacrifices performance when the load is more CPU bound. On my 10 core (20 hyper threads) laptop, I observe nearly a 15-20% drop in throughput when subjecting the server to 1200 concurrent CPU bound requests, but a much smaller drop when using virtual threads: * 10 platform threads: ~260K requests/s (note: this is too few threads for more IO bound traffic) * 40 platform threads: ~220K requests/s * 1200 platform threads: ~220K requests/s (note: this would be the equivalent of a one platform thread per request) * virtual threads: 252K requests/s (note: FJ pool defaults to 20 on my laptop - I didn't try disabling hyperthreading). I find the "one size fits all" provided by virtual threads to be much easier for developers and our users alike. I don't have to worry about complex architectures involving split thread pools (one for CPU, one for IO), etc. We also have to deal with slow misbehaving clients, which has meant use of async IO and hard to debug call-back hell :-) All of this goes away with virtual threads as it will allow us to use simpler blocking network IO and a simple one thread per request design that is much more tolerant to heterogeneous traffic patterns. It also opens up the possibility of future enhancements that would definitely shine with virtual threads as you suggest. For example, modern hashing algorithms, such as Argon2, can take hundreds of milliseconds of computation, which is simply too costly to scale horizontally in the data layer. We want to offload this to an external elastic compute service, but we could very quickly have thousands of blocked platform threads with response times this high. Cheers, Matt On Fri, 21 Jun 2024 at 19:29, robert engels > wrote: Hi, Just an fyi, until you get into the order of 1k, 10k, etc. concurrent clients - I would expect platform threads to outperform virtual threads by quite a bit (best case be the same). Modern OS?s routinely handle thousands of active threads. (My OSX desktop with 4 true cores has nearly 5k threads running). Also, if you can saturate your CPUs or local IO bus, adding more threads isn?t going to help. VirtualThreads shine when the request handler is fanning out to multiple remote services. Regards, Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at me.com Tue Jun 25 11:02:50 2024 From: robaho at me.com (robert engels) Date: Tue, 25 Jun 2024 06:02:50 -0500 Subject: Interesting profile session In-Reply-To: <62c21cea-d76e-44c1-a887-e7f8836d285d@oracle.com> References: <62c21cea-d76e-44c1-a887-e7f8836d285d@oracle.com> Message-ID: <17AD6AC4-6529-4337-8C2A-ABE71030BC63@me.com> Will do and I?ll report back. > On Jun 25, 2024, at 3:14?AM, Alan Bateman wrote: > > ? On 24/06/2024 23:03, Robert Engels wrote: >> >> The VT latency is a couple of orders of magnitude higher than the platform latency. >> >> I suspect that what is happening is that the virtual threads are parking waiting for work too soon - or that the read & writes are always causing a context switch - regardless of if the call is very short (room in the kernel socket buffers). >> >> Can you suggest any remedies? It feels like the scheduler needs some heuristics on average call time to determine and a spin loop to avoid this sort of thing. >> > There may be a combination of things here. From the stack traces, this looks like JDK 21 + macOS. There has been significant changes to both the scheduler (ForkJoinPool) and the I/O poller mechanism since then. Would you have time to out the latest EA build [1] to see if you get similar latency? It would be interesting to see data with -Djdk.pollerMode=1 and 2 (the default on macOS is "a"). Also would be useful to see `jcmd Thread.vthread_summary` output while the benchmark is running as that will reveal more about the scheduler and how many virtual threads are blocked on socket I/O. > > [1] https://jdk.java.net/loom/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Jun 25 11:15:04 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 25 Jun 2024 12:15:04 +0100 Subject: Experience using virtual threads in EA 23-loom+4-102 In-Reply-To: References: Message-ID: <826fbc3f-b9a2-4828-a3e2-5bf9e4229791@oracle.com> On 24/06/2024 18:24, Matthew Swift wrote: > : > > > > I reran the test and executed the above command once per second for 10 > seconds: > > $ for i in 1 2 3 4 5 6 7 8 9 10; do jcmd DirectoryServer > Thread.vthread_scheduler; sleep 1; done > 110886: > java.util.concurrent.ForkJoinPool at 3a7204cd[Running, parallelism = 20, > size = 20, active = 13, running = 0, steals = 17676052, tasks = 0, > submissions = 0] > 110886: > java.util.concurrent.ForkJoinPool at 3a7204cd[Running, parallelism = 20, > size = 20, active = 16, running = 0, steals = 17784106, tasks = 1, > submissions = 0] > 110886: > java.util.concurrent.ForkJoinPool at 3a7204cd[Running, parallelism = 20, > size = 20, active = 20, running = 1, steals = 17887000, tasks = 1, > submissions = 0] > 110886: > java.util.concurrent.ForkJoinPool at 3a7204cd[Running, parallelism = 20, > size = 20, active = 15, running = 1, steals = 17984238, tasks = 1, > submissions = 0] > 110886: > java.util.concurrent.ForkJoinPool at 3a7204cd[Running, parallelism = 20, > size = 20, active = 9, running = 0, steals = 18082247, tasks = 0, > submissions = 0] > 110886: > java.util.concurrent.ForkJoinPool at 3a7204cd[Running, parallelism = 20, > size = 20, active = 9, running = 0, steals = 18201916, tasks = 0, > submissions = 0] > 110886: > java.util.concurrent.ForkJoinPool at 3a7204cd[Running, parallelism = 20, > size = 20, active = 20, running = 0, steals = 18302449, tasks = 2, > submissions = 0] > 110886: > java.util.concurrent.ForkJoinPool at 3a7204cd[Running, parallelism = 20, > size = 20, active = 1, running = 0, steals = 18416910, tasks = 0, > submissions = 0] > 110886: > java.util.concurrent.ForkJoinPool at 3a7204cd[Running, parallelism = 20, > size = 20, active = 13, running = 0, steals = 18516576, tasks = 0, > submissions = 0] > 110886: > java.util.concurrent.ForkJoinPool at 3a7204cd[Running, parallelism = 20, > size = 20, active = 14, running = 0, steals = 18602916, tasks = 0, > submissions = 0] > > I won't pretend to understand what this means :-) > Thanks, I mostly wanted to see the values for the "tasks" and "submissions" in the output. These are the number of virtual threads that are waiting to execute in both local queues and unowned submission queues. There are 0, except for the sample where all 20 workers are active and 2 virtual threads have been unparked and are waiting to continue. So that doesn't explain the outliers you see. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From dannyt at netflix.com Wed Jun 26 05:36:41 2024 From: dannyt at netflix.com (Danny Thomas) Date: Wed, 26 Jun 2024 15:36:41 +1000 Subject: Real-world Pinning/ReentrantLock deadlock In-Reply-To: References: Message-ID: Working on looking at the scheduler, poller and locking changes as we speak. On Tue, 25 Jun 2024 at 4:21?PM, Alan Bateman wrote: > > > On 25/06/2024 02:13, Danny Thomas wrote: > > Hi folks, > > > > We ran into a real-world deadlock with virtual threads and Micrometer, > > Brave/Zipkin. In short, there are two paths to > > CountBoundedQueue.offer[1] for finishing a span. RealSpan.finish[2] > > has a synchronized block, RealScopedSpan.finish[3] doesn't. If a > > virtual thread using RealScopedSpan is next line for the lock, but all > > carriers are currently occupied by pinned VTs in RealSpan.finish, the > > application will deadlock: > > > > https://gist.github.com/DanielThomas/dddd850f7e491cac3a2dd734978f4267 > > > > Looking forward to the locking improvements! > > > > Yes, if a j.u.concurrent lock is sometimes acquired by threads holding a > monitor and at other times by threads that aren't holding a monitor then > deadlock is possible when all carriers are pinned and the selected > successor is unmounted. Have you, or your team, tried the early access > build [1] with the changes for object monitors yet? > > -Alan > > [1] https://jdk.java.net/loom/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hepin.p at alibaba-inc.com Wed Jun 26 06:22:41 2024 From: hepin.p at alibaba-inc.com (=?UTF-8?B?5L2V5ZOBKOiZjum4oyk=?=) Date: Wed, 26 Jun 2024 14:22:41 +0800 Subject: =?UTF-8?B?5Zue5aSN77yaUmVhbC13b3JsZCBQaW5uaW5nL1JlZW50cmFudExvY2sgZGVhZGxvY2s=?= In-Reply-To: References: Message-ID: is it possible to make the `unparker` plugable ? ------------------------------------------------------------------ ????Danny Thomas ?????2024?6?26?(???) 13:37 ????Alan Bateman ????"loom-dev" ????Re: Real-world Pinning/ReentrantLock deadlock Working on looking at the scheduler, poller and locking changes as we speak. On Tue, 25 Jun 2024 at 4:21?PM, Alan Bateman > wrote: On 25/06/2024 02:13, Danny Thomas wrote: > Hi folks, > > We ran into a real-world deadlock with virtual threads and Micrometer, > Brave/Zipkin. In short, there are two paths to > CountBoundedQueue.offer[1] for finishing a span. RealSpan.finish[2] > has a synchronized block, RealScopedSpan.finish[3] doesn't. If a > virtual thread using RealScopedSpan is next line for the lock, but all > carriers are currently occupied by pinned VTs in RealSpan.finish, the > application will deadlock: > > https://gist.github.com/DanielThomas/dddd850f7e491cac3a2dd734978f4267 > > Looking forward to the locking improvements! > Yes, if a j.u.concurrent lock is sometimes acquired by threads holding a monitor and at other times by threads that aren't holding a monitor then deadlock is possible when all carriers are pinned and the selected successor is unmounted. Have you, or your team, tried the early access build [1] with the changes for object monitors yet? -Alan [1] https://jdk.java.net/loom/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Wed Jun 26 06:31:11 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 26 Jun 2024 07:31:11 +0100 Subject: =?UTF-8?B?UmU6IOWbnuWkje+8mlJlYWwtd29ybGQgUGlubmluZy9SZWVudHJhbnRM?= =?UTF-8?Q?ock_deadlock?= In-Reply-To: References: Message-ID: On 26/06/2024 07:22, ??(??) wrote: > is it possible to make the `unparker` plugable ? Are you asking about being able to use a scheduler other than FJP, or are you specifically talking about the timers which currently use a number of "unparker" threads? -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Wed Jun 26 06:44:58 2024 From: duke at openjdk.org (duke) Date: Wed, 26 Jun 2024 06:44:58 GMT Subject: git: openjdk/loom: fibers: 37 new changesets Message-ID: <420c5052-3958-4d2f-8f5b-afb4f823caf3@openjdk.org> Changeset: 72ca7baf Author: Hannes Greule Committer: Chen Liang Date: 2024-06-22 12:16:50 +0000 URL: https://git.openjdk.org/loom/commit/72ca7bafcd49a98c1fe09da72e4e47683f052e9d 8334708: FFM: two javadoc problems Reviewed-by: mcimadamore ! src/java.base/share/classes/java/lang/foreign/Linker.java ! src/java.base/share/classes/java/lang/foreign/MemoryLayout.java Changeset: 652784c8 Author: Johan Sj?len Date: 2024-06-23 08:19:28 +0000 URL: https://git.openjdk.org/loom/commit/652784c803863f40ee3d81695a19e705365cb800 8334392: Switch RNG in NMT's treap Reviewed-by: stuefe, azafari, gziemski ! src/hotspot/share/nmt/nmtTreap.hpp ! test/hotspot/gtest/nmt/test_nmt_treap.cpp Changeset: eb110bdc Author: Johan Sj?len Date: 2024-06-23 12:33:38 +0000 URL: https://git.openjdk.org/loom/commit/eb110bdc6e8bcb87b9b8b24ac66eb9b4c57106fd 8334180: NMT gtests introduced with 8312132 should be labeled as NMT Reviewed-by: gziemski, stuefe ! src/hotspot/share/nmt/memoryFileTracker.hpp ! src/hotspot/share/nmt/nmtTreap.hpp ! src/hotspot/share/nmt/vmatree.hpp ! test/hotspot/gtest/nmt/test_nmt_memoryfiletracker.cpp ! test/hotspot/gtest/nmt/test_nmt_nativecallstackstorage.cpp ! test/hotspot/gtest/nmt/test_nmt_treap.cpp ! test/hotspot/gtest/nmt/test_vmatree.cpp Changeset: 7baddc20 Author: SendaoYan Committer: Alan Bateman Date: 2024-06-23 18:00:28 +0000 URL: https://git.openjdk.org/loom/commit/7baddc202a9ab2b85401aa05f827678b514ebf55 8334339: Test java/nio/file/attribute/BasicFileAttributeView/CreationTime.java fails on alinux3 Reviewed-by: alanb ! test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java Changeset: a4582a89 Author: Zhao Song Committer: Erik Joelsson Date: 2024-06-24 05:15:32 +0000 URL: https://git.openjdk.org/loom/commit/a4582a8957d604b50249e1f59679393966456a14 8334166: Enable binary check Reviewed-by: kcr, ihse, prr, erikj ! .jcheck/conf Changeset: 863b2a99 Author: Axel Boldt-Christmas Date: 2024-06-24 06:06:45 +0000 URL: https://git.openjdk.org/loom/commit/863b2a991df9204560c4680fc10dd0f68b260217 8329994: Zap alignment padding bits for ArrayOops in non-release builds Reviewed-by: ayang, sjohanss ! src/hotspot/share/gc/shared/memAllocator.cpp ! src/hotspot/share/gc/shared/memAllocator.hpp ! src/hotspot/share/gc/z/zObjArrayAllocator.cpp Changeset: 13dce296 Author: Richard Reingruber Date: 2024-06-24 06:33:39 +0000 URL: https://git.openjdk.org/loom/commit/13dce296fc3924b269757ce1279c57afe18faeeb 8334560: [PPC64]: postalloc_expand_java_dynamic_call_sched does not copy all fields Reviewed-by: mbaesken, mdoerr ! src/hotspot/cpu/ppc/ppc.ad ! test/jdk/com/sun/jdi/EATests.java Changeset: edf7f055 Author: Emanuel Peter Date: 2024-06-24 07:14:57 +0000 URL: https://git.openjdk.org/loom/commit/edf7f055ee010a2c19bce26c15726d5b58e2e832 8334083: C2 SuperWord: TestCompatibleUseDefTypeSize.java fails with -XX:+AlignVector after JDK-8325155 Reviewed-by: chagedorn, kvn ! test/hotspot/jtreg/compiler/loopopts/superword/TestCompatibleUseDefTypeSize.java Changeset: 05a63d80 Author: Johan Sj?len Date: 2024-06-24 07:51:01 +0000 URL: https://git.openjdk.org/loom/commit/05a63d80b9c1e312512c707ccf6b255c16a9edf5 8334489: Add function os::used_memory Reviewed-by: eosterlund, dholmes, stuefe ! src/hotspot/share/runtime/os.cpp ! src/hotspot/share/runtime/os.hpp Changeset: 05ff3185 Author: Aleksey Shipilev Date: 2024-06-24 08:46:10 +0000 URL: https://git.openjdk.org/loom/commit/05ff3185edd25b381a97f6879f496e97b62dddc2 8334594: Generational ZGC: Deadlock after OopMap rewrites in 8331572 Reviewed-by: stefank, eosterlund, coleenp, zgu ! src/hotspot/share/gc/shared/gcVMOperations.cpp ! src/hotspot/share/gc/shenandoah/shenandoahVMOperations.cpp ! src/hotspot/share/gc/x/xDriver.cpp ! src/hotspot/share/gc/z/zGeneration.cpp ! src/hotspot/share/interpreter/oopMapCache.cpp ! src/hotspot/share/interpreter/oopMapCache.hpp Changeset: ca5a438e Author: Christian Hagedorn Date: 2024-06-24 08:58:02 +0000 URL: https://git.openjdk.org/loom/commit/ca5a438e5a4612c66f70c70a9d425eca0e49e84d 8334571: Extract control dependency rewiring out of PhaseIdealLoop::dominated_by() into separate method Reviewed-by: roland, kvn ! src/hotspot/share/opto/loopPredicate.cpp ! src/hotspot/share/opto/loopnode.hpp ! src/hotspot/share/opto/loopopts.cpp Changeset: 9d4a4bd2 Author: Matthew Donovan Date: 2024-06-24 11:15:33 +0000 URL: https://git.openjdk.org/loom/commit/9d4a4bd2c2a4bd16bbc80b602b15b448c52220f6 8324841: PKCS11 tests still skip execution Reviewed-by: valeriep ! test/jdk/sun/security/pkcs11/PKCS11Test.java Changeset: 2e64d151 Author: Lutz Schmidt Date: 2024-06-24 11:27:18 +0000 URL: https://git.openjdk.org/loom/commit/2e64d15144be03388104c762816c1ba629da9639 8334564: VM startup: fatal error: FLAG_SET_ERGO cannot be used to set an invalid value for NonNMethodCodeHeapSize Reviewed-by: mdoerr, kvn, stuefe ! src/hotspot/share/code/codeCache.cpp Changeset: 5ac2149b Author: Coleen Phillimore Date: 2024-06-24 12:37:53 +0000 URL: https://git.openjdk.org/loom/commit/5ac2149b7bde947886533bf5996d977bb8ec66f1 8334299: Deprecate LockingMode option, along with LM_LEGACY and LM_MONITOR Reviewed-by: stuefe, dholmes ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp ! test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java Changeset: e825ccfe Author: Robert Toyonaga Committer: Thomas Stuefe Date: 2024-06-24 13:33:20 +0000 URL: https://git.openjdk.org/loom/commit/e825ccfe6652577e4e828e8e4dfe19be0ea77813 8332362: Implement os::committed_in_range for MacOS and AIX Reviewed-by: stuefe ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/os/posix/os_posix.cpp ! src/hotspot/share/runtime/os.cpp ! test/hotspot/gtest/runtime/test_committed_virtualmemory.cpp ! test/hotspot/jtreg/runtime/Thread/TestAlwaysPreTouchStacks.java Changeset: b2930c5a Author: Adam Sotona Date: 2024-06-24 13:34:29 +0000 URL: https://git.openjdk.org/loom/commit/b2930c5aeedf911ec893734181c1af0573e222f4 8334040: jdk/classfile/CorpusTest.java timed out Reviewed-by: alanb ! test/jdk/jdk/classfile/CorpusTest.java Changeset: 55c79694 Author: Erik Gahlin Date: 2024-06-24 14:36:50 +0000 URL: https://git.openjdk.org/loom/commit/55c796946158aab1d019a57b77a33441d7b13065 8334765: JFR: Log chunk waste Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/filter/ChunkWriter.java ! test/jdk/jdk/jfr/jvm/TestWaste.java Changeset: 71a692ab Author: Matias Saavedra Silva Date: 2024-06-24 18:05:50 +0000 URL: https://git.openjdk.org/loom/commit/71a692ab435fdeea4ce8f8db7a55dd735c7c5016 8321033: Avoid casting Array to GrowableArray Reviewed-by: kbarrett, iklam, ccheung ! src/hotspot/share/classfile/moduleEntry.cpp ! src/hotspot/share/classfile/moduleEntry.hpp Changeset: 4b153e5e Author: Matias Saavedra Silva Date: 2024-06-24 18:19:03 +0000 URL: https://git.openjdk.org/loom/commit/4b153e5e051c01ad8d0c3ff335352918c2970fe6 8306580: Propagate CDS dumping errors instead of directly exiting the VM Reviewed-by: iklam, ccheung ! src/hotspot/share/cds/archiveBuilder.cpp ! src/hotspot/share/cds/archiveBuilder.hpp ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/cds/metaspaceShared.hpp ! src/hotspot/share/runtime/threads.cpp + test/hotspot/jtreg/runtime/cds/StaticWritingError.java Changeset: 3a26bbce Author: Alisen Chung Date: 2024-06-25 02:19:57 +0000 URL: https://git.openjdk.org/loom/commit/3a26bbcebc2f7d11b172f2b16192a3adefeb8111 8185429: [macos] After a modal dialog is closed, no window becomes active Reviewed-by: tr, dnguyen, serb ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! test/jdk/ProblemList.txt Changeset: e527e1c3 Author: Prasanta Sadhukhan Date: 2024-06-25 03:26:18 +0000 URL: https://git.openjdk.org/loom/commit/e527e1c32fcc7b2560cec540bcde930075ac284a 8334580: Deprecate no-arg constructor BasicSliderUI() for removal Reviewed-by: kcr, aivanov, iris, prr ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicSliderUI.java Changeset: 974dca80 Author: Thomas Stuefe Date: 2024-06-25 05:06:33 +0000 URL: https://git.openjdk.org/loom/commit/974dca80df71c5cbe492d1e8ca5cee76bcc79358 8334223: Make Arena MEMFLAGs immutable Reviewed-by: jsjolen, azafari, gziemski ! src/hotspot/share/compiler/compilerThread.cpp ! src/hotspot/share/memory/arena.cpp ! src/hotspot/share/memory/arena.hpp ! src/hotspot/share/memory/resourceArea.cpp ! src/hotspot/share/memory/resourceArea.hpp ! src/hotspot/share/prims/jni.cpp ! src/hotspot/share/runtime/handles.hpp ! src/hotspot/share/runtime/javaThread.cpp ! src/hotspot/share/runtime/javaThread.hpp ! src/hotspot/share/runtime/javaThread.inline.hpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp Changeset: c30e0403 Author: Neethu Prasad Committer: Aleksey Shipilev Date: 2024-06-25 07:08:07 +0000 URL: https://git.openjdk.org/loom/commit/c30e040342c69a213bdff321fdcb0d27ff740489 8331911: Reconsider locking for recently disarmed nmethods Reviewed-by: shade, eosterlund ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/gc/shared/barrierSetNMethod.cpp ! src/hotspot/share/gc/x/xBarrierSetNMethod.cpp ! src/hotspot/share/gc/z/zBarrierSetNMethod.cpp Changeset: baafa662 Author: Kevin Walls Date: 2024-06-25 09:12:09 +0000 URL: https://git.openjdk.org/loom/commit/baafa662a2f0706e4275a4fe0459ee6759369858 8334287: Man page update for jstatd deprecation Reviewed-by: alanb ! src/jdk.jstatd/share/man/jstatd.1 Changeset: 75a2afac Author: Sean Mullan Date: 2024-06-25 12:21:46 +0000 URL: https://git.openjdk.org/loom/commit/75a2afacc8f5fdec53350b1cb66076cdfeae12f0 8248981: Specify list of standard message digest and mgf algorithms for RSASSA-PSS signature Reviewed-by: valeriep ! src/java.base/share/classes/java/security/spec/ECGenParameterSpec.java ! src/java.base/share/classes/java/security/spec/NamedParameterSpec.java ! src/java.base/share/classes/java/security/spec/PSSParameterSpec.java Changeset: cae94b26 Author: Hamlin Li Date: 2024-06-25 14:06:03 +0000 URL: https://git.openjdk.org/loom/commit/cae94b268d633b0557a54e3b21eff60d7f0edc2d 8334397: RISC-V: verify perf of ReverseBytesS/US Reviewed-by: fyang, luhenry ! src/hotspot/cpu/riscv/riscv.ad ! src/hotspot/cpu/riscv/riscv_b.ad ! test/micro/org/openjdk/bench/java/lang/Characters.java + test/micro/org/openjdk/bench/java/lang/Shorts.java Changeset: 6c679330 Author: Matias Saavedra Silva Date: 2024-06-25 14:07:32 +0000 URL: https://git.openjdk.org/loom/commit/6c6793307d4734409016943ae584726ac30d667e 8334899: Test runtime/cds/appcds/javaldr/ExceptionDuringDumpAtObjectsInitPhase.java failed after JDK-8306580 Reviewed-by: iklam, dholmes ! test/hotspot/jtreg/runtime/cds/appcds/javaldr/ExceptionDuringDumpAtObjectsInitPhase.java Changeset: 57f8b91e Author: Johan Sj?len Date: 2024-06-25 14:37:38 +0000 URL: https://git.openjdk.org/loom/commit/57f8b91e558e5b9ff9c2000b8f74e3a1988ead2b 8333658: NMT: Use an allocator with 4-byte pointers to save memory in NativeCallStackStorage Reviewed-by: stuefe, azafari + src/hotspot/share/nmt/arrayWithFreeList.hpp + src/hotspot/share/nmt/nmtNativeCallStackStorage.cpp ! src/hotspot/share/nmt/nmtNativeCallStackStorage.hpp + test/hotspot/gtest/nmt/test_arrayWithFreeList.cpp Changeset: 9c89f086 Author: Vladimir Kozlov Date: 2024-06-25 16:04:03 +0000 URL: https://git.openjdk.org/loom/commit/9c89f0861c1b6d25e1a7c3ac1add9a168d807788 8334421: assert(!oldbox->is_unbalanced()) failed: this should not be called for unbalanced region Reviewed-by: vlivanov, thartmann ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/callnode.hpp ! src/hotspot/share/opto/escape.cpp ! src/hotspot/share/opto/locknode.hpp ! src/hotspot/share/opto/macro.cpp + test/hotspot/jtreg/compiler/locks/TestCoarsenedAndNotEscapedLocksElimination.java Changeset: 7429c37e Author: Ioi Lam Date: 2024-06-25 16:44:41 +0000 URL: https://git.openjdk.org/loom/commit/7429c37e63ffd50884d91d8f583d409633bfb04d 8334598: Default classlist in JDK is not deterministic after JDK-8293980 Reviewed-by: ccheung, dholmes, stuefe, erikj ! make/GenerateLinkOptData.gmk Changeset: 933eabab Author: Quan Anh Mai Date: 2024-06-25 17:10:20 +0000 URL: https://git.openjdk.org/loom/commit/933eababf2b79586a911082af36fdcc41763c7b9 8334629: [BACKOUT] PhaseIdealLoop::conditional_move is too conservative Reviewed-by: epeter, thartmann, jkarthikeyan ! src/hotspot/share/opto/loopopts.cpp ! test/hotspot/jtreg/ProblemList.txt - test/micro/org/openjdk/bench/vm/compiler/CMove.java Changeset: f8bf470b Author: Yude Lin Committer: Naoto Sato Date: 2024-06-25 18:19:42 +0000 URL: https://git.openjdk.org/loom/commit/f8bf470b773884911290fa6ce059f7cc13686186 8334810: Redo: Un-ProblemList LocaleProvidersRun and CalendarDataRegression 8268379: java/util/Locale/LocaleProvidersRun.java and sun/util/locale/provider/CalendarDataRegression.java timed out Reviewed-by: naoto, jlu ! test/jdk/ProblemList.txt Changeset: 861aefca Author: Justin Lu Date: 2024-06-25 19:05:01 +0000 URL: https://git.openjdk.org/loom/commit/861aefcafacdc21459ef966307f52568e327fd49 8334418: Update IANA Language Subtag Registry to Version 2024-06-14 Reviewed-by: lancea, iris, srl, naoto ! src/java.base/share/data/lsrdata/language-subtag-registry.txt ! test/jdk/java/util/Locale/LanguageSubtagRegistryTest.java Changeset: 86b0cf25 Author: Justin Lu Date: 2024-06-25 19:05:22 +0000 URL: https://git.openjdk.org/loom/commit/86b0cf259fb3cbe3a1973151148e5d36c6a99d91 8334653: ISO 4217 Amendment 177 Update Reviewed-by: naoto ! src/java.base/share/classes/sun/util/resources/CurrencyNames.properties ! src/java.base/share/data/currency/CurrencyData.properties ! test/jdk/java/util/Currency/CheckDataVersion.java ! test/jdk/java/util/Currency/CurrencyTest.java = test/jdk/java/util/Currency/ISO4217-list-one.txt ! test/jdk/java/util/Currency/ValidateISO4217.java Changeset: 581f569a Author: Alan Bateman Date: 2024-06-25 21:24:27 +0000 URL: https://git.openjdk.org/loom/commit/581f569afe299ad19a19e3948a662fe8b7700d43 Merge ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/interpreter/oopMapCache.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/javaThread.cpp ! src/hotspot/share/runtime/javaThread.hpp ! src/hotspot/share/runtime/javaThread.inline.hpp ! src/hotspot/share/runtime/threads.cpp ! test/hotspot/jtreg/ProblemList.txt ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/interpreter/oopMapCache.cpp ! src/hotspot/share/runtime/globals.hpp ! src/hotspot/share/runtime/javaThread.cpp ! src/hotspot/share/runtime/javaThread.hpp ! src/hotspot/share/runtime/javaThread.inline.hpp ! src/hotspot/share/runtime/threads.cpp ! test/hotspot/jtreg/ProblemList.txt Changeset: c16254bb Author: Alan Bateman Date: 2024-06-25 14:08:09 +0000 URL: https://git.openjdk.org/loom/commit/c16254bb154ccf35d214129d6ca492784f223342 Failure handler not using right jcmd ! test/failure_handler/src/share/conf/common.properties Changeset: 04f1a170 Author: Alan Bateman Date: 2024-06-25 21:24:59 +0000 URL: https://git.openjdk.org/loom/commit/04f1a170f48022a4c74bb5a4258dd2fcfa83dfec Merge From duke at openjdk.org Wed Jun 26 06:46:58 2024 From: duke at openjdk.org (duke) Date: Wed, 26 Jun 2024 06:46:58 GMT Subject: git: openjdk/loom: master: 34 new changesets Message-ID: <89121b35-2fec-4f40-a480-e6c3e4be345b@openjdk.org> Changeset: 72ca7baf Author: Hannes Greule Committer: Chen Liang Date: 2024-06-22 12:16:50 +0000 URL: https://git.openjdk.org/loom/commit/72ca7bafcd49a98c1fe09da72e4e47683f052e9d 8334708: FFM: two javadoc problems Reviewed-by: mcimadamore ! src/java.base/share/classes/java/lang/foreign/Linker.java ! src/java.base/share/classes/java/lang/foreign/MemoryLayout.java Changeset: 652784c8 Author: Johan Sj?len Date: 2024-06-23 08:19:28 +0000 URL: https://git.openjdk.org/loom/commit/652784c803863f40ee3d81695a19e705365cb800 8334392: Switch RNG in NMT's treap Reviewed-by: stuefe, azafari, gziemski ! src/hotspot/share/nmt/nmtTreap.hpp ! test/hotspot/gtest/nmt/test_nmt_treap.cpp Changeset: eb110bdc Author: Johan Sj?len Date: 2024-06-23 12:33:38 +0000 URL: https://git.openjdk.org/loom/commit/eb110bdc6e8bcb87b9b8b24ac66eb9b4c57106fd 8334180: NMT gtests introduced with 8312132 should be labeled as NMT Reviewed-by: gziemski, stuefe ! src/hotspot/share/nmt/memoryFileTracker.hpp ! src/hotspot/share/nmt/nmtTreap.hpp ! src/hotspot/share/nmt/vmatree.hpp ! test/hotspot/gtest/nmt/test_nmt_memoryfiletracker.cpp ! test/hotspot/gtest/nmt/test_nmt_nativecallstackstorage.cpp ! test/hotspot/gtest/nmt/test_nmt_treap.cpp ! test/hotspot/gtest/nmt/test_vmatree.cpp Changeset: 7baddc20 Author: SendaoYan Committer: Alan Bateman Date: 2024-06-23 18:00:28 +0000 URL: https://git.openjdk.org/loom/commit/7baddc202a9ab2b85401aa05f827678b514ebf55 8334339: Test java/nio/file/attribute/BasicFileAttributeView/CreationTime.java fails on alinux3 Reviewed-by: alanb ! test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java Changeset: a4582a89 Author: Zhao Song Committer: Erik Joelsson Date: 2024-06-24 05:15:32 +0000 URL: https://git.openjdk.org/loom/commit/a4582a8957d604b50249e1f59679393966456a14 8334166: Enable binary check Reviewed-by: kcr, ihse, prr, erikj ! .jcheck/conf Changeset: 863b2a99 Author: Axel Boldt-Christmas Date: 2024-06-24 06:06:45 +0000 URL: https://git.openjdk.org/loom/commit/863b2a991df9204560c4680fc10dd0f68b260217 8329994: Zap alignment padding bits for ArrayOops in non-release builds Reviewed-by: ayang, sjohanss ! src/hotspot/share/gc/shared/memAllocator.cpp ! src/hotspot/share/gc/shared/memAllocator.hpp ! src/hotspot/share/gc/z/zObjArrayAllocator.cpp Changeset: 13dce296 Author: Richard Reingruber Date: 2024-06-24 06:33:39 +0000 URL: https://git.openjdk.org/loom/commit/13dce296fc3924b269757ce1279c57afe18faeeb 8334560: [PPC64]: postalloc_expand_java_dynamic_call_sched does not copy all fields Reviewed-by: mbaesken, mdoerr ! src/hotspot/cpu/ppc/ppc.ad ! test/jdk/com/sun/jdi/EATests.java Changeset: edf7f055 Author: Emanuel Peter Date: 2024-06-24 07:14:57 +0000 URL: https://git.openjdk.org/loom/commit/edf7f055ee010a2c19bce26c15726d5b58e2e832 8334083: C2 SuperWord: TestCompatibleUseDefTypeSize.java fails with -XX:+AlignVector after JDK-8325155 Reviewed-by: chagedorn, kvn ! test/hotspot/jtreg/compiler/loopopts/superword/TestCompatibleUseDefTypeSize.java Changeset: 05a63d80 Author: Johan Sj?len Date: 2024-06-24 07:51:01 +0000 URL: https://git.openjdk.org/loom/commit/05a63d80b9c1e312512c707ccf6b255c16a9edf5 8334489: Add function os::used_memory Reviewed-by: eosterlund, dholmes, stuefe ! src/hotspot/share/runtime/os.cpp ! src/hotspot/share/runtime/os.hpp Changeset: 05ff3185 Author: Aleksey Shipilev Date: 2024-06-24 08:46:10 +0000 URL: https://git.openjdk.org/loom/commit/05ff3185edd25b381a97f6879f496e97b62dddc2 8334594: Generational ZGC: Deadlock after OopMap rewrites in 8331572 Reviewed-by: stefank, eosterlund, coleenp, zgu ! src/hotspot/share/gc/shared/gcVMOperations.cpp ! src/hotspot/share/gc/shenandoah/shenandoahVMOperations.cpp ! src/hotspot/share/gc/x/xDriver.cpp ! src/hotspot/share/gc/z/zGeneration.cpp ! src/hotspot/share/interpreter/oopMapCache.cpp ! src/hotspot/share/interpreter/oopMapCache.hpp Changeset: ca5a438e Author: Christian Hagedorn Date: 2024-06-24 08:58:02 +0000 URL: https://git.openjdk.org/loom/commit/ca5a438e5a4612c66f70c70a9d425eca0e49e84d 8334571: Extract control dependency rewiring out of PhaseIdealLoop::dominated_by() into separate method Reviewed-by: roland, kvn ! src/hotspot/share/opto/loopPredicate.cpp ! src/hotspot/share/opto/loopnode.hpp ! src/hotspot/share/opto/loopopts.cpp Changeset: 9d4a4bd2 Author: Matthew Donovan Date: 2024-06-24 11:15:33 +0000 URL: https://git.openjdk.org/loom/commit/9d4a4bd2c2a4bd16bbc80b602b15b448c52220f6 8324841: PKCS11 tests still skip execution Reviewed-by: valeriep ! test/jdk/sun/security/pkcs11/PKCS11Test.java Changeset: 2e64d151 Author: Lutz Schmidt Date: 2024-06-24 11:27:18 +0000 URL: https://git.openjdk.org/loom/commit/2e64d15144be03388104c762816c1ba629da9639 8334564: VM startup: fatal error: FLAG_SET_ERGO cannot be used to set an invalid value for NonNMethodCodeHeapSize Reviewed-by: mdoerr, kvn, stuefe ! src/hotspot/share/code/codeCache.cpp Changeset: 5ac2149b Author: Coleen Phillimore Date: 2024-06-24 12:37:53 +0000 URL: https://git.openjdk.org/loom/commit/5ac2149b7bde947886533bf5996d977bb8ec66f1 8334299: Deprecate LockingMode option, along with LM_LEGACY and LM_MONITOR Reviewed-by: stuefe, dholmes ! src/hotspot/share/runtime/arguments.cpp ! src/hotspot/share/runtime/globals.hpp ! test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java Changeset: e825ccfe Author: Robert Toyonaga Committer: Thomas Stuefe Date: 2024-06-24 13:33:20 +0000 URL: https://git.openjdk.org/loom/commit/e825ccfe6652577e4e828e8e4dfe19be0ea77813 8332362: Implement os::committed_in_range for MacOS and AIX Reviewed-by: stuefe ! src/hotspot/os/linux/os_linux.cpp ! src/hotspot/os/posix/os_posix.cpp ! src/hotspot/share/runtime/os.cpp ! test/hotspot/gtest/runtime/test_committed_virtualmemory.cpp ! test/hotspot/jtreg/runtime/Thread/TestAlwaysPreTouchStacks.java Changeset: b2930c5a Author: Adam Sotona Date: 2024-06-24 13:34:29 +0000 URL: https://git.openjdk.org/loom/commit/b2930c5aeedf911ec893734181c1af0573e222f4 8334040: jdk/classfile/CorpusTest.java timed out Reviewed-by: alanb ! test/jdk/jdk/classfile/CorpusTest.java Changeset: 55c79694 Author: Erik Gahlin Date: 2024-06-24 14:36:50 +0000 URL: https://git.openjdk.org/loom/commit/55c796946158aab1d019a57b77a33441d7b13065 8334765: JFR: Log chunk waste Reviewed-by: mgronlun ! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/filter/ChunkWriter.java ! test/jdk/jdk/jfr/jvm/TestWaste.java Changeset: 71a692ab Author: Matias Saavedra Silva Date: 2024-06-24 18:05:50 +0000 URL: https://git.openjdk.org/loom/commit/71a692ab435fdeea4ce8f8db7a55dd735c7c5016 8321033: Avoid casting Array to GrowableArray Reviewed-by: kbarrett, iklam, ccheung ! src/hotspot/share/classfile/moduleEntry.cpp ! src/hotspot/share/classfile/moduleEntry.hpp Changeset: 4b153e5e Author: Matias Saavedra Silva Date: 2024-06-24 18:19:03 +0000 URL: https://git.openjdk.org/loom/commit/4b153e5e051c01ad8d0c3ff335352918c2970fe6 8306580: Propagate CDS dumping errors instead of directly exiting the VM Reviewed-by: iklam, ccheung ! src/hotspot/share/cds/archiveBuilder.cpp ! src/hotspot/share/cds/archiveBuilder.hpp ! src/hotspot/share/cds/filemap.cpp ! src/hotspot/share/cds/metaspaceShared.cpp ! src/hotspot/share/cds/metaspaceShared.hpp ! src/hotspot/share/runtime/threads.cpp + test/hotspot/jtreg/runtime/cds/StaticWritingError.java Changeset: 3a26bbce Author: Alisen Chung Date: 2024-06-25 02:19:57 +0000 URL: https://git.openjdk.org/loom/commit/3a26bbcebc2f7d11b172f2b16192a3adefeb8111 8185429: [macos] After a modal dialog is closed, no window becomes active Reviewed-by: tr, dnguyen, serb ! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! test/jdk/ProblemList.txt Changeset: e527e1c3 Author: Prasanta Sadhukhan Date: 2024-06-25 03:26:18 +0000 URL: https://git.openjdk.org/loom/commit/e527e1c32fcc7b2560cec540bcde930075ac284a 8334580: Deprecate no-arg constructor BasicSliderUI() for removal Reviewed-by: kcr, aivanov, iris, prr ! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicSliderUI.java Changeset: 974dca80 Author: Thomas Stuefe Date: 2024-06-25 05:06:33 +0000 URL: https://git.openjdk.org/loom/commit/974dca80df71c5cbe492d1e8ca5cee76bcc79358 8334223: Make Arena MEMFLAGs immutable Reviewed-by: jsjolen, azafari, gziemski ! src/hotspot/share/compiler/compilerThread.cpp ! src/hotspot/share/memory/arena.cpp ! src/hotspot/share/memory/arena.hpp ! src/hotspot/share/memory/resourceArea.cpp ! src/hotspot/share/memory/resourceArea.hpp ! src/hotspot/share/prims/jni.cpp ! src/hotspot/share/runtime/handles.hpp ! src/hotspot/share/runtime/javaThread.cpp ! src/hotspot/share/runtime/javaThread.hpp ! src/hotspot/share/runtime/javaThread.inline.hpp ! src/hotspot/share/runtime/thread.cpp ! src/hotspot/share/runtime/thread.hpp Changeset: c30e0403 Author: Neethu Prasad Committer: Aleksey Shipilev Date: 2024-06-25 07:08:07 +0000 URL: https://git.openjdk.org/loom/commit/c30e040342c69a213bdff321fdcb0d27ff740489 8331911: Reconsider locking for recently disarmed nmethods Reviewed-by: shade, eosterlund ! src/hotspot/share/code/nmethod.cpp ! src/hotspot/share/gc/shared/barrierSetNMethod.cpp ! src/hotspot/share/gc/x/xBarrierSetNMethod.cpp ! src/hotspot/share/gc/z/zBarrierSetNMethod.cpp Changeset: baafa662 Author: Kevin Walls Date: 2024-06-25 09:12:09 +0000 URL: https://git.openjdk.org/loom/commit/baafa662a2f0706e4275a4fe0459ee6759369858 8334287: Man page update for jstatd deprecation Reviewed-by: alanb ! src/jdk.jstatd/share/man/jstatd.1 Changeset: 75a2afac Author: Sean Mullan Date: 2024-06-25 12:21:46 +0000 URL: https://git.openjdk.org/loom/commit/75a2afacc8f5fdec53350b1cb66076cdfeae12f0 8248981: Specify list of standard message digest and mgf algorithms for RSASSA-PSS signature Reviewed-by: valeriep ! src/java.base/share/classes/java/security/spec/ECGenParameterSpec.java ! src/java.base/share/classes/java/security/spec/NamedParameterSpec.java ! src/java.base/share/classes/java/security/spec/PSSParameterSpec.java Changeset: cae94b26 Author: Hamlin Li Date: 2024-06-25 14:06:03 +0000 URL: https://git.openjdk.org/loom/commit/cae94b268d633b0557a54e3b21eff60d7f0edc2d 8334397: RISC-V: verify perf of ReverseBytesS/US Reviewed-by: fyang, luhenry ! src/hotspot/cpu/riscv/riscv.ad ! src/hotspot/cpu/riscv/riscv_b.ad ! test/micro/org/openjdk/bench/java/lang/Characters.java + test/micro/org/openjdk/bench/java/lang/Shorts.java Changeset: 6c679330 Author: Matias Saavedra Silva Date: 2024-06-25 14:07:32 +0000 URL: https://git.openjdk.org/loom/commit/6c6793307d4734409016943ae584726ac30d667e 8334899: Test runtime/cds/appcds/javaldr/ExceptionDuringDumpAtObjectsInitPhase.java failed after JDK-8306580 Reviewed-by: iklam, dholmes ! test/hotspot/jtreg/runtime/cds/appcds/javaldr/ExceptionDuringDumpAtObjectsInitPhase.java Changeset: 57f8b91e Author: Johan Sj?len Date: 2024-06-25 14:37:38 +0000 URL: https://git.openjdk.org/loom/commit/57f8b91e558e5b9ff9c2000b8f74e3a1988ead2b 8333658: NMT: Use an allocator with 4-byte pointers to save memory in NativeCallStackStorage Reviewed-by: stuefe, azafari + src/hotspot/share/nmt/arrayWithFreeList.hpp + src/hotspot/share/nmt/nmtNativeCallStackStorage.cpp ! src/hotspot/share/nmt/nmtNativeCallStackStorage.hpp + test/hotspot/gtest/nmt/test_arrayWithFreeList.cpp Changeset: 9c89f086 Author: Vladimir Kozlov Date: 2024-06-25 16:04:03 +0000 URL: https://git.openjdk.org/loom/commit/9c89f0861c1b6d25e1a7c3ac1add9a168d807788 8334421: assert(!oldbox->is_unbalanced()) failed: this should not be called for unbalanced region Reviewed-by: vlivanov, thartmann ! src/hotspot/share/opto/callnode.cpp ! src/hotspot/share/opto/callnode.hpp ! src/hotspot/share/opto/escape.cpp ! src/hotspot/share/opto/locknode.hpp ! src/hotspot/share/opto/macro.cpp + test/hotspot/jtreg/compiler/locks/TestCoarsenedAndNotEscapedLocksElimination.java Changeset: 7429c37e Author: Ioi Lam Date: 2024-06-25 16:44:41 +0000 URL: https://git.openjdk.org/loom/commit/7429c37e63ffd50884d91d8f583d409633bfb04d 8334598: Default classlist in JDK is not deterministic after JDK-8293980 Reviewed-by: ccheung, dholmes, stuefe, erikj ! make/GenerateLinkOptData.gmk Changeset: 933eabab Author: Quan Anh Mai Date: 2024-06-25 17:10:20 +0000 URL: https://git.openjdk.org/loom/commit/933eababf2b79586a911082af36fdcc41763c7b9 8334629: [BACKOUT] PhaseIdealLoop::conditional_move is too conservative Reviewed-by: epeter, thartmann, jkarthikeyan ! src/hotspot/share/opto/loopopts.cpp ! test/hotspot/jtreg/ProblemList.txt - test/micro/org/openjdk/bench/vm/compiler/CMove.java Changeset: f8bf470b Author: Yude Lin Committer: Naoto Sato Date: 2024-06-25 18:19:42 +0000 URL: https://git.openjdk.org/loom/commit/f8bf470b773884911290fa6ce059f7cc13686186 8334810: Redo: Un-ProblemList LocaleProvidersRun and CalendarDataRegression 8268379: java/util/Locale/LocaleProvidersRun.java and sun/util/locale/provider/CalendarDataRegression.java timed out Reviewed-by: naoto, jlu ! test/jdk/ProblemList.txt Changeset: 861aefca Author: Justin Lu Date: 2024-06-25 19:05:01 +0000 URL: https://git.openjdk.org/loom/commit/861aefcafacdc21459ef966307f52568e327fd49 8334418: Update IANA Language Subtag Registry to Version 2024-06-14 Reviewed-by: lancea, iris, srl, naoto ! src/java.base/share/data/lsrdata/language-subtag-registry.txt ! test/jdk/java/util/Locale/LanguageSubtagRegistryTest.java Changeset: 86b0cf25 Author: Justin Lu Date: 2024-06-25 19:05:22 +0000 URL: https://git.openjdk.org/loom/commit/86b0cf259fb3cbe3a1973151148e5d36c6a99d91 8334653: ISO 4217 Amendment 177 Update Reviewed-by: naoto ! src/java.base/share/classes/sun/util/resources/CurrencyNames.properties ! src/java.base/share/data/currency/CurrencyData.properties ! test/jdk/java/util/Currency/CheckDataVersion.java ! test/jdk/java/util/Currency/CurrencyTest.java = test/jdk/java/util/Currency/ISO4217-list-one.txt ! test/jdk/java/util/Currency/ValidateISO4217.java From hepin.p at alibaba-inc.com Thu Jun 27 11:21:02 2024 From: hepin.p at alibaba-inc.com (=?UTF-8?B?5L2V5ZOBKOiZjum4oyk=?=) Date: Thu, 27 Jun 2024 19:21:02 +0800 Subject: =?UTF-8?B?5Zue5aSN77ya5Zue5aSN77yaUmVhbC13b3JsZCBQaW5uaW5nL1JlZW50cmFudExvY2sgZGVh?= =?UTF-8?B?ZGxvY2s=?= In-Reply-To: References: Message-ID: <83f74e25-0db5-4855-95bf-07b51ae7a34a.hepin.p@alibaba-inc.com> I want to use something like HashWheelTimer as a `unparker`. ------------------------------------------------------------------ ????Alan Bateman ?????2024?6?26?(???) 14:31 ????"??(??)" ????"loom-dev" ????Re: ???Real-world Pinning/ReentrantLock deadlock On 26/06/2024 07:22, ??(??) wrote: is it possible to make the `unparker` plugable ? Are you asking about being able to use a scheduler other than FJP, or are you specifically talking about the timers which currently use a number of "unparker" threads? -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Jun 27 11:53:28 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 27 Jun 2024 12:53:28 +0100 Subject: =?UTF-8?B?UmU6IOWbnuWkje+8muWbnuWkje+8mlJlYWwtd29ybGQgUGlubmluZy9S?= =?UTF-8?Q?eentrantLock_deadlock?= In-Reply-To: <83f74e25-0db5-4855-95bf-07b51ae7a34a.hepin.p@alibaba-inc.com> References: <83f74e25-0db5-4855-95bf-07b51ae7a34a.hepin.p@alibaba-inc.com> Message-ID: On 27/06/2024 12:21, ??(??) wrote: > I want to use something like HashWheelTimer as a `unparker`. Are you running into a scalability issue with timers with the loom EA builds where the number of times is configurable? Have you done any experiments in your own repo? This project has explored a number of directions for timers, including hashed and hierarchical timing wheels and making using of the OS timer support, but didn't come to a conclusion. One thing on the list is to explore integration with ForkJoinPool but still using a heap-based data structure. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From robaho at me.com Thu Jun 27 21:44:01 2024 From: robaho at me.com (Robert Engels) Date: Thu, 27 Jun 2024 16:44:01 -0500 Subject: Interesting profile session In-Reply-To: References: <62c21cea-d76e-44c1-a887-e7f8836d285d@oracle.com> <17AD6AC4-6529-4337-8C2A-ABE71030BC63@me.com> Message-ID: <7FDC8772-D5E5-4E94-9F96-E2B3B72E981B@me.com> One issue I have run into, with the Loom EA build I can?t run the async profiler against it. When trying to profile it fails with: # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007ff8021fd0b0, pid=80985, tid=36355 # # JRE version: OpenJDK Runtime Environment (24.0+1) (build 24-loom+1-17) # Java VM: OpenJDK 64-Bit Server VM (24-loom+1-17, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-amd64) # Problematic frame: # C [libsystem_platform.dylib+0x10b0] _platform_strcmp+0x50 # # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /Users/robertengels/FrameworkBenchmarks/frameworks/Java/httpserver-robaho/hs_err_pid80985.log [23.364s][warning][os] Loading hsdis library failed # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp # > On Jun 25, 2024, at 8:34 PM, Robert Engels wrote: > > A couple more data points, I built a few more of the servers from https://github.com/TechEmpower/FrameworkBenchmarks/tree/master?tab=readme-ov-file including several non-Java (Rust, Go) - and all showed roughly the same latency (~12-13ms) and throughput, so I suspect it is some limiting factor in the OS. > > Now, how the Java one with platform threads achieved such low latency, I don?t know? > > >> On Jun 25, 2024, at 8:37 AM, Robert Engels > wrote: >> >> I tested with the Loom EA build (Interestingly, I needed to turn off the OSX firewall - there was no prompt ?Allow network access?? and no errors, but the client could not connect. Even if I added the java binary to the allowed list - something to be aware of). >> >> With the default, it made no difference: >> >> Thread Stats Avg Stdev Max +/- Stdev >> Latency 13.74ms 3.67ms 140.26ms 98.12% >> Req/Sec 1.18k 101.17 2.44k 92.82% >> >> With pollerMode=1: (note the huge increase in the max requests per thread) >> >> Thread Stats Avg Stdev Max +/- Stdev >> Latency 13.81ms 5.72ms 442.92ms 98.91% >> Req/Sec 1.18k 125.92 11.17k 95.90% >> >> With pollerMode=2: >> >> Thread Stats Avg Stdev Max +/- Stdev >> Latency 13.62ms 3.25ms 440.39ms 97.55% >> Req/Sec 1.18k 104.44 5.19k 91.89% >> >> So no option approaches the platform thread latency. >> >> Here is the vthread summary captured using the default pollerMode: >> >> iMac:httpserver-robaho robertengels$ jcmd 99219 Thread.vthread_summary >> 99219: >> [platform threads = 13, virtual threads = 0] >> +-- java.util.concurrent.ThreadPerTaskExecutor at 3b764bce [platform threads = 0, virtual threads = 1024] >> +-- java.util.concurrent.ScheduledThreadPoolExecutor at 80820e0 [platform threads = 1, virtual threads = 0] >> +-- java.util.concurrent.ScheduledThreadPoolExecutor at 4e40fef8 [platform threads = 0, virtual threads = 0] >> +-- java.util.concurrent.ScheduledThreadPoolExecutor at 72e23c5b [platform threads = 1, virtual threads = 0] >> +-- ForkJoinPool-1/jdk.internal.vm.SharedThreadContainer at 2b84658e [platform threads = 8, virtual threads = 0] >> +-- ForkJoinPool.commonPool/jdk.internal.vm.SharedThreadContainer at 368551f2 [platform threads = 0, virtual threads = 0] >> +-- java.util.concurrent.ThreadPoolExecutor at 2f2ae4f0 [platform threads = 0, virtual threads = 0] >> >> Default virtual thread scheduler: >> java.util.concurrent.ForkJoinPool at 7fb948b5[Running, parallelism = 8, size = 8, active = 4, running = 1, steals = 4360536, tasks = 0, submissions = 0] >> >> Timeout schedulers: >> [0] java.util.concurrent.ScheduledThreadPoolExecutor at 80820e0[Running, pool size = 1, active threads = 0, queued tasks = 0, completed tasks = 2] >> [1] java.util.concurrent.ScheduledThreadPoolExecutor at 72e23c5b[Running, pool size = 1, active threads = 0, queued tasks = 0, completed tasks = 4] >> >> Read I/O pollers: >> [0] sun.nio.ch.KQueuePoller at 3ff9782b [registered = 1011] >> >> Write I/O pollers: >> [0] sun.nio.ch.KQueuePoller at 58e6b7f4 [registered = 0] >> >> iMac:httpserver-robaho robertengels$ jcmd 99219 VM.version >> 99219: >> OpenJDK 64-Bit Server VM version 24-loom+1-17 >> JDK 24.0.0 >> >> >>> On Jun 25, 2024, at 6:02 AM, robert engels > wrote: >>> >>> Will do and I?ll report back. >>> >>>> On Jun 25, 2024, at 3:14?AM, Alan Bateman > wrote: >>>> >>>> ? On 24/06/2024 23:03, Robert Engels wrote: >>>>> >>>>> The VT latency is a couple of orders of magnitude higher than the platform latency. >>>>> >>>>> I suspect that what is happening is that the virtual threads are parking waiting for work too soon - or that the read & writes are always causing a context switch - regardless of if the call is very short (room in the kernel socket buffers). >>>>> >>>>> Can you suggest any remedies? It feels like the scheduler needs some heuristics on average call time to determine and a spin loop to avoid this sort of thing. >>>>> >>>> There may be a combination of things here. From the stack traces, this looks like JDK 21 + macOS. There has been significant changes to both the scheduler (ForkJoinPool) and the I/O poller mechanism since then. Would you have time to out the latest EA build [1] to see if you get similar latency? It would be interesting to see data with -Djdk.pollerMode=1 and 2 (the default on macOS is "a"). Also would be useful to see `jcmd Thread.vthread_summary` output while the benchmark is running as that will reveal more about the scheduler and how many virtual threads are blocked on socket I/O. >>>> >>>> [1] https://jdk.java.net/loom/ >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: hs_err_pid52472.log Type: application/octet-stream Size: 467286 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: hs_err_pid80985.log Type: application/octet-stream Size: 89095 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From hepin.p at alibaba-inc.com Fri Jun 28 02:58:03 2024 From: hepin.p at alibaba-inc.com (=?UTF-8?B?5L2V5ZOBKOiZjum4oyk=?=) Date: Fri, 28 Jun 2024 10:58:03 +0800 Subject: =?UTF-8?B?5Zue5aSN77ya5Zue5aSN77ya5Zue5aSN77yaUmVhbC13b3JsZCBQaW5uaW5nL1JlZW50cmFu?= =?UTF-8?B?dExvY2sgZGVhZGxvY2s=?= In-Reply-To: References: Message-ID: I think integration with ForkJoinPool should be great as the Netty's EventLoop can do a scheduling too. but in some cases, we may need another timer for accuracy. I have not encounter a problem because I am doing scheduling with another dedicated timer. ------------------------------------------------------------------ ????Alan Bateman ?????2024?6?27?(???) 19:53 ????"??(??)" ????"loom-dev" ????Re: ??????Real-world Pinning/ReentrantLock deadlock On 27/06/2024 12:21, ??(??) wrote: I want to use something like HashWheelTimer as a `unparker`. Are you running into a scalability issue with timers with the loom EA builds where the number of times is configurable? Have you done any experiments in your own repo? This project has explored a number of directions for timers, including hashed and hierarchical timing wheels and making using of the OS timer support, but didn't come to a conclusion. One thing on the list is to explore integration with ForkJoinPool but still using a heap-based data structure. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Jun 28 06:25:40 2024 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 28 Jun 2024 07:25:40 +0100 Subject: Interesting profile session In-Reply-To: <7FDC8772-D5E5-4E94-9F96-E2B3B72E981B@me.com> References: <62c21cea-d76e-44c1-a887-e7f8836d285d@oracle.com> <17AD6AC4-6529-4337-8C2A-ABE71030BC63@me.com> <7FDC8772-D5E5-4E94-9F96-E2B3B72E981B@me.com> Message-ID: <4f740363-4d3d-4f8c-8dcb-c1d439d99ca0@oracle.com> On 27/06/2024 22:44, Robert Engels wrote: > One issue I have run into, with the Loom EA build I can?t run the > async profiler against it. The current EA build is based on jdk-24+3. I don't know if async profiler is working with JDK 24 EA builds yet, it would be good to check that as a baseline. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Sat Jun 29 13:53:56 2024 From: ron.pressler at oracle.com (Ron Pressler) Date: Sat, 29 Jun 2024 13:53:56 +0000 Subject: Experience of adding JDK21 virtual thread support to a DB application In-Reply-To: References: Message-ID: <70AAB518-0B13-4611-B2F6-82938B81CE84@oracle.com> > On 21 Jun 2024, at 16:57, Matthew Swift wrote: > > I know that ReentrantLock is supposed to be a little bit less efficient in highly contended situations, but I was surprised by an 8-10% impact. Is that expected? I wouldn?t say at all that it?s supposed to be slightly less efficient but rather, as Alan mentioned, the behaviour of ReentrantLock and native monitors is a little different ? monitors spin for a bit before blocking. The reason this isn?t the default for ReentrantLock is that this may or may not be what you want, depending on circumstance. However, the ReentrantLock API supports adding spinning manually with a loop calling ReentrantLock.tryLock in the condition and Thread.onSpinWait in the body. ? Ron From ron.pressler at oracle.com Sat Jun 29 14:07:14 2024 From: ron.pressler at oracle.com (Ron Pressler) Date: Sat, 29 Jun 2024 14:07:14 +0000 Subject: Experience using virtual threads in EA 23-loom+4-102 In-Reply-To: <11DD9614-B571-45E9-9C33-EBB9279E7663@icloud.com> References: <6A9FDAD8-3507-4952-A47C-B8CC57C8AD2E@ix.netcom.com> <11DD9614-B571-45E9-9C33-EBB9279E7663@icloud.com> Message-ID: <07DDEEC5-688D-45A4-A651-CFDA38E3757C@oracle.com> > On 24 Jun 2024, at 21:12, Robert Engels wrote: > > > The problem with using VT for everything is that a VT is not time-sliced, so you could quickly consume all of the carrier threads and then you make no progress on the IO (fan out) requests - which is especially bad if they are simply calling out to other servers (less bad if doing lots of local disk io). The only reason why virtual threads do not time share is because we have yet to find a server workload for which time-sharing would help. Even the OS starts relying heavily on time-sharing only at 100% CPU, and people don?t generally think their servers behave well at 100% CPU. In other words, the only reason virtual threads don?t time share is that we haven?t found a problem that time sharing solves satisfactorily. Even theoretically, time sharing is about as likely to hurt as it is to help ? when tasks consume similar amounts of CPU to each other, time sharing can very significantly hurt the average latency; on the other hand, when tasks vary a lot from each other in the amount of CPU they consume, time sharing could significantly improve the average latency but, again, we need to see such workloads before we can add time sharing. After all, we can only solve a problem once we see what it is. The reason why this isn?t obvious is that if you have some portion of tasks that vary greatly in their CPU consumption, that means that some consume a lot of CPU. If that portion is very small, it?s not clear that time sharing helps; if that portion is high, and remember ? we?re talking about many thousands of threads at least ? then it?s likely that the overall CPU consumption is very high, in which case it is also unclear that time-sharing can help. However, that we have not found realistic cases where time sharing helps does not mean they don?t exist. We would very much like to see realistic server instances where there is a problem that time sharing could solve. ? Ron From robaho at icloud.com Sat Jun 29 18:04:27 2024 From: robaho at icloud.com (robert engels) Date: Sat, 29 Jun 2024 13:04:27 -0500 Subject: Experience using virtual threads in EA 23-loom+4-102 In-Reply-To: <07DDEEC5-688D-45A4-A651-CFDA38E3757C@oracle.com> References: <07DDEEC5-688D-45A4-A651-CFDA38E3757C@oracle.com> Message-ID: <2B54EE29-CDD4-47A0-8178-27F8FE2AD39F@icloud.com> I think the issue is for cpu bound work land - eg image conversions, etc. I think not having time sharing is only an issue for machines with low cpu counts. The issue is that tail latency gets out of control. IO tasks get blocked too easily. Every general workload OS has time sharing (that I?m aware of) has time sharing just for this reason. > On Jun 29, 2024, at 9:07?AM, Ron Pressler wrote: > > ? > >> On 24 Jun 2024, at 21:12, Robert Engels wrote: >> >> >> The problem with using VT for everything is that a VT is not time-sliced, so you could quickly consume all of the carrier threads and then you make no progress on the IO (fan out) requests - which is especially bad if they are simply calling out to other servers (less bad if doing lots of local disk io). > > The only reason why virtual threads do not time share is because we have yet to find a server workload for which time-sharing would help. Even the OS starts relying heavily on time-sharing only at 100% CPU, and people don?t generally think their servers behave well at 100% CPU. In other words, the only reason virtual threads don?t time share is that we haven?t found a problem that time sharing solves satisfactorily. > > Even theoretically, time sharing is about as likely to hurt as it is to help ? when tasks consume similar amounts of CPU to each other, time sharing can very significantly hurt the average latency; on the other hand, when tasks vary a lot from each other in the amount of CPU they consume, time sharing could significantly improve the average latency but, again, we need to see such workloads before we can add time sharing. After all, we can only solve a problem once we see what it is. > > The reason why this isn?t obvious is that if you have some portion of tasks that vary greatly in their CPU consumption, that means that some consume a lot of CPU. If that portion is very small, it?s not clear that time sharing helps; if that portion is high, and remember ? we?re talking about many thousands of threads at least ? then it?s likely that the overall CPU consumption is very high, in which case it is also unclear that time-sharing can help. > > However, that we have not found realistic cases where time sharing helps does not mean they don?t exist. We would very much like to see realistic server instances where there is a problem that time sharing could solve. > > ? Ron From robaho at icloud.com Sat Jun 29 18:11:35 2024 From: robaho at icloud.com (robert engels) Date: Sat, 29 Jun 2024 13:11:35 -0500 Subject: Experience using virtual threads in EA 23-loom+4-102 In-Reply-To: <2B54EE29-CDD4-47A0-8178-27F8FE2AD39F@icloud.com> References: <2B54EE29-CDD4-47A0-8178-27F8FE2AD39F@icloud.com> Message-ID: <50F59B39-CB9D-4FD1-87AC-3CAEA893D8E7@icloud.com> Sorry for all the typos. And to be clear I wasn?t suggesting that VT should have time sharing. Since platform threads are available to address a lot of these issues. For a data point, Go was forced to implement time sharing because too many things degenerated poorly. > On Jun 29, 2024, at 1:05?PM, robert engels wrote: > > ?I think the issue is for cpu bound work land - eg image conversions, etc. I think not having time sharing is only an issue for machines with low cpu counts. The issue is that tail latency gets out of control. IO tasks get blocked too easily. Every general workload OS has time sharing (that I?m aware of) has time sharing just for this reason. > >> On Jun 29, 2024, at 9:07?AM, Ron Pressler wrote: >> >> ? >> >>>> On 24 Jun 2024, at 21:12, Robert Engels wrote: >>> >>> >>> The problem with using VT for everything is that a VT is not time-sliced, so you could quickly consume all of the carrier threads and then you make no progress on the IO (fan out) requests - which is especially bad if they are simply calling out to other servers (less bad if doing lots of local disk io). >> >> The only reason why virtual threads do not time share is because we have yet to find a server workload for which time-sharing would help. Even the OS starts relying heavily on time-sharing only at 100% CPU, and people don?t generally think their servers behave well at 100% CPU. In other words, the only reason virtual threads don?t time share is that we haven?t found a problem that time sharing solves satisfactorily. >> >> Even theoretically, time sharing is about as likely to hurt as it is to help ? when tasks consume similar amounts of CPU to each other, time sharing can very significantly hurt the average latency; on the other hand, when tasks vary a lot from each other in the amount of CPU they consume, time sharing could significantly improve the average latency but, again, we need to see such workloads before we can add time sharing. After all, we can only solve a problem once we see what it is. >> >> The reason why this isn?t obvious is that if you have some portion of tasks that vary greatly in their CPU consumption, that means that some consume a lot of CPU. If that portion is very small, it?s not clear that time sharing helps; if that portion is high, and remember ? we?re talking about many thousands of threads at least ? then it?s likely that the overall CPU consumption is very high, in which case it is also unclear that time-sharing can help. >> >> However, that we have not found realistic cases where time sharing helps does not mean they don?t exist. We would very much like to see realistic server instances where there is a problem that time sharing could solve. >> >> ? Ron