JDK-8176828: jtools do not list VM process launched with the debugger option suspend=y

[Gary Adams]

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  }
>>>
>>>
>>
>>
>
>