RFR 8226690: SIGSEGV in MetadataOnStackClosure::do_metadata

[coleen.phillimore at oracle.com]

On 9/26/19 12:01 AM, dean.long at oracle.com wrote:
> 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 
>

I see.  Thank you for reviewing the change and your comments.
Coleen

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