Integrated: 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

This pull request has now been integrated.

Changeset: 269c9f3e
Author:    Casper Norrbin <cnorrbin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/269c9f3ed53275bcad2b3ce0e1c93cf8eb3ef06d
Stats:     77 lines in 3 files changed: 74 ins; 1 del; 2 mod

8378442: RBTreeCHeap does not deallocate removed nodes when using remove_at_cursor

Reviewed-by: jsikstro, jsjolen

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

PR: https://git.openjdk.org/jdk/pull/29883