The jvmstat tools will fail to attach to a JVM that has changed
its effective user id on Solaris. The solaris implementation of
the function that maps a pid to a uid use the effective user id
of the target process. However, some applications, such as BEA's
application server, startup as root in order to bind to a privileged
socket, and then execute a setuid() call via JNI in order to change
to an unprivileged user id. As a result, the JVM code maps the
target pid to the effective user id instead of real user id and
attempt to access the hsperfdata file in the wrong directory.

In this scenario, the jps tool will successfully report the process
identifier of the target jvm, but will not be able to report the
class name or other target specific information. It will generally
report: '-- process information unavailable'.

  xxxxx@xxxxx   2005-2-01 04:30:49 GMT

N/A

N/A

has there been a resolution for this? 

This is very important to monitor remote host

# ./java -version
java version "1.6.0_07"
Java(TM) SE Runtime Environment (build 1.6.0_07-b06)
Java HotSpot(TM) Server VM (build 10.0-b23, mixed mode)

$ ps -ef|grep java
 claudio 15593 15171   0 15:43:10 pts/15      0:00 grep java
webservd 21862  1142   0   Jul 11 ?          55:11 /opt/jdk_current/bin/java -Xss256k -Xmn48m -Xmx168m -Xverify:none -XX:+UseConcM

# id
uid=0(root) gid=0(root)

# /opt/jdk_current/bin/jps -l
15698 sun.tools.jps.Jps
21862 -- process information unavailable

# /opt/jdk1.6.0_07/bin/jstat -gcutil 21862
21862 not found

# /opt/jdk1.6.0_07/bin/jmap -heap 21862
Attaching to process ID 21862, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 10.0-b23
......
concurrent mark-sweep generation:
   capacity = 125829120 (120.0MB)
Free chunk in CMS heap, size=65536
Free chunk in CMS heap, size=1048
Free chunk in CMS heap, size=1048
Free chunk in CMS heap, size=256
Free chunk in CMS heap, size=256

a lot of free chunk messages, until ctrl+c

Exception in thread "main" java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at sun.tools.jmap.JMap.runTool(JMap.java:178)
        at sun.tools.jmap.JMap.main(JMap.java:110)
Caused by: java.lang.RuntimeException: VM.initialize() was not yet called
        at sun.jvm.hotspot.runtime.VM.getVM(VM.java:359)
        at sun.jvm.hotspot.oops.ObjectHeap.newOop(ObjectHeap.java:342)
        at sun.jvm.hotspot.memory.CompactibleFreeListSpace.getLiveRegions(CompactibleFreeListSpace.java:138)
        at sun.jvm.hotspot.memory.CompactibleFreeListSpace.used(CompactibleFreeListSpace.java:68)
        at sun.jvm.hotspot.memory.ConcurrentMarkSweepGeneration.used(ConcurrentMarkSweepGeneration.java:61)
        at sun.jvm.hotspot.tools.HeapSummary.printGen(HeapSummary.java:182)
        at sun.jvm.hotspot.tools.HeapSummary.run(HeapSummary.java:94)
        at sun.jvm.hotspot.tools.Tool.start(Tool.java:221)
        at sun.jvm.hotspot.tools.HeapSummary.main(HeapSummary.java:39)