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