RFR(T) [13] : 8066173 : compiler/types/correctness/OffTest.java failed with assert

[Igor Ignatyev]

thanks Vladimir, pushed.

-- Igor

> On Jun 11, 2019, at 2:29 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
> 
> Good.
> 
> Thanks
> Vladimir
> 
>> On Jun 11, 2019, at 2:13 PM, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>> 
>> http://cr.openjdk.java.net/~iignatyev//8066173/webrev.00/index.html
>>> 3 lines changed: 1 ins; 0 del; 2 mod;
>> 
>> Hi all,
>> 
>> could you please review this trivial fix removes compiler/types/correctness from problem list on all platform and problem list them only on solaris-sparcv9 due to 8225620[1]?
>> 
>> from JBS:
>>> Patric Hedlin added a comment:
>> 
>>> The implementation in *load_extra_data()* has changed over the last few months (for JDK12/13) and may/should not manifest the problem any more. However, there might still be a potential problem (window) in *prepare_metadata()*, in the current JDK13 code base, where _PrepareExtraDataClosure_ will use the (now) fragile/raced (_SafepointSynchronize_) *safepoint_counter()*. The scenario would be that a safepoint has indeed started during *prepare_metadata()* but finishes after, without being detected. 
>>> 
>>> The test-case also uses the WhiteBox API to clean method data, via (_WhiteBox_) *clearMethodState()*. This would explain the (mal-) interaction with the previous implementation of *load_extra_data()*. 
>>> 
>>> 1. I would suggest that the issue is closed until manifested anew. 
>>> 
>>> 2. The Safepoint code/state should perhaps be scrutinized further to close the potential problem window. (Robbin will file a new report.)
>> 
>> 
>> webrev: http://cr.openjdk.java.net/~iignatyev//8066173/webrev.00/index.html
>> testing: compiler/types/correctness on {linux-x64,windows-x64,mac-x64} x {product,fastdebug}
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8066173
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8225620
>> 
>> Thanks,
>> -- Igor
>