RFR: 8338708: Don't create/destroy debug agent cmdQueueLock for each connection.

[Leonid Mesnik]

On Wed, 28 Aug 2024 21:40:57 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Only allocate the cmdQueueLock once rather than allocate each time there is a new connection (and destroy when the connection is terminated).
> 
> Currently each time there is a new debug agent connection established, the cmdQueueLock is allocated. It is then destroyed when the connection is dropped, only to be recreated on the next connection. I looked closely at the use of this lock, and what happens when the connection is dropped, and I can't see any reason to create and then dispose of cmdQueueLock for each connection. Of the 18 debug agent raw monitors, this is the only one that gets destroyed and recreated. The other 17 stick around for the next connection. I'd like to get rid of this reallocation in order to support static initialization of all the debug agent raw monitors on startup. This will be done as part of the ranked monitor support ([JDK-8328866](https://bugs.openjdk.org/browse/JDK-8328866)).
> 
> As part of the testing for this change, I put an assert in place when we try to create cmdQueueLock for the 2nd time. I ran all our debugger tests, and unfortunately none of them failed. This means we don't currently test attaching to the debug agent more than once in any of our tests, so I did two things to better test out this change. The first was to write a test that attaches numerous times in sequence, and the 2nd was to manually attach and reattach using jdb. At the same time I stepped through the debug agent code in gdb just to help better understand the setup and use of cmdQueueLock. I didn't see anything that gave me concern about making this change.
> 
> Tested by running all jdi, jdwp, and jdb tests on all supported platforms.

src/jdk.jdwp.agent/share/native/libjdwp/debugLoop.c line 90:

> 88:     /* We may be starting a new connection after an error */
> 89:     cmdQueue = NULL;
> 90:     if (cmdQueueLock == NULL) {

Doesn't it makes sense to check that lock is not locked here?
Is there possibility that lock is left locked for disconnected process or any other similar timeout. Probably it is not covered by our tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20755#discussion_r1739149630