[11u] RFC 8231405: [Shenandoah] guarantee(d != NULL) failed: Null dominator info

Aleksey Shipilev shade at redhat.com
Mon Sep 30 19:25:39 UTC 2019


On 9/30/19 9:22 PM, Andrew John Hughes wrote:
> The second option, b, makes sense to me. I don't really follow the con
> for that; there are plenty of instances where Shenandoah changes have
> gone in between merges. I think a bit of noise on a webrev is
> outweighted by the testing and visibility it would get in the public repos.

Agreed. The "con" was mostly about not having a clear "tag" that CPU forest is based on, but I guess
that is a minor nuisance at this juncture, as CPU forests are probably tested at their "tip" anyway.
Which would include public fixes after we pull them in.

> As to the viability of the fix itself, it's Shenandoah-only code that it
> affects, so I'll leave that call up to you.
Right. We are going to have another small fix tomorrow, and then we would ask to pull new sh/jdk11
to the CPU forest, OK?

-- 
Thanks,
-Aleksey



More information about the shenandoah-dev mailing list