misc catchup

[Doug Lea]

On 10/31/12 03:05, David Holmes wrote:
> Hi Doug,
>
> I didn't know this was being folded back into FJP. We'll have to update the JEP.
>

Sorry not to give more people advanced warning, but I wanted to
do most of this out before announcing, to internally sanity-check
that it wouldn't hit some big snag. I expect to find ways to further
improve now that the basic structure is stabilizing.

> 1. The new spin-lock stuff using Unsafe directly isn't sending a very good
> message. We're basically saying ReentrantLock is not performant and we have to
> dive under the covers to get performance. :( That may be the truth but it is
> still not a good message.

No. The reason is entirely to reduce initial commonPool footprint --
there is no secondary allocation (just setup of 12 fields), not
even for a Lock object needed to further initialize. This might
shrink even further.

(It takes some unfortunate luck to ever get that lock to block.
Most runs never do. So using the CHM 2bit scheme works fine
even through the construction is terrible if heavily contended.)

(BTW, mostly unrelatedly, AQS improvements based on some of the
new adaptive spin stuff in StampedLock are on the todo list.)

>
> 2. I don't recall if we definitely established that a thread can always
> interrupt itself, but if not I can't quite convince myself that if

We did, but ...

> tryAwaitMainLock throws SecurityException that everything continues to work ok -
> deregisterWorker seems problematic as the WorkQueue state has already been mutated.
>

... for sake of paranoia, I added the
   catch (SecurityException ignore)

-Doug