Memory leaks on Linux with hardware renderer

[Itai]

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.

[Kevin Rushforth]

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

Post by Itai
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).
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.

[Kevin Rushforth]

I'll add a comment to that effect (although our incident triage team is
good about spotting such duplicates).

-- Kevin

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
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
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).
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]

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.

Post by Kevin Rushforth
I'll add a comment to that effect (although our incident triage team is
good about spotting such duplicates).
-- Kevin

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 <
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
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).
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.

[Kevin Rushforth]

Thanks. I added this to the bug report for
https://bugs.openjdk.java.net/browse/JDK-8161911

-- Kevin

Post by Rahman USTA
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.
I'll add a comment to that effect (although our incident triage
team is good about spotting such duplicates).
-- Kevin
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
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
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).
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/>

[Itai]

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.

Thanks. I added this to the bug report for https://bugs.openjdk.java.net/
browse/JDK-8161911
-- Kevin
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.

Post by Kevin Rushforth
I'll add a comment to that effect (although our incident triage team is
good about spotting such duplicates).
-- Kevin

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 <
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
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).
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/>

[Jim Graham]

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

Post by Itai
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
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`.
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.

Thanks. I added this to the bug report for https://bugs.openjdk.java.net/
browse/JDK-8161911
-- Kevin
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.

Post by Kevin Rushforth
I'll add a comment to that effect (although our incident triage team is
good about spotting such duplicates).
-- Kevin

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 <
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
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).
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/>

[Chien Yang]

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

Post by Jim Graham
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

Post by Itai
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
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`.
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

Post by Kevin Rushforth
Thanks. I added this to the bug report for
https://bugs.openjdk.java.net/
browse/JDK-8161911
-- Kevin
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.

Post by Kevin Rushforth
I'll add a comment to that effect (although our incident triage team is
good about spotting such duplicates).
-- Kevin

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 <
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
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).
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/>

[Kevin Rushforth]

To add to what Chien and Jim said, we use 1 context (ignoring Mac where
glass also has a context) and N+1 drawables for N windows. We use a
drawable per Window (including popup Windows used for Tooltip, ComboBox,
etc), and a dummy drawable for when we are "in between" frames. The
switch to the dummy drawable is necessary to allow our resources
disposal mechanism to work. And as Jim mentioned, Popup windows are
common enough that we would still do frequent calls to glXMakeCurrent
even without the dummy drawable.

-- Kevin

Post by Chien Yang
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

Post by Jim Graham
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

Post by Itai
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
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`.
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

Post by Kevin Rushforth
Thanks. I added this to the bug report for
https://bugs.openjdk.java.net/
browse/JDK-8161911
-- Kevin
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

Post by Kevin Rushforth
I'll add a comment to that effect (although our incident triage team is
good about spotting such duplicates).
-- Kevin

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 <
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
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).
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/>