[15] RFR(XS): 8245128: Kitchensink fails with: assert(destination == (address)-1 || destination == entry) failed: b) MT-unsafe modification of inline cache

[coleen.phillimore at oracle.com]

I know less about this code than Erik and Vladimir but would you need to 
also test for this condition in the b) case?

  754          !old_method->method_holder()->is_loader_alive() ||


You probably won't get as much racy behavior from class unloading though.

Otherwise, the change makes sense.
thanks,
Coleen

On 6/23/20 12:31 PM, Vladimir Kozlov wrote:
> Good.
>
> Thanks,
> Vladimir
>
> On 6/23/20 6:58 AM, Christian Hagedorn wrote:
>> Hi
>>
>> Please review the following patch:
>> https://bugs.openjdk.java.net/browse/JDK-8245128
>> http://cr.openjdk.java.net/~chagedorn/8245128/webrev.00/
>>
>> The assert is often hit when enabling the Kitchensink instrumentation 
>> module which triggers a lot of class redefinitions. The problem looks 
>> similar to the one fixed in JDK-8225681 [1] for the other a) 
>> MT-unsafe assert. We could be dealing with an old method which we 
>> should also exclude in the second b) MT-unsafe assert (JDK-8225681 
>> fixed it only for a)). A nice description of the problem is found in 
>> the comment [2] by Erik Ö.
>>
>> Applying this fix, the assert is not hit anymore with repeated 
>> Kitchensink runs with the instrumentation module enabled.
>>
>> Thank you!
>>
>> Best regards,
>> Christian
>>
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8225681
>> [2] 
>> https://bugs.openjdk.java.net/browse/JDK-8225681?focusedCommentId=14278441&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14278441 
>>