RFR: 8240872: Shenandoah: Avoid updating new regions from start of evacuation

Aleksey Shipilev shade at redhat.com
Wed Mar 11 13:34:15 UTC 2020


On 3/11/20 1:52 PM, Roman Kennke wrote:
> Also, I wonder if we should not use the safe-iteration-limit here, but
> rather have a fast lookup-table like we do for TAMS. Again, it is not
> really relevant here, but the arraycopy follow-up will check the limit
> on the mid-path of the arraycopy-barrier. WDYT?

I'd prefer to introduce that check when arraycopy shortcut is in place.

> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8240872
> Webrev:
> http://cr.openjdk.java.net/~rkennke/JDK-8240872/webrev.00/

The patch is okay.

Do we really need to care about is_trash() during final mark? Those regions would be recycled soon
anyway.

I do wonder if we want to introduce the proper field in ShHeapRegion, rather than hijacking
Space::concurrent_iteration_safe_limit, though. It becomes even more necessary since the meaning of
it changes with this patch. This thing is more like "update_watermark" or some such.

-- 
Thanks,
-Aleksey



More information about the shenandoah-dev mailing list