[OpenJDK 2D-Dev] [10] Review Request: 8185093 Expensive multi-core choke point when any graphics objects are created

[Jim Graham]

To be clear, I couldn't think of any way in which removing a synchronized keyword would create a compatibility risk, 
though I suppose it potentially could cause a program to proceed faster and thus tickle a race condition - that seems 
rather remote and the race condition would be a "pre-existing condition"...

			...jim

On 7/31/17 1:32 PM, Jim Graham wrote:
> I adjusted one of the statements to be a little more straightforward and set the compatibility risk to minimal.  If Phil 
> thinks the risk can be set to "None", that was my alternate, but I stuck with "minimal" to be safe...
> 
>              ...jim
> 
> On 7/28/17 5:07 PM, Sergey Bylokhov wrote:
>> DRAFT version of CSR:
>> https://bugs.openjdk.java.net/browse/JDK-8185542
>>
>> ----- philip.race at oracle.com wrote:
>>
>>> On 07/24/2017 05:09 PM, Sergey Bylokhov wrote:
>>>>
>>>>
>>>> The main issue which I would like to clarify is it possible to
>>> remove
>>>> synchronize keyword from the getLocalGraphicsEnvironment(), possibly
>>>
>>>> with updating a specification? We have similar issues in other parts
>>>
>>>> of code which I would like to update later after this one.
>>>
>>>
>>> Yes, I do think we can remove synchronized but we should do a CSR
>>> (CCC)
>>>
>>> On 07/25/2017 03:03 PM, Jim Graham wrote:
>>>>
>>>> +1 for the inner class version - it's the most straightforward way
>>> to
>>>> do this optimally...
>>>
>>> Same from me.
>>>
>>> -phil.