RFR: [8u, 9, 10] Cherry-pick SATB/KAL fixes for G1 and Shenandoah

[Aleksey Shipilev]

On 04/13/2018 05:54 PM, Roman Kennke wrote:
>> === sh/jdk10:
>>
>> http://cr.openjdk.java.net/~shade/shenandoah/audit-satb/10/webrev.01/
>>
>> 6b510cb0f14f: Cherry pick JDK-8187577: JVM crash during gc doing concurrent marking
>> cds-unsharable: Fix assert in ConstantPool::restore_unshareable_info (see also JDK-8194741)
>>
>> I am going to request the backport for JDK-8187577 to JDK 10 a bit later. 

Added jdk10u-fix-request to:
  https://bugs.openjdk.java.net/browse/JDK-8187577

>> === sh/jdk8u:
>>
>> http://cr.openjdk.java.net/~shade/shenandoah/audit-satb/8u/webrev.01/
>>
>> 6c280bbde146: Cherry-pick JDK-8173013: JVMTI tagged object access needs G1 pre-barrier
>> a696583f5ddb: Cherry-pick JDK-8165489: Missing G1 barrier in Unsafe_GetObjectVolatile
>> 6b510cb0f14f: Cherry-pick JDK-8187577: JVM crash during gc doing concurrent marking
>>
>> JDK-8187577 is going to come with the 8u merge at some point. I am going to request backports for
>> JDK-8173013 and JDK-8165489 to 8u-dev a bit later, so they also come via the regular channel.

8u backport for JDK-8173013:
 http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-April/007383.html

8u backport for JDK-8165489:
 http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-April/007384.html

>> All patches pass hotspot_gc_shenandoah {fastdebug|release}.
> 
> Patches look good.

Pushed.

> I wonder if we want to backport our (interim) keep_alive_barrier() API
> in BarrierSet to JDK8?

This increases our upstream exposure in 8u for no particular benefit. So I would say we are fine
with current injection in G1-related code.

Thanks,
-Aleksey