JDK-8214892 : Delayed starting of debugging via jcmd
  • Type: Enhancement
  • Component: core-svc
  • Sub-Component: debugger
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2018-12-05
  • Updated: 2024-07-17
  • Resolved: 2018-12-12
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 11 JDK 12 JDK 13
11.0.3Fixed 12 b24Fixed 13Fixed
Related Reports
CSR :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
Description

The jdwp debugging agent currently allows the debugging to be started delayed when specific exceptions are thrown via the onthrow=<exception> option. Additionally it can be started delayed on any uncaught exception via the onuncaught=y option. We propose a third way to start up debugging delayed, namely via a jcmd command.

The user has to specify the oncmd=y option on the jdwp command line. Analog to the onthrow/onuncaught options, it requires server=y too (which is required indirectly for onthrow/onuncaught, since they require the launch= option to be set, which is only supported for the server=y case). If the option is set, debugging is not directly fully initialized. The user can then really start the debugging via the VM.start_java_debugging jcmd later. Using the jcmd later again will have no impact, since debugging was already started.

Implementation

The implementation is mostly analog to the onthrow and onuncaught options. We avoid the direct call to initialize() by setting the initOnStartup variable to JNI_FALSE. When the startup of the backend is later requested via the VM.start_java_debugging jcmd, we check if oncmd=y was given and the initialize method was not yet called. If true, we call the initialize method, which will fully start the debugging backend, including the transports. Note that the initialize() method currently requires a JVMTI event type to be supplied, for which later an event is created to put in the event queue. Since we don't need this, we supply an invalid event type and filter it out in the initialize method. Alternatively sending a VM_INIT event seems to work fine too.

We have to call from the hotspot code to the jdwp agent to trigger the startup. To do this we have opted to include an exported JNI function in the jdwp agent with a specific name. The jcmd handler in the hotspot then iterates all loaded agents and looks for one called "jdwp". Then we check if this agent has exported the debugInit_startDebuggingViaCommand function. If yes, we use this method to start the debugging.

The VM.start_java_debugging jcmd will print an error message if the debugInit_startDebuggingViaCommand could not be found in a jdwp agent or if the oncmd option was not set to y. Otherwise it will indicate if the debugging was started for the first time or was already started. In both cases we also include the transport name and address, so the user knows how to connect to the VM.

Alternative implementations

Instead of finding the debugInit_startDebuggingViaCommand in the agent libraries, the debugging agent could register a pointer to the function by calling a specific Java method. We opted not to do it because a function pointer (especially when calling between libraries) might not be a simple pointer. And since we cannot call Java in the Agent_OnLoad() function, there is no naturally called function to register the pointer (one could use a different callback for VM_INIT to circumvent this).
Comments
There was some discussion on the "onjcmd" choice during the review. Note it was originally "oncmd" http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-December/026343.html From [~cjplummer]: The help for "oncmd" says "debug triggered by jcmd?". I think your use of "cmd" should be more consistent. It's a dcmd providing the service, and jcmd is just one way to get at the dcmd. I'm not sure of the best way to convey this simply in the option name and help, but it should be consistent. "ondcmd" is probably most accurate, but "onjcmd" is probably what is most meaningful to users. I don't think it makes sense to use "oncmd" if the help is referring to jcmd. From [~rschmelter]: Regarding the name of the option, I agree that onjcmd, while not technically fully accurate, makes most sense for the common user.
07-05-2019

I think the "feature" also needs discussion as to whether it make sense or not. The sub-option name is also very strange and would be useful to see the alternatives that were explored.
07-05-2019

Yes, new or updated command line option handling requires a CSR. A retroactive CSR should be filed in a case like this.
07-05-2019

This change involves an interface change so I think should have a CSR (I realize the change has been pushed).
07-05-2019

Fix Request This change provides a little enhancement to the start of Java Debugging. The risk is low as it doesn't interfere with existing debug functionality. It applies cleanly.
14-12-2018

URL: http://hg.openjdk.java.net/jdk/jdk/rev/21dfea980e23 User: clanger Date: 2018-12-12 11:45:01 +0000
12-12-2018

I created this issue for Ralf Schmelter. He is working on it, but hasn't got a JBS account yet.
05-12-2018