-
Bug
-
Resolution: Fixed
-
P4
-
7u55, 8u5
After a number of opening/disposing very long media files we may run out of the native memory while the Java heap is almost free. That leads to inability to open a media until the first full GC. No crashes observed.
When the moov table is parsed the qtdemuxer asks to read that table in a single block. For 12hr mp4 that requires about 50Mb. The stream java source allocates direct ByteBuffer when asked for readBlock(). For reading the moov table the direct ByteBuffer of 50Mb is allocated. The problem is that this native memory could be released only when the instance of this ByteBuffer is garbage collected and thus native memory may leak even if the MediaPlayer.dispose() is called when closing media.
Since there is no API for controlling media source stream operations the only workaround is to call System.gc() after MediaPlayer.dispose(), though no guarantees here of course.
When the moov table is parsed the qtdemuxer asks to read that table in a single block. For 12hr mp4 that requires about 50Mb. The stream java source allocates direct ByteBuffer when asked for readBlock(). For reading the moov table the direct ByteBuffer of 50Mb is allocated. The problem is that this native memory could be released only when the instance of this ByteBuffer is garbage collected and thus native memory may leak even if the MediaPlayer.dispose() is called when closing media.
Since there is no API for controlling media source stream operations the only workaround is to call System.gc() after MediaPlayer.dispose(), though no guarantees here of course.
- blocks
-
JDK-8094930 Memory-Leak in Media Components
- Closed
- relates to
-
JDK-8115891 JavaFx MediaView hangs when I used large video files
- Resolved
-
JDK-8195803 Eliminate use of sun.nio.ch.DirectBuffer in javafx.media
- Resolved
1.
|
Backport to 2.2 | Resolved | Anton Nashatyrev (Inactive) |