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

[Roman Kennke]

Looks good to me. Thank you!

Roman


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