RFR: 8378354: Faulty assertion in checkInvariants method of ConcurrentHashMap

[Jaikiran Pai]

On Fri, 20 Feb 2026 20:23:27 GMT, cdw200806 <duke at openjdk.org> wrote:

>> Please describe the semantic impact of the violated assertion. Would it ever be observable?
>
>> Please describe the semantic impact of the violated assertion. Would it ever be observable?
> 
> If concurrent map use red-black-tree correctly(or use it normally as common red-balck-tree algorithm), this bug will never be observable.
> In the logic, It just like the old code assert 1 is a Object, but I fix it to 1 is a Integer. More correctly( if 1 is a String it will throw error) , but the old code is not a "bug" , will never throw error(if the tree is build and use correct). I find it by code review.
> 
> This assert just like a ut lack some of branch,a ut not perfect, if the red-black-tree operation code is wrong and some case  not as expect happen and it will not aware,but if the code run correctly, maybe it not need to fix, it decide by your team. 
> 
> @RogerRiggs

Hello @cdw200806, the line numbers in your change don't match the code in JDK master branch. Can you merge in the latest changes from master branch into yours and update this PR? I'm a bit surprised that the skara bots haven't tagged this PR with a merge-conflict label.

While at it please also enable GitHub Actions in your repo so that the GitHub actions test jobs get run in this PR. See the message here which explains what needs to be done https://github.com/openjdk/jdk/pull/24612/checks?check_run_id=40460799667.

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

PR Comment: https://git.openjdk.org/jdk/pull/24612#issuecomment-3937937691