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

[David Holmes]

On Tue, 15 Jul 2025 17:38:11 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> why doesn't line 657 need the same change?

Are you asking why it doesn't need the change to address the current bug? That would be because that block of code has nothing at all to do with the current bug. That block is looking at superclass overpass and static methods, to see if they may be candidates for replacing by a default method. For each of those methods it checks if there is an implementation in the current class that matches the name and sig and is a real method, and if so it doesn't create an empty vtable slot for it for default method processing to fill in. I spent a long time trying to create a scenario that would hit this block and the condition you want changed, but failed. Lets say we are looking at a slot for method `void m()` for simplicity. First you need a superclass that declares as static `void m()` method. Then you need a subclass that implements a non-static `void m()` method. But you also need to have the subclass implement an interface with a default `void m()` method, but in that case we will never r
 each the block of code because we will find that default method is already present in the list of miranda methods that we already processed! (During this phase of processing, default methods are considered mirandas - pass 1).

Now as to the actual fix ... we have a subclass that we are processing, and a superclass that has a private `void m()` method, and a super-super-interface that defines the default `void m()` method. We find `void m()` in the superclass's default methods - hence we reach the block of code I modified. For this slot to be processed  for default method handling (i.e. to get the correct entry so we invoke the true default method) we need to decide to create an empty vtable slot. The current logic (mirroring that for superclass methods - including the comment block that may or may not be accurate) checks to see if the current class has a concrete implementation of `void m()` as that would replace use of the default implementation (class instance methods "win"), except that is only true for non-private concrete implementations - a private class method is never considered the implementation of an interface method. So if the method is private we need to create the empty vtable slot - hence th
 e fix. 

Note that `klass->lookup_method` looks up the method in the current class and all superclasses, and will find overpass and private methods - so an alternative fix would be to change the lookup to skip private methods (and we could also skip overpasses and then simplify the condition further). But the two approaches to the fix seem equivalent in terms of readability/complexity and what I did was slightly shorter to write and fitted in with the other checks nicely.

I hope that clarifies things.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26302#discussion_r2209440542