On 05/02/2016 02:08 PM, Sergey Bylokhov wrote:
On 02.05.16 23:52, Phil Race wrote:
Just to make sure I understand this right, even if an application
disposes of all Frames, we still somehow hold on to one Frame ?
And it was the most recent one used by "validatedSrcData"
due to some long reference chain ?
correct.
https://bugs.openjdk.java.net/secure/attachment/59121/8028486.png
WeakReferences are cleared quite aggressively so if an
application loops doing
then we may be re-creating these objects.
And this is fine because we use only identity checks inside the
validate method. If the java object was deleted we should update the
native state anyway.
Not sure how to read that. Do you mean there is always
some amount of work to do anyway ?
Is there any value in doing the "nulling" in Anton's earlier version
of the fix to be more prompt ?
is BufferedContext only used by D3D & OGL ?
I suggest to run a decent set of tests on these different pipelines
to make sure no surprises ..
-phil.
On 05/02/2016 01:26 PM, Sergey Bylokhov wrote:
Hello,
Please review the fix for jdk9.
Bug evaluation was done by Anton:
http://mail.openjdk.java.net/pipermail/awt-dev/2016-April/011177.html
This is a cross-platform bug it affects d3d/ogl pipelines. The problem
is that BufferedContex cached information to skip some native
reconfigurations. But this cache cause a memory leak if some
data(src/dst surfaces) was cached and there was no new rendering in
this context(we create context per-d3d_device/ogl_config).
In the fix I changed all these caches to weak references. Note that i
use a references as initial values instead of null, just to eliminate
the null checks in the body of the method.
The test was updated to be more stable(flushed the EDT + flushed the
Disposer thread).
Bug: https://bugs.openjdk.java.net/browse/JDK-8028486
Webrev can be found at:
http://cr.openjdk.java.net/~serb/8028486/webrev.00
