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