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

[Roman Kennke]

Hi Aleksey,

On 3/11/20 2:34 PM, Aleksey Shipilev wrote:
> 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 s in place.

Ok, I am taking it out.

>> 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.

Good you mention that. It was actually wrong and covered up the fact
that the watermark is not reset properly on ShHeapRegion::recycle(). I
fixed that now.

> 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.

Yes, I agree. Done.

I also removed a suspicious (but, afaict pointless) update of the
watermark in mark-compact.

http://cr.openjdk.java.net/~rkennke/JDK-8240872/webrev.01/

Roman