RFR: 8332488: Add JVMTI DataDumpRequest to the debug agent. [v3]

Chris Plummer cjplummer at openjdk.org
Thu Aug 8 21:01:33 UTC 2024


On Thu, 8 Aug 2024 20:06:08 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> JVMTI has a somewhat unique event called DataDumpRequest. One way it is triggered is via the JVMTI.data_dump jcmd, which causes JVMTI to send the DataDumpRequest event to all agents that have registered for the event callback. The agent is free to do pretty much what it wants during the callback, but the normal usage is to dump anything that might be useful for debugging the agent. In the case of the debug agent, it could dump internal data like the list of known threads and event handlers. After ranked monitor support is complete, it can also dump the state of all jvmti raw monitors that the debug agent uses.
>> 
>> I decided to not enable this feature by default, and not make public the option to enable it. This should only be used by developers working on the debug agent, or by users when requested to do so (by debug agent developers) to help debug a debug agent problem.
>> 
>> Most of the code executed during the data dump was only available for debug builds, so I've made it available for all builds. Their addition does not affect product builds except for adding a small footprint.
>> 
>> TBD is directing the output to a file. This is useful for some of the debugger tests that don't include the debuggee output in the log. This seems to be the case for most com/sun/jdi tests. I decided not to include it for this first pass since it is rather disruptive and detracts from the main changes being made.
>> 
>> testing tbd: run all tier1, tier2, and. tie5 svc tests.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improved comments.

FYI, this is what the (entire) debuggee output looks like for this test:


Deuggee output:
Listening for transport dt_socket at address: 42509
Debug Agent Data Dump
=== START DUMP ===
suspendAllCount: 0
Dumping runningThreads:
Thread: node = 0x149684000f10, jthread = 0x1497504da382
	name: Notification Thread
	suspendCount: 0
Thread: node = 0x14969c000f10, jthread = 0x1497504da352
	name: Common-Cleaner
	suspendCount: 0
Thread: node = 0x149750583a60, jthread = 0x1497504da332
	name: Attach Listener
	suspendCount: 0
Thread: node = 0x1497505835c0, jthread = 0x1497504da32a
	name: Signal Dispatcher
	suspendCount: 0
Thread: node = 0x149750583120, jthread = 0x1497504da322
	name: Finalizer
	suspendCount: 0
Thread: node = 0x149750582c50, jthread = 0x1497504da31a
	name: Reference Handler
	suspendCount: 0
Thread: node = 0x1497505827b0, jthread = 0x1497504da312
	name: main
	suspendCount: 1

Dumping runningVThreads:

Dumping otherThreads:

Handlers for EI_CLASS_PREPARE(7)
node(0x1496a40034e0) handlerID(4) suspendPolicy(1) permanent(0)
ClassMatch: classPattern(DataDumpTestTarg)
node(0x1496a4002d80) handlerID(2) suspendPolicy(0) permanent(0)

Handlers for EI_CLASS_UNLOAD(8)
node(0x1496a4002de0) handlerID(3) suspendPolicy(0) permanent(0)

Handlers for EI_VM_DEATH(20)
node(0x1496a4004a20) handlerID(0) suspendPolicy(0) permanent(1)
=== END DUMP ===
Debuggee started

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20367#issuecomment-2276641888


More information about the serviceability-dev mailing list