hsperfdata causing long GC/safepoint times: Don't use mmap?
mikael.gerdin at oracle.com
Thu Mar 26 15:33:49 UTC 2015
On 2015-03-26 16:14, Evan Jones wrote:
> 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:
Truly interesting stuff!
I know we've seen similar discrepancies in user/sys/real time before,
this could indeed be a cause for at least some of them.
> 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
> * Use shared memory that is not backed by a file?
Yeah, something like shm_open("/hsperfdata_<user>_<pid>",
> * Something else I'm not considering?
Have the VM asynchronously update the values in the hsperfdata file by
caching the new values somewhere in memory and using the ServiceThread
to commit the updated values to the mmaped perf data?
I'll file and issue for this and copy the relevant information into it.
> Evan Jones
More information about the hotspot-runtime-dev