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