RFR: 8378442: RBTreeCHeap does not deallocate removed nodes when using remove_at_cursor

[Casper Norrbin]

On Mon, 23 Feb 2026 16:41:07 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> 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

Thanks for the quick reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/29883#issuecomment-3958739595