8293252: Shenandoah: ThreadMXBean synchronizer tests crash with aggressive heuristics #10268

ashu-mehra · 2022-09-14T16:04:03Z

Please review the fix for the assertion failure when running ThreadMXBean synchronizer code in fastdebug mode.

Please note that the assertion failure happens in regular (satb) mode as well, not just in iu mode.

At the point of assertion failure, the JVM is at a safepoint as the VMThread is executing VM_ThreadDump operation and the GC worker threads are paused after the mark phase.
Assertion happened when the VMThread performs NativeAccess<>::oop_store() (as part of creating an OopHandle) on an object which has been marked and is in the collection set. But the failing assertion in oop_store_not_in_heap() expects the oop is not in the collection set.

The assertion is conditional on the statement value != NULL && !ShenandoahHeap::heap()->cancelled_gc()

	shenandoah_assert_not_in_cset_if(addr, value, value != NULL && !ShenandoahHeap::heap()->cancelled_gc());

But it looks like it is missing another important condition - the GC should be in marking phase.
i.e. the assertion is valid only if it is protected by ShenandoahHeap::heap()->is_concurrent_mark_in_progress().
So the correct assertion should be:

	shenandoah_assert_not_in_cset_if(addr, value, value != NULL && !ShenandoahHeap::heap()->cancelled_gc() && ShenandoahHeap::heap()->is_concurrent_mark_in_progress());

In fact this assertion is already present in one of its caller (`oop_store_in_heap()1) in its negative form:

	shenandoah_assert_not_in_cset_except    (addr, value, value == NULL || ShenandoahHeap::heap()->cancelled_gc() || !ShenandoahHeap::heap()->is_concurrent_mark_in_progress());

Also, it reads strange that oop_store_in_heap() would call oop_store_not_in_heap().
So I have moved the code to a separate method oop_store_common() that gets called by both oop_store_in_heap() and oop_store_not_in_heap().

Tested it by running following tests in fastdebug mode:

hotspot_gc_shenandoah
java/lang/management/ThreadMXBean/MyOwnSynchronizer.java (50 times with -XX:ShenandoahGCHeuristics=aggressive)
java/lang/management/ThreadMXBean/LockedSynchronizers.java (50 times with -XX:ShenandoahGCHeuristics=aggressive)

Signed-off-by: Ashutosh Mehra asmehra@redhat.com

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue

Issue

JDK-8293252: Shenandoah: ThreadMXBean synchronizer tests crash with aggressive heuristics

Reviewers

William Kemper (@earthling-amzn - no project role)
Roman Kennke (@rkennke - Reviewer)
Dan Heidinga (@DanHeidinga - no project role)
Paul Hohensee (@phohensee - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/10268/head:pull/10268
$ git checkout pull/10268

Update a local copy of the PR:
$ git checkout pull/10268
$ git pull https://git.openjdk.org/jdk pull/10268/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 10268

View PR using the GUI difftool:
$ git pr show -t 10268

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/10268.diff

…gressive mode Signed-off-by: Ashutosh Mehra <asmehra@redhat.com>

bridgekeeper · 2022-09-14T16:05:50Z

👋 Welcome back ashu-mehra! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2022-09-14T16:12:56Z

@ashu-mehra The following labels will be automatically applied to this pull request:

hotspot-gc
shenandoah

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing lists. If you would like to change these labels, use the /label pull request command.

mlbridge · 2022-09-14T16:17:15Z

Webrevs

DanHeidinga · 2022-09-14T18:55:55Z

src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp

@@ -175,6 +175,8 @@ class ShenandoahBarrierSet: public BarrierSet {
    template <typename T>
    static oop oop_atomic_xchg_not_in_heap(T* addr, oop new_value);

+    template <typename T>
+    static void oop_store_common(T* addr, oop value);


This is an implementation detail and a public part of the barrier set. We wouldn't expect users - other than the two existing callers - to ever use this api.

Can it be refactored out of this header and kept entirely within shenandoahBarrierSet.inline.hpp?

I have made oop_store_common a private method. It needs to be part of ShenandoahBarrierSet::AccessBarrier to be able to access RawAccessBarrier::oop_store().

@DanHeidinga are you okay with the updates?

Looks good to me

earthling-amzn

Please help me understand why VM_ThreadDump would be modifying oops?

earthling-amzn · 2022-09-14T19:48:54Z

src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp

  shenandoah_assert_marked_if(NULL, value, !CompressedOops::is_null(value) && ShenandoahHeap::heap()->is_evacuation_in_progress());
-  shenandoah_assert_not_in_cset_if(addr, value, value != NULL && !ShenandoahHeap::heap()->cancelled_gc());
+  shenandoah_assert_not_in_cset_if(addr, value, value != NULL && !ShenandoahHeap::heap()->cancelled_gc() && ShenandoahHeap::heap()->is_concurrent_mark_in_progress());


The collection set is chosen during final mark and should always be empty during concurrent mark, so restricting this assertion to run only when concurrent mark is in progress effectively disables it.

Are you suggesting we are better off removing this assertion completely, because the assertion that the value is not in collection set is also not correct as is evident from this issue.

I'm worried the assertion is correct and the thread dump is doing something wrong. Why is it writing an oop? Should it go through the load reference barrier first and evacuate the object?

That was my first impression as well - that we are missing load reference barrier somewhere. But then I realized we do hit the LRB when the JVM tires to load oop from the OopHandle using OopHandle::resolve, as is done here [0]

That prompted me to think there is nothing wrong in VM_ThreadDump and the problem lies in the assert conditions, more so because oop_store_in_heap() has that additional condition of is_concurrent_mark_in_progress().

With the additional condition I added in this PR, I am currently hitting another assert with the same test case in the same code area. The sequence of events leading to the new assertion failure are:

T1: GC cycle started and marked object A
T2: "Concurrent strong root" is completed which evacuates and updates the non-heap strong roots
T3: Concurrent evacuation started
T4: VMThread running VM_ThreadDump creates a new non-heap strong root R to object A (by creating OopHandle)
T5: VMThread completes VM_ThreadDump operation
T4: Concurrent evacuation moves object A
T5: GC cycle completes
T6: New GC cycle starts (in my case it was because the test was running with "aggressive" heuristics)
T7: Concurrent root marking comes across R and crashes trying to access A which has been evacuated

Initially I was thinking of resolving it by moving "Concurrent strong root" phase after "Concurrent evacuation" so that any new non-heap strong roots which may have been created during evacuation are also properly updated.

But now I am skeptic. It seems the underlying problem for both these asserts is the same - the object was not evacuated when it was handed over to VM_ThreadDump.

VM_ThreadDump calls HeapInspection::find_instances_at_safepoint to find instances of a particular class at safepoint which uses GC API object_iterate(). In case of Shenandoah GC core of this API is in ObjectIterateScanRootClosure::do_oop_work() [1] which does not have the code to evacuate the object. So probably the right way to fix these issues is to add a call to _heap->evacuate_object() in ObjectIterateScanRootClosure::do_oop_work. what do you think?

[0]

jdk/src/hotspot/share/services/management.cpp

Line 1288 in 6beeb84

synchronizers_array->obj_at_put(k, locks->at(k).resolve());

[1]

jdk/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp

Line 1233 in 6beeb84

void do_oop_work(T* p) {

Hmm, OopHandle::resolve should have gone through the LRB, which should have evacuated the object. If the object is in the cset and it didn't get evacuated by the LRB, then it should be true that the gc is cancelled (out-of-memory during evac). Did this happen under low memory conditions? I wonder if the VM thread did try to evacuate it and fail?

This looks related: https://bugs.openjdk.org/browse/JDK-8235324. The CollectedHeap::keep_alive API doesn't support the case where the given oop would need to be evacuated and return the new location.

Thanks for pointing out that bug. It explains the need for the keep_alive API. But that API is solving a different issue than what we are facing here. I think we are on right track with respect to adding LRB during object iteration.

I am going to try changing ObjectIterateScanRootClosure to use HeapAccess<AS_NO_KEEPALIVE> instead of RawAccess.
I have been deliberating over the need for if (_heap->is_concurrent_weak_root_in_progress() && !_marking_context->is_marked(obj)) check in ObjectIterateScanRootClosure after we switch to HeapAccess. The same check is executed by LRB [1] if ON_PHANTOM_OOP_REF decorator is also set, which makes me think we should probably use HeapAccess<AS_NO_KEEPALIVE | ON_PHANTOM_OOP_REF> and remove that check from ObjectIterateScanRootClosure. wdyt?

[1]

jdk/src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp

Lines 104 to 108 in 6beeb84

if ((decorators & ON_PHANTOM_OOP_REF) != 0 &&

_heap->is_concurrent_weak_root_in_progress() &&

!_heap->marking_context()->is_marked(obj)) {

return NULL;

}

I have added commit that replaces the RawAccess with HeapAccess<AS_NO_KEEPALIVE>. I think its better not to avoid the check if (_heap->is_concurrent_weak_root_in_progress() && !_marking_context->is_marked(obj)) by using ON_PHANTOM_OOP_REF decorator as it relies on the assumption that weak oops in the VM are similar to phantomly reachable references (which is true and may remain so, but is not as explicit as the condition itself). I have therefore kept the check for is_concurrent_weak_root_in_progress as it is.

It might be simpler to only change the one line in these object iterators:

obj = ShenandoahBarrierSet::resolve_forwarded_not_null(obj);

to

obj = ShenandoahBarrierSet::load_reference_barrier(obj);

This will evacuate objects in the cset after checking for unmarked concurrent weak roots. resolve_forwarded_not_null presumes the object has already been evacuated, but that may not be the case here.

I think it makes sense to just call ShenandoahBarrierSet::load_reference_barrier directly. Thanks for pointing that out.

ashu-mehra · 2022-09-14T20:43:13Z

Please help me understand why VM_ThreadDump would be modifying oops?

The relevant stack trace for the VMThread (at the point of assertion failure) is:

#8  0x00007fd7e35a0c09 in ShenandoahAsserts::assert_not_in_cset (interior_loc=interior_loc@entry=0x7fd5a00043c0, obj=..., 
    file=file@entry=0x7fd7e3a121c0 "/home/asmehra/data/ashu-mehra/jdk/src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp", line=line@entry=246)
    at /home/asmehra/data/ashu-mehra/jdk/src/hotspot/share/oops/oopsHierarchy.hpp:91
#9  0x00007fd7e27ca136 in ShenandoahBarrierSet::AccessBarrier<548932ul, ShenandoahBarrierSet>::oop_store_not_in_heap<oop> (value=..., addr=0x7fd5a00043c0)
    at /home/asmehra/data/ashu-mehra/jdk/src/hotspot/share/oops/oopsHierarchy.hpp:91
#10 AccessInternal::PostRuntimeDispatch<ShenandoahBarrierSet::AccessBarrier<548932ul, ShenandoahBarrierSet>, (AccessInternal::BarrierType)0, 548932ul>::oop_access_barrier (addr=0x7fd5a00043c0, value=...)
    at /home/asmehra/data/ashu-mehra/jdk/src/hotspot/share/oops/access.inline.hpp:69
#11 0x00007fd7e2d2cc93 in AccessInternal::RuntimeDispatch<548932ul, oop, (AccessInternal::BarrierType)0>::store (value=..., addr=0x7fd5a00043c0)
    at /home/asmehra/data/ashu-mehra/jdk/src/hotspot/share/oops/oopsHierarchy.hpp:91
#12 AccessInternal::PreRuntimeDispatch::store<548932ul, oop> (value=..., addr=0x7fd5a00043c0) at /home/asmehra/data/ashu-mehra/jdk/src/hotspot/share/oops/accessBackend.hpp:682
#13 AccessInternal::store_reduce_types<548932ul, oop> (value=..., addr=0x7fd5a00043c0) at /home/asmehra/data/ashu-mehra/jdk/src/hotspot/share/oops/accessBackend.hpp:961
#14 AccessInternal::store<524292ul, oop, oop> (value=..., addr=0x7fd5a00043c0) at /home/asmehra/data/ashu-mehra/jdk/src/hotspot/share/oops/accessBackend.hpp:1114
#15 Access<524288ul>::oop_store<oop, oop> (value=..., addr=0x7fd5a00043c0) at /home/asmehra/data/ashu-mehra/jdk/src/hotspot/share/oops/access.hpp:252
#16 OopHandle::OopHandle (this=<optimized out>, storage=<optimized out>, obj=...) at /home/asmehra/data/ashu-mehra/jdk/src/hotspot/share/oops/oopHandle.inline.hpp:47
#17 0x00007fd7e381e920 in ThreadConcurrentLocks::add_lock (this=this@entry=0x7fd5a0004310, o=...) at /home/asmehra/data/ashu-mehra/jdk/src/hotspot/share/oops/oopsHierarchy.hpp:91
#18 0x00007fd7e381eac0 in ConcurrentLocksDump::add_lock (o=..., thread=<optimized out>, this=0x7fd5a6bfe820) at /home/asmehra/data/ashu-mehra/jdk/src/hotspot/share/oops/oopsHierarchy.hpp:91
#19 ConcurrentLocksDump::add_lock (this=0x7fd5a6bfe820, thread=<optimized out>, o=...) at /home/asmehra/data/ashu-mehra/jdk/src/hotspot/share/services/threadService.cpp:832
#20 0x00007fd7e381ebf6 in ConcurrentLocksDump::build_map (this=this@entry=0x7fd5a6bfe820, aos_objects=aos_objects@entry=0x7fd5a0003f40)
    at /home/asmehra/data/ashu-mehra/jdk/src/hotspot/share/oops/oopsHierarchy.hpp:91
#21 0x00007fd7e381f00a in ConcurrentLocksDump::dump_at_safepoint (this=0x7fd5a6bfe820) at /home/asmehra/data/ashu-mehra/jdk/src/hotspot/share/services/threadService.cpp:810
#22 0x00007fd7e38e4bbc in VM_ThreadDump::doit (this=0x7fd5a56c11b0) at /home/asmehra/data/ashu-mehra/jdk/src/hotspot/share/runtime/vmOperations.cpp:280
#23 0x00007fd7e38e4f6a in VM_Operation::evaluate (this=this@entry=0x7fd5a56c11b0) at /home/asmehra/data/ashu-mehra/jdk/src/hotspot/share/runtime/vmOperations.cpp:71
#24 0x00007fd7e390c4c8 in VMThread::evaluate_operation (this=0x7fd5a6bfea50, op=0x7fd5a56c11b0) at /home/asmehra/data/ashu-mehra/jdk/src/hotspot/share/runtime/vmThread.cpp:282
#25 VMThread::inner_execute (this=this@entry=0x7fd7dc2499f0, op=<optimized out>) at /home/asmehra/data/ashu-mehra/jdk/src/hotspot/share/runtime/vmThread.cpp:429
#26 0x00007fd7e390d172 in VMThread::loop (this=this@entry=0x7fd7dc2499f0) at /home/asmehra/data/ashu-mehra/jdk/src/hotspot/share/runtime/vmThread.cpp:496
#27 0x00007fd7e390d3e0 in VMThread::run (this=0x7fd7dc2499f0) at /home/asmehra/data/ashu-mehra/jdk/src/hotspot/share/runtime/vmThread.cpp:175

The VMThread is creating a new OopHandle and as part of that it creates a new oop

jdk/src/hotspot/share/oops/oopHandle.inline.hpp

Line 47 in a75ddb8

NativeAccess<>::oop_store(_obj, obj);

…tion Signed-off-by: Ashutosh Mehra <asmehra@redhat.com>

Signed-off-by: Ashutosh Mehra <asmehra@redhat.com>

earthling-amzn · 2022-09-22T16:39:15Z

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp

-    T o = RawAccess<>::oop_load(p);
-    if (!CompressedOops::is_null(o)) {
-      oop obj = CompressedOops::decode_not_null(o);
+    oop obj = HeapAccess<AS_NO_KEEPALIVE>::oop_load(p);


After taking a closer look at the LRB code, I think we should or in ON_WEAK_OOP_REF to the access decorators. With only the AS_NO_KEEPALIVE decorator, the LRB will fall through all the cases here and end up evacuating a doomed weak referent (i.e., keeping the object alive).
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp#L119

I'm worried that this access here could defeat the logic which is meant to keep weak references from being resurrected. It also looks like if we add in the ON_WEAK_OOP_REF decorator, the LRB will handle this case for the object iterator too:

if (_heap->is_concurrent_weak_root_in_progress() && !_marking_context->is_marked(obj)) { // There may be dead oops in weak roots in concurrent root phase, do not touch them. return; }

I missed the fact that the object referred by week root would have already been evacuated by the time we hit is_concurrent_weak_root_in_progress condition.

objects referred by weak roots. Signed-off-by: Ashutosh Mehra <asmehra@redhat.com>

ashu-mehra · 2022-09-22T21:31:09Z

@earthling-amzn as you suggested I have added another commit to call load_reference_barrier directly instead of using HeapAccess. That seems to be the safest approach to effect evacuation without meddling with other conditions.

earthling-amzn

This looks good to me. Thank you for working through it with me!

ashu-mehra · 2022-09-22T22:07:33Z

@earthling-amzn thank you for reviewing it and guiding the code changes.

rkennke

Looks good to me, too. Thanks, Ashu!

/Roman

openjdk · 2022-09-23T15:43:31Z

@ashu-mehra This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8293252: Shenandoah: ThreadMXBean synchronizer tests crash with aggressive heuristics

Reviewed-by: wkemper, rkennke, heidinga, phh

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 377 new commits pushed to the master branch:

543851d: 8289607: Change hotspot/jtreg tests to not use Thread.suspend/resume
e2f8251: 8293618: x86: Wrong code generation in class Assembler
6ecd081: 8294270: make test passes awkward -status:-status:error,fail to jtreg
eca9749: 8288325: [windows] Actual and Preferred Size of AWT Non-resizable frame are different
2e20e7e: 8294271: Remove use of ThreadDeath from make utilities
e45f3d5: 8294281: Allow warnings to be disabled on a per-file basis
664e5b1: 8294187: RISC-V: Unify all relocations for the backend into AbstractAssembler::relocate()
acd75e0: 8294053: Unneeded local variable in handle_safefetch()
0b56b82: 8293991: java/lang/Float/Binary16ConversionNaN.java fails on silent NaN conversions
acd5bcf: 8289610: Degrade Thread.stop
... and 367 more: https://git.openjdk.org/jdk/compare/d24b7b7026cf85f1aecf44f60819762872cfd5c1...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@rkennke, @phohensee) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

ashu-mehra · 2022-09-23T15:43:41Z

@rkennke thank you for reviewing it.

ashu-mehra · 2022-09-23T15:47:04Z

/integrate

openjdk · 2022-09-23T15:51:44Z

@ashu-mehra
Your change (at version a4d6fd8) is now ready to be sponsored by a Committer.

ashu-mehra · 2022-09-23T18:36:30Z

@rkennke can you please sponsor it as well?

phohensee

Lgtm. I'll sponsor.

phohensee · 2022-09-23T18:45:56Z

/sponsor

openjdk · 2022-09-23T18:53:02Z

Going to push as commit 3675f4c.
Since your change was applied there have been 377 commits pushed to the master branch:

543851d: 8289607: Change hotspot/jtreg tests to not use Thread.suspend/resume
e2f8251: 8293618: x86: Wrong code generation in class Assembler
6ecd081: 8294270: make test passes awkward -status:-status:error,fail to jtreg
eca9749: 8288325: [windows] Actual and Preferred Size of AWT Non-resizable frame are different
2e20e7e: 8294271: Remove use of ThreadDeath from make utilities
e45f3d5: 8294281: Allow warnings to be disabled on a per-file basis
664e5b1: 8294187: RISC-V: Unify all relocations for the backend into AbstractAssembler::relocate()
acd75e0: 8294053: Unneeded local variable in handle_safefetch()
0b56b82: 8293991: java/lang/Float/Binary16ConversionNaN.java fails on silent NaN conversions
acd5bcf: 8289610: Degrade Thread.stop
... and 367 more: https://git.openjdk.org/jdk/compare/d24b7b7026cf85f1aecf44f60819762872cfd5c1...master

Your commit was automatically rebased without conflicts.

openjdk · 2022-09-23T18:54:47Z

@phohensee @ashu-mehra Pushed as commit 3675f4c.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

ashu-mehra · 2022-09-23T19:01:22Z

@phohensee thank you!

openjdk · 2023-02-07T16:48:47Z

@rkennke Unknown command roman - for a list of valid commands use /help.

8293252: Shenandoah: ThreadMXBean synchronizer tests crash with IU+ag…

4162950

…gressive mode Signed-off-by: Ashutosh Mehra <asmehra@redhat.com>

openjdk bot added the rfr Pull request is ready for review label Sep 14, 2022

openjdk bot added hotspot-gc hotspot-gc-dev@openjdk.org shenandoah shenandoah-dev@openjdk.org labels Sep 14, 2022

DanHeidinga reviewed Sep 14, 2022

View reviewed changes

earthling-amzn suggested changes Sep 14, 2022

View reviewed changes

ashu-mehra changed the title ~~8293252: Shenandoah: ThreadMXBean synchronizer tests crash with IU+aggressive mode~~ 8293252: Shenandoah: ThreadMXBean synchronizer tests crash with aggressive heuristics Sep 21, 2022

ashu-mehra added 2 commits September 21, 2022 21:38

Make oop_store_common() as private method and remove extraneous condi…

62b40d3

…tion Signed-off-by: Ashutosh Mehra <asmehra@redhat.com>

Use HeapAccess instead of RawAccess when iterating the heap objects

ee36ab8

Signed-off-by: Ashutosh Mehra <asmehra@redhat.com>

earthling-amzn reviewed Sep 22, 2022

View reviewed changes

Use lrb directly instead of using HeapAccess to avoid evacuating doomed

a4d6fd8

objects referred by weak roots. Signed-off-by: Ashutosh Mehra <asmehra@redhat.com>

earthling-amzn approved these changes Sep 22, 2022

View reviewed changes

rkennke approved these changes Sep 23, 2022

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Sep 23, 2022

DanHeidinga approved these changes Sep 23, 2022

View reviewed changes

openjdk bot added the sponsor Pull request is ready to be sponsored label Sep 23, 2022

phohensee approved these changes Sep 23, 2022

View reviewed changes

openjdk bot added the integrated Pull request has been integrated label Sep 23, 2022

openjdk bot closed this Sep 23, 2022

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review sponsor Pull request is ready to be sponsored labels Sep 23, 2022

ashu-mehra deleted the JDK-8293252 branch February 7, 2023 16:47

	if ((decorators & ON_PHANTOM_OOP_REF) != 0 &&
	_heap->is_concurrent_weak_root_in_progress() &&
	!_heap->marking_context()->is_marked(obj)) {
	return NULL;
	}

8293252: Shenandoah: ThreadMXBean synchronizer tests crash with aggressive heuristics #10268

8293252: Shenandoah: ThreadMXBean synchronizer tests crash with aggressive heuristics #10268

Conversation

ashu-mehra commented Sep 14, 2022 • edited by openjdk bot Loading

Progress

Issue

Reviewers

Reviewing

bridgekeeper bot commented Sep 14, 2022

openjdk bot commented Sep 14, 2022

mlbridge bot commented Sep 14, 2022 • edited Loading

Webrevs

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

earthling-amzn left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ashu-mehra Sep 22, 2022 • edited Loading

Choose a reason for hiding this comment

ashu-mehra commented Sep 14, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ashu-mehra commented Sep 22, 2022

earthling-amzn left a comment

Choose a reason for hiding this comment

ashu-mehra commented Sep 22, 2022

rkennke left a comment

Choose a reason for hiding this comment

openjdk bot commented Sep 23, 2022 • edited Loading

ashu-mehra commented Sep 23, 2022

ashu-mehra commented Sep 23, 2022

openjdk bot commented Sep 23, 2022

ashu-mehra commented Sep 23, 2022

phohensee left a comment • edited Loading

Choose a reason for hiding this comment

phohensee commented Sep 23, 2022

openjdk bot commented Sep 23, 2022

openjdk bot commented Sep 23, 2022

ashu-mehra commented Sep 23, 2022

openjdk bot commented Feb 7, 2023

ashu-mehra commented Sep 14, 2022 •

edited by openjdk bot

Loading

mlbridge bot commented Sep 14, 2022 •

edited

Loading

ashu-mehra Sep 22, 2022 •

edited

Loading

ashu-mehra commented Sep 14, 2022 •

edited

Loading

openjdk bot commented Sep 23, 2022 •

edited

Loading

phohensee left a comment •

edited

Loading