JDK-6351349 : On linux with the old thread lib, jps should return the same PID as $!
  • Type: Bug
  • Component: core-svc
  • Sub-Component: tools
  • Affected Version: 6
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,linux
  • CPU: generic
  • Submitted: 2005-11-16
  • Updated: 2019-09-18
  • Resolved: 2006-01-07
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.
6 b67Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
In 5.0, if you do this:

 .../java  Hello &
You will be told a PID for the process.  This PID is also in shell var $!.
If you then to a jps command, you will see this PID reported for
this java process.  This is the PID that is given to the other command
line tools, jstat, jstack, jconsole, jmap.

After the fix for 
     6316197 Java launcher should create JVM from non-primordial thread

the above is no longer true on linux systems running the old thread lib,
eg, RH AS 2.1.  Instead, jps will report the PID of the new thread
created by the Java launcher.  After the fix for 
  6348630: initial thread != primordial thread confuses attach tests (LinuxThreads only)

the command line tools must be given the PID reported by jps
instead of the pid reported by the shell in $!.

This should be fixed so that the old behavior returns, ie, so
that the PID reported by jps is the same as the PID reported by $!
so that the command line tools on linux-with-old-threads behave the
same way as they do on other platforms.
The following is the list of the jtreg tests affected by this bug:

The jstack and jmap tests (and maybe attach tests too) were changed to silently pass
without execution on old Linux systems with LinuxThreads.
They have to be fixed back in the SDK build b68.

SUGGESTED FIX Please, see the corresponding SDK and HotSpot webrevs in attachments: sdk.Jan2.tar.gz and hs_pid.Dec20.tar.gz

EVALUATION The cause of this is that as part of the hsperf and dynamic attach connection mechanisms, HotSpot creates special filenames that contain the PID of the HotSpot Process. On linux-with-old-threads, before the fix 6316197, this was the linux primordial thread, whose PID was the value of $! After the fix, this PID is that of the new thread created by the launcher, thus it is different than the PID in $!.

SUGGESTED FIX The fix is to have the new launcher gets its PID (which will be that reported by the shell in $!) and pass it to the VM in a new command line property, eg, -Dsun.java.pid=<pid> The VM code for hsperf and dynamic attach will then use this pid instead of os::current_process_id(). Here is an outline of changes needed: SDK: - src/share/bin/java.c - main currently does this { /* Create a new thread to create JVM and invoke main method */ struct JavaMainArgs args; args.argc = argc; args.argv = argv; args.jarfile = jarfile; args.classname = classname; args.ifn = ifn; return ContinueInNewThread(JavaMain, threadStackSize, (void*)&args); } We would change it to add the -Dsun.java.pid=<my pid> to args if it is linux old threads. - Do other commands use java.c as a launcher? Would this be a problem for them? HotSpot - src/os/linux/vm/perfMemory_linux.cpp - change os::current_process_id() to if there is a sun.java.pid prop get it else os::current_process_id() But, one of these uses of the pid is to do a kill. Should that use current_process_id or the passed in pid? TBD. Are there other subtleties here? - src/os/linux/vm/attachListener_linux.cpp - same change as above - make sure the sys. props. are available when the above code is executed - make sure the sun.java.pid prop is not included any version of the props that is made visible to the user via java or jvmti - ?? *** (#1 of 1): [ UNSAVED ] ###@###.###