Memory leaks on Linux with hardware renderer
Chien Yang
chien.yang at oracle.com
Thu Aug 11 22:39:16 UTC 2016
Based on my recollection, this oddity (2 contexts) is because we use
CALayer on Mac. We have tested in early prototype, when we did the
switch from JOGL to native GL, Prism implementation on Linux works fine
with a single GL context.
- Chien
On 8/11/2016 2:08 PM, Jim Graham wrote:
> It looks like we create a dummy drawable for the context and install
> it when we are done with the frame. This appeared in rev
> bbb8d2772b37, but it looks like that revision involved removing the
> unnecessary RenderingContext class, so we may have been doing
> something similar via the RenderingContext class and the code was
> merely moved into SwapChain when the other class was deleted. Further
> investigation would be needed, but my mercurial rev/diffing skills are
> pretty primitive. Anyone care to dig a little on this and figure out
> if there is a reason for us to unset the drawable at the end of a frame?
>
> In either case, if we had 2 windows open, and that will happen if
> there is a simple popup on a choice box or a menu item I think
> unfortunately, then we'd still have the problem so whether or not it
> happens with a single window with no popup items in it, it still looks
> like we could potentially trigger this in common cases anyway. We
> should track the fix to GLX and make sure we document required patches
> if there is a fix...
>
> ...jim
>
> On 8/11/16 6:13 AM, Itai wrote:
>> I'm sorry to see the issue could still not be reproduced on any OpenJFX
>> team members.
>>
>> Meanwhile, I have noticed a user on reddit (JavaFX sub-reddit) had
>> the same
>> issue:
>> https://www.reddit.com/r/JavaFX/comments/4nr2ln/memory_leak_when_calling_imageviewsettranslatex/
>>
>> .
>> However, they have managed to profile it (VisualVM has a bug making it
>> nearly impossible to CPU profile JavaFX programs), and found out a
>> lot of
>> time is taken by `com.sun.prism.es2.X11GLContext.makeCurrent`.
>>
>> Taking this lead, I have found this:
>> http://www.gamedev.net/topic/679705-glxmakecurrent-slowly-leaks-memory/
>>
>> Sadly I don't know enough about OpenGL to understand most of it, but it
>> seems to me like it's the same issue, so possibly it's not a Java
>> issue at
>> all. However, maybe it can be avoided? In this linked post it is
>> mentioned
>> that the leak only happens when having two windows, but in JavaFX this
>> always happens, so maybe there is a redundant call to `makeCurrent`?
>>
>> Hope this helps to find the source of the problem, and if it's indeed
>> outside of Java/JavaFX scope - report it to the relevant project.
>>
>> On Thu, Jul 21, 2016 at 6:12 PM, Kevin Rushforth
>> <kevin.rushforth at oracle.com
>>> wrote:
>>
>>> Thanks. I added this to the bug report for
>>> https://bugs.openjdk.java.net/
>>> browse/JDK-8161911
>>>
>>> -- Kevin
>>>
>>>
>>>
>>> Rahman USTA wrote:
>>>
>>> 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 <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
>>>>> 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.
>>>>>
>>>>>
>>>>>
>>>
>>>
>>> --
>>> Rahman USTA
>>> Istanbul JUG
>>> https://github.com/rahmanusta <http://www.kodcu.com/>
>>>
>>>
More information about the openjfx-dev
mailing list