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

[Evgeny Astigeevich]

On Tue, 28 Oct 2025 09:22:25 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I don't understand this patch. So for release builds, we get stuck at `reference_count=1` and do continuous `os::free(_immutable_data)`? How's that correct?

I think we should not continuously free as long as we call `nmethod::purge` once per nmethod.

The counter is a part of the immutable data, not a part of nmethod, which is shared among copies of an nmethod.

    int reference_count = get_immutable_data_references_counter();



We have:

nmethod_orig     ---|
nmethod_copy1  ---|---> {data, counter == 3}
nmethod_copy3 ---|


The counter becoming 1 means the only one nmethod points at `{data, counter == 1}`.
Executing the code

    // Free memory if this is the last nmethod referencing immutable data
    if (reference_count == 1) {
      // Updating the counter here is not necessary since the memory is
      // being freed so only do it for debug builds to eliminate a write
      DEBUG_ONLY(set_immutable_data_references_counter(reference_count - 1);)

      os::free(_immutable_data);

will release the memory used for the immutable data. This also makes the counter garbage.
As a result there will be no more nmethods sharing the pointer to the immutable data.

There will be a problem if `purge` is called again for the same nmethod. `get_immutable_data_references_counter` might return garbage. `purge` does not free CodeCache memory used by the nmethod. Maybe we should  check `_immutable_data` is not `blob_end()` either explicitly or with an assert.

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

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