RFR: 8268406: Deallocate jmethodID native memory [v7]

[Coleen Phillimore]

On Thu, 19 Jun 2025 00:45:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This still seems racy though. What if the lookup succeeds but at the same time the class is to be unloaded?

Yes, It won't be at the same time, since lookup and remove_jmethod_ids hold the JmethodIdCreation_lock.  But this is a good question.  It could be still a race:


Method* Method::checked_resolve_jmethod_id(jmethodID mid) {
  if (mid == nullptr) return nullptr;
  Method* o = resolve_jmethod_id(mid);
  if (o == nullptr) {
    return nullptr;
  }
  // Method should otherwise be valid. Assert for testing.
  assert(is_valid_method(o), "should be valid jmethodid");
  // If the method's class holder object is unreferenced, but not yet marked as
  // unloaded, we need to return null here too because after a safepoint, its memory
  // will be reclaimed.
  return o->method_holder()->is_loader_alive() ? o : nullptr;
}


I think this should prevent this race but I'd have to think about it some more.

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

PR Comment: https://git.openjdk.org/jdk/pull/25267#issuecomment-2992814813