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