misc catchup

[David Holmes]

On 31/10/2012 10:16 PM, Doug Lea wrote:
> 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.

Okay - so that raised a point I forgot to raise - this common pool is 
always created, not just on demand. I understand the expectation is that 
anyone loading FJP will in all likelihood be using the common pool. But 
my concern is that pool initialization is part of the class static 
initialization, so if anything goes wrong the class will be unusable. My 
main concern is potential SecurityExceptions from the getProperty calls. 
Am I being paranoid? :)

Thanks,
David
-----

> (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
>
>