RFR 8226690: SIGSEGV in MetadataOnStackClosure::do_metadata

coleen.phillimore at oracle.com coleen.phillimore at oracle.com
Thu Sep 26 01:21:20 UTC 2019


I see.  I dumped the redefinition count in the replay data because I saw 
the other fields were dumped there.  Would they also not affect the 
generated code?

I can remove these changes.

Thanks,
Coleen

On 9/25/19 6:18 PM, dean.long at oracle.com wrote:
> Saving and restoring redefinition_count for compiler replay doesn't 
> make sense to me.  It won't affect the generated code, and we probably 
> shouldn't even be installing/registering replay nmethods. I would 
> remove the ciEnv::dump_replay_data_unsafe() and process_JvmtiExport() 
> changes.
>
> dl
>
> On 9/25/19 7:33 AM, coleen.phillimore at oracle.com wrote:
>> Summary: Dont create nmethod if classes have been redefined since 
>> compilation start.
>>
>> The bug was caused by a new nmethod created with an old Method in the 
>> metadata section.  Added verification (which hit on windows) and NSV 
>> in the other place where the method can be replaced in the nmethod 
>> metadata section.
>>
>> There are some jvmci changes (to vmStructs_jvmci.cpp) that might be 
>> needed also in the graal compiler.
>>
>> Tested with tier1-6 and failing test 100 times.
>>
>> open webrev at 
>> http://cr.openjdk.java.net/~coleenp/2019/8226690.01/webrev
>> bug link https://bugs.openjdk.java.net/browse/JDK-8226690
>>
>> Thanks,
>> Coleen
>



More information about the serviceability-dev mailing list