hsperfdata causing long GC/safepoint times: Don't use mmap?
mikael.gerdin at oracle.com
Thu Mar 26 15:42:14 UTC 2015
On 2015-03-26 16:33, Mikael Gerdin wrote:
> Hi Evan,
> On 2015-03-26 16:14, Evan Jones wrote:
>> At Twitter, I recently discovered that the hsperfdata file that is
>> 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>",
> O_RDWR|O_CREAT|O_EXCL, 0600)
>> * 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