RFR: JMC-6556 JFR V1 Parser memory leak
Erik Gahlin
erik.gahlin at oracle.com
Mon Aug 26 16:31:04 UTC 2019
Looks good.
Another problem with a static is that type id could differ between
recordings or attributes could be added to type in a newer release.
As long as you only open one recording per JMC instance you will be
fine, but pretty high risk it can go wrong if you open multiple
recordings from different releases.
Erik
> Hi all,
>
> JIRA: https://bugs.openjdk.java.net/browse/JMC-6556
>
> This fixes a small memory leak where the number of attributes added to a
> StructContentType object grows unbounded while recordings are being parsed.
>
> ---
> a/core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/TypeManager.java
> +++
> b/core/org.openjdk.jmc.flightrecorder/src/main/java/org/openjdk/jmc/flightrecorder/internal/parser/v1/TypeManager.java
> @@ -116,7 +116,7 @@
> }
>
> // NOTE: Using constant pool id as identifier.
> - private static final Map<Long, StructContentType<Object[]>> STRUCT_TYPES
> = new HashMap<>();
> + private final Map<Long, StructContentType<Object[]>> STRUCT_TYPES = new
> HashMap<>();
>
> private class TypeEntry {
> private static final String STRUCT_TYPE_CLASS = "java.lang.Class";
> //$NON-NLS-1$
>
>
> Cheers,
> Henrik Dafgård
More information about the jmc-dev
mailing list