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

[Vladimir Kozlov]

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