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

Jaroslav Bachorik jbachorik at openjdk.org
Thu Nov 23 08:49:35 UTC 2023


On Mon, 20 Nov 2023 22:08:49 GMT, Coleen Phillimore <coleenp at openjdk.org> 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:
> 
>> 5577: 
>> 5578:   if (_methods != nullptr) {
>> 5579:     // Free methods - those methods are not fully wired and miss the method holder
> 
> How about saying: for methods whose InstanceKlass as method holder is not yet created?

This comment went away with the change @dholmes-ora recommended

> test/hotspot/jtreg/serviceability/jvmti/thread/GetStackTrace/GetStackTraceAndRetransformTest/GetStackTraceAndRetransformTest.java line 53:
> 
>> 51: import java.util.List;
>> 52: import java.util.concurrent.CyclicBarrier;
>> 53: import java.util.concurrent.locks.LockSupport;
> 
> Do you need all these imports?
> 
> There's a simple RedefineClassHelper class that does most of the work, but maybe you need the explicit agent code to reproduce the crash?  See test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRunningMethodsWithBacktrace.java as an example.

I did clean up the imports and switched to `RedefineClassHelper`. Thanks for pointing that out!

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

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


More information about the hotspot-dev mailing list