RFR 8226690: SIGSEGV in MetadataOnStackClosure::do_metadata

[dean.long at oracle.com]

On 9/25/19 6: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 know some like _jvmti_can_access_local_variables can affect the 
generated code.  See

https://github.com/openjdk/jdk/blob/c83c8515ebb4e49fb63c9b896581c9f056268aa0/src/hotspot/share/ci/ciEnv.hpp#L344

dl
> 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
>>
>