[15] 8237632: Shenandoah fails some vmTestbase_nsk_jvmti tests with "Forwardee must point to a heap address"

[Zhengyu Gu]

Hi,

Based on Erik's suggestion from JDK-8238633 review [1], we can filter 
out oops marked by JVMTI and JFR leak profiler via resolve_forwarded() 
barrier, by inserting an null check on forwarding pointer.

To reduce performance impact, we split up compiler and runtime resolve 
forwarded barrier, only performs extra null check in runtime barrier, as 
JVMTI and leak profiler heap walk are performed at safepoints, where 
mutators are stopped.


Webrev: http://cr.openjdk.java.net/~zgu/JDK-8237632/webrev.01/

Test:
   hotspot_gc_shenandoah
   vmTestbase_nsk_jvmti
   vmTestbase_nsk_jdi

Thanks,

-Zhengyu

[1] 
https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-February/040974.html



On 2/4/20 2:23 PM, Aleksey Shipilev wrote:
> On 2/3/20 9:59 PM, Zhengyu Gu wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8237632
>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8237632/webrev.00/
> 
> Uh. It seems to me the cure is worse than the disease:
>    1) It rewires sensitive parts of barrier paths, root handling, etc, which requires more thorough
> testing, and we are too deep in RDP2 for this;
>    2) It effectively disables asserts for anything not in collection set. Which means it disables
> most of asserts. The fact that Verifier still works is a small consolation.
> 
> I propose to accept this failure in 14, and rework the JVMTI heap walk to stop messing around with
> mark words in 15. Since this relates to concurrent root handling, 11-shenandoah is already safe.
>