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

[Alexander Scherbatiy]

   Hello,

   Could you review  the updated fix:
     http://cr.openjdk.java.net/~alexsch/8132791/webrev.01/

   - reset() method is removed form the SynthContext class
   - unused checks to null are removed from

On 13/04/16 02:40, Sergey Bylokhov wrote:
> Hi, Alexander.
>
> Can you please run the same test using the minimum possible Xmx(like 5 
> or 10 mb). It will be interesting who the performance will drop will 
> be in this corner case, when the memory is under pressure.
   The tests immediately fail with OOME using -Xmx2m option, fail on the 
same steps with 3 and 4 mb and pass with 5 mb.

Thanks,
Alexandr.

>
> On 12.04.16 22:02, 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.
>>
>
>