On Wed, 17 Mar 2021 04:55:27 GMT, Chris Plummer <cjplum...@openjdk.org> wrote:
> Do we have any issues with any other clhsdb commands that rely CDebugger. I > haven't looked into the implementation, but I'm suspicious of `thread`, > `threads`, `findpc` of an address in the executable, and `findsym`. Yes, I confirmed `findsim` has same issue on remote debugger. It will be fixed if `findsym` use `execCommandOnServer()` in this PR, but it is not in this scope now. > And speaking of CDebugger, the SA "debugger" hierarchy is too heavily > abstracted. I counted about 18 classes and interfaces that have "Debugger" in > their name, and some of the interfaces get inherited more than once. I really > wonder if it has to be that complex. My first adventure into this mess was > for [JDK-8239062](https://bugs.openjdk.java.net/browse/JDK-8239062), a time > when I knew close to nothing about SA. Was not fun and I eventually gave up. > You might want to have a look at the CR, if not just to add some comments and > maybe enlighten me on some things. I agree with you that Debugger (includes Debugger) and their inheritances are very complex, but it is very difficult to refactor IMHO - it could be the same as creating SA from scratch. It would be better if all commands run on client side of course, but it seems to be difficult, thus I decided to run some primitive commands (e.g. pmap, pstack) are run on server side (debugd). If this PR is integrated, [JDK-8239062](https://bugs.openjdk.java.net/browse/JDK-8239062) also can be fixed because it may be able to run on debugd. OTOH this PR could be more complex to SA implementation for remote debugger, but I have no idea to fix this problem without refactoring (C)Debugger interfaces. ------------- PR: https://git.openjdk.java.net/jdk/pull/3027
