Memory leaks on Linux with hardware renderer

[Kevin Rushforth]

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 oracle.com <mailto:kevin.rushforth at oracle.com>> wrote:
>
>     JI-9041860 has now been transferred to the JDK project as:
>
>     https://bugs.openjdk.java.net/browse/JDK-8161911
>
>     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 "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
>         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.
>          
>
>