RFR: 8378442: RBTreeCHeap does not deallocate removed nodes when using remove_at_cursor
Casper Norrbin
cnorrbin at openjdk.org
Mon Feb 23 16:54:10 UTC 2026
Hi everyone,
`RBTree::remove_at_cursor` currently uses the abstract (intrusive) `remove_at_cursor`, which does not deallocate the removed node. The other `RBTree::remove` variants call `remove_at_cursor` and then deallocated the removed node. As a result, calling `remove_at_cursor` directly can leak memory. This only affects `RBTreeCHeap`, as the `free` operations in other tree variants are NOOPs.
This PR updates `RBTree::remove_at_cursor` to also deallocate the removed node, and calls from other `remove` functions are redirected to the abstract `remove_at_cursor`. There are currently no external uses of `RBTree::remove_at_cursor`, so this has not been impacting anything. All existing call sites use the other `remove` functions that behave correctly.
Testing:
- Oracle tiers 1-3
- New gtest checking that all functions that are supposed to deallocate nodes do so as expected
-------------
Commit messages:
- remove_at_cursor fix
Changes: https://git.openjdk.org/jdk/pull/29883/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29883&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8378442
Stats: 77 lines in 3 files changed: 74 ins; 1 del; 2 mod
Patch: https://git.openjdk.org/jdk/pull/29883.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/29883/head:pull/29883
PR: https://git.openjdk.org/jdk/pull/29883
More information about the hotspot-dev
mailing list