JDK-6447182 : temp dir locations should not be hardcoded for hsperfdata_ dirctories
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: hs14,5.0,6
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2006-07-10
  • Updated: 2011-01-11
  • Resolved: 2011-01-11
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7-poolResolved
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Description
Topic "hsperfdata_<USER> dirctories" was updated by briansully with the following message: 
------------------------------------------------
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?
------------------------------------------------

To view the topic, visit:
http://forum.java.sun.com/thread.jspa?forumID=37&threadID=750466

Comments
EVALUATION This was fixed as bug 6938627 so making this as a duplicate. Tnen this will be reverted because it breaks things so see also bug 7009828.
11-01-2011

EVALUATION I fixed this to use java.io.tmpdir but probably broke jstat. Can you just specify -Djava.io.tmpdir=xxx to jstat too?
01-09-2010

WORK AROUND The correct option for the 2nd proposed workaround is -XX:+PerfDisableSharedMem
25-06-2010

WORK AROUND Another alternative is to set -XX:+PerfDataDisableSharedMem. This will prevent the hsperfdata_pid files from being created, but will still allow JMX clients, like jconsole, to access the instrumentation via JMX interfaces. This is less disruptive than the -XX:-UsePerfData option.
25-09-2006

WORK AROUND One workaround would be to disable the temporary mapping of hsperfdata file by using "-XX:-UsePerfData". Then when your application is running, VM won't use "/tmp" to temporary maping the performance data file.
25-09-2006

EVALUATION After further investigation, I found that allowing user to control where the temporary image of the performance data (i.e hsperfdata) will cause jstat to be difficult to function properly. For example, if hotspot use the system property "java.io.tmpdir" (the other way as suggested in the description section, e.g. using TMPDIR env varibale, will lead to the same problem) to mmap the performance data, then when jstat runs to examine that running java process, it will have no idea of where the mmaped file is unless it is explicitly told which sometimes it is impossible to do so. This problem will become even hairy when jstat is running remotely. If we ignore jstat, we could provide a flag such that when specified, all the temporary files will go to that directory. But we need a strong business case to do it. After all, "/tmp" is a perfect place to put the temporary files and many Unix dameon services use that no matter whether you like it or not. I will keep this bug open. So if there are enough votes for this in future, we'll consider to add that flag as mentioned above.
14-07-2006

EVALUATION On Unix, "tempnam(char* s, char* prefix)" returns a file name for the temporary file and it allows user to specific an alternative directory for the tempory file. On Solaris, if s is NULL, the temp directory will be /var/tmp if TMPDIR is not set, otherwise, TMPDIR will be used. If /var/tmp is not writtable, /tmp will be used instead. This should address the concerns of RFE 6447220 (HotSpot and JDK don't agree on /tmp location on Solaris) since both side will use /var/tmp when TMPDIR is not set. We probably need to measure the performance of using /tmp versus /var/tmp for dumping hsperfdata. It would be ideal that we don't need to create a jvmstat specific override assume there is no compatibility issue.
10-07-2006