JDK-8076103 : Writing to the mmaped PerfData file hsperfdata can cause long stalls on Linux
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: svc
  • Affected Version: 8u60,9
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: linux
  • Submitted: 2015-03-26
  • Updated: 2023-01-05
  • Resolved: 2019-02-05
Related Reports
Relates :  
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
Comments
https://mail.openjdk.org/pipermail/hotspot-runtime-dev/2015-March/014307.html This problem does *not* happen if /tmp is on tmpfs (or if /tmp/hsperfdata_user is symlinked to tmpfs). It *does* happen on ext2, ext3, ext4, btrfs, and xfs. It is *extremely* common on btrfs, and rare on xfs (but still seems to occur).
05-01-2023

http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-March/014298.html
27-03-2015