RFR: 8370527: Memory leak after 8316694: Implement relocation of nmethod within CodeCache

[Aleksey Shipilev]

On Mon, 27 Oct 2025 19:48:10 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

> [JDK-8370527](https://bugs.openjdk.org/browse/JDK-8370527)
> 
> [JDK-8316694](https://bugs.openjdk.org/browse/JDK-8316694) introduced an `immutable_data_references_counter` which keeps track of the number of nmethods using the immutable data so it can be shared between relocated nmethods. The old code reads the counter, decrements the counter, and then checks the first read to see if it is zero. Since the check is performed on the initial read it will never be zero which causes immutable data to never be freed.

Well, it sounds like "reference counter" is misleading then. You seem to be saying that "since the initial value is 1 even for unreferenced data, then the final value should also be 1, and that is when we free". But why that value is not 0? That would make much more sense for a _reference counter_. In other words, I think the problem is with initial value, not with the final one. Right?

Plus, drop the `DEBUG_ONLY` thing: it only makes debug and release bits perform differently, which obscures the testing, i.e. you cannot readily trust that fastdebug and release builds do the same thing. Only ever do `DEBUG_ONLY` counter updates for _debugging_ counters.

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

PR Comment: https://git.openjdk.org/jdk/pull/28008#issuecomment-3457363352