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

[Roman Kennke]

Currently, we set the safe-iteration-limit at start of
update-refs-phase. This is subsequently used as limit for the linear
scan in update-refs phase. However, with the strong invariant we can do
better: we can set this limit at evac-start, because it is guaranteed
that any reference that is written to the new fields is to-space and
does not require updating.

An exception is new allocations for evacuated objects: those still
require updates and thus require special handling.

Note that closing the limit after we processed it is not strictly
necessary here, but it's useful in the follow-up where we'll short-cut
arraycopy-barriers based on the limit.

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?

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

Testing: hotspot_gc_shenandoah, specjbb, some workloads of specjvm

Can I please get a review?

Thanks, Roman