RFR 8226690: SIGSEGV in MetadataOnStackClosure::do_metadata

[dean.long at oracle.com]

Looks good.

dl

On 9/25/19 6:29 PM, coleen.phillimore at oracle.com wrote:
>
>
> On 9/25/19 9:21 PM, coleen.phillimore at oracle.com wrote:
>>
>> 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.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/2019/8226690.02/webrev
>
> Rebuilt and retested with the ciReplay tests.  Thank you for looking 
> at the change.
> Coleen
>>
>> 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
>>>
>>
>