Re: RFR: 8257967: JFR: Events for loaded agents [v15]

2023-03-31 Thread Serguei Spitsyn
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 ag

Re: RFR: 8257967: JFR: Events for loaded agents [v10]

2023-03-31 Thread Serguei Spitsyn
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, no

Re: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v5]

2023-03-31 Thread Naoto Sato
On Fri, 17 Mar 2023 22:27:48 GMT, Justin Lu wrote: >> This PR converts Unicode sequences to UTF-8 native in .properties file. >> (Excluding the Unicode space and tab sequence). The conversion was done >> using native2ascii. >> >> In addition, the build logic is adjusted to support reading in t

Re: RFR: 8291555: Implement alternative fast-locking scheme [v47]

2023-03-31 Thread Dean Long
On Fri, 31 Mar 2023 07:25:48 GMT, Thomas Stuefe wrote: >> Roman Kennke has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Use int instead of size_t for cached offsets, to match the uncached offset >> type and avoid build failures > > src/h

Re: RFR: 8291555: Implement alternative fast-locking scheme [v49]

2023-03-31 Thread Daniel D . Daugherty
On Fri, 31 Mar 2023 19:39:03 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

Re: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native [v5]

2023-03-31 Thread Justin Lu
On Fri, 17 Mar 2023 22:27:48 GMT, Justin Lu wrote: >> This PR converts Unicode sequences to UTF-8 native in .properties file. >> (Excluding the Unicode space and tab sequence). The conversion was done >> using native2ascii. >> >> In addition, the build logic is adjusted to support reading in t

Re: RFR: 8291555: Implement alternative fast-locking scheme [v49]

2023-03-31 Thread Daniel D . Daugherty
On Fri, 31 Mar 2023 19:39:03 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

Re: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324 [v15]

2023-03-31 Thread Serguei Spitsyn
> 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

Re: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324 [v14]

2023-03-31 Thread Serguei Spitsyn
On Fri, 31 Mar 2023 06:52:18 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

Re: RFR: 8291555: Implement alternative fast-locking scheme [v49]

2023-03-31 Thread Daniel D . Daugherty
On Fri, 31 Mar 2023 19:39:03 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

Re: RFR: 8305341: Alignment outside of HotSpot should be enforced by alignas instead of compiler specific attributes

2023-03-31 Thread Chris Plummer
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 have any comments on this change in general (it's not something I've dealt with in the past),

Re: RFR: 8305237: CompilerDirectives DCmds permissions correction

2023-03-31 Thread Chris Plummer
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 > requir

Re: RFR: 8291555: Implement alternative fast-locking scheme [v49]

2023-03-31 Thread Roman Kennke
> 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 Li

Re: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324 [v14]

2023-03-31 Thread Chris Plummer
On Fri, 31 Mar 2023 06:52:18 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

Re: RFR: 8291555: Implement alternative fast-locking scheme [v48]

2023-03-31 Thread Thomas Stuefe
On Fri, 31 Mar 2023 13:54: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

Re: RFR: 8291555: Implement alternative fast-locking scheme [v48]

2023-03-31 Thread Thomas Stuefe
On Fri, 31 Mar 2023 15:24:07 GMT, Thomas Stuefe wrote: >> Roman Kennke has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Merge remote-tracking branch 'origin/JDK-8291555-v2' into JDK-8291555-v2 >> - Check underflow, top-of-stack and mar

Re: RFR: 8301995: Move invokedynamic resolution information out of ConstantPoolCacheEntry [v16]

2023-03-31 Thread Matias Saavedra Silva
On Tue, 28 Mar 2023 19:50:36 GMT, Matias Saavedra Silva wrote: >> The current structure used to store the resolution information for >> invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its >> ambigious fields f1 and f2. This structure can hold information for fields, >>

Re: RFR: 8291555: Implement alternative fast-locking scheme [v48]

2023-03-31 Thread Thomas Stuefe
On Fri, 31 Mar 2023 13:54: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

Re: RFR: 8301995: Move invokedynamic resolution information out of ConstantPoolCacheEntry [v16]

2023-03-31 Thread Doug Simon
On Tue, 28 Mar 2023 19:50:36 GMT, Matias Saavedra Silva wrote: >> The current structure used to store the resolution information for >> invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its >> ambigious fields f1 and f2. This structure can hold information for fields, >>

Re: RFR: 8301995: Move invokedynamic resolution information out of ConstantPoolCacheEntry [v16]

2023-03-31 Thread Thomas Stuefe
On Tue, 28 Mar 2023 19:50:36 GMT, Matias Saavedra Silva wrote: >> The current structure used to store the resolution information for >> invokedynamic, ConstantPoolCacheEntry, is difficult to interpret due to its >> ambigious fields f1 and f2. This structure can hold information for fields, >>

Re: RFR: 8291555: Implement alternative fast-locking scheme [v48]

2023-03-31 Thread Roman Kennke
> 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 Li

Re: RFR: 8257967: JFR: Events for loaded agents [v14]

2023-03-31 Thread Markus Grönlund
On Fri, 31 Mar 2023 03:05:31 GMT, David Holmes wrote: >> Markus Grönlund has updated the pull request incrementally with one >> additional commit since the last revision: >> >> restore misssing frees > > src/hotspot/share/prims/agent.cpp line 533: > >> 531: if (thread->is_pending_jni_exc

Re: RFR: 8257967: JFR: Events for loaded agents [v15]

2023-03-31 Thread Markus Grönlund
> 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 comm

Re: RFR: 8304919: Implementation of Virtual Threads [v5]

2023-03-31 Thread Alan Bateman
> 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 chan

Re: RFR: 8305237: CompilerDirectives DCmds permissions correction

2023-03-31 Thread Kevin Walls
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 > requir

RFR: 8305237: CompilerDirectives DCmds permissions correction

2023-03-31 Thread Kevin Walls
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/c

Re: RFR: 8291555: Implement alternative fast-locking scheme [v47]

2023-03-31 Thread Thomas Stuefe
On Fri, 31 Mar 2023 06:06: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