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

Jim Graham james.graham at oracle.com
Wed Jul 26 19:34:35 UTC 2017

On 7/25/17 3:37 PM, Sergey Bylokhov wrote:
>> If that is the case then I think we have a few places where we do this "manual conditional synchronization" that 
>> should probably be investigated.  If I remember correctly, though, they may use the following paradigm which might not 
>> suffer from that issue:
>> Does it help if a local variable is used, as in:
>> GE env = this.localEnv
>> if (env == null) {
>>      synchronized (class) {
>>          if (this.localEnv == null) {
>>              localEnv = createGE();
>>          }
>>          env = this.localEnv;
>>      }
>> }
>> return env;
>> This ensures that the second read from the field is done in the synchronized block for the case that it was originally 
>> found to be null, though this might not help if the line "localEnv = createGE()" can reorder code from inside the call 
>> to createGE() to code outside of it. However those dangling reordered stores should be resolved before it leaves the 
>> synchronized block, no?
> I think that it is possible that one thread will do:
>   - create an object
>   - assign the object to the localEnv.
>   - Initialize the object.
> And the second thread will do:
>   - Read non-null value from the this.localEnv to the env
>   - Check env to null
>   - Return non-initialized object.

I can see that.  I suppose one thing that keeps this from causing problems in AWT is that we tend to be single-threaded 
for most applications.  I suppose that one could get even more sophisticated to prevent that case, but in the end, as I 
said, I can see the simplicity of using the inner class now in getting all of this right.

I'll do a search and see if there are any cases of the above paradigm left...


More information about the 2d-dev mailing list