Details
Backports
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8160208 | 8u112 | Jim Graham | P3 | Resolved | Fixed | b02 |
Description
Repeated drawing of Paths appears to slowly leak native memory. A project is attached that can be run with gradle.
The test code paints 100 paths repeatedly. While it is running, observe the process memory usage with a tool like Process Explorer or Task Manager on Windows, or Activity Monitor on OS X.
To be sure there is a real native leak, limit the Java heap and allow the program to run for 30 minutes or so, recording the processes totally memory usage every 5 minutes. Memory fluctuations early on can make it difficult to see that the memory usage of the process steadily climbs.
Using a tool like jvisualvm you can see that Java heap is not leaking.
The leak is present with -Dprism.order=sw as well as using the GPU accelerated pipeline.
Using jvisualvm to trigger GC has no effect on the native memory usage. (My thinking is that a finalizer might be used to reclaim native resources.)
The test code paints 100 paths repeatedly. While it is running, observe the process memory usage with a tool like Process Explorer or Task Manager on Windows, or Activity Monitor on OS X.
To be sure there is a real native leak, limit the Java heap and allow the program to run for 30 minutes or so, recording the processes totally memory usage every 5 minutes. Memory fluctuations early on can make it difficult to see that the memory usage of the process steadily climbs.
Using a tool like jvisualvm you can see that Java heap is not leaking.
The leak is present with -Dprism.order=sw as well as using the GPU accelerated pipeline.
Using jvisualvm to trigger GC has no effect on the native memory usage. (My thinking is that a finalizer might be used to reclaim native resources.)
Attachments
Issue Links
- backported by
-
JDK-8160208 JavaFX Path drawing appears to leak native memory
-
- Resolved
-