Discussion:
hsperfdata
(too old to reply)
Brian S O'Neill
2003-07-03 05:35:16 UTC
Permalink
I just noticed that on the win32 version of jdk1.4.2, when it runs it
creates a hsperfdata_<username> directory in my temp directory with a small
numbered file. The file is 16k bytes, but I assume it can vary. Other VMs
running get a different number for their file. When the VM exits, the file
is deleted. While the VM is running, I cannot access the file to see what's
in it. I'm not sure if this feature exists on other platforms or previous
versions of the jdk, but I do know it didn't exist in jdk1.3.1.

Does anyone know the purpose of this file? By the name I can guess it has
something to do with HotSpot gathering performance data. If the file is
always 16k bytes, it sure isn't saving much memory storing this data in a
file. Since the file is deleted upon exit, the VM isn't preserving any
profiling data for future runs. Even if the file were to grow larger, it
wouldn't likely save any memory if its accessed often enough - the file
cache will hold it in memory.
Joseph Millar
2003-07-04 17:27:38 UTC
Permalink
Post by Brian S O'Neill
I just noticed that on the win32 version of jdk1.4.2, when it runs it
creates a hsperfdata_<username> directory in my temp directory with a small
numbered file. The file is 16k bytes, but I assume it can vary. Other VMs
running get a different number for their file. When the VM exits, the file
is deleted. While the VM is running, I cannot access the file to see what's
in it. I'm not sure if this feature exists on other platforms or previous
versions of the jdk, but I do know it didn't exist in jdk1.3.1.
Does anyone know the purpose of this file? By the name I can guess it has
something to do with HotSpot gathering performance data. If the file is
always 16k bytes, it sure isn't saving much memory storing this data in a
file. Since the file is deleted upon exit, the VM isn't preserving any
profiling data for future runs. Even if the file were to grow larger, it
wouldn't likely save any memory if its accessed often enough - the file
cache will hold it in memory.
It's not created to save space, like you said, 16k (4 pages) is
less than nothing when we're talking mem usage. The file is
created as part of win32's memory mapped file system. In essence,
it allows multiple processes to share the same piece of memory,
to share information or whatnot. Exactly who outside the current
process might want shared memory is a mystery. I imagine Sun
has some tools for understanding the layout of this memory, which
appears to be a bunch of Hotspot statistics (you can cat the file).
A quick search through the developer site doesn't reveal anything really
interesting (but I only did a brief search). A similar mechanism
exists on other platforms, so this file exists on most platforms.

If you want to see the code that creates the shared memory, check
out the hotspot\src\os\win32\vm\perfMemory_win32.cpp file in the
JVM sources. It's interesting reading.

--Joe

Loading...