[OpenJDK 2D-Dev] [9] Review Request: 8028486 java/awt/Window/WindowsLeak/WindowsLeak.java fails

[Phil Race]

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