On Mon, 28 Sep 2026 16:47:02 GMT, Kevin Walls <[email protected]> wrote:
>> This implements "jcmd on core files" for Linux, and for MiniDumps on Windows >> (MacOS is "future work"). >> jcmd "revives" the VM memory and .so/.dll from the core/minidump, and runs >> the existing native diagnostic command parser and command implementations. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Kevin Walls has updated the pull request incrementally with one additional > commit since the last revision: > > feedback and test update Various updates, including Attach-related changes: (1) Separate AttachProvider for core files. JCmd.java (or any app) can iterate providers itself if it wants to specifically choose the core file provider. The existing HotSpotAttachProvider (extends AttachProvider) is a base class for existing platform-specific AttachProviderImpl and the new CoreDumpAttachProviderImpl (also platform-specific). (2) On the VirtualMachine side: HotSpotVirtualMachine (extends VirtualMachine) is not the public documented API, but is the implementation-specific "hotspot api", various tools cast the result of an attach to a HotSpotVirtualMachine. So HotSpotVirtualMachine needs to be the type returned by attach operations for cores or live (otherwise JCmd.java gets ugly, needing to deal with such specifics). The executeJCmd method continues being defined in HotSpotVirtualMachine, and is usable by pid and core file users alike. Move live pid specifics out of HotSpotVirtualMachine into new subclass HotSpotVirtualMachineLive, to be seprate from the core file impl. The existing platform-specific VirtualMachineImpl classes all extend HotSpotVirtualMachineLive (so the hierarchy changes a little but not any names of classes people might expect to be there). Core dump handling has a few platform-specifics to it, so use a HotSpotVirtualMachineCoreDump (extends HotSpotVirtualMachine) class for the common code, and a VirtualMachineCoreDumpImpl class extending that, for the platform-specifics. (3) Attach attempts only show one Exception, but possibly multiple providers were tried. Two providers could each give an Exeption, and we can't tell which will be shown (the "last" one...). Create an error message, using the message text from all providers. This means a test that expects an error from an attach operation that expects some specific text, will still work (I only see the recent test/jdk/com/sun/tools/attach/JvmTempDirTest.java doing this). (4) Previously, on Windows, VirtualMachineImpl (platform-specific) would let the NumberFormatException be thrown, unlike the Linux impl which catches it and throws AttachNotSupportedException, letting the AttachProvider iteration continue. Make Windows behave like Linux. ------------- PR Comment: https://git.openjdk.org/jdk/pull/31011#issuecomment-5876874238
