[jdk8u-dev] RFR: 8205399: Set node color on pinned HashMap.TreeNode deletion
Doug Lea
dl at openjdk.org
Mon Jun 5 10:36:10 UTC 2023
On Tue, 30 May 2023 08:42:32 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:
> See the issue for details. It reproduces in 8u, which breaks applications that run with `-ea -esa` for extra safety. We have seen at least two in-production bug reports due to this.
>
> The backport is not clean, because the test should reside in the different folder.
>
> The verification barfs on discovering the red root, when it also discovers left/right child node is also red. This technically violates one of the basic properties of RB trees: a red node should not have red children. We can always change (sub-)root node color from red to black without violating RB properties, as the path to any descendant node would still have the same number of black nodes. AFAIU, leaving the (sub-)root red and the child red could potentially break something else. This is why I believe this backport is required and safe for 8u.
>
> Additional testing:
> - [x] Linux x86_64, new regression test fails without the patch, passes with it
> - [x] Linux x86_64 `jdk_util`
> - [x] Linux x86_64 fastdebug `tier1` (some intermittent failures, which look unrelated and present in current master)
Yes, this was a rare bug that hadn't got checked for years in HashMap tests. There's no reason not to backport.
-------------
PR Comment: https://git.openjdk.org/jdk8u-dev/pull/325#issuecomment-1576542637
More information about the jdk8u-dev
mailing list