RFR: 8313816: Accessing jmethodID might lead to spurious crashes [v8]

Jaroslav Bachorik jbachorik at openjdk.org
Fri Nov 24 11:42:09 UTC 2023


On Fri, 24 Nov 2023 06:49:14 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>I wondered about that but IIUC the pointers inside IK->_methods_jmethod_ids may refer to jmethodID slots that have been reused for different methods?

Yes. The reason is that if a class has previous versions, these versions do not contain their own jmethodID cache but rather delegate to the 'main' version. So we have nothing to iterate over when a previous class version gets unloaded - also, to make things more interesting, the previous method versions are pointing to the main class version as their `method_holder`. Making it impossible to iterate over the full jmethodID cache in the main class version and nulling out a jmethodID only if the method it points to has `method_holder` pointing to the class being unloaded (it will always point to the main class version ...). 

If there is an easy way out of this without incurring O(n^2) complexity, please speak up. I was not able to figure out an alternative without eg. keeping an explicit method->jmethodID link but that would increase the Method instance footprint and it felt like a more invasive change for what I want to achieve.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16662#discussion_r1404260866


More information about the serviceability-dev mailing list