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 https://github.com/asciidocfx/AsciidocFX/issues/227 Thanks. 2016-07-21 2:38 GMT+03:00 Kevin Rushforth <[email protected]>: > 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 < >> [email protected] <mailto:[email protected]>> 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. >> >> >> -- Rahman USTA Istanbul JUG https://github.com/rahmanusta <http://www.kodcu.com/>
