RFR: 8338471: Refactor Method::get_new_method() for better NoSuchMethodError handling [v4]
Dean Long
dlong at openjdk.org
Wed Sep 18 18:38:06 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 thought I had convinced myself that this doesn't cause a change in behavior. But I'm concerned about ConstantPoolCache::adjust_method_entries(). It looks like setting deleted _resolved_indy_entries to NoSuchMethodError is new behavior. Why are they treated differently than _resolved_method_entries?
For CallInfo::resolved_method() and selected_method(), it seems like this could be a change in behavior if the caller allows a safepoint. Can we assert that these functions never see an old method?
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20874#issuecomment-2359156443
More information about the serviceability-dev
mailing list