On Tue, 15 Feb 2022 06:31:46 GMT, Chris Plummer <cjplum...@openjdk.org> wrote:

>> Zhengyu Gu has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   David and Chris' comments
>
> src/jdk.jdwp.agent/share/native/libjdwp/classTrack.c line 65:
> 
>> 63:  * handler may acquire the same monitor(s), e.g. classTrackLock in 
>> cbTrackingObjectFree(),
>> 64:  * which can lead to deadlock.
>> 65:  */
> 
> The debug agent does a lot alloc/dealloc calls while processing JVMTI events 
> and holding locks. So the question is why this is not problematic other than 
> this classTrackLock issue. I believe the answer is that 
> cbTrackingObjectFree() is unique in that it is handled outside of the debug 
> agent's normal event handling code, which is serialized. 
> cbTrackingObjectFree() is called so the debug agent can maintain a list of 
> loaded classes, and is not an event that gets passed on to the debugger like 
> most JVMTI events are. So we have a case here where classTrackLock can be 
> grabbed by both "typical" JVMTI event handling code via the 
> classTrack_processUnloads() call, and then this special 
> cbTrackingObjectFree() event handling.
> 
> I think having this comment here doesn't help the reader of the code below 
> unless they somehow read the comment first and then recognized it's 
> application in the code below. At the very least the code below should 
> tersely state while the lock is being released, and then refer to this 
> comment for details.

I moved comments inside `classTrack_processUnloads()`, let me know if you 
prefer other places.

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

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

Reply via email to