RFR: 8356941: AbstractMethodError in HotSpot Due to Incorrect Handling of Private Method [v2]

[David Holmes]

On Tue, 15 Jul 2025 15:07:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8356941-defaultmeth
>>  - Merge branch 'master' into 8356941-defaultmeth
>>  - Fix bug and add new testcases
>>  - Additional logging to identify the problem
>
> Maybe better without logging. It is not immediately clear if we need more `ResourceMark`-s around some logging messages?

Thanks for looking at this @shipilev !

> Maybe better without logging. It is not immediately clear if we need more `ResourceMark`-s around some logging messages?

Regarding `ResourceMark` this is handled at the `generate_default_methods` entry point:

void DefaultMethods::generate_default_methods(
    InstanceKlass* klass, const GrowableArray<Method*>* mirandas, TRAPS) {
  assert(klass != nullptr, "invariant");
  assert(klass != vmClasses::Object_klass(), "Shouldn't be called for Object");

  // This resource mark is the bound for all memory allocation that takes
  // place during default method processing.  After this goes out of scope,
  // all (Resource) objects' memory will be reclaimed.  Be careful if adding an
  // embedded resource mark under here as that memory can't be used outside
  // whatever scope it's in.
  ResourceMark rm(THREAD);

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

PR Comment: https://git.openjdk.org/jdk/pull/26302#issuecomment-3077145815