RFR: 8301248: Less side effects in InstanceRefKlass::trace_reference_gc
Erik Österlund
eosterlund at openjdk.org
Fri Jan 27 19:41:19 UTC 2023
On Fri, 27 Jan 2023 18:25:55 GMT, Roman Kennke <rkennke at openjdk.org> wrote:
>> The InstanceRefKlass::trace_reference_gc function is called when using oop_iterate on a reference object. Since oop_iterate is a general iterator that can be used for anything, including verification code, it would be desirable for this code to not have subtle side effects. We currently apply load barriers which "fix" pointers in the heap. As a result, verification code that was meant to detect bugs, can end up fixing and hiding the bug. This CR aims to address this by limiting the logging to addresses, and not following them.
>
> Changes look reasonable to me. If I remember correctly, there have been issues with this code and Shenandoah in the past, but I don't quite remember what it was. Maybe it was the fact that barriers have been used there (because of ZGC?), and Shenandoah barriers did not like that? Not sure. Quite likely no longer an issue - at least I don't see how it could be -, but maybe run 'make test TEST=hotspot_gc_shenandoah' to be extra sure?
Thanks for the review @rkennke and @stefank! And yeah IIRC the Shenandoah issue had something to do with load barrier triggering relocation, and the new object being after TAMS, messing up some reference processing code as some referent then became live while it should have been dead really.
-------------
PR: https://git.openjdk.org/jdk/pull/12258
More information about the hotspot-dev
mailing list