Re: RFR: 8315149: Add hsperf counters for CPU time of internal GC threads [v47]

2023-11-29 Thread Stefan Johansson
On Thu, 23 Nov 2023 13:46:54 GMT, Albert Mingkun Yang wrote: >> Jonathan Joo has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Cleanup and address comments > > src/hotspot/share/runtime/cpuTimeCounters.cpp line 119: > >> 117: if (CPUT

Re: RFR: 8315149: Add hsperf counters for CPU time of internal GC threads [v48]

2023-11-29 Thread Stefan Johansson
On Tue, 28 Nov 2023 02:22:45 GMT, Jonathan Joo wrote: >> 8315149: Add hsperf counters for CPU time of internal GC threads > > Jonathan Joo has updated the pull request incrementally with two additional > commits since the last revision: > > - Fix namespace issues (2) > >Co-authored-by:

Re: RFR: 8320515: assert(monitor->object_peek() != nullptr) failed: Owned monitors should not have a dead object [v7]

2023-11-29 Thread Stefan Karlsson
On Mon, 27 Nov 2023 19:33:09 GMT, Serguei Spitsyn wrote: > It will be completely safe to run mach5 tiers 1-4, tier5-svc and 6. In this > particular case, the tier6 can be not necessary. It has some important > -Xcomp/interp_only_mode related testing. I've run the suggested testing and it passe

Re: RFR: 8318706: Implement JEP 423: Region Pinning for G1 [v10]

2023-11-29 Thread Thomas Schatzl
On Fri, 3 Nov 2023 14:14:50 GMT, Albert Mingkun Yang wrote: >> Thomas Schatzl has updated the pull request incrementally with one >> additional commit since the last revision: >> >> typos > > Marked as reviewed by ayang (Reviewer). Thanks @albertnetymk @kstefanj @walulyai for your reviews! G

Integrated: 8318706: Implement JEP 423: Region Pinning for G1

2023-11-29 Thread Thomas Schatzl
On Tue, 24 Oct 2023 09:56:57 GMT, Thomas Schatzl wrote: > The JEP covers the idea very well, so I'm only covering some implementation > details here: > > * regions get a "pin count" (reference count). As long as it is non-zero, we > conservatively never reclaim that region even if there is no

Re: RFR: 8320652: ThreadInfo.isInNative needs to be updated to say what executing native code means [v2]

2023-11-29 Thread Alan Bateman
On Wed, 29 Nov 2023 06:44:58 GMT, David Holmes wrote: > JDWP filters its own internal threads out of any thread lists it returns, so > this may be a case of using two different API's with different views of the > set of threads running. I think the issue that Bernd is running into is a long st

Re: RFR: 8313816: Accessing jmethodID might lead to spurious crashes [v11]

2023-11-29 Thread Jaroslav Bachorik
> Please, review this fix for a corner case handling of `jmethodID` values. > > The issue is related to the interplay between `jmethodID` values and method > redefinitions. Each `jmethodID` value is effectively a pointer to a `Method` > instance. Once that method gets redefined, the `jmethodID`

Re: RFR: 8313816: Accessing jmethodID might lead to spurious crashes [v10]

2023-11-29 Thread Jaroslav Bachorik
On Tue, 28 Nov 2023 21:30:16 GMT, Coleen Phillimore wrote: >> Jaroslav Bachorik has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Remove unnecessary assert > > src/hotspot/share/oops/instanceKlass.cpp line 4236: > >> 4234: if (method

Re: RFR: 8313816: Accessing jmethodID might lead to spurious crashes [v10]

2023-11-29 Thread Coleen Phillimore
On Wed, 29 Nov 2023 11:45:53 GMT, Jaroslav Bachorik wrote: >> src/hotspot/share/oops/instanceKlass.cpp line 4236: >> >>> 4234: if (method != nullptr) { >>> 4235: method->clear_jmethod_id(); >>> 4236: } >> >> This loops through the methods in the InstanceKlass that was a previous

Re: RFR: 8313816: Accessing jmethodID might lead to spurious crashes [v10]

2023-11-29 Thread Jaroslav Bachorik
On Wed, 29 Nov 2023 13:29:18 GMT, Coleen Phillimore wrote: >> Restricting to obsolete methods sounds like a good idea. > > Can you confirm my observation above, that EMCP jmethodIDs are replaced? I > haven't looked at this code in a while. Thanks. I am going to take a look. - PR

Re: RFR: 8313816: Accessing jmethodID might lead to spurious crashes [v10]

2023-11-29 Thread Jaroslav Bachorik
On Wed, 29 Nov 2023 14:57:34 GMT, Jaroslav Bachorik wrote: >> Can you confirm my observation above, that EMCP jmethodIDs are replaced? I >> haven't looked at this code in a while. Thanks. > > I am going to take a look. Ok, I found it. The reason for the jmethodID not being cleaned out is thi

Re: RFR: 8315149: Add hsperf counters for CPU time of internal GC threads [v48]

2023-11-29 Thread Albert Mingkun Yang
On Wed, 29 Nov 2023 08:24:22 GMT, Stefan Johansson wrote: >> Jonathan Joo has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Fix namespace issues (2) >> >>Co-authored-by: Stefan Johansson >> <54407259+kstef...@users.noreply.githu

Re: RFR: 8315149: Add hsperf counters for CPU time of internal GC threads [v47]

2023-11-29 Thread Albert Mingkun Yang
On Wed, 29 Nov 2023 08:31:37 GMT, Stefan Johansson wrote: >> src/hotspot/share/runtime/cpuTimeCounters.cpp line 119: >> >>> 117: if (CPUTimeGroups::is_gc_counter(_name)) { >>> 118: instance->inc_gc_total_cpu_time(net_cpu_time); >>> 119: } >> >> I feel much of this is on the wrong

Re: RFR: 8319935: Ensure only one JvmtiThreadState is created for one JavaThread associated with attached native thread [v2]

2023-11-29 Thread Jiangli Zhou
On Thu, 16 Nov 2023 21:58:17 GMT, Man Cao wrote: >> Jiangli Zhou has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Don't try to setup_jvmti_thread_state for obj allocation sampling if the >> current thread is attaching from native and is

Re: RFR: 8319935: Ensure only one JvmtiThreadState is created for one JavaThread associated with attached native thread [v5]

2023-11-29 Thread Jiangli Zhou
On Tue, 28 Nov 2023 21:28:31 GMT, Jiangli Zhou wrote: >> This fix looks good to me, so approved now. >> I assume it is for 22. Is it correct? > >> This fix looks good to me, so approved now. I assume it is for 22. Is it >> correct? > > Thanks for the careful review, @sspitsyn! The fix is for 22

Integrated: 8319935: Ensure only one JvmtiThreadState is created for one JavaThread associated with attached native thread

2023-11-29 Thread Jiangli Zhou
On Mon, 13 Nov 2023 21:52:22 GMT, Jiangli Zhou wrote: > Please review JvmtiThreadState::state_for_while_locked change to handle the > state->get_thread_oop() null case. Please see > https://bugs.openjdk.org/browse/JDK-8319935 for details. This pull request has now been integrated. Changeset:

Re: RFR: 8320515: assert(monitor->object_peek() != nullptr) failed: Owned monitors should not have a dead object [v9]

2023-11-29 Thread Daniel D . Daugherty
On Wed, 29 Nov 2023 06:38:51 GMT, Stefan Karlsson wrote: >> In the rewrites made for: >> [JDK-8318757](https://bugs.openjdk.org/browse/JDK-8318757) `VM_ThreadDump >> asserts in interleaved ObjectMonitor::deflate_monitor calls` >> >> I removed the filtering of *owned ObjectMonitors with dead obj

Re: RFR: 8320515: assert(monitor->object_peek() != nullptr) failed: Owned monitors should not have a dead object [v8]

2023-11-29 Thread Stefan Karlsson
On Tue, 28 Nov 2023 18:38:07 GMT, Daniel D. Daugherty wrote: >> Stefan Karlsson has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Fix indentation > > I'll re-review again once the last set of comments are addressed. Thanks @dcubed-ojdk!

Re: RFR: 8313816: Accessing jmethodID might lead to spurious crashes [v10]

2023-11-29 Thread Coleen Phillimore
On Wed, 29 Nov 2023 15:14:59 GMT, Jaroslav Bachorik wrote: >> I am going to take a look. > > Ok, I found it. > The reason for the jmethodID not being cleaned out is this assignment of a > new jmethodID to obsolete methods - > https://github.com/openjdk/jdk/blob/a2c5f1fc914ef5c28d044b75598f895c

Re: RFR: 8313816: Accessing jmethodID might lead to spurious crashes [v11]

2023-11-29 Thread Jaroslav Bachorik
On Wed, 29 Nov 2023 11:49:31 GMT, Jaroslav Bachorik wrote: >> Please, review this fix for a corner case handling of `jmethodID` values. >> >> The issue is related to the interplay between `jmethodID` values and method >> redefinitions. Each `jmethodID` value is effectively a pointer to a `Meth

Integrated: 8313816: Accessing jmethodID might lead to spurious crashes

2023-11-29 Thread Jaroslav Bachorik
On Tue, 14 Nov 2023 17:56:09 GMT, Jaroslav Bachorik wrote: > Please, review this fix for a corner case handling of `jmethodID` values. > > The issue is related to the interplay between `jmethodID` values and method > redefinitions. Each `jmethodID` value is effectively a pointer to a `Method`

Re: RFR: 8319935: Ensure only one JvmtiThreadState is created for one JavaThread associated with attached native thread [v3]

2023-11-29 Thread Serguei Spitsyn
On Tue, 28 Nov 2023 22:40:10 GMT, Serguei Spitsyn wrote: >> @jianglizhou Thank you for filing the sub-task. You have already seen some >> crashes. Even though you do not have a standalone test case, it is still >> valuable if you describe a test scenario (at least, surfacely) which helped >> t

Integrated: JDK-8318626: GetClassFields does not filter out ConstantPool.constantPoolOop field

2023-11-29 Thread Alex Menkov
On Tue, 24 Oct 2023 00:46:54 GMT, Alex Menkov wrote: > FilteredFieldStream is intended to filter out some fields which does not > represent valid java objects. > Currently the only filtered field is "constantPoolOop" from > jdk.internal.reflect.ConstantPool class. > The change fixes FilteredFie

Re: RFR: 8299426: Heap dump does not contain virtual Thread stack references

2023-11-29 Thread Chris Plummer
On Wed, 29 Nov 2023 20:29:40 GMT, Chris Plummer wrote: >> The change impelements dumping of unmounted virtual threads data (stack >> traces and stack references). >> Unmounted vthreads can be detected only by iterating over the heap, but >> hprof stack trace records (HPROF_FRAME/HPROF_TRACE) sh

Re: RFR: 8299426: Heap dump does not contain virtual Thread stack references

2023-11-29 Thread Chris Plummer
On Tue, 14 Nov 2023 21:54:06 GMT, Alex Menkov wrote: > The change impelements dumping of unmounted virtual threads data (stack > traces and stack references). > Unmounted vthreads can be detected only by iterating over the heap, but hprof > stack trace records (HPROF_FRAME/HPROF_TRACE) should b

Re: RFR: 8308614: Enabling JVMTI ClassLoad event slows down vthread creation by factor 10 [v3]

2023-11-29 Thread Daniel D . Daugherty
On Fri, 17 Nov 2023 20:29:11 GMT, Serguei Spitsyn wrote: >> This is a fix of a performance/scalability related issue. The >> `JvmtiThreadState` objects for virtual thread filtered events enabled >> globally are created eagerly because it is needed when the >> `interp_only_mode` is enabled. Oth

Re: RFR: 8320935: Move CDS config initialization code to cdsConfig.cpp

2023-11-29 Thread Calvin Cheung
On Tue, 28 Nov 2023 23:24:53 GMT, Ioi Lam wrote: > This is a simple clean up that moves the code for initializing the CDS config > states from arguments.cpp to cdsConfig.cpp > > I renamed a few functions, but otherwise the code is unchanged. > > - `get_default_shared_archive_path()` -> `defaul

Re: RFR: 8299426: Heap dump does not contain virtual Thread stack references

2023-11-29 Thread Serguei Spitsyn
On Wed, 29 Nov 2023 20:31:50 GMT, Chris Plummer wrote: >> src/hotspot/share/services/heapDumper.cpp line 2026: >> >>> 2024: size_t buf_size = strlen(base_path) >>> 2025: + 2 // ".p" >>> 2026: + 1 + (seq / 10)// number >> >> Is this

Re: RFR: 8299426: Heap dump does not contain virtual Thread stack references

2023-11-29 Thread Serguei Spitsyn
On Wed, 29 Nov 2023 20:51:02 GMT, Chris Plummer wrote: >> The change impelements dumping of unmounted virtual threads data (stack >> traces and stack references). >> Unmounted vthreads can be detected only by iterating over the heap, but >> hprof stack trace records (HPROF_FRAME/HPROF_TRACE) sh

Re: RFR: 8299426: Heap dump does not contain virtual Thread stack references

2023-11-29 Thread Serguei Spitsyn
On Tue, 14 Nov 2023 21:54:06 GMT, Alex Menkov wrote: > The change impelements dumping of unmounted virtual threads data (stack > traces and stack references). > Unmounted vthreads can be detected only by iterating over the heap, but hprof > stack trace records (HPROF_FRAME/HPROF_TRACE) should b

Re: RFR: 8299426: Heap dump does not contain virtual Thread stack references

2023-11-29 Thread Serguei Spitsyn
On Tue, 14 Nov 2023 21:54:06 GMT, Alex Menkov wrote: > The change impelements dumping of unmounted virtual threads data (stack > traces and stack references). > Unmounted vthreads can be detected only by iterating over the heap, but hprof > stack trace records (HPROF_FRAME/HPROF_TRACE) should b

Re: RFR: 8319935: Ensure only one JvmtiThreadState is created for one JavaThread associated with attached native thread [v5]

2023-11-29 Thread Daniel D . Daugherty
On Wed, 22 Nov 2023 22:40:20 GMT, Jiangli Zhou wrote: >> Please review JvmtiThreadState::state_for_while_locked change to handle the >> state->get_thread_oop() null case. Please see >> https://bugs.openjdk.org/browse/JDK-8319935 for details. > > Jiangli Zhou has updated the pull request increme

Re: RFR: 8320239: add dynamic switch for JvmtiVTMSTransitionDisabler sync protocol [v2]

2023-11-29 Thread Serguei Spitsyn
On Fri, 17 Nov 2023 10:30:59 GMT, Serguei Spitsyn wrote: >> This is an update for a performance/scalability enhancement. >> >> The `JvmtiVTMSTransitionDisabler`sync protocol is on a performance critical >> path of the virtual threads mount state transitions (VTMS transitions). It >> has a noti

Re: RFR: 8315149: Add hsperf counters for CPU time of internal GC threads [v47]

2023-11-29 Thread Jonathan Joo
On Thu, 23 Nov 2023 12:43:00 GMT, Albert Mingkun Yang wrote: >> Jonathan Joo has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Cleanup and address comments > > src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2433: > >> 2431: } >> 2432:

Re: RFR: 8299426: Heap dump does not contain virtual Thread stack references [v2]

2023-11-29 Thread Alex Menkov
> The change impelements dumping of unmounted virtual threads data (stack > traces and stack references). > Unmounted vthreads can be detected only by iterating over the heap, but hprof > stack trace records (HPROF_FRAME/HPROF_TRACE) should be written before > HPROF_HEAP_DUMP/HPROF_HEAP_DUMP_SEG

Re: RFR: 8299426: Heap dump does not contain virtual Thread stack references [v2]

2023-11-29 Thread Alex Menkov
On Wed, 29 Nov 2023 22:38:18 GMT, Serguei Spitsyn wrote: >> Alex Menkov has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - feedback >> - prepare_parallel_dum > > src/hotspot/share/services/heapDumper.cpp line 1947: > >> 1945: _comp

Re: RFR: 8299426: Heap dump does not contain virtual Thread stack references [v2]

2023-11-29 Thread Alex Menkov
On Wed, 29 Nov 2023 20:14:07 GMT, Chris Plummer wrote: >> Alex Menkov has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - feedback >> - prepare_parallel_dum > > src/hotspot/share/services/heapDumper.cpp line 1886: > >> 1884: }; >> 1885:

Re: RFR: 8299426: Heap dump does not contain virtual Thread stack references [v2]

2023-11-29 Thread Alex Menkov
On Wed, 29 Nov 2023 22:16:53 GMT, Serguei Spitsyn wrote: >> I think the easiest solution is probably just coming up with some reasonable >> max sequence number and then just assuming that you will need enough chars >> for it. But if you want to actually compute it, there are a few solutions, >

Re: RFR: 8320239: add dynamic switch for JvmtiVTMSTransitionDisabler sync protocol [v2]

2023-11-29 Thread Patricio Chilano Mateo
On Fri, 17 Nov 2023 10:30:59 GMT, Serguei Spitsyn wrote: >> This is an update for a performance/scalability enhancement. >> >> The `JvmtiVTMSTransitionDisabler`sync protocol is on a performance critical >> path of the virtual threads mount state transitions (VTMS transitions). It >> has a noti

Re: RFR: 8320239: add dynamic switch for JvmtiVTMSTransitionDisabler sync protocol [v2]

2023-11-29 Thread Alex Menkov
On Fri, 17 Nov 2023 10:30:59 GMT, Serguei Spitsyn wrote: >> This is an update for a performance/scalability enhancement. >> >> The `JvmtiVTMSTransitionDisabler`sync protocol is on a performance critical >> path of the virtual threads mount state transitions (VTMS transitions). It >> has a noti

Re: RFR: 8299426: Heap dump does not contain virtual Thread stack references [v2]

2023-11-29 Thread Serguei Spitsyn
On Thu, 30 Nov 2023 00:26:25 GMT, Alex Menkov wrote: >> The change impelements dumping of unmounted virtual threads data (stack >> traces and stack references). >> Unmounted vthreads can be detected only by iterating over the heap, but >> hprof stack trace records (HPROF_FRAME/HPROF_TRACE) shou

Re: RFR: 8308614: Enabling JVMTI ClassLoad event slows down vthread creation by factor 10 [v3]

2023-11-29 Thread Serguei Spitsyn
On Wed, 29 Nov 2023 21:05:31 GMT, Daniel D. Daugherty wrote: >> Serguei Spitsyn has updated the pull request incrementally with one >> additional commit since the last revision: >> >> review: add comment for new ThreadsListHandle use > > I'm going to resurrect the failing guarantee() code an

Re: RFR: 8315149: Add hsperf counters for CPU time of internal GC threads [v49]

2023-11-29 Thread Jonathan Joo
> 8315149: Add hsperf counters for CPU time of internal GC threads Jonathan Joo has updated the pull request incrementally with one additional commit since the last revision: Change APIs to be all-static, address other comments - Changes: - all: https://git.openjdk.org/jdk/pull

Re: RFR: 8315149: Add hsperf counters for CPU time of internal GC threads [v47]

2023-11-29 Thread Jonathan Joo
On Wed, 29 Nov 2023 15:23:55 GMT, Albert Mingkun Yang wrote: >> We could add a new closure just used by GC that 's a sub-class of >> `ThreadTotalCPUTimeClosure` and just adds this to the constructor: >> >> instance->inc_gc_total_cpu_time(net_cpu_time); >> >> >> That way we could get rid of `

Re: RFR: 8315149: Add hsperf counters for CPU time of internal GC threads [v50]

2023-11-29 Thread Jonathan Joo
> 8315149: Add hsperf counters for CPU time of internal GC threads Jonathan Joo has updated the pull request incrementally with one additional commit since the last revision: remove whitespace - Changes: - all: https://git.openjdk.org/jdk/pull/15082/files - new: https://git.o

Re: RFR: 8315149: Add hsperf counters for CPU time of internal GC threads [v51]

2023-11-29 Thread Jonathan Joo
> 8315149: Add hsperf counters for CPU time of internal GC threads Jonathan Joo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 56 commits: - Merge branch 'openjdk:master' into master - remove whitespace - Change APIs to be all-sta

Re: RFR: 8315149: Add hsperf counters for CPU time of internal GC threads [v52]

2023-11-29 Thread Jonathan Joo
> 8315149: Add hsperf counters for CPU time of internal GC threads Jonathan Joo has updated the pull request incrementally with one additional commit since the last revision: fix whitespace again - Changes: - all: https://git.openjdk.org/jdk/pull/15082/files - new: https://gi

Re: RFR: 8308614: Enabling JVMTI ClassLoad event slows down vthread creation by factor 10 [v4]

2023-11-29 Thread Serguei Spitsyn
> This is a fix of a performance/scalability related issue. The > `JvmtiThreadState` objects for virtual thread filtered events enabled > globally are created eagerly because it is needed when the `interp_only_mode` > is enabled. Otherwise, some events which are generated in `interp_only_mode`

Re: RFR: 8315149: Add hsperf counters for CPU time of internal GC threads [v48]

2023-11-29 Thread Jonathan Joo
On Wed, 29 Nov 2023 15:24:52 GMT, Albert Mingkun Yang wrote: >> src/hotspot/share/runtime/cpuTimeCounters.cpp line 91: >> >>> 89: } while (old_value != fetched_value); >>> 90: get_counter(CPUTimeGroups::CPUTimeType::gc_total)->inc(fetched_value); >>> 91: } >> >> Why do we have to do this pu

Re: RFR: 8314029: Add file name parameter to Compiler.perfmap [v5]

2023-11-29 Thread David Holmes
On Tue, 28 Nov 2023 23:25:27 GMT, Yi-Fan Tsai wrote: >> `jcmd Compiler.perfmap` uses the hard-coded file name for a perf map: >> `/tmp/perf-%d.map`. This change adds an optional argument for specifying a >> file name. >> >> `jcmd PID help Compiler.perfmap` shows the following usage. >> >> >>

Re: RFR: 8315149: Add hsperf counters for CPU time of internal GC threads [v53]

2023-11-29 Thread Jonathan Joo
> 8315149: Add hsperf counters for CPU time of internal GC threads Jonathan Joo has updated the pull request incrementally with one additional commit since the last revision: Add missing include - Changes: - all: https://git.openjdk.org/jdk/pull/15082/files - new: https://git

RFR: 8320860: add-opens/add-exports require '=' in JAVA_TOOL_OPTIONS

2023-11-29 Thread David Holmes
Please review this simple clarification to the JVM TI spec regarding use of `JAVA_TOOL_OPTIONS` in regards to module options and their format. I do not believe this clarification needs a CSR request. Thanks. - Commit messages: - 8320860: add-opens/add-exports require '=' in JAVA_T

Re: RFR: 8299426: Heap dump does not contain virtual Thread stack references [v2]

2023-11-29 Thread Chris Plummer
On Wed, 29 Nov 2023 22:22:09 GMT, Serguei Spitsyn wrote: > There is a check for virtual thread liveness which has to be good enough in > general: > > ``` > 1617 static bool should_dump_vthread(oop vt) { > 1618 return java_lang_VirtualThread::state(vt) != > java_lang_VirtualThread::NEW >

Re: RFR: 8313816: Accessing jmethodID might lead to spurious crashes [v11]

2023-11-29 Thread David Holmes
On Wed, 29 Nov 2023 17:27:30 GMT, Jaroslav Bachorik wrote: >> Jaroslav Bachorik has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Restrict cleanup to obsolete methods only > > Thanks everyone involved in reviewing this PR! You were awesom

Re: RFR: 8315149: Add hsperf counters for CPU time of internal GC threads [v48]

2023-11-29 Thread Albert Mingkun Yang
On Thu, 30 Nov 2023 02:39:39 GMT, Jonathan Joo wrote: >> This two-step update does seem unnecessary, IMO. > > I agree that in the case that multiple closures are not active at the same > time, we wouldn't have to implement it in this way. However, isn't it > possible to have multiple closures a

Re: RFR: 8320239: add dynamic switch for JvmtiVTMSTransitionDisabler sync protocol [v3]

2023-11-29 Thread Serguei Spitsyn
> This is an update for a performance/scalability enhancement. > > The `JvmtiVTMSTransitionDisabler`sync protocol is on a performance critical > path of the virtual threads mount state transitions (VTMS transitions). It > has a noticeable performance overhead (about 10%) which contributes to the

Re: RFR: 8320515: assert(monitor->object_peek() != nullptr) failed: Owned monitors should not have a dead object [v9]

2023-11-29 Thread Serguei Spitsyn
On Wed, 29 Nov 2023 06:38:51 GMT, Stefan Karlsson wrote: >> In the rewrites made for: >> [JDK-8318757](https://bugs.openjdk.org/browse/JDK-8318757) `VM_ThreadDump >> asserts in interleaved ObjectMonitor::deflate_monitor calls` >> >> I removed the filtering of *owned ObjectMonitors with dead obj

Re: RFR: 8320239: add dynamic switch for JvmtiVTMSTransitionDisabler sync protocol [v2]

2023-11-29 Thread Serguei Spitsyn
On Thu, 30 Nov 2023 00:14:34 GMT, Patricio Chilano Mateo wrote: >> Serguei Spitsyn has updated the pull request incrementally with one >> additional commit since the last revision: >> >> review: make new fields volatile, use Atomic for access/update > > src/hotspot/share/prims/jvmtiThreadSta