Memory leaks on Linux with hardware renderer
rahman.usta.88 at gmail.com
Thu Jul 21 06:57:52 UTC 2016
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 oracle.com>:
> 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
>> On Thu, Jul 21, 2016 at 2:27 AM, Kevin Rushforth <
>> kevin.rushforth at oracle.com <mailto:kevin.rushforth at oracle.com>> 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
>> The memory leak seems to be completely absent when using the
>> renderer (-Dprism.order=sw), and does not seem to happen on
>> (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 "Demo.java".
>> 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
>> OpenJDK version 1.8.0_91-8u91-b14-3-b14 (behavior is identical
>> on Oracle
>> 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.
More information about the openjfx-dev