<Swing Dev> [9] Review request for 8132791 No access to SynthContext.getContext()

[Semyon Sadetsky]

Hi Alexander,

Your comparison makes sense.
In addition to your change I'd suggest to remove the reset() method in 
SynthContext and set the fields in the constructor.
Does the factory method really necessary? It seems the public 
constructor has the same arguments and produces the same object.

--Semyon

On 4/12/2016 10:02 PM, Alexander Scherbatiy wrote:
>
> Hello,
>
> Could you review the fix:
>   bug: https://bugs.openjdk.java.net/browse/JDK-8132791
>   webrev: http://cr.openjdk.java.net/~alexsch/8132791/webrev.00
>
>
> SynthContext is an object with 4 fields which is used a lot by Synth 
> L&F for components painting. It has an internal API which allows to 
> put unused objects to queue and reuse them later. Application 
> developers will not be able to have access to this API in JDK 9 with 
> modularization feature so they only be able to create new SyntContext 
> objects. There are ways that a SyntContext object created by a 
> developer can be disposed by Synth L&F and put to the unused object 
> queue.  This can lead to a memory leak.
>
> There are 2 options to fix the issue: provide a public API for the 
> SyntContext object custom disposing or just get rid of the unused 
> object queue.
>
> Effective Java Guide has a suggestion: “avoiding object creation by 
> maintaining your own object pool is a bad idea unless the objects in 
> the pool are extremely heavyweight”
>
> To check if there are memory or performance degradation for the second 
> solution I used SwingMark application which extensively creates and 
> paints a lot of Swing components like labels, menus and others.
>
> The tests were run 5 times with using the object queue and without it.
> There results can be found at: 
> http://cr.openjdk.java.net/~alexsch/8132791/profiling/results_3-5
>
> The minimum and maximum values from 5 runs are:
>
> Tests which used an object queue:
> used memory (in bytes)
>   min: 3.75 million max: 3.78 million
> heap size  (in bytes)
>   min: 11.53 million max: 12.58 million
> elapsed time (in milliseconds)
>   min: 57.27 thousand max: 57.97 thousand
> requests for SynthContext objects: 380 thousands
> created objects: 21
>
> Tests which did not use an object queue:
> used memory (in bytes)
>   min:  3.71 million max: 3.79 million
> heap size   (in bytes)
>   min: 11.53 million max: 12.58 million
> elapsed time (in milliseconds)
>   min: 57.90 thousand max: 57.97 thousand
> requests for SynthContext objects: 380 thousands
> created objects: 380 thousands
>
> There were about 380 thousand request for SynthContext objects in both 
> tests but only 21 object were crated for the first ones.
>
> However, the used memory size and running time are nearly the same for 
> both runs for these particular tests.
>
> According to the test results it looks reasonable to remove the custom 
> object pool support from the SynthContext object.
>
> Thanks,
> Alexandr.
>