Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8214892

Delayed starting of debugging via jcmd

    XMLWordPrintable

    Details

    • Subcomponent:
    • Resolved In Build:
      b24
    • CPU:
      generic
    • OS:
      generic

      Backports

        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).

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  rrich Richard Reingruber
                  Reporter:
                  rrich Richard Reingruber
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  3 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: