8237632: Shenandoah fails some vmTestbase_nsk_jvmti tests with "Forwardee must point to a heap address"
rkennke at redhat.com
Thu Feb 27 14:54:04 UTC 2020
Looks good to me. Thank you!
> Based on Erik's suggestion from JDK-8238633 review , 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/
> 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
>> 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.
More information about the hotspot-gc-dev