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 t