Followup in
RFR: JDK-8231587: Memory leak in WorkArounds.serializedForms Jonathan
Gibbons
https://mail.openjdk.java.net/pipermail/javadoc-dev/2019-October/001167.html
-- Jon
On 10/08/2019 01:43 PM, Florian Weimer wrote:
* Jonathan Gibbons:
I do not see any evidence of any additional leak,
* Jonathan Gibbons:
> I do not see any evidence of any additional leak, despite my best efforts
> to find one.
Sorry, I can't reproduce it either. I must have looked at the wrong
heap dump, or a heap dump that wasn't restricted to just live data.
So removing the static is sufficient after all.
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 coul
* 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
>
On 9/28/19 2: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
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: http
Florian,
Thank you for identifying and reporting this issue.
I will investigate it. It is likely the item is a cache, but as a general
rule, javadoc (and javac) try and avoid the use of static caches.
-- Jon
On 9/27/19 2:11 AM, Florian Weimer wrote:
It seems that it's currently very difficult
It seems that it's currently very difficult to use the javadoc tool in
a long-running VM because there is a severe memory leak.
This appears to be related to the class
jdk.javadoc.internal.doclets.toolkit.WorkArounds, specifically the
field serializedForms. It looks like elements are never remove
