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

System.currentTimeMillis() is slow on Linux, especially with the HPET time source

    Details

    • Subcomponent:
    • CPU:
      generic
    • OS:
      linux

      Description

      A DESCRIPTION OF THE REQUEST :
      See http://pzemtsov.github.io/2017/07/23/the-slow-currenttimemillis.html

      System.currentTimeMillis() takes about 650 ns on Linux with the HPET time source, compared to 4 ns on Windows.

      The Linux implementation of currentTimeMillis calls gettimeofday. gettimeofday has higher precision than what's needed for currentTimeMillis. clock_gettime with a COARSE timer would be much faster, which would help a lot with the HPET time, but also with the TSC timer.

      JUSTIFICATION :
      If System.currentTimeMillis is called in a time-sensitive manner, the slower behaviour on Linux can be damaging, especially if the HPET timer happens to be used. Using a faster implementation would be beneficial without a drawback, since the granularity of the result is 1ms.


      ---------- BEGIN SOURCE ----------
      See http://pzemtsov.github.io/2017/07/23/the-slow-currenttimemillis.html for extensive tests and analysis.
      ---------- END SOURCE ----------

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                dholmes David Holmes
                Reporter:
                webbuggrp Webbug Group
              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: