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

Writing to the mmaped PerfData file hsperfdata can cause long stalls on Linux

    Details

    • Type: Enhancement
    • Status: Closed
    • Priority: P4
    • Resolution: Won't Fix
    • Affects Version/s: 8u60, 9
    • Fix Version/s: tbd
    • Component/s: hotspot
    • Labels:
    • Subcomponent:
      svc
    • OS:
      linux

      Description

      Reported to hotspot-runtime-dev:
      From: Evan Jones
      At Twitter, I recently discovered that the hsperfdata file that is created
      by default by the JVM causes long safepoint and GC pauses. It turns out
      that writes to mmap-ed files can block until disk I/O completes, even if
      the I/O is to another disk. For details see:
      http://www.evanjones.ca/jvm-mmap-pause.html

      We have been experimenting with adding the -XX:+PerfDisableSharedMem JVM
      flag on a number of our latency sensitive services, and have seen a
      significant improvement. Our JVM team (which I am *not* part of), is
      investigating potential changes to the JVM to prevent this.

      Any suggestions for an approach to solving this problem that could be
      accepted into Hotspot itself? Some options:

      * Make the location of this file configurable (this was set with
      java.io.tmpdir for a time, but then was reverted; see
      JDK-6447182)

      * Use shared memory that is not backed by a file?

      * Something else I'm not considering?
      (not updating the actual hsperfdata file in fast paths?)

      I=H, can cause long stalls in execution
      L=L, fairly unlikely
      W=M, disable perf data file reporting
      => P3

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              mgerdin Mikael Gerdin (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: