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

2023-11-23 Thread Jaroslav Bachorik
On Wed, 22 Nov 2023 01:21:15 GMT, David Holmes wrote: >> Jaroslav Bachorik has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Rewerite the test to use RedefineClassHelper > > test/hotspot/jtreg/serviceability/jvmti/thread/GetStackTrace/GetS

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

2023-11-23 Thread Jaroslav Bachorik
On Mon, 20 Nov 2023 22:08:49 GMT, Coleen Phillimore wrote: >> Jaroslav Bachorik has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Rewerite the test to use RedefineClassHelper > > src/hotspot/share/classfile/classFileParser.cpp line 5579: >

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

2023-11-23 Thread Jaroslav Bachorik
On Wed, 22 Nov 2023 01:27:25 GMT, David Holmes wrote: >> I see, holder is the right word and concept. So the parameter means >> has_method_holder, in that the InstanceKlass has been fully parsed at the >> point of clearing the jmethodIDs. > > Can't we just check `method->method_holder()` for n

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

2023-11-23 Thread Jaroslav Bachorik
> Please, review this fix for a corner case handling of `jmethodID` values. > > The issue is related to the interplay between `jmethodID` values and method > redefinitions. Each `jmethodID` value is effectively a pointer to a `Method` > instance. Once that method gets redefined, the `jmethodID`