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

[Jim Graham]

On 7/26/17 12:34 PM, Jim Graham wrote:
> I'll do a search and see if there are any cases of the above paradigm left...

I did a basic grep over the Java sources in java.desktop looking primarily for synchronizations on a class, ignoring 
synchronized methods (both instance and static) and synchronizations on an object other than a class (such as "this" or 
"getTreeLock()").

I didn't find any cases of initializing a singleton without all of the tests inside the synch block (such as Toolkit 
which does do the lazy initialization, but it has all of the lazy tests inside the synch block so it can't have 
unordered initialization, but it might benefit from an inner class treatment for performance).  Either I was imagining 
it, or we've gradually cleaned up a lot of those in the past.

I did find the following related issues:

TrayIcon.setPopupMenu()
  - synchronizes on TrayIcon.class, but then relies on tests from outside the synch block for correctness I believe - 
the "already set" test should probably be duplicated inside the synchronization

I found a number of cases of "synchronized (Foo.class)" inside Foo.java, and some of them were the first statement in 
the method - which begs the question of why the method wasn't just made synchronized in the first place. 
Window.getWindows() and Window.removeWindowFromList() for examples...

				...jim