From sspitsyn at openjdk.org Sat Apr 1 03:23:37 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 1 Apr 2023 03:23:37 GMT Subject: RFR: 8257967: JFR: Events for loaded agents [v10] In-Reply-To: References: Message-ID: On Wed, 22 Mar 2023 09:18:51 GMT, David Holmes wrote: >> src/hotspot/share/prims/jvmtiEnvBase.hpp line 166: >> >>> 164: >>> 165: const void* get_env_local_storage() { return _env_local_storage; } >>> 166: >> >> Why was this change/move necessary? Do I miss anything? > > It is now public, not protected. I see, thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12923#discussion_r1155048753 From sspitsyn at openjdk.org Sat Apr 1 03:34:34 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 1 Apr 2023 03:34:34 GMT Subject: RFR: 8257967: JFR: Events for loaded agents [v15] In-Reply-To: <5cFyTNQZjfRp6VlzOqkgdwhoSGaX92KNL3EZlv-NrpY=.fae84f7f-f1d4-4354-a123-33ab97928dcf@github.com> References: <5cFyTNQZjfRp6VlzOqkgdwhoSGaX92KNL3EZlv-NrpY=.fae84f7f-f1d4-4354-a123-33ab97928dcf@github.com> Message-ID: On Fri, 31 Mar 2023 11:18:23 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> We are adding support to let JFR report on Agents. >> >> #### Design >> >> An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize. >> >> A JavaAgent is an agent written in the Java programming language, using the APIs in the package [java.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html) >> >> A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services. >> >> To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples: >> >> // Command line >> jdk.JavaAgent { >> startTime = 12:31:19.789 (2023-03-08) >> name = "JavaAgent.jar" >> options = "foo=bar" >> dynamic = false >> initializationTime = 12:31:15.574 (2023-03-08) >> initializationDuration = 172 ms >> } >> >> // Dynamic load >> jdk.JavaAgent { >> startTime = 12:31:31.158 (2023-03-08) >> name = "JavaAgent.jar" >> options = "bar=baz" >> dynamic = true >> initializationTime = 12:31:31.037 (2023-03-08) >> initializationDuration = 64,1 ms >> } >> >> The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents. >> >> For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar. >> >> The "dynamic" field denotes if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true) >> >> "initializationTime" is the timestamp the JVM invoked the initialization method, and "initializationDuration" is the duration of executing the initialization method. >> >> "startTime" represents the time the JFR framework issued the periodic event; hence "initializationTime" will be earlier than "startTime". >> >> An agent can also be written in a native programming language using the [JVM Tools Interface (JVMTI)](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file. >> >> To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example: >> >> jdk.NativeAgent { >> startTime = 12:31:40.398 (2023-03-08) >> name = "jdwp" >> options = "transport=dt_socket,server=y,address=any,onjcmd=y" >> dynamic = false >> initializationTime = 12:31:36.142 (2023-03-08) >> initializationDuration = 0,00184 ms >> path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll" >> } >> >> The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported. >> >> The initialization of a native agent is performed by invoking an agent-specified callback routine. The "initializationTime" is when the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationDuration" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationDuration" will be 0. If the agent is loaded dynamically, "initializationDuration" is the time taken to execute the Agent_OnAttach callback. >> >> #### Implementation >> >> There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization ? as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before. >> >> Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize. >> >> When implementing this capability, it was necessary to refactor the code used to represent agents, AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp. >> >> The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp. >> >> The previous two lists that maintained "agents" (JVMTI) and "libraries" (Xrun) were not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced. >> >> Testing: jdk_jfr, tier 1 - 6 >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: > > fixes src/hotspot/share/prims/agent.hpp line 1: > 1: /* The name for class and file is too general. I'm thinking if renaming the files to jvmtiAgent and the class to JvmtiAgent would work. In general, there exists a convention to name JVMTI file with the "jvmti" prefix. It is a gray zone between Runtime and JVMTI but seems to belong more to JVMTI. The same about the AgentList class and file. Also, these new files are good candidates to add here: make/hotspot/lib/JvmFeatures.gmk: ifneq ($(call check-jvm-feature, jvmti), true) JVM_CFLAGS_FEATURES += -DINCLUDE_JVMTI=0 JVM_EXCLUDE_FILES += jvmtiGetLoadedClasses.cpp jvmtiThreadState.cpp jvmtiExtensions.cpp \ jvmtiImpl.cpp jvmtiManageCapabilities.cpp jvmtiRawMonitor.cpp jvmtiUtil.cpp jvmtiTrace.cpp \ jvmtiCodeBlobEvents.cpp jvmtiEnv.cpp jvmtiRedefineClasses.cpp jvmtiEnvBase.cpp jvmtiEnvThreadState.cpp \ jvmtiTagMap.cpp jvmtiEventController.cpp evmCompat.cpp jvmtiEnter.xsl jvmtiExport.cpp \ jvmtiClassFileReconstituter.cpp jvmtiTagMapTable.cpp endif ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12923#discussion_r1155049911 From rkennke at openjdk.org Sat Apr 1 08:00:51 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Sat, 1 Apr 2023 08:00:51 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v49] In-Reply-To: References: Message-ID: On Fri, 31 Mar 2023 21:59:19 GMT, Daniel D. Daugherty wrote: > v47 is hitting an assertion failure in my Mach5 Tier2 and Tier3 testing: > > ``` > # Internal Error (/opt/mach5/mesos/work_dir/slaves/741e9afd-8c02-45c3-b2e2-9db1450d0832-S30407/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/b94a7623-5f98-46f3-8e2c-08444e95afa4/runs/a5754c45-3d7a-46fa-ba4b-c52efcf6ca3b/workspace/open/src/hotspot/share/runtime/lockStack.cpp:78), pid=1731612, tid=1731617 > # assert((_top < end_offset())) failed: lockstack overflow: _top 1704 end_offset 1704 > # > # JRE version: Java(TM) SE Runtime Environment (21.0) (fastdebug build 21-internal-LTS-2023-03-31-1908037.daniel.daugherty.8291555forjdk21.git) > # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 21-internal-LTS-2023-03-31-1908037.daniel.daugherty.8291555forjdk21.git, mixed mode, tiered, compressed oops, compressed class ptrs, serial gc, linux-aarch64) > # Problematic frame: > # V [libjvm.so+0x10cfa0c] LockStack::verify_no_thread(char const*) const+0x288 > ``` > > Please see the bug for the latest details as I investigate. Uh, that is a simple mistake. It should assert _top <= end_offset(). _top is allowed to be at _end, but not go beyond that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1492868319 From rkennke at openjdk.org Sat Apr 1 08:00:51 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Sat, 1 Apr 2023 08:00:51 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v50] In-Reply-To: References: Message-ID: > This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). > > What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. > > This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p rotocols. > > The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare. > > In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. > > One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. > > As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. > > This change enables to simplify (and speed-up!) a lot of code: > > - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. > - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR > > > Testing: > - [x] tier1 x86_64 x aarch64 x +UseFastLocking > - [x] tier2 x86_64 x aarch64 x +UseFastLocking > - [x] tier3 x86_64 x aarch64 x +UseFastLocking > - [x] tier4 x86_64 x aarch64 x +UseFastLocking > - [x] tier1 x86_64 x aarch64 x -UseFastLocking > - [x] tier2 x86_64 x aarch64 x -UseFastLocking > - [x] tier3 x86_64 x aarch64 x -UseFastLocking > - [x] tier4 x86_64 x aarch64 x -UseFastLocking > - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet > > ### Performance > > #### Simple Microbenchmark > > The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops. > > | | x86_64 | aarch64 | > | -- | -- | -- | > | -UseFastLocking | 20.651 | 20.764 | > | +UseFastLocking | 18.896 | 18.908 | > > > #### Renaissance > > ? | x86_64 | ? | ? | ? | aarch64 | ? | ? > -- | -- | -- | -- | -- | -- | -- | -- > ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? > AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% > Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21% > Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% > ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% > GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% > LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% > MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%% > NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% > PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% > FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% > FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% > ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34% > Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% > RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% > Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% > ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% > FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% > FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Fix assert in lock-stack boundaries check ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10907/files - new: https://git.openjdk.org/jdk/pull/10907/files/1ad95851..298031b6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=49 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=48-49 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10907.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/10907/head:pull/10907 PR: https://git.openjdk.org/jdk/pull/10907 From jwaters at openjdk.org Sun Apr 2 06:33:28 2023 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 2 Apr 2023 06:33:28 GMT Subject: RFR: 8305341: Alignment outside of HotSpot should be enforced by alignas instead of compiler specific attributes In-Reply-To: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com> References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com> Message-ID: <8aU00n6Ts6blnBchhfbMycW_iAh1mX0Tv-breuukQto=.2c3d8810-c75f-427e-8fc3-436a89f63b79@github.com> On Fri, 31 Mar 2023 06:07:39 GMT, Julian Waters wrote: > C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements I don't think I can touch the freetype code since I think it's an external library that was imported. HotSpot requires a special review for changes like this, so it's not done here, but instead at https://github.com/openjdk/jdk/pull/11431 (Which has dried up for a long time now, would be great if someone finally looked at that PR...) ------------- PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1493242732 From jwaters at openjdk.org Sun Apr 2 06:37:19 2023 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 2 Apr 2023 06:37:19 GMT Subject: RFR: 8305341: Alignment outside of HotSpot should be enforced by alignas instead of compiler specific attributes In-Reply-To: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com> References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com> Message-ID: On Fri, 31 Mar 2023 06:07:39 GMT, Julian Waters wrote: > C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements Just checked, the pragmas in the freetype code now seems to be pointless since there is no alignment specified in the code it's supposed to guard. Maybe upstream will fix this someday :/ ------------- PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1493245182 From kevinw at openjdk.org Sun Apr 2 09:33:18 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Sun, 2 Apr 2023 09:33:18 GMT Subject: RFR: 8305237: CompilerDirectives DCmds permissions correction In-Reply-To: References: Message-ID: On Fri, 31 Mar 2023 08:24:19 GMT, Kevin Walls wrote: > The Permissions in DCmds relate to remote usage over JMX. > "monitor" is generally for reading information, and "control" is generally for making changes. > The DCmds for changing compiler directives should have "control" as the required permission. > > Tests in test/hotspot/jtreg/serviceability/dcmd/compiler and test/hotspot/jtreg/compiler/compilercontrol still pass with this change. Right, I don't think we test this remotely, and I don't think we test it with permissions. We have test/hotspot/jtreg/serviceability/dcmd/compiler/CompilerDirectivesDCMDTest.java which uses test/lib/jdk/test/lib/dcmd/JMXExecutor.java ...where JMXExecutor implements a CommandExecutor passed to the test's run method and the test does things like: executor.execute("Compiler.directives_clear"); CompilerDirectivesDCMDTest currently tests local usage in the running VM, which is fine and this change does not affect it. I don't really think this feature (remote, permissions) is likely to be actively used, as it is not well documented, so this change is just to try and correct the record of the intent of the feature. I think additional testing should come as a next step as we make changes to the implementation required by the upcoming removal of Security Manager and related APIs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13262#issuecomment-1493278465 From rkennke at openjdk.org Sun Apr 2 21:41:47 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Sun, 2 Apr 2023 21:41:47 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v51] In-Reply-To: References: Message-ID: > This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). > > What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. > > This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p rotocols. > > The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare. > > In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. > > One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. > > As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. > > This change enables to simplify (and speed-up!) a lot of code: > > - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. > - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR > > > Testing: > - [x] tier1 x86_64 x aarch64 x +UseFastLocking > - [x] tier2 x86_64 x aarch64 x +UseFastLocking > - [x] tier3 x86_64 x aarch64 x +UseFastLocking > - [x] tier4 x86_64 x aarch64 x +UseFastLocking > - [x] tier1 x86_64 x aarch64 x -UseFastLocking > - [x] tier2 x86_64 x aarch64 x -UseFastLocking > - [x] tier3 x86_64 x aarch64 x -UseFastLocking > - [x] tier4 x86_64 x aarch64 x -UseFastLocking > - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet > > ### Performance > > #### Simple Microbenchmark > > The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops. > > | | x86_64 | aarch64 | > | -- | -- | -- | > | -UseFastLocking | 20.651 | 20.764 | > | +UseFastLocking | 18.896 | 18.908 | > > > #### Renaissance > > ? | x86_64 | ? | ? | ? | aarch64 | ? | ? > -- | -- | -- | -- | -- | -- | -- | -- > ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? > AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% > Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21% > Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% > ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% > GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% > LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% > MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%% > NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% > PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% > FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% > FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% > ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34% > Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% > RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% > Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% > ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% > FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% > FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% Roman Kennke has updated the pull request incrementally with four additional commits since the last revision: - Replace UseFastLocking with LockingMode flag - Reject +UseFastLocking on unsupported platforms - Merge remote-tracking branch 'tstuefe/ARM-port-8291555' into JDK-8291555-v2 - Arm port ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10907/files - new: https://git.openjdk.org/jdk/pull/10907/files/298031b6..1348f3bc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=50 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=49-50 Stats: 650 lines in 39 files changed: 328 ins; 35 del; 287 mod Patch: https://git.openjdk.org/jdk/pull/10907.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/10907/head:pull/10907 PR: https://git.openjdk.org/jdk/pull/10907 From iklam at openjdk.org Sun Apr 2 23:46:26 2023 From: iklam at openjdk.org (Ioi Lam) Date: Sun, 2 Apr 2023 23:46:26 GMT Subject: RFR: 8305421: Work around JDK-8305420 in CDSJDITest.java Message-ID: Please review this trivial work-around that removes logging that would trigger [JDK-8305420](https://bugs.openjdk.org/browse/JDK-8305420). I also fixed an incorrect parameter in the `executeAndLog()` call, which caused the dumping process's stdout/stderr to be logged in the wrong file. ------------- Commit messages: - 8305421: Work around JDK-8305420 in CDSJDITest.java Changes: https://git.openjdk.org/jdk/pull/13283/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13283&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8305421 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13283.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13283/head:pull/13283 PR: https://git.openjdk.org/jdk/pull/13283 From stuefe at openjdk.org Mon Apr 3 06:00:47 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 3 Apr 2023 06:00:47 GMT Subject: RFR: 8301995: Move invokedynamic resolution information out of ConstantPoolCacheEntry [v16] In-Reply-To: References: <5YPjVZsQAVVL9PHaGu7Mc7kNE0WvPrsiCubKSGzKxvk=.78e8f8fb-1005-4bd7-9ad1-d1dd3aacbe04@github.com> Message-ID: <2QX2qfq-D7XFxp-deWNW7JyrZRMikCDt9LLe8EyQKx8=.1dc3d0be-b6f4-4651-a6d5-1b4aced23ba9@github.com> On Fri, 31 Mar 2023 15:34:12 GMT, Matias Saavedra Silva wrote: > > This obviously breaks arm, since its implementation is missing. I opened https://bugs.openjdk.org/browse/JDK-8305387 to track this. This is unfortunate since it holds work on arm in other areas, in my case for #10907. > > > This change supports the following platforms: x86, aarch64, PPC, RISCV, and S390x > > > > > > I wonder about the explicit exclusion of arm. Every other CPU seems to be taken care of, even those Oracle does not maintain. Just curious, was there a special reason for excluding arm? > > There is no special reason ARM32 was excluded other than the fact no porter has picked it up yet. Fortunately I was able to get in contact with porters for the other platforms, but nobody took on the ARM port until now. Thank you for opening the issue! I lack the time to do this atm; let's see if one of the porters can help. @bulasevich @snazarkin ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/12778#issuecomment-1493703283 From stuefe at openjdk.org Mon Apr 3 06:13:58 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 3 Apr 2023 06:13:58 GMT Subject: RFR: 8301995: Move invokedynamic resolution information out of ConstantPoolCacheEntry [v16] In-Reply-To: <2QX2qfq-D7XFxp-deWNW7JyrZRMikCDt9LLe8EyQKx8=.1dc3d0be-b6f4-4651-a6d5-1b4aced23ba9@github.com> References: <5YPjVZsQAVVL9PHaGu7Mc7kNE0WvPrsiCubKSGzKxvk=.78e8f8fb-1005-4bd7-9ad1-d1dd3aacbe04@github.com> <2QX2qfq-D7XFxp-deWNW7JyrZRMikCDt9LLe8EyQKx8=.1dc3d0be-b6f4-4651-a6d5-1b4aced23ba9@github.com> Message-ID: On Mon, 3 Apr 2023 05:57:18 GMT, Thomas Stuefe wrote: > > I wonder about the explicit exclusion of arm. Every other CPU seems to be taken care of, even those Oracle does not maintain. Just curious, was there a special reason for excluding arm? > > There is no special reason ARM32 was excluded other than the fact no porter has picked it up yet. Fortunately I was able to get in contact with porters for the other platforms, but nobody took on the ARM port until now. Thank you for opening the issue! For future reference, we maintain a list of people working on ports: https://wiki.openjdk.org/display/HotSpot/Ports and we do have a mailing list for porters as well: porters-dev at openjdk.org . This makes it easier to find out who to contact. Cheers, Thomas ------------- PR Comment: https://git.openjdk.org/jdk/pull/12778#issuecomment-1493717962 From jbechberger at openjdk.org Mon Apr 3 08:29:55 2023 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Mon, 3 Apr 2023 08:29:55 GMT Subject: RFR: 8304725: AsyncGetCallTrace can cause SIGBUS on M1 [v5] In-Reply-To: References: Message-ID: > Fixes the issue by transitioning the thread into the WXWrite mode while walking the stack in AsyncGetCallTrace. > > Tested on my M1 mac. Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision: - Fix fix - Fix minor issues ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13144/files - new: https://git.openjdk.org/jdk/pull/13144/files/1973e005..6f1108ed Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13144&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13144&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13144.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13144/head:pull/13144 PR: https://git.openjdk.org/jdk/pull/13144 From jbechberger at openjdk.org Mon Apr 3 08:29:55 2023 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Mon, 3 Apr 2023 08:29:55 GMT Subject: RFR: 8304725: AsyncGetCallTrace can cause SIGBUS on M1 [v4] In-Reply-To: References: Message-ID: On Fri, 24 Mar 2023 10:35:36 GMT, Johannes Bechberger wrote: >> Fixes the issue by transitioning the thread into the WXWrite mode while walking the stack in AsyncGetCallTrace. >> >> Tested on my M1 mac. > > Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision: > > - Remove misc lines > - Disable caching in ASGCT Thanks for the review, I fixed the issues. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13144#issuecomment-1493893275 From fyang at openjdk.org Mon Apr 3 08:40:58 2023 From: fyang at openjdk.org (Fei Yang) Date: Mon, 3 Apr 2023 08:40:58 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v51] In-Reply-To: References: Message-ID: On Sun, 2 Apr 2023 21:41:47 GMT, Roman Kennke wrote: >> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). >> >> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. >> >> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal protocols. >> >> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare. >> >> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. >> >> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. >> >> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. >> >> This change enables to simplify (and speed-up!) a lot of code: >> >> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. >> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR >> >> >> Testing: >> - [x] tier1 x86_64 x aarch64 x +UseFastLocking >> - [x] tier2 x86_64 x aarch64 x +UseFastLocking >> - [x] tier3 x86_64 x aarch64 x +UseFastLocking >> - [x] tier4 x86_64 x aarch64 x +UseFastLocking >> - [x] tier1 x86_64 x aarch64 x -UseFastLocking >> - [x] tier2 x86_64 x aarch64 x -UseFastLocking >> - [x] tier3 x86_64 x aarch64 x -UseFastLocking >> - [x] tier4 x86_64 x aarch64 x -UseFastLocking >> - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet >> >> ### Performance >> >> #### Simple Microbenchmark >> >> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops. >> >> | | x86_64 | aarch64 | >> | -- | -- | -- | >> | -UseFastLocking | 20.651 | 20.764 | >> | +UseFastLocking | 18.896 | 18.908 | >> >> >> #### Renaissance >> >> ? | x86_64 | ? | ? | ? | aarch64 | ? | ? >> -- | -- | -- | -- | -- | -- | -- | -- >> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? >> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% >> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21% >> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% >> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% >> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% >> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% >> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%% >> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% >> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% >> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% >> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% >> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34% >> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% >> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% >> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% >> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% >> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% >> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% >> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% >> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% >> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% > > Roman Kennke has updated the pull request incrementally with four additional commits since the last revision: > > - Replace UseFastLocking with LockingMode flag > - Reject +UseFastLocking on unsupported platforms > - Merge remote-tracking branch 'tstuefe/ARM-port-8291555' into JDK-8291555-v2 > - Arm port src/hotspot/share/runtime/javaThread.cpp line 993: > 991: > 992: bool JavaThread::is_lock_owned(address adr) const { > 993: assert(!LockingMode != 2, "should not be called with new lightweight locking"); Looks like there is a typo here. I think this should be: assert(LockingMode != 2, "should not be called with new lightweight locking"); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1155652106 From sspitsyn at openjdk.org Mon Apr 3 09:04:44 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 3 Apr 2023 09:04:44 GMT Subject: RFR: 8257967: JFR: Events for loaded agents [v15] In-Reply-To: <5cFyTNQZjfRp6VlzOqkgdwhoSGaX92KNL3EZlv-NrpY=.fae84f7f-f1d4-4354-a123-33ab97928dcf@github.com> References: <5cFyTNQZjfRp6VlzOqkgdwhoSGaX92KNL3EZlv-NrpY=.fae84f7f-f1d4-4354-a123-33ab97928dcf@github.com> Message-ID: On Fri, 31 Mar 2023 11:18:23 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> We are adding support to let JFR report on Agents. >> >> #### Design >> >> An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize. >> >> A JavaAgent is an agent written in the Java programming language, using the APIs in the package [java.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html) >> >> A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services. >> >> To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples: >> >> // Command line >> jdk.JavaAgent { >> startTime = 12:31:19.789 (2023-03-08) >> name = "JavaAgent.jar" >> options = "foo=bar" >> dynamic = false >> initializationTime = 12:31:15.574 (2023-03-08) >> initializationDuration = 172 ms >> } >> >> // Dynamic load >> jdk.JavaAgent { >> startTime = 12:31:31.158 (2023-03-08) >> name = "JavaAgent.jar" >> options = "bar=baz" >> dynamic = true >> initializationTime = 12:31:31.037 (2023-03-08) >> initializationDuration = 64,1 ms >> } >> >> The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents. >> >> For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar. >> >> The "dynamic" field denotes if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true) >> >> "initializationTime" is the timestamp the JVM invoked the initialization method, and "initializationDuration" is the duration of executing the initialization method. >> >> "startTime" represents the time the JFR framework issued the periodic event; hence "initializationTime" will be earlier than "startTime". >> >> An agent can also be written in a native programming language using the [JVM Tools Interface (JVMTI)](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file. >> >> To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example: >> >> jdk.NativeAgent { >> startTime = 12:31:40.398 (2023-03-08) >> name = "jdwp" >> options = "transport=dt_socket,server=y,address=any,onjcmd=y" >> dynamic = false >> initializationTime = 12:31:36.142 (2023-03-08) >> initializationDuration = 0,00184 ms >> path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll" >> } >> >> The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported. >> >> The initialization of a native agent is performed by invoking an agent-specified callback routine. The "initializationTime" is when the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationDuration" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationDuration" will be 0. If the agent is loaded dynamically, "initializationDuration" is the time taken to execute the Agent_OnAttach callback. >> >> #### Implementation >> >> There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization ? as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before. >> >> Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize. >> >> When implementing this capability, it was necessary to refactor the code used to represent agents, AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp. >> >> The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp. >> >> The previous two lists that maintained "agents" (JVMTI) and "libraries" (Xrun) were not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced. >> >> Testing: jdk_jfr, tier 1 - 6 >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: > > fixes src/hotspot/share/prims/agentList.cpp line 204: > 202: > 203: // Invokes Agent_OnAttach for agents loaded dynamically during runtime. > 204: jint AgentList::load_agent(const char* agent_name, const char* absParam, I feel that it is better to keep the original function name "load_agent_library". As you listed there two kinds of agents: Java and Native. The function name give a hint it is native agent. Also, it is better to avoid changes that aren't really necessary. src/hotspot/share/prims/jvmtiExport.cpp line 694: > 692: } > 693: > 694: // Lookup an agent from an JvmtiEnv.Return agent only if it is not yet initialized. A space is missed after the first dot. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12923#discussion_r1155051226 PR Review Comment: https://git.openjdk.org/jdk/pull/12923#discussion_r1155050084 From rkennke at openjdk.org Mon Apr 3 11:05:41 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 3 Apr 2023 11:05:41 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v52] In-Reply-To: References: Message-ID: <7jOmtn6ogSPGZYMvJmV7yPWUgR5sBImxQaf2F8vQZBc=.6f4cad6d-058b-48a5-a943-ff2f18f90d3a@github.com> > This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). > > What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. > > This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p rotocols. > > The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare. > > In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. > > One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. > > As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. > > This change enables to simplify (and speed-up!) a lot of code: > > - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. > - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR > > > Testing: > - [x] tier1 x86_64 x aarch64 x +UseFastLocking > - [x] tier2 x86_64 x aarch64 x +UseFastLocking > - [x] tier3 x86_64 x aarch64 x +UseFastLocking > - [x] tier4 x86_64 x aarch64 x +UseFastLocking > - [x] tier1 x86_64 x aarch64 x -UseFastLocking > - [x] tier2 x86_64 x aarch64 x -UseFastLocking > - [x] tier3 x86_64 x aarch64 x -UseFastLocking > - [x] tier4 x86_64 x aarch64 x -UseFastLocking > - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet > > ### Performance > > #### Simple Microbenchmark > > The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops. > > | | x86_64 | aarch64 | > | -- | -- | -- | > | -UseFastLocking | 20.651 | 20.764 | > | +UseFastLocking | 18.896 | 18.908 | > > > #### Renaissance > > ? | x86_64 | ? | ? | ? | aarch64 | ? | ? > -- | -- | -- | -- | -- | -- | -- | -- > ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? > AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% > Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21% > Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% > ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% > GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% > LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% > MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%% > NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% > PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% > FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% > FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% > ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34% > Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% > RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% > Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% > ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% > FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% > FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Fix typo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10907/files - new: https://git.openjdk.org/jdk/pull/10907/files/1348f3bc..13c84b5c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=51 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=50-51 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10907.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/10907/head:pull/10907 PR: https://git.openjdk.org/jdk/pull/10907 From rkennke at openjdk.org Mon Apr 3 12:31:40 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 3 Apr 2023 12:31:40 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v51] In-Reply-To: References: Message-ID: On Mon, 3 Apr 2023 08:37:51 GMT, Fei Yang wrote: > Looks like there is a typo here. I think this should be: > > ``` > assert(LockingMode != 2, "should not be called with new lightweight locking"); > ``` Thanks for catching this! I pushed a fix. You might want to try the riscv port again, I have made some changes that might have broken it. Also, you might want to compare it again with aarch64 (or x86_64), I have done a bunch of changes and improvements that you might want to adopt. Thanks! Roman ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1155894717 From mgronlun at openjdk.org Mon Apr 3 13:02:15 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 3 Apr 2023 13:02:15 GMT Subject: RFR: 8257967: JFR: Events for loaded agents [v15] In-Reply-To: References: <5cFyTNQZjfRp6VlzOqkgdwhoSGaX92KNL3EZlv-NrpY=.fae84f7f-f1d4-4354-a123-33ab97928dcf@github.com> Message-ID: On Sat, 1 Apr 2023 03:47:26 GMT, Serguei Spitsyn wrote: >> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: >> >> fixes > > src/hotspot/share/prims/agentList.cpp line 204: > >> 202: >> 203: // Invokes Agent_OnAttach for agents loaded dynamically during runtime. >> 204: jint AgentList::load_agent(const char* agent_name, const char* absParam, > > I feel that it is better to keep the original function name "load_agent_library". As you listed there two kinds of agents: Java and Native. The function name give a hint it is native agent. Also, it is better to avoid changes that aren't really necessary. I changed the names because I found it very hard to understand what the old names represented: "AgentLibrary" vs "Library"? "add_init_agent" vs "add_instrumentation_agent", or even "add_loaded_agent"? Also a bit confusing that "load_agent_library" would also include statically linked agents - no library is loaded there. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12923#discussion_r1155930115 From pchilanomate at openjdk.org Mon Apr 3 16:45:08 2023 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 3 Apr 2023 16:45:08 GMT Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324 [v13] In-Reply-To: References: <07UH4ks6EGmxIt5mZ3dNPi0YaC8u-xhBNF-Ao9iOAcA=.378b96b5-19e0-4d0a-95d8-83fd44f39024@github.com> Message-ID: On Fri, 31 Mar 2023 05:13:04 GMT, Serguei Spitsyn wrote: >> So the race I am talking about is between the main thread running finishThreads() and the launcher thread running startThreads(). The main thread could execute finishThreads() before the launcher executes startThreads(). If you comment out the two first sleeps in run_test_cycle() you can actually see the issue. Again, given that the sleeps are there it is an unlikely scheduling, but if we want to avoid depending on timing we can add that extra synchronization. > > Sorry, I understood you incorrectly. You are right, there is this kind of race here. > I've rearranges this area a little bit, and hope, it is cleaner now. > Now, both `startVirtualThreads()` and `finishVirtualThreads()` are invoked on the main thread, so they do not need to be synchronized any more. Also, the call to `ensureReady()` are moved to `finishVirtualThreads()` right before the call to `letFinish()`. Fix looks good, thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1156204813 From sspitsyn at openjdk.org Mon Apr 3 18:17:13 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 3 Apr 2023 18:17:13 GMT Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324 [v16] In-Reply-To: References: Message-ID: > The fix is to enable virtual threads support for late binding JVMTI agents. > The fix includes: > - New function `JvmtiEnvBase::enable_virtual_threads_notify_jvmti()` which does enabling JVMTI VTMS transition notifications in case of agent loaded into running VM. This function executes a VM operation counting VTMS transition bits in all `JavaThread`'s to correctly set the static counter `_VTMS_transition_count` needed for VTMS transition protocol. > - New function `JvmtiEnvBase::disable_virtual_threads_notify_jvmti()` which is needed for testing. It is used by the `WhiteBox` API. > - New WhiteBox function `WB_SetVirtualThreadsNotifyJvmtiMode(JNIEnv* env, jobject wb, jboolean enable)` needed for testing of this update. > - New regression test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest` > > Testing: > - New test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest` > - The originally failed tests are expected to pass now: > `runtime/vthread/RedefineClass.java` > `runtime/vthread/TestObjectAllocationSampleEvent.java` > - In progress: Run the tiers 1-6 to make sure there are no regression. Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: set java_lang_Thread::is_in_VTMS_transition bit when notifyJvmti is off ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13133/files - new: https://git.openjdk.org/jdk/pull/13133/files/c55b6b38..d38e53fd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13133&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13133&range=14-15 Stats: 21 lines in 5 files changed: 13 ins; 5 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13133.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13133/head:pull/13133 PR: https://git.openjdk.org/jdk/pull/13133 From cjplummer at openjdk.org Mon Apr 3 19:01:59 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 3 Apr 2023 19:01:59 GMT Subject: RFR: 8305421: Work around JDK-8305420 in CDSJDITest.java In-Reply-To: References: Message-ID: On Sun, 2 Apr 2023 22:11:40 GMT, Ioi Lam wrote: > Please review this trivial work-around that removes logging that would trigger [JDK-8305420](https://bugs.openjdk.org/browse/JDK-8305420). > > I also fixed an incorrect parameter in the `executeAndLog()` call, which caused the dumping process's stdout/stderr to be logged in the wrong file. Change looks good. Per https://bugs.openjdk.org/browse/JDK-8173304, this is a known issue and tests need to avoid having the JVM produce too much output before the debugger connection is setup. ------------- Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13283#pullrequestreview-1369626298 From cjplummer at openjdk.org Mon Apr 3 19:02:57 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 3 Apr 2023 19:02:57 GMT Subject: RFR: 8305237: CompilerDirectives DCmds permissions correction In-Reply-To: References: Message-ID: On Fri, 31 Mar 2023 08:24:19 GMT, Kevin Walls wrote: > The Permissions in DCmds relate to remote usage over JMX. > "monitor" is generally for reading information, and "control" is generally for making changes. > The DCmds for changing compiler directives should have "control" as the required permission. > > Tests in test/hotspot/jtreg/serviceability/dcmd/compiler and test/hotspot/jtreg/compiler/compilercontrol still pass with this change. Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13262#pullrequestreview-1369628119 From sspitsyn at openjdk.org Mon Apr 3 19:25:11 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 3 Apr 2023 19:25:11 GMT Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324 [v9] In-Reply-To: References: <5SO5rUZwV3SQ2w7t7mOwmP1jXjUVgl4g7NiT7cKi9LU=.355314c8-03ec-4a1e-80d8-e70e98868ecc@github.com> Message-ID: On Wed, 29 Mar 2023 22:15:35 GMT, Patricio Chilano Mateo wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> review: updated correction of jt->jvmti_thread_state() links in VM_SetNotifyJvmtiEventsMode > > Hi Serguei, > > I took a look at the patch and looks good to me. I have a couple of comments though. > > Thanks, > Patricio @pchilano I've pushed an update where the VTMS transition bit in the VirtualThread object is laways/unconditionally set. I do not see any performance impact with this. Please, let me know about your opinion. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13133#issuecomment-1494852395 From cjplummer at openjdk.org Mon Apr 3 19:34:57 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 3 Apr 2023 19:34:57 GMT Subject: RFR: 8305341: Alignment outside of HotSpot should be enforced by alignas instead of compiler specific attributes In-Reply-To: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com> References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com> Message-ID: On Fri, 31 Mar 2023 06:07:39 GMT, Julian Waters wrote: > C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements > I don't think I can touch the freetype code since I think it's an external library that was imported. HotSpot requires a special review for changes like this, so it's not done here, but instead at #11431 (Which has dried up for a long time now, would be great if someone finally looked at that PR...) Ok. What about the globalDefinitions_visCPP.hpp reference? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1494864710 From cjplummer at openjdk.org Mon Apr 3 19:36:56 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 3 Apr 2023 19:36:56 GMT Subject: RFR: 8305209: JDWP exit error AGENT_ERROR_INVALID_THREAD(203): missing entry in running thread table In-Reply-To: References: Message-ID: <0mEuiqrdIHvfsxTn1naqyNvlKq9GiaOOhSRejgSQYRE=.e605e6c2-ac07-4583-95b5-2055b6fa7081@github.com> On Thu, 30 Mar 2023 16:03:05 GMT, Chris Plummer wrote: > The real purpose of this PR is to add virtual thread support to ThreadMemoryLeakTest.java, but this exposed bugs in both the debug agent and in TestScaffold, so those are being fixed also (and the debug agent bug is the CR being used). > > The debug agent bug is due to a race condition during VM exit. The VM is in the process of shutting down. The debug agent has already disabled JVMTI callbacks and has sent the VMDeathEvent. At this point in time there are also threads exiting that the debug agent knows about, but it will not get a ThreadEndEvent for because of the callbacks being disabled. Thus these threads remain in the debug agent's list of known threads, even though they have exited. The debuggee receives the VMDeathEvent and does a VM.resume(). During the debug agent's handing of the VM.Resume command, it iterates over all known threads and needs to map each to its ThreadNode so it can be resumed, and this mapping requires accessing the JVMTI TLS for the thread. The problem is some of the threads may have exited already, and therefore no longer have TLS. This results in the assert in the debug agent. This debug agent issue was already addressed for platform threads, but not for virtual threads, which is why we started seeing this issue when this test was modified. The fix is to just replicate what is done for platform threads for virtual threads also. > > The TestScaffold bug is that if the debuggee crashes/asserts, this is likely to go unnoticed, especially if it happens during VM exit (and the test essentially has already completed). Because of this TestScaffold bug, the debug agent bug above did not result in a test failure. After fixing TestScaffold to check the exitCode of the debuggee process, the test started to appropriately fail until the debug agent was fixed. > > One other thing to point out is the OOME issue I started getting frequently when testing with virtual threads. Since virtual threads are created at a much higher rate than platform threads, their creation started to overwhelm the debugger (actually the JDI implementation). There is already a mechanism in place to do a VM.HoldEvents if JDI has queue up 10,000 events. The problem is that events are coming in so fast that even after doing the VM.HoldEvents, the number of queued events continues to go up for a while, and sometimes reaches 30,000 or more. This raises the peak memory usage of the test quite a bit. Since the test purposely uses a small heap so a memory leak is quickly and reliably detected, the large queue often results in an OOME. Because of this I make virtual threads sleep for 100ms instead of 50ms to slow down their creation, and this resolved the issue. > > I tested by running all of test/jdk/com/sun/jdi 25 times on each platform with and without virtual thread testing enabled. Ping! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13246#issuecomment-1494866475 From pchilanomate at openjdk.org Mon Apr 3 20:04:09 2023 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 3 Apr 2023 20:04:09 GMT Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324 [v16] In-Reply-To: References: Message-ID: On Mon, 3 Apr 2023 18:17:13 GMT, Serguei Spitsyn wrote: >> The fix is to enable virtual threads support for late binding JVMTI agents. >> The fix includes: >> - New function `JvmtiEnvBase::enable_virtual_threads_notify_jvmti()` which does enabling JVMTI VTMS transition notifications in case of agent loaded into running VM. This function executes a VM operation counting VTMS transition bits in all `JavaThread`'s to correctly set the static counter `_VTMS_transition_count` needed for VTMS transition protocol. >> - New function `JvmtiEnvBase::disable_virtual_threads_notify_jvmti()` which is needed for testing. It is used by the `WhiteBox` API. >> - New WhiteBox function `WB_SetVirtualThreadsNotifyJvmtiMode(JNIEnv* env, jobject wb, jboolean enable)` needed for testing of this update. >> - New regression test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest` >> >> Testing: >> - New test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest` >> - The originally failed tests are expected to pass now: >> `runtime/vthread/RedefineClass.java` >> `runtime/vthread/TestObjectAllocationSampleEvent.java` >> - In progress: Run the tiers 1-6 to make sure there are no regression. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > set java_lang_Thread::is_in_VTMS_transition bit when notifyJvmti is off Marked as reviewed by pchilanomate (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13133#pullrequestreview-1369718538 From pchilanomate at openjdk.org Mon Apr 3 20:04:15 2023 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 3 Apr 2023 20:04:15 GMT Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324 [v9] In-Reply-To: References: <5SO5rUZwV3SQ2w7t7mOwmP1jXjUVgl4g7NiT7cKi9LU=.355314c8-03ec-4a1e-80d8-e70e98868ecc@github.com> Message-ID: On Wed, 29 Mar 2023 22:15:35 GMT, Patricio Chilano Mateo wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> review: updated correction of jt->jvmti_thread_state() links in VM_SetNotifyJvmtiEventsMode > > Hi Serguei, > > I took a look at the patch and looks good to me. I have a couple of comments though. > > Thanks, > Patricio > @pchilano I've pushed an update where the VTMS transition bit in the VirtualThread object is laways/unconditionally set. I do not see any performance impact with this. Please, let me know about your opinion. > Latest changes look good to me. Thanks Serguei! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13133#issuecomment-1494901707 From sspitsyn at openjdk.org Mon Apr 3 21:30:13 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 3 Apr 2023 21:30:13 GMT Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324 [v16] In-Reply-To: References: Message-ID: <5_xt-s7TgWtBNoLMLIEMEfkf6WZbbsw2HTtDgJx3sbY=.6d71e9ff-2ca5-42c1-a509-5d20ff5ca843@github.com> On Mon, 3 Apr 2023 18:17:13 GMT, Serguei Spitsyn wrote: >> The fix is to enable virtual threads support for late binding JVMTI agents. >> The fix includes: >> - New function `JvmtiEnvBase::enable_virtual_threads_notify_jvmti()` which does enabling JVMTI VTMS transition notifications in case of agent loaded into running VM. This function executes a VM operation counting VTMS transition bits in all `JavaThread`'s to correctly set the static counter `_VTMS_transition_count` needed for VTMS transition protocol. >> - New function `JvmtiEnvBase::disable_virtual_threads_notify_jvmti()` which is needed for testing. It is used by the `WhiteBox` API. >> - New WhiteBox function `WB_SetVirtualThreadsNotifyJvmtiMode(JNIEnv* env, jobject wb, jboolean enable)` needed for testing of this update. >> - New regression test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest` >> >> Testing: >> - New test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest` >> - The originally failed tests are expected to pass now: >> `runtime/vthread/RedefineClass.java` >> `runtime/vthread/TestObjectAllocationSampleEvent.java` >> - In progress: Run the tiers 1-6 to make sure there are no regression. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > set java_lang_Thread::is_in_VTMS_transition bit when notifyJvmti is off Thank you for review, Patricio! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13133#issuecomment-1495003990 From iklam at openjdk.org Mon Apr 3 21:35:52 2023 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 3 Apr 2023 21:35:52 GMT Subject: RFR: 8305421: Work around JDK-8305420 in CDSJDITest.java In-Reply-To: References: Message-ID: On Mon, 3 Apr 2023 18:59:03 GMT, Chris Plummer wrote: >> Please review this trivial work-around that removes logging that would trigger [JDK-8305420](https://bugs.openjdk.org/browse/JDK-8305420). >> >> I also fixed an incorrect parameter in the `executeAndLog()` call, which caused the dumping process's stdout/stderr to be logged in the wrong file. > > Change looks good. Per https://bugs.openjdk.org/browse/JDK-8173304, this is a known issue and tests need to avoid having the JVM produce too much output before the debugger connection is setup. Thanks @plummercj for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13283#issuecomment-1495013582 From sspitsyn at openjdk.org Mon Apr 3 21:57:46 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 3 Apr 2023 21:57:46 GMT Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324 [v17] In-Reply-To: References: Message-ID: > The fix is to enable virtual threads support for late binding JVMTI agents. > The fix includes: > - New function `JvmtiEnvBase::enable_virtual_threads_notify_jvmti()` which does enabling JVMTI VTMS transition notifications in case of agent loaded into running VM. This function executes a VM operation counting VTMS transition bits in all `JavaThread`'s to correctly set the static counter `_VTMS_transition_count` needed for VTMS transition protocol. > - New function `JvmtiEnvBase::disable_virtual_threads_notify_jvmti()` which is needed for testing. It is used by the `WhiteBox` API. > - New WhiteBox function `WB_SetVirtualThreadsNotifyJvmtiMode(JNIEnv* env, jobject wb, jboolean enable)` needed for testing of this update. > - New regression test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest` > > Testing: > - New test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest` > - The originally failed tests are expected to pass now: > `runtime/vthread/RedefineClass.java` > `runtime/vthread/TestObjectAllocationSampleEvent.java` > - In progress: Run the tiers 1-6 to make sure there are no regression. Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 20 additional commits since the last revision: - Merge - set java_lang_Thread::is_in_VTMS_transition bit when notifyJvmti is off - minor simplification in ToggleNotifyJvmtiTest.java - review: addressed next round of review suggestions - review: tweak in count_transitions_and_correct_jvmti_thread_states - review: minor tweak in test - one more review round fixes - refactored jt->jvmti_thread_state() corrections in VM_SetNotifyJvmtiEventsMode - review: updated correction of jt->jvmti_thread_state() links in VM_SetNotifyJvmtiEventsMode - fixed trailing spaces in two files - ... and 10 more: https://git.openjdk.org/jdk/compare/5c31a0bf...b5624011 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13133/files - new: https://git.openjdk.org/jdk/pull/13133/files/d38e53fd..b5624011 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13133&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13133&range=15-16 Stats: 27373 lines in 728 files changed: 13694 ins; 9290 del; 4389 mod Patch: https://git.openjdk.org/jdk/pull/13133.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13133/head:pull/13133 PR: https://git.openjdk.org/jdk/pull/13133 From iklam at openjdk.org Mon Apr 3 22:33:07 2023 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 3 Apr 2023 22:33:07 GMT Subject: Integrated: 8305421: Work around JDK-8305420 in CDSJDITest.java In-Reply-To: References: Message-ID: On Sun, 2 Apr 2023 22:11:40 GMT, Ioi Lam wrote: > Please review this trivial work-around that removes logging that would trigger [JDK-8305420](https://bugs.openjdk.org/browse/JDK-8305420). > > I also fixed an incorrect parameter in the `executeAndLog()` call, which caused the dumping process's stdout/stderr to be logged in the wrong file. This pull request has now been integrated. Changeset: 9ce5fdc9 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/9ce5fdc96262ac80c5a2ac2d51a149408d3d727a Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod 8305421: Work around JDK-8305420 in CDSJDITest.java Reviewed-by: cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/13283 From sspitsyn at openjdk.org Tue Apr 4 00:50:41 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 4 Apr 2023 00:50:41 GMT Subject: Integrated: 8297286: runtime/vthread tests crashing after JDK-8296324 In-Reply-To: References: Message-ID: On Wed, 22 Mar 2023 02:12:12 GMT, Serguei Spitsyn wrote: > The fix is to enable virtual threads support for late binding JVMTI agents. > The fix includes: > - New function `JvmtiEnvBase::enable_virtual_threads_notify_jvmti()` which does enabling JVMTI VTMS transition notifications in case of agent loaded into running VM. This function executes a VM operation counting VTMS transition bits in all `JavaThread`'s to correctly set the static counter `_VTMS_transition_count` needed for VTMS transition protocol. > - New function `JvmtiEnvBase::disable_virtual_threads_notify_jvmti()` which is needed for testing. It is used by the `WhiteBox` API. > - New WhiteBox function `WB_SetVirtualThreadsNotifyJvmtiMode(JNIEnv* env, jobject wb, jboolean enable)` needed for testing of this update. > - New regression test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest` > > Testing: > - New test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest` > - The originally failed tests are expected to pass now: > `runtime/vthread/RedefineClass.java` > `runtime/vthread/TestObjectAllocationSampleEvent.java` > - In progress: Run the tiers 1-6 to make sure there are no regression. This pull request has now been integrated. Changeset: a1a9ec6e Author: Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/a1a9ec6e46b70d5436711f89f4bf603ebacc8060 Stats: 574 lines in 15 files changed: 554 ins; 9 del; 11 mod 8297286: runtime/vthread tests crashing after JDK-8296324 Reviewed-by: lmesnik, pchilanomate, cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/13133 From lmesnik at openjdk.org Tue Apr 4 03:26:00 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 4 Apr 2023 03:26:00 GMT Subject: RFR: 8305511: Remove ignore from com/sun/jdi/PopAndInvokeTest.java In-Reply-To: References: Message-ID: On Tue, 4 Apr 2023 03:18:37 GMT, Leonid Mesnik wrote: > Test com/sun/jdi/PopAndInvokeTest.java has > @ignore 6951287 > bug 6951287 is closed as a dup for 6417053 which is closed as not reproduced. The test pass. If it start failing in CI it is needed to file a new bug and problemlist test. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13317#issuecomment-1495289747 From lmesnik at openjdk.org Tue Apr 4 03:25:59 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 4 Apr 2023 03:25:59 GMT Subject: RFR: 8305511: Remove ignore from com/sun/jdi/PopAndInvokeTest.java Message-ID: Test com/sun/jdi/PopAndInvokeTest.java has @ignore 6951287 bug 6951287 is closed as a dup for 6417053 which is closed as not reproduced. ------------- Commit messages: - @ignore removed Changes: https://git.openjdk.org/jdk/pull/13317/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13317&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8305511 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13317.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13317/head:pull/13317 PR: https://git.openjdk.org/jdk/pull/13317 From cjplummer at openjdk.org Tue Apr 4 04:20:05 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 4 Apr 2023 04:20:05 GMT Subject: RFR: 8305511: Remove ignore from com/sun/jdi/PopAndInvokeTest.java In-Reply-To: References: Message-ID: <4CvzhtJS8YL-Mt0i7wQmr9SwkWbpxbkoFwaZ34h4Tuc=.b402af06-7142-4054-8edf-23f2b67353fd@github.com> On Tue, 4 Apr 2023 03:18:37 GMT, Leonid Mesnik wrote: > Test com/sun/jdi/PopAndInvokeTest.java has > @ignore 6951287 > bug 6951287 is closed as a dup for 6417053 which is closed as not reproduced. Looks good, and trivial. ------------- Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13317#pullrequestreview-1370166753 From dholmes at openjdk.org Tue Apr 4 04:54:08 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 4 Apr 2023 04:54:08 GMT Subject: RFR: 8304725: AsyncGetCallTrace can cause SIGBUS on M1 [v5] In-Reply-To: References: Message-ID: On Mon, 3 Apr 2023 08:29:55 GMT, Johannes Bechberger wrote: >> Fixes the issue by transitioning the thread into the WXWrite mode while walking the stack in AsyncGetCallTrace. >> >> Tested on my M1 mac. > > Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision: > > - Fix fix > - Fix minor issues Can you update the description please to reflect the final approach. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13144#issuecomment-1495340463 From jwaters at openjdk.org Tue Apr 4 05:19:15 2023 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 4 Apr 2023 05:19:15 GMT Subject: RFR: 8305341: Alignment outside of HotSpot should be enforced by alignas instead of compiler specific attributes In-Reply-To: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com> References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com> Message-ID: On Fri, 31 Mar 2023 06:07:39 GMT, Julian Waters wrote: > C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements globalDefinitions_visCPP.hpp (and the corresponding globalDefinitions file for gcc based compilers) are both hotspot code, which require special review and are done in another Pull Request: https://github.com/openjdk/jdk/pull/11431 It would be great if Reviewers would take a look at that PR though... ------------- PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1495357119 From cjplummer at openjdk.org Tue Apr 4 05:33:03 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 4 Apr 2023 05:33:03 GMT Subject: RFR: 8305341: Alignment outside of HotSpot should be enforced by alignas instead of compiler specific attributes In-Reply-To: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com> References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com> Message-ID: On Fri, 31 Mar 2023 06:07:39 GMT, Julian Waters wrote: > C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements I'm not sure what you mean by hotspot requiring a special review, but serviceability code does require two reviewers just like hotspot does. Also, you don't need to split the PR because of that. If you get one person to review the jdk changes and 2 to review the hostpot/svc changes, then you are good to go. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1495369012 From jiefu at openjdk.org Tue Apr 4 06:16:13 2023 From: jiefu at openjdk.org (Jie Fu) Date: Tue, 4 Apr 2023 06:16:13 GMT Subject: RFR: 8305520: ToggleNotifyJvmtiTest.java fails with release VMs Message-ID: Add `-XX:+UnlockDiagnosticVMOptions` to fix the failure with release VMs. Thanks. ------------- Commit messages: - 8305520: ToggleNotifyJvmtiTest.java fails with release VMs Changes: https://git.openjdk.org/jdk/pull/13318/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13318&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8305520 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13318.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13318/head:pull/13318 PR: https://git.openjdk.org/jdk/pull/13318 From dholmes at openjdk.org Tue Apr 4 06:49:49 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 4 Apr 2023 06:49:49 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v52] In-Reply-To: <7jOmtn6ogSPGZYMvJmV7yPWUgR5sBImxQaf2F8vQZBc=.6f4cad6d-058b-48a5-a943-ff2f18f90d3a@github.com> References: <7jOmtn6ogSPGZYMvJmV7yPWUgR5sBImxQaf2F8vQZBc=.6f4cad6d-058b-48a5-a943-ff2f18f90d3a@github.com> Message-ID: On Mon, 3 Apr 2023 11:05:41 GMT, Roman Kennke wrote: >> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). >> >> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. >> >> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal protocols. >> >> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare. >> >> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. >> >> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. >> >> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. >> >> This change enables to simplify (and speed-up!) a lot of code: >> >> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. >> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR >> >> Also, and I might be mistaken here, this new lightweight locking would make synchronized work better with Loom: Because the lock-records are no longer scattered across the stack, but instead are densely packed into the lock-stack, it should be easy for a vthread to save its lock-stack upon unmounting and restore it when re-mounting. However, I am not sure about this, and this PR does not attempt to implement that support. >> >> Testing: >> - [x] tier1 x86_64 x aarch64 x +UseFastLocking >> - [x] tier2 x86_64 x aarch64 x +UseFastLocking >> - [x] tier3 x86_64 x aarch64 x +UseFastLocking >> - [x] tier4 x86_64 x aarch64 x +UseFastLocking >> - [x] tier1 x86_64 x aarch64 x -UseFastLocking >> - [x] tier2 x86_64 x aarch64 x -UseFastLocking >> - [x] tier3 x86_64 x aarch64 x -UseFastLocking >> - [x] tier4 x86_64 x aarch64 x -UseFastLocking >> - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet >> >> ### Performance >> >> #### Simple Microbenchmark >> >> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops. >> >> | | x86_64 | aarch64 | >> | -- | -- | -- | >> | -UseFastLocking | 20.651 | 20.764 | >> | +UseFastLocking | 18.896 | 18.908 | >> >> >> #### Renaissance >> >> ? | x86_64 | ? | ? | ? | aarch64 | ? | ? >> -- | -- | -- | -- | -- | -- | -- | -- >> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? >> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% >> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21% >> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% >> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% >> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% >> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% >> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%% >> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% >> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% >> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% >> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% >> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34% >> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% >> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% >> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% >> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% >> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% >> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% >> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% >> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% >> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo Thanks for previous updates - much appreciated. Another round of comments and some concerns. One thing I can't quite get clear in my head is whether the small window where an object's monitor is inflated and the object is still in the thread's lock-stack, could cause an issue for any external observers trying to determine the object's locked state. src/hotspot/cpu/x86/macroAssembler_x86.cpp line 9739: > 9737: get_thread(thread); > 9738: #endif > 9739: subl(Address(thread, JavaThread::lock_stack_top_offset()), oopSize); Is this code used for monitorexit or only returning from synchronized methods? If used for monitorexit there is no requirement that the monitor being unlocked was the last monitor locked. Balanced locking only requires the locks and unlocks are matched, not that they are perfectly nested ie. this is valid in bytecode: monitorenter A monitorenter B monitorexit A monitorExit B src/hotspot/share/runtime/javaThread.cpp line 1388: > 1386: } > 1387: > 1388: if (!UseHeavyMonitors && LockingMode == 2) { Given UseHeavyMonitors implies LockingMode==0 it suffices to just check LockingMode==2 here. src/hotspot/share/runtime/lockStack.inline.hpp line 53: > 51: if (!thread->is_Java_thread()) { > 52: return false; > 53: } I'm still unclear how we can have non-JavaThreads here. Only JavaThreads can lock object monitors. src/hotspot/share/runtime/synchronizer.cpp line 1283: > 1281: inf->set_owner_from_anonymous(current); > 1282: assert(current->is_Java_thread(), "must be Java thread"); > 1283: JavaThread::cast(current)->lock_stack().remove(object); JavaThread::cast already asserts it is a JavaThread. src/hotspot/share/runtime/synchronizer.cpp line 1314: > 1312: LogStreamHandle(Trace, monitorinflation) lsh; > 1313: if (mark.is_fast_locked()) { > 1314: assert(LockingMode == 2, "can only happen with new lightweight locking"); I'd rather see this entire case guarded by "`if (LockingMode ==2)`" and have `is_fast_locked()` assert if called in any other mode. Similarly for the stack-locked case below. src/hotspot/share/runtime/synchronizer.cpp line 1330: > 1328: // Success! Return inflated monitor. > 1329: if (own) { > 1330: assert(current->is_Java_thread(), "must be: checked in is_lock_owned()"); Again this assert is not needed as `JavaThread::cast` will perform it. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaVFrame.java line 85: > 83: ( // we have marked ourself as pending on this monitor > 84: mark.monitor().equals(thread.getCurrentPendingMonitor()) || > 85: mark.monitor().isOwnedAnonymous() || Not at all clear to me how this fits here. ?? ------------- PR Review: https://git.openjdk.org/jdk/pull/10907#pullrequestreview-1370203589 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1156763358 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1156767200 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1156736240 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1156785509 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1156787971 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1156789340 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1156797838 From dholmes at openjdk.org Tue Apr 4 06:49:50 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 4 Apr 2023 06:49:50 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v35] In-Reply-To: References: <-xn2Y5lZ-63av1QhbJNDx4saAzgmFT9hE394alHUFHI=.ae58b01f-d6ef-45f3-8e42-fc7b7a552b8e@github.com> Message-ID: On Thu, 30 Mar 2023 14:30:28 GMT, Roman Kennke wrote: >> Please explain why you think this is "not safe". Yes, you can observe state that is in >> the process of changing, but do you think that we'll see a crash with allowing >> `Threads::owning_thread_from_object()` to be called from a non-safepoint place? > > I don't think we'd see a crash, but we might get false results when we are scanning the lock-stack of a foreign thread, when that thread does not hold still. I'm not even comfortable doing that cross-stack lock query with the old code. Given the owner could release the monitor the moment after we check I don't see how false results are an issue here. The existing code should be safe when not executed at a safepoint.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1156792723 From sspitsyn at openjdk.org Tue Apr 4 07:23:05 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 4 Apr 2023 07:23:05 GMT Subject: RFR: 8305520: ToggleNotifyJvmtiTest.java fails with release VMs In-Reply-To: References: Message-ID: On Tue, 4 Apr 2023 06:09:02 GMT, Jie Fu wrote: > Add `-XX:+UnlockDiagnosticVMOptions` to fix the failure with release VMs. > Thanks. Looks good and trivial. Thank you for taking care about it. -Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13318#pullrequestreview-1370349702 From dholmes at openjdk.org Tue Apr 4 07:28:10 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 4 Apr 2023 07:28:10 GMT Subject: RFR: 8304725: AsyncGetCallTrace can cause SIGBUS on M1 [v5] In-Reply-To: References: Message-ID: On Mon, 3 Apr 2023 08:29:55 GMT, Johannes Bechberger wrote: >> Fixes the issue by disabling PCDesc cache modifications when in ASGCT. >> >> Tested on my M1 mac. > > Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision: > > - Fix fix > - Fix minor issues Can I just clarify the new approach please. IIUC if we update the PcDesc cache whilst within ASGCT then we hit code that needs WXWrite mode. So the fix is to just skip updating the cache if ASGCT is active. I have no idea what the PcDesc cache is but I presume if it is really a cache then not updating it only potentially affects lookup performance - right? Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13144#issuecomment-1495349989 From jbechberger at openjdk.org Tue Apr 4 07:32:10 2023 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Tue, 4 Apr 2023 07:32:10 GMT Subject: RFR: 8304725: AsyncGetCallTrace can cause SIGBUS on M1 [v5] In-Reply-To: References: Message-ID: On Mon, 3 Apr 2023 08:29:55 GMT, Johannes Bechberger wrote: >> Fixes the issue by disabling PCDesc cache modifications when in ASGCT. >> >> Tested on my M1 mac. > > Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision: > > - Fix fix > - Fix minor issues You're right and I updated the description of the PR. I gave some performance figures in a previous comment, they show that the performance impact is probably negligible. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13144#issuecomment-1495482316 From jiefu at openjdk.org Tue Apr 4 07:38:15 2023 From: jiefu at openjdk.org (Jie Fu) Date: Tue, 4 Apr 2023 07:38:15 GMT Subject: RFR: 8305520: ToggleNotifyJvmtiTest.java fails with release VMs In-Reply-To: References: Message-ID: On Tue, 4 Apr 2023 07:20:11 GMT, Serguei Spitsyn wrote: > Looks good and trivial. Thank you for taking care about it. -Serguei Thanks @sspitsyn for your review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13318#issuecomment-1495485094 From jiefu at openjdk.org Tue Apr 4 07:38:16 2023 From: jiefu at openjdk.org (Jie Fu) Date: Tue, 4 Apr 2023 07:38:16 GMT Subject: Integrated: 8305520: ToggleNotifyJvmtiTest.java fails with release VMs In-Reply-To: References: Message-ID: On Tue, 4 Apr 2023 06:09:02 GMT, Jie Fu wrote: > Add `-XX:+UnlockDiagnosticVMOptions` to fix the failure with release VMs. > Thanks. This pull request has now been integrated. Changeset: a663d5d6 Author: Jie Fu URL: https://git.openjdk.org/jdk/commit/a663d5d69486447d80cab040830abf0b11636c8f Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8305520: ToggleNotifyJvmtiTest.java fails with release VMs Reviewed-by: sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/13318 From sspitsyn at openjdk.org Tue Apr 4 07:46:10 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 4 Apr 2023 07:46:10 GMT Subject: RFR: 8305237: CompilerDirectives DCmds permissions correction In-Reply-To: References: Message-ID: On Fri, 31 Mar 2023 08:24:19 GMT, Kevin Walls wrote: > The Permissions in DCmds relate to remote usage over JMX. > "monitor" is generally for reading information, and "control" is generally for making changes. > The DCmds for changing compiler directives should have "control" as the required permission. > > Tests in test/hotspot/jtreg/serviceability/dcmd/compiler and test/hotspot/jtreg/compiler/compilercontrol still pass with this change. Marked as reviewed by sspitsyn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13262#pullrequestreview-1370387666 From asotona at openjdk.org Tue Apr 4 07:52:08 2023 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 4 Apr 2023 07:52:08 GMT Subject: RFR: 8305490: CommandProcessor command "dumpclass" produces classes with invalid field descriptors Message-ID: <8e2AC4JawGrdgbWH5PyuYPDNf2cYUPMIZ202DM-ujzA=.cf9602e1-d653-41b4-af4b-e4ef58606fcf@github.com> CommandProcessor command "dumpclass" produces classes with invalid field descriptors. Proposed patch fixes `sun.jvm.hotspot.oops.InstanceKlass::getFieldSignatureIndex` to return correct `getSignatureIndex` instead of invalid `getGenericSignatureIndex`. Added condition to `ClhsdbDumpclass` test assures no errors are reported by `javap` in the dumped classes. Please review. Thank you, Adam ------------- Commit messages: - added test condition - 8305490: CommandProcessor command "dumpclass" produces classes with invalid field descriptors Changes: https://git.openjdk.org/jdk/pull/13321/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13321&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8305490 Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13321.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13321/head:pull/13321 PR: https://git.openjdk.org/jdk/pull/13321 From sspitsyn at openjdk.org Tue Apr 4 07:58:06 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 4 Apr 2023 07:58:06 GMT Subject: RFR: 8305511: Remove ignore from com/sun/jdi/PopAndInvokeTest.java In-Reply-To: References: Message-ID: On Tue, 4 Apr 2023 03:18:37 GMT, Leonid Mesnik wrote: > Test com/sun/jdi/PopAndInvokeTest.java has > @ignore 6951287 > bug 6951287 is closed as a dup for 6417053 which is closed as not reproduced. Marked as reviewed by sspitsyn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13317#pullrequestreview-1370407643 From stuefe at openjdk.org Tue Apr 4 08:20:44 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 4 Apr 2023 08:20:44 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v52] In-Reply-To: References: <7jOmtn6ogSPGZYMvJmV7yPWUgR5sBImxQaf2F8vQZBc=.6f4cad6d-058b-48a5-a943-ff2f18f90d3a@github.com> Message-ID: <2f4eLmsH_dQMV6eQfr1PR0nOIjWWMqe2LDzIk48kBHw=.7bd76dee-a18a-426f-8ea9-cd17e0717352@github.com> On Tue, 4 Apr 2023 05:54:09 GMT, David Holmes wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typo > > src/hotspot/cpu/x86/macroAssembler_x86.cpp line 9739: > >> 9737: get_thread(thread); >> 9738: #endif >> 9739: subl(Address(thread, JavaThread::lock_stack_top_offset()), oopSize); > > Is this code used for monitorexit or only returning from synchronized methods? If used for monitorexit there is no requirement that the monitor being unlocked was the last monitor locked. Balanced locking only requires the locks and unlocks are matched, not that they are perfectly nested ie. this is valid in bytecode: > > monitorenter A > monitorenter B > monitorexit A > monitorExit B That is done one layer up in InterpreterMacroAssembler::unlock_object. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1156895293 From sspitsyn at openjdk.org Tue Apr 4 08:31:08 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 4 Apr 2023 08:31:08 GMT Subject: RFR: 8305209: JDWP exit error AGENT_ERROR_INVALID_THREAD(203): missing entry in running thread table In-Reply-To: References: Message-ID: On Thu, 30 Mar 2023 16:03:05 GMT, Chris Plummer wrote: > The real purpose of this PR is to add virtual thread support to ThreadMemoryLeakTest.java, but this exposed bugs in both the debug agent and in TestScaffold, so those are being fixed also (and the debug agent bug is the CR being used). > > The debug agent bug is due to a race condition during VM exit. The VM is in the process of shutting down. The debug agent has already disabled JVMTI callbacks and has sent the VMDeathEvent. At this point in time there are also threads exiting that the debug agent knows about, but it will not get a ThreadEndEvent for because of the callbacks being disabled. Thus these threads remain in the debug agent's list of known threads, even though they have exited. The debuggee receives the VMDeathEvent and does a VM.resume(). During the debug agent's handing of the VM.Resume command, it iterates over all known threads and needs to map each to its ThreadNode so it can be resumed, and this mapping requires accessing the JVMTI TLS for the thread. The problem is some of the threads may have exited already, and therefore no longer have TLS. This results in the assert in the debug agent. This debug agent issue was already addressed for platform threads, but not for virtual threads, which is why we started seeing this issue when this test was modified. The fix is to just replicate what is done for platform threads for virtual threads also. > > The TestScaffold bug is that if the debuggee crashes/asserts, this is likely to go unnoticed, especially if it happens during VM exit (and the test essentially has already completed). Because of this TestScaffold bug, the debug agent bug above did not result in a test failure. After fixing TestScaffold to check the exitCode of the debuggee process, the test started to appropriately fail until the debug agent was fixed. > > One other thing to point out is the OOME issue I started getting frequently when testing with virtual threads. Since virtual threads are created at a much higher rate than platform threads, their creation started to overwhelm the debugger (actually the JDI implementation). There is already a mechanism in place to do a VM.HoldEvents if JDI has queue up 10,000 events. The problem is that events are coming in so fast that even after doing the VM.HoldEvents, the number of queued events continues to go up for a while, and sometimes reaches 30,000 or more. This raises the peak memory usage of the test quite a bit. Since the test purposely uses a small heap so a memory leak is quickly and reliably detected, the large queue often results in an OOME. Because of this I make virtual threads sleep for 100ms instead of 50ms to slow down their creation, and this resolved the issue. > > I tested by running all of test/jdk/com/sun/jdi 25 times on each platform with and without virtual thread testing enabled. test/jdk/com/sun/jdi/TestScaffold.java line 731: > 729: } > 730: } > 731: Good fix. It looks like this code is important to add in general. test/jdk/com/sun/jdi/ThreadMemoryLeakTest.java line 74: > 72: // that get queued up, so we need to slow it down a bit more > 73: // than we do for platform threads to avoid getting OOME. > 74: Thread.sleep(100); I wonder if this time for sleep can still be not enough. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13246#discussion_r1156905694 PR Review Comment: https://git.openjdk.org/jdk/pull/13246#discussion_r1156907862 From sspitsyn at openjdk.org Tue Apr 4 08:39:09 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 4 Apr 2023 08:39:09 GMT Subject: RFR: 8305209: JDWP exit error AGENT_ERROR_INVALID_THREAD(203): missing entry in running thread table In-Reply-To: References: Message-ID: On Thu, 30 Mar 2023 16:03:05 GMT, Chris Plummer wrote: > The real purpose of this PR is to add virtual thread support to ThreadMemoryLeakTest.java, but this exposed bugs in both the debug agent and in TestScaffold, so those are being fixed also (and the debug agent bug is the CR being used). > > The debug agent bug is due to a race condition during VM exit. The VM is in the process of shutting down. The debug agent has already disabled JVMTI callbacks and has sent the VMDeathEvent. At this point in time there are also threads exiting that the debug agent knows about, but it will not get a ThreadEndEvent for because of the callbacks being disabled. Thus these threads remain in the debug agent's list of known threads, even though they have exited. The debuggee receives the VMDeathEvent and does a VM.resume(). During the debug agent's handing of the VM.Resume command, it iterates over all known threads and needs to map each to its ThreadNode so it can be resumed, and this mapping requires accessing the JVMTI TLS for the thread. The problem is some of the threads may have exited already, and therefore no longer have TLS. This results in the assert in the debug agent. This debug agent issue was already addressed for platform threads, but not for virtual threads, which is why we started seeing this issue when this test was modified. The fix is to just replicate what is done for platform threads for virtual threads also. > > The TestScaffold bug is that if the debuggee crashes/asserts, this is likely to go unnoticed, especially if it happens during VM exit (and the test essentially has already completed). Because of this TestScaffold bug, the debug agent bug above did not result in a test failure. After fixing TestScaffold to check the exitCode of the debuggee process, the test started to appropriately fail until the debug agent was fixed. > > One other thing to point out is the OOME issue I started getting frequently when testing with virtual threads. Since virtual threads are created at a much higher rate than platform threads, their creation started to overwhelm the debugger (actually the JDI implementation). There is already a mechanism in place to do a VM.HoldEvents if JDI has queue up 10,000 events. The problem is that events are coming in so fast that even after doing the VM.HoldEvents, the number of queued events continues to go up for a while, and sometimes reaches 30,000 or more. This raises the peak memory usage of the test quite a bit. Since the test purposely uses a small heap so a memory leak is quickly and reliably detected, the large queue often results in an OOME. Because of this I make virtual threads sleep for 100ms instead of 50ms to slow down their creation, and this resolved the issue. > > I tested by running all of test/jdk/com/sun/jdi 25 times on each platform with and without virtual thread testing enabled. Marked as reviewed by sspitsyn (Reviewer). src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 263: > 261: * Search the runningThreads and runningVThreads lists. The TLS lookup may have > 262: * failed because the thread has terminated, but we never got the THREAD_END event. > 263: * The big comment immediately above explains why this can happen. Nit: I'd suggest to get rid of word "immediately" here. :) src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 274: > 272: } > 273: } > 274: } The fix here is reasonable. ------------- PR Review: https://git.openjdk.org/jdk/pull/13246#pullrequestreview-1370475970 PR Review Comment: https://git.openjdk.org/jdk/pull/13246#discussion_r1156917281 PR Review Comment: https://git.openjdk.org/jdk/pull/13246#discussion_r1156916285 From dholmes at openjdk.org Tue Apr 4 12:28:47 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 4 Apr 2023 12:28:47 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v52] In-Reply-To: <2f4eLmsH_dQMV6eQfr1PR0nOIjWWMqe2LDzIk48kBHw=.7bd76dee-a18a-426f-8ea9-cd17e0717352@github.com> References: <7jOmtn6ogSPGZYMvJmV7yPWUgR5sBImxQaf2F8vQZBc=.6f4cad6d-058b-48a5-a943-ff2f18f90d3a@github.com> <2f4eLmsH_dQMV6eQfr1PR0nOIjWWMqe2LDzIk48kBHw=.7bd76dee-a18a-426f-8ea9-cd17e0717352@github.com> Message-ID: On Tue, 4 Apr 2023 08:17:14 GMT, Thomas Stuefe wrote: >> src/hotspot/cpu/x86/macroAssembler_x86.cpp line 9739: >> >>> 9737: get_thread(thread); >>> 9738: #endif >>> 9739: subl(Address(thread, JavaThread::lock_stack_top_offset()), oopSize); >> >> Is this code used for monitorexit or only returning from synchronized methods? If used for monitorexit there is no requirement that the monitor being unlocked was the last monitor locked. Balanced locking only requires the locks and unlocks are matched, not that they are perfectly nested ie. this is valid in bytecode: >> >> monitorenter A >> monitorenter B >> monitorexit A >> monitorExit B > > That is done one layer up in InterpreterMacroAssembler::unlock_object. Thanks @tstuefe . I see at that level if the object doesn't match the top of the lock-stack then we take the slow path. But then I'm lost - AFAICS the slow path is `InterpreterRuntime::monitorexit` and that doesn't have any fast-locking code in it at all ??? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1157169176 From dholmes at openjdk.org Tue Apr 4 12:31:13 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 4 Apr 2023 12:31:13 GMT Subject: RFR: 8304725: AsyncGetCallTrace can cause SIGBUS on M1 [v5] In-Reply-To: References: Message-ID: On Mon, 3 Apr 2023 08:29:55 GMT, Johannes Bechberger wrote: >> Fixes the issue by disabling PCDesc cache modifications when in ASGCT. >> >> Tested on my M1 mac. > > Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision: > > - Fix fix > - Fix minor issues Nothing further from me. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13144#pullrequestreview-1370866393 From stuefe at openjdk.org Tue Apr 4 13:01:04 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 4 Apr 2023 13:01:04 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v52] In-Reply-To: <7jOmtn6ogSPGZYMvJmV7yPWUgR5sBImxQaf2F8vQZBc=.6f4cad6d-058b-48a5-a943-ff2f18f90d3a@github.com> References: <7jOmtn6ogSPGZYMvJmV7yPWUgR5sBImxQaf2F8vQZBc=.6f4cad6d-058b-48a5-a943-ff2f18f90d3a@github.com> Message-ID: On Mon, 3 Apr 2023 11:05:41 GMT, Roman Kennke wrote: >> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). >> >> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. >> >> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal protocols. >> >> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare. >> >> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. >> >> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. >> >> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. >> >> This change enables to simplify (and speed-up!) a lot of code: >> >> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. >> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR >> >> Also, and I might be mistaken here, this new lightweight locking would make synchronized work better with Loom: Because the lock-records are no longer scattered across the stack, but instead are densely packed into the lock-stack, it should be easy for a vthread to save its lock-stack upon unmounting and restore it when re-mounting. However, I am not sure about this, and this PR does not attempt to implement that support. >> >> Testing: >> - [x] tier1 x86_64 x aarch64 x +UseFastLocking >> - [x] tier2 x86_64 x aarch64 x +UseFastLocking >> - [x] tier3 x86_64 x aarch64 x +UseFastLocking >> - [x] tier4 x86_64 x aarch64 x +UseFastLocking >> - [x] tier1 x86_64 x aarch64 x -UseFastLocking >> - [x] tier2 x86_64 x aarch64 x -UseFastLocking >> - [x] tier3 x86_64 x aarch64 x -UseFastLocking >> - [x] tier4 x86_64 x aarch64 x -UseFastLocking >> - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet >> >> ### Performance >> >> #### Simple Microbenchmark >> >> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops. >> >> | | x86_64 | aarch64 | >> | -- | -- | -- | >> | -UseFastLocking | 20.651 | 20.764 | >> | +UseFastLocking | 18.896 | 18.908 | >> >> >> #### Renaissance >> >> ? | x86_64 | ? | ? | ? | aarch64 | ? | ? >> -- | -- | -- | -- | -- | -- | -- | -- >> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? >> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% >> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21% >> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% >> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% >> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% >> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% >> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%% >> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% >> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% >> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% >> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% >> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34% >> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% >> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% >> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% >> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% >> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% >> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% >> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% >> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% >> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo Can we have named constants for LockingMode, please? Something grepable? ------------- PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1495928668 From stuefe at openjdk.org Tue Apr 4 13:01:04 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 4 Apr 2023 13:01:04 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v52] In-Reply-To: References: <7jOmtn6ogSPGZYMvJmV7yPWUgR5sBImxQaf2F8vQZBc=.6f4cad6d-058b-48a5-a943-ff2f18f90d3a@github.com> <2f4eLmsH_dQMV6eQfr1PR0nOIjWWMqe2LDzIk48kBHw=.7bd76dee-a18a-426f-8ea9-cd17e0717352@github.com> Message-ID: On Tue, 4 Apr 2023 12:25:19 GMT, David Holmes wrote: >> That is done one layer up in InterpreterMacroAssembler::unlock_object. > > Thanks @tstuefe . I see at that level if the object doesn't match the top of the lock-stack then we take the slow path. But then I'm lost - AFAICS the slow path is `InterpreterRuntime::monitorexit` and that doesn't have any fast-locking code in it at all ??? I'm not sure what you mean. `InterpreterRuntime::monitorexit` will enter `ObjectSynchronizer::exit` which handles the fast-locking case under `if (LockingMode == 2)...`. Or am I misunderstanding you? (I really wish for named constants instead of `1` and `2` constants though...) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1157209193 From mgronlun at openjdk.org Tue Apr 4 14:39:19 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 4 Apr 2023 14:39:19 GMT Subject: RFR: 8257967: JFR: Events for loaded agents [v16] In-Reply-To: References: Message-ID: > Greetings, > > We are adding support to let JFR report on Agents. > > #### Design > > An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize. > > A JavaAgent is an agent written in the Java programming language, using the APIs in the package [java.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html) > > A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services. > > To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples: > > // Command line > jdk.JavaAgent { > startTime = 12:31:19.789 (2023-03-08) > name = "JavaAgent.jar" > options = "foo=bar" > dynamic = false > initializationTime = 12:31:15.574 (2023-03-08) > initializationDuration = 172 ms > } > > // Dynamic load > jdk.JavaAgent { > startTime = 12:31:31.158 (2023-03-08) > name = "JavaAgent.jar" > options = "bar=baz" > dynamic = true > initializationTime = 12:31:31.037 (2023-03-08) > initializationDuration = 64,1 ms > } > > The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents. > > For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar. > > The "dynamic" field denotes if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true) > > "initializationTime" is the timestamp the JVM invoked the initialization method, and "initializationDuration" is the duration of executing the initialization method. > > "startTime" represents the time the JFR framework issued the periodic event; hence "initializationTime" will be earlier than "startTime". > > An agent can also be written in a native programming language using the [JVM Tools Interface (JVMTI)](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file. > > To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example: > > jdk.NativeAgent { > startTime = 12:31:40.398 (2023-03-08) > name = "jdwp" > options = "transport=dt_socket,server=y,address=any,onjcmd=y" > dynamic = false > initializationTime = 12:31:36.142 (2023-03-08) > initializationDuration = 0,00184 ms > path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll" > } > > The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported. > > The initialization of a native agent is performed by invoking an agent-specified callback routine. The "initializationTime" is when the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationDuration" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationDuration" will be 0. If the agent is loaded dynamically, "initializationDuration" is the time taken to execute the Agent_OnAttach callback. > > #### Implementation > > There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization ? as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before. > > Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize. > > When implementing this capability, it was necessary to refactor the code used to represent agents, AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp. > > The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp. > > The previous two lists that maintained "agents" (JVMTI) and "libraries" (Xrun) were not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced. > > Testing: jdk_jfr, tier 1 - 6 > > Thanks > Markus Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: renames ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12923/files - new: https://git.openjdk.org/jdk/pull/12923/files/07407a82..d0fd9e97 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12923&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12923&range=14-15 Stats: 2158 lines in 19 files changed: 1059 ins; 1059 del; 40 mod Patch: https://git.openjdk.org/jdk/pull/12923.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/12923/head:pull/12923 PR: https://git.openjdk.org/jdk/pull/12923 From mgronlun at openjdk.org Tue Apr 4 14:44:13 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 4 Apr 2023 14:44:13 GMT Subject: RFR: 8257967: JFR: Events for loaded agents [v15] In-Reply-To: References: <5cFyTNQZjfRp6VlzOqkgdwhoSGaX92KNL3EZlv-NrpY=.fae84f7f-f1d4-4354-a123-33ab97928dcf@github.com> Message-ID: <96JFUTmjTmM45mitEipdK8x2jqjo2uhqF42031X6LRQ=.11d4b13f-7d95-426a-8fc9-50e7dfb8f8ab@github.com> On Sat, 1 Apr 2023 03:31:48 GMT, Serguei Spitsyn wrote: >> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: >> >> fixes > > src/hotspot/share/prims/agent.hpp line 1: > >> 1: /* > > The name for class and file is too general. > I'm thinking if renaming the files to jvmtiAgent and the class to JvmtiAgent would work. > In general, there exists a convention to name JVMTI file with the "jvmti" prefix. > It is a gray zone between Runtime and JVMTI but seems to belong more to JVMTI. > The same about the AgentList class and file. > Also, these new files are good candidates to add here: > > make/hotspot/lib/JvmFeatures.gmk: > ifneq ($(call check-jvm-feature, jvmti), true) > JVM_CFLAGS_FEATURES += -DINCLUDE_JVMTI=0 > JVM_EXCLUDE_FILES += jvmtiGetLoadedClasses.cpp jvmtiThreadState.cpp jvmtiExtensions.cpp \ > jvmtiImpl.cpp jvmtiManageCapabilities.cpp jvmtiRawMonitor.cpp jvmtiUtil.cpp jvmtiTrace.cpp \ > jvmtiCodeBlobEvents.cpp jvmtiEnv.cpp jvmtiRedefineClasses.cpp jvmtiEnvBase.cpp jvmtiEnvThreadState.cpp \ > jvmtiTagMap.cpp jvmtiEventController.cpp evmCompat.cpp jvmtiEnter.xsl jvmtiExport.cpp \ > jvmtiClassFileReconstituter.cpp jvmtiTagMapTable.cpp > endif Hi Sergui, thanks for taking a look. I have updated with the names you suggested. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12923#discussion_r1157362083 From lmesnik at openjdk.org Tue Apr 4 14:43:15 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 4 Apr 2023 14:43:15 GMT Subject: Integrated: 8305511: Remove ignore from com/sun/jdi/PopAndInvokeTest.java In-Reply-To: References: Message-ID: On Tue, 4 Apr 2023 03:18:37 GMT, Leonid Mesnik wrote: > Test com/sun/jdi/PopAndInvokeTest.java has > @ignore 6951287 > bug 6951287 is closed as a dup for 6417053 which is closed as not reproduced. This pull request has now been integrated. Changeset: c5941192 Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/c59411929ddbf5fdc51ccc9d7508cfceeabc58c1 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod 8305511: Remove ignore from com/sun/jdi/PopAndInvokeTest.java Reviewed-by: cjplummer, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/13317 From cjplummer at openjdk.org Tue Apr 4 17:45:06 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 4 Apr 2023 17:45:06 GMT Subject: RFR: 8305490: CommandProcessor command "dumpclass" produces classes with invalid field descriptors In-Reply-To: <8e2AC4JawGrdgbWH5PyuYPDNf2cYUPMIZ202DM-ujzA=.cf9602e1-d653-41b4-af4b-e4ef58606fcf@github.com> References: <8e2AC4JawGrdgbWH5PyuYPDNf2cYUPMIZ202DM-ujzA=.cf9602e1-d653-41b4-af4b-e4ef58606fcf@github.com> Message-ID: On Tue, 4 Apr 2023 07:44:40 GMT, Adam Sotona wrote: > CommandProcessor command "dumpclass" produces classes with invalid field descriptors. > > Proposed patch fixes `sun.jvm.hotspot.oops.InstanceKlass::getFieldSignatureIndex` to return correct `getSignatureIndex` instead of invalid `getGenericSignatureIndex`. > > Added condition to `ClhsdbDumpclass` test assures no errors are reported by `javap` in the dumped classes. > > Please review. > > Thank you, > Adam The test needs a copyright update. Otherwise the changes look good. I assume the reason you caught this failure is because the [JDK-8294969](https://bugs.openjdk.org/browse/JDK-8294969) changes include making javap return a non-zero exit code if there are any error. If that's the case, I guess technically the test change is not needed, but probably good to have in place anyway. ------------- Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13321#pullrequestreview-1371480017 From fparain at openjdk.org Tue Apr 4 17:57:07 2023 From: fparain at openjdk.org (Frederic Parain) Date: Tue, 4 Apr 2023 17:57:07 GMT Subject: RFR: 8305490: CommandProcessor command "dumpclass" produces classes with invalid field descriptors In-Reply-To: <8e2AC4JawGrdgbWH5PyuYPDNf2cYUPMIZ202DM-ujzA=.cf9602e1-d653-41b4-af4b-e4ef58606fcf@github.com> References: <8e2AC4JawGrdgbWH5PyuYPDNf2cYUPMIZ202DM-ujzA=.cf9602e1-d653-41b4-af4b-e4ef58606fcf@github.com> Message-ID: On Tue, 4 Apr 2023 07:44:40 GMT, Adam Sotona wrote: > CommandProcessor command "dumpclass" produces classes with invalid field descriptors. > > Proposed patch fixes `sun.jvm.hotspot.oops.InstanceKlass::getFieldSignatureIndex` to return correct `getSignatureIndex` instead of invalid `getGenericSignatureIndex`. > > Added condition to `ClhsdbDumpclass` test assures no errors are reported by `javap` in the dumped classes. > > Please review. > > Thank you, > Adam Looks good to me. Thank you for fixing this. Fred ------------- Marked as reviewed by fparain (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13321#pullrequestreview-1371500110 From cjplummer at openjdk.org Tue Apr 4 18:51:21 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 4 Apr 2023 18:51:21 GMT Subject: RFR: 8305209: JDWP exit error AGENT_ERROR_INVALID_THREAD(203): missing entry in running thread table [v2] In-Reply-To: References: Message-ID: > The real purpose of this PR is to add virtual thread support to ThreadMemoryLeakTest.java, but this exposed bugs in both the debug agent and in TestScaffold, so those are being fixed also (and the debug agent bug is the CR being used). > > The debug agent bug is due to a race condition during VM exit. The VM is in the process of shutting down. The debug agent has already disabled JVMTI callbacks and has sent the VMDeathEvent. At this point in time there are also threads exiting that the debug agent knows about, but it will not get a ThreadEndEvent for because of the callbacks being disabled. Thus these threads remain in the debug agent's list of known threads, even though they have exited. The debuggee receives the VMDeathEvent and does a VM.resume(). During the debug agent's handing of the VM.Resume command, it iterates over all known threads and needs to map each to its ThreadNode so it can be resumed, and this mapping requires accessing the JVMTI TLS for the thread. The problem is some of the threads may have exited already, and therefore no longer have TLS. This results in the assert in the debug agent. This debug agent issue was already addressed for platform threads, but not for virtual threads, which is why we started seeing this issue when this test was modified. The fix is to just replicate what is done for platform threads for virtual threads also. > > The TestScaffold bug is that if the debuggee crashes/asserts, this is likely to go unnoticed, especially if it happens during VM exit (and the test essentially has already completed). Because of this TestScaffold bug, the debug agent bug above did not result in a test failure. After fixing TestScaffold to check the exitCode of the debuggee process, the test started to appropriately fail until the debug agent was fixed. > > One other thing to point out is the OOME issue I started getting frequently when testing with virtual threads. Since virtual threads are created at a much higher rate than platform threads, their creation started to overwhelm the debugger (actually the JDI implementation). There is already a mechanism in place to do a VM.HoldEvents if JDI has queue up 10,000 events. The problem is that events are coming in so fast that even after doing the VM.HoldEvents, the number of queued events continues to go up for a while, and sometimes reaches 30,000 or more. This raises the peak memory usage of the test quite a bit. Since the test purposely uses a small heap so a memory leak is quickly and reliably detected, the large queue often results in an OOME. Because of this I make virtual threads sleep for 100ms instead of 50ms to slow down their creation, and this resolved the issue. > > I tested by running all of test/jdk/com/sun/jdi 25 times on each platform with and without virtual thread testing enabled. Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: minor comment fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13246/files - new: https://git.openjdk.org/jdk/pull/13246/files/821b49cb..28a337d1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13246&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13246&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13246.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13246/head:pull/13246 PR: https://git.openjdk.org/jdk/pull/13246 From cjplummer at openjdk.org Tue Apr 4 18:51:24 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 4 Apr 2023 18:51:24 GMT Subject: RFR: 8305209: JDWP exit error AGENT_ERROR_INVALID_THREAD(203): missing entry in running thread table [v2] In-Reply-To: References: Message-ID: <1AOBgM_XZxKgD4GX1ZwODBeWcJMlllrM4b9KVwYbFqI=.1e57b67c-758c-4313-9022-413885c77a0b@github.com> On Tue, 4 Apr 2023 08:27:53 GMT, Serguei Spitsyn wrote: >> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: >> >> minor comment fix > > test/jdk/com/sun/jdi/ThreadMemoryLeakTest.java line 74: > >> 72: // that get queued up, so we need to slow it down a bit more >> 73: // than we do for platform threads to avoid getting OOME. >> 74: Thread.sleep(100); > > I wonder if this time for sleep can still be not enough. I did a lot of testing on all platforms, including with product builds, but yes, it is possible that on some some platforms with some flags it might not be enough. I guess more testing will tell. Adjustments might be necessary. It is important not too slow things down too much, or it's possible that if there is a memory leak, the test won't catch it because the leak is not fast enough. With the current sleep values, throughput for virtual threads is still about 2x what it is for platform threads, so right now I'm not worried about it having been slowed down too much. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13246#discussion_r1157634443 From rkennke at openjdk.org Tue Apr 4 19:03:49 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 4 Apr 2023 19:03:49 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v52] In-Reply-To: References: <7jOmtn6ogSPGZYMvJmV7yPWUgR5sBImxQaf2F8vQZBc=.6f4cad6d-058b-48a5-a943-ff2f18f90d3a@github.com> Message-ID: On Tue, 4 Apr 2023 06:46:02 GMT, David Holmes wrote: > One thing I can't quite get clear in my head is whether the small window where an object's monitor is inflated and the object is still in the thread's lock-stack, could cause an issue for any external observers trying to determine the object's locked state. Most observers are thread-local and are basically asking 'am I locking this object?'. Almost all cases where an external thread is checking lightweight- and monitor locks are doing so from a safepoint. The only exception seems to be the path through management.cpp that you are mentioning below, and you say we're ok there (and I tend to agree). > I'm still unclear how we can have non-JavaThreads here. Only JavaThreads can lock object monitors. I've checked again. This particular case is only reached through verification and can easily be solved. The other instance of similar check in synchronizer.cpp seems no longer be called from non-Java-thread, it's probably been fixed by some other change earlier in this PR. In any case, I changed these code paths to assume Java thread and it's not failing tier1 and tier2, but may be worth to do more extensive testing. > src/hotspot/share/runtime/synchronizer.cpp line 1314: > >> 1312: LogStreamHandle(Trace, monitorinflation) lsh; >> 1313: if (mark.is_fast_locked()) { >> 1314: assert(LockingMode == 2, "can only happen with new lightweight locking"); > > I'd rather see this entire case guarded by "`if (LockingMode ==2)`" and have `is_fast_locked()` assert if called in any other mode. Similarly for the stack-locked case below. Ok, I am doing this change. But it means many more LockingMode == 1 or 2 checks in other places, and also means that we need to do a raw-check under VerifyHeavyMonitor paths that the mark-word is not stack-/fast-locked. Overall it does look cleaner and gives a better idea which code path deals with what kind of locking. > Not at all clear to me how this fits here. ?? This block checks whether the monitor is in waiting state. When it is anonymously locked it must be waiting. I added a comment. ------------- PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1496449012 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1157647952 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1157651107 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1157652282 From rkennke at openjdk.org Tue Apr 4 19:03:50 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 4 Apr 2023 19:03:50 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v52] In-Reply-To: References: <7jOmtn6ogSPGZYMvJmV7yPWUgR5sBImxQaf2F8vQZBc=.6f4cad6d-058b-48a5-a943-ff2f18f90d3a@github.com> <2f4eLmsH_dQMV6eQfr1PR0nOIjWWMqe2LDzIk48kBHw=.7bd76dee-a18a-426f-8ea9-cd17e0717352@github.com> Message-ID: On Tue, 4 Apr 2023 12:57:38 GMT, Thomas Stuefe wrote: >> Thanks @tstuefe . I see at that level if the object doesn't match the top of the lock-stack then we take the slow path. But then I'm lost - AFAICS the slow path is `InterpreterRuntime::monitorexit` and that doesn't have any fast-locking code in it at all ??? > > I'm not sure what you mean. `InterpreterRuntime::monitorexit` will enter `ObjectSynchronizer::exit` which handles the fast-locking case under `if (LockingMode == 2)...`. Or am I misunderstanding you? > > (I really wish for named constants instead of `1` and `2` constants though...) > Is this code used for monitorexit or only returning from synchronized methods? If used for monitorexit there is no requirement that the monitor being unlocked was the last monitor locked. Balanced locking only requires the locks and unlocks are matched, not that they are perfectly nested ie. this is valid in bytecode: > > ``` > monitorenter A > monitorenter B > monitorexit A > monitorExit B > ``` As Thomas mentioned, we check this in the interpreter paths, which are the only paths where this can happen. C1 and C2 would reject bytecode with unstructured locking. That's why we can assert for structured locking in MacroAssembler. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1157649461 From rkennke at openjdk.org Tue Apr 4 19:09:31 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 4 Apr 2023 19:09:31 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v53] In-Reply-To: References: Message-ID: > This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). > > What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. > > This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p rotocols. > > The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare. > > In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. > > One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. > > As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. > > This change enables to simplify (and speed-up!) a lot of code: > > - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. > - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR > > Also, and I might be mistaken here, this new lightweight locking would make synchronized work better with Loom: Because the lock-records are no longer scattered across the stack, but instead are densely packed into the lock-stack, it should be easy for a vthread to save its lock-stack upon unmounting and restore it when re-mounting. However, I am not sure about this, and this PR does not attempt to implement that support. > > Testing: > - [x] tier1 x86_64 x aarch64 x +UseFastLocking > - [x] tier2 x86_64 x aarch64 x +UseFastLocking > - [x] tier3 x86_64 x aarch64 x +UseFastLocking > - [x] tier4 x86_64 x aarch64 x +UseFastLocking > - [x] tier1 x86_64 x aarch64 x -UseFastLocking > - [x] tier2 x86_64 x aarch64 x -UseFastLocking > - [x] tier3 x86_64 x aarch64 x -UseFastLocking > - [x] tier4 x86_64 x aarch64 x -UseFastLocking > - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet > > ### Performance > > #### Simple Microbenchmark > > The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops. > > | | x86_64 | aarch64 | > | -- | -- | -- | > | -UseFastLocking | 20.651 | 20.764 | > | +UseFastLocking | 18.896 | 18.908 | > > > #### Renaissance > > ? | x86_64 | ? | ? | ? | aarch64 | ? | ? > -- | -- | -- | -- | -- | -- | -- | -- > ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? > AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% > Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21% > Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% > ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% > GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% > LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% > MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%% > NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% > PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% > FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% > FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% > ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34% > Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% > RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% > Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% > ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% > FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% > FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% Roman Kennke has updated the pull request incrementally with two additional commits since the last revision: - Address David's review comments - Allow scanning lock-stack outside safepoint ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10907/files - new: https://git.openjdk.org/jdk/pull/10907/files/13c84b5c..839f350b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=52 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=51-52 Stats: 47 lines in 10 files changed: 5 ins; 22 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/10907.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/10907/head:pull/10907 PR: https://git.openjdk.org/jdk/pull/10907 From rkennke at openjdk.org Tue Apr 4 19:09:33 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 4 Apr 2023 19:09:33 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v52] In-Reply-To: References: <7jOmtn6ogSPGZYMvJmV7yPWUgR5sBImxQaf2F8vQZBc=.6f4cad6d-058b-48a5-a943-ff2f18f90d3a@github.com> Message-ID: On Tue, 4 Apr 2023 19:01:44 GMT, Roman Kennke wrote: >> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaVFrame.java line 85: >> >>> 83: ( // we have marked ourself as pending on this monitor >>> 84: mark.monitor().equals(thread.getCurrentPendingMonitor()) || >>> 85: mark.monitor().isOwnedAnonymous() || >> >> Not at all clear to me how this fits here. ?? > >> Not at all clear to me how this fits here. ?? > > This block checks whether the monitor is in waiting state. When it is anonymously locked it must be waiting. I added a comment. > Given the owner could release the monitor the moment after we check I don't see how false results are an issue here. The existing code should be safe when not executed at a safepoint.. I checked again. It looks like the DeadLock test now passes even if I let the code in management.cpp go check stacks without safepoint. I believe the addition of the start_processing() to LockStack::contains() fixes the ZGC problem. But please, run the full tests again on Mach5. I don't see any failures here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1157654320 From lmesnik at openjdk.org Tue Apr 4 20:23:03 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 4 Apr 2023 20:23:03 GMT Subject: RFR: 8305607: Remove some unused test parameters in com/sun/jdi tests Message-ID: Some tests set debugee name which is set by startUp() method. The test/jdk/com/sun/jdi/RedefineNestmateAttr/TestNestmateAttr.java set classpath which is not required. ------------- Commit messages: - fixed tests Changes: https://git.openjdk.org/jdk/pull/13337/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13337&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8305607 Stats: 12 lines in 5 files changed: 0 ins; 2 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/13337.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13337/head:pull/13337 PR: https://git.openjdk.org/jdk/pull/13337 From sspitsyn at openjdk.org Tue Apr 4 20:40:03 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 4 Apr 2023 20:40:03 GMT Subject: RFR: 8303563: GetCurrentThreadCpuTime and GetThreadCpuTime need further clarification for virtual threads Message-ID: This is a follow-up to [JDK-8302615](https://bugs.openjdk.org/browse/JDK-8302615) where GetCurrentThreadCpuTime and GetThreadCpuTime were changed from being not supported to optional, when called from/with a virtual thread. There are two additional sentences that need adjustment to avoid creating a conflict in the spec. In the functions `GetCurrentThreadCpuTime` and `GetThreadCpuTime`: The fragment: `"The current thread may not be a virtual thread. Otherwise, the error code"` is replaced with: "An implementation is not required to support this function when the current thread is a virtual thread, in which case" CSR: [JDK-8305617](https://bugs.openjdk.org/browse/JDK-8305617) ------------- Commit messages: - 8303563: GetCurrentThreadCpuTime and GetThreadCpuTime need further clarification for virtual threads Changes: https://git.openjdk.org/jdk/pull/13338/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13338&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303563 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13338.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13338/head:pull/13338 PR: https://git.openjdk.org/jdk/pull/13338 From lmesnik at openjdk.org Tue Apr 4 20:56:10 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 4 Apr 2023 20:56:10 GMT Subject: RFR: 8305209: JDWP exit error AGENT_ERROR_INVALID_THREAD(203): missing entry in running thread table [v2] In-Reply-To: References: Message-ID: <3mXQdNVXC2df19bVjdi7hlnctoHR5I8RgCDcFcGJ1T8=.525a5996-f2fd-4522-a5b7-da976a955c0c@github.com> On Tue, 4 Apr 2023 18:51:21 GMT, Chris Plummer wrote: >> The real purpose of this PR is to add virtual thread support to ThreadMemoryLeakTest.java, but this exposed bugs in both the debug agent and in TestScaffold, so those are being fixed also (and the debug agent bug is the CR being used). >> >> The debug agent bug is due to a race condition during VM exit. The VM is in the process of shutting down. The debug agent has already disabled JVMTI callbacks and has sent the VMDeathEvent. At this point in time there are also threads exiting that the debug agent knows about, but it will not get a ThreadEndEvent for because of the callbacks being disabled. Thus these threads remain in the debug agent's list of known threads, even though they have exited. The debuggee receives the VMDeathEvent and does a VM.resume(). During the debug agent's handing of the VM.Resume command, it iterates over all known threads and needs to map each to its ThreadNode so it can be resumed, and this mapping requires accessing the JVMTI TLS for the thread. The problem is some of the threads may have exited already, and therefore no longer have TLS. This results in the assert in the debug agent. This debug agent issue was already addressed for platform threads, but not for virtual threads, which is why w e started seeing this issue when this test was modified. The fix is to just replicate what is done for platform threads for virtual threads also. >> >> The TestScaffold bug is that if the debuggee crashes/asserts, this is likely to go unnoticed, especially if it happens during VM exit (and the test essentially has already completed). Because of this TestScaffold bug, the debug agent bug above did not result in a test failure. After fixing TestScaffold to check the exitCode of the debuggee process, the test started to appropriately fail until the debug agent was fixed. >> >> One other thing to point out is the OOME issue I started getting frequently when testing with virtual threads. Since virtual threads are created at a much higher rate than platform threads, their creation started to overwhelm the debugger (actually the JDI implementation). There is already a mechanism in place to do a VM.HoldEvents if JDI has queue up 10,000 events. The problem is that events are coming in so fast that even after doing the VM.HoldEvents, the number of queued events continues to go up for a while, and sometimes reaches 30,000 or more. This raises the peak memory usage of the test quite a bit. Since the test purposely uses a small heap so a memory leak is quickly and reliably detected, the large queue often results in an OOME. Because of this I make virtual threads sleep for 100ms instead of 50ms to slow down their creation, and this resolved the issue. >> >> I tested by running all of test/jdk/com/sun/jdi 25 times on each platform with and without virtual thread testing enabled. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > minor comment fix Changes requested by lmesnik (Reviewer). test/jdk/com/sun/jdi/TestScaffold.java line 721: > 719: throw new RuntimeException(e); > 720: } > 721: if (p.isAlive()) { It think it is better to just use watiFor(). If debugee hangs it would be better to times out and give timeout handler a chance to dump all stack traces. ------------- PR Review: https://git.openjdk.org/jdk/pull/13246#pullrequestreview-1371766736 PR Review Comment: https://git.openjdk.org/jdk/pull/13246#discussion_r1157749483 From lmesnik at openjdk.org Tue Apr 4 20:56:13 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 4 Apr 2023 20:56:13 GMT Subject: RFR: 8305209: JDWP exit error AGENT_ERROR_INVALID_THREAD(203): missing entry in running thread table [v2] In-Reply-To: <1AOBgM_XZxKgD4GX1ZwODBeWcJMlllrM4b9KVwYbFqI=.1e57b67c-758c-4313-9022-413885c77a0b@github.com> References: <1AOBgM_XZxKgD4GX1ZwODBeWcJMlllrM4b9KVwYbFqI=.1e57b67c-758c-4313-9022-413885c77a0b@github.com> Message-ID: On Tue, 4 Apr 2023 18:42:57 GMT, Chris Plummer wrote: >> test/jdk/com/sun/jdi/ThreadMemoryLeakTest.java line 74: >> >>> 72: // that get queued up, so we need to slow it down a bit more >>> 73: // than we do for platform threads to avoid getting OOME. >>> 74: Thread.sleep(100); >> >> I wonder if this time for sleep can still be not enough. > > I did a lot of testing on all platforms, including with product builds, but yes, it is possible that on some some platforms with some flags it might not be enough. I guess more testing will tell. Adjustments might be necessary. It is important not too slow things down too much, or it's possible that if there is a memory leak, the test won't catch it because the leak is not fast enough. With the current sleep values, throughput for virtual threads is still about 2x what it is for platform threads, so right now I'm not worried about it having been slowed down too much. small nit. shorter to use: long timeToSleep = "Virtual".equals(mainWrapper) ? 100 : 50; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13246#discussion_r1157751992 From lmesnik at openjdk.org Tue Apr 4 20:57:09 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 4 Apr 2023 20:57:09 GMT Subject: RFR: 8305608: Change VMConnection to use "test.class.path"instead of "test.classes" Message-ID: Currently, VMConnection run debugee using "test.classes" as a classpath. It cause test failures when virtual thread factory (wrapper) is enabled and test is not located the same directory as TestScaffold. ------------- Commit messages: - more tests are added - updated vmconnection Changes: https://git.openjdk.org/jdk/pull/13339/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13339&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8305608 Stats: 17 lines in 2 files changed: 3 ins; 12 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13339.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13339/head:pull/13339 PR: https://git.openjdk.org/jdk/pull/13339 From lmesnik at openjdk.org Tue Apr 4 20:57:10 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 4 Apr 2023 20:57:10 GMT Subject: RFR: 8305608: Change VMConnection to use "test.class.path"instead of "test.classes" In-Reply-To: References: Message-ID: On Tue, 4 Apr 2023 20:42:34 GMT, Leonid Mesnik wrote: > Currently, VMConnection run debugee using "test.classes" as a classpath. It cause test failures when virtual thread factory (wrapper) is enabled and test is not located the same directory as TestScaffold. Might be always use use to simplify execution and allow debugee to use test library? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13339#issuecomment-1496581485 From iklam at openjdk.org Tue Apr 4 21:15:00 2023 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 4 Apr 2023 21:15:00 GMT Subject: RFR: 8298048: Combine CDS archive heap into a single block Message-ID: This PR combines the "open" and "closed" regions of the CDS archive heap into a single region. This significantly simplifies the implementation, making it more compatible with non-G1 collectors. There's a net removal of ~1000 lines in src code and another ~1200 lines of tests. **Notes for reviewers:** - Most of the code changes in CDS are removing the handling of "open" vs "closed" objects. - Reviewers can start with ArchiveHeapWriter::copy_source_objs_to_buffer(). - It might be easier to see the diff with whitespaces off. - There are two major changes in the G1 code - The archived objects are now stored in the "old" region (see g1CollectedHeap.cpp in [58d720e](https://github.com/openjdk/jdk/pull/13284/commits/58d720e294bb36f21cb88cddde724ed2b9e93770)) - The majority of the other changes are removal of the "archive" region type (see heapRegionType.hpp). For ease of review, such code is isolated in [a852dfb](https://github.com/openjdk/jdk/pull/13284/commits/a852dfbbf5ff56e035399f7cc3704f29e76697f6) - Testing changes: - Now the archived java objects can move, along with the "old" regions that contain them. It's no longer possible to test whether a heap object came from CDS. As a result, the `WhiteBox.isShared(Object o)` API has been removed. - Many tests that uses this API are removed. Most of them were written during early development of CDS archived objects and are no longer relevant. **Testing:** - Mach5 tiers 1 ~ 7 ------------- Commit messages: - Remove archive region types from G1 - clean up (1) - 8298048: Combine CDS archive heap into a single block Changes: https://git.openjdk.org/jdk/pull/13284/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13284&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298048 Stats: 2995 lines in 75 files changed: 110 ins; 2271 del; 614 mod Patch: https://git.openjdk.org/jdk/pull/13284.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13284/head:pull/13284 PR: https://git.openjdk.org/jdk/pull/13284 From dholmes at openjdk.org Tue Apr 4 22:07:39 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 4 Apr 2023 22:07:39 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v52] In-Reply-To: References: <7jOmtn6ogSPGZYMvJmV7yPWUgR5sBImxQaf2F8vQZBc=.6f4cad6d-058b-48a5-a943-ff2f18f90d3a@github.com> <2f4eLmsH_dQMV6eQfr1PR0nOIjWWMqe2LDzIk48kBHw=.7bd76dee-a18a-426f-8ea9-cd17e0717352@github.com> Message-ID: On Tue, 4 Apr 2023 12:57:38 GMT, Thomas Stuefe wrote: >> Thanks @tstuefe . I see at that level if the object doesn't match the top of the lock-stack then we take the slow path. But then I'm lost - AFAICS the slow path is `InterpreterRuntime::monitorexit` and that doesn't have any fast-locking code in it at all ??? > > I'm not sure what you mean. `InterpreterRuntime::monitorexit` will enter `ObjectSynchronizer::exit` which handles the fast-locking case under `if (LockingMode == 2)...`. Or am I misunderstanding you? > > (I really wish for named constants instead of `1` and `2` constants though...) Thanks @tstuefe .I misread something. > (I really wish for named constants instead of 1 and 2 constants though...) Yeah but then we are back at the "what do we call this" problem :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1157813697 From dholmes at openjdk.org Tue Apr 4 22:15:41 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 4 Apr 2023 22:15:41 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v52] In-Reply-To: References: <7jOmtn6ogSPGZYMvJmV7yPWUgR5sBImxQaf2F8vQZBc=.6f4cad6d-058b-48a5-a943-ff2f18f90d3a@github.com> Message-ID: <3Xk6QvHPcMBoY8Su5aEHQBkkDjPtRKUtkm7Avnq-K_k=.6f85a673-69a2-48d1-90b2-0994f346fd00@github.com> On Tue, 4 Apr 2023 19:04:03 GMT, Roman Kennke wrote: >>> Not at all clear to me how this fits here. ?? >> >> This block checks whether the monitor is in waiting state. When it is anonymously locked it must be waiting. I added a comment. > >> Given the owner could release the monitor the moment after we check I don't see how false results are an issue here. The existing code should be safe when not executed at a safepoint.. > > I checked again. It looks like the DeadLock test now passes even if I let the code in management.cpp go check stacks without safepoint. I believe the addition of the start_processing() to LockStack::contains() fixes the ZGC problem. But please, run the full tests again on Mach5. I don't see any failures here. > When it is anonymously locked it must be waiting. I guess I am unclear what "waiting" refers to here, and which "thread" we are checking for what. If the monitor is anonymously locked then we know it is contended - perhaps that is what this "waiting" means? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1157819177 From kevinw at openjdk.org Tue Apr 4 22:16:10 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 4 Apr 2023 22:16:10 GMT Subject: RFR: 8305237: CompilerDirectives DCmds permissions correction In-Reply-To: References: Message-ID: On Fri, 31 Mar 2023 08:24:19 GMT, Kevin Walls wrote: > The Permissions in DCmds relate to remote usage over JMX. > "monitor" is generally for reading information, and "control" is generally for making changes. > The DCmds for changing compiler directives should have "control" as the required permission. > > Tests in test/hotspot/jtreg/serviceability/dcmd/compiler and test/hotspot/jtreg/compiler/compilercontrol still pass with this change. Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13262#issuecomment-1496667870 From kevinw at openjdk.org Tue Apr 4 22:20:15 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 4 Apr 2023 22:20:15 GMT Subject: Integrated: 8305237: CompilerDirectives DCmds permissions correction In-Reply-To: References: Message-ID: On Fri, 31 Mar 2023 08:24:19 GMT, Kevin Walls wrote: > The Permissions in DCmds relate to remote usage over JMX. > "monitor" is generally for reading information, and "control" is generally for making changes. > The DCmds for changing compiler directives should have "control" as the required permission. > > Tests in test/hotspot/jtreg/serviceability/dcmd/compiler and test/hotspot/jtreg/compiler/compilercontrol still pass with this change. This pull request has now been integrated. Changeset: 15fa78e6 Author: Kevin Walls URL: https://git.openjdk.org/jdk/commit/15fa78e6e78942e6c33e071b5a9d4d85143bc822 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8305237: CompilerDirectives DCmds permissions correction Reviewed-by: cjplummer, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/13262 From sspitsyn at openjdk.org Tue Apr 4 22:40:06 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 4 Apr 2023 22:40:06 GMT Subject: RFR: 8305209: JDWP exit error AGENT_ERROR_INVALID_THREAD(203): missing entry in running thread table [v2] In-Reply-To: References: <1AOBgM_XZxKgD4GX1ZwODBeWcJMlllrM4b9KVwYbFqI=.1e57b67c-758c-4313-9022-413885c77a0b@github.com> Message-ID: <0O33RlR90CmsvRfeRk9fJh8ZepjPoMMor-UYRa3CoiA=.5ed1a14c-5a95-4b66-9d4e-85e4103a0347@github.com> On Tue, 4 Apr 2023 20:53:18 GMT, Leonid Mesnik wrote: >> I did a lot of testing on all platforms, including with product builds, but yes, it is possible that on some some platforms with some flags it might not be enough. I guess more testing will tell. Adjustments might be necessary. It is important not too slow things down too much, or it's possible that if there is a memory leak, the test won't catch it because the leak is not fast enough. With the current sleep values, throughput for virtual threads is still about 2x what it is for platform threads, so right now I'm not worried about it having been slowed down too much. > > small nit. shorter to use: > long timeToSleep = "Virtual".equals(mainWrapper) ? 100 : 50; Okay. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13246#discussion_r1157832902 From sspitsyn at openjdk.org Tue Apr 4 22:58:12 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 4 Apr 2023 22:58:12 GMT Subject: RFR: 8305607: Remove some unused test parameters in com/sun/jdi tests In-Reply-To: References: Message-ID: On Tue, 4 Apr 2023 20:15:41 GMT, Leonid Mesnik wrote: > Some tests set debugee name which is set by startUp() method. > > The test/jdk/com/sun/jdi/RedefineNestmateAttr/TestNestmateAttr.java set classpath which is not required. Looks good. Good to know this about `TestScaffold` framework. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13337#pullrequestreview-1371896414 From sspitsyn at openjdk.org Tue Apr 4 23:11:06 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 4 Apr 2023 23:11:06 GMT Subject: RFR: 8305608: Change VMConnection to use "test.class.path"instead of "test.classes" In-Reply-To: References: Message-ID: On Tue, 4 Apr 2023 20:42:34 GMT, Leonid Mesnik wrote: > Currently, VMConnection run debugee using "test.classes" as a classpath. It cause test failures when virtual thread factory (wrapper) is enabled and test is not located the same directory as TestScaffold. test/jdk/com/sun/jdi/VMConnection.java line 54: > 52: // When we run under jtreg, test.classes contains the pathname of > 53: // the dir in which the .class files will be placed. > 54: // When we run jtreg with plugin, the TestScaffold should be also in classpath A stupid question about this part of comment: `the TestScaffold should be also in classpath`. If it should be ALSO in classpath then why in the `Virtual` case we use "test.class.path" instead of "test.classes" but not both. It'd be good to clarify this in the comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13339#discussion_r1157850857 From lmesnik at openjdk.org Tue Apr 4 23:55:07 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 4 Apr 2023 23:55:07 GMT Subject: RFR: 8305608: Change VMConnection to use "test.class.path"instead of "test.classes" In-Reply-To: References: Message-ID: On Tue, 4 Apr 2023 23:08:06 GMT, Serguei Spitsyn wrote: >> Currently, VMConnection run debugee using "test.classes" as a classpath. It cause test failures when virtual thread factory (wrapper) is enabled and test is not located the same directory as TestScaffold. > > test/jdk/com/sun/jdi/VMConnection.java line 54: > >> 52: // When we run under jtreg, test.classes contains the pathname of >> 53: // the dir in which the .class files will be placed. >> 54: // When we run jtreg with plugin, the TestScaffold should be also in classpath > > A stupid question about this part of comment: `the TestScaffold should be also in classpath`. > If it should be ALSO in classpath then why in the `Virtual` case we use "test.class.path" instead of "test.classes" but not both. It'd be good to clarify this in the comment. The "test.class.path" is complete classpath required to run test. It included test.classes as well as testlibrary and some other classes. The tests located in com/sun/jdi/ uses 'com/sun/jdi' as a testlibrary. The better comment would be // When we run jtreg with plugin, the full classpath including testlibrary is required to use TestScaffold is required However, before fixing this comment I would like to see if there are any objections against using "test.class.path" in all cases. It would minimize difference in virtual and standard mode. Is there are any reason to use "test.classes" at all? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13339#discussion_r1157871028 From dcubed at openjdk.org Wed Apr 5 00:17:44 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 5 Apr 2023 00:17:44 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v53] In-Reply-To: References: Message-ID: On Tue, 4 Apr 2023 19:09:31 GMT, Roman Kennke wrote: >> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). >> >> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. >> >> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal protocols. >> >> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare. >> >> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. >> >> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. >> >> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. >> >> This change enables to simplify (and speed-up!) a lot of code: >> >> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. >> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR >> >> Also, and I might be mistaken here, this new lightweight locking would make synchronized work better with Loom: Because the lock-records are no longer scattered across the stack, but instead are densely packed into the lock-stack, it should be easy for a vthread to save its lock-stack upon unmounting and restore it when re-mounting. However, I am not sure about this, and this PR does not attempt to implement that support. >> >> Testing: >> - [x] tier1 x86_64 x aarch64 x +UseFastLocking >> - [x] tier2 x86_64 x aarch64 x +UseFastLocking >> - [x] tier3 x86_64 x aarch64 x +UseFastLocking >> - [x] tier4 x86_64 x aarch64 x +UseFastLocking >> - [x] tier1 x86_64 x aarch64 x -UseFastLocking >> - [x] tier2 x86_64 x aarch64 x -UseFastLocking >> - [x] tier3 x86_64 x aarch64 x -UseFastLocking >> - [x] tier4 x86_64 x aarch64 x -UseFastLocking >> - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet >> >> ### Performance >> >> #### Simple Microbenchmark >> >> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops. >> >> | | x86_64 | aarch64 | >> | -- | -- | -- | >> | -UseFastLocking | 20.651 | 20.764 | >> | +UseFastLocking | 18.896 | 18.908 | >> >> >> #### Renaissance >> >> ? | x86_64 | ? | ? | ? | aarch64 | ? | ? >> -- | -- | -- | -- | -- | -- | -- | -- >> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? >> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% >> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21% >> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% >> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% >> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% >> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% >> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%% >> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% >> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% >> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% >> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% >> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34% >> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% >> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% >> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% >> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% >> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% >> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% >> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% >> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% >> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% > > Roman Kennke has updated the pull request incrementally with two additional commits since the last revision: > > - Address David's review comments > - Allow scanning lock-stack outside safepoint I've updated my repos with v52 and I'm doing Mach5 testing on it. I've still only reviewed up thru v36 so I have some catching up to do. ------------- PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1496755688 From dholmes at openjdk.org Wed Apr 5 00:17:45 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 5 Apr 2023 00:17:45 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v52] In-Reply-To: <3Xk6QvHPcMBoY8Su5aEHQBkkDjPtRKUtkm7Avnq-K_k=.6f85a673-69a2-48d1-90b2-0994f346fd00@github.com> References: <7jOmtn6ogSPGZYMvJmV7yPWUgR5sBImxQaf2F8vQZBc=.6f4cad6d-058b-48a5-a943-ff2f18f90d3a@github.com> <3Xk6QvHPcMBoY8Su5aEHQBkkDjPtRKUtkm7Avnq-K_k=.6f85a673-69a2-48d1-90b2-0994f346fd00@github.com> Message-ID: On Tue, 4 Apr 2023 22:12:03 GMT, David Holmes wrote: >>> Given the owner could release the monitor the moment after we check I don't see how false results are an issue here. The existing code should be safe when not executed at a safepoint.. >> >> I checked again. It looks like the DeadLock test now passes even if I let the code in management.cpp go check stacks without safepoint. I believe the addition of the start_processing() to LockStack::contains() fixes the ZGC problem. But please, run the full tests again on Mach5. I don't see any failures here. > >> When it is anonymously locked it must be waiting. > > I guess I am unclear what "waiting" refers to here, and which "thread" we are checking for what. If the monitor is anonymously locked then we know it is contended - perhaps that is what this "waiting" means? > The existing code should be safe when not executed at a safepoint. Just to be clear I meant the code before your changes should be safe. Your code needs to establish it is safe - which takes us back to the issue of querying the lock-stack while it may be being concurrently pushed/popped. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1157820627 From sspitsyn at openjdk.org Wed Apr 5 01:08:16 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 5 Apr 2023 01:08:16 GMT Subject: RFR: 8305608: Change VMConnection to use "test.class.path"instead of "test.classes" In-Reply-To: References: Message-ID: <3Xyc3nRyd_hr8fw7XQcAqsSv3UQg2wnsnp7fdvTYteo=.c1381ed9-25c5-4fe5-b4bd-1df7e73d3572@github.com> On Tue, 4 Apr 2023 23:52:45 GMT, Leonid Mesnik wrote: >> test/jdk/com/sun/jdi/VMConnection.java line 54: >> >>> 52: // When we run under jtreg, test.classes contains the pathname of >>> 53: // the dir in which the .class files will be placed. >>> 54: // When we run jtreg with plugin, the TestScaffold should be also in classpath >> >> A stupid question about this part of comment: `the TestScaffold should be also in classpath`. >> If it should be ALSO in classpath then why in the `Virtual` case we use "test.class.path" instead of "test.classes" but not both. It'd be good to clarify this in the comment. > > The "test.class.path" is complete classpath required to run test. It included test.classes as well as testlibrary and some other classes. The tests located in com/sun/jdi/ uses 'com/sun/jdi' as a testlibrary. > The better comment would be > // When we run jtreg with plugin, the full classpath including testlibrary is required to use TestScaffold is required > > However, before fixing this comment I would like to see if there are any objections against using "test.class.path" in all cases. It would minimize difference in virtual and standard mode. > Is there are any reason to use "test.classes" at all? I'd prefer to always use the "test.class.path" as it is a complete classpath required to run test. > The better comment would be > // When we run jtreg with plugin, the full classpath including testlibrary is required to use TestScaffold is required I guess, you are going to remove this duplication with "is required". :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13339#discussion_r1157911621 From dholmes at openjdk.org Wed Apr 5 01:51:14 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 5 Apr 2023 01:51:14 GMT Subject: RFR: 8257967: JFR: Events for loaded agents [v16] In-Reply-To: References: Message-ID: On Tue, 4 Apr 2023 14:39:19 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> We are adding support to let JFR report on Agents. >> >> #### Design >> >> An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize. >> >> A JavaAgent is an agent written in the Java programming language, using the APIs in the package [java.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html) >> >> A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services. >> >> To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples: >> >> // Command line >> jdk.JavaAgent { >> startTime = 12:31:19.789 (2023-03-08) >> name = "JavaAgent.jar" >> options = "foo=bar" >> dynamic = false >> initializationTime = 12:31:15.574 (2023-03-08) >> initializationDuration = 172 ms >> } >> >> // Dynamic load >> jdk.JavaAgent { >> startTime = 12:31:31.158 (2023-03-08) >> name = "JavaAgent.jar" >> options = "bar=baz" >> dynamic = true >> initializationTime = 12:31:31.037 (2023-03-08) >> initializationDuration = 64,1 ms >> } >> >> The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents. >> >> For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar. >> >> The "dynamic" field denotes if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true) >> >> "initializationTime" is the timestamp the JVM invoked the initialization method, and "initializationDuration" is the duration of executing the initialization method. >> >> "startTime" represents the time the JFR framework issued the periodic event; hence "initializationTime" will be earlier than "startTime". >> >> An agent can also be written in a native programming language using the [JVM Tools Interface (JVMTI)](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file. >> >> To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example: >> >> jdk.NativeAgent { >> startTime = 12:31:40.398 (2023-03-08) >> name = "jdwp" >> options = "transport=dt_socket,server=y,address=any,onjcmd=y" >> dynamic = false >> initializationTime = 12:31:36.142 (2023-03-08) >> initializationDuration = 0,00184 ms >> path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll" >> } >> >> The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported. >> >> The initialization of a native agent is performed by invoking an agent-specified callback routine. The "initializationTime" is when the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationDuration" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationDuration" will be 0. If the agent is loaded dynamically, "initializationDuration" is the time taken to execute the Agent_OnAttach callback. >> >> #### Implementation >> >> There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization ? as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before. >> >> Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize. >> >> When implementing this capability, it was necessary to refactor the code used to represent agents, AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp. >> >> The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp. >> >> The previous two lists that maintained "agents" (JVMTI) and "libraries" (Xrun) were not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced. >> >> Testing: jdk_jfr, tier 1 - 6 >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: > > renames Renamings look good to me. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/12923#pullrequestreview-1372019560 From dholmes at openjdk.org Wed Apr 5 02:15:15 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 5 Apr 2023 02:15:15 GMT Subject: RFR: 8303563: GetCurrentThreadCpuTime and GetThreadCpuTime need further clarification for virtual threads In-Reply-To: References: Message-ID: On Tue, 4 Apr 2023 20:33:46 GMT, Serguei Spitsyn wrote: > This is a follow-up to [JDK-8302615](https://bugs.openjdk.org/browse/JDK-8302615) where GetCurrentThreadCpuTime and GetThreadCpuTime were changed from being not supported to optional, when called from/with a virtual thread. There are two additional sentences that need adjustment to avoid creating a conflict in the spec. > > In the functions `GetCurrentThreadCpuTime` and `GetThreadCpuTime`: > > The fragment: > `"The current thread may not be a virtual thread. Otherwise, the error code"` > > is replaced with: > > "An implementation is not required to support this function > when the current thread is a virtual thread, in which case" > > > CSR: [JDK-8305617](https://bugs.openjdk.org/browse/JDK-8305617) Looks good. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13338#pullrequestreview-1372034930 From cjplummer at openjdk.org Wed Apr 5 05:30:07 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 5 Apr 2023 05:30:07 GMT Subject: RFR: 8305209: JDWP exit error AGENT_ERROR_INVALID_THREAD(203): missing entry in running thread table [v2] In-Reply-To: <3mXQdNVXC2df19bVjdi7hlnctoHR5I8RgCDcFcGJ1T8=.525a5996-f2fd-4522-a5b7-da976a955c0c@github.com> References: <3mXQdNVXC2df19bVjdi7hlnctoHR5I8RgCDcFcGJ1T8=.525a5996-f2fd-4522-a5b7-da976a955c0c@github.com> Message-ID: On Tue, 4 Apr 2023 20:50:21 GMT, Leonid Mesnik wrote: >> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: >> >> minor comment fix > > test/jdk/com/sun/jdi/TestScaffold.java line 721: > >> 719: throw new RuntimeException(e); >> 720: } >> 721: if (p.isAlive()) { > > It think it is better to just use watiFor(). If debugee hangs it would be better to times out and give timeout handler a chance to dump all stack traces. Ok. I hadn't thought about the timeout handler. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13246#discussion_r1158037262 From alanb at openjdk.org Wed Apr 5 06:09:05 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 5 Apr 2023 06:09:05 GMT Subject: RFR: 8303563: GetCurrentThreadCpuTime and GetThreadCpuTime need further clarification for virtual threads In-Reply-To: References: Message-ID: On Tue, 4 Apr 2023 20:33:46 GMT, Serguei Spitsyn wrote: > This is a follow-up to [JDK-8302615](https://bugs.openjdk.org/browse/JDK-8302615) where GetCurrentThreadCpuTime and GetThreadCpuTime were changed from being not supported to optional, when called from/with a virtual thread. There are two additional sentences that need adjustment to avoid creating a conflict in the spec. > > In the functions `GetCurrentThreadCpuTime` and `GetThreadCpuTime`: > > The fragment: > `"The current thread may not be a virtual thread. Otherwise, the error code"` > > is replaced with: > > "An implementation is not required to support this function > when the current thread is a virtual thread, in which case" > > > CSR: [JDK-8305617](https://bugs.openjdk.org/browse/JDK-8305617) Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13338#pullrequestreview-1372207726 From asotona at openjdk.org Wed Apr 5 06:30:51 2023 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 5 Apr 2023 06:30:51 GMT Subject: RFR: 8305490: CommandProcessor command "dumpclass" produces classes with invalid field descriptors [v2] In-Reply-To: <8e2AC4JawGrdgbWH5PyuYPDNf2cYUPMIZ202DM-ujzA=.cf9602e1-d653-41b4-af4b-e4ef58606fcf@github.com> References: <8e2AC4JawGrdgbWH5PyuYPDNf2cYUPMIZ202DM-ujzA=.cf9602e1-d653-41b4-af4b-e4ef58606fcf@github.com> Message-ID: > CommandProcessor command "dumpclass" produces classes with invalid field descriptors. > > Proposed patch fixes `sun.jvm.hotspot.oops.InstanceKlass::getFieldSignatureIndex` to return correct `getSignatureIndex` instead of invalid `getGenericSignatureIndex`. > > Added condition to `ClhsdbDumpclass` test assures no errors are reported by `javap` in the dumped classes. > > Please review. > > Thank you, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: updated copyright header ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13321/files - new: https://git.openjdk.org/jdk/pull/13321/files/ff0b4c99..9077e2eb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13321&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13321&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13321.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13321/head:pull/13321 PR: https://git.openjdk.org/jdk/pull/13321 From asotona at openjdk.org Wed Apr 5 06:36:06 2023 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 5 Apr 2023 06:36:06 GMT Subject: RFR: 8305490: CommandProcessor command "dumpclass" produces classes with invalid field descriptors [v2] In-Reply-To: References: <8e2AC4JawGrdgbWH5PyuYPDNf2cYUPMIZ202DM-ujzA=.cf9602e1-d653-41b4-af4b-e4ef58606fcf@github.com> Message-ID: On Wed, 5 Apr 2023 06:30:51 GMT, Adam Sotona wrote: >> CommandProcessor command "dumpclass" produces classes with invalid field descriptors. >> >> Proposed patch fixes `sun.jvm.hotspot.oops.InstanceKlass::getFieldSignatureIndex` to return correct `getSignatureIndex` instead of invalid `getGenericSignatureIndex`. >> >> Added condition to `ClhsdbDumpclass` test assures no errors are reported by `javap` in the dumped classes. >> >> Please review. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > updated copyright header Thank you, I've updated test copyright header. Yes, it was identified when working on [JDK-8294969](https://bugs.openjdk.org/browse/JDK-8294969), however it is still work in progress. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13321#issuecomment-1496987115 From sspitsyn at openjdk.org Wed Apr 5 06:48:13 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 5 Apr 2023 06:48:13 GMT Subject: RFR: 8257967: JFR: Events for loaded agents [v15] In-Reply-To: <96JFUTmjTmM45mitEipdK8x2jqjo2uhqF42031X6LRQ=.11d4b13f-7d95-426a-8fc9-50e7dfb8f8ab@github.com> References: <5cFyTNQZjfRp6VlzOqkgdwhoSGaX92KNL3EZlv-NrpY=.fae84f7f-f1d4-4354-a123-33ab97928dcf@github.com> <96JFUTmjTmM45mitEipdK8x2jqjo2uhqF42031X6LRQ=.11d4b13f-7d95-426a-8fc9-50e7dfb8f8ab@github.com> Message-ID: <_qDvAFz7h-1lyB_hYlBCN6Za8wQlvJZriTDHVIYXmB4=.9ce998bf-5d9c-449e-9ec7-937fcd224f97@github.com> On Tue, 4 Apr 2023 14:41:13 GMT, Markus Gr?nlund wrote: >> src/hotspot/share/prims/agent.hpp line 1: >> >>> 1: /* >> >> The name for class and file is too general. >> I'm thinking if renaming the files to jvmtiAgent and the class to JvmtiAgent would work. >> In general, there exists a convention to name JVMTI file with the "jvmti" prefix. >> It is a gray zone between Runtime and JVMTI but seems to belong more to JVMTI. >> The same about the AgentList class and file. >> Also, these new files are good candidates to add here: >> >> make/hotspot/lib/JvmFeatures.gmk: >> ifneq ($(call check-jvm-feature, jvmti), true) >> JVM_CFLAGS_FEATURES += -DINCLUDE_JVMTI=0 >> JVM_EXCLUDE_FILES += jvmtiGetLoadedClasses.cpp jvmtiThreadState.cpp jvmtiExtensions.cpp \ >> jvmtiImpl.cpp jvmtiManageCapabilities.cpp jvmtiRawMonitor.cpp jvmtiUtil.cpp jvmtiTrace.cpp \ >> jvmtiCodeBlobEvents.cpp jvmtiEnv.cpp jvmtiRedefineClasses.cpp jvmtiEnvBase.cpp jvmtiEnvThreadState.cpp \ >> jvmtiTagMap.cpp jvmtiEventController.cpp evmCompat.cpp jvmtiEnter.xsl jvmtiExport.cpp \ >> jvmtiClassFileReconstituter.cpp jvmtiTagMapTable.cpp >> endif > > Hi Serguei, thanks for taking a look. > > I have updated with the names you suggested. Thanks. Thank you for the update. It looks good to me. I still need to finish my review. Sorry for the latency. It is is a busy time now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12923#discussion_r1158087046 From sspitsyn at openjdk.org Wed Apr 5 06:59:18 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 5 Apr 2023 06:59:18 GMT Subject: RFR: 8257967: JFR: Events for loaded agents [v15] In-Reply-To: References: <5cFyTNQZjfRp6VlzOqkgdwhoSGaX92KNL3EZlv-NrpY=.fae84f7f-f1d4-4354-a123-33ab97928dcf@github.com> Message-ID: On Mon, 3 Apr 2023 12:59:12 GMT, Markus Gr?nlund wrote: >> src/hotspot/share/prims/agentList.cpp line 204: >> >>> 202: >>> 203: // Invokes Agent_OnAttach for agents loaded dynamically during runtime. >>> 204: jint AgentList::load_agent(const char* agent_name, const char* absParam, >> >> I feel that it is better to keep the original function name "load_agent_library". As you listed there two kinds of agents: Java and Native. The function name give a hint it is native agent. Also, it is better to avoid changes that aren't really necessary. > > I changed the names because I found it very hard to understand what the old names represented: "AgentLibrary" vs "Library"? "add_init_agent" vs "add_instrumentation_agent", or even "add_loaded_agent"? Also a bit confusing that "load_agent_library" would also include statically linked agents - no library is loaded there. Okay. Refactoring is usually not easy to review. With a renaming it becomes harder, so it is better to be conservative. There are other side effects to consider: - back porting also becomes harder - developers have to learn new names instead of already known The good side is that your refactoring consolidates this code in a well known locations. :-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12923#discussion_r1158094815 From dholmes at openjdk.org Wed Apr 5 07:32:14 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 5 Apr 2023 07:32:14 GMT Subject: RFR: 8305511: Remove ignore from com/sun/jdi/PopAndInvokeTest.java In-Reply-To: References: Message-ID: On Tue, 4 Apr 2023 03:18:37 GMT, Leonid Mesnik wrote: > Test com/sun/jdi/PopAndInvokeTest.java has > @ignore 6951287 > bug 6951287 is closed as a dup for 6417053 which is closed as not reproduced. The test fails in tier5 in our CI. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13317#issuecomment-1497045710 From sspitsyn at openjdk.org Wed Apr 5 07:52:07 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 5 Apr 2023 07:52:07 GMT Subject: RFR: 8303563: GetCurrentThreadCpuTime and GetThreadCpuTime need further clarification for virtual threads In-Reply-To: References: Message-ID: On Tue, 4 Apr 2023 20:33:46 GMT, Serguei Spitsyn wrote: > This is a follow-up to [JDK-8302615](https://bugs.openjdk.org/browse/JDK-8302615) where GetCurrentThreadCpuTime and GetThreadCpuTime were changed from being not supported to optional, when called from/with a virtual thread. There are two additional sentences that need adjustment to avoid creating a conflict in the spec. > > In the functions `GetCurrentThreadCpuTime` and `GetThreadCpuTime`: > > The fragment: > `"The current thread may not be a virtual thread. Otherwise, the error code"` > > is replaced with: > > "An implementation is not required to support this function > when the current thread is a virtual thread, in which case" > > > CSR: [JDK-8305617](https://bugs.openjdk.org/browse/JDK-8305617) Thank you for review, David and Alan! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13338#issuecomment-1497065943 From jwaters at openjdk.org Wed Apr 5 09:39:19 2023 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 5 Apr 2023 09:39:19 GMT Subject: RFR: 8305341: Alignment should be enforced by alignas instead of compiler specific attributes [v2] In-Reply-To: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com> References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com> Message-ID: > C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision: - gcc offset_of - Remove Visual C++ alignment - Remove gcc alignment - globalDefinitions.hpp - Merge branch 'openjdk:master' into patch-6 - - GSSLibStub.c - ArrayReferenceImpl.c - Alignment outside of HotSpot should be enforced by alignas instead of compiler specific attributes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13258/files - new: https://git.openjdk.org/jdk/pull/13258/files/7e5e6449..7dc7f7d8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13258&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13258&range=00-01 Stats: 16524 lines in 394 files changed: 7231 ins; 8051 del; 1242 mod Patch: https://git.openjdk.org/jdk/pull/13258.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13258/head:pull/13258 PR: https://git.openjdk.org/jdk/pull/13258 From jwaters at openjdk.org Wed Apr 5 09:39:22 2023 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 5 Apr 2023 09:39:22 GMT Subject: RFR: 8305341: Alignment should be enforced by alignas instead of compiler specific attributes In-Reply-To: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com> References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com> Message-ID: <648nGU6epXFxCy9rfbKldQsb_LN7wqrjkzQMN9n3z98=.4d090b19-8f13-4740-a595-17b0564d3a54@github.com> On Fri, 31 Mar 2023 06:07:39 GMT, Julian Waters wrote: > C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements Hmm, right I'll link that issue into this one as well then ------------- PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1497188210 From mgronlun at openjdk.org Wed Apr 5 09:48:23 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 5 Apr 2023 09:48:23 GMT Subject: RFR: 8257967: JFR: Events for loaded agents [v15] In-Reply-To: References: <5cFyTNQZjfRp6VlzOqkgdwhoSGaX92KNL3EZlv-NrpY=.fae84f7f-f1d4-4354-a123-33ab97928dcf@github.com> Message-ID: On Wed, 5 Apr 2023 06:55:16 GMT, Serguei Spitsyn wrote: >> I changed the names because I found it very hard to understand what the old names represented: "AgentLibrary" vs "Library"? "add_init_agent" vs "add_instrumentation_agent", or even "add_loaded_agent"? Also a bit confusing that "load_agent_library" would also include statically linked agents - no library is loaded there. > > Okay. > Refactoring is usually not easy to review. > With a renaming it becomes harder, so it is better to be conservative. > > There are other side effects to consider: > > - back porting also becomes harder > - developers have to learn new names instead of already known > > The good side is that your refactoring consolidates this code in a well known locations. :-) Of course, I would not have changed this unless I believe it improves things. The abstraction is now better from the perspective of the rest of the VM. There are now only JVMTI agents, and they are kept in a list. Arguments.cpp adds agents to the list. The same thing for the diagnosticCommand.cpp for dynamically loaded agents. Threads.cpp loads the JVMTI agents, java.cpp unloads agents. All other sites take out an iterator of the subtypes they want to iterate. There is no longer any separation between "agent" and "library"; the subtypes of the agents are now abstracted away. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12923#discussion_r1158282424 From mgronlun at openjdk.org Wed Apr 5 09:48:21 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 5 Apr 2023 09:48:21 GMT Subject: RFR: 8257967: JFR: Events for loaded agents [v16] In-Reply-To: References: Message-ID: On Wed, 5 Apr 2023 01:48:19 GMT, David Holmes wrote: > Renamings look good to me. Thank you for your review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/12923#issuecomment-1497209787 From rkennke at openjdk.org Wed Apr 5 10:40:54 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 5 Apr 2023 10:40:54 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v54] In-Reply-To: References: Message-ID: > This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). > > What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. > > This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p rotocols. > > The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare. > > In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. > > One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. > > As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. > > This change enables to simplify (and speed-up!) a lot of code: > > - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. > - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR > > Also, and I might be mistaken here, this new lightweight locking would make synchronized work better with Loom: Because the lock-records are no longer scattered across the stack, but instead are densely packed into the lock-stack, it should be easy for a vthread to save its lock-stack upon unmounting and restore it when re-mounting. However, I am not sure about this, and this PR does not attempt to implement that support. > > Testing: > - [x] tier1 x86_64 x aarch64 x +UseFastLocking > - [x] tier2 x86_64 x aarch64 x +UseFastLocking > - [x] tier3 x86_64 x aarch64 x +UseFastLocking > - [x] tier4 x86_64 x aarch64 x +UseFastLocking > - [x] tier1 x86_64 x aarch64 x -UseFastLocking > - [x] tier2 x86_64 x aarch64 x -UseFastLocking > - [x] tier3 x86_64 x aarch64 x -UseFastLocking > - [x] tier4 x86_64 x aarch64 x -UseFastLocking > - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet > > ### Performance > > #### Simple Microbenchmark > > The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops. > > | | x86_64 | aarch64 | > | -- | -- | -- | > | -UseFastLocking | 20.651 | 20.764 | > | +UseFastLocking | 18.896 | 18.908 | > > > #### Renaissance > > ? | x86_64 | ? | ? | ? | aarch64 | ? | ? > -- | -- | -- | -- | -- | -- | -- | -- > ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? > AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% > Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21% > Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% > ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% > GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% > LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% > MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%% > NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% > PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% > FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% > FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% > ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34% > Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% > RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% > Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% > ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% > FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% > FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Named constants for LockingMode ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10907/files - new: https://git.openjdk.org/jdk/pull/10907/files/839f350b..baf71624 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=53 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=52-53 Stats: 157 lines in 37 files changed: 9 ins; 0 del; 148 mod Patch: https://git.openjdk.org/jdk/pull/10907.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/10907/head:pull/10907 PR: https://git.openjdk.org/jdk/pull/10907 From asotona at openjdk.org Wed Apr 5 13:23:26 2023 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 5 Apr 2023 13:23:26 GMT Subject: Integrated: 8305490: CommandProcessor command "dumpclass" produces classes with invalid field descriptors In-Reply-To: <8e2AC4JawGrdgbWH5PyuYPDNf2cYUPMIZ202DM-ujzA=.cf9602e1-d653-41b4-af4b-e4ef58606fcf@github.com> References: <8e2AC4JawGrdgbWH5PyuYPDNf2cYUPMIZ202DM-ujzA=.cf9602e1-d653-41b4-af4b-e4ef58606fcf@github.com> Message-ID: On Tue, 4 Apr 2023 07:44:40 GMT, Adam Sotona wrote: > CommandProcessor command "dumpclass" produces classes with invalid field descriptors. > > Proposed patch fixes `sun.jvm.hotspot.oops.InstanceKlass::getFieldSignatureIndex` to return correct `getSignatureIndex` instead of invalid `getGenericSignatureIndex`. > > Added condition to `ClhsdbDumpclass` test assures no errors are reported by `javap` in the dumped classes. > > Please review. > > Thank you, > Adam This pull request has now been integrated. Changeset: 78ff454f Author: Adam Sotona URL: https://git.openjdk.org/jdk/commit/78ff454f1986abdb9b72d3c6c5b1f3bbab823540 Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod 8305490: CommandProcessor command "dumpclass" produces classes with invalid field descriptors Reviewed-by: cjplummer, fparain ------------- PR: https://git.openjdk.org/jdk/pull/13321 From dcubed at openjdk.org Wed Apr 5 14:08:29 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 5 Apr 2023 14:08:29 GMT Subject: Integrated: 8305659: ProblemList com/sun/jdi/PopAndInvokeTest.java with virtual threads Message-ID: A trivial fix to ProblemList com/sun/jdi/PopAndInvokeTest.java with virtual threads. ------------- Commit messages: - Fix the bugID to the proper one. - 8305659: ProblemList com/sun/jdi/PopAndInvokeTest.java with virtual threads Changes: https://git.openjdk.org/jdk/pull/13351/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13351&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8305659 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13351.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13351/head:pull/13351 PR: https://git.openjdk.org/jdk/pull/13351 From dcubed at openjdk.org Wed Apr 5 14:08:32 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 5 Apr 2023 14:08:32 GMT Subject: Integrated: 8305659: ProblemList com/sun/jdi/PopAndInvokeTest.java with virtual threads In-Reply-To: References: Message-ID: On Wed, 5 Apr 2023 14:00:25 GMT, Tobias Hartmann wrote: >> A trivial fix to ProblemList com/sun/jdi/PopAndInvokeTest.java with virtual threads. > > Looks good with now updated bug id. @TobiHartmann - Thanks for the fast review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13351#issuecomment-1497543061 From dcubed at openjdk.org Wed Apr 5 14:08:33 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 5 Apr 2023 14:08:33 GMT Subject: Integrated: 8305659: ProblemList com/sun/jdi/PopAndInvokeTest.java with virtual threads In-Reply-To: References: Message-ID: On Wed, 5 Apr 2023 13:51:59 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList com/sun/jdi/PopAndInvokeTest.java with virtual threads. This pull request has now been integrated. Changeset: 2e59d21e Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/2e59d21e5620e834cb55a69d23a16c44d6ca2393 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8305659: ProblemList com/sun/jdi/PopAndInvokeTest.java with virtual threads Reviewed-by: thartmann ------------- PR: https://git.openjdk.org/jdk/pull/13351 From thartmann at openjdk.org Wed Apr 5 14:08:31 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Wed, 5 Apr 2023 14:08:31 GMT Subject: Integrated: 8305659: ProblemList com/sun/jdi/PopAndInvokeTest.java with virtual threads In-Reply-To: References: Message-ID: On Wed, 5 Apr 2023 13:51:59 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList com/sun/jdi/PopAndInvokeTest.java with virtual threads. Looks good with now updated bug id. ------------- Marked as reviewed by thartmann (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13351#pullrequestreview-1372981707 From dcubed at openjdk.org Wed Apr 5 15:54:52 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 5 Apr 2023 15:54:52 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v54] In-Reply-To: References: Message-ID: On Wed, 5 Apr 2023 10:40:54 GMT, Roman Kennke wrote: >> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). >> >> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. >> >> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal protocols. >> >> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare. >> >> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. >> >> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. >> >> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. >> >> This change enables to simplify (and speed-up!) a lot of code: >> >> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. >> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR >> >> Also, and I might be mistaken here, this new lightweight locking would make synchronized work better with Loom: Because the lock-records are no longer scattered across the stack, but instead are densely packed into the lock-stack, it should be easy for a vthread to save its lock-stack upon unmounting and restore it when re-mounting. However, I am not sure about this, and this PR does not attempt to implement that support. >> >> Testing: >> - [x] tier1 x86_64 x aarch64 x +UseFastLocking >> - [x] tier2 x86_64 x aarch64 x +UseFastLocking >> - [x] tier3 x86_64 x aarch64 x +UseFastLocking >> - [x] tier4 x86_64 x aarch64 x +UseFastLocking >> - [x] tier1 x86_64 x aarch64 x -UseFastLocking >> - [x] tier2 x86_64 x aarch64 x -UseFastLocking >> - [x] tier3 x86_64 x aarch64 x -UseFastLocking >> - [x] tier4 x86_64 x aarch64 x -UseFastLocking >> - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet >> >> ### Performance >> >> #### Simple Microbenchmark >> >> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops. >> >> | | x86_64 | aarch64 | >> | -- | -- | -- | >> | -UseFastLocking | 20.651 | 20.764 | >> | +UseFastLocking | 18.896 | 18.908 | >> >> >> #### Renaissance >> >> ? | x86_64 | ? | ? | ? | aarch64 | ? | ? >> -- | -- | -- | -- | -- | -- | -- | -- >> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? >> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% >> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21% >> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% >> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% >> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% >> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% >> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%% >> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% >> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% >> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% >> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% >> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34% >> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% >> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% >> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% >> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% >> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% >> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% >> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% >> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% >> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Named constants for LockingMode v52 is failing quite a few JVM/TI tests with crashes that look like this: # Internal Error (/opt/mach5/mesos/work_dir/slaves/741e9afd-8c02-45c3-b2e2-9db1450d0832-S40935/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/b154597d-2ba7-420d-81c1-ef13f408c137/runs/d52e181d-f011-47c8-a35f-30fcbba5c164/workspace/open/src/hotspot/share/runtime/javaThread.hpp:983), pid=1112738, tid=1112747 # assert(t->is_Java_thread()) failed: incorrect cast to JavaThread # # JRE version: Java(TM) SE Runtime Environment (21.0) (fastdebug build 21-internal-LTS-2023-04-04-2141101.daniel.daugherty.8291555forjdk21.git) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 21-internal-LTS-2023-04-04-2141101.daniel.daugherty.8291555forjdk21.git, compiled mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-aarch64) # Problematic frame: # V [libjvm.so+0x155baa4] is_lock_owned(Thread*, oop)+0x254 snip Stack: [0x0000fffdb8970000,0x0000fffdb8b70000], sp=0x0000fffdb8b6d480, free space=2037k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x155baa4] is_lock_owned(Thread*, oop)+0x254 (javaThread.hpp:983) V [libjvm.so+0x15627d0] ObjectSynchronizer::FastHashCode(Thread*, oop)+0x720 (synchronizer.cpp:956) V [libjvm.so+0x12dbedc] oopDesc::slow_identity_hash()+0x68 (oop.cpp:112) V [libjvm.so+0x105f044] JvmtiTagMapTable::find(oop)+0x1c4 (oop.inline.hpp:364) V [libjvm.so+0x1056744] CallbackWrapper::CallbackWrapper(JvmtiTagMap*, oop)+0xa4 (jvmtiTagMap.cpp:222) V [libjvm.so+0x105c538] CallbackInvoker::invoke_advanced_stack_ref_callback(jvmtiHeapReferenceKind, long, long, int, _jmethodID*, long, int, oop)+0x158 (jvmtiTagMap.cpp:1754) V [libjvm.so+0x105d688] JNILocalRootsClosure::do_oop(oop*)+0x168 (jvmtiTagMap.cpp:2019) V [libjvm.so+0xe8bac8] JNIHandleBlock::oops_do(OopClosure*)+0x68 (jniHandles.cpp:411) V [libjvm.so+0x105ddbc] VM_HeapWalkOperation::collect_stack_roots(JavaThread*, JNILocalRootsClosure*)+0x6dc (jvmtiTagMap.cpp:2725) V [libjvm.so+0x105e368] VM_HeapWalkOperation::collect_stack_roots()+0x138 (jvmtiTagMap.cpp:2772) V [libjvm.so+0x10555f0] VM_HeapWalkOperation::doit()+0x6e0 (jvmtiTagMap.cpp:2827) V [libjvm.so+0x1686ac0] VM_Operation::evaluate()+0x120 (vmOperations.cpp:71) V [libjvm.so+0x16b2710] VMThread::evaluate_operation(VM_Operation*)+0xd0 (vmThread.cpp:281) V [libjvm.so+0x16b3204] VMThread::inner_execute(VM_Operation*)+0x374 (vmThread.cpp:428) V [libjvm.so+0x16b33fc] VMThread::loop()+0x8c (vmThread.cpp:495) V [libjvm.so+0x16b352c] VMThread::run()+0x9c (vmThread.cpp:175) V [libjvm.so+0x15ad4b0] Thread::call_run()+0xac (thread.cpp:224) V [libjvm.so+0x130c0a8] thread_native_entry(Thread*)+0x134 (os_linux.cpp:740) C [libpthread.so.0+0x7908] start_thread+0x188 This code block in `ObjectSynchronizer::FastHashCode()`: // Fall thru so we only have one place that installs the hash in // the ObjectMonitor. } else if (LockingMode == 2 && mark.is_fast_locked() && is_lock_owned(current, obj)) { // This is a fast-lock owned by the calling thread so use the // markWord from the object. hash = mark.hash(); if (hash != 0) { // if it has a hash, just return it return hash; } } else if (LockingMode == 1 && mark.has_locker() && current->is_lock_owned((address)mark.locker())) { is calling this static function: static bool is_lock_owned(Thread* thread, oop obj) { assert(LockingMode == 2, "only call this with new lightweight locking enabled"); return JavaThread::cast(thread)->lock_stack().contains(obj); } and that function used to look like this: static bool is_lock_owned(Thread* thread, oop obj) { assert(LockingMode == 2, "only call this with new lightweight locking enabled"); - return thread->is_Java_thread() ? JavaThread::cast(thread)->lock_stack().contains(obj) : false; + return JavaThread::cast(thread)->lock_stack().contains(obj); } so that `thread->is_Java_thread()` check is needed since the VMThread is the one that's making this`is_lock_owned()` check as part of a hashcode operation. There are 129 test failures in Mach5 Tier4 and 769 test failures in Mach5 Tier5. I don't know yet whether all are due to: # Internal Error (/opt/mach5/mesos/work_dir/slaves/741e9afd-8c02-45c3-b2e2-9db1450d0832-S40935/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/b154597d-2ba7-420d-81c1-ef13f408c137/runs/d52e181d-f011-47c8-a35f-30fcbba5c164/workspace/open/src/hotspot/share/runtime/javaThread.hpp:983), pid=1112738, tid=1112747 # assert(t->is_Java_thread()) failed: incorrect cast to JavaThread ------------- PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1497720340 PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1497725623 From rriggs at openjdk.org Wed Apr 5 16:06:25 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 5 Apr 2023 16:06:25 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply Message-ID: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. The enumeration values are defined to match those used in the build. The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE` Note that `amd64` and `x86_64` in the build are represented by `X64`. The values of the system property `os.arch` is unchanged. The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). Uses in `java.base` and a few others are included but other modules will be done in separate PRs. ------------- Commit messages: - 8304915: Create jdk.internal.util.Architecture enum and apply Changes: https://git.openjdk.org/jdk/pull/13357/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304915 Stats: 279 lines in 10 files changed: 265 ins; 3 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/13357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13357/head:pull/13357 PR: https://git.openjdk.org/jdk/pull/13357 From rkennke at openjdk.org Wed Apr 5 16:17:44 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 5 Apr 2023 16:17:44 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v55] In-Reply-To: References: Message-ID: > This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). > > What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. > > This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p rotocols. > > The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare. > > In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. > > One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. > > As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. > > This change enables to simplify (and speed-up!) a lot of code: > > - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. > - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR > > Also, and I might be mistaken here, this new lightweight locking would make synchronized work better with Loom: Because the lock-records are no longer scattered across the stack, but instead are densely packed into the lock-stack, it should be easy for a vthread to save its lock-stack upon unmounting and restore it when re-mounting. However, I am not sure about this, and this PR does not attempt to implement that support. > > Testing: > - [x] tier1 x86_64 x aarch64 x +UseFastLocking > - [x] tier2 x86_64 x aarch64 x +UseFastLocking > - [x] tier3 x86_64 x aarch64 x +UseFastLocking > - [x] tier4 x86_64 x aarch64 x +UseFastLocking > - [x] tier1 x86_64 x aarch64 x -UseFastLocking > - [x] tier2 x86_64 x aarch64 x -UseFastLocking > - [x] tier3 x86_64 x aarch64 x -UseFastLocking > - [x] tier4 x86_64 x aarch64 x -UseFastLocking > - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet > > ### Performance > > #### Simple Microbenchmark > > The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops. > > | | x86_64 | aarch64 | > | -- | -- | -- | > | -UseFastLocking | 20.651 | 20.764 | > | +UseFastLocking | 18.896 | 18.908 | > > > #### Renaissance > > ? | x86_64 | ? | ? | ? | aarch64 | ? | ? > -- | -- | -- | -- | -- | -- | -- | -- > ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? > AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% > Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21% > Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% > ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% > GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% > LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% > MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%% > NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% > PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% > FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% > FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% > ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34% > Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% > RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% > Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% > ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% > FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% > FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Put back thread type check in OS::is_lock_owned() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10907/files - new: https://git.openjdk.org/jdk/pull/10907/files/baf71624..963de0ef Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=54 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=53-54 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10907.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/10907/head:pull/10907 PR: https://git.openjdk.org/jdk/pull/10907 From duke at openjdk.org Wed Apr 5 16:26:15 2023 From: duke at openjdk.org (Glavo) Date: Wed, 5 Apr 2023 16:26:15 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Wed, 5 Apr 2023 15:58:08 GMT, Roger Riggs wrote: > Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. > The enumeration values are defined to match those used in the build. > The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE` > Note that `amd64` and `x86_64` in the build are represented by `X64`. > The values of the system property `os.arch` is unchanged. > > The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). > Uses in `java.base` and a few others are included but other modules will be done in separate PRs. src/java.base/share/classes/jdk/internal/util/Architecture.java line 77: > 75: * {@return {@code true} if the current architecture is IA64} > 76: */ > 77: public static boolean isIA64() { Why is the name case correct only for IA-64, while `AArch64`, `RISC-V 64` and other architectures only have the first letter capitalized? I think names like `isRiscv64`, `isPpc64le`, and `isAarch64` are quite ugly, and there is no precedent yet. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1158748071 From erikj at openjdk.org Wed Apr 5 16:40:06 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 5 Apr 2023 16:40:06 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Wed, 5 Apr 2023 15:58:08 GMT, Roger Riggs wrote: > Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. > The enumeration values are defined to match those used in the build. > The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE` > Note that `amd64` and `x86_64` in the build are represented by `X64`. > The values of the system property `os.arch` is unchanged. > > The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). > Uses in `java.base` and a few others are included but other modules will be done in separate PRs. Looks good from a build point of view. ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13357#pullrequestreview-1373301135 From dcubed at openjdk.org Wed Apr 5 16:50:54 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 5 Apr 2023 16:50:54 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v55] In-Reply-To: References: Message-ID: On Wed, 5 Apr 2023 16:17:44 GMT, Roman Kennke wrote: >> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). >> >> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. >> >> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal protocols. >> >> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare. >> >> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. >> >> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. >> >> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. >> >> This change enables to simplify (and speed-up!) a lot of code: >> >> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. >> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR >> >> Also, and I might be mistaken here, this new lightweight locking would make synchronized work better with Loom: Because the lock-records are no longer scattered across the stack, but instead are densely packed into the lock-stack, it should be easy for a vthread to save its lock-stack upon unmounting and restore it when re-mounting. However, I am not sure about this, and this PR does not attempt to implement that support. >> >> Testing: >> - [x] tier1 x86_64 x aarch64 x +UseFastLocking >> - [x] tier2 x86_64 x aarch64 x +UseFastLocking >> - [x] tier3 x86_64 x aarch64 x +UseFastLocking >> - [x] tier4 x86_64 x aarch64 x +UseFastLocking >> - [x] tier1 x86_64 x aarch64 x -UseFastLocking >> - [x] tier2 x86_64 x aarch64 x -UseFastLocking >> - [x] tier3 x86_64 x aarch64 x -UseFastLocking >> - [x] tier4 x86_64 x aarch64 x -UseFastLocking >> - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet >> >> ### Performance >> >> #### Simple Microbenchmark >> >> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops. >> >> | | x86_64 | aarch64 | >> | -- | -- | -- | >> | -UseFastLocking | 20.651 | 20.764 | >> | +UseFastLocking | 18.896 | 18.908 | >> >> >> #### Renaissance >> >> ? | x86_64 | ? | ? | ? | aarch64 | ? | ? >> -- | -- | -- | -- | -- | -- | -- | -- >> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? >> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% >> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21% >> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% >> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% >> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% >> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% >> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%% >> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% >> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% >> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% >> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% >> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34% >> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% >> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% >> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% >> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% >> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% >> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% >> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% >> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% >> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Put back thread type check in OS::is_lock_owned() I'm worried that I'll run into more cases where a JavaThread check was removed. However, I'll start with this: $ git diff diff --git a/src/hotspot/share/runtime/synchronizer.cpp b/src/hotspot/share/runtime/synchronizer.cpp index bf8afffd693..3c269885f97 100644 --- a/src/hotspot/share/runtime/synchronizer.cpp +++ b/src/hotspot/share/runtime/synchronizer.cpp @@ -894,9 +894,11 @@ static inline intptr_t get_next_hash(Thread* current, oop obj) { return value; } +// Can be called from non JavaThreads (e.g., VMThread) for FastHashCode +// calculations as part of JVM/TI tagging. static bool is_lock_owned(Thread* thread, oop obj) { assert(LockingMode == 2, "only call this with new lightweight locking enabled"); - return JavaThread::cast(thread)->lock_stack().contains(obj); + return thread->is_Java_thread() ? JavaThread::cast(thread)->lock_stack().contains(obj) : false; } intptr_t ObjectSynchronizer::FastHashCode(Thread* current, oop obj) { and see what else testing shakes out. ------------- PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1497815036 From rriggs at openjdk.org Wed Apr 5 17:18:15 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 5 Apr 2023 17:18:15 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: <9Nk_HYxa54gfYKJSJbxMZ-HRVyzjeGK7U9kf98E9DIE=.73c87a07-e254-44b8-882d-8c46fab92d15@github.com> On Wed, 5 Apr 2023 16:23:08 GMT, Glavo wrote: >> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. >> The enumeration values are defined to match those used in the build. >> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE` >> Note that `amd64` and `x86_64` in the build are represented by `X64`. >> The values of the system property `os.arch` is unchanged. >> >> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). >> Uses in `java.base` and a few others are included but other modules will be done in separate PRs. > > src/java.base/share/classes/jdk/internal/util/Architecture.java line 77: > >> 75: * {@return {@code true} if the current architecture is IA64} >> 76: */ >> 77: public static boolean isIA64() { > > Why is the name case correct only for IA-64, while `AArch64`, `RISC-V 64` and other architectures only have the first letter capitalized? > > I think names like `isRiscv64`, `isPpc64le`, and `isAarch64` are quite ugly, and there is no precedent yet. Yes, the capitalization names should be disciplined. In the enum, there are all uppercase, following the style of manifest constants and enums. In the build they are always lower case. Camel case is usually used for method names. Using all upper case would make them consistent with the Enum names. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1158801096 From duke at openjdk.org Wed Apr 5 17:41:04 2023 From: duke at openjdk.org (Glavo) Date: Wed, 5 Apr 2023 17:41:04 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply In-Reply-To: <9Nk_HYxa54gfYKJSJbxMZ-HRVyzjeGK7U9kf98E9DIE=.73c87a07-e254-44b8-882d-8c46fab92d15@github.com> References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> <9Nk_HYxa54gfYKJSJbxMZ-HRVyzjeGK7U9kf98E9DIE=.73c87a07-e254-44b8-882d-8c46fab92d15@github.com> Message-ID: On Wed, 5 Apr 2023 17:15:13 GMT, Roger Riggs wrote: > Yes, the capitalization names should be disciplined. In the enum, there are all uppercase, following the style of manifest constants and enums. In the build they are always lower case. Camel case is usually used for method names. Using all upper case would make them consistent with the Enum names. What I mean is, should we rename these methods? Because they are really ugly. https://github.com/openjdk/jdk/blob/0c61382dc50fdc66d3e2b9a9975ac31d91890a5e/src/java.base/share/classes/jdk/internal/util/Architecture.java#L91 https://github.com/openjdk/jdk/blob/0c61382dc50fdc66d3e2b9a9975ac31d91890a5e/src/java.base/share/classes/jdk/internal/util/Architecture.java#L105 https://github.com/openjdk/jdk/blob/0c61382dc50fdc66d3e2b9a9975ac31d91890a5e/src/java.base/share/classes/jdk/internal/util/Architecture.java#L112 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1158823225 From rriggs at openjdk.org Wed Apr 5 18:53:12 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 5 Apr 2023 18:53:12 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v2] In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: <9lnZlVpDi3KGYMVOhH2747WWOXbQjR5wqge69MvhMVs=.6b59dacd-19d0-4c5b-9869-11e31db3219a@github.com> > Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. > The enumeration values are defined to match those used in the build. > The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE` > Note that `amd64` and `x86_64` in the build are represented by `X64`. > The values of the system property `os.arch` is unchanged. > > The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). > Uses in `java.base` and a few others are included but other modules will be done in separate PRs. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Rename isXXX method to be uppercase architecture names matching the enum. Refactor the is64Bit method to be a static method for the current runtime. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13357/files - new: https://git.openjdk.org/jdk/pull/13357/files/0c61382d..bef30f96 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=00-01 Stats: 72 lines in 5 files changed: 35 ins; 13 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/13357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13357/head:pull/13357 PR: https://git.openjdk.org/jdk/pull/13357 From duke at openjdk.org Wed Apr 5 18:55:19 2023 From: duke at openjdk.org (Glavo) Date: Wed, 5 Apr 2023 18:55:19 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v2] In-Reply-To: <9lnZlVpDi3KGYMVOhH2747WWOXbQjR5wqge69MvhMVs=.6b59dacd-19d0-4c5b-9869-11e31db3219a@github.com> References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> <9lnZlVpDi3KGYMVOhH2747WWOXbQjR5wqge69MvhMVs=.6b59dacd-19d0-4c5b-9869-11e31db3219a@github.com> Message-ID: On Wed, 5 Apr 2023 18:53:12 GMT, Roger Riggs wrote: >> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. >> The enumeration values are defined to match those used in the build. >> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE` >> Note that `amd64` and `x86_64` in the build are represented by `X64`. >> The values of the system property `os.arch` is unchanged. >> >> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). >> Uses in `java.base` and a few others are included but other modules will be done in separate PRs. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Rename isXXX method to be uppercase architecture names matching the enum. > Refactor the is64Bit method to be a static method for the current runtime. src/java.base/share/classes/jdk/internal/util/Architecture.java line 85: > 83: */ > 84: @ForceInline > 85: public static boolean isRISCV() { I think it should be named `isRISCV64` because RISC-V also has a 32-bit variant, so the name `isRISCV` may cause confusion. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1158897476 From rriggs at openjdk.org Wed Apr 5 19:05:03 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 5 Apr 2023 19:05:03 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v3] In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: > Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. > The enumeration values are defined to match those used in the build. > The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE` > Note that `amd64` and `x86_64` in the build are represented by `X64`. > The values of the system property `os.arch` is unchanged. > > The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). > Uses in `java.base` and a few others are included but other modules will be done in separate PRs. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Correct name of isRISCV64 method. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13357/files - new: https://git.openjdk.org/jdk/pull/13357/files/bef30f96..3349b46d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=01-02 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13357/head:pull/13357 PR: https://git.openjdk.org/jdk/pull/13357 From rriggs at openjdk.org Wed Apr 5 19:20:08 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 5 Apr 2023 19:20:08 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v4] In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: > Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. > The enumeration values are defined to match those used in the build. > The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE` > Note that `amd64` and `x86_64` in the build are represented by `X64`. > The values of the system property `os.arch` is unchanged. > > The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). > Uses in `java.base` and a few others are included but other modules will be done in separate PRs. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Correct spelling of isAARCH64 in WIndows AttachProviderImpl ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13357/files - new: https://git.openjdk.org/jdk/pull/13357/files/3349b46d..8916dcae Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13357/head:pull/13357 PR: https://git.openjdk.org/jdk/pull/13357 From dcubed at openjdk.org Wed Apr 5 19:37:45 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 5 Apr 2023 19:37:45 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v55] In-Reply-To: References: Message-ID: On Wed, 5 Apr 2023 16:17:44 GMT, Roman Kennke wrote: >> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). >> >> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. >> >> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal protocols. >> >> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare. >> >> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. >> >> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. >> >> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. >> >> This change enables to simplify (and speed-up!) a lot of code: >> >> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. >> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR >> >> Also, and I might be mistaken here, this new lightweight locking would make synchronized work better with Loom: Because the lock-records are no longer scattered across the stack, but instead are densely packed into the lock-stack, it should be easy for a vthread to save its lock-stack upon unmounting and restore it when re-mounting. However, I am not sure about this, and this PR does not attempt to implement that support. >> >> Testing: >> - [x] tier1 x86_64 x aarch64 x +UseFastLocking >> - [x] tier2 x86_64 x aarch64 x +UseFastLocking >> - [x] tier3 x86_64 x aarch64 x +UseFastLocking >> - [x] tier4 x86_64 x aarch64 x +UseFastLocking >> - [x] tier1 x86_64 x aarch64 x -UseFastLocking >> - [x] tier2 x86_64 x aarch64 x -UseFastLocking >> - [x] tier3 x86_64 x aarch64 x -UseFastLocking >> - [x] tier4 x86_64 x aarch64 x -UseFastLocking >> - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet >> >> ### Performance >> >> #### Simple Microbenchmark >> >> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops. >> >> | | x86_64 | aarch64 | >> | -- | -- | -- | >> | -UseFastLocking | 20.651 | 20.764 | >> | +UseFastLocking | 18.896 | 18.908 | >> >> >> #### Renaissance >> >> ? | x86_64 | ? | ? | ? | aarch64 | ? | ? >> -- | -- | -- | -- | -- | -- | -- | -- >> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? >> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% >> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21% >> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% >> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% >> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% >> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% >> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%% >> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% >> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% >> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% >> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% >> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34% >> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% >> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% >> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% >> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% >> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% >> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% >> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% >> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% >> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Put back thread type check in OS::is_lock_owned() All 8 test tasks that failed in my Tier4 passed with the patch that I posted above. The Tier4 is still not yet complete, but I'm going to go ahead and retest Tier5 to see if anything else shakes out. @rkennke - Please consider adding the comment I mentioned above: +// Can be called from non JavaThreads (e.g., VMThread) for FastHashCode +// calculations as part of JVM/TI tagging. static bool is_lock_owned(Thread* thread, oop obj) { That should prevent anyone from thinking that `is_lock_owned` can be optimized again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1498013391 From cjplummer at openjdk.org Wed Apr 5 19:54:12 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 5 Apr 2023 19:54:12 GMT Subject: RFR: 8305607: Remove some unused test parameters in com/sun/jdi tests In-Reply-To: References: Message-ID: On Tue, 4 Apr 2023 20:15:41 GMT, Leonid Mesnik wrote: > Some tests set debugee name which is set by startUp() method. > > The test/jdk/com/sun/jdi/RedefineNestmateAttr/TestNestmateAttr.java set classpath which is not required. Do I understand correctly that this bug just caused the debuggee to appear twice in the arguments, leading to output like the following: [2ms] run args: [RefTypes, RefTypes] In this case it was harmless because the 2nd "RefTypes" gets passed as an arg to the RefTypes debuggee, which just ignored it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13337#issuecomment-1498032324 From cjplummer at openjdk.org Wed Apr 5 20:12:14 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 5 Apr 2023 20:12:14 GMT Subject: RFR: 8305608: Change VMConnection to use "test.class.path"instead of "test.classes" In-Reply-To: <3Xyc3nRyd_hr8fw7XQcAqsSv3UQg2wnsnp7fdvTYteo=.c1381ed9-25c5-4fe5-b4bd-1df7e73d3572@github.com> References: <3Xyc3nRyd_hr8fw7XQcAqsSv3UQg2wnsnp7fdvTYteo=.c1381ed9-25c5-4fe5-b4bd-1df7e73d3572@github.com> Message-ID: On Wed, 5 Apr 2023 01:05:44 GMT, Serguei Spitsyn wrote: >> The "test.class.path" is complete classpath required to run test. It included test.classes as well as testlibrary and some other classes. The tests located in com/sun/jdi/ uses 'com/sun/jdi' as a testlibrary. >> The better comment would be >> // When we run jtreg with plugin, the full classpath including testlibrary is required to use TestScaffold is required >> >> However, before fixing this comment I would like to see if there are any objections against using "test.class.path" in all cases. It would minimize difference in virtual and standard mode. >> Is there are any reason to use "test.classes" at all? > > I'd prefer to always use the "test.class.path" as it is a complete classpath required to run test. > >> The better comment would be >> // When we run jtreg with plugin, the full classpath including testlibrary is required to use TestScaffold is required > > I guess, you are going to remove this duplication with "is required". :) I think the CR should explain this test.classes vs test.class.path difference, and also explain why the classpath requirements are different when using virtual threads. You say that "TestScaffold should be also in classpath", but don't explain why. It's also not clear to me why only tests that are in subdirs are impacted when running with the wrapper. Also, when you say "When we run jtreg with plugin..", do you mean with the wrapper, not the plugin? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13339#discussion_r1158962727 From amenkov at openjdk.org Wed Apr 5 20:21:12 2023 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 5 Apr 2023 20:21:12 GMT Subject: RFR: 8299414: JVMTI FollowReferences should support references from VirtualThread stack Message-ID: <6oQOD_egcB3HyuagMWGSPLjKSE3JkaI2K2WOsDK1Cww=.c568223b-5100-4425-a4b7-defbd812a9ff@github.com> The fix updates JVMTI FollowReferences implementation to report references from virtual threads: - added heap scanning to report unmounted vthreads; - stacks of mounted vthreads are splitted into 2 parts (vittual thread stack and carrier thread stack), references are reported with correct thread id/class and object tags/frame depth; - common code to handle stack frames are moved into separate class; ------------- Commit messages: - tab - improved test - Merge branch 'openjdk:master' into vthread_follow_ref - update - tabs again - tabs - update - proto Changes: https://git.openjdk.org/jdk/pull/13254/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13254&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299414 Stats: 733 lines in 3 files changed: 636 ins; 86 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/13254.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13254/head:pull/13254 PR: https://git.openjdk.org/jdk/pull/13254 From cjplummer at openjdk.org Wed Apr 5 20:21:16 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 5 Apr 2023 20:21:16 GMT Subject: RFR: 8299414: JVMTI FollowReferences should support references from VirtualThread stack In-Reply-To: <6oQOD_egcB3HyuagMWGSPLjKSE3JkaI2K2WOsDK1Cww=.c568223b-5100-4425-a4b7-defbd812a9ff@github.com> References: <6oQOD_egcB3HyuagMWGSPLjKSE3JkaI2K2WOsDK1Cww=.c568223b-5100-4425-a4b7-defbd812a9ff@github.com> Message-ID: On Thu, 30 Mar 2023 22:58:12 GMT, Alex Menkov wrote: > The fix updates JVMTI FollowReferences implementation to report references from virtual threads: > - added heap scanning to report unmounted vthreads; > - stacks of mounted vthreads are splitted into 2 parts (vittual thread stack and carrier thread stack), references are reported with correct thread id/class and object tags/frame depth; > - common code to handle stack frames are moved into separate class; test/hotspot/jtreg/serviceability/jvmti/vthread/FollowReferences/VThreadStackRefTest.java line 54: > 52: } > 53: } > 54: await(dumpedLatch); await() seems unnecessary given the use the !timeToStop flag. test/hotspot/jtreg/serviceability/jvmti/vthread/FollowReferences/VThreadStackRefTest.java line 83: > 81: System.out.println(referenced.getClass()); > 82: }); > 83: vthreadEnded.join(); Add comment that says something like "Make sure this vthread has exited so we can test that it no longer holds any stack references". test/hotspot/jtreg/serviceability/jvmti/vthread/FollowReferences/VThreadStackRefTest.java line 85: > 83: vthreadEnded.join(); > 84: > 85: Thread.sleep(2000); // wait for reference and unmount I think what you mean is you need to wait until the threads have made enough progress to create the references, and then you need to wait until they have had a chance to amount due to the await() call. This should be made more clear in the comments. BTW, you could choose to get JVMTI VIRTUAL_THREAD_UNMOUNT events, and instead block here until you get them all, but doing a sleep is a lot easier. test/hotspot/jtreg/serviceability/jvmti/vthread/FollowReferences/VThreadStackRefTest.java line 94: > 92: // expected to be unreported as stack local > 93: new TestCase(VThreadUnmountedEnded.class, 0, 0) > 94: }; I think it would be useful the have a test case which has expected_cnt > 1. test/hotspot/jtreg/serviceability/jvmti/vthread/FollowReferences/libVThreadStackRefTest.cpp line 72: > 70: jvmtiHeapReferenceInfoStackLocal *stackInfo = (jvmtiHeapReferenceInfoStackLocal *)reference_info; > 71: refCounters.count[index]++; > 72: refCounters.threadId[index] = stackInfo->thread_id; If `count` is >1 at this point, can this line be an assert? I assume the threadId should never change for any given index once it is set. ------------- PR Review: https://git.openjdk.org/jdk/pull/13254#pullrequestreview-1369892549 PR Review Comment: https://git.openjdk.org/jdk/pull/13254#discussion_r1156534139 PR Review Comment: https://git.openjdk.org/jdk/pull/13254#discussion_r1156534779 PR Review Comment: https://git.openjdk.org/jdk/pull/13254#discussion_r1156538712 PR Review Comment: https://git.openjdk.org/jdk/pull/13254#discussion_r1156540510 PR Review Comment: https://git.openjdk.org/jdk/pull/13254#discussion_r1156520354 From amenkov at openjdk.org Wed Apr 5 20:21:18 2023 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 5 Apr 2023 20:21:18 GMT Subject: RFR: 8299414: JVMTI FollowReferences should support references from VirtualThread stack In-Reply-To: References: <6oQOD_egcB3HyuagMWGSPLjKSE3JkaI2K2WOsDK1Cww=.c568223b-5100-4425-a4b7-defbd812a9ff@github.com> Message-ID: On Mon, 3 Apr 2023 23:11:49 GMT, Chris Plummer wrote: >> The fix updates JVMTI FollowReferences implementation to report references from virtual threads: >> - added heap scanning to report unmounted vthreads; >> - stacks of mounted vthreads are splitted into 2 parts (vittual thread stack and carrier thread stack), references are reported with correct thread id/class and object tags/frame depth; >> - common code to handle stack frames are moved into separate class; > > test/hotspot/jtreg/serviceability/jvmti/vthread/FollowReferences/VThreadStackRefTest.java line 54: > >> 52: } >> 53: } >> 54: await(dumpedLatch); > > await() seems unnecessary given the use the !timeToStop flag. Correct. Fixed. > test/hotspot/jtreg/serviceability/jvmti/vthread/FollowReferences/VThreadStackRefTest.java line 83: > >> 81: System.out.println(referenced.getClass()); >> 82: }); >> 83: vthreadEnded.join(); > > Add comment that says something like "Make sure this vthread has exited so we can test that it no longer holds any stack references". Fixed > test/hotspot/jtreg/serviceability/jvmti/vthread/FollowReferences/VThreadStackRefTest.java line 85: > >> 83: vthreadEnded.join(); >> 84: >> 85: Thread.sleep(2000); // wait for reference and unmount > > I think what you mean is you need to wait until the threads have made enough progress to create the references, and then you need to wait until they have had a chance to amount due to the await() call. This should be made more clear in the comments. > > BTW, you could choose to get JVMTI VIRTUAL_THREAD_UNMOUNT events, and instead block here until you get them all, but doing a sleep is a lot easier. Added comment. Sleep does the job, I don't think it makes sense to overcomplicate the test > test/hotspot/jtreg/serviceability/jvmti/vthread/FollowReferences/VThreadStackRefTest.java line 94: > >> 92: // expected to be unreported as stack local >> 93: new TestCase(VThreadUnmountedEnded.class, 0, 0) >> 94: }; > > I think it would be useful the have a test case which has expected_cnt > 1. expected_cnt > 1 means there are references to 2 objects of the class or 2 references to the same object. I don't see how this would improve test coverage. 1 (or 0) reference to each object helps to keep the test simple > test/hotspot/jtreg/serviceability/jvmti/vthread/FollowReferences/libVThreadStackRefTest.cpp line 72: > >> 70: jvmtiHeapReferenceInfoStackLocal *stackInfo = (jvmtiHeapReferenceInfoStackLocal *)reference_info; >> 71: refCounters.count[index]++; >> 72: refCounters.threadId[index] = stackInfo->thread_id; > > If `count` is >1 at this point, can this line be an assert? I assume the threadId should never change for any given index once it is set. if count is > 1 the will fail later verifying the value I added "ERROR" logging ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13254#discussion_r1156603534 PR Review Comment: https://git.openjdk.org/jdk/pull/13254#discussion_r1156603638 PR Review Comment: https://git.openjdk.org/jdk/pull/13254#discussion_r1156605011 PR Review Comment: https://git.openjdk.org/jdk/pull/13254#discussion_r1156573479 PR Review Comment: https://git.openjdk.org/jdk/pull/13254#discussion_r1156603364 From duke at openjdk.org Wed Apr 5 20:35:17 2023 From: duke at openjdk.org (Bernd) Date: Wed, 5 Apr 2023 20:35:17 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v4] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: <9TzfWvcOSBZeVJB0RL3cMxgXvkXA3Vhp9PR3LgOApwo=.7834e964-b8fe-4deb-8185-2ad8ff27a2c4@github.com> On Wed, 5 Apr 2023 19:20:08 GMT, Roger Riggs wrote: >> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. >> The enumeration values are defined to match those used in the build. >> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE` >> Note that `amd64` and `x86_64` in the build are represented by `X64`. >> The values of the system property `os.arch` is unchanged. >> >> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). >> Uses in `java.base` and a few others are included but other modules will be done in separate PRs. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Correct spelling of isAARCH64 in WIndows AttachProviderImpl src/java.base/share/classes/jdk/internal/foreign/CABI.java line 48: > 46: // might be running in a 32-bit VM on a 64-bit platform. > 47: // addressSize will be correctly 32 > 48: if (Architecture.isX64() && ADDRESS_SIZE == 64) { Is there a difference to Architecture.is64bit (I.e. is the later or the former runtime vs compiletime src/java.base/share/classes/jdk/internal/util/Architecture.java line 77: > 75: */ > 76: @ForceInline > 77: public static boolean isARM() { It should define what?s the difference to aarch64 for example will aarch64 also be arm, but arm32 wont? (Or remove) test/jdk/jdk/internal/util/ArchTest.java line 58: > 56: @Test > 57: public void nameVsCurrent() { > 58: String osArch = System.getProperty("os.arch").toLowerCase(Locale.ROOT); Is it planned to determine os.arch with the same enum in the future (keeping the legacy names)? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1158982643 PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1158988981 PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1158993835 From cjplummer at openjdk.org Wed Apr 5 20:37:08 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 5 Apr 2023 20:37:08 GMT Subject: RFR: 8299414: JVMTI FollowReferences should support references from VirtualThread stack In-Reply-To: <6oQOD_egcB3HyuagMWGSPLjKSE3JkaI2K2WOsDK1Cww=.c568223b-5100-4425-a4b7-defbd812a9ff@github.com> References: <6oQOD_egcB3HyuagMWGSPLjKSE3JkaI2K2WOsDK1Cww=.c568223b-5100-4425-a4b7-defbd812a9ff@github.com> Message-ID: On Thu, 30 Mar 2023 22:58:12 GMT, Alex Menkov wrote: > The fix updates JVMTI FollowReferences implementation to report references from virtual threads: > - added heap scanning to report unmounted vthreads; > - stacks of mounted vthreads are splitted into 2 parts (vittual thread stack and carrier thread stack), references are reported with correct thread id/class and object tags/frame depth; > - common code to handle stack frames are moved into separate class; test/hotspot/jtreg/serviceability/jvmti/vthread/FollowReferences/VThreadStackRefTest.java line 43: > 41: * mounted and unmounted virtual threads and reports correct thread id > 42: * (for mounted vthread it should be vthread id, and not carrier thread id). > 43: * Additionally tests that references from platform threads aree reported correctly "aree" -> "are" test/hotspot/jtreg/serviceability/jvmti/vthread/FollowReferences/VThreadStackRefTest.java line 93: > 91: createObjAndWait(VThreadMountedJNIReferenced.class); > 92: Reference.reachabilityFence(referenced); > 93: }); This code used to use a java loop to keep busy, but now it relies on a sleep loop in native code. Was the java loop problematic? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13254#discussion_r1158982377 PR Review Comment: https://git.openjdk.org/jdk/pull/13254#discussion_r1158995466 From dcubed at openjdk.org Wed Apr 5 20:42:58 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 5 Apr 2023 20:42:58 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v55] In-Reply-To: References: Message-ID: On Wed, 5 Apr 2023 16:17:44 GMT, Roman Kennke wrote: >> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). >> >> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. >> >> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal protocols. >> >> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare. >> >> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. >> >> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. >> >> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. >> >> This change enables to simplify (and speed-up!) a lot of code: >> >> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. >> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR >> >> Also, and I might be mistaken here, this new lightweight locking would make synchronized work better with Loom: Because the lock-records are no longer scattered across the stack, but instead are densely packed into the lock-stack, it should be easy for a vthread to save its lock-stack upon unmounting and restore it when re-mounting. However, I am not sure about this, and this PR does not attempt to implement that support. >> >> Testing: >> - [x] tier1 x86_64 x aarch64 x +UseFastLocking >> - [x] tier2 x86_64 x aarch64 x +UseFastLocking >> - [x] tier3 x86_64 x aarch64 x +UseFastLocking >> - [x] tier4 x86_64 x aarch64 x +UseFastLocking >> - [x] tier1 x86_64 x aarch64 x -UseFastLocking >> - [x] tier2 x86_64 x aarch64 x -UseFastLocking >> - [x] tier3 x86_64 x aarch64 x -UseFastLocking >> - [x] tier4 x86_64 x aarch64 x -UseFastLocking >> - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet >> >> ### Performance >> >> #### Simple Microbenchmark >> >> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops. >> >> | | x86_64 | aarch64 | >> | -- | -- | -- | >> | -UseFastLocking | 20.651 | 20.764 | >> | +UseFastLocking | 18.896 | 18.908 | >> >> >> #### Renaissance >> >> ? | x86_64 | ? | ? | ? | aarch64 | ? | ? >> -- | -- | -- | -- | -- | -- | -- | -- >> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? >> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% >> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21% >> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% >> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% >> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% >> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% >> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%% >> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% >> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% >> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% >> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% >> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34% >> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% >> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% >> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% >> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% >> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% >> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% >> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% >> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% >> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Put back thread type check in OS::is_lock_owned() src/hotspot/cpu/aarch64/aarch64.ad line 3843: > 3841: > 3842: if (!UseHeavyMonitors) { > 3843: if (LockingMode == LIGHTWEIGHT) { You should consider changing uses of `UseHeavyMonitors` to the appropriate check of `LockingMode`. For this case, use: ` if (LockingMode != MONITOR) {` You'll also need to change the implementation of the `UseHeavyMonitors` option to set `LockingMode = MONITOR` or something like that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1158999786 From rriggs at openjdk.org Wed Apr 5 20:43:27 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 5 Apr 2023 20:43:27 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v4] In-Reply-To: <9TzfWvcOSBZeVJB0RL3cMxgXvkXA3Vhp9PR3LgOApwo=.7834e964-b8fe-4deb-8185-2ad8ff27a2c4@github.com> References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> <9TzfWvcOSBZeVJB0RL3cMxgXvkXA3Vhp9PR3LgOApwo=.7834e964-b8fe-4deb-8185-2ad8ff27a2c4@github.com> Message-ID: On Wed, 5 Apr 2023 20:25:43 GMT, Bernd wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Correct spelling of isAARCH64 in WIndows AttachProviderImpl > > src/java.base/share/classes/jdk/internal/foreign/CABI.java line 48: > >> 46: // might be running in a 32-bit VM on a 64-bit platform. >> 47: // addressSize will be correctly 32 >> 48: if (Architecture.isX64() && ADDRESS_SIZE == 64) { > > Is there a difference to Architecture.is64bit (I.e. is the later or the former runtime vs compiletime There should be no difference; I was hesitant to drop the ADDRESS_SIZE check without knowing more about the foreign api dependencies. ADDRESS_SIZE is computed (I think) from `UNSAFE.ADDRESS_SIZE * 8`. But I can't think of how it can be different than the CPU_BITS that are defined when the JDK is built. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159001239 From rriggs at openjdk.org Wed Apr 5 20:52:15 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 5 Apr 2023 20:52:15 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v4] In-Reply-To: <9TzfWvcOSBZeVJB0RL3cMxgXvkXA3Vhp9PR3LgOApwo=.7834e964-b8fe-4deb-8185-2ad8ff27a2c4@github.com> References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> <9TzfWvcOSBZeVJB0RL3cMxgXvkXA3Vhp9PR3LgOApwo=.7834e964-b8fe-4deb-8185-2ad8ff27a2c4@github.com> Message-ID: On Wed, 5 Apr 2023 20:31:43 GMT, Bernd wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Correct spelling of isAARCH64 in WIndows AttachProviderImpl > > test/jdk/jdk/internal/util/ArchTest.java line 58: > >> 56: @Test >> 57: public void nameVsCurrent() { >> 58: String osArch = System.getProperty("os.arch").toLowerCase(Locale.ROOT); > > Is it planned to determine os.arch with the same enum in the future (keeping the legacy names)? That's a different set of twisty build and native source files, I'll create an issue to re-visit that. It may not change too much, the native code needs to initialize `os.arch` very early. [JDK-8305676](https://bugs.openjdk.org/browse/JDK-8305676) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159009755 From amenkov at openjdk.org Wed Apr 5 21:09:09 2023 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 5 Apr 2023 21:09:09 GMT Subject: RFR: 8299414: JVMTI FollowReferences should support references from VirtualThread stack [v2] In-Reply-To: <6oQOD_egcB3HyuagMWGSPLjKSE3JkaI2K2WOsDK1Cww=.c568223b-5100-4425-a4b7-defbd812a9ff@github.com> References: <6oQOD_egcB3HyuagMWGSPLjKSE3JkaI2K2WOsDK1Cww=.c568223b-5100-4425-a4b7-defbd812a9ff@github.com> Message-ID: > The fix updates JVMTI FollowReferences implementation to report references from virtual threads: > - added heap scanning to report unmounted vthreads; > - stacks of mounted vthreads are splitted into 2 parts (vittual thread stack and carrier thread stack), references are reported with correct thread id/class and object tags/frame depth; > - common code to handle stack frames are moved into separate class; Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: aree -> are ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13254/files - new: https://git.openjdk.org/jdk/pull/13254/files/0eb9b050..8108f217 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13254&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13254&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13254.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13254/head:pull/13254 PR: https://git.openjdk.org/jdk/pull/13254 From amenkov at openjdk.org Wed Apr 5 21:09:13 2023 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 5 Apr 2023 21:09:13 GMT Subject: RFR: 8299414: JVMTI FollowReferences should support references from VirtualThread stack [v2] In-Reply-To: References: <6oQOD_egcB3HyuagMWGSPLjKSE3JkaI2K2WOsDK1Cww=.c568223b-5100-4425-a4b7-defbd812a9ff@github.com> Message-ID: On Wed, 5 Apr 2023 20:25:39 GMT, Chris Plummer wrote: >> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: >> >> aree -> are > > test/hotspot/jtreg/serviceability/jvmti/vthread/FollowReferences/VThreadStackRefTest.java line 43: > >> 41: * mounted and unmounted virtual threads and reports correct thread id >> 42: * (for mounted vthread it should be vthread id, and not carrier thread id). >> 43: * Additionally tests that references from platform threads aree reported correctly > > "aree" -> "are" Fixed > test/hotspot/jtreg/serviceability/jvmti/vthread/FollowReferences/VThreadStackRefTest.java line 93: > >> 91: createObjAndWait(VThreadMountedJNIReferenced.class); >> 92: Reference.reachabilityFence(referenced); >> 93: }); > > This code used to use a java loop to keep busy, but now it relies on a sleep loop in native code. Was the java loop problematic? No. I had a failure of the test due racing, but I believe the reason was lack of synchronization. I decided to simplify the test - 2 virtual threads are enough and as the test verifies "JNI local on top frame" case, it needs block in native call anyway, so I use it to prevent unmount too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13254#discussion_r1159022346 PR Review Comment: https://git.openjdk.org/jdk/pull/13254#discussion_r1159020544 From kevinw at openjdk.org Wed Apr 5 21:12:13 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 5 Apr 2023 21:12:13 GMT Subject: RFR: 8305622: Remove Permission details from jcmd man page Message-ID: Removal of the Permission information from the jcmd man page. This information is not useful in the way it is presented, and is not used in connection with jcmd, so should be removed from that man page. The Permissions can be relevant when connecting remotely to JMX with a Security Manager in place. That usage is clearly deprecated with JEP 411. If there is a transition feature, it will be documented elsewhere. ------------- Commit messages: - 8305622: Remove Permission details from jcmd man page Changes: https://git.openjdk.org/jdk/pull/13363/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13363&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8305622 Stats: 79 lines in 1 file changed: 0 ins; 79 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13363.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13363/head:pull/13363 PR: https://git.openjdk.org/jdk/pull/13363 From duke at openjdk.org Wed Apr 5 21:21:07 2023 From: duke at openjdk.org (Glavo) Date: Wed, 5 Apr 2023 21:21:07 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v4] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> <9TzfWvcOSBZeVJB0RL3cMxgXvkXA3Vhp9PR3LgOApwo=.7834e964-b8fe-4deb-8185-2ad8ff27a2c4@github.com> Message-ID: <1HKkKI-yuCGm_7ojnOgq0VCK-uJyAnsnXp4KYsrXW0M=.fbe8d18f-e9a6-4032-b9d3-6de15297f8d1@github.com> On Wed, 5 Apr 2023 20:40:32 GMT, Roger Riggs wrote: >> src/java.base/share/classes/jdk/internal/foreign/CABI.java line 48: >> >>> 46: // might be running in a 32-bit VM on a 64-bit platform. >>> 47: // addressSize will be correctly 32 >>> 48: if (Architecture.isX64() && ADDRESS_SIZE == 64) { >> >> Is there a difference to Architecture.is64bit (I.e. is the later or the former runtime vs compiletime > > There should be no difference; I was hesitant to drop the ADDRESS_SIZE check without knowing more about the foreign api dependencies. ADDRESS_SIZE is computed (I think) from `UNSAFE.ADDRESS_SIZE * 8`. > But I can't think of how it can be different than the CPU_BITS that are defined when the JDK is built. > Is there a difference to Architecture.is64bit (I.e. is the later or the former runtime vs compiletime Theoretically, the two can be unrelated. Linux x32 ABI is a typical example of using 32-bit addresses on the x86-64 architecture. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159032441 From amenkov at openjdk.org Wed Apr 5 21:26:05 2023 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 5 Apr 2023 21:26:05 GMT Subject: RFR: 8305607: Remove some unused test parameters in com/sun/jdi tests In-Reply-To: References: Message-ID: On Tue, 4 Apr 2023 20:15:41 GMT, Leonid Mesnik wrote: > Some tests set debugee name which is set by startUp() method. > > The test/jdk/com/sun/jdi/RedefineNestmateAttr/TestNestmateAttr.java set classpath which is not required. Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13337#pullrequestreview-1373713744 From cjplummer at openjdk.org Wed Apr 5 21:27:14 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 5 Apr 2023 21:27:14 GMT Subject: RFR: 8305622: Remove Permission details from jcmd man page In-Reply-To: References: Message-ID: <3vcaZsan7YvEw24Zj_w9dBxD18GpJX-6Sugh71HqGJA=.bfdf44e8-a726-4eb4-874a-352141b8ba37@github.com> On Wed, 5 Apr 2023 21:00:55 GMT, Kevin Walls wrote: > Removal of the Permission information from the jcmd man page. > > This information is not useful in the way it is presented, and is not used in connection with jcmd, so should be removed from that man page. > > The Permissions can be relevant when connecting remotely to JMX with a Security Manager in place. That usage is clearly deprecated with JEP 411. If there is a transition feature, it will be documented elsewhere. What about the permissions references in the jcmd help output: $ jcmd 32228 help VM.version 32228: VM.version Print JVM version information. Impact: Low Permission: java.util.PropertyPermission(java.vm.version, read) Syntax: VM.version ------------- PR Comment: https://git.openjdk.org/jdk/pull/13363#issuecomment-1498181211 From dcubed at openjdk.org Wed Apr 5 21:29:20 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 5 Apr 2023 21:29:20 GMT Subject: Integrated: 8305678: ProblemList serviceability/sa/ClhsdbInspect.java on windows-x64 in Xcomp Message-ID: Trivial fixes to ProblemList a couple of tests: [JDK-8305678](https://bugs.openjdk.org/browse/JDK-8305678) ProblemList serviceability/sa/ClhsdbInspect.java on windows-x64 in Xcomp [JDK-8305679](https://bugs.openjdk.org/browse/JDK-8305679) ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-aarch64 with ZGC ------------- Commit messages: - 8305679: ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-aarch64 with ZGC - 8305678: ProblemList serviceability/sa/ClhsdbInspect.java on windows-x64 in Xcomp Changes: https://git.openjdk.org/jdk/pull/13365/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13365&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8305678 Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13365.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13365/head:pull/13365 PR: https://git.openjdk.org/jdk/pull/13365 From mikael at openjdk.org Wed Apr 5 21:29:20 2023 From: mikael at openjdk.org (Mikael Vidstedt) Date: Wed, 5 Apr 2023 21:29:20 GMT Subject: Integrated: 8305678: ProblemList serviceability/sa/ClhsdbInspect.java on windows-x64 in Xcomp In-Reply-To: References: Message-ID: On Wed, 5 Apr 2023 21:12:14 GMT, Daniel D. Daugherty wrote: > Trivial fixes to ProblemList a couple of tests: > [JDK-8305678](https://bugs.openjdk.org/browse/JDK-8305678) ProblemList serviceability/sa/ClhsdbInspect.java on windows-x64 in Xcomp > [JDK-8305679](https://bugs.openjdk.org/browse/JDK-8305679) ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-aarch64 with ZGC Marked as reviewed by mikael (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13365#pullrequestreview-1373708430 From dcubed at openjdk.org Wed Apr 5 21:29:21 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 5 Apr 2023 21:29:21 GMT Subject: Integrated: 8305678: ProblemList serviceability/sa/ClhsdbInspect.java on windows-x64 in Xcomp In-Reply-To: References: Message-ID: On Wed, 5 Apr 2023 21:18:28 GMT, Mikael Vidstedt wrote: >> Trivial fixes to ProblemList a couple of tests: >> [JDK-8305678](https://bugs.openjdk.org/browse/JDK-8305678) ProblemList serviceability/sa/ClhsdbInspect.java on windows-x64 in Xcomp >> [JDK-8305679](https://bugs.openjdk.org/browse/JDK-8305679) ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-aarch64 with ZGC > > Marked as reviewed by mikael (Reviewer). @vidmik - Thanks for the fast review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13365#issuecomment-1498180191 From dcubed at openjdk.org Wed Apr 5 21:29:22 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 5 Apr 2023 21:29:22 GMT Subject: Integrated: 8305678: ProblemList serviceability/sa/ClhsdbInspect.java on windows-x64 in Xcomp In-Reply-To: References: Message-ID: On Wed, 5 Apr 2023 21:12:14 GMT, Daniel D. Daugherty wrote: > Trivial fixes to ProblemList a couple of tests: > [JDK-8305678](https://bugs.openjdk.org/browse/JDK-8305678) ProblemList serviceability/sa/ClhsdbInspect.java on windows-x64 in Xcomp > [JDK-8305679](https://bugs.openjdk.org/browse/JDK-8305679) ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-aarch64 with ZGC This pull request has now been integrated. Changeset: b5d204c3 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/b5d204c3a4274c2e4604390eba436d42b5f5e9c9 Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod 8305678: ProblemList serviceability/sa/ClhsdbInspect.java on windows-x64 in Xcomp 8305679: ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-aarch64 with ZGC Reviewed-by: mikael ------------- PR: https://git.openjdk.org/jdk/pull/13365 From lmesnik at openjdk.org Wed Apr 5 21:33:14 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 5 Apr 2023 21:33:14 GMT Subject: RFR: 8305607: Remove some unused test parameters in com/sun/jdi tests In-Reply-To: References: Message-ID: On Wed, 5 Apr 2023 19:51:00 GMT, Chris Plummer wrote: > Do I understand correctly that this bug just caused the debuggee to appear twice in the arguments, leading to output like the following: > > [2ms] run args: [RefTypes, RefTypes] > > In this case it was harmless because the 2nd "RefTypes" gets passed as an arg to the RefTypes debuggee, which just ignored it. Exactly, the unused parameters are just ignored silently. They just confuse people trying to understand why they are required. Also, I am trying to improve parsing arguments in TestScaffold and harden parameters verification. So I want to make this clean up first. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13337#issuecomment-1498186200 From kevinw at openjdk.org Wed Apr 5 21:37:13 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 5 Apr 2023 21:37:13 GMT Subject: RFR: 8305622: Remove Permission details from jcmd man page In-Reply-To: <3vcaZsan7YvEw24Zj_w9dBxD18GpJX-6Sugh71HqGJA=.bfdf44e8-a726-4eb4-874a-352141b8ba37@github.com> References: <3vcaZsan7YvEw24Zj_w9dBxD18GpJX-6Sugh71HqGJA=.bfdf44e8-a726-4eb4-874a-352141b8ba37@github.com> Message-ID: <7u8By-1Av_NlY-OoBiYuBUeKz48pRfJDOfwDqteIupY=.28a801ae-a49f-427a-bffc-78781eff3277@github.com> On Wed, 5 Apr 2023 21:24:16 GMT, Chris Plummer wrote: > What about the permissions references in the jcmd help output: > > ``` > $ jcmd 32228 help VM.version > 32228: > VM.version > Print JVM version information. > > Impact: Low > > Permission: java.util.PropertyPermission(java.vm.version, read) > > Syntax: VM.version > ``` Aha, ok that is created programmatically by HelpDCmd::execute... And I don't think we should print it, it has the same problems as the man page. As it's a code change not a man page change, I think I should handle that in a separate CR which I'll log now... ------------- PR Comment: https://git.openjdk.org/jdk/pull/13363#issuecomment-1498189981 From duke at openjdk.org Wed Apr 5 21:40:16 2023 From: duke at openjdk.org (Glavo) Date: Wed, 5 Apr 2023 21:40:16 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v4] In-Reply-To: <9TzfWvcOSBZeVJB0RL3cMxgXvkXA3Vhp9PR3LgOApwo=.7834e964-b8fe-4deb-8185-2ad8ff27a2c4@github.com> References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> <9TzfWvcOSBZeVJB0RL3cMxgXvkXA3Vhp9PR3LgOApwo=.7834e964-b8fe-4deb-8185-2ad8ff27a2c4@github.com> Message-ID: On Wed, 5 Apr 2023 20:28:17 GMT, Bernd wrote: > It should define what?s the difference to aarch64 for example will aarch64 also be arm, but arm32 wont? (Or remove) I think x86 and ARM are a bit confusing in this regard, as they can refer to 32-bit architectures in a narrow sense and 32-bit or 64 bit architectures in a broad sense. For clarity, we can use more specific names: `x86-32`/`i686` and `arm32`/`aarch32`. But these names don't seem to be that commonly used. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159047360 From lmesnik at openjdk.org Wed Apr 5 21:40:16 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 5 Apr 2023 21:40:16 GMT Subject: RFR: 8305608: Change VMConnection to use "test.class.path"instead of "test.classes" In-Reply-To: References: <3Xyc3nRyd_hr8fw7XQcAqsSv3UQg2wnsnp7fdvTYteo=.c1381ed9-25c5-4fe5-b4bd-1df7e73d3572@github.com> Message-ID: On Wed, 5 Apr 2023 20:09:38 GMT, Chris Plummer wrote: >> I'd prefer to always use the "test.class.path" as it is a complete classpath required to run test. >> >>> The better comment would be >>> // When we run jtreg with plugin, the full classpath including testlibrary is required to use TestScaffold is required >> >> I guess, you are going to remove this duplication with "is required". :) > > I think the CR should explain this test.classes vs test.class.path difference, and also explain why the classpath requirements are different when using virtual threads. You say that "TestScaffold should be also in classpath", but don't explain why. It's also not clear to me why only tests that are in subdirs are impacted when running with the wrapper. > > Also, when you say "When we run jtreg with plugin..", do you mean with the wrapper, not the plugin? @plummercj, I'e updated CR with more detailed information. Hope it makes clearer why this change is needed. Here is the text. " VMConnection runs debuggee using "test.classes" as a classpath for debuggee classes. It works fine when test and TestScaffold.java are located in the same directory and are both compiled into "test.classes" location. However, it causes test failures when the virtual thread factory (wrapper) is enabled and the test is not located in the same directory as TestScaffold. Such tests use TestScaffold as a testlibrary. (They have ' * @library ..' or something like similar). So TestScaffold is not included in 'test.classes' which include tests only. However, it is included as all testlibrary classes in "test.class.path" classparth. It is needed to use "test.class.path" to be able to use TestScaffolld as debugee wrapper Might be it better to always use "test.class.path" as classpath for debugee to minimize the difference between standard and "virtual" execution. " Yes, it would be better to change "When we jtreg with plugin" to "When 'main wrapper' is used". Before updating the comments I want to confirm if we want to keep "test.classes" for standard execution or change it to use "test.class.path" always. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13339#discussion_r1159047948 From cjplummer at openjdk.org Wed Apr 5 21:47:04 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 5 Apr 2023 21:47:04 GMT Subject: RFR: 8305607: Remove some unused test parameters in com/sun/jdi tests In-Reply-To: References: Message-ID: On Tue, 4 Apr 2023 20:15:41 GMT, Leonid Mesnik wrote: > Some tests set debugee name which is set by startUp() method. > > The test/jdk/com/sun/jdi/RedefineNestmateAttr/TestNestmateAttr.java set classpath which is not required. Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13337#pullrequestreview-1373737367 From cjplummer at openjdk.org Wed Apr 5 21:50:06 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 5 Apr 2023 21:50:06 GMT Subject: RFR: 8305608: Change VMConnection to use "test.class.path"instead of "test.classes" In-Reply-To: References: <3Xyc3nRyd_hr8fw7XQcAqsSv3UQg2wnsnp7fdvTYteo=.c1381ed9-25c5-4fe5-b4bd-1df7e73d3572@github.com> Message-ID: On Wed, 5 Apr 2023 21:37:46 GMT, Leonid Mesnik wrote: >> I think the CR should explain this test.classes vs test.class.path difference, and also explain why the classpath requirements are different when using virtual threads. You say that "TestScaffold should be also in classpath", but don't explain why. It's also not clear to me why only tests that are in subdirs are impacted when running with the wrapper. >> >> Also, when you say "When we run jtreg with plugin..", do you mean with the wrapper, not the plugin? > > @plummercj, I'e updated CR with more detailed information. Hope it makes clearer why this change is needed. Here is the text. > > " > VMConnection runs debuggee using "test.classes" as a classpath for debuggee classes. It works fine when test and TestScaffold.java are located in the same directory and are both compiled into "test.classes" location. However, it causes test failures when the virtual thread factory (wrapper) is enabled and the test is not located in the same directory as TestScaffold. Such tests use TestScaffold as a testlibrary. (They have ' * @library ..' or something like similar). > So TestScaffold is not included in 'test.classes' which include tests only. However, it is included as all testlibrary classes in "test.class.path" classparth. > > It is needed to use "test.class.path" to be able to use TestScaffolld as debugee wrapper Might be it better to always use "test.class.path" as classpath for debugee to minimize the difference between standard and "virtual" execution. > " > > Yes, it would be better to change "When we jtreg with plugin" to "When 'main wrapper' is used". > > Before updating the comments I want to confirm if we want to keep "test.classes" for standard execution or change it to use "test.class.path" always. I'm ok with always using test.class.path. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13339#discussion_r1159056459 From cjplummer at openjdk.org Wed Apr 5 22:04:15 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 5 Apr 2023 22:04:15 GMT Subject: RFR: 8305622: Remove Permission details from jcmd man page In-Reply-To: References: Message-ID: On Wed, 5 Apr 2023 21:00:55 GMT, Kevin Walls wrote: > Removal of the Permission information from the jcmd man page. > > This information is not useful in the way it is presented, and is not used in connection with jcmd, so should be removed from that man page. > > The Permissions can be relevant when connecting remotely to JMX with a Security Manager in place. That usage is clearly deprecated with JEP 411. If there is a transition feature, it will be documented elsewhere. I ran jconsole, selected MBeans -> com.sun.management -> DiagnosticCommand -> Operations, and it shows the list of DCMDs (what we normally see as jcmds). I clicked on one and it has a `dcmd.permissionName` field with the permission in it. Is this an example of using JMX where you feel showing the permission is the right thing to do. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13363#issuecomment-1498211955 From kevinw at openjdk.org Wed Apr 5 22:26:15 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 5 Apr 2023 22:26:15 GMT Subject: RFR: 8305622: Remove Permission details from jcmd man page In-Reply-To: References: Message-ID: On Wed, 5 Apr 2023 21:00:55 GMT, Kevin Walls wrote: > Removal of the Permission information from the jcmd man page. > > This information is not useful in the way it is presented, and is not used in connection with jcmd, so should be removed from that man page. > > The Permissions can be relevant when connecting remotely to JMX with a Security Manager in place. That usage is clearly deprecated with JEP 411. If there is a transition feature, it will be documented elsewhere. > Yes - JConsole (using DiagnosticCommandImpl.java) showing the permissions is more relevant, I wasn't going to change that right now. Removing the Permissions from the jcmd help output (in a separate change) will make that jconsole info better, as the Permission info is duplicated in the help text and the permission fields that it shows. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13363#issuecomment-1498234672 From cjplummer at openjdk.org Wed Apr 5 22:51:06 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 5 Apr 2023 22:51:06 GMT Subject: RFR: 8305622: Remove Permission details from jcmd man page In-Reply-To: References: Message-ID: <2ZnPee_f5MVgGfoszMLcSuFjqbkCR3VneEuek3iWkZA=.d7268f94-97d4-4a79-a82e-e388721d1589@github.com> On Wed, 5 Apr 2023 21:00:55 GMT, Kevin Walls wrote: > Removal of the Permission information from the jcmd man page. > > This information is not useful in the way it is presented, and is not used in connection with jcmd, so should be removed from that man page. > > The Permissions can be relevant when connecting remotely to JMX with a Security Manager in place. That usage is clearly deprecated with JEP 411. If there is a transition feature, it will be documented elsewhere. src/jdk.jcmd/share/man/jcmd.1 line 410: > 408: If false, files are deleted. > 409: By default, this parameter is disabled. > 410: .IP \[bu] 2 Why is this being removed? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13363#discussion_r1159098473 From jvernee at openjdk.org Wed Apr 5 23:42:13 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 5 Apr 2023 23:42:13 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v4] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Wed, 5 Apr 2023 19:20:08 GMT, Roger Riggs wrote: >> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. >> The enumeration values are defined to match those used in the build. >> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE` >> Note that `amd64` and `x86_64` in the build are represented by `X64`. >> The values of the system property `os.arch` is unchanged. >> >> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). >> Uses in `java.base` and a few others are included but other modules will be done in separate PRs. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Correct spelling of isAARCH64 in WIndows AttachProviderImpl test/jdk/java/foreign/TestUnsupportedLinker.java line 26: > 24: /* > 25: * @test > 26: * @ignore architecture can not be overridden by setting os.arch - delete test FWIW, we introduce a property in CABI to override it directly in the JEP patch: https://github.com/openjdk/jdk/pull/13079/files#diff-1e9526318ae485495af012cbf0450693d77fd8241be62afe422a75304de5aed1R28 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159130445 From jvernee at openjdk.org Wed Apr 5 23:50:05 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 5 Apr 2023 23:50:05 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v4] In-Reply-To: <1HKkKI-yuCGm_7ojnOgq0VCK-uJyAnsnXp4KYsrXW0M=.fbe8d18f-e9a6-4032-b9d3-6de15297f8d1@github.com> References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> <9TzfWvcOSBZeVJB0RL3cMxgXvkXA3Vhp9PR3LgOApwo=.7834e964-b8fe-4deb-8185-2ad8ff27a2c4@github.com> <1HKkKI-yuCGm_7ojnOgq0VCK-uJyAnsnXp4KYsrXW0M=.fbe8d18f-e9a6-4032-b9d3-6de15297f8d1@github.com> Message-ID: On Wed, 5 Apr 2023 21:18:43 GMT, Glavo wrote: >> There should be no difference; I was hesitant to drop the ADDRESS_SIZE check without knowing more about the foreign api dependencies. ADDRESS_SIZE is computed (I think) from `UNSAFE.ADDRESS_SIZE * 8`. >> But I can't think of how it can be different than the CPU_BITS that are defined when the JDK is built. > >> Is there a difference to Architecture.is64bit (I.e. is the later or the former runtime vs compiletime > > Theoretically, the two can be unrelated. Linux x32 ABI is a typical example of using 32-bit addresses on the x86-64 architecture. Right, it is still possible to run a 32-bit VM build on a 64-bit platform. `os.arch` is the runtime platform in this case, but the VM variant can still be 32 bits. Since `Architecture.isX64` seems to be the target arch of the VM, I'm think that when running a 32-bit VM on a amd64 would result in `isX64` being `false`? (In that case, only the `isX64` check should be enough) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159142830 From lmesnik at openjdk.org Thu Apr 6 00:01:05 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 6 Apr 2023 00:01:05 GMT Subject: RFR: 8305608: Change VMConnection to use "test.class.path"instead of "test.classes" [v2] In-Reply-To: References: Message-ID: > Currently, VMConnection run debugee using "test.classes" as a classpath. It cause test failures when virtual thread factory (wrapper) is enabled and test is not located the same directory as TestScaffold. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13339/files - new: https://git.openjdk.org/jdk/pull/13339/files/525f769f..ac9c64a8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13339&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13339&range=00-01 Stats: 8 lines in 1 file changed: 0 ins; 2 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/13339.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13339/head:pull/13339 PR: https://git.openjdk.org/jdk/pull/13339 From cjplummer at openjdk.org Thu Apr 6 01:09:08 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 6 Apr 2023 01:09:08 GMT Subject: RFR: 8305608: Change VMConnection to use "test.class.path"instead of "test.classes" [v2] In-Reply-To: References: Message-ID: On Thu, 6 Apr 2023 00:01:05 GMT, Leonid Mesnik wrote: >> Currently, VMConnection run debugee using "test.classes" as a classpath. It cause test failures when virtual thread factory (wrapper) is enabled and test is not located the same directory as TestScaffold. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > fix Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13339#pullrequestreview-1373924130 From sspitsyn at openjdk.org Thu Apr 6 01:29:16 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 6 Apr 2023 01:29:16 GMT Subject: RFR: 8305608: Change VMConnection to use "test.class.path"instead of "test.classes" [v2] In-Reply-To: References: Message-ID: On Thu, 6 Apr 2023 00:01:05 GMT, Leonid Mesnik wrote: >> Currently, VMConnection run debugee using "test.classes" as a classpath. It cause test failures when virtual thread factory (wrapper) is enabled and test is not located the same directory as TestScaffold. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > fix Thank you for update. The fix looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13339#pullrequestreview-1373934773 From sspitsyn at openjdk.org Thu Apr 6 01:35:22 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 6 Apr 2023 01:35:22 GMT Subject: Integrated: 8303563: GetCurrentThreadCpuTime and GetThreadCpuTime need further clarification for virtual threads In-Reply-To: References: Message-ID: On Tue, 4 Apr 2023 20:33:46 GMT, Serguei Spitsyn wrote: > This is a follow-up to [JDK-8302615](https://bugs.openjdk.org/browse/JDK-8302615) where GetCurrentThreadCpuTime and GetThreadCpuTime were changed from being not supported to optional, when called from/with a virtual thread. There are two additional sentences that need adjustment to avoid creating a conflict in the spec. > > In the functions `GetCurrentThreadCpuTime` and `GetThreadCpuTime`: > > The fragment: > `"The current thread may not be a virtual thread. Otherwise, the error code"` > > is replaced with: > > "An implementation is not required to support this function > when the current thread is a virtual thread, in which case" > > > CSR: [JDK-8305617](https://bugs.openjdk.org/browse/JDK-8305617) This pull request has now been integrated. Changeset: 57641190 Author: Serguei Spitsyn URL: https://git.openjdk.org/jdk/commit/5764119024be067ef7afb063a49a14ef59325af6 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod 8303563: GetCurrentThreadCpuTime and GetThreadCpuTime need further clarification for virtual threads Reviewed-by: dholmes, alanb ------------- PR: https://git.openjdk.org/jdk/pull/13338 From dholmes at openjdk.org Thu Apr 6 03:14:15 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 6 Apr 2023 03:14:15 GMT Subject: RFR: 8305622: Remove Permission details from jcmd man page In-Reply-To: <2ZnPee_f5MVgGfoszMLcSuFjqbkCR3VneEuek3iWkZA=.d7268f94-97d4-4a79-a82e-e388721d1589@github.com> References: <2ZnPee_f5MVgGfoszMLcSuFjqbkCR3VneEuek3iWkZA=.d7268f94-97d4-4a79-a82e-e388721d1589@github.com> Message-ID: On Wed, 5 Apr 2023 22:48:45 GMT, Chris Plummer wrote: >> Removal of the Permission information from the jcmd man page. >> >> This information is not useful in the way it is presented, and is not used in connection with jcmd, so should be removed from that man page. >> >> The Permissions can be relevant when connecting remotely to JMX with a Security Manager in place. That usage is clearly deprecated with JEP 411. If there is a transition feature, it will be documented elsewhere. > > src/jdk.jcmd/share/man/jcmd.1 line 410: > >> 408: If false, files are deleted. >> 409: By default, this parameter is disabled. >> 410: .IP \[bu] 2 > > Why is this being removed? I'm guessing the src used to generate the manpage was missing the very recent change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13363#discussion_r1159240634 From lmesnik at openjdk.org Thu Apr 6 03:19:12 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 6 Apr 2023 03:19:12 GMT Subject: RFR: 8305607: Remove some unused test parameters in com/sun/jdi tests [v2] In-Reply-To: References: Message-ID: <7egizfcNuvoiZb8If4pRuVV8_svsy8MpqTZvuGKAKDA=.c01e49c8-dec9-4d28-bfb4-ccd8b267cf79@github.com> > Some tests set debugee name which is set by startUp() method. > > The test/jdk/com/sun/jdi/RedefineNestmateAttr/TestNestmateAttr.java set classpath which is not required. Leonid Mesnik has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' of https://github.com/openjdk/jdk into 8305607 - fixed tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13337/files - new: https://git.openjdk.org/jdk/pull/13337/files/9ed4c893..e52a1714 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13337&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13337&range=00-01 Stats: 36369 lines in 832 files changed: 17274 ins; 15527 del; 3568 mod Patch: https://git.openjdk.org/jdk/pull/13337.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13337/head:pull/13337 PR: https://git.openjdk.org/jdk/pull/13337 From duke at openjdk.org Thu Apr 6 03:27:18 2023 From: duke at openjdk.org (ExE Boss) Date: Thu, 6 Apr 2023 03:27:18 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v4] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Wed, 5 Apr 2023 19:20:08 GMT, Roger Riggs wrote: >> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. >> The enumeration values are defined to match those used in the build. >> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE` >> Note that `amd64` and `x86_64` in the build are represented by `X64`. >> The values of the system property `os.arch` is unchanged. >> >> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). >> Uses in `java.base` and a few others are included but other modules will be done in separate PRs. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Correct spelling of isAARCH64 in WIndows AttachProviderImpl Per?@Glavo?s [comment][GH?13357#r1159047360]: [GH?13357#r1159047360]: https://github.com/openjdk/jdk/pull/13357#discussion_r1159047360 src/java.base/share/classes/jdk/internal/util/Architecture.java line 37: > 35: public enum Architecture { > 36: X64(), // Represents AMD64 and X86_64 > 37: X86(), Suggestion: X86_64(), // Represents AMD64 and X86_64 X86_32(), src/java.base/share/classes/jdk/internal/util/Architecture.java line 39: > 37: X86(), > 38: IA64(), > 39: ARM(), Suggestion: ARM32(), src/java.base/share/classes/jdk/internal/util/Architecture.java line 53: > 51: */ > 52: @ForceInline > 53: public static boolean isX64() { Suggestion: public static boolean isX86_64() { src/java.base/share/classes/jdk/internal/util/Architecture.java line 61: > 59: */ > 60: @ForceInline > 61: public static boolean isX86() { Suggestion: public static boolean isX86_32() { ------------- PR Review: https://git.openjdk.org/jdk/pull/13357#pullrequestreview-1373996601 PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159242846 PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159242963 PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159245067 PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159245163 From duke at openjdk.org Thu Apr 6 03:27:21 2023 From: duke at openjdk.org (ExE Boss) Date: Thu, 6 Apr 2023 03:27:21 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v4] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> <9TzfWvcOSBZeVJB0RL3cMxgXvkXA3Vhp9PR3LgOApwo=.7834e964-b8fe-4deb-8185-2ad8ff27a2c4@github.com> Message-ID: <7EnGBAROZJ-eiWhNUPPVUL2oPQDWGF_7Dd7sPT_ihNs=.c3317c6f-0986-4ba8-8bb2-62cd2b2ba390@github.com> On Wed, 5 Apr 2023 21:36:57 GMT, Glavo wrote: >> src/java.base/share/classes/jdk/internal/util/Architecture.java line 77: >> >>> 75: */ >>> 76: @ForceInline >>> 77: public static boolean isARM() { >> >> It should define what?s the difference to aarch64 for example will aarch64 also be arm, but arm32 wont? (Or remove) > >> It should define what?s the difference to aarch64 for example will aarch64 also be arm, but arm32 wont? (Or remove) > > I think x86 and ARM are a bit confusing in this regard, as they can refer to 32-bit architectures in a narrow sense and 32-bit or 64 bit architectures in a broad sense. > > For clarity, we can use more specific names: `x86-32`/`i686` and `arm32`/`aarch32`. But these names don't seem to be that commonly used. Suggestion: public static boolean isARM32() { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159243677 From cjplummer at openjdk.org Thu Apr 6 03:35:17 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 6 Apr 2023 03:35:17 GMT Subject: RFR: 8305209: JDWP exit error AGENT_ERROR_INVALID_THREAD(203): missing entry in running thread table [v3] In-Reply-To: References: Message-ID: > The real purpose of this PR is to add virtual thread support to ThreadMemoryLeakTest.java, but this exposed bugs in both the debug agent and in TestScaffold, so those are being fixed also (and the debug agent bug is the CR being used). > > The debug agent bug is due to a race condition during VM exit. The VM is in the process of shutting down. The debug agent has already disabled JVMTI callbacks and has sent the VMDeathEvent. At this point in time there are also threads exiting that the debug agent knows about, but it will not get a ThreadEndEvent for because of the callbacks being disabled. Thus these threads remain in the debug agent's list of known threads, even though they have exited. The debuggee receives the VMDeathEvent and does a VM.resume(). During the debug agent's handing of the VM.Resume command, it iterates over all known threads and needs to map each to its ThreadNode so it can be resumed, and this mapping requires accessing the JVMTI TLS for the thread. The problem is some of the threads may have exited already, and therefore no longer have TLS. This results in the assert in the debug agent. This debug agent issue was already addressed for platform threads, but not for virtual threads, which is why we started seeing this issue when this test was modified. The fix is to just replicate what is done for platform threads for virtual threads also. > > The TestScaffold bug is that if the debuggee crashes/asserts, this is likely to go unnoticed, especially if it happens during VM exit (and the test essentially has already completed). Because of this TestScaffold bug, the debug agent bug above did not result in a test failure. After fixing TestScaffold to check the exitCode of the debuggee process, the test started to appropriately fail until the debug agent was fixed. > > One other thing to point out is the OOME issue I started getting frequently when testing with virtual threads. Since virtual threads are created at a much higher rate than platform threads, their creation started to overwhelm the debugger (actually the JDI implementation). There is already a mechanism in place to do a VM.HoldEvents if JDI has queue up 10,000 events. The problem is that events are coming in so fast that even after doing the VM.HoldEvents, the number of queued events continues to go up for a while, and sometimes reaches 30,000 or more. This raises the peak memory usage of the test quite a bit. Since the test purposely uses a small heap so a memory leak is quickly and reliably detected, the large queue often results in an OOME. Because of this I make virtual threads sleep for 100ms instead of 50ms to slow down their creation, and this resolved the issue. > > I tested by running all of test/jdk/com/sun/jdi 25 times on each platform with and without virtual thread testing enabled. Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: TestScaffold now waits indefinitely for process exit. Simpler coding of sleep time. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13246/files - new: https://git.openjdk.org/jdk/pull/13246/files/28a337d1..7b02bef2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13246&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13246&range=01-02 Stats: 19 lines in 2 files changed: 0 ins; 7 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/13246.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13246/head:pull/13246 PR: https://git.openjdk.org/jdk/pull/13246 From lmesnik at openjdk.org Thu Apr 6 03:35:24 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 6 Apr 2023 03:35:24 GMT Subject: Integrated: 8305607: Remove some unused test parameters in com/sun/jdi tests In-Reply-To: References: Message-ID: On Tue, 4 Apr 2023 20:15:41 GMT, Leonid Mesnik wrote: > Some tests set debugee name which is set by startUp() method. > > The test/jdk/com/sun/jdi/RedefineNestmateAttr/TestNestmateAttr.java set classpath which is not required. This pull request has now been integrated. Changeset: 35d22930 Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/35d22930bbb9f038273361d8a1a07d07f3766735 Stats: 12 lines in 5 files changed: 0 ins; 2 del; 10 mod 8305607: Remove some unused test parameters in com/sun/jdi tests Reviewed-by: sspitsyn, amenkov, cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/13337 From lmesnik at openjdk.org Thu Apr 6 03:51:15 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 6 Apr 2023 03:51:15 GMT Subject: RFR: 8305209: JDWP exit error AGENT_ERROR_INVALID_THREAD(203): missing entry in running thread table [v3] In-Reply-To: References: Message-ID: On Thu, 6 Apr 2023 03:35:17 GMT, Chris Plummer wrote: >> The real purpose of this PR is to add virtual thread support to ThreadMemoryLeakTest.java, but this exposed bugs in both the debug agent and in TestScaffold, so those are being fixed also (and the debug agent bug is the CR being used). >> >> The debug agent bug is due to a race condition during VM exit. The VM is in the process of shutting down. The debug agent has already disabled JVMTI callbacks and has sent the VMDeathEvent. At this point in time there are also threads exiting that the debug agent knows about, but it will not get a ThreadEndEvent for because of the callbacks being disabled. Thus these threads remain in the debug agent's list of known threads, even though they have exited. The debuggee receives the VMDeathEvent and does a VM.resume(). During the debug agent's handing of the VM.Resume command, it iterates over all known threads and needs to map each to its ThreadNode so it can be resumed, and this mapping requires accessing the JVMTI TLS for the thread. The problem is some of the threads may have exited already, and therefore no longer have TLS. This results in the assert in the debug agent. This debug agent issue was already addressed for platform threads, but not for virtual threads, which is why w e started seeing this issue when this test was modified. The fix is to just replicate what is done for platform threads for virtual threads also. >> >> The TestScaffold bug is that if the debuggee crashes/asserts, this is likely to go unnoticed, especially if it happens during VM exit (and the test essentially has already completed). Because of this TestScaffold bug, the debug agent bug above did not result in a test failure. After fixing TestScaffold to check the exitCode of the debuggee process, the test started to appropriately fail until the debug agent was fixed. >> >> One other thing to point out is the OOME issue I started getting frequently when testing with virtual threads. Since virtual threads are created at a much higher rate than platform threads, their creation started to overwhelm the debugger (actually the JDI implementation). There is already a mechanism in place to do a VM.HoldEvents if JDI has queue up 10,000 events. The problem is that events are coming in so fast that even after doing the VM.HoldEvents, the number of queued events continues to go up for a while, and sometimes reaches 30,000 or more. This raises the peak memory usage of the test quite a bit. Since the test purposely uses a small heap so a memory leak is quickly and reliably detected, the large queue often results in an OOME. Because of this I make virtual threads sleep for 100ms instead of 50ms to slow down their creation, and this resolved the issue. >> >> I tested by running all of test/jdk/com/sun/jdi 25 times on each platform with and without virtual thread testing enabled. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > TestScaffold now waits indefinitely for process exit. Simpler coding of sleep time. Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13246#pullrequestreview-1374011838 From stuefe at openjdk.org Thu Apr 6 05:12:51 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 6 Apr 2023 05:12:51 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v54] In-Reply-To: References: Message-ID: On Wed, 5 Apr 2023 10:40:54 GMT, Roman Kennke wrote: >> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). >> >> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. >> >> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal protocols. >> >> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare. >> >> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. >> >> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. >> >> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. >> >> This change enables to simplify (and speed-up!) a lot of code: >> >> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. >> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR >> >> Also, and I might be mistaken here, this new lightweight locking would make synchronized work better with Loom: Because the lock-records are no longer scattered across the stack, but instead are densely packed into the lock-stack, it should be easy for a vthread to save its lock-stack upon unmounting and restore it when re-mounting. However, I am not sure about this, and this PR does not attempt to implement that support. >> >> Testing: >> - [x] tier1 x86_64 x aarch64 x +UseFastLocking >> - [x] tier2 x86_64 x aarch64 x +UseFastLocking >> - [x] tier3 x86_64 x aarch64 x +UseFastLocking >> - [x] tier4 x86_64 x aarch64 x +UseFastLocking >> - [x] tier1 x86_64 x aarch64 x -UseFastLocking >> - [x] tier2 x86_64 x aarch64 x -UseFastLocking >> - [x] tier3 x86_64 x aarch64 x -UseFastLocking >> - [x] tier4 x86_64 x aarch64 x -UseFastLocking >> - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet >> >> ### Performance >> >> #### Simple Microbenchmark >> >> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops. >> >> | | x86_64 | aarch64 | >> | -- | -- | -- | >> | -UseFastLocking | 20.651 | 20.764 | >> | +UseFastLocking | 18.896 | 18.908 | >> >> >> #### Renaissance >> >> ? | x86_64 | ? | ? | ? | aarch64 | ? | ? >> -- | -- | -- | -- | -- | -- | -- | -- >> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? >> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% >> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21% >> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% >> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% >> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% >> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% >> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%% >> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% >> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% >> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% >> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% >> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34% >> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% >> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% >> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% >> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% >> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% >> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% >> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% >> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% >> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Named constants for LockingMode src/hotspot/share/utilities/globalDefinitions.hpp line 1045: > 1043: }; > 1044: > 1045: enum LockingMode { Thank you for having named constants. But I'd use enum class here. Either that or prefix the names with something like "LM_", but enum class is preferred. The names are far to generic for global scope, especially since this lives in globalDefinitions.hpp. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1159287860 From fyang at openjdk.org Thu Apr 6 06:02:55 2023 From: fyang at openjdk.org (Fei Yang) Date: Thu, 6 Apr 2023 06:02:55 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v55] In-Reply-To: References: Message-ID: On Wed, 5 Apr 2023 16:17:44 GMT, Roman Kennke wrote: >> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). >> >> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. >> >> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal protocols. >> >> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare. >> >> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. >> >> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. >> >> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. >> >> This change enables to simplify (and speed-up!) a lot of code: >> >> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. >> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR >> >> Also, and I might be mistaken here, this new lightweight locking would make synchronized work better with Loom: Because the lock-records are no longer scattered across the stack, but instead are densely packed into the lock-stack, it should be easy for a vthread to save its lock-stack upon unmounting and restore it when re-mounting. However, I am not sure about this, and this PR does not attempt to implement that support. >> >> Testing: >> - [x] tier1 x86_64 x aarch64 x +UseFastLocking >> - [x] tier2 x86_64 x aarch64 x +UseFastLocking >> - [x] tier3 x86_64 x aarch64 x +UseFastLocking >> - [x] tier4 x86_64 x aarch64 x +UseFastLocking >> - [x] tier1 x86_64 x aarch64 x -UseFastLocking >> - [x] tier2 x86_64 x aarch64 x -UseFastLocking >> - [x] tier3 x86_64 x aarch64 x -UseFastLocking >> - [x] tier4 x86_64 x aarch64 x -UseFastLocking >> - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet >> >> ### Performance >> >> #### Simple Microbenchmark >> >> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops. >> >> | | x86_64 | aarch64 | >> | -- | -- | -- | >> | -UseFastLocking | 20.651 | 20.764 | >> | +UseFastLocking | 18.896 | 18.908 | >> >> >> #### Renaissance >> >> ? | x86_64 | ? | ? | ? | aarch64 | ? | ? >> -- | -- | -- | -- | -- | -- | -- | -- >> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? >> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% >> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21% >> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% >> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% >> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% >> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% >> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%% >> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% >> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% >> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% >> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% >> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34% >> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% >> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% >> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% >> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% >> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% >> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% >> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% >> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% >> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Put back thread type check in OS::is_lock_owned() src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 6261: > 6259: { > 6260: // The following checks rely on the fact that LockStack is only ever modified by > 6261: // its owning stack, even if the lock got inflated concurrently; removal of LockStack Suggestion: s/its owning stack/its owning thread/ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1159314439 From sspitsyn at openjdk.org Thu Apr 6 06:34:15 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 6 Apr 2023 06:34:15 GMT Subject: RFR: 8305209: JDWP exit error AGENT_ERROR_INVALID_THREAD(203): missing entry in running thread table [v3] In-Reply-To: References: Message-ID: On Thu, 6 Apr 2023 03:35:17 GMT, Chris Plummer wrote: >> The real purpose of this PR is to add virtual thread support to ThreadMemoryLeakTest.java, but this exposed bugs in both the debug agent and in TestScaffold, so those are being fixed also (and the debug agent bug is the CR being used). >> >> The debug agent bug is due to a race condition during VM exit. The VM is in the process of shutting down. The debug agent has already disabled JVMTI callbacks and has sent the VMDeathEvent. At this point in time there are also threads exiting that the debug agent knows about, but it will not get a ThreadEndEvent for because of the callbacks being disabled. Thus these threads remain in the debug agent's list of known threads, even though they have exited. The debuggee receives the VMDeathEvent and does a VM.resume(). During the debug agent's handing of the VM.Resume command, it iterates over all known threads and needs to map each to its ThreadNode so it can be resumed, and this mapping requires accessing the JVMTI TLS for the thread. The problem is some of the threads may have exited already, and therefore no longer have TLS. This results in the assert in the debug agent. This debug agent issue was already addressed for platform threads, but not for virtual threads, which is why w e started seeing this issue when this test was modified. The fix is to just replicate what is done for platform threads for virtual threads also. >> >> The TestScaffold bug is that if the debuggee crashes/asserts, this is likely to go unnoticed, especially if it happens during VM exit (and the test essentially has already completed). Because of this TestScaffold bug, the debug agent bug above did not result in a test failure. After fixing TestScaffold to check the exitCode of the debuggee process, the test started to appropriately fail until the debug agent was fixed. >> >> One other thing to point out is the OOME issue I started getting frequently when testing with virtual threads. Since virtual threads are created at a much higher rate than platform threads, their creation started to overwhelm the debugger (actually the JDI implementation). There is already a mechanism in place to do a VM.HoldEvents if JDI has queue up 10,000 events. The problem is that events are coming in so fast that even after doing the VM.HoldEvents, the number of queued events continues to go up for a while, and sometimes reaches 30,000 or more. This raises the peak memory usage of the test quite a bit. Since the test purposely uses a small heap so a memory leak is quickly and reliably detected, the large queue often results in an OOME. Because of this I make virtual threads sleep for 100ms instead of 50ms to slow down their creation, and this resolved the issue. >> >> I tested by running all of test/jdk/com/sun/jdi 25 times on each platform with and without virtual thread testing enabled. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > TestScaffold now waits indefinitely for process exit. Simpler coding of sleep time. Marked as reviewed by sspitsyn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13246#pullrequestreview-1374133992 From alanb at openjdk.org Thu Apr 6 06:50:15 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 6 Apr 2023 06:50:15 GMT Subject: RFR: 8305622: Remove Permission details from jcmd man page In-Reply-To: References: Message-ID: On Wed, 5 Apr 2023 21:00:55 GMT, Kevin Walls wrote: > Removal of the Permission information from the jcmd man page. > > This information is not useful in the way it is presented, and is not used in connection with jcmd, so should be removed from that man page. > > The Permissions can be relevant when connecting remotely to JMX with a Security Manager in place. That usage is clearly deprecated with JEP 411. If there is a transition feature, it will be documented elsewhere. The SM permissions were interesting when connected to a MBeanServerConnection to access MXBeans remotely. A bit puzzling why they would be printed as the usage for commands executed by jcmd. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13363#issuecomment-1498573459 From fyang at openjdk.org Thu Apr 6 07:30:58 2023 From: fyang at openjdk.org (Fei Yang) Date: Thu, 6 Apr 2023 07:30:58 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v55] In-Reply-To: References: Message-ID: On Wed, 5 Apr 2023 16:17:44 GMT, Roman Kennke wrote: >> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). >> >> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. >> >> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal protocols. >> >> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare. >> >> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. >> >> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. >> >> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. >> >> This change enables to simplify (and speed-up!) a lot of code: >> >> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. >> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR >> >> Also, and I might be mistaken here, this new lightweight locking would make synchronized work better with Loom: Because the lock-records are no longer scattered across the stack, but instead are densely packed into the lock-stack, it should be easy for a vthread to save its lock-stack upon unmounting and restore it when re-mounting. However, I am not sure about this, and this PR does not attempt to implement that support. >> >> Testing: >> - [x] tier1 x86_64 x aarch64 x +UseFastLocking >> - [x] tier2 x86_64 x aarch64 x +UseFastLocking >> - [x] tier3 x86_64 x aarch64 x +UseFastLocking >> - [x] tier4 x86_64 x aarch64 x +UseFastLocking >> - [x] tier1 x86_64 x aarch64 x -UseFastLocking >> - [x] tier2 x86_64 x aarch64 x -UseFastLocking >> - [x] tier3 x86_64 x aarch64 x -UseFastLocking >> - [x] tier4 x86_64 x aarch64 x -UseFastLocking >> - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet >> >> ### Performance >> >> #### Simple Microbenchmark >> >> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops. >> >> | | x86_64 | aarch64 | >> | -- | -- | -- | >> | -UseFastLocking | 20.651 | 20.764 | >> | +UseFastLocking | 18.896 | 18.908 | >> >> >> #### Renaissance >> >> ? | x86_64 | ? | ? | ? | aarch64 | ? | ? >> -- | -- | -- | -- | -- | -- | -- | -- >> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? >> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% >> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21% >> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% >> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% >> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% >> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% >> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%% >> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% >> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% >> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% >> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% >> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34% >> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% >> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% >> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% >> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% >> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% >> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% >> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% >> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% >> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Put back thread type check in OS::is_lock_owned() Some update for riscv to reflect the latest changes: [riscv-update.txt](https://github.com/openjdk/jdk/files/11167462/riscv-update.txt) ------------- PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1498612617 From pminborg at openjdk.org Thu Apr 6 07:39:17 2023 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 6 Apr 2023 07:39:17 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v4] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Wed, 5 Apr 2023 19:20:08 GMT, Roger Riggs wrote: >> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. >> The enumeration values are defined to match those used in the build. >> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE` >> Note that `amd64` and `x86_64` in the build are represented by `X64`. >> The values of the system property `os.arch` is unchanged. >> >> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). >> Uses in `java.base` and a few others are included but other modules will be done in separate PRs. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Correct spelling of isAARCH64 in WIndows AttachProviderImpl src/java.base/share/classes/jdk/internal/util/Architecture.java line 114: > 112: > 113: /** > 114: * {@return return the current architecture} Suggestion : {@return the current architecture}. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159396971 From pminborg at openjdk.org Thu Apr 6 07:45:16 2023 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 6 Apr 2023 07:45:16 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v4] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Wed, 5 Apr 2023 19:20:08 GMT, Roger Riggs wrote: >> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. >> The enumeration values are defined to match those used in the build. >> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE` >> Note that `amd64` and `x86_64` in the build are represented by `X64`. >> The values of the system property `os.arch` is unchanged. >> >> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). >> Uses in `java.base` and a few others are included but other modules will be done in separate PRs. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Correct spelling of isAARCH64 in WIndows AttachProviderImpl src/java.base/share/classes/jdk/internal/util/Architecture.java line 2: > 1: /* > 2: * Copyright (c) 2018, 2023, Oracle and/or its affiliates. All rights reserved. Why 2018? src/java.base/share/classes/jdk/internal/util/Architecture.java line 85: > 83: */ > 84: @ForceInline > 85: public static boolean isRISCV64() { Are all the "isers" necessary to provide constant code folding or is the samt thing achievable via expressions like `(Architecture.current() == Architecture.X)` ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159404227 PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159402728 From duke at openjdk.org Thu Apr 6 08:02:19 2023 From: duke at openjdk.org (ExE Boss) Date: Thu, 6 Apr 2023 08:02:19 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v4] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Thu, 6 Apr 2023 07:36:36 GMT, Per Minborg wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Correct spelling of isAARCH64 in WIndows AttachProviderImpl > > src/java.base/share/classes/jdk/internal/util/Architecture.java line 114: > >> 112: >> 113: /** >> 114: * {@return return the current architecture} > > Suggestion : > > {@return the current architecture}. Suggestion: * {@return the current architecture}. -------------------------------------------------------------------------------- @minborg You?need to?use: Suggestion: * {@return the current architecture}. For?**GitHub** to?recognise?it as?a?suggestion. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159422715 From duke at openjdk.org Thu Apr 6 08:08:20 2023 From: duke at openjdk.org (ExE Boss) Date: Thu, 6 Apr 2023 08:08:20 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v4] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Wed, 5 Apr 2023 19:20:08 GMT, Roger Riggs wrote: >> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. >> The enumeration values are defined to match those used in the build. >> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE` >> Note that `amd64` and `x86_64` in the build are represented by `X64`. >> The values of the system property `os.arch` is unchanged. >> >> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). >> Uses in `java.base` and a few others are included but other modules will be done in separate PRs. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Correct spelling of isAARCH64 in WIndows AttachProviderImpl src/java.base/share/classes/jdk/internal/util/Architecture.java line 26: > 24: > 25: import jdk.internal.vm.annotation.ForceInline; > 26: Suggestion: import jdk.internal.vm.annotation.ForceInline; import jdk.internal.vm.annotation.Stable; src/java.base/share/classes/jdk/internal/util/Architecture.java line 47: > 45: > 46: // Cache a copy of the array for lightweight indexing > 47: private static final Architecture[] archValues = Architecture.values(); This?needs to?be?annotated with?`@jdk.internal.vm.annotation.Stable` for?`Architecture.current()` to?be?constant?foldable: Suggestion: private static final @Stable Architecture[] archValues = Architecture.values(); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159426832 PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159424057 From duke at openjdk.org Thu Apr 6 08:08:23 2023 From: duke at openjdk.org (ExE Boss) Date: Thu, 6 Apr 2023 08:08:23 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v4] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Thu, 6 Apr 2023 07:40:50 GMT, Per Minborg wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Correct spelling of isAARCH64 in WIndows AttachProviderImpl > > src/java.base/share/classes/jdk/internal/util/Architecture.java line 85: > >> 83: */ >> 84: @ForceInline >> 85: public static boolean isRISCV64() { > > Are all the "isers" necessary to provide constant code folding or is the samt thing achievable via expressions like `(Architecture.current() == Architecture.X)` ? `Architecture.current()`?requires the?`Architecture.archValues` array to?be?annotated with?`@jdk.internal.vm.annotation.Stable` for?it?to?be?constant?foldable by?the?JIT. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159428913 From duke at openjdk.org Thu Apr 6 08:16:19 2023 From: duke at openjdk.org (Glavo) Date: Thu, 6 Apr 2023 08:16:19 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v4] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> <9TzfWvcOSBZeVJB0RL3cMxgXvkXA3Vhp9PR3LgOApwo=.7834e964-b8fe-4deb-8185-2ad8ff27a2c4@github.com> <1HKkKI-yuCGm_7ojnOgq0VCK-uJyAnsnXp4KYsrXW0M=.fbe8d18f-e9a6-4032-b9d3-6de15297f8d1@github.com> Message-ID: <7w-PPxtMpjBDyYgYeIuNwR_Ntbd-6T2Ja_umzjWFRLA=.548725ca-0692-4e1f-82a7-5e6689317cae@github.com> On Wed, 5 Apr 2023 23:46:33 GMT, Jorn Vernee wrote: > Right, it is still possible to run a 32-bit VM build on a 64-bit platform. `os.arch` can be `amd64`, the runtime platform, in this case, but the VM variant can still be 32 bits. `os.arch` is always the target architecture for JVM, even using 32-bit JVM on 64-bit system, its value remains x86. But as mentioned above, the size of the address can be independent of these. Linux x32 ABI is an ABI for the x86-64 architecture, which uses unique features of 64-bit architectures such as 64-bit registers, but it uses 32-bit addresses. Although OpenJDK does not support such a platform, technically speaking, it is still necessary to distinguish between architecture bits and address bits. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159438411 From kevinw at openjdk.org Thu Apr 6 08:38:02 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 6 Apr 2023 08:38:02 GMT Subject: RFR: 8305622: Remove Permission details from jcmd man page [v2] In-Reply-To: References: Message-ID: > Removal of the Permission information from the jcmd man page. > > This information is not useful in the way it is presented, and is not used in connection with jcmd, so should be removed from that man page. > > The Permissions can be relevant when connecting remotely to JMX with a Security Manager in place. That usage is clearly deprecated with JEP 411. If there is a transition feature, it will be documented elsewhere. Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: sync ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13363/files - new: https://git.openjdk.org/jdk/pull/13363/files/9994a90b..e9d62bb5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13363&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13363&range=00-01 Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13363.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13363/head:pull/13363 PR: https://git.openjdk.org/jdk/pull/13363 From kevinw at openjdk.org Thu Apr 6 08:38:05 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 6 Apr 2023 08:38:05 GMT Subject: RFR: 8305622: Remove Permission details from jcmd man page [v2] In-Reply-To: References: <2ZnPee_f5MVgGfoszMLcSuFjqbkCR3VneEuek3iWkZA=.d7268f94-97d4-4a79-a82e-e388721d1589@github.com> Message-ID: On Thu, 6 Apr 2023 03:11:34 GMT, David Holmes wrote: >> src/jdk.jcmd/share/man/jcmd.1 line 410: >> >>> 408: If false, files are deleted. >>> 409: By default, this parameter is disabled. >>> 410: .IP \[bu] 2 >> >> Why is this being removed? > > I'm guessing the src used to generate the manpage was missing the very recent change. Yes, it was rush hour in the jcmd man page, the changes overlapped. Updated this change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13363#discussion_r1159466247 From kevinw at openjdk.org Thu Apr 6 08:55:21 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 6 Apr 2023 08:55:21 GMT Subject: RFR: 8305680: Remove Permissions from jcmd help output Message-ID: <232Cd_P8bHHsUTUNmLfBbs6Hqzi9nGGZXmIVJi4OHJ8=.521404a7-a8eb-4b62-be17-8159216c9d9d@github.com> Like the removal of Permission information from the man page in JDK-8305622, this change removes Permission information from the jcmd help output. These Permissions are not relevant to jcmd users. The Permissions can be relevant when connecting remotely to JMX with a Security Manager in place. That usage is clearly deprecated with JEP 411. We don't specifically test for this output, but we have dcmd tests in test/hotspot/jtreg/serviceability which all continue to pass. ------------- Commit messages: - 8305680: Remove Permissions from jcmd help output Changes: https://git.openjdk.org/jdk/pull/13371/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13371&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8305680 Stats: 10 lines in 1 file changed: 0 ins; 10 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13371.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13371/head:pull/13371 PR: https://git.openjdk.org/jdk/pull/13371 From mbaesken at openjdk.org Thu Apr 6 11:13:10 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 6 Apr 2023 11:13:10 GMT Subject: RFR: 8304725: AsyncGetCallTrace can cause SIGBUS on M1 [v5] In-Reply-To: References: Message-ID: On Mon, 3 Apr 2023 08:29:55 GMT, Johannes Bechberger wrote: >> Fixes the issue by disabling PCDesc cache modifications when in ASGCT. >> >> Tested on my M1 mac. > > Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision: > > - Fix fix > - Fix minor issues LGTM. I would like a short comment line in nmethod.cpp and/or forte.cpp shortly describing what you do and why but up to you. ------------- Marked as reviewed by mbaesken (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13144#pullrequestreview-1374643965 From jbechberger at openjdk.org Thu Apr 6 11:37:52 2023 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Thu, 6 Apr 2023 11:37:52 GMT Subject: RFR: 8304725: AsyncGetCallTrace can cause SIGBUS on M1 [v5] In-Reply-To: References: Message-ID: <9Ov7dy2ZGMsxEr8rM_7L6Nt3YqYHX3k_iWlobwy3h8I=.a9200352-e1d6-4d81-a284-21e32814b9a7@github.com> On Mon, 3 Apr 2023 08:29:55 GMT, Johannes Bechberger wrote: >> Fixes the issue by disabling PCDesc cache modifications when in ASGCT. >> >> Tested on my M1 mac. > > Johannes Bechberger has updated the pull request incrementally with two additional commits since the last revision: > > - Fix fix > - Fix minor issues I added two comments :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/13144#issuecomment-1498919468 From jbechberger at openjdk.org Thu Apr 6 11:37:48 2023 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Thu, 6 Apr 2023 11:37:48 GMT Subject: RFR: 8304725: AsyncGetCallTrace can cause SIGBUS on M1 [v6] In-Reply-To: References: Message-ID: > Fixes the issue by disabling PCDesc cache modifications when in ASGCT. > > Tested on my M1 mac. Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision: Add comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13144/files - new: https://git.openjdk.org/jdk/pull/13144/files/6f1108ed..5d9df9a6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13144&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13144&range=04-05 Stats: 3 lines in 2 files changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13144.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13144/head:pull/13144 PR: https://git.openjdk.org/jdk/pull/13144 From rkennke at openjdk.org Thu Apr 6 11:59:45 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 6 Apr 2023 11:59:45 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v56] In-Reply-To: References: Message-ID: > This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). > > What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. > > This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p rotocols. > > The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare. > > In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. > > One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. > > As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. > > This change enables to simplify (and speed-up!) a lot of code: > > - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. > - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR > > Also, and I might be mistaken here, this new lightweight locking would make synchronized work better with Loom: Because the lock-records are no longer scattered across the stack, but instead are densely packed into the lock-stack, it should be easy for a vthread to save its lock-stack upon unmounting and restore it when re-mounting. However, I am not sure about this, and this PR does not attempt to implement that support. > > Testing: > - [x] tier1 x86_64 x aarch64 x +UseFastLocking > - [x] tier2 x86_64 x aarch64 x +UseFastLocking > - [x] tier3 x86_64 x aarch64 x +UseFastLocking > - [x] tier4 x86_64 x aarch64 x +UseFastLocking > - [x] tier1 x86_64 x aarch64 x -UseFastLocking > - [x] tier2 x86_64 x aarch64 x -UseFastLocking > - [x] tier3 x86_64 x aarch64 x -UseFastLocking > - [x] tier4 x86_64 x aarch64 x -UseFastLocking > - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet > > ### Performance > > #### Simple Microbenchmark > > The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops. > > | | x86_64 | aarch64 | > | -- | -- | -- | > | -UseFastLocking | 20.651 | 20.764 | > | +UseFastLocking | 18.896 | 18.908 | > > > #### Renaissance > > ? | x86_64 | ? | ? | ? | aarch64 | ? | ? > -- | -- | -- | -- | -- | -- | -- | -- > ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? > AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% > Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21% > Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% > ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% > GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% > LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% > MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%% > NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% > PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% > FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% > FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% > ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34% > Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% > RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% > Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% > ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% > FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% > FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: RISCV update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10907/files - new: https://git.openjdk.org/jdk/pull/10907/files/963de0ef..d1c88261 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=55 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=54-55 Stats: 73 lines in 5 files changed: 60 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/10907.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/10907/head:pull/10907 PR: https://git.openjdk.org/jdk/pull/10907 From rkennke at openjdk.org Thu Apr 6 11:59:45 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 6 Apr 2023 11:59:45 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v55] In-Reply-To: References: Message-ID: On Thu, 6 Apr 2023 07:27:27 GMT, Fei Yang wrote: > Some update for riscv to reflect the latest changes: [riscv-update.txt](https://github.com/openjdk/jdk/files/11167462/riscv-update.txt) Thank you! The patch did apply with fuzz - I pushed it as it is, can you check if it's still ok? Thanks, Roman ------------- PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1498945218 From jvernee at openjdk.org Thu Apr 6 12:32:16 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 6 Apr 2023 12:32:16 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v4] In-Reply-To: <7w-PPxtMpjBDyYgYeIuNwR_Ntbd-6T2Ja_umzjWFRLA=.548725ca-0692-4e1f-82a7-5e6689317cae@github.com> References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> <9TzfWvcOSBZeVJB0RL3cMxgXvkXA3Vhp9PR3LgOApwo=.7834e964-b8fe-4deb-8185-2ad8ff27a2c4@github.com> <1HKkKI-yuCGm_7ojnOgq0VCK-uJyAnsnXp4KYsrXW0M=.fbe8d18f-e9a6-4032-b9d3-6de15297f8d1@github.com> <7w-PPxtMpjBDyYgYeIuNwR_Ntbd-6T2Ja_umzjWFRLA=.548725ca-0692-4e1f-82a7-5e6689317cae@github.com> Message-ID: On Thu, 6 Apr 2023 08:11:45 GMT, Glavo wrote: > os.arch is always the target architecture for JVM, even using 32-bit JVM on 64-bit system, its value remains x86. Okay, I could have sworn we had to add the `ADDRESS_SIZE` check because of this issue where a 32-bit VM running on x64 would erroneously select the x64 ABIs. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159734833 From rriggs at openjdk.org Thu Apr 6 13:34:13 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 6 Apr 2023 13:34:13 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v4] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Thu, 6 Apr 2023 03:17:37 GMT, ExE Boss wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Correct spelling of isAARCH64 in WIndows AttachProviderImpl > > src/java.base/share/classes/jdk/internal/util/Architecture.java line 37: > >> 35: public enum Architecture { >> 36: X64(), // Represents AMD64 and X86_64 >> 37: X86(), > > Suggestion: > > X86_64(), // Represents AMD64 and X86_64 > X86_32(), The underscores are too ugly and X86 and X64 are well accepted names for those architectures. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159804212 From rriggs at openjdk.org Thu Apr 6 13:34:16 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 6 Apr 2023 13:34:16 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v4] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Wed, 5 Apr 2023 23:39:00 GMT, Jorn Vernee wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Correct spelling of isAARCH64 in WIndows AttachProviderImpl > > test/jdk/java/foreign/TestUnsupportedLinker.java line 26: > >> 24: /* >> 25: * @test >> 26: * @ignore architecture can not be overridden by setting os.arch - delete test > > FWIW, we introduce a property in CABI to override it directly in the JEP patch: https://github.com/openjdk/jdk/pull/13079/files#diff-1e9526318ae485495af012cbf0450693d77fd8241be62afe422a75304de5aed1R28 I'll drop the changes to foreign to avoid conflicts with PR #13079. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159801845 From rriggs at openjdk.org Thu Apr 6 13:41:21 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 6 Apr 2023 13:41:21 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v4] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Thu, 6 Apr 2023 07:41:48 GMT, Per Minborg wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Correct spelling of isAARCH64 in WIndows AttachProviderImpl > > src/java.base/share/classes/jdk/internal/util/Architecture.java line 2: > >> 1: /* >> 2: * Copyright (c) 2018, 2023, Oracle and/or its affiliates. All rights reserved. > > Why 2018? Copy/paste error. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159813009 From jpai at openjdk.org Thu Apr 6 13:41:24 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 6 Apr 2023 13:41:24 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v4] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Wed, 5 Apr 2023 19:20:08 GMT, Roger Riggs wrote: >> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. >> The enumeration values are defined to match those used in the build. >> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE` >> Note that `amd64` and `x86_64` in the build are represented by `X64`. >> The values of the system property `os.arch` is unchanged. >> >> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). >> Uses in `java.base` and a few others are included but other modules will be done in separate PRs. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Correct spelling of isAARCH64 in WIndows AttachProviderImpl src/java.base/share/classes/jdk/internal/util/Architecture.java line 42: > 40: AARCH64(), > 41: RISCV64(), > 42: S390X(), Hello Roger, in a recent unrelated discussion, @RealLucy noted here https://github.com/openjdk/jdk/pull/13228#issuecomment-1488650865 that `s390x` denotes the arch and operating system combination and `s390` on the other hand represents the architecture. So should this enum value instead be `S390`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159810942 From rriggs at openjdk.org Thu Apr 6 13:41:26 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 6 Apr 2023 13:41:26 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v4] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Thu, 6 Apr 2023 08:05:14 GMT, ExE Boss wrote: >> src/java.base/share/classes/jdk/internal/util/Architecture.java line 85: >> >>> 83: */ >>> 84: @ForceInline >>> 85: public static boolean isRISCV64() { >> >> Are all the "isers" necessary to provide constant code folding or is the samt thing achievable via expressions like `(Architecture.current() == Architecture.X)` ? > > `Architecture.current()`?requires the?`Architecture.archValues` array to?be?annotated with?`@jdk.internal.vm.annotation.Stable` for?it?to?be?constant?foldable by?the?JIT. The `isXXX` is lighterweight and easier to read. With current compiler technology, it can result in dead code elimination. The HotSpot compiler reduces `(Architecture.current() == Architecture.X)` at runtime. Project Leyden may enable dead code based on evaluating more complex expressions as above. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159811629 From alanb at openjdk.org Thu Apr 6 14:07:16 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 6 Apr 2023 14:07:16 GMT Subject: RFR: 8299414: JVMTI FollowReferences should support references from VirtualThread stack [v2] In-Reply-To: References: <6oQOD_egcB3HyuagMWGSPLjKSE3JkaI2K2WOsDK1Cww=.c568223b-5100-4425-a4b7-defbd812a9ff@github.com> Message-ID: On Wed, 5 Apr 2023 21:09:09 GMT, Alex Menkov wrote: >> The fix updates JVMTI FollowReferences implementation to report references from virtual threads: >> - added heap scanning to report unmounted vthreads; >> - stacks of mounted vthreads are splitted into 2 parts (vittual thread stack and carrier thread stack), references are reported with correct thread id/class and object tags/frame depth; >> - common code to handle stack frames are moved into separate class; > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > aree -> are Do I read it correctly that the entire heap is walked to find the unmounted virtual threads? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13254#issuecomment-1499116956 From rriggs at openjdk.org Thu Apr 6 14:11:19 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 6 Apr 2023 14:11:19 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v4] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Thu, 6 Apr 2023 03:17:57 GMT, ExE Boss wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Correct spelling of isAARCH64 in WIndows AttachProviderImpl > > src/java.base/share/classes/jdk/internal/util/Architecture.java line 39: > >> 37: X86(), >> 38: IA64(), >> 39: ARM(), > > Suggestion: > > ARM32(), I'm inclined to drop the enum value and isArm method because they are legacy and are not being used in OpenJDK sources. This could also apply to IA64. They can be added if needed and otherwise are just unused bulk. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159852394 From lmesnik at openjdk.org Thu Apr 6 14:15:25 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 6 Apr 2023 14:15:25 GMT Subject: RFR: 8305608: Change VMConnection to use "test.class.path"instead of "test.classes" [v3] In-Reply-To: References: Message-ID: > Currently, VMConnection run debugee using "test.classes" as a classpath. It cause test failures when virtual thread factory (wrapper) is enabled and test is not located the same directory as TestScaffold. Leonid Mesnik has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Merge branch 'master' of https://github.com/openjdk/jdk into 8305608 - fix - more tests are added - updated vmconnection ------------- Changes: https://git.openjdk.org/jdk/pull/13339/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13339&range=02 Stats: 19 lines in 2 files changed: 1 ins; 12 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/13339.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13339/head:pull/13339 PR: https://git.openjdk.org/jdk/pull/13339 From lmesnik at openjdk.org Thu Apr 6 14:15:26 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 6 Apr 2023 14:15:26 GMT Subject: Integrated: 8305608: Change VMConnection to use "test.class.path"instead of "test.classes" In-Reply-To: References: Message-ID: On Tue, 4 Apr 2023 20:42:34 GMT, Leonid Mesnik wrote: > Currently, VMConnection run debugee using "test.classes" as a classpath. It cause test failures when virtual thread factory (wrapper) is enabled and test is not located the same directory as TestScaffold. This pull request has now been integrated. Changeset: ddd50d0d Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/ddd50d0db31e50c0fcedafa290d6eac277ddae3e Stats: 19 lines in 2 files changed: 1 ins; 12 del; 6 mod 8305608: Change VMConnection to use "test.class.path"instead of "test.classes" Reviewed-by: cjplummer, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/13339 From dcubed at openjdk.org Thu Apr 6 14:27:14 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 6 Apr 2023 14:27:14 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v56] In-Reply-To: References: Message-ID: On Thu, 6 Apr 2023 11:59:45 GMT, Roman Kennke wrote: >> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). >> >> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. >> >> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal protocols. >> >> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare. >> >> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. >> >> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. >> >> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. >> >> This change enables to simplify (and speed-up!) a lot of code: >> >> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. >> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR >> >> Also, and I might be mistaken here, this new lightweight locking would make synchronized work better with Loom: Because the lock-records are no longer scattered across the stack, but instead are densely packed into the lock-stack, it should be easy for a vthread to save its lock-stack upon unmounting and restore it when re-mounting. However, I am not sure about this, and this PR does not attempt to implement that support. >> >> Testing: >> - [x] tier1 x86_64 x aarch64 x +UseFastLocking >> - [x] tier2 x86_64 x aarch64 x +UseFastLocking >> - [x] tier3 x86_64 x aarch64 x +UseFastLocking >> - [x] tier4 x86_64 x aarch64 x +UseFastLocking >> - [x] tier1 x86_64 x aarch64 x -UseFastLocking >> - [x] tier2 x86_64 x aarch64 x -UseFastLocking >> - [x] tier3 x86_64 x aarch64 x -UseFastLocking >> - [x] tier4 x86_64 x aarch64 x -UseFastLocking >> - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet >> >> ### Performance >> >> #### Simple Microbenchmark >> >> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops. >> >> | | x86_64 | aarch64 | >> | -- | -- | -- | >> | -UseFastLocking | 20.651 | 20.764 | >> | +UseFastLocking | 18.896 | 18.908 | >> >> >> #### Renaissance >> >> ? | x86_64 | ? | ? | ? | aarch64 | ? | ? >> -- | -- | -- | -- | -- | -- | -- | -- >> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? >> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% >> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21% >> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% >> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% >> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% >> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% >> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%% >> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% >> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% >> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% >> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% >> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34% >> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% >> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% >> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% >> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% >> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% >> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% >> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% >> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% >> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > RISCV update I'm rerunning my Mach5 testing of v54 + forced-enable of the new lightweight locking. ------------- PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1499151050 From dcubed at openjdk.org Thu Apr 6 14:42:09 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 6 Apr 2023 14:42:09 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v56] In-Reply-To: References: Message-ID: On Thu, 6 Apr 2023 11:59:45 GMT, Roman Kennke wrote: >> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). >> >> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. >> >> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal protocols. >> >> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare. >> >> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. >> >> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. >> >> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. >> >> This change enables to simplify (and speed-up!) a lot of code: >> >> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. >> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR >> >> Also, and I might be mistaken here, this new lightweight locking would make synchronized work better with Loom: Because the lock-records are no longer scattered across the stack, but instead are densely packed into the lock-stack, it should be easy for a vthread to save its lock-stack upon unmounting and restore it when re-mounting. However, I am not sure about this, and this PR does not attempt to implement that support. >> >> Testing: >> - [x] tier1 x86_64 x aarch64 x +UseFastLocking >> - [x] tier2 x86_64 x aarch64 x +UseFastLocking >> - [x] tier3 x86_64 x aarch64 x +UseFastLocking >> - [x] tier4 x86_64 x aarch64 x +UseFastLocking >> - [x] tier1 x86_64 x aarch64 x -UseFastLocking >> - [x] tier2 x86_64 x aarch64 x -UseFastLocking >> - [x] tier3 x86_64 x aarch64 x -UseFastLocking >> - [x] tier4 x86_64 x aarch64 x -UseFastLocking >> - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet >> >> ### Performance >> >> #### Simple Microbenchmark >> >> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops. >> >> | | x86_64 | aarch64 | >> | -- | -- | -- | >> | -UseFastLocking | 20.651 | 20.764 | >> | +UseFastLocking | 18.896 | 18.908 | >> >> >> #### Renaissance >> >> ? | x86_64 | ? | ? | ? | aarch64 | ? | ? >> -- | -- | -- | -- | -- | -- | -- | -- >> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? >> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% >> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21% >> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% >> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% >> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% >> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% >> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%% >> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% >> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% >> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% >> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% >> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34% >> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% >> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% >> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% >> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% >> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% >> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% >> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% >> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% >> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > RISCV update src/hotspot/share/services/management.cpp line 1129: > 1127: // give wrong results when Java threads are running and > 1128: // entering/leaving locks while we inspect the thread stacks. > 1129: if (maxDepth == 0) { You've removed the code that cause safepoint code path to be taken here so this comment is no longer correct. Also, I've verified that: vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Deadlock/JavaDeadlock005/TestDescription.java no longer fails on my MBP13 so I agree that the `start_processing()` call made the ZGC -Xcomp config much happier. src/hotspot/share/services/management.cpp line 1131: > 1129: if (maxDepth == 0) { > 1130: // No stack trace to dump so we do not need to stop the world. > 1131: // Since we never do the VM op here we must set the threads list. You may want to add a little more to this comment after L1131: // Since we are not stopping the world, the data we gather here // may change the moment after we return it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1159887650 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1159890005 From duke at openjdk.org Thu Apr 6 15:31:14 2023 From: duke at openjdk.org (David M. Lloyd) Date: Thu, 6 Apr 2023 15:31:14 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v4] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Thu, 6 Apr 2023 08:00:43 GMT, ExE Boss wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Correct spelling of isAARCH64 in WIndows AttachProviderImpl > > src/java.base/share/classes/jdk/internal/util/Architecture.java line 47: > >> 45: >> 46: // Cache a copy of the array for lightweight indexing >> 47: private static final Architecture[] archValues = Architecture.values(); > > This?needs to?be?annotated with?`@jdk.internal.vm.annotation.Stable` for?`Architecture.current()` to?be?constant?foldable: > Suggestion: > > private static final @Stable Architecture[] archValues = Architecture.values(); Even if it's `static` *and* `final`? I thought `@Stable` exists to "...process non-null stable fields (final or otherwise) in a similar manner to static final fields with respect to promoting the field's value to a constant", implying that `static final` fields already have this property. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1159957027 From alanb at openjdk.org Thu Apr 6 15:49:27 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 6 Apr 2023 15:49:27 GMT Subject: RFR: 8304919: Implementation of Virtual Threads [v6] In-Reply-To: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com> References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com> Message-ID: > JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview. > > There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently. > > In addition, there are a small number of implementation changes to sync up from the loom fibers branch: > > - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly. > - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes. > - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs. > - New system property to print a stack trace when a virtual thread sets its own value of a TL. > - ThreadPerTaskExecutor is changed to use FutureTask. > > Testing: tier1-6. Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: - Test/comments updates - Merge - Expand tests for jdk.ThreadSleep event - Review feedback - Merge - Fix ThreadSleepEvent again - Test updates - ThreadSleepEvent refactoring - Merge - Merge - ... and 1 more: https://git.openjdk.org/jdk/compare/6e04878d...a5bb3fd9 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13203/files - new: https://git.openjdk.org/jdk/pull/13203/files/722d5afa..a5bb3fd9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13203&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13203&range=04-05 Stats: 21808 lines in 499 files changed: 11410 ins; 8547 del; 1851 mod Patch: https://git.openjdk.org/jdk/pull/13203.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13203/head:pull/13203 PR: https://git.openjdk.org/jdk/pull/13203 From rriggs at openjdk.org Thu Apr 6 16:29:09 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 6 Apr 2023 16:29:09 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v4] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Thu, 6 Apr 2023 15:27:49 GMT, David M. Lloyd wrote: >> src/java.base/share/classes/jdk/internal/util/Architecture.java line 47: >> >>> 45: >>> 46: // Cache a copy of the array for lightweight indexing >>> 47: private static final Architecture[] archValues = Architecture.values(); >> >> This?needs to?be?annotated with?`@jdk.internal.vm.annotation.Stable` for?`Architecture.current()` to?be?constant?foldable: >> Suggestion: >> >> private static final @Stable Architecture[] archValues = Architecture.values(); > > Even if it's `static` *and* `final`? I thought `@Stable` exists to "...process non-null stable fields (final or otherwise) in a similar manner to static final fields with respect to promoting the field's value to a constant", implying that `static final` fields already have this property. The use here is not particularly performance sensitive. So it doesn't provide much value. In this case, it allows each array element to be considered stable. >From the @Stable javadoc: * Fields which are declared {@code final} may also be annotated as stable. * Since final fields already behave as stable values, such an annotation * conveys no additional information regarding change of the field's value, but * still conveys information regarding change of additional components values if * the type of the field is an array type (as described above). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160018375 From cjplummer at openjdk.org Thu Apr 6 16:44:15 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 6 Apr 2023 16:44:15 GMT Subject: RFR: 8305680: Remove Permissions from jcmd help output In-Reply-To: <232Cd_P8bHHsUTUNmLfBbs6Hqzi9nGGZXmIVJi4OHJ8=.521404a7-a8eb-4b62-be17-8159216c9d9d@github.com> References: <232Cd_P8bHHsUTUNmLfBbs6Hqzi9nGGZXmIVJi4OHJ8=.521404a7-a8eb-4b62-be17-8159216c9d9d@github.com> Message-ID: On Thu, 6 Apr 2023 08:44:00 GMT, Kevin Walls wrote: > Like the removal of Permission information from the man page in JDK-8305622, this change removes Permission information from the jcmd help output. > > These Permissions are not relevant to jcmd users. The Permissions can be relevant when connecting remotely to JMX with a Security Manager in place. That usage is clearly deprecated with JEP 411. > > We don't specifically test for this output, but we have dcmd tests in test/hotspot/jtreg/serviceability which all continue to pass. Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13371#pullrequestreview-1375231400 From rriggs at openjdk.org Thu Apr 6 17:17:35 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 6 Apr 2023 17:17:35 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v5] In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: > Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. > The enumeration values are defined to match those used in the build. > The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE` > Note that `amd64` and `x86_64` in the build are represented by `X64`. > The values of the system property `os.arch` is unchanged. > > The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). > Uses in `java.base` and a few others are included but other modules will be done in separate PRs. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Revert changes to Foreign API to avoid class with another PR Rename S390X to S390, representing just the s390 architecture Removed ARM and IA64 enum values; they are unused; they can be added later if needed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13357/files - new: https://git.openjdk.org/jdk/pull/13357/files/8916dcae..105ce605 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=03-04 Stats: 58 lines in 5 files changed: 5 ins; 32 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/13357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13357/head:pull/13357 PR: https://git.openjdk.org/jdk/pull/13357 From cjplummer at openjdk.org Thu Apr 6 17:40:19 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 6 Apr 2023 17:40:19 GMT Subject: RFR: 8305622: Remove Permission details from jcmd man page [v2] In-Reply-To: References: Message-ID: On Thu, 6 Apr 2023 08:38:02 GMT, Kevin Walls wrote: >> Removal of the Permission information from the jcmd man page. >> >> This information is not useful in the way it is presented, and is not used in connection with jcmd, so should be removed from that man page. >> >> The Permissions can be relevant when connecting remotely to JMX with a Security Manager in place. That usage is clearly deprecated with JEP 411. If there is a transition feature, it will be documented elsewhere. > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > sync Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13363#pullrequestreview-1375309894 From amenkov at openjdk.org Thu Apr 6 18:20:16 2023 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 6 Apr 2023 18:20:16 GMT Subject: RFR: 8299414: JVMTI FollowReferences should support references from VirtualThread stack [v2] In-Reply-To: References: <6oQOD_egcB3HyuagMWGSPLjKSE3JkaI2K2WOsDK1Cww=.c568223b-5100-4425-a4b7-defbd812a9ff@github.com> Message-ID: On Thu, 6 Apr 2023 14:03:50 GMT, Alan Bateman wrote: > Do I read it correctly that the entire heap is walked to find the unmounted virtual threads? Correct. I don't see other way to find unmounted threads ------------- PR Comment: https://git.openjdk.org/jdk/pull/13254#issuecomment-1499446517 From alanb at openjdk.org Thu Apr 6 18:47:21 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 6 Apr 2023 18:47:21 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v5] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Thu, 6 Apr 2023 17:17:35 GMT, Roger Riggs wrote: >> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. >> The enumeration values are defined to match those used in the build. >> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE` >> Note that `amd64` and `x86_64` in the build are represented by `X64`. >> The values of the system property `os.arch` is unchanged. >> >> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). >> Uses in `java.base` and a few others are included but other modules will be done in separate PRs. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Revert changes to Foreign API to avoid class with another PR > Rename S390X to S390, representing just the s390 architecture > Removed ARM and IA64 enum values; they are unused; they can be added later if needed src/jdk.attach/windows/classes/sun/tools/attach/AttachProviderImpl.java line 51: > 49: !Architecture.isAARCH64()) { > 50: throw new RuntimeException( > 51: "This provider is not supported on this processor architecture: " + Architecture.current()); Could this constructor be changed to be a no-op? The check for Windows 9 and Windows Me dates back to JDK 6 and is no longer needed. The os.arch check also dates from JDK 6 when the attach provider didn't work on IA64 The only Windows builds now are windows-x86, windows-x64, windows-aarch64 so I assume this check can go away. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160140379 From alanb at openjdk.org Thu Apr 6 18:57:15 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 6 Apr 2023 18:57:15 GMT Subject: RFR: 8299414: JVMTI FollowReferences should support references from VirtualThread stack [v2] In-Reply-To: References: <6oQOD_egcB3HyuagMWGSPLjKSE3JkaI2K2WOsDK1Cww=.c568223b-5100-4425-a4b7-defbd812a9ff@github.com> Message-ID: On Thu, 6 Apr 2023 18:17:29 GMT, Alex Menkov wrote: > Correct. I don't see other way to find unmounted threads FollowReferences is a graph walk so it will visit the reachable virtual Threads. If I'm not mistake, VThreadClosure will iterate over unreachable Virtual Thread objects. That might be okay as they should be terminated and thus not have any frames, but maybe the other approach needs to be explored too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13254#issuecomment-1499484526 From rriggs at openjdk.org Thu Apr 6 19:06:16 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 6 Apr 2023 19:06:16 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v6] In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: > Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. > The enumeration values are defined to match those used in the build. > The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE` > Note that `amd64` and `x86_64` in the build are represented by `X64`. > The values of the system property `os.arch` is unchanged. > > The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). > Uses in `java.base` and a few others are included but other modules will be done in separate PRs. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Remove obsolete conditions in Windows AttachProviderImpl. All platforms and architectures that can be built support attach. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13357/files - new: https://git.openjdk.org/jdk/pull/13357/files/105ce605..ab084c27 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=04-05 Stats: 11 lines in 1 file changed: 0 ins; 11 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13357/head:pull/13357 PR: https://git.openjdk.org/jdk/pull/13357 From rriggs at openjdk.org Thu Apr 6 19:06:20 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 6 Apr 2023 19:06:20 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v5] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: <4mLFbdHUYtZRYFFi_s9YffxJOeVcMjU_TsIgVn7hUbM=.34d74c76-68dd-4ad3-ae8d-4906756aa438@github.com> On Thu, 6 Apr 2023 18:44:02 GMT, Alan Bateman wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert changes to Foreign API to avoid class with another PR >> Rename S390X to S390, representing just the s390 architecture >> Removed ARM and IA64 enum values; they are unused; they can be added later if needed > > src/jdk.attach/windows/classes/sun/tools/attach/AttachProviderImpl.java line 51: > >> 49: !Architecture.isAARCH64()) { >> 50: throw new RuntimeException( >> 51: "This provider is not supported on this processor architecture: " + Architecture.current()); > > Could this constructor be changed to be a no-op? The check for Windows 9 and Windows Me dates back to JDK 6 and is no longer needed. The os.arch check also dates from JDK 6 when the attach provider didn't work on IA64 The only Windows builds now are windows-x86, windows-x64, windows-aarch64 so I assume this check can go away. Removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160154277 From alanb at openjdk.org Thu Apr 6 19:15:18 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 6 Apr 2023 19:15:18 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v5] In-Reply-To: <4mLFbdHUYtZRYFFi_s9YffxJOeVcMjU_TsIgVn7hUbM=.34d74c76-68dd-4ad3-ae8d-4906756aa438@github.com> References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> <4mLFbdHUYtZRYFFi_s9YffxJOeVcMjU_TsIgVn7hUbM=.34d74c76-68dd-4ad3-ae8d-4906756aa438@github.com> Message-ID: On Thu, 6 Apr 2023 19:01:39 GMT, Roger Riggs wrote: > Removed. Good, that makes it simpler and it means the qualified export can be removed too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160162760 From cjplummer at openjdk.org Thu Apr 6 19:16:23 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 6 Apr 2023 19:16:23 GMT Subject: Integrated: 8305209: JDWP exit error AGENT_ERROR_INVALID_THREAD(203): missing entry in running thread table In-Reply-To: References: Message-ID: On Thu, 30 Mar 2023 16:03:05 GMT, Chris Plummer wrote: > The real purpose of this PR is to add virtual thread support to ThreadMemoryLeakTest.java, but this exposed bugs in both the debug agent and in TestScaffold, so those are being fixed also (and the debug agent bug is the CR being used). > > The debug agent bug is due to a race condition during VM exit. The VM is in the process of shutting down. The debug agent has already disabled JVMTI callbacks and has sent the VMDeathEvent. At this point in time there are also threads exiting that the debug agent knows about, but it will not get a ThreadEndEvent for because of the callbacks being disabled. Thus these threads remain in the debug agent's list of known threads, even though they have exited. The debuggee receives the VMDeathEvent and does a VM.resume(). During the debug agent's handing of the VM.Resume command, it iterates over all known threads and needs to map each to its ThreadNode so it can be resumed, and this mapping requires accessing the JVMTI TLS for the thread. The problem is some of the threads may have exited already, and therefore no longer have TLS. This results in the assert in the debug agent. This debug agent issue was already addressed for platform threads, but not for virtual threads, which is why we started seeing this issue when this test was modified. The fix is to just replicate what is done for platform threads for virtual threads also. > > The TestScaffold bug is that if the debuggee crashes/asserts, this is likely to go unnoticed, especially if it happens during VM exit (and the test essentially has already completed). Because of this TestScaffold bug, the debug agent bug above did not result in a test failure. After fixing TestScaffold to check the exitCode of the debuggee process, the test started to appropriately fail until the debug agent was fixed. > > One other thing to point out is the OOME issue I started getting frequently when testing with virtual threads. Since virtual threads are created at a much higher rate than platform threads, their creation started to overwhelm the debugger (actually the JDI implementation). There is already a mechanism in place to do a VM.HoldEvents if JDI has queue up 10,000 events. The problem is that events are coming in so fast that even after doing the VM.HoldEvents, the number of queued events continues to go up for a while, and sometimes reaches 30,000 or more. This raises the peak memory usage of the test quite a bit. Since the test purposely uses a small heap so a memory leak is quickly and reliably detected, the large queue often results in an OOME. Because of this I make virtual threads sleep for 100ms instead of 50ms to slow down their creation, and this resolved the issue. > > I tested by running all of test/jdk/com/sun/jdi 25 times on each platform with and without virtual thread testing enabled. This pull request has now been integrated. Changeset: 1d517afb Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/1d517afbd4547171ad6fb6a3356351c2554c8279 Stats: 33 lines in 3 files changed: 28 ins; 0 del; 5 mod 8305209: JDWP exit error AGENT_ERROR_INVALID_THREAD(203): missing entry in running thread table Reviewed-by: sspitsyn, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/13246 From rriggs at openjdk.org Thu Apr 6 19:25:19 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 6 Apr 2023 19:25:19 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v7] In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: > Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. > The enumeration values are defined to match those used in the build. > The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE` > Note that `amd64` and `x86_64` in the build are represented by `X64`. > The values of the system property `os.arch` is unchanged. > > The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). > Uses in `java.base` and a few others are included but other modules will be done in separate PRs. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Remove unneeded qualified export from java.base to jdk.attach ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13357/files - new: https://git.openjdk.org/jdk/pull/13357/files/ab084c27..52ca4a70 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=05-06 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13357/head:pull/13357 PR: https://git.openjdk.org/jdk/pull/13357 From duke at openjdk.org Thu Apr 6 19:58:21 2023 From: duke at openjdk.org (Glavo) Date: Thu, 6 Apr 2023 19:58:21 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v7] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Thu, 6 Apr 2023 19:25:19 GMT, Roger Riggs wrote: >> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. >> The enumeration values are defined to match those used in the build. >> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE` >> Note that `amd64` and `x86_64` in the build are represented by `X64`. >> The values of the system property `os.arch` is unchanged. >> >> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). >> Uses in `java.base` and a few others are included but other modules will be done in separate PRs. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Remove unneeded qualified export from java.base to jdk.attach src/java.base/share/classes/jdk/internal/util/Architecture.java line 100: > 98: */ > 99: public static Architecture current() { > 100: return archValues[OperatingSystemProps.CURRENT_ARCH_ORDINAL]; I think the `Architecture ` is different from the `OperatingSystem`. There are ports of [other architectures](https://github.com/openjdk/jdk/blob/1d517afbd4547171ad6fb6a3356351c2554c8279/make/autoconf/platform.m4#L33-L188) (Including `MIPS64el`, `LoongArch64`, `SPARC v9`, etc) in the upstream. Will hard coding architectures destroy these ports? Should a "OTHER" or "UNKNOWN" entry be added to the enum to represent other architectures that are not of concern? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160193842 From rriggs at openjdk.org Thu Apr 6 20:27:22 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 6 Apr 2023 20:27:22 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v7] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Thu, 6 Apr 2023 19:55:07 GMT, Glavo wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unneeded qualified export from java.base to jdk.attach > > src/java.base/share/classes/jdk/internal/util/Architecture.java line 100: > >> 98: */ >> 99: public static Architecture current() { >> 100: return archValues[OperatingSystemProps.CURRENT_ARCH_ORDINAL]; > > I think the `Architecture ` is different from the `OperatingSystem`. There are ports of [other architectures](https://github.com/openjdk/jdk/blob/1d517afbd4547171ad6fb6a3356351c2554c8279/make/autoconf/platform.m4#L33-L188) (Including `MIPS64el`, `LoongArch64`, `SPARC v9`, etc) in the upstream. > > Will hard coding architectures destroy these ports? Should a "OTHER" or "UNKNOWN" entry be added to the enum to represent other architectures that are not of concern? There is no benefit to preemptively defining a full set of architectures; we only need those that are used in the OpenJDK runtime selection of options or parameters. The other and unknown cases can be handled in code using switch as `default` or for `if (xx) {} else {...}` in the else clause. Ports not supported the OpenJDK can add enum values and the corresponding static `isXXX()` methods if needed. The template file used in the implementation could be renamed to be more agnostic to OS or arch. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160226259 From stuefe at openjdk.org Thu Apr 6 20:31:21 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 6 Apr 2023 20:31:21 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v7] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Thu, 6 Apr 2023 19:25:19 GMT, Roger Riggs wrote: >> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. >> The enumeration values are defined to match those used in the build. >> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE` >> Note that `amd64` and `x86_64` in the build are represented by `X64`. >> The values of the system property `os.arch` is unchanged. >> >> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). >> Uses in `java.base` and a few others are included but other modules will be done in separate PRs. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Remove unneeded qualified export from java.base to jdk.attach What about PPC (big endian)? Used on AIX? On Arm, it may be useful to know whether we built for thumb mode (We recently had this problem in tests). ------------- PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1499585079 From sspitsyn at openjdk.org Thu Apr 6 20:33:04 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 6 Apr 2023 20:33:04 GMT Subject: RFR: 8305680: Remove Permissions from jcmd help output In-Reply-To: <232Cd_P8bHHsUTUNmLfBbs6Hqzi9nGGZXmIVJi4OHJ8=.521404a7-a8eb-4b62-be17-8159216c9d9d@github.com> References: <232Cd_P8bHHsUTUNmLfBbs6Hqzi9nGGZXmIVJi4OHJ8=.521404a7-a8eb-4b62-be17-8159216c9d9d@github.com> Message-ID: On Thu, 6 Apr 2023 08:44:00 GMT, Kevin Walls wrote: > Like the removal of Permission information from the man page in JDK-8305622, this change removes Permission information from the jcmd help output. > > These Permissions are not relevant to jcmd users. The Permissions can be relevant when connecting remotely to JMX with a Security Manager in place. That usage is clearly deprecated with JEP 411. > > We don't specifically test for this output, but we have dcmd tests in test/hotspot/jtreg/serviceability which all continue to pass. Marked as reviewed by sspitsyn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13371#pullrequestreview-1375533572 From sspitsyn at openjdk.org Thu Apr 6 20:37:17 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 6 Apr 2023 20:37:17 GMT Subject: RFR: 8305622: Remove Permission details from jcmd man page [v2] In-Reply-To: References: Message-ID: On Thu, 6 Apr 2023 08:38:02 GMT, Kevin Walls wrote: >> Removal of the Permission information from the jcmd man page. >> >> This information is not useful in the way it is presented, and is not used in connection with jcmd, so should be removed from that man page. >> >> The Permissions can be relevant when connecting remotely to JMX with a Security Manager in place. That usage is clearly deprecated with JEP 411. If there is a transition feature, it will be documented elsewhere. > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > sync Marked as reviewed by sspitsyn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13363#pullrequestreview-1375541038 From stuefe at openjdk.org Thu Apr 6 20:42:18 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 6 Apr 2023 20:42:18 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v7] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Thu, 6 Apr 2023 19:25:19 GMT, Roger Riggs wrote: >> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. >> The enumeration values are defined to match those used in the build. >> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE` >> Note that `amd64` and `x86_64` in the build are represented by `X64`. >> The values of the system property `os.arch` is unchanged. >> >> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). >> Uses in `java.base` and a few others are included but other modules will be done in separate PRs. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Remove unneeded qualified export from java.base to jdk.attach Another question, how does this work with Zero? I know e.g. Debian maintains a broad range of Zero JVMs on different target CPUs. Things like ia64 and parisc. What is the os.arch value on those, and how will this work with the limited set of enums we replace it with? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1499594972 From rriggs at openjdk.org Thu Apr 6 20:42:20 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 6 Apr 2023 20:42:20 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v7] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Thu, 6 Apr 2023 20:28:29 GMT, Thomas Stuefe wrote: > What about PPC (big endian)? Used on AIX? I'm not aware of any code (in OpenJDK) related to big/little endian that is derived from `os.arch`. > > On Arm, it may be useful to know whether we built for thumb mode (We recently had this problem in tests). For tests, there is the test library `jdk.test.lib.Platform` class with its own set of predicates. For the moment, the idea is to do the minimum to replace OpenJDK internal uses of `os.arch`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1499597036 From duke at openjdk.org Thu Apr 6 20:45:21 2023 From: duke at openjdk.org (Glavo) Date: Thu, 6 Apr 2023 20:45:21 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v7] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Thu, 6 Apr 2023 20:24:27 GMT, Roger Riggs wrote: >> src/java.base/share/classes/jdk/internal/util/Architecture.java line 100: >> >>> 98: */ >>> 99: public static Architecture current() { >>> 100: return archValues[OperatingSystemProps.CURRENT_ARCH_ORDINAL]; >> >> I think the `Architecture ` is different from the `OperatingSystem`. There are ports of [other architectures](https://github.com/openjdk/jdk/blob/1d517afbd4547171ad6fb6a3356351c2554c8279/make/autoconf/platform.m4#L33-L188) (Including `MIPS64el`, `LoongArch64`, `SPARC v9`, etc) in the upstream. >> >> Will hard coding architectures destroy these ports? Should a "OTHER" or "UNKNOWN" entry be added to the enum to represent other architectures that are not of concern? > > There is no benefit to preemptively defining a full set of architectures; we only need those that are used in the OpenJDK runtime selection of options or parameters. > The other and unknown cases can be handled in code using switch as `default` or for `if (xx) {} else {...}` in the else clause. > Ports not supported the OpenJDK can add enum values and the corresponding static `isXXX()` methods if needed. > > The template file used in the implementation could be renamed to be more agnostic to OS or arch. I understand that there is no need to define enum entries for all architectures now, but the `current` method seems to cause crashes on other platforms. Even worse, `OperatingSystemProps` seems to be unable to compile on other architectures at all: https://github.com/openjdk/jdk/blob/52ca4a70fc3de9e285964f9545ea8cd54e2d9924/src/java.base/share/classes/jdk/internal/util/OperatingSystemProps.java.template#L40 Does `Architecture` really need to be implemented as an enum? The value of this enum has never been used in this PR except for testing. I think perhaps just providing the isXXX methods is enough. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160242246 From rriggs at openjdk.org Thu Apr 6 20:53:18 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 6 Apr 2023 20:53:18 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v7] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Thu, 6 Apr 2023 20:38:02 GMT, Thomas Stuefe wrote: > Another question, how does this work with Zero? Zero is orthogonal to architecture; the interpreter is compiled for a specific target architecture. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1499606550 From rriggs at openjdk.org Thu Apr 6 20:59:22 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 6 Apr 2023 20:59:22 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v7] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: <1K_5UDcRkPBwGy5qnR6KouHWF1wX6CRiX9sWgdBBxbA=.9e637d8f-817a-42a7-92df-1e2f5ad3d7f1@github.com> On Thu, 6 Apr 2023 20:42:26 GMT, Glavo wrote: >> There is no benefit to preemptively defining a full set of architectures; we only need those that are used in the OpenJDK runtime selection of options or parameters. >> The other and unknown cases can be handled in code using switch as `default` or for `if (xx) {} else {...}` in the else clause. >> Ports not supported the OpenJDK can add enum values and the corresponding static `isXXX()` methods if needed. >> >> The template file used in the implementation could be renamed to be more agnostic to OS or arch. > > I understand that there is no need to define enum entries for all architectures now, but the `current` method seems to cause crashes on other platforms. > > Even worse, `OperatingSystemProps` seems to be unable to compile on other architectures at all: > > https://github.com/openjdk/jdk/blob/52ca4a70fc3de9e285964f9545ea8cd54e2d9924/src/java.base/share/classes/jdk/internal/util/OperatingSystemProps.java.template#L40 > > Does `Architecture` really need to be implemented as an enum? The value of this enum has never been used in this PR except for testing. I think perhaps just providing the isXXX methods is enough. The point of Architecture is reflect the architecture as supported by the build and the runtime mutually and to reflect dependencies on the target hardware. What did you use as the example that would not compile on the other architecture? Did you make the other changes to the build that would be needed for a new architecture? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160252604 From kevinw at openjdk.org Thu Apr 6 21:10:17 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 6 Apr 2023 21:10:17 GMT Subject: RFR: 8305680: Remove Permissions from jcmd help output In-Reply-To: <232Cd_P8bHHsUTUNmLfBbs6Hqzi9nGGZXmIVJi4OHJ8=.521404a7-a8eb-4b62-be17-8159216c9d9d@github.com> References: <232Cd_P8bHHsUTUNmLfBbs6Hqzi9nGGZXmIVJi4OHJ8=.521404a7-a8eb-4b62-be17-8159216c9d9d@github.com> Message-ID: <_GPvniEU-Z4jXUXhOngerTRCv_n4dAeH4_3tJOQn-Lw=.5e0ea43c-b832-439d-a59a-8db1bb4ed50e@github.com> On Thu, 6 Apr 2023 08:44:00 GMT, Kevin Walls wrote: > Like the removal of Permission information from the man page in JDK-8305622, this change removes Permission information from the jcmd help output. > > These Permissions are not relevant to jcmd users. The Permissions can be relevant when connecting remotely to JMX with a Security Manager in place. That usage is clearly deprecated with JEP 411. > > We don't specifically test for this output, but we have dcmd tests in test/hotspot/jtreg/serviceability which all continue to pass. Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13371#issuecomment-1499632738 From kevinw at openjdk.org Thu Apr 6 21:12:26 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 6 Apr 2023 21:12:26 GMT Subject: RFR: 8305622: Remove Permission details from jcmd man page [v2] In-Reply-To: References: Message-ID: <-xyYfJOciAGU_002bO-4N-VyS_pjX93XTLBLGByikFg=.e0f65312-2134-4a65-b798-73f551cf391e@github.com> On Thu, 6 Apr 2023 08:38:02 GMT, Kevin Walls wrote: >> Removal of the Permission information from the jcmd man page. >> >> This information is not useful in the way it is presented, and is not used in connection with jcmd, so should be removed from that man page. >> >> The Permissions can be relevant when connecting remotely to JMX with a Security Manager in place. That usage is clearly deprecated with JEP 411. If there is a transition feature, it will be documented elsewhere. > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > sync Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13363#issuecomment-1499632482 From kevinw at openjdk.org Thu Apr 6 21:12:27 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 6 Apr 2023 21:12:27 GMT Subject: Integrated: 8305622: Remove Permission details from jcmd man page In-Reply-To: References: Message-ID: On Wed, 5 Apr 2023 21:00:55 GMT, Kevin Walls wrote: > Removal of the Permission information from the jcmd man page. > > This information is not useful in the way it is presented, and is not used in connection with jcmd, so should be removed from that man page. > > The Permissions can be relevant when connecting remotely to JMX with a Security Manager in place. That usage is clearly deprecated with JEP 411. If there is a transition feature, it will be documented elsewhere. This pull request has now been integrated. Changeset: 8db1dd02 Author: Kevin Walls URL: https://git.openjdk.org/jdk/commit/8db1dd02582edb3be99c2f63a54772e47311aa8e Stats: 74 lines in 1 file changed: 0 ins; 73 del; 1 mod 8305622: Remove Permission details from jcmd man page Reviewed-by: cjplummer, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/13363 From kevinw at openjdk.org Thu Apr 6 21:13:25 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 6 Apr 2023 21:13:25 GMT Subject: Integrated: 8305680: Remove Permissions from jcmd help output In-Reply-To: <232Cd_P8bHHsUTUNmLfBbs6Hqzi9nGGZXmIVJi4OHJ8=.521404a7-a8eb-4b62-be17-8159216c9d9d@github.com> References: <232Cd_P8bHHsUTUNmLfBbs6Hqzi9nGGZXmIVJi4OHJ8=.521404a7-a8eb-4b62-be17-8159216c9d9d@github.com> Message-ID: <1dD2sjJW5Xsa_9p84tg4xKwaYflntyoTW-2kCV2TTKg=.6400a344-1682-4510-b631-d5e7e4dd6cb4@github.com> On Thu, 6 Apr 2023 08:44:00 GMT, Kevin Walls wrote: > Like the removal of Permission information from the man page in JDK-8305622, this change removes Permission information from the jcmd help output. > > These Permissions are not relevant to jcmd users. The Permissions can be relevant when connecting remotely to JMX with a Security Manager in place. That usage is clearly deprecated with JEP 411. > > We don't specifically test for this output, but we have dcmd tests in test/hotspot/jtreg/serviceability which all continue to pass. This pull request has now been integrated. Changeset: 0a340187 Author: Kevin Walls URL: https://git.openjdk.org/jdk/commit/0a3401879743878c63a3db8d68d33894de6ccf6a Stats: 10 lines in 1 file changed: 0 ins; 10 del; 0 mod 8305680: Remove Permissions from jcmd help output Reviewed-by: cjplummer, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/13371 From duke at openjdk.org Thu Apr 6 21:20:20 2023 From: duke at openjdk.org (Glavo) Date: Thu, 6 Apr 2023 21:20:20 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v7] In-Reply-To: <1K_5UDcRkPBwGy5qnR6KouHWF1wX6CRiX9sWgdBBxbA=.9e637d8f-817a-42a7-92df-1e2f5ad3d7f1@github.com> References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> <1K_5UDcRkPBwGy5qnR6KouHWF1wX6CRiX9sWgdBBxbA=.9e637d8f-817a-42a7-92df-1e2f5ad3d7f1@github.com> Message-ID: <3jNPX5xpKbZQ0Cz05qJHuDLRpx5SmhzOxIHCeERnDWg=.90260d1e-6d77-430c-b0dc-a83df36b1272@github.com> On Thu, 6 Apr 2023 20:56:42 GMT, Roger Riggs wrote: > What did you use as the example that would not compile on the other architecture? https://github.com/openjdk/jdk/blob/52ca4a70fc3de9e285964f9545ea8cd54e2d9924/src/java.base/share/classes/jdk/internal/util/OperatingSystemProps.java.template#L40 I don't understand how the above code can be compiled on architectures such as LongArch64, MIPS64el, or ARM32 without modifying the source file. > Did you make the other changes to the build that would be needed for a new architecture? I'm not talking about the new architecture, I'm talking about the architecture that OpenJDK already supports. According to my understanding, the above code breaks the support of all architectures not listed in `Architecture`. But has `Architecture` really listed all the supported architectures in the OpenJDK mainline? For example, I want to compile OpenJDK for 32-bit ARM. I think in this PR, I cannot compile without modifying the source code because `TARGET_ARCH_arm` does not exist. But before this PR, I was able to compile. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160266038 From prr at openjdk.org Thu Apr 6 22:47:58 2023 From: prr at openjdk.org (Phil Race) Date: Thu, 6 Apr 2023 22:47:58 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v7] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: <3iWq-g0ji56gRdTxUVtO64dy60rPmtQsQ_64HWoCMlY=.300723e5-d788-42f4-9d40-bb768390fc0b@github.com> On Thu, 6 Apr 2023 19:25:19 GMT, Roger Riggs wrote: >> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. >> The enumeration values are defined to match those used in the build. >> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE` >> Note that `amd64` and `x86_64` in the build are represented by `X64`. >> The values of the system property `os.arch` is unchanged. >> >> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). >> Uses in `java.base` and a few others are included but other modules will be done in separate PRs. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Remove unneeded qualified export from java.base to jdk.attach src/jdk.accessibility/windows/classes/com/sun/java/accessibility/internal/AccessBridge.java line 169: > 167: // Load the appropriate DLLs > 168: boolean is32on64 = false; > 169: if (Architecture.isX86()) { This would be another coupling of java.desktop into java.base internals and I don't think it worth it. Particularly because this check is obsolete ! It is a remnant of when accessbridge was an unbundled download so provided both 32 and 64 bit. We don't even have the file it is looking for in the build - even if someone did a 32 bit build. Instead of making this change a bug should be filed to remove this code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160314934 From amenkov at openjdk.org Thu Apr 6 23:11:43 2023 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 6 Apr 2023 23:11:43 GMT Subject: RFR: 8299414: JVMTI FollowReferences should support references from VirtualThread stack [v2] In-Reply-To: References: <6oQOD_egcB3HyuagMWGSPLjKSE3JkaI2K2WOsDK1Cww=.c568223b-5100-4425-a4b7-defbd812a9ff@github.com> Message-ID: On Thu, 6 Apr 2023 18:53:59 GMT, Alan Bateman wrote: > FollowReferences is a graph walk so it will visit the reachable virtual Threads. If I'm not mistake, VThreadClosure will iterate over unreachable Virtual Thread objects. That might be okay as they should be terminated and thus not have any frames, but maybe the other approach needs to be explored too. The fix is for the case when FollowReferences is called with null initial_object. Per spec in the case "references are followed from the heap roots". And: "The heap root are the set of system classes, JNI globals, references from thread stacks, and other objects used as roots for the purposes of garbage collection." FollowReferences visits all reachable virtual threads only if agent callback always returns JVMTI_VISIT_OBJECTS. If agent callback doesn't return JVMTI_VISIT_OBJECTS for some object, references from the object are not traversed, so some unmounted vthreads may be missed. VThreadClosure iterates over all VirtualThread objects, but skips mounted and terminated threads. After reporting the object is marked "visited" and won't be reported again when some objects have reference to it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13254#issuecomment-1499733642 From amenkov at openjdk.org Fri Apr 7 02:20:04 2023 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 7 Apr 2023 02:20:04 GMT Subject: RFR: 8299414: JVMTI FollowReferences should support references from VirtualThread stack [v3] In-Reply-To: <6oQOD_egcB3HyuagMWGSPLjKSE3JkaI2K2WOsDK1Cww=.c568223b-5100-4425-a4b7-defbd812a9ff@github.com> References: <6oQOD_egcB3HyuagMWGSPLjKSE3JkaI2K2WOsDK1Cww=.c568223b-5100-4425-a4b7-defbd812a9ff@github.com> Message-ID: <6mhiHz0YwjatkbtDRngp1M_N8QYMuD4SRWUFty_OEZ8=.c03ce00a-449f-4590-a2fe-9edc7e5f5981@github.com> > The fix updates JVMTI FollowReferences implementation to report references from virtual threads: > - added heap scanning to report unmounted vthreads; > - stacks of mounted vthreads are splitted into 2 parts (vittual thread stack and carrier thread stack), references are reported with correct thread id/class and object tags/frame depth; > - common code to handle stack frames are moved into separate class; Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: Fixed test - replaced obsolete java.util.concurrent.ForkJoinPool.common.parallelism with jdk.virtualThreadScheduler.parallelism; - added check that vthreads are mounted/unmounted; - disabled testing of JNI locals for unmounted thread as native call pins vthread and does not allow it to unmount. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13254/files - new: https://git.openjdk.org/jdk/pull/13254/files/8108f217..841f5a78 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13254&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13254&range=01-02 Stats: 45 lines in 1 file changed: 30 ins; 0 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/13254.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13254/head:pull/13254 PR: https://git.openjdk.org/jdk/pull/13254 From amenkov at openjdk.org Fri Apr 7 02:25:43 2023 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 7 Apr 2023 02:25:43 GMT Subject: RFR: 8299414: JVMTI FollowReferences should support references from VirtualThread stack [v4] In-Reply-To: <6oQOD_egcB3HyuagMWGSPLjKSE3JkaI2K2WOsDK1Cww=.c568223b-5100-4425-a4b7-defbd812a9ff@github.com> References: <6oQOD_egcB3HyuagMWGSPLjKSE3JkaI2K2WOsDK1Cww=.c568223b-5100-4425-a4b7-defbd812a9ff@github.com> Message-ID: <6PJnRfvOuXFiO9boUg2aQevPX6458AsY1nYQNcZDX70=.faf4c611-4f5e-4258-aef2-d9154d7ff0b2@github.com> > The fix updates JVMTI FollowReferences implementation to report references from virtual threads: > - added heap scanning to report unmounted vthreads; > - stacks of mounted vthreads are splitted into 2 parts (vittual thread stack and carrier thread stack), references are reported with correct thread id/class and object tags/frame depth; > - common code to handle stack frames are moved into separate class; Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: trailing spaces ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13254/files - new: https://git.openjdk.org/jdk/pull/13254/files/841f5a78..47657252 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13254&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13254&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13254.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13254/head:pull/13254 PR: https://git.openjdk.org/jdk/pull/13254 From lmesnik at openjdk.org Fri Apr 7 02:30:45 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 7 Apr 2023 02:30:45 GMT Subject: RFR: 8299414: JVMTI FollowReferences should support references from VirtualThread stack [v4] In-Reply-To: <6PJnRfvOuXFiO9boUg2aQevPX6458AsY1nYQNcZDX70=.faf4c611-4f5e-4258-aef2-d9154d7ff0b2@github.com> References: <6oQOD_egcB3HyuagMWGSPLjKSE3JkaI2K2WOsDK1Cww=.c568223b-5100-4425-a4b7-defbd812a9ff@github.com> <6PJnRfvOuXFiO9boUg2aQevPX6458AsY1nYQNcZDX70=.faf4c611-4f5e-4258-aef2-d9154d7ff0b2@github.com> Message-ID: On Fri, 7 Apr 2023 02:25:43 GMT, Alex Menkov wrote: >> The fix updates JVMTI FollowReferences implementation to report references from virtual threads: >> - added heap scanning to report unmounted vthreads; >> - stacks of mounted vthreads are splitted into 2 parts (vittual thread stack and carrier thread stack), references are reported with correct thread id/class and object tags/frame depth; >> - common code to handle stack frames are moved into separate class; > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > trailing spaces Changes requested by lmesnik (Reviewer). test/hotspot/jtreg/serviceability/jvmti/vthread/FollowReferences/libVThreadStackRefTest.cpp line 179: > 177: } > 178: > 179: static volatile bool timeToExit = false; It is not enough to make variable volatile in c++. You need to make it atomic or use monitors to correctly synchronize. ------------- PR Review: https://git.openjdk.org/jdk/pull/13254#pullrequestreview-1375759394 PR Review Comment: https://git.openjdk.org/jdk/pull/13254#discussion_r1160389940 From amenkov at openjdk.org Fri Apr 7 04:51:36 2023 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 7 Apr 2023 04:51:36 GMT Subject: RFR: 8299414: JVMTI FollowReferences should support references from VirtualThread stack [v5] In-Reply-To: <6oQOD_egcB3HyuagMWGSPLjKSE3JkaI2K2WOsDK1Cww=.c568223b-5100-4425-a4b7-defbd812a9ff@github.com> References: <6oQOD_egcB3HyuagMWGSPLjKSE3JkaI2K2WOsDK1Cww=.c568223b-5100-4425-a4b7-defbd812a9ff@github.com> Message-ID: > The fix updates JVMTI FollowReferences implementation to report references from virtual threads: > - added heap scanning to report unmounted vthreads; > - stacks of mounted vthreads are splitted into 2 parts (vittual thread stack and carrier thread stack), references are reported with correct thread id/class and object tags/frame depth; > - common code to handle stack frames are moved into separate class; Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: Use atomic for synchronization ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13254/files - new: https://git.openjdk.org/jdk/pull/13254/files/47657252..f7831794 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13254&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13254&range=03-04 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13254.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13254/head:pull/13254 PR: https://git.openjdk.org/jdk/pull/13254 From amenkov at openjdk.org Fri Apr 7 04:51:39 2023 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 7 Apr 2023 04:51:39 GMT Subject: RFR: 8299414: JVMTI FollowReferences should support references from VirtualThread stack [v4] In-Reply-To: References: <6oQOD_egcB3HyuagMWGSPLjKSE3JkaI2K2WOsDK1Cww=.c568223b-5100-4425-a4b7-defbd812a9ff@github.com> <6PJnRfvOuXFiO9boUg2aQevPX6458AsY1nYQNcZDX70=.faf4c611-4f5e-4258-aef2-d9154d7ff0b2@github.com> Message-ID: On Fri, 7 Apr 2023 02:27:59 GMT, Leonid Mesnik wrote: >> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: >> >> trailing spaces > > test/hotspot/jtreg/serviceability/jvmti/vthread/FollowReferences/libVThreadStackRefTest.cpp line 179: > >> 177: } >> 178: >> 179: static volatile bool timeToExit = false; > > It is not enough to make variable volatile in c++. You need to make it atomic or use monitors to correctly synchronize. fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13254#discussion_r1160432556 From stuefe at openjdk.org Fri Apr 7 06:05:49 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 7 Apr 2023 06:05:49 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v7] In-Reply-To: <3jNPX5xpKbZQ0Cz05qJHuDLRpx5SmhzOxIHCeERnDWg=.90260d1e-6d77-430c-b0dc-a83df36b1272@github.com> References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> <1K_5UDcRkPBwGy5qnR6KouHWF1wX6CRiX9sWgdBBxbA=.9e637d8f-817a-42a7-92df-1e2f5ad3d7f1@github.com> <3jNPX5xpKbZQ0Cz05qJHuDLRpx5SmhzOxIHCeERnDWg=.90260d1e-6d77-430c-b0dc-a83df36b1272@github.com> Message-ID: <7ams55QLQB0VUnTJfQBNoFlrgkZUBKTYsBL-NGVAxJY=.55a97708-fa04-4705-bf4d-60bf27d0a872@github.com> On Thu, 6 Apr 2023 21:17:25 GMT, Glavo wrote: >> The point of Architecture is reflect the architecture as supported by the build and the runtime mutually and to reflect dependencies on the target hardware. >> >> What did you use as the example that would not compile on the other architecture? >> Did you make the other changes to the build that would be needed for a new architecture? > >> What did you use as the example that would not compile on the other architecture? > > https://github.com/openjdk/jdk/blob/52ca4a70fc3de9e285964f9545ea8cd54e2d9924/src/java.base/share/classes/jdk/internal/util/OperatingSystemProps.java.template#L40 > > I don't understand how the above code can be compiled on architectures such as LongArch64, MIPS64el, or ARM32 without modifying the source file. > >> Did you make the other changes to the build that would be needed for a new architecture? > > I'm not talking about the new architecture, I'm talking about the architecture that OpenJDK already supports. > > According to my understanding, the above code breaks the support of all architectures not listed in `Architecture`. But has `Architecture` really listed all the supported architectures in the OpenJDK mainline? > > For example, I want to compile OpenJDK for 32-bit ARM. I think in this PR, I cannot compile without modifying the source code because `TARGET_ARCH_arm` does not exist. But before this PR, I was able to compile. @Glavo Arm32 builds, though, see GHAs (crossbuilding test). As for the others, as long as the ports have not been integrated into mainline, I expect port maintainers will adapt the enum downstream. They do this anyway. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160459041 From jpai at openjdk.org Fri Apr 7 06:29:51 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 7 Apr 2023 06:29:51 GMT Subject: RFR: 8304919: Implementation of Virtual Threads [v6] In-Reply-To: References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com> Message-ID: On Thu, 6 Apr 2023 15:49:27 GMT, Alan Bateman wrote: >> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview. >> >> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently. >> >> In addition, there are a small number of implementation changes to sync up from the loom fibers branch: >> >> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly. >> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes. >> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs. >> - New system property to print a stack trace when a virtual thread sets its own value of a TL. >> - ThreadPerTaskExecutor is changed to use FutureTask. >> >> Testing: tier1-6. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: > > - Test/comments updates > - Merge > - Expand tests for jdk.ThreadSleep event > - Review feedback > - Merge > - Fix ThreadSleepEvent again > - Test updates > - ThreadSleepEvent refactoring > - Merge > - Merge > - ... and 1 more: https://git.openjdk.org/jdk/compare/7adf8162...a5bb3fd9 src/java.base/share/classes/java/lang/ThreadLocal.java line 825: > 823: // switch to carrier thread to avoid recursive use of thread-locals > 824: vthread.executeOnCarrierThread(() -> { > 825: System.out.println(vthread); Hello Alan, as far as I have seen, much of a our debug logs/stacktrace in the JDK uses `System.err` to write them out. For example, `Thread.dumpStack()`, then even `java.security.debug` logging and many such places. Is it intentional that this tracing here uses `System.out` instead? src/java.base/share/classes/java/lang/ThreadLocal.java line 832: > 830: }); > 831: } catch (Exception e) { > 832: throw new InternalError(e); Should inability to log/trace `ThreadLocal` creation or `set` lead to those operations failing? Or would it be OK, if we just ignored this exception that happened when tracing/logging? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1160468749 PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1160469548 From stuefe at openjdk.org Fri Apr 7 06:35:49 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 7 Apr 2023 06:35:49 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v7] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Thu, 6 Apr 2023 20:39:41 GMT, Roger Riggs wrote: > > What about PPC (big endian)? Used on AIX? > > I'm not aware of any code (in OpenJDK) related to big/little endian that is derived from `os.arch`. > > > On Arm, it may be useful to know whether we built for thumb mode (We recently had this problem in tests). > > For tests, there is the test library `jdk.test.lib.Platform` class with its own set of predicates. > > For the moment, the idea is to do the minimum to replace OpenJDK internal uses of `os.arch`. What I meant was: You define PPCLE. PPCLE specifies ppc, little endian. We also have PPC big-endian, it is used by AIX (and you can also run Linux with PPC big-endian). Why omit that? os.arch for AIX is "ppc64". It is even used in our codebase, see https://github.com/openjdk/jdk/blob/c67bbcea92919fea9b6f7bbcde8ba4488289d174/test/hotspot/jtreg/runtime/ElfDecoder/TestElfDirectRead.java#L51 > > Another question, how does this work with Zero? > > Zero is orthogonal to architecture; the interpreter is compiled for a specific target architecture. Sorry, I was not clear. Zero is the vehicle to get the OpenJDK to build and run on hardware we don't directly support. It is not only used in bootstrapping but finds surprisingly broad use, e.g., for Debian wich itself supports a wide range of platforms and tries to provide java on all of them. For these JDKs, IIUC, os.arch would have the value of the target architecture ("PA-RISC", "mips", "alpha" etc). These platforms would be at a disadvantage now, as @Glavo pointed out: since OPENJDK_TARGET_CPU is fed from uname: https://github.com/openjdk/jdk/blob/c67bbcea92919fea9b6f7bbcde8ba4488289d174/make/RunTestsPrebuilt.gmk#L182, they will have a name that expands to an enum that is not compilable. So all of these platforms will get build errors. I understand your intention to keep this patch simple, and that you want to limit the enum value. I also like enums. I wonder whether it would be possible to have an enum value "other" and map unknown architectures to that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1499986742 From alanb at openjdk.org Fri Apr 7 06:38:48 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 7 Apr 2023 06:38:48 GMT Subject: RFR: 8304919: Implementation of Virtual Threads [v6] In-Reply-To: References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com> Message-ID: On Fri, 7 Apr 2023 06:26:30 GMT, Jaikiran Pai wrote: > Or would it be OK, if we just ignored this exception that happened when tracing/logging? If, for example, something has changed System.out to be a throwing PrintStream, and this diagnostic option is enabled, then it may fail here. As it's just a diagnostic option then I don't think it's a bit issue. Also this code will change with a future PR that will integrate this will filtering. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1160473898 From jpai at openjdk.org Fri Apr 7 06:45:52 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 7 Apr 2023 06:45:52 GMT Subject: RFR: 8304919: Implementation of Virtual Threads [v6] In-Reply-To: References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com> Message-ID: On Thu, 6 Apr 2023 15:49:27 GMT, Alan Bateman wrote: >> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview. >> >> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently. >> >> In addition, there are a small number of implementation changes to sync up from the loom fibers branch: >> >> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly. >> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes. >> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs. >> - New system property to print a stack trace when a virtual thread sets its own value of a TL. >> - ThreadPerTaskExecutor is changed to use FutureTask. >> >> Testing: tier1-6. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: > > - Test/comments updates > - Merge > - Expand tests for jdk.ThreadSleep event > - Review feedback > - Merge > - Fix ThreadSleepEvent again > - Test updates > - ThreadSleepEvent refactoring > - Merge > - Merge > - ... and 1 more: https://git.openjdk.org/jdk/compare/430702c5...a5bb3fd9 src/java.base/share/classes/java/lang/ThreadLocal.java line 823: > 821: .collect(Collectors.toList())); > 822: > 823: // switch to carrier thread to avoid recursive use of thread-locals The lambda here uses `System.out` to format and print and there's a loop which converts each collect `StackFrame` to a printable `StackTraceElement`. I had a brief look at the internals of the classes involved, but couldn't spot any code that instantiates or calls `set()` on any `ThreadLocal`s. Is there any specific code here which would trigger recursive thread-local usage or is it more a precaution to prevent any such potential usage. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1160476293 From alanb at openjdk.org Fri Apr 7 06:45:55 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 7 Apr 2023 06:45:55 GMT Subject: RFR: 8304919: Implementation of Virtual Threads [v6] In-Reply-To: References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com> Message-ID: On Fri, 7 Apr 2023 06:24:43 GMT, Jaikiran Pai wrote: > Hello Alan, as far as I have seen, much of a our debug logs/stacktrace in the JDK uses `System.err` to write them out. For example, `Thread.dumpStack()`, then even `java.security.debug` logging and many such places. Is it intentional that this tracing here uses `System.out` instead? The tracing/diagnostic options print to stdout so I just kept it consistent. As I mentioned in another comment, there is further work on filtering that will require re-visiting this and maybe we can look at having broader consistency then, just not this PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1160476763 From jpai at openjdk.org Fri Apr 7 06:49:51 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 7 Apr 2023 06:49:51 GMT Subject: RFR: 8304919: Implementation of Virtual Threads [v6] In-Reply-To: References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com> Message-ID: On Thu, 6 Apr 2023 15:49:27 GMT, Alan Bateman wrote: >> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview. >> >> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently. >> >> In addition, there are a small number of implementation changes to sync up from the loom fibers branch: >> >> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly. >> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes. >> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs. >> - New system property to print a stack trace when a virtual thread sets its own value of a TL. >> - ThreadPerTaskExecutor is changed to use FutureTask. >> >> Testing: tier1-6. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: > > - Test/comments updates > - Merge > - Expand tests for jdk.ThreadSleep event > - Review feedback > - Merge > - Fix ThreadSleepEvent again > - Test updates > - ThreadSleepEvent refactoring > - Merge > - Merge > - ... and 1 more: https://git.openjdk.org/jdk/compare/a6347823...a5bb3fd9 src/java.base/share/classes/java/lang/ThreadLocal.java line 805: > 803: /** > 804: * Reads the value of the jdk.traceVirtualThreadLocals property to determine if > 805: * a stack trace should be printed when a virtual threads sets a thread local. Trivial typo - "virtual threads sets ...." should have been "virtual thread sets ...." ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1160478015 From alanb at openjdk.org Fri Apr 7 06:49:54 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 7 Apr 2023 06:49:54 GMT Subject: RFR: 8304919: Implementation of Virtual Threads [v6] In-Reply-To: References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com> Message-ID: On Fri, 7 Apr 2023 06:41:26 GMT, Jaikiran Pai wrote: > The lambda here uses `System.out` to format and print and there's a loop which converts each collect `StackFrame` to a printable `StackTraceElement`. I had a brief look at the internals of the classes involved, but couldn't spot any code that instantiates or calls `set()` on any `ThreadLocal`s. Is there any specific code here which would trigger recursive thread-local usage or is it more a precaution to prevent any such potential usage. Formatting is locale specific and amounts to running arbitrary code, so this cod has to defend against recursive calls. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1160478956 From jpai at openjdk.org Fri Apr 7 06:59:53 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 7 Apr 2023 06:59:53 GMT Subject: RFR: 8304919: Implementation of Virtual Threads [v6] In-Reply-To: References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com> Message-ID: On Thu, 6 Apr 2023 15:49:27 GMT, Alan Bateman wrote: >> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview. >> >> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently. >> >> In addition, there are a small number of implementation changes to sync up from the loom fibers branch: >> >> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly. >> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes. >> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs. >> - New system property to print a stack trace when a virtual thread sets its own value of a TL. >> - ThreadPerTaskExecutor is changed to use FutureTask. >> >> Testing: tier1-6. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: > > - Test/comments updates > - Merge > - Expand tests for jdk.ThreadSleep event > - Review feedback > - Merge > - Fix ThreadSleepEvent again > - Test updates > - ThreadSleepEvent refactoring > - Merge > - Merge > - ... and 1 more: https://git.openjdk.org/jdk/compare/c776b73f...a5bb3fd9 src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 72: > 70: RECORD_PATTERNS, > 71: // not used > 72: VIRTUAL_THREADS, The javadoc `Preview` page lists the preview features (and the JEPs) that are part of a release. For example, for JDK 20 the page is here https://docs.oracle.com/en/java/javase/20/docs/api/preview-list.html. In a JDK image that's built out of this PR, does the missing `@JEP` annotation on this enum value cause issues in javadoc image generation or presentation on that page? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1160484235 From alanb at openjdk.org Fri Apr 7 07:11:50 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 7 Apr 2023 07:11:50 GMT Subject: RFR: 8304919: Implementation of Virtual Threads [v6] In-Reply-To: References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com> Message-ID: On Fri, 7 Apr 2023 06:56:51 GMT, Jaikiran Pai wrote: > In a JDK image that's built out of this PR, does the missing `@JEP` annotation on this enum value cause issues in javadoc image generation or presentation on that page? This has been looked at a few times and we didn't find any issues. Ideally the constant would be removed but we are forced to leave it for now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1160490631 From jpai at openjdk.org Fri Apr 7 07:11:55 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 7 Apr 2023 07:11:55 GMT Subject: RFR: 8304919: Implementation of Virtual Threads [v6] In-Reply-To: References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com> Message-ID: On Thu, 6 Apr 2023 15:49:27 GMT, Alan Bateman wrote: >> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview. >> >> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently. >> >> In addition, there are a small number of implementation changes to sync up from the loom fibers branch: >> >> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly. >> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes. >> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs. >> - New system property to print a stack trace when a virtual thread sets its own value of a TL. >> - ThreadPerTaskExecutor is changed to use FutureTask. >> >> Testing: tier1-6. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: > > - Test/comments updates > - Merge > - Expand tests for jdk.ThreadSleep event > - Review feedback > - Merge > - Fix ThreadSleepEvent again > - Test updates > - ThreadSleepEvent refactoring > - Merge > - Merge > - ... and 1 more: https://git.openjdk.org/jdk/compare/24494df1...a5bb3fd9 test/jdk/com/sun/jdi/SuspendAfterDeath.java line 2: > 1: /* > 2: * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved. This should have been `2022, 2023,` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1160490224 From jpai at openjdk.org Fri Apr 7 07:28:52 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 7 Apr 2023 07:28:52 GMT Subject: RFR: 8304919: Implementation of Virtual Threads [v6] In-Reply-To: References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com> Message-ID: On Thu, 6 Apr 2023 15:49:27 GMT, Alan Bateman wrote: >> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview. >> >> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently. >> >> In addition, there are a small number of implementation changes to sync up from the loom fibers branch: >> >> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly. >> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes. >> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs. >> - New system property to print a stack trace when a virtual thread sets its own value of a TL. >> - ThreadPerTaskExecutor is changed to use FutureTask. >> >> Testing: tier1-6. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: > > - Test/comments updates > - Merge > - Expand tests for jdk.ThreadSleep event > - Review feedback > - Merge > - Fix ThreadSleepEvent again > - Test updates > - ThreadSleepEvent refactoring > - Merge > - Merge > - ... and 1 more: https://git.openjdk.org/jdk/compare/a85d6cbe...a5bb3fd9 test/jdk/java/lang/Thread/java.base/jdk/internal/event/ThreadSleepEvent.java line 29: > 27: * ThreadSleepEvent to optionally throw OOME at create, begin or commit time. > 28: */ > 29: public class ThreadSleepEvent { Should this extend `jdk.internal.event.Event` and then have each of the methods have a `@Override` on them? Or would that cause some issue when this is used in a jtreg test in the `@compile` directive? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1160500794 From jpai at openjdk.org Fri Apr 7 07:41:52 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 7 Apr 2023 07:41:52 GMT Subject: RFR: 8304919: Implementation of Virtual Threads [v6] In-Reply-To: References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com> Message-ID: <5qIKJpxmQtkzyHNAtMdEPV9NHYUGMXinsHk6gTOk8WM=.4ffa9d7e-ae4f-4ab3-acbd-4c2e59642659@github.com> On Thu, 6 Apr 2023 15:49:27 GMT, Alan Bateman wrote: >> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview. >> >> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently. >> >> In addition, there are a small number of implementation changes to sync up from the loom fibers branch: >> >> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly. >> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes. >> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs. >> - New system property to print a stack trace when a virtual thread sets its own value of a TL. >> - ThreadPerTaskExecutor is changed to use FutureTask. >> >> Testing: tier1-6. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: > > - Test/comments updates > - Merge > - Expand tests for jdk.ThreadSleep event > - Review feedback > - Merge > - Fix ThreadSleepEvent again > - Test updates > - ThreadSleepEvent refactoring > - Merge > - Merge > - ... and 1 more: https://git.openjdk.org/jdk/compare/c2ee11c7...a5bb3fd9 test/jdk/java/lang/Thread/virtual/TraceVirtualThreadLocals.java line 52: > 50: name.get(); > 51: }); > 52: assertContains(output, "java.lang.ThreadLocal.get"); Should it also assert the presence of `ThreadLocal.setInitialValue` in the stacktrace? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1160508153 From alanb at openjdk.org Fri Apr 7 07:45:55 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 7 Apr 2023 07:45:55 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v7] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Fri, 7 Apr 2023 06:33:08 GMT, Thomas Stuefe wrote: > What I meant was: You define PPCLE. PPCLE specifies ppc, little endian. We also have PPC big-endian, it is used by AIX (and you can also run Linux with PPC big-endian). Why omit that? > > os.arch for AIX is "ppc64". So I think you are saying that there are aix-ppc64 and linux-ppc64le builds so this enum needs to have values for both ppc64 and ppc64le. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1500032422 From jpai at openjdk.org Fri Apr 7 07:49:58 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 7 Apr 2023 07:49:58 GMT Subject: RFR: 8304919: Implementation of Virtual Threads [v6] In-Reply-To: References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com> Message-ID: On Fri, 7 Apr 2023 07:25:59 GMT, Jaikiran Pai wrote: >> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: >> >> - Test/comments updates >> - Merge >> - Expand tests for jdk.ThreadSleep event >> - Review feedback >> - Merge >> - Fix ThreadSleepEvent again >> - Test updates >> - ThreadSleepEvent refactoring >> - Merge >> - Merge >> - ... and 1 more: https://git.openjdk.org/jdk/compare/97c49893...a5bb3fd9 > > test/jdk/java/lang/Thread/java.base/jdk/internal/event/ThreadSleepEvent.java line 29: > >> 27: * ThreadSleepEvent to optionally throw OOME at create, begin or commit time. >> 28: */ >> 29: public class ThreadSleepEvent { > > Should this extend `jdk.internal.event.Event` and then have each of the methods have a `@Override` on them? Or would that cause some issue when this is used in a jtreg test in the `@compile` directive? Same comment for the newly introduced `test/jdk/java/lang/Thread/virtual/java.base/jdk/internal/event/VirtualThreadPinnedEvent.java` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1160511761 From jpai at openjdk.org Fri Apr 7 07:50:00 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 7 Apr 2023 07:50:00 GMT Subject: RFR: 8304919: Implementation of Virtual Threads [v6] In-Reply-To: References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com> Message-ID: On Thu, 6 Apr 2023 15:49:27 GMT, Alan Bateman wrote: >> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview. >> >> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently. >> >> In addition, there are a small number of implementation changes to sync up from the loom fibers branch: >> >> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly. >> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes. >> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs. >> - New system property to print a stack trace when a virtual thread sets its own value of a TL. >> - ThreadPerTaskExecutor is changed to use FutureTask. >> >> Testing: tier1-6. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: > > - Test/comments updates > - Merge > - Expand tests for jdk.ThreadSleep event > - Review feedback > - Merge > - Fix ThreadSleepEvent again > - Test updates > - ThreadSleepEvent refactoring > - Merge > - Merge > - ... and 1 more: https://git.openjdk.org/jdk/compare/97c49893...a5bb3fd9 test/jdk/java/lang/Thread/virtual/YieldQueuing.java line 2: > 1: /* > 2: * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved. Should have been `2022, 2023,` test/jdk/java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java line 2: > 1: /* > 2: * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved. Same as some other files with copyright year updates, should have been `2022, 2023,` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1160510856 PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1160513282 From alanb at openjdk.org Fri Apr 7 08:39:50 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 7 Apr 2023 08:39:50 GMT Subject: RFR: 8304919: Implementation of Virtual Threads [v6] In-Reply-To: References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com> Message-ID: On Fri, 7 Apr 2023 07:44:39 GMT, Jaikiran Pai wrote: >> test/jdk/java/lang/Thread/java.base/jdk/internal/event/ThreadSleepEvent.java line 29: >> >>> 27: * ThreadSleepEvent to optionally throw OOME at create, begin or commit time. >>> 28: */ >>> 29: public class ThreadSleepEvent { >> >> Should this extend `jdk.internal.event.Event` and then have each of the methods have a `@Override` on them? Or would that cause some issue when this is used in a jtreg test in the `@compile` directive? > > Same comment for the newly introduced `test/jdk/java/lang/Thread/virtual/java.base/jdk/internal/event/VirtualThreadPinnedEvent.java` > Should this extend `jdk.internal.event.Event` and then have each of the methods have a `@Override` on them? Or would that cause some issue when this is used in a jtreg test in the `@compile` directive? Okay, we can do that do as it might be cleaner for something changing these tests in the future and help to find issues quickly in the event that the internal infrastructure for JFR events in java.base changes in the future. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1160543904 From alanb at openjdk.org Fri Apr 7 08:39:56 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 7 Apr 2023 08:39:56 GMT Subject: RFR: 8304919: Implementation of Virtual Threads [v6] In-Reply-To: References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com> Message-ID: <_8akvgHjBo-ri1FBYwKY9ZvnCl1wgJplmI7ws6Q4giU=.05eb7df4-06dd-402a-91a6-37cdbb8bb04e@github.com> On Fri, 7 Apr 2023 07:43:02 GMT, Jaikiran Pai wrote: >> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: >> >> - Test/comments updates >> - Merge >> - Expand tests for jdk.ThreadSleep event >> - Review feedback >> - Merge >> - Fix ThreadSleepEvent again >> - Test updates >> - ThreadSleepEvent refactoring >> - Merge >> - Merge >> - ... and 1 more: https://git.openjdk.org/jdk/compare/9db93ce4...a5bb3fd9 > > test/jdk/java/lang/Thread/virtual/YieldQueuing.java line 2: > >> 1: /* >> 2: * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved. > > Should have been `2022, 2023,` Yes, it should. There are 200+ tests updated, the majority of which were updated with `sed` rather than manual edits, got it wrong for 5 tests it seems. I'll fix those, thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1160542385 From alanb at openjdk.org Fri Apr 7 08:46:52 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 7 Apr 2023 08:46:52 GMT Subject: RFR: 8304919: Implementation of Virtual Threads [v6] In-Reply-To: <5qIKJpxmQtkzyHNAtMdEPV9NHYUGMXinsHk6gTOk8WM=.4ffa9d7e-ae4f-4ab3-acbd-4c2e59642659@github.com> References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com> <5qIKJpxmQtkzyHNAtMdEPV9NHYUGMXinsHk6gTOk8WM=.4ffa9d7e-ae4f-4ab3-acbd-4c2e59642659@github.com> Message-ID: On Fri, 7 Apr 2023 07:38:31 GMT, Jaikiran Pai wrote: >> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: >> >> - Test/comments updates >> - Merge >> - Expand tests for jdk.ThreadSleep event >> - Review feedback >> - Merge >> - Fix ThreadSleepEvent again >> - Test updates >> - ThreadSleepEvent refactoring >> - Merge >> - Merge >> - ... and 1 more: https://git.openjdk.org/jdk/compare/49869acd...a5bb3fd9 > > test/jdk/java/lang/Thread/virtual/TraceVirtualThreadLocals.java line 52: > >> 50: name.get(); >> 51: }); >> 52: assertContains(output, "java.lang.ThreadLocal.get"); > > Should it also assert the presence of `ThreadLocal.setInitialValue` in the stacktrace? It's the `get` method that triggers the initial value to be generated so this is why the test checks that method. But I think you have a point it would be clearer if the the test were to match on something that has "initialValue" in the string. It means using the name of an internal method but it might be okay here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13203#discussion_r1160548887 From duke at openjdk.org Fri Apr 7 09:10:49 2023 From: duke at openjdk.org (ExE Boss) Date: Fri, 7 Apr 2023 09:10:49 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v7] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Thu, 6 Apr 2023 19:25:19 GMT, Roger Riggs wrote: >> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. >> The enumeration values are defined to match those used in the build. >> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE` >> Note that `amd64` and `x86_64` in the build are represented by `X64`. >> The values of the system property `os.arch` is unchanged. >> >> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). >> Uses in `java.base` and a few others are included but other modules will be done in separate PRs. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Remove unneeded qualified export from java.base to jdk.attach src/jdk.attach/windows/classes/sun/tools/attach/AttachProviderImpl.java line 38: > 36: > 37: import jdk.internal.util.Architecture; > 38: Not?removed in?[commit?`ab084c2` or?`52ca4a7`](https://github.com/openjdk/jdk/pull/13357/files/105ce60528f7ef84e31ac3db64e6eb63860b4a70..52ca4a70fc3de9e285964f9545ea8cd54e2d9924): Suggestion: ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160563815 From stuefe at openjdk.org Fri Apr 7 09:30:48 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 7 Apr 2023 09:30:48 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v7] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Fri, 7 Apr 2023 07:42:51 GMT, Alan Bateman wrote: > > What I meant was: You define PPCLE. PPCLE specifies ppc, little endian. We also have PPC big-endian, it is used by AIX (and you can also run Linux with PPC big-endian). Why omit that? > > os.arch for AIX is "ppc64". > > So I think you are saying that there are aix-ppc64 and linux-ppc64le builds so this enum needs to have values for both ppc64 and ppc64le. Yes, precisely. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1500115177 From duke at openjdk.org Fri Apr 7 10:06:09 2023 From: duke at openjdk.org (ExE Boss) Date: Fri, 7 Apr 2023 10:06:09 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v7] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Fri, 7 Apr 2023 09:28:18 GMT, Thomas Stuefe wrote: > > > What I meant was: You define PPCLE. PPCLE specifies ppc, little endian. We also have PPC big-endian, it is used by AIX (and you can also run Linux with PPC big-endian). Why omit that? > > > os.arch for AIX is "ppc64". > > > > > > So I think you are saying that there are aix-ppc64 and linux-ppc64le builds so this enum needs to have values for both ppc64 and ppc64le. > > Yes, precisely. In?that?case, they?should probably be?called `PPC64BE` and?`PPC64LE`?to?disambiguate between?them. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1500140904 From stuefe at openjdk.org Fri Apr 7 10:26:50 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 7 Apr 2023 10:26:50 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v7] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Thu, 6 Apr 2023 19:25:19 GMT, Roger Riggs wrote: >> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. >> The enumeration values are defined to match those used in the build. >> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE` >> Note that `amd64` and `x86_64` in the build are represented by `X64`. >> The values of the system property `os.arch` is unchanged. >> >> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). >> Uses in `java.base` and a few others are included but other modules will be done in separate PRs. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Remove unneeded qualified export from java.base to jdk.attach src/java.base/share/classes/jdk/internal/util/Architecture.java line 41: > 39: AARCH64(), > 40: RISCV64(), > 41: S390(), Why getting rid of the X in s390x? There has not been an s390 linux kernel in almost ten years. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160610072 From jpai at openjdk.org Fri Apr 7 10:55:49 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 7 Apr 2023 10:55:49 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v7] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: <1rnezvB6dF2qCWucljVIY9AO_mGGDCwZfah9pntJFmU=.391a8c44-602e-49d0-a8b7-379d174712ce@github.com> On Fri, 7 Apr 2023 10:24:20 GMT, Thomas Stuefe wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unneeded qualified export from java.base to jdk.attach > > src/java.base/share/classes/jdk/internal/util/Architecture.java line 41: > >> 39: AARCH64(), >> 40: RISCV64(), >> 41: S390(), > > Why getting rid of the X in s390x? There has not been an s390 linux kernel in almost ten years. Hello Thomas, that change was based on the review comment here https://github.com/openjdk/jdk/pull/13357#discussion_r1159810942 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160623813 From stuefe at openjdk.org Fri Apr 7 11:24:50 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 7 Apr 2023 11:24:50 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v7] In-Reply-To: <1rnezvB6dF2qCWucljVIY9AO_mGGDCwZfah9pntJFmU=.391a8c44-602e-49d0-a8b7-379d174712ce@github.com> References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> <1rnezvB6dF2qCWucljVIY9AO_mGGDCwZfah9pntJFmU=.391a8c44-602e-49d0-a8b7-379d174712ce@github.com> Message-ID: On Fri, 7 Apr 2023 10:52:47 GMT, Jaikiran Pai wrote: >> src/java.base/share/classes/jdk/internal/util/Architecture.java line 41: >> >>> 39: AARCH64(), >>> 40: RISCV64(), >>> 41: S390(), >> >> Why getting rid of the X in s390x? There has not been an s390 linux kernel in almost ten years. > > Hello Thomas, that change was based on the review comment here https://github.com/openjdk/jdk/pull/13357#discussion_r1159810942 Okay, Lutz is the expert here. Sorry for the noise. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160637280 From alanb at openjdk.org Fri Apr 7 11:54:00 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 7 Apr 2023 11:54:00 GMT Subject: RFR: 8304919: Implementation of Virtual Threads [v7] In-Reply-To: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com> References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com> Message-ID: <-mPFKr9vh4NoXyvJfYAlS0UmtkuxdKdk0UZpm6lcif0=.adcf09ea-f301-4c82-93d0-f6cfcc7a8b51@github.com> > JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview. > > There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently. > > In addition, there are a small number of implementation changes to sync up from the loom fibers branch: > > - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly. > - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes. > - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs. > - New system property to print a stack trace when a virtual thread sets its own value of a TL. > - ThreadPerTaskExecutor is changed to use FutureTask. > > Testing: tier1-6. Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision: - Merge - Test updates to address review comments - Test/comments updates - Merge - Expand tests for jdk.ThreadSleep event - Review feedback - Merge - Fix ThreadSleepEvent again - Test updates - ThreadSleepEvent refactoring - ... and 3 more: https://git.openjdk.org/jdk/compare/a19243ec...cd680f66 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13203/files - new: https://git.openjdk.org/jdk/pull/13203/files/a5bb3fd9..cd680f66 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13203&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13203&range=05-06 Stats: 3163 lines in 90 files changed: 2642 ins; 442 del; 79 mod Patch: https://git.openjdk.org/jdk/pull/13203.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13203/head:pull/13203 PR: https://git.openjdk.org/jdk/pull/13203 From lucy at openjdk.org Fri Apr 7 12:08:49 2023 From: lucy at openjdk.org (Lutz Schmidt) Date: Fri, 7 Apr 2023 12:08:49 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v7] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> <1rnezvB6dF2qCWucljVIY9AO_mGGDCwZfah9pntJFmU=.391a8c44-602e-49d0-a8b7-379d174712ce@github.com> Message-ID: On Fri, 7 Apr 2023 11:21:33 GMT, Thomas Stuefe wrote: >> Hello Thomas, that change was based on the review comment here https://github.com/openjdk/jdk/pull/13357#discussion_r1159810942 > > Okay, Lutz is the expert here. Sorry for the noise. Just to let my voice be heard directly after being cited several times: s390 is used to designate the CPU architecture. The arch-specific files are stored in src/hotspot/cpu/s390 for that reason. Back in the days when SAP contributed the s390 port, there was a discussion which architecture name to use. SAP had used zArch_64 which more closely reflects what the port really is (a 64-bit only port to IBM's z/Architecture). It was a majority decision to use s390 for some historic reasons (I don't remember exactly anymore). s390x is (almost) always used in conjunction with a Linux OS port. In that respect, linuxs390x is a tautology. OpenJDK does not use this tautology, see src/hotspot/os_cpu/linux_s390 for example. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160657249 From jpai at openjdk.org Fri Apr 7 12:44:51 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 7 Apr 2023 12:44:51 GMT Subject: RFR: 8304919: Implementation of Virtual Threads [v7] In-Reply-To: <-mPFKr9vh4NoXyvJfYAlS0UmtkuxdKdk0UZpm6lcif0=.adcf09ea-f301-4c82-93d0-f6cfcc7a8b51@github.com> References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com> <-mPFKr9vh4NoXyvJfYAlS0UmtkuxdKdk0UZpm6lcif0=.adcf09ea-f301-4c82-93d0-f6cfcc7a8b51@github.com> Message-ID: <2mMJCOu4-A2LKcNdNqVHXGy_yg8Yncc67BysDb7sedc=.5852ccfc-c175-46c3-9bc0-a9058320215f@github.com> On Fri, 7 Apr 2023 11:54:00 GMT, Alan Bateman wrote: >> JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview. >> >> There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently. >> >> In addition, there are a small number of implementation changes to sync up from the loom fibers branch: >> >> - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly. >> - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes. >> - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs. >> - New system property to print a stack trace when a virtual thread sets its own value of a TL. >> - ThreadPerTaskExecutor is changed to use FutureTask. >> >> Testing: tier1-6. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision: > > - Merge > - Test updates to address review comments > - Test/comments updates > - Merge > - Expand tests for jdk.ThreadSleep event > - Review feedback > - Merge > - Fix ThreadSleepEvent again > - Test updates > - ThreadSleepEvent refactoring > - ... and 3 more: https://git.openjdk.org/jdk/compare/af05156d...cd680f66 Thank you for the updates Alan, they look fine to me. I've gone through the java side changes in this PR and the tests (except for hotspot tests) and they all look fine to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13203#pullrequestreview-1376162404 From rriggs at openjdk.org Fri Apr 7 14:43:50 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 7 Apr 2023 14:43:50 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v7] In-Reply-To: <3iWq-g0ji56gRdTxUVtO64dy60rPmtQsQ_64HWoCMlY=.300723e5-d788-42f4-9d40-bb768390fc0b@github.com> References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> <3iWq-g0ji56gRdTxUVtO64dy60rPmtQsQ_64HWoCMlY=.300723e5-d788-42f4-9d40-bb768390fc0b@github.com> Message-ID: On Thu, 6 Apr 2023 22:44:52 GMT, Phil Race wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unneeded qualified export from java.base to jdk.attach > > src/jdk.accessibility/windows/classes/com/sun/java/accessibility/internal/AccessBridge.java line 169: > >> 167: // Load the appropriate DLLs >> 168: boolean is32on64 = false; >> 169: if (Architecture.isX86()) { > > This would be another coupling of java.desktop into java.base internals and I don't think it worth it. > Particularly because this check is obsolete ! > It is a remnant of when accessbridge was an unbundled download so provided both 32 and 64 bit. > We don't even have the file it is looking for in the build - even if someone did a 32 bit build. > Instead of making this change a bug should be filed to remove this code. Reverting; filed [8305745](https://bugs.openjdk.org/browse/JDK-8305745) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160748988 From lmesnik at openjdk.org Fri Apr 7 19:01:34 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 7 Apr 2023 19:01:34 GMT Subject: RFR: 8304834: Fix wrapper insertion in TestScaffold.parseArgs(String args[]) [v3] In-Reply-To: <7PDwD7zFu8CYojj6LDm0qVMlVHKuJNmAzxKaWdjGuvY=.cf39e296-777b-4653-bc19-7276a7da28e8@github.com> References: <7PDwD7zFu8CYojj6LDm0qVMlVHKuJNmAzxKaWdjGuvY=.cf39e296-777b-4653-bc19-7276a7da28e8@github.com> Message-ID: > The TestScaffold incorrectly parse options, it should insert wrapper class between VM options and applications classame. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: updated parsing. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13170/files - new: https://git.openjdk.org/jdk/pull/13170/files/1b74ae22..bc8dd5ea Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13170&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13170&range=01-02 Stats: 13 lines in 2 files changed: 3 ins; 4 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/13170.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13170/head:pull/13170 PR: https://git.openjdk.org/jdk/pull/13170 From lmesnik at openjdk.org Fri Apr 7 19:02:45 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 7 Apr 2023 19:02:45 GMT Subject: RFR: 8304834: Fix wrapper insertion in TestScaffold.parseArgs(String args[]) [v2] In-Reply-To: References: <7PDwD7zFu8CYojj6LDm0qVMlVHKuJNmAzxKaWdjGuvY=.cf39e296-777b-4653-bc19-7276a7da28e8@github.com> Message-ID: <351RQSVr4b0cKr4ZlITmjYHT012ZkbjhD-etQvT-cgI=.b959bf62-3d26-4a62-b7b9-5829c7418e34@github.com> On Fri, 24 Mar 2023 06:31:14 GMT, Leonid Mesnik wrote: >> The TestScaffold incorrectly parse options, it should insert wrapper class between VM options and applications classame. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > added comments and trim arguments I have updated parsing to don't accept -J which has been used in the one test only. Also improved parsing to recognize double-argument options. Also, I provided statistic of current options in the bug. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13170#issuecomment-1500552968 From matsaave at openjdk.org Fri Apr 7 19:20:44 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 7 Apr 2023 19:20:44 GMT Subject: RFR: 8298048: Combine CDS archive heap into a single block In-Reply-To: References: Message-ID: On Mon, 3 Apr 2023 03:32:27 GMT, Ioi Lam wrote: > This PR combines the "open" and "closed" regions of the CDS archive heap into a single region. This significantly simplifies the implementation, making it more compatible with non-G1 collectors. There's a net removal of ~1000 lines in src code and another ~1200 lines of tests. > > **Notes for reviewers:** > - Most of the code changes in CDS are removing the handling of "open" vs "closed" objects. > - Reviewers can start with ArchiveHeapWriter::copy_source_objs_to_buffer(). > - It might be easier to see the diff with whitespaces off. > - There are two major changes in the G1 code > - The archived objects are now stored in the "old" region (see g1CollectedHeap.cpp in [58d720e](https://github.com/openjdk/jdk/pull/13284/commits/58d720e294bb36f21cb88cddde724ed2b9e93770)) > - The majority of the other changes are removal of the "archive" region type (see heapRegionType.hpp). For ease of review, such code is isolated in [a852dfb](https://github.com/openjdk/jdk/pull/13284/commits/a852dfbbf5ff56e035399f7cc3704f29e76697f6) > - Testing changes: > - Now the archived java objects can move, along with the "old" regions that contain them. It's no longer possible to test whether a heap object came from CDS. As a result, the `WhiteBox.isShared(Object o)` API has been removed. > - Many tests that uses this API are removed. Most of them were written during early development of CDS archived objects and are no longer relevant. > > **Testing:** > - Mach5 tiers 1 ~ 7 Great cleanup! Making CDS easier to read and use is always a plus. Just some observations/nits: ------------- PR Comment: https://git.openjdk.org/jdk/pull/13284#issuecomment-1500569237 From matsaave at openjdk.org Fri Apr 7 19:57:48 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 7 Apr 2023 19:57:48 GMT Subject: RFR: 8298048: Combine CDS archive heap into a single block In-Reply-To: References: Message-ID: On Mon, 3 Apr 2023 03:32:27 GMT, Ioi Lam wrote: > This PR combines the "open" and "closed" regions of the CDS archive heap into a single region. This significantly simplifies the implementation, making it more compatible with non-G1 collectors. There's a net removal of ~1000 lines in src code and another ~1200 lines of tests. > > **Notes for reviewers:** > - Most of the code changes in CDS are removing the handling of "open" vs "closed" objects. > - Reviewers can start with ArchiveHeapWriter::copy_source_objs_to_buffer(). > - It might be easier to see the diff with whitespaces off. > - There are two major changes in the G1 code > - The archived objects are now stored in the "old" region (see g1CollectedHeap.cpp in [58d720e](https://github.com/openjdk/jdk/pull/13284/commits/58d720e294bb36f21cb88cddde724ed2b9e93770)) > - The majority of the other changes are removal of the "archive" region type (see heapRegionType.hpp). For ease of review, such code is isolated in [a852dfb](https://github.com/openjdk/jdk/pull/13284/commits/a852dfbbf5ff56e035399f7cc3704f29e76697f6) > - Testing changes: > - Now the archived java objects can move, along with the "old" regions that contain them. It's no longer possible to test whether a heap object came from CDS. As a result, the `WhiteBox.isShared(Object o)` API has been removed. > - Many tests that uses this API are removed. Most of them were written during early development of CDS archived objects and are no longer relevant. > > **Testing:** > - Mach5 tiers 1 ~ 7 Changes requested by matsaave (Committer). src/hotspot/share/cds/archiveBuilder.cpp line 1086: > 1084: p2i(to_requested(start)), size_t(end - start)); > 1085: log_data(start, end, to_requested(start), /*is_heap=*/true); > 1086: } These log messages can be placed inside the else case before the break src/hotspot/share/cds/archiveHeapWriter.cpp line 369: > 367: template void ArchiveHeapWriter::store_requested_oop_in_buffer(T* buffered_addr, > 368: oop request_oop) { > 369: //assert(is_in_requested_regions(request_oop), "must be"); Some left over commented code. I assume this should be removed or a new assert should be here to replace it. src/hotspot/share/cds/archiveHeapWriter.cpp line 529: > 527: num_non_null_ptrs ++; > 528: > 529: if (max_idx < idx) { Is there a built in min() function we can use here? Maybe std::min()? src/hotspot/share/cds/filemap.cpp line 1674: > 1672: > 1673: char* buffer = NEW_C_HEAP_ARRAY(char, size_in_bytes, mtClassShared); > 1674: size_t written = write_bitmap(ptrmap, buffer, 0); Maybe add a comment to clarify there is no offset? Constants in method parameters can be confusing sometimes. src/hotspot/share/cds/filemap.cpp line 2035: > 2033: } > 2034: if (end < e) { > 2035: end = e; Like mentioned before, maybe we have max() and min() methods to use here. src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 520: > 518: } else { > 519: return true; > 520: } Maybe make this `return reserved.contains(range.start()) && reserved.contains(range.last())` ------------- PR Review: https://git.openjdk.org/jdk/pull/13284#pullrequestreview-1376508819 PR Review Comment: https://git.openjdk.org/jdk/pull/13284#discussion_r1160911406 PR Review Comment: https://git.openjdk.org/jdk/pull/13284#discussion_r1160911559 PR Review Comment: https://git.openjdk.org/jdk/pull/13284#discussion_r1160913791 PR Review Comment: https://git.openjdk.org/jdk/pull/13284#discussion_r1160916309 PR Review Comment: https://git.openjdk.org/jdk/pull/13284#discussion_r1160916888 PR Review Comment: https://git.openjdk.org/jdk/pull/13284#discussion_r1160924110 From rriggs at openjdk.org Fri Apr 7 21:13:03 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 7 Apr 2023 21:13:03 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v8] In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: > Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. > The enumeration values are defined to match those used in the build. > The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE` > Note that `amd64` and `x86_64` in the build are represented by `X64`. > The values of the system property `os.arch` is unchanged. > > The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). > Uses in `java.base` and a few others are included but other modules will be done in separate PRs. Roger Riggs has updated the pull request incrementally with three additional commits since the last revision: - Rename OperatingSystemProps to PlatformProps. Refactor OperatingSystem initialization to use strings instead of integers. - Revised mapping mechanism of build target architecture names to enum values. Unrecognized values from the build are mapped to enum value "OTHER". Renamed PPC64LE to PPC64 to reflect only the architecture, not the endianness. Added an `isLittleEndian` method to return the endianness (not currently used anywhere) - Revert changes to jdk.accessibility AccessBridge ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13357/files - new: https://git.openjdk.org/jdk/pull/13357/files/52ca4a70..53c20c77 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=06-07 Stats: 237 lines in 10 files changed: 123 ins; 81 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/13357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13357/head:pull/13357 PR: https://git.openjdk.org/jdk/pull/13357 From rriggs at openjdk.org Fri Apr 7 21:20:52 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 7 Apr 2023 21:20:52 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v7] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> <1rnezvB6dF2qCWucljVIY9AO_mGGDCwZfah9pntJFmU=.391a8c44-602e-49d0-a8b7-379d174712ce@github.com> Message-ID: On Fri, 7 Apr 2023 12:05:28 GMT, Lutz Schmidt wrote: >> Okay, Lutz is the expert here. Sorry for the noise. > > Just to let my voice be heard directly after being cited several times: s390 is used to designate the CPU architecture. The arch-specific files are stored in src/hotspot/cpu/s390 for that reason. Back in the days when SAP contributed the s390 port, there was a discussion which architecture name to use. SAP had used zArch_64 which more closely reflects what the port really is (a 64-bit only port to IBM's z/Architecture). It was a majority decision to use s390 for some historic reasons (I don't remember exactly anymore). > > s390x is (almost) always used in conjunction with a Linux OS port. In that respect, linuxs390x is a tautology. OpenJDK does not use this tautology, see src/hotspot/os_cpu/linux_s390 for example. Thanks for the authoritative answer. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160968894 From rriggs at openjdk.org Fri Apr 7 21:20:53 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 7 Apr 2023 21:20:53 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v7] In-Reply-To: <7ams55QLQB0VUnTJfQBNoFlrgkZUBKTYsBL-NGVAxJY=.55a97708-fa04-4705-bf4d-60bf27d0a872@github.com> References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> <1K_5UDcRkPBwGy5qnR6KouHWF1wX6CRiX9sWgdBBxbA=.9e637d8f-817a-42a7-92df-1e2f5ad3d7f1@github.com> <3jNPX5xpKbZQ0Cz05qJHuDLRpx5SmhzOxIHCeERnDWg=.90260d1e-6d77-430c-b0dc-a83df36b1272@github.com> <7ams55QLQB0VUnTJfQBNoFlrgkZUBKTYsBL-NGVAxJY=.55a97708-fa04-4705-bf4d-60bf27d0a872@github.com> Message-ID: On Fri, 7 Apr 2023 06:03:11 GMT, Thomas Stuefe wrote: >>> What did you use as the example that would not compile on the other architecture? >> >> https://github.com/openjdk/jdk/blob/52ca4a70fc3de9e285964f9545ea8cd54e2d9924/src/java.base/share/classes/jdk/internal/util/OperatingSystemProps.java.template#L40 >> >> I don't understand how the above code can be compiled on architectures such as LongArch64, MIPS64el, or ARM32 without modifying the source file. >> >>> Did you make the other changes to the build that would be needed for a new architecture? >> >> I'm not talking about the new architecture, I'm talking about the architecture that OpenJDK already supports. >> >> According to my understanding, the above code breaks the support of all architectures not listed in `Architecture`. But has `Architecture` really listed all the supported architectures in the OpenJDK mainline? >> >> For example, I want to compile OpenJDK for 32-bit ARM. I think in this PR, I cannot compile without modifying the source code because `TARGET_ARCH_arm` does not exist. But before this PR, I was able to compile. > > @Glavo Arm32 builds, though, see GHAs (crossbuilding test). As for the others, as long as the ports have not been integrated into mainline, I expect port maintainers will adapt the enum downstream. They do this anyway. > > Edit: I now understand your point better and agree in parts, see my reply below. Refactored the way that build time architecture values are mapped to the Architecture enum. It now uses strings and does not require predefined names in the template file. Explicitly maps some build time arch values to the corresponding (but not identical Arch enum); for example x86_64 to X64. Added a method to expose the endian-ness of the build; this allows it to be separated from the architecture. So for example "ppc64le" maps to PPC64 and the endian-ness is little. Added an "OTHER" to the enum values so that unrecognized architecture values from the build can be mapped to that enum. Renamed the template file so it can more naturally cover the os, architecture, endianness, and 64bit'ness of the implementation. Reworked OperatingSystem to use the same string based interface between the build and the enum. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1160968389 From rriggs at openjdk.org Fri Apr 7 21:20:50 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 7 Apr 2023 21:20:50 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v8] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Fri, 7 Apr 2023 21:13:03 GMT, Roger Riggs wrote: >> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. >> The enumeration values are defined to match those used in the build. >> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE` >> Note that `amd64` and `x86_64` in the build are represented by `X64`. >> The values of the system property `os.arch` is unchanged. >> >> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). >> Uses in `java.base` and a few others are included but other modules will be done in separate PRs. > > Roger Riggs has updated the pull request incrementally with three additional commits since the last revision: > > - Rename OperatingSystemProps to PlatformProps. > Refactor OperatingSystem initialization to use strings instead of integers. > - Revised mapping mechanism of build target architecture names to enum values. > Unrecognized values from the build are mapped to enum value "OTHER". > Renamed PPC64LE to PPC64 to reflect only the architecture, not the endianness. > Added an `isLittleEndian` method to return the endianness (not currently used anywhere) > - Revert changes to jdk.accessibility AccessBridge Take a fresh look and comment. Thanks ------------- PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1500655738 From lmesnik at openjdk.org Fri Apr 7 21:23:42 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 7 Apr 2023 21:23:42 GMT Subject: RFR: 8277573: VmObjectAlloc is not generated by intrinsics methods which allocate objects Message-ID: Updated VM internal object allocation C2 intrinsic to post jvmti events when needed. ------------- Commit messages: - fixed EA - Merge branch 'master' of https://github.com/openjdk/jdk into 8277573 - 8277573: VmObjectAlloc is not generated by intrinsics methods which allocate objects Changes: https://git.openjdk.org/jdk/pull/13312/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13312&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8277573 Stats: 78 lines in 11 files changed: 69 ins; 5 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13312.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13312/head:pull/13312 PR: https://git.openjdk.org/jdk/pull/13312 From lmesnik at openjdk.org Fri Apr 7 21:23:43 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 7 Apr 2023 21:23:43 GMT Subject: RFR: 8277573: VmObjectAlloc is not generated by intrinsics methods which allocate objects In-Reply-To: References: Message-ID: On Mon, 3 Apr 2023 22:20:43 GMT, Leonid Mesnik wrote: > Updated VM internal object allocation C2 intrinsic to post jvmti events when needed. Thanks to Vladimir K for fix in escape.cpp. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13312#issuecomment-1500656370 From lmesnik at openjdk.org Fri Apr 7 21:48:43 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 7 Apr 2023 21:48:43 GMT Subject: RFR: 8277573: VmObjectAlloc is not generated by intrinsics methods which allocate objects In-Reply-To: References: Message-ID: <3MwcnyFKbGUB420hx0RykEG43HA9Uyra08ZRFQUms7Y=.4dada609-deee-49d7-a21b-e29c8ecd3d36@github.com> On Mon, 3 Apr 2023 22:20:43 GMT, Leonid Mesnik wrote: > Updated VM internal object allocation C2 intrinsic to post jvmti events when needed. Tested with all CI tests. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13312#issuecomment-1500670951 From kvn at openjdk.org Fri Apr 7 22:23:42 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 7 Apr 2023 22:23:42 GMT Subject: RFR: 8277573: VmObjectAlloc is not generated by intrinsics methods which allocate objects In-Reply-To: References: Message-ID: On Mon, 3 Apr 2023 22:20:43 GMT, Leonid Mesnik wrote: > Updated VM internal object allocation C2 intrinsic to post jvmti events when needed. Good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13312#pullrequestreview-1376633778 From jiangli at openjdk.org Fri Apr 7 23:55:54 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 7 Apr 2023 23:55:54 GMT Subject: RFR: 8305761: Resolve multiple definition of 'jvm' when statically linking with JDK native libraries Message-ID: Rename various 'jvm' variables to 'jvm_' to avoid duplicate symbol problems when statically linking the launcher executable with JDK native libraries. 8305761: Resolve multiple definition of 'jvm' when statically linking with JDK native libraries ------------- Commit messages: - Resolve linker failure due to multiple definition of 'jvm' when statically linking with JDK native libraries. Changes: https://git.openjdk.org/jdk/pull/13396/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13396&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8305761 Stats: 130 lines in 5 files changed: 82 ins; 0 del; 48 mod Patch: https://git.openjdk.org/jdk/pull/13396.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13396/head:pull/13396 PR: https://git.openjdk.org/jdk/pull/13396 From jiangli at openjdk.org Sat Apr 8 00:04:57 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Sat, 8 Apr 2023 00:04:57 GMT Subject: Withdrawn: 8305761: Resolve multiple definition of 'jvm' when statically linking with JDK native libraries In-Reply-To: References: Message-ID: On Fri, 7 Apr 2023 23:32:46 GMT, Jiangli Zhou wrote: > Rename various 'jvm' variables to 'jvm_' to avoid duplicate symbol problems when statically linking the launcher executable with JDK native libraries. > > 8305761: Resolve multiple definition of 'jvm' when statically linking with JDK native libraries This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/13396 From jiangli at openjdk.org Sat Apr 8 01:19:44 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Sat, 8 Apr 2023 01:19:44 GMT Subject: RFR: 8305761: Resolve multiple definition of 'jvm' when statically linking with JDK native libraries Message-ID: ? with JDK native libraries ------------- Commit messages: - 8305761: Resolve multiple definition of 'jvm' when statically linking with JDK native libraries Changes: https://git.openjdk.org/jdk/pull/13397/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13397&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8305761 Stats: 36 lines in 5 files changed: 0 ins; 0 del; 36 mod Patch: https://git.openjdk.org/jdk/pull/13397.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13397/head:pull/13397 PR: https://git.openjdk.org/jdk/pull/13397 From stuefe at openjdk.org Sat Apr 8 07:10:55 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 8 Apr 2023 07:10:55 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v7] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> <1K_5UDcRkPBwGy5qnR6KouHWF1wX6CRiX9sWgdBBxbA=.9e637d8f-817a-42a7-92df-1e2f5ad3d7f1@github.com> <3jNPX5xpKbZQ0Cz05qJHuDLRpx5SmhzOxIHCeERnDWg=.90260d1e-6d77-430c-b0dc-a83df36b1272@github.com> <7ams55QLQB0VUnTJfQBNoFlrgkZUBKTYsBL-NGVAxJY=.55a97708-fa04-4705-bf4d-60bf27d0a872@github.com> Message-ID: On Fri, 7 Apr 2023 21:15:11 GMT, Roger Riggs wrote: > Refactored the way that build time architecture values are mapped to the Architecture enum. Thank you for this, Roger. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1161075537 From stuefe at openjdk.org Sat Apr 8 07:17:44 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 8 Apr 2023 07:17:44 GMT Subject: RFR: 8298048: Combine CDS archive heap into a single block In-Reply-To: References: Message-ID: On Mon, 3 Apr 2023 03:32:27 GMT, Ioi Lam wrote: > This PR combines the "open" and "closed" regions of the CDS archive heap into a single region. This significantly simplifies the implementation, making it more compatible with non-G1 collectors. There's a net removal of ~1000 lines in src code and another ~1200 lines of tests. > > **Notes for reviewers:** > - Most of the code changes in CDS are removing the handling of "open" vs "closed" objects. > - Reviewers can start with ArchiveHeapWriter::copy_source_objs_to_buffer(). > - It might be easier to see the diff with whitespaces off. > - There are two major changes in the G1 code > - The archived objects are now stored in the "old" region (see g1CollectedHeap.cpp in [58d720e](https://github.com/openjdk/jdk/pull/13284/commits/58d720e294bb36f21cb88cddde724ed2b9e93770)) > - The majority of the other changes are removal of the "archive" region type (see heapRegionType.hpp). For ease of review, such code is isolated in [a852dfb](https://github.com/openjdk/jdk/pull/13284/commits/a852dfbbf5ff56e035399f7cc3704f29e76697f6) > - Testing changes: > - Now the archived java objects can move, along with the "old" regions that contain them. It's no longer possible to test whether a heap object came from CDS. As a result, the `WhiteBox.isShared(Object o)` API has been removed. > - Many tests that uses this API are removed. Most of them were written during early development of CDS archived objects and are no longer relevant. > > **Testing:** > - Mach5 tiers 1 ~ 7 This looks like a nice simplification. Will you also combine all mappings at OS level to a single one, so that you only need one mmap call? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13284#issuecomment-1500812579 From duke at openjdk.org Sat Apr 8 08:26:49 2023 From: duke at openjdk.org (ExE Boss) Date: Sat, 8 Apr 2023 08:26:49 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v8] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Fri, 7 Apr 2023 21:13:03 GMT, Roger Riggs wrote: >> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. >> The enumeration values are defined to match those used in the build. >> The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE` >> Note that `amd64` and `x86_64` in the build are represented by `X64`. >> The values of the system property `os.arch` is unchanged. >> >> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). >> Uses in `java.base` and a few others are included but other modules will be done in separate PRs. > > Roger Riggs has updated the pull request incrementally with three additional commits since the last revision: > > - Rename OperatingSystemProps to PlatformProps. > Refactor OperatingSystem initialization to use strings instead of integers. > - Revised mapping mechanism of build target architecture names to enum values. > Unrecognized values from the build are mapped to enum value "OTHER". > Renamed PPC64LE to PPC64 to reflect only the architecture, not the endianness. > Added an `isLittleEndian` method to return the endianness (not currently used anywhere) > - Revert changes to jdk.accessibility AccessBridge src/java.base/share/classes/jdk/internal/util/Architecture.java line 47: > 45: // Cache a copy of the array for lightweight indexing > 46: private static final @Stable Architecture[] archValues = Architecture.values(); > 47: This?now appears to?be?unused: Suggestion: ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1161082612 From jwaters at openjdk.org Sat Apr 8 13:24:37 2023 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 8 Apr 2023 13:24:37 GMT Subject: RFR: 8305341: Alignment should be enforced by alignas instead of compiler specific attributes [v3] In-Reply-To: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com> References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com> Message-ID: > C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Semicolon ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13258/files - new: https://git.openjdk.org/jdk/pull/13258/files/7dc7f7d8..07f5c702 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13258&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13258&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13258.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13258/head:pull/13258 PR: https://git.openjdk.org/jdk/pull/13258 From rriggs at openjdk.org Sat Apr 8 18:00:53 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Sat, 8 Apr 2023 18:00:53 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v9] In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: > Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. > The enumeration values are defined to match those used in the build. > The initial values are: `X64, X86, IA64, ARM, AARCH64, RISCV64, S390X, PPC64LE` > Note that `amd64` and `x86_64` in the build are represented by `X64`. > The values of the system property `os.arch` is unchanged. > > The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). > Uses in `java.base` and a few others are included but other modules will be done in separate PRs. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Remove unused static and import of Stabile ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13357/files - new: https://git.openjdk.org/jdk/pull/13357/files/53c20c77..f3646dc9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=07-08 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13357/head:pull/13357 PR: https://git.openjdk.org/jdk/pull/13357 From alanb at openjdk.org Mon Apr 10 13:55:43 2023 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 10 Apr 2023 13:55:43 GMT Subject: RFR: 8305761: Resolve multiple definition of 'jvm' when statically linking with JDK native libraries In-Reply-To: References: Message-ID: On Sat, 8 Apr 2023 01:11:08 GMT, Jiangli Zhou wrote: > Rename various 'jvm' variables to 'jvm_' to avoid duplicate symbol problems when statically linking the launcher executable with JDK native libraries. src/java.management/share/native/libmanagement/management.c line 36: > 34: const JmmInterface* jmm_interface = NULL; > 35: JavaVM* jvm_management = NULL; > 36: jint jmm_version = 0; Is there any reason why these field can't be static? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13397#discussion_r1161738529 From sspitsyn at openjdk.org Mon Apr 10 18:53:04 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 10 Apr 2023 18:53:04 GMT Subject: RFR: 8277573: VmObjectAlloc is not generated by intrinsics methods which allocate objects In-Reply-To: References: Message-ID: On Mon, 3 Apr 2023 22:20:43 GMT, Leonid Mesnik wrote: > Updated VM internal object allocation C2 intrinsic to post jvmti events when needed. It looks pretty good. But I'd like to request a couple of changes. The `notify_allocation` sounds to generic. What about to replace it with `notify_jvmti_vm_object_alloc`? I'll post another request separately. src/hotspot/share/opto/library_call.cpp line 2856: > 2854: set_result(ideal.value(result)); > 2855: return true; > 2856: #else Nit: It is better to replace #else at 2856 with #endif. Then #endif at 2859 is not needed. ------------- Changes requested by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13312#pullrequestreview-1377960281 PR Review Comment: https://git.openjdk.org/jdk/pull/13312#discussion_r1161981967 From sspitsyn at openjdk.org Mon Apr 10 19:00:58 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 10 Apr 2023 19:00:58 GMT Subject: RFR: 8277573: VmObjectAlloc is not generated by intrinsics methods which allocate objects In-Reply-To: References: Message-ID: On Mon, 3 Apr 2023 22:20:43 GMT, Leonid Mesnik wrote: > Updated VM internal object allocation C2 intrinsic to post jvmti events when needed. src/hotspot/share/prims/jvmtiEventController.cpp line 727: > 725: JvmtiExport::set_should_post_on_exceptions((any_env_thread_enabled & SHOULD_POST_ON_EXCEPTIONS_BITS) != 0); > 726: > 727: JvmtiExport::_should_post_allocation_notifications = JvmtiExport::should_post_vm_object_alloc(); I'm not sure why this flag is needed. It looks like a dup of `JvmtiExport::should_post_vm_object_alloc()`. Can we just replace it with `JvmtiExport::should_post_vm_object_alloc()`? test/hotspot/jtreg/ProblemList-Xcomp.txt line 41: > 39: serviceability/sa/TestJhsdbJstackMixed.java 8248675 linux-aarch64 > 40: > 41: serviceability/jvmti/VMObjectAlloc/VMObjectAllocTest.java 8288430 generic-all If the 8288430 is a dup of 8277573 then should we close it as such? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13312#discussion_r1161989234 PR Review Comment: https://git.openjdk.org/jdk/pull/13312#discussion_r1161990486 From jiangli at openjdk.org Mon Apr 10 19:22:50 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 10 Apr 2023 19:22:50 GMT Subject: RFR: 8305761: Resolve multiple definition of 'jvm' when statically linking with JDK native libraries In-Reply-To: References: Message-ID: On Mon, 10 Apr 2023 13:52:39 GMT, Alan Bateman wrote: >> Rename various 'jvm' variables to 'jvm_' to avoid duplicate symbol problems when statically linking the launcher executable with JDK native libraries. > > src/java.management/share/native/libmanagement/management.c line 36: > >> 34: const JmmInterface* jmm_interface = NULL; >> 35: JavaVM* jvm_management = NULL; >> 36: jint jmm_version = 0; > > Is there any reason why these field can't be static? Thanks. My understanding is that 'static' gives internal linkage. The static variable is limited to the scope of the translate unit that declares it. It seems to be okay to use 'static' for the 'jvm' variables in [management.c](https://github.com/openjdk/jdk/pull/13397/files/0fa6a4b3984d91c124ee2adb9d6e1facdc63c156#diff-1717ac36c4bbefab688a4e75104417bec3687f78108096c2cca3af4ee552ab11) and [management_ext.c](https://github.com/openjdk/jdk/pull/13397/files#diff-0fa91a6686c9e5dc77bdef6981235785524108950075e58d2004853dc66e1977) to resolve the symbol issue. It's problematic for the usages in jdk.crypto.cryptoki code. I'll change management.c and management_ext.c to define 'jvm' as 'static' as suggested. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13397#discussion_r1162008444 From jiangli at openjdk.org Mon Apr 10 19:38:18 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 10 Apr 2023 19:38:18 GMT Subject: RFR: 8305761: Resolve multiple definition of 'jvm' when statically linking with JDK native libraries [v2] In-Reply-To: References: Message-ID: <1g3QgTxTpw20iuTgUcEWiuvXSiz6IwOv0BkO7zemPiY=.d5578ff1-eaa3-44c5-b08e-201e122d3c1d@github.com> > Rename various 'jvm' variables to 'jvm_' to avoid duplicate symbol problems when statically linking the launcher executable with JDK native libraries. Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: Update management.c and management_ext.c to define 'jvm' as static. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13397/files - new: https://git.openjdk.org/jdk/pull/13397/files/0fa6a4b3..40b1a82a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13397&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13397&range=00-01 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13397.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13397/head:pull/13397 PR: https://git.openjdk.org/jdk/pull/13397 From lmesnik at openjdk.org Mon Apr 10 22:07:38 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 10 Apr 2023 22:07:38 GMT Subject: RFR: 8277573: VmObjectAlloc is not generated by intrinsics methods which allocate objects In-Reply-To: References: Message-ID: On Mon, 10 Apr 2023 18:46:42 GMT, Serguei Spitsyn wrote: >> Updated VM internal object allocation C2 intrinsic to post jvmti events when needed. > > src/hotspot/share/opto/library_call.cpp line 2856: > >> 2854: set_result(ideal.value(result)); >> 2855: return true; >> 2856: #else > > Nit: It is better to replace #else at 2856 with #endif. Then #endif at 2859 is not needed. In this case the code is: ``` set_result(ideal.value(result)); return true; set_result(obj); return true; Which might cause compiler warnings and complains from static analyzers. > src/hotspot/share/prims/jvmtiEventController.cpp line 727: > >> 725: JvmtiExport::set_should_post_on_exceptions((any_env_thread_enabled & SHOULD_POST_ON_EXCEPTIONS_BITS) != 0); >> 726: >> 727: JvmtiExport::_should_post_allocation_notifications = JvmtiExport::should_post_vm_object_alloc(); > > I'm not sure why this flag is needed. It looks like a dup of `JvmtiExport::should_post_vm_object_alloc()`. > Can we just replace it with `JvmtiExport::should_post_vm_object_alloc()`? I don't think we could replace it by function. Also, I think that it is needed later to add SampledObjectAlloc event here. It should consider VM internal object allocations along with all allocations. > test/hotspot/jtreg/ProblemList-Xcomp.txt line 41: > >> 39: serviceability/sa/TestJhsdbJstackMixed.java 8248675 linux-aarch64 >> 40: >> 41: serviceability/jvmti/VMObjectAlloc/VMObjectAllocTest.java 8288430 generic-all > > If the 8288430 is a dup of 8277573 then should we close it as such? Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13312#discussion_r1162123421 PR Review Comment: https://git.openjdk.org/jdk/pull/13312#discussion_r1162124409 PR Review Comment: https://git.openjdk.org/jdk/pull/13312#discussion_r1162124580 From sspitsyn at openjdk.org Tue Apr 11 00:00:36 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 11 Apr 2023 00:00:36 GMT Subject: RFR: 8277573: VmObjectAlloc is not generated by intrinsics methods which allocate objects In-Reply-To: References: Message-ID: On Mon, 10 Apr 2023 22:02:10 GMT, Leonid Mesnik wrote: >> src/hotspot/share/opto/library_call.cpp line 2856: >> >>> 2854: set_result(ideal.value(result)); >>> 2855: return true; >>> 2856: #else >> >> Nit: It is better to replace #else at 2856 with #endif. Then #endif at 2859 is not needed. > > In this case the code is: > ``` > set_result(ideal.value(result)); > return true; > set_result(obj); > return true; > > > Which might cause compiler warnings and complains from static analyzers. I wonder if it possible to do the following: + . . . . . . . + final_sync(ideal); + obj = ideal.value(result); + return true; + #endif // INCLUDE_JVMTI set_result(obj); return true; But I'm not sure if one more sync is needed in such a case. At lease, this line should not be under #if/#else: ` return true;` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13312#discussion_r1162175803 From sspitsyn at openjdk.org Tue Apr 11 00:00:39 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 11 Apr 2023 00:00:39 GMT Subject: RFR: 8277573: VmObjectAlloc is not generated by intrinsics methods which allocate objects In-Reply-To: References: Message-ID: On Mon, 3 Apr 2023 22:20:43 GMT, Leonid Mesnik wrote: > Updated VM internal object allocation C2 intrinsic to post jvmti events when needed. src/hotspot/share/prims/jvmtiExport.cpp line 1050: > 1048: > 1049: // This flag is read by C2 during VM internal objects allocation > 1050: bool JvmtiExport::_should_post_allocation_notifications = true; Needs to be initialized with `false`. src/hotspot/share/prims/jvmtiExport.hpp line 400: > 398: > 399: // Used by C2 to post vm_object_alloc > 400: static bool _should_post_allocation_notifications; As we privately discussed, consider replacing it with something like: `_should_notify_vm_object_alloc`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13312#discussion_r1162176341 PR Review Comment: https://git.openjdk.org/jdk/pull/13312#discussion_r1162177316 From sspitsyn at openjdk.org Tue Apr 11 00:12:38 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 11 Apr 2023 00:12:38 GMT Subject: RFR: 8277573: VmObjectAlloc is not generated by intrinsics methods which allocate objects In-Reply-To: References: Message-ID: On Mon, 10 Apr 2023 22:03:56 GMT, Leonid Mesnik wrote: >> src/hotspot/share/prims/jvmtiEventController.cpp line 727: >> >>> 725: JvmtiExport::set_should_post_on_exceptions((any_env_thread_enabled & SHOULD_POST_ON_EXCEPTIONS_BITS) != 0); >>> 726: >>> 727: JvmtiExport::_should_post_allocation_notifications = JvmtiExport::should_post_vm_object_alloc(); >> >> I'm not sure why this flag is needed. It looks like a dup of `JvmtiExport::should_post_vm_object_alloc()`. >> Can we just replace it with `JvmtiExport::should_post_vm_object_alloc()`? > > I don't think we could replace it by function. Also, I think that it is needed later to add SampledObjectAlloc event here. It should consider VM internal object allocations along with all allocations. I was thinking about an offset. But I've got your plan to use this flag for both `VMObjectAlloc` and `SampledObjectAlloc` event types. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13312#discussion_r1162181763 From lmesnik at openjdk.org Tue Apr 11 01:05:49 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 11 Apr 2023 01:05:49 GMT Subject: RFR: 8277573: VmObjectAlloc is not generated by intrinsics methods which allocate objects [v2] In-Reply-To: References: Message-ID: > Updated VM internal object allocation C2 intrinsic to post jvmti events when needed. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: fixed after Sergey's comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13312/files - new: https://git.openjdk.org/jdk/pull/13312/files/9d13e058..82aa5d93 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13312&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13312&range=00-01 Stats: 23 lines in 9 files changed: 0 ins; 4 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/13312.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13312/head:pull/13312 PR: https://git.openjdk.org/jdk/pull/13312 From lmesnik at openjdk.org Tue Apr 11 01:05:51 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 11 Apr 2023 01:05:51 GMT Subject: RFR: 8277573: VmObjectAlloc is not generated by intrinsics methods which allocate objects In-Reply-To: References: Message-ID: On Mon, 3 Apr 2023 22:20:43 GMT, Leonid Mesnik wrote: > Updated VM internal object allocation C2 intrinsic to post jvmti events when needed. I have simplified #if #else #endif and renamed functions and variables. Also, changed _should_notify_object_alloc default value to false. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13312#issuecomment-1502535015 From dholmes at openjdk.org Tue Apr 11 03:09:36 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 11 Apr 2023 03:09:36 GMT Subject: RFR: 8299414: JVMTI FollowReferences should support references from VirtualThread stack [v5] In-Reply-To: References: <6oQOD_egcB3HyuagMWGSPLjKSE3JkaI2K2WOsDK1Cww=.c568223b-5100-4425-a4b7-defbd812a9ff@github.com> Message-ID: On Fri, 7 Apr 2023 04:51:36 GMT, Alex Menkov wrote: >> The fix updates JVMTI FollowReferences implementation to report references from virtual threads: >> - added heap scanning to report unmounted vthreads; >> - stacks of mounted vthreads are splitted into 2 parts (vittual thread stack and carrier thread stack), references are reported with correct thread id/class and object tags/frame depth; >> - common code to handle stack frames are moved into separate class; > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > Use atomic for synchronization Seems to me the bug report is asking for unmounted virtual threads to be considered roots - but virtual threads are deliberately not roots. Any unmounted virtual thread should be reachable from either the scheduler or whatever object the VT is parked on, so if they are not showing up then perhaps the wrong reference is being followed. If there is a bug/missing-functionality in the FollowReferences implementation then fixing it is of course fine, but that is not what the bug report seems to be about. ??? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13254#issuecomment-1502624570 From sspitsyn at openjdk.org Tue Apr 11 04:16:37 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 11 Apr 2023 04:16:37 GMT Subject: RFR: 8277573: VmObjectAlloc is not generated by intrinsics methods which allocate objects [v2] In-Reply-To: References: Message-ID: On Tue, 11 Apr 2023 01:05:49 GMT, Leonid Mesnik wrote: >> Updated VM internal object allocation C2 intrinsic to post jvmti events when needed. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > fixed after Sergey's comments Thank you for the update& Looks good now. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13312#pullrequestreview-1378422184 From kvn at openjdk.org Tue Apr 11 04:32:35 2023 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 11 Apr 2023 04:32:35 GMT Subject: RFR: 8277573: VmObjectAlloc is not generated by intrinsics methods which allocate objects [v2] In-Reply-To: References: Message-ID: On Tue, 11 Apr 2023 01:05:49 GMT, Leonid Mesnik wrote: >> Updated VM internal object allocation C2 intrinsic to post jvmti events when needed. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > fixed after Sergey's comments Update looks good to me. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13312#pullrequestreview-1378431164 From alanb at openjdk.org Tue Apr 11 05:53:57 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 11 Apr 2023 05:53:57 GMT Subject: Integrated: 8304919: Implementation of Virtual Threads In-Reply-To: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com> References: <5i_MXEpA1DKDXRb40oNKuNkO8Lx5cxVGAi2cd0xQB8s=.f7c43207-d81a-4a75-89d2-a2877269d5f9@github.com> Message-ID: On Tue, 28 Mar 2023 07:28:01 GMT, Alan Bateman wrote: > JEP 444 proposes to make virtual threads a permanent feature in Java 21. The APIs that were preview APIs in Java 19/20 are changed to permanent and their `@since`/equivalent are changed to 21 (as per the guidance in JEP 12). The JNI and JVMTI versions are bumped as this is the first change in 21 to need the new version number. A lot of tests are updated to drop `@enablePreview` and --enable-preview. > > There is one API change from Java 19/20, the preview API Thread.Builder.allowSetThreadLocals(boolean) is dropped. This requires an update to the JVMTI GetThreadInfo implementation to read the TCCL consistently. > > In addition, there are a small number of implementation changes to sync up from the loom fibers branch: > > - A number of stack frames are `@Hidden` to reduce noise in the stack traces. This exposed a few issues with the stack walker code. More specifically, the cases where end of a continuation falls precisely at the end of the batch, or where the remaining frames are hidden, weren't handled correctly. > - The code to emit the JFR jdk.ThreadSleepEvent is refactored so it's in Thread rather than in two classes. > - A few robustness improvements for OOME and SOE. There is more to do here, for future PRs. > - New system property to print a stack trace when a virtual thread sets its own value of a TL. > - ThreadPerTaskExecutor is changed to use FutureTask. > > Testing: tier1-6. This pull request has now been integrated. Changeset: 2586f361 Author: Alan Bateman URL: https://git.openjdk.org/jdk/commit/2586f36120317cd206464b1e79d3906f711487cb Stats: 2275 lines in 206 files changed: 903 ins; 866 del; 506 mod 8304919: Implementation of Virtual Threads Reviewed-by: lmesnik, cjplummer, psandoz, mchung, sspitsyn, jpai ------------- PR: https://git.openjdk.org/jdk/pull/13203 From dholmes at openjdk.org Tue Apr 11 06:30:35 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 11 Apr 2023 06:30:35 GMT Subject: RFR: 8304834: Fix wrapper insertion in TestScaffold.parseArgs(String args[]) [v3] In-Reply-To: References: <7PDwD7zFu8CYojj6LDm0qVMlVHKuJNmAzxKaWdjGuvY=.cf39e296-777b-4653-bc19-7276a7da28e8@github.com> Message-ID: On Fri, 7 Apr 2023 19:01:34 GMT, Leonid Mesnik wrote: >> The TestScaffold incorrectly parse options, it should insert wrapper class between VM options and applications classame. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > updated parsing. A small nit but otherwise the new approach to parsing args now seems complete/consistent. Thanks. test/jdk/com/sun/jdi/TestScaffold.java line 478: > 476: // The result with wrapper enabled: > 477: // argInfo.targetAppCommandLine : TestScaffold Virtual Frames2Targ > 478: // argInfo.targetVMArgs : -Xss4M --enable-preview This example may need updating now virtual threads are no longer in preview mode. test/jdk/com/sun/jdi/TestScaffold.java line 501: > 499: } else if (arg.startsWith("-J")) { > 500: argInfo.targetVMArgs += (arg.substring(2) + ' '); > 501: throw new RuntimeException("-J-option is not supported. Incorrect arg: " + args[i]); Shouldn't line 500 be deleted now and the exception just print `arg`? ------------- PR Review: https://git.openjdk.org/jdk/pull/13170#pullrequestreview-1378508428 PR Review Comment: https://git.openjdk.org/jdk/pull/13170#discussion_r1162352554 PR Review Comment: https://git.openjdk.org/jdk/pull/13170#discussion_r1162341404 From mdoerr at openjdk.org Tue Apr 11 10:18:44 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 11 Apr 2023 10:18:44 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v9] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Sat, 8 Apr 2023 18:00:53 GMT, Roger Riggs wrote: >> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. >> The enumeration values are defined to match those used in the build. >> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64` >> Note that `amd64` and `x86_64` in the build are represented by `X64`. >> The value of the system property `os.arch` is unchanged. >> >> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). >> Uses in `java.base` and a few others are included but other modules will be done in separate PRs. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused static and import of Stabile Would be great if you could support "os.arch = ppc64" for AIX and legacy linux, too. test/jdk/jdk/internal/util/ArchTest.java line 128: > 126: case RISCV64 -> true; > 127: case S390 -> false; > 128: case PPC64 -> true; This is not always true. The PPC64 architecture supports both endianness versions. AIX and legacy linux is Big Endian while recent linux is little Endian (determined by platform name "os.arch = ppc64le" instead of "os.arch = ppc64"). Querying the endianness is also possible, of course. ------------- Changes requested by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13357#pullrequestreview-1378905956 PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1162600674 From duke at openjdk.org Tue Apr 11 10:27:27 2023 From: duke at openjdk.org (Afshin Zafari) Date: Tue, 11 Apr 2023 10:27:27 GMT Subject: RFR: 8305084: Remove finalize() from test/hotspot/jtreg/serviceability/dcmd/gc/ that are used in serviceability/dcmd/gc/ Message-ID: The `removal` warnings are suppressed out. Test: `FinalizerInfoTest` and `RunFinalizationTest` are executed locally. ------------- Commit messages: - 8305084: Remove finalize() from test/hotspot/jtreg/serviceability/dcmd/gc/ that are used in serviceability/dcmd/gc/ Changes: https://git.openjdk.org/jdk/pull/13423/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13423&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8305084 Stats: 4 lines in 2 files changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13423.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13423/head:pull/13423 PR: https://git.openjdk.org/jdk/pull/13423 From duke at openjdk.org Tue Apr 11 10:29:43 2023 From: duke at openjdk.org (ExE Boss) Date: Tue, 11 Apr 2023 10:29:43 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v9] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Tue, 11 Apr 2023 10:15:27 GMT, Martin Doerr wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unused static and import of Stabile > > test/jdk/jdk/internal/util/ArchTest.java line 128: > >> 126: case RISCV64 -> true; >> 127: case S390 -> false; >> 128: case PPC64 -> true; > > This is not always true. The PPC64 architecture supports both endianness versions. AIX and legacy linux is Big Endian while recent linux is little Endian (determined by platform name "os.arch = ppc64le" instead of "os.arch = ppc64"). Querying the endianness is also possible, of course. This?should (probably) be?correct: Suggestion: case PPC64 -> !OperatingSystem.isAix() && Architecture.isLittleEndian(); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1162614588 From mdoerr at openjdk.org Tue Apr 11 10:42:41 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 11 Apr 2023 10:42:41 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v9] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Tue, 11 Apr 2023 10:26:02 GMT, ExE Boss wrote: >> test/jdk/jdk/internal/util/ArchTest.java line 128: >> >>> 126: case RISCV64 -> true; >>> 127: case S390 -> false; >>> 128: case PPC64 -> true; >> >> This is not always true. The PPC64 architecture supports both endianness versions. AIX and legacy linux is Big Endian while recent linux is little Endian (determined by platform name "os.arch = ppc64le" instead of "os.arch = ppc64"). Querying the endianness is also possible, of course. > > This?should (probably) be?correct: > Suggestion: > > case PPC64 -> !OperatingSystem.isAix() && Architecture.isLittleEndian(); Looks correct, but makes the test pointless for any linux on PPC64. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1162628828 From dholmes at openjdk.org Tue Apr 11 11:00:34 2023 From: dholmes at openjdk.org (David Holmes) Date: Tue, 11 Apr 2023 11:00:34 GMT Subject: RFR: 8305084: Remove finalize() from test/hotspot/jtreg/serviceability/dcmd/gc/ that are used in serviceability/dcmd/gc/ In-Reply-To: References: Message-ID: On Tue, 11 Apr 2023 10:20:25 GMT, Afshin Zafari wrote: > The `removal` warnings are suppressed out. > Test: > `FinalizerInfoTest` and `RunFinalizationTest` are executed locally. Suppression of warning is fine but the bug synopsis (and so PR title) needs to be updated to reflect what is actually happening here. And the bug title doesn't really make sense anyway - why is the test location given twice ?? Thanks test/hotspot/jtreg/serviceability/dcmd/gc/FinalizationRunner.java line 2: > 1: /* > 2: * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved. Copyright change is wrong - should be "2015, 2023," ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13423#pullrequestreview-1378979810 PR Review Comment: https://git.openjdk.org/jdk/pull/13423#discussion_r1162643632 From alanb at openjdk.org Tue Apr 11 11:07:33 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 11 Apr 2023 11:07:33 GMT Subject: RFR: 8305761: Resolve multiple definition of 'jvm' when statically linking with JDK native libraries [v2] In-Reply-To: <1g3QgTxTpw20iuTgUcEWiuvXSiz6IwOv0BkO7zemPiY=.d5578ff1-eaa3-44c5-b08e-201e122d3c1d@github.com> References: <1g3QgTxTpw20iuTgUcEWiuvXSiz6IwOv0BkO7zemPiY=.d5578ff1-eaa3-44c5-b08e-201e122d3c1d@github.com> Message-ID: On Mon, 10 Apr 2023 19:38:18 GMT, Jiangli Zhou wrote: >> Rename various 'jvm' variables to 'jvm_' to avoid duplicate symbol problems when statically linking the launcher executable with JDK native libraries. > > Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: > > Update management.c and management_ext.c to define 'jvm' as static. Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13397#pullrequestreview-1378993775 From stefank at openjdk.org Tue Apr 11 11:39:17 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 11 Apr 2023 11:39:17 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v56] In-Reply-To: References: Message-ID: On Thu, 6 Apr 2023 11:59:45 GMT, Roman Kennke wrote: >> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). >> >> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. >> >> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal protocols. >> >> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare. >> >> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. >> >> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. >> >> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. >> >> This change enables to simplify (and speed-up!) a lot of code: >> >> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. >> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR >> >> Also, and I might be mistaken here, this new lightweight locking would make synchronized work better with Loom: Because the lock-records are no longer scattered across the stack, but instead are densely packed into the lock-stack, it should be easy for a vthread to save its lock-stack upon unmounting and restore it when re-mounting. However, I am not sure about this, and this PR does not attempt to implement that support. >> >> Testing: >> - [x] tier1 x86_64 x aarch64 x +UseFastLocking >> - [x] tier2 x86_64 x aarch64 x +UseFastLocking >> - [x] tier3 x86_64 x aarch64 x +UseFastLocking >> - [x] tier4 x86_64 x aarch64 x +UseFastLocking >> - [x] tier1 x86_64 x aarch64 x -UseFastLocking >> - [x] tier2 x86_64 x aarch64 x -UseFastLocking >> - [x] tier3 x86_64 x aarch64 x -UseFastLocking >> - [x] tier4 x86_64 x aarch64 x -UseFastLocking >> - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet >> >> ### Performance >> >> #### Simple Microbenchmark >> >> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops. >> >> | | x86_64 | aarch64 | >> | -- | -- | -- | >> | -UseFastLocking | 20.651 | 20.764 | >> | +UseFastLocking | 18.896 | 18.908 | >> >> >> #### Renaissance >> >> ? | x86_64 | ? | ? | ? | aarch64 | ? | ? >> -- | -- | -- | -- | -- | -- | -- | -- >> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? >> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% >> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21% >> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% >> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% >> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% >> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% >> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%% >> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% >> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% >> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% >> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% >> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34% >> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% >> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% >> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% >> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% >> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% >> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% >> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% >> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% >> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > RISCV update Changes requested by stefank (Reviewer). src/hotspot/share/runtime/lockStack.inline.hpp line 111: > 109: int end = to_index(_top); > 110: for (int i = end - 1; i >= 0; i--) { > 111: if (NativeAccess<>::oop_load(&_base[i]) == o) { The use of NativeAccess here will break Generational ZGC. For other GCs it's just a redundant GC barrier. The actual GC barrier for the oops in the thread header is the start_processing() call. I was going to propose that you changed this to a plain load (as opposed to using RawAccess), but @fisk pointed out that it looks like this code is used from one thread looking into the data structures of another thread, which would make such a load potentially racing. And that makes us also question the plain load of `_top`. Is there anything that ensures that these are not racy loads? ------------- PR Review: https://git.openjdk.org/jdk/pull/10907#pullrequestreview-1379038780 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1162681920 From rkennke at openjdk.org Tue Apr 11 11:51:21 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 11 Apr 2023 11:51:21 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v56] In-Reply-To: References: Message-ID: On Tue, 11 Apr 2023 11:36:10 GMT, Stefan Karlsson wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> RISCV update > > src/hotspot/share/runtime/lockStack.inline.hpp line 111: > >> 109: int end = to_index(_top); >> 110: for (int i = end - 1; i >= 0; i--) { >> 111: if (NativeAccess<>::oop_load(&_base[i]) == o) { > > The use of NativeAccess here will break Generational ZGC. For other GCs it's just a redundant GC barrier. The actual GC barrier for the oops in the thread header is the start_processing() call. > > I was going to propose that you changed this to a plain load (as opposed to using RawAccess), but @fisk pointed out that it looks like this code is used from one thread looking into the data structures of another thread, which would make such a load potentially racing. And that makes us also question the plain load of `_top`. Is there anything that ensures that these are not racy loads? The NativeAccess is a left-over from an earlier attempt, and yes I think the start_processing() is the actual barrier. There is a single call-path where we inspect another thread's lock-stack outside of a safepoint (from management/JMX code). We had some arguments back and forth with David about that (somewhere up in this PR) and the conclusion so far is that yes, it is racy, but it doesn't seem to be a problem. We might be getting wrong results in the sense that the other thread could change the state of locking in the moment right after we inspect it, but this doesn't look like a correctness problem in the code that's calling it and the problem is pre-existing with current stack-locking, too. See jmm_GetThreadInfo() in management.cpp around lines 1129ff. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1162692775 From duke at openjdk.org Tue Apr 11 11:53:42 2023 From: duke at openjdk.org (Glavo) Date: Tue, 11 Apr 2023 11:53:42 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v9] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Sat, 8 Apr 2023 18:00:53 GMT, Roger Riggs wrote: >> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. >> The enumeration values are defined to match those used in the build. >> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64` >> Note that `amd64` and `x86_64` in the build are represented by `X64`. >> The value of the system property `os.arch` is unchanged. >> >> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). >> Uses in `java.base` and a few others are included but other modules will be done in separate PRs. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused static and import of Stabile src/java.base/share/classes/jdk/internal/util/PlatformProps.java.template line 68: > 66: // The variables are named to match the Architecture value names, and > 67: // the values are named to match the build variables. > 68: static final boolean TARGET_ARCH_IS_X64 = "@@OPENJDK_TARGET_CPU@@" == "x86_64"; Would it be better to rename the enum entry to `X86_64`? I personally prefer the name x86-64 because I feel it is more regular than x64.. src/java.base/share/classes/jdk/internal/util/PlatformProps.java.template line 82: > 80: private static Architecture initArch(String archName) { > 81: try { > 82: String mapped = switch (archName) { How about mapping names in the build script instead of at runtime? I suggest placing only the mapped arch name in `PlatformProps` and moving the `CURRENT_ARCH` to `Architecture`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1162686875 PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1162695586 From duke at openjdk.org Tue Apr 11 12:07:32 2023 From: duke at openjdk.org (Afshin Zafari) Date: Tue, 11 Apr 2023 12:07:32 GMT Subject: RFR: 8305084: Remove the removal warnings for finalize() from test/hotspot/jtreg/serviceability/dcmd/gc/FinalizerInfoTest.java and RunFinalizationTest.java [v2] In-Reply-To: References: Message-ID: > The `removal` warnings are suppressed out. > Test: > `FinalizerInfoTest` and `RunFinalizationTest` are executed locally. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: Remove the removal warnings for finalize() from test/hotspot/jtreg/serviceability/dcmd/gc/FinalizerInfoTest.java and RunFinalizationTest.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13423/files - new: https://git.openjdk.org/jdk/pull/13423/files/e0708596..ac504f49 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13423&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13423&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13423.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13423/head:pull/13423 PR: https://git.openjdk.org/jdk/pull/13423 From duke at openjdk.org Tue Apr 11 12:08:33 2023 From: duke at openjdk.org (Afshin Zafari) Date: Tue, 11 Apr 2023 12:08:33 GMT Subject: RFR: 8305084: Remove the removal warnings for finalize() from test/hotspot/jtreg/serviceability/dcmd/gc/FinalizerInfoTest.java and RunFinalizationTest.java [v2] In-Reply-To: References: Message-ID: On Tue, 11 Apr 2023 10:57:34 GMT, David Holmes wrote: > Suppression of warning is fine but the bug synopsis (and so PR title) needs to be updated to reflect what is actually happening here. And the bug title doesn't really make sense anyway - why is the test location given twice ?? Bug and PR titles are changed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13423#issuecomment-1503210782 From stefank at openjdk.org Tue Apr 11 12:18:34 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 11 Apr 2023 12:18:34 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v56] In-Reply-To: References: Message-ID: On Tue, 11 Apr 2023 11:47:46 GMT, Roman Kennke wrote: >> src/hotspot/share/runtime/lockStack.inline.hpp line 111: >> >>> 109: int end = to_index(_top); >>> 110: for (int i = end - 1; i >= 0; i--) { >>> 111: if (NativeAccess<>::oop_load(&_base[i]) == o) { >> >> The use of NativeAccess here will break Generational ZGC. For other GCs it's just a redundant GC barrier. The actual GC barrier for the oops in the thread header is the start_processing() call. >> >> I was going to propose that you changed this to a plain load (as opposed to using RawAccess), but @fisk pointed out that it looks like this code is used from one thread looking into the data structures of another thread, which would make such a load potentially racing. And that makes us also question the plain load of `_top`. Is there anything that ensures that these are not racy loads? > > The NativeAccess is a left-over from an earlier attempt, and yes I think the start_processing() is the actual barrier. There is a single call-path where we inspect another thread's lock-stack outside of a safepoint (from management/JMX code). We had some arguments back and forth with David about that (somewhere up in this PR) and the conclusion so far is that yes, it is racy, but it doesn't seem to be a problem. We might be getting wrong results in the sense that the other thread could change the state of locking in the moment right after we inspect it, but this doesn't look like a correctness problem in the code that's calling it and the problem is pre-existing with current stack-locking, too. See jmm_GetThreadInfo() in management.cpp around lines 1129ff. It looks to me like the code could read racingly read the element just above `_top`, which could contain a stale oop. If the address of the stale oop matches the address of `o` then `contains` would incorrectly return true. Did you consider rewriting the racing code to use thread-local handshakes to remove the race? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1162729676 From mgronlun at openjdk.org Tue Apr 11 12:36:43 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 11 Apr 2023 12:36:43 GMT Subject: RFR: 8257967: JFR: Events for loaded agents [v16] In-Reply-To: References: Message-ID: On Tue, 4 Apr 2023 14:39:19 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> We are adding support to let JFR report on Agents. >> >> #### Design >> >> An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize. >> >> A JavaAgent is an agent written in the Java programming language, using the APIs in the package [java.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html) >> >> A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services. >> >> To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples: >> >> // Command line >> jdk.JavaAgent { >> startTime = 12:31:19.789 (2023-03-08) >> name = "JavaAgent.jar" >> options = "foo=bar" >> dynamic = false >> initializationTime = 12:31:15.574 (2023-03-08) >> initializationDuration = 172 ms >> } >> >> // Dynamic load >> jdk.JavaAgent { >> startTime = 12:31:31.158 (2023-03-08) >> name = "JavaAgent.jar" >> options = "bar=baz" >> dynamic = true >> initializationTime = 12:31:31.037 (2023-03-08) >> initializationDuration = 64,1 ms >> } >> >> The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents. >> >> For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar. >> >> The "dynamic" field denotes if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true) >> >> "initializationTime" is the timestamp the JVM invoked the initialization method, and "initializationDuration" is the duration of executing the initialization method. >> >> "startTime" represents the time the JFR framework issued the periodic event; hence "initializationTime" will be earlier than "startTime". >> >> An agent can also be written in a native programming language using the [JVM Tools Interface (JVMTI)](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file. >> >> To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example: >> >> jdk.NativeAgent { >> startTime = 12:31:40.398 (2023-03-08) >> name = "jdwp" >> options = "transport=dt_socket,server=y,address=any,onjcmd=y" >> dynamic = false >> initializationTime = 12:31:36.142 (2023-03-08) >> initializationDuration = 0,00184 ms >> path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll" >> } >> >> The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported. >> >> The initialization of a native agent is performed by invoking an agent-specified callback routine. The "initializationTime" is when the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationDuration" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationDuration" will be 0. If the agent is loaded dynamically, "initializationDuration" is the time taken to execute the Agent_OnAttach callback. >> >> #### Implementation >> >> There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization ? as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before. >> >> Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize. >> >> When implementing this capability, it was necessary to refactor the code used to represent agents, AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp. >> >> The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp. >> >> The previous two lists that maintained "agents" (JVMTI) and "libraries" (Xrun) were not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced. >> >> Testing: jdk_jfr, tier 1 - 6 >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: > > renames Can I please get a second review to close this one out? Thanks Markus ------------- PR Comment: https://git.openjdk.org/jdk/pull/12923#issuecomment-1503245005 From rkennke at openjdk.org Tue Apr 11 13:50:22 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 11 Apr 2023 13:50:22 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v56] In-Reply-To: References: Message-ID: <2J4SoXF42zWujj5jjDllPGCHVLxuuT44tO-Oiz1PFNI=.a7bfa89d-3f4d-49b8-81ae-cd416cb5d263@github.com> On Tue, 11 Apr 2023 12:15:07 GMT, Stefan Karlsson wrote: >> The NativeAccess is a left-over from an earlier attempt, and yes I think the start_processing() is the actual barrier. There is a single call-path where we inspect another thread's lock-stack outside of a safepoint (from management/JMX code). We had some arguments back and forth with David about that (somewhere up in this PR) and the conclusion so far is that yes, it is racy, but it doesn't seem to be a problem. We might be getting wrong results in the sense that the other thread could change the state of locking in the moment right after we inspect it, but this doesn't look like a correctness problem in the code that's calling it and the problem is pre-existing with current stack-locking, too. See jmm_GetThreadInfo() in management.cpp around lines 1129ff. > > It looks to me like the code could read racingly read the element just above `_top`, which could contain a stale oop. If the address of the stale oop matches the address of `o` then `contains` would incorrectly return true. > > Did you consider rewriting the racing code to use thread-local handshakes to remove the race? Hmm you are right. But still - that problem is pre-existing, right? Consider this code in the current stack-locking implementation. If we don't stop the other thread, we may end up following a stack-pointer from the locked-object, and by the time we get to that stack-address, the thread may already have given up that lock and the stack-address could contain some other random stuff. Re-writing that code to do a handshake would be nice, but I don't think I want to include this in the scope of this PR. If you agree, I would file a separate issue to investigate the problem. As a band-aid, I could add a 'LockingMode == 2' to the if-statement in management.cpp as I already did it earlier: https://github.com/rkennke/jdk/blob/JDK-8291555-v2/src/hotspot/share/services/management.cpp#L1129. This would make all calls into LockStack::contains() happen at a safepoint or only by self-thread, and would certainly make me sleep a little better ;-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1162848799 From lmesnik at openjdk.org Tue Apr 11 13:58:51 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 11 Apr 2023 13:58:51 GMT Subject: Integrated: 8277573: VmObjectAlloc is not generated by intrinsics methods which allocate objects In-Reply-To: References: Message-ID: On Mon, 3 Apr 2023 22:20:43 GMT, Leonid Mesnik wrote: > Updated VM internal object allocation C2 intrinsic to post jvmti events when needed. This pull request has now been integrated. Changeset: 7a5597c3 Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/7a5597c34f3b52d8b7c44647bfdcdfac9301b483 Stats: 74 lines in 11 files changed: 65 ins; 5 del; 4 mod 8277573: VmObjectAlloc is not generated by intrinsics methods which allocate objects Reviewed-by: kvn, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/13312 From stefank at openjdk.org Tue Apr 11 14:06:21 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Tue, 11 Apr 2023 14:06:21 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v56] In-Reply-To: <2J4SoXF42zWujj5jjDllPGCHVLxuuT44tO-Oiz1PFNI=.a7bfa89d-3f4d-49b8-81ae-cd416cb5d263@github.com> References: <2J4SoXF42zWujj5jjDllPGCHVLxuuT44tO-Oiz1PFNI=.a7bfa89d-3f4d-49b8-81ae-cd416cb5d263@github.com> Message-ID: <78es_NBdhW3jSDDYRHU8wcmuV53gwrvd4SB5i6g2HC4=.b93cd4c4-f0ac-44e0-b36a-854ce2f0cfac@github.com> On Tue, 11 Apr 2023 13:48:15 GMT, Roman Kennke wrote: >> It looks to me like the code could read racingly read the element just above `_top`, which could contain a stale oop. If the address of the stale oop matches the address of `o` then `contains` would incorrectly return true. >> >> Did you consider rewriting the racing code to use thread-local handshakes to remove the race? > > Hmm you are right. But still - that problem is pre-existing, right? Consider this code in the current stack-locking implementation. If we don't stop the other thread, we may end up following a stack-pointer from the locked-object, and by the time we get to that stack-address, the thread may already have given up that lock and the stack-address could contain some other random stuff. > Re-writing that code to do a handshake would be nice, but I don't think I want to include this in the scope of this PR. If you agree, I would file a separate issue to investigate the problem. As a band-aid, I could add a 'LockingMode == 2' to the if-statement in management.cpp as I already did it earlier: https://github.com/rkennke/jdk/blob/JDK-8291555-v2/src/hotspot/share/services/management.cpp#L1129. This would make all calls into LockStack::contains() happen at a safepoint or only by self-thread, and would certainly make me sleep a little better ;-) OK. Given that I haven't looked at the rest of the patch, I leave it up to you and the Reviewers to figure out what to do about this code. Cheers. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1162872406 From kevinw at openjdk.org Tue Apr 11 14:12:36 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 11 Apr 2023 14:12:36 GMT Subject: RFR: 8305761: Resolve multiple definition of 'jvm' when statically linking with JDK native libraries [v2] In-Reply-To: <1g3QgTxTpw20iuTgUcEWiuvXSiz6IwOv0BkO7zemPiY=.d5578ff1-eaa3-44c5-b08e-201e122d3c1d@github.com> References: <1g3QgTxTpw20iuTgUcEWiuvXSiz6IwOv0BkO7zemPiY=.d5578ff1-eaa3-44c5-b08e-201e122d3c1d@github.com> Message-ID: On Mon, 10 Apr 2023 19:38:18 GMT, Jiangli Zhou wrote: >> Rename various 'jvm' variables to 'jvm_' to avoid duplicate symbol problems when statically linking the launcher executable with JDK native libraries. > > Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: > > Update management.c and management_ext.c to define 'jvm' as static. Marked as reviewed by kevinw (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13397#pullrequestreview-1379355549 From jiangli at openjdk.org Tue Apr 11 15:08:48 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 11 Apr 2023 15:08:48 GMT Subject: RFR: 8305761: Resolve multiple definition of 'jvm' when statically linking with JDK native libraries [v2] In-Reply-To: <1g3QgTxTpw20iuTgUcEWiuvXSiz6IwOv0BkO7zemPiY=.d5578ff1-eaa3-44c5-b08e-201e122d3c1d@github.com> References: <1g3QgTxTpw20iuTgUcEWiuvXSiz6IwOv0BkO7zemPiY=.d5578ff1-eaa3-44c5-b08e-201e122d3c1d@github.com> Message-ID: On Mon, 10 Apr 2023 19:38:18 GMT, Jiangli Zhou wrote: >> Rename various 'jvm' variables to 'jvm_' to avoid duplicate symbol problems when statically linking the launcher executable with JDK native libraries. > > Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: > > Update management.c and management_ext.c to define 'jvm' as static. Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13397#issuecomment-1503553861 From jiangli at openjdk.org Tue Apr 11 15:08:50 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 11 Apr 2023 15:08:50 GMT Subject: Integrated: 8305761: Resolve multiple definition of 'jvm' when statically linking with JDK native libraries In-Reply-To: References: Message-ID: <-x_vxEhdcSWFLhsFY6_gPE15yQueMwboKZUAkuY42tM=.33bf748a-cc6e-4b25-ba27-80c2267b8c98@github.com> On Sat, 8 Apr 2023 01:11:08 GMT, Jiangli Zhou wrote: > Rename various 'jvm' variables to 'jvm_' to avoid duplicate symbol problems when statically linking the launcher executable with JDK native libraries. This pull request has now been integrated. Changeset: ce4b9955 Author: Jiangli Zhou URL: https://git.openjdk.org/jdk/commit/ce4b9955568100d6b315336321ff8903b703f19e Stats: 34 lines in 5 files changed: 0 ins; 0 del; 34 mod 8305761: Resolve multiple definition of 'jvm' when statically linking with JDK native libraries Reviewed-by: alanb, kevinw ------------- PR: https://git.openjdk.org/jdk/pull/13397 From dcubed at openjdk.org Tue Apr 11 15:33:31 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 11 Apr 2023 15:33:31 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v56] In-Reply-To: <78es_NBdhW3jSDDYRHU8wcmuV53gwrvd4SB5i6g2HC4=.b93cd4c4-f0ac-44e0-b36a-854ce2f0cfac@github.com> References: <2J4SoXF42zWujj5jjDllPGCHVLxuuT44tO-Oiz1PFNI=.a7bfa89d-3f4d-49b8-81ae-cd416cb5d263@github.com> <78es_NBdhW3jSDDYRHU8wcmuV53gwrvd4SB5i6g2HC4=.b93cd4c4-f0ac-44e0-b36a-854ce2f0cfac@github.com> Message-ID: On Tue, 11 Apr 2023 14:04:17 GMT, Stefan Karlsson wrote: >> Hmm you are right. But still - that problem is pre-existing, right? Consider this code in the current stack-locking implementation. If we don't stop the other thread, we may end up following a stack-pointer from the locked-object, and by the time we get to that stack-address, the thread may already have given up that lock and the stack-address could contain some other random stuff. >> Re-writing that code to do a handshake would be nice, but I don't think I want to include this in the scope of this PR. If you agree, I would file a separate issue to investigate the problem. As a band-aid, I could add a 'LockingMode == 2' to the if-statement in management.cpp as I already did it earlier: https://github.com/rkennke/jdk/blob/JDK-8291555-v2/src/hotspot/share/services/management.cpp#L1129. This would make all calls into LockStack::contains() happen at a safepoint or only by self-thread, and would certainly make me sleep a little better ;-) > > OK. Given that I haven't looked at the rest of the patch, I leave it up to you and the Reviewers to figure out what to do about this code. Cheers. Given that the race with new lightweight locking is virtually the same as the race with legacy stack locking, please do not put back the 'LockingMode == 2' check which would make `jmm_GetThreadInfo()` calls slower with new lightweight locking than with legacy stack locking. Perhaps I'm not understanding the risk of what @stefank means with: It looks to me like the code could read racingly read the element just above _top, which could contain a stale oop. If the address of the stale oop matches the address of o then contains would incorrectly return true. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1162994635 From lmesnik at openjdk.org Tue Apr 11 16:55:42 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 11 Apr 2023 16:55:42 GMT Subject: RFR: 8304834: Fix wrapper insertion in TestScaffold.parseArgs(String args[]) [v4] In-Reply-To: <7PDwD7zFu8CYojj6LDm0qVMlVHKuJNmAzxKaWdjGuvY=.cf39e296-777b-4653-bc19-7276a7da28e8@github.com> References: <7PDwD7zFu8CYojj6LDm0qVMlVHKuJNmAzxKaWdjGuvY=.cf39e296-777b-4653-bc19-7276a7da28e8@github.com> Message-ID: > The TestScaffold incorrectly parse options, it should insert wrapper class between VM options and applications classame. Leonid Mesnik has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - updated after David's comments. - Merge branch 'master' of https://github.com/openjdk/jdk into 8289546 - updated parsing. - added comments and trim arguments - parsing updted - problemlist fixed - comments - fix ------------- Changes: https://git.openjdk.org/jdk/pull/13170/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13170&range=03 Stats: 52 lines in 3 files changed: 23 ins; 8 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/13170.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13170/head:pull/13170 PR: https://git.openjdk.org/jdk/pull/13170 From sspitsyn at openjdk.org Tue Apr 11 16:59:48 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 11 Apr 2023 16:59:48 GMT Subject: RFR: 8257967: JFR: Events for loaded agents [v16] In-Reply-To: References: Message-ID: On Tue, 11 Apr 2023 12:33:32 GMT, Markus Gr?nlund wrote: > Can I please get a second review to close this one out? Markus, I'm still working on it and close to finish. I have some questions to ask. In fact, I gave up to prove this refactoring does not break anything. So, we should rely on testing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12923#issuecomment-1503774347 From rriggs at openjdk.org Tue Apr 11 17:00:51 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 11 Apr 2023 17:00:51 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v9] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Tue, 11 Apr 2023 11:41:24 GMT, Glavo wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unused static and import of Stabile > > src/java.base/share/classes/jdk/internal/util/PlatformProps.java.template line 68: > >> 66: // The variables are named to match the Architecture value names, and >> 67: // the values are named to match the build variables. >> 68: static final boolean TARGET_ARCH_IS_X64 = "@@OPENJDK_TARGET_CPU@@" == "x86_64"; > > Would it be better to rename the enum entry to `X86_64`? I personally prefer the name x86-64 because I feel it is more regular than x64.. > Would be great if you could support "os.arch = ppc64" for AIX and legacy linux, too. Changing os.arch is out of scope for this PR. The best way for that would someone supporting ppc to develop and propose a PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1163098619 From mgronlun at openjdk.org Tue Apr 11 17:02:46 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 11 Apr 2023 17:02:46 GMT Subject: RFR: 8257967: JFR: Events for loaded agents [v16] In-Reply-To: References: Message-ID: On Tue, 11 Apr 2023 16:56:49 GMT, Serguei Spitsyn wrote: > > Can I please get a second review to close this one out? > > Markus, I'm still working on it and close to finish. I have some questions to ask. In fact, I gave up to prove this refactoring does not break anything. So, we should rely on testing. No worries, Serguei. Thank you for taking a look, please take your time. I have run tiers 1-6. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12923#issuecomment-1503779085 From rriggs at openjdk.org Tue Apr 11 17:14:41 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 11 Apr 2023 17:14:41 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v9] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: <0k8KcVp6piijYrt4MpxXyZzVIM_00uf_Zetj14jTBww=.c09aec26-1e32-4e0d-bf2c-8324b1c47a44@github.com> On Tue, 11 Apr 2023 10:39:39 GMT, Martin Doerr wrote: >> This?should (probably) be?correct: >> Suggestion: >> >> case PPC64 -> !OperatingSystem.isAix() && Architecture.isLittleEndian(); > > Looks correct, but makes the test pointless for any linux on PPC64. Will change to compare `isLittleEndian` with `!Unsafe.isBigEndian()`. The runtime must match the build time. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1163112421 From iklam at openjdk.org Tue Apr 11 17:42:31 2023 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 11 Apr 2023 17:42:31 GMT Subject: RFR: 8298048: Combine CDS archive heap into a single block In-Reply-To: References: Message-ID: On Sat, 8 Apr 2023 07:14:30 GMT, Thomas Stuefe wrote: > This looks like a nice simplification. Will you also combine all mappings at OS level to a single one, so that you only need one mmap call? Now there's a single call to mmap() in FileMapInfo::map_heap_regions_impl_inner(). This reminds me that I should remove the "s" from "heap_regions" in the function names. Will do that in my next commit. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13284#issuecomment-1503827701 From cjplummer at openjdk.org Tue Apr 11 17:43:41 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 11 Apr 2023 17:43:41 GMT Subject: RFR: 8304834: Fix wrapper insertion in TestScaffold.parseArgs(String args[]) [v4] In-Reply-To: References: <7PDwD7zFu8CYojj6LDm0qVMlVHKuJNmAzxKaWdjGuvY=.cf39e296-777b-4653-bc19-7276a7da28e8@github.com> Message-ID: On Tue, 11 Apr 2023 16:55:42 GMT, Leonid Mesnik wrote: >> The TestScaffold incorrectly parse options, it should insert wrapper class between VM options and applications classame. > > Leonid Mesnik has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - updated after David's comments. > - Merge branch 'master' of https://github.com/openjdk/jdk into 8289546 > - updated parsing. > - added comments and trim arguments > - parsing updted > - problemlist fixed > - comments > - fix Changes requested by cjplummer (Reviewer). test/jdk/com/sun/jdi/TestScaffold.java line 471: > 469: // Parse arguments, like java/j* tools command-line arguments > 470: // the first argument not-starting with '-' is treated as a classname > 471: // the other arguments are split to targetVMArgs targetAppCommandLine correspondingly Can you make these proper sentences with the first letter uppercase and a period at the end. test/jdk/com/sun/jdi/TestScaffold.java line 475: > 473: // The result without any wrapper enabled: > 474: // argInfo.targetAppCommandLine : Frames2Targ > 475: // argInfo.targetVMArgs : -Xss4M The 2 argInfo comments would be easier to read if indented 2 or 4 spaces (after the //, not before). test/jdk/com/sun/jdi/TestScaffold.java line 478: > 476: // The result with wrapper enabled: > 477: // argInfo.targetAppCommandLine : TestScaffold Virtual Frames2Targ > 478: // argInfo.targetVMArgs : -Xss4M The 2 argInfo comments would be easier to read if indented 2 or 4 spaces (after the //, not before). test/jdk/com/sun/jdi/TestScaffold.java line 500: > 498: redefineAsynchronously = true; > 499: } else if (arg.startsWith("-J")) { > 500: throw new RuntimeException("-J-option format is not supported. Incorrect arg: " + args[i]); David pointed out that you can use arg instead of args[i] here. ------------- PR Review: https://git.openjdk.org/jdk/pull/13170#pullrequestreview-1379784054 PR Review Comment: https://git.openjdk.org/jdk/pull/13170#discussion_r1163138251 PR Review Comment: https://git.openjdk.org/jdk/pull/13170#discussion_r1163138841 PR Review Comment: https://git.openjdk.org/jdk/pull/13170#discussion_r1163138984 PR Review Comment: https://git.openjdk.org/jdk/pull/13170#discussion_r1163137029 From lmesnik at openjdk.org Tue Apr 11 17:51:39 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 11 Apr 2023 17:51:39 GMT Subject: RFR: 8304834: Fix wrapper insertion in TestScaffold.parseArgs(String args[]) [v5] In-Reply-To: <7PDwD7zFu8CYojj6LDm0qVMlVHKuJNmAzxKaWdjGuvY=.cf39e296-777b-4653-bc19-7276a7da28e8@github.com> References: <7PDwD7zFu8CYojj6LDm0qVMlVHKuJNmAzxKaWdjGuvY=.cf39e296-777b-4653-bc19-7276a7da28e8@github.com> Message-ID: > The TestScaffold incorrectly parse options, it should insert wrapper class between VM options and applications classame. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: Updated comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13170/files - new: https://git.openjdk.org/jdk/pull/13170/files/e0a29a77..17f81d27 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13170&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13170&range=03-04 Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/13170.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13170/head:pull/13170 PR: https://git.openjdk.org/jdk/pull/13170 From rriggs at openjdk.org Tue Apr 11 17:58:54 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 11 Apr 2023 17:58:54 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v10] In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: > Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. > The enumeration values are defined to match those used in the build. > The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64` > Note that `amd64` and `x86_64` in the build are represented by `X64`. > The value of the system property `os.arch` is unchanged. > > The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). > Uses in `java.base` and a few others are included but other modules will be done in separate PRs. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Modified test to check Architecture is64bits() and isLittleEndian() against Unsafe respective values. Relocated code mapping OS name and arch name from PlatformProps to OperatingSystem and Architecture. Kept the mapping of names in the template close to where the values are filled in by the build. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13357/files - new: https://git.openjdk.org/jdk/pull/13357/files/f3646dc9..fc40270a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=08-09 Stats: 105 lines in 4 files changed: 46 ins; 41 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/13357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13357/head:pull/13357 PR: https://git.openjdk.org/jdk/pull/13357 From mdoerr at openjdk.org Tue Apr 11 18:04:49 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 11 Apr 2023 18:04:49 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v10] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Tue, 11 Apr 2023 17:58:54 GMT, Roger Riggs wrote: >> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. >> The enumeration values are defined to match those used in the build. >> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64` >> Note that `amd64` and `x86_64` in the build are represented by `X64`. >> The value of the system property `os.arch` is unchanged. >> >> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). >> Uses in `java.base` and a few others are included but other modules will be done in separate PRs. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Modified test to check Architecture is64bits() and isLittleEndian() > against Unsafe respective values. > Relocated code mapping OS name and arch name from PlatformProps to > OperatingSystem and Architecture. Kept the mapping of names > in the template close to where the values are filled in by the build. test/jdk/jdk/internal/util/ArchTest.java line 74: > 72: case "riscv64" -> RISCV64; // unverified > 73: case "s390x", "s390" -> S390; // unverified > 74: case "ppc64le" -> PPC64; // unverified I think "ppc64" should also get mapped to "PPC64". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1163161387 From mdoerr at openjdk.org Tue Apr 11 18:11:42 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 11 Apr 2023 18:11:42 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v10] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Tue, 11 Apr 2023 17:58:54 GMT, Roger Riggs wrote: >> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. >> The enumeration values are defined to match those used in the build. >> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64` >> Note that `amd64` and `x86_64` in the build are represented by `X64`. >> The value of the system property `os.arch` is unchanged. >> >> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). >> Uses in `java.base` and a few others are included but other modules will be done in separate PRs. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Modified test to check Architecture is64bits() and isLittleEndian() > against Unsafe respective values. > Relocated code mapping OS name and arch name from PlatformProps to > OperatingSystem and Architecture. Kept the mapping of names > in the template close to where the values are filled in by the build. Another remark: Old JDK on s390 used "os.arch = zArch_64", current one "os.arch = s390x". @offamitkumar: You probably want to take a look. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1503861585 From duke at openjdk.org Tue Apr 11 18:11:45 2023 From: duke at openjdk.org (ExE Boss) Date: Tue, 11 Apr 2023 18:11:45 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v10] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Tue, 11 Apr 2023 18:02:14 GMT, Martin Doerr wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Modified test to check Architecture is64bits() and isLittleEndian() >> against Unsafe respective values. >> Relocated code mapping OS name and arch name from PlatformProps to >> OperatingSystem and Architecture. Kept the mapping of names >> in the template close to where the values are filled in by the build. > > test/jdk/jdk/internal/util/ArchTest.java line 74: > >> 72: case "riscv64" -> RISCV64; // unverified >> 73: case "s390x", "s390" -> S390; // unverified >> 74: case "ppc64le" -> PPC64; // unverified > > I think "ppc64" should also get mapped to "PPC64". Suggestion: case "ppc64", "ppc64le" -> PPC64; // unverified ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1163166827 From jjg at openjdk.org Tue Apr 11 18:21:56 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Tue, 11 Apr 2023 18:21:56 GMT Subject: RFR: JDK-8305713: DocCommentParser: merge blockContent and inlineContent Message-ID: Please review a cleanup in DocCommentParser to merge blockContent and inlineContent into a single method to parse "rich content" in a doc comment. ------------- Depends on: https://git.openjdk.org/jdk/pull/13362 Commit messages: - JDK-8305713: DocCommentParser: merge blockContent and inlineContent - 8272119: Typo in JDK documentation (a -> an) - 8305461: [vectorapi] Add VectorMask::xor - 8305608: Change VMConnection to use "test.class.path"instead of "test.classes" - 8274166: Some CDS tests ignore -Dtest.cds.runtime.options - 8304745: Lazily initialize byte[] in java.io.BufferedInputStream - 8267140: Support closing the HttpClient by making it auto-closable - 8269843: typo in LinkedHashMap::removeEldestEntry spec - 8305480: test/hotspot/jtreg/runtime/NMT/VirtualAllocCommitMerge.java failing on 32 bit arm - 8305607: Remove some unused test parameters in com/sun/jdi tests - ... and 6 more: https://git.openjdk.org/jdk/compare/44f33ad1...b8b43eae Changes: https://git.openjdk.org/jdk/pull/13431/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13431&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8305713 Stats: 5934 lines in 119 files changed: 5071 ins; 480 del; 383 mod Patch: https://git.openjdk.org/jdk/pull/13431.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13431/head:pull/13431 PR: https://git.openjdk.org/jdk/pull/13431 From jjg at openjdk.org Tue Apr 11 18:35:12 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Tue, 11 Apr 2023 18:35:12 GMT Subject: RFR: JDK-8305713: DocCommentParser: merge blockContent and inlineContent [v2] In-Reply-To: References: Message-ID: > Please review a cleanup in DocCommentParser to merge blockContent and inlineContent into a single method to parse "rich content" in a doc comment. Jonathan Gibbons has updated the pull request incrementally with 42 additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into 8305713.dcp-content - 8305809: (fs) Review obsolete Linux kernel dependency on os.version (Unix kernel 2.6.39) Reviewed-by: rriggs, alanb - 8294806: jpackaged-app ignores splash screen from jar file Reviewed-by: almatvee - 8305368: G1 remset chunk claiming may use relaxed memory ordering Reviewed-by: ayang, iwalulya - 8305370: Inconsistent use of for_young_only_phase parameter in G1 predictions Reviewed-by: iwalulya, kbarrett - 8305663: Wrong iteration order of pause array in g1MMUTracker Reviewed-by: ayang, tschatzl - 8305761: Resolve multiple definition of 'jvm' when statically linking with JDK native libraries Reviewed-by: alanb, kevinw - 8305419: JDK-8301995 broke building libgraal Reviewed-by: matsaave, dnsimon, thartmann - 8302696: Revert API signature changes made in JDK-8285504 and JDK-8285263 Reviewed-by: mullan - 8304738: UnregisteredClassesTable_lock never created Reviewed-by: iklam, jcking, dholmes - ... and 32 more: https://git.openjdk.org/jdk/compare/b8b43eae...ab56c463 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13431/files - new: https://git.openjdk.org/jdk/pull/13431/files/b8b43eae..ab56c463 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13431&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13431&range=00-01 Stats: 9487 lines in 384 files changed: 2654 ins; 5914 del; 919 mod Patch: https://git.openjdk.org/jdk/pull/13431.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13431/head:pull/13431 PR: https://git.openjdk.org/jdk/pull/13431 From rriggs at openjdk.org Tue Apr 11 18:35:56 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 11 Apr 2023 18:35:56 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v11] In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: > Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. > The enumeration values are defined to match those used in the build. > The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64` > Note that `amd64` and `x86_64` in the build are represented by `X64`. > The value of the system property `os.arch` is unchanged. > > The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). > Uses in `java.base` and a few others are included but other modules will be done in separate PRs. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Add ppc64 as mapping to PPC64 Architecture ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13357/files - new: https://git.openjdk.org/jdk/pull/13357/files/fc40270a..1c0c0220 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=09-10 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13357/head:pull/13357 PR: https://git.openjdk.org/jdk/pull/13357 From duke at openjdk.org Tue Apr 11 18:39:41 2023 From: duke at openjdk.org (Glavo) Date: Tue, 11 Apr 2023 18:39:41 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v9] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Tue, 11 Apr 2023 16:58:13 GMT, Roger Riggs wrote: > > Would be great if you could support "os.arch = ppc64" for AIX and legacy linux, too. > > Changing os.arch is out of scope for this PR. The best way for that would someone supporting ppc to develop and propose a PR. It seems that you replied in the wrong place. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1163192614 From jjg at openjdk.org Tue Apr 11 18:39:53 2023 From: jjg at openjdk.org (Jonathan Gibbons) Date: Tue, 11 Apr 2023 18:39:53 GMT Subject: RFR: JDK-8305713: DocCommentParser: merge blockContent and inlineContent [v3] In-Reply-To: References: Message-ID: > Please review a cleanup in DocCommentParser to merge blockContent and inlineContent into a single method to parse "rich content" in a doc comment. Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 59 commits: - Merge branch 'pr/13362' into pr/13362 - Merge remote-tracking branch 'upstream/master' into 8305713.dcp-content - 8305809: (fs) Review obsolete Linux kernel dependency on os.version (Unix kernel 2.6.39) Reviewed-by: rriggs, alanb - 8294806: jpackaged-app ignores splash screen from jar file Reviewed-by: almatvee - 8305368: G1 remset chunk claiming may use relaxed memory ordering Reviewed-by: ayang, iwalulya - 8305370: Inconsistent use of for_young_only_phase parameter in G1 predictions Reviewed-by: iwalulya, kbarrett - 8305663: Wrong iteration order of pause array in g1MMUTracker Reviewed-by: ayang, tschatzl - 8305761: Resolve multiple definition of 'jvm' when statically linking with JDK native libraries Reviewed-by: alanb, kevinw - 8305419: JDK-8301995 broke building libgraal Reviewed-by: matsaave, dnsimon, thartmann - 8302696: Revert API signature changes made in JDK-8285504 and JDK-8285263 Reviewed-by: mullan - ... and 49 more: https://git.openjdk.org/jdk/compare/5501bf21...45ee028b ------------- Changes: https://git.openjdk.org/jdk/pull/13431/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13431&range=02 Stats: 15292 lines in 500 files changed: 7710 ins; 6358 del; 1224 mod Patch: https://git.openjdk.org/jdk/pull/13431.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13431/head:pull/13431 PR: https://git.openjdk.org/jdk/pull/13431 From cjplummer at openjdk.org Tue Apr 11 18:55:38 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 11 Apr 2023 18:55:38 GMT Subject: RFR: 8304834: Fix wrapper insertion in TestScaffold.parseArgs(String args[]) [v5] In-Reply-To: References: <7PDwD7zFu8CYojj6LDm0qVMlVHKuJNmAzxKaWdjGuvY=.cf39e296-777b-4653-bc19-7276a7da28e8@github.com> Message-ID: On Tue, 11 Apr 2023 17:51:39 GMT, Leonid Mesnik wrote: >> The TestScaffold incorrectly parse options, it should insert wrapper class between VM options and applications classame. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > Updated comments Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13170#pullrequestreview-1379888486 From amenkov at openjdk.org Tue Apr 11 18:56:37 2023 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 11 Apr 2023 18:56:37 GMT Subject: RFR: 8299414: JVMTI FollowReferences should support references from VirtualThread stack [v5] In-Reply-To: References: <6oQOD_egcB3HyuagMWGSPLjKSE3JkaI2K2WOsDK1Cww=.c568223b-5100-4425-a4b7-defbd812a9ff@github.com> Message-ID: On Tue, 11 Apr 2023 03:07:04 GMT, David Holmes wrote: > Seems to me the bug report is asking for unmounted virtual threads to be considered roots - but virtual threads are deliberately not roots. Any unmounted virtual thread should be reachable from either the scheduler or whatever object the VT is parked on, so if they are not showing up then perhaps the wrong reference is being followed. If there is a bug/missing-functionality in the FollowReferences implementation then fixing it is of course fine, but that is not what the bug report seems to be about. ??? The bug is about objects referenced only from stack of unmounted VT are not reported by FollowReferences. So we need to detect stackChunk object and report references from them. Next question - how to report them (jvmtiHeapReferenceKind). Stack locals for java threads are reported as JVMTI_HEAP_REFERENCE_STACK_LOCAL and this looks appropriate kind for this references. For JVMTI_HEAP_REFERENCE_STACK_LOCAL kind reference_info should contain pointer to jvmtiHeapReferenceInfoStackLocal structure, which contain info about thread (thread_tag, thread_id). It would be strange if we report stack locals from a thread without reporting thread itself (reference with JVMTI_HEAP_REFERENCE_THREAD kind), so we need to detect corresponding VirtualThread and report it. So we implicitly consider VT and their stack locals as roots and this made me think we need to report all of them. But as you mentioned VTs are deliberately not roots, so maybe we don't need to detect all of them and reporting only objects we found by following references is enough. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13254#issuecomment-1503929711 From cjplummer at openjdk.org Tue Apr 11 19:14:33 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 11 Apr 2023 19:14:33 GMT Subject: RFR: 8305084: Remove the removal warnings for finalize() from test/hotspot/jtreg/serviceability/dcmd/gc/FinalizerInfoTest.java and RunFinalizationTest.java [v2] In-Reply-To: References: Message-ID: On Tue, 11 Apr 2023 12:07:32 GMT, Afshin Zafari wrote: >> The `removal` warnings are suppressed out. >> Test: >> `FinalizerInfoTest` and `RunFinalizationTest` are executed locally. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > Remove the removal warnings for finalize() from test/hotspot/jtreg/serviceability/dcmd/gc/FinalizerInfoTest.java and RunFinalizationTest.java Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13423#pullrequestreview-1379915826 From rriggs at openjdk.org Tue Apr 11 19:37:52 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 11 Apr 2023 19:37:52 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v9] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: <1V5TUTuOnnVWmf7IyjkNZnrl0qRn1eS77yCD5ALEltI=.8f4a049a-eba3-42fe-85ad-80ee5cafa660@github.com> On Tue, 11 Apr 2023 18:37:11 GMT, Glavo wrote: >>> Would be great if you could support "os.arch = ppc64" for AIX and legacy linux, too. >> >> Changing os.arch is out of scope for this PR. >> The best way for that would someone supporting ppc to develop and propose a PR. > >> > Would be great if you could support "os.arch = ppc64" for AIX and legacy linux, too. >> >> Changing os.arch is out of scope for this PR. The best way for that would someone supporting ppc to develop and propose a PR. > > It seems that you replied in the wrong place. Likely, I misunderstood the request. Mapping ppc64 to PPC64 is easy enough. But currently, there is no direct support in the build/makefiles for ppc. See [OpenJDK supported platforms](https://wiki.openjdk.org/display/Build/Supported+Build+Platforms). For anything other than the most trivial and obvious, someone who can build ppc and test should propose the changes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1163241987 From rriggs at openjdk.org Tue Apr 11 19:37:53 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 11 Apr 2023 19:37:53 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v9] In-Reply-To: <1V5TUTuOnnVWmf7IyjkNZnrl0qRn1eS77yCD5ALEltI=.8f4a049a-eba3-42fe-85ad-80ee5cafa660@github.com> References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> <1V5TUTuOnnVWmf7IyjkNZnrl0qRn1eS77yCD5ALEltI=.8f4a049a-eba3-42fe-85ad-80ee5cafa660@github.com> Message-ID: On Tue, 11 Apr 2023 19:33:28 GMT, Roger Riggs wrote: >>> > Would be great if you could support "os.arch = ppc64" for AIX and legacy linux, too. >>> >>> Changing os.arch is out of scope for this PR. The best way for that would someone supporting ppc to develop and propose a PR. >> >> It seems that you replied in the wrong place. > > Likely, I misunderstood the request. Mapping ppc64 to PPC64 is easy enough. > But currently, there is no direct support in the build/makefiles for ppc. See [OpenJDK supported platforms](https://wiki.openjdk.org/display/Build/Supported+Build+Platforms). > For anything other than the most trivial and obvious, someone who can build ppc and test should propose the changes. The naming of x86_64 was raised earlier and resolved to use X64. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1163242850 From dlong at openjdk.org Tue Apr 11 19:39:20 2023 From: dlong at openjdk.org (Dean Long) Date: Tue, 11 Apr 2023 19:39:20 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v56] In-Reply-To: References: <2J4SoXF42zWujj5jjDllPGCHVLxuuT44tO-Oiz1PFNI=.a7bfa89d-3f4d-49b8-81ae-cd416cb5d263@github.com> <78es_NBdhW3jSDDYRHU8wcmuV53gwrvd4SB5i6g2HC4=.b93cd4c4-f0ac-44e0-b36a-854ce2f0cfac@github.com> Message-ID: On Tue, 11 Apr 2023 15:29:16 GMT, Daniel D. Daugherty wrote: >> OK. Given that I haven't looked at the rest of the patch, I leave it up to you and the Reviewers to figure out what to do about this code. Cheers. > > Given that the race with new lightweight locking is virtually the same as the race > with legacy stack locking, please do not put back the 'LockingMode == 2' check > which would make `jmm_GetThreadInfo()` calls slower with new lightweight locking > than with legacy stack locking. > > Perhaps I'm not understanding the risk of what @stefank means with: > > It looks to me like the code could read racingly read the element just above _top, > which could contain a stale oop. If the address of the stale oop matches the > address of o then contains would incorrectly return true. The `_base` array is only initialized to nullptr in debug builds. I don't see a release barrier in LockStack::push between the update to _base[] and the update to _top, nor a corresponding acquire barrier when reading. Doesn't this mean it is possible to racily read an uninitialized junk oop value from _base[], especially on weak memory models? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1163243827 From duke at openjdk.org Tue Apr 11 19:53:46 2023 From: duke at openjdk.org (ExE Boss) Date: Tue, 11 Apr 2023 19:53:46 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v11] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Tue, 11 Apr 2023 18:35:56 GMT, Roger Riggs wrote: >> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. >> The enumeration values are defined to match those used in the build. >> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64` >> Note that `amd64` and `x86_64` in the build are represented by `X64`. >> The value of the system property `os.arch` is unchanged. >> >> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). >> Uses in `java.base` and a few others are included but other modules will be done in separate PRs. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Add ppc64 as mapping to PPC64 Architecture src/java.base/share/classes/jdk/internal/util/PlatformProps.java.template line 58: > 56: return switch (archName) { > 57: case "x86_64" -> "x64"; > 58: case "ppc64", "ppc64le" -> "ppc64"; There?s?no `case?"s390" ->?"s390"`, so?this is?also?extraneous: Suggestion: case "ppc64le" -> "ppc64"; -------------------------------------------------------------------------------- The?`case?"ppc64"` was?supposed to?be?added to?`ArchTest.java`. test/jdk/jdk/internal/util/ArchTest.java line 74: > 72: case "riscv64" -> RISCV64; // unverified > 73: case "s390x", "s390" -> S390; // unverified > 74: case "ppc64le" -> PPC64; // unverified Suggestion: case "ppc64", "ppc64le" -> PPC64; // unverified ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1163257592 PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1163257861 From rkennke at openjdk.org Tue Apr 11 20:00:23 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 11 Apr 2023 20:00:23 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v56] In-Reply-To: References: <2J4SoXF42zWujj5jjDllPGCHVLxuuT44tO-Oiz1PFNI=.a7bfa89d-3f4d-49b8-81ae-cd416cb5d263@github.com> <78es_NBdhW3jSDDYRHU8wcmuV53gwrvd4SB5i6g2HC4=.b93cd4c4-f0ac-44e0-b36a-854ce2f0cfac@github.com> Message-ID: On Tue, 11 Apr 2023 19:35:36 GMT, Dean Long wrote: >> Given that the race with new lightweight locking is virtually the same as the race >> with legacy stack locking, please do not put back the 'LockingMode == 2' check >> which would make `jmm_GetThreadInfo()` calls slower with new lightweight locking >> than with legacy stack locking. >> >> Perhaps I'm not understanding the risk of what @stefank means with: >> >> It looks to me like the code could read racingly read the element just above _top, >> which could contain a stale oop. If the address of the stale oop matches the >> address of o then contains would incorrectly return true. > > The `_base` array is only initialized to nullptr in debug builds. I don't see a release barrier in LockStack::push between the update to _base[] and the update to _top, nor a corresponding acquire barrier when reading. Doesn't this mean it is possible to racily read an uninitialized junk oop value from _base[], especially on weak memory models? Yes. The whole LockStack is not meant to be accessed cross-thread, pretty much like any thread's stack is not meant to be accessed like that (including current stack-locking). So what can go wrong? With the new locking, we could read junk and compare it to the oop that we're testing against and get a wrong result. We're not going to crash though. With the current stack-locking, we would fetch the stack-pointer and check if that address is within the foreign thread's stack. Again, because the other thread is not holding still, we might get a wrong result, but we would not crash. So I guess we need to answer the question whether or not jmm_GetThreadInfo() is ok with returning wrong result and what could be the consequences of this. For example, how important is it that the info about the thread(s) is correct and consistent (e.g. what happens if we report two threads both holding the same lock?), etc. But I don't consider this to be part of this PR. So my proposal is: leave that code as it is, for now (being racy when inspecting foreign threads, but don't crash). Open a new issue to investigate and possibly fix the problem (maybe by safepointing, maybe by handshaking if that is enough, or maybe we find out we don't need to do anything). Add comments in relevant places to point out the problem like you and David suggested earlier. Would that be ok? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1163263926 From dlong at openjdk.org Tue Apr 11 20:42:16 2023 From: dlong at openjdk.org (Dean Long) Date: Tue, 11 Apr 2023 20:42:16 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v56] In-Reply-To: References: <2J4SoXF42zWujj5jjDllPGCHVLxuuT44tO-Oiz1PFNI=.a7bfa89d-3f4d-49b8-81ae-cd416cb5d263@github.com> <78es_NBdhW3jSDDYRHU8wcmuV53gwrvd4SB5i6g2HC4=.b93cd4c4-f0ac-44e0-b36a-854ce2f0cfac@github.com> Message-ID: <6vD1PFLLelAVWsCl3YpuPBhd_tuc-xlE3wH_HCp7Lu8=.6b9ed684-f94c-434e-82df-15003ded284d@github.com> On Tue, 11 Apr 2023 19:58:19 GMT, Roman Kennke wrote: >> The `_base` array is only initialized to nullptr in debug builds. I don't see a release barrier in LockStack::push between the update to _base[] and the update to _top, nor a corresponding acquire barrier when reading. Doesn't this mean it is possible to racily read an uninitialized junk oop value from _base[], especially on weak memory models? > > Yes. The whole LockStack is not meant to be accessed cross-thread, pretty much like any thread's stack is not meant to be accessed like that (including current stack-locking). So what can go wrong? > With the new locking, we could read junk and compare it to the oop that we're testing against and get a wrong result. We're not going to crash though. > With the current stack-locking, we would fetch the stack-pointer and check if that address is within the foreign thread's stack. Again, because the other thread is not holding still, we might get a wrong result, but we would not crash. > So I guess we need to answer the question whether or not jmm_GetThreadInfo() is ok with returning wrong result and what could be the consequences of this. For example, how important is it that the info about the thread(s) is correct and consistent (e.g. what happens if we report two threads both holding the same lock?), etc. But I don't consider this to be part of this PR. > > So my proposal is: leave that code as it is, for now (being racy when inspecting foreign threads, but don't crash). Open a new issue to investigate and possibly fix the problem (maybe by safepointing, maybe by handshaking if that is enough, or maybe we find out we don't need to do anything). Add comments in relevant places to point out the problem like you and David suggested earlier. Would that be ok? That seems fine to me, as long as we don't crash. But my understanding is that Generational ZGC will crash if it sees a stale oop. Isn't it possible that the racing read sees junk that looks to Generational ZGC like a stale oop? To avoid this, unused slots may need to be set to nullptr even in product builds. But I'm not a GC expert so maybe there's no problem. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1163306288 From mdoerr at openjdk.org Tue Apr 11 20:46:44 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 11 Apr 2023 20:46:44 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v11] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Tue, 11 Apr 2023 18:35:56 GMT, Roger Riggs wrote: >> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. >> The enumeration values are defined to match those used in the build. >> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64` >> Note that `amd64` and `x86_64` in the build are represented by `X64`. >> The value of the system property `os.arch` is unchanged. >> >> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). >> Uses in `java.base` and a few others are included but other modules will be done in separate PRs. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Add ppc64 as mapping to PPC64 Architecture Thanks for the updates! PPC64 looks basically good except of a upper / lower case issue in the test: STARTED ArchTest::nameVsCurrent 'nameVsCurrent()' org.opentest4j.AssertionFailedError: mismatch in Architecture.current vs ppc64 ==> expected: but was: ... FAILED ArchTest::nameVsCurrent 'nameVsCurrent()' JavaTest Message: JUnit Platform Failure(s): 1 ------------- PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1504064549 From rriggs at openjdk.org Tue Apr 11 21:09:43 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 11 Apr 2023 21:09:43 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v12] In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: <8RVzDuEvl7ono94GeIvGJ1_ucB35VjayTJezgYfaUw4=.aae42a0f-116d-498a-ba59-95a3a52a9b41@github.com> > Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. > The enumeration values are defined to match those used in the build. > The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64` > Note that `amd64` and `x86_64` in the build are represented by `X64`. > The value of the system property `os.arch` is unchanged. > > The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). > Uses in `java.base` and a few others are included but other modules will be done in separate PRs. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Correct mapping and test of ppc64 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13357/files - new: https://git.openjdk.org/jdk/pull/13357/files/1c0c0220..71135e3b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=10-11 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13357/head:pull/13357 PR: https://git.openjdk.org/jdk/pull/13357 From duke at openjdk.org Tue Apr 11 21:16:46 2023 From: duke at openjdk.org (Glavo) Date: Tue, 11 Apr 2023 21:16:46 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v12] In-Reply-To: <8RVzDuEvl7ono94GeIvGJ1_ucB35VjayTJezgYfaUw4=.aae42a0f-116d-498a-ba59-95a3a52a9b41@github.com> References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> <8RVzDuEvl7ono94GeIvGJ1_ucB35VjayTJezgYfaUw4=.aae42a0f-116d-498a-ba59-95a3a52a9b41@github.com> Message-ID: On Tue, 11 Apr 2023 21:09:43 GMT, Roger Riggs wrote: >> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. >> The enumeration values are defined to match those used in the build. >> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64` >> Note that `amd64` and `x86_64` in the build are represented by `X64`. >> The value of the system property `os.arch` is unchanged. >> >> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). >> Uses in `java.base` and a few others are included but other modules will be done in separate PRs. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Correct mapping and test of ppc64 test/jdk/jdk/internal/util/ArchTest.java line 70: > 68: case "x86" -> X86; > 69: case "i386" -> X86; > 70: case "amd64" -> X64; // Is alias for X86_64 Suggestion: case "x86_64", "amd64" -> X64; case "x86", "i386" -> X86; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1163340519 From duke at openjdk.org Tue Apr 11 21:50:36 2023 From: duke at openjdk.org (Ashutosh Mehra) Date: Tue, 11 Apr 2023 21:50:36 GMT Subject: RFR: 8298048: Combine CDS archive heap into a single block In-Reply-To: References: Message-ID: <3ybhZpVsw5iki0H2OkFswEIqFfEFC0YwNhp9chzu5yU=.8b29a446-3be0-4ae8-a8d0-948003be0411@github.com> On Mon, 3 Apr 2023 03:32:27 GMT, Ioi Lam wrote: > This PR combines the "open" and "closed" regions of the CDS archive heap into a single region. This significantly simplifies the implementation, making it more compatible with non-G1 collectors. There's a net removal of ~1000 lines in src code and another ~1200 lines of tests. > > **Notes for reviewers:** > - Most of the code changes in CDS are removing the handling of "open" vs "closed" objects. > - Reviewers can start with ArchiveHeapWriter::copy_source_objs_to_buffer(). > - It might be easier to see the diff with whitespaces off. > - There are two major changes in the G1 code > - The archived objects are now stored in the "old" region (see g1CollectedHeap.cpp in [58d720e](https://github.com/openjdk/jdk/pull/13284/commits/58d720e294bb36f21cb88cddde724ed2b9e93770)) > - The majority of the other changes are removal of the "archive" region type (see heapRegionType.hpp). For ease of review, such code is isolated in [a852dfb](https://github.com/openjdk/jdk/pull/13284/commits/a852dfbbf5ff56e035399f7cc3704f29e76697f6) > - Testing changes: > - Now the archived java objects can move, along with the "old" regions that contain them. It's no longer possible to test whether a heap object came from CDS. As a result, the `WhiteBox.isShared(Object o)` API has been removed. > - Many tests that uses this API are removed. Most of them were written during early development of CDS archived objects and are no longer relevant. > > **Testing:** > - Mach5 tiers 1 ~ 7 Marked as reviewed by ashu-mehra at github.com (no known OpenJDK username). cds changes look good! just few nitpicks. src/hotspot/share/cds/archiveHeapLoader.cpp line 265: > 263: MemRegion& archive_space) { > 264: size_t total_bytes = 0; > 265: int i = MetaspaceShared::hp; nitpick: this can be replaced with a better variable name instead of `i`, probably region_idx. src/hotspot/share/cds/archiveHeapLoader.cpp line 274: > 272: assert(is_aligned(r->used(), HeapWordSize), "must be"); > 273: total_bytes += r->used(); > 274: loaded_region->_region_index = i; nitpick: we can do away with `_region_index` and use `MetaspaceShared::hp` wherever required. src/hotspot/share/cds/archiveHeapLoader.cpp line 445: > 443: } > 444: > 445: int i = MetaspaceShared::hp; nitpick: same as before, suggest to replace `i` with `region_idx`. src/hotspot/share/cds/archiveHeapWriter.cpp line 54: > 52: // The following are offsets from buffer_bottom() > 53: size_t ArchiveHeapWriter::_buffer_used; > 54: size_t ArchiveHeapWriter::_heap_roots_bottom; nitpick: would be clearer if `_heap_roots_bottom` is named as `_heap_roots_bottom_offset` src/hotspot/share/cds/metaspaceShared.hpp line 63: > 61: ro = 1, // read-only shared space > 62: bm = 2, // relocation bitmaps (freed after file mapping is finished) > 63: hp = 3, // relocation bitmaps (freed after file mapping is finished) This comment needs to be updated. ------------- PR Review: https://git.openjdk.org/jdk/pull/13284#pullrequestreview-1380125495 PR Comment: https://git.openjdk.org/jdk/pull/13284#issuecomment-1504143568 PR Review Comment: https://git.openjdk.org/jdk/pull/13284#discussion_r1163361181 PR Review Comment: https://git.openjdk.org/jdk/pull/13284#discussion_r1163361230 PR Review Comment: https://git.openjdk.org/jdk/pull/13284#discussion_r1163361633 PR Review Comment: https://git.openjdk.org/jdk/pull/13284#discussion_r1163362914 PR Review Comment: https://git.openjdk.org/jdk/pull/13284#discussion_r1163362267 From amenkov at openjdk.org Wed Apr 12 01:06:46 2023 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 12 Apr 2023 01:06:46 GMT Subject: RFR: 8299414: JVMTI FollowReferences should support references from VirtualThread stack [v6] In-Reply-To: <6oQOD_egcB3HyuagMWGSPLjKSE3JkaI2K2WOsDK1Cww=.c568223b-5100-4425-a4b7-defbd812a9ff@github.com> References: <6oQOD_egcB3HyuagMWGSPLjKSE3JkaI2K2WOsDK1Cww=.c568223b-5100-4425-a4b7-defbd812a9ff@github.com> Message-ID: > The fix updates JVMTI FollowReferences implementation to report references from virtual threads: > - added heap scanning to report unmounted vthreads; > - stacks of mounted vthreads are splitted into 2 parts (vittual thread stack and carrier thread stack), references are reported with correct thread id/class and object tags/frame depth; > - common code to handle stack frames are moved into separate class; Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: removed full heap scan. unmounted VT are not considered roots and reported only from references ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13254/files - new: https://git.openjdk.org/jdk/pull/13254/files/f7831794..f85e95ba Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13254&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13254&range=04-05 Stats: 144 lines in 2 files changed: 62 ins; 74 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/13254.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13254/head:pull/13254 PR: https://git.openjdk.org/jdk/pull/13254 From amenkov at openjdk.org Wed Apr 12 01:12:49 2023 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 12 Apr 2023 01:12:49 GMT Subject: RFR: 8299414: JVMTI FollowReferences should support references from VirtualThread stack [v7] In-Reply-To: <6oQOD_egcB3HyuagMWGSPLjKSE3JkaI2K2WOsDK1Cww=.c568223b-5100-4425-a4b7-defbd812a9ff@github.com> References: <6oQOD_egcB3HyuagMWGSPLjKSE3JkaI2K2WOsDK1Cww=.c568223b-5100-4425-a4b7-defbd812a9ff@github.com> Message-ID: > The fix updates JVMTI FollowReferences implementation to report references from virtual threads: > - added heap scanning to report unmounted vthreads; > - stacks of mounted vthreads are splitted into 2 parts (vittual thread stack and carrier thread stack), references are reported with correct thread id/class and object tags/frame depth; > - common code to handle stack frames are moved into separate class; Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: Fixed indent in collect_vthread_stack_roots ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13254/files - new: https://git.openjdk.org/jdk/pull/13254/files/f85e95ba..d95a8426 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13254&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13254&range=05-06 Stats: 43 lines in 1 file changed: 7 ins; 7 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/13254.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13254/head:pull/13254 PR: https://git.openjdk.org/jdk/pull/13254 From kbarrett at openjdk.org Wed Apr 12 01:41:34 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 12 Apr 2023 01:41:34 GMT Subject: RFR: 8305341: Alignment should be enforced by alignas instead of compiler specific attributes [v3] In-Reply-To: References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com> Message-ID: On Sat, 8 Apr 2023 13:24:37 GMT, Julian Waters wrote: >> C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Semicolon I don't think the other bug/PR (JDK-8250269, PR#11431) to change HotSpot's ATTRIBUTE_ALIGNED should be combined with the changes outside of HotSpot. They are doing rather different things, despite the token "alignas" occuring in both. I've been meaning to review PR#11431, but have been swamped. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1504401317 From dholmes at openjdk.org Wed Apr 12 02:11:14 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 12 Apr 2023 02:11:14 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v56] In-Reply-To: <6vD1PFLLelAVWsCl3YpuPBhd_tuc-xlE3wH_HCp7Lu8=.6b9ed684-f94c-434e-82df-15003ded284d@github.com> References: <2J4SoXF42zWujj5jjDllPGCHVLxuuT44tO-Oiz1PFNI=.a7bfa89d-3f4d-49b8-81ae-cd416cb5d263@github.com> <78es_NBdhW3jSDDYRHU8wcmuV53gwrvd4SB5i6g2HC4=.b93cd4c4-f0ac-44e0-b36a-854ce2f0cfac@github.com> <6vD1PFLLelAVWsCl3YpuPBhd_tuc-xlE3wH _HCp7Lu8=.6b9ed684-f94c-434e-82df-15003ded284d@github.com> Message-ID: On Tue, 11 Apr 2023 20:40:14 GMT, Dean Long wrote: >> Yes. The whole LockStack is not meant to be accessed cross-thread, pretty much like any thread's stack is not meant to be accessed like that (including current stack-locking). So what can go wrong? >> With the new locking, we could read junk and compare it to the oop that we're testing against and get a wrong result. We're not going to crash though. >> With the current stack-locking, we would fetch the stack-pointer and check if that address is within the foreign thread's stack. Again, because the other thread is not holding still, we might get a wrong result, but we would not crash. >> So I guess we need to answer the question whether or not jmm_GetThreadInfo() is ok with returning wrong result and what could be the consequences of this. For example, how important is it that the info about the thread(s) is correct and consistent (e.g. what happens if we report two threads both holding the same lock?), etc. But I don't consider this to be part of this PR. >> >> So my proposal is: leave that code as it is, for now (being racy when inspecting foreign threads, but don't crash). Open a new issue to investigate and possibly fix the problem (maybe by safepointing, maybe by handshaking if that is enough, or maybe we find out we don't need to do anything). Add comments in relevant places to point out the problem like you and David suggested earlier. Would that be ok? > > That seems fine to me, as long as we don't crash. But my understanding is that Generational ZGC will crash if it sees a stale oop. Isn't it possible that the racing read sees junk that looks to Generational ZGC like a stale oop? To avoid this, unused slots may need to be set to nullptr even in product builds. But I'm not a GC expert so maybe there's no problem. The old code is "racy but safe - it basically answers the question "what thread held the lock at the time I was asking?" and if we get a stack-addr as the owner at the time we ask, and that stack-address belongs to a given thread t then we report t as the owner. The fact t may have released the lock as soon as we read the stack-addr is immaterial. The new code may be a different matter however. Now the race involves oops, and potentially stale ones IIUC what Stefan is saying. So now the race is not safe, and potentially may crash. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1163491093 From dholmes at openjdk.org Wed Apr 12 02:19:32 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 12 Apr 2023 02:19:32 GMT Subject: RFR: 8299414: JVMTI FollowReferences should support references from VirtualThread stack [v5] In-Reply-To: References: <6oQOD_egcB3HyuagMWGSPLjKSE3JkaI2K2WOsDK1Cww=.c568223b-5100-4425-a4b7-defbd812a9ff@github.com> Message-ID: On Tue, 11 Apr 2023 18:54:09 GMT, Alex Menkov wrote: > The bug is about objects referenced only from stack of unmounted VT are not reported by FollowReferences. > So we need to detect stackChunk object and report references from them. If an object is only reachable from the stack of a VT and the VT itself is not followed then we don't find that object either. But as I said a VT should be found via the object it is parked on, or via the scheduler. So is it the case that the current logic will not follow the stack of an unmounted Virtual thread? If so that seems wrong - especially if a mounted VT would find those objects. A VT is not a GC root but now I'm unsure exactly what that means. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13254#issuecomment-1504443345 From dholmes at openjdk.org Wed Apr 12 02:28:34 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 12 Apr 2023 02:28:34 GMT Subject: RFR: 8304834: Fix wrapper insertion in TestScaffold.parseArgs(String args[]) [v5] In-Reply-To: References: <7PDwD7zFu8CYojj6LDm0qVMlVHKuJNmAzxKaWdjGuvY=.cf39e296-777b-4653-bc19-7276a7da28e8@github.com> Message-ID: On Tue, 11 Apr 2023 17:51:39 GMT, Leonid Mesnik wrote: >> The TestScaffold incorrectly parse options, it should insert wrapper class between VM options and applications classame. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > Updated comments Looks good. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13170#pullrequestreview-1380335870 From dholmes at openjdk.org Wed Apr 12 02:39:36 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 12 Apr 2023 02:39:36 GMT Subject: RFR: 8305084: Remove the removal warnings for finalize() from test/hotspot/jtreg/serviceability/dcmd/gc/FinalizerInfoTest.java and RunFinalizationTest.java [v2] In-Reply-To: References: Message-ID: On Tue, 11 Apr 2023 12:07:32 GMT, Afshin Zafari wrote: >> The `removal` warnings are suppressed out. >> Test: >> `FinalizerInfoTest` and `RunFinalizationTest` are executed locally. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > Remove the removal warnings for finalize() from test/hotspot/jtreg/serviceability/dcmd/gc/FinalizerInfoTest.java and RunFinalizationTest.java Looks good. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13423#pullrequestreview-1380344532 From kbarrett at openjdk.org Wed Apr 12 02:39:36 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 12 Apr 2023 02:39:36 GMT Subject: RFR: 8305341: Alignment should be enforced by alignas instead of compiler specific attributes [v3] In-Reply-To: References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com> Message-ID: On Sat, 8 Apr 2023 13:24:37 GMT, Julian Waters wrote: >> C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Semicolon I was pretty confused by the C changes for a while, since I didn't know or had forgotten that the 32bit Windows ABI only guarantees 4 byte stack alignment, and permits "misaligned" local variables for types such as long long and double. (And I failed to find any definitive documentation for that.) Yuck! What is the purpose of removing `defined(_MSC_VER)` from the conditionals? Is this to allow for other compilers that similarly only ensure 4 byte alignment of the stack? If so, it would have been nice to mention that separate concern in the PR description, rather than making reviewers guess. And do such compilers actually exist? A bit of research suggests gcc (at least) maintains 16 byte alignment (and may warrant the use of -mstackrealign or other hoops). See, for example, https://github.com/uTox/uTox/issues/1304. Is `defined(_WIN32)` really the right conditional? That's true for pretty much any Visual Studio supported target, both 32bit and 64bit. But the alignment spec is effectively a nop for 64bit platforms, so harmless. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1504466526 From amitkumar at openjdk.org Wed Apr 12 03:47:43 2023 From: amitkumar at openjdk.org (Amit Kumar) Date: Wed, 12 Apr 2023 03:47:43 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v10] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Tue, 11 Apr 2023 18:07:41 GMT, Martin Doerr wrote: > Another remark: Old JDK on s390 used "os.arch = zArch_64", current one "os.arch = s390x". @offamitkumar: You probably want to take a look. Martin, only concern was that I didn't have a good experience with `s390x` string in [past](https://github.com/openjdk/jdk/pull/13228#issuecomment-1488599607). But, I assume that `default` in `mapArchString` will unintentionally handle that scenario here. I tested it, and 'ArchTest.java' also passes. I guess @RealLucy might have some pointer over this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1504542573 From amenkov at openjdk.org Wed Apr 12 04:07:36 2023 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 12 Apr 2023 04:07:36 GMT Subject: RFR: 8299414: JVMTI FollowReferences should support references from VirtualThread stack [v5] In-Reply-To: References: <6oQOD_egcB3HyuagMWGSPLjKSE3JkaI2K2WOsDK1Cww=.c568223b-5100-4425-a4b7-defbd812a9ff@github.com> Message-ID: On Wed, 12 Apr 2023 02:17:14 GMT, David Holmes wrote: > If an object is only reachable from the stack of a VT and the VT itself is not followed then we don't find that object either. But as I said a VT should be found via the object it is parked on, or via the scheduler. So is it the case that the current logic will not follow the stack of an unmounted Virtual thread? If so that seems wrong - especially if a mounted VT would find those objects. A VT is not a GC root but now I'm unsure exactly what that means. Right, unmounted VTs are reachable from other objects. And that's correct that current logic does not follow their stack references (current logic considers VT object as normal object, i.e. follows reference to its class and to its fields (iterate_over_object method, line 2687)). Mounted VT does follow stack references as its stack is a part of carrier thread stack and carrier stack locals are followed (collect_stack_roots method, line 2775). The fix just splits carrier thread stack and report some references as references from VT stack (not carrier thread stack). As for "heap roots" FollowReferences spec says: `The heap root are the set of system classes, JNI globals, references from thread stacks, and other objects used as roots for the purposes of garbage collection.` As far as I understand the idea here is all other heap objects are reachable from "heap roots". ------------- PR Comment: https://git.openjdk.org/jdk/pull/13254#issuecomment-1504564223 From dholmes at openjdk.org Wed Apr 12 04:29:35 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 12 Apr 2023 04:29:35 GMT Subject: RFR: 8299414: JVMTI FollowReferences should support references from VirtualThread stack [v5] In-Reply-To: References: <6oQOD_egcB3HyuagMWGSPLjKSE3JkaI2K2WOsDK1Cww=.c568223b-5100-4425-a4b7-defbd812a9ff@github.com> Message-ID: On Wed, 12 Apr 2023 04:05:07 GMT, Alex Menkov wrote: > current logic does not follow their stack references Okay that needs to be fixed then. Apologies if that is what you already were doing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13254#issuecomment-1504587109 From iklam at openjdk.org Wed Apr 12 05:00:42 2023 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 12 Apr 2023 05:00:42 GMT Subject: RFR: 8298048: Combine CDS archive heap into a single block [v2] In-Reply-To: References: Message-ID: > This PR combines the "open" and "closed" regions of the CDS archive heap into a single region. This significantly simplifies the implementation, making it more compatible with non-G1 collectors. There's a net removal of ~1000 lines in src code and another ~1200 lines of tests. > > **Notes for reviewers:** > - Most of the code changes in CDS are removing the handling of "open" vs "closed" objects. > - Reviewers can start with ArchiveHeapWriter::copy_source_objs_to_buffer(). > - It might be easier to see the diff with whitespaces off. > - There are two major changes in the G1 code > - The archived objects are now stored in the "old" region (see g1CollectedHeap.cpp in [58d720e](https://github.com/openjdk/jdk/pull/13284/commits/58d720e294bb36f21cb88cddde724ed2b9e93770)) > - The majority of the other changes are removal of the "archive" region type (see heapRegionType.hpp). For ease of review, such code is isolated in [a852dfb](https://github.com/openjdk/jdk/pull/13284/commits/a852dfbbf5ff56e035399f7cc3704f29e76697f6) > - Testing changes: > - Now the archived java objects can move, along with the "old" regions that contain them. It's no longer possible to test whether a heap object came from CDS. As a result, the `WhiteBox.isShared(Object o)` API has been removed. > - Many tests that uses this API are removed. Most of them were written during early development of CDS archived objects and are no longer relevant. > > **Testing:** > - Mach5 tiers 1 ~ 7 Ioi Lam has updated the pull request incrementally with two additional commits since the last revision: - more clean up: heap_regions -> heap_region, etc - @matias9927 comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13284/files - new: https://git.openjdk.org/jdk/pull/13284/files/a852dfbb..a1a3cac7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13284&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13284&range=00-01 Stats: 116 lines in 12 files changed: 11 ins; 46 del; 59 mod Patch: https://git.openjdk.org/jdk/pull/13284.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13284/head:pull/13284 PR: https://git.openjdk.org/jdk/pull/13284 From iklam at openjdk.org Wed Apr 12 05:00:49 2023 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 12 Apr 2023 05:00:49 GMT Subject: RFR: 8298048: Combine CDS archive heap into a single block [v2] In-Reply-To: References: Message-ID: <-wObHrEhbZ2UN9T88NDX3RNnkn3RLuC3BI4KUXSDY80=.1f276277-08a9-44c7-ae2c-7181a3e6b873@github.com> On Fri, 7 Apr 2023 19:17:46 GMT, Matias Saavedra Silva wrote: >> Ioi Lam has updated the pull request incrementally with two additional commits since the last revision: >> >> - more clean up: heap_regions -> heap_region, etc >> - @matias9927 comments > > src/hotspot/share/cds/archiveBuilder.cpp line 1086: > >> 1084: p2i(to_requested(start)), size_t(end - start)); >> 1085: log_data(start, end, to_requested(start), /*is_heap=*/true); >> 1086: } > > These log messages can be placed inside the else case before the break Fixed. > src/hotspot/share/cds/archiveHeapWriter.cpp line 369: > >> 367: template void ArchiveHeapWriter::store_requested_oop_in_buffer(T* buffered_addr, >> 368: oop request_oop) { >> 369: //assert(is_in_requested_regions(request_oop), "must be"); > > Some left over commented code. I assume this should be removed or a new assert should be here to replace it. I fixed the assert. > src/hotspot/share/cds/archiveHeapWriter.cpp line 529: > >> 527: num_non_null_ptrs ++; >> 528: >> 529: if (max_idx < idx) { > > Is there a built in min() function we can use here? Maybe std::min()? Updated with the `MAX2()` macro. > src/hotspot/share/cds/filemap.cpp line 1674: > >> 1672: >> 1673: char* buffer = NEW_C_HEAP_ARRAY(char, size_in_bytes, mtClassShared); >> 1674: size_t written = write_bitmap(ptrmap, buffer, 0); > > Maybe add a comment to clarify there is no offset? Constants in method parameters can be confusing sometimes. I changed the code to pass "written" as a parameter similar to the other two calls. Also added comments. > src/hotspot/share/cds/filemap.cpp line 2035: > >> 2033: } >> 2034: if (end < e) { >> 2035: end = e; > > Like mentioned before, maybe we have max() and min() methods to use here. I simplified the code -- there's only one range now so the start/end can be easily determined. > src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 520: > >> 518: } else { >> 519: return true; >> 520: } > > Maybe make this `return reserved.contains(range.start()) && reserved.contains(range.last())` Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13284#discussion_r1163601901 PR Review Comment: https://git.openjdk.org/jdk/pull/13284#discussion_r1163601972 PR Review Comment: https://git.openjdk.org/jdk/pull/13284#discussion_r1163602280 PR Review Comment: https://git.openjdk.org/jdk/pull/13284#discussion_r1163602339 PR Review Comment: https://git.openjdk.org/jdk/pull/13284#discussion_r1163602400 PR Review Comment: https://git.openjdk.org/jdk/pull/13284#discussion_r1163602433 From stefank at openjdk.org Wed Apr 12 05:29:21 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 12 Apr 2023 05:29:21 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v56] In-Reply-To: References: <2J4SoXF42zWujj5jjDllPGCHVLxuuT44tO-Oiz1PFNI=.a7bfa89d-3f4d-49b8-81ae-cd416cb5d263@github.com> <78es_NBdhW3jSDDYRHU8wcmuV53gwrvd4SB5i6g2HC4=.b93cd4c4-f0ac-44e0-b36a-854ce2f0cfac@github.com> <6vD1PFLLelAVWsCl3YpuPBhd_tuc-xlE3wH _HCp7Lu8=.6b9ed684-f94c-434e-82df-15003ded284d@github.com> Message-ID: On Wed, 12 Apr 2023 02:08:08 GMT, David Holmes wrote: >> That seems fine to me, as long as we don't crash. But my understanding is that Generational ZGC will crash if it sees a stale oop. Isn't it possible that the racing read sees junk that looks to Generational ZGC like a stale oop? To avoid this, unused slots may need to be set to nullptr even in product builds. But I'm not a GC expert so maybe there's no problem. > > The old code is "racy but safe - it basically answers the question "what thread held the lock at the time I was asking?" and if we get a stack-addr as the owner at the time we ask, and that stack-address belongs to a given thread t then we report t as the owner. The fact t may have released the lock as soon as we read the stack-addr is immaterial. > > The new code may be a different matter however. Now the race involves oops, and potentially stale ones IIUC what Stefan is saying. So now the race is not safe, and potentially may crash. > That seems fine to me, as long as we don't crash. But my understanding is that Generational ZGC will crash if it sees a stale oop. Isn't it possible that the racing read sees junk that looks to Generational ZGC like a stale oop? To avoid this, unused slots may need to be set to nullptr even in product builds. But I'm not a GC expert so maybe there's no problem. Generational ZGC has verification code in fastdebug builds that try to detect stale oops. However, the current LockStack implementation seems to always clear unused slots when running in debug builds. That minimizes the risk that the verification code would find stale oops in the LockStack. Regarding release build, given that the LockStack code doesn't dereference any of the contained oops and we don't have oop verification code in release builds, I don't see of ZGC would crash because of this race. Note however that these kind of races are technically undefined behavior, so I wouldn't be too confident that this code is safe. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1163627980 From iklam at openjdk.org Wed Apr 12 05:29:45 2023 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 12 Apr 2023 05:29:45 GMT Subject: RFR: 8298048: Combine CDS archive heap into a single block [v3] In-Reply-To: References: Message-ID: > This PR combines the "open" and "closed" regions of the CDS archive heap into a single region. This significantly simplifies the implementation, making it more compatible with non-G1 collectors. There's a net removal of ~1000 lines in src code and another ~1200 lines of tests. > > **Notes for reviewers:** > - Most of the code changes in CDS are removing the handling of "open" vs "closed" objects. > - Reviewers can start with ArchiveHeapWriter::copy_source_objs_to_buffer(). > - It might be easier to see the diff with whitespaces off. > - There are two major changes in the G1 code > - The archived objects are now stored in the "old" region (see g1CollectedHeap.cpp in [58d720e](https://github.com/openjdk/jdk/pull/13284/commits/58d720e294bb36f21cb88cddde724ed2b9e93770)) > - The majority of the other changes are removal of the "archive" region type (see heapRegionType.hpp). For ease of review, such code is isolated in [a852dfb](https://github.com/openjdk/jdk/pull/13284/commits/a852dfbbf5ff56e035399f7cc3704f29e76697f6) > - Testing changes: > - Now the archived java objects can move, along with the "old" regions that contain them. It's no longer possible to test whether a heap object came from CDS. As a result, the `WhiteBox.isShared(Object o)` API has been removed. > - Many tests that uses this API are removed. Most of them were written during early development of CDS archived objects and are no longer relevant. > > **Testing:** > - Mach5 tiers 1 ~ 7 Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge branch 'master' into 8298048-combine-cds-heap-to-single-region-PUSH - more clean up: heap_regions -> heap_region, etc - @matias9927 comments - Remove archive region types from G1 - clean up (1) - 8298048: Combine CDS archive heap into a single block ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13284/files - new: https://git.openjdk.org/jdk/pull/13284/files/a1a3cac7..b693d27c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13284&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13284&range=01-02 Stats: 33051 lines in 911 files changed: 16125 ins; 14331 del; 2595 mod Patch: https://git.openjdk.org/jdk/pull/13284.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13284/head:pull/13284 PR: https://git.openjdk.org/jdk/pull/13284 From jbechberger at openjdk.org Wed Apr 12 06:52:49 2023 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Wed, 12 Apr 2023 06:52:49 GMT Subject: Integrated: 8304725: AsyncGetCallTrace can cause SIGBUS on M1 In-Reply-To: References: Message-ID: On Wed, 22 Mar 2023 15:57:40 GMT, Johannes Bechberger wrote: > Fixes the issue by disabling PCDesc cache modifications when in ASGCT. > > Tested on my M1 mac. This pull request has now been integrated. Changeset: d8af7a60 Author: Johannes Bechberger Committer: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/d8af7a6014055295355a1242db6c2872299c6398 Stats: 33 lines in 3 files changed: 32 ins; 0 del; 1 mod 8304725: AsyncGetCallTrace can cause SIGBUS on M1 Reviewed-by: dholmes, stuefe, mbaesken ------------- PR: https://git.openjdk.org/jdk/pull/13144 From jwaters at openjdk.org Wed Apr 12 07:12:10 2023 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 12 Apr 2023 07:12:10 GMT Subject: RFR: 8305341: Alignment should be enforced by alignas instead of compiler specific attributes [v4] In-Reply-To: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com> References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com> Message-ID: > C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements Julian Waters has updated the pull request incrementally with four additional commits since the last revision: - Restore visCPP - Restore gcc attribute - Revert gcc - Revert ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13258/files - new: https://git.openjdk.org/jdk/pull/13258/files/07f5c702..e63d5938 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13258&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13258&range=02-03 Stats: 9 lines in 3 files changed: 7 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13258.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13258/head:pull/13258 PR: https://git.openjdk.org/jdk/pull/13258 From jwaters at openjdk.org Wed Apr 12 07:20:45 2023 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 12 Apr 2023 07:20:45 GMT Subject: RFR: 8305341: Alignment should be enforced by alignas instead of compiler specific attributes [v4] In-Reply-To: References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com> Message-ID: On Wed, 12 Apr 2023 07:12:10 GMT, Julian Waters wrote: >> C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements > > Julian Waters has updated the pull request incrementally with four additional commits since the last revision: > > - Restore visCPP > - Restore gcc attribute > - Revert gcc > - Revert > What is the purpose of removing `defined(_MSC_VER)` from the conditionals? Is this to allow for other compilers that similarly only ensure 4 byte alignment of the stack? If so, it would have been nice to mention that separate concern in the PR description, rather than making reviewers guess. And do such compilers actually exist? A bit of research suggests gcc (at least) maintains 16 byte alignment (and may warrant the use of -mstackrealign or other hoops). See, for example, [uTox/uTox#1304](https://github.com/uTox/uTox/issues/1304). Admittedly I wasn't sure what the alignment specifier here was for either, but assumed that it was something that was simply required for Windows code, and since _MSC_VER is always the only compiler (for now) that can compile Windows code, the check seemed pretty pointless. It seemed logical then that even if another compiler was added to the mix Windows code would still be under said ABI restrictions, hence the removal of that conditional. I'm now no longer as certain that this is always the case and can revert those changes if that check turns out to be correct > Is `defined(_WIN32)` really the right conditional? That's true for pretty much any Visual Studio supported target, both 32bit and 64bit. But the alignment spec is effectively a nop for 64bit platforms, so harmless. Perhaps, since this pretty much specifies that only Windows code should be affected by the alignment (Irrespective of this change). Others might disagree here, though > I was pretty confused by the C changes for a while, since I didn't know or had forgotten that the 32bit Windows ABI only guarantees 4 byte stack alignment, and permits "misaligned" local variables for types such as long long and double. (And I failed to find any definitive documentation for that.) Yuck! Haha, that's Microsoft for you ;) ------------- PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1504786534 From duke at openjdk.org Wed Apr 12 07:49:19 2023 From: duke at openjdk.org (Milind Mantri) Date: Wed, 12 Apr 2023 07:49:19 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v56] In-Reply-To: References: Message-ID: On Thu, 6 Apr 2023 11:59:45 GMT, Roman Kennke wrote: >> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). >> >> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. >> >> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal protocols. >> >> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare. >> >> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. >> >> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. >> >> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. >> >> This change enables to simplify (and speed-up!) a lot of code: >> >> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. >> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR >> >> Also, and I might be mistaken here, this new lightweight locking would make synchronized work better with Loom: Because the lock-records are no longer scattered across the stack, but instead are densely packed into the lock-stack, it should be easy for a vthread to save its lock-stack upon unmounting and restore it when re-mounting. However, I am not sure about this, and this PR does not attempt to implement that support. >> >> Testing: >> - [x] tier1 x86_64 x aarch64 x +UseFastLocking >> - [x] tier2 x86_64 x aarch64 x +UseFastLocking >> - [x] tier3 x86_64 x aarch64 x +UseFastLocking >> - [x] tier4 x86_64 x aarch64 x +UseFastLocking >> - [x] tier1 x86_64 x aarch64 x -UseFastLocking >> - [x] tier2 x86_64 x aarch64 x -UseFastLocking >> - [x] tier3 x86_64 x aarch64 x -UseFastLocking >> - [x] tier4 x86_64 x aarch64 x -UseFastLocking >> - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet >> >> ### Performance >> >> #### Simple Microbenchmark >> >> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops. >> >> | | x86_64 | aarch64 | >> | -- | -- | -- | >> | -UseFastLocking | 20.651 | 20.764 | >> | +UseFastLocking | 18.896 | 18.908 | >> >> >> #### Renaissance >> >> ? | x86_64 | ? | ? | ? | aarch64 | ? | ? >> -- | -- | -- | -- | -- | -- | -- | -- >> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? >> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% >> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21% >> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% >> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% >> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% >> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% >> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%% >> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% >> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% >> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% >> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% >> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34% >> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% >> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% >> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% >> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% >> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% >> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% >> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% >> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% >> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > RISCV update src/hotspot/share/utilities/globalDefinitions.hpp line 1050: > 1048: // Legacy stack-locking, with monitors as 2nd tier > 1049: LEGACY = 1, > 1050: // New lightweight locing, with monitors as 2nd tier Suggestion: // New lightweight locking, with monitors as 2nd tier I was just passing by your PR. Pointing out a minor typo. Cheers! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1163659759 From duke at openjdk.org Wed Apr 12 07:56:35 2023 From: duke at openjdk.org (Afshin Zafari) Date: Wed, 12 Apr 2023 07:56:35 GMT Subject: RFR: 8305084: Remove the removal warnings for finalize() from test/hotspot/jtreg/serviceability/dcmd/gc/FinalizerInfoTest.java and RunFinalizationTest.java [v2] In-Reply-To: References: Message-ID: <4hqfUDPEqzCW-m8-qvTGjyMBEAiWsIMSXLODtLECZiM=.c07b0656-2793-4b31-bcf6-afee291d4955@github.com> On Tue, 11 Apr 2023 12:07:32 GMT, Afshin Zafari wrote: >> The `removal` warnings are suppressed out. >> Test: >> `FinalizerInfoTest` and `RunFinalizationTest` are executed locally. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > Remove the removal warnings for finalize() from test/hotspot/jtreg/serviceability/dcmd/gc/FinalizerInfoTest.java and RunFinalizationTest.java Thank you David and Chris for your reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13423#issuecomment-1504826674 From mdoerr at openjdk.org Wed Apr 12 09:10:43 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 12 Apr 2023 09:10:43 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v12] In-Reply-To: <8RVzDuEvl7ono94GeIvGJ1_ucB35VjayTJezgYfaUw4=.aae42a0f-116d-498a-ba59-95a3a52a9b41@github.com> References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> <8RVzDuEvl7ono94GeIvGJ1_ucB35VjayTJezgYfaUw4=.aae42a0f-116d-498a-ba59-95a3a52a9b41@github.com> Message-ID: <7kFdmkpwgMes1T3aGrG6-rE5ZCAhTxeBseoh3SkN1M4=.2fcf70ea-88d5-4138-9dca-2dfcdbb410e1@github.com> On Tue, 11 Apr 2023 21:09:43 GMT, Roger Riggs wrote: >> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. >> The enumeration values are defined to match those used in the build. >> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64` >> Note that `amd64` and `x86_64` in the build are represented by `X64`. >> The value of the system property `os.arch` is unchanged. >> >> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). >> Uses in `java.base` and a few others are included but other modules will be done in separate PRs. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Correct mapping and test of ppc64 Works on PPC64 Big Endian, now. However, little Endian fails: org.opentest4j.AssertionFailedError: Mismatch PPC64 == PPC64 vs isPPC64 ==> expected: but was: at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) at org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62) at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182) at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1152) at ArchTest.isArch(ArchTest.java:99) ... System property os.arch: "ppc64le", Architecture.current(): "PPC64" ------------- PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1504925182 From duke at openjdk.org Wed Apr 12 09:17:19 2023 From: duke at openjdk.org (Afshin Zafari) Date: Wed, 12 Apr 2023 09:17:19 GMT Subject: RFR: 8305083: Remove finalize() from test/hotspot/jtreg/vmTestbase/nsk/share/ and /jpda that are used in serviceability/dcmd/framework tests Message-ID: The `finalize()` method is removed from base classes/interfaces and are replaced by a Cleaner callback.. ------------- Commit messages: - 8305083: Remove finalize() from test/hotspot/jtreg/vmTestbase/nsk/share/ and /jpda that are used in serviceability/dcmd/framework tests Changes: https://git.openjdk.org/jdk/pull/13420/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13420&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8305083 Stats: 75 lines in 6 files changed: 45 ins; 9 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/13420.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13420/head:pull/13420 PR: https://git.openjdk.org/jdk/pull/13420 From duke at openjdk.org Wed Apr 12 09:19:51 2023 From: duke at openjdk.org (Afshin Zafari) Date: Wed, 12 Apr 2023 09:19:51 GMT Subject: RFR: 8305085: Remove finalize() from test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineFinalizer.java Message-ID: The whole test is removed. ------------- Commit messages: - 8305085: Remove finalize() from test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineFinalizer.java Changes: https://git.openjdk.org/jdk/pull/13422/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13422&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8305085 Stats: 73 lines in 1 file changed: 0 ins; 73 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13422.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13422/head:pull/13422 PR: https://git.openjdk.org/jdk/pull/13422 From sspitsyn at openjdk.org Wed Apr 12 10:13:49 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 12 Apr 2023 10:13:49 GMT Subject: RFR: 8257967: JFR: Events for loaded agents [v16] In-Reply-To: References: Message-ID: On Tue, 4 Apr 2023 14:39:19 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> We are adding support to let JFR report on Agents. >> >> #### Design >> >> An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize. >> >> A JavaAgent is an agent written in the Java programming language, using the APIs in the package [java.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html) >> >> A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services. >> >> To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples: >> >> // Command line >> jdk.JavaAgent { >> startTime = 12:31:19.789 (2023-03-08) >> name = "JavaAgent.jar" >> options = "foo=bar" >> dynamic = false >> initializationTime = 12:31:15.574 (2023-03-08) >> initializationDuration = 172 ms >> } >> >> // Dynamic load >> jdk.JavaAgent { >> startTime = 12:31:31.158 (2023-03-08) >> name = "JavaAgent.jar" >> options = "bar=baz" >> dynamic = true >> initializationTime = 12:31:31.037 (2023-03-08) >> initializationDuration = 64,1 ms >> } >> >> The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents. >> >> For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar. >> >> The "dynamic" field denotes if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true) >> >> "initializationTime" is the timestamp the JVM invoked the initialization method, and "initializationDuration" is the duration of executing the initialization method. >> >> "startTime" represents the time the JFR framework issued the periodic event; hence "initializationTime" will be earlier than "startTime". >> >> An agent can also be written in a native programming language using the [JVM Tools Interface (JVMTI)](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file. >> >> To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example: >> >> jdk.NativeAgent { >> startTime = 12:31:40.398 (2023-03-08) >> name = "jdwp" >> options = "transport=dt_socket,server=y,address=any,onjcmd=y" >> dynamic = false >> initializationTime = 12:31:36.142 (2023-03-08) >> initializationDuration = 0,00184 ms >> path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll" >> } >> >> The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported. >> >> The initialization of a native agent is performed by invoking an agent-specified callback routine. The "initializationTime" is when the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationDuration" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationDuration" will be 0. If the agent is loaded dynamically, "initializationDuration" is the time taken to execute the Agent_OnAttach callback. >> >> #### Implementation >> >> There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization ? as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before. >> >> Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize. >> >> When implementing this capability, it was necessary to refactor the code used to represent agents, AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp. >> >> The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp. >> >> The previous two lists that maintained "agents" (JVMTI) and "libraries" (Xrun) were not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced. >> >> Testing: jdk_jfr, tier 1 - 6 >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: > > renames src/hotspot/share/prims/jvmtiAgent.cpp line 265: > 263: // For statically linked agents we cant't rely on os_lib == nullptr because > 264: // statically linked agents could have a handle of RTLD_DEFAULT which == 0 on some platforms. > 265: // If this function returns true, then agent->is_static_lib().&& agent->is_loaded(). Nit: replace : ".&&" => "&&" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12923#discussion_r1163921271 From sspitsyn at openjdk.org Wed Apr 12 10:35:44 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 12 Apr 2023 10:35:44 GMT Subject: RFR: 8257967: JFR: Events for loaded agents [v16] In-Reply-To: References: Message-ID: On Tue, 4 Apr 2023 14:39:19 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> We are adding support to let JFR report on Agents. >> >> #### Design >> >> An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize. >> >> A JavaAgent is an agent written in the Java programming language, using the APIs in the package [java.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html) >> >> A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services. >> >> To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples: >> >> // Command line >> jdk.JavaAgent { >> startTime = 12:31:19.789 (2023-03-08) >> name = "JavaAgent.jar" >> options = "foo=bar" >> dynamic = false >> initializationTime = 12:31:15.574 (2023-03-08) >> initializationDuration = 172 ms >> } >> >> // Dynamic load >> jdk.JavaAgent { >> startTime = 12:31:31.158 (2023-03-08) >> name = "JavaAgent.jar" >> options = "bar=baz" >> dynamic = true >> initializationTime = 12:31:31.037 (2023-03-08) >> initializationDuration = 64,1 ms >> } >> >> The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents. >> >> For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar. >> >> The "dynamic" field denotes if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true) >> >> "initializationTime" is the timestamp the JVM invoked the initialization method, and "initializationDuration" is the duration of executing the initialization method. >> >> "startTime" represents the time the JFR framework issued the periodic event; hence "initializationTime" will be earlier than "startTime". >> >> An agent can also be written in a native programming language using the [JVM Tools Interface (JVMTI)](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file. >> >> To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example: >> >> jdk.NativeAgent { >> startTime = 12:31:40.398 (2023-03-08) >> name = "jdwp" >> options = "transport=dt_socket,server=y,address=any,onjcmd=y" >> dynamic = false >> initializationTime = 12:31:36.142 (2023-03-08) >> initializationDuration = 0,00184 ms >> path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll" >> } >> >> The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported. >> >> The initialization of a native agent is performed by invoking an agent-specified callback routine. The "initializationTime" is when the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationDuration" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationDuration" will be 0. If the agent is loaded dynamically, "initializationDuration" is the time taken to execute the Agent_OnAttach callback. >> >> #### Implementation >> >> There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization ? as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before. >> >> Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize. >> >> When implementing this capability, it was necessary to refactor the code used to represent agents, AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp. >> >> The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp. >> >> The previous two lists that maintained "agents" (JVMTI) and "libraries" (Xrun) were not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced. >> >> Testing: jdk_jfr, tier 1 - 6 >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: > > renames src/hotspot/share/prims/jvmtiAgent.cpp line 323: > 321: assert(agent != nullptr, "invariant"); > 322: if (!agent->is_loaded()) { > 323: if (!load_agent_from_executable(agent, on_load_symbols, num_symbol_entries)) { It feels like I'm missing something. We already checked and found at line 322 that `agent->is_loaded() == false`. Also, we have the comment at line 265: 265 // If this function returns true, then agent->is_static_lib().&& agent->is_loaded(). 266 static bool load_agent_from_executable(Agent* agent, const char* on_load_symbols[], size_t num_symbol_entries) { As the `agent->is_loaded() == false` then t he condition `agent->is_static_lib() && agent->is_loaded()` has to be `false` and can not be `true`. Then the if-check at line 323 is not needed and can be removed. Is it right? Otherwise, the comment at line 265 can be incorrect. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12923#discussion_r1163943712 From rkennke at openjdk.org Wed Apr 12 10:45:19 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 12 Apr 2023 10:45:19 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v57] In-Reply-To: References: Message-ID: > This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). > > What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. > > This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p rotocols. > > The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare. > > In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. > > One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. > > As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. > > This change enables to simplify (and speed-up!) a lot of code: > > - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. > - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR > > Also, and I might be mistaken here, this new lightweight locking would make synchronized work better with Loom: Because the lock-records are no longer scattered across the stack, but instead are densely packed into the lock-stack, it should be easy for a vthread to save its lock-stack upon unmounting and restore it when re-mounting. However, I am not sure about this, and this PR does not attempt to implement that support. > > Testing: > - [x] tier1 x86_64 x aarch64 x +UseFastLocking > - [x] tier2 x86_64 x aarch64 x +UseFastLocking > - [x] tier3 x86_64 x aarch64 x +UseFastLocking > - [x] tier4 x86_64 x aarch64 x +UseFastLocking > - [x] tier1 x86_64 x aarch64 x -UseFastLocking > - [x] tier2 x86_64 x aarch64 x -UseFastLocking > - [x] tier3 x86_64 x aarch64 x -UseFastLocking > - [x] tier4 x86_64 x aarch64 x -UseFastLocking > - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet > > ### Performance > > #### Simple Microbenchmark > > The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops. > > | | x86_64 | aarch64 | > | -- | -- | -- | > | -UseFastLocking | 20.651 | 20.764 | > | +UseFastLocking | 18.896 | 18.908 | > > > #### Renaissance > > ? | x86_64 | ? | ? | ? | aarch64 | ? | ? > -- | -- | -- | -- | -- | -- | -- | -- > ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? > AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% > Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21% > Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% > ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% > GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% > LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% > MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%% > NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% > PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% > FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% > FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% > ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34% > Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% > RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% > Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% > ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% > FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% > FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% Roman Kennke has updated the pull request incrementally with two additional commits since the last revision: - Bunch of comments and typos - Don't use NativeAccess in LockStack::contains() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10907/files - new: https://git.openjdk.org/jdk/pull/10907/files/d1c88261..cb260c1f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=56 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=55-56 Stats: 8 lines in 5 files changed: 4 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/10907.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/10907/head:pull/10907 PR: https://git.openjdk.org/jdk/pull/10907 From mgronlun at openjdk.org Wed Apr 12 10:47:09 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 12 Apr 2023 10:47:09 GMT Subject: RFR: 8257967: JFR: Events for loaded agents [v16] In-Reply-To: References: Message-ID: On Wed, 12 Apr 2023 10:31:37 GMT, Serguei Spitsyn wrote: >> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: >> >> renames > > src/hotspot/share/prims/jvmtiAgent.cpp line 323: > >> 321: assert(agent != nullptr, "invariant"); >> 322: if (!agent->is_loaded()) { >> 323: if (!load_agent_from_executable(agent, on_load_symbols, num_symbol_entries)) { > > It feels like I'm missing something. > We already checked and found at line 322 that `agent->is_loaded() == false`. > Also, we have the comment at line 265: > > 265 // If this function returns true, then agent->is_static_lib().&& agent->is_loaded(). > 266 static bool load_agent_from_executable(Agent* agent, const char* on_load_symbols[], size_t num_symbol_entries) { > > As the `agent->is_loaded() == false` then t he condition `agent->is_static_lib() && agent->is_loaded()` has to be `false` and can not be `true`. Then one of the if-checks at lines 322 and 323 is not needed and can be removed. Is it right? Otherwise, the comment at line 265 can be incorrect. Good observation, Serguei. It is because some paths call into lookup_On_load_Entry_point() twice. It is primarily the attempted conversion of xrun agents, the first invocation comes from JvmtiAgent::convert_xrun_agent(). This will have the agent "loaded". If there is an Agent_OnLoad function, the agent is converted (i.e. xrun removed). Then when the agent is to invoke the Agent_OnLoad function, there is a second invocation. Here a converted xrun library is already loaded, so I bypass attempting to load it again by checking the is_loaded() property. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12923#discussion_r1163954754 From sspitsyn at openjdk.org Wed Apr 12 11:06:49 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 12 Apr 2023 11:06:49 GMT Subject: RFR: 8257967: JFR: Events for loaded agents [v16] In-Reply-To: References: Message-ID: On Tue, 4 Apr 2023 14:39:19 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> We are adding support to let JFR report on Agents. >> >> #### Design >> >> An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize. >> >> A JavaAgent is an agent written in the Java programming language, using the APIs in the package [java.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html) >> >> A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services. >> >> To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples: >> >> // Command line >> jdk.JavaAgent { >> startTime = 12:31:19.789 (2023-03-08) >> name = "JavaAgent.jar" >> options = "foo=bar" >> dynamic = false >> initializationTime = 12:31:15.574 (2023-03-08) >> initializationDuration = 172 ms >> } >> >> // Dynamic load >> jdk.JavaAgent { >> startTime = 12:31:31.158 (2023-03-08) >> name = "JavaAgent.jar" >> options = "bar=baz" >> dynamic = true >> initializationTime = 12:31:31.037 (2023-03-08) >> initializationDuration = 64,1 ms >> } >> >> The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents. >> >> For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar. >> >> The "dynamic" field denotes if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true) >> >> "initializationTime" is the timestamp the JVM invoked the initialization method, and "initializationDuration" is the duration of executing the initialization method. >> >> "startTime" represents the time the JFR framework issued the periodic event; hence "initializationTime" will be earlier than "startTime". >> >> An agent can also be written in a native programming language using the [JVM Tools Interface (JVMTI)](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file. >> >> To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example: >> >> jdk.NativeAgent { >> startTime = 12:31:40.398 (2023-03-08) >> name = "jdwp" >> options = "transport=dt_socket,server=y,address=any,onjcmd=y" >> dynamic = false >> initializationTime = 12:31:36.142 (2023-03-08) >> initializationDuration = 0,00184 ms >> path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll" >> } >> >> The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported. >> >> The initialization of a native agent is performed by invoking an agent-specified callback routine. The "initializationTime" is when the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationDuration" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationDuration" will be 0. If the agent is loaded dynamically, "initializationDuration" is the time taken to execute the Agent_OnAttach callback. >> >> #### Implementation >> >> There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization ? as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before. >> >> Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize. >> >> When implementing this capability, it was necessary to refactor the code used to represent agents, AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp. >> >> The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp. >> >> The previous two lists that maintained "agents" (JVMTI) and "libraries" (Xrun) were not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced. >> >> Testing: jdk_jfr, tier 1 - 6 >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: > > renames I've posted a couple of questions now. There can be more later. Sorry for the latency again. src/hotspot/share/prims/jvmtiAgent.cpp line 357: > 355: vm_exit_during_initialization("Could not find JVM_OnLoad or Agent_OnLoad function in the library", name()); > 356: } > 357: _xrun = false; // converted Just questions to understand it better. Neither `JVM_Onload` nor `Agent_Onload` entry points are stored after these lookups. It means that in order to be called later (as the comment at line 350 says) they have to be looked up again. Is it right? Was it the same originally? ------------- PR Review: https://git.openjdk.org/jdk/pull/12923#pullrequestreview-1381065121 PR Review Comment: https://git.openjdk.org/jdk/pull/12923#discussion_r1163972452 From mgronlun at openjdk.org Wed Apr 12 11:11:41 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 12 Apr 2023 11:11:41 GMT Subject: RFR: 8257967: JFR: Events for loaded agents [v16] In-Reply-To: References: Message-ID: On Tue, 4 Apr 2023 14:39:19 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> We are adding support to let JFR report on Agents. >> >> #### Design >> >> An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize. >> >> A JavaAgent is an agent written in the Java programming language, using the APIs in the package [java.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html) >> >> A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services. >> >> To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples: >> >> // Command line >> jdk.JavaAgent { >> startTime = 12:31:19.789 (2023-03-08) >> name = "JavaAgent.jar" >> options = "foo=bar" >> dynamic = false >> initializationTime = 12:31:15.574 (2023-03-08) >> initializationDuration = 172 ms >> } >> >> // Dynamic load >> jdk.JavaAgent { >> startTime = 12:31:31.158 (2023-03-08) >> name = "JavaAgent.jar" >> options = "bar=baz" >> dynamic = true >> initializationTime = 12:31:31.037 (2023-03-08) >> initializationDuration = 64,1 ms >> } >> >> The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents. >> >> For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar. >> >> The "dynamic" field denotes if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true) >> >> "initializationTime" is the timestamp the JVM invoked the initialization method, and "initializationDuration" is the duration of executing the initialization method. >> >> "startTime" represents the time the JFR framework issued the periodic event; hence "initializationTime" will be earlier than "startTime". >> >> An agent can also be written in a native programming language using the [JVM Tools Interface (JVMTI)](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file. >> >> To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example: >> >> jdk.NativeAgent { >> startTime = 12:31:40.398 (2023-03-08) >> name = "jdwp" >> options = "transport=dt_socket,server=y,address=any,onjcmd=y" >> dynamic = false >> initializationTime = 12:31:36.142 (2023-03-08) >> initializationDuration = 0,00184 ms >> path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll" >> } >> >> The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported. >> >> The initialization of a native agent is performed by invoking an agent-specified callback routine. The "initializationTime" is when the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationDuration" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationDuration" will be 0. If the agent is loaded dynamically, "initializationDuration" is the time taken to execute the Agent_OnAttach callback. >> >> #### Implementation >> >> There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization ? as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before. >> >> Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize. >> >> When implementing this capability, it was necessary to refactor the code used to represent agents, AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp. >> >> The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp. >> >> The previous two lists that maintained "agents" (JVMTI) and "libraries" (Xrun) were not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced. >> >> Testing: jdk_jfr, tier 1 - 6 >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: > > renames > Thank you for having a look. I think I have answered them. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12923#issuecomment-1505086800 From mgronlun at openjdk.org Wed Apr 12 11:11:45 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 12 Apr 2023 11:11:45 GMT Subject: RFR: 8257967: JFR: Events for loaded agents [v16] In-Reply-To: References: Message-ID: On Wed, 12 Apr 2023 11:01:43 GMT, Serguei Spitsyn wrote: >> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: >> >> renames > > src/hotspot/share/prims/jvmtiAgent.cpp line 357: > >> 355: vm_exit_during_initialization("Could not find JVM_OnLoad or Agent_OnLoad function in the library", name()); >> 356: } >> 357: _xrun = false; // converted > > Just questions to understand it better. > Neither `JVM_Onload` nor `Agent_Onload` entry points are stored after these lookups. It means that in order to be called later (as the comment at line 350 says) they have to be looked up again. > Is it right? Was it the same originally? The entry points are not saved and so have to be looked up again. It was the same originally. That is why there is a check and branch on agent->is_loaded(). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12923#discussion_r1163979282 From lucy at openjdk.org Wed Apr 12 11:32:43 2023 From: lucy at openjdk.org (Lutz Schmidt) Date: Wed, 12 Apr 2023 11:32:43 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v10] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Wed, 12 Apr 2023 03:44:45 GMT, Amit Kumar wrote: > Another remark: Old JDK on s390 used "os.arch = zArch_64", current one "os.arch = s390x". @offamitkumar: You probably want to take a look. zArch_64 is not relevant/not used in the OpenJDK port to IBM System z. As noted elsewhere in the PR, it's the architecture name that was used in the initial, proprietary port by SAP. I found just one occurrence of the string in the head revision, and that was in test/lib/jdk/test/lib/Platform.java. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1505110504 From alanb at openjdk.org Wed Apr 12 14:58:36 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 12 Apr 2023 14:58:36 GMT Subject: RFR: 8299414: JVMTI FollowReferences should support references from VirtualThread stack [v7] In-Reply-To: References: <6oQOD_egcB3HyuagMWGSPLjKSE3JkaI2K2WOsDK1Cww=.c568223b-5100-4425-a4b7-defbd812a9ff@github.com> Message-ID: On Wed, 12 Apr 2023 01:12:49 GMT, Alex Menkov wrote: >> The fix updates JVMTI FollowReferences implementation to report references from virtual threads: >> - unmounted vthreads are detected and reported as JVMTI_HEAP_REFERENCE_THREAD; >> - stack references for unmounted VT are reported as JVMTI_HEAP_REFERENCE_STACK_LOCAL/JVMTI_HEAP_REFERENCE_JNI_LOCAL; >> - stacks of mounted vthreads are splitted into 2 parts (virtual thread stack and carrier thread stack), references are reported with correct thread id/class tag/object tags/frame depth; >> - common code to handle stack frames are moved into separate class; > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > Fixed indent in collect_vthread_stack_roots In the spec for FollowReferences, it says that the heap roots include "references from thread stacks". There is a similar sentence in the deprecated IterateOverReachableObjects function. We should decide whether these sentences need to be changed to say "platform thread stacks". ------------- PR Comment: https://git.openjdk.org/jdk/pull/13254#issuecomment-1505423293 From rriggs at openjdk.org Wed Apr 12 17:31:49 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 12 Apr 2023 17:31:49 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v13] In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: > Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. > The enumeration values are defined to match those used in the build. > The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64` > Note that `amd64` and `x86_64` in the build are represented by `X64`. > The value of the system property `os.arch` is unchanged. > > The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). > Uses in `java.base` and a few others are included but other modules will be done in separate PRs. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Fixed isPPC64(). Consolidated switch cases in ArchTest. Moved mapping of build TARGET_OS and TARGET_CPU to the build to avoid multiple mappings in more than one place. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13357/files - new: https://git.openjdk.org/jdk/pull/13357/files/71135e3b..0cd6ce70 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=11-12 Stats: 60 lines in 5 files changed: 19 ins; 22 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/13357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13357/head:pull/13357 PR: https://git.openjdk.org/jdk/pull/13357 From iklam at openjdk.org Wed Apr 12 17:44:42 2023 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 12 Apr 2023 17:44:42 GMT Subject: RFR: 8298048: Combine CDS archive heap into a single block [v4] In-Reply-To: References: Message-ID: > This PR combines the "open" and "closed" regions of the CDS archive heap into a single region. This significantly simplifies the implementation, making it more compatible with non-G1 collectors. There's a net removal of ~1000 lines in src code and another ~1200 lines of tests. > > **Notes for reviewers:** > - Most of the code changes in CDS are removing the handling of "open" vs "closed" objects. > - Reviewers can start with ArchiveHeapWriter::copy_source_objs_to_buffer(). > - It might be easier to see the diff with whitespaces off. > - There are two major changes in the G1 code > - The archived objects are now stored in the "old" region (see g1CollectedHeap.cpp in [58d720e](https://github.com/openjdk/jdk/pull/13284/commits/58d720e294bb36f21cb88cddde724ed2b9e93770)) > - The majority of the other changes are removal of the "archive" region type (see heapRegionType.hpp). For ease of review, such code is isolated in [a852dfb](https://github.com/openjdk/jdk/pull/13284/commits/a852dfbbf5ff56e035399f7cc3704f29e76697f6) > - Testing changes: > - Now the archived java objects can move, along with the "old" regions that contain them. It's no longer possible to test whether a heap object came from CDS. As a result, the `WhiteBox.isShared(Object o)` API has been removed. > - Many tests that uses this API are removed. Most of them were written during early development of CDS archived objects and are no longer relevant. > > **Testing:** > - Mach5 tiers 1 ~ 7 Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @ashu-mehra comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13284/files - new: https://git.openjdk.org/jdk/pull/13284/files/b693d27c..8ce6953e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13284&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13284&range=02-03 Stats: 6 lines in 1 file changed: 0 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13284.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13284/head:pull/13284 PR: https://git.openjdk.org/jdk/pull/13284 From rriggs at openjdk.org Wed Apr 12 17:47:21 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 12 Apr 2023 17:47:21 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v12] In-Reply-To: <7kFdmkpwgMes1T3aGrG6-rE5ZCAhTxeBseoh3SkN1M4=.2fcf70ea-88d5-4138-9dca-2dfcdbb410e1@github.com> References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> <8RVzDuEvl7ono94GeIvGJ1_ucB35VjayTJezgYfaUw4=.aae42a0f-116d-498a-ba59-95a3a52a9b41@github.com> <7kFdmkpwgMes1T3aGrG6-rE5ZCAhTxeBseoh3SkN1M4=.2fcf70ea-88d5-4138-9dca-2dfcdbb410e1@github.com> Message-ID: On Wed, 12 Apr 2023 09:07:34 GMT, Martin Doerr wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Correct mapping and test of ppc64 > > Works on PPC64 Big Endian, now. However, little Endian fails: > STARTED ArchTest::isArch '[6] PPC64, false' > org.opentest4j.AssertionFailedError: Mismatch PPC64 == PPC64 vs isPPC64 ==> expected: but was: > at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:55) > at org.junit.jupiter.api.AssertionUtils.failNotEqual(AssertionUtils.java:62) > at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182) > at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1152) > at ArchTest.isArch(ArchTest.java:99) > ... > System property os.arch: "ppc64le", Architecture.current(): "PPC64" @TheRealMDoerr Thanks for the ppc64 feedback and testing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1505685254 From lmesnik at openjdk.org Wed Apr 12 17:48:15 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 12 Apr 2023 17:48:15 GMT Subject: Integrated: 8304834: Fix wrapper insertion in TestScaffold.parseArgs(String args[]) In-Reply-To: <7PDwD7zFu8CYojj6LDm0qVMlVHKuJNmAzxKaWdjGuvY=.cf39e296-777b-4653-bc19-7276a7da28e8@github.com> References: <7PDwD7zFu8CYojj6LDm0qVMlVHKuJNmAzxKaWdjGuvY=.cf39e296-777b-4653-bc19-7276a7da28e8@github.com> Message-ID: <1GV0UW2ad7gkk2pQ-8dzBDS2Tu00pi-GuhlzTNikO0s=.817e0a83-7a21-4778-8e93-bf52c2790db5@github.com> On Thu, 23 Mar 2023 21:49:55 GMT, Leonid Mesnik wrote: > The TestScaffold incorrectly parse options, it should insert wrapper class between VM options and applications classame. This pull request has now been integrated. Changeset: bc151633 Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/bc15163386659bfd549576817b4efe7307261ea8 Stats: 52 lines in 3 files changed: 23 ins; 8 del; 21 mod 8304834: Fix wrapper insertion in TestScaffold.parseArgs(String args[]) Reviewed-by: cjplummer, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/13170 From iklam at openjdk.org Wed Apr 12 17:59:23 2023 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 12 Apr 2023 17:59:23 GMT Subject: RFR: 8298048: Combine CDS archive heap into a single block [v5] In-Reply-To: References: Message-ID: <3wLQHgnmbwNVuVVZDe1Nlt6V6upyOrUXDxKKkMEOT8Y=.9a9c2b21-e683-4bd0-94ee-8ebcaf1b8333@github.com> > This PR combines the "open" and "closed" regions of the CDS archive heap into a single region. This significantly simplifies the implementation, making it more compatible with non-G1 collectors. There's a net removal of ~1000 lines in src code and another ~1200 lines of tests. > > **Notes for reviewers:** > - Most of the code changes in CDS are removing the handling of "open" vs "closed" objects. > - Reviewers can start with ArchiveHeapWriter::copy_source_objs_to_buffer(). > - It might be easier to see the diff with whitespaces off. > - There are two major changes in the G1 code > - The archived objects are now stored in the "old" region (see g1CollectedHeap.cpp in [58d720e](https://github.com/openjdk/jdk/pull/13284/commits/58d720e294bb36f21cb88cddde724ed2b9e93770)) > - The majority of the other changes are removal of the "archive" region type (see heapRegionType.hpp). For ease of review, such code is isolated in [a852dfb](https://github.com/openjdk/jdk/pull/13284/commits/a852dfbbf5ff56e035399f7cc3704f29e76697f6) > - Testing changes: > - Now the archived java objects can move, along with the "old" regions that contain them. It's no longer possible to test whether a heap object came from CDS. As a result, the `WhiteBox.isShared(Object o)` API has been removed. > - Many tests that uses this API are removed. Most of them were written during early development of CDS archived objects and are no longer relevant. > > **Testing:** > - Mach5 tiers 1 ~ 7 Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @ashu-mehra comments; some clean up ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13284/files - new: https://git.openjdk.org/jdk/pull/13284/files/8ce6953e..30542e53 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13284&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13284&range=03-04 Stats: 11 lines in 3 files changed: 1 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/13284.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13284/head:pull/13284 PR: https://git.openjdk.org/jdk/pull/13284 From iklam at openjdk.org Wed Apr 12 17:59:25 2023 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 12 Apr 2023 17:59:25 GMT Subject: RFR: 8298048: Combine CDS archive heap into a single block In-Reply-To: <3ybhZpVsw5iki0H2OkFswEIqFfEFC0YwNhp9chzu5yU=.8b29a446-3be0-4ae8-a8d0-948003be0411@github.com> References: <3ybhZpVsw5iki0H2OkFswEIqFfEFC0YwNhp9chzu5yU=.8b29a446-3be0-4ae8-a8d0-948003be0411@github.com> Message-ID: On Tue, 11 Apr 2023 21:47:40 GMT, Ashutosh Mehra wrote: > cds changes look good! just few nitpicks. Thanks for the review. I've incorporated your suggestions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13284#issuecomment-1505698259 From mdoerr at openjdk.org Wed Apr 12 18:20:45 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 12 Apr 2023 18:20:45 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v13] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: <-7iBud-60uLA3dCL1rKYgWjUok8t7rcMA8XDD2P9RoM=.606c361c-f677-4729-9537-e66c1e1c3ff3@github.com> On Wed, 12 Apr 2023 17:31:49 GMT, Roger Riggs wrote: >> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. >> The enumeration values are defined to match those used in the build. >> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64` >> Note that `amd64` and `x86_64` in the build are represented by `X64`. >> The value of the system property `os.arch` is unchanged. >> >> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). >> Uses in `java.base` and a few others are included but other modules will be done in separate PRs. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Fixed isPPC64(). > Consolidated switch cases in ArchTest. > Moved mapping of build TARGET_OS and TARGET_CPU to the build > to avoid multiple mappings in more than one place. Thanks! PPC64 parts look good and the test has passed on both endianness versions. ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13357#pullrequestreview-1381866371 From cjplummer at openjdk.org Wed Apr 12 19:18:31 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 12 Apr 2023 19:18:31 GMT Subject: RFR: 8305083: Remove finalize() from test/hotspot/jtreg/vmTestbase/nsk/share/ and /jpda that are used in serviceability/dcmd/framework tests In-Reply-To: References: Message-ID: On Tue, 11 Apr 2023 08:16:29 GMT, Afshin Zafari wrote: > The `finalize()` method is removed from base classes/interfaces and are replaced by a Cleaner callback.. The interaction of Finalizable, FinalizableObject, Finalizer, and FinalizerThread is hard to follow, so it is hard to tell if your changes still honor the needed "finalization". Did you figure this all out? Perhaps you can summarize how it worked properly when using finalize(), and why it continues to work after your changes. I'm especially suspicious of your removal of the finalize() call in FinalizableObject. I don't see how this is made up for elsewhere in your changes. Is it because finalizeAtExit() is always overridden to do the right thing? If so, perhaps it should be made abstract in FinalizableObject. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13420#issuecomment-1505796926 From rkennke at openjdk.org Wed Apr 12 19:21:11 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 12 Apr 2023 19:21:11 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v58] In-Reply-To: References: Message-ID: <12a9gxyIsM9NIHJyjPCqEcdtZGJPO9lgUxQdm6eYy70=.50d37ab5-e76c-4dc9-9d45-0cc60ddc7429@github.com> > This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). > > What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. > > This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p rotocols. > > The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare. > > In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. > > One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. > > As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. > > This change enables to simplify (and speed-up!) a lot of code: > > - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. > - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR > > Also, and I might be mistaken here, this new lightweight locking would make synchronized work better with Loom: Because the lock-records are no longer scattered across the stack, but instead are densely packed into the lock-stack, it should be easy for a vthread to save its lock-stack upon unmounting and restore it when re-mounting. However, I am not sure about this, and this PR does not attempt to implement that support. > > Testing: > - [x] tier1 x86_64 x aarch64 x +UseFastLocking > - [x] tier2 x86_64 x aarch64 x +UseFastLocking > - [x] tier3 x86_64 x aarch64 x +UseFastLocking > - [x] tier4 x86_64 x aarch64 x +UseFastLocking > - [x] tier1 x86_64 x aarch64 x -UseFastLocking > - [x] tier2 x86_64 x aarch64 x -UseFastLocking > - [x] tier3 x86_64 x aarch64 x -UseFastLocking > - [x] tier4 x86_64 x aarch64 x -UseFastLocking > - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet > > ### Performance > > #### Simple Microbenchmark > > The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops. > > | | x86_64 | aarch64 | > | -- | -- | -- | > | -UseFastLocking | 20.651 | 20.764 | > | +UseFastLocking | 18.896 | 18.908 | > > > #### Renaissance > > ? | x86_64 | ? | ? | ? | aarch64 | ? | ? > -- | -- | -- | -- | -- | -- | -- | -- > ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? > AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% > Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21% > Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% > ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% > GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% > LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% > MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%% > NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% > PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% > FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% > FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% > ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34% > Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% > RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% > Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% > ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% > FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% > FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% Roman Kennke has updated the pull request incrementally with two additional commits since the last revision: - Replace UseHeavyMonitor with LockingMode == LM_MONITOR - Prefix LockingMode constants with LM_* ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10907/files - new: https://git.openjdk.org/jdk/pull/10907/files/cb260c1f..f5451943 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=57 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=56-57 Stats: 778 lines in 43 files changed: 257 ins; 265 del; 256 mod Patch: https://git.openjdk.org/jdk/pull/10907.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/10907/head:pull/10907 PR: https://git.openjdk.org/jdk/pull/10907 From cjplummer at openjdk.org Wed Apr 12 19:21:35 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 12 Apr 2023 19:21:35 GMT Subject: RFR: 8305085: Remove finalize() from test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineFinalizer.java In-Reply-To: References: Message-ID: On Tue, 11 Apr 2023 09:03:49 GMT, Afshin Zafari wrote: > The whole test is removed. I'm not sure of the current plan to actually remove finalize() support, but unless it is going away in 21, it seems this test should remain in place for now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13422#issuecomment-1505800331 From amenkov at openjdk.org Wed Apr 12 20:19:36 2023 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 12 Apr 2023 20:19:36 GMT Subject: RFR: 8299414: JVMTI FollowReferences should support references from VirtualThread stack [v7] In-Reply-To: References: <6oQOD_egcB3HyuagMWGSPLjKSE3JkaI2K2WOsDK1Cww=.c568223b-5100-4425-a4b7-defbd812a9ff@github.com> Message-ID: On Wed, 12 Apr 2023 14:55:59 GMT, Alan Bateman wrote: > In the spec for FollowReferences, it says that the heap roots include "references from thread stacks". There is a similar sentence in the deprecated IterateOverReachableObjects function. We should decide whether these sentences need to be changed to say "platform thread stacks". IterateOverReachableObjects spec is stricter. It contains: `Roots are always reported to the profiler before any object references are reported.` That is the reason this fix fixes only FollowReferences (stack references for unmounted VTs are collected only when is_advanced_heap_walk() is true), because otherwise we'd have to find all stack references before visit the object, i.e. it requires full heap scan in the beginning. I don't care much about deprecated IterateOverReachableObjects (it shouldn't' be used by modern agents), but I think change in the spec would allow to fix IterateOverReachableObjects as well ------------- PR Comment: https://git.openjdk.org/jdk/pull/13254#issuecomment-1505869437 From jiangli at openjdk.org Wed Apr 12 23:41:39 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 12 Apr 2023 23:41:39 GMT Subject: RFR: 8305935: Resolve multiple definition of 'jmm_' when statically linking with JDK native libraries Message-ID: <97aWCpgt7_5qWV56OxZ_nG3jmZQ_aJHJlbYFpuhV9nc=.d3219cfa-de87-441d-bde7-0b560047984e@github.com> Rename 'jmm_' to 'jmm__management_ext' in libmanagement_ext to resolve related linker errors when statically linking with both libmanagement and libmanagement_ext. ------------- Commit messages: - 8305935: Resolve multiple definition of 'jmm_' when statically linking with JDK native libraries Changes: https://git.openjdk.org/jdk/pull/13451/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13451&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8305935 Stats: 28 lines in 7 files changed: 0 ins; 0 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/13451.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13451/head:pull/13451 PR: https://git.openjdk.org/jdk/pull/13451 From dholmes at openjdk.org Thu Apr 13 05:49:37 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 13 Apr 2023 05:49:37 GMT Subject: RFR: 8305936: JavaThread::create_system_thread_object has unused is_visible argument Message-ID: Please review this simple cleanup of an unused parameter in `create_system_thread_object`. Details are in JBS. Testing: tiers 1-3 Thanks. ------------- Commit messages: - 8305936: JavaThread::create_system_thread_object has unused is_visible argument Changes: https://git.openjdk.org/jdk/pull/13455/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13455&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8305936 Stats: 17 lines in 9 files changed: 0 ins; 2 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/13455.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13455/head:pull/13455 PR: https://git.openjdk.org/jdk/pull/13455 From alanb at openjdk.org Thu Apr 13 06:19:32 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 13 Apr 2023 06:19:32 GMT Subject: RFR: 8305936: JavaThread::create_system_thread_object has unused is_visible argument In-Reply-To: References: Message-ID: <76L-hhJOUzq5PZrz4ky2gi_HaDQ-nI3f9Bs0WZHdLzA=.14d85a40-45b8-4e45-91e1-435787acee81@github.com> On Thu, 13 Apr 2023 05:41:31 GMT, David Holmes wrote: > Please review this simple cleanup of an unused parameter in `create_system_thread_object`. Details are in JBS. > > Testing: tiers 1-3 > > Thanks. Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13455#pullrequestreview-1382703726 From dholmes at openjdk.org Thu Apr 13 06:32:39 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 13 Apr 2023 06:32:39 GMT Subject: RFR: 8299414: JVMTI FollowReferences should support references from VirtualThread stack [v7] In-Reply-To: References: <6oQOD_egcB3HyuagMWGSPLjKSE3JkaI2K2WOsDK1Cww=.c568223b-5100-4425-a4b7-defbd812a9ff@github.com> Message-ID: On Wed, 12 Apr 2023 14:55:59 GMT, Alan Bateman wrote: >> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed indent in collect_vthread_stack_roots > > In the spec for FollowReferences, it says that the heap roots include "references from thread stacks". There is a similar sentence in the deprecated IterateOverReachableObjects function. We should decide whether these sentences need to be changed to say "platform thread stacks". @AlanBateman as virtual threads have already been defined to not be GC roots aka "heap roots" then it would seem the spec does need adjusting to say "platform threads". ------------- PR Comment: https://git.openjdk.org/jdk/pull/13254#issuecomment-1506420491 From dholmes at openjdk.org Thu Apr 13 06:47:32 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 13 Apr 2023 06:47:32 GMT Subject: RFR: 8305083: Remove finalize() from test/hotspot/jtreg/vmTestbase/nsk/share/ and /jpda that are used in serviceability/dcmd/framework tests In-Reply-To: References: Message-ID: On Wed, 12 Apr 2023 19:16:14 GMT, Chris Plummer wrote: > The interaction of Finalizable, FinalizableObject, Finalizer, and FinalizerThread is hard to follow, These classes implement a cleanup-at-vm-exit mechanism, which uses `finalize` as the cleanup method. It is unclear if the classes that implement `FinalizableObject` can actually get cleaned up before VM exit through normal GC and execution of finalizers. Simply adding a Cleaner does not provide the cleanup-at-vm-exit functionality. You need to rename Finaliz* to Clean* and keep all these classes, as well as adding a Cleaner - which should be done as part of CleanableObject. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13420#issuecomment-1506435408 From dholmes at openjdk.org Thu Apr 13 06:50:33 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 13 Apr 2023 06:50:33 GMT Subject: RFR: 8305085: Remove finalize() from test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineFinalizer.java In-Reply-To: References: Message-ID: On Wed, 12 Apr 2023 19:19:01 GMT, Chris Plummer wrote: >> The whole test is removed. > > I'm not sure of the current plan to actually remove finalize() support, but unless it is going away in 21, it seems this test should remain in place for now. I agree with @plummercj this is a test of finalization and so should be kept (with the warning suppressed) until finalization itself is removed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13422#issuecomment-1506438120 From dholmes at openjdk.org Thu Apr 13 06:59:33 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 13 Apr 2023 06:59:33 GMT Subject: RFR: 8305935: Resolve multiple definition of 'jmm_' when statically linking with JDK native libraries In-Reply-To: <97aWCpgt7_5qWV56OxZ_nG3jmZQ_aJHJlbYFpuhV9nc=.d3219cfa-de87-441d-bde7-0b560047984e@github.com> References: <97aWCpgt7_5qWV56OxZ_nG3jmZQ_aJHJlbYFpuhV9nc=.d3219cfa-de87-441d-bde7-0b560047984e@github.com> Message-ID: On Wed, 12 Apr 2023 23:35:02 GMT, Jiangli Zhou wrote: > Rename 'jmm_' to 'jmm__management_ext' in libmanagement_ext to resolve related linker errors when statically linking with both libmanagement and libmanagement_ext. src/jdk.management/share/native/libmanagement_ext/management_ext.c line 36: > 34: const JmmInterface* jmm_interface_management_ext = NULL; > 35: static JavaVM* jvm = NULL; > 36: jint jmm_version_management_ext = 0; Is there not a way to stop these from being exported from the library, as I assume they are not actually intended for external use. ?? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13451#discussion_r1165084734 From dholmes at openjdk.org Thu Apr 13 07:00:32 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 13 Apr 2023 07:00:32 GMT Subject: RFR: 8305936: JavaThread::create_system_thread_object has unused is_visible argument In-Reply-To: <76L-hhJOUzq5PZrz4ky2gi_HaDQ-nI3f9Bs0WZHdLzA=.14d85a40-45b8-4e45-91e1-435787acee81@github.com> References: <76L-hhJOUzq5PZrz4ky2gi_HaDQ-nI3f9Bs0WZHdLzA=.14d85a40-45b8-4e45-91e1-435787acee81@github.com> Message-ID: On Thu, 13 Apr 2023 06:17:00 GMT, Alan Bateman wrote: >> Please review this simple cleanup of an unused parameter in `create_system_thread_object`. Details are in JBS. >> >> Testing: tiers 1-3 >> >> Thanks. > > Marked as reviewed by alanb (Reviewer). Thanks for the review @AlanBateman ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13455#issuecomment-1506449282 From cjplummer at openjdk.org Thu Apr 13 07:15:39 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 13 Apr 2023 07:15:39 GMT Subject: RFR: 8299414: JVMTI FollowReferences should support references from VirtualThread stack [v7] In-Reply-To: References: <6oQOD_egcB3HyuagMWGSPLjKSE3JkaI2K2WOsDK1Cww=.c568223b-5100-4425-a4b7-defbd812a9ff@github.com> Message-ID: On Wed, 12 Apr 2023 14:55:59 GMT, Alan Bateman wrote: >> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed indent in collect_vthread_stack_roots > > In the spec for FollowReferences, it says that the heap roots include "references from thread stacks". There is a similar sentence in the deprecated IterateOverReachableObjects function. We should decide whether these sentences need to be changed to say "platform thread stacks". > @AlanBateman as virtual threads have already been defined to not be GC roots aka "heap roots" then it would seem the spec does need adjusting to say "platform threads". I know the implementation of virtual threads in hotspot does not treat virtual threads as GC roots w.r.t. garbage collection. However, that's a JVM implementation detail, and I'm not so sure I would extend that to imply that "virtual threads have already been defined to not be GC roots" from a spec perspective. Do we actually say that anywhere in a spec? We have a similar situation with hprof, and the current plan is to include a `HPROF_GC_ROOT_THREAD_OBJ` record for each virtual thread (and accompanying set of `HPROF_GC_ROOT_JAVA_FRAME` records for the stack). In other words, virtual threads will be GC roots for any tool doing analysis of the hprof heap dump. Note that decisions in this area are very much in flux, and we are also considering making it optional whether or not hprof treats virtual threads in this manner. My point isn't to hash out hprof in this discussion, but just to make sure we differentiate between spec and implementation when it comes to treating virtual threads as roots. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13254#issuecomment-1506465610 From dholmes at openjdk.org Thu Apr 13 07:25:42 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 13 Apr 2023 07:25:42 GMT Subject: RFR: 8299414: JVMTI FollowReferences should support references from VirtualThread stack [v7] In-Reply-To: References: <6oQOD_egcB3HyuagMWGSPLjKSE3JkaI2K2WOsDK1Cww=.c568223b-5100-4425-a4b7-defbd812a9ff@github.com> Message-ID: On Wed, 12 Apr 2023 01:12:49 GMT, Alex Menkov wrote: >> The fix updates JVMTI FollowReferences implementation to report references from virtual threads: >> - unmounted vthreads are detected and reported as JVMTI_HEAP_REFERENCE_THREAD; >> - stack references for unmounted VT are reported as JVMTI_HEAP_REFERENCE_STACK_LOCAL/JVMTI_HEAP_REFERENCE_JNI_LOCAL; >> - stacks of mounted vthreads are splitted into 2 parts (virtual thread stack and carrier thread stack), references are reported with correct thread id/class tag/object tags/frame depth; >> - common code to handle stack frames are moved into separate class; > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > Fixed indent in collect_vthread_stack_roots I don't see how you can make a distinction between spec and implementation in this particular area - an object is either a GC root or it is not. If it is then that has implications for reachability as well as these traversal API's. Having two different notions of "root" will just lead to confusion. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13254#issuecomment-1506477528 From rkennke at openjdk.org Thu Apr 13 07:30:26 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 13 Apr 2023 07:30:26 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v59] In-Reply-To: References: Message-ID: <1I0RTRTux5ZmqOwFkLGlzB5utmIliV7c4U74daaL9P0=.bc46d7fe-dde9-4698-80ab-a946c750b714@github.com> > This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). > > What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. > > This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p rotocols. > > The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare. > > In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. > > One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. > > As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. > > This change enables to simplify (and speed-up!) a lot of code: > > - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. > - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR > > Also, and I might be mistaken here, this new lightweight locking would make synchronized work better with Loom: Because the lock-records are no longer scattered across the stack, but instead are densely packed into the lock-stack, it should be easy for a vthread to save its lock-stack upon unmounting and restore it when re-mounting. However, I am not sure about this, and this PR does not attempt to implement that support. > > Testing: > - [x] tier1 x86_64 x aarch64 x +UseFastLocking > - [x] tier2 x86_64 x aarch64 x +UseFastLocking > - [x] tier3 x86_64 x aarch64 x +UseFastLocking > - [x] tier4 x86_64 x aarch64 x +UseFastLocking > - [x] tier1 x86_64 x aarch64 x -UseFastLocking > - [x] tier2 x86_64 x aarch64 x -UseFastLocking > - [x] tier3 x86_64 x aarch64 x -UseFastLocking > - [x] tier4 x86_64 x aarch64 x -UseFastLocking > - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet > > ### Performance > > #### Simple Microbenchmark > > The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops. > > | | x86_64 | aarch64 | > | -- | -- | -- | > | -UseFastLocking | 20.651 | 20.764 | > | +UseFastLocking | 18.896 | 18.908 | > > > #### Renaissance > > ? | x86_64 | ? | ? | ? | aarch64 | ? | ? > -- | -- | -- | -- | -- | -- | -- | -- > ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? > AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% > Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21% > Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% > ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% > GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% > LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% > MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%% > NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% > PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% > FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% > FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% > ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34% > Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% > RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% > Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% > ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% > FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% > FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: A few more LM_ prefixes in 32bit code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10907/files - new: https://git.openjdk.org/jdk/pull/10907/files/f5451943..db4ca102 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=58 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=57-58 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/10907.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/10907/head:pull/10907 PR: https://git.openjdk.org/jdk/pull/10907 From kbarrett at openjdk.org Thu Apr 13 08:51:32 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 13 Apr 2023 08:51:32 GMT Subject: RFR: 8305936: JavaThread::create_system_thread_object has unused is_visible argument In-Reply-To: References: Message-ID: On Thu, 13 Apr 2023 05:41:31 GMT, David Holmes wrote: > Please review this simple cleanup of an unused parameter in `create_system_thread_object`. Details are in JBS. > > Testing: tiers 1-3 > > Thanks. Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13455#pullrequestreview-1382942892 From alanb at openjdk.org Thu Apr 13 09:59:37 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 13 Apr 2023 09:59:37 GMT Subject: RFR: 8299414: JVMTI FollowReferences should support references from VirtualThread stack [v7] In-Reply-To: References: <6oQOD_egcB3HyuagMWGSPLjKSE3JkaI2K2WOsDK1Cww=.c568223b-5100-4425-a4b7-defbd812a9ff@github.com> Message-ID: On Wed, 12 Apr 2023 14:55:59 GMT, Alan Bateman wrote: >> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed indent in collect_vthread_stack_roots > > In the spec for FollowReferences, it says that the heap roots include "references from thread stacks". There is a similar sentence in the deprecated IterateOverReachableObjects function. We should decide whether these sentences need to be changed to say "platform thread stacks". > @AlanBateman as virtual threads have already been defined to not be GC roots aka "heap roots" then it would seem the spec does need adjusting to say "platform threads". Yes, I think both the sentence in both FollowReferences and IterateOverReachableObjects will need to be re-visited. It is GC specific but historically the JVMTI spec has tried to specify something. Changing it to say platform threads does not prevent an implementation from using the the thread stacks of all threads. Additionally, we might have re-examine the descriptions of both JVMTI_HEAP_REFERENCE_STACK_LOCAL and JVMTI_HEAP_REFERENCE_JNI_LOCAL in jvmtiHeapReferenceKind. Doing the spec changes in a separate PR might be okay, I don't have any opinion on that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13254#issuecomment-1506685530 From sspitsyn at openjdk.org Thu Apr 13 10:06:51 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 13 Apr 2023 10:06:51 GMT Subject: RFR: 8257967: JFR: Events for loaded agents [v16] In-Reply-To: References: Message-ID: On Wed, 12 Apr 2023 10:43:31 GMT, Markus Gr?nlund wrote: >> src/hotspot/share/prims/jvmtiAgent.cpp line 323: >> >>> 321: assert(agent != nullptr, "invariant"); >>> 322: if (!agent->is_loaded()) { >>> 323: if (!load_agent_from_executable(agent, on_load_symbols, num_symbol_entries)) { >> >> It feels like I'm missing something. >> We already checked and found at line 322 that `agent->is_loaded() == false`. >> Also, we have the comment at line 265: >> >> 265 // If this function returns true, then agent->is_static_lib().&& agent->is_loaded(). >> 266 static bool load_agent_from_executable(Agent* agent, const char* on_load_symbols[], size_t num_symbol_entries) { >> >> As the `agent->is_loaded() == false` then t he condition `agent->is_static_lib() && agent->is_loaded()` has to be `false` and can not be `true`. Then one of the if-checks at lines 322 and 323 is not needed and can be removed. Is it right? Otherwise, the comment at line 265 can be incorrect. > > Good observation, Serguei. > > It is because some paths call into lookup_On_load_Entry_point() twice. > > It is primarily the attempted conversion of xrun agents, the first invocation comes from JvmtiAgent::convert_xrun_agent(). This will have the agent "loaded". If there is an Agent_OnLoad function, the agent is converted (i.e. xrun removed). > > Then when the agent is to invoke the Agent_OnLoad function, there is a second invocation. Here a converted xrun library is already loaded, so I bypass attempting to load it again by checking the is_loaded() property. Thanks. >> src/hotspot/share/prims/jvmtiAgent.cpp line 357: >> >>> 355: vm_exit_during_initialization("Could not find JVM_OnLoad or Agent_OnLoad function in the library", name()); >>> 356: } >>> 357: _xrun = false; // converted >> >> Just questions to understand it better. >> Neither `JVM_Onload` nor `Agent_Onload` entry points are stored after these lookups. It means that in order to be called later (as the comment at line 350 says) they have to be looked up again. >> Is it right? Was it the same originally? > > The entry points are not saved and so have to be looked up again. It was the same originally. > > That is why there is a check and branch on agent->is_loaded(). Thank you. I'm okay with it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12923#discussion_r1165306181 PR Review Comment: https://git.openjdk.org/jdk/pull/12923#discussion_r1165307170 From sspitsyn at openjdk.org Thu Apr 13 10:10:47 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 13 Apr 2023 10:10:47 GMT Subject: RFR: 8257967: JFR: Events for loaded agents [v16] In-Reply-To: References: Message-ID: On Tue, 4 Apr 2023 14:39:19 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> We are adding support to let JFR report on Agents. >> >> #### Design >> >> An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize. >> >> A JavaAgent is an agent written in the Java programming language, using the APIs in the package [java.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html) >> >> A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services. >> >> To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples: >> >> // Command line >> jdk.JavaAgent { >> startTime = 12:31:19.789 (2023-03-08) >> name = "JavaAgent.jar" >> options = "foo=bar" >> dynamic = false >> initializationTime = 12:31:15.574 (2023-03-08) >> initializationDuration = 172 ms >> } >> >> // Dynamic load >> jdk.JavaAgent { >> startTime = 12:31:31.158 (2023-03-08) >> name = "JavaAgent.jar" >> options = "bar=baz" >> dynamic = true >> initializationTime = 12:31:31.037 (2023-03-08) >> initializationDuration = 64,1 ms >> } >> >> The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents. >> >> For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar. >> >> The "dynamic" field denotes if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true) >> >> "initializationTime" is the timestamp the JVM invoked the initialization method, and "initializationDuration" is the duration of executing the initialization method. >> >> "startTime" represents the time the JFR framework issued the periodic event; hence "initializationTime" will be earlier than "startTime". >> >> An agent can also be written in a native programming language using the [JVM Tools Interface (JVMTI)](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file. >> >> To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example: >> >> jdk.NativeAgent { >> startTime = 12:31:40.398 (2023-03-08) >> name = "jdwp" >> options = "transport=dt_socket,server=y,address=any,onjcmd=y" >> dynamic = false >> initializationTime = 12:31:36.142 (2023-03-08) >> initializationDuration = 0,00184 ms >> path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll" >> } >> >> The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported. >> >> The initialization of a native agent is performed by invoking an agent-specified callback routine. The "initializationTime" is when the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationDuration" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationDuration" will be 0. If the agent is loaded dynamically, "initializationDuration" is the time taken to execute the Agent_OnAttach callback. >> >> #### Implementation >> >> There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization ? as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before. >> >> Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize. >> >> When implementing this capability, it was necessary to refactor the code used to represent agents, AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp. >> >> The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp. >> >> The previous two lists that maintained "agents" (JVMTI) and "libraries" (Xrun) were not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced. >> >> Testing: jdk_jfr, tier 1 - 6 >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: > > renames What was the reason to clone the classes below ?: `JvmtiJavaThreadEventTransition` => `AgentJavaThreadEventTransition` `JvmtiThreadEventMark` => `AgentThreadEventMark` `JvmtiEventMark` => `AgentEventMark` ------------- PR Comment: https://git.openjdk.org/jdk/pull/12923#issuecomment-1506701619 From sspitsyn at openjdk.org Thu Apr 13 10:17:44 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 13 Apr 2023 10:17:44 GMT Subject: RFR: 8257967: JFR: Events for loaded agents [v16] In-Reply-To: References: Message-ID: On Tue, 4 Apr 2023 14:39:19 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> We are adding support to let JFR report on Agents. >> >> #### Design >> >> An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize. >> >> A JavaAgent is an agent written in the Java programming language, using the APIs in the package [java.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html) >> >> A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services. >> >> To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples: >> >> // Command line >> jdk.JavaAgent { >> startTime = 12:31:19.789 (2023-03-08) >> name = "JavaAgent.jar" >> options = "foo=bar" >> dynamic = false >> initializationTime = 12:31:15.574 (2023-03-08) >> initializationDuration = 172 ms >> } >> >> // Dynamic load >> jdk.JavaAgent { >> startTime = 12:31:31.158 (2023-03-08) >> name = "JavaAgent.jar" >> options = "bar=baz" >> dynamic = true >> initializationTime = 12:31:31.037 (2023-03-08) >> initializationDuration = 64,1 ms >> } >> >> The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents. >> >> For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar. >> >> The "dynamic" field denotes if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true) >> >> "initializationTime" is the timestamp the JVM invoked the initialization method, and "initializationDuration" is the duration of executing the initialization method. >> >> "startTime" represents the time the JFR framework issued the periodic event; hence "initializationTime" will be earlier than "startTime". >> >> An agent can also be written in a native programming language using the [JVM Tools Interface (JVMTI)](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file. >> >> To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example: >> >> jdk.NativeAgent { >> startTime = 12:31:40.398 (2023-03-08) >> name = "jdwp" >> options = "transport=dt_socket,server=y,address=any,onjcmd=y" >> dynamic = false >> initializationTime = 12:31:36.142 (2023-03-08) >> initializationDuration = 0,00184 ms >> path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll" >> } >> >> The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported. >> >> The initialization of a native agent is performed by invoking an agent-specified callback routine. The "initializationTime" is when the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationDuration" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationDuration" will be 0. If the agent is loaded dynamically, "initializationDuration" is the time taken to execute the Agent_OnAttach callback. >> >> #### Implementation >> >> There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization ? as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before. >> >> Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize. >> >> When implementing this capability, it was necessary to refactor the code used to represent agents, AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp. >> >> The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp. >> >> The previous two lists that maintained "agents" (JVMTI) and "libraries" (Xrun) were not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced. >> >> Testing: jdk_jfr, tier 1 - 6 >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: > > renames Your fix introduced a hidden dependency of this new structure on the JPLISEnvironment structure and some Java agents implementation details: 202 struct JPLISEnvironmentMirror { 203 jvmtiEnv* mJVMTIEnv; // the JVMTI environment 204 const void* mAgent; // corresponding agent 205 jboolean mIsRetransformer; // indicates if special environment 206 }; It does not look good to me but I can't suggest any other approach at the moment. How important is this part? Have you considered other ways to achieve what is needed? ------------- PR Comment: https://git.openjdk.org/jdk/pull/12923#issuecomment-1506711461 From sspitsyn at openjdk.org Thu Apr 13 10:27:48 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 13 Apr 2023 10:27:48 GMT Subject: RFR: 8257967: JFR: Events for loaded agents [v16] In-Reply-To: References: Message-ID: On Tue, 4 Apr 2023 14:39:19 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> We are adding support to let JFR report on Agents. >> >> #### Design >> >> An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize. >> >> A JavaAgent is an agent written in the Java programming language, using the APIs in the package [java.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html) >> >> A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services. >> >> To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples: >> >> // Command line >> jdk.JavaAgent { >> startTime = 12:31:19.789 (2023-03-08) >> name = "JavaAgent.jar" >> options = "foo=bar" >> dynamic = false >> initializationTime = 12:31:15.574 (2023-03-08) >> initializationDuration = 172 ms >> } >> >> // Dynamic load >> jdk.JavaAgent { >> startTime = 12:31:31.158 (2023-03-08) >> name = "JavaAgent.jar" >> options = "bar=baz" >> dynamic = true >> initializationTime = 12:31:31.037 (2023-03-08) >> initializationDuration = 64,1 ms >> } >> >> The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents. >> >> For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar. >> >> The "dynamic" field denotes if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true) >> >> "initializationTime" is the timestamp the JVM invoked the initialization method, and "initializationDuration" is the duration of executing the initialization method. >> >> "startTime" represents the time the JFR framework issued the periodic event; hence "initializationTime" will be earlier than "startTime". >> >> An agent can also be written in a native programming language using the [JVM Tools Interface (JVMTI)](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file. >> >> To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example: >> >> jdk.NativeAgent { >> startTime = 12:31:40.398 (2023-03-08) >> name = "jdwp" >> options = "transport=dt_socket,server=y,address=any,onjcmd=y" >> dynamic = false >> initializationTime = 12:31:36.142 (2023-03-08) >> initializationDuration = 0,00184 ms >> path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll" >> } >> >> The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported. >> >> The initialization of a native agent is performed by invoking an agent-specified callback routine. The "initializationTime" is when the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationDuration" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationDuration" will be 0. If the agent is loaded dynamically, "initializationDuration" is the time taken to execute the Agent_OnAttach callback. >> >> #### Implementation >> >> There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization ? as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before. >> >> Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize. >> >> When implementing this capability, it was necessary to refactor the code used to represent agents, AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp. >> >> The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp. >> >> The previous two lists that maintained "agents" (JVMTI) and "libraries" (Xrun) were not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced. >> >> Testing: jdk_jfr, tier 1 - 6 >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: > > renames src/hotspot/share/prims/jvmtiAgentList.cpp line 72: > 70: // there exist an order requirement to iterate oldest -> newest. Our concurrent storage linked-list is newest -> oldest. > 71: // The correct order is preserved by the iterator, by storing a filtered set of entries in a stack. > 72: JvmtiAgentList::Iterator::Iterator(JvmtiAgent** list, Filter filter) : _stack(new GrowableArrayCHeap(16)), _filter(filter) { Nit: It'd be nice to make the lines 69-72 shorter. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12923#discussion_r1165328661 From dholmes at openjdk.org Thu Apr 13 10:42:32 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 13 Apr 2023 10:42:32 GMT Subject: RFR: 8305936: JavaThread::create_system_thread_object has unused is_visible argument In-Reply-To: References: Message-ID: On Thu, 13 Apr 2023 08:48:20 GMT, Kim Barrett wrote: >> Please review this simple cleanup of an unused parameter in `create_system_thread_object`. Details are in JBS. >> >> Testing: tiers 1-3 >> >> Thanks. > > Looks good. Thanks for the review @kimbarrett! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13455#issuecomment-1506740659 From duke at openjdk.org Thu Apr 13 11:31:05 2023 From: duke at openjdk.org (Afshin Zafari) Date: Thu, 13 Apr 2023 11:31:05 GMT Subject: RFR: 8305085: Remove finalize() from test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineFinalizer.java [v2] In-Reply-To: References: Message-ID: > The whole test is removed. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: 8305085: Remove finalize() from test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineFinalizer.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13422/files - new: https://git.openjdk.org/jdk/pull/13422/files/6d2855fe..d6e999b7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13422&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13422&range=00-01 Stats: 74 lines in 1 file changed: 74 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13422.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13422/head:pull/13422 PR: https://git.openjdk.org/jdk/pull/13422 From mgronlun at openjdk.org Thu Apr 13 11:48:43 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 13 Apr 2023 11:48:43 GMT Subject: RFR: 8257967: JFR: Events for loaded agents [v16] In-Reply-To: References: Message-ID: On Thu, 13 Apr 2023 10:07:50 GMT, Serguei Spitsyn wrote: > What was the reason to clone the classes below ?: `JvmtiJavaThreadEventTransition` => `AgentJavaThreadEventTransition` `JvmtiThreadEventMark` => `AgentThreadEventMark` `JvmtiEventMark` => `AgentEventMark` The reason is they are used when invoking Agent_OnAttach. Those classes are defined in jvmtiExport.cpp, so not reachable. I considered exporting them, but it would require additional headers to be included. I opted for just replicating them, also with static linkage. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12923#issuecomment-1506825122 From mgronlun at openjdk.org Thu Apr 13 11:54:45 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 13 Apr 2023 11:54:45 GMT Subject: RFR: 8257967: JFR: Events for loaded agents [v16] In-Reply-To: References: Message-ID: <7KrE0kjLkzjP1sEUxDNXAr3r64GUwZzOckaM9QeHhqs=.4232e5a4-a065-41ee-8240-6729b70f21cb@github.com> On Thu, 13 Apr 2023 10:15:02 GMT, Serguei Spitsyn wrote: > Your fix introduced a hidden dependency of this new structure on the JPLISEnvironment structure and some Java agents implementation details: > > ``` > 202 struct JPLISEnvironmentMirror { > 203 jvmtiEnv* mJVMTIEnv; // the JVMTI environment > 204 const void* mAgent; // corresponding agent > 205 jboolean mIsRetransformer; // indicates if special environment > 206 }; > ``` > > It does not look good to me but I can't suggest any other approach at the moment. How important is this part? Have you considered other ways to achieve what is needed? Yes. It is the key to locating which JavaAgent maps to which JvmtiEnv. I tried some other variants, but those would change the layout of the exported structs in jplisAgent.h, and I don't know if people depend on that layout, implicitly or explicitly. So I choose not go down that route. This seemed the best alternative since we own jdk.instrument and the implementation on the JDK side is unlikely to change very much. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12923#issuecomment-1506830279 From mgronlun at openjdk.org Thu Apr 13 12:16:16 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 13 Apr 2023 12:16:16 GMT Subject: RFR: 8257967: JFR: Events for loaded agents [v17] In-Reply-To: References: Message-ID: > Greetings, > > We are adding support to let JFR report on Agents. > > #### Design > > An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize. > > A JavaAgent is an agent written in the Java programming language, using the APIs in the package [java.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html) > > A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services. > > To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples: > > // Command line > jdk.JavaAgent { > startTime = 12:31:19.789 (2023-03-08) > name = "JavaAgent.jar" > options = "foo=bar" > dynamic = false > initializationTime = 12:31:15.574 (2023-03-08) > initializationDuration = 172 ms > } > > // Dynamic load > jdk.JavaAgent { > startTime = 12:31:31.158 (2023-03-08) > name = "JavaAgent.jar" > options = "bar=baz" > dynamic = true > initializationTime = 12:31:31.037 (2023-03-08) > initializationDuration = 64,1 ms > } > > The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents. > > For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar. > > The "dynamic" field denotes if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true) > > "initializationTime" is the timestamp the JVM invoked the initialization method, and "initializationDuration" is the duration of executing the initialization method. > > "startTime" represents the time the JFR framework issued the periodic event; hence "initializationTime" will be earlier than "startTime". > > An agent can also be written in a native programming language using the [JVM Tools Interface (JVMTI)](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file. > > To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example: > > jdk.NativeAgent { > startTime = 12:31:40.398 (2023-03-08) > name = "jdwp" > options = "transport=dt_socket,server=y,address=any,onjcmd=y" > dynamic = false > initializationTime = 12:31:36.142 (2023-03-08) > initializationDuration = 0,00184 ms > path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll" > } > > The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported. > > The initialization of a native agent is performed by invoking an agent-specified callback routine. The "initializationTime" is when the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationDuration" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationDuration" will be 0. If the agent is loaded dynamically, "initializationDuration" is the time taken to execute the Agent_OnAttach callback. > > #### Implementation > > There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization ? as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before. > > Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize. > > When implementing this capability, it was necessary to refactor the code used to represent agents, AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp. > > The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp. > > The previous two lists that maintained "agents" (JVMTI) and "libraries" (Xrun) were not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced. > > Testing: jdk_jfr, tier 1 - 6 > > Thanks > Markus Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: line breaks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12923/files - new: https://git.openjdk.org/jdk/pull/12923/files/d0fd9e97..85f06038 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12923&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12923&range=15-16 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/12923.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/12923/head:pull/12923 PR: https://git.openjdk.org/jdk/pull/12923 From mgronlun at openjdk.org Thu Apr 13 12:16:18 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Thu, 13 Apr 2023 12:16:18 GMT Subject: RFR: 8257967: JFR: Events for loaded agents [v16] In-Reply-To: References: Message-ID: On Thu, 13 Apr 2023 10:24:55 GMT, Serguei Spitsyn wrote: >> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: >> >> renames > > src/hotspot/share/prims/jvmtiAgentList.cpp line 72: > >> 70: // there exist an order requirement to iterate oldest -> newest. Our concurrent storage linked-list is newest -> oldest. >> 71: // The correct order is preserved by the iterator, by storing a filtered set of entries in a stack. >> 72: JvmtiAgentList::Iterator::Iterator(JvmtiAgent** list, Filter filter) : _stack(new GrowableArrayCHeap(16)), _filter(filter) { > > Nit: It'd be nice to make the lines 69-72 shorter. Ok. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12923#discussion_r1165429976 From lmesnik at openjdk.org Thu Apr 13 14:50:59 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 13 Apr 2023 14:50:59 GMT Subject: RFR: 8305937: com/sun/jdi/SetLocalWhileThreadInNative.java fails with -XX:+TieredCompilation Message-ID: TestScaffold combines test optionos and jtreg vm options. Before [JDK-8304834](https://bugs.openjdk.org/browse/JDK-8304834) it passed test jvm args as part of targetAppCommandLine. So the test VM args are added to the jtreg vm options. But after JDK-8304834 it parse then into targetVMArgs. So test vm args should append to jtreg vm options to override them. Testing: tier1-tier5 (including failing combination and testing with wrapper) I haven't added requires to filter out the test, because e filter only failing combination usually. ------------- Commit messages: - 8305937 - Merge branch 'master' of https://github.com/openjdk/jdk into 8289546 - Merge branch 'master' of https://github.com/openjdk/jdk into 8289546 - Updated comments - updated after David's comments. - Merge branch 'master' of https://github.com/openjdk/jdk into 8289546 - updated parsing. - added comments and trim arguments - parsing updted - problemlist fixed - ... and 2 more: https://git.openjdk.org/jdk/compare/6b9b7d1d...424d854e Changes: https://git.openjdk.org/jdk/pull/13461/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13461&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8305937 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13461/head:pull/13461 PR: https://git.openjdk.org/jdk/pull/13461 From lmesnik at openjdk.org Thu Apr 13 14:53:02 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 13 Apr 2023 14:53:02 GMT Subject: Withdrawn: 8305937: com/sun/jdi/SetLocalWhileThreadInNative.java fails with -XX:+TieredCompilation In-Reply-To: References: Message-ID: On Thu, 13 Apr 2023 14:41:42 GMT, Leonid Mesnik wrote: > TestScaffold combines test optionos and jtreg vm options. Before [JDK-8304834](https://bugs.openjdk.org/browse/JDK-8304834) it passed test jvm args as part of targetAppCommandLine. So the test VM args are added to the jtreg vm options. But after JDK-8304834 it parse then into targetVMArgs. So test vm args should append to jtreg vm options to override them. > > Testing: tier1-tier5 (including failing combination and testing with wrapper) > I haven't added requires to filter out the test, because e filter only failing combination usually. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/13461 From lmesnik at openjdk.org Thu Apr 13 14:58:18 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 13 Apr 2023 14:58:18 GMT Subject: RFR: 8305937: com/sun/jdi/SetLocalWhileThreadInNative.java fails with -XX:+TieredCompilation Message-ID: Could you please review following trivial fix which correct jvm options order in TestScaffold. TestScaffold combines test optionos and jtreg vm options. Before [JDK-8304834](https://bugs.openjdk.org/browse/JDK-8304834) it passed test jvm args as part of targetAppCommandLine. So the test VM args are added to the jtreg vm options. But after JDK-8304834 it parse then into targetVMArgs. So test vm args should append to jtreg vm options to override them. Testing: tier1-tier5 (including failing combination and testing with wrapper) I haven't added requires to filter out the test, because e filter only failing combination usually. ------------- Commit messages: - 8305937: com/sun/jdi/SetLocalWhileThreadInNative.java fails with -XX:+TieredCompilation Changes: https://git.openjdk.org/jdk/pull/13462/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13462&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8305937 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13462.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13462/head:pull/13462 PR: https://git.openjdk.org/jdk/pull/13462 From cjplummer at openjdk.org Thu Apr 13 15:34:45 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 13 Apr 2023 15:34:45 GMT Subject: RFR: 8305085: Remove finalize() from test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineFinalizer.java [v2] In-Reply-To: References: Message-ID: On Thu, 13 Apr 2023 11:31:05 GMT, Afshin Zafari wrote: >> The whole test is removed. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 8305085: Remove finalize() from test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineFinalizer.java The CR synopsis needs to be updated. ------------- PR Review: https://git.openjdk.org/jdk/pull/13422#pullrequestreview-1383702124 From dcubed at openjdk.org Thu Apr 13 15:49:35 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 13 Apr 2023 15:49:35 GMT Subject: RFR: 8305937: com/sun/jdi/SetLocalWhileThreadInNative.java fails with -XX:+TieredCompilation In-Reply-To: References: Message-ID: On Thu, 13 Apr 2023 14:49:58 GMT, Leonid Mesnik wrote: > Could you please review following trivial fix which correct jvm options order in TestScaffold. > TestScaffold combines test optionos and jtreg vm options. Before [JDK-8304834](https://bugs.openjdk.org/browse/JDK-8304834) it passed test jvm args as part of targetAppCommandLine. So the test VM args are added to the jtreg vm options. But after JDK-8304834 it parse then into targetVMArgs. So test vm args should append to jtreg vm options to override them. > > Testing: tier1-tier5 (including failing combination and testing with wrapper) > I haven't added requires to filter out the test, because e filter only failing combination usually. Thumbs up. This is a trivial fix. ------------- Marked as reviewed by dcubed (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13462#pullrequestreview-1383729766 From dcubed at openjdk.org Thu Apr 13 15:51:35 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 13 Apr 2023 15:51:35 GMT Subject: RFR: 8305966: ProblemList com/sun/jdi/JdbLastErrorTest.java on windows-x64 Message-ID: A trivial fix to ProblemList com/sun/jdi/JdbLastErrorTest.java on windows-x64. ------------- Commit messages: - 8305966: ProblemList com/sun/jdi/JdbLastErrorTest.java on windows-x64 Changes: https://git.openjdk.org/jdk/pull/13465/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13465&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8305966 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13465.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13465/head:pull/13465 PR: https://git.openjdk.org/jdk/pull/13465 From alanb at openjdk.org Thu Apr 13 15:51:36 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 13 Apr 2023 15:51:36 GMT Subject: RFR: 8305966: ProblemList com/sun/jdi/JdbLastErrorTest.java on windows-x64 In-Reply-To: References: Message-ID: On Thu, 13 Apr 2023 15:41:28 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList com/sun/jdi/JdbLastErrorTest.java on windows-x64. Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13465#pullrequestreview-1383725934 From dcubed at openjdk.org Thu Apr 13 15:51:37 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 13 Apr 2023 15:51:37 GMT Subject: RFR: 8305966: ProblemList com/sun/jdi/JdbLastErrorTest.java on windows-x64 In-Reply-To: References: Message-ID: On Thu, 13 Apr 2023 15:44:46 GMT, Alan Bateman wrote: >> A trivial fix to ProblemList com/sun/jdi/JdbLastErrorTest.java on windows-x64. > > Marked as reviewed by alanb (Reviewer). @AlanBateman - Thanks for the fast review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13465#issuecomment-1507200134 From dcubed at openjdk.org Thu Apr 13 15:54:47 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 13 Apr 2023 15:54:47 GMT Subject: Integrated: 8305966: ProblemList com/sun/jdi/JdbLastErrorTest.java on windows-x64 In-Reply-To: References: Message-ID: On Thu, 13 Apr 2023 15:41:28 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList com/sun/jdi/JdbLastErrorTest.java on windows-x64. This pull request has now been integrated. Changeset: 1385c3d2 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/1385c3d2f10357ac75a715cc9db0d94e16236889 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8305966: ProblemList com/sun/jdi/JdbLastErrorTest.java on windows-x64 Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/13465 From lmesnik at openjdk.org Thu Apr 13 16:05:42 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 13 Apr 2023 16:05:42 GMT Subject: Integrated: 8305937: com/sun/jdi/SetLocalWhileThreadInNative.java fails with -XX:+TieredCompilation In-Reply-To: References: Message-ID: <_GFUjOirOdDV3KZ23SMpCKNFbjIi0dZPJJnneZJnBeo=.dd816306-6fa5-49d4-878a-c3f5405434b0@github.com> On Thu, 13 Apr 2023 14:49:58 GMT, Leonid Mesnik wrote: > Could you please review following trivial fix which correct jvm options order in TestScaffold. > TestScaffold combines test optionos and jtreg vm options. Before [JDK-8304834](https://bugs.openjdk.org/browse/JDK-8304834) it passed test jvm args as part of targetAppCommandLine. So the test VM args are added to the jtreg vm options. But after JDK-8304834 it parse then into targetVMArgs. So test vm args should append to jtreg vm options to override them. > > Testing: tier1-tier5 (including failing combination and testing with wrapper) > I haven't added requires to filter out the test, because e filter only failing combination usually. This pull request has now been integrated. Changeset: 00eb348a Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/00eb348a521c81555355a8e5988a039851ed683f Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8305937: com/sun/jdi/SetLocalWhileThreadInNative.java fails with -XX:+TieredCompilation Reviewed-by: dcubed ------------- PR: https://git.openjdk.org/jdk/pull/13462 From duke at openjdk.org Thu Apr 13 17:36:31 2023 From: duke at openjdk.org (Afshin Zafari) Date: Thu, 13 Apr 2023 17:36:31 GMT Subject: RFR: 8305085: Suppress removal warning for finalize() from test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineFinalizer.java [v2] In-Reply-To: References: Message-ID: On Thu, 13 Apr 2023 15:32:19 GMT, Chris Plummer wrote: > The CR synopsis needs to be updated. The titles updated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13422#issuecomment-1507357976 From matsaave at openjdk.org Thu Apr 13 17:43:34 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Thu, 13 Apr 2023 17:43:34 GMT Subject: RFR: 8298048: Combine CDS archive heap into a single block [v5] In-Reply-To: <3wLQHgnmbwNVuVVZDe1Nlt6V6upyOrUXDxKKkMEOT8Y=.9a9c2b21-e683-4bd0-94ee-8ebcaf1b8333@github.com> References: <3wLQHgnmbwNVuVVZDe1Nlt6V6upyOrUXDxKKkMEOT8Y=.9a9c2b21-e683-4bd0-94ee-8ebcaf1b8333@github.com> Message-ID: On Wed, 12 Apr 2023 17:59:23 GMT, Ioi Lam wrote: >> This PR combines the "open" and "closed" regions of the CDS archive heap into a single region. This significantly simplifies the implementation, making it more compatible with non-G1 collectors. There's a net removal of ~1000 lines in src code and another ~1200 lines of tests. >> >> **Notes for reviewers:** >> - Most of the code changes in CDS are removing the handling of "open" vs "closed" objects. >> - Reviewers can start with ArchiveHeapWriter::copy_source_objs_to_buffer(). >> - It might be easier to see the diff with whitespaces off. >> - There are two major changes in the G1 code >> - The archived objects are now stored in the "old" region (see g1CollectedHeap.cpp in [58d720e](https://github.com/openjdk/jdk/pull/13284/commits/58d720e294bb36f21cb88cddde724ed2b9e93770)) >> - The majority of the other changes are removal of the "archive" region type (see heapRegionType.hpp). For ease of review, such code is isolated in [a852dfb](https://github.com/openjdk/jdk/pull/13284/commits/a852dfbbf5ff56e035399f7cc3704f29e76697f6) >> - Testing changes: >> - Now the archived java objects can move, along with the "old" regions that contain them. It's no longer possible to test whether a heap object came from CDS. As a result, the `WhiteBox.isShared(Object o)` API has been removed. >> - Many tests that uses this API are removed. Most of them were written during early development of CDS archived objects and are no longer relevant. >> >> **Testing:** >> - Mach5 tiers 1 ~ 7 > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @ashu-mehra comments; some clean up The changes look good to me! ------------- Marked as reviewed by matsaave (Committer). PR Review: https://git.openjdk.org/jdk/pull/13284#pullrequestreview-1383920908 From cjplummer at openjdk.org Thu Apr 13 18:23:35 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 13 Apr 2023 18:23:35 GMT Subject: RFR: 8305085: Suppress removal warning for finalize() from test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineFinalizer.java [v2] In-Reply-To: References: Message-ID: On Thu, 13 Apr 2023 11:31:05 GMT, Afshin Zafari wrote: >> The whole test is removed. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 8305085: Remove finalize() from test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineFinalizer.java Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13422#pullrequestreview-1383983433 From cjplummer at openjdk.org Thu Apr 13 18:31:33 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 13 Apr 2023 18:31:33 GMT Subject: RFR: 8305085: Suppress removal warning for finalize() from test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineFinalizer.java [v2] In-Reply-To: References: Message-ID: On Thu, 13 Apr 2023 11:31:05 GMT, Afshin Zafari wrote: >> The whole test is removed. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 8305085: Remove finalize() from test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineFinalizer.java > The whole test is removed. I just noticed that the PR description also needs to be updated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13422#issuecomment-1507436725 From jiangli at openjdk.org Thu Apr 13 20:07:32 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 13 Apr 2023 20:07:32 GMT Subject: RFR: 8305935: Resolve multiple definition of 'jmm_' when statically linking with JDK native libraries In-Reply-To: References: <97aWCpgt7_5qWV56OxZ_nG3jmZQ_aJHJlbYFpuhV9nc=.d3219cfa-de87-441d-bde7-0b560047984e@github.com> Message-ID: On Thu, 13 Apr 2023 06:56:46 GMT, David Holmes wrote: > Is there not a way to stop these from being exported from the library, as I assume they are not actually intended for external use. ?? Good question. We could make those as weak symbols as long as there is no concern about portability. In our current prototype on JDK 11, we use weak symbol to help detect if we are dealing with a statically linked binary at runtime then handle some of the cases conditionally (dynamic vs. static). Around the end of last year, I became aware that there could be issues in some cases on macos with weak symbols (e.g. without '-undefined dynamic_lookup'). I'm planning to look into alternatives (besides using weak symbol) when porting the support to the latest OpenJDK code base. Another approach is using 'objcopy' (https://web.mit.edu/gnu/doc/html/binutils_4.html) to localize the problematic symbols in the object file. It was suggested by our C++ colleague. We used that to hide symbols in libfreetype and libharfbuzz (there were problems when user code requires its own specific statically linked libfreetype and libharfbuzz due to versioning difference). So we first partially link all .o for the particular native library (in JDK) to form one .o file, then run 'objcopy' to localize the symbols. That hides the affected symbols during final link time. We had to do that since we don't control libfreetype and libharfbuzz. It worked for our specific case (for linux). It's probably not a general solution. The direct renaming in this case seems to be more strait forward. Any thoughts? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13451#discussion_r1165975548 From coleenp at openjdk.org Thu Apr 13 20:35:03 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 13 Apr 2023 20:35:03 GMT Subject: RFR: 8305083: Remove finalize() from test/hotspot/jtreg/vmTestbase/nsk/share/ and /jpda that are used in serviceability/dcmd/framework tests In-Reply-To: References: Message-ID: <0pXJVHtQE2NCqnrBA0v-9i_I8oNPpgSWQV9NgA3Fqvo=.63bb3d87-9db8-4a61-93d5-3f9ff0d1ab87@github.com> On Tue, 11 Apr 2023 08:16:29 GMT, Afshin Zafari wrote: > The `finalize()` method is removed from base classes/interfaces and are replaced by a Cleaner callback.. Another change that has turned into something much bigger. This cleanup is worth doing. Possible steps are (not in order and not in one push): 1. It seems like FinalizerObject should be removed in favor of classes that implement interface Finalizable and are forced to implement finalizeAtExit, so the Finalize thread can call the function on all the objects that get registered to it. Not sure if this mechanism is useful or not. Maybe it should be removed. If the process exits, are these connections closed? 2. If this mechanism is needed, rename Finalizer, FinalizerThread and Finalizable (ugh) to TestCleaner{Thread}. Cleanable with cleanAtExit, and rewrite/remove all references to these in the comments. Or just delete this (better?) 3. Fix remaining comments and especially all the typos. 4. This patch removes the classes that have registered finalize methods in favor of the cleaner mechanism, which looks good to me. These appear to be cases where some connection needs to be closed, or something like that. It seems to me that step 1 should be done then 4 as in this patch, leaving 2 and 3 to further cleanups and RFEs. Looks like we've uncovered a mess. The purpose of these changes are to remove the dependence on finalizer() with their associated warnings. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13420#issuecomment-1507574587 From jiangli at openjdk.org Thu Apr 13 20:50:36 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 13 Apr 2023 20:50:36 GMT Subject: RFR: 8305935: Resolve multiple definition of 'jmm_' when statically linking with JDK native libraries In-Reply-To: References: <97aWCpgt7_5qWV56OxZ_nG3jmZQ_aJHJlbYFpuhV9nc=.d3219cfa-de87-441d-bde7-0b560047984e@github.com> Message-ID: On Thu, 13 Apr 2023 20:04:15 GMT, Jiangli Zhou wrote: >> src/jdk.management/share/native/libmanagement_ext/management_ext.c line 36: >> >>> 34: const JmmInterface* jmm_interface_management_ext = NULL; >>> 35: static JavaVM* jvm = NULL; >>> 36: jint jmm_version_management_ext = 0; >> >> Is there not a way to stop these from being exported from the library, as I assume they are not actually intended for external use. ?? > >> Is there not a way to stop these from being exported from the library, as I assume they are not actually intended for external use. ?? > > Good question. > > We could make those as weak symbols as long as there is no concern about portability. In our current prototype on JDK 11, we use weak symbol to help detect if we are dealing with a statically linked binary at runtime then handle some of the cases conditionally (dynamic vs. static). Around the end of last year, I became aware that there could be issues in some cases on macos with weak symbols (e.g. without '-undefined dynamic_lookup'). I'm planning to look into alternatives (besides using weak symbol) when porting the support to the latest OpenJDK code base. > > Another approach is using 'objcopy' (https://web.mit.edu/gnu/doc/html/binutils_4.html) to localize the problematic symbols in the object file. It was suggested by our C++ colleague. We used that to hide symbols in libfreetype and libharfbuzz (there were problems when user code requires its own specific statically linked libfreetype and libharfbuzz due to versioning difference). So we first partially link all .o for the particular native library (in JDK) to form one .o file, then run 'objcopy' to localize the symbols. That hides the affected symbols during final link time. We had to do that since we don't control libfreetype and libharfbuzz. It worked for our specific case (for linux). It's probably not a general solution. > > The direct renaming in this case seems to be more strait forward. Any thoughts? Forgot to mention that using 'static' effectively resolves the symbol issue when feasible, like the 'jvm' variable case. That doesn't work for the 'jmm_interface' and 'jmm_version' ... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13451#discussion_r1166010486 From dholmes at openjdk.org Thu Apr 13 23:10:32 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 13 Apr 2023 23:10:32 GMT Subject: RFR: 8305935: Resolve multiple definition of 'jmm_' when statically linking with JDK native libraries In-Reply-To: References: <97aWCpgt7_5qWV56OxZ_nG3jmZQ_aJHJlbYFpuhV9nc=.d3219cfa-de87-441d-bde7-0b560047984e@github.com> Message-ID: On Thu, 13 Apr 2023 20:47:39 GMT, Jiangli Zhou wrote: >>> Is there not a way to stop these from being exported from the library, as I assume they are not actually intended for external use. ?? >> >> Good question. >> >> We could make those as weak symbols as long as there is no concern about portability. In our current prototype on JDK 11, we use weak symbol to help detect if we are dealing with a statically linked binary at runtime then handle some of the cases conditionally (dynamic vs. static). Around the end of last year, I became aware that there could be issues in some cases on macos with weak symbols (e.g. without '-undefined dynamic_lookup'). I'm planning to look into alternatives (besides using weak symbol) when porting the support to the latest OpenJDK code base. >> >> Another approach is using 'objcopy' (https://web.mit.edu/gnu/doc/html/binutils_4.html) to localize the problematic symbols in the object file. It was suggested by our C++ colleague. We used that to hide symbols in libfreetype and libharfbuzz (there were problems when user code requires its own specific statically linked libfreetype and libharfbuzz due to versioning difference). So we first partially link all .o for the particular native library (in JDK) to form one .o file, then run 'objcopy' to localize the symbols. That hides the affected symbols during final link time. We had to do that since we don't control libfreetype and libharfbuzz. It worked for our specific case (for linux). It's probably not a general solution. >> >> The direct renaming in this case seems to be more strait forward. Any thoughts? > > Forgot to mention that using 'static' effectively resolves the symbol issue when feasible, like the 'jvm' variable case. That doesn't work for the 'jmm_interface' and 'jmm_version' ... I'm not familiar with the details of symbol scoping and linkage with libraries, but I would have hoped there was a way to have symbols like this shareable throughout the code that comprises the library without exposing them to users of the library. It used to be IIRC only functions we listed in the mapfiles were exposed, and these days we use explicit attributes to export them. Is there not some equivalent thing for data? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13451#discussion_r1166110590 From dholmes at openjdk.org Thu Apr 13 23:10:32 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 13 Apr 2023 23:10:32 GMT Subject: RFR: 8305935: Resolve multiple definition of 'jmm_' when statically linking with JDK native libraries In-Reply-To: References: <97aWCpgt7_5qWV56OxZ_nG3jmZQ_aJHJlbYFpuhV9nc=.d3219cfa-de87-441d-bde7-0b560047984e@github.com> Message-ID: On Thu, 13 Apr 2023 23:05:02 GMT, David Holmes wrote: >> Forgot to mention that using 'static' effectively resolves the symbol issue when feasible, like the 'jvm' variable case. That doesn't work for the 'jmm_interface' and 'jmm_version' ... > > I'm not familiar with the details of symbol scoping and linkage with libraries, but I would have hoped there was a way to have symbols like this shareable throughout the code that comprises the library without exposing them to users of the library. It used to be IIRC only functions we listed in the mapfiles were exposed, and these days we use explicit attributes to export them. Is there not some equivalent thing for data? > The direct renaming in this case seems to be more strait forward. If we were to do this then we should have a naming convention of some kind e.g. `_` but it strikes me as wrong as the code shouldn't need to know what library it is part of. In this case we do something as a simple point-fix, but to me it says there is a bigger problem. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13451#discussion_r1166111820 From dholmes at openjdk.org Thu Apr 13 23:13:41 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 13 Apr 2023 23:13:41 GMT Subject: Integrated: 8305936: JavaThread::create_system_thread_object has unused is_visible argument In-Reply-To: References: Message-ID: On Thu, 13 Apr 2023 05:41:31 GMT, David Holmes wrote: > Please review this simple cleanup of an unused parameter in `create_system_thread_object`. Details are in JBS. > > Testing: tiers 1-3 > > Thanks. This pull request has now been integrated. Changeset: 8a1639d4 Author: David Holmes URL: https://git.openjdk.org/jdk/commit/8a1639d49b4adc45501fe77cedfef3ca5f42c7f5 Stats: 17 lines in 9 files changed: 0 ins; 2 del; 15 mod 8305936: JavaThread::create_system_thread_object has unused is_visible argument Reviewed-by: alanb, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/13455 From jiangli at openjdk.org Fri Apr 14 00:36:42 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 14 Apr 2023 00:36:42 GMT Subject: RFR: 8305935: Resolve multiple definition of 'jmm_' when statically linking with JDK native libraries In-Reply-To: References: <97aWCpgt7_5qWV56OxZ_nG3jmZQ_aJHJlbYFpuhV9nc=.d3219cfa-de87-441d-bde7-0b560047984e@github.com> Message-ID: On Thu, 13 Apr 2023 23:07:23 GMT, David Holmes wrote: >> I'm not familiar with the details of symbol scoping and linkage with libraries, but I would have hoped there was a way to have symbols like this shareable throughout the code that comprises the library without exposing them to users of the library. It used to be IIRC only functions we listed in the mapfiles were exposed, and these days we use explicit attributes to export them. Is there not some equivalent thing for data? > >> The direct renaming in this case seems to be more strait forward. > > If we were to do this then we should have a naming convention of some kind e.g. `_` but it strikes me as wrong as the code shouldn't need to know what library it is part of. In this case we do something as a simple point-fix, but to me it says there is a bigger problem. > I'm not familiar with the details of symbol scoping and linkage with libraries, but I would have hoped there was a way to have symbols like this shareable throughout the code that comprises the library without exposing them to users of the library. It used to be IIRC only functions we listed in the mapfiles were exposed, and these days we use explicit attributes to export them. Is there not some equivalent thing for data? If my understanding is correct the mapfile is for exported symbols, which are in the export table. Those symbols can be dynamically looked up, e.g. via dlsym. By default, '-fvisibility=hidden' is used (https://github.com/openjdk/jdk/blob/master/make/common/modules/LibCommon.gmk#L41). The symbols are '.hidden' by default if not exported. E.g. jmm_interface is 'hidden' as objdump shows below. However, the linker error that we are seeing here for statically linking the libraries together is a different issue. The linker founds multiple ones in different object files, hence the failures. We'd have to change to use internal linkage for the affect variables to resolve the failure if feasible (without renaming). Please let me know if I'm missing anything. objdump: ./linux-x86_64-server-release/support/native/jdk.management/libmanagement_ext/management_ext.o: not a dynamic object SYMBOL TABLE: 0000000000000000 l df *ABS* 0000000000000000 management_ext.c ... 0000000000000000 g F .text 0000000000000068 JNI_OnLoad 0000000000000008 g O .bss 0000000000000008 .hidden jvm 0000000000000000 *UND* 0000000000000000 JVM_GetManagement 0000000000000010 g O .bss 0000000000000008 .hidden jmm_interface 0000000000000000 g O .bss 0000000000000004 .hidden jmm_version ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13451#discussion_r1166157315 From jiangli at openjdk.org Fri Apr 14 00:57:31 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 14 Apr 2023 00:57:31 GMT Subject: RFR: 8305935: Resolve multiple definition of 'jmm_' when statically linking with JDK native libraries In-Reply-To: References: <97aWCpgt7_5qWV56OxZ_nG3jmZQ_aJHJlbYFpuhV9nc=.d3219cfa-de87-441d-bde7-0b560047984e@github.com> Message-ID: On Fri, 14 Apr 2023 00:34:14 GMT, Jiangli Zhou wrote: >>> The direct renaming in this case seems to be more strait forward. >> >> If we were to do this then we should have a naming convention of some kind e.g. `_` but it strikes me as wrong as the code shouldn't need to know what library it is part of. In this case we do something as a simple point-fix, but to me it says there is a bigger problem. > >> I'm not familiar with the details of symbol scoping and linkage with libraries, but I would have hoped there was a way to have symbols like this shareable throughout the code that comprises the library without exposing them to users of the library. It used to be IIRC only functions we listed in the mapfiles were exposed, and these days we use explicit attributes to export them. Is there not some equivalent thing for data? > > If my understanding is correct the mapfile is for exported symbols, which are in the export table. Those symbols can be dynamically looked up, e.g. via dlsym. By default, '-fvisibility=hidden' is used (https://github.com/openjdk/jdk/blob/master/make/common/modules/LibCommon.gmk#L41). The symbols are '.hidden' by default if not exported. E.g. jmm_interface is 'hidden' as objdump shows below. However, the linker error that we are seeing here for statically linking the libraries together is a different issue. The linker founds multiple ones in different object files, hence the failures. We'd have to change to use internal linkage for the affect variables to resolve the failure if feasible (without renaming). Please let me know if I'm missing anything. > > objdump: ./linux-x86_64-server-release/support/native/jdk.management/libmanagement_ext/management_ext.o: not a dynamic object > SYMBOL TABLE: > 0000000000000000 l df *ABS* 0000000000000000 management_ext.c > ... > 0000000000000000 g F .text 0000000000000068 JNI_OnLoad > 0000000000000008 g O .bss 0000000000000008 .hidden jvm > 0000000000000000 *UND* 0000000000000000 JVM_GetManagement > 0000000000000010 g O .bss 0000000000000008 .hidden jmm_interface > 0000000000000000 g O .bss 0000000000000004 .hidden jmm_version > If we were to do this then we should have a naming convention of some kind e.g. `_` but it strikes me as wrong as the code shouldn't need to know what library it is part of. In this case we do something as a simple point-fix, but to me it says there is a bigger problem. Using a naming convention as you suggested sounds good. I'm not completely clear what's the bigger problem though. Could you please clarify? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13451#discussion_r1166165671 From dholmes at openjdk.org Fri Apr 14 01:53:42 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 14 Apr 2023 01:53:42 GMT Subject: RFR: 8305085: Suppress removal warning for finalize() from test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineFinalizer.java [v2] In-Reply-To: References: Message-ID: <35BHEcQMaMdeBfMOPhrpvvONjbUXjpeHBAuVW_Mubss=.a883143b-aea5-4647-aa4e-e5a48d50aeac@github.com> On Thu, 13 Apr 2023 11:31:05 GMT, Afshin Zafari wrote: >> The whole test is removed. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 8305085: Remove finalize() from test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineFinalizer.java Looks good. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13422#pullrequestreview-1384484413 From jiangli at openjdk.org Fri Apr 14 02:12:33 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 14 Apr 2023 02:12:33 GMT Subject: RFR: 8305935: Resolve multiple definition of 'jmm_' when statically linking with JDK native libraries In-Reply-To: References: <97aWCpgt7_5qWV56OxZ_nG3jmZQ_aJHJlbYFpuhV9nc=.d3219cfa-de87-441d-bde7-0b560047984e@github.com> Message-ID: On Fri, 14 Apr 2023 00:54:22 GMT, Jiangli Zhou wrote: >>> I'm not familiar with the details of symbol scoping and linkage with libraries, but I would have hoped there was a way to have symbols like this shareable throughout the code that comprises the library without exposing them to users of the library. It used to be IIRC only functions we listed in the mapfiles were exposed, and these days we use explicit attributes to export them. Is there not some equivalent thing for data? >> >> If my understanding is correct the mapfile is for exported symbols, which are in the export table. Those symbols can be dynamically looked up, e.g. via dlsym. By default, '-fvisibility=hidden' is used (https://github.com/openjdk/jdk/blob/master/make/common/modules/LibCommon.gmk#L41). The symbols are '.hidden' by default if not exported. E.g. jmm_interface is 'hidden' as objdump shows below. However, the linker error that we are seeing here for statically linking the libraries together is a different issue. The linker founds multiple ones in different object files, hence the failures. We'd have to change to use internal linkage for the affect variables to resolve the failure if feasible (without renaming). Please let me know if I'm missing anything. >> >> objdump: ./linux-x86_64-server-release/support/native/jdk.management/libmanagement_ext/management_ext.o: not a dynamic object >> SYMBOL TABLE: >> 0000000000000000 l df *ABS* 0000000000000000 management_ext.c >> ... >> 0000000000000000 g F .text 0000000000000068 JNI_OnLoad >> 0000000000000008 g O .bss 0000000000000008 .hidden jvm >> 0000000000000000 *UND* 0000000000000000 JVM_GetManagement >> 0000000000000010 g O .bss 0000000000000008 .hidden jmm_interface >> 0000000000000000 g O .bss 0000000000000004 .hidden jmm_version > >> If we were to do this then we should have a naming convention of some kind e.g. `_` but it strikes me as wrong as the code shouldn't need to know what library it is part of. In this case we do something as a simple point-fix, but to me it says there is a bigger problem. > > Using a naming convention as you suggested sounds good. I'm not completely clear what's the bigger problem though. Could you please clarify? David, I was doing some more reading on the topic for our discussion in the thread and just found this: https://stackoverflow.com/questions/61663118/avoid-multiple-definition-linker-error-when-not-using-the-redefined-symbols. It has some good information on the symbol collision issue. It describes using 'objcopy' to localize or redefine symbols. It also mentions '--allow-multiple-definitions', which I didn't know before. However, '--allow-multiple-definitions' doesn't seem to be a good approach. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13451#discussion_r1166209365 From dholmes at openjdk.org Fri Apr 14 05:13:31 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 14 Apr 2023 05:13:31 GMT Subject: RFR: 8305935: Resolve multiple definition of 'jmm_' when statically linking with JDK native libraries In-Reply-To: References: <97aWCpgt7_5qWV56OxZ_nG3jmZQ_aJHJlbYFpuhV9nc=.d3219cfa-de87-441d-bde7-0b560047984e@github.com> Message-ID: On Fri, 14 Apr 2023 02:09:47 GMT, Jiangli Zhou wrote: >>> If we were to do this then we should have a naming convention of some kind e.g. `_` but it strikes me as wrong as the code shouldn't need to know what library it is part of. In this case we do something as a simple point-fix, but to me it says there is a bigger problem. >> >> Using a naming convention as you suggested sounds good. I'm not completely clear what's the bigger problem though. Could you please clarify? > > David, I was doing some more reading on the topic for our discussion in the thread and just found this: https://stackoverflow.com/questions/61663118/avoid-multiple-definition-linker-error-when-not-using-the-redefined-symbols. > > It has some good information on the symbol collision issue. It describes using 'objcopy' to localize or redefine symbols. It also mentions '--allow-multiple-definitions', which I didn't know before. However, '--allow-multiple-definitions' doesn't seem to be a good approach. Thanks for the pointer to stackoverflow - that made things a lot clearer. The symbol localization using `objcopy` seems to achieve what we desire but has the same drawback as renaming, that you need to know the symbols will clash to localize them. And it is also not ideal that changing the code may also need a change to the build file. :( With that in mind a simple renaming seems the least worst option for fixing this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13451#discussion_r1166283513 From dholmes at openjdk.org Fri Apr 14 05:23:33 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 14 Apr 2023 05:23:33 GMT Subject: RFR: 8305935: Resolve multiple definition of 'jmm_' when statically linking with JDK native libraries In-Reply-To: <97aWCpgt7_5qWV56OxZ_nG3jmZQ_aJHJlbYFpuhV9nc=.d3219cfa-de87-441d-bde7-0b560047984e@github.com> References: <97aWCpgt7_5qWV56OxZ_nG3jmZQ_aJHJlbYFpuhV9nc=.d3219cfa-de87-441d-bde7-0b560047984e@github.com> Message-ID: On Wed, 12 Apr 2023 23:35:02 GMT, Jiangli Zhou wrote: > Rename 'jmm_' to 'jmm__management_ext' in libmanagement_ext to resolve related linker errors when statically linking with both libmanagement and libmanagement_ext. One small request but otherwise okay. In wonder if @magicus or @erikj79 have anything to add from a build perspective? Thanks for the extended discussion on the potential options here. src/jdk.management/share/native/libmanagement_ext/management_ext.c line 34: > 32: #define ERR_MSG_SIZE 128 > 33: > 34: const JmmInterface* jmm_interface_management_ext = NULL; Can you add a comment before declaring the two "exported" symbols together: // These symbols are global in this library but need to be uniquely named to avoid conflicts // with same-named symbols in other libraries, when statically linking. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13451#pullrequestreview-1384611991 PR Review Comment: https://git.openjdk.org/jdk/pull/13451#discussion_r1166286584 From dholmes at openjdk.org Fri Apr 14 05:23:35 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 14 Apr 2023 05:23:35 GMT Subject: RFR: 8305935: Resolve multiple definition of 'jmm_' when statically linking with JDK native libraries In-Reply-To: References: <97aWCpgt7_5qWV56OxZ_nG3jmZQ_aJHJlbYFpuhV9nc=.d3219cfa-de87-441d-bde7-0b560047984e@github.com> Message-ID: On Fri, 14 Apr 2023 05:17:28 GMT, David Holmes wrote: >> Rename 'jmm_' to 'jmm__management_ext' in libmanagement_ext to resolve related linker errors when statically linking with both libmanagement and libmanagement_ext. > > src/jdk.management/share/native/libmanagement_ext/management_ext.c line 34: > >> 32: #define ERR_MSG_SIZE 128 >> 33: >> 34: const JmmInterface* jmm_interface_management_ext = NULL; > > Can you add a comment before declaring the two "exported" symbols together: > > // These symbols are global in this library but need to be uniquely named to avoid conflicts > // with same-named symbols in other libraries, when statically linking. > > Thanks. Oops! Sorry meant to add this comment to the declarations in the hpp file. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13451#discussion_r1166288127 From dholmes at openjdk.org Fri Apr 14 05:49:40 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 14 Apr 2023 05:49:40 GMT Subject: RFR: 8305937: com/sun/jdi/SetLocalWhileThreadInNative.java fails with -XX:+TieredCompilation In-Reply-To: References: Message-ID: <67QPUVuVOhV3iWs34kK7Lpke5RhxHETubtEpVBc4zvU=.2bea7630-1ad6-4ecf-8bc4-0a2ecb0e0b7c@github.com> On Thu, 13 Apr 2023 14:49:58 GMT, Leonid Mesnik wrote: > Could you please review following trivial fix which correct jvm options order in TestScaffold. > TestScaffold combines test optionos and jtreg vm options. Before [JDK-8304834](https://bugs.openjdk.org/browse/JDK-8304834) it passed test jvm args as part of targetAppCommandLine. So the test VM args are added to the jtreg vm options. But after JDK-8304834 it parse then into targetVMArgs. So test vm args should append to jtreg vm options to override them. > > Testing: tier1-tier5 (including failing combination and testing with wrapper) > I haven't added requires to filter out the test, because e filter only failing combination usually. So IIUC basically before [JDK-8304834](https://bugs.openjdk.org/browse/JDK-8304834) we would have: java TestClass and those intended test VM args were completely ignored as the VM never saw them. Then after [JDK-8304834](https://bugs.openjdk.org/browse/JDK-8304834): java TestClass and the test VM args are seen by the VM but potentially overridden by the jtreg VM args. And now we have: java TestClass and things now work as planned. But it also means that since [JDK-8304834](https://bugs.openjdk.org/browse/JDK-8304834) we've started running a whole bunch of tests (how many?) in a way they have never actually run before. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13462#issuecomment-1507954240 From duke at openjdk.org Fri Apr 14 07:38:42 2023 From: duke at openjdk.org (Afshin Zafari) Date: Fri, 14 Apr 2023 07:38:42 GMT Subject: RFR: 8305085: Suppress removal warning for finalize() from test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineFinalizer.java [v2] In-Reply-To: References: Message-ID: On Thu, 13 Apr 2023 18:28:27 GMT, Chris Plummer wrote: > > The whole test is removed. > > I just noticed that the PR description also needs to be updated. Thanks for your comment. It is updated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13422#issuecomment-1508061117 From sspitsyn at openjdk.org Fri Apr 14 07:38:47 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 14 Apr 2023 07:38:47 GMT Subject: RFR: 8257967: JFR: Events for loaded agents [v17] In-Reply-To: References: Message-ID: On Thu, 13 Apr 2023 12:16:16 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> We are adding support to let JFR report on Agents. >> >> #### Design >> >> An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize. >> >> A JavaAgent is an agent written in the Java programming language, using the APIs in the package [java.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html) >> >> A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services. >> >> To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples: >> >> // Command line >> jdk.JavaAgent { >> startTime = 12:31:19.789 (2023-03-08) >> name = "JavaAgent.jar" >> options = "foo=bar" >> dynamic = false >> initializationTime = 12:31:15.574 (2023-03-08) >> initializationDuration = 172 ms >> } >> >> // Dynamic load >> jdk.JavaAgent { >> startTime = 12:31:31.158 (2023-03-08) >> name = "JavaAgent.jar" >> options = "bar=baz" >> dynamic = true >> initializationTime = 12:31:31.037 (2023-03-08) >> initializationDuration = 64,1 ms >> } >> >> The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents. >> >> For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar. >> >> The "dynamic" field denotes if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true) >> >> "initializationTime" is the timestamp the JVM invoked the initialization method, and "initializationDuration" is the duration of executing the initialization method. >> >> "startTime" represents the time the JFR framework issued the periodic event; hence "initializationTime" will be earlier than "startTime". >> >> An agent can also be written in a native programming language using the [JVM Tools Interface (JVMTI)](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file. >> >> To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example: >> >> jdk.NativeAgent { >> startTime = 12:31:40.398 (2023-03-08) >> name = "jdwp" >> options = "transport=dt_socket,server=y,address=any,onjcmd=y" >> dynamic = false >> initializationTime = 12:31:36.142 (2023-03-08) >> initializationDuration = 0,00184 ms >> path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll" >> } >> >> The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported. >> >> The initialization of a native agent is performed by invoking an agent-specified callback routine. The "initializationTime" is when the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationDuration" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationDuration" will be 0. If the agent is loaded dynamically, "initializationDuration" is the time taken to execute the Agent_OnAttach callback. >> >> #### Implementation >> >> There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization ? as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before. >> >> Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize. >> >> When implementing this capability, it was necessary to refactor the code used to represent agents, AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp. >> >> The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp. >> >> The previous two lists that maintained "agents" (JVMTI) and "libraries" (Xrun) were not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced. >> >> Testing: jdk_jfr, tier 1 - 6 >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: > > line breaks Markus, thank you for your answers. I'm okay with it as I can't suggest anything better. These issues are local and spots are pretty small, so it is not that bad and look like reasonable compromise. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12923#issuecomment-1508063709 From duke at openjdk.org Fri Apr 14 07:38:45 2023 From: duke at openjdk.org (Afshin Zafari) Date: Fri, 14 Apr 2023 07:38:45 GMT Subject: RFR: 8305085: Suppress removal warning for finalize() from test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineFinalizer.java [v2] In-Reply-To: References: Message-ID: On Thu, 13 Apr 2023 11:31:05 GMT, Afshin Zafari wrote: >> The warning message is suppressed out. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 8305085: Remove finalize() from test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineFinalizer.java Thank you David and Chris for your reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13422#issuecomment-1508063119 From sspitsyn at openjdk.org Fri Apr 14 07:46:42 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 14 Apr 2023 07:46:42 GMT Subject: RFR: 8257967: JFR: Events for loaded agents [v17] In-Reply-To: References: Message-ID: On Thu, 13 Apr 2023 12:16:16 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> We are adding support to let JFR report on Agents. >> >> #### Design >> >> An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize. >> >> A JavaAgent is an agent written in the Java programming language, using the APIs in the package [java.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html) >> >> A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services. >> >> To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples: >> >> // Command line >> jdk.JavaAgent { >> startTime = 12:31:19.789 (2023-03-08) >> name = "JavaAgent.jar" >> options = "foo=bar" >> dynamic = false >> initializationTime = 12:31:15.574 (2023-03-08) >> initializationDuration = 172 ms >> } >> >> // Dynamic load >> jdk.JavaAgent { >> startTime = 12:31:31.158 (2023-03-08) >> name = "JavaAgent.jar" >> options = "bar=baz" >> dynamic = true >> initializationTime = 12:31:31.037 (2023-03-08) >> initializationDuration = 64,1 ms >> } >> >> The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents. >> >> For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar. >> >> The "dynamic" field denotes if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true) >> >> "initializationTime" is the timestamp the JVM invoked the initialization method, and "initializationDuration" is the duration of executing the initialization method. >> >> "startTime" represents the time the JFR framework issued the periodic event; hence "initializationTime" will be earlier than "startTime". >> >> An agent can also be written in a native programming language using the [JVM Tools Interface (JVMTI)](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file. >> >> To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example: >> >> jdk.NativeAgent { >> startTime = 12:31:40.398 (2023-03-08) >> name = "jdwp" >> options = "transport=dt_socket,server=y,address=any,onjcmd=y" >> dynamic = false >> initializationTime = 12:31:36.142 (2023-03-08) >> initializationDuration = 0,00184 ms >> path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll" >> } >> >> The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported. >> >> The initialization of a native agent is performed by invoking an agent-specified callback routine. The "initializationTime" is when the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationDuration" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationDuration" will be 0. If the agent is loaded dynamically, "initializationDuration" is the time taken to execute the Agent_OnAttach callback. >> >> #### Implementation >> >> There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization ? as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before. >> >> Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize. >> >> When implementing this capability, it was necessary to refactor the code used to represent agents, AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp. >> >> The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp. >> >> The previous two lists that maintained "agents" (JVMTI) and "libraries" (Xrun) were not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced. >> >> Testing: jdk_jfr, tier 1 - 6 >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: > > line breaks src/hotspot/share/prims/jvmtiExport.cpp line 717: > 715: jvmtiEventVMInit callback = env->callbacks()->VMInit; > 716: if (callback != nullptr) { > 717: JvmtiAgent* const agent = lookup_uninitialized_agent(env, reinterpret_cast(callback)); It was a surprise to me to discover this code in your changes. How can it be possible that some agents are left uninitialized at the time of VMInit event? Have you really observed this? If so, then can you add a comment explaining the need of this initialization? Is it needed for JFR purposes only? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12923#discussion_r1166421178 From sspitsyn at openjdk.org Fri Apr 14 07:53:49 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 14 Apr 2023 07:53:49 GMT Subject: RFR: 8257967: JFR: Events for loaded agents [v17] In-Reply-To: References: Message-ID: <73FsVYPjYuC09PElaj8hwZRKc55HfqdVKsJqJiQVrBU=.9d7d395e-5618-4148-b20c-04d9e5184c01@github.com> On Thu, 13 Apr 2023 12:16:16 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> We are adding support to let JFR report on Agents. >> >> #### Design >> >> An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize. >> >> A JavaAgent is an agent written in the Java programming language, using the APIs in the package [java.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html) >> >> A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services. >> >> To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples: >> >> // Command line >> jdk.JavaAgent { >> startTime = 12:31:19.789 (2023-03-08) >> name = "JavaAgent.jar" >> options = "foo=bar" >> dynamic = false >> initializationTime = 12:31:15.574 (2023-03-08) >> initializationDuration = 172 ms >> } >> >> // Dynamic load >> jdk.JavaAgent { >> startTime = 12:31:31.158 (2023-03-08) >> name = "JavaAgent.jar" >> options = "bar=baz" >> dynamic = true >> initializationTime = 12:31:31.037 (2023-03-08) >> initializationDuration = 64,1 ms >> } >> >> The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents. >> >> For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar. >> >> The "dynamic" field denotes if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true) >> >> "initializationTime" is the timestamp the JVM invoked the initialization method, and "initializationDuration" is the duration of executing the initialization method. >> >> "startTime" represents the time the JFR framework issued the periodic event; hence "initializationTime" will be earlier than "startTime". >> >> An agent can also be written in a native programming language using the [JVM Tools Interface (JVMTI)](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file. >> >> To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example: >> >> jdk.NativeAgent { >> startTime = 12:31:40.398 (2023-03-08) >> name = "jdwp" >> options = "transport=dt_socket,server=y,address=any,onjcmd=y" >> dynamic = false >> initializationTime = 12:31:36.142 (2023-03-08) >> initializationDuration = 0,00184 ms >> path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll" >> } >> >> The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported. >> >> The initialization of a native agent is performed by invoking an agent-specified callback routine. The "initializationTime" is when the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationDuration" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationDuration" will be 0. If the agent is loaded dynamically, "initializationDuration" is the time taken to execute the Agent_OnAttach callback. >> >> #### Implementation >> >> There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization ? as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before. >> >> Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize. >> >> When implementing this capability, it was necessary to refactor the code used to represent agents, AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp. >> >> The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp. >> >> The previous two lists that maintained "agents" (JVMTI) and "libraries" (Xrun) were not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced. >> >> Testing: jdk_jfr, tier 1 - 6 >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: > > line breaks Markus, It looks good to me. Overall, it is a nice consolidation of the agent code, good move in general! Thank you for your patience. I've posted one minor request though. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/12923#pullrequestreview-1384843610 From mgronlun at openjdk.org Fri Apr 14 09:24:44 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 14 Apr 2023 09:24:44 GMT Subject: RFR: 8257967: JFR: Events for loaded agents [v17] In-Reply-To: References: Message-ID: <0gj2kjWDMnEpt_58UH60JCzURC9ZuOowVLom48A69n0=.0c35359f-514a-4526-95ae-2a256d9372d7@github.com> On Fri, 14 Apr 2023 07:43:23 GMT, Serguei Spitsyn wrote: >> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: >> >> line breaks > > src/hotspot/share/prims/jvmtiExport.cpp line 717: > >> 715: jvmtiEventVMInit callback = env->callbacks()->VMInit; >> 716: if (callback != nullptr) { >> 717: JvmtiAgent* const agent = lookup_uninitialized_agent(env, reinterpret_cast(callback)); > > It was a surprise to me to discover this code in your changes. > How can it be possible that some agents are left uninitialized at the time of VMInit event? > Have you really observed this? > If so, then can you add a comment explaining the need of this initialization? > Is it needed for JFR purposes only? Ok. the terminology here might be confusing. The concept of an agent being "initialized" is introduced and reported by JFR. For example, here is the JFR event type definition for a NativeAgent: ``` As you can see, there are two fields: initializationTime and IntializationDuration. We report these to let users understand when an agent was initialized (VMInit or Agent_OnAttach), together with the duration it took to execute either. For JavaAgents, it measures the invocation and duration of the premain or agentmain methods. "Initialized" does not mean "loaded" (at this point, all agents are loaded), but rather it means the agent has received a timestamp set as a function of VMInit. This timestamp and duration are what we will report in JFR as part of the event. An "uninitialized" agent is an agent who has not yet been timestamped, as part of VMInit, for example. Since an agent can create multiple JvmtiEnvs, the function is called lookup_unitialized_agent(), because we can only have a single timestamp for an agent, but it can, in turn, have multiple JvmtiEnvs. When looking up an agent again, using a second JvmtiEnv created by it, the agent is already "initialized", so no agent is returned. We cannot have the timestamping logic as part of the call out to Agent_OnLoad, because that call happens very early during VM bootstrap, so the Ticks support structures are not yet in place. But, timing the Agent_OnLoad call would be rather meaningless because the agent cannot do much except construct a JvmtiEnv and setting capabilities and callbacks. VMInit is where most of the invocation logic, at least for JavaAgents happens, so the measurements are placed there. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12923#discussion_r1166568901 From rkennke at openjdk.org Fri Apr 14 11:19:32 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 14 Apr 2023 11:19:32 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v60] In-Reply-To: References: Message-ID: > This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). > > What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. > > This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p rotocols. > > The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare. > > In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. > > One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. > > As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. > > This change enables to simplify (and speed-up!) a lot of code: > > - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. > - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR > > Also, and I might be mistaken here, this new lightweight locking would make synchronized work better with Loom: Because the lock-records are no longer scattered across the stack, but instead are densely packed into the lock-stack, it should be easy for a vthread to save its lock-stack upon unmounting and restore it when re-mounting. However, I am not sure about this, and this PR does not attempt to implement that support. > > Testing: > - [x] tier1 x86_64 x aarch64 x +UseFastLocking > - [x] tier2 x86_64 x aarch64 x +UseFastLocking > - [x] tier3 x86_64 x aarch64 x +UseFastLocking > - [x] tier4 x86_64 x aarch64 x +UseFastLocking > - [x] tier1 x86_64 x aarch64 x -UseFastLocking > - [x] tier2 x86_64 x aarch64 x -UseFastLocking > - [x] tier3 x86_64 x aarch64 x -UseFastLocking > - [x] tier4 x86_64 x aarch64 x -UseFastLocking > - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet > > ### Performance > > #### Simple Microbenchmark > > The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops. > > | | x86_64 | aarch64 | > | -- | -- | -- | > | -UseFastLocking | 20.651 | 20.764 | > | +UseFastLocking | 18.896 | 18.908 | > > > #### Renaissance > > ? | x86_64 | ? | ? | ? | aarch64 | ? | ? > -- | -- | -- | -- | -- | -- | -- | -- > ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? > AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% > Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21% > Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% > ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% > GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% > LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% > MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%% > NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% > PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% > FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% > FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% > ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34% > Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% > RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% > Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% > ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% > FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% > FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 156 commits: - Merge remote-tracking branch 'upstream/master' into JDK-8291555-v2 - A few more LM_ prefixes in 32bit code - Replace UseHeavyMonitor with LockingMode == LM_MONITOR - Prefix LockingMode constants with LM_* - Bunch of comments and typos - Don't use NativeAccess in LockStack::contains() - RISCV update - Put back thread type check in OS::is_lock_owned() - Named constants for LockingMode - Address David's review comments - ... and 146 more: https://git.openjdk.org/jdk/compare/d2ce04bb...d0a448c6 ------------- Changes: https://git.openjdk.org/jdk/pull/10907/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=59 Stats: 2505 lines in 69 files changed: 1682 ins; 109 del; 714 mod Patch: https://git.openjdk.org/jdk/pull/10907.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/10907/head:pull/10907 PR: https://git.openjdk.org/jdk/pull/10907 From duke at openjdk.org Fri Apr 14 13:36:31 2023 From: duke at openjdk.org (Fredrik Bredberg) Date: Fri, 14 Apr 2023 13:36:31 GMT Subject: RFR: 8306006: strace001.java fails due to unknown methods on stack Message-ID: <0MpbrqTjZXqfi6_St4dA5WcxAPZ8ec3P6UwLu0jFKUQ=.599f880e-b0bf-4308-bada-ca075c42ac63@github.com> Added the missing java.lang.Thread.beforeSleep and java.lang.afterSleep to expectedSystemTrace. Tested on my local machine. ------------- Commit messages: - 8306006: strace001.java fails due to unknown methods on stack Changes: https://git.openjdk.org/jdk/pull/13476/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13476&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306006 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13476.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13476/head:pull/13476 PR: https://git.openjdk.org/jdk/pull/13476 From rehn at openjdk.org Fri Apr 14 13:36:31 2023 From: rehn at openjdk.org (Robbin Ehn) Date: Fri, 14 Apr 2023 13:36:31 GMT Subject: RFR: 8306006: strace001.java fails due to unknown methods on stack In-Reply-To: <0MpbrqTjZXqfi6_St4dA5WcxAPZ8ec3P6UwLu0jFKUQ=.599f880e-b0bf-4308-bada-ca075c42ac63@github.com> References: <0MpbrqTjZXqfi6_St4dA5WcxAPZ8ec3P6UwLu0jFKUQ=.599f880e-b0bf-4308-bada-ca075c42ac63@github.com> Message-ID: On Fri, 14 Apr 2023 13:27:37 GMT, Fredrik Bredberg wrote: > Added the missing java.lang.Thread.beforeSleep and java.lang.afterSleep to expectedSystemTrace. > Tested on my local machine. Marked as reviewed by rehn (Reviewer). Looks good to me! ------------- PR Review: https://git.openjdk.org/jdk/pull/13476#pullrequestreview-1385466134 PR Comment: https://git.openjdk.org/jdk/pull/13476#issuecomment-1508507582 From alanb at openjdk.org Fri Apr 14 13:57:33 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 14 Apr 2023 13:57:33 GMT Subject: RFR: 8306006: strace001.java fails due to unknown methods on stack In-Reply-To: <0MpbrqTjZXqfi6_St4dA5WcxAPZ8ec3P6UwLu0jFKUQ=.599f880e-b0bf-4308-bada-ca075c42ac63@github.com> References: <0MpbrqTjZXqfi6_St4dA5WcxAPZ8ec3P6UwLu0jFKUQ=.599f880e-b0bf-4308-bada-ca075c42ac63@github.com> Message-ID: On Fri, 14 Apr 2023 13:27:37 GMT, Fredrik Bredberg wrote: > Added the missing java.lang.Thread.beforeSleep and java.lang.afterSleep to expectedSystemTrace. > Tested on my local machine. Looks good. Apologies we missed this test when updating j.l.Thread, I'm quite sure I didn't see this test failing. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13476#pullrequestreview-1385508753 From rriggs at openjdk.org Fri Apr 14 14:34:51 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 14 Apr 2023 14:34:51 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v13] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Wed, 12 Apr 2023 17:31:49 GMT, Roger Riggs wrote: >> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. >> The enumeration values are defined to match those used in the build. >> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64` >> Note that `amd64` and `x86_64` in the build are represented by `X64`. >> The value of the system property `os.arch` is unchanged. >> >> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). >> Uses in `java.base` and a few others are included but other modules will be done in separate PRs. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Fixed isPPC64(). > Consolidated switch cases in ArchTest. > Moved mapping of build TARGET_OS and TARGET_CPU to the build > to avoid multiple mappings in more than one place. make/modules/java.base/gensrc/GensrcMisc.gmk line 72: > 70: endif > 71: > 72: $(eval $(call SetupTextFileProcessing, BUILD_PLATFORMPROPERTIES_JAVA, \ @erikj79 Is there a better/good way to do these mappings, or select "local" variable names? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1166913016 From mgronlun at openjdk.org Fri Apr 14 14:44:43 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 14 Apr 2023 14:44:43 GMT Subject: RFR: 8257967: JFR: Events for loaded agents [v17] In-Reply-To: <73FsVYPjYuC09PElaj8hwZRKc55HfqdVKsJqJiQVrBU=.9d7d395e-5618-4148-b20c-04d9e5184c01@github.com> References: <73FsVYPjYuC09PElaj8hwZRKc55HfqdVKsJqJiQVrBU=.9d7d395e-5618-4148-b20c-04d9e5184c01@github.com> Message-ID: On Fri, 14 Apr 2023 07:50:39 GMT, Serguei Spitsyn wrote: > Markus, It looks good to me. Overall, it is a nice consolidation of the agent code, good move in general! Thank you for your patience. I've posted one minor request though. Thanks, Serguei Thanks for taking a look Serguei, appreciate it! ------------- PR Comment: https://git.openjdk.org/jdk/pull/12923#issuecomment-1508680453 From erikj at openjdk.org Fri Apr 14 17:10:48 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 14 Apr 2023 17:10:48 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v13] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Fri, 14 Apr 2023 14:31:31 GMT, Roger Riggs wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed isPPC64(). >> Consolidated switch cases in ArchTest. >> Moved mapping of build TARGET_OS and TARGET_CPU to the build >> to avoid multiple mappings in more than one place. > > make/modules/java.base/gensrc/GensrcMisc.gmk line 72: > >> 70: endif >> 71: >> 72: $(eval $(call SetupTextFileProcessing, BUILD_PLATFORMPROPERTIES_JAVA, \ > > @erikj79 Is there a better/good way to do these mappings, or select "local" variable names? Not sure if it's better, but you could consider doing this directly in the switch statements in `make/autoconf/platform.m4` and add the corresponding variables in `spec.gmk.in`. That would make them available globally in the build, which may also be detrimental as parts of the build could start relying on them, and we end up with even more variants sprinkled around. I think what you have here is better for now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1167095379 From jiangli at openjdk.org Fri Apr 14 17:16:24 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 14 Apr 2023 17:16:24 GMT Subject: RFR: 8305935: Resolve multiple definition of 'jmm_' when statically linking with JDK native libraries [v2] In-Reply-To: <97aWCpgt7_5qWV56OxZ_nG3jmZQ_aJHJlbYFpuhV9nc=.d3219cfa-de87-441d-bde7-0b560047984e@github.com> References: <97aWCpgt7_5qWV56OxZ_nG3jmZQ_aJHJlbYFpuhV9nc=.d3219cfa-de87-441d-bde7-0b560047984e@github.com> Message-ID: > Rename 'jmm_' to 'jmm__management_ext' in libmanagement_ext to resolve related linker errors when statically linking with both libmanagement and libmanagement_ext. Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: Add comment suggested by dholmes-ora. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13451/files - new: https://git.openjdk.org/jdk/pull/13451/files/f10e1a06..9d98f728 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13451&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13451&range=00-01 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13451.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13451/head:pull/13451 PR: https://git.openjdk.org/jdk/pull/13451 From jiangli at openjdk.org Fri Apr 14 17:16:26 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 14 Apr 2023 17:16:26 GMT Subject: RFR: 8305935: Resolve multiple definition of 'jmm_' when statically linking with JDK native libraries In-Reply-To: <97aWCpgt7_5qWV56OxZ_nG3jmZQ_aJHJlbYFpuhV9nc=.d3219cfa-de87-441d-bde7-0b560047984e@github.com> References: <97aWCpgt7_5qWV56OxZ_nG3jmZQ_aJHJlbYFpuhV9nc=.d3219cfa-de87-441d-bde7-0b560047984e@github.com> Message-ID: On Wed, 12 Apr 2023 23:35:02 GMT, Jiangli Zhou wrote: > Rename 'jmm_' to 'jmm__management_ext' in libmanagement_ext to resolve related linker errors when statically linking with both libmanagement and libmanagement_ext. Thanks for the review and discussion. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13451#issuecomment-1508978901 From jiangli at openjdk.org Fri Apr 14 17:16:28 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 14 Apr 2023 17:16:28 GMT Subject: RFR: 8305935: Resolve multiple definition of 'jmm_' when statically linking with JDK native libraries [v2] In-Reply-To: References: <97aWCpgt7_5qWV56OxZ_nG3jmZQ_aJHJlbYFpuhV9nc=.d3219cfa-de87-441d-bde7-0b560047984e@github.com> Message-ID: <-F0EefG2_UQGSMBo2k-FLfQKXE100586ZgtGGTjcVVQ=.d49dfc8a-58bd-471f-8f67-e14fce048125@github.com> On Fri, 14 Apr 2023 05:20:48 GMT, David Holmes wrote: >> src/jdk.management/share/native/libmanagement_ext/management_ext.c line 34: >> >>> 32: #define ERR_MSG_SIZE 128 >>> 33: >>> 34: const JmmInterface* jmm_interface_management_ext = NULL; >> >> Can you add a comment before declaring the two "exported" symbols together: >> >> // These symbols are global in this library but need to be uniquely named to avoid conflicts >> // with same-named symbols in other libraries, when statically linking. >> >> Thanks. > > Oops! Sorry meant to add this comment to the declarations in the hpp file. Added comment as suggested (with minor adjustment) in management_ext.h. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13451#discussion_r1167098349 From duke at openjdk.org Fri Apr 14 17:55:43 2023 From: duke at openjdk.org (Afshin Zafari) Date: Fri, 14 Apr 2023 17:55:43 GMT Subject: Integrated: 8305085: Suppress removal warning for finalize() from test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineFinalizer.java In-Reply-To: References: Message-ID: On Tue, 11 Apr 2023 09:03:49 GMT, Afshin Zafari wrote: > The warning message is suppressed out. This pull request has now been integrated. Changeset: 2cc4bf1a Author: Afshin Zafari Committer: Chris Plummer URL: https://git.openjdk.org/jdk/commit/2cc4bf1a9d00dc24ec150e0e39bfdd374eb6eb77 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8305085: Suppress removal warning for finalize() from test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineFinalizer.java Reviewed-by: cjplummer, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/13422 From kevinw at openjdk.org Fri Apr 14 19:39:27 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 14 Apr 2023 19:39:27 GMT Subject: RFR: 8305913: com/sun/jdi/JdbLastErrorTest.java failed with '"lastError = 42' missing from stdout/stderr" Message-ID: This test is failing often since 8304725 added a call to Thread::current_in_asgct(). This can end up being called e.g. when resolving calls, and then the OS last error value is lost. The test is reliable with a single warm-up call to getLastError.invoke() before the loop. The test was introduced when in JDK-8292302 a change was undone that had made JavaThread::threadObj call Thread::current_or_null_safe, as the use of TLS upset this case of accessing last error directly. This new Thread::current_in_asgct() case shows that the VM will find new ways to interfere with the last error value, or at least new VM code keeps wanting to call Thread::current. This testcase is kind of niche usage, so it not an argument that VM code should not be calling Thread::current. If this test is to stay active, it needs to have this warm-up getLastError call. (If there are more issues, it might mean removing the test.) ------------- Commit messages: - 8305913: com/sun/jdi/JdbLastErrorTest.java failed with '"lastError = 42' missing from stdout/stderr" Changes: https://git.openjdk.org/jdk/pull/13481/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13481&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8305913 Stats: 6 lines in 2 files changed: 3 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13481.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13481/head:pull/13481 PR: https://git.openjdk.org/jdk/pull/13481 From dcubed at openjdk.org Fri Apr 14 21:15:31 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 14 Apr 2023 21:15:31 GMT Subject: RFR: 8305913: com/sun/jdi/JdbLastErrorTest.java failed with '"lastError = 42' missing from stdout/stderr" In-Reply-To: References: Message-ID: On Fri, 14 Apr 2023 19:23:05 GMT, Kevin Walls wrote: > This test is failing often since 8304725 added a call to Thread::current_in_asgct(). This can end up being called e.g. when resolving calls, and then the OS last error value is lost. > > The test is reliable with a single warm-up call to getLastError.invoke() before the loop. > > The test was introduced when in JDK-8292302 a change was undone that had made JavaThread::threadObj call Thread::current_or_null_safe, as the use of TLS upset this case of accessing last error directly. > > This new Thread::current_in_asgct() case shows that the VM will find new ways to interfere with the last error value, or at least new VM code keeps wanting to call Thread::current. This testcase is kind of niche usage, so it not an argument that VM code should not be calling Thread::current. If this test is to stay active, it needs to have this warm-up getLastError call. (If there are more issues, it might mean removing the test.) Thumbs up. I think this is a trivial fix, but please get a Serviceability team member to also review. Please do a "/issue JDK-8305913" to sync the PR title with the bug ID synopsis. ------------- Marked as reviewed by dcubed (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13481#pullrequestreview-1386186110 PR Comment: https://git.openjdk.org/jdk/pull/13481#issuecomment-1509277130 From jiangli at openjdk.org Fri Apr 14 21:16:40 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 14 Apr 2023 21:16:40 GMT Subject: Integrated: 8305935: Resolve multiple definition of 'jmm_' when statically linking with JDK native libraries In-Reply-To: <97aWCpgt7_5qWV56OxZ_nG3jmZQ_aJHJlbYFpuhV9nc=.d3219cfa-de87-441d-bde7-0b560047984e@github.com> References: <97aWCpgt7_5qWV56OxZ_nG3jmZQ_aJHJlbYFpuhV9nc=.d3219cfa-de87-441d-bde7-0b560047984e@github.com> Message-ID: On Wed, 12 Apr 2023 23:35:02 GMT, Jiangli Zhou wrote: > Rename 'jmm_' to 'jmm__management_ext' in libmanagement_ext to resolve related linker errors when statically linking with both libmanagement and libmanagement_ext. This pull request has now been integrated. Changeset: 314bad36 Author: Jiangli Zhou URL: https://git.openjdk.org/jdk/commit/314bad36135c6404b31a41efc48954cb5b7877fd Stats: 31 lines in 7 files changed: 3 ins; 0 del; 28 mod 8305935: Resolve multiple definition of 'jmm_' when statically linking with JDK native libraries Reviewed-by: dholmes ------------- PR: https://git.openjdk.org/jdk/pull/13451 From cjplummer at openjdk.org Fri Apr 14 21:23:32 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 14 Apr 2023 21:23:32 GMT Subject: RFR: 8305913: com/sun/jdi/JdbLastErrorTest.java failed with '"lastError = 42' missing from stdout/stderr" In-Reply-To: References: Message-ID: On Fri, 14 Apr 2023 19:23:05 GMT, Kevin Walls wrote: > This test is failing often since 8304725 added a call to Thread::current_in_asgct(). This can end up being called e.g. when resolving calls, and then the OS last error value is lost. > > The test is reliable with a single warm-up call to getLastError.invoke() before the loop. > > The test was introduced when in JDK-8292302 a change was undone that had made JavaThread::threadObj call Thread::current_or_null_safe, as the use of TLS upset this case of accessing last error directly. > > This new Thread::current_in_asgct() case shows that the VM will find new ways to interfere with the last error value, or at least new VM code keeps wanting to call Thread::current. This testcase is kind of niche usage, so it not an argument that VM code should not be calling Thread::current. If this test is to stay active, it needs to have this warm-up getLastError call. (If there are more issues, it might mean removing the test.) I guess I don't understand the purpose of having this test if it is just going to work around the underlying issue it is suppose to be testing for. Does it serve a purpose still? Does it still correctly detect the fix that was done for [JDK-8292302](https://bugs.openjdk.org/browse/JDK-8292302)? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13481#issuecomment-1509287280 From rriggs at openjdk.org Fri Apr 14 21:38:41 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 14 Apr 2023 21:38:41 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v13] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: <0FxAZMAVyrqeR8n81rBSDKzKSL_GF_Qeyv5QbQeRJBI=.8d285dcf-1f72-40bf-a810-94a8cc073e97@github.com> On Fri, 14 Apr 2023 17:08:10 GMT, Erik Joelsson wrote: >> make/modules/java.base/gensrc/GensrcMisc.gmk line 72: >> >>> 70: endif >>> 71: >>> 72: $(eval $(call SetupTextFileProcessing, BUILD_PLATFORMPROPERTIES_JAVA, \ >> >> @erikj79 Is there a better/good way to do these mappings, or select "local" variable names? > > Not sure if it's better, but you could consider doing this directly in the switch statements in `make/autoconf/platform.m4` and add the corresponding variables in `spec.gmk.in`. That would make them available globally in the build, which may also be detrimental as parts of the build could start relying on them, and we end up with even more variants sprinkled around. I think what you have here is better for now. ok, I'd rather keep it local. Thanks ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1167290252 From kevinw at openjdk.org Fri Apr 14 22:01:32 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 14 Apr 2023 22:01:32 GMT Subject: RFR: 8305913: com/sun/jdi/JdbLastErrorTest.java failed with "'lastError = 42' missing from stdout/stderr" In-Reply-To: References: Message-ID: <6bYtZDzPe7SUv70AdarXNoCNIXMnMy78K2uROn2iTy8=.f553526e-7110-4e87-921f-3da6f8a5b1ff@github.com> On Fri, 14 Apr 2023 21:20:46 GMT, Chris Plummer wrote: > I guess I don't understand the purpose of having this test if it is just going to work around the underlying issue it is suppose to be testing for. Does it serve a purpose still? Does it still correctly detect the fix that was done for [JDK-8292302](https://bugs.openjdk.org/browse/JDK-8292302)? Right, and I do wonder about removing it. It is still verifying that you can try and debug a java app that uses panama, and can set and fetch last error using panama, in a debugged target (after you've called getLastError once). Now I'm admitting that various other causes make the first attempt commonly fail, and it is testing that things don't get any _worse_ than the first iteration failing, but no it would not detect if we reverted 8292302. I think it has some value, but in my note above I hinted that if it causes more trouble it should probably go. If anybody thinks it should go now... ------------- PR Comment: https://git.openjdk.org/jdk/pull/13481#issuecomment-1509328958 From sspitsyn at openjdk.org Fri Apr 14 22:07:27 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 14 Apr 2023 22:07:27 GMT Subject: RFR: 8306028: separate ThreadStart/ThreadEnd events posting code in JVMTI VTMS transitions Message-ID: This refactoring to separate ThreadStart/ThreadEnd events posting code in the JVMTI VTMS transitions is needed for future work on JVMTI scalability and performance improvements. It is to easier put this code on slow path. Testing: mach5 tiers 1-6 were successful. ------------- Commit messages: - 8306028: separate ThreadStart/ThreadEnd events posting code in JVMTI VTMS transitions Changes: https://git.openjdk.org/jdk/pull/13484/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13484&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306028 Stats: 161 lines in 4 files changed: 86 ins; 61 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/13484.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13484/head:pull/13484 PR: https://git.openjdk.org/jdk/pull/13484 From sspitsyn at openjdk.org Fri Apr 14 22:24:39 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 14 Apr 2023 22:24:39 GMT Subject: RFR: 8257967: JFR: Events for loaded agents [v17] In-Reply-To: <0gj2kjWDMnEpt_58UH60JCzURC9ZuOowVLom48A69n0=.0c35359f-514a-4526-95ae-2a256d9372d7@github.com> References: <0gj2kjWDMnEpt_58UH60JCzURC9ZuOowVLom48A69n0=.0c35359f-514a-4526-95ae-2a256d9372d7@github.com> Message-ID: On Fri, 14 Apr 2023 09:20:18 GMT, Markus Gr?nlund wrote: >> src/hotspot/share/prims/jvmtiExport.cpp line 717: >> >>> 715: jvmtiEventVMInit callback = env->callbacks()->VMInit; >>> 716: if (callback != nullptr) { >>> 717: JvmtiAgent* const agent = lookup_uninitialized_agent(env, reinterpret_cast(callback)); >> >> It was a surprise to me to discover this code in your changes. >> How can it be possible that some agents are left uninitialized at the time of VMInit event? >> Have you really observed this? >> If so, then can you add a comment explaining the need of this initialization? >> Is it needed for JFR purposes only? > > Ok. the terminology here might be confusing. The concept of an agent being "initialized" is introduced and reported by JFR. For example, here is the JFR event type definition for a NativeAgent: > ``` > thread="false" startTime="false" period="endChunk" stackTrace="false"> > > > > > > > > > As you can see, there are two fields: initializationTime and IntializationDuration. > > We report these to let users understand when an agent was initialized (VMInit or Agent_OnAttach), together with the duration it took to execute either. For JavaAgents, it measures the invocation and duration of the premain or agentmain methods. > > "Initialized" does not mean "loaded" (at this point, all agents are loaded), but rather it means the agent has received a timestamp set as a function of VMInit. This timestamp and duration are what we will report in JFR as part of the event. > > An "uninitialized" agent is an agent who has not yet been timestamped, as part of VMInit, for example. Since an agent can create multiple JvmtiEnvs, the function is called lookup_uninitialized_agent() because we can only have a single timestamp for an agent, but it can, in turn, have multiple JvmtiEnvs. When looking up an agent again, using a second JvmtiEnv created by it, the agent is already "initialized", so no agent is returned. > > We cannot have the timestamping logic as part of the call out to Agent_OnLoad, because that call happens very early during VM bootstrap, so the Ticks support structures are not yet in place. But, timing the Agent_OnLoad call would be rather meaningless because the agent cannot do much except construct a JvmtiEnv and setting capabilities and callbacks. > > VMInit is where most of the invocation logic, at least for JavaAgents happens, so the measurements are placed there. Thank you for explaining it. Could you, please, add small comment explaining that it is for JFR purposes? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12923#discussion_r1167310779 From sspitsyn at openjdk.org Sat Apr 15 00:23:30 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 15 Apr 2023 00:23:30 GMT Subject: RFR: 8306028: separate ThreadStart/ThreadEnd events posting code in JVMTI VTMS transitions [v2] In-Reply-To: References: Message-ID: > This refactoring to separate ThreadStart/ThreadEnd events posting code in the JVMTI VTMS transitions is needed for future work on JVMTI scalability and performance improvements. It is to easier put this code on slow path. > > Testing: mach5 tiers 1-6 were successful. Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: 8304444: Reappearance of NULL in jvmtiThreadState.cpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13484/files - new: https://git.openjdk.org/jdk/pull/13484/files/1f042a16..7735ffac Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13484&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13484&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13484.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13484/head:pull/13484 PR: https://git.openjdk.org/jdk/pull/13484 From duke at openjdk.org Sat Apr 15 01:47:50 2023 From: duke at openjdk.org (duke) Date: Sat, 15 Apr 2023 01:47:50 GMT Subject: Withdrawn: 8299915: Remove ArrayAllocatorMallocLimit and associated code In-Reply-To: References: Message-ID: On Tue, 10 Jan 2023 20:55:12 GMT, Justin King wrote: > Remove abstraction that is a holdover from Solaris. Direct usages of `MmapArrayAllocator` have been switched to normal `malloc`. The justification is that none of the code paths are called from signal handlers, so using `mmap` directly does not make sense and is potentially slower than going through `malloc` which can potentially re-use memory without making any system calls. The remaining usages of `ArrayAllocator` and `MallocArrayAllocator` are equivalent. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/11931 From dholmes at openjdk.org Sat Apr 15 02:42:31 2023 From: dholmes at openjdk.org (David Holmes) Date: Sat, 15 Apr 2023 02:42:31 GMT Subject: RFR: 8306006: strace001.java fails due to unknown methods on stack In-Reply-To: <0MpbrqTjZXqfi6_St4dA5WcxAPZ8ec3P6UwLu0jFKUQ=.599f880e-b0bf-4308-bada-ca075c42ac63@github.com> References: <0MpbrqTjZXqfi6_St4dA5WcxAPZ8ec3P6UwLu0jFKUQ=.599f880e-b0bf-4308-bada-ca075c42ac63@github.com> Message-ID: On Fri, 14 Apr 2023 13:27:37 GMT, Fredrik Bredberg wrote: > Added the missing java.lang.Thread.beforeSleep and java.lang.afterSleep to expectedSystemTrace. > Tested on my local machine. This change is not sufficient. You also have: # ERROR: Length of the stack trace is 206, but expected to be not greater than 205 and if you look at the log: Snapshot of thread: 0 0: jdk.internal.event.ThreadSleepEvent.isEnabled(ThreadSleepEvent.java:-1) 1: jdk.internal.event.ThreadSleepEvent.isTurnedOn(ThreadSleepEvent.java:39) 2: java.lang.Thread.beforeSleep(Thread.java:456) so you need to increase the allowance on the expected depth by 2 and add the two SleepEvent methods to the expected list. I don't think you want to add `afterSleep` as that means the thread woke too soon and we may need to adjust the sleep time. - so we would want that to fail. Thanks. P.S. The comment block at line 209 discussing the extra allowance on stack depth needs updating - it was already inaccurate before these latest Thread changes. Thanks. ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13476#pullrequestreview-1386295135 PR Comment: https://git.openjdk.org/jdk/pull/13476#issuecomment-1509474451 From dholmes at openjdk.org Sat Apr 15 06:58:33 2023 From: dholmes at openjdk.org (David Holmes) Date: Sat, 15 Apr 2023 06:58:33 GMT Subject: RFR: 8305913: com/sun/jdi/JdbLastErrorTest.java failed with "'lastError = 42' missing from stdout/stderr" In-Reply-To: References: Message-ID: On Fri, 14 Apr 2023 19:23:05 GMT, Kevin Walls wrote: > This test is failing often since 8304725 added a call to Thread::current_in_asgct(). This can end up being called e.g. when resolving calls, and then the OS last error value is lost. > > The test is reliable with a single warm-up call to getLastError.invoke() before the loop. > > The test was introduced when in JDK-8292302 a change was undone that had made JavaThread::threadObj call Thread::current_or_null_safe, as the use of TLS upset this case of accessing last error directly. > > This new Thread::current_in_asgct() case shows that the VM will find new ways to interfere with the last error value, or at least new VM code keeps wanting to call Thread::current. This testcase is kind of niche usage, so it not an argument that VM code should not be calling Thread::current. If this test is to stay active, it needs to have this warm-up getLastError call. (If there are more issues, it might mean removing the test.) Looks good - thanks for getting to the bottom of this failure! One suggestion below. test/jdk/com/sun/jdi/JdbLastErrorTest.java line 63: > 61: FunctionDescriptor.ofVoid(ValueLayout.JAVA_INT)); > 62: > 63: // One "warmup" call avoids VM activity (e.g. Thread::current) disturbing last error value. Suggestion: // Perform a "warmup" call to ensure method resolution can't disturb the last error value // that we are trying to set. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13481#pullrequestreview-1386348947 PR Review Comment: https://git.openjdk.org/jdk/pull/13481#discussion_r1167410330 From kevinw at openjdk.org Sat Apr 15 10:15:20 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Sat, 15 Apr 2023 10:15:20 GMT Subject: RFR: 8305913: com/sun/jdi/JdbLastErrorTest.java failed with "'lastError = 42' missing from stdout/stderr" [v2] In-Reply-To: References: Message-ID: > This test is failing often since 8304725 added a call to Thread::current_in_asgct(). This can end up being called e.g. when resolving calls, and then the OS last error value is lost. > > The test is reliable with a single warm-up call to getLastError.invoke() before the loop. > > The test was introduced when in JDK-8292302 a change was undone that had made JavaThread::threadObj call Thread::current_or_null_safe, as the use of TLS upset this case of accessing last error directly. > > This new Thread::current_in_asgct() case shows that the VM will find new ways to interfere with the last error value, or at least new VM code keeps wanting to call Thread::current. This testcase is kind of niche usage, so it not an argument that VM code should not be calling Thread::current. If this test is to stay active, it needs to have this warm-up getLastError call. (If there are more issues, it might mean removing the test.) Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: comment update feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13481/files - new: https://git.openjdk.org/jdk/pull/13481/files/dc91d5ab..1562317c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13481&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13481&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13481.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13481/head:pull/13481 PR: https://git.openjdk.org/jdk/pull/13481 From kevinw at openjdk.org Sat Apr 15 10:15:22 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Sat, 15 Apr 2023 10:15:22 GMT Subject: RFR: 8305913: com/sun/jdi/JdbLastErrorTest.java failed with "'lastError = 42' missing from stdout/stderr" In-Reply-To: References: Message-ID: On Fri, 14 Apr 2023 19:23:05 GMT, Kevin Walls wrote: > This test is failing often since 8304725 added a call to Thread::current_in_asgct(). This can end up being called e.g. when resolving calls, and then the OS last error value is lost. > > The test is reliable with a single warm-up call to getLastError.invoke() before the loop. > > The test was introduced when in JDK-8292302 a change was undone that had made JavaThread::threadObj call Thread::current_or_null_safe, as the use of TLS upset this case of accessing last error directly. > > This new Thread::current_in_asgct() case shows that the VM will find new ways to interfere with the last error value, or at least new VM code keeps wanting to call Thread::current. This testcase is kind of niche usage, so it not an argument that VM code should not be calling Thread::current. If this test is to stay active, it needs to have this warm-up getLastError call. (If there are more issues, it might mean removing the test.) Thanks for the feedback! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13481#issuecomment-1509715147 From duke at openjdk.org Sat Apr 15 17:23:43 2023 From: duke at openjdk.org (Glavo) Date: Sat, 15 Apr 2023 17:23:43 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v13] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Wed, 12 Apr 2023 17:31:49 GMT, Roger Riggs wrote: >> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. >> The enumeration values are defined to match those used in the build. >> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64` >> Note that `amd64` and `x86_64` in the build are represented by `X64`. >> The value of the system property `os.arch` is unchanged. >> >> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). >> Uses in `java.base` and a few others are included but other modules will be done in separate PRs. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Fixed isPPC64(). > Consolidated switch cases in ArchTest. > Moved mapping of build TARGET_OS and TARGET_CPU to the build > to avoid multiple mappings in more than one place. The RISC-V 64 part look good, `ArchTest` has passed on Debian RISC-V 64. test/jdk/jdk/internal/util/ArchTest.java line 70: > 68: case "x86", "i386" -> X86; > 69: case "aarch64" -> AARCH64; > 70: case "riscv64" -> RISCV64; // unverified Suggestion: case "riscv64" -> RISCV64; ------------- Marked as reviewed by Glavo at github.com (no known OpenJDK username). PR Review: https://git.openjdk.org/jdk/pull/13357#pullrequestreview-1386559067 PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1167584685 From dholmes at openjdk.org Sat Apr 15 23:59:32 2023 From: dholmes at openjdk.org (David Holmes) Date: Sat, 15 Apr 2023 23:59:32 GMT Subject: RFR: 8305913: com/sun/jdi/JdbLastErrorTest.java failed with "'lastError = 42' missing from stdout/stderr" [v2] In-Reply-To: References: Message-ID: On Sat, 15 Apr 2023 10:15:20 GMT, Kevin Walls wrote: >> This test is failing often since 8304725 added a call to Thread::current_in_asgct(). This can end up being called e.g. when resolving calls, and then the OS last error value is lost. >> >> The test is reliable with a single warm-up call to getLastError.invoke() before the loop. >> >> The test was introduced when in JDK-8292302 a change was undone that had made JavaThread::threadObj call Thread::current_or_null_safe, as the use of TLS upset this case of accessing last error directly. >> >> This new Thread::current_in_asgct() case shows that the VM will find new ways to interfere with the last error value, or at least new VM code keeps wanting to call Thread::current. This testcase is kind of niche usage, so it not an argument that VM code should not be calling Thread::current. If this test is to stay active, it needs to have this warm-up getLastError call. (If there are more issues, it might mean removing the test.) > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > comment update feedback Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13481#pullrequestreview-1386638869 From duke at openjdk.org Sun Apr 16 05:33:45 2023 From: duke at openjdk.org (Logan Abernathy) Date: Sun, 16 Apr 2023 05:33:45 GMT Subject: RFR: 8305913: com/sun/jdi/JdbLastErrorTest.java failed with "'lastError = 42' missing from stdout/stderr" [v2] In-Reply-To: References: Message-ID: On Sat, 15 Apr 2023 10:15:20 GMT, Kevin Walls wrote: >> This test is failing often since 8304725 added a call to Thread::current_in_asgct(). This can end up being called e.g. when resolving calls, and then the OS last error value is lost. >> >> The test is reliable with a single warm-up call to getLastError.invoke() before the loop. >> >> The test was introduced when in JDK-8292302 a change was undone that had made JavaThread::threadObj call Thread::current_or_null_safe, as the use of TLS upset this case of accessing last error directly. >> >> This new Thread::current_in_asgct() case shows that the VM will find new ways to interfere with the last error value, or at least new VM code keeps wanting to call Thread::current. This testcase is kind of niche usage, so it not an argument that VM code should not be calling Thread::current. If this test is to stay active, it needs to have this warm-up getLastError call. (If there are more issues, it might mean removing the test.) > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > comment update feedback Marked as reviewed by M4ximumPizza at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jdk/pull/13481#pullrequestreview-1386683574 From alanb at openjdk.org Sun Apr 16 08:10:34 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 16 Apr 2023 08:10:34 GMT Subject: RFR: 8306006: strace001.java fails due to unknown methods on stack In-Reply-To: <0MpbrqTjZXqfi6_St4dA5WcxAPZ8ec3P6UwLu0jFKUQ=.599f880e-b0bf-4308-bada-ca075c42ac63@github.com> References: <0MpbrqTjZXqfi6_St4dA5WcxAPZ8ec3P6UwLu0jFKUQ=.599f880e-b0bf-4308-bada-ca075c42ac63@github.com> Message-ID: On Fri, 14 Apr 2023 13:27:37 GMT, Fredrik Bredberg wrote: > Added the missing java.lang.Thread.beforeSleep and java.lang.afterSleep to expectedSystemTrace. > Tested on my local machine. David seems to be right, this test needs further work. David seems to be right, this test needs further work. ------------- PR Review: https://git.openjdk.org/jdk/pull/13476#pullrequestreview-1386736913 Changes requested by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13476#pullrequestreview-1386737268 From alanb at openjdk.org Sun Apr 16 08:10:34 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 16 Apr 2023 08:10:34 GMT Subject: RFR: 8306006: strace001.java fails due to unknown methods on stack In-Reply-To: References: <0MpbrqTjZXqfi6_St4dA5WcxAPZ8ec3P6UwLu0jFKUQ=.599f880e-b0bf-4308-bada-ca075c42ac63@github.com> Message-ID: On Sat, 15 Apr 2023 02:38:11 GMT, David Holmes wrote: > I don't think you want to add `afterSleep` as that means the thread woke too soon and we may need to adjust the sleep time. - so we would want that to fail. If I read the test correctly, "RunningThread" does recursive calls and eventually calls waitForSign where it spins calling Thread.sleep(1). The observer calling java.lang.management.ThreadInfo::getStackTrace could sample the thread in Thread.sleep at any time so I think it may see afterSleep in the stack. I don't know if there is any value doing this, would it loose anything to ignore any frames deeper than Thread.sleep(long)? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13476#issuecomment-1510169356 From dholmes at openjdk.org Mon Apr 17 01:37:43 2023 From: dholmes at openjdk.org (David Holmes) Date: Mon, 17 Apr 2023 01:37:43 GMT Subject: RFR: 8306006: strace001.java fails due to unknown methods on stack In-Reply-To: References: <0MpbrqTjZXqfi6_St4dA5WcxAPZ8ec3P6UwLu0jFKUQ=.599f880e-b0bf-4308-bada-ca075c42ac63@github.com> Message-ID: On Sun, 16 Apr 2023 08:06:32 GMT, Alan Bateman wrote: > The observer calling java.lang.management.ThreadInfo::getStackTrace could sample the thread in Thread.sleep at any time so I think it may see afterSleep in the stack. Thanks @AlanBateman -Yes, sorry, the test doesn't do what I expected - the sleep is actually incidental so it copuld be sampled anywhere. > and add the two SleepEvent methods to the expected list. I see now those two methods are already present, so just the stack depth check needs updating. Of course if this test were ever run with these events enabled then it could fail for a variety of reasons. BTW the comments in TestDescription.java for strace00* are all inaccurate with regards to this: 2. The length of a trace must not be greater than (depth + 3). ------------- PR Comment: https://git.openjdk.org/jdk/pull/13476#issuecomment-1510571422 From jvernee at openjdk.org Mon Apr 17 06:30:33 2023 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 17 Apr 2023 06:30:33 GMT Subject: RFR: 8305913: com/sun/jdi/JdbLastErrorTest.java failed with "'lastError = 42' missing from stdout/stderr" [v2] In-Reply-To: References: Message-ID: <7gITC0CATbEkPWDGAFAtiFDp5NMYLIWkM0t8zhW7tGk=.1b57cd7c-c293-4aad-8330-2af65fd11286@github.com> On Sat, 15 Apr 2023 10:15:20 GMT, Kevin Walls wrote: >> This test is failing often since 8304725 added a call to Thread::current_in_asgct(). This can end up being called e.g. when resolving calls, and then the OS last error value is lost. >> >> The test is reliable with a single warm-up call to getLastError.invoke() before the loop. >> >> The test was introduced when in JDK-8292302 a change was undone that had made JavaThread::threadObj call Thread::current_or_null_safe, as the use of TLS upset this case of accessing last error directly. >> >> This new Thread::current_in_asgct() case shows that the VM will find new ways to interfere with the last error value, or at least new VM code keeps wanting to call Thread::current. This testcase is kind of niche usage, so it not an argument that VM code should not be calling Thread::current. If this test is to stay active, it needs to have this warm-up getLastError call. (If there are more issues, it might mean removing the test.) > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > comment update feedback FWIW, this behavior is not required by Panama. We've chosen another approach to capturing the last error code so that it can not be overwritten by the VM. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13481#issuecomment-1510777940 From mgronlun at openjdk.org Mon Apr 17 09:17:45 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 17 Apr 2023 09:17:45 GMT Subject: RFR: 8257967: JFR: Events for loaded agents [v17] In-Reply-To: References: <0gj2kjWDMnEpt_58UH60JCzURC9ZuOowVLom48A69n0=.0c35359f-514a-4526-95ae-2a256d9372d7@github.com> Message-ID: On Fri, 14 Apr 2023 22:22:13 GMT, Serguei Spitsyn wrote: >> Ok. the terminology here might be confusing. The concept of an agent being "initialized" is introduced and reported by JFR. For example, here is the JFR event type definition for a NativeAgent: >> ``` >> > thread="false" startTime="false" period="endChunk" stackTrace="false"> >> >> >> >> >> >> >> >> >> As you can see, there are two fields: initializationTime and IntializationDuration. >> >> We report these to let users understand when an agent was initialized (VMInit or Agent_OnAttach), together with the duration it took to execute either. For JavaAgents, it measures the invocation and duration of the premain or agentmain methods. >> >> "Initialized" does not mean "loaded" (at this point, all agents are loaded), but rather it means the agent has received a timestamp set as a function of VMInit. This timestamp and duration are what we will report in JFR as part of the event. >> >> An "uninitialized" agent is an agent who has not yet been timestamped, as part of VMInit, for example. Since an agent can create multiple JvmtiEnvs, the function is called lookup_uninitialized_agent() because we can only have a single timestamp for an agent, but it can, in turn, have multiple JvmtiEnvs. When looking up an agent again, using a second JvmtiEnv created by it, the agent is already "initialized", so no agent is returned. >> >> We cannot have the timestamping logic as part of the call out to Agent_OnLoad, because that call happens very early during VM bootstrap, so the Ticks support structures are not yet in place. But, timing the Agent_OnLoad call would be rather meaningless because the agent cannot do much except construct a JvmtiEnv and setting capabilities and callbacks. >> >> VMInit is where most of the invocation logic, at least for JavaAgents happens, so the measurements are placed there. > > Thank you for explaining it. > Could you, please, add small comment explaining that it is for JFR purposes? Will do. Thank you, Serguei. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12923#discussion_r1168407443 From mgronlun at openjdk.org Mon Apr 17 09:36:56 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 17 Apr 2023 09:36:56 GMT Subject: RFR: 8257967: JFR: Events for loaded agents [v18] In-Reply-To: References: Message-ID: > Greetings, > > We are adding support to let JFR report on Agents. > > #### Design > > An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize. > > A JavaAgent is an agent written in the Java programming language, using the APIs in the package [java.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html) > > A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services. > > To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples: > > // Command line > jdk.JavaAgent { > startTime = 12:31:19.789 (2023-03-08) > name = "JavaAgent.jar" > options = "foo=bar" > dynamic = false > initializationTime = 12:31:15.574 (2023-03-08) > initializationDuration = 172 ms > } > > // Dynamic load > jdk.JavaAgent { > startTime = 12:31:31.158 (2023-03-08) > name = "JavaAgent.jar" > options = "bar=baz" > dynamic = true > initializationTime = 12:31:31.037 (2023-03-08) > initializationDuration = 64,1 ms > } > > The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents. > > For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar. > > The "dynamic" field denotes if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true) > > "initializationTime" is the timestamp the JVM invoked the initialization method, and "initializationDuration" is the duration of executing the initialization method. > > "startTime" represents the time the JFR framework issued the periodic event; hence "initializationTime" will be earlier than "startTime". > > An agent can also be written in a native programming language using the [JVM Tools Interface (JVMTI)](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file. > > To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example: > > jdk.NativeAgent { > startTime = 12:31:40.398 (2023-03-08) > name = "jdwp" > options = "transport=dt_socket,server=y,address=any,onjcmd=y" > dynamic = false > initializationTime = 12:31:36.142 (2023-03-08) > initializationDuration = 0,00184 ms > path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll" > } > > The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported. > > The initialization of a native agent is performed by invoking an agent-specified callback routine. The "initializationTime" is when the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationDuration" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationDuration" will be 0. If the agent is loaded dynamically, "initializationDuration" is the time taken to execute the Agent_OnAttach callback. > > #### Implementation > > There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization ? as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before. > > Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize. > > When implementing this capability, it was necessary to refactor the code used to represent agents, AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp. > > The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp. > > The previous two lists that maintained "agents" (JVMTI) and "libraries" (Xrun) were not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced. > > Testing: jdk_jfr, tier 1 - 6 > > Thanks > Markus Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision: - capital letter - explanatory comment in jvmtiExport.cpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/12923/files - new: https://git.openjdk.org/jdk/pull/12923/files/85f06038..140079c7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=12923&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12923&range=16-17 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/12923.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/12923/head:pull/12923 PR: https://git.openjdk.org/jdk/pull/12923 From mgronlun at openjdk.org Mon Apr 17 09:37:44 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 17 Apr 2023 09:37:44 GMT Subject: RFR: 8257967: JFR: Events for loaded agents [v4] In-Reply-To: References: Message-ID: On Thu, 9 Mar 2023 00:23:39 GMT, David Holmes wrote: >> No need to load any JFR classes. No change to startup logic. > >> No need to load any JFR classes. > > I thought JFR was all Java-based these days. But if no Java involved then that is good. > >> No change to startup logic. > > I flagged a change in my comment above. Thank you @dholmes-ora, @sspitsyn and @adinn for your reviews and sticking with this one for quite some time. ------------- PR Comment: https://git.openjdk.org/jdk/pull/12923#issuecomment-1511011114 From mgronlun at openjdk.org Mon Apr 17 10:29:01 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 17 Apr 2023 10:29:01 GMT Subject: Integrated: 8257967: JFR: Events for loaded agents In-Reply-To: References: Message-ID: On Wed, 8 Mar 2023 12:41:15 GMT, Markus Gr?nlund wrote: > Greetings, > > We are adding support to let JFR report on Agents. > > #### Design > > An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize. > > A JavaAgent is an agent written in the Java programming language, using the APIs in the package [java.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/java.instrument/java/lang/instrument/package-summary.html) > > A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services. > > To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples: > > // Command line > jdk.JavaAgent { > startTime = 12:31:19.789 (2023-03-08) > name = "JavaAgent.jar" > options = "foo=bar" > dynamic = false > initializationTime = 12:31:15.574 (2023-03-08) > initializationDuration = 172 ms > } > > // Dynamic load > jdk.JavaAgent { > startTime = 12:31:31.158 (2023-03-08) > name = "JavaAgent.jar" > options = "bar=baz" > dynamic = true > initializationTime = 12:31:31.037 (2023-03-08) > initializationDuration = 64,1 ms > } > > The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents. > > For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar. > > The "dynamic" field denotes if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true) > > "initializationTime" is the timestamp the JVM invoked the initialization method, and "initializationDuration" is the duration of executing the initialization method. > > "startTime" represents the time the JFR framework issued the periodic event; hence "initializationTime" will be earlier than "startTime". > > An agent can also be written in a native programming language using the [JVM Tools Interface (JVMTI)](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file. > > To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example: > > jdk.NativeAgent { > startTime = 12:31:40.398 (2023-03-08) > name = "jdwp" > options = "transport=dt_socket,server=y,address=any,onjcmd=y" > dynamic = false > initializationTime = 12:31:36.142 (2023-03-08) > initializationDuration = 0,00184 ms > path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll" > } > > The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported. > > The initialization of a native agent is performed by invoking an agent-specified callback routine. The "initializationTime" is when the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationDuration" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationDuration" will be 0. If the agent is loaded dynamically, "initializationDuration" is the time taken to execute the Agent_OnAttach callback. > > #### Implementation > > There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization ? as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before. > > Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize. > > When implementing this capability, it was necessary to refactor the code used to represent agents, AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp. > > The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp. > > The previous two lists that maintained "agents" (JVMTI) and "libraries" (Xrun) were not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced. > > Testing: jdk_jfr, tier 1 - 6 > > Thanks > Markus This pull request has now been integrated. Changeset: 5c95bb1c Author: Markus Gr?nlund URL: https://git.openjdk.org/jdk/commit/5c95bb1c5146e13dd213d5ca6e02e2a02ca0323e Stats: 1893 lines in 23 files changed: 1375 ins; 487 del; 31 mod 8257967: JFR: Events for loaded agents Reviewed-by: dholmes, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/12923 From rriggs at openjdk.org Mon Apr 17 17:14:33 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 17 Apr 2023 17:14:33 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v14] In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: > Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. > The enumeration values are defined to match those used in the build. > The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64` > Note that `amd64` and `x86_64` in the build are represented by `X64`. > The value of the system property `os.arch` is unchanged. > > The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). > Uses in `java.base` and a few others are included but other modules will be done in separate PRs. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: ArchTest on Debian RISC-V 64 confirmed by reviewer ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13357/files - new: https://git.openjdk.org/jdk/pull/13357/files/0cd6ce70..7094db61 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=12-13 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13357/head:pull/13357 PR: https://git.openjdk.org/jdk/pull/13357 From jiangli at openjdk.org Mon Apr 17 17:25:16 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 17 Apr 2023 17:25:16 GMT Subject: RFR: 8306033: Resolve multiple definition of 'throwIOException' and friends when statically linking with JDK native libraries Message-ID: - Make functions 'static' when feasible: - throwByName() in src/java.security.jgss/share/native/libj2gss/NativeUtil.c. - throwByName(), throwIOException() and throwNullPointerException() in src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c. - throwByName() in src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c. - throwOutOfMemoryError() in src/java.smartcardio/share/native/libj2pcsc/pcsc.c. - Move throwDisconnectedRuntimeException() to src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c since it's only used in the file. Make it static. - Move throw_internal_error() to src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c as it's only used in the file. Make it static. - Rename functions by following the existing naming usages in different libraries code: - Rename throwOutOfMemoryError() to gssThrowOutOfMemoryError() in libj2gss. - Rename throwOutOfMemoryError() to p11ThrowOutOfMemoryError() in libj2pks11. - Rename throwNullPointerException() to p11ThrowNullPointerException() in libj2pks11. - Rename throwIOException() to p11ThrowIOException() in libj2pks11. - Rename throwPKCS11RuntimeException() to p11ThrowPKCS11RuntimeException() in libj2pks11. This function only exists in libj2pks11. The rename is done so the function naming is consistent with the other throw functions. - Remove throw_internal_error() from src/java.management/share/native/libmanagement/management.h and src/java.management/share/native/libmanagement/management.c. It's not used. - Remove throw_internal_error() from src/jdk.management/share/native/libmanagement_ext/management_ext.h and src/jdk.management/share/native/libmanagement_ext/management_ext.c. ------------- Commit messages: - - Fix whitespaces in p11_util.c. - 8306033: Resolve multiple definition of 'throwIOException' and friends when statically linking with JDK native libraries Changes: https://git.openjdk.org/jdk/pull/13497/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13497&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306033 Stats: 162 lines in 25 files changed: 17 ins; 28 del; 117 mod Patch: https://git.openjdk.org/jdk/pull/13497.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13497/head:pull/13497 PR: https://git.openjdk.org/jdk/pull/13497 From rriggs at openjdk.org Mon Apr 17 17:31:52 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 17 Apr 2023 17:31:52 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v13] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Sat, 15 Apr 2023 17:17:13 GMT, Glavo wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed isPPC64(). >> Consolidated switch cases in ArchTest. >> Moved mapping of build TARGET_OS and TARGET_CPU to the build >> to avoid multiple mappings in more than one place. > > test/jdk/jdk/internal/util/ArchTest.java line 70: > >> 68: case "x86", "i386" -> X86; >> 69: case "aarch64" -> AARCH64; >> 70: case "riscv64" -> RISCV64; // unverified > > Suggestion: > > case "riscv64" -> RISCV64; @Glavo Thanks for verifying. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1169059529 From rkennke at openjdk.org Mon Apr 17 20:04:26 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 17 Apr 2023 20:04:26 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v60] In-Reply-To: References: Message-ID: On Fri, 14 Apr 2023 11:19:32 GMT, Roman Kennke wrote: >> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). >> >> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. >> >> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal protocols. >> >> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare. >> >> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. >> >> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. >> >> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. >> >> This change enables to simplify (and speed-up!) a lot of code: >> >> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. >> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR >> >> Also, and I might be mistaken here, this new lightweight locking would make synchronized work better with Loom: Because the lock-records are no longer scattered across the stack, but instead are densely packed into the lock-stack, it should be easy for a vthread to save its lock-stack upon unmounting and restore it when re-mounting. However, I am not sure about this, and this PR does not attempt to implement that support. >> >> Testing: >> - [x] tier1 x86_64 x aarch64 x +UseFastLocking >> - [x] tier2 x86_64 x aarch64 x +UseFastLocking >> - [x] tier3 x86_64 x aarch64 x +UseFastLocking >> - [x] tier4 x86_64 x aarch64 x +UseFastLocking >> - [x] tier1 x86_64 x aarch64 x -UseFastLocking >> - [x] tier2 x86_64 x aarch64 x -UseFastLocking >> - [x] tier3 x86_64 x aarch64 x -UseFastLocking >> - [x] tier4 x86_64 x aarch64 x -UseFastLocking >> - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet >> >> ### Performance >> >> #### Simple Microbenchmark >> >> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops. >> >> | | x86_64 | aarch64 | >> | -- | -- | -- | >> | -UseFastLocking | 20.651 | 20.764 | >> | +UseFastLocking | 18.896 | 18.908 | >> >> >> #### Renaissance >> >> ? | x86_64 | ? | ? | ? | aarch64 | ? | ? >> -- | -- | -- | -- | -- | -- | -- | -- >> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? >> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% >> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21% >> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% >> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% >> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% >> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% >> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%% >> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% >> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% >> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% >> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% >> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34% >> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% >> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% >> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% >> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% >> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% >> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% >> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% >> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% >> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% > > Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 156 commits: > > - Merge remote-tracking branch 'upstream/master' into JDK-8291555-v2 > - A few more LM_ prefixes in 32bit code > - Replace UseHeavyMonitor with LockingMode == LM_MONITOR > - Prefix LockingMode constants with LM_* > - Bunch of comments and typos > - Don't use NativeAccess in LockStack::contains() > - RISCV update > - Put back thread type check in OS::is_lock_owned() > - Named constants for LockingMode > - Address David's review comments > - ... and 146 more: https://git.openjdk.org/jdk/compare/d2ce04bb...d0a448c6 Hi there, what is needed to bring this PR over the approval line? ------------- PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1512003092 From rkennke at openjdk.org Mon Apr 17 20:10:38 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 17 Apr 2023 20:10:38 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v61] In-Reply-To: References: Message-ID: > This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). > > What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. > > This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p rotocols. > > The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare. > > In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. > > One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. > > As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. > > This change enables to simplify (and speed-up!) a lot of code: > > - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. > - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR > > Also, and I might be mistaken here, this new lightweight locking would make synchronized work better with Loom: Because the lock-records are no longer scattered across the stack, but instead are densely packed into the lock-stack, it should be easy for a vthread to save its lock-stack upon unmounting and restore it when re-mounting. However, I am not sure about this, and this PR does not attempt to implement that support. > > Testing: > - [x] tier1 x86_64 x aarch64 x +UseFastLocking > - [x] tier2 x86_64 x aarch64 x +UseFastLocking > - [x] tier3 x86_64 x aarch64 x +UseFastLocking > - [x] tier4 x86_64 x aarch64 x +UseFastLocking > - [x] tier1 x86_64 x aarch64 x -UseFastLocking > - [x] tier2 x86_64 x aarch64 x -UseFastLocking > - [x] tier3 x86_64 x aarch64 x -UseFastLocking > - [x] tier4 x86_64 x aarch64 x -UseFastLocking > - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet > > ### Performance > > #### Simple Microbenchmark > > The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops. > > | | x86_64 | aarch64 | > | -- | -- | -- | > | -UseFastLocking | 20.651 | 20.764 | > | +UseFastLocking | 18.896 | 18.908 | > > > #### Renaissance > > ? | x86_64 | ? | ? | ? | aarch64 | ? | ? > -- | -- | -- | -- | -- | -- | -- | -- > ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? > AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% > Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21% > Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% > ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% > GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% > LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% > MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%% > NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% > PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% > FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% > FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% > ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34% > Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% > RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% > Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% > ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% > FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% > FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Simple build fix for extra arches ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10907/files - new: https://git.openjdk.org/jdk/pull/10907/files/d0a448c6..c3486726 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=60 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=59-60 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10907.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/10907/head:pull/10907 PR: https://git.openjdk.org/jdk/pull/10907 From rriggs at openjdk.org Mon Apr 17 20:59:06 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 17 Apr 2023 20:59:06 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v15] In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: > Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. > The enumeration values are defined to match those used in the build. > The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64` > Note that `amd64` and `x86_64` in the build are represented by `X64`. > The value of the system property `os.arch` is unchanged. > > The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). > Uses in `java.base` and a few others are included but other modules will be done in separate PRs. Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: - Merge branch 'master' into 8304915-arch-enum - ArchTest on Debian RISC-V 64 confirmed by reviewer - Fixed isPPC64(). Consolidated switch cases in ArchTest. Moved mapping of build TARGET_OS and TARGET_CPU to the build to avoid multiple mappings in more than one place. - Correct mapping and test of ppc64 - Add ppc64 as mapping to PPC64 Architecture - Modified test to check Architecture is64bits() and isLittleEndian() against Unsafe respective values. Relocated code mapping OS name and arch name from PlatformProps to OperatingSystem and Architecture. Kept the mapping of names in the template close to where the values are filled in by the build. - Remove unused static and import of Stabile - Rename OperatingSystemProps to PlatformProps. Refactor OperatingSystem initialization to use strings instead of integers. - Revised mapping mechanism of build target architecture names to enum values. Unrecognized values from the build are mapped to enum value "OTHER". Renamed PPC64LE to PPC64 to reflect only the architecture, not the endianness. Added an `isLittleEndian` method to return the endianness (not currently used anywhere) - Revert changes to jdk.accessibility AccessBridge - ... and 7 more: https://git.openjdk.org/jdk/compare/8858d543...99a93b7e ------------- Changes: https://git.openjdk.org/jdk/pull/13357/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=14 Stats: 410 lines in 7 files changed: 342 ins; 57 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/13357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13357/head:pull/13357 PR: https://git.openjdk.org/jdk/pull/13357 From fyang at openjdk.org Tue Apr 18 03:33:35 2023 From: fyang at openjdk.org (Fei Yang) Date: Tue, 18 Apr 2023 03:33:35 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v61] In-Reply-To: References: Message-ID: On Mon, 17 Apr 2023 20:10:38 GMT, Roman Kennke wrote: >> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). >> >> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. >> >> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal protocols. >> >> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare. >> >> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. >> >> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. >> >> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. >> >> This change enables to simplify (and speed-up!) a lot of code: >> >> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. >> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR >> >> Also, and I might be mistaken here, this new lightweight locking would make synchronized work better with Loom: Because the lock-records are no longer scattered across the stack, but instead are densely packed into the lock-stack, it should be easy for a vthread to save its lock-stack upon unmounting and restore it when re-mounting. However, I am not sure about this, and this PR does not attempt to implement that support. >> >> Testing: >> - [x] tier1 x86_64 x aarch64 x +UseFastLocking >> - [x] tier2 x86_64 x aarch64 x +UseFastLocking >> - [x] tier3 x86_64 x aarch64 x +UseFastLocking >> - [x] tier4 x86_64 x aarch64 x +UseFastLocking >> - [x] tier1 x86_64 x aarch64 x -UseFastLocking >> - [x] tier2 x86_64 x aarch64 x -UseFastLocking >> - [x] tier3 x86_64 x aarch64 x -UseFastLocking >> - [x] tier4 x86_64 x aarch64 x -UseFastLocking >> - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet >> >> ### Performance >> >> #### Simple Microbenchmark >> >> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops. >> >> | | x86_64 | aarch64 | >> | -- | -- | -- | >> | -UseFastLocking | 20.651 | 20.764 | >> | +UseFastLocking | 18.896 | 18.908 | >> >> >> #### Renaissance >> >> ? | x86_64 | ? | ? | ? | aarch64 | ? | ? >> -- | -- | -- | -- | -- | -- | -- | -- >> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? >> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% >> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21% >> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% >> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% >> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% >> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% >> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%% >> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% >> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% >> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% >> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% >> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34% >> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% >> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% >> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% >> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% >> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% >> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% >> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% >> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% >> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Simple build fix for extra arches Hello, please add a few more changes for riscv making use of the 'test_bit' introduced recently. This function will use 'bexti' instruction from the Zbs extension to do single-bit testing when available. Tier1-3 tested on linux-riscv64 unmatched boards with LockingMode set to LM_LIGHTWEIGHT. [riscv-test_bit.txt](https://github.com/openjdk/jdk/files/11257602/riscv-test_bit.txt) ------------- PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1512382864 From iklam at openjdk.org Tue Apr 18 05:13:10 2023 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 18 Apr 2023 05:13:10 GMT Subject: RFR: 8298048: Combine CDS archive heap into a single block [v6] In-Reply-To: References: Message-ID: > This PR combines the "open" and "closed" regions of the CDS archive heap into a single region. This significantly simplifies the implementation, making it more compatible with non-G1 collectors. There's a net removal of ~1000 lines in src code and another ~1200 lines of tests. > > **Notes for reviewers:** > - Most of the code changes in CDS are removing the handling of "open" vs "closed" objects. > - Reviewers can start with ArchiveHeapWriter::copy_source_objs_to_buffer(). > - It might be easier to see the diff with whitespaces off. > - There are two major changes in the G1 code > - The archived objects are now stored in the "old" region (see g1CollectedHeap.cpp in [58d720e](https://github.com/openjdk/jdk/pull/13284/commits/58d720e294bb36f21cb88cddde724ed2b9e93770)) > - The majority of the other changes are removal of the "archive" region type (see heapRegionType.hpp). For ease of review, such code is isolated in [a852dfb](https://github.com/openjdk/jdk/pull/13284/commits/a852dfbbf5ff56e035399f7cc3704f29e76697f6) > - Testing changes: > - Now the archived java objects can move, along with the "old" regions that contain them. It's no longer possible to test whether a heap object came from CDS. As a result, the `WhiteBox.isShared(Object o)` API has been removed. > - Many tests that uses this API are removed. Most of them were written during early development of CDS archived objects and are no longer relevant. > > **Testing:** > - Mach5 tiers 1 ~ 7 Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - fixed merge - Merge branch 'master' into 8298048-combine-cds-heap-to-single-region-PUSH - removed G1CollectedHeap::fill_archive_regions() -- we no longer have unused space at the start of the "old" regions - Simplified of runtime range of the mapped archive heap - @ashu-mehra comments; some clean up - @ashu-mehra comments - Merge branch 'master' into 8298048-combine-cds-heap-to-single-region-PUSH - more clean up: heap_regions -> heap_region, etc - @matias9927 comments - Remove archive region types from G1 - ... and 2 more: https://git.openjdk.org/jdk/compare/e3ece365...3543dd2a ------------- Changes: https://git.openjdk.org/jdk/pull/13284/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13284&range=05 Stats: 3152 lines in 77 files changed: 121 ins; 2371 del; 660 mod Patch: https://git.openjdk.org/jdk/pull/13284.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13284/head:pull/13284 PR: https://git.openjdk.org/jdk/pull/13284 From jpai at openjdk.org Tue Apr 18 06:06:42 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 18 Apr 2023 06:06:42 GMT Subject: RFR: 8306033: Resolve multiple definition of 'throwIOException' and friends when statically linking with JDK native libraries In-Reply-To: References: Message-ID: On Mon, 17 Apr 2023 16:56:31 GMT, Jiangli Zhou wrote: > - Make functions 'static' when feasible: > - throwByName() in src/java.security.jgss/share/native/libj2gss/NativeUtil.c. > - throwByName(), throwIOException() and throwNullPointerException() in src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c. > - throwByName() in src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c. > - throwOutOfMemoryError() in src/java.smartcardio/share/native/libj2pcsc/pcsc.c. > - Move throwDisconnectedRuntimeException() to src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c since it's only used in the file. Make it static. > - Move throw_internal_error() to src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c as it's only used in the file. Make it static. > > - Rename functions by following the existing naming usages in different libraries code: > - Rename throwOutOfMemoryError() to gssThrowOutOfMemoryError() in libj2gss. > - Rename throwOutOfMemoryError() to p11ThrowOutOfMemoryError() in libj2pks11. > - Rename throwNullPointerException() to p11ThrowNullPointerException() in libj2pks11. > - Rename throwIOException() to p11ThrowIOException() in libj2pks11. > - Rename throwPKCS11RuntimeException() to p11ThrowPKCS11RuntimeException() in libj2pks11. This function only exists in libj2pks11. The rename is done so the function naming is consistent with the other throw functions. > > - Remove throw_internal_error() from src/java.management/share/native/libmanagement/management.h and src/java.management/share/native/libmanagement/management.c. It's not used. > - Remove throw_internal_error() from src/jdk.management/share/native/libmanagement_ext/management_ext.h and src/jdk.management/share/native/libmanagement_ext/management_ext.c. Hello Jiangli, I have no experience in C language or the symbol linking that's involved in this PR, but given similar PRs that have been merged recently, is there some way these issues can be caught when code changes are being reviewed in future? Or would this require explicit run of some tool to identify these issues? I realize that you have been working on JDK-8303796 which proposes to build statically linked JDK image. Once that work is done and integrated in the JDK build, would that catch issues like these across different components of the JDK, before such changes get merged in? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13497#issuecomment-1512486343 From duke at openjdk.org Tue Apr 18 12:59:43 2023 From: duke at openjdk.org (Afshin Zafari) Date: Tue, 18 Apr 2023 12:59:43 GMT Subject: RFR: 8305590: Remove nothrow exception specifications from operator new Message-ID: - The `throw()` (i.e., no throw) specifications are removed from the instances of `operator new` where _do not_ return `nullptr`. - The `-fcheck-new` is removed from the gcc compile flags. - The `operator new` and `operator delete` are deleted from `StackObj`. - The `GrowableArrayCHeap::operator delete` is added to be matched with its corresponding allocation`AnyObj::operator new`, because gcc complains on that after removing the `-fcheck-new` flag. - The `Thread::operator new`with and without `null` return are removed. ### Tests local: linux-x64 gtest:GrowableArrayCHeap, macosx-aarch64 hotspot:tier1 mach5: tiers 1-5 ------------- Commit messages: - 8305590: Remove nothrow exception specifications from operator new - 8305590: Remove nothrow exception specifications from operator new Changes: https://git.openjdk.org/jdk/pull/13498/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13498&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8305590 Stats: 34 lines in 7 files changed: 3 ins; 8 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/13498.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13498/head:pull/13498 PR: https://git.openjdk.org/jdk/pull/13498 From mgronlun at openjdk.org Tue Apr 18 14:30:41 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 18 Apr 2023 14:30:41 GMT Subject: RFR: 8306282: Build failure linux-arm32-open-cmp-baseline after JDK-8257967 Message-ID: Greetings, With [JDK-8257967](https://bugs.openjdk.org/browse/JDK-8257967), much refactoring was done to the JVMTI code concerning agents. However, some platforms do not have JVMTI support, and tier5 of testing builds an embedded build, linux-arm32-open-cmp-baseline, which failed because the refactoring did not properly handle conditional compilations for JVMTI. JDK-8257967 did run tier5, but it used an existing build, so it did not cause recompilations of the embedded target :-( This changeset adds the conditional constructs to let linux-arm32-open-cmp-baseline build successfully. It does not look good, but there you go... Testing: Building: linux-arm32-open-cmp-baseline Building: regular platforms Thanks Markus ------------- Commit messages: - conditional constructs for embedded Changes: https://git.openjdk.org/jdk/pull/13512/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13512&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306282 Stats: 29 lines in 3 files changed: 2 ins; 7 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/13512.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13512/head:pull/13512 PR: https://git.openjdk.org/jdk/pull/13512 From egahlin at openjdk.org Tue Apr 18 14:40:41 2023 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 18 Apr 2023 14:40:41 GMT Subject: RFR: 8306282: Build failure linux-arm32-open-cmp-baseline after JDK-8257967 In-Reply-To: References: Message-ID: On Tue, 18 Apr 2023 14:22:21 GMT, Markus Gr?nlund wrote: > Greetings, > > With [JDK-8257967](https://bugs.openjdk.org/browse/JDK-8257967), much refactoring was done to the JVMTI code concerning agents. However, some platforms do not have JVMTI support, and tier5 of testing builds an embedded build, linux-arm32-open-cmp-baseline, which failed because the refactoring did not properly handle conditional compilations for JVMTI. > > JDK-8257967 did run tier5, but it used an existing build, so it did not cause recompilations of the embedded target :-( > > This changeset adds the conditional constructs to let linux-arm32-open-cmp-baseline build successfully. > > It does not look good, but there you go... > > Testing: > > Building: linux-arm32-open-cmp-baseline > Building: regular platforms > > Thanks > Markus Marked as reviewed by egahlin (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13512#pullrequestreview-1390279307 From mgronlun at openjdk.org Tue Apr 18 15:02:15 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 18 Apr 2023 15:02:15 GMT Subject: RFR: 8306282: Build failure linux-arm32-open-cmp-baseline after JDK-8257967 [v2] In-Reply-To: References: Message-ID: > Greetings, > > With [JDK-8257967](https://bugs.openjdk.org/browse/JDK-8257967), much refactoring was done to the JVMTI code concerning agents. However, some platforms do not have JVMTI support, and tier5 of testing builds an embedded build, linux-arm32-open-cmp-baseline, which failed because the refactoring did not properly handle conditional compilations for JVMTI. > > JDK-8257967 did run tier5, but it used an existing build, so it did not cause recompilations of the embedded target :-( > > This changeset adds the conditional constructs to let linux-arm32-open-cmp-baseline build successfully. > > It does not look good, but there you go... > > Testing: > > Building: linux-arm32-open-cmp-baseline > Building: regular platforms > > Thanks > Markus Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: fix CDS format specifier to get GitHub actions working again ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13512/files - new: https://git.openjdk.org/jdk/pull/13512/files/70bc2625..80e3d33d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13512&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13512&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13512.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13512/head:pull/13512 PR: https://git.openjdk.org/jdk/pull/13512 From mgronlun at openjdk.org Tue Apr 18 15:22:02 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 18 Apr 2023 15:22:02 GMT Subject: RFR: 8306282: Build failure linux-arm32-open-cmp-baseline after JDK-8257967 [v3] In-Reply-To: References: Message-ID: <7Mtu4sDUSEqgO7yYhYPVT-aU0XmHOObSRnPOQqDcIic=.443775c9-0d30-4c6f-9815-0133f57a2e00@github.com> > Greetings, > > With [JDK-8257967](https://bugs.openjdk.org/browse/JDK-8257967), much refactoring was done to the JVMTI code concerning agents. However, some platforms do not have JVMTI support, and tier5 of testing builds an embedded build, linux-arm32-open-cmp-baseline, which failed because the refactoring did not properly handle conditional compilations for JVMTI. > > JDK-8257967 did run tier5, but it used an existing build, so it did not cause recompilations of the embedded target :-( > > This changeset adds the conditional constructs to let linux-arm32-open-cmp-baseline build successfully. > > It does not look good, but there you go... > > Testing: > > Building: linux-arm32-open-cmp-baseline > Building: regular platforms > > Thanks > Markus Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: SIZE_FORMAT ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13512/files - new: https://git.openjdk.org/jdk/pull/13512/files/80e3d33d..9b231f4e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13512&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13512&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13512.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13512/head:pull/13512 PR: https://git.openjdk.org/jdk/pull/13512 From coleenp at openjdk.org Tue Apr 18 15:22:05 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 18 Apr 2023 15:22:05 GMT Subject: RFR: 8305590: Remove nothrow exception specifications from operator new In-Reply-To: References: Message-ID: On Mon, 17 Apr 2023 17:09:44 GMT, Afshin Zafari wrote: > - The `throw()` (i.e., no throw) specifications are removed from the instances of `operator new` where _do not_ return `nullptr`. > > - The `-fcheck-new` is removed from the gcc compile flags. > > - The `operator new` and `operator delete` are deleted from `StackObj`. > > - The `GrowableArrayCHeap::operator delete` is added to be matched with its corresponding allocation`AnyObj::operator new`, because gcc complains on that after removing the `-fcheck-new` flag. > - The `Thread::operator new`with and without `null` return are removed. > > ### Tests > local: linux-x64 gtest:GrowableArrayCHeap, macosx-aarch64 hotspot:tier1 > mach5: tiers 1-5 Changes requested by coleenp (Reviewer). src/hotspot/share/memory/allocation.hpp line 289: > 287: void* operator new [](size_t size) throw() = delete; > 288: void operator delete(void* p) = delete; > 289: void operator delete [](void* p) = delete; Nice. src/hotspot/share/runtime/thread.hpp line 203: > 201: static bool is_JavaThread_protected_by_TLH(const JavaThread* target); > 202: > 203: void operator delete(void* p); Should you have removed delete and Thread::allocate() also? is Thread::allocate now unused? ------------- PR Review: https://git.openjdk.org/jdk/pull/13498#pullrequestreview-1390368704 PR Review Comment: https://git.openjdk.org/jdk/pull/13498#discussion_r1170196398 PR Review Comment: https://git.openjdk.org/jdk/pull/13498#discussion_r1170197505 From iklam at openjdk.org Tue Apr 18 15:29:08 2023 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 18 Apr 2023 15:29:08 GMT Subject: RFR: 8306282: Build failure linux-arm32-open-cmp-baseline after JDK-8257967 [v3] In-Reply-To: <7Mtu4sDUSEqgO7yYhYPVT-aU0XmHOObSRnPOQqDcIic=.443775c9-0d30-4c6f-9815-0133f57a2e00@github.com> References: <7Mtu4sDUSEqgO7yYhYPVT-aU0XmHOObSRnPOQqDcIic=.443775c9-0d30-4c6f-9815-0133f57a2e00@github.com> Message-ID: On Tue, 18 Apr 2023 15:22:02 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> With [JDK-8257967](https://bugs.openjdk.org/browse/JDK-8257967), much refactoring was done to the JVMTI code concerning agents. However, some platforms do not have JVMTI support, and tier5 of testing builds an embedded build, linux-arm32-open-cmp-baseline, which failed because the refactoring did not properly handle conditional compilations for JVMTI. >> >> JDK-8257967 did run tier5, but it used an existing build, so it did not cause recompilations of the embedded target :-( >> >> This changeset adds the conditional constructs to let linux-arm32-open-cmp-baseline build successfully. >> >> It does not look good, but there you go... >> >> Testing: >> >> Building: linux-arm32-open-cmp-baseline >> Building: regular platforms >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: > > SIZE_FORMAT LGTM ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13512#pullrequestreview-1390388100 From mgronlun at openjdk.org Tue Apr 18 16:03:57 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 18 Apr 2023 16:03:57 GMT Subject: Integrated: 8306282: Build failure linux-arm32-open-cmp-baseline after JDK-8257967 In-Reply-To: References: Message-ID: On Tue, 18 Apr 2023 14:22:21 GMT, Markus Gr?nlund wrote: > Greetings, > > With [JDK-8257967](https://bugs.openjdk.org/browse/JDK-8257967), much refactoring was done to the JVMTI code concerning agents. However, some platforms do not have JVMTI support, and tier5 of testing builds an embedded build, linux-arm32-open-cmp-baseline, which failed because the refactoring did not properly handle conditional compilations for JVMTI. > > JDK-8257967 did run tier5, but it used an existing build, so it did not cause recompilations of the embedded target :-( > > This changeset adds the conditional constructs to let linux-arm32-open-cmp-baseline build successfully. > > It does not look good, but there you go... > > Testing: > > Building: linux-arm32-open-cmp-baseline > Building: regular platforms > > Thanks > Markus This pull request has now been integrated. Changeset: 0f3828dd Author: Markus Gr?nlund URL: https://git.openjdk.org/jdk/commit/0f3828dddd8d4a08677efcd15aa8dfde18540130 Stats: 29 lines in 3 files changed: 2 ins; 7 del; 20 mod 8306282: Build failure linux-arm32-open-cmp-baseline after JDK-8257967 Reviewed-by: egahlin, iklam ------------- PR: https://git.openjdk.org/jdk/pull/13512 From mgronlun at openjdk.org Tue Apr 18 17:07:12 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 18 Apr 2023 17:07:12 GMT Subject: RFR: 8306278: jvmtiAgentList.cpp:253 assert(offset >= 0) failed: invariant occurs on AIX after JDK-8257967 Message-ID: Greetings, For most platforms, os::dll_address_to_library_name() only sets offset = -1 in case of errors. If there is an error, the function returns false. This is fine. On AIX, the offset, being optional, is invariantly set to -1, even in the case of non-errors. Easiest to remove the assertion for a positive offset. Thanks Markus ------------- Commit messages: - remove assertion on positive offset Changes: https://git.openjdk.org/jdk/pull/13513/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13513&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306278 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13513.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13513/head:pull/13513 PR: https://git.openjdk.org/jdk/pull/13513 From sspitsyn at openjdk.org Tue Apr 18 17:18:25 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 18 Apr 2023 17:18:25 GMT Subject: RFR: 8306278: jvmtiAgentList.cpp:253 assert(offset >= 0) failed: invariant occurs on AIX after JDK-8257967 In-Reply-To: References: Message-ID: On Tue, 18 Apr 2023 16:59:29 GMT, Markus Gr?nlund wrote: > Greetings, > > For most platforms, os::dll_address_to_library_name() only sets offset = -1 in case of errors. If there is an error, the function returns false. This is fine. > > On AIX, the offset, being optional, is invariantly set to -1, even in the case of non-errors. > > Easiest to remove the assertion for a positive offset. > > Thanks > Markus Looks good to me. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13513#pullrequestreview-1390594264 From coleenp at openjdk.org Tue Apr 18 17:19:18 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 18 Apr 2023 17:19:18 GMT Subject: RFR: 8306123: Move InstanceKlass writeable flags Message-ID: Please review this patch to move the writeable Klass AccessFlags to InstanceKlassFlags. Tested with tier1-4. ------------- Commit messages: - 8306123: Move InstanceKlass writeable flags Changes: https://git.openjdk.org/jdk/pull/13515/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13515&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306123 Stats: 114 lines in 6 files changed: 64 ins; 34 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/13515.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13515/head:pull/13515 PR: https://git.openjdk.org/jdk/pull/13515 From jiangli at openjdk.org Tue Apr 18 17:52:51 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 18 Apr 2023 17:52:51 GMT Subject: RFR: 8306033: Resolve multiple definition of 'throwIOException' and friends when statically linking with JDK native libraries In-Reply-To: References: Message-ID: On Mon, 17 Apr 2023 16:56:31 GMT, Jiangli Zhou wrote: > - Make functions 'static' when feasible: > - throwByName() in src/java.security.jgss/share/native/libj2gss/NativeUtil.c. > - throwByName(), throwIOException() and throwNullPointerException() in src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c. > - throwByName() in src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c. > - throwOutOfMemoryError() in src/java.smartcardio/share/native/libj2pcsc/pcsc.c. > - Move throwDisconnectedRuntimeException() to src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c since it's only used in the file. Make it static. > - Move throw_internal_error() to src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c as it's only used in the file. Make it static. > > - Rename functions by following the existing naming usages in different libraries code: > - Rename throwOutOfMemoryError() to gssThrowOutOfMemoryError() in libj2gss. > - Rename throwOutOfMemoryError() to p11ThrowOutOfMemoryError() in libj2pks11. > - Rename throwNullPointerException() to p11ThrowNullPointerException() in libj2pks11. > - Rename throwIOException() to p11ThrowIOException() in libj2pks11. > - Rename throwPKCS11RuntimeException() to p11ThrowPKCS11RuntimeException() in libj2pks11. This function only exists in libj2pks11. The rename is done so the function naming is consistent with the other throw functions. > > - Remove throw_internal_error() from src/java.management/share/native/libmanagement/management.h and src/java.management/share/native/libmanagement/management.c. It's not used. > - Remove throw_internal_error() from src/jdk.management/share/native/libmanagement_ext/management_ext.h and src/jdk.management/share/native/libmanagement_ext/management_ext.c. Hi Jaikiran, Thanks for looking into this. > is there some way these issues can be caught when code changes are being reviewed in future? Or would this require explicit run of some tool to identify these issues? The symbol issues are reported as linker errors when statically linking the executable with JDK native libraries and libjvm. I just created a branch with the preliminary makefile changes for optionally statically linking JDK, which can be used to demonstrate/identify the issues: https://github.com/jianglizhou/jdk/pull/new/JDK-8303796 The branch is based on our prototype on JDK 11, but mostly reworked. It re-uses the existing JDK make infrastructure based on the feedback from Severin Gehwolf in https://bugs.openjdk.org/browse/JDK-8303796. Still need to clean up the makefile changes before making it ready for review. Early feedback/input is also welcomed. > Once that work is done and integrated in the JDK build, would that catch issues like these across different components of the JDK, before such changes get merged in? Yes, one option would be to include the JDK static build in pre-submit testing, which can catch any changes breaking the build. That would need to be discussed broadly with other members in OpenJDK. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13497#issuecomment-1513574228 From kbarrett at openjdk.org Tue Apr 18 19:02:50 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 18 Apr 2023 19:02:50 GMT Subject: RFR: 8305590: Remove nothrow exception specifications from operator new In-Reply-To: References: Message-ID: On Mon, 17 Apr 2023 17:09:44 GMT, Afshin Zafari wrote: > - The `throw()` (i.e., no throw) specifications are removed from the instances of `operator new` where _do not_ return `nullptr`. > > - The `-fcheck-new` is removed from the gcc compile flags. > > - The `operator new` and `operator delete` are deleted from `StackObj`. > > - The `GrowableArrayCHeap::operator delete` is added to be matched with its corresponding allocation`AnyObj::operator new`, because gcc complains on that after removing the `-fcheck-new` flag. > - The `Thread::operator new`with and without `null` return are removed. > > ### Tests > local: linux-x64 gtest:GrowableArrayCHeap, macosx-aarch64 hotspot:tier1 > mach5: tiers 1-5 Changes requested by kbarrett (Reviewer). src/hotspot/share/jfr/utilities/jfrAllocation.hpp line 58: > 56: NOINLINE void* operator new(size_t size); > 57: NOINLINE void* operator new (size_t size, const std::nothrow_t& nothrow_constant) throw(); > 58: NOINLINE void* operator new [](size_t size); The changes to JfrCHeapObj are not correct, because these allocators currently _can_ return null. Their implementation is just to return the result of calling the non-throwing allocator. That's probably not an ideal implementation. Either the declaration needs to be left as-is or the implementation changed. src/hotspot/share/memory/allocation.hpp line 287: > 285: private: > 286: void* operator new(size_t size) throw() = delete; > 287: void* operator new [](size_t size) throw() = delete; The lingering nothrow exception-specs here are just clutter and can be removed. src/hotspot/share/memory/allocation.hpp line 289: > 287: void* operator new [](size_t size) throw() = delete; > 288: void operator delete(void* p) = delete; > 289: void operator delete [](void* p) = delete; Making these deleted functions public might provide better error messages if someone accidentally attempts to reference them. src/hotspot/share/memory/allocation.hpp line 504: > 502: // Arena allocations > 503: void* operator new(size_t size, Arena *arena); > 504: void* operator new [](size_t size, Arena *arena) = delete; `operator new[](size_t)` (down below, where github won't let me comment directly) should also have it's nothrow exception-spec removed. src/hotspot/share/prims/jvmtiRawMonitor.hpp line 114: > 112: > 113: // Non-aborting operator new > 114: void* operator new(size_t size) { This change is incorrect, as this can quite obviously return null. And that seems to be intentional. Presumably the callers are checking for a possible null allocation result (else there is a bug). I think it would be less confusing if this took a `std::nothrow_t` to be explicit about it's behavior, and updated the caller(s) accordingly. That would match the usual idiom. ------------- PR Review: https://git.openjdk.org/jdk/pull/13498#pullrequestreview-1390703118 PR Review Comment: https://git.openjdk.org/jdk/pull/13498#discussion_r1170425313 PR Review Comment: https://git.openjdk.org/jdk/pull/13498#discussion_r1170429604 PR Review Comment: https://git.openjdk.org/jdk/pull/13498#discussion_r1170428457 PR Review Comment: https://git.openjdk.org/jdk/pull/13498#discussion_r1170434730 PR Review Comment: https://git.openjdk.org/jdk/pull/13498#discussion_r1170438594 From kbarrett at openjdk.org Tue Apr 18 19:02:53 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 18 Apr 2023 19:02:53 GMT Subject: RFR: 8305590: Remove nothrow exception specifications from operator new In-Reply-To: References: Message-ID: <-cM0_BrloWCZxEYY8rbloXrXe1_mcQscU3ghJc1TE2I=.94b5de60-cfc8-4263-b37e-dae00e4577bc@github.com> On Tue, 18 Apr 2023 15:18:34 GMT, Coleen Phillimore wrote: >> - The `throw()` (i.e., no throw) specifications are removed from the instances of `operator new` where _do not_ return `nullptr`. >> >> - The `-fcheck-new` is removed from the gcc compile flags. >> >> - The `operator new` and `operator delete` are deleted from `StackObj`. >> >> - The `GrowableArrayCHeap::operator delete` is added to be matched with its corresponding allocation`AnyObj::operator new`, because gcc complains on that after removing the `-fcheck-new` flag. >> - The `Thread::operator new`with and without `null` return are removed. >> >> ### Tests >> local: linux-x64 gtest:GrowableArrayCHeap, macosx-aarch64 hotspot:tier1 >> mach5: tiers 1-5 > > src/hotspot/share/runtime/thread.hpp line 203: > >> 201: static bool is_JavaThread_protected_by_TLH(const JavaThread* target); >> 202: >> 203: void operator delete(void* p); > > Should you have removed delete and Thread::allocate() also? is Thread::allocate now unused? I was thinking the same thing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13498#discussion_r1170457293 From iklam at openjdk.org Tue Apr 18 20:16:06 2023 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 18 Apr 2023 20:16:06 GMT Subject: RFR: 8298048: Combine CDS archive heap into a single block [v7] In-Reply-To: References: Message-ID: > This PR combines the "open" and "closed" regions of the CDS archive heap into a single region. This significantly simplifies the implementation, making it more compatible with non-G1 collectors. There's a net removal of ~1000 lines in src code and another ~1200 lines of tests. > > **Notes for reviewers:** > - Most of the code changes in CDS are removing the handling of "open" vs "closed" objects. > - Reviewers can start with ArchiveHeapWriter::copy_source_objs_to_buffer(). > - It might be easier to see the diff with whitespaces off. > - There are two major changes in the G1 code > - The archived objects are now stored in the "old" region (see g1CollectedHeap.cpp in [58d720e](https://github.com/openjdk/jdk/pull/13284/commits/58d720e294bb36f21cb88cddde724ed2b9e93770)) > - The majority of the other changes are removal of the "archive" region type (see heapRegionType.hpp). For ease of review, such code is isolated in [a852dfb](https://github.com/openjdk/jdk/pull/13284/commits/a852dfbbf5ff56e035399f7cc3704f29e76697f6) > - Testing changes: > - Now the archived java objects can move, along with the "old" regions that contain them. It's no longer possible to test whether a heap object came from CDS. As a result, the `WhiteBox.isShared(Object o)` API has been removed. > - Many tests that uses this API are removed. Most of them were written during early development of CDS archived objects and are no longer relevant. > > **Testing:** > - Mach5 tiers 1 ~ 7 Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: - Merge branch 'master' into 8298048-combine-cds-heap-to-single-region-PUSH - Fixed assert in runtime/cds/appcds/SharedArchiveConsistency.java - Removal of JFR custom closed/open archive region types - Remove g1 full gc skip marking optimization - Some comment updates - Move g1collectedheap archive related regions together in the cpp file - Factor out region/range iteration - Fix comment - Ioi fix - fixed merge - ... and 11 more: https://git.openjdk.org/jdk/compare/0f3828dd...8a35c7ee ------------- Changes: https://git.openjdk.org/jdk/pull/13284/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13284&range=06 Stats: 3252 lines in 83 files changed: 159 ins; 2446 del; 647 mod Patch: https://git.openjdk.org/jdk/pull/13284.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13284/head:pull/13284 PR: https://git.openjdk.org/jdk/pull/13284 From dcubed at openjdk.org Tue Apr 18 20:22:43 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 18 Apr 2023 20:22:43 GMT Subject: RFR: 8306006: strace001.java fails due to unknown methods on stack In-Reply-To: <0MpbrqTjZXqfi6_St4dA5WcxAPZ8ec3P6UwLu0jFKUQ=.599f880e-b0bf-4308-bada-ca075c42ac63@github.com> References: <0MpbrqTjZXqfi6_St4dA5WcxAPZ8ec3P6UwLu0jFKUQ=.599f880e-b0bf-4308-bada-ca075c42ac63@github.com> Message-ID: On Fri, 14 Apr 2023 13:27:37 GMT, Fredrik Bredberg wrote: > Added the missing java.lang.Thread.beforeSleep and java.lang.afterSleep to expectedSystemTrace. > Tested on my local machine. We current have a total of 20 sightings of this failure in both CI and Adhoc jobs and it's happening in quite a few tests. Here's the current distribution: 2 vmTestbase/nsk/monitoring/stress/thread/strace001/TestDescription.java 3 vmTestbase/nsk/monitoring/stress/thread/strace003/TestDescription.java 8 vmTestbase/nsk/monitoring/stress/thread/strace004/TestDescription.java 2 vmTestbase/nsk/monitoring/stress/thread/strace006/TestDescription.java 2 vmTestbase/nsk/monitoring/stress/thread/strace007/TestDescription.java 2 vmTestbase/nsk/monitoring/stress/thread/strace008/TestDescription.java 1 vmTestbase/nsk/monitoring/stress/thread/strace009/TestDescription.java I would prefer not to ProblemList these 7 tests. What's the current status of this PR and what's the estimate for integration? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13476#issuecomment-1513747940 From rriggs at openjdk.org Tue Apr 18 20:34:57 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 18 Apr 2023 20:34:57 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v15] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: <0mWtWPVJ_Rb3lP1w1l5jS5C0uM8S6LbuDqoG_VoHjp4=.46e0a172-0ac8-4453-badb-fea41c4275ee@github.com> On Mon, 17 Apr 2023 20:59:06 GMT, Roger Riggs wrote: >> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. >> The enumeration values are defined to match those used in the build. >> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64` >> Note that `amd64` and `x86_64` in the build are represented by `X64`. >> The value of the system property `os.arch` is unchanged. >> >> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). >> Uses in `java.base` and a few others are included but other modules will be done in separate PRs. > > Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: > > - Merge branch 'master' into 8304915-arch-enum > - ArchTest on Debian RISC-V 64 confirmed by reviewer > - Fixed isPPC64(). > Consolidated switch cases in ArchTest. > Moved mapping of build TARGET_OS and TARGET_CPU to the build > to avoid multiple mappings in more than one place. > - Correct mapping and test of ppc64 > - Add ppc64 as mapping to PPC64 Architecture > - Modified test to check Architecture is64bits() and isLittleEndian() > against Unsafe respective values. > Relocated code mapping OS name and arch name from PlatformProps to > OperatingSystem and Architecture. Kept the mapping of names > in the template close to where the values are filled in by the build. > - Remove unused static and import of Stabile > - Rename OperatingSystemProps to PlatformProps. > Refactor OperatingSystem initialization to use strings instead of integers. > - Revised mapping mechanism of build target architecture names to enum values. > Unrecognized values from the build are mapped to enum value "OTHER". > Renamed PPC64LE to PPC64 to reflect only the architecture, not the endianness. > Added an `isLittleEndian` method to return the endianness (not currently used anywhere) > - Revert changes to jdk.accessibility AccessBridge > - ... and 7 more: https://git.openjdk.org/jdk/compare/8858d543...99a93b7e Last call for Reviewers. Tnx ------------- PR Comment: https://git.openjdk.org/jdk/pull/13357#issuecomment-1513760009 From iklam at openjdk.org Tue Apr 18 21:54:44 2023 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 18 Apr 2023 21:54:44 GMT Subject: RFR: 8306123: Move InstanceKlass writeable flags In-Reply-To: References: Message-ID: On Tue, 18 Apr 2023 17:11:25 GMT, Coleen Phillimore wrote: > Please review this patch to move the writeable Klass AccessFlags to InstanceKlassFlags. > Tested with tier1-4. LGTM. ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13515#pullrequestreview-1390984891 From erikj at openjdk.org Tue Apr 18 21:54:57 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 18 Apr 2023 21:54:57 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v15] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Mon, 17 Apr 2023 20:59:06 GMT, Roger Riggs wrote: >> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. >> The enumeration values are defined to match those used in the build. >> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64` >> Note that `amd64` and `x86_64` in the build are represented by `X64`. >> The value of the system property `os.arch` is unchanged. >> >> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). >> Uses in `java.base` and a few others are included but other modules will be done in separate PRs. > > Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: > > - Merge branch 'master' into 8304915-arch-enum > - ArchTest on Debian RISC-V 64 confirmed by reviewer > - Fixed isPPC64(). > Consolidated switch cases in ArchTest. > Moved mapping of build TARGET_OS and TARGET_CPU to the build > to avoid multiple mappings in more than one place. > - Correct mapping and test of ppc64 > - Add ppc64 as mapping to PPC64 Architecture > - Modified test to check Architecture is64bits() and isLittleEndian() > against Unsafe respective values. > Relocated code mapping OS name and arch name from PlatformProps to > OperatingSystem and Architecture. Kept the mapping of names > in the template close to where the values are filled in by the build. > - Remove unused static and import of Stabile > - Rename OperatingSystemProps to PlatformProps. > Refactor OperatingSystem initialization to use strings instead of integers. > - Revised mapping mechanism of build target architecture names to enum values. > Unrecognized values from the build are mapped to enum value "OTHER". > Renamed PPC64LE to PPC64 to reflect only the architecture, not the endianness. > Added an `isLittleEndian` method to return the endianness (not currently used anywhere) > - Revert changes to jdk.accessibility AccessBridge > - ... and 7 more: https://git.openjdk.org/jdk/compare/8858d543...99a93b7e Build changes look good. ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13357#pullrequestreview-1390984858 From ron.pressler at oracle.com Tue Apr 18 22:29:47 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Tue, 18 Apr 2023 22:29:47 +0000 Subject: JEP draft: Disallow the Dynamic Loading of Agents by Default Message-ID: <168352AB-C660-484F-BAA6-31A2B6F0D0C8@oracle.com> Hi. Following last month?s email about changing the default of EnableDynamicAgentLoading [1], we?ve now published two JEP drafts. The first is an informational JEP describing what integrity is and why we need it, and motivates what changes are required to get it (which include the restriction of dynamically loaded agents among others): https://openjdk.org/jeps/8305968 Integrity and Strong Encapsulation The second touches on the specifics of dynamically loaded agents and the proposed change: https://openjdk.org/jeps/8306275 Disallow the Dynamic Loading of Agents by Default [1]: https://mail.openjdk.org/pipermail/jigsaw-dev/2023-March/014816.html ? Ron From liach at openjdk.org Wed Apr 19 01:11:00 2023 From: liach at openjdk.org (Chen Liang) Date: Wed, 19 Apr 2023 01:11:00 GMT Subject: RFR: 8294977: Convert test/jdk/java tests from ASM library to Classfile API [v7] In-Reply-To: <3PN6riy9fxQHRz1646Xi5fo-V7pTeF_r4Ojgt3yMRtg=.eb0d3145-3d0c-4c3e-b158-d836f7460110@github.com> References: <3PN6riy9fxQHRz1646Xi5fo-V7pTeF_r4Ojgt3yMRtg=.eb0d3145-3d0c-4c3e-b158-d836f7460110@github.com> Message-ID: On Tue, 21 Mar 2023 21:39:48 GMT, Chen Liang wrote: >> Summaries: >> 1. A few recommendations about updating the constant API is made at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000233.html and I may update this patch shall the API changes be integrated before >> 2. One ASM library-specific test, `LambdaAsm` is removed. Others have their code generation infrastructure upgraded from ASM to Classfile API. >> 3. Most tests are included in tier1, but some are not: >> In `:jdk_io`: (tier2, part 2) >> >> test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java >> test/jdk/java/io/Serializable/records/ProhibitedMethods.java >> test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java >> >> In `:jdk_instrument`: (tier 3) >> >> test/jdk/java/lang/instrument/RetransformAgent.java >> test/jdk/java/lang/instrument/NativeMethodPrefixAgent.java >> test/jdk/java/lang/instrument/asmlib/Instrumentor.java >> >> >> @asotona Would you mind reviewing? > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Switch to ConstantDescs for and void constants > - Merge AnnotationsTest, remove ModuleTargetAttribute call > - Merge branch 'invoke-test-classfile' of https://github.com/liachmodded/jdk into invoke-test-classfile > - Update test/jdk/java/lang/invoke/8022701/MHIllegalAccess.java > > Co-authored-by: Andrey Turbanov > - Merge branch 'master' into invoke-test-classfile > - Fix LambdaStackTrace after running > - formatting > - Fix failed LambdaStackTrace test, use more convenient APIs > - Merge branch 'master' of https://git.openjdk.java.net/jdk into invoke-test-classfile > - Shorten lines, move from mask() to ACC_ constants, other misc improvements > - ... and 1 more: https://git.openjdk.org/jdk/compare/0deb6489...7dc785b3 keep alive. this might not be integrated until classfile api has been previewed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13009#issuecomment-1513989606 From dholmes at openjdk.org Wed Apr 19 02:20:45 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 19 Apr 2023 02:20:45 GMT Subject: RFR: 8306278: jvmtiAgentList.cpp:253 assert(offset >= 0) failed: invariant occurs on AIX after JDK-8257967 In-Reply-To: References: Message-ID: On Tue, 18 Apr 2023 16:59:29 GMT, Markus Gr?nlund wrote: > Greetings, > > For most platforms, os::dll_address_to_library_name() only sets offset = -1 in case of errors. If there is an error, the function returns false. This is fine. > > On AIX, the offset, being optional, is invariantly set to -1, even in the case of non-errors. > > Easiest to remove the assertion for a positive offset. > > Thanks > Markus Removing the assertion seems the best course of action. It is interesting to note that the two call sites for these functions that pass `offset` do not correctly handle a return of -1 (it is only printed as an informational value but it isnb't printed in a suitable form). Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13513#pullrequestreview-1391171295 From dholmes at openjdk.org Wed Apr 19 02:25:54 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 19 Apr 2023 02:25:54 GMT Subject: RFR: 8306282: Build failure linux-arm32-open-cmp-baseline after JDK-8257967 [v3] In-Reply-To: <7Mtu4sDUSEqgO7yYhYPVT-aU0XmHOObSRnPOQqDcIic=.443775c9-0d30-4c6f-9815-0133f57a2e00@github.com> References: <7Mtu4sDUSEqgO7yYhYPVT-aU0XmHOObSRnPOQqDcIic=.443775c9-0d30-4c6f-9815-0133f57a2e00@github.com> Message-ID: <8bWAmer1c40K83zNOqk4t96rJ8xPG-lVyjBXpeGTp2M=.a4fead0c-23c2-4575-b5f7-5782c874fa5d@github.com> On Tue, 18 Apr 2023 15:22:02 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> With [JDK-8257967](https://bugs.openjdk.org/browse/JDK-8257967), much refactoring was done to the JVMTI code concerning agents. However, some platforms do not have JVMTI support, and tier5 of testing builds an embedded build, linux-arm32-open-cmp-baseline, which failed because the refactoring did not properly handle conditional compilations for JVMTI. >> >> JDK-8257967 did run tier5, but it used an existing build, so it did not cause recompilations of the embedded target :-( >> >> This changeset adds the conditional constructs to let linux-arm32-open-cmp-baseline build successfully. >> >> It does not look good, but there you go... >> >> Testing: >> >> Building: linux-arm32-open-cmp-baseline >> Building: regular platforms >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: > > SIZE_FORMAT @mgronlun I agree this does not look good. I'm not sure this was the right way to conditionalize the new code, rather than ensuring the callsites were conditionalized on INCLUDE_JVMTI. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13512#issuecomment-1514041621 From mbaesken at openjdk.org Wed Apr 19 07:12:41 2023 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 19 Apr 2023 07:12:41 GMT Subject: RFR: 8306278: jvmtiAgentList.cpp:253 assert(offset >= 0) failed: invariant occurs on AIX after JDK-8257967 In-Reply-To: References: Message-ID: On Tue, 18 Apr 2023 16:59:29 GMT, Markus Gr?nlund wrote: > Greetings, > > For most platforms, os::dll_address_to_library_name() only sets offset = -1 in case of errors. If there is an error, the function returns false. This is fine. > > On AIX, the offset, being optional, is invariantly set to -1, even in the case of non-errors. > > Easiest to remove the assertion for a positive offset. > > Thanks > Markus Thanks, looks good to me. One of my colleague has an idea to improve os::dll_address_to_library_name on AIX to support the offsets but this is something for the future so still good to have your fix. ------------- Marked as reviewed by mbaesken (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13513#pullrequestreview-1391391403 From duke at openjdk.org Wed Apr 19 07:38:44 2023 From: duke at openjdk.org (Fredrik Bredberg) Date: Wed, 19 Apr 2023 07:38:44 GMT Subject: RFR: 8306006: strace001.java fails due to unknown methods on stack In-Reply-To: References: <0MpbrqTjZXqfi6_St4dA5WcxAPZ8ec3P6UwLu0jFKUQ=.599f880e-b0bf-4308-bada-ca075c42ac63@github.com> Message-ID: On Tue, 18 Apr 2023 20:20:09 GMT, Daniel D. Daugherty wrote: >> Added the missing java.lang.Thread.beforeSleep and java.lang.afterSleep to expectedSystemTrace. >> Tested on my local machine. > > We currently have a total of 20 sightings of this failure in both CI and Adhoc > jobs and it's happening in quite a few tests. Here's the current distribution: > > 2 vmTestbase/nsk/monitoring/stress/thread/strace001/TestDescription.java > 3 vmTestbase/nsk/monitoring/stress/thread/strace003/TestDescription.java > 8 vmTestbase/nsk/monitoring/stress/thread/strace004/TestDescription.java > 2 vmTestbase/nsk/monitoring/stress/thread/strace006/TestDescription.java > 2 vmTestbase/nsk/monitoring/stress/thread/strace007/TestDescription.java > 2 vmTestbase/nsk/monitoring/stress/thread/strace008/TestDescription.java > 1 vmTestbase/nsk/monitoring/stress/thread/strace009/TestDescription.java > > I would prefer not to ProblemList these 7 tests. What's the current status of > this PR and what's the estimate for integration? Hi @dcubed-ojdk, Don't ProblemList the 7 tests. I'm currently updating the tests after the review. Running the tests looks good (no issues). Will integrate as soon as all reviewers are happy. Hoping for today or tomorrow. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13476#issuecomment-1514270168 From duke at openjdk.org Wed Apr 19 10:25:49 2023 From: duke at openjdk.org (Afshin Zafari) Date: Wed, 19 Apr 2023 10:25:49 GMT Subject: RFR: 8305590: Remove nothrow exception specifications from operator new [v2] In-Reply-To: References: Message-ID: <619AH3LBFaBdG1odgp4kpuCjm6ujfOivOUtoDYHdhCw=.96e5693b-e8c1-4923-88e4-11715889b822@github.com> > - The `throw()` (i.e., no throw) specifications are removed from the instances of `operator new` where _do not_ return `nullptr`. > > - The `-fcheck-new` is removed from the gcc compile flags. > > - The `operator new` and `operator delete` are deleted from `StackObj`. > > - The `GrowableArrayCHeap::operator delete` is added to be matched with its corresponding allocation`AnyObj::operator new`, because gcc complains on that after removing the `-fcheck-new` flag. > - The `Thread::operator new`with and without `null` return are removed. > > ### Tests > local: linux-x64 gtest:GrowableArrayCHeap, macosx-aarch64 hotspot:tier1 > mach5: tiers 1-5 Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: 8305590: Remove nothrow exception specifications from operator new ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13498/files - new: https://git.openjdk.org/jdk/pull/13498/files/45a4e5de..d2d75e7f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13498&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13498&range=00-01 Stats: 24 lines in 6 files changed: 0 ins; 14 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/13498.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13498/head:pull/13498 PR: https://git.openjdk.org/jdk/pull/13498 From duke at openjdk.org Wed Apr 19 10:25:53 2023 From: duke at openjdk.org (Afshin Zafari) Date: Wed, 19 Apr 2023 10:25:53 GMT Subject: RFR: 8305590: Remove nothrow exception specifications from operator new [v2] In-Reply-To: References: Message-ID: On Tue, 18 Apr 2023 18:29:13 GMT, Kim Barrett wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> 8305590: Remove nothrow exception specifications from operator new > > src/hotspot/share/memory/allocation.hpp line 289: > >> 287: void* operator new [](size_t size) throw() = delete; >> 288: void operator delete(void* p) = delete; >> 289: void operator delete [](void* p) = delete; > > Making these deleted functions public might provide better error messages if someone accidentally attempts to reference them. Done. > src/hotspot/share/memory/allocation.hpp line 504: > >> 502: // Arena allocations >> 503: void* operator new(size_t size, Arena *arena); >> 504: void* operator new [](size_t size, Arena *arena) = delete; > > `operator new[](size_t)` (down below, where github won't let me comment directly) should also have it's nothrow exception-spec removed. Done. > src/hotspot/share/prims/jvmtiRawMonitor.hpp line 114: > >> 112: >> 113: // Non-aborting operator new >> 114: void* operator new(size_t size) { > > This change is incorrect, as this can quite obviously return null. And that seems to be intentional. > Presumably the callers are checking for a possible null allocation result (else there is a bug). I think > it would be less confusing if this took a `std::nothrow_t` to be explicit about it's behavior, and updated > the caller(s) accordingly. That would match the usual idiom. no throw argument is added to the declaration and the caller is changed accordingly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13498#discussion_r1171133732 PR Review Comment: https://git.openjdk.org/jdk/pull/13498#discussion_r1171134794 PR Review Comment: https://git.openjdk.org/jdk/pull/13498#discussion_r1171136374 From duke at openjdk.org Wed Apr 19 10:25:56 2023 From: duke at openjdk.org (Afshin Zafari) Date: Wed, 19 Apr 2023 10:25:56 GMT Subject: RFR: 8305590: Remove nothrow exception specifications from operator new [v2] In-Reply-To: <-cM0_BrloWCZxEYY8rbloXrXe1_mcQscU3ghJc1TE2I=.94b5de60-cfc8-4263-b37e-dae00e4577bc@github.com> References: <-cM0_BrloWCZxEYY8rbloXrXe1_mcQscU3ghJc1TE2I=.94b5de60-cfc8-4263-b37e-dae00e4577bc@github.com> Message-ID: On Tue, 18 Apr 2023 18:59:31 GMT, Kim Barrett wrote: >> src/hotspot/share/runtime/thread.hpp line 203: >> >>> 201: static bool is_JavaThread_protected_by_TLH(const JavaThread* target); >>> 202: >>> 203: void operator delete(void* p); >> >> Should you have removed delete and Thread::allocate() also? is Thread::allocate now unused? > > I was thinking the same thing. Removed and tested. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13498#discussion_r1171133528 From duke at openjdk.org Wed Apr 19 10:47:50 2023 From: duke at openjdk.org (Alexey Pavlyutkin) Date: Wed, 19 Apr 2023 10:47:50 GMT Subject: RFR: 8306437: jhsdb cannot resolve image/symbol paths being used for analysis of Windows coredumps Message-ID: <62oUnZxCgEiiGjk1I9qb_1M_Zl0Sx4UvFeCk2S7mY00=.15eb4fda-eb88-4f9c-9d73-6fba9da60692@github.com> Hi! The patch fixes image/symbol lookup by jhsdb on alanysis Windows coredump. It uses executableName as a hint prepending image path with `;\server` and symbol path with `srv*https://msdl.microsoft.com/download/symbols;;\server` where the first bit points to Windows symbols located on remote server ------------- Commit messages: - 8306437: use executable name as a hint for image/symbol lookup Changes: https://git.openjdk.org/jdk/pull/13530/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13530&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306437 Stats: 48 lines in 1 file changed: 39 ins; 9 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13530.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13530/head:pull/13530 PR: https://git.openjdk.org/jdk/pull/13530 From tschatzl at openjdk.org Wed Apr 19 10:47:51 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 19 Apr 2023 10:47:51 GMT Subject: RFR: 8298048: Combine CDS archive heap into a single block [v7] In-Reply-To: References: Message-ID: On Tue, 18 Apr 2023 20:16:06 GMT, Ioi Lam wrote: >> This PR combines the "open" and "closed" regions of the CDS archive heap into a single region. This significantly simplifies the implementation, making it more compatible with non-G1 collectors. There's a net removal of ~1000 lines in src code and another ~1200 lines of tests. >> >> **Notes for reviewers:** >> - Most of the code changes in CDS are removing the handling of "open" vs "closed" objects. >> - Reviewers can start with ArchiveHeapWriter::copy_source_objs_to_buffer(). >> - It might be easier to see the diff with whitespaces off. >> - There are two major changes in the G1 code >> - The archived objects are now stored in the "old" region (see g1CollectedHeap.cpp in [58d720e](https://github.com/openjdk/jdk/pull/13284/commits/58d720e294bb36f21cb88cddde724ed2b9e93770)) >> - The majority of the other changes are removal of the "archive" region type (see heapRegionType.hpp). For ease of review, such code is isolated in [a852dfb](https://github.com/openjdk/jdk/pull/13284/commits/a852dfbbf5ff56e035399f7cc3704f29e76697f6) >> - Testing changes: >> - Now the archived java objects can move, along with the "old" regions that contain them. It's no longer possible to test whether a heap object came from CDS. As a result, the `WhiteBox.isShared(Object o)` API has been removed. >> - Many tests that uses this API are removed. Most of them were written during early development of CDS archived objects and are no longer relevant. >> >> **Testing:** >> - Mach5 tiers 1 ~ 7 > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: > > - Merge branch 'master' into 8298048-combine-cds-heap-to-single-region-PUSH > - Fixed assert in runtime/cds/appcds/SharedArchiveConsistency.java > - Removal of JFR custom closed/open archive region types > - Remove g1 full gc skip marking optimization > - Some comment updates > - Move g1collectedheap archive related regions together in the cpp file > - Factor out region/range iteration > - Fix comment > - Ioi fix > - fixed merge > - ... and 11 more: https://git.openjdk.org/jdk/compare/0f3828dd...8a35c7ee GC changes seem good. Only cursorily looked at runtime/CDS changes. ------------- Marked as reviewed by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13284#pullrequestreview-1391786221 From mgronlun at openjdk.org Wed Apr 19 10:59:44 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 19 Apr 2023 10:59:44 GMT Subject: RFR: 8306278: jvmtiAgentList.cpp:253 assert(offset >= 0) failed: invariant occurs on AIX after JDK-8257967 In-Reply-To: References: Message-ID: On Tue, 18 Apr 2023 17:15:46 GMT, Serguei Spitsyn wrote: >> Greetings, >> >> For most platforms, os::dll_address_to_library_name() only sets offset = -1 in case of errors. If there is an error, the function returns false. This is fine. >> >> On AIX, the offset, being optional, is invariantly set to -1, even in the case of non-errors. >> >> Easiest to remove the assertion for a positive offset. >> >> Thanks >> Markus > > Looks good to me. > Thanks, > Serguei Thank you @sspitsyn, @dholmes-ora and @MBaesken for your reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13513#issuecomment-1514533473 From mgronlun at openjdk.org Wed Apr 19 11:02:54 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 19 Apr 2023 11:02:54 GMT Subject: Integrated: 8306278: jvmtiAgentList.cpp:253 assert(offset >= 0) failed: invariant occurs on AIX after JDK-8257967 In-Reply-To: References: Message-ID: On Tue, 18 Apr 2023 16:59:29 GMT, Markus Gr?nlund wrote: > Greetings, > > For most platforms, os::dll_address_to_library_name() only sets offset = -1 in case of errors. If there is an error, the function returns false. This is fine. > > On AIX, the offset, being optional, is invariantly set to -1, even in the case of non-errors. > > Easiest to remove the assertion for a positive offset. > > Thanks > Markus This pull request has now been integrated. Changeset: c738c8ea Author: Markus Gr?nlund URL: https://git.openjdk.org/jdk/commit/c738c8ea3e9fda87abb03acb599a2433a344db09 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8306278: jvmtiAgentList.cpp:253 assert(offset >= 0) failed: invariant occurs on AIX after JDK-8257967 Reviewed-by: sspitsyn, dholmes, mbaesken ------------- PR: https://git.openjdk.org/jdk/pull/13513 From jpai at openjdk.org Wed Apr 19 11:03:42 2023 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 19 Apr 2023 11:03:42 GMT Subject: RFR: 8306033: Resolve multiple definition of 'throwIOException' and friends when statically linking with JDK native libraries In-Reply-To: References: Message-ID: On Mon, 17 Apr 2023 16:56:31 GMT, Jiangli Zhou wrote: > - Make functions 'static' when feasible: > - throwByName() in src/java.security.jgss/share/native/libj2gss/NativeUtil.c. > - throwByName(), throwIOException() and throwNullPointerException() in src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c. > - throwByName() in src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c. > - throwOutOfMemoryError() in src/java.smartcardio/share/native/libj2pcsc/pcsc.c. > - Move throwDisconnectedRuntimeException() to src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c since it's only used in the file. Make it static. > - Move throw_internal_error() to src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c as it's only used in the file. Make it static. > > - Rename functions by following the existing naming usages in different libraries code: > - Rename throwOutOfMemoryError() to gssThrowOutOfMemoryError() in libj2gss. > - Rename throwOutOfMemoryError() to p11ThrowOutOfMemoryError() in libj2pks11. > - Rename throwNullPointerException() to p11ThrowNullPointerException() in libj2pks11. > - Rename throwIOException() to p11ThrowIOException() in libj2pks11. > - Rename throwPKCS11RuntimeException() to p11ThrowPKCS11RuntimeException() in libj2pks11. This function only exists in libj2pks11. The rename is done so the function naming is consistent with the other throw functions. > > - Remove throw_internal_error() from src/java.management/share/native/libmanagement/management.h and src/java.management/share/native/libmanagement/management.c. It's not used. > - Remove throw_internal_error() from src/jdk.management/share/native/libmanagement_ext/management_ext.h and src/jdk.management/share/native/libmanagement_ext/management_ext.c. Thank you for those details, Jiangli. > > > > Once that work is done and integrated in the JDK build, would that catch issues like these across different components of the JDK, before such changes get merged in? > > Yes, one option would be to include the JDK static build in pre-submit testing, which can catch any changes breaking the build. That would need to be discussed broadly with other members in OpenJDK. Even if it doesn't get enrolled in the pre-submit testing, I think the fact that there will be a build within the JDK which can catch these issues is a good thing. It might catch the issue(s) after the integration, but I think it's still a good improvement to have these issues identified by running a specific variant of the JDK build process. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13497#issuecomment-1514538152 From mgronlun at openjdk.org Wed Apr 19 11:11:56 2023 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 19 Apr 2023 11:11:56 GMT Subject: RFR: 8306282: Build failure linux-arm32-open-cmp-baseline after JDK-8257967 [v3] In-Reply-To: <8bWAmer1c40K83zNOqk4t96rJ8xPG-lVyjBXpeGTp2M=.a4fead0c-23c2-4575-b5f7-5782c874fa5d@github.com> References: <7Mtu4sDUSEqgO7yYhYPVT-aU0XmHOObSRnPOQqDcIic=.443775c9-0d30-4c6f-9815-0133f57a2e00@github.com> <8bWAmer1c40K83zNOqk4t96rJ8xPG-lVyjBXpeGTp2M=.a4fead0c-23c2-4575-b5f7-5782c874fa5d@github.com> Message-ID: On Wed, 19 Apr 2023 02:22:38 GMT, David Holmes wrote: > @mgronlun I agree this does not look good. I'm not sure this was the right way to conditionalize the new code, rather than ensuring the callsites were conditionalized on INCLUDE_JVMTI. It follows the same pattern as for other jvmti*.cpp files also excluded via make/hotspot/lib/jvmFeatures.gmk. For example, jvmtiExport.cpp. Might be better to improve with conditionalized callsites, agree. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13512#issuecomment-1514547771 From kbarrett at openjdk.org Wed Apr 19 11:13:49 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 19 Apr 2023 11:13:49 GMT Subject: RFR: 8305590: Remove nothrow exception specifications from operator new [v2] In-Reply-To: <619AH3LBFaBdG1odgp4kpuCjm6ujfOivOUtoDYHdhCw=.96e5693b-e8c1-4923-88e4-11715889b822@github.com> References: <619AH3LBFaBdG1odgp4kpuCjm6ujfOivOUtoDYHdhCw=.96e5693b-e8c1-4923-88e4-11715889b822@github.com> Message-ID: On Wed, 19 Apr 2023 10:25:49 GMT, Afshin Zafari wrote: >> - The `throw()` (i.e., no throw) specifications are removed from the instances of `operator new` where _do not_ return `nullptr`. >> >> - The `-fcheck-new` is removed from the gcc compile flags. >> >> - The `operator new` and `operator delete` are deleted from `StackObj`. >> >> - The `GrowableArrayCHeap::operator delete` is added to be matched with its corresponding allocation`AnyObj::operator new`, because gcc complains on that after removing the `-fcheck-new` flag. >> - The `Thread::operator new`with and without `null` return are removed. >> >> ### Tests >> local: linux-x64 gtest:GrowableArrayCHeap, macosx-aarch64 hotspot:tier1 >> mach5: tiers 1-5 > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 8305590: Remove nothrow exception specifications from operator new src/hotspot/share/prims/jvmtiRawMonitor.hpp line 114: > 112: > 113: // Non-aborting operator new > 114: void* operator new(size_t size, const std::nothrow_t& nothrow_constant) throw() { Hm, now I'm wondering why isn't an `operator delete` to go with this? Or are these objects never deleted? Otherwise I'd have thought we'd get the same mismatched new/delete warning you encountered elsewhere. If they're never supposed to be deleted, then giving `operator delete` a deleted definition here seems appropriate, to prevent accidentally calling the CHeapObj function. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13498#discussion_r1171175550 From duke at openjdk.org Wed Apr 19 11:30:42 2023 From: duke at openjdk.org (Fredrik Bredberg) Date: Wed, 19 Apr 2023 11:30:42 GMT Subject: RFR: 8306006: strace001.java fails due to unknown methods on stack [v2] In-Reply-To: <0MpbrqTjZXqfi6_St4dA5WcxAPZ8ec3P6UwLu0jFKUQ=.599f880e-b0bf-4308-bada-ca075c42ac63@github.com> References: <0MpbrqTjZXqfi6_St4dA5WcxAPZ8ec3P6UwLu0jFKUQ=.599f880e-b0bf-4308-bada-ca075c42ac63@github.com> Message-ID: > Added the missing java.lang.Thread.beforeSleep and java.lang.afterSleep to expectedSystemTrace. > Tested on my local machine. Fredrik Bredberg has updated the pull request incrementally with two additional commits since the last revision: - Updated after review - Added java.util.concurrent.TimeUnit.toNanos to expectedSystemTrace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13476/files - new: https://git.openjdk.org/jdk/pull/13476/files/6d7f9163..3739314e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13476&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13476&range=00-01 Stats: 56 lines in 10 files changed: 6 ins; 12 del; 38 mod Patch: https://git.openjdk.org/jdk/pull/13476.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13476/head:pull/13476 PR: https://git.openjdk.org/jdk/pull/13476 From dholmes at openjdk.org Wed Apr 19 11:57:45 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 19 Apr 2023 11:57:45 GMT Subject: RFR: 8305590: Remove nothrow exception specifications from operator new [v2] In-Reply-To: <619AH3LBFaBdG1odgp4kpuCjm6ujfOivOUtoDYHdhCw=.96e5693b-e8c1-4923-88e4-11715889b822@github.com> References: <619AH3LBFaBdG1odgp4kpuCjm6ujfOivOUtoDYHdhCw=.96e5693b-e8c1-4923-88e4-11715889b822@github.com> Message-ID: On Wed, 19 Apr 2023 10:25:49 GMT, Afshin Zafari wrote: >> - The `throw()` (i.e., no throw) specifications are removed from the instances of `operator new` where _do not_ return `nullptr`. >> >> - The `-fcheck-new` is removed from the gcc compile flags. >> >> - The `operator new` and `operator delete` are deleted from `StackObj`. >> >> - The `GrowableArrayCHeap::operator delete` is added to be matched with its corresponding allocation`AnyObj::operator new`, because gcc complains on that after removing the `-fcheck-new` flag. >> - The `Thread::operator new`with and without `null` return are removed. >> >> ### Tests >> local: linux-x64 gtest:GrowableArrayCHeap, macosx-aarch64 hotspot:tier1 >> mach5: tiers 1-5 > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 8305590: Remove nothrow exception specifications from operator new src/hotspot/share/jfr/utilities/jfrAllocation.hpp line 2: > 1: /* > 2: * Copyright (c) 2014, 2023, Oracle and/or its affiliates. All rights reserved. This appears to be the only change to this file so should be reverted. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13498#discussion_r1171223970 From alanb at openjdk.org Wed Apr 19 12:31:51 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 19 Apr 2023 12:31:51 GMT Subject: RFR: 8306006: strace001.java fails due to unknown methods on stack [v2] In-Reply-To: References: <0MpbrqTjZXqfi6_St4dA5WcxAPZ8ec3P6UwLu0jFKUQ=.599f880e-b0bf-4308-bada-ca075c42ac63@github.com> Message-ID: On Wed, 19 Apr 2023 11:30:42 GMT, Fredrik Bredberg wrote: >> Added the missing java.lang.Thread.beforeSleep and java.lang.afterSleep to expectedSystemTrace. >> Tested on my local machine. > > Fredrik Bredberg has updated the pull request incrementally with two additional commits since the last revision: > > - Updated after review > - Added java.util.concurrent.TimeUnit.toNanos to expectedSystemTrace Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13476#pullrequestreview-1391949725 From dholmes at openjdk.org Wed Apr 19 12:42:49 2023 From: dholmes at openjdk.org (David Holmes) Date: Wed, 19 Apr 2023 12:42:49 GMT Subject: RFR: 8306006: strace001.java fails due to unknown methods on stack [v2] In-Reply-To: References: <0MpbrqTjZXqfi6_St4dA5WcxAPZ8ec3P6UwLu0jFKUQ=.599f880e-b0bf-4308-bada-ca075c42ac63@github.com> Message-ID: On Wed, 19 Apr 2023 11:30:42 GMT, Fredrik Bredberg wrote: >> Added the missing java.lang.Thread.beforeSleep and java.lang.afterSleep to expectedSystemTrace. >> Tested on my local machine. > > Fredrik Bredberg has updated the pull request incrementally with two additional commits since the last revision: > > - Updated after review > - Added java.util.concurrent.TimeUnit.toNanos to expectedSystemTrace Final version looks good - thanks! A follow up would be to check what each of these test variants are supposed to do, because AFAICS the `-testMode` argument is never used. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13476#pullrequestreview-1391970240 From duke at openjdk.org Wed Apr 19 13:05:59 2023 From: duke at openjdk.org (Glavo) Date: Wed, 19 Apr 2023 13:05:59 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v15] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: <1P4W0dAhJfkFtBtGoeQ0ZQ30sKh1mDJCj6NdEZnrolI=.f8cb190a-ad8a-4ddc-8e06-02dc055371a4@github.com> On Mon, 17 Apr 2023 20:59:06 GMT, Roger Riggs wrote: >> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. >> The enumeration values are defined to match those used in the build. >> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64` >> Note that `amd64` and `x86_64` in the build are represented by `X64`. >> The value of the system property `os.arch` is unchanged. >> >> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). >> Uses in `java.base` and a few others are included but other modules will be done in separate PRs. > > Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: > > - Merge branch 'master' into 8304915-arch-enum > - ArchTest on Debian RISC-V 64 confirmed by reviewer > - Fixed isPPC64(). > Consolidated switch cases in ArchTest. > Moved mapping of build TARGET_OS and TARGET_CPU to the build > to avoid multiple mappings in more than one place. > - Correct mapping and test of ppc64 > - Add ppc64 as mapping to PPC64 Architecture > - Modified test to check Architecture is64bits() and isLittleEndian() > against Unsafe respective values. > Relocated code mapping OS name and arch name from PlatformProps to > OperatingSystem and Architecture. Kept the mapping of names > in the template close to where the values are filled in by the build. > - Remove unused static and import of Stabile > - Rename OperatingSystemProps to PlatformProps. > Refactor OperatingSystem initialization to use strings instead of integers. > - Revised mapping mechanism of build target architecture names to enum values. > Unrecognized values from the build are mapped to enum value "OTHER". > Renamed PPC64LE to PPC64 to reflect only the architecture, not the endianness. > Added an `isLittleEndian` method to return the endianness (not currently used anywhere) > - Revert changes to jdk.accessibility AccessBridge > - ... and 7 more: https://git.openjdk.org/jdk/compare/8858d543...99a93b7e Looks good, tests still pass on Debian RISC-V 64. ------------- Marked as reviewed by Glavo at github.com (no known OpenJDK username). PR Review: https://git.openjdk.org/jdk/pull/13357#pullrequestreview-1392016242 From fparain at openjdk.org Wed Apr 19 13:09:44 2023 From: fparain at openjdk.org (Frederic Parain) Date: Wed, 19 Apr 2023 13:09:44 GMT Subject: RFR: 8306123: Move InstanceKlass writeable flags In-Reply-To: References: Message-ID: <0eCwdxDqCvbPfBVrzu-CXBQY-Ob8k5y_TOqSH2pA34w=.9b423d4f-7766-4610-b96f-3842a91915b1@github.com> On Tue, 18 Apr 2023 17:11:25 GMT, Coleen Phillimore wrote: > Please review this patch to move the writeable Klass AccessFlags to InstanceKlassFlags. > Tested with tier1-4. Nice clean up. Looks good to me. ------------- Marked as reviewed by fparain (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13515#pullrequestreview-1392028279 From mdoerr at openjdk.org Wed Apr 19 13:26:02 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 19 Apr 2023 13:26:02 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v15] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Mon, 17 Apr 2023 20:59:06 GMT, Roger Riggs wrote: >> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. >> The enumeration values are defined to match those used in the build. >> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64` >> Note that `amd64` and `x86_64` in the build are represented by `X64`. >> The value of the system property `os.arch` is unchanged. >> >> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). >> Uses in `java.base` and a few others are included but other modules will be done in separate PRs. > > Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: > > - Merge branch 'master' into 8304915-arch-enum > - ArchTest on Debian RISC-V 64 confirmed by reviewer > - Fixed isPPC64(). > Consolidated switch cases in ArchTest. > Moved mapping of build TARGET_OS and TARGET_CPU to the build > to avoid multiple mappings in more than one place. > - Correct mapping and test of ppc64 > - Add ppc64 as mapping to PPC64 Architecture > - Modified test to check Architecture is64bits() and isLittleEndian() > against Unsafe respective values. > Relocated code mapping OS name and arch name from PlatformProps to > OperatingSystem and Architecture. Kept the mapping of names > in the template close to where the values are filled in by the build. > - Remove unused static and import of Stabile > - Rename OperatingSystemProps to PlatformProps. > Refactor OperatingSystem initialization to use strings instead of integers. > - Revised mapping mechanism of build target architecture names to enum values. > Unrecognized values from the build are mapped to enum value "OTHER". > Renamed PPC64LE to PPC64 to reflect only the architecture, not the endianness. > Added an `isLittleEndian` method to return the endianness (not currently used anywhere) > - Revert changes to jdk.accessibility AccessBridge > - ... and 7 more: https://git.openjdk.org/jdk/compare/8858d543...99a93b7e test/jdk/jdk/internal/util/ArchTest.java line 71: > 69: case "aarch64" -> AARCH64; > 70: case "riscv64" -> RISCV64; > 71: case "s390x", "s390" -> S390; // unverified This was also verified according to comments. Right, @offamitkumar? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1171335657 From lmesnik at openjdk.org Wed Apr 19 13:29:56 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 19 Apr 2023 13:29:56 GMT Subject: RFR: 8305937: com/sun/jdi/SetLocalWhileThreadInNative.java fails with -XX:+TieredCompilation In-Reply-To: References: Message-ID: On Thu, 13 Apr 2023 14:49:58 GMT, Leonid Mesnik wrote: > Could you please review following trivial fix which correct jvm options order in TestScaffold. > TestScaffold combines test optionos and jtreg vm options. Before [JDK-8304834](https://bugs.openjdk.org/browse/JDK-8304834) it passed test jvm args as part of targetAppCommandLine. So the test VM args are added to the jtreg vm options. But after JDK-8304834 it parse then into targetVMArgs. So test vm args should append to jtreg vm options to override them. > > Testing: tier1-tier5 (including failing combination and testing with wrapper) > I haven't added requires to filter out the test, because e filter only failing combination usually. Not exactly, before fix the VM arguments and testClass were split to `java` + "empty VMargs" + ` DebugeeClass` and then VMargs were set to ' ', that all these lines were concatenated back to java DebugeeClass so it worked in the end. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13462#issuecomment-1514735349 From coleenp at openjdk.org Wed Apr 19 14:06:46 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 19 Apr 2023 14:06:46 GMT Subject: RFR: 8306123: Move InstanceKlass writeable flags In-Reply-To: References: Message-ID: On Tue, 18 Apr 2023 17:11:25 GMT, Coleen Phillimore wrote: > Please review this patch to move the writeable Klass AccessFlags to InstanceKlassFlags. > Tested with tier1-4. Thanks Ioi and Fred. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13515#issuecomment-1514794910 From coleenp at openjdk.org Wed Apr 19 14:10:12 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 19 Apr 2023 14:10:12 GMT Subject: Integrated: 8306123: Move InstanceKlass writeable flags In-Reply-To: References: Message-ID: On Tue, 18 Apr 2023 17:11:25 GMT, Coleen Phillimore wrote: > Please review this patch to move the writeable Klass AccessFlags to InstanceKlassFlags. > Tested with tier1-4. This pull request has now been integrated. Changeset: ddb86469 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/ddb86469e024147ab41db7dd26344ba9e14ce17a Stats: 114 lines in 6 files changed: 64 ins; 34 del; 16 mod 8306123: Move InstanceKlass writeable flags Reviewed-by: iklam, fparain ------------- PR: https://git.openjdk.org/jdk/pull/13515 From duke at openjdk.org Wed Apr 19 14:41:03 2023 From: duke at openjdk.org (Fredrik Bredberg) Date: Wed, 19 Apr 2023 14:41:03 GMT Subject: RFR: 8306006: strace001.java fails due to unknown methods on stack [v2] In-Reply-To: References: <0MpbrqTjZXqfi6_St4dA5WcxAPZ8ec3P6UwLu0jFKUQ=.599f880e-b0bf-4308-bada-ca075c42ac63@github.com> Message-ID: On Wed, 19 Apr 2023 11:30:42 GMT, Fredrik Bredberg wrote: >> Added the missing java.lang.Thread.beforeSleep and java.lang.afterSleep to expectedSystemTrace. >> Tested on my local machine. > > Fredrik Bredberg has updated the pull request incrementally with two additional commits since the last revision: > > - Updated after review > - Added java.util.concurrent.TimeUnit.toNanos to expectedSystemTrace Thanks for the review guys. Can any of you give me a helping hand (sponsor) the integration. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13476#issuecomment-1514856304 From duke at openjdk.org Wed Apr 19 14:49:49 2023 From: duke at openjdk.org (Afshin Zafari) Date: Wed, 19 Apr 2023 14:49:49 GMT Subject: RFR: 8305590: Remove nothrow exception specifications from operator new [v2] In-Reply-To: References: <619AH3LBFaBdG1odgp4kpuCjm6ujfOivOUtoDYHdhCw=.96e5693b-e8c1-4923-88e4-11715889b822@github.com> Message-ID: On Wed, 19 Apr 2023 11:00:32 GMT, Kim Barrett wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> 8305590: Remove nothrow exception specifications from operator new > > src/hotspot/share/prims/jvmtiRawMonitor.hpp line 114: > >> 112: >> 113: // Non-aborting operator new >> 114: void* operator new(size_t size, const std::nothrow_t& nothrow_constant) throw() { > > Hm, now I'm wondering why isn't an `operator delete` to go with this? Or are these objects > never deleted? Otherwise I'd have thought we'd get the same mismatched new/delete warning > you encountered elsewhere. If they're never supposed to be deleted, then giving `operator delete` > a deleted definition here seems appropriate, to prevent accidentally calling the CHeapObj function. This `operator new` just calls the `CHeapObj::operator new` with nothrow argument. So changing the caller will call the right one in `CHeapObj`. This object is deleted in https://github.com/openjdk/jdk/blob/c738c8ea3e9fda87abb03acb599a2433a344db09/src/hotspot/share/prims/jvmtiEnv.cpp#L3699 and this will call the `CHeapObj::operator delete` which is the right one. So this `operator new` is not needed since I changed the caller. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13498#discussion_r1171457189 From duke at openjdk.org Wed Apr 19 15:08:00 2023 From: duke at openjdk.org (Fredrik Bredberg) Date: Wed, 19 Apr 2023 15:08:00 GMT Subject: Integrated: 8306006: strace001.java fails due to unknown methods on stack In-Reply-To: <0MpbrqTjZXqfi6_St4dA5WcxAPZ8ec3P6UwLu0jFKUQ=.599f880e-b0bf-4308-bada-ca075c42ac63@github.com> References: <0MpbrqTjZXqfi6_St4dA5WcxAPZ8ec3P6UwLu0jFKUQ=.599f880e-b0bf-4308-bada-ca075c42ac63@github.com> Message-ID: On Fri, 14 Apr 2023 13:27:37 GMT, Fredrik Bredberg wrote: > Added the missing java.lang.Thread.beforeSleep and java.lang.afterSleep to expectedSystemTrace. > Tested on my local machine. This pull request has now been integrated. Changeset: a31a11f4 Author: Fredrik Bredberg Committer: Alan Bateman URL: https://git.openjdk.org/jdk/commit/a31a11f44a8477c2fbfde929b5c725f819470d25 Stats: 59 lines in 10 files changed: 8 ins; 12 del; 39 mod 8306006: strace001.java fails due to unknown methods on stack Reviewed-by: rehn, alanb, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/13476 From jiangli at openjdk.org Wed Apr 19 15:18:44 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 19 Apr 2023 15:18:44 GMT Subject: RFR: 8306033: Resolve multiple definition of 'throwIOException' and friends when statically linking with JDK native libraries In-Reply-To: References: Message-ID: On Wed, 19 Apr 2023 11:01:07 GMT, Jaikiran Pai wrote: > Even if it doesn't get enrolled in the pre-submit testing, I think the fact that there will be a build within the JDK which can catch these issues is a good thing. It might catch the issue(s) after the integration, but I think it's still a good improvement to have these issues identified by running a specific variant of the JDK build process. Agreed, thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13497#issuecomment-1514918976 From amitkumar at openjdk.org Wed Apr 19 16:26:02 2023 From: amitkumar at openjdk.org (Amit Kumar) Date: Wed, 19 Apr 2023 16:26:02 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v15] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Wed, 19 Apr 2023 13:22:54 GMT, Martin Doerr wrote: >> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: >> >> - Merge branch 'master' into 8304915-arch-enum >> - ArchTest on Debian RISC-V 64 confirmed by reviewer >> - Fixed isPPC64(). >> Consolidated switch cases in ArchTest. >> Moved mapping of build TARGET_OS and TARGET_CPU to the build >> to avoid multiple mappings in more than one place. >> - Correct mapping and test of ppc64 >> - Add ppc64 as mapping to PPC64 Architecture >> - Modified test to check Architecture is64bits() and isLittleEndian() >> against Unsafe respective values. >> Relocated code mapping OS name and arch name from PlatformProps to >> OperatingSystem and Architecture. Kept the mapping of names >> in the template close to where the values are filled in by the build. >> - Remove unused static and import of Stabile >> - Rename OperatingSystemProps to PlatformProps. >> Refactor OperatingSystem initialization to use strings instead of integers. >> - Revised mapping mechanism of build target architecture names to enum values. >> Unrecognized values from the build are mapped to enum value "OTHER". >> Renamed PPC64LE to PPC64 to reflect only the architecture, not the endianness. >> Added an `isLittleEndian` method to return the endianness (not currently used anywhere) >> - Revert changes to jdk.accessibility AccessBridge >> - ... and 7 more: https://git.openjdk.org/jdk/compare/8858d543...99a93b7e > > test/jdk/jdk/internal/util/ArchTest.java line 71: > >> 69: case "aarch64" -> AARCH64; >> 70: case "riscv64" -> RISCV64; >> 71: case "s390x", "s390" -> S390; // unverified > > This was also verified according to comments. Right, @offamitkumar? Yes, you're correct @TheRealMDoerr ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1171580811 From amitkumar at openjdk.org Wed Apr 19 16:29:57 2023 From: amitkumar at openjdk.org (Amit Kumar) Date: Wed, 19 Apr 2023 16:29:57 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v15] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Mon, 17 Apr 2023 20:59:06 GMT, Roger Riggs wrote: >> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. >> The enumeration values are defined to match those used in the build. >> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64` >> Note that `amd64` and `x86_64` in the build are represented by `X64`. >> The value of the system property `os.arch` is unchanged. >> >> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). >> Uses in `java.base` and a few others are included but other modules will be done in separate PRs. > > Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: > > - Merge branch 'master' into 8304915-arch-enum > - ArchTest on Debian RISC-V 64 confirmed by reviewer > - Fixed isPPC64(). > Consolidated switch cases in ArchTest. > Moved mapping of build TARGET_OS and TARGET_CPU to the build > to avoid multiple mappings in more than one place. > - Correct mapping and test of ppc64 > - Add ppc64 as mapping to PPC64 Architecture > - Modified test to check Architecture is64bits() and isLittleEndian() > against Unsafe respective values. > Relocated code mapping OS name and arch name from PlatformProps to > OperatingSystem and Architecture. Kept the mapping of names > in the template close to where the values are filled in by the build. > - Remove unused static and import of Stabile > - Rename OperatingSystemProps to PlatformProps. > Refactor OperatingSystem initialization to use strings instead of integers. > - Revised mapping mechanism of build target architecture names to enum values. > Unrecognized values from the build are mapped to enum value "OTHER". > Renamed PPC64LE to PPC64 to reflect only the architecture, not the endianness. > Added an `isLittleEndian` method to return the endianness (not currently used anywhere) > - Revert changes to jdk.accessibility AccessBridge > - ... and 7 more: https://git.openjdk.org/jdk/compare/8858d543...99a93b7e for s390x, build is fine and tier1 (specifically `ArchTest.java`) passes. Thanks for the change. ------------- Marked as reviewed by amitkumar (Author). PR Review: https://git.openjdk.org/jdk/pull/13357#pullrequestreview-1392455297 From rriggs at openjdk.org Wed Apr 19 18:08:40 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 19 Apr 2023 18:08:40 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v16] In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: > Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. > The enumeration values are defined to match those used in the build. > The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64` > Note that `amd64` and `x86_64` in the build are represented by `X64`. > The value of the system property `os.arch` is unchanged. > > The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). > Uses in `java.base` and a few others are included but other modules will be done in separate PRs. Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: - Use and test of "s390" verified by reviewer. - Merge branch 'master' into 8304915-arch-enum - Merge branch 'master' into 8304915-arch-enum - ArchTest on Debian RISC-V 64 confirmed by reviewer - Fixed isPPC64(). Consolidated switch cases in ArchTest. Moved mapping of build TARGET_OS and TARGET_CPU to the build to avoid multiple mappings in more than one place. - Correct mapping and test of ppc64 - Add ppc64 as mapping to PPC64 Architecture - Modified test to check Architecture is64bits() and isLittleEndian() against Unsafe respective values. Relocated code mapping OS name and arch name from PlatformProps to OperatingSystem and Architecture. Kept the mapping of names in the template close to where the values are filled in by the build. - Remove unused static and import of Stabile - Rename OperatingSystemProps to PlatformProps. Refactor OperatingSystem initialization to use strings instead of integers. - ... and 9 more: https://git.openjdk.org/jdk/compare/0f3828dd...b95a312d ------------- Changes: https://git.openjdk.org/jdk/pull/13357/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=15 Stats: 410 lines in 7 files changed: 342 ins; 57 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/13357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13357/head:pull/13357 PR: https://git.openjdk.org/jdk/pull/13357 From cjplummer at openjdk.org Wed Apr 19 18:42:43 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 19 Apr 2023 18:42:43 GMT Subject: RFR: 8306437: jhsdb cannot resolve image/symbol paths being used for analysis of Windows coredumps In-Reply-To: <62oUnZxCgEiiGjk1I9qb_1M_Zl0Sx4UvFeCk2S7mY00=.15eb4fda-eb88-4f9c-9d73-6fba9da60692@github.com> References: <62oUnZxCgEiiGjk1I9qb_1M_Zl0Sx4UvFeCk2S7mY00=.15eb4fda-eb88-4f9c-9d73-6fba9da60692@github.com> Message-ID: On Wed, 19 Apr 2023 10:39:40 GMT, Alexey Pavlyutkin wrote: > Hi! The patch fixes image/symbol lookup by jhsdb on alanysis Windows coredump. It uses executableName as a hint prepending image path with > > `;\server` > > and symbol path with > > `srv*https://msdl.microsoft.com/download/symbols;;\server` > > where the first bit points to Windows symbols located on remote server Did you read the "Using transported core dumps on Windows" section of transported_core.html? https://github.com/openjdk/jdk/blob/master/src/jdk.hotspot.agent/doc/transported_core.html#L70 I'd like to know if you tried everything mentioned and still had issues. I reworked this section recently, but didn't have any first hand experience to go with. Just the old text and some input from those were using jhsdb with Windows. It would be good if you could update this section to reflect your changes, and also add something regarding `sun.jvm.hotspot.debugger.windbg.imagePath` and `sun.jvm.hotspot.debugger.windbg.imagePath`, which I wasn't aware of when I recently updated this doc. I understand your changes regarding looking relative to the executable name, but I don't understand how the following works. These are Windows services I'm not familiar with. Can you explain? // request Windows symbol table from remote server... symbols.append("srv*https://msdl.microsoft.com/download/symbols;"); ------------- PR Comment: https://git.openjdk.org/jdk/pull/13530#issuecomment-1515198314 From sspitsyn at openjdk.org Wed Apr 19 22:02:20 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 19 Apr 2023 22:02:20 GMT Subject: RFR: 8306028: separate ThreadStart/ThreadEnd events posting code in JVMTI VTMS transitions [v3] In-Reply-To: References: Message-ID: > This refactoring to separate ThreadStart/ThreadEnd events posting code in the JVMTI VTMS transitions is needed for future work on JVMTI scalability and performance improvements. It is to easier put this code on slow path. > > Testing: mach5 tiers 1-6 were successful. Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge - 8304444: Reappearance of NULL in jvmtiThreadState.cpp - 8306028: separate ThreadStart/ThreadEnd events posting code in JVMTI VTMS transitions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13484/files - new: https://git.openjdk.org/jdk/pull/13484/files/7735ffac..5594635c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13484&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13484&range=01-02 Stats: 224828 lines in 1318 files changed: 212269 ins; 4015 del; 8544 mod Patch: https://git.openjdk.org/jdk/pull/13484.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13484/head:pull/13484 PR: https://git.openjdk.org/jdk/pull/13484 From coleenp at openjdk.org Wed Apr 19 22:53:41 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 19 Apr 2023 22:53:41 GMT Subject: RFR: 8306474: Move InstanceKlass read-only flags Message-ID: Moved three read-only InstanceKlass flags out of AccessFlags to InstanceKlassFlags, and removed unused and unneeded SA code. Tested with tier1-4. ------------- Commit messages: - 8306474: Move InstanceKlass read-only flags Changes: https://git.openjdk.org/jdk/pull/13545/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13545&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306474 Stats: 44 lines in 10 files changed: 11 ins; 26 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/13545.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13545/head:pull/13545 PR: https://git.openjdk.org/jdk/pull/13545 From sspitsyn at openjdk.org Wed Apr 19 23:17:31 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 19 Apr 2023 23:17:31 GMT Subject: RFR: 8306034: add support of virtual threads to JVMTI StopThread Message-ID: This enhancement adds support of virtual threads to the JVMTI `StopThread` function. In preview releases before this enhancement the StopThread returned the JVMTI_ERROR_UNSUPPORTED_OPERATION error code for virtual threads. The `StopThread` supports sending an asynchronous exception to a virtual thread only if it is current or suspended at mounted state. For instance, a virtual thread can be suspended at a JVMTI event. If the virtual thread is not suspended and is not current then the `JVMTI_ERROR_THREAD_NOT_SUSPENDED` error code is returned. If the virtual thread was suspended at unmounted state then the `JVMTI_ERROR_OPAQUE_FRAME` error code is returned. The `StopThread` has the following description for `JVMTI_ERROR_OPAQUE_FRAME` error code: > The thread is a suspended virtual thread and the implementation > was unable to throw an asynchronous exception from this frame. A couple of the `serviceability/jvmti/vthread` tests has been updated to adopt to new `StopThread` behavior. The CSR is: https://bugs.openjdk.org/browse/JDK-8306434 Testing: The mach5 tears 1-6 are in progress. Preliminary test runs were good in general. The JDB test `vmTestbase/nsk/jdb/kill/kill001/kill001.java` has been problem-listed and will be fixed by the corresponding debugger enhancement which is going to adopt JDWP/JDI specs to new behavior of the JVMTI `StopThread` related to virtual threads. Also, two JCK JVMTI tests are failing in the tier-6 : > vm/jvmti/StopThread/stop001/stop00103/stop00103.html > vm/jvmti/StopThread/stop001/stop00103/stop00103a.html These two tests will be excluded from the test runs by the JCK team and then adjusted to new `StopThread` behavior. ------------- Commit messages: - fixed trailing spaces - 8306034: add support of virtual threads to JVMTI StopThread Changes: https://git.openjdk.org/jdk/pull/13546/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13546&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306034 Stats: 477 lines in 8 files changed: 456 ins; 8 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/13546.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13546/head:pull/13546 PR: https://git.openjdk.org/jdk/pull/13546 From jrose at openjdk.org Wed Apr 19 23:31:42 2023 From: jrose at openjdk.org (John R Rose) Date: Wed, 19 Apr 2023 23:31:42 GMT Subject: RFR: 8306474: Move InstanceKlass read-only flags In-Reply-To: References: Message-ID: On Wed, 19 Apr 2023 22:46:55 GMT, Coleen Phillimore wrote: > Moved three read-only InstanceKlass flags out of AccessFlags to InstanceKlassFlags, and removed unused and unneeded SA code. > Tested with tier1-4. Reviewed. I like to see access flags being slowly emptied out. It was a not-so-good idea (in hindsight) to overload them. src/hotspot/share/oops/instanceKlassFlags.hpp line 52: > 50: flag(is_shared_app_class , 1 << 9) /* defining class loader is app class loader */ \ > 51: flag(has_contended_annotations , 1 << 10) /* has @Contended annotation */ \ > 52: flag(has_localvariable_table , 1 << 11) /* has localvariable information */ I suggest, as a matter of course, keeping the final `` at the end of the list, and then adding something like `/*end of list*/` at the end. This helps prevent churn on the final line, in such lists. ------------- Marked as reviewed by jrose (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13545#pullrequestreview-1393009587 PR Review Comment: https://git.openjdk.org/jdk/pull/13545#discussion_r1171940561 From jrose at openjdk.org Wed Apr 19 23:39:44 2023 From: jrose at openjdk.org (John R Rose) Date: Wed, 19 Apr 2023 23:39:44 GMT Subject: RFR: 8306474: Move InstanceKlass read-only flags In-Reply-To: References: Message-ID: On Wed, 19 Apr 2023 23:27:10 GMT, John R Rose wrote: >> Moved three read-only InstanceKlass flags out of AccessFlags to InstanceKlassFlags, and removed unused and unneeded SA code. >> Tested with tier1-4. > > src/hotspot/share/oops/instanceKlassFlags.hpp line 52: > >> 50: flag(is_shared_app_class , 1 << 9) /* defining class loader is app class loader */ \ >> 51: flag(has_contended_annotations , 1 << 10) /* has @Contended annotation */ \ >> 52: flag(has_localvariable_table , 1 << 11) /* has localvariable information */ > > I suggest, as a matter of course, keeping the final `` at the end of the list, and then adding something like `/*end of list*/` at the end. This helps prevent churn on the final line, in such lists. That should be ``, in case it didn?t come through markdown. Removing the final backslash, like removing the final comma of an `enum`, causes churn. Adding a final comment also makes it easy to visually locate the end of the sequence; it is much clearer than the blank line required by the cpp macro mechanism. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13545#discussion_r1171944831 From cjplummer at openjdk.org Wed Apr 19 23:54:43 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 19 Apr 2023 23:54:43 GMT Subject: RFR: 8306034: add support of virtual threads to JVMTI StopThread In-Reply-To: References: Message-ID: On Wed, 19 Apr 2023 22:54:35 GMT, Serguei Spitsyn wrote: > The JDB test `vmTestbase/nsk/jdb/kill/kill001/kill001.java` has been problem-listed and will be fixed by the corresponding debugger enhancement which is going to adopt JDWP/JDI specs to new behavior of the JVMTI `StopThread` related to virtual threads. I'll be fixing this using [JDK-8306467](https://bugs.openjdk.org/browse/JDK-8306467), which will be done after the JDWP/JDI spec/impl update, which is being handled by [JDK-8306471](https://bugs.openjdk.org/browse/JDK-8306471). ------------- PR Comment: https://git.openjdk.org/jdk/pull/13546#issuecomment-1515519931 From sspitsyn at openjdk.org Thu Apr 20 00:00:41 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 20 Apr 2023 00:00:41 GMT Subject: RFR: 8306034: add support of virtual threads to JVMTI StopThread In-Reply-To: References: Message-ID: On Wed, 19 Apr 2023 23:51:53 GMT, Chris Plummer wrote: > I'll be fixing this using [JDK-8306467](https://bugs.openjdk.org/browse/JDK-8306467), > which will be done after the JDWP/JDI spec/impl update, which is being handled by > [JDK-8306471](https://bugs.openjdk.org/browse/JDK-8306471). Thank you, Chris. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13546#issuecomment-1515523290 From coleenp at openjdk.org Thu Apr 20 00:27:20 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 20 Apr 2023 00:27:20 GMT Subject: RFR: 8306474: Move InstanceKlass read-only flags [v2] In-Reply-To: References: Message-ID: On Wed, 19 Apr 2023 23:36:45 GMT, John R Rose wrote: >> src/hotspot/share/oops/instanceKlassFlags.hpp line 52: >> >>> 50: flag(is_shared_app_class , 1 << 9) /* defining class loader is app class loader */ \ >>> 51: flag(has_contended_annotations , 1 << 10) /* has @Contended annotation */ \ >>> 52: flag(has_localvariable_table , 1 << 11) /* has localvariable information */ >> >> I suggest, as a matter of course, keeping the final `` at the end of the list, and then adding something like `/*end of list*/` at the end. This helps prevent churn on the final line, in such lists. > > That should be ``, in case it didn?t come through markdown. Removing the final backslash, like removing the final comma of an `enum`, causes churn. Adding a final comment also makes it easy to visually locate the end of the sequence; it is much clearer than the blank line required by the cpp macro mechanism. Thanks John, that was a good suggestion. Yes, I'm clearing out the AccessFlags in lots of small changes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13545#discussion_r1171963968 From coleenp at openjdk.org Thu Apr 20 00:27:20 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 20 Apr 2023 00:27:20 GMT Subject: RFR: 8306474: Move InstanceKlass read-only flags [v2] In-Reply-To: References: Message-ID: > Moved three read-only InstanceKlass flags out of AccessFlags to InstanceKlassFlags, and removed unused and unneeded SA code. > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: John's suggestion ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13545/files - new: https://git.openjdk.org/jdk/pull/13545/files/eb1e4139..066798c2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13545&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13545&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13545.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13545/head:pull/13545 PR: https://git.openjdk.org/jdk/pull/13545 From coleenp at openjdk.org Thu Apr 20 00:41:50 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 20 Apr 2023 00:41:50 GMT Subject: RFR: 8306482: Remove unused Method AccessFlags Message-ID: Please review this small change to remove Method AccessFlags that are unused. These flags were moved to ConstMethod a long time ago. Tested with tier1-4, SA tests locally ------------- Commit messages: - 8306482: Remove unused Method AccessFlags Changes: https://git.openjdk.org/jdk/pull/13549/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13549&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306482 Stats: 27 lines in 4 files changed: 0 ins; 27 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13549.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13549/head:pull/13549 PR: https://git.openjdk.org/jdk/pull/13549 From dholmes at openjdk.org Thu Apr 20 01:49:44 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 20 Apr 2023 01:49:44 GMT Subject: RFR: 8306474: Move InstanceKlass read-only flags [v2] In-Reply-To: References: Message-ID: On Thu, 20 Apr 2023 00:27:20 GMT, Coleen Phillimore wrote: >> Moved three read-only InstanceKlass flags out of AccessFlags to InstanceKlassFlags, and removed unused and unneeded SA code. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > John's suggestion Changes seem fine. Thanks. Why was `has_finalizer` not included with this group? ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13545#pullrequestreview-1393091073 From dholmes at openjdk.org Thu Apr 20 02:03:42 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 20 Apr 2023 02:03:42 GMT Subject: RFR: 8306482: Remove unused Method AccessFlags In-Reply-To: References: Message-ID: On Thu, 20 Apr 2023 00:35:06 GMT, Coleen Phillimore wrote: > Please review this small change to remove Method AccessFlags that are unused. These flags were moved to ConstMethod a long time ago. > Tested with tier1-4, SA tests locally Seems okay. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13549#pullrequestreview-1393100023 From lmesnik at openjdk.org Thu Apr 20 03:09:44 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 20 Apr 2023 03:09:44 GMT Subject: RFR: 8306034: add support of virtual threads to JVMTI StopThread In-Reply-To: References: Message-ID: On Wed, 19 Apr 2023 22:54:35 GMT, Serguei Spitsyn wrote: > This enhancement adds support of virtual threads to the JVMTI `StopThread` function. > In preview releases before this enhancement the StopThread returned the JVMTI_ERROR_UNSUPPORTED_OPERATION error code for virtual threads. > > The `StopThread` supports sending an asynchronous exception to a virtual thread only if it is current or suspended at mounted state. For instance, a virtual thread can be suspended at a JVMTI event. If the virtual thread is not suspended and is not current then the `JVMTI_ERROR_THREAD_NOT_SUSPENDED` error code is returned. If the virtual thread was suspended at unmounted state then the `JVMTI_ERROR_OPAQUE_FRAME` error code is returned. > > The `StopThread` has the following description for `JVMTI_ERROR_OPAQUE_FRAME` error code: >> The thread is a suspended virtual thread and the implementation >> was unable to throw an asynchronous exception from this frame. > > A couple of the `serviceability/jvmti/vthread` tests has been updated to adopt to new `StopThread` behavior. > > The CSR is: https://bugs.openjdk.org/browse/JDK-8306434 > > Testing: > The mach5 tears 1-6 are in progress. > Preliminary test runs were good in general. > The JDB test `vmTestbase/nsk/jdb/kill/kill001/kill001.java` has been problem-listed and will be fixed by the corresponding debugger enhancement which is going to adopt JDWP/JDI specs to new behavior of the JVMTI `StopThread` related to virtual threads. > > Also, two JCK JVMTI tests are failing in the tier-6 : >> vm/jvmti/StopThread/stop001/stop00103/stop00103.html >> vm/jvmti/StopThread/stop001/stop00103/stop00103a.html > > These two tests will be excluded from the test runs by the JCK team and then adjusted to new `StopThread` behavior. Changes requested by lmesnik (Reviewer). test/hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest/StopThreadTest.java line 38: > 36: * > 37: * @requires vm.continuations > 38: * @compile --enable-preview -source ${jdk.version} StopThreadTest.java --enable-preview is not needed anymore. test/hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest/StopThreadTest.java line 48: > 46: static final int JVMTI_ERROR_NONE = 0; > 47: static final int THREAD_NOT_SUSPENDED = 13; > 48: static final int PASSED = 0; I think it would be better to don't use statuses and just throw exception after first failure. Usually the other results of other test cases might be corrupted and output just confuse user. test/hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest/libStopThreadTest.cpp line 135: > 133: check_jvmti_status(jni, err, "prepareAgent: Failed in JVMTI SetBreakpoint"); > 134: > 135: err = jvmti->SetEventNotificationMode(JVMTI_ENABLE, JVMTI_EVENT_BREAKPOINT, NULL); We have set_event_notification_mode() in jvmti_h. test/hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest/libStopThreadTest.cpp line 151: > 149: Java_StopThreadTest_resumeThread(JNIEnv *jni, jclass cls, jthread thread) { > 150: LOG("Main: resumeThread\n"); > 151: jvmtiError err = jvmti->ResumeThread(thread); there is suspend_thread/resume_thread() in jvmti.h ------------- PR Review: https://git.openjdk.org/jdk/pull/13546#pullrequestreview-1393079770 PR Review Comment: https://git.openjdk.org/jdk/pull/13546#discussion_r1171991173 PR Review Comment: https://git.openjdk.org/jdk/pull/13546#discussion_r1172026145 PR Review Comment: https://git.openjdk.org/jdk/pull/13546#discussion_r1171995417 PR Review Comment: https://git.openjdk.org/jdk/pull/13546#discussion_r1171994042 From dholmes at openjdk.org Thu Apr 20 03:10:55 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 20 Apr 2023 03:10:55 GMT Subject: RFR: 8306282: Build failure linux-arm32-open-cmp-baseline after JDK-8257967 [v3] In-Reply-To: References: <7Mtu4sDUSEqgO7yYhYPVT-aU0XmHOObSRnPOQqDcIic=.443775c9-0d30-4c6f-9815-0133f57a2e00@github.com> <8bWAmer1c40K83zNOqk4t96rJ8xPG-lVyjBXpeGTp2M=.a4fead0c-23c2-4575-b5f7-5782c874fa5d@github.com> Message-ID: On Wed, 19 Apr 2023 11:09:02 GMT, Markus Gr?nlund wrote: > It follows the same pattern as for other jvmti*.cpp files also excluded via make/hotspot/lib/jvmFeatures.gmk. For example, jvmtiExport.cpp. Okay , yes I see that now - I was thrown by the fact that the original versions of these functions in arguments.hpp/cpp did not need this but they were in fact not conditional despite being JVMTI specific. Seems to me there should be a bunch of code in arguments.cpp that is conditionalized on INCLUDE_JVMTI. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13512#issuecomment-1515648566 From duke at openjdk.org Thu Apr 20 03:25:43 2023 From: duke at openjdk.org (Alexey Pavlyutkin) Date: Thu, 20 Apr 2023 03:25:43 GMT Subject: RFR: 8306437: jhsdb cannot resolve image/symbol paths being used for analysis of Windows coredumps In-Reply-To: <62oUnZxCgEiiGjk1I9qb_1M_Zl0Sx4UvFeCk2S7mY00=.15eb4fda-eb88-4f9c-9d73-6fba9da60692@github.com> References: <62oUnZxCgEiiGjk1I9qb_1M_Zl0Sx4UvFeCk2S7mY00=.15eb4fda-eb88-4f9c-9d73-6fba9da60692@github.com> Message-ID: <9VvKt2wdupLCTOJ7IoCUOfLBAMpUiFzN4oT-4QmDCxY=.a2323594-4a18-492c-b74b-40cd34575b33@github.com> On Wed, 19 Apr 2023 10:39:40 GMT, Alexey Pavlyutkin wrote: > Hi! The patch fixes image/symbol lookup by jhsdb on alanysis Windows coredump. It uses executableName as a hint prepending image path with > > `;\server` > > and symbol path with > > `srv*https://msdl.microsoft.com/download/symbols;;\server` > > where the first bit points to Windows symbols located on remote server This public Microsoft symbol server providing debug information for Windows binaries: https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/symbol-path#using-a-symbol-server-srv ------------- PR Comment: https://git.openjdk.org/jdk/pull/13530#issuecomment-1515658163 From kbarrett at openjdk.org Thu Apr 20 05:07:42 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 20 Apr 2023 05:07:42 GMT Subject: RFR: 8305590: Remove nothrow exception specifications from operator new [v2] In-Reply-To: References: <619AH3LBFaBdG1odgp4kpuCjm6ujfOivOUtoDYHdhCw=.96e5693b-e8c1-4923-88e4-11715889b822@github.com> Message-ID: <4mSYzcXKe-qzoXuUBeKHw6nzxEewqPXPkfeZ1kTExHQ=.adb1f609-ffad-43c7-9067-c9fdbeea4071@github.com> On Wed, 19 Apr 2023 14:46:48 GMT, Afshin Zafari wrote: >> src/hotspot/share/prims/jvmtiRawMonitor.hpp line 114: >> >>> 112: >>> 113: // Non-aborting operator new >>> 114: void* operator new(size_t size, const std::nothrow_t& nothrow_constant) throw() { >> >> Hm, now I'm wondering why isn't an `operator delete` to go with this? Or are these objects >> never deleted? Otherwise I'd have thought we'd get the same mismatched new/delete warning >> you encountered elsewhere. If they're never supposed to be deleted, then giving `operator delete` >> a deleted definition here seems appropriate, to prevent accidentally calling the CHeapObj function. > > This `operator new` just calls the `CHeapObj::operator new` with nothrow argument. So changing the caller will call the right one in `CHeapObj`. This object is deleted in > https://github.com/openjdk/jdk/blob/c738c8ea3e9fda87abb03acb599a2433a344db09/src/hotspot/share/prims/jvmtiEnv.cpp#L3699 > and this will call the `CHeapObj::operator delete` which is the right one. So this `operator new` is not needed since I changed the caller. A possible reason for keeping this `operator new` is to force the use of null return for oom for this class. If it's removed then we have the option of (perhaps unintentionally) using the terminating allocator. That doesn't seem like a _strong_ reason to keep it, but someone more familiar with jvmti stuff might want to weigh in. If it is kept, then I think it should have a corresponding `operator delete`, else it at least looks odd. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13498#discussion_r1172085220 From dholmes at openjdk.org Thu Apr 20 07:00:42 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 20 Apr 2023 07:00:42 GMT Subject: RFR: 8305590: Remove nothrow exception specifications from operator new [v2] In-Reply-To: <4mSYzcXKe-qzoXuUBeKHw6nzxEewqPXPkfeZ1kTExHQ=.adb1f609-ffad-43c7-9067-c9fdbeea4071@github.com> References: <619AH3LBFaBdG1odgp4kpuCjm6ujfOivOUtoDYHdhCw=.96e5693b-e8c1-4923-88e4-11715889b822@github.com> <4mSYzcXKe-qzoXuUBeKHw6nzxEewqPXPkfeZ1kTExHQ=.adb1f609-ffad-43c7-9067-c9fdbeea4071@github.com> Message-ID: On Thu, 20 Apr 2023 05:05:17 GMT, Kim Barrett wrote: >> This `operator new` just calls the `CHeapObj::operator new` with nothrow argument. So changing the caller will call the right one in `CHeapObj`. This object is deleted in >> https://github.com/openjdk/jdk/blob/c738c8ea3e9fda87abb03acb599a2433a344db09/src/hotspot/share/prims/jvmtiEnv.cpp#L3699 >> and this will call the `CHeapObj::operator delete` which is the right one. So this `operator new` is not needed since I changed the caller. > > A possible reason for keeping this `operator new` is to force the use of null return for oom for this class. > If it's removed then we have the option of (perhaps unintentionally) using the terminating allocator. > That doesn't seem like a _strong_ reason to keep it, but someone more familiar with jvmti stuff might > want to weigh in. If it is kept, then I think it should have a corresponding `operator delete`, else it at > least looks odd. JVMTI does not abort on OOM it reports an error, so we definitely do not want a terminating allocator! jvmtiError JvmtiEnv::CreateRawMonitor(const char* name, jrawMonitorID* monitor_ptr) { JvmtiRawMonitor* rmonitor = new JvmtiRawMonitor(name); NULL_CHECK(rmonitor, JVMTI_ERROR_OUT_OF_MEMORY); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13498#discussion_r1172159575 From dholmes at openjdk.org Thu Apr 20 07:20:34 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 20 Apr 2023 07:20:34 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v56] In-Reply-To: References: Message-ID: On Thu, 6 Apr 2023 14:38:20 GMT, Daniel D. Daugherty wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> RISCV update > > src/hotspot/share/services/management.cpp line 1131: > >> 1129: if (maxDepth == 0) { >> 1130: // No stack trace to dump so we do not need to stop the world. >> 1131: // Since we never do the VM op here we must set the threads list. > > You may want to add a little more to this comment after L1131: > > // Since we are not stopping the world, the data we gather here > // may change the moment after we return it. Nit: even if you are stopping the world you have restarted it by the time you return so the data can change anyway. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1172177158 From duke at openjdk.org Thu Apr 20 08:41:58 2023 From: duke at openjdk.org (Afshin Zafari) Date: Thu, 20 Apr 2023 08:41:58 GMT Subject: RFR: 8305590: Remove nothrow exception specifications from operator new [v3] In-Reply-To: References: Message-ID: <5uZmZV3ssLzKKFBeajmWUBmZsaZeq-3ImeHkzCvnSwg=.4941a9c0-b250-4290-828a-15416ed791df@github.com> > - The `throw()` (i.e., no throw) specifications are removed from the instances of `operator new` where _do not_ return `nullptr`. > > - The `-fcheck-new` is removed from the gcc compile flags. > > - The `operator new` and `operator delete` are deleted from `StackObj`. > > - The `GrowableArrayCHeap::operator delete` is added to be matched with its corresponding allocation`AnyObj::operator new`, because gcc complains on that after removing the `-fcheck-new` flag. > - The `Thread::operator new`with and without `null` return are removed. > > ### Tests > local: linux-x64 gtest:GrowableArrayCHeap, macosx-aarch64 hotspot:tier1 > mach5: tiers 1-5 Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: 8305590: Remove nothrow exception specifications from operator new ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13498/files - new: https://git.openjdk.org/jdk/pull/13498/files/d2d75e7f..bc0d3069 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13498&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13498&range=01-02 Stats: 7 lines in 3 files changed: 0 ins; 5 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13498.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13498/head:pull/13498 PR: https://git.openjdk.org/jdk/pull/13498 From duke at openjdk.org Thu Apr 20 08:42:01 2023 From: duke at openjdk.org (Afshin Zafari) Date: Thu, 20 Apr 2023 08:42:01 GMT Subject: RFR: 8305590: Remove nothrow exception specifications from operator new [v2] In-Reply-To: References: <619AH3LBFaBdG1odgp4kpuCjm6ujfOivOUtoDYHdhCw=.96e5693b-e8c1-4923-88e4-11715889b822@github.com> Message-ID: <-t-PXOEJs-9wbK-IZVrthyrtUTLfOhI5C3l2IgfmQvU=.cc4287db-ffbe-4c54-94b8-42ce57db87bd@github.com> On Wed, 19 Apr 2023 11:49:49 GMT, David Holmes wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> 8305590: Remove nothrow exception specifications from operator new > > src/hotspot/share/jfr/utilities/jfrAllocation.hpp line 2: > >> 1: /* >> 2: * Copyright (c) 2014, 2023, Oracle and/or its affiliates. All rights reserved. > > This appears to be the only change to this file so should be reverted. Thanks for catching this. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13498#discussion_r1172267019 From duke at openjdk.org Thu Apr 20 08:42:03 2023 From: duke at openjdk.org (Afshin Zafari) Date: Thu, 20 Apr 2023 08:42:03 GMT Subject: RFR: 8305590: Remove nothrow exception specifications from operator new [v3] In-Reply-To: References: Message-ID: On Tue, 18 Apr 2023 18:25:55 GMT, Kim Barrett wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> 8305590: Remove nothrow exception specifications from operator new > > src/hotspot/share/jfr/utilities/jfrAllocation.hpp line 58: > >> 56: NOINLINE void* operator new(size_t size); >> 57: NOINLINE void* operator new (size_t size, const std::nothrow_t& nothrow_constant) throw(); >> 58: NOINLINE void* operator new [](size_t size); > > The changes to JfrCHeapObj are not correct, because these allocators currently _can_ return null. > Their implementation is just to return the result of calling the non-throwing allocator. That's probably > not an ideal implementation. Either the declaration needs to be left as-is or the implementation changed. declaration kept as it is. > src/hotspot/share/memory/allocation.hpp line 287: > >> 285: private: >> 286: void* operator new(size_t size) throw() = delete; >> 287: void* operator new [](size_t size) throw() = delete; > > The lingering nothrow exception-specs here are just clutter and can be removed. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13498#discussion_r1172265672 PR Review Comment: https://git.openjdk.org/jdk/pull/13498#discussion_r1172265938 From duke at openjdk.org Thu Apr 20 08:42:03 2023 From: duke at openjdk.org (Afshin Zafari) Date: Thu, 20 Apr 2023 08:42:03 GMT Subject: RFR: 8305590: Remove nothrow exception specifications from operator new [v2] In-Reply-To: References: <619AH3LBFaBdG1odgp4kpuCjm6ujfOivOUtoDYHdhCw=.96e5693b-e8c1-4923-88e4-11715889b822@github.com> <4mSYzcXKe-qzoXuUBeKHw6nzxEewqPXPkfeZ1kTExHQ=.adb1f609-ffad-43c7-9067-c9fdbeea4071@github.com> Message-ID: <4x0Wm39zfuJNcoQ5PCnW_7coiE5AqQRVMSYqKFW-KUc=.ffc385ac-9baf-4f6d-a65c-9443b495fcd5@github.com> On Thu, 20 Apr 2023 06:58:20 GMT, David Holmes wrote: >> A possible reason for keeping this `operator new` is to force the use of null return for oom for this class. >> If it's removed then we have the option of (perhaps unintentionally) using the terminating allocator. >> That doesn't seem like a _strong_ reason to keep it, but someone more familiar with jvmti stuff might >> want to weigh in. If it is kept, then I think it should have a corresponding `operator delete`, else it at >> least looks odd. > > JVMTI does not abort on OOM it reports an error, so we definitely do not want a terminating allocator! > > jvmtiError > JvmtiEnv::CreateRawMonitor(const char* name, jrawMonitorID* monitor_ptr) { > JvmtiRawMonitor* rmonitor = new JvmtiRawMonitor(name); > NULL_CHECK(rmonitor, JVMTI_ERROR_OUT_OF_MEMORY); The new operator is removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13498#discussion_r1172266527 From kbarrett at openjdk.org Thu Apr 20 09:51:45 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 20 Apr 2023 09:51:45 GMT Subject: RFR: 8305590: Remove nothrow exception specifications from operator new [v3] In-Reply-To: <5uZmZV3ssLzKKFBeajmWUBmZsaZeq-3ImeHkzCvnSwg=.4941a9c0-b250-4290-828a-15416ed791df@github.com> References: <5uZmZV3ssLzKKFBeajmWUBmZsaZeq-3ImeHkzCvnSwg=.4941a9c0-b250-4290-828a-15416ed791df@github.com> Message-ID: On Thu, 20 Apr 2023 08:41:58 GMT, Afshin Zafari wrote: >> - The `throw()` (i.e., no throw) specifications are removed from the instances of `operator new` where _do not_ return `nullptr`. >> >> - The `-fcheck-new` is removed from the gcc compile flags. >> >> - The `operator new` and `operator delete` are deleted from `StackObj`. >> >> - The `GrowableArrayCHeap::operator delete` is added to be matched with its corresponding allocation`AnyObj::operator new`, because gcc complains on that after removing the `-fcheck-new` flag. >> - The `Thread::operator new`with and without `null` return are removed. >> >> ### Tests >> local: linux-x64 gtest:GrowableArrayCHeap, macosx-aarch64 hotspot:tier1 >> mach5: tiers 1-5 > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 8305590: Remove nothrow exception specifications from operator new Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13498#pullrequestreview-1393623647 From zcai at openjdk.org Thu Apr 20 10:19:44 2023 From: zcai at openjdk.org (Zixian Cai) Date: Thu, 20 Apr 2023 10:19:44 GMT Subject: RFR: JDK-8306538: Zero variant build failure after JDK-8257967 Message-ID: JDK-8306538: Zero variant build failure after JDK-8257967 ------------- Commit messages: - Define JvmtiAgent::set_os_lib when JVMTI feature is not available Changes: https://git.openjdk.org/jdk/pull/13557/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13557&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306538 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13557.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13557/head:pull/13557 PR: https://git.openjdk.org/jdk/pull/13557 From rkennke at openjdk.org Thu Apr 20 11:15:47 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 20 Apr 2023 11:15:47 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v62] In-Reply-To: References: Message-ID: > This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). > > What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. > > This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p rotocols. > > The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare. > > In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. > > One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. > > As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. > > This change enables to simplify (and speed-up!) a lot of code: > > - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. > - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR > > Also, and I might be mistaken here, this new lightweight locking would make synchronized work better with Loom: Because the lock-records are no longer scattered across the stack, but instead are densely packed into the lock-stack, it should be easy for a vthread to save its lock-stack upon unmounting and restore it when re-mounting. However, I am not sure about this, and this PR does not attempt to implement that support. > > Testing: > - [x] tier1 x86_64 x aarch64 x +UseFastLocking > - [x] tier2 x86_64 x aarch64 x +UseFastLocking > - [x] tier3 x86_64 x aarch64 x +UseFastLocking > - [x] tier4 x86_64 x aarch64 x +UseFastLocking > - [x] tier1 x86_64 x aarch64 x -UseFastLocking > - [x] tier2 x86_64 x aarch64 x -UseFastLocking > - [x] tier3 x86_64 x aarch64 x -UseFastLocking > - [x] tier4 x86_64 x aarch64 x -UseFastLocking > - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet > > ### Performance > > #### Simple Microbenchmark > > The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops. > > | | x86_64 | aarch64 | > | -- | -- | -- | > | -UseFastLocking | 20.651 | 20.764 | > | +UseFastLocking | 18.896 | 18.908 | > > > #### Renaissance > > ? | x86_64 | ? | ? | ? | aarch64 | ? | ? > -- | -- | -- | -- | -- | -- | -- | -- > ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? > AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% > Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21% > Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% > ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% > GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% > LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% > MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%% > NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% > PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% > FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% > FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% > ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34% > Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% > RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% > Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% > ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% > FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% > FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Remove unnecessary comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10907/files - new: https://git.openjdk.org/jdk/pull/10907/files/c3486726..5d0a0451 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=61 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=60-61 Stats: 7 lines in 1 file changed: 0 ins; 7 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10907.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/10907/head:pull/10907 PR: https://git.openjdk.org/jdk/pull/10907 From shade at openjdk.org Thu Apr 20 12:19:43 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 20 Apr 2023 12:19:43 GMT Subject: RFR: JDK-8306538: Zero variant build failure after JDK-8257967 In-Reply-To: References: Message-ID: On Thu, 20 Apr 2023 10:10:57 GMT, Zixian Cai wrote: > This follows the same style of fix applied in #13512. I noticed this issue when cross-compiling zero slowdebug for riscv64. I confirmed locally that this PR fixes the linking errors. Looks fine and trivial. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13557#pullrequestreview-1393854336 From dholmes at openjdk.org Thu Apr 20 12:22:45 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 20 Apr 2023 12:22:45 GMT Subject: RFR: JDK-8306538: Zero variant build failure after JDK-8257967 In-Reply-To: References: Message-ID: <-IPiDnCACW5_M5g19QvV4skCGfa3qYdw2T8-vK1SrZ4=.3f79658b-3efb-4ca8-bbf9-20e97a0cf15f@github.com> On Thu, 20 Apr 2023 10:10:57 GMT, Zixian Cai wrote: > This follows the same style of fix applied in #13512. I noticed this issue when cross-compiling zero slowdebug for riscv64. I confirmed locally that this PR fixes the linking errors. I'll approve this to get a quick fix in place but: 1. I can't see why this should be specific to zero. 2. I think the better fix is that os::find_builtin_agent should be guarded by `#if INCLUDE_JVMTI`. Or even moved to a JVMTI file instead. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13557#pullrequestreview-1393859986 From zcai at openjdk.org Thu Apr 20 12:40:44 2023 From: zcai at openjdk.org (Zixian Cai) Date: Thu, 20 Apr 2023 12:40:44 GMT Subject: RFR: JDK-8306538: Zero variant build failure after JDK-8257967 In-Reply-To: References: Message-ID: On Thu, 20 Apr 2023 10:10:57 GMT, Zixian Cai wrote: > This follows the same style of fix applied in #13512. I noticed this issue when cross-compiling zero slowdebug for riscv64. I confirmed locally that this PR fixes the linking errors. Agreed. As discussed #13512, relevant code should be cleaned up. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13557#issuecomment-1516252162 From zcai at openjdk.org Thu Apr 20 12:40:46 2023 From: zcai at openjdk.org (Zixian Cai) Date: Thu, 20 Apr 2023 12:40:46 GMT Subject: RFR: JDK-8306538: Zero variant build failure after JDK-8257967 In-Reply-To: <-IPiDnCACW5_M5g19QvV4skCGfa3qYdw2T8-vK1SrZ4=.3f79658b-3efb-4ca8-bbf9-20e97a0cf15f@github.com> References: <-IPiDnCACW5_M5g19QvV4skCGfa3qYdw2T8-vK1SrZ4=.3f79658b-3efb-4ca8-bbf9-20e97a0cf15f@github.com> Message-ID: On Thu, 20 Apr 2023 12:20:05 GMT, David Holmes wrote: > I think the better fix is that `os::find_builtin_agent` should be guarded by `#if INCLUDE_JVMTI`. Or even moved to a JVMTI file instead. Right. This is also the pattern used to exclude C1/C2 specific stuff from a zero build. Perhaps we can have a separate JBS issue to track these proposed changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13557#issuecomment-1516254023 From zcai at openjdk.org Thu Apr 20 12:44:56 2023 From: zcai at openjdk.org (Zixian Cai) Date: Thu, 20 Apr 2023 12:44:56 GMT Subject: Integrated: JDK-8306538: Zero variant build failure after JDK-8257967 In-Reply-To: References: Message-ID: On Thu, 20 Apr 2023 10:10:57 GMT, Zixian Cai wrote: > This follows the same style of fix applied in #13512. I noticed this issue when cross-compiling zero slowdebug for riscv64. I confirmed locally that this PR fixes the linking errors. This pull request has now been integrated. Changeset: 33a7978e Author: Zixian Cai Committer: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/33a7978e85c0c2d610828f89fc1389696f55e1f2 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8306538: Zero variant build failure after JDK-8257967 Reviewed-by: shade, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/13557 From coleenp at openjdk.org Thu Apr 20 13:14:48 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 20 Apr 2023 13:14:48 GMT Subject: RFR: 8306474: Move InstanceKlass read-only flags [v2] In-Reply-To: References: Message-ID: On Thu, 20 Apr 2023 01:46:46 GMT, David Holmes wrote: > Why was has_finalizer not included with this group? There are 4 flags that aren't included because these flags are referenced from assembly or compiler code. I'm going to write more about this in a comment in the bug as I'm trying to decide how to or whether to move them. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13545#issuecomment-1516304294 From sspitsyn at openjdk.org Thu Apr 20 15:48:48 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 20 Apr 2023 15:48:48 GMT Subject: RFR: 8306034: add support of virtual threads to JVMTI StopThread In-Reply-To: References: Message-ID: On Thu, 20 Apr 2023 01:27:37 GMT, Leonid Mesnik wrote: >> This enhancement adds support of virtual threads to the JVMTI `StopThread` function. >> In preview releases before this enhancement the StopThread returned the JVMTI_ERROR_UNSUPPORTED_OPERATION error code for virtual threads. >> >> The `StopThread` supports sending an asynchronous exception to a virtual thread only if it is current or suspended at mounted state. For instance, a virtual thread can be suspended at a JVMTI event. If the virtual thread is not suspended and is not current then the `JVMTI_ERROR_THREAD_NOT_SUSPENDED` error code is returned. If the virtual thread was suspended at unmounted state then the `JVMTI_ERROR_OPAQUE_FRAME` error code is returned. >> >> The `StopThread` has the following description for `JVMTI_ERROR_OPAQUE_FRAME` error code: >>> The thread is a suspended virtual thread and the implementation >>> was unable to throw an asynchronous exception from this frame. >> >> A couple of the `serviceability/jvmti/vthread` tests has been updated to adopt to new `StopThread` behavior. >> >> The CSR is: https://bugs.openjdk.org/browse/JDK-8306434 >> >> Testing: >> The mach5 tears 1-6 are in progress. >> Preliminary test runs were good in general. >> The JDB test `vmTestbase/nsk/jdb/kill/kill001/kill001.java` has been problem-listed and will be fixed by the corresponding debugger enhancement which is going to adopt JDWP/JDI specs to new behavior of the JVMTI `StopThread` related to virtual threads. >> >> Also, two JCK JVMTI tests are failing in the tier-6 : >>> vm/jvmti/StopThread/stop001/stop00103/stop00103.html >>> vm/jvmti/StopThread/stop001/stop00103/stop00103a.html >> >> These two tests will be excluded from the test runs by the JCK team and then adjusted to new `StopThread` behavior. > > test/hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest/StopThreadTest.java line 38: > >> 36: * >> 37: * @requires vm.continuations >> 38: * @compile --enable-preview -source ${jdk.version} StopThreadTest.java > > --enable-preview is not needed anymore. Fixed, thanks. > test/hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest/libStopThreadTest.cpp line 135: > >> 133: check_jvmti_status(jni, err, "prepareAgent: Failed in JVMTI SetBreakpoint"); >> 134: >> 135: err = jvmti->SetEventNotificationMode(JVMTI_ENABLE, JVMTI_EVENT_BREAKPOINT, NULL); > > We have set_event_notification_mode() in jvmti_h. Fixed, thanks. > test/hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest/libStopThreadTest.cpp line 151: > >> 149: Java_StopThreadTest_resumeThread(JNIEnv *jni, jclass cls, jthread thread) { >> 150: LOG("Main: resumeThread\n"); >> 151: jvmtiError err = jvmti->ResumeThread(thread); > > there is suspend_thread/resume_thread() in jvmti.h Fixed, thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13546#discussion_r1172784838 PR Review Comment: https://git.openjdk.org/jdk/pull/13546#discussion_r1172785542 PR Review Comment: https://git.openjdk.org/jdk/pull/13546#discussion_r1172785177 From lmesnik at openjdk.org Thu Apr 20 16:18:48 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 20 Apr 2023 16:18:48 GMT Subject: RFR: 8233725: ProcessTools.startProcess() has output issues when using an OutputAnalyzer at the same time Message-ID: ProcessTools.startProcess() creates process and read it's output error streams. So the any other using of corresponding Process.getInputStream() and Process.getErrorStream() doesn't get process streams. This fix preserve process streams content and allow to read it after process completion. The another possible solution would be to throw exception when user tries to read already drained streams to fail tests earlier. However it complicates usage of ProcessTools.startProcess() methods. The regression test has been provided with issue. ------------- Commit messages: - 8233725: ProcessTools.startProcess() has output issues when using an OutputAnalyzer at the same time Changes: https://git.openjdk.org/jdk/pull/13560/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13560&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8233725 Stats: 180 lines in 3 files changed: 163 ins; 2 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/13560.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13560/head:pull/13560 PR: https://git.openjdk.org/jdk/pull/13560 From sspitsyn at openjdk.org Thu Apr 20 16:40:48 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 20 Apr 2023 16:40:48 GMT Subject: RFR: 8306034: add support of virtual threads to JVMTI StopThread [v2] In-Reply-To: References: Message-ID: > This enhancement adds support of virtual threads to the JVMTI `StopThread` function. > In preview releases before this enhancement the StopThread returned the JVMTI_ERROR_UNSUPPORTED_OPERATION error code for virtual threads. > > The `StopThread` supports sending an asynchronous exception to a virtual thread only if it is current or suspended at mounted state. For instance, a virtual thread can be suspended at a JVMTI event. If the virtual thread is not suspended and is not current then the `JVMTI_ERROR_THREAD_NOT_SUSPENDED` error code is returned. If the virtual thread was suspended at unmounted state then the `JVMTI_ERROR_OPAQUE_FRAME` error code is returned. > > The `StopThread` has the following description for `JVMTI_ERROR_OPAQUE_FRAME` error code: >> The thread is a suspended virtual thread and the implementation >> was unable to throw an asynchronous exception from this frame. > > A couple of the `serviceability/jvmti/vthread` tests has been updated to adopt to new `StopThread` behavior. > > The CSR is: https://bugs.openjdk.org/browse/JDK-8306434 > > Testing: > The mach5 tears 1-6 are in progress. > Preliminary test runs were good in general. > The JDB test `vmTestbase/nsk/jdb/kill/kill001/kill001.java` has been problem-listed and will be fixed by the corresponding debugger enhancement which is going to adopt JDWP/JDI specs to new behavior of the JVMTI `StopThread` related to virtual threads. > > Also, two JCK JVMTI tests are failing in the tier-6 : >> vm/jvmti/StopThread/stop001/stop00103/stop00103.html >> vm/jvmti/StopThread/stop001/stop00103/stop00103a.html > > These two tests will be excluded from the test runs by the JCK team and then adjusted to new `StopThread` behavior. Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: addressed review comments on new test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13546/files - new: https://git.openjdk.org/jdk/pull/13546/files/bde41a00..0b26f42c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13546&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13546&range=00-01 Stats: 39 lines in 2 files changed: 9 ins; 13 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/13546.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13546/head:pull/13546 PR: https://git.openjdk.org/jdk/pull/13546 From sspitsyn at openjdk.org Thu Apr 20 16:42:44 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 20 Apr 2023 16:42:44 GMT Subject: RFR: 8306034: add support of virtual threads to JVMTI StopThread [v2] In-Reply-To: References: Message-ID: On Thu, 20 Apr 2023 02:46:58 GMT, Leonid Mesnik wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> addressed review comments on new test > > test/hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest/StopThreadTest.java line 48: > >> 46: static final int JVMTI_ERROR_NONE = 0; >> 47: static final int THREAD_NOT_SUSPENDED = 13; >> 48: static final int PASSED = 0; > > I think it would be better to don't use statuses and just throw exception after first failure. Usually the other results of other test cases might be corrupted and output just confuse user. I've made some changes to throw RuntimeException right away in the Main thread. However, this status is still needed for failures from the TestTask thread. Sync protocol with the TestTask thread needs to remain. Otherwise, the process hangs. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13546#discussion_r1172847943 From alanb at openjdk.org Thu Apr 20 18:19:45 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 20 Apr 2023 18:19:45 GMT Subject: RFR: 8306034: add support of virtual threads to JVMTI StopThread [v2] In-Reply-To: References: Message-ID: <70mPVNX3n2TUacbWW0JDIfTNEACwzppdyY5PzYZxdRY=.749a3e99-be99-45ab-a688-e9c563dd5182@github.com> On Thu, 20 Apr 2023 16:40:48 GMT, Serguei Spitsyn wrote: >> This enhancement adds support of virtual threads to the JVMTI `StopThread` function. >> In preview releases before this enhancement the StopThread returned the JVMTI_ERROR_UNSUPPORTED_OPERATION error code for virtual threads. >> >> The `StopThread` supports sending an asynchronous exception to a virtual thread only if it is current or suspended at mounted state. For instance, a virtual thread can be suspended at a JVMTI event. If the virtual thread is not suspended and is not current then the `JVMTI_ERROR_THREAD_NOT_SUSPENDED` error code is returned. If the virtual thread was suspended at unmounted state then the `JVMTI_ERROR_OPAQUE_FRAME` error code is returned. >> >> The `StopThread` has the following description for `JVMTI_ERROR_OPAQUE_FRAME` error code: >>> The thread is a suspended virtual thread and the implementation >>> was unable to throw an asynchronous exception from this frame. >> >> A couple of the `serviceability/jvmti/vthread` tests has been updated to adopt to new `StopThread` behavior. >> >> The CSR is: https://bugs.openjdk.org/browse/JDK-8306434 >> >> Testing: >> The mach5 tears 1-6 are in progress. >> Preliminary test runs were good in general. >> The JDB test `vmTestbase/nsk/jdb/kill/kill001/kill001.java` has been problem-listed and will be fixed by the corresponding debugger enhancement which is going to adopt JDWP/JDI specs to new behavior of the JVMTI `StopThread` related to virtual threads. >> >> Also, two JCK JVMTI tests are failing in the tier-6 : >>> vm/jvmti/StopThread/stop001/stop00103/stop00103.html >>> vm/jvmti/StopThread/stop001/stop00103/stop00103a.html >> >> These two tests will be excluded from the test runs by the JCK team and then adjusted to new `StopThread` behavior. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > addressed review comments on new test src/hotspot/share/prims/jvmtiEnv.cpp line 1197: > 1195: if (is_virtual && !is_JavaThread_current(java_thread, thread_oop)) { > 1196: if (!JvmtiVTSuspender::is_vthread_suspended(thread_oop)) { > 1197: return JVMTI_ERROR_THREAD_NOT_SUSPENDED; Does JvmtiVTSuspender::is_vthread_suspended work for the alternative virtual thread implementation (-XX:+VMContinuations)? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13546#discussion_r1172941986 From coleenp at openjdk.org Thu Apr 20 18:39:48 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 20 Apr 2023 18:39:48 GMT Subject: RFR: 8305590: Remove nothrow exception specifications from operator new [v3] In-Reply-To: <5uZmZV3ssLzKKFBeajmWUBmZsaZeq-3ImeHkzCvnSwg=.4941a9c0-b250-4290-828a-15416ed791df@github.com> References: <5uZmZV3ssLzKKFBeajmWUBmZsaZeq-3ImeHkzCvnSwg=.4941a9c0-b250-4290-828a-15416ed791df@github.com> Message-ID: On Thu, 20 Apr 2023 08:41:58 GMT, Afshin Zafari wrote: >> - The `throw()` (i.e., no throw) specifications are removed from the instances of `operator new` where _do not_ return `nullptr`. >> >> - The `-fcheck-new` is removed from the gcc compile flags. >> >> - The `operator new` and `operator delete` are deleted from `StackObj`. >> >> - The `GrowableArrayCHeap::operator delete` is added to be matched with its corresponding allocation`AnyObj::operator new`, because gcc complains on that after removing the `-fcheck-new` flag. >> - The `Thread::operator new`with and without `null` return are removed. >> >> ### Tests >> local: linux-x64 gtest:GrowableArrayCHeap, macosx-aarch64 hotspot:tier1 >> mach5: tiers 1-5 > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 8305590: Remove nothrow exception specifications from operator new This is a nice cleanup. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13498#pullrequestreview-1394563701 From coleenp at openjdk.org Thu Apr 20 18:39:50 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 20 Apr 2023 18:39:50 GMT Subject: RFR: 8305590: Remove nothrow exception specifications from operator new [v2] In-Reply-To: <4x0Wm39zfuJNcoQ5PCnW_7coiE5AqQRVMSYqKFW-KUc=.ffc385ac-9baf-4f6d-a65c-9443b495fcd5@github.com> References: <619AH3LBFaBdG1odgp4kpuCjm6ujfOivOUtoDYHdhCw=.96e5693b-e8c1-4923-88e4-11715889b822@github.com> <4mSYzcXKe-qzoXuUBeKHw6nzxEewqPXPkfeZ1kTExHQ=.adb1f609-ffad-43c7-9067-c9fdbeea4071@github.com> <4x0Wm39zfuJNcoQ5PCnW_7coiE5AqQRVMSYqKFW-KUc=.ffc385ac-9baf-4f6d-a65c-9443b495fcd5@github.com> Message-ID: On Thu, 20 Apr 2023 08:36:53 GMT, Afshin Zafari wrote: >> JVMTI does not abort on OOM it reports an error, so we definitely do not want a terminating allocator! >> >> jvmtiError >> JvmtiEnv::CreateRawMonitor(const char* name, jrawMonitorID* monitor_ptr) { >> JvmtiRawMonitor* rmonitor = new JvmtiRawMonitor(name); >> NULL_CHECK(rmonitor, JVMTI_ERROR_OUT_OF_MEMORY); > > The new operator is removed. We decide this at the call site though by adding the nothrow parameter. Adding an overloaded operator new without a nothrow parameter that we're not supposed to call seems very marginally useful. ie not useful. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13498#discussion_r1172958617 From lmesnik at openjdk.org Thu Apr 20 18:40:52 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 20 Apr 2023 18:40:52 GMT Subject: RFR: 8233725: ProcessTools.startProcess() has output issues when using an OutputAnalyzer at the same time [v2] In-Reply-To: References: Message-ID: > ProcessTools.startProcess() creates process and read it's output error streams. So the any other using of corresponding Process.getInputStream() and Process.getErrorStream() doesn't get process streams. > > This fix preserve process streams content and allow to read it after process completion. The another possible solution would be to throw exception when user tries to read already drained streams to fail tests earlier. However it complicates usage of ProcessTools.startProcess() methods. > > The regression test has been provided with issue. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: JStackStressTest.java updated. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13560/files - new: https://git.openjdk.org/jdk/pull/13560/files/c1534166..38d82fa5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13560&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13560&range=00-01 Stats: 3 lines in 1 file changed: 1 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13560.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13560/head:pull/13560 PR: https://git.openjdk.org/jdk/pull/13560 From matsaave at openjdk.org Thu Apr 20 19:03:45 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Thu, 20 Apr 2023 19:03:45 GMT Subject: RFR: 8306482: Remove unused Method AccessFlags In-Reply-To: References: Message-ID: On Thu, 20 Apr 2023 00:35:06 GMT, Coleen Phillimore wrote: > Please review this small change to remove Method AccessFlags that are unused. These flags were moved to ConstMethod a long time ago. > Tested with tier1-4, SA tests locally Nice cleanup, LGTM! ------------- Marked as reviewed by matsaave (Committer). PR Review: https://git.openjdk.org/jdk/pull/13549#pullrequestreview-1394595045 From coleenp at openjdk.org Thu Apr 20 19:16:52 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 20 Apr 2023 19:16:52 GMT Subject: RFR: 8306482: Remove unused Method AccessFlags In-Reply-To: References: Message-ID: On Thu, 20 Apr 2023 00:35:06 GMT, Coleen Phillimore wrote: > Please review this small change to remove Method AccessFlags that are unused. These flags were moved to ConstMethod a long time ago. > Tested with tier1-4, SA tests locally Thanks David and Matias. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13549#issuecomment-1516819018 From coleenp at openjdk.org Thu Apr 20 19:16:53 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 20 Apr 2023 19:16:53 GMT Subject: Integrated: 8306482: Remove unused Method AccessFlags In-Reply-To: References: Message-ID: On Thu, 20 Apr 2023 00:35:06 GMT, Coleen Phillimore wrote: > Please review this small change to remove Method AccessFlags that are unused. These flags were moved to ConstMethod a long time ago. > Tested with tier1-4, SA tests locally This pull request has now been integrated. Changeset: afd2501f Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/afd2501fcc9f8ccb4993a6565d68b882e5130688 Stats: 27 lines in 4 files changed: 0 ins; 27 del; 0 mod 8306482: Remove unused Method AccessFlags Reviewed-by: dholmes, matsaave ------------- PR: https://git.openjdk.org/jdk/pull/13549 From coleenp at openjdk.org Thu Apr 20 19:23:04 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 20 Apr 2023 19:23:04 GMT Subject: RFR: 8306474: Move InstanceKlass read-only flags [v2] In-Reply-To: References: Message-ID: On Thu, 20 Apr 2023 00:27:20 GMT, Coleen Phillimore wrote: >> Moved three read-only InstanceKlass flags out of AccessFlags to InstanceKlassFlags, and removed unused and unneeded SA code. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > John's suggestion Thanks John and David. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13545#issuecomment-1516825031 From coleenp at openjdk.org Thu Apr 20 19:23:06 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 20 Apr 2023 19:23:06 GMT Subject: Integrated: 8306474: Move InstanceKlass read-only flags In-Reply-To: References: Message-ID: On Wed, 19 Apr 2023 22:46:55 GMT, Coleen Phillimore wrote: > Moved three read-only InstanceKlass flags out of AccessFlags to InstanceKlassFlags, and removed unused and unneeded SA code. > Tested with tier1-4. This pull request has now been integrated. Changeset: f6336231 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/f63362310e17ba5c3e415ef3c5bd5f9bd65fd67c Stats: 45 lines in 10 files changed: 12 ins; 26 del; 7 mod 8306474: Move InstanceKlass read-only flags Reviewed-by: jrose, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/13545 From cjplummer at openjdk.org Thu Apr 20 22:35:47 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 20 Apr 2023 22:35:47 GMT Subject: RFR: 8233725: ProcessTools.startProcess() has output issues when using an OutputAnalyzer at the same time [v2] In-Reply-To: References: Message-ID: <-G9WskHyBL-VvD-95BHoWsSn9cSiQc5mpUayH2_rUBM=.638204df-fa19-4c70-b51e-d4c7b1eb8290@github.com> On Thu, 20 Apr 2023 18:40:52 GMT, Leonid Mesnik wrote: >> ProcessTools.startProcess() creates process and read it's output error streams. So the any other using of corresponding Process.getInputStream() and Process.getErrorStream() doesn't get process streams. >> >> This fix preserve process streams content and allow to read it after process completion. The another possible solution would be to throw exception when user tries to read already drained streams to fail tests earlier. However it complicates usage of ProcessTools.startProcess() methods. >> >> The regression test has been provided with issue. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > JStackStressTest.java updated. test/jdk/sun/tools/jhsdb/JStackStressTest.java line 86: > 84: } catch (InterruptedException e) { > 85: } > 86: OutputAnalyzer jshellOutput = new OutputAnalyzer(jShellProcess); It's not clear to me how moving this is fixing anything. test/jdk/sun/tools/jstatd/JstatdTest.java line 357: > 355: assertEquals(stdout.size(), 1, "Output should contain one line"); > 356: assertTrue(stdout.get(0).startsWith("jstatd started"), "List should start with 'jstatd started'"); > 357: assertNotEquals(output.getExitValue(), 0, Before your fix, was the "jstatd started" line being missed because of this bug. test/lib/jdk/test/lib/process/ProcessTools.java line 750: > 748: public InputStream getInputStream() { > 749: try { > 750: waitFor(); With this added `waitFor()` the assumption now is that the caller doesn't intent to do incremental reads of the output as the process generates it. For example, if the test were to send some command to the process and then want to read the resulting output, and do this repeatedly, it won't able to use the InputStream to do that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13560#discussion_r1173141642 PR Review Comment: https://git.openjdk.org/jdk/pull/13560#discussion_r1173139688 PR Review Comment: https://git.openjdk.org/jdk/pull/13560#discussion_r1173146951 From iklam at openjdk.org Thu Apr 20 22:41:45 2023 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 20 Apr 2023 22:41:45 GMT Subject: RFR: 8298048: Combine CDS archive heap into a single block [v8] In-Reply-To: References: Message-ID: > This PR combines the "open" and "closed" regions of the CDS archive heap into a single region. This significantly simplifies the implementation, making it more compatible with non-G1 collectors. There's a net removal of ~1000 lines in src code and another ~1200 lines of tests. > > **Notes for reviewers:** > - Most of the code changes in CDS are removing the handling of "open" vs "closed" objects. > - Reviewers can start with ArchiveHeapWriter::copy_source_objs_to_buffer(). > - It might be easier to see the diff with whitespaces off. > - There are two major changes in the G1 code > - The archived objects are now stored in the "old" region (see g1CollectedHeap.cpp in [58d720e](https://github.com/openjdk/jdk/pull/13284/commits/58d720e294bb36f21cb88cddde724ed2b9e93770)) > - The majority of the other changes are removal of the "archive" region type (see heapRegionType.hpp). For ease of review, such code is isolated in [a852dfb](https://github.com/openjdk/jdk/pull/13284/commits/a852dfbbf5ff56e035399f7cc3704f29e76697f6) > - Testing changes: > - Now the archived java objects can move, along with the "old" regions that contain them. It's no longer possible to test whether a heap object came from CDS. As a result, the `WhiteBox.isShared(Object o)` API has been removed. > - Many tests that uses this API are removed. Most of them were written during early development of CDS archived objects and are no longer relevant. > > **Testing:** > - Mach5 tiers 1 ~ 7 Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: - Merge branch 'master' into 8298048-combine-cds-heap-to-single-region-PUSH - Merge branch 'master' into 8298048-combine-cds-heap-to-single-region-PUSH - Fixed assert in runtime/cds/appcds/SharedArchiveConsistency.java - Removal of JFR custom closed/open archive region types - Remove g1 full gc skip marking optimization - Some comment updates - Move g1collectedheap archive related regions together in the cpp file - Factor out region/range iteration - Fix comment - Ioi fix - ... and 12 more: https://git.openjdk.org/jdk/compare/f6336231...e8041d50 ------------- Changes: https://git.openjdk.org/jdk/pull/13284/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13284&range=07 Stats: 3252 lines in 83 files changed: 159 ins; 2446 del; 647 mod Patch: https://git.openjdk.org/jdk/pull/13284.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13284/head:pull/13284 PR: https://git.openjdk.org/jdk/pull/13284 From dholmes at openjdk.org Thu Apr 20 22:57:45 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 20 Apr 2023 22:57:45 GMT Subject: RFR: 8233725: ProcessTools.startProcess() has output issues when using an OutputAnalyzer at the same time [v2] In-Reply-To: <-G9WskHyBL-VvD-95BHoWsSn9cSiQc5mpUayH2_rUBM=.638204df-fa19-4c70-b51e-d4c7b1eb8290@github.com> References: <-G9WskHyBL-VvD-95BHoWsSn9cSiQc5mpUayH2_rUBM=.638204df-fa19-4c70-b51e-d4c7b1eb8290@github.com> Message-ID: On Thu, 20 Apr 2023 22:31:55 GMT, Chris Plummer wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> JStackStressTest.java updated. > > test/lib/jdk/test/lib/process/ProcessTools.java line 750: > >> 748: public InputStream getInputStream() { >> 749: try { >> 750: waitFor(); > > With this added `waitFor()` the assumption now is that the caller doesn't intent to do incremental reads of the output as the process generates it. For example, if the test were to send some command to the process and then want to read the resulting output, and do this repeatedly, it won't able to use the InputStream to do that. I have to agree with Chris. You are changing a fundamental property of this API. We no longer just start the process, we are forced to wait for it to complete. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13560#discussion_r1173158259 From lmesnik at openjdk.org Thu Apr 20 23:05:45 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 20 Apr 2023 23:05:45 GMT Subject: RFR: 8233725: ProcessTools.startProcess() has output issues when using an OutputAnalyzer at the same time [v2] In-Reply-To: <-G9WskHyBL-VvD-95BHoWsSn9cSiQc5mpUayH2_rUBM=.638204df-fa19-4c70-b51e-d4c7b1eb8290@github.com> References: <-G9WskHyBL-VvD-95BHoWsSn9cSiQc5mpUayH2_rUBM=.638204df-fa19-4c70-b51e-d4c7b1eb8290@github.com> Message-ID: On Thu, 20 Apr 2023 22:22:06 GMT, Chris Plummer wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> JStackStressTest.java updated. > > test/jdk/sun/tools/jhsdb/JStackStressTest.java line 86: > >> 84: } catch (InterruptedException e) { >> 85: } >> 86: OutputAnalyzer jshellOutput = new OutputAnalyzer(jShellProcess); > > It's not clear to me how moving this is fixing anything. It is the main issues with current approach. The outputanalyzer tries to read from streams which are available only when process finishes. This test interact with process so it just hangs waiting of process completion. > test/jdk/sun/tools/jstatd/JstatdTest.java line 357: > >> 355: assertEquals(stdout.size(), 1, "Output should contain one line"); >> 356: assertTrue(stdout.get(0).startsWith("jstatd started"), "List should start with 'jstatd started'"); >> 357: assertNotEquals(output.getExitValue(), 0, > > Before your fix, was the "jstatd started" line being missed because of this bug. Yep. the output was "empty" before fix. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13560#discussion_r1173155279 PR Review Comment: https://git.openjdk.org/jdk/pull/13560#discussion_r1173155433 From lmesnik at openjdk.org Thu Apr 20 23:05:48 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 20 Apr 2023 23:05:48 GMT Subject: RFR: 8233725: ProcessTools.startProcess() has output issues when using an OutputAnalyzer at the same time [v2] In-Reply-To: References: <-G9WskHyBL-VvD-95BHoWsSn9cSiQc5mpUayH2_rUBM=.638204df-fa19-4c70-b51e-d4c7b1eb8290@github.com> Message-ID: <_dsCvusmXp4WGZ-9RZiihf92Rqd0_lX-udKls-ZGKnE=.6c09a4d0-e5ae-4676-89c3-9206213d4628@github.com> On Thu, 20 Apr 2023 22:54:49 GMT, David Holmes wrote: >> test/lib/jdk/test/lib/process/ProcessTools.java line 750: >> >>> 748: public InputStream getInputStream() { >>> 749: try { >>> 750: waitFor(); >> >> With this added `waitFor()` the assumption now is that the caller doesn't intent to do incremental reads of the output as the process generates it. For example, if the test were to send some command to the process and then want to read the resulting output, and do this repeatedly, it won't able to use the InputStream to do that. > > I have to agree with Chris. You are changing a fundamental property of this API. We no longer just start the process, we are forced to wait for it to complete. Exactly. I added note about implementation in the javadoc to make it clear. I don't see any good solution for this problem. The only other possible solution which I see is to throw Exception here, forcing user to use lineConsumer. However the any usage of OutputAnalyzer with startProcess() would clearly and quickly fails. Also, the public static Process startProcess(String name, ProcessBuilder processBuilder) could be modified to allow to read process streams. The test should drain tests by itself in such case to avoid hang. However, it don't see any good way to implement this method correctly if already read the process streams. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13560#discussion_r1173161520 From duke at openjdk.org Fri Apr 21 02:37:04 2023 From: duke at openjdk.org (SUN Guoyun) Date: Fri, 21 Apr 2023 02:37:04 GMT Subject: RFR: 8301995: Move invokedynamic resolution information out of ConstantPoolCacheEntry [v16] In-Reply-To: <5YPjVZsQAVVL9PHaGu7Mc7kNE0WvPrsiCubKSGzKxvk=.78e8f8fb-1005-4bd7-9ad1-d1dd3aacbe04@github.com> References: <5YPjVZsQAVVL9PHaGu7Mc7kNE0WvPrsiCubKSGzKxvk=.78e8f8fb-1005-4bd7-9ad1-d1dd3aacbe04@github.com> Message-ID: <3rkPRibD2-ZVCzw62DT1EpmeoHaeLBhIFuOClAXRGvE=.85f13a21-bdbd-4cad-88fc-d3c704a6c2ae@github.com> On Tue, 28 Mar 2023 19:50:36 GMT, Matias Saavedra Silva wrote: >> The current structure used to store the resolution information for invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its ambigious fields f1 and f2. This structure can hold information for fields, methods, and invokedynamics and each of its fields can hold different types of values depending on the entry. >> >> This enhancement proposes a new structure to exclusively contain invokedynamic information in a manner that is easy to interpret and easy to extend. Resolved invokedynamic entries will be stored in an array in the constant pool cache and the operand of the invokedynamic bytecode will be rewritten to be the index into this array. >> >> Any areas that previously accessed invokedynamic data from ConstantPoolCacheEntry will be replaced with accesses to this new array and structure. Verified with tier1-9 tests. >> >> The PPC port was provided by @reinrich, RISCV was provided by @DingliZhang and @zifeihan, and S390x by @offamitkumar. >> >> This change supports the following platforms: x86, aarch64, PPC, RISCV, and S390x > > Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: > > s390x NULL to nullptr src/hotspot/cpu/riscv/templateTable_riscv.cpp line 2233: > 2231: > 2232: __ load_resolved_indy_entry(cache, index); > 2233: __ membar(MacroAssembler::AnyAny); Why is the AnyAny barrier used here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12778#discussion_r1173246912 From lmesnik at openjdk.org Fri Apr 21 04:45:04 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 21 Apr 2023 04:45:04 GMT Subject: Withdrawn: 8233725: ProcessTools.startProcess() has output issues when using an OutputAnalyzer at the same time In-Reply-To: References: Message-ID: On Thu, 20 Apr 2023 16:09:29 GMT, Leonid Mesnik wrote: > ProcessTools.startProcess() creates process and read it's output error streams. So the any other using of corresponding Process.getInputStream() and Process.getErrorStream() doesn't get process streams. > > This fix preserve process streams content and allow to read it after process completion. The another possible solution would be to throw exception when user tries to read already drained streams to fail tests earlier. However it complicates usage of ProcessTools.startProcess() methods. > > The regression test has been provided with issue. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/13560 From sspitsyn at openjdk.org Fri Apr 21 06:08:43 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 21 Apr 2023 06:08:43 GMT Subject: RFR: 8306034: add support of virtual threads to JVMTI StopThread [v2] In-Reply-To: <70mPVNX3n2TUacbWW0JDIfTNEACwzppdyY5PzYZxdRY=.749a3e99-be99-45ab-a688-e9c563dd5182@github.com> References: <70mPVNX3n2TUacbWW0JDIfTNEACwzppdyY5PzYZxdRY=.749a3e99-be99-45ab-a688-e9c563dd5182@github.com> Message-ID: On Thu, 20 Apr 2023 18:17:19 GMT, Alan Bateman wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> addressed review comments on new test > > src/hotspot/share/prims/jvmtiEnv.cpp line 1197: > >> 1195: if (is_virtual && !is_JavaThread_current(java_thread, thread_oop)) { >> 1196: if (!JvmtiVTSuspender::is_vthread_suspended(thread_oop)) { >> 1197: return JVMTI_ERROR_THREAD_NOT_SUSPENDED; > > Does JvmtiVTSuspender::is_vthread_suspended work for the alternative virtual thread implementation (-XX:+VMContinuations)? Nice catch - fixed now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13546#discussion_r1173336527 From dholmes at openjdk.org Fri Apr 21 06:40:58 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 21 Apr 2023 06:40:58 GMT Subject: RFR: 8306034: add support of virtual threads to JVMTI StopThread [v2] In-Reply-To: References: Message-ID: On Thu, 20 Apr 2023 16:40:48 GMT, Serguei Spitsyn wrote: >> This enhancement adds support of virtual threads to the JVMTI `StopThread` function. >> In preview releases before this enhancement the StopThread returned the JVMTI_ERROR_UNSUPPORTED_OPERATION error code for virtual threads. >> >> The `StopThread` supports sending an asynchronous exception to a virtual thread only if it is current or suspended at mounted state. For instance, a virtual thread can be suspended at a JVMTI event. If the virtual thread is not suspended and is not current then the `JVMTI_ERROR_THREAD_NOT_SUSPENDED` error code is returned. If the virtual thread was suspended at unmounted state then the `JVMTI_ERROR_OPAQUE_FRAME` error code is returned. >> >> The `StopThread` has the following description for `JVMTI_ERROR_OPAQUE_FRAME` error code: >>> The thread is a suspended virtual thread and the implementation >>> was unable to throw an asynchronous exception from this frame. >> >> A couple of the `serviceability/jvmti/vthread` tests has been updated to adopt to new `StopThread` behavior. >> >> The CSR is: https://bugs.openjdk.org/browse/JDK-8306434 >> >> Testing: >> The mach5 tears 1-6 are in progress. >> Preliminary test runs were good in general. >> The JDB test `vmTestbase/nsk/jdb/kill/kill001/kill001.java` has been problem-listed and will be fixed by the corresponding debugger enhancement which is going to adopt JDWP/JDI specs to new behavior of the JVMTI `StopThread` related to virtual threads. >> >> Also, two JCK JVMTI tests are failing in the tier-6 : >>> vm/jvmti/StopThread/stop001/stop00103/stop00103.html >>> vm/jvmti/StopThread/stop001/stop00103/stop00103a.html >> >> These two tests will be excluded from the test runs by the JCK team and then adjusted to new `StopThread` behavior. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > addressed review comments on new test src/hotspot/share/prims/jvmtiEnv.cpp line 1200: > 1198: } > 1199: if (java_thread == nullptr) { // unmounted virtual thread > 1200: return JVMTI_ERROR_OPAQUE_FRAME; Where is the check for "suspended at an event" that otherwise results in `JVMTI_ERROR_OPAQUE_FRAME`? test/hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest/StopThreadTest.java line 33: > 31: * Its method run() invokes the following methods: > 32: * - method A() that is blocked on a monitor > 33: * - method B() that is stopped at a brakepoint s/brakepoint/breakpoint/ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13546#discussion_r1173352162 PR Review Comment: https://git.openjdk.org/jdk/pull/13546#discussion_r1173356185 From fjiang at openjdk.org Fri Apr 21 06:43:06 2023 From: fjiang at openjdk.org (Feilong Jiang) Date: Fri, 21 Apr 2023 06:43:06 GMT Subject: RFR: 8301995: Move invokedynamic resolution information out of ConstantPoolCacheEntry [v16] In-Reply-To: <3rkPRibD2-ZVCzw62DT1EpmeoHaeLBhIFuOClAXRGvE=.85f13a21-bdbd-4cad-88fc-d3c704a6c2ae@github.com> References: <5YPjVZsQAVVL9PHaGu7Mc7kNE0WvPrsiCubKSGzKxvk=.78e8f8fb-1005-4bd7-9ad1-d1dd3aacbe04@github.com> <3rkPRibD2-ZVCzw62DT1EpmeoHaeLBhIFuOClAXRGvE=.85f13a21-bdbd-4cad-88fc-d3c704a6c2ae@github.com> Message-ID: <4UK8s-Hj57YFE1RKMi5LiA-ZuvTn2-cQ7uPZRASZF_E=.1ade79d2-3e3f-486b-8ac2-8dc459f42ffc@github.com> On Fri, 21 Apr 2023 02:33:37 GMT, SUN Guoyun wrote: >> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision: >> >> s390x NULL to nullptr > > src/hotspot/cpu/riscv/templateTable_riscv.cpp line 2233: > >> 2231: >> 2232: __ load_resolved_indy_entry(cache, index); >> 2233: __ membar(MacroAssembler::AnyAny); > > Why is the AnyAny barrier used here? Hi @sunny868, I'm working on removing these unnecessary barriers. RISC-V port uses more conservative barriers like this for some reasons (e.g.: [1][2][3]), we can just remove them. 1. https://github.com/openjdk/jdk/blob/36ec05d52a79185d8c6669713fd17933128c032a/src/hotspot/cpu/riscv/templateTable_riscv.cpp#L3438-L3443 2. https://github.com/openjdk/jdk/blob/36ec05d52a79185d8c6669713fd17933128c032a/src/hotspot/cpu/riscv/templateTable_riscv.cpp#L3558-L3563 3. https://github.com/openjdk/jdk/blob/36ec05d52a79185d8c6669713fd17933128c032a/src/hotspot/cpu/riscv/templateTable_riscv.cpp#L3614-L3619 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/12778#discussion_r1173362912 From sspitsyn at openjdk.org Fri Apr 21 07:51:48 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 21 Apr 2023 07:51:48 GMT Subject: RFR: 8306034: add support of virtual threads to JVMTI StopThread [v2] In-Reply-To: References: Message-ID: On Fri, 21 Apr 2023 06:31:52 GMT, David Holmes wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> addressed review comments on new test > > test/hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest/StopThreadTest.java line 33: > >> 31: * Its method run() invokes the following methods: >> 32: * - method A() that is blocked on a monitor >> 33: * - method B() that is stopped at a brakepoint > > s/brakepoint/breakpoint/ Thanks, fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13546#discussion_r1173437781 From sspitsyn at openjdk.org Fri Apr 21 08:03:47 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 21 Apr 2023 08:03:47 GMT Subject: RFR: 8306034: add support of virtual threads to JVMTI StopThread [v2] In-Reply-To: References: Message-ID: On Fri, 21 Apr 2023 06:26:33 GMT, David Holmes wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> addressed review comments on new test > > src/hotspot/share/prims/jvmtiEnv.cpp line 1200: > >> 1198: } >> 1199: if (java_thread == nullptr) { // unmounted virtual thread >> 1200: return JVMTI_ERROR_OPAQUE_FRAME; > > Where is the check for "suspended at an event" that otherwise results in `JVMTI_ERROR_OPAQUE_FRAME`? The JVMTI `StopThread` spec has this description: > The StopThread function may be used to send an asynchronous > exception to a virtual thread when it is suspended at an event. > An implementation may support sending an asynchronous exception > to a suspended virtual thread in other cases. > . . . > JVMTI_ERROR_OPAQUE_FRAME: > The thread is a suspended virtual thread and the implementation > was unable to throw an asynchronous exception from this frame. This update supports all suspended mounted cases of virtual threads and returns OPAQUE_FRAME only if the target virtual thread is suspended and unmounted. But we avoid using the mount/unmount terms in the JVMTI spec. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13546#discussion_r1173451827 From sspitsyn at openjdk.org Fri Apr 21 08:09:55 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 21 Apr 2023 08:09:55 GMT Subject: RFR: 8306034: add support of virtual threads to JVMTI StopThread [v3] In-Reply-To: References: Message-ID: > This enhancement adds support of virtual threads to the JVMTI `StopThread` function. > In preview releases before this enhancement the StopThread returned the JVMTI_ERROR_UNSUPPORTED_OPERATION error code for virtual threads. > > The `StopThread` supports sending an asynchronous exception to a virtual thread only if it is current or suspended at mounted state. For instance, a virtual thread can be suspended at a JVMTI event. If the virtual thread is not suspended and is not current then the `JVMTI_ERROR_THREAD_NOT_SUSPENDED` error code is returned. If the virtual thread was suspended at unmounted state then the `JVMTI_ERROR_OPAQUE_FRAME` error code is returned. > > The `StopThread` has the following description for `JVMTI_ERROR_OPAQUE_FRAME` error code: >> The thread is a suspended virtual thread and the implementation >> was unable to throw an asynchronous exception from this frame. > > A couple of the `serviceability/jvmti/vthread` tests has been updated to adopt to new `StopThread` behavior. > > The CSR is: https://bugs.openjdk.org/browse/JDK-8306434 > > Testing: > The mach5 tears 1-6 are in progress. > Preliminary test runs were good in general. > The JDB test `vmTestbase/nsk/jdb/kill/kill001/kill001.java` has been problem-listed and will be fixed by the corresponding debugger enhancement which is going to adopt JDWP/JDI specs to new behavior of the JVMTI `StopThread` related to virtual threads. > > Also, two JCK JVMTI tests are failing in the tier-6 : >> vm/jvmti/StopThread/stop001/stop00103/stop00103.html >> vm/jvmti/StopThread/stop001/stop00103/stop00103a.html > > These two tests will be excluded from the test runs by the JCK team and then adjusted to new `StopThread` behavior. Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: corrections for BoundVirtualThread and test typos ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13546/files - new: https://git.openjdk.org/jdk/pull/13546/files/0b26f42c..d2cc010e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13546&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13546&range=01-02 Stats: 20 lines in 4 files changed: 16 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13546.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13546/head:pull/13546 PR: https://git.openjdk.org/jdk/pull/13546 From duke at openjdk.org Fri Apr 21 09:54:47 2023 From: duke at openjdk.org (Afshin Zafari) Date: Fri, 21 Apr 2023 09:54:47 GMT Subject: RFR: 8305590: Remove nothrow exception specifications from operator new [v3] In-Reply-To: <5uZmZV3ssLzKKFBeajmWUBmZsaZeq-3ImeHkzCvnSwg=.4941a9c0-b250-4290-828a-15416ed791df@github.com> References: <5uZmZV3ssLzKKFBeajmWUBmZsaZeq-3ImeHkzCvnSwg=.4941a9c0-b250-4290-828a-15416ed791df@github.com> Message-ID: On Thu, 20 Apr 2023 08:41:58 GMT, Afshin Zafari wrote: >> - The `throw()` (i.e., no throw) specifications are removed from the instances of `operator new` where _do not_ return `nullptr`. >> >> - The `-fcheck-new` is removed from the gcc compile flags. >> >> - The `operator new` and `operator delete` are deleted from `StackObj`. >> >> - The `GrowableArrayCHeap::operator delete` is added to be matched with its corresponding allocation`AnyObj::operator new`, because gcc complains on that after removing the `-fcheck-new` flag. >> - The `Thread::operator new`with and without `null` return are removed. >> >> ### Tests >> local: linux-x64 gtest:GrowableArrayCHeap, macosx-aarch64 hotspot:tier1 >> mach5: tiers 1-5 > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 8305590: Remove nothrow exception specifications from operator new Thanks for the reviews and the helpful discussions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13498#issuecomment-1517574843 From dholmes at openjdk.org Fri Apr 21 13:12:51 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 21 Apr 2023 13:12:51 GMT Subject: RFR: 8306034: add support of virtual threads to JVMTI StopThread [v2] In-Reply-To: References: Message-ID: On Fri, 21 Apr 2023 07:58:45 GMT, Serguei Spitsyn wrote: >> src/hotspot/share/prims/jvmtiEnv.cpp line 1200: >> >>> 1198: } >>> 1199: if (java_thread == nullptr) { // unmounted virtual thread >>> 1200: return JVMTI_ERROR_OPAQUE_FRAME; >> >> Where is the check for "suspended at an event" that otherwise results in `JVMTI_ERROR_OPAQUE_FRAME`? > > The JVMTI `StopThread` spec has this description: >> The StopThread function may be used to send an asynchronous >> exception to a virtual thread when it is suspended at an event. >> An implementation may support sending an asynchronous exception >> to a suspended virtual thread in other cases. >> . . . >> JVMTI_ERROR_OPAQUE_FRAME: >> The thread is a suspended virtual thread and the implementation >> was unable to throw an asynchronous exception from this frame. > > This update supports all suspended mounted cases of virtual threads and returns OPAQUE_FRAME only if the target virtual thread is suspended and unmounted. > But we avoid using the mount/unmount terms in the JVMTI spec. What does "suspended at an event" mean? As a programmer trying to use this how am I supposed to know when it can be used without getting an error? I find it very surprising that the error would occur with an unmounted thread - having a VT throw when it was remounted seems the most natural way to implement this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13546#discussion_r1173749491 From alanb at openjdk.org Fri Apr 21 13:38:43 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 21 Apr 2023 13:38:43 GMT Subject: RFR: 8306034: add support of virtual threads to JVMTI StopThread [v2] In-Reply-To: References: Message-ID: On Fri, 21 Apr 2023 13:09:58 GMT, David Holmes wrote: >> The JVMTI `StopThread` spec has this description: >>> The StopThread function may be used to send an asynchronous >>> exception to a virtual thread when it is suspended at an event. >>> An implementation may support sending an asynchronous exception >>> to a suspended virtual thread in other cases. >>> . . . >>> JVMTI_ERROR_OPAQUE_FRAME: >>> The thread is a suspended virtual thread and the implementation >>> was unable to throw an asynchronous exception from this frame. >> >> This update supports all suspended mounted cases of virtual threads and returns OPAQUE_FRAME only if the target virtual thread is suspended and unmounted. >> But we avoid using the mount/unmount terms in the JVMTI spec. > > What does "suspended at an event" mean? As a programmer trying to use this how am I supposed to know when it can be used without getting an error? > > I find it very surprising that the error would occur with an unmounted thread - having a VT throw when it was remounted seems the most natural way to implement this. I think "suspended at an event" is okay. It means the callback for an event has been triggered and the agent suspended the thread. The typical use-case for JVMTI StopThread is when at a breakpoint or when single stepping and the user asks the debugger to throw some exception so that the code's handling of the exception can been debugged/tested. Debugger and JDWP agent aside, I don't know if there are other agents using this JVMTI function. If there are other and they call this function on some random virtual thread at some random time then the function will fail. One other point around this is that the plan is to have StopThread, ForceEarlyReturn, PopFrame and SetLocalXXX work more consistently. Right now, SetLocalXXX minimally requires a virtual thread be suspended at a breakpoint or single step event. The minimum support can be broader to be suspended at any event. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13546#discussion_r1173774433 From iklam at openjdk.org Fri Apr 21 15:33:00 2023 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 21 Apr 2023 15:33:00 GMT Subject: Integrated: 8298048: Combine CDS archive heap into a single block In-Reply-To: References: Message-ID: On Mon, 3 Apr 2023 03:32:27 GMT, Ioi Lam wrote: > This PR combines the "open" and "closed" regions of the CDS archive heap into a single region. This significantly simplifies the implementation, making it more compatible with non-G1 collectors. There's a net removal of ~1100 lines in src code and another ~1200 lines of tests. > > **Notes for reviewers:** > - Most of the code changes in CDS are removing the handling of "open" vs "closed" objects. > - Reviewers can start with ArchiveHeapWriter::copy_source_objs_to_buffer(). > - It might be easier to see the diff with whitespaces off. > - There are two major changes in the G1 code > - The archived objects are now stored in the "old" region (see g1CollectedHeap.cpp in [58d720e](https://github.com/openjdk/jdk/pull/13284/commits/58d720e294bb36f21cb88cddde724ed2b9e93770)) > - The majority of the other changes are removal of the "archive" region type (see heapRegionType.hpp). For ease of review, such code is isolated in [a852dfb](https://github.com/openjdk/jdk/pull/13284/commits/a852dfbbf5ff56e035399f7cc3704f29e76697f6) > - Testing changes: > - Now the archived java objects can move, along with the "old" regions that contain them. It's no longer possible to test whether a heap object came from CDS. As a result, the `WhiteBox.isShared(Object o)` API has been removed. > - Many tests that uses this API are removed. Most of them were written during early development of CDS archived objects and are no longer relevant. > > **Testing:** > - Mach5 tiers 1 ~ 7 This pull request has now been integrated. Changeset: 723037a7 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/723037a79d2a43b9a1a247d8f81a47907faadab1 Stats: 3252 lines in 83 files changed: 159 ins; 2446 del; 647 mod 8298048: Combine CDS archive heap into a single block Co-authored-by: Thomas Schatzl Reviewed-by: matsaave, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/13284 From iklam at openjdk.org Fri Apr 21 15:32:59 2023 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 21 Apr 2023 15:32:59 GMT Subject: RFR: 8298048: Combine CDS archive heap into a single block In-Reply-To: <3ybhZpVsw5iki0H2OkFswEIqFfEFC0YwNhp9chzu5yU=.8b29a446-3be0-4ae8-a8d0-948003be0411@github.com> References: <3ybhZpVsw5iki0H2OkFswEIqFfEFC0YwNhp9chzu5yU=.8b29a446-3be0-4ae8-a8d0-948003be0411@github.com> Message-ID: On Tue, 11 Apr 2023 21:47:40 GMT, Ashutosh Mehra wrote: >> This PR combines the "open" and "closed" regions of the CDS archive heap into a single region. This significantly simplifies the implementation, making it more compatible with non-G1 collectors. There's a net removal of ~1100 lines in src code and another ~1200 lines of tests. >> >> **Notes for reviewers:** >> - Most of the code changes in CDS are removing the handling of "open" vs "closed" objects. >> - Reviewers can start with ArchiveHeapWriter::copy_source_objs_to_buffer(). >> - It might be easier to see the diff with whitespaces off. >> - There are two major changes in the G1 code >> - The archived objects are now stored in the "old" region (see g1CollectedHeap.cpp in [58d720e](https://github.com/openjdk/jdk/pull/13284/commits/58d720e294bb36f21cb88cddde724ed2b9e93770)) >> - The majority of the other changes are removal of the "archive" region type (see heapRegionType.hpp). For ease of review, such code is isolated in [a852dfb](https://github.com/openjdk/jdk/pull/13284/commits/a852dfbbf5ff56e035399f7cc3704f29e76697f6) >> - Testing changes: >> - Now the archived java objects can move, along with the "old" regions that contain them. It's no longer possible to test whether a heap object came from CDS. As a result, the `WhiteBox.isShared(Object o)` API has been removed. >> - Many tests that uses this API are removed. Most of them were written during early development of CDS archived objects and are no longer relevant. >> >> **Testing:** >> - Mach5 tiers 1 ~ 7 > > cds changes look good! just few nitpicks. Thanks @ashu-mehra @matias9927 @tschatzl for the code review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13284#issuecomment-1518001489 From cjplummer at openjdk.org Fri Apr 21 16:42:49 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 21 Apr 2023 16:42:49 GMT Subject: RFR: 8306034: add support of virtual threads to JVMTI StopThread [v3] In-Reply-To: References: Message-ID: On Fri, 21 Apr 2023 08:09:55 GMT, Serguei Spitsyn wrote: >> This enhancement adds support of virtual threads to the JVMTI `StopThread` function. >> In preview releases before this enhancement the StopThread returned the JVMTI_ERROR_UNSUPPORTED_OPERATION error code for virtual threads. >> >> The `StopThread` supports sending an asynchronous exception to a virtual thread only if it is current or suspended at mounted state. For instance, a virtual thread can be suspended at a JVMTI event. If the virtual thread is not suspended and is not current then the `JVMTI_ERROR_THREAD_NOT_SUSPENDED` error code is returned. If the virtual thread was suspended at unmounted state then the `JVMTI_ERROR_OPAQUE_FRAME` error code is returned. >> >> The `StopThread` has the following description for `JVMTI_ERROR_OPAQUE_FRAME` error code: >>> The thread is a suspended virtual thread and the implementation >>> was unable to throw an asynchronous exception from this frame. >> >> A couple of the `serviceability/jvmti/vthread` tests has been updated to adopt to new `StopThread` behavior. >> >> The CSR is: https://bugs.openjdk.org/browse/JDK-8306434 >> >> Testing: >> The mach5 tears 1-6 are in progress. >> Preliminary test runs were good in general. >> The JDB test `vmTestbase/nsk/jdb/kill/kill001/kill001.java` has been problem-listed and will be fixed by the corresponding debugger enhancement which is going to adopt JDWP/JDI specs to new behavior of the JVMTI `StopThread` related to virtual threads. >> >> Also, two JCK JVMTI tests are failing in the tier-6 : >>> vm/jvmti/StopThread/stop001/stop00103/stop00103.html >>> vm/jvmti/StopThread/stop001/stop00103/stop00103a.html >> >> These two tests will be excluded from the test runs by the JCK team and then adjusted to new `StopThread` behavior. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > corrections for BoundVirtualThread and test typos test/hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest/StopThreadTest.java line 89: > 87: log("\nMain #A: method A() must be blocked on entering a synchronized statement"); > 88: synchronized (TestTask.lock) { > 89: testTaskThread = Thread.ofVirtual().name("TestTaskThread").start(testTask); Do we have other tests that are doing the equivalent testing on platform threads? test/hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest/StopThreadTest.java line 135: > 133: // StopThread is expected to succeed. > 134: testTask.ensureFinished(); > 135: } I don't see how this is doing any testing. Where is the stopThread(null) call? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13546#discussion_r1173970088 PR Review Comment: https://git.openjdk.org/jdk/pull/13546#discussion_r1173968926 From alanb at openjdk.org Fri Apr 21 17:15:47 2023 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 21 Apr 2023 17:15:47 GMT Subject: RFR: 8306034: add support of virtual threads to JVMTI StopThread [v2] In-Reply-To: References: <70mPVNX3n2TUacbWW0JDIfTNEACwzppdyY5PzYZxdRY=.749a3e99-be99-45ab-a688-e9c563dd5182@github.com> Message-ID: On Fri, 21 Apr 2023 06:06:16 GMT, Serguei Spitsyn wrote: >> src/hotspot/share/prims/jvmtiEnv.cpp line 1197: >> >>> 1195: if (is_virtual && !is_JavaThread_current(java_thread, thread_oop)) { >>> 1196: if (!JvmtiVTSuspender::is_vthread_suspended(thread_oop)) { >>> 1197: return JVMTI_ERROR_THREAD_NOT_SUSPENDED; >> >> Does JvmtiVTSuspender::is_vthread_suspended work for the alternative virtual thread implementation (-XX:-VMContinuations)? > > Nice catch - fixed now. Okay but JvmtiVTMSTransitionDisabler prevent the thread from being resumed for the -XX:-VMContinuations case? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13546#discussion_r1174002110 From sspitsyn at openjdk.org Fri Apr 21 18:36:46 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 21 Apr 2023 18:36:46 GMT Subject: RFR: 8306034: add support of virtual threads to JVMTI StopThread [v3] In-Reply-To: References: Message-ID: On Fri, 21 Apr 2023 16:33:06 GMT, Chris Plummer wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> corrections for BoundVirtualThread and test typos > > test/hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest/StopThreadTest.java line 135: > >> 133: // StopThread is expected to succeed. >> 134: testTask.ensureFinished(); >> 135: } > > I don't see how this is doing any testing. Where is the stopThread(null) call? The target virtual thread just continues and invokes method `C()` which sends asynchronous exception with JVMTI `StopThread` to current thread: // This method uses StopThread to send an AssertionError object to // its own thread. It is expected to succeed. static void C() { log("TestTask.C: started"); StopThreadTest.stopThread(Thread.currentThread()); log("TestTask.C: finished"); } I'll try to add a comment to make it clear. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13546#discussion_r1174062854 From sspitsyn at openjdk.org Fri Apr 21 18:44:45 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 21 Apr 2023 18:44:45 GMT Subject: RFR: 8306034: add support of virtual threads to JVMTI StopThread [v3] In-Reply-To: References: Message-ID: <7nu2pq19SIw1me07wf4RnLEVErjYF3tnNnHZNcNWRlg=.8eb78564-8a56-4f59-a692-c7f79aef6ade@github.com> On Fri, 21 Apr 2023 16:34:34 GMT, Chris Plummer wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> corrections for BoundVirtualThread and test typos > > test/hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest/StopThreadTest.java line 89: > >> 87: log("\nMain #A: method A() must be blocked on entering a synchronized statement"); >> 88: synchronized (TestTask.lock) { >> 89: testTaskThread = Thread.ofVirtual().name("TestTaskThread").start(testTask); > > Do we have other tests that are doing the equivalent testing on platform threads? Do you ask this question to check if we want to extend this test to provide coverage for platform threads as well? The support of platform threads is much simpler. The JVMTI `StopThread` never returns the `THREAD_NOT_SUSPENDED` and `OPAQUE_FRAME` error codes for platform threads. So that this kind of testing is not needed for platform threads. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13546#discussion_r1174068855 From cjplummer at openjdk.org Fri Apr 21 19:00:48 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 21 Apr 2023 19:00:48 GMT Subject: RFR: 8306034: add support of virtual threads to JVMTI StopThread [v3] In-Reply-To: <7nu2pq19SIw1me07wf4RnLEVErjYF3tnNnHZNcNWRlg=.8eb78564-8a56-4f59-a692-c7f79aef6ade@github.com> References: <7nu2pq19SIw1me07wf4RnLEVErjYF3tnNnHZNcNWRlg=.8eb78564-8a56-4f59-a692-c7f79aef6ade@github.com> Message-ID: On Fri, 21 Apr 2023 18:41:41 GMT, Serguei Spitsyn wrote: >> test/hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest/StopThreadTest.java line 89: >> >>> 87: log("\nMain #A: method A() must be blocked on entering a synchronized statement"); >>> 88: synchronized (TestTask.lock) { >>> 89: testTaskThread = Thread.ofVirtual().name("TestTaskThread").start(testTask); >> >> Do we have other tests that are doing the equivalent testing on platform threads? > > Do you ask this question to check if we want to extend this test to provide coverage for platform threads as well? > > The support of platform threads is much simpler. The JVMTI `StopThread` never returns the `THREAD_NOT_SUSPENDED` and `OPAQUE_FRAME` error codes for platform threads. So that this kind of testing is not needed for platform threads. For the JDI tests I added, I execute them in both modes, with the appropriate adjustments to account for the errors we except for virtual threads. We should be testing to make sure that StopThread works with platform threads under a variety of situations. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13546#discussion_r1174080418 From rriggs at openjdk.org Fri Apr 21 20:26:12 2023 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 21 Apr 2023 20:26:12 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v17] In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: > Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. > The enumeration values are defined to match those used in the build. > The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64` > Note that `amd64` and `x86_64` in the build are represented by `X64`. > The value of the system property `os.arch` is unchanged. > > The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). > Uses in `java.base` and a few others are included but other modules will be done in separate PRs. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Correct comment on isPPC64() and refer to isLittleEndian() instead of mentioning PPC64LE ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13357/files - new: https://git.openjdk.org/jdk/pull/13357/files/b95a312d..accf67f9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13357&range=15-16 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13357.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13357/head:pull/13357 PR: https://git.openjdk.org/jdk/pull/13357 From cjplummer at openjdk.org Fri Apr 21 20:59:42 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 21 Apr 2023 20:59:42 GMT Subject: RFR: 8306437: jhsdb cannot resolve image/symbol paths being used for analysis of Windows coredumps In-Reply-To: <62oUnZxCgEiiGjk1I9qb_1M_Zl0Sx4UvFeCk2S7mY00=.15eb4fda-eb88-4f9c-9d73-6fba9da60692@github.com> References: <62oUnZxCgEiiGjk1I9qb_1M_Zl0Sx4UvFeCk2S7mY00=.15eb4fda-eb88-4f9c-9d73-6fba9da60692@github.com> Message-ID: On Wed, 19 Apr 2023 10:39:40 GMT, Alexey Pavlyutkin wrote: > Hi! The patch fixes image/symbol lookup by jhsdb on alanysis Windows coredump. It uses executableName as a hint prepending image path with > > `;\server` > > and symbol path with > > `srv*https://msdl.microsoft.com/download/symbols;;\server` > > where the first bit points to Windows symbols located on remote server Are these symbols normally also stored locally, but may not work because they aren't the exact same version that was used on the host that produced the core file? Would it work if the user included "srv*https://msdl.microsoft.com/download/symbols;" in the `sun.jvm.hotspot.debugger.windbg.symbolPath` property? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13530#issuecomment-1518327813 From dcubed at openjdk.org Fri Apr 21 21:54:39 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 21 Apr 2023 21:54:39 GMT Subject: RFR: 8301377: adjust timeout for JLI GetObjectSizeIntrinsicsTest.java subtest again Message-ID: Trivial fixes to increase timeouts for tests that timeout under heavy stress: [JDK-8301377](https://bugs.openjdk.org/browse/JDK-8301377) adjust timeout for JLI GetObjectSizeIntrinsicsTest.java subtest again [JDK-8305502](https://bugs.openjdk.org/browse/JDK-8305502) adjust timeouts in three more M&M tests [JDK-8302607](https://bugs.openjdk.org/browse/JDK-8302607) increase timeout for ContinuousCallSiteTargetChange.java ------------- Commit messages: - 8302607: adjust timeout for compiler/jsr292/ContinuousCallSiteTargetChange.java - 8305502: adjust timeouts in three more M&M tests - 8301377: adjust timeout for JLI GetObjectSizeIntrinsicsTest.java subtest again Changes: https://git.openjdk.org/jdk/pull/13593/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13593&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8301377 Stats: 9 lines in 5 files changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/13593.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13593/head:pull/13593 PR: https://git.openjdk.org/jdk/pull/13593 From dcubed at openjdk.org Fri Apr 21 22:05:28 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 21 Apr 2023 22:05:28 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v60] In-Reply-To: References: Message-ID: On Mon, 17 Apr 2023 20:00:58 GMT, Roman Kennke wrote: >> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 156 commits: >> >> - Merge remote-tracking branch 'upstream/master' into JDK-8291555-v2 >> - A few more LM_ prefixes in 32bit code >> - Replace UseHeavyMonitor with LockingMode == LM_MONITOR >> - Prefix LockingMode constants with LM_* >> - Bunch of comments and typos >> - Don't use NativeAccess in LockStack::contains() >> - RISCV update >> - Put back thread type check in OS::is_lock_owned() >> - Named constants for LockingMode >> - Address David's review comments >> - ... and 146 more: https://git.openjdk.org/jdk/compare/d2ce04bb...d0a448c6 > > Hi there, > what is needed to bring this PR over the approval line? @rkennke - I'm planning to do another crawl thru review next week. ------------- PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1518372821 From naoto at openjdk.org Fri Apr 21 22:19:46 2023 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 21 Apr 2023 22:19:46 GMT Subject: RFR: 8301377: adjust timeout for JLI GetObjectSizeIntrinsicsTest.java subtest again In-Reply-To: References: Message-ID: <1XddcAzXBaAyIg0SS6cRwCw_e4dZv_ydPfBOn7jAnQg=.52261e09-7238-468e-9319-a81d72954cce@github.com> On Fri, 21 Apr 2023 21:35:07 GMT, Daniel D. Daugherty wrote: > Trivial fixes to increase timeouts for tests that timeout under heavy stress: > [JDK-8301377](https://bugs.openjdk.org/browse/JDK-8301377) adjust timeout for JLI GetObjectSizeIntrinsicsTest.java subtest again > [JDK-8305502](https://bugs.openjdk.org/browse/JDK-8305502) adjust timeouts in three more M&M tests > [JDK-8302607](https://bugs.openjdk.org/browse/JDK-8302607) increase timeout for ContinuousCallSiteTargetChange.java Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13593#pullrequestreview-1396444259 From lmesnik at openjdk.org Fri Apr 21 22:48:43 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 21 Apr 2023 22:48:43 GMT Subject: RFR: 8301377: adjust timeout for JLI GetObjectSizeIntrinsicsTest.java subtest again In-Reply-To: References: Message-ID: On Fri, 21 Apr 2023 21:35:07 GMT, Daniel D. Daugherty wrote: > Trivial fixes to increase timeouts for tests that timeout under heavy stress: > [JDK-8301377](https://bugs.openjdk.org/browse/JDK-8301377) adjust timeout for JLI GetObjectSizeIntrinsicsTest.java subtest again > [JDK-8305502](https://bugs.openjdk.org/browse/JDK-8305502) adjust timeouts in three more M&M tests > [JDK-8302607](https://bugs.openjdk.org/browse/JDK-8302607) increase timeout for ContinuousCallSiteTargetChange.java Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13593#pullrequestreview-1396464773 From dcubed at openjdk.org Fri Apr 21 22:53:43 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 21 Apr 2023 22:53:43 GMT Subject: RFR: 8301377: adjust timeout for JLI GetObjectSizeIntrinsicsTest.java subtest again In-Reply-To: References: Message-ID: On Fri, 21 Apr 2023 21:35:07 GMT, Daniel D. Daugherty wrote: > Trivial fixes to increase timeouts for tests that timeout under heavy stress: > [JDK-8301377](https://bugs.openjdk.org/browse/JDK-8301377) adjust timeout for JLI GetObjectSizeIntrinsicsTest.java subtest again > [JDK-8305502](https://bugs.openjdk.org/browse/JDK-8305502) adjust timeouts in three more M&M tests > [JDK-8302607](https://bugs.openjdk.org/browse/JDK-8302607) increase timeout for ContinuousCallSiteTargetChange.java I forgot to include testing info: - 8301377 has been tested in jdk-20+34 and jdk-21+{9,1[013-9]} stress testing. - 8302607 has been reworked into increasing the timeout and has been tested in jdk-21+1[89] stress testing. - 8305502 has been tested in jdk-21+1[7-9] stress testing. The jdk-21+19 stress run will complete late on Sunday, 2023.04.23. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13593#issuecomment-1518402540 From dcubed at openjdk.org Fri Apr 21 22:53:44 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 21 Apr 2023 22:53:44 GMT Subject: RFR: 8301377: adjust timeout for JLI GetObjectSizeIntrinsicsTest.java subtest again In-Reply-To: <1XddcAzXBaAyIg0SS6cRwCw_e4dZv_ydPfBOn7jAnQg=.52261e09-7238-468e-9319-a81d72954cce@github.com> References: <1XddcAzXBaAyIg0SS6cRwCw_e4dZv_ydPfBOn7jAnQg=.52261e09-7238-468e-9319-a81d72954cce@github.com> Message-ID: On Fri, 21 Apr 2023 22:16:32 GMT, Naoto Sato wrote: >> Trivial fixes to increase timeouts for tests that timeout under heavy stress: >> [JDK-8301377](https://bugs.openjdk.org/browse/JDK-8301377) adjust timeout for JLI GetObjectSizeIntrinsicsTest.java subtest again >> [JDK-8305502](https://bugs.openjdk.org/browse/JDK-8305502) adjust timeouts in three more M&M tests >> [JDK-8302607](https://bugs.openjdk.org/browse/JDK-8302607) increase timeout for ContinuousCallSiteTargetChange.java > > Marked as reviewed by naoto (Reviewer). @naotoj and @lmesnik - Thanks for the reviews! This PR will likely integrate on Monday (2023.04.24). ------------- PR Comment: https://git.openjdk.org/jdk/pull/13593#issuecomment-1518403740 From sspitsyn at openjdk.org Fri Apr 21 23:56:44 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 21 Apr 2023 23:56:44 GMT Subject: RFR: 8306034: add support of virtual threads to JVMTI StopThread [v2] In-Reply-To: References: <70mPVNX3n2TUacbWW0JDIfTNEACwzppdyY5PzYZxdRY=.749a3e99-be99-45ab-a688-e9c563dd5182@github.com> Message-ID: On Fri, 21 Apr 2023 17:12:32 GMT, Alan Bateman wrote: >> Nice catch - fixed now. > > Okay but JvmtiVTMSTransitionDisabler prevent the thread from being resumed for the -XX:-VMContinuations case? Thank you for the catch. Will check it. I have to extend the test to cover the BoundVirtualThread case enabled with the flag `-XX:-VMContinuations`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13546#discussion_r1174228621 From sspitsyn at openjdk.org Sat Apr 22 00:12:50 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 22 Apr 2023 00:12:50 GMT Subject: RFR: 8306034: add support of virtual threads to JVMTI StopThread [v3] In-Reply-To: References: <7nu2pq19SIw1me07wf4RnLEVErjYF3tnNnHZNcNWRlg=.8eb78564-8a56-4f59-a692-c7f79aef6ade@github.com> Message-ID: On Fri, 21 Apr 2023 18:58:22 GMT, Chris Plummer wrote: >> Do you ask this question to check if we want to extend this test to provide coverage for platform threads as well? >> >> The support of platform threads is much simpler. The JVMTI `StopThread` never returns the `THREAD_NOT_SUSPENDED` and `OPAQUE_FRAME` error codes for platform threads. So that this kind of testing is not needed for platform threads. > > For the JDI tests I added, I execute them in both modes, with the appropriate adjustments to account for the errors we except for virtual threads. We should be testing to make sure that StopThread works with platform threads under a variety of situations. Extending this test to cover platform threads does not look natural and is going to be a little ugly. But I can extend it to provide coverage for BoundVirtualThread case which is highjacking the platform thread implementation. Would it help? We should have pretty good coverage of the JVMTI `StopThread` for platform threads in `nsk.jvmti` test suite. It includes: - `stopthrd006` and `stopthrd007` - a number of `scenarios/capability/CM01 `tests ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13546#discussion_r1174232494 From alanb at openjdk.org Sat Apr 22 08:03:44 2023 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 22 Apr 2023 08:03:44 GMT Subject: RFR: 8306034: add support of virtual threads to JVMTI StopThread [v2] In-Reply-To: References: <70mPVNX3n2TUacbWW0JDIfTNEACwzppdyY5PzYZxdRY=.749a3e99-be99-45ab-a688-e9c563dd5182@github.com> Message-ID: On Fri, 21 Apr 2023 23:53:45 GMT, Serguei Spitsyn wrote: >> Okay but JvmtiVTMSTransitionDisabler prevent the thread from being resumed for the -XX:-VMContinuations case? > > Thank you for the catch. Will check it. I have to extend the test to cover the BoundVirtualThread case enabled with the flag `-XX:-VMContinuations`. The scenario that I'm wondering about is where a virtual thread is resumed at around the same time that JVMTI StopThread is called. Not easy to test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13546#discussion_r1174328716 From duke at openjdk.org Sun Apr 23 15:23:51 2023 From: duke at openjdk.org (Afshin Zafari) Date: Sun, 23 Apr 2023 15:23:51 GMT Subject: Integrated: 8305590: Remove nothrow exception specifications from operator new In-Reply-To: References: Message-ID: <0RuAzlA_w6Fo1ozWGLeyZxx-rWonpl0ioRtILLXTZYI=.918fbcfb-d617-4e72-89c7-3b69284b81df@github.com> On Mon, 17 Apr 2023 17:09:44 GMT, Afshin Zafari wrote: > - The `throw()` (i.e., no throw) specifications are removed from the instances of `operator new` where _do not_ return `nullptr`. > > - The `-fcheck-new` is removed from the gcc compile flags. > > - The `operator new` and `operator delete` are deleted from `StackObj`. > > - The `GrowableArrayCHeap::operator delete` is added to be matched with its corresponding allocation`AnyObj::operator new`, because gcc complains on that after removing the `-fcheck-new` flag. > - The `Thread::operator new`with and without `null` return are removed. > > ### Tests > local: linux-x64 gtest:GrowableArrayCHeap, macosx-aarch64 hotspot:tier1 > mach5: tiers 1-5 This pull request has now been integrated. Changeset: 0f51e632 Author: Afshin Zafari Committer: Jesper Wilhelmsson URL: https://git.openjdk.org/jdk/commit/0f51e6326373ff7d4a4d9a0e3a2788401f73405d Stats: 53 lines in 8 files changed: 3 ins; 27 del; 23 mod 8305590: Remove nothrow exception specifications from operator new Reviewed-by: coleenp, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/13498 From jwaters at openjdk.org Sun Apr 23 18:34:54 2023 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 23 Apr 2023 18:34:54 GMT Subject: RFR: 8305590: Remove nothrow exception specifications from operator new [v3] In-Reply-To: <5uZmZV3ssLzKKFBeajmWUBmZsaZeq-3ImeHkzCvnSwg=.4941a9c0-b250-4290-828a-15416ed791df@github.com> References: <5uZmZV3ssLzKKFBeajmWUBmZsaZeq-3ImeHkzCvnSwg=.4941a9c0-b250-4290-828a-15416ed791df@github.com> Message-ID: <7EfFlEYBncjzdoZzU_gdl8tB7kpj_z3ga_h-fXxy0Os=.42af4f0f-e003-4a54-bf79-603c80bdd12f@github.com> On Thu, 20 Apr 2023 08:41:58 GMT, Afshin Zafari wrote: >> - The `throw()` (i.e., no throw) specifications are removed from the instances of `operator new` where _do not_ return `nullptr`. >> >> - The `-fcheck-new` is removed from the gcc compile flags. >> >> - The `operator new` and `operator delete` are deleted from `StackObj`. >> >> - The `GrowableArrayCHeap::operator delete` is added to be matched with its corresponding allocation`AnyObj::operator new`, because gcc complains on that after removing the `-fcheck-new` flag. >> - The `Thread::operator new`with and without `null` return are removed. >> >> ### Tests >> local: linux-x64 gtest:GrowableArrayCHeap, macosx-aarch64 hotspot:tier1 >> mach5: tiers 1-5 > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 8305590: Remove nothrow exception specifications from operator new I believe this may have missed removing the exception specifier from an operator new inside AnyObj, allocation.cpp, since gcc 12 and up on my end now refuses to compile HotSpot with this change. I'll create a cleanup change for this, if there isn't any opposition to that ------------- PR Comment: https://git.openjdk.org/jdk/pull/13498#issuecomment-1519127682 From lmesnik at openjdk.org Sun Apr 23 22:42:48 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Sun, 23 Apr 2023 22:42:48 GMT Subject: RFR: 8233725: ProcessTools.startProcess() has output issues when using an OutputAnalyzer at the same time Message-ID: ProcessTools.startProcess() creates process and read it's output error streams. So the any other using of corresponding Process.getInputStream() and Process.getErrorStream() doesn't get process streams. This fix preserve process streams content and allow to read reuse the date. The ByteArrayOutputStream is used as a buffer. It stores all process output, never trying to clean date which has been read. The regression test has been provided with issue. I closed previous PR https://github.com/openjdk/jdk/pull/13560 by mistake instead of updating it. I run all tests to ensure that no failures are introduced. ------------- Commit messages: - copyrights fixed - typo fixed - fixed to use buffer. - JStackStressTest.java updated. - 8233725: ProcessTools.startProcess() has output issues when using an OutputAnalyzer at the same time Changes: https://git.openjdk.org/jdk/pull/13594/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13594&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8233725 Stats: 210 lines in 3 files changed: 198 ins; 2 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/13594.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13594/head:pull/13594 PR: https://git.openjdk.org/jdk/pull/13594 From kbarrett at openjdk.org Mon Apr 24 00:25:52 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 24 Apr 2023 00:25:52 GMT Subject: RFR: 8305590: Remove nothrow exception specifications from operator new [v3] In-Reply-To: <7EfFlEYBncjzdoZzU_gdl8tB7kpj_z3ga_h-fXxy0Os=.42af4f0f-e003-4a54-bf79-603c80bdd12f@github.com> References: <5uZmZV3ssLzKKFBeajmWUBmZsaZeq-3ImeHkzCvnSwg=.4941a9c0-b250-4290-828a-15416ed791df@github.com> <7EfFlEYBncjzdoZzU_gdl8tB7kpj_z3ga_h-fXxy0Os=.42af4f0f-e003-4a54-bf79-603c80bdd12f@github.com> Message-ID: On Sun, 23 Apr 2023 18:31:57 GMT, Julian Waters wrote: > I believe this may have missed removing the exception specifier from an operator new inside AnyObj, allocation.cpp, since gcc 12 and up on my end now refuses to compile HotSpot with this change. I'll create a cleanup change for this, if there isn't any opposition to that It builds for me, with gcc12.2. However, it does look like `AnyObj::operator new(size_t, MEMFLAGS)` should have had the nothrow exception spec removed (both in the header and the .cpp) but didn't. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13498#issuecomment-1519208242 From thartmann at openjdk.org Mon Apr 24 05:26:53 2023 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 24 Apr 2023 05:26:53 GMT Subject: RFR: 8301377: adjust timeout for JLI GetObjectSizeIntrinsicsTest.java subtest again In-Reply-To: References: Message-ID: On Fri, 21 Apr 2023 21:35:07 GMT, Daniel D. Daugherty wrote: > Trivial fixes to increase timeouts for tests that timeout under heavy stress: > [JDK-8301377](https://bugs.openjdk.org/browse/JDK-8301377) adjust timeout for JLI GetObjectSizeIntrinsicsTest.java subtest again > [JDK-8305502](https://bugs.openjdk.org/browse/JDK-8305502) adjust timeouts in three more M&M tests > [JDK-8302607](https://bugs.openjdk.org/browse/JDK-8302607) increase timeout for ContinuousCallSiteTargetChange.java Looks good. ------------- Marked as reviewed by thartmann (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13593#pullrequestreview-1397215121 From kbarrett at openjdk.org Mon Apr 24 08:52:18 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 24 Apr 2023 08:52:18 GMT Subject: RFR: 8305566: ZGC: gc/stringdedup/TestStringDeduplicationFullGC.java#Z failed with SIGSEGV in ZBarrier::weak_load_barrier_on_phantom_oop_slow_path Message-ID: Please review this change to the string deduplication thread to make it a kind of JavaThread rather than a ConcurrentGCThread. There are several pieces to this change: (1) New class StringDedupThread (derived from JavaThread), separate from StringDedup::Processor (which is now just a CHeapObj instead of deriving from ConcurrentGCThread). The thread no longer needs to or supports being stopped, like other similar threads. It also needs to be started later, once Java threads are supported. Also don't need an explicit visitor, since it will be in the normal Java threads list. This separation made the changeover a little cleaner to develop, and made the servicability support a little cleaner too. (2) The Processor now uses the ThreadBlockInVM idiom to be safepoint polite, instead of using the SuspendibleThreadSet facility. (3) Because we're using ThreadBlockInVM, which has a different usage style from STS, the tracking of time spent by the processor blocked for safepoints doesn't really work. It's not very important anyway, since normal thread descheduling can also affect the normal processing times being gathered and reported. So we just drop the so-called "blocked" time and associated infrastructure, simplifying Stat tracking a bit. Also renamed the "concurrent" stat to be "active", since it's all in a JavaThread now. (4) To avoid #include problems, moved the definition of JavaThread::is_active_Java_thread from the .hpp file to the .inline.hpp file, where one of the functions it calls also is defined. (5) Added servicability support for the new thread. Testing: mach5 tier1-3 with -XX:+UseStringDeduplication. The test runtime/cds/DeterministicDump.java fails intermittently with that option, which is not surprising - see JDK-8306712. I was never able to reproduce the failure; it's likely quite timing sensitive. The fix of changing the type is based on StefanK's comment that ZResurrection doesn't expect a non-Java thread to perform load-barriers. ------------- Commit messages: - fix stray tab - move is_active_Java_thread - copyrights - servicabilty support - use JavaThread - separate thread class - simplify init - do not pass around STS joiner - remove no longer needed Phase enum - remove block_phase et al Changes: https://git.openjdk.org/jdk/pull/13607/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13607&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8305566 Stats: 440 lines in 18 files changed: 193 ins; 146 del; 101 mod Patch: https://git.openjdk.org/jdk/pull/13607.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13607/head:pull/13607 PR: https://git.openjdk.org/jdk/pull/13607 From stefank at openjdk.org Mon Apr 24 09:10:45 2023 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 24 Apr 2023 09:10:45 GMT Subject: RFR: 8305566: ZGC: gc/stringdedup/TestStringDeduplicationFullGC.java#Z failed with SIGSEGV in ZBarrier::weak_load_barrier_on_phantom_oop_slow_path In-Reply-To: References: Message-ID: On Mon, 24 Apr 2023 08:24:53 GMT, Kim Barrett wrote: > Please review this change to the string deduplication thread to make it a kind > of JavaThread rather than a ConcurrentGCThread. There are several pieces to > this change: > > (1) New class StringDedupThread (derived from JavaThread), separate from > StringDedup::Processor (which is now just a CHeapObj instead of deriving from > ConcurrentGCThread). The thread no longer needs to or supports being stopped, > like other similar threads. It also needs to be started later, once Java > threads are supported. Also don't need an explicit visitor, since it will be > in the normal Java threads list. This separation made the changeover a little > cleaner to develop, and made the servicability support a little cleaner too. > > (2) The Processor now uses the ThreadBlockInVM idiom to be safepoint polite, > instead of using the SuspendibleThreadSet facility. > > (3) Because we're using ThreadBlockInVM, which has a different usage style > from STS, the tracking of time spent by the processor blocked for safepoints > doesn't really work. It's not very important anyway, since normal thread > descheduling can also affect the normal processing times being gathered and > reported. So we just drop the so-called "blocked" time and associated > infrastructure, simplifying Stat tracking a bit. Also renamed the > "concurrent" stat to be "active", since it's all in a JavaThread now. > > (4) To avoid #include problems, moved the definition of > JavaThread::is_active_Java_thread from the .hpp file to the .inline.hpp file, > where one of the functions it calls also is defined. > > (5) Added servicability support for the new thread. > > Testing: > mach5 tier1-3 with -XX:+UseStringDeduplication. > The test runtime/cds/DeterministicDump.java fails intermittently with that > option, which is not surprising - see JDK-8306712. > > I was never able to reproduce the failure; it's likely quite timing sensitive. > The fix of changing the type is based on StefanK's comment that ZResurrection > doesn't expect a non-Java thread to perform load-barriers. I think this looks sensible to me, though I'm not very familiar with the current StringDedup code, so consider this a partial review only. src/hotspot/share/gc/shared/stringdedup/stringDedupProcessor.hpp line 29: > 27: > 28: #include "memory/allocation.hpp" > 29: #include "gc/shared/stringdedup/stringDedup.hpp" sort order ------------- Marked as reviewed by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13607#pullrequestreview-1397500893 PR Review Comment: https://git.openjdk.org/jdk/pull/13607#discussion_r1174989267 From kbarrett at openjdk.org Mon Apr 24 09:25:02 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 24 Apr 2023 09:25:02 GMT Subject: RFR: 8305566: ZGC: gc/stringdedup/TestStringDeduplicationFullGC.java#Z failed with SIGSEGV in ZBarrier::weak_load_barrier_on_phantom_oop_slow_path [v2] In-Reply-To: References: Message-ID: On Mon, 24 Apr 2023 09:00:53 GMT, Stefan Karlsson wrote: >> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: >> >> fix include order > > src/hotspot/share/gc/shared/stringdedup/stringDedupProcessor.hpp line 29: > >> 27: >> 28: #include "memory/allocation.hpp" >> 29: #include "gc/shared/stringdedup/stringDedup.hpp" > > sort order oops. fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13607#discussion_r1175009838 From kbarrett at openjdk.org Mon Apr 24 09:25:01 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 24 Apr 2023 09:25:01 GMT Subject: RFR: 8305566: ZGC: gc/stringdedup/TestStringDeduplicationFullGC.java#Z failed with SIGSEGV in ZBarrier::weak_load_barrier_on_phantom_oop_slow_path [v2] In-Reply-To: References: Message-ID: <-k-_JovF26G4lOTq2AvCVxvDgwnqpD4-GSbSYCbDcn4=.e82221d2-9fd8-4aed-9a11-6f5ccc09c669@github.com> > Please review this change to the string deduplication thread to make it a kind > of JavaThread rather than a ConcurrentGCThread. There are several pieces to > this change: > > (1) New class StringDedupThread (derived from JavaThread), separate from > StringDedup::Processor (which is now just a CHeapObj instead of deriving from > ConcurrentGCThread). The thread no longer needs to or supports being stopped, > like other similar threads. It also needs to be started later, once Java > threads are supported. Also don't need an explicit visitor, since it will be > in the normal Java threads list. This separation made the changeover a little > cleaner to develop, and made the servicability support a little cleaner too. > > (2) The Processor now uses the ThreadBlockInVM idiom to be safepoint polite, > instead of using the SuspendibleThreadSet facility. > > (3) Because we're using ThreadBlockInVM, which has a different usage style > from STS, the tracking of time spent by the processor blocked for safepoints > doesn't really work. It's not very important anyway, since normal thread > descheduling can also affect the normal processing times being gathered and > reported. So we just drop the so-called "blocked" time and associated > infrastructure, simplifying Stat tracking a bit. Also renamed the > "concurrent" stat to be "active", since it's all in a JavaThread now. > > (4) To avoid #include problems, moved the definition of > JavaThread::is_active_Java_thread from the .hpp file to the .inline.hpp file, > where one of the functions it calls also is defined. > > (5) Added servicability support for the new thread. > > Testing: > mach5 tier1-3 with -XX:+UseStringDeduplication. > The test runtime/cds/DeterministicDump.java fails intermittently with that > option, which is not surprising - see JDK-8306712. > > I was never able to reproduce the failure; it's likely quite timing sensitive. > The fix of changing the type is based on StefanK's comment that ZResurrection > doesn't expect a non-Java thread to perform load-barriers. Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: fix include order ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13607/files - new: https://git.openjdk.org/jdk/pull/13607/files/d4e94b89..f17cc6be Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13607&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13607&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13607.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13607/head:pull/13607 PR: https://git.openjdk.org/jdk/pull/13607 From shade at openjdk.org Mon Apr 24 09:25:31 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 24 Apr 2023 09:25:31 GMT Subject: RFR: 8305566: ZGC: gc/stringdedup/TestStringDeduplicationFullGC.java#Z failed with SIGSEGV in ZBarrier::weak_load_barrier_on_phantom_oop_slow_path In-Reply-To: References: Message-ID: <55jKHzOyDChs03tfesgftPEzppeIIaJhS3AZ8uxNrXw=.3c35cfd0-01fa-49fd-8e4a-baec119edc9c@github.com> On Mon, 24 Apr 2023 08:24:53 GMT, Kim Barrett wrote: > Please review this change to the string deduplication thread to make it a kind > of JavaThread rather than a ConcurrentGCThread. There are several pieces to > this change: > > (1) New class StringDedupThread (derived from JavaThread), separate from > StringDedup::Processor (which is now just a CHeapObj instead of deriving from > ConcurrentGCThread). The thread no longer needs to or supports being stopped, > like other similar threads. It also needs to be started later, once Java > threads are supported. Also don't need an explicit visitor, since it will be > in the normal Java threads list. This separation made the changeover a little > cleaner to develop, and made the servicability support a little cleaner too. > > (2) The Processor now uses the ThreadBlockInVM idiom to be safepoint polite, > instead of using the SuspendibleThreadSet facility. > > (3) Because we're using ThreadBlockInVM, which has a different usage style > from STS, the tracking of time spent by the processor blocked for safepoints > doesn't really work. It's not very important anyway, since normal thread > descheduling can also affect the normal processing times being gathered and > reported. So we just drop the so-called "blocked" time and associated > infrastructure, simplifying Stat tracking a bit. Also renamed the > "concurrent" stat to be "active", since it's all in a JavaThread now. > > (4) To avoid #include problems, moved the definition of > JavaThread::is_active_Java_thread from the .hpp file to the .inline.hpp file, > where one of the functions it calls also is defined. > > (5) Added servicability support for the new thread. > > Testing: > mach5 tier1-3 with -XX:+UseStringDeduplication. > The test runtime/cds/DeterministicDump.java fails intermittently with that > option, which is not surprising - see JDK-8306712. > > I was never able to reproduce the failure; it's likely quite timing sensitive. > The fix of changing the type is based on StefanK's comment that ZResurrection > doesn't expect a non-Java thread to perform load-barriers. Could we please change the synopsis to something more relevant? This PR does not only fix the ZGC test failure, but does a more fundamental change: switching string dedup thread from being `ConcurrentGCThread` to `JavaThread`, and so it affects more than one GC. The synopsis should reflect that, I think. (This would also be cleaner for potential backports, if any). ------------- PR Comment: https://git.openjdk.org/jdk/pull/13607#issuecomment-1519707606 From shade at openjdk.org Mon Apr 24 09:41:43 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 24 Apr 2023 09:41:43 GMT Subject: RFR: 8305566: ZGC: gc/stringdedup/TestStringDeduplicationFullGC.java#Z failed with SIGSEGV in ZBarrier::weak_load_barrier_on_phantom_oop_slow_path [v2] In-Reply-To: <-k-_JovF26G4lOTq2AvCVxvDgwnqpD4-GSbSYCbDcn4=.e82221d2-9fd8-4aed-9a11-6f5ccc09c669@github.com> References: <-k-_JovF26G4lOTq2AvCVxvDgwnqpD4-GSbSYCbDcn4=.e82221d2-9fd8-4aed-9a11-6f5ccc09c669@github.com> Message-ID: On Mon, 24 Apr 2023 09:25:01 GMT, Kim Barrett wrote: >> Please review this change to the string deduplication thread to make it a kind >> of JavaThread rather than a ConcurrentGCThread. There are several pieces to >> this change: >> >> (1) New class StringDedupThread (derived from JavaThread), separate from >> StringDedup::Processor (which is now just a CHeapObj instead of deriving from >> ConcurrentGCThread). The thread no longer needs to or supports being stopped, >> like other similar threads. It also needs to be started later, once Java >> threads are supported. Also don't need an explicit visitor, since it will be >> in the normal Java threads list. This separation made the changeover a little >> cleaner to develop, and made the servicability support a little cleaner too. >> >> (2) The Processor now uses the ThreadBlockInVM idiom to be safepoint polite, >> instead of using the SuspendibleThreadSet facility. >> >> (3) Because we're using ThreadBlockInVM, which has a different usage style >> from STS, the tracking of time spent by the processor blocked for safepoints >> doesn't really work. It's not very important anyway, since normal thread >> descheduling can also affect the normal processing times being gathered and >> reported. So we just drop the so-called "blocked" time and associated >> infrastructure, simplifying Stat tracking a bit. Also renamed the >> "concurrent" stat to be "active", since it's all in a JavaThread now. >> >> (4) To avoid #include problems, moved the definition of >> JavaThread::is_active_Java_thread from the .hpp file to the .inline.hpp file, >> where one of the functions it calls also is defined. >> >> (5) Added servicability support for the new thread. >> >> Testing: >> mach5 tier1-3 with -XX:+UseStringDeduplication. >> The test runtime/cds/DeterministicDump.java fails intermittently with that >> option, which is not surprising - see JDK-8306712. >> >> I was never able to reproduce the failure; it's likely quite timing sensitive. >> The fix of changing the type is based on StefanK's comment that ZResurrection >> doesn't expect a non-Java thread to perform load-barriers. > > Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: > > fix include order I like this simplification a lot, thanks! I am running some Shenandoah string-dedup tests now. (Formally requesting the change of synopsis) ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13607#pullrequestreview-1397574534 Changes requested by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13607#pullrequestreview-1397576017 From mdoerr at openjdk.org Mon Apr 24 09:55:57 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 24 Apr 2023 09:55:57 GMT Subject: RFR: 8304915: Create jdk.internal.util.Architecture enum and apply [v17] In-Reply-To: References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com> Message-ID: On Fri, 21 Apr 2023 20:26:12 GMT, Roger Riggs wrote: >> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`. >> The enumeration values are defined to match those used in the build. >> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64` >> Note that `amd64` and `x86_64` in the build are represented by `X64`. >> The value of the system property `os.arch` is unchanged. >> >> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931). >> Uses in `java.base` and a few others are included but other modules will be done in separate PRs. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Correct comment on isPPC64() and refer to isLittleEndian() instead of mentioning PPC64LE Thanks for the comment updates! ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13357#pullrequestreview-1397600716 From shade at openjdk.org Mon Apr 24 11:57:51 2023 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 24 Apr 2023 11:57:51 GMT Subject: RFR: 8305566: ZGC: gc/stringdedup/TestStringDeduplicationFullGC.java#Z failed with SIGSEGV in ZBarrier::weak_load_barrier_on_phantom_oop_slow_path [v2] In-Reply-To: References: <-k-_JovF26G4lOTq2AvCVxvDgwnqpD4-GSbSYCbDcn4=.e82221d2-9fd8-4aed-9a11-6f5ccc09c669@github.com> Message-ID: On Mon, 24 Apr 2023 09:39:07 GMT, Aleksey Shipilev wrote: > I like this simplification a lot, thanks! I am running some Shenandoah string-dedup tests now. Ran `gc/shenandoah/TestStringDedup*` on x86_64 and AArch64 for 100 times without a problem. These tests usually fail when there are bugs in string dedup. So I think we are clear there! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13607#issuecomment-1520010545 From dcubed at openjdk.org Mon Apr 24 16:13:56 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Mon, 24 Apr 2023 16:13:56 GMT Subject: RFR: 8301377: adjust timeout for JLI GetObjectSizeIntrinsicsTest.java subtest again In-Reply-To: References: Message-ID: On Mon, 24 Apr 2023 05:24:20 GMT, Tobias Hartmann wrote: >> Trivial fixes to increase timeouts for tests that timeout under heavy stress: >> [JDK-8301377](https://bugs.openjdk.org/browse/JDK-8301377) adjust timeout for JLI GetObjectSizeIntrinsicsTest.java subtest again >> [JDK-8305502](https://bugs.openjdk.org/browse/JDK-8305502) adjust timeouts in three more M&M tests >> [JDK-8302607](https://bugs.openjdk.org/browse/JDK-8302607) increase timeout for ContinuousCallSiteTargetChange.java > > Looks good. @TobiHartmann - Thanks for the review! My jdk-21+19 stress testing round had no issues with these fixes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13593#issuecomment-1520457554 From dcubed at openjdk.org Mon Apr 24 16:13:58 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Mon, 24 Apr 2023 16:13:58 GMT Subject: Integrated: 8301377: adjust timeout for JLI GetObjectSizeIntrinsicsTest.java subtest again In-Reply-To: References: Message-ID: <3UbIgqWd7vlTLk6ovrv5dJX2kocPtT147xX26XcA3mU=.bb2b347b-eab3-457f-8acd-ed54ef5b2e61@github.com> On Fri, 21 Apr 2023 21:35:07 GMT, Daniel D. Daugherty wrote: > Trivial fixes to increase timeouts for tests that timeout under heavy stress: > [JDK-8301377](https://bugs.openjdk.org/browse/JDK-8301377) adjust timeout for JLI GetObjectSizeIntrinsicsTest.java subtest again > [JDK-8305502](https://bugs.openjdk.org/browse/JDK-8305502) adjust timeouts in three more M&M tests > [JDK-8302607](https://bugs.openjdk.org/browse/JDK-8302607) increase timeout for ContinuousCallSiteTargetChange.java This pull request has now been integrated. Changeset: 4b23bef5 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/4b23bef51df9c1a5bc8f43748a8d6c8d99995656 Stats: 9 lines in 5 files changed: 0 ins; 0 del; 9 mod 8301377: adjust timeout for JLI GetObjectSizeIntrinsicsTest.java subtest again 8302607: increase timeout for ContinuousCallSiteTargetChange.java 8305502: adjust timeouts in three more M&M tests Reviewed-by: naoto, lmesnik, thartmann ------------- PR: https://git.openjdk.org/jdk/pull/13593 From jiangli at openjdk.org Mon Apr 24 17:27:44 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 24 Apr 2023 17:27:44 GMT Subject: RFR: 8306033: Resolve multiple definition of 'throwIOException' and friends when statically linking with JDK native libraries In-Reply-To: References: Message-ID: On Mon, 17 Apr 2023 16:56:31 GMT, Jiangli Zhou wrote: > - Make functions 'static' when feasible: > - throwByName() in src/java.security.jgss/share/native/libj2gss/NativeUtil.c. > - throwByName(), throwIOException() and throwNullPointerException() in src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c. > - throwByName() in src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c. > - throwOutOfMemoryError() in src/java.smartcardio/share/native/libj2pcsc/pcsc.c. > - Move throwDisconnectedRuntimeException() to src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c since it's only used in the file. Make it static. > - Move throw_internal_error() to src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c as it's only used in the file. Make it static. > > - Rename functions by following the existing naming usages in different libraries code: > - Rename throwOutOfMemoryError() to gssThrowOutOfMemoryError() in libj2gss. > - Rename throwOutOfMemoryError() to p11ThrowOutOfMemoryError() in libj2pks11. > - Rename throwNullPointerException() to p11ThrowNullPointerException() in libj2pks11. > - Rename throwIOException() to p11ThrowIOException() in libj2pks11. > - Rename throwPKCS11RuntimeException() to p11ThrowPKCS11RuntimeException() in libj2pks11. This function only exists in libj2pks11. The rename is done so the function naming is consistent with the other throw functions. > > - Remove throw_internal_error() from src/java.management/share/native/libmanagement/management.h and src/java.management/share/native/libmanagement/management.c. It's not used. > - Remove throw_internal_error() from src/jdk.management/share/native/libmanagement_ext/management_ext.h and src/jdk.management/share/native/libmanagement_ext/management_ext.c. Gentle ping, please help review this PR. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13497#issuecomment-1520559203 From rkennke at openjdk.org Mon Apr 24 19:45:59 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 24 Apr 2023 19:45:59 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v60] In-Reply-To: References: Message-ID: On Mon, 17 Apr 2023 20:00:58 GMT, Roman Kennke wrote: >> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 156 commits: >> >> - Merge remote-tracking branch 'upstream/master' into JDK-8291555-v2 >> - A few more LM_ prefixes in 32bit code >> - Replace UseHeavyMonitor with LockingMode == LM_MONITOR >> - Prefix LockingMode constants with LM_* >> - Bunch of comments and typos >> - Don't use NativeAccess in LockStack::contains() >> - RISCV update >> - Put back thread type check in OS::is_lock_owned() >> - Named constants for LockingMode >> - Address David's review comments >> - ... and 146 more: https://git.openjdk.org/jdk/compare/d2ce04bb...d0a448c6 > > Hi there, > what is needed to bring this PR over the approval line? > @rkennke - I'm planning to do another crawl thru review next week. Thanks! That is greatly appeciated! ------------- PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1520728296 From dcubed at openjdk.org Mon Apr 24 20:11:56 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Mon, 24 Apr 2023 20:11:56 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v62] In-Reply-To: References: Message-ID: On Thu, 20 Apr 2023 11:15:47 GMT, Roman Kennke wrote: >> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). >> >> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. >> >> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal protocols. >> >> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare. >> >> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. >> >> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. >> >> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. >> >> This change enables to simplify (and speed-up!) a lot of code: >> >> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. >> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR >> >> Also, and I might be mistaken here, this new lightweight locking would make synchronized work better with Loom: Because the lock-records are no longer scattered across the stack, but instead are densely packed into the lock-stack, it should be easy for a vthread to save its lock-stack upon unmounting and restore it when re-mounting. However, I am not sure about this, and this PR does not attempt to implement that support. >> >> Testing: >> - [x] tier1 x86_64 x aarch64 x +UseFastLocking >> - [x] tier2 x86_64 x aarch64 x +UseFastLocking >> - [x] tier3 x86_64 x aarch64 x +UseFastLocking >> - [x] tier4 x86_64 x aarch64 x +UseFastLocking >> - [x] tier1 x86_64 x aarch64 x -UseFastLocking >> - [x] tier2 x86_64 x aarch64 x -UseFastLocking >> - [x] tier3 x86_64 x aarch64 x -UseFastLocking >> - [x] tier4 x86_64 x aarch64 x -UseFastLocking >> - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet >> >> ### Performance >> >> #### Simple Microbenchmark >> >> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops. >> >> | | x86_64 | aarch64 | >> | -- | -- | -- | >> | -UseFastLocking | 20.651 | 20.764 | >> | +UseFastLocking | 18.896 | 18.908 | >> >> >> #### Renaissance >> >> ? | x86_64 | ? | ? | ? | aarch64 | ? | ? >> -- | -- | -- | -- | -- | -- | -- | -- >> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? >> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% >> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21% >> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% >> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% >> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% >> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% >> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%% >> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% >> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% >> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% >> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% >> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34% >> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% >> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% >> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% >> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% >> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% >> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% >> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% >> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% >> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Remove unnecessary comments This project is currently baselined on jdk-21+19-1510. ------------- PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1520761332 From cjplummer at openjdk.org Mon Apr 24 20:26:12 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 24 Apr 2023 20:26:12 GMT Subject: RFR: 8305566: ZGC: gc/stringdedup/TestStringDeduplicationFullGC.java#Z failed with SIGSEGV in ZBarrier::weak_load_barrier_on_phantom_oop_slow_path [v2] In-Reply-To: <-k-_JovF26G4lOTq2AvCVxvDgwnqpD4-GSbSYCbDcn4=.e82221d2-9fd8-4aed-9a11-6f5ccc09c669@github.com> References: <-k-_JovF26G4lOTq2AvCVxvDgwnqpD4-GSbSYCbDcn4=.e82221d2-9fd8-4aed-9a11-6f5ccc09c669@github.com> Message-ID: On Mon, 24 Apr 2023 09:25:01 GMT, Kim Barrett wrote: >> Please review this change to the string deduplication thread to make it a kind >> of JavaThread rather than a ConcurrentGCThread. There are several pieces to >> this change: >> >> (1) New class StringDedupThread (derived from JavaThread), separate from >> StringDedup::Processor (which is now just a CHeapObj instead of deriving from >> ConcurrentGCThread). The thread no longer needs to or supports being stopped, >> like other similar threads. It also needs to be started later, once Java >> threads are supported. Also don't need an explicit visitor, since it will be >> in the normal Java threads list. This separation made the changeover a little >> cleaner to develop, and made the servicability support a little cleaner too. >> >> (2) The Processor now uses the ThreadBlockInVM idiom to be safepoint polite, >> instead of using the SuspendibleThreadSet facility. >> >> (3) Because we're using ThreadBlockInVM, which has a different usage style >> from STS, the tracking of time spent by the processor blocked for safepoints >> doesn't really work. It's not very important anyway, since normal thread >> descheduling can also affect the normal processing times being gathered and >> reported. So we just drop the so-called "blocked" time and associated >> infrastructure, simplifying Stat tracking a bit. Also renamed the >> "concurrent" stat to be "active", since it's all in a JavaThread now. >> >> (4) To avoid #include problems, moved the definition of >> JavaThread::is_active_Java_thread from the .hpp file to the .inline.hpp file, >> where one of the functions it calls also is defined. >> >> (5) Added servicability support for the new thread. >> >> Testing: >> mach5 tier1-3 with -XX:+UseStringDeduplication. >> The test runtime/cds/DeterministicDump.java fails intermittently with that >> option, which is not surprising - see JDK-8306712. >> >> I was never able to reproduce the failure; it's likely quite timing sensitive. >> The fix of changing the type is based on StefanK's comment that ZResurrection >> doesn't expect a non-Java thread to perform load-barriers. > > Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: > > fix include order SA changes look good ------------- Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13607#pullrequestreview-1398739628 From cjplummer at openjdk.org Mon Apr 24 20:29:20 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 24 Apr 2023 20:29:20 GMT Subject: RFR: 8306034: add support of virtual threads to JVMTI StopThread [v2] In-Reply-To: References: <70mPVNX3n2TUacbWW0JDIfTNEACwzppdyY5PzYZxdRY=.749a3e99-be99-45ab-a688-e9c563dd5182@github.com> Message-ID: On Sat, 22 Apr 2023 08:01:20 GMT, Alan Bateman wrote: >> Thank you for the catch. Will check it. I have to extend the test to cover the BoundVirtualThread case enabled with the flag `-XX:-VMContinuations`. > > The scenario that I'm wondering about is where a virtual thread is resumed at around the same time that JVMTI StopThread is called. Not easy to test. Seems we should have a stress test for that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13546#discussion_r1175750223 From cjplummer at openjdk.org Mon Apr 24 21:00:13 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 24 Apr 2023 21:00:13 GMT Subject: RFR: 8233725: ProcessTools.startProcess() has output issues when using an OutputAnalyzer at the same time In-Reply-To: References: Message-ID: On Fri, 21 Apr 2023 21:43:39 GMT, Leonid Mesnik wrote: > ProcessTools.startProcess() creates process and read it's output error streams. So the any other using of corresponding Process.getInputStream() and Process.getErrorStream() doesn't get process streams. > > This fix preserve process streams content and allow to read reuse the date. The ByteArrayOutputStream is used as a buffer. > It stores all process output, never trying to clean date which has been read. > > The regression test has been provided with issue. > > I closed previous PR https://github.com/openjdk/jdk/pull/13560 by mistake instead of updating it. > > I run all tests to ensure that no failures are introduced. Marked as reviewed by cjplummer (Reviewer). test/lib/jdk/test/lib/process/ProcessTools.java line 249: > 247: stdout.addOutputStream(out.getOutputStream()); > 248: stderr.addOutputStream(err.getOutputStream()); > 249: Overall this looks good, although I'm a bit unclear on how some of the underpinnings work, allowing the output to appear in these output streams, and also in the LineForwarder output (above), and for that matter, in the lineConsumer output (below). I guess there is some multiplexing of the output that I just don't grasp, but appears to be something that already worked. ------------- PR Review: https://git.openjdk.org/jdk/pull/13594#pullrequestreview-1398781718 PR Review Comment: https://git.openjdk.org/jdk/pull/13594#discussion_r1175775335 From mark.powers at oracle.com Mon Apr 24 22:01:38 2023 From: mark.powers at oracle.com (Mark Powers) Date: Mon, 24 Apr 2023 22:01:38 +0000 Subject: RFR: 8306033: Resolve multiple definition of 'throwIOException' and friends when statically linking with JDK native libraries In-Reply-To: References: Message-ID: I'll take a look. ________________________________ From: security-dev on behalf of Jiangli Zhou Sent: Monday, April 24, 2023 10:27 AM To: jmx-dev at openjdk.org ; security-dev at openjdk.org ; serviceability-dev at openjdk.org Subject: Re: RFR: 8306033: Resolve multiple definition of 'throwIOException' and friends when statically linking with JDK native libraries On Mon, 17 Apr 2023 16:56:31 GMT, Jiangli Zhou wrote: > - Make functions 'static' when feasible: > - throwByName() in src/java.security.jgss/share/native/libj2gss/NativeUtil.c. > - throwByName(), throwIOException() and throwNullPointerException() in src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c. > - throwByName() in src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c. > - throwOutOfMemoryError() in src/java.smartcardio/share/native/libj2pcsc/pcsc.c. > - Move throwDisconnectedRuntimeException() to src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c since it's only used in the file. Make it static. > - Move throw_internal_error() to src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c as it's only used in the file. Make it static. > > - Rename functions by following the existing naming usages in different libraries code: > - Rename throwOutOfMemoryError() to gssThrowOutOfMemoryError() in libj2gss. > - Rename throwOutOfMemoryError() to p11ThrowOutOfMemoryError() in libj2pks11. > - Rename throwNullPointerException() to p11ThrowNullPointerException() in libj2pks11. > - Rename throwIOException() to p11ThrowIOException() in libj2pks11. > - Rename throwPKCS11RuntimeException() to p11ThrowPKCS11RuntimeException() in libj2pks11. This function only exists in libj2pks11. The rename is done so the function naming is consistent with the other throw functions. > > - Remove throw_internal_error() from src/java.management/share/native/libmanagement/management.h and src/java.management/share/native/libmanagement/management.c. It's not used. > - Remove throw_internal_error() from src/jdk.management/share/native/libmanagement_ext/management_ext.h and src/jdk.management/share/native/libmanagement_ext/management_ext.c. Gentle ping, please help review this PR. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13497#issuecomment-1520559203 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mpowers at openjdk.org Mon Apr 24 22:45:13 2023 From: mpowers at openjdk.org (Mark Powers) Date: Mon, 24 Apr 2023 22:45:13 GMT Subject: RFR: 8306033: Resolve multiple definition of 'throwIOException' and friends when statically linking with JDK native libraries In-Reply-To: References: Message-ID: On Mon, 17 Apr 2023 16:56:31 GMT, Jiangli Zhou wrote: > - Make functions 'static' when feasible: > - throwByName() in src/java.security.jgss/share/native/libj2gss/NativeUtil.c. > - throwByName(), throwIOException() and throwNullPointerException() in src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c. > - throwByName() in src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c. > - throwOutOfMemoryError() in src/java.smartcardio/share/native/libj2pcsc/pcsc.c. > - Move throwDisconnectedRuntimeException() to src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c since it's only used in the file. Make it static. > - Move throw_internal_error() to src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c as it's only used in the file. Make it static. > > - Rename functions by following the existing naming usages in different libraries code: > - Rename throwOutOfMemoryError() to gssThrowOutOfMemoryError() in libj2gss. > - Rename throwOutOfMemoryError() to p11ThrowOutOfMemoryError() in libj2pks11. > - Rename throwNullPointerException() to p11ThrowNullPointerException() in libj2pks11. > - Rename throwIOException() to p11ThrowIOException() in libj2pks11. > - Rename throwPKCS11RuntimeException() to p11ThrowPKCS11RuntimeException() in libj2pks11. This function only exists in libj2pks11. The rename is done so the function naming is consistent with the other throw functions. > > - Remove throw_internal_error() from src/java.management/share/native/libmanagement/management.h and src/java.management/share/native/libmanagement/management.c. It's not used. > - Remove throw_internal_error() from src/jdk.management/share/native/libmanagement_ext/management_ext.h and src/jdk.management/share/native/libmanagement_ext/management_ext.c. Update copyrights to 2023. src/java.security.jgss/share/native/libj2gss/GSSLibStub.c line 201: > 199: cb = malloc(sizeof(struct gss_channel_bindings_struct)); > 200: if (cb == NULL) { > 201: gssThrowOutOfMemoryError(env,NULL); While you're fixing this, add a space between arguments, e.g. `(env,NULL) `becomes `(env, NULL)`. src/java.security.jgss/share/native/libj2gss/NativeUtil.c line 456: > 454: > 455: /* Throws a Java Exception by name */ > 456: static void throwByName(JNIEnv *env, const char *name, const char *msg) { Why can't you move the few lines of `throwByName()` into `gssThrowOutOfMemoryError()` and totally remove `throwByName()`? ------------- PR Review: https://git.openjdk.org/jdk/pull/13497#pullrequestreview-1398895019 PR Review Comment: https://git.openjdk.org/jdk/pull/13497#discussion_r1175839776 PR Review Comment: https://git.openjdk.org/jdk/pull/13497#discussion_r1175840162 From jiangli at openjdk.org Tue Apr 25 00:47:17 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 25 Apr 2023 00:47:17 GMT Subject: RFR: 8306033: Resolve multiple definition of 'throwIOException' and friends when statically linking with JDK native libraries [v2] In-Reply-To: References: Message-ID: > - Make functions 'static' when feasible: > - throwByName() in src/java.security.jgss/share/native/libj2gss/NativeUtil.c. > - throwByName(), throwIOException() and throwNullPointerException() in src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c. > - throwByName() in src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c. > - throwOutOfMemoryError() in src/java.smartcardio/share/native/libj2pcsc/pcsc.c. > - Move throwDisconnectedRuntimeException() to src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c since it's only used in the file. Make it static. > - Move throw_internal_error() to src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c as it's only used in the file. Make it static. > > - Rename functions by following the existing naming usages in different libraries code: > - Rename throwOutOfMemoryError() to gssThrowOutOfMemoryError() in libj2gss. > - Rename throwOutOfMemoryError() to p11ThrowOutOfMemoryError() in libj2pks11. > - Rename throwNullPointerException() to p11ThrowNullPointerException() in libj2pks11. > - Rename throwIOException() to p11ThrowIOException() in libj2pks11. > - Rename throwPKCS11RuntimeException() to p11ThrowPKCS11RuntimeException() in libj2pks11. This function only exists in libj2pks11. The rename is done so the function naming is consistent with the other throw functions. > > - Remove throw_internal_error() from src/java.management/share/native/libmanagement/management.h and src/java.management/share/native/libmanagement/management.c. It's not used. > - Remove throw_internal_error() from src/jdk.management/share/native/libmanagement_ext/management_ext.h and src/jdk.management/share/native/libmanagement_ext/management_ext.c. Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: Minor updates, as suggested by mcpowers: - Update copyright headers in affected files. - Formatting update in src/java.security.jgss/share/native/libj2gss/GSSLibStub.c. - Remove throwByName() and move the logic into gssThrowOutOfMemoryError() (the only caller) in src/java.security.jgss/share/native/libj2gss/NativeUtil.c. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13497/files - new: https://git.openjdk.org/jdk/pull/13497/files/9d319df6..fcb35192 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13497&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13497&range=00-01 Stats: 35 lines in 25 files changed: 0 ins; 6 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/13497.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13497/head:pull/13497 PR: https://git.openjdk.org/jdk/pull/13497 From jiangli at openjdk.org Tue Apr 25 00:47:20 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 25 Apr 2023 00:47:20 GMT Subject: RFR: 8306033: Resolve multiple definition of 'throwIOException' and friends when statically linking with JDK native libraries [v2] In-Reply-To: References: Message-ID: <4ezRtZpp6IfNoO_w2nyu2FA9GAy5k8FUrppmfd0pCqQ=.36ad7365-ae7f-40af-b0ff-86f1cfc60175@github.com> On Mon, 24 Apr 2023 22:41:53 GMT, Mark Powers wrote: > Update copyrights to 2023. Done, thanks. > src/java.security.jgss/share/native/libj2gss/GSSLibStub.c line 201: > >> 199: cb = malloc(sizeof(struct gss_channel_bindings_struct)); >> 200: if (cb == NULL) { >> 201: gssThrowOutOfMemoryError(env,NULL); > > While you're fixing this, add a space between arguments, e.g. `(env,NULL) `becomes `(env, NULL)`. Done, thanks. > src/java.security.jgss/share/native/libj2gss/NativeUtil.c line 456: > >> 454: >> 455: /* Throws a Java Exception by name */ >> 456: static void throwByName(JNIEnv *env, const char *name, const char *msg) { > > Why can't you move the few lines of `throwByName()` into `gssThrowOutOfMemoryError()` and totally remove `throwByName()`? Updated as suggested, thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13497#issuecomment-1521007212 PR Review Comment: https://git.openjdk.org/jdk/pull/13497#discussion_r1175910048 PR Review Comment: https://git.openjdk.org/jdk/pull/13497#discussion_r1175910110 From lmesnik at openjdk.org Tue Apr 25 01:46:06 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 25 Apr 2023 01:46:06 GMT Subject: RFR: 8233725: ProcessTools.startProcess() has output issues when using an OutputAnalyzer at the same time In-Reply-To: References: Message-ID: <30GUv37oCfNRntrXrUJHeG8tJ1km_2QkB2lptFzNz_s=.b342898f-ecce-4f41-9869-01bf3e97d29c@github.com> On Mon, 24 Apr 2023 20:57:31 GMT, Chris Plummer wrote: >> ProcessTools.startProcess() creates process and read it's output error streams. So the any other using of corresponding Process.getInputStream() and Process.getErrorStream() doesn't get process streams. >> >> This fix preserve process streams content and allow to read reuse the date. The ByteArrayOutputStream is used as a buffer. >> It stores all process output, never trying to clean date which has been read. >> >> The regression test has been provided with issue. >> >> I closed previous PR https://github.com/openjdk/jdk/pull/13560 by mistake instead of updating it. >> >> I run all tests to ensure that no failures are introduced. > > test/lib/jdk/test/lib/process/ProcessTools.java line 249: > >> 247: stdout.addOutputStream(out.getOutputStream()); >> 248: stderr.addOutputStream(err.getOutputStream()); >> 249: > > Overall this looks good, although I'm a bit unclear on how some of the underpinnings work, allowing the output to appear in these output streams, and also in the LineForwarder output (above), and for that matter, in the lineConsumer output (below). I guess there is some multiplexing of the output that I just don't grasp, but appears to be something that already worked. StreamPumper read process stdout, stderr streams and write read data to registered streams. So it works as multiplexer. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13594#discussion_r1175930914 From sspitsyn at openjdk.org Tue Apr 25 02:19:18 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 25 Apr 2023 02:19:18 GMT Subject: RFR: 8306034: add support of virtual threads to JVMTI StopThread [v2] In-Reply-To: References: <70mPVNX3n2TUacbWW0JDIfTNEACwzppdyY5PzYZxdRY=.749a3e99-be99-45ab-a688-e9c563dd5182@github.com> Message-ID: On Mon, 24 Apr 2023 20:26:31 GMT, Chris Plummer wrote: >> The scenario that I'm wondering about is where a virtual thread is resumed at around the same time that JVMTI StopThread is called. Not easy to test. > > Seems we should have a stress test for that. > The scenario that I'm wondering about is where a virtual thread is resumed > at around the same time that JVMTI StopThread is called. This kind of scenario is not typical. The debugger should keep virtual thread suspended when making a call to JVMTI StopThread. Normally, this kind of race should never happen with the JDWP agent. Chris, why do you think it is important to have a stress test for this? Also, do you have any testing scenario in mind? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13546#discussion_r1175944953 From sspitsyn at openjdk.org Tue Apr 25 03:09:08 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 25 Apr 2023 03:09:08 GMT Subject: RFR: 8233725: ProcessTools.startProcess() has output issues when using an OutputAnalyzer at the same time In-Reply-To: References: Message-ID: <4EDhpXuaKhviIcVGoDrPbVzcdze_pl4rJZu6DQvWeAw=.f5a9a485-3bb2-4f2b-8b65-e3d35eae1001@github.com> On Fri, 21 Apr 2023 21:43:39 GMT, Leonid Mesnik wrote: > ProcessTools.startProcess() creates process and read it's output error streams. So the any other using of corresponding Process.getInputStream() and Process.getErrorStream() doesn't get process streams. > > This fix preserve process streams content and allow to read reuse the date. The ByteArrayOutputStream is used as a buffer. > It stores all process output, never trying to clean date which has been read. > > The regression test has been provided with issue. > > I closed previous PR https://github.com/openjdk/jdk/pull/13560 by mistake instead of updating it. > > I run all tests to ensure that no failures are introduced. test/lib/jdk/test/lib/process/ProcessTools.java line 792: > 790: @Override > 791: public InputStream getInputStream() { > 792: return out; This is a little bit confusing that the `getInputStream()` returns `out` stream. Just wanted to double-check if it is intentional and was not needed for `getOutputStream()` instead. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13594#discussion_r1175965035 From cjplummer at openjdk.org Tue Apr 25 03:52:07 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 25 Apr 2023 03:52:07 GMT Subject: RFR: 8306034: add support of virtual threads to JVMTI StopThread [v2] In-Reply-To: References: <70mPVNX3n2TUacbWW0JDIfTNEACwzppdyY5PzYZxdRY=.749a3e99-be99-45ab-a688-e9c563dd5182@github.com> Message-ID: <7mPRSjn63r8Of6T5JG-cc7wWRiQ8ZEY_LbY6aKqAg1s=.a7cd70c7-e431-45de-9bf8-84546e098674@github.com> On Tue, 25 Apr 2023 02:15:54 GMT, Serguei Spitsyn wrote: >> Seems we should have a stress test for that. > >> The scenario that I'm wondering about is where a virtual thread is resumed >> at around the same time that JVMTI StopThread is called. > > This kind of scenario is not typical. > The debugger should keep virtual thread suspended when making a call to JVMTI StopThread. > Normally, this kind of race should never happen with the JDWP agent. > Chris, why do you think it is important to have a stress test for this? > Also, do you have any testing scenario in mind? I guess if it is not something that would typically ever be done in realistic situations, then there is no need for a stress test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13546#discussion_r1175979665 From lmesnik at openjdk.org Tue Apr 25 04:08:06 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 25 Apr 2023 04:08:06 GMT Subject: RFR: 8233725: ProcessTools.startProcess() has output issues when using an OutputAnalyzer at the same time In-Reply-To: <4EDhpXuaKhviIcVGoDrPbVzcdze_pl4rJZu6DQvWeAw=.f5a9a485-3bb2-4f2b-8b65-e3d35eae1001@github.com> References: <4EDhpXuaKhviIcVGoDrPbVzcdze_pl4rJZu6DQvWeAw=.f5a9a485-3bb2-4f2b-8b65-e3d35eae1001@github.com> Message-ID: On Tue, 25 Apr 2023 03:06:09 GMT, Serguei Spitsyn wrote: >> ProcessTools.startProcess() creates process and read it's output error streams. So the any other using of corresponding Process.getInputStream() and Process.getErrorStream() doesn't get process streams. >> >> This fix preserve process streams content and allow to read reuse the date. The ByteArrayOutputStream is used as a buffer. >> It stores all process output, never trying to clean date which has been read. >> >> The regression test has been provided with issue. >> >> I closed previous PR https://github.com/openjdk/jdk/pull/13560 by mistake instead of updating it. >> >> I run all tests to ensure that no failures are introduced. > > test/lib/jdk/test/lib/process/ProcessTools.java line 792: > >> 790: @Override >> 791: public InputStream getInputStream() { >> 792: return out; > > This is a little bit confusing that the `getInputStream()` returns `out` stream. > Just wanted to double-check if it is intentional and was not needed for `getOutputStream()` instead. Agree, it is confusing, even in standard j.l.Process API . The `InputStream java.lang.Process.getInputStream()`" returns **output** stream of started process. So for our implementation ProcessImpl the 'out' and 'err' mean output and error streams. However they are returned as InputStreams so users could read them. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13594#discussion_r1175985058 From sspitsyn at openjdk.org Tue Apr 25 04:27:07 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 25 Apr 2023 04:27:07 GMT Subject: RFR: 8306034: add support of virtual threads to JVMTI StopThread [v4] In-Reply-To: References: Message-ID: > This enhancement adds support of virtual threads to the JVMTI `StopThread` function. > In preview releases before this enhancement the StopThread returned the JVMTI_ERROR_UNSUPPORTED_OPERATION error code for virtual threads. > > The `StopThread` supports sending an asynchronous exception to a virtual thread only if it is current or suspended at mounted state. For instance, a virtual thread can be suspended at a JVMTI event. If the virtual thread is not suspended and is not current then the `JVMTI_ERROR_THREAD_NOT_SUSPENDED` error code is returned. If the virtual thread was suspended at unmounted state then the `JVMTI_ERROR_OPAQUE_FRAME` error code is returned. > > The `StopThread` has the following description for `JVMTI_ERROR_OPAQUE_FRAME` error code: >> The thread is a suspended virtual thread and the implementation >> was unable to throw an asynchronous exception from this frame. > > A couple of the `serviceability/jvmti/vthread` tests has been updated to adopt to new `StopThread` behavior. > > The CSR is: https://bugs.openjdk.org/browse/JDK-8306434 > > Testing: > The mach5 tears 1-6 are in progress. > Preliminary test runs were good in general. > The JDB test `vmTestbase/nsk/jdb/kill/kill001/kill001.java` has been problem-listed and will be fixed by the corresponding debugger enhancement which is going to adopt JDWP/JDI specs to new behavior of the JVMTI `StopThread` related to virtual threads. > > Also, two JCK JVMTI tests are failing in the tier-6 : >> vm/jvmti/StopThread/stop001/stop00103/stop00103.html >> vm/jvmti/StopThread/stop001/stop00103/stop00103a.html > > These two tests will be excluded from the test runs by the JCK team and then adjusted to new `StopThread` behavior. Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: 1. Address review comments 2. Clear interrupt bit in the TestTaskThread ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13546/files - new: https://git.openjdk.org/jdk/pull/13546/files/d2cc010e..dbdb4edd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13546&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13546&range=02-03 Stats: 53 lines in 1 file changed: 31 ins; 7 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/13546.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13546/head:pull/13546 PR: https://git.openjdk.org/jdk/pull/13546 From sspitsyn at openjdk.org Tue Apr 25 04:36:09 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 25 Apr 2023 04:36:09 GMT Subject: RFR: 8306034: add support of virtual threads to JVMTI StopThread [v2] In-Reply-To: <7mPRSjn63r8Of6T5JG-cc7wWRiQ8ZEY_LbY6aKqAg1s=.a7cd70c7-e431-45de-9bf8-84546e098674@github.com> References: <70mPVNX3n2TUacbWW0JDIfTNEACwzppdyY5PzYZxdRY=.749a3e99-be99-45ab-a688-e9c563dd5182@github.com> <7mPRSjn63r8Of6T5JG-cc7wWRiQ8ZEY_LbY6aKqAg1s=.a7cd70c7-e431-45de-9bf8-84546e098674@github.com> Message-ID: On Tue, 25 Apr 2023 03:49:09 GMT, Chris Plummer wrote: >>> The scenario that I'm wondering about is where a virtual thread is resumed >>> at around the same time that JVMTI StopThread is called. >> >> This kind of scenario is not typical. >> The debugger should keep virtual thread suspended when making a call to JVMTI StopThread. >> Normally, this kind of race should never happen with the JDWP agent. >> Chris, why do you think it is important to have a stress test for this? >> Also, do you have any testing scenario in mind? > > I guess if it is not something that would typically ever be done in realistic situations, then there is no need for a stress test. Okay, thanks. I've extended the test to cover BoundVirtualThread's as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13546#discussion_r1175995873 From sspitsyn at openjdk.org Tue Apr 25 04:36:11 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 25 Apr 2023 04:36:11 GMT Subject: RFR: 8306034: add support of virtual threads to JVMTI StopThread [v3] In-Reply-To: References: <7nu2pq19SIw1me07wf4RnLEVErjYF3tnNnHZNcNWRlg=.8eb78564-8a56-4f59-a692-c7f79aef6ade@github.com> Message-ID: On Sat, 22 Apr 2023 00:09:27 GMT, Serguei Spitsyn wrote: >> For the JDI tests I added, I execute them in both modes, with the appropriate adjustments to account for the errors we except for virtual threads. We should be testing to make sure that StopThread works with platform threads under a variety of situations. > > Extending this test to cover platform threads does not look natural and is going to be a little ugly. > But I can extend it to provide coverage for BoundVirtualThread case > which is highjacking the platform thread implementation. > Would it help? > We should have pretty good coverage of the JVMTI `StopThread` for platform threads in `nsk.jvmti` test suite. > It includes: > - `stopthrd006` and `stopthrd007` > - a number of `scenarios/capability/CM01 `tests > > Also, this extension does not touch the code path of platform threads support. I've extended the test to cover platform threads as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13546#discussion_r1175995443 From sspitsyn at openjdk.org Tue Apr 25 10:17:10 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 25 Apr 2023 10:17:10 GMT Subject: RFR: 8306034: add support of virtual threads to JVMTI StopThread [v2] In-Reply-To: References: Message-ID: On Fri, 21 Apr 2023 13:33:53 GMT, Alan Bateman wrote: >> What does "suspended at an event" mean? As a programmer trying to use this how am I supposed to know when it can be used without getting an error? >> >> I find it very surprising that the error would occur with an unmounted thread - having a VT throw when it was remounted seems the most natural way to implement this. > > I think "suspended at an event" is okay. It means the callback for an event has been triggered and the agent suspended the thread. The typical use-case for JVMTI StopThread is when at a breakpoint or when single stepping and the user asks the debugger to throw some exception so that the code's handling of the exception can been debugged/tested. Debugger and JDWP agent aside, I don't know if there are other agents using this JVMTI function. If there are other and they call this function on some random virtual thread at some random time then the function will fail. > > One other point around this is that the plan is to have StopThread, ForceEarlyReturn, PopFrame and SetLocalXXX work more consistently. Right now, SetLocalXXX minimally requires a virtual thread be suspended at a breakpoint or single step event. The minimum support can be broader to be suspended at any event. Alan, thank you for explaining this. Resolving this conversation. David, please, reopen it if it is no okay with you. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13546#discussion_r1176306009 From tschatzl at openjdk.org Tue Apr 25 13:57:20 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 25 Apr 2023 13:57:20 GMT Subject: RFR: 8306836: Remove pinned tag for G1 heap regions Message-ID: Hi all, please review this change that removes the pinned tag from `HeapRegion`. So that "pinned" tag for G1 heap regions indicates that the region should not move during (young) gc. This applies to now removed archive regions and humongous objects/regions. With "real" g1 region pinning to deal with gclocker in g1 once and for all upcoming we need a refcount, a single bit is not sufficient anymore. Further there will be a naming conflict as this kind of "pinning" is different to g1 region pinning "pinning". The former indicates "contents can not be moved, but can be reclaimed", while the latter means "contents can not be moved and not reclaimed". The (current) pinned flag is surprisingly little used, only for policy decisions. The suggestion this change implements is to remove the "pinned" tag as it is, and reserve it for future g1 region pinning (that needs to store the pinning attribute differently anyway). Testing: tier1-3, gha Thanks, Thomas ------------- Commit messages: - Fix hsdb - compilation fixes - Initial implementation Changes: https://git.openjdk.org/jdk/pull/13643/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13643&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306836 Stats: 66 lines in 20 files changed: 16 ins; 22 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/13643.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13643/head:pull/13643 PR: https://git.openjdk.org/jdk/pull/13643 From ayang at openjdk.org Tue Apr 25 15:10:15 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 25 Apr 2023 15:10:15 GMT Subject: RFR: 8306836: Remove pinned tag for G1 heap regions In-Reply-To: References: Message-ID: <7a8WQxuLeLXBx9EGCq2ntzVZvEgdGrDl6UJKtS3I4a0=.69144425-8a3d-4e66-95a7-f6dbb36e875a@github.com> On Tue, 25 Apr 2023 13:49:05 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that removes the pinned tag from `HeapRegion`. > > So that "pinned" tag for G1 heap regions indicates that the region should not move during (young) gc. This applies to now removed archive regions and humongous objects/regions. > > With "real" g1 region pinning to deal with gclocker in g1 once and for all upcoming we need a refcount, a single bit is not sufficient anymore. Further there will be a naming conflict as this kind of "pinning" is different to g1 region pinning "pinning". The former indicates "contents can not be moved, but can be reclaimed", while the latter means "contents can not be moved and not reclaimed". > > The (current) pinned flag is surprisingly little used, only for policy decisions. > > The suggestion this change implements is to remove the "pinned" tag as it is, and reserve it for future g1 region pinning (that needs to store the pinning attribute differently as a refcount anyway). > > Testing: tier1-3, gha > > Thanks, > Thomas The name, `is_young_gc_movable`, seems to suggest it is context sensitive. Maybe it's clearer if it's not defined as an API of heap-region, like other region-type-predicates. For example, it's odd to see them on the same abstraction level, when the two APIs refer to sth quite different. assert(hr->is_young_gc_movable(), "Should only be movable region in compaction queue"); assert(!hr->is_humongous(), "Should be no humongous regions in compaction queue"); Additionally, it's confusing to see sth named "*young_gc*" in full-gc code (`g1FullGCPrepareTask.inline.hpp`). For this particular PR, could one just use `!hr->is_humongous()` where `is_young_gc_movable` is used? (Essentially, inlining the new API.) src/hotspot/share/gc/g1/g1HeapVerifier.cpp line 414: > 412: // There are no other valid region types. Check for one invalid > 413: // one we can identify before crashing: non-movable. > 414: assert(hr->is_young_gc_movable(), "Heap region %u is non-movable.", hr->hrm_index()); Given this branch is unreachable, can one just use `fatal(...)` without a predicate? ------------- PR Review: https://git.openjdk.org/jdk/pull/13643#pullrequestreview-1400139894 PR Review Comment: https://git.openjdk.org/jdk/pull/13643#discussion_r1176660073 From tschatzl at openjdk.org Tue Apr 25 15:33:07 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 25 Apr 2023 15:33:07 GMT Subject: RFR: 8306836: Remove pinned tag for G1 heap regions In-Reply-To: <7a8WQxuLeLXBx9EGCq2ntzVZvEgdGrDl6UJKtS3I4a0=.69144425-8a3d-4e66-95a7-f6dbb36e875a@github.com> References: <7a8WQxuLeLXBx9EGCq2ntzVZvEgdGrDl6UJKtS3I4a0=.69144425-8a3d-4e66-95a7-f6dbb36e875a@github.com> Message-ID: On Tue, 25 Apr 2023 15:05:10 GMT, Albert Mingkun Yang wrote: >> Hi all, >> >> please review this change that removes the pinned tag from `HeapRegion`. >> >> So that "pinned" tag for G1 heap regions indicates that the region should not move during (young) gc. This applies to now removed archive regions and humongous objects/regions. >> >> With "real" g1 region pinning to deal with gclocker in g1 once and for all upcoming we need a refcount, a single bit is not sufficient anymore. Further there will be a naming conflict as this kind of "pinning" is different to g1 region pinning "pinning". The former indicates "contents can not be moved, but can be reclaimed", while the latter means "contents can not be moved and not reclaimed". >> >> The (current) pinned flag is surprisingly little used, only for policy decisions. >> >> The suggestion this change implements is to remove the "pinned" tag as it is, and reserve it for future g1 region pinning (that needs to store the pinning attribute differently as a refcount anyway). >> >> Testing: tier1-3, gha >> >> Thanks, >> Thomas > > src/hotspot/share/gc/g1/g1HeapVerifier.cpp line 414: > >> 412: // There are no other valid region types. Check for one invalid >> 413: // one we can identify before crashing: non-movable. >> 414: assert(hr->is_young_gc_movable(), "Heap region %u is non-movable.", hr->hrm_index()); > > Given this branch is unreachable, can one just use `fatal(...)` without a predicate? >The name, is_young_gc_movable, seems to suggest it is context sensitive. Maybe it's clearer if it's not defined as an API of heap-region, like other region-type-predicates. It is defined in `G1Policy`, there is simply a shortcut via `HeapRegion`. I considered removing that shortcut in `HeapRegion`, but then this would mean lots of clutter everywhere to get to the policy object. I will find a better location for a helper. > >For example, it's odd to see them on the same abstraction level, when the two APIs refer to sth quite different. > > assert(hr->is_young_gc_movable(), "Should only be movable region in compaction queue"); > assert(!hr->is_humongous(), "Should be no humongous regions in compaction queue"); > >Additionally, it's confusing to see sth named "young_gc" in full-gc code (g1FullGCPrepareTask.inline.hpp). I was too lazy to wrap it in a "movable-during-first-full-gc-attempt" method, will fix. I thought the comment would be enough. > >For this particular PR, could one just use !hr->is_humongous() where is_young_gc_movable is used? (Essentially, inlining >the new API.) I do not like inlining this API because this looses the documentation of this condition. One would probably need to add a "(At the moment) Humongous regions are non-movable." comment everywhere to understand why that condition is there. Thanks, Thomas ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13643#discussion_r1176691594 From tschatzl at openjdk.org Tue Apr 25 15:33:08 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 25 Apr 2023 15:33:08 GMT Subject: RFR: 8306836: Remove pinned tag for G1 heap regions In-Reply-To: References: <7a8WQxuLeLXBx9EGCq2ntzVZvEgdGrDl6UJKtS3I4a0=.69144425-8a3d-4e66-95a7-f6dbb36e875a@github.com> Message-ID: On Tue, 25 Apr 2023 15:29:08 GMT, Thomas Schatzl wrote: >> src/hotspot/share/gc/g1/g1HeapVerifier.cpp line 414: >> >>> 412: // There are no other valid region types. Check for one invalid >>> 413: // one we can identify before crashing: non-movable. >>> 414: assert(hr->is_young_gc_movable(), "Heap region %u is non-movable.", hr->hrm_index()); >> >> Given this branch is unreachable, can one just use `fatal(...)` without a predicate? > >>The name, is_young_gc_movable, seems to suggest it is context sensitive. Maybe it's clearer if it's not defined as an API of heap-region, like other region-type-predicates. > > It is defined in `G1Policy`, there is simply a shortcut via `HeapRegion`. I considered removing that shortcut in `HeapRegion`, but then this would mean lots of clutter everywhere to get to the policy object. > > I will find a better location for a helper. > >> >>For example, it's odd to see them on the same abstraction level, when the two APIs refer to sth quite different. >> >> assert(hr->is_young_gc_movable(), "Should only be movable region in compaction queue"); >> assert(!hr->is_humongous(), "Should be no humongous regions in compaction queue"); >> >>Additionally, it's confusing to see sth named "young_gc" in full-gc code (g1FullGCPrepareTask.inline.hpp). > > I was too lazy to wrap it in a "movable-during-first-full-gc-attempt" method, will fix. I thought the comment would be enough. > >> >>For this particular PR, could one just use !hr->is_humongous() where is_young_gc_movable is used? (Essentially, inlining >the new API.) > > I do not like inlining this API because this looses the documentation of this condition. One would probably need to add a "(At the moment) Humongous regions are non-movable." comment everywhere to understand why that condition is there. > > Thanks, > Thomas > Given this branch is unreachable, can one just use `fatal(...)` without a predicate? I also thought about this: the purpose of the additional assert is/was (I think) to fail with a better message than just crashing with some nondescript message, filtering out other possible cases. Will remove this after all. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13643#discussion_r1176693623 From dcubed at openjdk.org Tue Apr 25 15:53:00 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 25 Apr 2023 15:53:00 GMT Subject: RFR: 8233725: ProcessTools.startProcess() has output issues when using an OutputAnalyzer at the same time In-Reply-To: References: <4EDhpXuaKhviIcVGoDrPbVzcdze_pl4rJZu6DQvWeAw=.f5a9a485-3bb2-4f2b-8b65-e3d35eae1001@github.com> Message-ID: <6ABDu4g-9JNwmdQpdmOXIbz6WUApspGnmHlMk7BhZ6I=.d11f2bc4-c895-4162-9b35-9f2a0d7be519@github.com> On Tue, 25 Apr 2023 04:05:05 GMT, Leonid Mesnik wrote: >> test/lib/jdk/test/lib/process/ProcessTools.java line 792: >> >>> 790: @Override >>> 791: public InputStream getInputStream() { >>> 792: return out; >> >> This is a little bit confusing that the `getInputStream()` returns `out` stream. >> Just wanted to double-check if it is intentional and was not needed for `getOutputStream()` instead. > > Agree, it is confusing, even in standard j.l.Process API . The `InputStream java.lang.Process.getInputStream()`" returns **output** stream of started process. So for our implementation ProcessImpl the 'out' and 'err' mean output and error streams. However they are returned as InputStreams so users could read them. Right. From the API caller's POV, it is asking for InputStreams that it can use to read the process' stdout or stderr streams. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13594#discussion_r1176718448 From tschatzl at openjdk.org Tue Apr 25 15:59:05 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 25 Apr 2023 15:59:05 GMT Subject: RFR: 8306836: Remove pinned tag for G1 heap regions [v2] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that removes the pinned tag from `HeapRegion`. > > So that "pinned" tag for G1 heap regions indicates that the region should not move during (young) gc. This applies to now removed archive regions and humongous objects/regions. > > With "real" g1 region pinning to deal with gclocker in g1 once and for all upcoming we need a refcount, a single bit is not sufficient anymore. Further there will be a naming conflict as this kind of "pinning" is different to g1 region pinning "pinning". The former indicates "contents can not be moved, but can be reclaimed", while the latter means "contents can not be moved and not reclaimed". > > The (current) pinned flag is surprisingly little used, only for policy decisions. > > The suggestion this change implements is to remove the "pinned" tag as it is, and reserve it for future g1 region pinning (that needs to store the pinning attribute differently as a refcount anyway). > > Testing: tier1-3, gha > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: ayang review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13643/files - new: https://git.openjdk.org/jdk/pull/13643/files/c0345927..4b736512 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13643&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13643&range=00-01 Stats: 24 lines in 12 files changed: 0 ins; 11 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/13643.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13643/head:pull/13643 PR: https://git.openjdk.org/jdk/pull/13643 From sspitsyn at openjdk.org Tue Apr 25 18:18:10 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 25 Apr 2023 18:18:10 GMT Subject: RFR: 8306823: Native memory leak in SharedRuntime::notify_jvmti_unmount/mount. In-Reply-To: <5pnvV5z6BaaPhKb0UWkA5wEu3FfaKZfepYGXtMx_tDk=.da25228a-18bf-450d-a5dd-c5114d5f046c@github.com> References: <5pnvV5z6BaaPhKb0UWkA5wEu3FfaKZfepYGXtMx_tDk=.da25228a-18bf-450d-a5dd-c5114d5f046c@github.com> Message-ID: On Tue, 25 Apr 2023 13:19:36 GMT, Martin Doerr wrote: > The code introduced by [JDK-8304303](https://bugs.openjdk.org/browse/JDK-8304303) uses `JNIHandles::make_local` which requires `JNIHandles::destroy_local` which is currently missing. Looks good. Thank you for taking care about it. Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13641#pullrequestreview-1400466729 From cjplummer at openjdk.org Tue Apr 25 18:25:09 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 25 Apr 2023 18:25:09 GMT Subject: RFR: 8306858: Remove some remnants of CMS from SA agent In-Reply-To: References: Message-ID: On Tue, 25 Apr 2023 16:25:40 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that removes some remaining CMS related stuff. > > Testing: tier1-3, gha > > Thanks, > Thomas Marked as reviewed by cjplummer (Reviewer). Copyrights need updating ------------- PR Review: https://git.openjdk.org/jdk/pull/13646#pullrequestreview-1400476463 Changes requested by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13646#pullrequestreview-1400478623 From sspitsyn at openjdk.org Tue Apr 25 18:27:18 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 25 Apr 2023 18:27:18 GMT Subject: RFR: 8306034: add support of virtual threads to JVMTI StopThread [v5] In-Reply-To: References: Message-ID: > This enhancement adds support of virtual threads to the JVMTI `StopThread` function. > In preview releases before this enhancement the StopThread returned the JVMTI_ERROR_UNSUPPORTED_OPERATION error code for virtual threads. > > The `StopThread` supports sending an asynchronous exception to a virtual thread only if it is current or suspended at mounted state. For instance, a virtual thread can be suspended at a JVMTI event. If the virtual thread is not suspended and is not current then the `JVMTI_ERROR_THREAD_NOT_SUSPENDED` error code is returned. If the virtual thread was suspended at unmounted state then the `JVMTI_ERROR_OPAQUE_FRAME` error code is returned. > > The `StopThread` has the following description for `JVMTI_ERROR_OPAQUE_FRAME` error code: >> The thread is a suspended virtual thread and the implementation >> was unable to throw an asynchronous exception from this frame. > > A couple of the `serviceability/jvmti/vthread` tests has been updated to adopt to new `StopThread` behavior. > > The CSR is: https://bugs.openjdk.org/browse/JDK-8306434 > > Testing: > The mach5 tears 1-6 are in progress. > Preliminary test runs were good in general. > The JDB test `vmTestbase/nsk/jdb/kill/kill001/kill001.java` has been problem-listed and will be fixed by the corresponding debugger enhancement which is going to adopt JDWP/JDI specs to new behavior of the JVMTI `StopThread` related to virtual threads. > > Also, two JCK JVMTI tests are failing in the tier-6 : >> vm/jvmti/StopThread/stop001/stop00103/stop00103.html >> vm/jvmti/StopThread/stop001/stop00103/stop00103a.html > > These two tests will be excluded from the test runs by the JCK team and then adjusted to new `StopThread` behavior. Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: minor tweak in new test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13546/files - new: https://git.openjdk.org/jdk/pull/13546/files/dbdb4edd..956e8ee8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13546&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13546&range=03-04 Stats: 4 lines in 1 file changed: 2 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13546.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13546/head:pull/13546 PR: https://git.openjdk.org/jdk/pull/13546 From cjplummer at openjdk.org Tue Apr 25 18:35:12 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 25 Apr 2023 18:35:12 GMT Subject: RFR: 8306836: Remove pinned tag for G1 heap regions [v2] In-Reply-To: References: Message-ID: On Tue, 25 Apr 2023 15:59:05 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that removes the pinned tag from `HeapRegion`. >> >> So that "pinned" tag for G1 heap regions indicates that the region should not move during (young) gc. This applies to now removed archive regions and humongous objects/regions. >> >> With "real" g1 region pinning to deal with gclocker in g1 once and for all upcoming we need a refcount, a single bit is not sufficient anymore. Further there will be a naming conflict as this kind of "pinning" is different to g1 region pinning "pinning". The former indicates "contents can not be moved, but can be reclaimed", while the latter means "contents can not be moved and not reclaimed". >> >> The (current) pinned flag is surprisingly little used, only for policy decisions. >> >> The suggestion this change implements is to remove the "pinned" tag as it is, and reserve it for future g1 region pinning (that needs to store the pinning attribute differently as a refcount anyway). >> >> Testing: tier1-3, gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > ayang review A few files need copyright updates src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/HSDB.java line 1109: > 1107: } else if (region.isPinned()) { > 1108: anno = "Pinned "; > 1109: bad = false; Does this mean that the region will now always be one of Free, Young, Humongous, or Old? ------------- PR Review: https://git.openjdk.org/jdk/pull/13643#pullrequestreview-1400494547 PR Review Comment: https://git.openjdk.org/jdk/pull/13643#discussion_r1176886830 From cjplummer at openjdk.org Tue Apr 25 19:16:07 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 25 Apr 2023 19:16:07 GMT Subject: RFR: 8306471: Add virtual threads support to JDWP ThreadReference.Stop and JDI ThreadReference.stop() Message-ID: <2iIOo1G9Tr-U5dzL82xfGQ5CkEA0V40nGXpKzmST_BM=.9b0ab2ed-996f-4163-b5e2-45a70ff18d9a@github.com> Note this PR depends on the #13546 PR for the following: [JDK-8306434](https://bugs.openjdk.org/browse/JDK-8306434): add support of virtual threads to JVMTI StopThread So it can't be finalized and push until after JDK-8306434 is pushed. There will also be GHA failures until then. If JDK-8306434 results in any additional spec changes, they will likely impact this CR also. [JDK-8306034](https://bugs.openjdk.org/browse/JDK-8306034) is adding some virtual thread support to JVMTI StopThread. This will allow JDWP ThreadReference.Stop and JDI ThreadReference.stop() to have the same level support for virtual threads. Mostly this is a spec update for JDWP and JDI, but there are also some minor changes needed to the ThreadReference.stop() handling of JDWP errors, and throwing the appropriate exceptions. Also some minor cleanup in jdb. The debug agent doesn't need changes since JVMTI errors are just passed through as the corresponding JDWP errors, and the code for this is already in place. These errors are not new nor need any special handling. Our existing testing for ThreadReference.stop() is fairly weak: - nsk/jdb/kill/kill001, which tests stop() when the thread is suspended at a breakpoint. It will get problem listed by [JDK-8306034](https://bugs.openjdk.org/browse/JDK-8306034). I have fixes for it already working and will push it separately. - nsk/jdi/stop/stop001, which is problem listed and only tests when the thread is blocked in Object.wait() - nsk/jdi/stop/stop002, which only tests that throwing an invalid exception fails properly I decided to take stop002 and make it a more thorough test of ThreadReference.stop(). See the comment at the top for a list of what is tested. As for reviewing this test, it's probably best to look at it as a completely new test rather than looking at diffs since so much has been changed and added. ------------- Commit messages: - fix some jcheck whitespace errors - minor formatting fixes - minor JDWP spec wording change - JDWP and JDI support for stop() of a virtual thread. Changes: https://git.openjdk.org/jdk/pull/13548/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13548&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306471 Stats: 335 lines in 7 files changed: 258 ins; 13 del; 64 mod Patch: https://git.openjdk.org/jdk/pull/13548.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13548/head:pull/13548 PR: https://git.openjdk.org/jdk/pull/13548 From alanb at openjdk.org Tue Apr 25 19:16:09 2023 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 25 Apr 2023 19:16:09 GMT Subject: RFR: 8306471: Add virtual threads support to JDWP ThreadReference.Stop and JDI ThreadReference.stop() In-Reply-To: <2iIOo1G9Tr-U5dzL82xfGQ5CkEA0V40nGXpKzmST_BM=.9b0ab2ed-996f-4163-b5e2-45a70ff18d9a@github.com> References: <2iIOo1G9Tr-U5dzL82xfGQ5CkEA0V40nGXpKzmST_BM=.9b0ab2ed-996f-4163-b5e2-45a70ff18d9a@github.com> Message-ID: On Wed, 19 Apr 2023 23:40:56 GMT, Chris Plummer wrote: > Note this PR depends on the #13546 PR for the following: > > [JDK-8306434](https://bugs.openjdk.org/browse/JDK-8306434): add support of virtual threads to JVMTI StopThread > > So it can't be finalized and push until after JDK-8306434 is pushed. There will also be GHA failures until then. If JDK-8306434 results in any additional spec changes, they will likely impact this CR also. > > > [JDK-8306034](https://bugs.openjdk.org/browse/JDK-8306034) is adding some virtual thread support to JVMTI StopThread. This will allow JDWP ThreadReference.Stop and JDI ThreadReference.stop() to have the same level support for virtual threads. > > Mostly this is a spec update for JDWP and JDI, but there are also some minor changes needed to the ThreadReference.stop() handling of JDWP errors, and throwing the appropriate exceptions. Also some minor cleanup in jdb. The debug agent doesn't need changes since JVMTI errors are just passed through as the corresponding JDWP errors, and the code for this is already in place. These errors are not new nor need any special handling. > > Our existing testing for ThreadReference.stop() is fairly weak: > > - nsk/jdb/kill/kill001, which tests stop() when the thread is suspended at a breakpoint. It will get problem listed by [JDK-8306034](https://bugs.openjdk.org/browse/JDK-8306034). I have fixes for it already working and will push it separately. > - nsk/jdi/stop/stop001, which is problem listed and only tests when the thread is blocked in Object.wait() > - nsk/jdi/stop/stop002, which only tests that throwing an invalid exception fails properly > > I decided to take stop002 and make it a more thorough test of ThreadReference.stop(). See the comment at the top for a list of what is tested. As for reviewing this test, it's probably best to look at it as a completely new test rather than looking at diffs since so much has been changed and added. src/java.se/share/data/jdwp/jdwp.spec line 2010: > 2008: "exception to a virtual thread when it is suspended at an event. " > 2009: "An implementation may support sending an asynchronous exception " > 2010: "to a suspended virtual thread in other cases." "The ThreadReference.Stop command may ...". I don't think the JDWP spec refers to commands links this, maybe just change it to "This command may ...". Otherwise the wording looks good. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13548#discussion_r1172812439 From aturbanov at openjdk.org Tue Apr 25 19:16:15 2023 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Tue, 25 Apr 2023 19:16:15 GMT Subject: RFR: 8306471: Add virtual threads support to JDWP ThreadReference.Stop and JDI ThreadReference.stop() In-Reply-To: <2iIOo1G9Tr-U5dzL82xfGQ5CkEA0V40nGXpKzmST_BM=.9b0ab2ed-996f-4163-b5e2-45a70ff18d9a@github.com> References: <2iIOo1G9Tr-U5dzL82xfGQ5CkEA0V40nGXpKzmST_BM=.9b0ab2ed-996f-4163-b5e2-45a70ff18d9a@github.com> Message-ID: On Wed, 19 Apr 2023 23:40:56 GMT, Chris Plummer wrote: > Note this PR depends on the #13546 PR for the following: > > [JDK-8306434](https://bugs.openjdk.org/browse/JDK-8306434): add support of virtual threads to JVMTI StopThread > > So it can't be finalized and push until after JDK-8306434 is pushed. There will also be GHA failures until then. If JDK-8306434 results in any additional spec changes, they will likely impact this CR also. > > > [JDK-8306034](https://bugs.openjdk.org/browse/JDK-8306034) is adding some virtual thread support to JVMTI StopThread. This will allow JDWP ThreadReference.Stop and JDI ThreadReference.stop() to have the same level support for virtual threads. > > Mostly this is a spec update for JDWP and JDI, but there are also some minor changes needed to the ThreadReference.stop() handling of JDWP errors, and throwing the appropriate exceptions. Also some minor cleanup in jdb. The debug agent doesn't need changes since JVMTI errors are just passed through as the corresponding JDWP errors, and the code for this is already in place. These errors are not new nor need any special handling. > > Our existing testing for ThreadReference.stop() is fairly weak: > > - nsk/jdb/kill/kill001, which tests stop() when the thread is suspended at a breakpoint. It will get problem listed by [JDK-8306034](https://bugs.openjdk.org/browse/JDK-8306034). I have fixes for it already working and will push it separately. > - nsk/jdi/stop/stop001, which is problem listed and only tests when the thread is blocked in Object.wait() > - nsk/jdi/stop/stop002, which only tests that throwing an invalid exception fails properly > > I decided to take stop002 and make it a more thorough test of ThreadReference.stop(). See the comment at the top for a list of what is tested. As for reviewing this test, it's probably best to look at it as a completely new test rather than looking at diffs since so much has been changed and added. test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/stop/stop002.java line 169: > 167: thrRef.stop(throwableRef); > 168: log.display("TEST #2 PASSED: stop() call succeeded."); > 169: } catch(Exception ue) { nit Suggestion: } catch (Exception ue) { test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/stop/stop002.java line 192: > 190: log.display("TEST #3 PASSED: stop() call succeeded."); > 191: } > 192: } catch(Exception ue) { nit Suggestion: } catch (Exception ue) { test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/stop/stop002.java line 223: > 221: log.display("TEST #4 PASSED: stop() call succeeded."); > 222: } > 223: } catch(Throwable ue) { Suggestion: } catch (Throwable ue) { test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/stop/stop002.java line 255: > 253: log.display("TEST #5 PASSED: stop() call for suspended thread succeeded"); > 254: } > 255: } catch(Throwable ue) { Suggestion: } catch (Throwable ue) { test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/stop/stop002.java line 274: > 272: } finally { > 273: // Force the debuggee out of both loops > 274: if (objRef != null && stopLoop1 != null && stopLoop2 != null) { Suggestion: if (objRef != null && stopLoop1 != null && stopLoop2 != null) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13548#discussion_r1174633416 PR Review Comment: https://git.openjdk.org/jdk/pull/13548#discussion_r1174633435 PR Review Comment: https://git.openjdk.org/jdk/pull/13548#discussion_r1174633460 PR Review Comment: https://git.openjdk.org/jdk/pull/13548#discussion_r1174633464 PR Review Comment: https://git.openjdk.org/jdk/pull/13548#discussion_r1174633486 From mdoerr at openjdk.org Tue Apr 25 19:48:10 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 25 Apr 2023 19:48:10 GMT Subject: RFR: 8306823: Native memory leak in SharedRuntime::notify_jvmti_unmount/mount. In-Reply-To: <5pnvV5z6BaaPhKb0UWkA5wEu3FfaKZfepYGXtMx_tDk=.da25228a-18bf-450d-a5dd-c5114d5f046c@github.com> References: <5pnvV5z6BaaPhKb0UWkA5wEu3FfaKZfepYGXtMx_tDk=.da25228a-18bf-450d-a5dd-c5114d5f046c@github.com> Message-ID: On Tue, 25 Apr 2023 13:19:36 GMT, Martin Doerr wrote: > The code introduced by [JDK-8304303](https://bugs.openjdk.org/browse/JDK-8304303) uses `JNIHandles::make_local` which requires `JNIHandles::destroy_local` which is currently missing. Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13641#issuecomment-1522327187 From cjplummer at openjdk.org Tue Apr 25 21:15:05 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 25 Apr 2023 21:15:05 GMT Subject: RFR: 8306705: com/sun/jdi/PopAndInvokeTest.java fails with NativeMethodException Message-ID: <8Ck4ju836i48Wi-oUWYwurOyKvKjWGLjCuSi8Rk9COA=.5ac9eed8-5d22-419b-be90-06ba572149c9@github.com> Recently [JDK-8305511](https://bugs.openjdk.org/browse/JDK-8305511) removed the "@ignore 6951287 ", allowing this test to run, which is why this failure mode is now turning up. There is a race condition, leading to the `popFrames()` call being done while a native method is in the set of frames to be popped. This results in a `NativeMethodException` instead of the frames being popped. The debuggee has: public static void waiter() { if (waiting) { return; } waiting = true; System.out.println(" debuggee: in waiter"); while (true) { } } And the debugger waits for `waiting == true` (checked via JDI calls) before suspending and doing the `popFrames()`. The problem is the println() after setting `waiting = true`. The debugger side can detect that `waiting == true` before the println() is complete, and the println() involves native code. Once `waiting` is set true, we need to make sure no other method calls are made so we can be sure that only the `waiter()` method is on the stack. Note there is a lot of interesting history to this CR, including [JDK-6417053](https://bugs.openjdk.org/browse/JDK-6417053), which actually reproduced this issue long ago (but got closed as CNR), although it failed with a different error message (even though it was the same issue), and the different error message was itself the result of another bug that was inadvertently fixed when virtual threads support was added to JDI. See the CR for details if you are interested. ------------- Commit messages: - Move println to before setting the waiting flag Changes: https://git.openjdk.org/jdk/pull/13657/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13657&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306705 Stats: 3 lines in 1 file changed: 2 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13657.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13657/head:pull/13657 PR: https://git.openjdk.org/jdk/pull/13657 From lmesnik at openjdk.org Tue Apr 25 21:29:07 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 25 Apr 2023 21:29:07 GMT Subject: RFR: 8306705: com/sun/jdi/PopAndInvokeTest.java fails with NativeMethodException In-Reply-To: <8Ck4ju836i48Wi-oUWYwurOyKvKjWGLjCuSi8Rk9COA=.5ac9eed8-5d22-419b-be90-06ba572149c9@github.com> References: <8Ck4ju836i48Wi-oUWYwurOyKvKjWGLjCuSi8Rk9COA=.5ac9eed8-5d22-419b-be90-06ba572149c9@github.com> Message-ID: On Tue, 25 Apr 2023 21:07:34 GMT, Chris Plummer wrote: > Recently [JDK-8305511](https://bugs.openjdk.org/browse/JDK-8305511) removed the "@ignore 6951287 ", allowing this test to run, which is why this failure mode is now turning up. > > There is a race condition, leading to the `popFrames()` call being done while a native method is in the set of frames to be popped. This results in a `NativeMethodException` instead of the frames being popped. The debuggee has: > > > public static void waiter() { > if (waiting) { > return; > } > waiting = true; > System.out.println(" debuggee: in waiter"); > while (true) { > } > } > > > And the debugger waits for `waiting == true` (checked via JDI calls) before suspending and doing the `popFrames()`. The problem is the println() after setting `waiting = true`. The debugger side can detect that `waiting == true` before the println() is complete, and the println() involves native code. Once `waiting` is set true, we need to make sure no other method calls are made so we can be sure that only the `waiter()` method is on the stack. > > Note there is a lot of interesting history to this CR, including [JDK-6417053](https://bugs.openjdk.org/browse/JDK-6417053), which actually reproduced this issue long ago (but got closed as CNR), although it failed with a different error message (even though it was the same issue), and the different error message was itself the result of another bug that was inadvertently fixed when virtual threads support was added to JDI. See the CR for details if you are interested. Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13657#pullrequestreview-1400777256 From amenkov at openjdk.org Tue Apr 25 21:43:08 2023 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 25 Apr 2023 21:43:08 GMT Subject: RFR: 8306705: com/sun/jdi/PopAndInvokeTest.java fails with NativeMethodException In-Reply-To: <8Ck4ju836i48Wi-oUWYwurOyKvKjWGLjCuSi8Rk9COA=.5ac9eed8-5d22-419b-be90-06ba572149c9@github.com> References: <8Ck4ju836i48Wi-oUWYwurOyKvKjWGLjCuSi8Rk9COA=.5ac9eed8-5d22-419b-be90-06ba572149c9@github.com> Message-ID: On Tue, 25 Apr 2023 21:07:34 GMT, Chris Plummer wrote: > Recently [JDK-8305511](https://bugs.openjdk.org/browse/JDK-8305511) removed the "@ignore 6951287 ", allowing this test to run, which is why this failure mode is now turning up. > > There is a race condition, leading to the `popFrames()` call being done while a native method is in the set of frames to be popped. This results in a `NativeMethodException` instead of the frames being popped. The debuggee has: > > > public static void waiter() { > if (waiting) { > return; > } > waiting = true; > System.out.println(" debuggee: in waiter"); > while (true) { > } > } > > > And the debugger waits for `waiting == true` (checked via JDI calls) before suspending and doing the `popFrames()`. The problem is the println() after setting `waiting = true`. The debugger side can detect that `waiting == true` before the println() is complete, and the println() involves native code. Once `waiting` is set true, we need to make sure no other method calls are made so we can be sure that only the `waiter()` method is on the stack. > > Note there is a lot of interesting history to this CR, including [JDK-6417053](https://bugs.openjdk.org/browse/JDK-6417053), which actually reproduced this issue long ago (but got closed as CNR), although it failed with a different error message (even though it was the same issue), and the different error message was itself the result of another bug that was inadvertently fixed when virtual threads support was added to JDI. See the CR for details if you are interested. Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13657#pullrequestreview-1400791875 From amenkov at openjdk.org Tue Apr 25 22:03:03 2023 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 25 Apr 2023 22:03:03 GMT Subject: RFR: 8299414: JVMTI FollowReferences should support references from VirtualThread stack [v8] In-Reply-To: <6oQOD_egcB3HyuagMWGSPLjKSE3JkaI2K2WOsDK1Cww=.c568223b-5100-4425-a4b7-defbd812a9ff@github.com> References: <6oQOD_egcB3HyuagMWGSPLjKSE3JkaI2K2WOsDK1Cww=.c568223b-5100-4425-a4b7-defbd812a9ff@github.com> Message-ID: > The fix updates JVMTI FollowReferences implementation to report references from virtual threads: > - unmounted vthreads are detected, their stack references for JVMTI_HEAP_REFERENCE_STACK_LOCAL/JVMTI_HEAP_REFERENCE_JNI_LOCAL; > - stacks of mounted vthreads are splitted into 2 parts (virtual thread stack and carrier thread stack), references are reported with correct thread id/class tag/object tags/frame depth; > - common code to handle stack frames are moved into separate class; > > Threads are reported as: > - platform threads: JVMTI_HEAP_REFERENCE_THREAD (as before); > - mounted vthreads (synthetic references, consider them as heap roots because carrier threads are roots): JVMTI_HEAP_REFERENCE_OTHER; > - unmounted vthreads: not reported as heap roots. Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: mounted VTs reported as OTHER, unmounted VTs are not reported as roots ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13254/files - new: https://git.openjdk.org/jdk/pull/13254/files/d95a8426..d149be41 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13254&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13254&range=06-07 Stats: 13 lines in 1 file changed: 9 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13254.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13254/head:pull/13254 PR: https://git.openjdk.org/jdk/pull/13254 From amenkov at openjdk.org Tue Apr 25 22:30:41 2023 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 25 Apr 2023 22:30:41 GMT Subject: RFR: 8306027: Clarify JVMTI heap functions spec about virtual thread stack. Message-ID: The fix updates JVMTI spec updates description of heap functions to support virtual threads. Virtual threads are not heap roots by design, so FollowReference/IterateOverReachableObjects specs are updated to note only platform threads. References from thread stacks (including virtual threads) are reported as JVMTI_HEAP_REFERENCE_STACK_LOCAL/JVMTI_HEAP_REFERENCE_JNI_LOCAL, so description of the values is relaxed. Also please review related CSR ------------- Commit messages: - spec update Changes: https://git.openjdk.org/jdk/pull/13661/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13661&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306027 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13661.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13661/head:pull/13661 PR: https://git.openjdk.org/jdk/pull/13661 From iklam at openjdk.org Wed Apr 26 00:05:23 2023 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 26 Apr 2023 00:05:23 GMT Subject: RFR: 8305771: SA ClassWriter.java fails to skip overpass methods Message-ID: <-XH_mUzboaslSO3DZ3Mx4Bj35LnXKiBPQzGFB-r6pPU=.5215d237-2b54-44ae-a7e5-6972549a6977@github.com> Please review this trivial fix. When checking for bits in `m.getAccessFlags()`, the mask `JVM_RECOGNIZED_METHOD_MODIFIERS` should be applied (similar to other uses of `m.getAccessFlags()` in ClassWriter.java ------------- Commit messages: - 8305771: SA ClassWriter.java fails to skip overpass methods Changes: https://git.openjdk.org/jdk/pull/13663/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13663&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8305771 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13663.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13663/head:pull/13663 PR: https://git.openjdk.org/jdk/pull/13663 From kbarrett at openjdk.org Wed Apr 26 02:26:52 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 26 Apr 2023 02:26:52 GMT Subject: RFR: 8306858: Remove some remnants of CMS from SA agent In-Reply-To: References: Message-ID: On Tue, 25 Apr 2023 16:25:40 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that removes some remaining CMS related stuff. > > Testing: tier1-3, gha > > Thanks, > Thomas Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13646#pullrequestreview-1401041280 From tschatzl at openjdk.org Wed Apr 26 08:41:30 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 26 Apr 2023 08:41:30 GMT Subject: RFR: 8306858: Remove some remnants of CMS from SA agent [v2] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that removes some remaining CMS related stuff. > > Testing: tier1-3, gha > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: cplummer review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13646/files - new: https://git.openjdk.org/jdk/pull/13646/files/42d4cafa..79f9a814 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13646&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13646&range=00-01 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13646.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13646/head:pull/13646 PR: https://git.openjdk.org/jdk/pull/13646 From mdoerr at openjdk.org Wed Apr 26 08:42:00 2023 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 26 Apr 2023 08:42:00 GMT Subject: Integrated: 8306823: Native memory leak in SharedRuntime::notify_jvmti_unmount/mount. In-Reply-To: <5pnvV5z6BaaPhKb0UWkA5wEu3FfaKZfepYGXtMx_tDk=.da25228a-18bf-450d-a5dd-c5114d5f046c@github.com> References: <5pnvV5z6BaaPhKb0UWkA5wEu3FfaKZfepYGXtMx_tDk=.da25228a-18bf-450d-a5dd-c5114d5f046c@github.com> Message-ID: On Tue, 25 Apr 2023 13:19:36 GMT, Martin Doerr wrote: > The code introduced by [JDK-8304303](https://bugs.openjdk.org/browse/JDK-8304303) uses `JNIHandles::make_local` which requires `JNIHandles::destroy_local` which is currently missing. This pull request has now been integrated. Changeset: d7476982 Author: Martin Doerr URL: https://git.openjdk.org/jdk/commit/d74769826ddb5e68df76407fb94c7560475249a0 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod 8306823: Native memory leak in SharedRuntime::notify_jvmti_unmount/mount. Reviewed-by: pchilanomate, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/13641 From tschatzl at openjdk.org Wed Apr 26 09:12:24 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 26 Apr 2023 09:12:24 GMT Subject: RFR: 8306836: Remove pinned tag for G1 heap regions [v3] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that removes the pinned tag from `HeapRegion`. > > So that "pinned" tag for G1 heap regions indicates that the region should not move during (young) gc. This applies to now removed archive regions and humongous objects/regions. > > With "real" g1 region pinning to deal with gclocker in g1 once and for all upcoming we need a refcount, a single bit is not sufficient anymore. Further there will be a naming conflict as this kind of "pinning" is different to g1 region pinning "pinning". The former indicates "contents can not be moved, but can be reclaimed", while the latter means "contents can not be moved and not reclaimed". > > The (current) pinned flag is surprisingly little used, only for policy decisions. > > The suggestion this change implements is to remove the "pinned" tag as it is, and reserve it for future g1 region pinning (that needs to store the pinning attribute differently as a refcount anyway). > > Testing: tier1-3, gha > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: cplummer review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13643/files - new: https://git.openjdk.org/jdk/pull/13643/files/4b736512..eacf54ba Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13643&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13643&range=01-02 Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13643.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13643/head:pull/13643 PR: https://git.openjdk.org/jdk/pull/13643 From tschatzl at openjdk.org Wed Apr 26 09:13:25 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 26 Apr 2023 09:13:25 GMT Subject: RFR: 8306836: Remove pinned tag for G1 heap regions [v3] In-Reply-To: References: Message-ID: <5fltNms8YN-m7KHDT11zD1NQ_2BxcIy-vcR_HlSO5nE=.25134e10-40f5-4a65-9eb4-7a578b90c630@github.com> On Tue, 25 Apr 2023 18:31:19 GMT, Chris Plummer wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> cplummer review > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/HSDB.java line 1109: > >> 1107: } else if (region.isPinned()) { >> 1108: anno = "Pinned "; >> 1109: bad = false; > > Does this mean that the region will now always be one of Free, Young, Humongous, or Old? As the description says, the "pinned" attribute is going away temporarily as it is not really required/used at this time. So only the base region types you specified will remain. The attribute will be re-introduced in a bit during completion of [JDK-8276094](https://bugs.openjdk.org/browse/JDK-8276094) with a slightly different meaning. Btw, the code has been wrong in that the "pinned" attribute is a modifier of the base types (Free, Young, ...), not a separate category. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13643#discussion_r1177560794 From qamai at openjdk.org Wed Apr 26 09:40:53 2023 From: qamai at openjdk.org (Quan Anh Mai) Date: Wed, 26 Apr 2023 09:40:53 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v62] In-Reply-To: References: Message-ID: <9aK0kPPAYJYmaffnYZ47rIkDC8El1snix1GhTeUTBnE=.54c3e35d-b285-4c04-9e3f-ab2751902724@github.com> On Thu, 20 Apr 2023 11:15:47 GMT, Roman Kennke wrote: >> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). >> >> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. >> >> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal protocols. >> >> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare. >> >> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. >> >> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. >> >> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. >> >> This change enables to simplify (and speed-up!) a lot of code: >> >> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. >> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR >> >> Also, and I might be mistaken here, this new lightweight locking would make synchronized work better with Loom: Because the lock-records are no longer scattered across the stack, but instead are densely packed into the lock-stack, it should be easy for a vthread to save its lock-stack upon unmounting and restore it when re-mounting. However, I am not sure about this, and this PR does not attempt to implement that support. >> >> Testing: >> - [x] tier1 x86_64 x aarch64 x +UseFastLocking >> - [x] tier2 x86_64 x aarch64 x +UseFastLocking >> - [x] tier3 x86_64 x aarch64 x +UseFastLocking >> - [x] tier4 x86_64 x aarch64 x +UseFastLocking >> - [x] tier1 x86_64 x aarch64 x -UseFastLocking >> - [x] tier2 x86_64 x aarch64 x -UseFastLocking >> - [x] tier3 x86_64 x aarch64 x -UseFastLocking >> - [x] tier4 x86_64 x aarch64 x -UseFastLocking >> - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet >> >> ### Performance >> >> #### Simple Microbenchmark >> >> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops. >> >> | | x86_64 | aarch64 | >> | -- | -- | -- | >> | -UseFastLocking | 20.651 | 20.764 | >> | +UseFastLocking | 18.896 | 18.908 | >> >> >> #### Renaissance >> >> ? | x86_64 | ? | ? | ? | aarch64 | ? | ? >> -- | -- | -- | -- | -- | -- | -- | -- >> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? >> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% >> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21% >> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% >> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% >> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% >> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% >> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%% >> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% >> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% >> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% >> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% >> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34% >> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% >> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% >> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% >> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% >> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% >> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% >> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% >> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% >> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Remove unnecessary comments src/hotspot/cpu/x86/c2_CodeStubs_x86.cpp line 81: > 79: // C2CodeStubList::emit() will throw an assertion and report the actual size that > 80: // is needed. > 81: return 33; This should be 36 with `ASSERT` and 21 without. If you are sure that `JavaThread::lock_stack_top_offset()` or `OM_OFFSET_NO_MONITOR_VALUE_TAG(owner)` fits within an `int8_t` then it reduces 3 bytes for each usage. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 691: > 689: jccb(Assembler::notEqual, NO_COUNT); // If not recursive, ZF = 0 at this point (fail) > 690: incq(Address(scrReg, OM_OFFSET_NO_MONITOR_VALUE_TAG(recursions))); > 691: xorq(rax, rax); // Set ZF = 1 (success) for recursive lock, denoting locking success `xorl` would save a byte here, and some similar places. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 701: > 699: // ZFlag == 0 count in slow path > 700: jccb(Assembler::notZero, NO_COUNT); // jump if ZFlag == 0 > 701: `DONE_LABEL` is conditionally jumped into from a lot of places, the only path it is reached without known `ZF` seems to be `LM_LEGAGY` fall-through. Maybe refactor a little to eliminate this block. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 781: > 779: #ifdef _LP64 > 780: C2HandleAnonOMOwnerStub* stub = new (Compile::current()->comp_arena()) C2HandleAnonOMOwnerStub(tmpReg, boxReg); > 781: Compile::current()->output()->add_stub(stub); This should be added only if we are really emitting the code (i.e. not emitting into a scratch buffer to measure the node size) src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 926: > 924: // Intentional fall-thru into DONE_LABEL > 925: } > 926: bind(DONE_LABEL); Similar to `fast_lock`, this `DONE_LABEL` can be removed. src/hotspot/cpu/x86/macroAssembler_x86.cpp line 9704: > 9702: > 9703: // If successful, push object to lock-stack. > 9704: movl(tmp, Address(thread, JavaThread::lock_stack_top_offset())); This value seems to be loaded twice, can they be merged? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1177505070 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1177289743 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1177289153 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1177301239 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1177302528 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1177293052 From qamai at openjdk.org Wed Apr 26 09:40:54 2023 From: qamai at openjdk.org (Quan Anh Mai) Date: Wed, 26 Apr 2023 09:40:54 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v62] In-Reply-To: <9aK0kPPAYJYmaffnYZ47rIkDC8El1snix1GhTeUTBnE=.54c3e35d-b285-4c04-9e3f-ab2751902724@github.com> References: <9aK0kPPAYJYmaffnYZ47rIkDC8El1snix1GhTeUTBnE=.54c3e35d-b285-4c04-9e3f-ab2751902724@github.com> Message-ID: <_Y6eLacV_ecmijvlzo2lGe-U5n6ZtaJnUA6KL9BsJJw=.a66f23b0-aaf6-43ac-a210-ad830a1e744c@github.com> On Wed, 26 Apr 2023 08:12:41 GMT, Quan Anh Mai wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unnecessary comments > > src/hotspot/cpu/x86/c2_CodeStubs_x86.cpp line 81: > >> 79: // C2CodeStubList::emit() will throw an assertion and report the actual size that >> 80: // is needed. >> 81: return 33; > > This should be 36 with `ASSERT` and 21 without. If you are sure that `JavaThread::lock_stack_top_offset()` or `OM_OFFSET_NO_MONITOR_VALUE_TAG(owner)` fits within an `int8_t` then it reduces 3 bytes for each usage. This stub has 2 instructions, and it seems not really uncommon, is it worth it to have a stub here? > src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 781: > >> 779: #ifdef _LP64 >> 780: C2HandleAnonOMOwnerStub* stub = new (Compile::current()->comp_arena()) C2HandleAnonOMOwnerStub(tmpReg, boxReg); >> 781: Compile::current()->output()->add_stub(stub); > > This should be added only if we are really emitting the code (i.e. not emitting into a scratch buffer to measure the node size) Also, I think this `if (LockingMode == LM_LIGHTWEIGHT)` block should be moved out of the enclosing if block, we are checking for inflation here, it seems logical to separate the inflation path out. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1177570766 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1177304198 From sspitsyn at openjdk.org Wed Apr 26 09:49:54 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 26 Apr 2023 09:49:54 GMT Subject: RFR: 8233725: ProcessTools.startProcess() has output issues when using an OutputAnalyzer at the same time In-Reply-To: References: Message-ID: On Fri, 21 Apr 2023 21:43:39 GMT, Leonid Mesnik wrote: > ProcessTools.startProcess() creates process and read it's output error streams. So the any other using of corresponding Process.getInputStream() and Process.getErrorStream() doesn't get process streams. > > This fix preserve process streams content and allow to read reuse the date. The ByteArrayOutputStream is used as a buffer. > It stores all process output, never trying to clean date which has been read. > > The regression test has been provided with issue. > > I closed previous PR https://github.com/openjdk/jdk/pull/13560 by mistake instead of updating it. > > I run all tests to ensure that no failures are introduced. Looks good. Posted a few minor comments. Thanks, Serguei test/lib/jdk/test/lib/process/ProcessTools.java line 170: > 168: } > 169: > 170: synchronized int readNext() { An extra space after synchronized keyword. test/lib/jdk/test/lib/process/ProcessTools.java line 172: > 170: synchronized int readNext() { > 171: if (current > count) { > 172: throw new RuntimeException("Shouldn't ever happen. start: " + current + " count: " + count + " buffer: " + this); This line is too long. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13594#pullrequestreview-1401596190 PR Review Comment: https://git.openjdk.org/jdk/pull/13594#discussion_r1177621994 PR Review Comment: https://git.openjdk.org/jdk/pull/13594#discussion_r1177622644 From sspitsyn at openjdk.org Wed Apr 26 09:50:54 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 26 Apr 2023 09:50:54 GMT Subject: RFR: 8233725: ProcessTools.startProcess() has output issues when using an OutputAnalyzer at the same time In-Reply-To: <6ABDu4g-9JNwmdQpdmOXIbz6WUApspGnmHlMk7BhZ6I=.d11f2bc4-c895-4162-9b35-9f2a0d7be519@github.com> References: <4EDhpXuaKhviIcVGoDrPbVzcdze_pl4rJZu6DQvWeAw=.f5a9a485-3bb2-4f2b-8b65-e3d35eae1001@github.com> <6ABDu4g-9JNwmdQpdmOXIbz6WUApspGnmHlMk7BhZ6I=.d11f2bc4-c895-4162-9b35-9f2a0d7be519@github.com> Message-ID: <7uK1GxdtnB1b_D1bA6Kq8dwnMZw3x3xLKkYDmGibWzc=.7006d521-7b82-4f1e-bdc9-cb23edde89b7@github.com> On Tue, 25 Apr 2023 15:50:24 GMT, Daniel D. Daugherty wrote: >> Agree, it is confusing, even in standard j.l.Process API . The `InputStream java.lang.Process.getInputStream()`" returns **output** stream of started process. So for our implementation ProcessImpl the 'out' and 'err' mean output and error streams. However they are returned as InputStreams so users could read them. > > Right. From the API caller's POV, it is asking for InputStreams that it can use to read the process' stdout or stderr streams. Okay, thanks. I'm thinking about simple/short comments on this to make it clear this naming mismatch is intentional. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13594#discussion_r1177619710 From sspitsyn at openjdk.org Wed Apr 26 10:00:53 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 26 Apr 2023 10:00:53 GMT Subject: RFR: 8306705: com/sun/jdi/PopAndInvokeTest.java fails with NativeMethodException In-Reply-To: <8Ck4ju836i48Wi-oUWYwurOyKvKjWGLjCuSi8Rk9COA=.5ac9eed8-5d22-419b-be90-06ba572149c9@github.com> References: <8Ck4ju836i48Wi-oUWYwurOyKvKjWGLjCuSi8Rk9COA=.5ac9eed8-5d22-419b-be90-06ba572149c9@github.com> Message-ID: On Tue, 25 Apr 2023 21:07:34 GMT, Chris Plummer wrote: > Recently [JDK-8305511](https://bugs.openjdk.org/browse/JDK-8305511) removed the "@ignore 6951287 ", allowing this test to run, which is why this failure mode is now turning up. > > There is a race condition, leading to the `popFrames()` call being done while a native method is in the set of frames to be popped. This results in a `NativeMethodException` instead of the frames being popped. The debuggee has: > > > public static void waiter() { > if (waiting) { > return; > } > waiting = true; > System.out.println(" debuggee: in waiter"); > while (true) { > } > } > > > And the debugger waits for `waiting == true` (checked via JDI calls) before suspending and doing the `popFrames()`. The problem is the println() after setting `waiting = true`. The debugger side can detect that `waiting == true` before the println() is complete, and the println() involves native code. Once `waiting` is set true, we need to make sure no other method calls are made so we can be sure that only the `waiter()` method is on the stack. > > Note there is a lot of interesting history to this CR, including [JDK-6417053](https://bugs.openjdk.org/browse/JDK-6417053), which actually reproduced this issue long ago (but got closed as CNR), although it failed with a different error message (even though it was the same issue), and the different error message was itself the result of another bug that was inadvertently fixed when virtual threads support was added to JDI. See the CR for details if you are interested. Looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13657#pullrequestreview-1401606470 From yyang at openjdk.org Wed Apr 26 10:03:02 2023 From: yyang at openjdk.org (Yi Yang) Date: Wed, 26 Apr 2023 10:03:02 GMT Subject: RFR: JDK-8306441: Segmented heap dump Message-ID: <8YqPPHSW4K1s0t317Kp6UqvoGuv5v9oCbjtQ9FX8p2o=.0f6c687b-d031-401d-901d-1ec532715cdc@github.com> Hi, heap dump brings about pauses for application's execution(STW), this is a well-known pain. JDK-8252842 have added parallel support to heapdump in an attempt to alleviate this issue. However, all concurrent threads competitively write heap data to the same file, and more memory is required to maintain the concurrent buffer queue. In experiments, we did not feel a significant performance improvement from that. The minor-pause solution, which is presented in this PR, is a two-stage segmented heap dump: 1. Stage One(STW): Concurrent threads directly write data to multiple heap files. 2. Stage Two(Non-STW): Merge multiple heap files into one complete heap dump file. Now concurrent worker threads are not required to maintain a buffer queue, which would result in more memory overhead, nor do they need to compete for locks. It significantly reduces 73~80% application pause time. | memory | numOfThread | STW | Total | | --- | --------- | -------------- | ------------ | | 8g | 1 thread | 15.612 secs | 15.612 secs | | 8g | 32 thread | 2.5617250 secs | 14.498 secs | | 8g | 96 thread | 2.6790452 secs | 14.012 secs | | 16g | 1 thread | 26.278 secs | 26.278 secs | | 16g | 32 thread | 5.2313740 secs | 26.417 secs | | 16g | 96 thread | 6.2445556 secs | 27.141 secs | | 32g | 1 thread | 48.149 secs | 48.149 secs | | 32g | 32 thread | 10.7734677 secs | 61.643 secs | | 32g | 96 thread | 13.1522042 secs | 61.432 secs | | 64g | 1 thread | 100.583 secs | 100.583 secs | | 64g | 32 thread | 20.9233744 secs | 134.701 secs | | 64g | 96 thread | 26.7374116 secs | 126.080 secs | | 128g | 1 thread | 233.843 secs | 233.843 secs | | 128g | 32 thread | 72.9945768 secs | 207.060 secs | | 128g | 96 thread | 67.6815929 secs | 336.345 secs | > **Total** means the total heap dump including both two phases > **STW** means the first phase only. > For parallel dump, **Total** = **STW** + **Merge**. For serial dump, **Total** = **STW** ![image](https://user-images.githubusercontent.com/5010047/234534654-6f29a3af-dad5-46bc-830b-7449c80b4dec.png) In actual testing, two-stage solution can lead to an increase in the overall time for heapdump(See table above). However, considering the reduction of STW time, I think it is an acceptable trade-off. Furthermore, there is still room for optimization in the second merge stage(e.g. sendfile/splice/copy_file_range instead of read+write combination). Since number of parallel dump thread has a considerable impact on total dump time, I added a parameter that allows users to specify the number of parallel dump thread they wish to run. ##### Open discussion - Pauseless heap dump solution? An alternative pauseless solution is to fork a child process, set the parent process heap to read-only, and dump the heap in child process. Once writing happens in parent process, child process observes them by userfaultfd and corresponding pages are prioritized for dumping. I'm also looking forward to hearing comments and discussions about this solution. - Client parser support for segmented heap dump This patch provides a possibility that whether heap dump needs to be complete or not, can the VM directly generate segmented heapdump, and let the client parser complete the merge process? Looking forward to hearing comments from the Eclipse MAT community ------------- Commit messages: - JDK-8306441: Segmented heap dump Changes: https://git.openjdk.org/jdk/pull/13667/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13667&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306441 Stats: 2838 lines in 11 files changed: 1006 ins; 1770 del; 62 mod Patch: https://git.openjdk.org/jdk/pull/13667.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13667/head:pull/13667 PR: https://git.openjdk.org/jdk/pull/13667 From alanb at openjdk.org Wed Apr 26 11:22:23 2023 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 26 Apr 2023 11:22:23 GMT Subject: RFR: 8306033: Resolve multiple definition of 'throwIOException' and friends when statically linking with JDK native libraries [v2] In-Reply-To: References: Message-ID: On Tue, 25 Apr 2023 00:47:17 GMT, Jiangli Zhou wrote: >> - Make functions 'static' when feasible: >> - throwByName() in src/java.security.jgss/share/native/libj2gss/NativeUtil.c. >> - throwByName(), throwIOException() and throwNullPointerException() in src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c. >> - throwByName() in src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c. >> - throwOutOfMemoryError() in src/java.smartcardio/share/native/libj2pcsc/pcsc.c. >> - Move throwDisconnectedRuntimeException() to src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c since it's only used in the file. Make it static. >> - Move throw_internal_error() to src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c as it's only used in the file. Make it static. >> >> - Rename functions by following the existing naming usages in different libraries code: >> - Rename throwOutOfMemoryError() to gssThrowOutOfMemoryError() in libj2gss. >> - Rename throwOutOfMemoryError() to p11ThrowOutOfMemoryError() in libj2pks11. >> - Rename throwNullPointerException() to p11ThrowNullPointerException() in libj2pks11. >> - Rename throwIOException() to p11ThrowIOException() in libj2pks11. >> - Rename throwPKCS11RuntimeException() to p11ThrowPKCS11RuntimeException() in libj2pks11. This function only exists in libj2pks11. The rename is done so the function naming is consistent with the other throw functions. >> >> - Remove throw_internal_error() from src/java.management/share/native/libmanagement/management.h and src/java.management/share/native/libmanagement/management.c. It's not used. >> - Remove throw_internal_error() from src/jdk.management/share/native/libmanagement_ext/management_ext.h and src/jdk.management/share/native/libmanagement_ext/management_ext.c. > > Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: > > Minor updates, as suggested by mcpowers: > - Update copyright headers in affected files. > - Formatting update in src/java.security.jgss/share/native/libj2gss/GSSLibStub.c. > - Remove throwByName() and move the logic into gssThrowOutOfMemoryError() (the only caller) in src/java.security.jgss/share/native/libj2gss/NativeUtil.c. I think this looks okay. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13497#pullrequestreview-1401741433 From rkennke at openjdk.org Wed Apr 26 11:26:56 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 26 Apr 2023 11:26:56 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v62] In-Reply-To: <_Y6eLacV_ecmijvlzo2lGe-U5n6ZtaJnUA6KL9BsJJw=.a66f23b0-aaf6-43ac-a210-ad830a1e744c@github.com> References: <9aK0kPPAYJYmaffnYZ47rIkDC8El1snix1GhTeUTBnE=.54c3e35d-b285-4c04-9e3f-ab2751902724@github.com> <_Y6eLacV_ecmijvlzo2lGe-U5n6ZtaJnUA6KL9BsJJw=.a66f23b0-aaf6-43ac-a210-ad830a1e744c@github.com> Message-ID: On Wed, 26 Apr 2023 09:03:07 GMT, Quan Anh Mai wrote: >> src/hotspot/cpu/x86/c2_CodeStubs_x86.cpp line 81: >> >>> 79: // C2CodeStubList::emit() will throw an assertion and report the actual size that >>> 80: // is needed. >>> 81: return 33; >> >> This should be 36 with `ASSERT` and 21 without. If you are sure that `JavaThread::lock_stack_top_offset()` or `OM_OFFSET_NO_MONITOR_VALUE_TAG(owner)` fits within an `int8_t` then it reduces 3 bytes for each usage. > > This stub has 2 instructions, and it seems not really uncommon, is it worth it to have a stub here? Ok I will change the value. Yes, this path is relatively uncommon (monitors are inflated only once, and not necessarily via ANONYMOUS handshake, but used often), and this path is performance relevant. The original impl had the two instructions inlined, but the common forward branch impacted performance. >> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 781: >> >>> 779: #ifdef _LP64 >>> 780: C2HandleAnonOMOwnerStub* stub = new (Compile::current()->comp_arena()) C2HandleAnonOMOwnerStub(tmpReg, boxReg); >>> 781: Compile::current()->output()->add_stub(stub); >> >> This should be added only if we are really emitting the code (i.e. not emitting into a scratch buffer to measure the node size) > > Also, I think this `if (LockingMode == LM_LIGHTWEIGHT)` block should be moved out of the enclosing if block, we are checking for inflation here, it seems logical to separate the inflation path out. How would I check if we are emitting code? I am not sure I understand. The check for ANONYMOUS is only relevant when we observe an already-inflated monitor. I think this is the right place to put it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1177703431 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1177699910 From qamai at openjdk.org Wed Apr 26 11:26:57 2023 From: qamai at openjdk.org (Quan Anh Mai) Date: Wed, 26 Apr 2023 11:26:57 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v62] In-Reply-To: References: <9aK0kPPAYJYmaffnYZ47rIkDC8El1snix1GhTeUTBnE=.54c3e35d-b285-4c04-9e3f-ab2751902724@github.com> <_Y6eLacV_ecmijvlzo2lGe-U5n6ZtaJnUA6KL9BsJJw=.a66f23b0-aaf6-43ac-a210-ad830a1e744c@github.com> Message-ID: On Wed, 26 Apr 2023 10:52:29 GMT, Roman Kennke wrote: >> This stub has 2 instructions, and it seems not really uncommon, is it worth it to have a stub here? > > Ok I will change the value. > Yes, this path is relatively uncommon (monitors are inflated only once, and not necessarily via ANONYMOUS handshake, but used often), and this path is performance relevant. The original impl had the two instructions inlined, but the common forward branch impacted performance. I see, thanks a lot for your explanations >> Also, I think this `if (LockingMode == LM_LIGHTWEIGHT)` block should be moved out of the enclosing if block, we are checking for inflation here, it seems logical to separate the inflation path out. > > How would I check if we are emitting code? > > I am not sure I understand. The check for ANONYMOUS is only relevant when we observe an already-inflated monitor. I think this is the right place to put it. The entry barrier does this: https://github.com/openjdk/jdk/blob/86f41a4c42268d364175263804eb4d1ce82fa943/src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp#L139 `testptr(tmpReg, markWord::monitor_value)` is checking for inflation, and the following `if` block acts when inflation is detected, what I mean is to move the whole enclosed if down out of the `if (LockingMode != LM_MONITOR)` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1177712615 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1177711237 From rkennke at openjdk.org Wed Apr 26 11:27:02 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 26 Apr 2023 11:27:02 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v62] In-Reply-To: <9aK0kPPAYJYmaffnYZ47rIkDC8El1snix1GhTeUTBnE=.54c3e35d-b285-4c04-9e3f-ab2751902724@github.com> References: <9aK0kPPAYJYmaffnYZ47rIkDC8El1snix1GhTeUTBnE=.54c3e35d-b285-4c04-9e3f-ab2751902724@github.com> Message-ID: On Wed, 26 Apr 2023 03:09:53 GMT, Quan Anh Mai wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unnecessary comments > > src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 691: > >> 689: jccb(Assembler::notEqual, NO_COUNT); // If not recursive, ZF = 0 at this point (fail) >> 690: incq(Address(scrReg, OM_OFFSET_NO_MONITOR_VALUE_TAG(recursions))); >> 691: xorq(rax, rax); // Set ZF = 1 (success) for recursive lock, denoting locking success > > `xorl` would save a byte here, and some similar places. Yes, but see above. > src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 701: > >> 699: // ZFlag == 0 count in slow path >> 700: jccb(Assembler::notZero, NO_COUNT); // jump if ZFlag == 0 >> 701: > > `DONE_LABEL` is conditionally jumped into from a lot of places, the only path it is reached without known `ZF` seems to be `LM_LEGAGY` fall-through. Maybe refactor a little to eliminate this block. I intentionally have not changed the existing paths to make it absolutely clear that the old behaviour is not changed. I'd rather make any changes to the stack-locking in a separate follow-up. > src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 926: > >> 924: // Intentional fall-thru into DONE_LABEL >> 925: } >> 926: bind(DONE_LABEL); > > Similar to `fast_lock`, this `DONE_LABEL` can be removed. Yes but see above ;-) > src/hotspot/cpu/x86/macroAssembler_x86.cpp line 9704: > >> 9702: >> 9703: // If successful, push object to lock-stack. >> 9704: movl(tmp, Address(thread, JavaThread::lock_stack_top_offset())); > > This value seems to be loaded twice, can they be merged? That would be nice, but we cannot do this without allocating another tmp register. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1177695188 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1177695040 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1177700194 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1177696506 From kevinw at openjdk.org Wed Apr 26 13:01:56 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 26 Apr 2023 13:01:56 GMT Subject: RFR: 8305771: SA ClassWriter.java fails to skip overpass methods In-Reply-To: <-XH_mUzboaslSO3DZ3Mx4Bj35LnXKiBPQzGFB-r6pPU=.5215d237-2b54-44ae-a7e5-6972549a6977@github.com> References: <-XH_mUzboaslSO3DZ3Mx4Bj35LnXKiBPQzGFB-r6pPU=.5215d237-2b54-44ae-a7e5-6972549a6977@github.com> Message-ID: On Tue, 25 Apr 2023 23:49:56 GMT, Ioi Lam wrote: > Please review this trivial fix. > > When checking for bits in `m.getAccessFlags()`, the mask `JVM_RECOGNIZED_METHOD_MODIFIERS` should be applied (similar to other uses of `m.getAccessFlags()` in ClassWriter.java Looks good to me. Other existing uses of access flags here look good too. ------------- PR Review: https://git.openjdk.org/jdk/pull/13663#pullrequestreview-1401926771 From rkennke at openjdk.org Wed Apr 26 13:16:26 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 26 Apr 2023 13:16:26 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v63] In-Reply-To: References: Message-ID: <89qIyO7ZpW-n-BqgskUr0vD04rjzu7ugBJZj7t5sonA=.2f7ed1ec-a2db-4042-97fd-68db0b02b292@github.com> > This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). > > What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. > > This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p rotocols. > > The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare. > > In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. > > One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. > > As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. > > This change enables to simplify (and speed-up!) a lot of code: > > - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. > - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR > > Also, and I might be mistaken here, this new lightweight locking would make synchronized work better with Loom: Because the lock-records are no longer scattered across the stack, but instead are densely packed into the lock-stack, it should be easy for a vthread to save its lock-stack upon unmounting and restore it when re-mounting. However, I am not sure about this, and this PR does not attempt to implement that support. > > Testing: > - [x] tier1 x86_64 x aarch64 x +UseFastLocking > - [x] tier2 x86_64 x aarch64 x +UseFastLocking > - [x] tier3 x86_64 x aarch64 x +UseFastLocking > - [x] tier4 x86_64 x aarch64 x +UseFastLocking > - [x] tier1 x86_64 x aarch64 x -UseFastLocking > - [x] tier2 x86_64 x aarch64 x -UseFastLocking > - [x] tier3 x86_64 x aarch64 x -UseFastLocking > - [x] tier4 x86_64 x aarch64 x -UseFastLocking > - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet > > ### Performance > > #### Simple Microbenchmark > > The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops. > > | | x86_64 | aarch64 | > | -- | -- | -- | > | -UseFastLocking | 20.651 | 20.764 | > | +UseFastLocking | 18.896 | 18.908 | > > > #### Renaissance > > ? | x86_64 | ? | ? | ? | aarch64 | ? | ? > -- | -- | -- | -- | -- | -- | -- | -- > ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? > AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% > Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21% > Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% > ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% > GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% > LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% > MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%% > NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% > PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% > FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% > FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% > ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34% > Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% > RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% > Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% > ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% > FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% > FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Suggested changes by @merykitty ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10907/files - new: https://git.openjdk.org/jdk/pull/10907/files/5d0a0451..5f927f9c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=62 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=61-62 Stats: 13 lines in 2 files changed: 6 ins; 2 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/10907.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/10907/head:pull/10907 PR: https://git.openjdk.org/jdk/pull/10907 From lmesnik at openjdk.org Wed Apr 26 14:38:23 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 26 Apr 2023 14:38:23 GMT Subject: RFR: 8233725: ProcessTools.startProcess() has output issues when using an OutputAnalyzer at the same time [v2] In-Reply-To: References: Message-ID: > ProcessTools.startProcess() creates process and read it's output error streams. So the any other using of corresponding Process.getInputStream() and Process.getErrorStream() doesn't get process streams. > > This fix preserve process streams content and allow to read reuse the date. The ByteArrayOutputStream is used as a buffer. > It stores all process output, never trying to clean date which has been read. > > The regression test has been provided with issue. > > I closed previous PR https://github.com/openjdk/jdk/pull/13560 by mistake instead of updating it. > > I run all tests to ensure that no failures are introduced. Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision: - fixed - renamed out to stdOut ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13594/files - new: https://git.openjdk.org/jdk/pull/13594/files/782e9cd6..b8bb6cb9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13594&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13594&range=00-01 Stats: 15 lines in 1 file changed: 1 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/13594.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13594/head:pull/13594 PR: https://git.openjdk.org/jdk/pull/13594 From lmesnik at openjdk.org Wed Apr 26 14:40:24 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 26 Apr 2023 14:40:24 GMT Subject: RFR: 8233725: ProcessTools.startProcess() has output issues when using an OutputAnalyzer at the same time [v2] In-Reply-To: <7uK1GxdtnB1b_D1bA6Kq8dwnMZw3x3xLKkYDmGibWzc=.7006d521-7b82-4f1e-bdc9-cb23edde89b7@github.com> References: <4EDhpXuaKhviIcVGoDrPbVzcdze_pl4rJZu6DQvWeAw=.f5a9a485-3bb2-4f2b-8b65-e3d35eae1001@github.com> <6ABDu4g-9JNwmdQpdmOXIbz6WUApspGnmHlMk7BhZ6I=.d11f2bc4-c895-4162-9b35-9f2a0d7be519@github.com> <7uK1GxdtnB1b_D1bA6Kq8dwnMZw3x3xLKkYDmGibWzc=.7006d521-7b82-4f1e-bdc9-cb23edde89b7@github.com> Message-ID: On Wed, 26 Apr 2023 09:38:45 GMT, Serguei Spitsyn wrote: >> Right. From the API caller's POV, it is asking for InputStreams that it can use to read the process' stdout or stderr streams. > > Okay, thanks. > I'm thinking about simple/short comments on this to make it clear this naming mismatch is intentional. There is a comment in line 156 explaining the purpose of these streams. Also, I renamed out/err names to stdOut/stdErr to make it clearer. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13594#discussion_r1177949748 From tschatzl at openjdk.org Wed Apr 26 14:57:54 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 26 Apr 2023 14:57:54 GMT Subject: RFR: 8305566: ZGC: gc/stringdedup/TestStringDeduplicationFullGC.java#Z failed with SIGSEGV in ZBarrier::weak_load_barrier_on_phantom_oop_slow_path [v2] In-Reply-To: <-k-_JovF26G4lOTq2AvCVxvDgwnqpD4-GSbSYCbDcn4=.e82221d2-9fd8-4aed-9a11-6f5ccc09c669@github.com> References: <-k-_JovF26G4lOTq2AvCVxvDgwnqpD4-GSbSYCbDcn4=.e82221d2-9fd8-4aed-9a11-6f5ccc09c669@github.com> Message-ID: On Mon, 24 Apr 2023 09:25:01 GMT, Kim Barrett wrote: >> Please review this change to the string deduplication thread to make it a kind >> of JavaThread rather than a ConcurrentGCThread. There are several pieces to >> this change: >> >> (1) New class StringDedupThread (derived from JavaThread), separate from >> StringDedup::Processor (which is now just a CHeapObj instead of deriving from >> ConcurrentGCThread). The thread no longer needs to or supports being stopped, >> like other similar threads. It also needs to be started later, once Java >> threads are supported. Also don't need an explicit visitor, since it will be >> in the normal Java threads list. This separation made the changeover a little >> cleaner to develop, and made the servicability support a little cleaner too. >> >> (2) The Processor now uses the ThreadBlockInVM idiom to be safepoint polite, >> instead of using the SuspendibleThreadSet facility. >> >> (3) Because we're using ThreadBlockInVM, which has a different usage style >> from STS, the tracking of time spent by the processor blocked for safepoints >> doesn't really work. It's not very important anyway, since normal thread >> descheduling can also affect the normal processing times being gathered and >> reported. So we just drop the so-called "blocked" time and associated >> infrastructure, simplifying Stat tracking a bit. Also renamed the >> "concurrent" stat to be "active", since it's all in a JavaThread now. >> >> (4) To avoid #include problems, moved the definition of >> JavaThread::is_active_Java_thread from the .hpp file to the .inline.hpp file, >> where one of the functions it calls also is defined. >> >> (5) Added servicability support for the new thread. >> >> Testing: >> mach5 tier1-3 with -XX:+UseStringDeduplication. >> The test runtime/cds/DeterministicDump.java fails intermittently with that >> option, which is not surprising - see JDK-8306712. >> >> I was never able to reproduce the failure; it's likely quite timing sensitive. >> The fix of changing the type is based on StefanK's comment that ZResurrection >> doesn't expect a non-Java thread to perform load-barriers. > > Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: > > fix include order Please improve the bug name as suggested by @shipilev before pushing. Looks good otherwise. ------------- Marked as reviewed by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13607#pullrequestreview-1402152540 From jiangli at openjdk.org Wed Apr 26 15:02:23 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 26 Apr 2023 15:02:23 GMT Subject: RFR: 8306033: Resolve multiple definition of 'throwIOException' and friends when statically linking with JDK native libraries [v2] In-Reply-To: References: Message-ID: On Tue, 25 Apr 2023 00:47:17 GMT, Jiangli Zhou wrote: >> - Make functions 'static' when feasible: >> - throwByName() in src/java.security.jgss/share/native/libj2gss/NativeUtil.c. >> - throwByName(), throwIOException() and throwNullPointerException() in src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c. >> - throwByName() in src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c. >> - throwOutOfMemoryError() in src/java.smartcardio/share/native/libj2pcsc/pcsc.c. >> - Move throwDisconnectedRuntimeException() to src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c since it's only used in the file. Make it static. >> - Move throw_internal_error() to src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c as it's only used in the file. Make it static. >> >> - Rename functions by following the existing naming usages in different libraries code: >> - Rename throwOutOfMemoryError() to gssThrowOutOfMemoryError() in libj2gss. >> - Rename throwOutOfMemoryError() to p11ThrowOutOfMemoryError() in libj2pks11. >> - Rename throwNullPointerException() to p11ThrowNullPointerException() in libj2pks11. >> - Rename throwIOException() to p11ThrowIOException() in libj2pks11. >> - Rename throwPKCS11RuntimeException() to p11ThrowPKCS11RuntimeException() in libj2pks11. This function only exists in libj2pks11. The rename is done so the function naming is consistent with the other throw functions. >> >> - Remove throw_internal_error() from src/java.management/share/native/libmanagement/management.h and src/java.management/share/native/libmanagement/management.c. It's not used. >> - Remove throw_internal_error() from src/jdk.management/share/native/libmanagement_ext/management_ext.h and src/jdk.management/share/native/libmanagement_ext/management_ext.c. > > Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: > > Minor updates, as suggested by mcpowers: > - Update copyright headers in affected files. > - Formatting update in src/java.security.jgss/share/native/libj2gss/GSSLibStub.c. > - Remove throwByName() and move the logic into gssThrowOutOfMemoryError() (the only caller) in src/java.security.jgss/share/native/libj2gss/NativeUtil.c. Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13497#issuecomment-1523566931 From lmesnik at openjdk.org Wed Apr 26 15:05:57 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 26 Apr 2023 15:05:57 GMT Subject: Integrated: 8233725: ProcessTools.startProcess() has output issues when using an OutputAnalyzer at the same time In-Reply-To: References: Message-ID: On Fri, 21 Apr 2023 21:43:39 GMT, Leonid Mesnik wrote: > ProcessTools.startProcess() creates process and read it's output error streams. So the any other using of corresponding Process.getInputStream() and Process.getErrorStream() doesn't get process streams. > > This fix preserve process streams content and allow to read reuse the date. The ByteArrayOutputStream is used as a buffer. > It stores all process output, never trying to clean date which has been read. > > The regression test has been provided with issue. > > I closed previous PR https://github.com/openjdk/jdk/pull/13560 by mistake instead of updating it. > > I run all tests to ensure that no failures are introduced. This pull request has now been integrated. Changeset: 2e340e85 Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/2e340e855b760e381793107f2a4d74095bd40199 Stats: 211 lines in 3 files changed: 199 ins; 2 del; 10 mod 8233725: ProcessTools.startProcess() has output issues when using an OutputAnalyzer at the same time Reviewed-by: cjplummer, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/13594 From coleenp at openjdk.org Wed Apr 26 16:06:26 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 26 Apr 2023 16:06:26 GMT Subject: RFR: 8306851: Move Method access flags Message-ID: This change moves the flags from AccessFlags to either ConstMethodFlags or MethodFlags, depending on whether they are set at class file parse time, which makes them essentially const, or at runtime, which makes them needing atomic access. This leaves AccessFlags int size because Klass still has JVM flags that are more work to move, but this change doesn't increase Method size. I didn't remove JVM_RECOGNIZED_METHOD_MODIFIERS with this change since there are several of these in other places, and with this change the code is benign. Tested with tier1-6, and some manual verification of printing. ------------- Commit messages: - fix comment - 8306851: Move Method access flags Changes: https://git.openjdk.org/jdk/pull/13654/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13654&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306851 Stats: 782 lines in 25 files changed: 321 ins; 303 del; 158 mod Patch: https://git.openjdk.org/jdk/pull/13654.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13654/head:pull/13654 PR: https://git.openjdk.org/jdk/pull/13654 From coleenp at openjdk.org Wed Apr 26 16:12:27 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 26 Apr 2023 16:12:27 GMT Subject: RFR: 8305083: Remove finalize() from test/hotspot/jtreg/vmTestbase/nsk/share/ and /jpda that are used in serviceability/dcmd/framework tests In-Reply-To: References: Message-ID: On Tue, 11 Apr 2023 08:16:29 GMT, Afshin Zafari wrote: > The `finalize()` method is removed from base classes/interfaces and are replaced by a Cleaner callback.. Amendment to my comment above. 1. FinalizableObject does seem to serve a purpose, so shouldn't be removed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13420#issuecomment-1523673711 From jiangli at openjdk.org Wed Apr 26 16:16:02 2023 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 26 Apr 2023 16:16:02 GMT Subject: Integrated: 8306033: Resolve multiple definition of 'throwIOException' and friends when statically linking with JDK native libraries In-Reply-To: References: Message-ID: On Mon, 17 Apr 2023 16:56:31 GMT, Jiangli Zhou wrote: > - Make functions 'static' when feasible: > - throwByName() in src/java.security.jgss/share/native/libj2gss/NativeUtil.c. > - throwByName(), throwIOException() and throwNullPointerException() in src/java.smartcardio/unix/native/libj2pcsc/pcsc_md.c. > - throwByName() in src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c. > - throwOutOfMemoryError() in src/java.smartcardio/share/native/libj2pcsc/pcsc.c. > - Move throwDisconnectedRuntimeException() to src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c since it's only used in the file. Make it static. > - Move throw_internal_error() to src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c as it's only used in the file. Make it static. > > - Rename functions by following the existing naming usages in different libraries code: > - Rename throwOutOfMemoryError() to gssThrowOutOfMemoryError() in libj2gss. > - Rename throwOutOfMemoryError() to p11ThrowOutOfMemoryError() in libj2pks11. > - Rename throwNullPointerException() to p11ThrowNullPointerException() in libj2pks11. > - Rename throwIOException() to p11ThrowIOException() in libj2pks11. > - Rename throwPKCS11RuntimeException() to p11ThrowPKCS11RuntimeException() in libj2pks11. This function only exists in libj2pks11. The rename is done so the function naming is consistent with the other throw functions. > > - Remove throw_internal_error() from src/java.management/share/native/libmanagement/management.h and src/java.management/share/native/libmanagement/management.c. It's not used. > - Remove throw_internal_error() from src/jdk.management/share/native/libmanagement_ext/management_ext.h and src/jdk.management/share/native/libmanagement_ext/management_ext.c. This pull request has now been integrated. Changeset: 9bc6a212 Author: Jiangli Zhou URL: https://git.openjdk.org/jdk/commit/9bc6a212f70eede108a8d3bc1ba1f780722b6e33 Stats: 194 lines in 25 files changed: 17 ins; 34 del; 143 mod 8306033: Resolve multiple definition of 'throwIOException' and friends when statically linking with JDK native libraries Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/13497 From dcubed at openjdk.org Wed Apr 26 16:34:53 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 26 Apr 2023 16:34:53 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v62] In-Reply-To: References: Message-ID: On Thu, 20 Apr 2023 11:15:47 GMT, Roman Kennke wrote: >> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). >> >> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. >> >> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal protocols. >> >> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare. >> >> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. >> >> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. >> >> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. >> >> This change enables to simplify (and speed-up!) a lot of code: >> >> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. >> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR >> >> Also, and I might be mistaken here, this new lightweight locking would make synchronized work better with Loom: Because the lock-records are no longer scattered across the stack, but instead are densely packed into the lock-stack, it should be easy for a vthread to save its lock-stack upon unmounting and restore it when re-mounting. However, I am not sure about this, and this PR does not attempt to implement that support. >> >> Testing: >> - [x] tier1 x86_64 x aarch64 x +UseFastLocking >> - [x] tier2 x86_64 x aarch64 x +UseFastLocking >> - [x] tier3 x86_64 x aarch64 x +UseFastLocking >> - [x] tier4 x86_64 x aarch64 x +UseFastLocking >> - [x] tier1 x86_64 x aarch64 x -UseFastLocking >> - [x] tier2 x86_64 x aarch64 x -UseFastLocking >> - [x] tier3 x86_64 x aarch64 x -UseFastLocking >> - [x] tier4 x86_64 x aarch64 x -UseFastLocking >> - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet >> >> ### Performance >> >> #### Simple Microbenchmark >> >> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops. >> >> | | x86_64 | aarch64 | >> | -- | -- | -- | >> | -UseFastLocking | 20.651 | 20.764 | >> | +UseFastLocking | 18.896 | 18.908 | >> >> >> #### Renaissance >> >> ? | x86_64 | ? | ? | ? | aarch64 | ? | ? >> -- | -- | -- | -- | -- | -- | -- | -- >> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? >> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% >> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21% >> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% >> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% >> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% >> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% >> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%% >> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% >> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% >> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% >> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% >> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34% >> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% >> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% >> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% >> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% >> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% >> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% >> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% >> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% >> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Remove unnecessary comments src/hotspot/cpu/aarch64/aarch64.ad line 3875: > 3873: __ b(cont); > 3874: } else { > 3875: assert(LockingMode == LM_LIGHTWEIGHT, ""); Perhaps should be: s/""/"must be"/ I'm not fond of empty assert mesgs. src/hotspot/cpu/aarch64/aarch64.ad line 3956: > 3954: __ b(cont); > 3955: } else { > 3956: assert(LockingMode == LM_LIGHTWEIGHT, ""); Perhaps should be: s/""/"must be"/ I'm not fond of empty assert mesgs. src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 1813: > 1811: __ br(Assembler::NE, slow_path_lock); > 1812: } else { > 1813: assert(LockingMode == LM_LIGHTWEIGHT, ""); Perhaps should be: s/""/"must be"/ I'm not fond of empty assert mesgs. src/hotspot/cpu/arm/c2_MacroAssembler_arm.cpp line 100: > 98: fast_lock_2(Roop /* obj */, Rbox /* t1 */, Rscratch /* t2 */, Rscratch2 /* t3 */, > 99: 1 /* savemask (save t1) */, > 100: done); Why not line up the '1' below the 'R' in Roop and join with the 'done);' line? src/hotspot/cpu/arm/c2_MacroAssembler_arm.cpp line 152: > 150: fast_unlock_2(Roop /* obj */, Rbox /* t1 */, Rscratch /* t2 */, Rscratch2 /* t3 */, > 151: 1 /* savemask (save t1) */, > 152: done); Why not line up the '1' below the 'R' in Roop and join with the 'done);' line? src/hotspot/cpu/arm/interp_masm_arm.cpp line 900: > 898: b(done); > 899: > 900: } else if (LockingMode == LM_LEGACY) { Why so many blank lines in this new block? src/hotspot/cpu/arm/interp_masm_arm.cpp line 1025: > 1023: fast_unlock_2(Robj /* obj */, Rlock /* t1 */, Rmark /* t2 */, Rtemp /* t3 */, > 1024: 1 /* savemask (save t1) */, > 1025: slow_case); Why not line up the '1' below the 'R' in Roop and join with the 'done);' line? src/hotspot/cpu/arm/macroAssembler_arm.cpp line 1803: > 1801: #ifdef ASSERT > 1802: // Poison scratch regs > 1803: POISON_REGS((~savemask), t1, t2, t3, 0x10000001); Should this poison value be: 0x20000002 src/hotspot/cpu/arm/macroAssembler_arm.cpp line 1811: > 1809: // Attempt to fast-unlock an object > 1810: // Registers: > 1811: // - obj: the object to be locked nit typo: s/locked/unlocked/ src/hotspot/cpu/arm/macroAssembler_arm.hpp line 1023: > 1021: // Attempt to fast-unlock an object > 1022: // Registers: > 1023: // - obj: the object to be locked nit typo: s/locked/unlocked/ src/hotspot/cpu/arm/sharedRuntime_arm.cpp line 649: > 647: > 648: __ flush(); > 649: return AdapterHandlerLibrary::new_entry(fingerprint, i2c_entry, c2i_entry, c2i_unverified_entry); This change seems out of place... what's the story here? src/hotspot/cpu/arm/sharedRuntime_arm.cpp line 1246: > 1244: if (LockingMode == LM_LIGHTWEIGHT) { > 1245: log_trace(fastlock2)("SharedRuntime unlock fast"); > 1246: __ fast_unlock_2(sync_obj, R2, tmp, Rtemp, 7, slow_unlock); No comments on the params like in other places... src/hotspot/cpu/x86/macroAssembler_x86.cpp line 9694: > 9692: > 9693: // Now we attempt to take the fast-lock. > 9694: // Clear lowest two header bits (locked state). Perhaps: // Clear lock_mask bits (locked state). so that you don't tie this comment to the implementation size of the lock_mask. src/hotspot/cpu/x86/macroAssembler_x86.cpp line 9697: > 9695: andptr(hdr, ~(int32_t)markWord::lock_mask_in_place); > 9696: movptr(tmp, hdr); > 9697: // Set lowest bit (unlocked state). Perhaps: // Set unlocked_value bit. so that you don't tied this comment to the implementation of the unlocked_value being the lowest bit. I'm less worried about 'bit' versus 'bits' for this one. src/hotspot/cpu/x86/macroAssembler_x86.cpp line 9721: > 9719: assert_different_registers(obj, hdr, tmp); > 9720: > 9721: // Mark-word must be 00 now, try to swing it back to 01 (unlocked) Perhaps: // Mark-word must be lock_mask now, try to swing it back to unlocked_value. so that you don't tie this comment to the implementation values of lock_mask and unlocked_value. src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp line 1717: > 1715: __ jcc(Assembler::notEqual, slow_path_lock); > 1716: } else { > 1717: assert(LockingMode == LM_LIGHTWEIGHT, ""); Perhaps should be: s/""/"must be"/ I'm not fond of empty assert mesgs. src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp line 1876: > 1874: __ dec_held_monitor_count(); > 1875: } else { > 1876: assert(LockingMode == LM_LIGHTWEIGHT, ""); Perhaps should be: s/""/"must be"/ I'm not fond of empty assert mesgs. src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp line 2187: > 2185: __ jcc(Assembler::notEqual, slow_path_lock); > 2186: } else { > 2187: assert(LockingMode == LM_LIGHTWEIGHT, ""); Perhaps should be: s/""/"must be"/ I'm not fond of empty assert mesgs. src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp line 2331: > 2329: __ dec_held_monitor_count(); > 2330: } else { > 2331: assert(LockingMode == LM_LIGHTWEIGHT, ""); Perhaps should be: s/""/"must be"/ I'm not fond of empty assert mesgs. src/hotspot/share/interpreter/interpreterRuntime.cpp line 759: > 757: // also keep the BasicObjectLock, but we don't really need it anyway, we only need > 758: // the object. See also InterpreterMacroAssembler::lock_object(). > 759: // As soon as traditional stack-locking goes away we could remove the other monitorenter() entry Perhaps: s/traditional/legacy/ for terminology consistency... src/hotspot/share/logging/logTag.hpp line 80: > 78: LOG_TAG(exceptions) \ > 79: LOG_TAG(exit) \ > 80: LOG_TAG(fastlock2) \ So why 'fastlock2'? Where's 'fastlock1'? Or 'fastlock'? src/hotspot/share/oops/markWord.hpp line 175: > 173: } > 174: bool has_locker() const { > 175: assert(LockingMode == LM_LEGACY, "should only be called with traditional stack locking"); Perhaps: s/traditional/legacy/ for terminology consistency... src/hotspot/share/runtime/arguments.cpp line 1994: > 1992: if (UseHeavyMonitors) { > 1993: FLAG_SET_CMDLINE(LockingMode, LM_MONITOR); > 1994: } HotSpot option processing has a general rule of last setting wins. With L1992-1994 here, I think there might be a problem with a cmd line that specifies: -XX:+UseHeavyMonitors -XX:LockingMode=1 I think that the resulting value of `LockingMode` will be `LM_MONITOR` instead of `LM_LEGACY`. Granted mixing uses of `UseHeavyMonitors` with `LockingMode` is just asking for trouble... src/hotspot/share/runtime/globals.hpp line 1981: > 1979: "Select locking mode: " \ > 1980: "0: monitors only, " \ > 1981: "1: monitors & traditional stack-locking (default), " \ Perhaps: s/traditional/legacy/ to be consistent with terminolgy... src/hotspot/share/runtime/javaThread.hpp line 1162: > 1160: > 1161: > 1162: static OopStorage* thread_oop_storage(); nit: delete extra blank line on L1161 src/hotspot/share/runtime/lockStack.cpp line 41: > 39: LockStack::LockStack(JavaThread* jt) : > 40: _top(lock_stack_base_offset), _base() > 41: { nit: '{' on L41 should be at the end of L40 (after a space). src/hotspot/share/runtime/lockStack.cpp line 63: > 61: #ifndef PRODUCT > 62: void LockStack::verify(const char* msg) const { > 63: assert(LockingMode == LM_LIGHTWEIGHT, "never use lock-stack when fast-locking is disabled"); Perhaps: s/fast-locking/light weight locking/ src/hotspot/share/runtime/lockStack.cpp line 64: > 62: void LockStack::verify(const char* msg) const { > 63: assert(LockingMode == LM_LIGHTWEIGHT, "never use lock-stack when fast-locking is disabled"); > 64: assert((_top <= end_offset()), "lockstack overflow: _top %d end_offset %d", _top, end_offset()); nit: extra space after `<=` src/hotspot/share/runtime/lockStack.cpp line 65: > 63: assert(LockingMode == LM_LIGHTWEIGHT, "never use lock-stack when fast-locking is disabled"); > 64: assert((_top <= end_offset()), "lockstack overflow: _top %d end_offset %d", _top, end_offset()); > 65: assert((_top >= start_offset()), "lockstack underflow: _topt %d end_offset %d", _top, start_offset()); nit typo: s/_topt/_top/ src/hotspot/share/runtime/lockStack.inline.hpp line 74: > 72: _base[to_index(_top)] = nullptr; > 73: #endif > 74: assert(!contains(o), "entries must be unique"); Perhaps: assert(!contains(o), "entries must be unique: " PTR_FORMAT, p2i(o)); src/hotspot/share/runtime/lockStack.inline.hpp line 81: > 79: inline void LockStack::remove(oop o) { > 80: verify("pre-remove"); > 81: assert(contains(o), "entry must be present"); Perhaps: assert(contains(o), "entry must be present: " PTR_FORMAT, p2i(o)); src/hotspot/share/runtime/synchronizer.cpp line 506: > 504: if (!useHeavyMonitors()) { > 505: if (LockingMode == LM_LIGHTWEIGHT) { > 506: // Fast-locking does not use the 'lock' argument.. nit: extra period at the end. src/hotspot/share/runtime/synchronizer.cpp line 1049: > 1047: > 1048: if (mark.has_monitor()) { > 1049: // inflated monitor so header points to ObjectMonitor (tagged pointer). nit: s/inflated/Inflated/ src/hotspot/share/runtime/synchronizer.cpp line 1077: > 1075: > 1076: if (mark.has_monitor()) { > 1077: // inflated monitor so header points to ObjectMonitor (tagged pointer). nit: s/inflated/Inflated/ src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java line 213: > 211: // refer to Threads::owning_thread_from_monitor_owner > 212: public JavaThread owningThreadFromMonitor(Address o) { > 213: assert(VM.getVM().getCommandLineFlag("LockingMode").getInt() != 2); Please put a comment after that literal '2': assert(VM.getVM().getCommandLineFlag("LockingMode").getInt() != 2 /* LM_LIGHTWEIGHT */); src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java line 231: > 229: > 230: public JavaThread owningThreadFromMonitor(ObjectMonitor monitor) { > 231: if (VM.getVM().getCommandLineFlag("LockingMode").getInt() == 2) { Please put a comment after that literal '2': if (VM.getVM().getCommandLineFlag("LockingMode").getInt() == 2 /* LM_LIGHTWEIGHT */) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1175779923 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1175782883 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1175838145 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1175841805 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1175841903 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1175842779 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1175843663 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1175846203 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1175845306 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1175846631 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1175847483 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1175847916 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1176939876 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1176943266 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1176946313 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1176950471 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1176951363 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1176952831 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1176953184 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1176960883 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1176963809 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1176965777 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1177061329 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1177064110 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1177066319 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1177067974 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1177069462 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1177071139 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1177071982 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1177085020 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1177084574 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1178061523 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1178072667 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1178076085 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1178100632 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1178101434 From dcubed at openjdk.org Wed Apr 26 16:35:23 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 26 Apr 2023 16:35:23 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v63] In-Reply-To: <89qIyO7ZpW-n-BqgskUr0vD04rjzu7ugBJZj7t5sonA=.2f7ed1ec-a2db-4042-97fd-68db0b02b292@github.com> References: <89qIyO7ZpW-n-BqgskUr0vD04rjzu7ugBJZj7t5sonA=.2f7ed1ec-a2db-4042-97fd-68db0b02b292@github.com> Message-ID: On Wed, 26 Apr 2023 13:16:26 GMT, Roman Kennke wrote: >> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). >> >> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. >> >> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal protocols. >> >> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare. >> >> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. >> >> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. >> >> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. >> >> This change enables to simplify (and speed-up!) a lot of code: >> >> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. >> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR >> >> Also, and I might be mistaken here, this new lightweight locking would make synchronized work better with Loom: Because the lock-records are no longer scattered across the stack, but instead are densely packed into the lock-stack, it should be easy for a vthread to save its lock-stack upon unmounting and restore it when re-mounting. However, I am not sure about this, and this PR does not attempt to implement that support. >> >> Testing: >> - [x] tier1 x86_64 x aarch64 x +UseFastLocking >> - [x] tier2 x86_64 x aarch64 x +UseFastLocking >> - [x] tier3 x86_64 x aarch64 x +UseFastLocking >> - [x] tier4 x86_64 x aarch64 x +UseFastLocking >> - [x] tier1 x86_64 x aarch64 x -UseFastLocking >> - [x] tier2 x86_64 x aarch64 x -UseFastLocking >> - [x] tier3 x86_64 x aarch64 x -UseFastLocking >> - [x] tier4 x86_64 x aarch64 x -UseFastLocking >> - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet >> >> ### Performance >> >> #### Simple Microbenchmark >> >> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops. >> >> | | x86_64 | aarch64 | >> | -- | -- | -- | >> | -UseFastLocking | 20.651 | 20.764 | >> | +UseFastLocking | 18.896 | 18.908 | >> >> >> #### Renaissance >> >> ? | x86_64 | ? | ? | ? | aarch64 | ? | ? >> -- | -- | -- | -- | -- | -- | -- | -- >> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? >> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% >> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21% >> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% >> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% >> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% >> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% >> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%% >> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% >> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% >> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% >> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% >> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34% >> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% >> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% >> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% >> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% >> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% >> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% >> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% >> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% >> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Suggested changes by @merykitty src/hotspot/share/runtime/synchronizer.cpp line 994: > 992: // Cannot have assertion since this object may have been > 993: // locked by another thread when reaching here. > 994: // assert(mark.is_neutral(), "sanity check"); Hmmm... why delete this comment block? It's there to document the racy nature of this function... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1178078300 From dcubed at openjdk.org Wed Apr 26 16:34:56 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 26 Apr 2023 16:34:56 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v62] In-Reply-To: References: <9aK0kPPAYJYmaffnYZ47rIkDC8El1snix1GhTeUTBnE=.54c3e35d-b285-4c04-9e3f-ab2751902724@github.com> Message-ID: On Wed, 26 Apr 2023 10:43:48 GMT, Roman Kennke wrote: >> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 701: >> >>> 699: // ZFlag == 0 count in slow path >>> 700: jccb(Assembler::notZero, NO_COUNT); // jump if ZFlag == 0 >>> 701: >> >> `DONE_LABEL` is conditionally jumped into from a lot of places, the only path it is reached without known `ZF` seems to be `LM_LEGAGY` fall-through. Maybe refactor a little to eliminate this block. > > I intentionally have not changed the existing paths to make it absolutely clear that the old behaviour is not changed. I'd rather make any changes to the stack-locking in a separate follow-up. Thanks for minimizing changes to the old/legacy code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1178113575 From dcubed at openjdk.org Wed Apr 26 16:47:00 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 26 Apr 2023 16:47:00 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v60] In-Reply-To: References: Message-ID: On Mon, 24 Apr 2023 19:42:35 GMT, Roman Kennke wrote: >> Hi there, >> what is needed to bring this PR over the approval line? > >> @rkennke - I'm planning to do another crawl thru review next week. > > Thanks! That is greatly appeciated! @rkennke - finished my second crawl thru review of 60/68 files changed. I only skipped the RISC-V files since I know nada about that platform... My Mach5 testing of v61 is running Tier7 and I hope to start Tier8 later tonight. So far all testing looks good, but I'll include the usual summary comment in the bug report... ------------- PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1523702754 From cjplummer at openjdk.org Wed Apr 26 17:38:31 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 26 Apr 2023 17:38:31 GMT Subject: RFR: 8306705: com/sun/jdi/PopAndInvokeTest.java fails with NativeMethodException In-Reply-To: <8Ck4ju836i48Wi-oUWYwurOyKvKjWGLjCuSi8Rk9COA=.5ac9eed8-5d22-419b-be90-06ba572149c9@github.com> References: <8Ck4ju836i48Wi-oUWYwurOyKvKjWGLjCuSi8Rk9COA=.5ac9eed8-5d22-419b-be90-06ba572149c9@github.com> Message-ID: On Tue, 25 Apr 2023 21:07:34 GMT, Chris Plummer wrote: > Recently [JDK-8305511](https://bugs.openjdk.org/browse/JDK-8305511) removed the "@ignore 6951287 ", allowing this test to run, which is why this failure mode is now turning up. > > There is a race condition, leading to the `popFrames()` call being done while a native method is in the set of frames to be popped. This results in a `NativeMethodException` instead of the frames being popped. The debuggee has: > > > public static void waiter() { > if (waiting) { > return; > } > waiting = true; > System.out.println(" debuggee: in waiter"); > while (true) { > } > } > > > And the debugger waits for `waiting == true` (checked via JDI calls) before suspending and doing the `popFrames()`. The problem is the println() after setting `waiting = true`. The debugger side can detect that `waiting == true` before the println() is complete, and the println() involves native code. Once `waiting` is set true, we need to make sure no other method calls are made so we can be sure that only the `waiter()` method is on the stack. > > Note there is a lot of interesting history to this CR, including [JDK-6417053](https://bugs.openjdk.org/browse/JDK-6417053), which actually reproduced this issue long ago (but got closed as CNR), although it failed with a different error message (even though it was the same issue), and the different error message was itself the result of another bug that was inadvertently fixed when virtual threads support was added to JDI. See the CR for details if you are interested. Thanks for the reviews Serguei, Alex, and Leonid! ------------- PR Comment: https://git.openjdk.org/jdk/pull/13657#issuecomment-1523802080 From cjplummer at openjdk.org Wed Apr 26 17:39:52 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 26 Apr 2023 17:39:52 GMT Subject: RFR: 8306858: Remove some remnants of CMS from SA agent [v2] In-Reply-To: References: Message-ID: On Wed, 26 Apr 2023 08:41:30 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that removes some remaining CMS related stuff. >> >> Testing: tier1-3, gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > cplummer review Looks good. ------------- Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13646#pullrequestreview-1402482123 From cjplummer at openjdk.org Wed Apr 26 17:40:23 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 26 Apr 2023 17:40:23 GMT Subject: RFR: 8306836: Remove pinned tag for G1 heap regions [v3] In-Reply-To: References: Message-ID: On Wed, 26 Apr 2023 09:12:24 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that removes the pinned tag from `HeapRegion`. >> >> So that "pinned" tag for G1 heap regions indicates that the region should not move during (young) gc. This applies to now removed archive regions and humongous objects/regions. >> >> With "real" g1 region pinning to deal with gclocker in g1 once and for all upcoming we need a refcount, a single bit is not sufficient anymore. Further there will be a naming conflict as this kind of "pinning" is different to g1 region pinning "pinning". The former indicates "contents can not be moved, but can be reclaimed", while the latter means "contents can not be moved and not reclaimed". >> >> The (current) pinned flag is surprisingly little used, only for policy decisions. >> >> The suggestion this change implements is to remove the "pinned" tag as it is, and reserve it for future g1 region pinning (that needs to store the pinning attribute differently as a refcount anyway). >> >> Testing: tier1-3, gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > cplummer review SA changes look good. ------------- Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13643#pullrequestreview-1402487734 From cjplummer at openjdk.org Wed Apr 26 17:51:25 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 26 Apr 2023 17:51:25 GMT Subject: RFR: 8305771: SA ClassWriter.java fails to skip overpass methods In-Reply-To: <-XH_mUzboaslSO3DZ3Mx4Bj35LnXKiBPQzGFB-r6pPU=.5215d237-2b54-44ae-a7e5-6972549a6977@github.com> References: <-XH_mUzboaslSO3DZ3Mx4Bj35LnXKiBPQzGFB-r6pPU=.5215d237-2b54-44ae-a7e5-6972549a6977@github.com> Message-ID: On Tue, 25 Apr 2023 23:49:56 GMT, Ioi Lam wrote: > Please review this trivial fix. > > When checking for bits in `m.getAccessFlags()`, the mask `JVM_RECOGNIZED_METHOD_MODIFIERS` should be applied (similar to other uses of `m.getAccessFlags()` in ClassWriter.java Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13663#pullrequestreview-1402499594 From kevinw at openjdk.org Wed Apr 26 17:51:27 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 26 Apr 2023 17:51:27 GMT Subject: RFR: 8305771: SA ClassWriter.java fails to skip overpass methods In-Reply-To: <-XH_mUzboaslSO3DZ3Mx4Bj35LnXKiBPQzGFB-r6pPU=.5215d237-2b54-44ae-a7e5-6972549a6977@github.com> References: <-XH_mUzboaslSO3DZ3Mx4Bj35LnXKiBPQzGFB-r6pPU=.5215d237-2b54-44ae-a7e5-6972549a6977@github.com> Message-ID: On Tue, 25 Apr 2023 23:49:56 GMT, Ioi Lam wrote: > Please review this trivial fix. > > When checking for bits in `m.getAccessFlags()`, the mask `JVM_RECOGNIZED_METHOD_MODIFIERS` should be applied (similar to other uses of `m.getAccessFlags()` in ClassWriter.java Marked as reviewed by kevinw (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13663#pullrequestreview-1402508359 From cjplummer at openjdk.org Wed Apr 26 17:54:55 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 26 Apr 2023 17:54:55 GMT Subject: Integrated: 8306705: com/sun/jdi/PopAndInvokeTest.java fails with NativeMethodException In-Reply-To: <8Ck4ju836i48Wi-oUWYwurOyKvKjWGLjCuSi8Rk9COA=.5ac9eed8-5d22-419b-be90-06ba572149c9@github.com> References: <8Ck4ju836i48Wi-oUWYwurOyKvKjWGLjCuSi8Rk9COA=.5ac9eed8-5d22-419b-be90-06ba572149c9@github.com> Message-ID: On Tue, 25 Apr 2023 21:07:34 GMT, Chris Plummer wrote: > Recently [JDK-8305511](https://bugs.openjdk.org/browse/JDK-8305511) removed the "@ignore 6951287 ", allowing this test to run, which is why this failure mode is now turning up. > > There is a race condition, leading to the `popFrames()` call being done while a native method is in the set of frames to be popped. This results in a `NativeMethodException` instead of the frames being popped. The debuggee has: > > > public static void waiter() { > if (waiting) { > return; > } > waiting = true; > System.out.println(" debuggee: in waiter"); > while (true) { > } > } > > > And the debugger waits for `waiting == true` (checked via JDI calls) before suspending and doing the `popFrames()`. The problem is the println() after setting `waiting = true`. The debugger side can detect that `waiting == true` before the println() is complete, and the println() involves native code. Once `waiting` is set true, we need to make sure no other method calls are made so we can be sure that only the `waiter()` method is on the stack. > > Note there is a lot of interesting history to this CR, including [JDK-6417053](https://bugs.openjdk.org/browse/JDK-6417053), which actually reproduced this issue long ago (but got closed as CNR), although it failed with a different error message (even though it was the same issue), and the different error message was itself the result of another bug that was inadvertently fixed when virtual threads support was added to JDI. See the CR for details if you are interested. This pull request has now been integrated. Changeset: 38cc0391 Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/38cc0391f3f7272167f92a4c2faa9fae21a26ef9 Stats: 3 lines in 1 file changed: 2 ins; 1 del; 0 mod 8306705: com/sun/jdi/PopAndInvokeTest.java fails with NativeMethodException Reviewed-by: lmesnik, amenkov, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/13657 From cjplummer at openjdk.org Wed Apr 26 18:03:04 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 26 Apr 2023 18:03:04 GMT Subject: RFR: 8306851: Move Method access flags In-Reply-To: References: Message-ID: On Tue, 25 Apr 2023 19:09:23 GMT, Coleen Phillimore wrote: > This change moves the flags from AccessFlags to either ConstMethodFlags or MethodFlags, depending on whether they are set at class file parse time, which makes them essentially const, or at runtime, which makes them needing atomic access. > > This leaves AccessFlags int size because Klass still has JVM flags that are more work to move, but this change doesn't increase Method size. I didn't remove JVM_RECOGNIZED_METHOD_MODIFIERS with this change since there are several of these in other places, and with this change the code is benign. > > Tested with tier1-6, and some manual verification of printing. The SA changes look good. I think these changes make @iklam's #13663 fix unnecessary, but harmless. ------------- Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13654#pullrequestreview-1402521002 From ysr at openjdk.org Wed Apr 26 18:28:23 2023 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Wed, 26 Apr 2023 18:28:23 GMT Subject: RFR: 8306858: Remove some remnants of CMS from SA agent [v2] In-Reply-To: References: Message-ID: On Wed, 26 Apr 2023 08:41:30 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that removes some remaining CMS related stuff. >> >> Testing: tier1-3, gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > cplummer review Marked as reviewed by ysr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13646#pullrequestreview-1402551121 From rkennke at openjdk.org Wed Apr 26 19:04:28 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 26 Apr 2023 19:04:28 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v60] In-Reply-To: References: Message-ID: On Mon, 24 Apr 2023 19:42:35 GMT, Roman Kennke wrote: >> Hi there, >> what is needed to bring this PR over the approval line? > >> @rkennke - I'm planning to do another crawl thru review next week. > > Thanks! That is greatly appeciated! > @rkennke - finished my second crawl thru review of 60/68 files changed. I only skipped the RISC-V files since I know nada about that platform... > > My Mach5 testing of v61 is running Tier7 and I hope to start Tier8 later tonight. So far all testing looks good, but I'll include the usual summary comment in the bug report... Thanks so much for reviewing this large PR (so many times)! I believe I have incorporated all your suggestions (or left a comment/question when it wasn't clear). Cheers, Roman ------------- PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1523901201 From rkennke at openjdk.org Wed Apr 26 19:04:32 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 26 Apr 2023 19:04:32 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v62] In-Reply-To: References: Message-ID: On Mon, 24 Apr 2023 22:51:10 GMT, Daniel D. Daugherty wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unnecessary comments > > src/hotspot/cpu/arm/macroAssembler_arm.cpp line 1803: > >> 1801: #ifdef ASSERT >> 1802: // Poison scratch regs >> 1803: POISON_REGS((~savemask), t1, t2, t3, 0x10000001); > > Should this poison value be: 0x20000002 Why? > src/hotspot/share/logging/logTag.hpp line 80: > >> 78: LOG_TAG(exceptions) \ >> 79: LOG_TAG(exit) \ >> 80: LOG_TAG(fastlock2) \ > > So why 'fastlock2'? Where's 'fastlock1'? Or 'fastlock'? It's currently only used in the arm port. I'm changing it to 'fastlock', ok? > src/hotspot/share/runtime/arguments.cpp line 1994: > >> 1992: if (UseHeavyMonitors) { >> 1993: FLAG_SET_CMDLINE(LockingMode, LM_MONITOR); >> 1994: } > > HotSpot option processing has a general rule of last setting wins. > With L1992-1994 here, I think there might be a problem with a cmd > line that specifies: > > -XX:+UseHeavyMonitors -XX:LockingMode=1 > > I think that the resulting value of `LockingMode` will be `LM_MONITOR` > instead of `LM_LEGACY`. Granted mixing uses of `UseHeavyMonitors` > with `LockingMode` is just asking for trouble... I added a check that rejects conflicting +UseHeavyMonitors and LockingMode=X flags on the cmd line. UseHeavyMonitors is already deprecated, and with the new LockingMode flag should be removed asap (in a follow-up PR). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1178244295 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1178253708 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1178260893 From stuefe at openjdk.org Wed Apr 26 19:04:33 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 26 Apr 2023 19:04:33 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v62] In-Reply-To: References: Message-ID: <1M7ql10BxRIBDp38CNNb_D0i6CE4O-97lGFO7iDRaFI=.570de882-cda2-4582-a4eb-c49cbc38aff6@github.com> On Mon, 24 Apr 2023 22:51:10 GMT, Daniel D. Daugherty wrote: >> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unnecessary comments > > src/hotspot/cpu/arm/macroAssembler_arm.cpp line 1803: > >> 1801: #ifdef ASSERT >> 1802: // Poison scratch regs >> 1803: POISON_REGS((~savemask), t1, t2, t3, 0x10000001); > > Should this poison value be: 0x20000002 The poison values were something I used during development of the arm part, bug hunting wise. Though I think they make sense in general. I agree with @dcubed-ojdk, 0x2000002 would be the most logical value here. Either that or remove the poisening (though it had been useful). > src/hotspot/cpu/arm/sharedRuntime_arm.cpp line 649: > >> 647: >> 648: __ flush(); >> 649: return AdapterHandlerLibrary::new_entry(fingerprint, i2c_entry, c2i_entry, c2i_unverified_entry); > > This change seems out of place... what's the story here? This is a local revert of *8303154: Investigate and improve instruction cache flushing during compilation* - the missing flush caused random crashes, but I did not have time to investigate. I reverted the flush, crashes were gone. If needed I may revisit this when there is time. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1178250178 PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1178255706 From coleenp at openjdk.org Wed Apr 26 19:56:54 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 26 Apr 2023 19:56:54 GMT Subject: RFR: 8306851: Move Method access flags In-Reply-To: References: Message-ID: On Tue, 25 Apr 2023 19:09:23 GMT, Coleen Phillimore wrote: > This change moves the flags from AccessFlags to either ConstMethodFlags or MethodFlags, depending on whether they are set at class file parse time, which makes them essentially const, or at runtime, which makes them needing atomic access. > > This leaves AccessFlags int size because Klass still has JVM flags that are more work to move, but this change doesn't increase Method size. I didn't remove JVM_RECOGNIZED_METHOD_MODIFIERS with this change since there are several of these in other places, and with this change the code is benign. > > Tested with tier1-6, and some manual verification of printing. Thanks Chris. We were wondering what to do with JVM_RECOGNIZED_METHOD_MODIFIERS but we'll clean them up in another pass. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13654#issuecomment-1523947642 From iklam at openjdk.org Wed Apr 26 21:06:56 2023 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 26 Apr 2023 21:06:56 GMT Subject: RFR: 8305771: SA ClassWriter.java fails to skip overpass methods In-Reply-To: References: <-XH_mUzboaslSO3DZ3Mx4Bj35LnXKiBPQzGFB-r6pPU=.5215d237-2b54-44ae-a7e5-6972549a6977@github.com> Message-ID: On Wed, 26 Apr 2023 17:43:26 GMT, Kevin Walls wrote: >> Please review this trivial fix. >> >> When checking for bits in `m.getAccessFlags()`, the mask `JVM_RECOGNIZED_METHOD_MODIFIERS` should be applied (similar to other uses of `m.getAccessFlags()` in ClassWriter.java > > Marked as reviewed by kevinw (Committer). Thanks @kevinjwalls and @plummercj for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13663#issuecomment-1524031268 From iklam at openjdk.org Wed Apr 26 21:06:59 2023 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 26 Apr 2023 21:06:59 GMT Subject: Integrated: 8305771: SA ClassWriter.java fails to skip overpass methods In-Reply-To: <-XH_mUzboaslSO3DZ3Mx4Bj35LnXKiBPQzGFB-r6pPU=.5215d237-2b54-44ae-a7e5-6972549a6977@github.com> References: <-XH_mUzboaslSO3DZ3Mx4Bj35LnXKiBPQzGFB-r6pPU=.5215d237-2b54-44ae-a7e5-6972549a6977@github.com> Message-ID: On Tue, 25 Apr 2023 23:49:56 GMT, Ioi Lam wrote: > Please review this trivial fix. > > When checking for bits in `m.getAccessFlags()`, the mask `JVM_RECOGNIZED_METHOD_MODIFIERS` should be applied (similar to other uses of `m.getAccessFlags()` in ClassWriter.java This pull request has now been integrated. Changeset: 750bece0 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/750bece0c2f331025590e7358c7b69f4811f0d24 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8305771: SA ClassWriter.java fails to skip overpass methods Reviewed-by: kevinw, cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/13663 From dcubed at openjdk.org Wed Apr 26 21:08:19 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 26 Apr 2023 21:08:19 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v62] In-Reply-To: <1M7ql10BxRIBDp38CNNb_D0i6CE4O-97lGFO7iDRaFI=.570de882-cda2-4582-a4eb-c49cbc38aff6@github.com> References: <1M7ql10BxRIBDp38CNNb_D0i6CE4O-97lGFO7iDRaFI=.570de882-cda2-4582-a4eb-c49cbc38aff6@github.com> Message-ID: On Wed, 26 Apr 2023 18:29:36 GMT, Thomas Stuefe wrote: >> src/hotspot/cpu/arm/macroAssembler_arm.cpp line 1803: >> >>> 1801: #ifdef ASSERT >>> 1802: // Poison scratch regs >>> 1803: POISON_REGS((~savemask), t1, t2, t3, 0x10000001); >> >> Should this poison value be: 0x20000002 > > The poison values were something I used during development of the arm part, bug hunting wise. Though I think they make sense in general. I agree with @dcubed-ojdk, 0x2000002 would be the most logical value here. Either that or remove the poisening (though it had been useful). 0x20000002 because 0x10000001 was used earlier and it would be good to keep the poisoning values unique. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1178390683 From dcubed at openjdk.org Wed Apr 26 21:08:21 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 26 Apr 2023 21:08:21 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v62] In-Reply-To: References: <9aK0kPPAYJYmaffnYZ47rIkDC8El1snix1GhTeUTBnE=.54c3e35d-b285-4c04-9e3f-ab2751902724@github.com> <_Y6eLacV_ecmijvlzo2lGe-U5n6ZtaJnUA6KL9BsJJw=.a66f23b0-aaf6-43ac-a210-ad830a1e744c@github.com> Message-ID: On Wed, 26 Apr 2023 11:00:33 GMT, Quan Anh Mai wrote: >> How would I check if we are emitting code? >> >> I am not sure I understand. The check for ANONYMOUS is only relevant when we observe an already-inflated monitor. I think this is the right place to put it. > > The entry barrier does this: > > https://github.com/openjdk/jdk/blob/86f41a4c42268d364175263804eb4d1ce82fa943/src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp#L139 > > `testptr(tmpReg, markWord::monitor_value)` is checking for inflation, and the following `if` block acts when inflation is detected, what I mean is to move the whole enclosed if down out of the `if (LockingMode != LM_MONITOR)` It took a couple of re-reads to figure this out. You've added a scratch emit size check before generating the C2HandleAnonOMOwnerStub. For some reason, the way that GitHub shows those changes really confused my brain... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1178116470 From dcubed at openjdk.org Wed Apr 26 21:08:23 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 26 Apr 2023 21:08:23 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v62] In-Reply-To: References: Message-ID: On Wed, 26 Apr 2023 18:33:28 GMT, Roman Kennke wrote: >> src/hotspot/share/logging/logTag.hpp line 80: >> >>> 78: LOG_TAG(exceptions) \ >>> 79: LOG_TAG(exit) \ >>> 80: LOG_TAG(fastlock2) \ >> >> So why 'fastlock2'? Where's 'fastlock1'? Or 'fastlock'? > > It's currently only used in the arm port. I'm changing it to 'fastlock', ok? Yup. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1178391272 From yyang at openjdk.org Thu Apr 27 03:30:54 2023 From: yyang at openjdk.org (Yi Yang) Date: Thu, 27 Apr 2023 03:30:54 GMT Subject: RFR: JDK-8306441: Segmented heap dump [v2] In-Reply-To: <8YqPPHSW4K1s0t317Kp6UqvoGuv5v9oCbjtQ9FX8p2o=.0f6c687b-d031-401d-901d-1ec532715cdc@github.com> References: <8YqPPHSW4K1s0t317Kp6UqvoGuv5v9oCbjtQ9FX8p2o=.0f6c687b-d031-401d-901d-1ec532715cdc@github.com> Message-ID: <5QngamRNdNy33AGwJkIuvQUjQkbd_FlvtfyOW099LdU=.0393cf6a-38dc-4dc8-9eba-36979de680c9@github.com> > Hi, heap dump brings about pauses for application's execution(STW), this is a well-known pain. JDK-8252842 have added parallel support to heapdump in an attempt to alleviate this issue. However, all concurrent threads competitively write heap data to the same file, and more memory is required to maintain the concurrent buffer queue. In experiments, we did not feel a significant performance improvement from that. > > The minor-pause solution, which is presented in this PR, is a two-stage segmented heap dump: > > 1. Stage One(STW): Concurrent threads directly write data to multiple heap files. > 2. Stage Two(Non-STW): Merge multiple heap files into one complete heap dump file. > > Now concurrent worker threads are not required to maintain a buffer queue, which would result in more memory overhead, nor do they need to compete for locks. It significantly reduces 73~80% application pause time. > > | memory | numOfThread | STW | Total | > | --- | --------- | -------------- | ------------ | > | 8g | 1 thread | 15.612 secs | 15.612 secs | > | 8g | 32 thread | 2.5617250 secs | 14.498 secs | > | 8g | 96 thread | 2.6790452 secs | 14.012 secs | > | 16g | 1 thread | 26.278 secs | 26.278 secs | > | 16g | 32 thread | 5.2313740 secs | 26.417 secs | > | 16g | 96 thread | 6.2445556 secs | 27.141 secs | > | 32g | 1 thread | 48.149 secs | 48.149 secs | > | 32g | 32 thread | 10.7734677 secs | 61.643 secs | > | 32g | 96 thread | 13.1522042 secs | 61.432 secs | > | 64g | 1 thread | 100.583 secs | 100.583 secs | > | 64g | 32 thread | 20.9233744 secs | 134.701 secs | > | 64g | 96 thread | 26.7374116 secs | 126.080 secs | > | 128g | 1 thread | 233.843 secs | 233.843 secs | > | 128g | 32 thread | 72.9945768 secs | 207.060 secs | > | 128g | 96 thread | 67.6815929 secs | 336.345 secs | > >> **Total** means the total heap dump including both two phases >> **STW** means the first phase only. >> For parallel dump, **Total** = **STW** + **Merge**. For serial dump, **Total** = **STW** > > ![image](https://user-images.githubusercontent.com/5010047/234534654-6f29a3af-dad5-46bc-830b-7449c80b4dec.png) > > In actual testing, two-stage solution can lead to an increase in the overall time for heapdump(See table above). However, considering the reduction of STW time, I think it is an acceptable trade-off. Furthermore, there is still room for optimization in the second merge stage(e.g. sendfile/splice/copy_file_range instead of read+write combination). Since number of parallel dump thread has a considerable impact on total dump time, I added a parameter that allows users to specify the number of parallel dump thread they wish to run. > > ##### Open discussion > > - Pauseless heap dump solution? > An alternative pauseless solution is to fork a child process, set the parent process heap to read-only, and dump the heap in child process. Once writing happens in parent process, child process observes them by userfaultfd and corresponding pages are prioritized for dumping. I'm also looking forward to hearing comments and discussions about this solution. > > - Client parser support for segmented heap dump > This patch provides a possibility that whether heap dump needs to be complete or not, can the VM directly generate segmented heapdump, and let the client parser complete the merge process? Looking forward to hearing comments from the Eclipse MAT community Yi Yang has updated the pull request incrementally with two additional commits since the last revision: - max_path check - fix test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13667/files - new: https://git.openjdk.org/jdk/pull/13667/files/620d94dc..00b49e4e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13667&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13667&range=00-01 Stats: 21 lines in 1 file changed: 12 ins; 5 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13667.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13667/head:pull/13667 PR: https://git.openjdk.org/jdk/pull/13667 From sspitsyn at openjdk.org Thu Apr 27 03:46:29 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 27 Apr 2023 03:46:29 GMT Subject: RFR: 8306028: separate ThreadStart/ThreadEnd events posting code in JVMTI VTMS transitions [v4] In-Reply-To: References: Message-ID: > This refactoring to separate ThreadStart/ThreadEnd events posting code in the JVMTI VTMS transitions is needed for future work on JVMTI scalability and performance improvements. It is to easier put this code on slow path. > > Testing: mach5 tiers 1-6 were successful. Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - Merge branch 'master' into br29 - do more refactoring including VirtualThread class - Merge - 8304444: Reappearance of NULL in jvmtiThreadState.cpp - 8306028: separate ThreadStart/ThreadEnd events posting code in JVMTI VTMS transitions ------------- Changes: https://git.openjdk.org/jdk/pull/13484/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13484&range=03 Stats: 331 lines in 16 files changed: 182 ins; 71 del; 78 mod Patch: https://git.openjdk.org/jdk/pull/13484.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13484/head:pull/13484 PR: https://git.openjdk.org/jdk/pull/13484 From sspitsyn at openjdk.org Thu Apr 27 03:55:54 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 27 Apr 2023 03:55:54 GMT Subject: RFR: 8306028: separate ThreadStart/ThreadEnd events posting code in JVMTI VTMS transitions [v3] In-Reply-To: References: Message-ID: On Wed, 19 Apr 2023 22:02:20 GMT, Serguei Spitsyn wrote: >> This refactoring to separate ThreadStart/ThreadEnd events posting code in the JVMTI VTMS transitions is needed for future work on JVMTI scalability and performance improvements. It is to easier put this code on slow path. >> >> Testing: mach5 tiers 1-6 were successful. > > Serguei Spitsyn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge > - 8304444: Reappearance of NULL in jvmtiThreadState.cpp > - 8306028: separate ThreadStart/ThreadEnd events posting code in JVMTI VTMS transitions Added update with refactoring prepared by @pchilano . This update includes some renaming to make function names more consistent. The mach5 runs of tiers 1-6 are all passed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13484#issuecomment-1524617260 From sspitsyn at openjdk.org Thu Apr 27 04:52:53 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 27 Apr 2023 04:52:53 GMT Subject: RFR: 8306028: separate ThreadStart/ThreadEnd events posting code in JVMTI VTMS transitions [v5] In-Reply-To: References: Message-ID: > This refactoring to separate ThreadStart/ThreadEnd events posting code in the JVMTI VTMS transitions is needed for future work on JVMTI scalability and performance improvements. It is to easier put this code on slow path. > > Testing: mach5 tiers 1-6 were successful. Serguei Spitsyn has updated the pull request incrementally with two additional commits since the last revision: - Merge branch 'br29' of https://github.com/sspitsyn/jdk into br29 merge with branch29 - move code a little bit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13484/files - new: https://git.openjdk.org/jdk/pull/13484/files/639b2110..debe49c3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13484&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13484&range=03-04 Stats: 52 lines in 2 files changed: 24 ins; 24 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13484.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13484/head:pull/13484 PR: https://git.openjdk.org/jdk/pull/13484 From dholmes at openjdk.org Thu Apr 27 05:00:53 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 27 Apr 2023 05:00:53 GMT Subject: RFR: 8306851: Move Method access flags In-Reply-To: References: Message-ID: <4MFJ-FafLsw4MTThURBlLZAvFZauwOd0VPklgivnehU=.4a24c95f-8c5f-416b-a63d-c21d58501dae@github.com> On Tue, 25 Apr 2023 19:09:23 GMT, Coleen Phillimore wrote: > This change moves the flags from AccessFlags to either ConstMethodFlags or MethodFlags, depending on whether they are set at class file parse time, which makes them essentially const, or at runtime, which makes them needing atomic access. > > This leaves AccessFlags int size because Klass still has JVM flags that are more work to move, but this change doesn't increase Method size. I didn't remove JVM_RECOGNIZED_METHOD_MODIFIERS with this change since there are several of these in other places, and with this change the code is benign. > > Tested with tier1-6, and some manual verification of printing. General idea is good but I have some issues with naming inconsistencies. A few other queries. Thanks. src/hotspot/share/classfile/classFileParser.cpp line 2741: > 2739: parsed_annotations.apply_to(methodHandle(THREAD, m)); > 2740: > 2741: if (is_hidden() && !m->is_hidden()) { // Mark methods in hidden classes as 'hidden'. This seems odd - how would m already be marked hidden? And why do we care? The check-and-branch is more expensive than just setting the field. src/hotspot/share/oops/constMethodFlags.hpp line 34: > 32: > 33: // The ConstMethodFlags class contains the parse-time flags associated with > 34: // an Method, and their associated accessors. s/an/a/ s/their/its/ src/hotspot/share/oops/constMethodFlags.hpp line 53: > 51: flag(has_type_annotations , 1 << 9) \ > 52: flag(has_default_annotations , 1 << 10) \ > 53: flag(caller_sensitive , 1 << 11) \ Nit: we should consistently use either `x` or `is_x` for `x` in `overpass, caller_sensitive, hidden, scoped, ...` src/hotspot/share/oops/method.cpp line 735: > 733: case Bytecodes::_jsr: > 734: if (bcs.dest() < bcs.next_bci()) { > 735: return set_has_loops(); I don't understand the new return logic here. The break gets us out of the switch but we are still in the while loop, but the return takes us all the way out. ??? src/hotspot/share/oops/method.hpp line 808: > 806: > 807: bool is_hidden() const { return constMethod()->is_hidden(); } > 808: void set_hidden() { constMethod()->set_is_hidden(); } The naming is inconsistent here regarding `is` - either both should have it or neither IMO. src/hotspot/share/oops/method.hpp line 871: > 869: void clear_not_c2_compilable() { set_not_c2_compilable(false); } > 870: > 871: bool is_not_c1_osr_compilable() const { return not_c1_compilable(); } // don't waste a flags bit Again inconsistent naming with `is` but also `osr` in this case. I would expect being compilable to be quite different to being "osr compilable". ------------- PR Review: https://git.openjdk.org/jdk/pull/13654#pullrequestreview-1403149129 PR Review Comment: https://git.openjdk.org/jdk/pull/13654#discussion_r1178611573 PR Review Comment: https://git.openjdk.org/jdk/pull/13654#discussion_r1178613648 PR Review Comment: https://git.openjdk.org/jdk/pull/13654#discussion_r1178614433 PR Review Comment: https://git.openjdk.org/jdk/pull/13654#discussion_r1178618364 PR Review Comment: https://git.openjdk.org/jdk/pull/13654#discussion_r1178619597 PR Review Comment: https://git.openjdk.org/jdk/pull/13654#discussion_r1178620558 From dholmes at openjdk.org Thu Apr 27 05:01:23 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 27 Apr 2023 05:01:23 GMT Subject: RFR: 8306851: Move Method access flags In-Reply-To: <4MFJ-FafLsw4MTThURBlLZAvFZauwOd0VPklgivnehU=.4a24c95f-8c5f-416b-a63d-c21d58501dae@github.com> References: <4MFJ-FafLsw4MTThURBlLZAvFZauwOd0VPklgivnehU=.4a24c95f-8c5f-416b-a63d-c21d58501dae@github.com> Message-ID: On Thu, 27 Apr 2023 04:49:10 GMT, David Holmes wrote: >> This change moves the flags from AccessFlags to either ConstMethodFlags or MethodFlags, depending on whether they are set at class file parse time, which makes them essentially const, or at runtime, which makes them needing atomic access. >> >> This leaves AccessFlags int size because Klass still has JVM flags that are more work to move, but this change doesn't increase Method size. I didn't remove JVM_RECOGNIZED_METHOD_MODIFIERS with this change since there are several of these in other places, and with this change the code is benign. >> >> Tested with tier1-6, and some manual verification of printing. > > src/hotspot/share/oops/method.hpp line 871: > >> 869: void clear_not_c2_compilable() { set_not_c2_compilable(false); } >> 870: >> 871: bool is_not_c1_osr_compilable() const { return not_c1_compilable(); } // don't waste a flags bit > > Again inconsistent naming with `is` but also `osr` in this case. I would expect being compilable to be quite different to being "osr compilable". Ah I get this bit now - but the comment didn't make it clear. For C1 compilable and osr-compilable are considered the same. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13654#discussion_r1178623386 From duke at openjdk.org Thu Apr 27 06:07:52 2023 From: duke at openjdk.org (Afshin Zafari) Date: Thu, 27 Apr 2023 06:07:52 GMT Subject: RFR: 8305590: Remove nothrow exception specifications from operator new [v3] In-Reply-To: References: <5uZmZV3ssLzKKFBeajmWUBmZsaZeq-3ImeHkzCvnSwg=.4941a9c0-b250-4290-828a-15416ed791df@github.com> <7EfFlEYBncjzdoZzU_gdl8tB7kpj_z3ga_h-fXxy0Os=.42af4f0f-e003-4a54-bf79-603c80bdd12f@github.com> Message-ID: On Mon, 24 Apr 2023 00:23:18 GMT, Kim Barrett wrote: > I believe this may have missed removing the exception specifier from an operator new inside AnyObj, allocation.cpp, since gcc 12 and up on my end now refuses to compile HotSpot with this change. I'll create a cleanup change for this, if there isn't any opposition to that To be able to work on this, please file an issue for this case including the error and the way to reproduce it. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13498#issuecomment-1524762797 From tschatzl at openjdk.org Thu Apr 27 07:41:24 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 27 Apr 2023 07:41:24 GMT Subject: RFR: 8306858: Remove some remnants of CMS from SA agent [v2] In-Reply-To: References: Message-ID: On Tue, 25 Apr 2023 16:43:27 GMT, Aleksey Shipilev wrote: >> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: >> >> cplummer review > > Looks fine to me. > > But the synopsis has a typo, "remnants". Thanks @shipilev @kimbarrett @plummercj @ysr for you reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13646#issuecomment-1524964919 From tschatzl at openjdk.org Thu Apr 27 07:41:26 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 27 Apr 2023 07:41:26 GMT Subject: Integrated: 8306858: Remove some remnants of CMS from SA agent In-Reply-To: References: Message-ID: On Tue, 25 Apr 2023 16:25:40 GMT, Thomas Schatzl wrote: > Hi all, > > please review this change that removes some remaining CMS related stuff. > > Testing: tier1-3, gha > > Thanks, > Thomas This pull request has now been integrated. Changeset: d94ce656 Author: Thomas Schatzl URL: https://git.openjdk.org/jdk/commit/d94ce6566d50fc0a6218adbb64d8f90e9eeb844a Stats: 16 lines in 4 files changed: 0 ins; 12 del; 4 mod 8306858: Remove some remnants of CMS from SA agent Reviewed-by: shade, cjplummer, kbarrett, ysr ------------- PR: https://git.openjdk.org/jdk/pull/13646 From rkennke at openjdk.org Thu Apr 27 07:52:23 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 27 Apr 2023 07:52:23 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v64] In-Reply-To: References: Message-ID: > This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). > > What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. > > This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p rotocols. > > The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare. > > In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. > > One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. > > As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. > > This change enables to simplify (and speed-up!) a lot of code: > > - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. > - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR > > Also, and I might be mistaken here, this new lightweight locking would make synchronized work better with Loom: Because the lock-records are no longer scattered across the stack, but instead are densely packed into the lock-stack, it should be easy for a vthread to save its lock-stack upon unmounting and restore it when re-mounting. However, I am not sure about this, and this PR does not attempt to implement that support. > > Testing: > - [x] tier1 x86_64 x aarch64 x +UseFastLocking > - [x] tier2 x86_64 x aarch64 x +UseFastLocking > - [x] tier3 x86_64 x aarch64 x +UseFastLocking > - [x] tier4 x86_64 x aarch64 x +UseFastLocking > - [x] tier1 x86_64 x aarch64 x -UseFastLocking > - [x] tier2 x86_64 x aarch64 x -UseFastLocking > - [x] tier3 x86_64 x aarch64 x -UseFastLocking > - [x] tier4 x86_64 x aarch64 x -UseFastLocking > - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet > > ### Performance > > #### Simple Microbenchmark > > The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops. > > | | x86_64 | aarch64 | > | -- | -- | -- | > | -UseFastLocking | 20.651 | 20.764 | > | +UseFastLocking | 18.896 | 18.908 | > > > #### Renaissance > > ? | x86_64 | ? | ? | ? | aarch64 | ? | ? > -- | -- | -- | -- | -- | -- | -- | -- > ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? > AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% > Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21% > Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% > ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% > GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% > LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% > MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%% > NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% > PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% > FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% > FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% > ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34% > Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% > RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% > Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% > ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% > FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% > FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Suggestios by @dcubed-ojdk ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10907/files - new: https://git.openjdk.org/jdk/pull/10907/files/5f927f9c..1323e958 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=63 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=62-63 Stats: 61 lines in 21 files changed: 11 ins; 10 del; 40 mod Patch: https://git.openjdk.org/jdk/pull/10907.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/10907/head:pull/10907 PR: https://git.openjdk.org/jdk/pull/10907 From sspitsyn at openjdk.org Thu Apr 27 09:14:29 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 27 Apr 2023 09:14:29 GMT Subject: RFR: 8306034: add support of virtual threads to JVMTI StopThread [v6] In-Reply-To: References: Message-ID: > This enhancement adds support of virtual threads to the JVMTI `StopThread` function. > In preview releases before this enhancement the StopThread returned the JVMTI_ERROR_UNSUPPORTED_OPERATION error code for virtual threads. > > The `StopThread` supports sending an asynchronous exception to a virtual thread only if it is current or suspended at mounted state. For instance, a virtual thread can be suspended at a JVMTI event. If the virtual thread is not suspended and is not current then the `JVMTI_ERROR_THREAD_NOT_SUSPENDED` error code is returned. If the virtual thread was suspended at unmounted state then the `JVMTI_ERROR_OPAQUE_FRAME` error code is returned. > > The `StopThread` has the following description for `JVMTI_ERROR_OPAQUE_FRAME` error code: >> The thread is a suspended virtual thread and the implementation >> was unable to throw an asynchronous exception from this frame. > > A couple of the `serviceability/jvmti/vthread` tests has been updated to adopt to new `StopThread` behavior. > > The CSR is: https://bugs.openjdk.org/browse/JDK-8306434 > > Testing: > The mach5 tears 1-6 are in progress. > Preliminary test runs were good in general. > The JDB test `vmTestbase/nsk/jdb/kill/kill001/kill001.java` has been problem-listed and will be fixed by the corresponding debugger enhancement which is going to adopt JDWP/JDI specs to new behavior of the JVMTI `StopThread` related to virtual threads. > > Also, two JCK JVMTI tests are failing in the tier-6 : >> vm/jvmti/StopThread/stop001/stop00103/stop00103.html >> vm/jvmti/StopThread/stop001/stop00103/stop00103a.html > > These two tests will be excluded from the test runs by the JCK team and then adjusted to new `StopThread` behavior. Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: install_async_exception: set interrupt status for platform threads only ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13546/files - new: https://git.openjdk.org/jdk/pull/13546/files/956e8ee8..0113f034 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13546&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13546&range=04-05 Stats: 14 lines in 2 files changed: 9 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/13546.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13546/head:pull/13546 PR: https://git.openjdk.org/jdk/pull/13546 From kevinw at openjdk.org Thu Apr 27 10:11:22 2023 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 27 Apr 2023 10:11:22 GMT Subject: RFR: 8305913: com/sun/jdi/JdbLastErrorTest.java failed with "'lastError = 42' missing from stdout/stderr" [v2] In-Reply-To: References: Message-ID: On Sat, 15 Apr 2023 10:15:20 GMT, Kevin Walls wrote: >> This test is failing often since 8304725 added a call to Thread::current_in_asgct(). This can end up being called e.g. when resolving calls, and then the OS last error value is lost. >> >> The test is reliable with a single warm-up call to getLastError.invoke() before the loop. >> >> The test was introduced when in JDK-8292302 a change was undone that had made JavaThread::threadObj call Thread::current_or_null_safe, as the use of TLS upset this case of accessing last error directly. >> >> This new Thread::current_in_asgct() case shows that the VM will find new ways to interfere with the last error value, or at least new VM code keeps wanting to call Thread::current. This testcase is kind of niche usage, so it not an argument that VM code should not be calling Thread::current. If this test is to stay active, it needs to have this warm-up getLastError call. (If there are more issues, it might mean removing the test.) > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > comment update feedback Thanks for looking at this, and for the Panama pointer to JDK-8294970 - I'm checking if that completely solves it for this testcase... ------------- PR Comment: https://git.openjdk.org/jdk/pull/13481#issuecomment-1525338902 From ayang at openjdk.org Thu Apr 27 10:56:24 2023 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 27 Apr 2023 10:56:24 GMT Subject: RFR: 8306836: Remove pinned tag for G1 heap regions [v3] In-Reply-To: References: Message-ID: On Wed, 26 Apr 2023 09:12:24 GMT, Thomas Schatzl wrote: >> Hi all, >> >> please review this change that removes the pinned tag from `HeapRegion`. >> >> So that "pinned" tag for G1 heap regions indicates that the region should not move during (young) gc. This applies to now removed archive regions and humongous objects/regions. >> >> With "real" g1 region pinning to deal with gclocker in g1 once and for all upcoming we need a refcount, a single bit is not sufficient anymore. Further there will be a naming conflict as this kind of "pinning" is different to g1 region pinning "pinning". The former indicates "contents can not be moved, but can be reclaimed", while the latter means "contents can not be moved and not reclaimed". >> >> The (current) pinned flag is surprisingly little used, only for policy decisions. >> >> The suggestion this change implements is to remove the "pinned" tag as it is, and reserve it for future g1 region pinning (that needs to store the pinning attribute differently as a refcount anyway). >> >> Testing: tier1-3, gha >> >> Thanks, >> Thomas > > Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: > > cplummer review > I think you are right about using is_humongous() directly here: the reason we skip compacting of humongous regions during the "main" compaction is intentional here However, I am unable to discern the difference -- why `is_young_gc_movable` is semantically-correct in one place, but not in the other in this concrete example. bool G1CollectionSetChooser::should_add(HeapRegion* hr) { return !hr->is_young() && G1CollectedHeap::heap()->policy()->is_young_gc_movable(hr) && vs void G1FullCollector::before_marking_update_attribute_table(HeapRegion* hr) { if (hr->is_free()) { _region_attr_table.set_free(hr->hrm_index()); } else if (hr->is_humongous()) { Looking at where `G1CollectionSetChooser::should_add` is called, can one use `hr->is_old()` instead of `!hr->is_young() && G1CollectedHeap::heap()->policy()->is_young_gc_movable(hr)`? (In fact, I believe that inlining `should_add` to the caller would result in a smoother code flow and prevent some duplicate region-type queries.) In my opinion, introducing a new `is_young_gc_movable` API in this particular PR may not be entirely justified. It may make more sense to introduce it in later PRs where region-pinning is supported and the API is actually utilized. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13643#issuecomment-1525434952 From alanb at openjdk.org Thu Apr 27 11:09:53 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 27 Apr 2023 11:09:53 GMT Subject: RFR: 8306034: add support of virtual threads to JVMTI StopThread [v6] In-Reply-To: References: Message-ID: <7fdlC2euVU0tBa91ZqEuLj9QLVNXe5hTT0KnImBaGgw=.e0a45607-2a7b-462c-98b6-16d5982ec495@github.com> On Thu, 27 Apr 2023 09:14:29 GMT, Serguei Spitsyn wrote: >> This enhancement adds support of virtual threads to the JVMTI `StopThread` function. >> In preview releases before this enhancement the StopThread returned the JVMTI_ERROR_UNSUPPORTED_OPERATION error code for virtual threads. >> >> The `StopThread` supports sending an asynchronous exception to a virtual thread only if it is current or suspended at mounted state. For instance, a virtual thread can be suspended at a JVMTI event. If the virtual thread is not suspended and is not current then the `JVMTI_ERROR_THREAD_NOT_SUSPENDED` error code is returned. If the virtual thread was suspended at unmounted state then the `JVMTI_ERROR_OPAQUE_FRAME` error code is returned. >> >> The `StopThread` has the following description for `JVMTI_ERROR_OPAQUE_FRAME` error code: >>> The thread is a suspended virtual thread and the implementation >>> was unable to throw an asynchronous exception from this frame. >> >> A couple of the `serviceability/jvmti/vthread` tests has been updated to adopt to new `StopThread` behavior. >> >> The CSR is: https://bugs.openjdk.org/browse/JDK-8306434 >> >> Testing: >> The mach5 tears 1-6 are in progress. >> Preliminary test runs were good in general. >> The JDB test `vmTestbase/nsk/jdb/kill/kill001/kill001.java` has been problem-listed and will be fixed by the corresponding debugger enhancement which is going to adopt JDWP/JDI specs to new behavior of the JVMTI `StopThread` related to virtual threads. >> >> Also, two JCK JVMTI tests are failing in the tier-6 : >>> vm/jvmti/StopThread/stop001/stop00103/stop00103.html >>> vm/jvmti/StopThread/stop001/stop00103/stop00103a.html >> >> These two tests will be excluded from the test runs by the JCK team and then adjusted to new `StopThread` behavior. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > install_async_exception: set interrupt status for platform threads only src/hotspot/share/prims/jvmti.xml line 11984: > 11982: > 11983: Information about the frame is not available (e.g. for native frames), > 11984: or the frame is not suitable for the requested operation. After re-reading the spec changes, I'm wondering if we can improve on "or the frame is not suitable for the requested operation". StopThread doesn't have a frame parameter. ForceEarlyReturn doesn't have a frame parameter either as it's implicit (the current frame). I wonder if wording something like this might be better: "or a function on a thread cannot be performed at the thread's current frame". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13546#discussion_r1178984510 From coleenp at openjdk.org Thu Apr 27 12:13:56 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 27 Apr 2023 12:13:56 GMT Subject: RFR: 8306851: Move Method access flags In-Reply-To: <4MFJ-FafLsw4MTThURBlLZAvFZauwOd0VPklgivnehU=.4a24c95f-8c5f-416b-a63d-c21d58501dae@github.com> References: <4MFJ-FafLsw4MTThURBlLZAvFZauwOd0VPklgivnehU=.4a24c95f-8c5f-416b-a63d-c21d58501dae@github.com> Message-ID: On Thu, 27 Apr 2023 04:28:31 GMT, David Holmes wrote: >> This change moves the flags from AccessFlags to either ConstMethodFlags or MethodFlags, depending on whether they are set at class file parse time, which makes them essentially const, or at runtime, which makes them needing atomic access. >> >> This leaves AccessFlags int size because Klass still has JVM flags that are more work to move, but this change doesn't increase Method size. I didn't remove JVM_RECOGNIZED_METHOD_MODIFIERS with this change since there are several of these in other places, and with this change the code is benign. >> >> Tested with tier1-6, and some manual verification of printing. > > src/hotspot/share/classfile/classFileParser.cpp line 2741: > >> 2739: parsed_annotations.apply_to(methodHandle(THREAD, m)); >> 2740: >> 2741: if (is_hidden() && !m->is_hidden()) { // Mark methods in hidden classes as 'hidden'. > > This seems odd - how would m already be marked hidden? And why do we care? The check-and-branch is more expensive than just setting the field. This hidden flag is set by both the Method attribute during class file parsing and set to true if the whole class is hidden. My original version of the assert_is_safe() function only allowed a flag to be set once, but I've changed it to only set to true. So I can undo this. > src/hotspot/share/oops/method.cpp line 735: > >> 733: case Bytecodes::_jsr: >> 734: if (bcs.dest() < bcs.next_bci()) { >> 735: return set_has_loops(); > > I don't understand the new return logic here. The break gets us out of the switch but we are still in the while loop, but the return takes us all the way out. ??? Yes, I had a version of this change where we only let has_loops get set once, and this code set it over and over again, which is unnecessary. Once it's true, it stays true. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13654#discussion_r1179049959 PR Review Comment: https://git.openjdk.org/jdk/pull/13654#discussion_r1179044448 From tschatzl at openjdk.org Thu Apr 27 12:31:24 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 27 Apr 2023 12:31:24 GMT Subject: RFR: 8306836: Remove pinned tag for G1 heap regions [v4] In-Reply-To: References: Message-ID: > Hi all, > > please review this change that removes the pinned tag from `HeapRegion`. > > So that "pinned" tag for G1 heap regions indicates that the region should not move during (young) gc. This applies to now removed archive regions and humongous objects/regions. > > With "real" g1 region pinning to deal with gclocker in g1 once and for all upcoming we need a refcount, a single bit is not sufficient anymore. Further there will be a naming conflict as this kind of "pinning" is different to g1 region pinning "pinning". The former indicates "contents can not be moved, but can be reclaimed", while the latter means "contents can not be moved and not reclaimed". > > The (current) pinned flag is surprisingly little used, only for policy decisions. > > The suggestion this change implements is to remove the "pinned" tag as it is, and reserve it for future g1 region pinning (that needs to store the pinning attribute differently as a refcount anyway). > > Testing: tier1-3, gha > > Thanks, > Thomas Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision: remove is_young_gc_movable in full gc code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13643/files - new: https://git.openjdk.org/jdk/pull/13643/files/eacf54ba..e136c7e4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13643&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13643&range=02-03 Stats: 3 lines in 3 files changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13643.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13643/head:pull/13643 PR: https://git.openjdk.org/jdk/pull/13643 From coleenp at openjdk.org Thu Apr 27 12:57:23 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 27 Apr 2023 12:57:23 GMT Subject: RFR: 8306851: Move Method access flags [v2] In-Reply-To: References: Message-ID: > This change moves the flags from AccessFlags to either ConstMethodFlags or MethodFlags, depending on whether they are set at class file parse time, which makes them essentially const, or at runtime, which makes them needing atomic access. > > This leaves AccessFlags int size because Klass still has JVM flags that are more work to move, but this change doesn't increase Method size. I didn't remove JVM_RECOGNIZED_METHOD_MODIFIERS with this change since there are several of these in other places, and with this change the code is benign. > > Tested with tier1-6, and some manual verification of printing. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Add is prefixes and some cleanups. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13654/files - new: https://git.openjdk.org/jdk/pull/13654/files/4b92aacf..fc5bcaa6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13654&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13654&range=00-01 Stats: 37 lines in 8 files changed: 1 ins; 0 del; 36 mod Patch: https://git.openjdk.org/jdk/pull/13654.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13654/head:pull/13654 PR: https://git.openjdk.org/jdk/pull/13654 From coleenp at openjdk.org Thu Apr 27 13:00:23 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 27 Apr 2023 13:00:23 GMT Subject: RFR: 8306851: Move Method access flags [v2] In-Reply-To: <4MFJ-FafLsw4MTThURBlLZAvFZauwOd0VPklgivnehU=.4a24c95f-8c5f-416b-a63d-c21d58501dae@github.com> References: <4MFJ-FafLsw4MTThURBlLZAvFZauwOd0VPklgivnehU=.4a24c95f-8c5f-416b-a63d-c21d58501dae@github.com> Message-ID: On Thu, 27 Apr 2023 04:35:10 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Add is prefixes and some cleanups. > > src/hotspot/share/oops/constMethodFlags.hpp line 53: > >> 51: flag(has_type_annotations , 1 << 9) \ >> 52: flag(has_default_annotations , 1 << 10) \ >> 53: flag(caller_sensitive , 1 << 11) \ > > Nit: we should consistently use either `x` or `is_x` for `x` in `overpass, caller_sensitive, hidden, scoped, ...` That's my preference too, but I was trying to not change all the callers to is_caller_sensitive, for example, or providing a set of wrappers to change the "x" calls to "is_x" calls to the flags interface. > src/hotspot/share/oops/method.hpp line 808: > >> 806: >> 807: bool is_hidden() const { return constMethod()->is_hidden(); } >> 808: void set_hidden() { constMethod()->set_is_hidden(); } > > The naming is inconsistent here regarding `is` - either both should have it or neither IMO. This one is easy to fix because there aren't calls everywhere. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13654#discussion_r1179054655 PR Review Comment: https://git.openjdk.org/jdk/pull/13654#discussion_r1179057923 From coleenp at openjdk.org Thu Apr 27 13:00:55 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 27 Apr 2023 13:00:55 GMT Subject: RFR: 8306851: Move Method access flags [v2] In-Reply-To: References: <4MFJ-FafLsw4MTThURBlLZAvFZauwOd0VPklgivnehU=.4a24c95f-8c5f-416b-a63d-c21d58501dae@github.com> Message-ID: <8hc_LuISgfyGtsyx-_GTeuhTQ5xyu2JLM5heYgREKIA=.a5acf58c-16bd-4a3e-b4db-aca3021e5c73@github.com> On Thu, 27 Apr 2023 12:09:21 GMT, Coleen Phillimore wrote: >> src/hotspot/share/oops/constMethodFlags.hpp line 53: >> >>> 51: flag(has_type_annotations , 1 << 9) \ >>> 52: flag(has_default_annotations , 1 << 10) \ >>> 53: flag(caller_sensitive , 1 << 11) \ >> >> Nit: we should consistently use either `x` or `is_x` for `x` in `overpass, caller_sensitive, hidden, scoped, ...` > > That's my preference too, but I was trying to not change all the callers to is_caller_sensitive, for example, or providing a set of wrappers to change the "x" calls to "is_x" calls to the flags interface. The 'is' in not_x_compilable can be added without too much fanout of lines and files that I don't want to change, so I added the 'is' to these. >> src/hotspot/share/oops/method.cpp line 735: >> >>> 733: case Bytecodes::_jsr: >>> 734: if (bcs.dest() < bcs.next_bci()) { >>> 735: return set_has_loops(); >> >> I don't understand the new return logic here. The break gets us out of the switch but we are still in the while loop, but the return takes us all the way out. ??? > > Yes, I had a version of this change where we only let has_loops get set once, and this code set it over and over again, which is unnecessary. Once it's true, it stays true. The early break and not resetting has_loops once it's true, saves the atomic access also. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13654#discussion_r1179084771 PR Review Comment: https://git.openjdk.org/jdk/pull/13654#discussion_r1179080249 From tschatzl at openjdk.org Thu Apr 27 13:25:53 2023 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Thu, 27 Apr 2023 13:25:53 GMT Subject: RFR: 8306836: Remove pinned tag for G1 heap regions [v3] In-Reply-To: References: Message-ID: On Thu, 27 Apr 2023 10:38:17 GMT, Albert Mingkun Yang wrote: > > I think you are right about using is_humongous() directly here: the reason we skip compacting of humongous regions during the "main" compaction is intentional here > > However, I am unable to discern the difference -- why `is_young_gc_movable` is semantically-correct in one place, but not in the other in this concrete example. > > ``` > bool G1CollectionSetChooser::should_add(HeapRegion* hr) { > return !hr->is_young() && > G1CollectedHeap::heap()->policy()->is_young_gc_movable(hr) && > ``` > `G1CollectionSetChooser::should_add` asks: can/should I add this region to the collection set candidates to evacuate (reclaim via moving) this region during young gc? > vs > > ``` > void G1FullCollector::before_marking_update_attribute_table(HeapRegion* hr) { > if (hr->is_free()) { > _region_attr_table.set_free(hr->hrm_index()); > } else if (hr->is_humongous()) { > ``` `G1FullCollector::before_marking_update_attribute_table` asks: can I compact/move this region in the (small object) compaction phase later? So they are asking the question for different types of gc, where in the second case it is actually asking that question for a phase that is about compacting regular object regions. So it seems somewhat obvious to exclude non-regular object regions at the outset, or at least not use this predicate (which you criticized as non-obvious why full gc uses a predicate with "young-gc" inside). Then there is the matter of documentation: if one writes `!is_humongous()` there, there is need for a comment like "we do not move humongous objects during young gc" everywhere you need it, while the method name also acts as the documentation, saying "exclude everything that we are not moving during young gc". > > Looking at where `G1CollectionSetChooser::should_add` is called, can one use `hr->is_old()` instead of `!hr->is_young() && G1CollectedHeap::heap()->policy()->is_young_gc_movable(hr)`? (In fact, I believe that inlining `should_add` to the caller would result in a smoother code flow and prevent some duplicate region-type queries.) > Combining the two into the single predicate may be correct from an execution POV. However the two predicates filter for different reasons: The `!is_young` filters out regions that are not allowed to be put in the collection set candidates at all (it's a set of old regions that young gc may evacuate later by definition), the second filters those that can't be reclaimed by moving/evacuation. Otherwise one would need to add comments, this way it is self-commenting (and this isn't performance sensitive). > In my opinion, introducing a new `is_young_gc_movable` API in this particular PR may not be entirely justified. It may make more sense to introduce it in later PRs where region-pinning is supported and the API is actually utilized. `is_young_gc_movable` and pinning are separate concerns. `is_young_gc_movable` is a static view on the region. Pinning is assumed to be very transient, and assumed to not pin too much (generating lots of garbage in pinned regions basically - everything but the potentially pinned objects are still evacuated out). So it is more than likely advantageous to put pinned regions into the candidates for proactive evacuation. Thanks, Thomas ------------- PR Comment: https://git.openjdk.org/jdk/pull/13643#issuecomment-1525668118 From coleenp at openjdk.org Thu Apr 27 14:21:23 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 27 Apr 2023 14:21:23 GMT Subject: RFR: 8306851: Move Method access flags [v3] In-Reply-To: References: Message-ID: > This change moves the flags from AccessFlags to either ConstMethodFlags or MethodFlags, depending on whether they are set at class file parse time, which makes them essentially const, or at runtime, which makes them needing atomic access. > > This leaves AccessFlags int size because Klass still has JVM flags that are more work to move, but this change doesn't increase Method size. I didn't remove JVM_RECOGNIZED_METHOD_MODIFIERS with this change since there are several of these in other places, and with this change the code is benign. > > Tested with tier1-6, and some manual verification of printing. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Remove bool argument from ConstMethodFlags.set function. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13654/files - new: https://git.openjdk.org/jdk/pull/13654/files/fc5bcaa6..6687cc0e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13654&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13654&range=01-02 Stats: 9 lines in 2 files changed: 0 ins; 5 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13654.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13654/head:pull/13654 PR: https://git.openjdk.org/jdk/pull/13654 From coleenp at openjdk.org Thu Apr 27 16:33:22 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 27 Apr 2023 16:33:22 GMT Subject: RFR: 8306851: Move Method access flags [v3] In-Reply-To: References: Message-ID: On Thu, 27 Apr 2023 14:21:23 GMT, Coleen Phillimore wrote: >> This change moves the flags from AccessFlags to either ConstMethodFlags or MethodFlags, depending on whether they are set at class file parse time, which makes them essentially const, or at runtime, which makes them needing atomic access. >> >> This leaves AccessFlags int size because Klass still has JVM flags that are more work to move, but this change doesn't increase Method size. I didn't remove JVM_RECOGNIZED_METHOD_MODIFIERS with this change since there are several of these in other places, and with this change the code is benign. >> >> Tested with tier1-6, and some manual verification of printing. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Remove bool argument from ConstMethodFlags.set function. @dougxc can you look at the JVMCI changes? ------------- PR Comment: https://git.openjdk.org/jdk/pull/13654#issuecomment-1525977245 From cjplummer at openjdk.org Thu Apr 27 17:58:23 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 27 Apr 2023 17:58:23 GMT Subject: RFR: 8282384: [LOOM] Need test for ThreadReference.interrupt() on a vthread Message-ID: Convert this ThreadReference.interrupt() test to support virtual threads. I believe this is the only test for ThreadReference.interrupt() that we have. Tested by running with and without -Dmain.wrapper=Virtual on all supported platforms. ------------- Commit messages: - Add vthread support to interrupt test Changes: https://git.openjdk.org/jdk/pull/13696/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13696&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8282384 Stats: 18 lines in 2 files changed: 5 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/13696.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13696/head:pull/13696 PR: https://git.openjdk.org/jdk/pull/13696 From cjplummer at openjdk.org Thu Apr 27 19:06:54 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 27 Apr 2023 19:06:54 GMT Subject: RFR: 8306034: add support of virtual threads to JVMTI StopThread [v6] In-Reply-To: <7fdlC2euVU0tBa91ZqEuLj9QLVNXe5hTT0KnImBaGgw=.e0a45607-2a7b-462c-98b6-16d5982ec495@github.com> References: <7fdlC2euVU0tBa91ZqEuLj9QLVNXe5hTT0KnImBaGgw=.e0a45607-2a7b-462c-98b6-16d5982ec495@github.com> Message-ID: <9XF3Y1s-QPZYzNu335PSoVIny_NvhIBEquY4qegGmXk=.e648f206-d58b-49b7-bf58-6360d275394d@github.com> On Thu, 27 Apr 2023 10:58:14 GMT, Alan Bateman wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> install_async_exception: set interrupt status for platform threads only > > src/hotspot/share/prims/jvmti.xml line 11984: > >> 11982: >> 11983: Information about the frame is not available (e.g. for native frames), >> 11984: or the frame is not suitable for the requested operation. > > After re-reading the spec changes, I'm wondering if we can improve on "or the frame is not suitable for the requested operation". StopThread doesn't have a frame parameter. ForceEarlyReturn doesn't have a frame parameter either as it's implicit (the current frame). I wonder if wording something like this might be better: > "or a function on a thread cannot be performed at the thread's current frame". The wording starts off with "Information about the frame...", and you haven't suggested to change that to "the current frame". We should be consistent. Can't we just change both "the frame" references to "the current frame", and leave the rest the same as what Serguei has in place here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13546#discussion_r1179561498 From alanb at openjdk.org Thu Apr 27 19:07:52 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 27 Apr 2023 19:07:52 GMT Subject: RFR: 8306034: add support of virtual threads to JVMTI StopThread [v6] In-Reply-To: <9XF3Y1s-QPZYzNu335PSoVIny_NvhIBEquY4qegGmXk=.e648f206-d58b-49b7-bf58-6360d275394d@github.com> References: <7fdlC2euVU0tBa91ZqEuLj9QLVNXe5hTT0KnImBaGgw=.e0a45607-2a7b-462c-98b6-16d5982ec495@github.com> <9XF3Y1s-QPZYzNu335PSoVIny_NvhIBEquY4qegGmXk=.e648f206-d58b-49b7-bf58-6360d275394d@github.com> Message-ID: On Thu, 27 Apr 2023 18:49:40 GMT, Chris Plummer wrote: >> src/hotspot/share/prims/jvmti.xml line 11984: >> >>> 11982: >>> 11983: Information about the frame is not available (e.g. for native frames), >>> 11984: or the frame is not suitable for the requested operation. >> >> After re-reading the spec changes, I'm wondering if we can improve on "or the frame is not suitable for the requested operation". StopThread doesn't have a frame parameter. ForceEarlyReturn doesn't have a frame parameter either as it's implicit (the current frame). I wonder if wording something like this might be better: >> "or a function on a thread cannot be performed at the thread's current frame". > > The wording starts off with "Information about the frame...", and you haven't suggested to change that to "the current frame". We should be consistent. Can't we just change both "the frame" references to "the current frame", and leave the rest the same as what Serguei has in place here? I think the first part is okay because it's for functions that are about frames. The NotifyFramePop specifies the depth so it may not be the current frame. The second usage is the functions on a thread where we might do better than "not suitable". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13546#discussion_r1179571945 From cjplummer at openjdk.org Thu Apr 27 19:17:03 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 27 Apr 2023 19:17:03 GMT Subject: RFR: 8306034: add support of virtual threads to JVMTI StopThread [v6] In-Reply-To: References: <7fdlC2euVU0tBa91ZqEuLj9QLVNXe5hTT0KnImBaGgw=.e0a45607-2a7b-462c-98b6-16d5982ec495@github.com> <9XF3Y1s-QPZYzNu335PSoVIny_NvhIBEquY4qegGmXk=.e648f206-d58b-49b7-bf58-6360d275394d@github.com> Message-ID: On Thu, 27 Apr 2023 18:59:34 GMT, Alan Bateman wrote: >> The wording starts off with "Information about the frame...", and you haven't suggested to change that to "the current frame". We should be consistent. Can't we just change both "the frame" references to "the current frame", and leave the rest the same as what Serguei has in place here? > > I think the first part is okay because it's for functions that are about frames. The NotifyFramePop specifies the depth so it may not be the current frame. The second usage is the functions on a thread where we might do better than "not suitable". Ok. How about "the function cannot be performed on the thread's current frame". We already have a couple references to "the function" in the error codes section. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13546#discussion_r1179584919 From lmesnik at openjdk.org Thu Apr 27 19:52:56 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 27 Apr 2023 19:52:56 GMT Subject: RFR: 8282384: [LOOM] Need test for ThreadReference.interrupt() on a vthread In-Reply-To: References: Message-ID: On Thu, 27 Apr 2023 17:42:41 GMT, Chris Plummer wrote: > Convert this ThreadReference.interrupt() test to support virtual threads. I believe this is the only test for ThreadReference.interrupt() that we have. > > Tested by running with and without -Dmain.wrapper=Virtual on all supported platforms. Changes requested by lmesnik (Reviewer). test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/interrupt/interrupt001a.java line 209: > 207: } > 208: > 209: class interrupt001aThread implements Runnable { Does it make sense to rename class to something like Interrupt001aTask? Just to let know that it is not a thread. Also, there is ./nsk/share/jdi/NamedTask.java for task with names in JDI tests. ------------- PR Review: https://git.openjdk.org/jdk/pull/13696#pullrequestreview-1404771083 PR Review Comment: https://git.openjdk.org/jdk/pull/13696#discussion_r1179608600 From cjplummer at openjdk.org Thu Apr 27 20:54:02 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 27 Apr 2023 20:54:02 GMT Subject: RFR: 8282384: [LOOM] Need test for ThreadReference.interrupt() on a vthread [v2] In-Reply-To: References: Message-ID: > Convert this ThreadReference.interrupt() test to support virtual threads. I believe this is the only test for ThreadReference.interrupt() that we have. > > Tested by running with and without -Dmain.wrapper=Virtual on all supported platforms. Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: some thread -> task renaming ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13696/files - new: https://git.openjdk.org/jdk/pull/13696/files/9e7d4f3b..e417fee0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13696&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13696&range=00-01 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/13696.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13696/head:pull/13696 PR: https://git.openjdk.org/jdk/pull/13696 From cjplummer at openjdk.org Thu Apr 27 20:54:22 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 27 Apr 2023 20:54:22 GMT Subject: RFR: 8282384: [LOOM] Need test for ThreadReference.interrupt() on a vthread [v2] In-Reply-To: References: Message-ID: On Thu, 27 Apr 2023 19:43:51 GMT, Leonid Mesnik wrote: >> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: >> >> some thread -> task renaming > > test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/interrupt/interrupt001a.java line 209: > >> 207: } >> 208: >> 209: class interrupt001aThread implements Runnable { > > Does it make sense to rename class to something like Interrupt001aTask? Just to let know that it is not a thread. Also, there is ./nsk/share/jdi/NamedTask.java for task with names in JDI tests. Ok. I've made both these changes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13696#discussion_r1179660333 From cjplummer at openjdk.org Thu Apr 27 21:08:23 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 27 Apr 2023 21:08:23 GMT Subject: RFR: 8282384: [LOOM] Need test for ThreadReference.interrupt() on a vthread [v3] In-Reply-To: References: Message-ID: <561aQXgCeVrvI7igBBoJAKWMQhqQ1ISiLW375KJR5v8=.0e6c9333-994c-4928-b850-8ea21df26d26@github.com> > Convert this ThreadReference.interrupt() test to support virtual threads. I believe this is the only test for ThreadReference.interrupt() that we have. > > Tested by running with and without -Dmain.wrapper=Virtual on all supported platforms. Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: use NamedTask library class ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13696/files - new: https://git.openjdk.org/jdk/pull/13696/files/e417fee0..a7f277a9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13696&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13696&range=01-02 Stats: 5 lines in 1 file changed: 0 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/13696.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13696/head:pull/13696 PR: https://git.openjdk.org/jdk/pull/13696 From lmesnik at openjdk.org Thu Apr 27 21:46:24 2023 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 27 Apr 2023 21:46:24 GMT Subject: RFR: 8282384: [LOOM] Need test for ThreadReference.interrupt() on a vthread [v3] In-Reply-To: <561aQXgCeVrvI7igBBoJAKWMQhqQ1ISiLW375KJR5v8=.0e6c9333-994c-4928-b850-8ea21df26d26@github.com> References: <561aQXgCeVrvI7igBBoJAKWMQhqQ1ISiLW375KJR5v8=.0e6c9333-994c-4928-b850-8ea21df26d26@github.com> Message-ID: On Thu, 27 Apr 2023 21:08:23 GMT, Chris Plummer wrote: >> Convert this ThreadReference.interrupt() test to support virtual threads. I believe this is the only test for ThreadReference.interrupt() that we have. >> >> Tested by running with and without -Dmain.wrapper=Virtual on all supported platforms. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > use NamedTask library class Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/13696#pullrequestreview-1404929979 From dcubed at openjdk.org Thu Apr 27 21:50:17 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 27 Apr 2023 21:50:17 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v64] In-Reply-To: References: Message-ID: On Thu, 27 Apr 2023 07:52:23 GMT, Roman Kennke wrote: >> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). >> >> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. >> >> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal protocols. >> >> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare. >> >> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. >> >> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. >> >> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. >> >> This change enables to simplify (and speed-up!) a lot of code: >> >> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. >> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR >> >> Also, and I might be mistaken here, this new lightweight locking would make synchronized work better with Loom: Because the lock-records are no longer scattered across the stack, but instead are densely packed into the lock-stack, it should be easy for a vthread to save its lock-stack upon unmounting and restore it when re-mounting. However, I am not sure about this, and this PR does not attempt to implement that support. >> >> Testing: >> - [x] tier1 x86_64 x aarch64 x +UseFastLocking >> - [x] tier2 x86_64 x aarch64 x +UseFastLocking >> - [x] tier3 x86_64 x aarch64 x +UseFastLocking >> - [x] tier4 x86_64 x aarch64 x +UseFastLocking >> - [x] tier1 x86_64 x aarch64 x -UseFastLocking >> - [x] tier2 x86_64 x aarch64 x -UseFastLocking >> - [x] tier3 x86_64 x aarch64 x -UseFastLocking >> - [x] tier4 x86_64 x aarch64 x -UseFastLocking >> - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet >> >> ### Performance >> >> #### Simple Microbenchmark >> >> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops. >> >> | | x86_64 | aarch64 | >> | -- | -- | -- | >> | -UseFastLocking | 20.651 | 20.764 | >> | +UseFastLocking | 18.896 | 18.908 | >> >> >> #### Renaissance >> >> ? | x86_64 | ? | ? | ? | aarch64 | ? | ? >> -- | -- | -- | -- | -- | -- | -- | -- >> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? >> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% >> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21% >> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% >> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% >> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% >> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% >> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%% >> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% >> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% >> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% >> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% >> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34% >> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% >> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% >> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% >> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% >> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% >> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% >> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% >> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% >> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Suggestios by @dcubed-ojdk src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java line 213: > 211: // refer to Threads::owning_thread_from_monitor_owner > 212: public JavaThread owningThreadFromMonitor(Address o) { > 213: assert(VM.getVM().getCommandLineFlag("LockingMode").getInt() != 2 /* LM_LIGHTWEIGHT */); nit: indent is too short by 2 spaces. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1179702987 From sspitsyn at openjdk.org Fri Apr 28 00:56:23 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 28 Apr 2023 00:56:23 GMT Subject: RFR: 8306034: add support of virtual threads to JVMTI StopThread [v6] In-Reply-To: References: <7fdlC2euVU0tBa91ZqEuLj9QLVNXe5hTT0KnImBaGgw=.e0a45607-2a7b-462c-98b6-16d5982ec495@github.com> <9XF3Y1s-QPZYzNu335PSoVIny_NvhIBEquY4qegGmXk=.e648f206-d58b-49b7-bf58-6360d275394d@github.com> Message-ID: On Thu, 27 Apr 2023 19:14:56 GMT, Chris Plummer wrote: >> I think the first part is okay because it's for functions that are about frames. The NotifyFramePop specifies the depth so it may not be the current frame. The second usage is the functions on a thread where we might do better than "not suitable". > > Ok. How about "the function cannot be performed on the thread's current frame". We already have a couple references to "the function" in the error codes section. We have two suggestions: > - "or a function on a thread cannot be performed at the thread's current frame". > - "the function cannot be performed on the thread's current frame." So, we need to pick one. The second one looks simpler to me but I'm not completely sure that it reflects the full meaning correctly. I wonder about a mix of the two suggestions above: > "the function cannot be performed at the thread's current frame." ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13546#discussion_r1179833278 From sspitsyn at openjdk.org Fri Apr 28 00:56:24 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 28 Apr 2023 00:56:24 GMT Subject: RFR: 8306034: add support of virtual threads to JVMTI StopThread [v6] In-Reply-To: References: <7fdlC2euVU0tBa91ZqEuLj9QLVNXe5hTT0KnImBaGgw=.e0a45607-2a7b-462c-98b6-16d5982ec495@github.com> <9XF3Y1s-QPZYzNu335PSoVIny_NvhIBEquY4qegGmXk=.e648f206-d58b-49b7-bf58-6360d275394d@github.com> Message-ID: On Fri, 28 Apr 2023 00:46:23 GMT, Serguei Spitsyn wrote: >> Ok. How about "the function cannot be performed on the thread's current frame". We already have a couple references to "the function" in the error codes section. > > We have two suggestions: >> - "or a function on a thread cannot be performed at the thread's current frame". >> - "the function cannot be performed on the thread's current frame." > > So, we need to pick one. The second one looks simpler to me but > I'm not completely sure that it reflects the full meaning correctly. > I wonder about a mix of the two suggestions above: > >> "the function cannot be performed at the thread's current frame." We need to account for the `SetLocalXXX` functions with the `depth` parameter which also return `OPAQUE_FRAME` error code for virtual frames. My concern is if the "current frame" part is fully correct. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13546#discussion_r1179834952 From kbarrett at openjdk.org Fri Apr 28 03:05:52 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 28 Apr 2023 03:05:52 GMT Subject: RFR: 8305566: Change StringDedup thread to derive from JavaThread [v2] In-Reply-To: <-k-_JovF26G4lOTq2AvCVxvDgwnqpD4-GSbSYCbDcn4=.e82221d2-9fd8-4aed-9a11-6f5ccc09c669@github.com> References: <-k-_JovF26G4lOTq2AvCVxvDgwnqpD4-GSbSYCbDcn4=.e82221d2-9fd8-4aed-9a11-6f5ccc09c669@github.com> Message-ID: On Mon, 24 Apr 2023 09:25:01 GMT, Kim Barrett wrote: >> Please review this change to the string deduplication thread to make it a kind >> of JavaThread rather than a ConcurrentGCThread. There are several pieces to >> this change: >> >> (1) New class StringDedupThread (derived from JavaThread), separate from >> StringDedup::Processor (which is now just a CHeapObj instead of deriving from >> ConcurrentGCThread). The thread no longer needs to or supports being stopped, >> like other similar threads. It also needs to be started later, once Java >> threads are supported. Also don't need an explicit visitor, since it will be >> in the normal Java threads list. This separation made the changeover a little >> cleaner to develop, and made the servicability support a little cleaner too. >> >> (2) The Processor now uses the ThreadBlockInVM idiom to be safepoint polite, >> instead of using the SuspendibleThreadSet facility. >> >> (3) Because we're using ThreadBlockInVM, which has a different usage style >> from STS, the tracking of time spent by the processor blocked for safepoints >> doesn't really work. It's not very important anyway, since normal thread >> descheduling can also affect the normal processing times being gathered and >> reported. So we just drop the so-called "blocked" time and associated >> infrastructure, simplifying Stat tracking a bit. Also renamed the >> "concurrent" stat to be "active", since it's all in a JavaThread now. >> >> (4) To avoid #include problems, moved the definition of >> JavaThread::is_active_Java_thread from the .hpp file to the .inline.hpp file, >> where one of the functions it calls also is defined. >> >> (5) Added servicability support for the new thread. >> >> Testing: >> mach5 tier1-3 with -XX:+UseStringDeduplication. >> The test runtime/cds/DeterministicDump.java fails intermittently with that >> option, which is not surprising - see JDK-8306712. >> >> I was never able to reproduce the failure; it's likely quite timing sensitive. >> The fix of changing the type is based on StefanK's comment that ZResurrection >> doesn't expect a non-Java thread to perform load-barriers. > > Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: > > fix include order Thanks all for reviews. I've changed the bug and PR summaries as requested. ------------- PR Comment: https://git.openjdk.org/jdk/pull/13607#issuecomment-1526905175 From kbarrett at openjdk.org Fri Apr 28 03:26:53 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 28 Apr 2023 03:26:53 GMT Subject: RFR: 8305566: Change StringDedup thread to derive from JavaThread [v3] In-Reply-To: References: Message-ID: > Please review this change to the string deduplication thread to make it a kind > of JavaThread rather than a ConcurrentGCThread. There are several pieces to > this change: > > (1) New class StringDedupThread (derived from JavaThread), separate from > StringDedup::Processor (which is now just a CHeapObj instead of deriving from > ConcurrentGCThread). The thread no longer needs to or supports being stopped, > like other similar threads. It also needs to be started later, once Java > threads are supported. Also don't need an explicit visitor, since it will be > in the normal Java threads list. This separation made the changeover a little > cleaner to develop, and made the servicability support a little cleaner too. > > (2) The Processor now uses the ThreadBlockInVM idiom to be safepoint polite, > instead of using the SuspendibleThreadSet facility. > > (3) Because we're using ThreadBlockInVM, which has a different usage style > from STS, the tracking of time spent by the processor blocked for safepoints > doesn't really work. It's not very important anyway, since normal thread > descheduling can also affect the normal processing times being gathered and > reported. So we just drop the so-called "blocked" time and associated > infrastructure, simplifying Stat tracking a bit. Also renamed the > "concurrent" stat to be "active", since it's all in a JavaThread now. > > (4) To avoid #include problems, moved the definition of > JavaThread::is_active_Java_thread from the .hpp file to the .inline.hpp file, > where one of the functions it calls also is defined. > > (5) Added servicability support for the new thread. > > Testing: > mach5 tier1-3 with -XX:+UseStringDeduplication. > The test runtime/cds/DeterministicDump.java fails intermittently with that > option, which is not surprising - see JDK-8306712. > > I was never able to reproduce the failure; it's likely quite timing sensitive. > The fix of changing the type is based on StefanK's comment that ZResurrection > doesn't expect a non-Java thread to perform load-barriers. Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: - Merge branch 'master' into jt-strdedup - fix include order - fix stray tab - move is_active_Java_thread - copyrights - servicabilty support - use JavaThread - separate thread class - simplify init - do not pass around STS joiner - ... and 2 more: https://git.openjdk.org/jdk/compare/8957f67e...da07a420 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13607/files - new: https://git.openjdk.org/jdk/pull/13607/files/f17cc6be..da07a420 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13607&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13607&range=01-02 Stats: 46789 lines in 794 files changed: 30868 ins; 11396 del; 4525 mod Patch: https://git.openjdk.org/jdk/pull/13607.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13607/head:pull/13607 PR: https://git.openjdk.org/jdk/pull/13607 From kbarrett at openjdk.org Fri Apr 28 03:35:53 2023 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 28 Apr 2023 03:35:53 GMT Subject: Integrated: 8305566: Change StringDedup thread to derive from JavaThread In-Reply-To: References: Message-ID: On Mon, 24 Apr 2023 08:24:53 GMT, Kim Barrett wrote: > Please review this change to the string deduplication thread to make it a kind > of JavaThread rather than a ConcurrentGCThread. There are several pieces to > this change: > > (1) New class StringDedupThread (derived from JavaThread), separate from > StringDedup::Processor (which is now just a CHeapObj instead of deriving from > ConcurrentGCThread). The thread no longer needs to or supports being stopped, > like other similar threads. It also needs to be started later, once Java > threads are supported. Also don't need an explicit visitor, since it will be > in the normal Java threads list. This separation made the changeover a little > cleaner to develop, and made the servicability support a little cleaner too. > > (2) The Processor now uses the ThreadBlockInVM idiom to be safepoint polite, > instead of using the SuspendibleThreadSet facility. > > (3) Because we're using ThreadBlockInVM, which has a different usage style > from STS, the tracking of time spent by the processor blocked for safepoints > doesn't really work. It's not very important anyway, since normal thread > descheduling can also affect the normal processing times being gathered and > reported. So we just drop the so-called "blocked" time and associated > infrastructure, simplifying Stat tracking a bit. Also renamed the > "concurrent" stat to be "active", since it's all in a JavaThread now. > > (4) To avoid #include problems, moved the definition of > JavaThread::is_active_Java_thread from the .hpp file to the .inline.hpp file, > where one of the functions it calls also is defined. > > (5) Added servicability support for the new thread. > > Testing: > mach5 tier1-3 with -XX:+UseStringDeduplication. > The test runtime/cds/DeterministicDump.java fails intermittently with that > option, which is not surprising - see JDK-8306712. > > I was never able to reproduce the failure; it's likely quite timing sensitive. > The fix of changing the type is based on StefanK's comment that ZResurrection > doesn't expect a non-Java thread to perform load-barriers. This pull request has now been integrated. Changeset: d3abfec8 Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/d3abfec8b7ce901150952356f9f1109d09a8cb2a Stats: 440 lines in 18 files changed: 193 ins; 146 del; 101 mod 8305566: Change StringDedup thread to derive from JavaThread Reviewed-by: stefank, cjplummer, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/13607 From sspitsyn at openjdk.org Fri Apr 28 05:05:26 2023 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 28 Apr 2023 05:05:26 GMT Subject: RFR: 8282384: [LOOM] Need test for ThreadReference.interrupt() on a vthread [v3] In-Reply-To: <561aQXgCeVrvI7igBBoJAKWMQhqQ1ISiLW375KJR5v8=.0e6c9333-994c-4928-b850-8ea21df26d26@github.com> References: <561aQXgCeVrvI7igBBoJAKWMQhqQ1ISiLW375KJR5v8=.0e6c9333-994c-4928-b850-8ea21df26d26@github.com> Message-ID: On Thu, 27 Apr 2023 21:08:23 GMT, Chris Plummer wrote: >> Convert this ThreadReference.interrupt() test to support virtual threads. I believe this is the only test for ThreadReference.interrupt() that we have. >> >> Tested by running with and without -Dmain.wrapper=Virtual on all supported platforms. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > use NamedTask library class Looks good. Thanks, Serguei test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/interrupt/interrupt001.java line 214: > 212: } > 213: > 214: log2("......thread2 is " + (thread2.isVirtual() ? "" : "not ") + "a virtual thread"); Nit: Would it better to print "is a virtual thread" instead of "is not a virtual thread"? ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13696#pullrequestreview-1405223335 PR Review Comment: https://git.openjdk.org/jdk/pull/13696#discussion_r1179927700 From dholmes at openjdk.org Fri Apr 28 06:00:24 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 28 Apr 2023 06:00:24 GMT Subject: RFR: 8306851: Move Method access flags [v3] In-Reply-To: References: Message-ID: On Thu, 27 Apr 2023 14:21:23 GMT, Coleen Phillimore wrote: >> This change moves the flags from AccessFlags to either ConstMethodFlags or MethodFlags, depending on whether they are set at class file parse time, which makes them essentially const, or at runtime, which makes them needing atomic access. >> >> This leaves AccessFlags int size because Klass still has JVM flags that are more work to move, but this change doesn't increase Method size. I didn't remove JVM_RECOGNIZED_METHOD_MODIFIERS with this change since there are several of these in other places, and with this change the code is benign. >> >> Tested with tier1-6, and some manual verification of printing. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Remove bool argument from ConstMethodFlags.set function. Thanks for the updates. I understand about the fanout from making `is` naming fully consistent. src/hotspot/share/oops/method.hpp line 875: > 873: bool is_not_c1_osr_compilable() const { return is_not_c1_compilable(); } > 874: void set_is_not_c1_osr_compilable() { set_is_not_c1_compilable(); } > 875: void clear_is_not_c1_osr_compilable() { clear_is_not_c1_compilable(); } Nit: don't need extra spaces after `{` ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13654#pullrequestreview-1405267857 PR Review Comment: https://git.openjdk.org/jdk/pull/13654#discussion_r1179956725 From cjplummer at openjdk.org Fri Apr 28 06:00:53 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 28 Apr 2023 06:00:53 GMT Subject: RFR: 8282384: [LOOM] Need test for ThreadReference.interrupt() on a vthread [v3] In-Reply-To: References: <561aQXgCeVrvI7igBBoJAKWMQhqQ1ISiLW375KJR5v8=.0e6c9333-994c-4928-b850-8ea21df26d26@github.com> Message-ID: On Fri, 28 Apr 2023 04:56:17 GMT, Serguei Spitsyn wrote: >> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: >> >> use NamedTask library class > > test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/interrupt/interrupt001.java line 214: > >> 212: } >> 213: >> 214: log2("......thread2 is " + (thread2.isVirtual() ? "" : "not ") + "a virtual thread"); > > Nit: Would it better to print "is a virtual thread" instead of "is not a virtual thread"? I don't see your point. It prints one or the other depending on whether or not the thread is virtual. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13696#discussion_r1179956252 From dnsimon at openjdk.org Fri Apr 28 07:30:22 2023 From: dnsimon at openjdk.org (Doug Simon) Date: Fri, 28 Apr 2023 07:30:22 GMT Subject: RFR: 8306851: Move Method access flags [v3] In-Reply-To: References: Message-ID: On Thu, 27 Apr 2023 14:21:23 GMT, Coleen Phillimore wrote: >> This change moves the flags from AccessFlags to either ConstMethodFlags or MethodFlags, depending on whether they are set at class file parse time, which makes them essentially const, or at runtime, which makes them needing atomic access. >> >> This leaves AccessFlags int size because Klass still has JVM flags that are more work to move, but this change doesn't increase Method size. I didn't remove JVM_RECOGNIZED_METHOD_MODIFIERS with this change since there are several of these in other places, and with this change the code is benign. >> >> Tested with tier1-6, and some manual verification of printing. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Remove bool argument from ConstMethodFlags.set function. Marked as reviewed by dnsimon (Committer). Thankfully all these changes only impact values read by JVMCI Java code and none in [Graal Java code](https://github.com/oracle/graal/blob/114067fc41d97e6c07f6de9bd745196d6f967ae4/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java#L47). Looks good to me. ------------- PR Review: https://git.openjdk.org/jdk/pull/13654#pullrequestreview-1405368377 PR Comment: https://git.openjdk.org/jdk/pull/13654#issuecomment-1527109990 From rkennke at openjdk.org Fri Apr 28 07:43:24 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 28 Apr 2023 07:43:24 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v65] In-Reply-To: References: Message-ID: > This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). > > What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. > > This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p rotocols. > > The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare. > > In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. > > One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. > > As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. > > This change enables to simplify (and speed-up!) a lot of code: > > - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. > - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR > > Also, and I might be mistaken here, this new lightweight locking would make synchronized work better with Loom: Because the lock-records are no longer scattered across the stack, but instead are densely packed into the lock-stack, it should be easy for a vthread to save its lock-stack upon unmounting and restore it when re-mounting. However, I am not sure about this, and this PR does not attempt to implement that support. > > Testing: > - [x] tier1 x86_64 x aarch64 x +UseFastLocking > - [x] tier2 x86_64 x aarch64 x +UseFastLocking > - [x] tier3 x86_64 x aarch64 x +UseFastLocking > - [x] tier4 x86_64 x aarch64 x +UseFastLocking > - [x] tier1 x86_64 x aarch64 x -UseFastLocking > - [x] tier2 x86_64 x aarch64 x -UseFastLocking > - [x] tier3 x86_64 x aarch64 x -UseFastLocking > - [x] tier4 x86_64 x aarch64 x -UseFastLocking > - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet > > ### Performance > > #### Simple Microbenchmark > > The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops. > > | | x86_64 | aarch64 | > | -- | -- | -- | > | -UseFastLocking | 20.651 | 20.764 | > | +UseFastLocking | 18.896 | 18.908 | > > > #### Renaissance > > ? | x86_64 | ? | ? | ? | aarch64 | ? | ? > -- | -- | -- | -- | -- | -- | -- | -- > ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? > AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% > Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21% > Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% > ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% > GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% > LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% > MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%% > NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% > PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% > FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% > FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% > ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34% > Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% > RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% > Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% > ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% > FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% > FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 162 commits: - Merge branch 'master' into JDK-8291555-v2 - Fix formatting - Suggestios by @dcubed-ojdk - Suggested changes by @merykitty - Remove unnecessary comments - Simple build fix for extra arches - Merge remote-tracking branch 'upstream/master' into JDK-8291555-v2 - A few more LM_ prefixes in 32bit code - Replace UseHeavyMonitor with LockingMode == LM_MONITOR - Prefix LockingMode constants with LM_* - ... and 152 more: https://git.openjdk.org/jdk/compare/3d9d84b7...d90810f1 ------------- Changes: https://git.openjdk.org/jdk/pull/10907/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=64 Stats: 2493 lines in 68 files changed: 1675 ins; 104 del; 714 mod Patch: https://git.openjdk.org/jdk/pull/10907.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/10907/head:pull/10907 PR: https://git.openjdk.org/jdk/pull/10907 From stuefe at openjdk.org Fri Apr 28 08:09:54 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 28 Apr 2023 08:09:54 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v65] In-Reply-To: References: Message-ID: On Fri, 28 Apr 2023 07:43:24 GMT, Roman Kennke wrote: >> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). >> >> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. >> >> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal protocols. >> >> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare. >> >> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. >> >> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. >> >> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. >> >> This change enables to simplify (and speed-up!) a lot of code: >> >> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. >> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR >> >> Also, and I might be mistaken here, this new lightweight locking would make synchronized work better with Loom: Because the lock-records are no longer scattered across the stack, but instead are densely packed into the lock-stack, it should be easy for a vthread to save its lock-stack upon unmounting and restore it when re-mounting. However, I am not sure about this, and this PR does not attempt to implement that support. >> >> Testing: >> - [x] tier1 x86_64 x aarch64 x +UseFastLocking >> - [x] tier2 x86_64 x aarch64 x +UseFastLocking >> - [x] tier3 x86_64 x aarch64 x +UseFastLocking >> - [x] tier4 x86_64 x aarch64 x +UseFastLocking >> - [x] tier1 x86_64 x aarch64 x -UseFastLocking >> - [x] tier2 x86_64 x aarch64 x -UseFastLocking >> - [x] tier3 x86_64 x aarch64 x -UseFastLocking >> - [x] tier4 x86_64 x aarch64 x -UseFastLocking >> - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet >> >> ### Performance >> >> #### Simple Microbenchmark >> >> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops. >> >> | | x86_64 | aarch64 | >> | -- | -- | -- | >> | -UseFastLocking | 20.651 | 20.764 | >> | +UseFastLocking | 18.896 | 18.908 | >> >> >> #### Renaissance >> >> ? | x86_64 | ? | ? | ? | aarch64 | ? | ? >> -- | -- | -- | -- | -- | -- | -- | -- >> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? >> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% >> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21% >> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% >> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% >> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% >> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% >> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%% >> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% >> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% >> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% >> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% >> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34% >> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% >> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% >> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% >> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% >> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% >> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% >> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% >> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% >> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% > > Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 162 commits: > > - Merge branch 'master' into JDK-8291555-v2 > - Fix formatting > - Suggestios by @dcubed-ojdk > - Suggested changes by @merykitty > - Remove unnecessary comments > - Simple build fix for extra arches > - Merge remote-tracking branch 'upstream/master' into JDK-8291555-v2 > - A few more LM_ prefixes in 32bit code > - Replace UseHeavyMonitor with LockingMode == LM_MONITOR > - Prefix LockingMode constants with LM_* > - ... and 152 more: https://git.openjdk.org/jdk/compare/3d9d84b7...d90810f1 Thanks for the merge. The only thing hindering ppcle from building is this: diff --git a/src/hotspot/share/runtime/arguments.cpp b/src/hotspot/share/runtime/arguments.cpp index c758f301cc9..c46bb6c3b5d 100644 --- a/src/hotspot/share/runtime/arguments.cpp +++ b/src/hotspot/share/runtime/arguments.cpp @@ -1984,7 +1984,7 @@ bool Arguments::check_vm_args_consistency() { #if !defined(X86) && !defined(AARCH64) && !defined(RISCV64) && !defined(ARM) if (LockingMode == LM_LIGHTWEIGHT) { - FLAG_SET_CMDLINE(LockingMode, LEGACY); + FLAG_SET_CMDLINE(LockingMode, LM_LEGACY); warning("New lightweight locking not supported on this platform"); } #endif Cannot build s390 because build is broken upstream (https://bugs.openjdk.org/browse/JDK-8307093) ------------- PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1527147139 From stuefe at openjdk.org Fri Apr 28 09:01:26 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 28 Apr 2023 09:01:26 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v62] In-Reply-To: <1M7ql10BxRIBDp38CNNb_D0i6CE4O-97lGFO7iDRaFI=.570de882-cda2-4582-a4eb-c49cbc38aff6@github.com> References: <1M7ql10BxRIBDp38CNNb_D0i6CE4O-97lGFO7iDRaFI=.570de882-cda2-4582-a4eb-c49cbc38aff6@github.com> Message-ID: On Wed, 26 Apr 2023 18:35:45 GMT, Thomas Stuefe wrote: >> src/hotspot/cpu/arm/sharedRuntime_arm.cpp line 649: >> >>> 647: >>> 648: __ flush(); >>> 649: return AdapterHandlerLibrary::new_entry(fingerprint, i2c_entry, c2i_entry, c2i_unverified_entry); >> >> This change seems out of place... what's the story here? > > This is a local revert of *8303154: Investigate and improve instruction cache flushing during compilation* - the missing flush caused random crashes, but I did not have time to investigate. I reverted the flush, crashes were gone. > > If needed I may revisit this when there is time. I'll remove it. Tests have to wait on arm for https://bugs.openjdk.org/browse/JDK-8305387 though. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/10907#discussion_r1180108118 From stuefe at openjdk.org Fri Apr 28 09:24:05 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 28 Apr 2023 09:24:05 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v60] In-Reply-To: References: Message-ID: On Wed, 26 Apr 2023 18:58:13 GMT, Roman Kennke wrote: >>> @rkennke - I'm planning to do another crawl thru review next week. >> >> Thanks! That is greatly appeciated! > >> @rkennke - finished my second crawl thru review of 60/68 files changed. I only skipped the RISC-V files since I know nada about that platform... >> >> My Mach5 testing of v61 is running Tier7 and I hope to start Tier8 later tonight. So far all testing looks good, but I'll include the usual summary comment in the bug report... > > Thanks so much for reviewing this large PR (so many times)! I believe I have incorporated all your suggestions (or left a comment/question when it wasn't clear). > > Cheers, > Roman @rkennke Last ARM32 fixes: https://gist.github.com/tstuefe/8a0fd30618f1d0e085b5ca12d7c156cd I removed the superfluous flush from sharedRuntime. For a test, I applied https://github.com/openjdk/jdk/pull/13596 patch and built and tested arm (starting fastlockbench with interpreted, c1, c2), all seems to be well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1527233512 From stuefe at openjdk.org Fri Apr 28 10:45:25 2023 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 28 Apr 2023 10:45:25 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v65] In-Reply-To: References: Message-ID: On Fri, 28 Apr 2023 07:43:24 GMT, Roman Kennke wrote: >> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). >> >> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. >> >> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal protocols. >> >> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare. >> >> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. >> >> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. >> >> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. >> >> This change enables to simplify (and speed-up!) a lot of code: >> >> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. >> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR >> >> Also, and I might be mistaken here, this new lightweight locking would make synchronized work better with Loom: Because the lock-records are no longer scattered across the stack, but instead are densely packed into the lock-stack, it should be easy for a vthread to save its lock-stack upon unmounting and restore it when re-mounting. However, I am not sure about this, and this PR does not attempt to implement that support. >> >> Testing: >> - [x] tier1 x86_64 x aarch64 x +UseFastLocking >> - [x] tier2 x86_64 x aarch64 x +UseFastLocking >> - [x] tier3 x86_64 x aarch64 x +UseFastLocking >> - [x] tier4 x86_64 x aarch64 x +UseFastLocking >> - [x] tier1 x86_64 x aarch64 x -UseFastLocking >> - [x] tier2 x86_64 x aarch64 x -UseFastLocking >> - [x] tier3 x86_64 x aarch64 x -UseFastLocking >> - [x] tier4 x86_64 x aarch64 x -UseFastLocking >> - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet >> >> ### Performance >> >> #### Simple Microbenchmark >> >> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops. >> >> | | x86_64 | aarch64 | >> | -- | -- | -- | >> | -UseFastLocking | 20.651 | 20.764 | >> | +UseFastLocking | 18.896 | 18.908 | >> >> >> #### Renaissance >> >> ? | x86_64 | ? | ? | ? | aarch64 | ? | ? >> -- | -- | -- | -- | -- | -- | -- | -- >> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? >> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% >> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21% >> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% >> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% >> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% >> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% >> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%% >> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% >> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% >> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% >> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% >> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34% >> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% >> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% >> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% >> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% >> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% >> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% >> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% >> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% >> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% > > Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 162 commits: > > - Merge branch 'master' into JDK-8291555-v2 > - Fix formatting > - Suggestios by @dcubed-ojdk > - Suggested changes by @merykitty > - Remove unnecessary comments > - Simple build fix for extra arches > - Merge remote-tracking branch 'upstream/master' into JDK-8291555-v2 > - A few more LM_ prefixes in 32bit code > - Replace UseHeavyMonitor with LockingMode == LM_MONITOR > - Prefix LockingMode constants with LM_* > - ... and 152 more: https://git.openjdk.org/jdk/compare/3d9d84b7...d90810f1 I gave it a final inspection (as of https://github.com/openjdk/jdk/pull/10907/commits/1323e9584ee2303da0553e65c3968b5e81394b06). If you take over my small arm32 and ppcle changes, the patch looks good from my side. We should increase the number of reviewers though, and at least Dan should ok it as well. ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/10907#pullrequestreview-1405683129 From rkennke at openjdk.org Fri Apr 28 11:32:54 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 28 Apr 2023 11:32:54 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v66] In-Reply-To: References: Message-ID: <-Kq6LaQmYZC8PVnmA4IH6QflBHwDB8__ovkqWOGFjeE=.451a7a23-578d-4b7f-b55d-74759c2cc446@github.com> > This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). > > What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. > > This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p rotocols. > > The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare. > > In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. > > One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. > > As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. > > This change enables to simplify (and speed-up!) a lot of code: > > - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. > - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR > > Also, and I might be mistaken here, this new lightweight locking would make synchronized work better with Loom: Because the lock-records are no longer scattered across the stack, but instead are densely packed into the lock-stack, it should be easy for a vthread to save its lock-stack upon unmounting and restore it when re-mounting. However, I am not sure about this, and this PR does not attempt to implement that support. > > Testing: > - [x] tier1 x86_64 x aarch64 x +UseFastLocking > - [x] tier2 x86_64 x aarch64 x +UseFastLocking > - [x] tier3 x86_64 x aarch64 x +UseFastLocking > - [x] tier4 x86_64 x aarch64 x +UseFastLocking > - [x] tier1 x86_64 x aarch64 x -UseFastLocking > - [x] tier2 x86_64 x aarch64 x -UseFastLocking > - [x] tier3 x86_64 x aarch64 x -UseFastLocking > - [x] tier4 x86_64 x aarch64 x -UseFastLocking > - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet > > ### Performance > > #### Simple Microbenchmark > > The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops. > > | | x86_64 | aarch64 | > | -- | -- | -- | > | -UseFastLocking | 20.651 | 20.764 | > | +UseFastLocking | 18.896 | 18.908 | > > > #### Renaissance > > ? | x86_64 | ? | ? | ? | aarch64 | ? | ? > -- | -- | -- | -- | -- | -- | -- | -- > ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? > AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% > Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21% > Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% > ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% > GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% > LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% > MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%% > NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% > PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% > FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% > FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% > ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34% > Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% > RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% > Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% > ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% > FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% > FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Fix arm and ppcle builds ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10907/files - new: https://git.openjdk.org/jdk/pull/10907/files/d90810f1..50f1369f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=65 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=64-65 Stats: 4 lines in 3 files changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/10907.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/10907/head:pull/10907 PR: https://git.openjdk.org/jdk/pull/10907 From sjohanss at openjdk.org Fri Apr 28 13:10:57 2023 From: sjohanss at openjdk.org (Stefan Johansson) Date: Fri, 28 Apr 2023 13:10:57 GMT Subject: RFR: 8306929: Avoid CleanClassLoaderDataMetaspaces safepoints when previous versions are shared Message-ID: Hi all, Please review this change to avoid CleanClassLoaderDataMetaspaces safepoint when there is nothing that can be cleaned up. **Summary** When transforming/redefining classes a previous version list is linked together in the InstanceKlass. The original class is added to this list if it is still used or shared. The difference between shared and used is not currently noted. This leads to a problem when doing concurrent class unloading, because during that we postpone some potential work to a safepoint (since we are not in one). This is the CleanClassLoaderDataMetaspaces and it is triggered by the ServiceThread if there is work to be done, for example if InstanceKlass::_has_previous_versions is true. Since we currently does not differentiate between shared and "in use" we always set _has_previous_versions if anything is on this list. This together with the fact that shared previous versions should never be cleaned out leads to this safepoint being triggered after every concurrent class unloading even though there is nothing that can be cleaned out. This can be avoided by making sure the _previous_versions list is only cleaned when there are non-shared classes on it. This change renames `_has_previous_versions` to `_clean_previous_versions` and only updates it if we have non-shared classes on the list. **Testing** * A lot of manual testing verifying that we do get the safepoint when we should. * Added new test to verify expected behavior by parsing the logs. The test uses JFR to trigger redefinition of some shared classes (when -Xshare:on). * Mach5 run of new test and tier 1-3 ------------- Commit messages: - Add test wih JFR - 8306929: Avoid CleanClassLoaderDataMetaspaces safepoints when previous versions are shared Changes: https://git.openjdk.org/jdk/pull/13716/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13716&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8306929 Stats: 139 lines in 6 files changed: 116 ins; 3 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/13716.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13716/head:pull/13716 PR: https://git.openjdk.org/jdk/pull/13716 From yyang at openjdk.org Fri Apr 28 13:34:53 2023 From: yyang at openjdk.org (Yi Yang) Date: Fri, 28 Apr 2023 13:34:53 GMT Subject: RFR: JDK-8306441: Segmented heap dump [v3] In-Reply-To: <8YqPPHSW4K1s0t317Kp6UqvoGuv5v9oCbjtQ9FX8p2o=.0f6c687b-d031-401d-901d-1ec532715cdc@github.com> References: <8YqPPHSW4K1s0t317Kp6UqvoGuv5v9oCbjtQ9FX8p2o=.0f6c687b-d031-401d-901d-1ec532715cdc@github.com> Message-ID: > Hi, heap dump brings about pauses for application's execution(STW), this is a well-known pain. JDK-8252842 have added parallel support to heapdump in an attempt to alleviate this issue. However, all concurrent threads competitively write heap data to the same file, and more memory is required to maintain the concurrent buffer queue. In experiments, we did not feel a significant performance improvement from that. > > The minor-pause solution, which is presented in this PR, is a two-stage segmented heap dump: > > 1. Stage One(STW): Concurrent threads directly write data to multiple heap files. > 2. Stage Two(Non-STW): Merge multiple heap files into one complete heap dump file. > > Now concurrent worker threads are not required to maintain a buffer queue, which would result in more memory overhead, nor do they need to compete for locks. It significantly reduces 73~80% application pause time. > > | memory | numOfThread | STW | Total | > | --- | --------- | -------------- | ------------ | > | 8g | 1 thread | 15.612 secs | 15.612 secs | > | 8g | 32 thread | 2.5617250 secs | 14.498 secs | > | 8g | 96 thread | 2.6790452 secs | 14.012 secs | > | 16g | 1 thread | 26.278 secs | 26.278 secs | > | 16g | 32 thread | 5.2313740 secs | 26.417 secs | > | 16g | 96 thread | 6.2445556 secs | 27.141 secs | > | 32g | 1 thread | 48.149 secs | 48.149 secs | > | 32g | 32 thread | 10.7734677 secs | 61.643 secs | > | 32g | 96 thread | 13.1522042 secs | 61.432 secs | > | 64g | 1 thread | 100.583 secs | 100.583 secs | > | 64g | 32 thread | 20.9233744 secs | 134.701 secs | > | 64g | 96 thread | 26.7374116 secs | 126.080 secs | > | 128g | 1 thread | 233.843 secs | 233.843 secs | > | 128g | 32 thread | 72.9945768 secs | 207.060 secs | > | 128g | 96 thread | 67.6815929 secs | 336.345 secs | > >> **Total** means the total heap dump including both two phases >> **STW** means the first phase only. >> For parallel dump, **Total** = **STW** + **Merge**. For serial dump, **Total** = **STW** > > ![image](https://user-images.githubusercontent.com/5010047/234534654-6f29a3af-dad5-46bc-830b-7449c80b4dec.png) > > In actual testing, two-stage solution can lead to an increase in the overall time for heapdump(See table above). However, considering the reduction of STW time, I think it is an acceptable trade-off. Furthermore, there is still room for optimization in the second merge stage(e.g. sendfile/splice/copy_file_range instead of read+write combination). Since number of parallel dump thread has a considerable impact on total dump time, I added a parameter that allows users to specify the number of parallel dump thread they wish to run. > > ##### Open discussion > > - Pauseless heap dump solution? > An alternative pauseless solution is to fork a child process, set the parent process heap to read-only, and dump the heap in child process. Once writing happens in parent process, child process observes them by userfaultfd and corresponding pages are prioritized for dumping. I'm also looking forward to hearing comments and discussions about this solution. > > - Client parser support for segmented heap dump > This patch provides a possibility that whether heap dump needs to be complete or not, can the VM directly generate segmented heapdump, and let the client parser complete the merge process? Looking forward to hearing comments from the Eclipse MAT community Yi Yang has updated the pull request incrementally with one additional commit since the last revision: refactor VM_HeapDumpMerge ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13667/files - new: https://git.openjdk.org/jdk/pull/13667/files/00b49e4e..9e563ca7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13667&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13667&range=01-02 Stats: 83 lines in 1 file changed: 43 ins; 35 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/13667.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13667/head:pull/13667 PR: https://git.openjdk.org/jdk/pull/13667 From matsaave at openjdk.org Fri Apr 28 14:32:53 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 28 Apr 2023 14:32:53 GMT Subject: RFR: 8306851: Move Method access flags [v3] In-Reply-To: References: Message-ID: On Thu, 27 Apr 2023 14:21:23 GMT, Coleen Phillimore wrote: >> This change moves the flags from AccessFlags to either ConstMethodFlags or MethodFlags, depending on whether they are set at class file parse time, which makes them essentially const, or at runtime, which makes them needing atomic access. >> >> This leaves AccessFlags int size because Klass still has JVM flags that are more work to move, but this change doesn't increase Method size. I didn't remove JVM_RECOGNIZED_METHOD_MODIFIERS with this change since there are several of these in other places, and with this change the code is benign. >> >> Tested with tier1-6, and some manual verification of printing. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Remove bool argument from ConstMethodFlags.set function. Nice change! Just some small nits but it otherwise looks good. src/hotspot/share/oops/method.hpp line 606: > 604: > 605: bool compute_has_loops_flag(); > 606: bool set_has_loops() { set_has_loops_flag(); set_has_loops_flag_init(); return true; } Since this has multiple statements it should probably be on different lines src/hotspot/share/oops/method.hpp line 615: > 613: // has not been computed yet. > 614: bool guaranteed_monitor_matching() const { return monitor_matching(); } > 615: void set_guaranteed_monitor_matching() { set_monitor_matching(); } Is this method just obsolete now? If so it might be worth replacing the callers with `set_monitor_matching()` unless `set_monitor_matching()` is still meant to be private. ------------- Changes requested by matsaave (Committer). PR Review: https://git.openjdk.org/jdk/pull/13654#pullrequestreview-1406036462 PR Review Comment: https://git.openjdk.org/jdk/pull/13654#discussion_r1180462644 PR Review Comment: https://git.openjdk.org/jdk/pull/13654#discussion_r1180472698 From volker.simonis at gmail.com Fri Apr 28 15:38:12 2023 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 28 Apr 2023 17:38:12 +0200 Subject: JEP draft: Disallow the Dynamic Loading of Agents by Default In-Reply-To: <168352AB-C660-484F-BAA6-31A2B6F0D0C8@oracle.com> References: <168352AB-C660-484F-BAA6-31A2B6F0D0C8@oracle.com> Message-ID: On Wed, Apr 19, 2023 at 12:29?AM Ron Pressler wrote: > > Hi. > > Following last month?s email about changing the default of > EnableDynamicAgentLoading [1], we?ve now published two JEP drafts. > > The first is an informational JEP describing what integrity is and why we need it, > and motivates what changes are required to get it (which include the > restriction of dynamically loaded agents among others): > > https://openjdk.org/jeps/8305968 Integrity and Strong Encapsulation > > - Use sun.misc.Unsafe to access and modify private fields. > > - Load a native library that employs JNI to call private methods and > set private fields. (The JNI API is not subject to access checks.) > > - Load an agent that changes code in a running application, > using an API intended for tools only. > > To attain our goal of integrity by default, we will gradually restrict > these APIs and close all loopholes in a series of upcoming JEPs, ensuring > that no library can assume superpowers without the application's consent. > Libraries that rely on these APIs should spend the time remaining until > they are restricted to prepare their users for any necessary changes. I think it is a little unfortunate to put the usage of s.m.Unsafe and JNI/Instrumentation/JVMTI into the same category, especially when it comes to blaming developers for their usage. While s.m.Unsafe has always been an internal, undocumented and unsupported API, the latter three are part of the Java Platform (e.g. "native" is a Java keyword and Runtime.loadLibrary() is part of the Java API). Do you really plan to make JNI an optional feature which will have to be manually enabled at startup? What will be the benefit? I understand that in an ideal world where you had no user-supplied JNI libraries at all, you might be able to perform more/better optimizations. But as you'd have to support JNI anyway, wouldn't the maintenance of the resulting code become a nightmare. How many "if (JNI) {..} else {..}" would we get? And what would be the benefit of disabling it by default for the user except increased "integrity"? I.e. do you have some concrete examples of planned features X, Y, Z which will only work with disabled JNI? Will these features be Java SE features or implementation specific OpenJDK-only features? > The second touches on the specifics of dynamically loaded agents and the > proposed change: > > https://openjdk.org/jeps/8306275 Disallow the Dynamic Loading of Agents by Default > > Agents are used by profiling tools to instrument Java applications, > but agents can also be misused to undermine the integrity of the > Java Platform. I don't think it is fair to assume that profilers are the only "valid" use case for agents and imply that all other use cases are a mis-use of the API. > - It is not a goal to change the Attach API that allows a tool to > connect to a running JVM for monitoring and management purposes. I don't understand this "Non-Goal"? The Attach API [1] allows to dynamically attach to a running JVM and "Once a reference to a virtual machine is obtained, the loadAgent, loadAgentLibrary, and loadAgentPath methods are used to load agents into target virtual machine". So how can you achieve this JEP's goals without changing/restricting the Attach API? I therefore think this "Non-Goal" should be rephrased to explain which parts of the Attach API will be changed and moved to the "Goal" section instead. General comments: - You go into great detail to explain why a human-operated tool is "superior" (in the sense of trust and security) to a library and "would ideally not be subject to the integrity constraints imposed on the application". I can't follow this argument, because both, the decision to use a specific tool as well as the decision to rely on a library is taken by a human. I'd even argue that the decision to depend on a specific library which requires the dynmaic attach mechanism is taken by a more knowledgeable user (i.e. the developer himself). Of course both, a tool as well as a library can contain malicious code, but I don't see a fundamental difference between the two. - You may argue that users have to be protected from malicious libraries which gain their superpowers by secretly loading agents at runtime. But users who don't know and don't care about their library dependencies will just as easy and without reflection (pun intended :) add the -XX:+EnableDynamicAgentLoading to their command line arguments (making this the new, most often used command line option even surpassing the usage of --add-opens :) - I still can't understand the benefit of "only" changing the default behavior for dynamic agent loading. I could understand this if you'd do it with a plan to deprecate and completely remove the dynamic agent loading capability. But what are the benefits of changing the default if you'll have to support the functionality anyway? As mentioned in earlier discussions, my main concern with the proposed change is the impact it will have on the evolution of Java. Java's dynamic features are one of its biggest strength and a major reason for its success. Sacrificing some of them or making their usage increasingly expensive requires a broader discussion in the community and shouldn't happen "under the hood" of a discussion about the default setting of a command line flag. - I don't understand why this JEP has scope "SE". As you rightly mentioned, the Attach API is a "non-standard" API which can be changed at any time and without affecting the Java SE specification, so this JEP should rather have scope "JDK" instead. On the other hand, the fact that this functionality is not governed by the SE specification will allow different OpenJDK distributors to use a different default setting for -XX:EnableDynamicAgentLoading which has the potential to cause a lot of confusion if we can't sattle on a common strategy. - If doing this change at all, I think it would be better to do it in a non-LTS release first. Best regards, Volker [1] https://docs.oracle.com/en/java/javase/20/docs/api/jdk.attach/com/sun/tools/attach/VirtualMachine.html > [1]: https://mail.openjdk.org/pipermail/jigsaw-dev/2023-March/014816.html > > ? Ron From coleenp at openjdk.org Fri Apr 28 15:42:58 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 28 Apr 2023 15:42:58 GMT Subject: RFR: 8306851: Move Method access flags [v4] In-Reply-To: References: Message-ID: > This change moves the flags from AccessFlags to either ConstMethodFlags or MethodFlags, depending on whether they are set at class file parse time, which makes them essentially const, or at runtime, which makes them needing atomic access. > > This leaves AccessFlags int size because Klass still has JVM flags that are more work to move, but this change doesn't increase Method size. I didn't remove JVM_RECOGNIZED_METHOD_MODIFIERS with this change since there are several of these in other places, and with this change the code is benign. > > Tested with tier1-6, and some manual verification of printing. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Updates ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13654/files - new: https://git.openjdk.org/jdk/pull/13654/files/6687cc0e..9b05ab84 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13654&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13654&range=02-03 Stats: 9 lines in 1 file changed: 5 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13654.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13654/head:pull/13654 PR: https://git.openjdk.org/jdk/pull/13654 From coleenp at openjdk.org Fri Apr 28 15:43:03 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 28 Apr 2023 15:43:03 GMT Subject: RFR: 8306851: Move Method access flags [v3] In-Reply-To: References: Message-ID: On Fri, 28 Apr 2023 14:18:11 GMT, Matias Saavedra Silva wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove bool argument from ConstMethodFlags.set function. > > src/hotspot/share/oops/method.hpp line 615: > >> 613: // has not been computed yet. >> 614: bool guaranteed_monitor_matching() const { return monitor_matching(); } >> 615: void set_guaranteed_monitor_matching() { set_monitor_matching(); } > > Is this method just obsolete now? If so it might be worth replacing the callers with `set_monitor_matching()` unless `set_monitor_matching()` is still meant to be private. The reason I left that was to anchor the comment. There is nowhere good to put that in the X macro. Also, didn't want to fix the callers. It's a good point about making monitor_matching() private, but also not really doable with the X macro. So that's why I left it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13654#discussion_r1180548707 From ecki at zusammenkunft.net Fri Apr 28 16:01:46 2023 From: ecki at zusammenkunft.net (Bernd) Date: Fri, 28 Apr 2023 18:01:46 +0200 Subject: JEP draft: Disallow the Dynamic Loading of Agents by Default In-Reply-To: References: <168352AB-C660-484F-BAA6-31A2B6F0D0C8@oracle.com>, Message-ID: An HTML attachment was scrubbed... URL: From coleenp at openjdk.org Fri Apr 28 16:16:23 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 28 Apr 2023 16:16:23 GMT Subject: RFR: 8306929: Avoid CleanClassLoaderDataMetaspaces safepoints when previous versions are shared In-Reply-To: References: Message-ID: On Fri, 28 Apr 2023 12:48:44 GMT, Stefan Johansson wrote: > Hi all, > > Please review this change to avoid CleanClassLoaderDataMetaspaces safepoint when there is nothing that can be cleaned up. > > **Summary** > When transforming/redefining classes a previous version list is linked together in the InstanceKlass. The original class is added to this list if it is still used or shared. The difference between shared and used is not currently noted. This leads to a problem when doing concurrent class unloading, because during that we postpone some potential work to a safepoint (since we are not in one). This is the CleanClassLoaderDataMetaspaces and it is triggered by the ServiceThread if there is work to be done, for example if InstanceKlass::_has_previous_versions is true. > > Since we currently does not differentiate between shared and "in use" we always set _has_previous_versions if anything is on this list. This together with the fact that shared previous versions should never be cleaned out leads to this safepoint being triggered after every concurrent class unloading even though there is nothing that can be cleaned out. > > This can be avoided by making sure the _previous_versions list is only cleaned when there are non-shared classes on it. This change renames `_has_previous_versions` to `_clean_previous_versions` and only updates it if we have non-shared classes on the list. > > **Testing** > * A lot of manual testing verifying that we do get the safepoint when we should. > * Added new test to verify expected behavior by parsing the logs. The test uses JFR to trigger redefinition of some shared classes (when -Xshare:on). > * Mach5 run of new test and tier 1-3 This looks good. Thanks for all the testing and adding the new test. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13716#pullrequestreview-1406222927 From dcubed at openjdk.org Fri Apr 28 17:00:58 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 28 Apr 2023 17:00:58 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v66] In-Reply-To: <-Kq6LaQmYZC8PVnmA4IH6QflBHwDB8__ovkqWOGFjeE=.451a7a23-578d-4b7f-b55d-74759c2cc446@github.com> References: <-Kq6LaQmYZC8PVnmA4IH6QflBHwDB8__ovkqWOGFjeE=.451a7a23-578d-4b7f-b55d-74759c2cc446@github.com> Message-ID: On Fri, 28 Apr 2023 11:32:54 GMT, Roman Kennke wrote: >> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). >> >> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. >> >> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal protocols. >> >> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare. >> >> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. >> >> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. >> >> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. >> >> This change enables to simplify (and speed-up!) a lot of code: >> >> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. >> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR >> >> Also, and I might be mistaken here, this new lightweight locking would make synchronized work better with Loom: Because the lock-records are no longer scattered across the stack, but instead are densely packed into the lock-stack, it should be easy for a vthread to save its lock-stack upon unmounting and restore it when re-mounting. However, I am not sure about this, and this PR does not attempt to implement that support. >> >> Testing: >> - [x] tier1 x86_64 x aarch64 x +UseFastLocking >> - [x] tier2 x86_64 x aarch64 x +UseFastLocking >> - [x] tier3 x86_64 x aarch64 x +UseFastLocking >> - [x] tier4 x86_64 x aarch64 x +UseFastLocking >> - [x] tier1 x86_64 x aarch64 x -UseFastLocking >> - [x] tier2 x86_64 x aarch64 x -UseFastLocking >> - [x] tier3 x86_64 x aarch64 x -UseFastLocking >> - [x] tier4 x86_64 x aarch64 x -UseFastLocking >> - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet >> >> ### Performance >> >> #### Simple Microbenchmark >> >> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops. >> >> | | x86_64 | aarch64 | >> | -- | -- | -- | >> | -UseFastLocking | 20.651 | 20.764 | >> | +UseFastLocking | 18.896 | 18.908 | >> >> >> #### Renaissance >> >> ? | x86_64 | ? | ? | ? | aarch64 | ? | ? >> -- | -- | -- | -- | -- | -- | -- | -- >> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? >> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% >> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21% >> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% >> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% >> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% >> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% >> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%% >> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% >> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% >> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% >> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% >> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34% >> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% >> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% >> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% >> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% >> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% >> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% >> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% >> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% >> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Fix arm and ppcle builds This project is currently baselined on jdk-21+21-1701. However, that build-ID contains very noisy test failures in Tier[234] and probably higher. If you could rebase on: jiefu: [452cb8 - OpenJDK](https://orahub.oci.oraclecorp.com/jpg-mirrors/jdk-open/commit/452cb8432f4d45c3dacd4415bc9499ae73f7a17c) [8307103 ](http://bugs.openjdk.java.net/browse/JDK-8307103) Two TestMetaspaceAllocationMT tests fail after JDK-8306696 That would make my next Mach5 test cycle much, much happier... ------------- PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1527824532 From cjplummer at openjdk.org Fri Apr 28 17:45:59 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 28 Apr 2023 17:45:59 GMT Subject: RFR: 8282384: [LOOM] Need test for ThreadReference.interrupt() on a vthread [v4] In-Reply-To: References: Message-ID: > Convert this ThreadReference.interrupt() test to support virtual threads. I believe this is the only test for ThreadReference.interrupt() that we have. > > Tested by running with and without -Dmain.wrapper=Virtual on all supported platforms. Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: update comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13696/files - new: https://git.openjdk.org/jdk/pull/13696/files/a7f277a9..d2ee0c31 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13696&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13696&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/13696.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13696/head:pull/13696 PR: https://git.openjdk.org/jdk/pull/13696 From cjplummer at openjdk.org Fri Apr 28 17:46:02 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 28 Apr 2023 17:46:02 GMT Subject: RFR: 8306471: Add virtual threads support to JDWP ThreadReference.Stop and JDI ThreadReference.stop() [v2] In-Reply-To: <2iIOo1G9Tr-U5dzL82xfGQ5CkEA0V40nGXpKzmST_BM=.9b0ab2ed-996f-4163-b5e2-45a70ff18d9a@github.com> References: <2iIOo1G9Tr-U5dzL82xfGQ5CkEA0V40nGXpKzmST_BM=.9b0ab2ed-996f-4163-b5e2-45a70ff18d9a@github.com> Message-ID: > Note this PR depends on the #13546 PR for the following: > > [JDK-8306434](https://bugs.openjdk.org/browse/JDK-8306434): add support of virtual threads to JVMTI StopThread > > So it can't be finalized and push until after JDK-8306434 is pushed. There will also be GHA failures until then. If JDK-8306434 results in any additional spec changes, they will likely impact this CR also. > > > [JDK-8306034](https://bugs.openjdk.org/browse/JDK-8306034) is adding some virtual thread support to JVMTI StopThread. This will allow JDWP ThreadReference.Stop and JDI ThreadReference.stop() to have the same level support for virtual threads. > > Mostly this is a spec update for JDWP and JDI, but there are also some minor changes needed to the ThreadReference.stop() handling of JDWP errors, and throwing the appropriate exceptions. Also some minor cleanup in jdb. The debug agent doesn't need changes since JVMTI errors are just passed through as the corresponding JDWP errors, and the code for this is already in place. These errors are not new nor need any special handling. > > Our existing testing for ThreadReference.stop() is fairly weak: > > - nsk/jdb/kill/kill001, which tests stop() when the thread is suspended at a breakpoint. It will get problem listed by [JDK-8306034](https://bugs.openjdk.org/browse/JDK-8306034). I have fixes for it already working and will push it separately. > - nsk/jdi/stop/stop001, which is problem listed and only tests when the thread is blocked in Object.wait() > - nsk/jdi/stop/stop002, which only tests that throwing an invalid exception fails properly > > I decided to take stop002 and make it a more thorough test of ThreadReference.stop(). See the comment at the top for a list of what is tested. As for reviewing this test, it's probably best to look at it as a completely new test rather than looking at diffs since so much has been changed and added. Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: Fix test when suspended in a loop. Cleanup sme comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13548/files - new: https://git.openjdk.org/jdk/pull/13548/files/fcf29b1e..f1ed2c6f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13548&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13548&range=00-01 Stats: 18 lines in 1 file changed: 2 ins; 9 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/13548.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13548/head:pull/13548 PR: https://git.openjdk.org/jdk/pull/13548 From fparain at openjdk.org Fri Apr 28 18:37:30 2023 From: fparain at openjdk.org (Frederic Parain) Date: Fri, 28 Apr 2023 18:37:30 GMT Subject: RFR: 8306851: Move Method access flags [v3] In-Reply-To: References: Message-ID: On Thu, 27 Apr 2023 14:21:23 GMT, Coleen Phillimore wrote: >> This change moves the flags from AccessFlags to either ConstMethodFlags or MethodFlags, depending on whether they are set at class file parse time, which makes them essentially const, or at runtime, which makes them needing atomic access. >> >> This leaves AccessFlags int size because Klass still has JVM flags that are more work to move, but this change doesn't increase Method size. I didn't remove JVM_RECOGNIZED_METHOD_MODIFIERS with this change since there are several of these in other places, and with this change the code is benign. >> >> Tested with tier1-6, and some manual verification of printing. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Remove bool argument from ConstMethodFlags.set function. Thank you for all those cleanings! Looks good to me. src/hotspot/share/oops/constMethod.cpp line 438: > 436: } > 437: st->cr(); > 438: st->print(" - flags: "); _flags.print_on(st); st->cr(); Method prints its flags as an int and in decoded form, but ConstMethod only prints the decoded form. Any particular reason for this difference? ------------- Marked as reviewed by fparain (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/13654#pullrequestreview-1406421552 PR Review Comment: https://git.openjdk.org/jdk/pull/13654#discussion_r1180705106 From coleenp at openjdk.org Fri Apr 28 18:51:24 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 28 Apr 2023 18:51:24 GMT Subject: RFR: 8306851: Move Method access flags [v3] In-Reply-To: References: Message-ID: On Fri, 28 Apr 2023 18:29:50 GMT, Frederic Parain wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove bool argument from ConstMethodFlags.set function. > > src/hotspot/share/oops/constMethod.cpp line 438: > >> 436: } >> 437: st->cr(); >> 438: st->print(" - flags: "); _flags.print_on(st); st->cr(); > > Method prints its flags as an int and in decoded form, but ConstMethod only prints the decoded form. Any particular reason for this difference? No reason for this difference. The only reason I added the int form for MethodFlags was because AccessFlags were printed also with the int form. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13654#discussion_r1180712196 From rkennke at openjdk.org Fri Apr 28 19:23:28 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 28 Apr 2023 19:23:28 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v66] In-Reply-To: References: <-Kq6LaQmYZC8PVnmA4IH6QflBHwDB8__ovkqWOGFjeE=.451a7a23-578d-4b7f-b55d-74759c2cc446@github.com> Message-ID: On Fri, 28 Apr 2023 16:48:12 GMT, Daniel D. Daugherty wrote: > http://bugs.openjdk.java.net/browse/JDK-8307103 Should be based on JDK-8307103 now. Thanks for all your testing! ------------- PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1527972396 From rkennke at openjdk.org Fri Apr 28 19:23:24 2023 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 28 Apr 2023 19:23:24 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v67] In-Reply-To: References: Message-ID: <3Iabuiks5W03nXCOPejWEQAZMz1GqlvaZUmuvs5Bczs=.b8433f00-9394-437f-a7e1-db407bbba983@github.com> > This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). > > What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. > > This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal p rotocols. > > The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare. > > In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. > > One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. > > As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. > > This change enables to simplify (and speed-up!) a lot of code: > > - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. > - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR > > Also, and I might be mistaken here, this new lightweight locking would make synchronized work better with Loom: Because the lock-records are no longer scattered across the stack, but instead are densely packed into the lock-stack, it should be easy for a vthread to save its lock-stack upon unmounting and restore it when re-mounting. However, I am not sure about this, and this PR does not attempt to implement that support. > > Testing: > - [x] tier1 x86_64 x aarch64 x +UseFastLocking > - [x] tier2 x86_64 x aarch64 x +UseFastLocking > - [x] tier3 x86_64 x aarch64 x +UseFastLocking > - [x] tier4 x86_64 x aarch64 x +UseFastLocking > - [x] tier1 x86_64 x aarch64 x -UseFastLocking > - [x] tier2 x86_64 x aarch64 x -UseFastLocking > - [x] tier3 x86_64 x aarch64 x -UseFastLocking > - [x] tier4 x86_64 x aarch64 x -UseFastLocking > - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet > > ### Performance > > #### Simple Microbenchmark > > The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops. > > | | x86_64 | aarch64 | > | -- | -- | -- | > | -UseFastLocking | 20.651 | 20.764 | > | +UseFastLocking | 18.896 | 18.908 | > > > #### Renaissance > > ? | x86_64 | ? | ? | ? | aarch64 | ? | ? > -- | -- | -- | -- | -- | -- | -- | -- > ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? > AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% > Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21% > Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% > ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% > GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% > LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% > MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%% > NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% > PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% > FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% > FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% > ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34% > Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% > RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% > Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% > ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% > ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% > ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% > Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% > FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% > FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 164 commits: - Merge commit '452cb8432f4d45c3dacd4415bc9499ae73f7a17c' into JDK-8291555-v2 - Fix arm and ppcle builds - Merge branch 'master' into JDK-8291555-v2 - Fix formatting - Suggestios by @dcubed-ojdk - Suggested changes by @merykitty - Remove unnecessary comments - Simple build fix for extra arches - Merge remote-tracking branch 'upstream/master' into JDK-8291555-v2 - A few more LM_ prefixes in 32bit code - ... and 154 more: https://git.openjdk.org/jdk/compare/452cb843...39b199b6 ------------- Changes: https://git.openjdk.org/jdk/pull/10907/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10907&range=66 Stats: 2492 lines in 68 files changed: 1674 ins; 104 del; 714 mod Patch: https://git.openjdk.org/jdk/pull/10907.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/10907/head:pull/10907 PR: https://git.openjdk.org/jdk/pull/10907 From matsaave at openjdk.org Fri Apr 28 19:37:53 2023 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 28 Apr 2023 19:37:53 GMT Subject: RFR: 8306851: Move Method access flags [v4] In-Reply-To: References: Message-ID: On Fri, 28 Apr 2023 15:42:58 GMT, Coleen Phillimore wrote: >> This change moves the flags from AccessFlags to either ConstMethodFlags or MethodFlags, depending on whether they are set at class file parse time, which makes them essentially const, or at runtime, which makes them needing atomic access. >> >> This leaves AccessFlags int size because Klass still has JVM flags that are more work to move, but this change doesn't increase Method size. I didn't remove JVM_RECOGNIZED_METHOD_MODIFIERS with this change since there are several of these in other places, and with this change the code is benign. >> >> Tested with tier1-6, and some manual verification of printing. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Updates Looks good, thanks! ------------- Marked as reviewed by matsaave (Committer). PR Review: https://git.openjdk.org/jdk/pull/13654#pullrequestreview-1406485565 From dcubed at openjdk.org Fri Apr 28 19:40:54 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 28 Apr 2023 19:40:54 GMT Subject: RFR: 8307067: remove broken EnableThreadSMRExtraValidityChecks option Message-ID: A trivial fix to remove broken EnableThreadSMRExtraValidityChecks option. ------------- Commit messages: - 8307067: remove broken EnableThreadSMRExtraValidityChecks option Changes: https://git.openjdk.org/jdk/pull/13704/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13704&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8307067 Stats: 11 lines in 3 files changed: 0 ins; 7 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13704.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13704/head:pull/13704 PR: https://git.openjdk.org/jdk/pull/13704 From coleenp at openjdk.org Fri Apr 28 20:00:53 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 28 Apr 2023 20:00:53 GMT Subject: RFR: 8306851: Move Method access flags [v3] In-Reply-To: References: Message-ID: <7o09JnIhYwcYOJhT1zl2necGdXP4bW4rZLmsujrIdmA=.8361d936-5061-43b2-8678-687ef1a94b74@github.com> On Fri, 28 Apr 2023 18:39:21 GMT, Coleen Phillimore wrote: >> src/hotspot/share/oops/constMethod.cpp line 438: >> >>> 436: } >>> 437: st->cr(); >>> 438: st->print(" - flags: "); _flags.print_on(st); st->cr(); >> >> Method prints its flags as an int and in decoded form, but ConstMethod only prints the decoded form. Any particular reason for this difference? > > No reason for this difference. The only reason I added the int form for MethodFlags was because AccessFlags were printed also with the int form. I fixed the constMethod printing with the last commit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13654#discussion_r1180757104 From coleenp at openjdk.org Fri Apr 28 19:59:53 2023 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 28 Apr 2023 19:59:53 GMT Subject: RFR: 8306851: Move Method access flags [v5] In-Reply-To: References: Message-ID: <9mcZrjg-k3wLBxbR3dCguWSBKxZkZJVGtQLsV30bMhI=.e9b2c774-c968-46e4-9b92-3e090edc07d5@github.com> > This change moves the flags from AccessFlags to either ConstMethodFlags or MethodFlags, depending on whether they are set at class file parse time, which makes them essentially const, or at runtime, which makes them needing atomic access. > > This leaves AccessFlags int size because Klass still has JVM flags that are more work to move, but this change doesn't increase Method size. I didn't remove JVM_RECOGNIZED_METHOD_MODIFIERS with this change since there are several of these in other places, and with this change the code is benign. > > Tested with tier1-6, and some manual verification of printing. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Fix constMethod printing. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13654/files - new: https://git.openjdk.org/jdk/pull/13654/files/9b05ab84..d0de72ac Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13654&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13654&range=03-04 Stats: 6 lines in 3 files changed: 1 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/13654.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13654/head:pull/13654 PR: https://git.openjdk.org/jdk/pull/13654 From cjplummer at openjdk.org Fri Apr 28 20:54:49 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 28 Apr 2023 20:54:49 GMT Subject: RFR: 8306471: Add virtual threads support to JDWP ThreadReference.Stop and JDI ThreadReference.stop() [v3] In-Reply-To: <2iIOo1G9Tr-U5dzL82xfGQ5CkEA0V40nGXpKzmST_BM=.9b0ab2ed-996f-4163-b5e2-45a70ff18d9a@github.com> References: <2iIOo1G9Tr-U5dzL82xfGQ5CkEA0V40nGXpKzmST_BM=.9b0ab2ed-996f-4163-b5e2-45a70ff18d9a@github.com> Message-ID: > Note this PR depends on the #13546 PR for the following: > > [JDK-8306434](https://bugs.openjdk.org/browse/JDK-8306434): add support of virtual threads to JVMTI StopThread > > So it can't be finalized and push until after JDK-8306434 is pushed. There will also be GHA failures until then. If JDK-8306434 results in any additional spec changes, they will likely impact this CR also. > > > [JDK-8306034](https://bugs.openjdk.org/browse/JDK-8306034) is adding some virtual thread support to JVMTI StopThread. This will allow JDWP ThreadReference.Stop and JDI ThreadReference.stop() to have the same level support for virtual threads. > > Mostly this is a spec update for JDWP and JDI, but there are also some minor changes needed to the ThreadReference.stop() handling of JDWP errors, and throwing the appropriate exceptions. Also some minor cleanup in jdb. The debug agent doesn't need changes since JVMTI errors are just passed through as the corresponding JDWP errors, and the code for this is already in place. These errors are not new nor need any special handling. > > Our existing testing for ThreadReference.stop() is fairly weak: > > - nsk/jdb/kill/kill001, which tests stop() when the thread is suspended at a breakpoint. It will get problem listed by [JDK-8306034](https://bugs.openjdk.org/browse/JDK-8306034). I have fixes for it already working and will push it separately. > - nsk/jdi/stop/stop001, which is problem listed and only tests when the thread is blocked in Object.wait() > - nsk/jdi/stop/stop002, which only tests that throwing an invalid exception fails properly > > I decided to take stop002 and make it a more thorough test of ThreadReference.stop(). See the comment at the top for a list of what is tested. As for reviewing this test, it's probably best to look at it as a completely new test rather than looking at diffs since so much has been changed and added. Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: Don't rely in Thread.sleep() to sychronize between debugger and debuggee. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13548/files - new: https://git.openjdk.org/jdk/pull/13548/files/f1ed2c6f..745ff33d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13548&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13548&range=01-02 Stats: 39 lines in 2 files changed: 26 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/13548.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13548/head:pull/13548 PR: https://git.openjdk.org/jdk/pull/13548 From dcubed at openjdk.org Fri Apr 28 20:54:53 2023 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 28 Apr 2023 20:54:53 GMT Subject: RFR: 8291555: Implement alternative fast-locking scheme [v67] In-Reply-To: <3Iabuiks5W03nXCOPejWEQAZMz1GqlvaZUmuvs5Bczs=.b8433f00-9394-437f-a7e1-db407bbba983@github.com> References: <3Iabuiks5W03nXCOPejWEQAZMz1GqlvaZUmuvs5Bczs=.b8433f00-9394-437f-a7e1-db407bbba983@github.com> Message-ID: <1gD-39K3koUUdiL3rAs2BmLD-KTN0rZBIM3PacdGa7I=.28f43014-26b8-4538-bac8-9c09fb48c2bc@github.com> On Fri, 28 Apr 2023 19:23:24 GMT, Roman Kennke wrote: >> This change adds a fast-locking scheme as an alternative to the current stack-locking implementation. It retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation when trying to access the mark-word. And because of the very racy nature, this turns out to be very complex and would involve a variant of the inflation protocol to ensure that the object header is stable. (The current implementation of setting/fetching the i-hash provides a glimpse into the complexity). >> >> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. >> >> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations (and we already do). The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal protocols. >> >> The lock-stack is fixed size, currently with 8 elements. According to my experiments with various workloads, this covers the vast majority of workloads (in-fact, most workloads seem to never exceed 5 active locks per thread at a time). We check for overflow in the fast-paths and when the lock-stack is full, we take the slow-path, which would inflate the lock to a monitor. That case should be very rare. >> >> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. >> >> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. >> >> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. >> >> This change enables to simplify (and speed-up!) a lot of code: >> >> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. >> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR >> >> Also, and I might be mistaken here, this new lightweight locking would make synchronized work better with Loom: Because the lock-records are no longer scattered across the stack, but instead are densely packed into the lock-stack, it should be easy for a vthread to save its lock-stack upon unmounting and restore it when re-mounting. However, I am not sure about this, and this PR does not attempt to implement that support. >> >> Testing: >> - [x] tier1 x86_64 x aarch64 x +UseFastLocking >> - [x] tier2 x86_64 x aarch64 x +UseFastLocking >> - [x] tier3 x86_64 x aarch64 x +UseFastLocking >> - [x] tier4 x86_64 x aarch64 x +UseFastLocking >> - [x] tier1 x86_64 x aarch64 x -UseFastLocking >> - [x] tier2 x86_64 x aarch64 x -UseFastLocking >> - [x] tier3 x86_64 x aarch64 x -UseFastLocking >> - [x] tier4 x86_64 x aarch64 x -UseFastLocking >> - [x] Several real-world applications have been tested with this change in tandem with Lilliput without any problems, yet >> >> ### Performance >> >> #### Simple Microbenchmark >> >> The microbenchmark exercises only the locking primitives for monitorenter and monitorexit, without contention. The benchmark can be found (here)[https://github.com/rkennke/fastlockbench]. Numbers are in ns/ops. >> >> | | x86_64 | aarch64 | >> | -- | -- | -- | >> | -UseFastLocking | 20.651 | 20.764 | >> | +UseFastLocking | 18.896 | 18.908 | >> >> >> #### Renaissance >> >> ? | x86_64 | ? | ? | ? | aarch64 | ? | ? >> -- | -- | -- | -- | -- | -- | -- | -- >> ? | stack-locking | fast-locking | ? | ? | stack-locking | fast-locking | ? >> AkkaUct | 841.884 | 836.948 | 0.59% | ? | 1475.774 | 1465.647 | 0.69% >> Reactors | 11041.427 | 11181.451 | -1.25% | ? | 11381.751 | 11521.318 | -1.21% >> Als | 1367.183 | 1359.358 | 0.58% | ? | 1678.103 | 1688.067 | -0.59% >> ChiSquare | 577.021 | 577.398 | -0.07% | ? | 986.619 | 988.063 | -0.15% >> GaussMix | 817.459 | 819.073 | -0.20% | ? | 1154.293 | 1155.522 | -0.11% >> LogRegression | 598.343 | 603.371 | -0.83% | ? | 638.052 | 644.306 | -0.97% >> MovieLens | 8248.116 | 8314.576 | -0.80% | ? | 7569.219 | 7646.828 | -1.01%% >> NaiveBayes | 587.607 | 581.608 | 1.03% | ? | 541.583 | 550.059 | -1.54% >> PageRank | 3260.553 | 3263.472 | -0.09% | ? | 4376.405 | 4381.101 | -0.11% >> FjKmeans | 979.978 | 976.122 | 0.40% | ? | 774.312 | 771.235 | 0.40% >> FutureGenetic | 2187.369 | 2183.271 | 0.19% | ? | 2685.722 | 2689.056 | -0.12% >> ParMnemonics | 2434.551 | 2468.763 | -1.39% | ? | 4278.225 | 4263.863 | 0.34% >> Scrabble | 111.882 | 111.768 | 0.10% | ? | 151.796 | 153.959 | -1.40% >> RxScrabble | 210.252 | 211.38 | -0.53% | ? | 310.116 | 315.594 | -1.74% >> Dotty | 750.415 | 752.658 | -0.30% | ? | 1033.636 | 1036.168 | -0.24% >> ScalaDoku | 3072.05 | 3051.2 | 0.68% | ? | 3711.506 | 3690.04 | 0.58% >> ScalaKmeans | 211.427 | 209.957 | 0.70% | ? | 264.38 | 265.788 | -0.53% >> ScalaStmBench7 | 1017.795 | 1018.869 | -0.11% | ? | 1088.182 | 1092.266 | -0.37% >> Philosophers | 6450.124 | 6565.705 | -1.76% | ? | 12017.964 | 11902.559 | 0.97% >> FinagleChirper | 3953.623 | 3972.647 | -0.48% | ? | 4750.751 | 4769.274 | -0.39% >> FinagleHttp | 3970.526 | 4005.341 | -0.87% | ? | 5294.125 | 5296.224 | -0.04% > > Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 164 commits: > > - Merge commit '452cb8432f4d45c3dacd4415bc9499ae73f7a17c' into JDK-8291555-v2 > - Fix arm and ppcle builds > - Merge branch 'master' into JDK-8291555-v2 > - Fix formatting > - Suggestios by @dcubed-ojdk > - Suggested changes by @merykitty > - Remove unnecessary comments > - Simple build fix for extra arches > - Merge remote-tracking branch 'upstream/master' into JDK-8291555-v2 > - A few more LM_ prefixes in 32bit code > - ... and 154 more: https://git.openjdk.org/jdk/compare/452cb843...39b199b6 This project is now baselined on jdk-21+21-1704. I've started Mach5 testing of v66 with stack-locking as the default and Mach5 testing of v66 with a patch that forces fast-locking to be the default. ------------- PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1528073011 From cjplummer at openjdk.org Fri Apr 28 21:30:23 2023 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 28 Apr 2023 21:30:23 GMT Subject: RFR: 8306471: Add virtual threads support to JDWP ThreadReference.Stop and JDI ThreadReference.stop() [v4] In-Reply-To: <2iIOo1G9Tr-U5dzL82xfGQ5CkEA0V40nGXpKzmST_BM=.9b0ab2ed-996f-4163-b5e2-45a70ff18d9a@github.com> References: <2iIOo1G9Tr-U5dzL82xfGQ5CkEA0V40nGXpKzmST_BM=.9b0ab2ed-996f-4163-b5e2-45a70ff18d9a@github.com> Message-ID: > Note this PR depends on the #13546 PR for the following: > > [JDK-8306434](https://bugs.openjdk.org/browse/JDK-8306434): add support of virtual threads to JVMTI StopThread > > So it can't be finalized and push until after JDK-8306434 is pushed. There will also be GHA failures until then. If JDK-8306434 results in any additional spec changes, they will likely impact this CR also. > > > [JDK-8306034](https://bugs.openjdk.org/browse/JDK-8306034) is adding some virtual thread support to JVMTI StopThread. This will allow JDWP ThreadReference.Stop and JDI ThreadReference.stop() to have the same level support for virtual threads. > > Mostly this is a spec update for JDWP and JDI, but there are also some minor changes needed to the ThreadReference.stop() handling of JDWP errors, and throwing the appropriate exceptions. Also some minor cleanup in jdb. The debug agent doesn't need changes since JVMTI errors are just passed through as the corresponding JDWP errors, and the code for this is already in place. These errors are not new nor need any special handling. > > Our existing testing for ThreadReference.stop() is fairly weak: > > - nsk/jdb/kill/kill001, which tests stop() when the thread is suspended at a breakpoint. It will get problem listed by [JDK-8306034](https://bugs.openjdk.org/browse/JDK-8306034). I have fixes for it already working and will push it separately. > - nsk/jdi/stop/stop001, which is problem listed and only tests when the thread is blocked in Object.wait() > - nsk/jdi/stop/stop002, which only tests that throwing an invalid exception fails properly > > I decided to take stop002 and make it a more thorough test of ThreadReference.stop(). See the comment at the top for a list of what is tested. As for reviewing this test, it's probably best to look at it as a completely new test rather than looking at diffs since so much has been changed and added. Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: Some test logging improvements. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13548/files - new: https://git.openjdk.org/jdk/pull/13548/files/745ff33d..801362e5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13548&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13548&range=02-03 Stats: 19 lines in 2 files changed: 7 ins; 1 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/13548.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13548/head:pull/13548 PR: https://git.openjdk.org/jdk/pull/13548 From heidinga at redhat.com Sat Apr 29 02:30:01 2023 From: heidinga at redhat.com (Dan Heidinga) Date: Fri, 28 Apr 2023 22:30:01 -0400 Subject: JEP draft: Disallow the Dynamic Loading of Agents by Default Message-ID: Hi Ron, Thanks for writing up the JEP draft outlining the proposal to disallow dynamic loading of agents by default. The Red Hat Java team has continued to discuss this proposal internally and with our stakeholders. While there is a general agreement (or at least acceptance) with the overall direction of this proposal, we still see the concerns raised by Andrew [0] as needing to be addressed. So let?s start with the high-order bit: timing. The JEP draft states it ?intends to adopt the proposal [to disable agents by default] six years later, in 2023, for JDK 21.? We would like to see this targeted to JDK 22 instead as the change has not been widely evangelized yet and comes as a surprise to many, both to those actively developing OpenJDK and to those monitoring its development. We owe it to the community to give this proposal enough bake time, especially given that JDK 21 is an LTS release. Though the official position is that LTS releases are no different than any other release, the actions of JDK consumers make them special. Users will be surprised by this change when they migrate from JDK 17 to 21. If we delay till JDK 22, we give the ecosystem time to adapt to the change before the next LTS. Additionally, users who have tested with the -XX:-EnableDynamicAgentLoading option will have false expectations if they validated their use of jcmd to load the agent as the behaviour was not correct prior to JDK 21 [1]. The next concern is one you call out in the draft that ?Java's excellent serviceability has long been a source of pride for the platform.? We agree! Java currently has an excellent, prime position in Observability capabilities. For better or for worse, there are many Observability tools that have relied on dynamic attach to provide the necessary monitoring for workloads It?s important we give Java?s monitoring tools sufficient time to migrate comfortably without shocking the ecosystem by changing the default in an LTS. By delaying the change till JDK 22, we give the ecosystem 2 years to migrate and to prepare users for the change. Additionally, this provides the time for Java?s profiling tools to adapt as well. And for the ?ad-hoc troubleshooting? tools - like Byteman - to retrain their users. Finally, while it?s easy to agree with the principle that ?the application owner is given the final say on whether to allow dynamic loading of agents?, the argument can (and should!) be made that those application owners have made that final decision by deploying the libraries and tools that use dynamic attach. A JVM command line argument is not the only way to express their consent for code to run on their system. For many production uses, the reality is more complicated than a single ?application owner?. Take a Kubernetes cluster for example. Who is the application owner when deploying to a Kubernetes cluster? The dev team that develops the application? The operations team that manages the cluster? The monitoring team that monitors the applications? The Support team that troubleshoots issues with the deployment? We should be careful not to understate or misrepresent the complex web of ?owners? that are currently able (and, for business reasons, need) to apply agents dynamically. Downplaying the complexity many organizations experience when dealing with changes to command line options (as an example) weakens the argument for changing today?s status quo. We also know that in many cases customers and users may not be in a position to modify startup scripts (e.g. even to add in an extra parameter) as to do so may invalidate support contracts, etc. Dynamically attached agents have been a ?superpower? of Java and their use has greatly benefited the ecosystem as they?ve helped service and support use cases that otherwise aren?t possible, as they helped propel Java to the forefront of the Observability tooling, and allowed many other useful libraries to be developed. Let?s delay flipping the default until JDK 22 to give the breadth of the ecosystem time to absorb this change. ?Dan [0] https://mail.openjdk.org/pipermail/serviceability-dev/2023-March/047084.html [1] https://bugs.openjdk.org/browse/JDK-8304438 -------------- next part -------------- An HTML attachment was scrubbed... URL: From eirbjo at gmail.com Fri Apr 28 19:14:08 2023 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Fri, 28 Apr 2023 21:14:08 +0200 Subject: JEP draft: Disallow the Dynamic Loading of Agents by Default In-Reply-To: References: <168352AB-C660-484F-BAA6-31A2B6F0D0C8@oracle.com> Message-ID: > > > Agents are used by profiling tools to instrument Java applications, > > but agents can also be misused to undermine the integrity of the > > Java Platform. > > I don't think it is fair to assume that profilers are the only "valid" > use case for agents and imply that all other use cases are a mis-use > of the API. > First, I don't read the JEP as implying that all non-profiler use cases are misuse. Having said that, I do think that agents can in fact strengthen the integrity of the platform. Case in point is that when the Java serialization vulnerabilities hit around 2015, I could very quickly ( a few hours) whip together the "NotSoSerial" serialization firewall agent [1] to efficiently prevent exploits. I later got word that a large CMS vendor deployed it to their platform which included some of the world's busiest websites. I don't know if they used the attach mechanism to plug their serialization holes, but they surely could at the time. With microservices gaining popularity over the years, restarts are probably more common and automated now, including configuration of JVM options. So attaching to long-running instances to prevent restarts is probably becoming less useful over time. The agent misuse that the JEP is referring to here is perhaps mostly concerning libraries using the attach mechanism to get access they otherwise would not have in a running JVM? Perhaps the JEP could be updated to be more clear on this? Cheers, Eirik. [1] https://github.com/kantega/notsoserial/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Sat Apr 29 15:54:23 2023 From: duke at openjdk.org (Afshin Zafari) Date: Sat, 29 Apr 2023 15:54:23 GMT Subject: RFR: 8305083: Remove finalize() from test/hotspot/jtreg/vmTestbase/nsk/share/ and /jpda that are used in serviceability/dcmd/framework tests [v2] In-Reply-To: References: Message-ID: > The `finalize()` method is removed from base classes/interfaces and are replaced by a Cleaner callback.. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: 8305083: Remove finalize() from test/hotspot/jtreg/vmTestbase/nsk/share/ and /jpda that are used in serviceability/dcmd/framework tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/13420/files - new: https://git.openjdk.org/jdk/pull/13420/files/6f430512..fa8e4537 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=13420&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13420&range=00-01 Stats: 107 lines in 10 files changed: 55 ins; 30 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/13420.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13420/head:pull/13420 PR: https://git.openjdk.org/jdk/pull/13420 From kirk.pepperdine at gmail.com Sat Apr 29 18:41:15 2023 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Sat, 29 Apr 2023 11:41:15 -0700 Subject: JEP draft: Disallow the Dynamic Loading of Agents by Default In-Reply-To: References: Message-ID: Hi Dan, I was initially concerned with this proposal and that it was being introduced into an LTS has only added to that. You are quite correct that it?s not what we wish to be true that should be driving us. So yes, LTS?s are no different than other releases except that isn?t what our users are saying as they jump from LTS to LTS. While I fear my being concerned by a pending change falls from a tendency towards "resistance to change?, I also know that changes in the tooling chain historically have oversized effects on an organizations ability to migrate to the latest and greatest. I?d feel a lot better about things if only I had the data to help me temper my level of concern. To that end I?ve been speaking to different projects to understand the impact this change might have on them. The feedback from our biggest project that will be directly impacted by this change have (loosely) said, dynamic attach offers us a simple model to deliver monitoring but we could switch to direct attach. The problem here is that this project is a bolt on to many other applications and while this project could change, it?s not clear (for many of the reasons you?ve pointed out below) that it?s customers could. Complicating this is that I believe that only a handful of devs/devops/ops people know this in the works. Finally, a precedent for delaying the taking away capabilities from users was established with the release of modularity in Java 9. As you may recall, Java 9 broke so many things that deploying the full on application of modularity was helpful. I would think that a similar approach here where the full on change was applied after the LTS release would also help adaptation. Kind regards, Kirk PS, this email is targeted for serviceability but has been crossposted so that others not following that list will be aware of pending changes. > On Apr 28, 2023, at 7:30 PM, Dan Heidinga wrote: > > Hi Ron, > > Thanks for writing up the JEP draft outlining the proposal to disallow dynamic loading of agents by default. The Red Hat Java team has continued to discuss this proposal internally and with our stakeholders. > > While there is a general agreement (or at least acceptance) with the overall direction of this proposal, we still see the concerns raised by Andrew [0] as needing to be addressed. > > So let?s start with the high-order bit: timing. > > The JEP draft states it ?intends to adopt the proposal [to disable agents by default] six years later, in 2023, for JDK 21.? We would like to see this targeted to JDK 22 instead as the change has not been widely evangelized yet and comes as a surprise to many, both to those actively developing OpenJDK and to those monitoring its development. > > We owe it to the community to give this proposal enough bake time, especially given that JDK 21 is an LTS release. Though the official position is that LTS releases are no different than any other release, the actions of JDK consumers make them special. Users will be surprised by this change when they migrate from JDK 17 to 21. If we delay till JDK 22, we give the ecosystem time to adapt to the change before the next LTS. > > Additionally, users who have tested with the -XX:-EnableDynamicAgentLoading option will have false expectations if they validated their use of jcmd to load the agent as the behaviour was not correct prior to JDK 21 [1]. > > The next concern is one you call out in the draft that ?Java's excellent serviceability has long been a source of pride for the platform.? We agree! > > Java currently has an excellent, prime position in Observability capabilities. For better or for worse, there are many Observability tools that have relied on dynamic attach to provide the necessary monitoring for workloads > > It?s important we give Java?s monitoring tools sufficient time to migrate comfortably without shocking the ecosystem by changing the default in an LTS. By delaying the change till JDK 22, we give the ecosystem 2 years to migrate and to prepare users for the change. > > Additionally, this provides the time for Java?s profiling tools to adapt as well. And for the ?ad-hoc troubleshooting? tools - like Byteman - to retrain their users. > > Finally, while it?s easy to agree with the principle that ?the application owner is given the final say on whether to allow dynamic loading of agents?, the argument can (and should!) be made that those application owners have made that final decision by deploying the libraries and tools that use dynamic attach. A JVM command line argument is not the only way to express their consent for code to run on their system. > > For many production uses, the reality is more complicated than a single ?application owner?. Take a Kubernetes cluster for example. > > Who is the application owner when deploying to a Kubernetes cluster? The dev team that develops the application? The operations team that manages the cluster? The monitoring team that monitors the applications? The Support team that troubleshoots issues with the deployment? > > We should be careful not to understate or misrepresent the complex web of ?owners? that are currently able (and, for business reasons, need) to apply agents dynamically. Downplaying the complexity many organizations experience when dealing with changes to command line options (as an example) weakens the argument for changing today?s status quo. > > We also know that in many cases customers and users may not be in a position to modify startup scripts (e.g. even to add in an extra parameter) as to do so may invalidate support contracts, etc. > > Dynamically attached agents have been a ?superpower? of Java and their use has greatly benefited the ecosystem as they?ve helped service and support use cases that otherwise aren?t possible, as they helped propel Java to the forefront of the Observability tooling, and allowed many other useful libraries to be developed. > > Let?s delay flipping the default until JDK 22 to give the breadth of the ecosystem time to absorb this change. > > ?Dan > > > [0] https://mail.openjdk.org/pipermail/serviceability-dev/2023-March/047084.html > [1] https://bugs.openjdk.org/browse/JDK-8304438 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Sun Apr 30 14:19:13 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Sun, 30 Apr 2023 14:19:13 +0000 Subject: [External] : Re: JEP draft: Disallow the Dynamic Loading of Agents by Default In-Reply-To: References: Message-ID: <1D74CB9A-1040-4992-954E-AAA1430FE4F0@oracle.com> Hi Dan! > On 29 Apr 2023, at 03:30, Dan Heidinga wrote: > > Hi Ron, > > Thanks for writing up the JEP draft outlining the proposal to disallow dynamic loading of agents by default. The Red Hat Java team has continued to discuss this proposal internally and with our stakeholders. > > While there is a general agreement (or at least acceptance) with the overall direction of this proposal, we still see the concerns raised by Andrew [0] as needing to be addressed. > > So let?s start with the high-order bit: timing. > > The JEP draft states it ?intends to adopt the proposal [to disable agents by default] six years later, in 2023, for JDK 21.? We would like to see this targeted to JDK 22 instead as the change has not been widely evangelized yet and comes as a surprise to many, both to those actively developing OpenJDK and to those monitoring its development. > > We owe it to the community to give this proposal enough bake time, especially given that JDK 21 is an LTS release. Though the official position is that LTS releases are no different than any other release, the actions of JDK consumers make them special. Users will be surprised by this change when they migrate from JDK 17 to 21. If we delay till JDK 22, we give the ecosystem time to adapt to the change before the next LTS. > > Additionally, users who have tested with the -XX:-EnableDynamicAgentLoading option will have false expectations if they validated their use of jcmd to load the agent as the behaviour was not correct prior to JDK 21 [1]. > > The next concern is one you call out in the draft that ?Java's excellent serviceability has long been a source of pride for the platform.? We agree! > > Java currently has an excellent, prime position in Observability capabilities. For better or for worse, there are many Observability tools that have relied on dynamic attach to provide the necessary monitoring for workloads > > It?s important we give Java?s monitoring tools sufficient time to migrate comfortably without shocking the ecosystem by changing the default in an LTS. By delaying the change till JDK 22, we give the ecosystem 2 years to migrate and to prepare users for the change. > > Additionally, this provides the time for Java?s profiling tools to adapt as well. And for the ?ad-hoc troubleshooting? tools - like Byteman - to retrain their users. That?s a fair point. Even though the change was announced some years ago, some strong encapsulation features had a transition period where they emitted warnings before changing defaults. Since we can reasonably expect 21 to see relatively high adoption, we could take that opportunity to educate more users and only emit a warning when an agent is loaded dynamically (otherwise, since many users unfortunately skip versions, they would be equally surprised and unprepared at the next version they adopt as they would be if the default change were made in 21). Would you find that reasonable? If so, we may perhaps be able to also emit warnings on JNI use in 21, thus bringing agents, JNI, and FFM to the same baseline in 21, i.e. they would all issue warnings unless sanctioned by the application. > > Finally, while it?s easy to agree with the principle that ?the application owner is given the final say on whether to allow dynamic loading of agents?, the argument can (and should!) be made that those application owners have made that final decision by deploying the libraries and tools that use dynamic attach. A JVM command line argument is not the only way to express their consent for code to run on their system. > > For many production uses, the reality is more complicated than a single ?application owner?. Take a Kubernetes cluster for example. > > Who is the application owner when deploying to a Kubernetes cluster? The dev team that develops the application? The operations team that manages the cluster? The monitoring team that monitors the applications? The Support team that troubleshoots issues with the deployment? > > We should be careful not to understate or misrepresent the complex web of ?owners? that are currently able (and, for business reasons, need) to apply agents dynamically. Downplaying the complexity many organizations experience when dealing with changes to command line options (as an example) weakens the argument for changing today?s status quo. Right. In this case, ?owner? means any person who has been given the sufficient OS privileges to attach a dynamic agent (and who then also has sufficient privileges to stop or start the process). Because the ideal is not to disrupt tools at all but rather to prevent libraries from escalating their powers without the application?s knowledge and consent, we?ve begun to explore means other than the flag to allow a tool to load an agent at runtime. Two ideas we?ve had so far are a challenge-response mechanism that would verify there?s a person in the loop or issuing certificates to tools that would be used by the VM to verify that it is an approved tool that?s loading an agent (revoking certificates that find their way to libraries). These mechanisms are, however, complex, so they (or perhaps some other alternative) may appear only later. > > Dynamically attached agents have been a ?superpower? of Java and their use has greatly benefited the ecosystem as they?ve helped service and support use cases that otherwise aren?t possible, as they helped propel Java to the forefront of the Observability tooling, and allowed many other useful libraries to be developed. > > Let?s delay flipping the default until JDK 22 to give the breadth of the ecosystem time to absorb this change. Very well. If a warning is acceptable, we can do that in 21 and delay the default change to 22. ? Ron P.S. > We also know that in many cases customers and users may not be in a position to modify startup scripts (e.g. even to add in an extra parameter) as to do so may invalidate support contracts, etc. Could you expand more on that? Even if the default change happens in 22, it would not apply retroactively. Upgrading to a new JDK requires changing startup scripts, as does adding/upgrading libraries, which happens at least as frequently as upgrading a JDK version. How can a Java application be developed and deployed without the ability to change the command line? I can?t see how an application is expected to change its runtime version and yet not be able to change the command line? I mean, I can imagine setups where that could sometimes *happen* to work, but not a way for this to be *expected* to work. Certainly since the JRE was removed it?s been the assumption that upgrading a JDK version may require changing the command line. There are more important mechanisms than loading agents dynamically that require setting VM options, such as selecting a GC/heap configuration tailored to the application?s particular needs. Even in third-party hosting situations, the applications needs some level of control over the command line and the host will appreciate more control that allows it to select what capabilities it offers hosted applications. From mike at plan99.net Sun Apr 30 18:59:17 2023 From: mike at plan99.net (Mike Hearn) Date: Sun, 30 Apr 2023 20:59:17 +0200 Subject: [External] : Re: JEP draft: Disallow the Dynamic Loading of Agents by Default In-Reply-To: <1D74CB9A-1040-4992-954E-AAA1430FE4F0@oracle.com> References: <1D74CB9A-1040-4992-954E-AAA1430FE4F0@oracle.com> Message-ID: > we?ve begun to explore means other than the flag to allow a tool to load an agent at runtime How about restricting access to the jcmd socket. For in-VM code it can be blocked at the filesystem implementation level, and for sub-processes by using the operating system APIs to determine if the other side of the socket is part of the same process tree at connect time. This would avoid the need for new UI to re-enable existing jcmd functionality, whilst preventing code loaded into the VM from connecting back to that same VM. Only truly external tools could trigger agent loading, or modules that had been given permission to do that. That is assuming native code is restricted of course but that's a whole other kettle of fish. I don't quite understand how the plan is meant to work when it reaches that stage. JNI is so widely used and so many libraries would break that you'd either just immediately see workarounds appear, like build systems concatenating lists of flags from META-INF files, or it'd just cause a lot of chaos and upgrade rejection. It'd also have to be dynamically controllable for plugins, so then you'd also get people running their apps inside classloaders that auto-grant any request to load native code. There must be a better way? Maybe the problem can be recast as one of build-time observability? One concept I experimented with for my own build system is the notion of "control reports", a generalization of lockfiles. The build generates text files describing things you care about, and these are then checked in to vcs. There is a build mode that doesn't write the generated reports on disk, instead it verifies there's no difference and exits if there are. By checking the reports into version control and using OWNERS files + code reviews various policies can be enforced. In this context it'd work like so: the JVM would be changed to look for a flags file in the JAR containing the main class/main module as part of its startup. JVM flags can thus be shipped as part of the app, formalizing an already existing convention that's today implemented with shell scripts. Build systems can generate this flag file from their existing lists of JVM flags, and/or compute it automatically by merging flag files found in any library JARs. For people who don't care about deprivileging libs (prototyping, learners, people who only use in-house code etc) this will keep things working as it does today. For people who wish to use this new security feature they can review the generated flag file and check it in. Now if they add a dependency on a library that needs to use panama, jni, an agent, opened packages etc, this will become visible as added lines in the flag file, can be pushed back on when the commit is reviewed, and by placing an OWNERS file in the directory containing the report tech leads can allow delegates to add dependencies without being able to change JVM flags. From ron.pressler at oracle.com Sun Apr 30 22:24:13 2023 From: ron.pressler at oracle.com (Ron Pressler) Date: Sun, 30 Apr 2023 22:24:13 +0000 Subject: [External] : Re: JEP draft: Disallow the Dynamic Loading of Agents by Default In-Reply-To: References: <1D74CB9A-1040-4992-954E-AAA1430FE4F0@oracle.com> Message-ID: <41BFCE0A-AE21-468B-8CF0-57710034845C@oracle.com> Hi Mike! On 30 Apr 2023, at 19:59, Mike Hearn > wrote: we?ve begun to explore means other than the flag to allow a tool to load an agent at runtime How about restricting access to the jcmd socket. For in-VM code it can be blocked at the filesystem implementation level, and for sub-processes by using the operating system APIs to determine if the other side of the socket is part of the same process tree at connect time. This would avoid the need for new UI to re-enable existing jcmd functionality, whilst preventing code loaded into the VM from connecting back to that same VM. Only truly external tools could trigger agent loading, or modules that had been given permission to do that. Determining the process on the other side and/or maintaining the integrity of the process tree is not easy on all OSes. That is assuming native code is restricted of course but that's a whole other kettle of fish. I don't quite understand how the plan is meant to work when it reaches that stage. JNI is so widely used and so many libraries would break that you'd either just immediately see workarounds appear, like build systems concatenating lists of flags from META-INF files, or it'd just cause a lot of chaos and upgrade rejection. It'd also have to be dynamically controllable for plugins, so then you'd also get people running their apps inside classloaders that auto-grant any request to load native code. No libraries will break and no workarounds would be possible once all loopholes are closed. All you?d need to do is grant the module permission to load/use native libraries, be it through JNI or FFM. Build tools may do whatever they want, but it?s important to remember that the low-integrity free-for-all worked more-or-less only while Java was relatively stagnant. Once the platform started evolving more rapidly we saw many applications break in the Java 8 -> 9 upgrade due to deep dependencies that relied on JDK internals in the days before strong encapsulation. There must be a better way? Before thinking about other ways, I think it?s best to first acknowledge the problem, and that is that we wish for two fundamentally contradictory things: On the one hand, we want it to be easy to break other people?s code?s encapsulation when we need to, and on the other we want features that fundamentally depend on encapsulation not being broken, such as smooth upgrades, robust security mechanisms, and future Leyden features. Both may be good, but they are in conflict. Because we can't to have our invariants and break them too, someone must choose between one and the other. But I also don?t think it?s a very complicated choice. The view of the Java ecosystem as a hotbed of encapsulation-breaking is gradually becoming outdated. Much of the necessity to break encapsulation came about due to the platform?s stagnation in the JDK 6-8 timeframe. While the ability to break encapsulation is being restricted, the problems that required it in the first place are also being addressed. The number of uses that require breaking strong encapsulation is shrinking. Maybe the problem can be recast as one of build-time observability? One concept I experimented with for my own build system is the notion of "control reports", a generalization of lockfiles. The build generates text files describing things you care about, and these are then checked in to vcs. There is a build mode that doesn't write the generated reports on disk, instead it verifies there's no difference and exits if there are. By checking the reports into version control and using OWNERS files + code reviews various policies can be enforced. In this context it'd work like so: the JVM would be changed to look for a flags file in the JAR containing the main class/main module as part of its startup. JVM flags can thus be shipped as part of the app, formalizing an already existing convention that's today implemented with shell scripts. Build systems can generate this flag file from their existing lists of JVM flags, and/or compute it automatically by merging flag files found in any library JARs. For people who don't care about deprivileging libs (prototyping, learners, people who only use in-house code etc) this will keep things working as it does today. A main JAR, when used, is already given control over some command-line flags via its manifest, including strong encapsulation controls. That?s fine, because it?s controlled by the application, not libraries. For people who wish to use this new security feature It?s not a security feature. It?s an integrity feature. they can review the generated flag file and check it in. Now if they add a dependency on a library that needs to use panama, jni, an agent, opened packages etc, this will become visible as added lines in the flag file, can be pushed back on when the commit is reviewed, and by placing an OWNERS file in the directory containing the report tech leads can allow delegates to add dependencies without being able to change JVM flags. I think what you?re describing is an automated generation of what the informational JEP calls the codebase map (i.e. the command-line) based on what libraries want. Such automated permission-management could perhaps be appropriate for a security mechanism for mobile phone apps ? requesting access to files, for example, is quite common ? but not so much for integrity, as the need to break encapsulation is supposed to be abnormal and rare; it is certainly discouraged, and we believe that it will become less and less necessary (currently, serialization is probably the biggest issue, but we?re getting closer to a point where it won?t be: https://openjdk.org/projects/amber/design-notes/towards-better-serialization). Of course, tools outside the JDK can offer such a mechanism, but if the number of libraries requiring bypassing of encapsulation continues to decline that may be a rather elaborate solution to a rather small problem. Personally, I think it might be best to see where the ecosystem is in a few years. ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From ecki at zusammenkunft.net Sun Apr 30 23:38:23 2023 From: ecki at zusammenkunft.net (Bernd) Date: Mon, 1 May 2023 01:38:23 +0200 Subject: [External] : Re: JEP draft: Disallow the Dynamic Loading of Agents by Default In-Reply-To: <41BFCE0A-AE21-468B-8CF0-57710034845C@oracle.com> References: <1D74CB9A-1040-4992-954E-AAA1430FE4F0@oracle.com> , <41BFCE0A-AE21-468B-8CF0-57710034845C@oracle.com> Message-ID: <97DB71E4-9930-3D40-8D2C-7A89C25C700A@hxcore.ol> An HTML attachment was scrubbed... URL: