hsperfdata_<USER> dirctories
From googling the net and searching these forums I understand the JVM needs to create the hsperfdata files. I can live with that I guess. My problem is that the JVM always creates them in /tmp on my SuSE Enterprise 9 server. I need to be able to specify the location of these files. I tried setting environment variables, TMP and TEMP. That did not work. I tried a -Djava.io.tmpdir=/mydir and that did not work.
I went to the JVM source and found in perfMemory_linux.cpp:
static char* get_user_tmp_dir(const char* user) {
const char* tmpdir = os::get_temp_directory();
const char* perfdir = PERFDATA_NAME;
size_t nbytes = strlen(tmpdir) + strlen(perfdir) + strlen(user) + 2;
char* dirname = NEW_C_HEAP_ARRAY(char, nbytes);
// construct the path name to user specific tmp directory
snprintf(dirname, nbytes, "%s%s_%s", tmpdir, perfdir, user);
return dirname;
}
I then tracked down this get_temp_directory function and found this in os_linux.cpp:
const char* os::get_temp_directory() { return "/tmp/"; }
So this means the JVM is hard coded to access /tmp. There is no reason the JVM should be hardcoded to such a location, it should be customizable through some sort of parameter. Anyone have ideas?
Yes, the location is hard coded to /tmp on Solaris and Linux. The jvmstat infrastructure is just using the HotSpot JVM's default tmp location. Overriding with -Djava.io.tmpdir is insufficient because java.io.tmpdir only changes the JDK's notion of where the tmp directory is located. It does not interact with the JVM's notion of the location of /tmp. Setting the TMP or TEMP variables on Windows just happens to work because both the JVM and the JDK use the same underlying Windows GetTempPath() API to select the default location. UNIX system don't have a corresponding API.
If you'd like to see a change to this behavior, I'd suggest that you file a bug at
http://bugs.sun.com/services/bugreport/index.jsp.
Out of curiosity, where would you redirect /tmp to? The jvmstat files are backing store files for named shared memory segments, one for each running JVM. On Solaris with a tmpfs based /tmp file system, the OS treats such shared memory files rather specially and doesn't write the data to disk until the application terminates (while still providing the coherent access to the data from any app that would access it). I'm not sure if Linux provides similar treatment. If you redirect these to a remote file system, that could result in some performance issues as the OS will periodically synchronize the in-memory data with the backing store file.
Brian
ryno3a at 2007-7-14 16:48:36 >
