https://bugs.openjdk.java.net/browse/JDK-8156537
  - Added a fix for module naming

https://bugs.openjdk.java.net/browse/JDK-8176533
  - Fixed a regression from JDK-816537 that prevented "jcmd <pid> <cmd>"
     from sending <cmd> to <pid>

https://bugs.openjdk.java.net/browse/JDK-8176828
  - Requests that "jcmd -l" should list the <pid>
     for the VM that has not completed initialization.
     This is not a regression, because jdk8 jcmd did
     not display the uninitialized VM either.

It appears you can send "jcmd <pid> <cmd>" to
the process that has not completed vm initialization.

On 11/28/18, 2:29 PM, Chris Plummer wrote:
Sorry, meant to say "before JDK-8176533".

Chris

On 11/28/18 10:11 AM, Chris Plummer wrote:
Hi Gary,

This seems reasonable. I just want clarification on one thing first. Before JDK-8176828, it listed the suspend=y process, but could you do anything with it? I'm assuming no, and therefore it makes sense not to list it at all.

thanks,

Chris

On 11/28/18 8:33 AM, Gary Adams wrote:
I'd like to close JDK-8176828 as will not fix.
  https://bugs.openjdk.java.net/browse/JDK-8176828

This bug was originally thought to be associated with
a regression fix in JDK-8176533, but I believe there
is simply a misunderstanding of how the "suspend=y"
behavior is supported for the jdwp agent library.

The "suspend=y" setting is designed to maximize the number
of events that can been seen by an attaching debugger.
This calls for the process to be waiting for the debugger connection
before the VM has been completely initialized.

In particular, the thread.cpp create_vm() function causes the
debugInit.c initialize() function to start the transport connection
and wait for an external debugger to attach. Once the dt_socket connection
is established the create_vm() function will complete. It is the
processing of the create_vm_timer.end() that results in the
management.cpp record_vm_startup_time() and the
PerfMemory::set_accessible(true) to be set.

Without the accessible field being set an external program can not use
the PerfMemory. That is why "jcmd -l" passes over processes which
do not have an initialized VM running.

=====
src/hotspot/share/runtime/:
src/jdk.jdwp.agent/share/native/libjdwp/:

thread.cpp:3587:jint Threads::create_vm(JavaVMInitArgs* args, bool* canTryAgain) {
  ...
  thread.cpp:3610:  create_vm_timer.start();
  ...
  thread.cpp:3907:  JvmtiExport::post_vm_initialized();
  ...
debugInit.c:432:cbEarlyVMInit(jvmtiEnv *jvmti_env, JNIEnv *env, jthread thread)
    ...
debugInit.c:103:static void initialize(JNIEnv *env, jthread thread, EventIndex triggering_ei);
    ...
debugInit.c:732: (void)bagEnumerateOver(transports, startTransport, &arg);
    ...
    debugInit.c:751:    transport_waitForConnection();
  ...
  thread.cpp:3955:  create_vm_timer.end();

====
src/hotspot/share/services/management.cpp:

203 void Management::record_vm_startup_time(jlong begin, jlong duration) {
   204    // if the performance counter is not initialized,
   205    // then vm initialization failed; simply return.
   206    if (_begin_vm_creation_time == NULL) return;
   207
   208    _begin_vm_creation_time->set_value(begin);
   209    _end_vm_creation_time->set_value(begin + duration);
   210    PerfMemory::set_accessible(true);
   211  }







Reply via email to