-
Bug
-
Resolution: Duplicate
-
P3
-
None
-
17
-
generic
-
generic
ADDITIONAL SYSTEM INFORMATION :
OpenJDK 17.0.1 (I tried OracleJDK 17 - the same problem) Ubuntu
A DESCRIPTION OF THE PROBLEM :
I have a java app (JDK13) running in a docker container. Recently I moved the app to JDK17 (OpenJDK17) and found a gradual increase of memory usage by docker container.
During investigation I found that the 'serviceability memory category' NMT grows constantly
Please find the detailed description:
https://stackoverflow.com/questions/70709971/what-is-serviceability-memory-category-of-native-memory-tracking/70716283
REGRESSION : Last worked in version 13
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run the attached source code:
java -Xmx512M -XX:NativeMemoryTracking=summary Test.java (runs lot ThreadMXBean#dumpAllThreads operations)
and check 'serviceability' section of jcmd YOUR_PID VM.native_memory summary
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
the memory category "serviceability" is not growing
ACTUAL -
the memory category "serviceability" is growing. There wasn't such problem on OpenJDK 13.0.1
---------- BEGIN SOURCE ----------
import java.lang.management.ManagementFactory;
import java.lang.management.ThreadInfo;
import java.lang.management.ThreadMXBean;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.TimeUnit;
public class Test {
private static final int RUNNING = 40;
private static final int WAITING = 460;
private final Object monitor = new Object();
private final ThreadMXBean threadMxBean = ManagementFactory.getThreadMXBean();
private final ExecutorService executorService = Executors.newFixedThreadPool(RUNNING + WAITING);
void startRunningThread() {
executorService.submit(() -> {
while (true) {
}
});
}
void startWaitingThread() {
executorService.submit(() -> {
try {
monitor.wait();
} catch (InterruptedException e) {
e.printStackTrace();
}
});
}
void startThreads() {
for (int i = 0; i < RUNNING; i++) {
startRunningThread();
}
for (int i = 0; i < WAITING; i++) {
startWaitingThread();
}
}
void shutdown() {
executorService.shutdown();
try {
executorService.awaitTermination(5, TimeUnit.SECONDS);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
public static void main(String[] args) throws InterruptedException {
Test test = new Test();
Runtime.getRuntime().addShutdownHook(new Thread(test::shutdown));
test.startThreads();
for (int i = 0; i < 12000; i++) {
ThreadInfo[] threadInfos = test.threadMxBean.dumpAllThreads(false, false);
System.out.println("ThreadInfos: " + threadInfos.length);
Thread.sleep(100);
}
test.shutdown();
}
}
---------- END SOURCE ----------
FREQUENCY : always
OpenJDK 17.0.1 (I tried OracleJDK 17 - the same problem) Ubuntu
A DESCRIPTION OF THE PROBLEM :
I have a java app (JDK13) running in a docker container. Recently I moved the app to JDK17 (OpenJDK17) and found a gradual increase of memory usage by docker container.
During investigation I found that the 'serviceability memory category' NMT grows constantly
Please find the detailed description:
https://stackoverflow.com/questions/70709971/what-is-serviceability-memory-category-of-native-memory-tracking/70716283
REGRESSION : Last worked in version 13
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run the attached source code:
java -Xmx512M -XX:NativeMemoryTracking=summary Test.java (runs lot ThreadMXBean#dumpAllThreads operations)
and check 'serviceability' section of jcmd YOUR_PID VM.native_memory summary
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
the memory category "serviceability" is not growing
ACTUAL -
the memory category "serviceability" is growing. There wasn't such problem on OpenJDK 13.0.1
---------- BEGIN SOURCE ----------
import java.lang.management.ManagementFactory;
import java.lang.management.ThreadInfo;
import java.lang.management.ThreadMXBean;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.TimeUnit;
public class Test {
private static final int RUNNING = 40;
private static final int WAITING = 460;
private final Object monitor = new Object();
private final ThreadMXBean threadMxBean = ManagementFactory.getThreadMXBean();
private final ExecutorService executorService = Executors.newFixedThreadPool(RUNNING + WAITING);
void startRunningThread() {
executorService.submit(() -> {
while (true) {
}
});
}
void startWaitingThread() {
executorService.submit(() -> {
try {
monitor.wait();
} catch (InterruptedException e) {
e.printStackTrace();
}
});
}
void startThreads() {
for (int i = 0; i < RUNNING; i++) {
startRunningThread();
}
for (int i = 0; i < WAITING; i++) {
startWaitingThread();
}
}
void shutdown() {
executorService.shutdown();
try {
executorService.awaitTermination(5, TimeUnit.SECONDS);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
public static void main(String[] args) throws InterruptedException {
Test test = new Test();
Runtime.getRuntime().addShutdownHook(new Thread(test::shutdown));
test.startThreads();
for (int i = 0; i < 12000; i++) {
ThreadInfo[] threadInfos = test.threadMxBean.dumpAllThreads(false, false);
System.out.println("ThreadInfos: " + threadInfos.length);
Thread.sleep(100);
}
test.shutdown();
}
}
---------- END SOURCE ----------
FREQUENCY : always
- duplicates
-
JDK-8273902 Memory leak in OopStorage due to bug in OopHandle::release()
-
- Closed
-