RFR: 8265505: findsym does not work on remote debug server [v2]

Yasumasa Suenaga ysuenaga at openjdk.java.net
Tue Apr 20 23:36:05 UTC 2021


On Tue, 20 Apr 2021 18:14:14 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unused imports
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java line 603:
> 
>> 601:                 } else {
>> 602:                     String result = VM.getVM().getDebugger().findSymbol(t.nextToken());
>> 603:                     out.println(result == null ? "Symbol not found" : result);
> 
> The import of sun.jvm.hotspot.debugger.cdbg.CDebugger is no longer needed in this file.
> 
> I think the more traditional approach would be to add remote support for LoadObject. That provides the building blocks needed here. It's harder to do, but might have some benefit down the road, although it's hard to say if there would ever be other users of it.

I removed both CDebugger and LoadObject from CommandProcessor.java in new commit.

> I think the more traditional approach would be to add remote support for LoadObject. That provides the building blocks needed here. It's harder to do, but might have some benefit down the road, although it's hard to say if there would ever be other users of it.

Agree. I saw similar issue in `dis`, `disassemble`, `dumpcodecache`, and `livenmethods`. I hope they will be fixed, and I believe remote support for LoadObject helps it. (They can be fixed in Disassembler.java)

I think LoadObject should be Serializable if we do so, but it might make big impact for the classes which implements LoadObject (e.g. DSO.java). It might be harder and we might have no more users for it as you said, so I decided to delegate the process to remote debug server.

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

PR: https://git.openjdk.java.net/jdk/pull/3582


More information about the serviceability-dev mailing list