Restrictions for lock coarsening?

[Clemens Eisserer]

> Also note, as I understand from work I did late in the Java 6 cycle, once an
> object has its biased revoked it remains revoked ie it will not participate
> in biased-locking again. This was done to prevent "thrashing" and it also
> makes things easier to reason about.

A quick-and-dirty solution would probably be a Sun-internal Api which
would allow some control over biased locking. Maybe just a method
which sets an object to a biasable state which has never been locked
before, which could be used for framework-classes where biased-locking
could be benefitial.
Another idea would be lock-profiling done by the interpreter, maybe on
a per-class basis. But I guess that would be a lot of work, and I am
not sure wether per-class is too coarse grained.

I did some analysis and it seems most swing applications access Java2D
from two different threads:
1. The EDT to draw content to the backbuffer
2. The XAWT thread to draw the back-buffer, always having the same stack-trace.

I inserted some trace-code into java2d and with netbeans I got:
Java2D accessed by different threads. Old: AWT-EventQueue-0 new:
AWT-EventQueue-1 Synchronized calls since last thread-switch: 4136
Java2D accessed by different threads. Old: AWT-EventQueue-1 new:
AWT-XAWT Synchronized calls since last thread-switch: 9665
Java2D accessed by different threads. Old: AWT-XAWT new:
AWT-EventQueue-1 Synchronized calls since last thread-switch: 5
Java2D accessed by different threads. Old: AWT-EventQueue-1 new:
AWT-XAWT Synchronized calls since last thread-switch: 15621
Java2D accessed by different threads. Old: AWT-XAWT new:
AWT-EventQueue-1 Synchronized calls since last thread-switch: 4
Java2D accessed by different threads. Old: AWT-EventQueue-1 new:
AWT-XAWT Synchronized calls since last thread-switch: 11815
Java2D accessed by different threads. Old: AWT-XAWT new:
AWT-EventQueue-1 Synchronized calls since last thread-switch: 3
Java2D accessed by different threads. Old: AWT-EventQueue-1 new:
AWT-XAWT Synchronized calls since last thread-switch: 33087
Java2D accessed by different threads. Old: AWT-XAWT new:
AWT-EventQueue-1 Synchronized calls since last thread-switch: 3

So until painting the backbuffer is not done on the EDT too, I guess a
few thousand CAS don't justify waiting on safepoints :-/
On the other side, if that would be possible to do the XAWT work on
the EDT too (which probably would conflict the gray-rect fix), all
accesses to Java2D done by swing would really be from one single
thread.

After all, my project is in a very early state of development, and
although I see great speedup with biased locking for synthetic
microbenchmarks I am not sure its woth any troubles. With real-world
workload I don't expect the locking to account for more than 2-3% of
cycles spent.

- Clemens