On Wed, 28 Aug 2024 21:40:57 GMT, Chris Plummer <cjplum...@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
