[11] RFR 8249560: Shenandoah: Fix racy GC request handling
Roman Kennke
rkennke at redhat.com
Mon Aug 10 10:31:51 UTC 2020
Looks good to me!
Thanks,
Roman
On Mon, 2020-08-10 at 10:17 +0200, Aleksey Shipilev wrote:
> Error verifying signature: Cannot verify message signature:
> Incorrect message format
> Original fix:
> https://bugs.openjdk.java.net/browse/JDK-8249560
> https://hg.openjdk.java.net/jdk/jdk15/rev/0fbc72a46860
>
> It does not apply cleanly to 11u, because MutexLockerEx is used in
> the middle of the hunk. I
> reapplied it by hand:
>
> diff -r 1584484e8128
> src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp
> ---
> a/src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp T
> hu Jul 23 12:46:24 2020 +0200
> +++
> b/src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp M
> on Aug 10 09:37:04 2020 +0200
> @@ -505,17 +505,19 @@
> // This is especially important for weak references cleanup and/or
> native
> // resources (e.g. DirectByteBuffers) machinery: when explicit GC
> request
> // comes very late in the already running cycle, it would miss
> lots of new
> // opportunities for cleanup that were made available before the
> caller
> // requested the GC.
> - size_t required_gc_id = get_gc_id() + 1;
>
> MonitorLockerEx ml(&_gc_waiters_lock);
> - while (get_gc_id() < required_gc_id) {
> + size_t current_gc_id = get_gc_id();
> + size_t required_gc_id = current_gc_id + 1;
> + while (current_gc_id < required_gc_id) {
> _gc_requested.set();
> _requested_gc_cause = cause;
> ml.wait();
> + current_gc_id = get_gc_id();
> }
> }
>
> void
> ShenandoahControlThread::handle_alloc_failure(ShenandoahAllocRequest&
> req) {
> ShenandoahHeap* heap = ShenandoahHeap::heap();
>
>
> Testing: hotspot_gc_shenandoah
>
More information about the jdk-updates-dev
mailing list