On behalf of Ekaterina Vergizova (katya@azul.com):
The leak is jdk.jfr.internal.TypeLibrary keeps on holding to jdk.jfr.internal.PlatformEventType instances even when the underlying classes are unloaded.
This can for example happen when you redeploy a web application that contains custom JFR events.
To reproduce run the attached jar with the following command line arguments:
java -Xmx64m -Xms64m -XX:MetaspaceSize=64m -XX:MaxMetaspaceSize=64m -XX:+HeapDumpOnOutOfMemoryError -XX:+UseSerialGC -jar jfr-leaker-0.1.0-SNAPSHOT.jar
The heap and metaspace sizes are limited to have the OutOfMemoryError happen earlier. The error also happens with bigger sizes, it just takes longer.
SerialGC is used because of the small heap size, but the bug also happens with other GCs.
The source code can be found here: https://github.com/marschall/jfr-leaker
The leak is jdk.jfr.internal.TypeLibrary keeps on holding to jdk.jfr.internal.PlatformEventType instances even when the underlying classes are unloaded.
This can for example happen when you redeploy a web application that contains custom JFR events.
To reproduce run the attached jar with the following command line arguments:
java -Xmx64m -Xms64m -XX:MetaspaceSize=64m -XX:MaxMetaspaceSize=64m -XX:+HeapDumpOnOutOfMemoryError -XX:+UseSerialGC -jar jfr-leaker-0.1.0-SNAPSHOT.jar
The heap and metaspace sizes are limited to have the OutOfMemoryError happen earlier. The error also happens with bigger sizes, it just takes longer.
SerialGC is used because of the small heap size, but the bug also happens with other GCs.
The source code can be found here: https://github.com/marschall/jfr-leaker
- duplicates
-
JDK-8154952 Memory leak with JFR event handlers
-
- Closed
-