Memory leaks on Linux with hardware renderer

Rahman USTA rahman.usta.88 at
Thu Jul 21 06:57:52 UTC 2016

Hello Kevin;

One of our user reported "Must be a memory leak somewhere" in AsciidocFX
project. It seems a similar issue.

You can see the issue here


2016-07-21 2:38 GMT+03:00 Kevin Rushforth <kevin.rushforth at>:

> I'll add a comment to that effect (although our incident triage team is
> good about spotting such duplicates).
> -- Kevin
> Itai wrote:
>> Thank you. Having gotten no reply, and seeing the bug report was closed
>> and with not means of commenting in the bug report system, I have since
>> (about an hour ago) filed a more detailed report (JI-9042009). I believe
>> they could be safely merged, but the second one does contain some more
>> info.
>> On Thu, Jul 21, 2016 at 2:27 AM, Kevin Rushforth <
>> kevin.rushforth at <mailto:kevin.rushforth at>> wrote:
>>     JI-9041860 has now been transferred to the JDK project as:
>>     Our support engineer was not able to reproduce the problem, so
>>     closed it as such. Based on the additional information you
>>     provided, I have reopened the bug and will ask someone on our team
>>     with a physical Linux setup to try to reproduce it.
>>     To answer your question, we are not aware of any such leaks.
>>     -- Kevin
>>     Itai wrote:
>>         I'm experiencing multiple memory leaks with JavaFX on Linux,
>>         to the point
>>         where I'm not sure which bug to report, as it seems like a
>>         systematic
>>         issue.
>>         The memory leak seems to be completely absent when using the
>>         software
>>         renderer (-Dprism.order=sw), and does not seem to happen on
>>         Windows
>>         (presumably not on Mac either, although I have no Mac to test it).
>>         Test cases include:
>>         1. Use ProgressIndicator with progress set to Indeterminate -
>>         with default
>>         (HW) renderer memory consumption quickly rises, climbing to
>>         8GB and more if
>>         not killed. With software renderer memory usage is reasonable.
>>         2. Using Scene Builder - after a few minutes with Scene
>>         Builder it quickly
>>         gobbles up all system memory - again, problem seems to go away
>>         if using
>>         software renderer. This test is less repeatable, as some
>>         actions seem more
>>         detrimental than others.
>>         3. Using Transitions on nodes (See attached code "".
>>         I have filed
>>         a bug report about this issue, JI-9041860). Running with
>>         default renderer
>>         the simple program reaches 3GB within 30 seconds, and memory
>>         continues to
>>         climb. On software renderer memory consumption remains <100MB
>>         for a minute
>>         and more.
>>         As I said, I am no longer sure it is prudent to report
>>         specific bugs, as
>>         this seems to be some low-level problem. I just want to know
>>         if this is a
>>         known issue and if there is any way to get around it (besides
>>         using the
>>         software pipe, which obviously has it's own disadvantages).
>>         For reference, I'm using Debian (testing, updated today),
>>         kernel version
>>         4.6.2, Intel HD4000 GPU, Intel driver version 2.99.917 (kms
>>         driver),
>>         OpenJDK version 1.8.0_91-8u91-b14-3-b14 (behavior is identical
>>         on Oracle
>>         version).
>>         If there is any other information needed please let me know.
>>         If this is a
>>         known issue I apologize, but I have tried searching and didn't
>>         find any
>>         reports of such behavior.
>>         Thank you.

Rahman USTA
Istanbul JUG <>

More information about the openjfx-dev mailing list