Memory leak in jdk.javadoc.internal.doclets.toolkit.WorkArounds

[Jonathan Gibbons]

On 09/28/2019 02:01 AM, Florian Weimer wrote:
> * Jonathan Gibbons:
>
>> Florian,
>>
>> I looked at the code: this is definitely a design bug.
>>
>> There appears to be no reason for it to be static, and removing the
>> `static` modifier
>> does not cause any compilation issues.
>>
>> There's some minor cleanup we could do in this area as well, to use
>> Map::computeIfAbsent,
>>
>> Filed: https://bugs.openjdk.java.net/browse/JDK-8231587
> Thanks.
>
> I removed the static keyword and the leak is gone if I do not reuse
> the DocumentationTool object.  However, there is still a leak if I
> recycle the tool object.  (This does not happen with the javac tool
> object, I think.)
>
> So it's an improvement in the sense that there is now an easy
> workaround, but the fix isn't quite complete yet.

Florian,

I do not see any evidence of any additional leak, despite my best efforts
to find one.

My experiment has been to repeatedly run javadoc on java.base/java.lang,
reusing the DocumentationTool object. I also do not see anything in
the impl of DocumentationTool that would cause it to hang on to any
state.  When I watch the memory usage in VisualVM, I see the increased
usage before the fix, and a "steady sawtooth" after the fix is applied.

Is there anything about your experiments that might be causing it to
be consuming more memory?

Note that there are some caches using soft references that may cause
the memory graph to show some increased memory usage until GC kicks in.

-- Jon