RFR(S): 8200286: (testbug) MOptionTest test fails with java.lang.AssertionError: Classfiles too old!

[Langer, Christoph]

Hi,

please review a fix proposal for an intermittent error in test/langtools/tools/javac/modules/MOptionTest.java.

Bug: https://bugs.openjdk.java.net/browse/JDK-8200286
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8200286.0/

The issue has been reported already a while ago but was closed as not reproducible/won't fix. However, we've encountered this issue quite often on a linuxppc64 test machine in our ci infrastructure. Here are links to failed test jobs:

jdk11u:
https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-11-pr-validation-linux_ppc64/27/
  ->jtr: https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-11-pr-validation-linux_ppc64/27/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr
https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-11-pr-validation-linux_ppc64/26/
    ->jtr: https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-11-pr-validation-linux_ppc64/26/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr

jdk12:
https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-12-pr-validation-linux_ppc64/5/
    ->jtr: https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-12-pr-validation-linux_ppc64/5/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr
https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-12-pr-validation-linux_ppc64/3/
    ->jtr: https://ci.sapmachine.io/view/Pull%20Request%20Validation%20Builds%20/job/build-12-pr-validation-linux_ppc64/3/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr
jdk:
https://ci.sapmachine.io/view/Branch%20Builds/job/build--branch-linux_ppc64/4/
    ->jtr: https://ci.sapmachine.io/view/Branch%20Builds/job/build--branch-linux_ppc64/4/JT_20Report_20langtools/JTwork/tools/javac/modules/MOptionTest.jtr

The analysis done in the bug by Jiangli seems to be true. There is some imprecision in time resolution (maybe rounding issue, maybe os inaccuracy) where it can happen that the class file created by the java compiler has an earlier timestamp than the original source file.

What I did to overcome this is to date back the .java file to be compiled by one second before doing the compilation which will create a class file with the current time stamp. This should make sure that the .java file doesn't have a newer timestamp than the .class file.
I can do that because the test thread had waited for 2 seconds before doing the compilation. In fact, I have removed another 2 second wait because I don't think it is needed at that place since the test had already waited 2 seconds before testing a noop compilation due to unchanged timestamps.

I guess this is certainly not perfect but it should stabilize this test and to me it seems pragmatic.

I have already added this fix to our (SapMachine) code base and have not observed this error after that and didn't run into regressions either.

Thanks
Christoph

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190315/994e9ca3/attachment.html>