On Thu, 19 Jan 2023 00:46:22 GMT, Jaikiran Pai <[email protected]> wrote:
>> Fix JDI leak when the debuggee creates a lot of threads, while at the same
>> the debugger is not sending any commands. The lack of commands being sent
>> results in code not being triggered that normally would clear out
>> unreachable listeners and also clear out ObjectReferences queued for
>> disposal.
>
> src/jdk.jdi/share/classes/com/sun/tools/jdi/VMState.java line 177:
>
>> 175: private void removeUnreachableListeners() {
>> 176: boolean found = false;
>> 177: while (listenersReferenceQueue.poll() != null) {
>
> Hello Chris, I have no prior knowledge of this code, so this is just a casual
> observation - should this change here be a `if` instead of a `while`? I see
> that this `removeUnreachableListeners()` gets called whenever a new listener
> is being added in `addListener(...)`. With the use of `while`, is this
> intentionally waiting for the GC to kick in and add at least one reference
> object to this queue?
No, because we have to clear the queue. This code could have been written as:
boolean found = listenersReferenceQueue.poll();
while (listenersReferenceQueue.poll() != null);
But you are partly right in that `removeUnreachableListeners()` doesn't really
do anything until after a GC has triggered adding some objects to the queue.
When there is one, there are probably a bunch, and they'll all get handled by
the code below the above code. If there are none on the queue, then this method
doesn't really do anything and has almost no overhead.
-------------
PR: https://git.openjdk.org/jdk/pull/12081
