RFR: 8338471: Refactor Method::get_new_method() for better NoSuchMethodError handling [v4]

Dean Long dlong at openjdk.org
Thu Sep 12 09:25:05 UTC 2024


On Wed, 11 Sep 2024 21:02:41 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> This patch cleans up the use of `get_new_method()` so callers don't have to worry about throwing `NoSuchMethodError`. The method is refactored to throw the error and avoid ever returning nullptr. Verified with tier1-5 tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Coleen suggestion

I'm trying to determine if this PR changes anything in regards to compilers, or leaves everything the same, so I am looking at callers of get_new_method() that don't already map is_deleted() to throw_no_such_method_error().
Is it true that CallInfo::resolved_method() and CallInfo::selected_method() can never return an is_old or is_deleted method?  They check for is_old but not is_deleted.  If get_new_method() actually returned nullptr for a deleted method then some callers might crash, so I am assuming this is impossible.  There is probably a rule that if you have a resolved CallInfo then you aren't allowed to safepoint, so there is no way the resolved/selected methods in the CallInfo can change to old or deleted, and it's probably impossible for them start out as old/deleted before a safepoint.  So why are these methods checking for is_old at all?

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

PR Comment: https://git.openjdk.org/jdk/pull/20874#issuecomment-2345732364


More information about the serviceability-dev mailing list