Integrated: JDK-8305334: GenShen: reference processing needs a card-marking barrier

Y. Srinivas Ramakrishna ysr at openjdk.org
Fri Mar 31 20:58:07 UTC 2023


On Thu, 30 Mar 2023 20:30:26 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> Global collections can create new cross-generational pointers during j.l.r.Reference processing which should be added to the card marking remembered set. The issue was found with dacapo during heap verification and happens somewhat rarely. I added the requisite barrier and provided a comment describing the sole situation in reference processing that should need the barrier. Assertions check this condition, but the card is also redundantly dirtied for young collections too where it's strictly not needed.
> 
> I have tested with and without heap verification using product and fastdebug builds using dacapo and specjbb, and through our internal tests pipelines.
> 
> I have not run any specific performance comparisons to assess the impact of the checks for applications that traffic heavily in j.l.r.Refs, but I do not expect much impact.

This pull request has now been integrated.

Changeset: d0e1f519
Author:    Y. Srinivas Ramakrishna <ysr at openjdk.org>
Committer: Kelvin Nilsen <kdnilsen at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/d0e1f5195315019467419dfd377d440026bbb87e
Stats:     28 lines in 1 file changed: 28 ins; 0 del; 0 mod

8305334: GenShen: reference processing needs a card-marking barrier

Global collections can create new cross-generational pointers during j.l.r.Reference processing which should be added to the card marking remembered set. The issue was found with dacapo during heap verification and happens somewhat rarely. I added the requisite barrier and provided a comment describing the sole situation in reference processing that should need the barrier. Assertions check this condition, but the card is also redundantly dirtied for young collections too where it's strictly not needed.

I have tested with and without heap verification using product and fastdebug builds using dacapo and specjbb, and through our internal tests pipelines.

I have not run any specific performance comparisons to assess the impact of the checks for applications that traffic heavily in j.l.r.Refs, but I do not expect much impact.

Reviewed-by: kdnilsen, wkemper

-------------

PR: https://git.openjdk.org/shenandoah/pull/238


More information about the shenandoah-dev mailing list