[sh/8u] Root processing related backports

[Aleksey Shipilev]

On 5/13/20 7:56 PM, Zhengyu Gu wrote:
> Updated: 
> http://cr.openjdk.java.net/~zgu/shenandoah/sh-8u-root-processing/webrev.02/

Very close! Roman needs to take a careful look as well.

>> Kinda. 8u is special here:
>>    https://mail.openjdk.java.net/pipermail/shenandoah-dev/2019-December/011193.html
>>
>> But, I can see that ShenandoahConcurrentMark::weak_roots_work() is now called unconditionally, so it
>> does the same thing? And there is no explicit call to JvmtiExport::weak_oops_do, which makes us
>> protected from this mess:
>>
>>   303     // In JDK 8, this is handled by JNIHandles::weak_oops_do. We cannot enter here, because
>>   304     // it would walk the JvmtiTagMap twice (which is okay) and possibly by multiple threads
>>   305     // (which is not okay, because that walk is not thread-safe). In subsequent releases,
>>   306     // it is handled in a more straightforward manner, see JDK-8189360.
>>   307     /*
>>   308     ShenandoahForwardedIsAliveClosure is_alive;
>>   309     JvmtiExport::weak_oops_do(&is_alive, oops);
>>   310     */
>>
> Ok, I digged into 8u reference processor, and yes, jni weak oops are 
> cleaned there.
> 
> Although, I could not find JDK-8189360 backport, but JVMTI weak oops no 
> longer piggyback to JNIHandles::weak_oops_do() ... which I missed.

JDK-8189360 is not backported. Look in JNIHandleBlock::weak_oops_do:

  /*
   * JVMTI data structures may also contain weak oops.  The iteration of them
   * is placed here so that we don't need to add it to each of the collectors.
   */
  JvmtiExport::weak_oops_do(is_alive, f);

So it would do JvmtiExport::weak_oops_do it during JNIHandle::weak_oops_do. Please make sure we
never ever touch JvmtiExport::weak_oops_do if JNIHandle::weak_oops_do possibly runs in another worker.

I would check myself tomorrow.

-- 
Thanks,
-Aleksey