[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