Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8078369

[testbug] java/time/tck/java/time/TCKOffsetTime[now] fails on slow devices

    Details

    • Subcomponent:
    • Resolved In Build:
      b63

      Backports

        Description

        The test failing on slow device in -Xcomp mode because of JIT take much time. In case we warm up VM the test passes.

        Example of results:

        /export/local/aurora/CommonData/jdk/bin/java -server -Xcomp LocalTimeNow
        diff = 116000000
        Fail

        Result of fixed test:
         /export/local/aurora/CommonData/jdk/bin/java -server -Xcomp LocalTimeNow
        12:36:50.356Z
        12:36:56.283Z
        12:36:56.648Z
        12:36:56.649Z
        12:36:56.650Z
        12:36:56.651Z
        12:36:56.651Z
        12:36:56.652Z
        12:36:56.653Z
        12:36:56.653Z
        diff = 22000000
        Ok


        Executed with 8u60 Linux-arm-hf.
        In case of -Xint and -Xmixed the test passes.
        1. LocalTimeNow.java
          0.8 kB
          Roger Riggs
        2. LocalTimeNow[1].java
          4 kB
          Sergei Kovalev

          Activity

          Hide
          rriggs Roger Riggs added a comment - - edited
          Note: the attachment LocalTimeNow[1].java is corrupted; it is contains html.

          The impact is to any test that checks nanotime between successive calls.

          The current limit is .1 sec which is short. Simply raising the tolerance
          to 10 seconds should avoid the faults.

          One alternative fix is to use a @BeforeClass warmup method to do the warmup before any of the tests are run.
          The timing issue exist for any of the individual tests that use OffsetTime.now().

          The same issue might arise for other tests including:
           - TCKLocalDate
           - TCKLocalDateTime
           - TCKOffsetDateTime

          The non-timing aspects of the tests are valid but verifying the result based on the time is not.
          Show
          rriggs Roger Riggs added a comment - - edited Note: the attachment LocalTimeNow[1].java is corrupted; it is contains html. The impact is to any test that checks nanotime between successive calls. The current limit is .1 sec which is short. Simply raising the tolerance to 10 seconds should avoid the faults. One alternative fix is to use a @BeforeClass warmup method to do the warmup before any of the tests are run. The timing issue exist for any of the individual tests that use OffsetTime.now(). The same issue might arise for other tests including:  - TCKLocalDate  - TCKLocalDateTime  - TCKOffsetDateTime The non-timing aspects of the tests are valid but verifying the result based on the time is not.
          Hide
          hgupdate HG Updates added a comment -
          URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/04f51cc56673
          User: rriggs
          Date: 2015-04-27 20:32:24 +0000
          Show
          hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/04f51cc56673 User: rriggs Date: 2015-04-27 20:32:24 +0000
          Hide
          hgupdate HG Updates added a comment -
          URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/04f51cc56673
          User: lana
          Date: 2015-05-06 20:09:00 +0000
          Show
          hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/04f51cc56673 User: lana Date: 2015-05-06 20:09:00 +0000

            People

            • Assignee:
              rriggs Roger Riggs
              Reporter:
              skovalev Sergei Kovalev (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: