river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Non Blocking java.security.Policy - synchronized method is superclass.
Date Mon, 09 Jan 2012 10:03:41 GMT
Dan Creswell wrote:
> On 8 January 2012 22:48, Peter Firmstone <jini@zeus.net.au> wrote:
>   
>> Dan Creswell wrote:
>>     
>>> On 8 January 2012 11:40, Peter Firmstone <peter.firmstone@zeus.net.au>
>>> wrote:
>>>
>>>       
>>>> How much can this one synchronized method spoil scalability?
>>>>
>>>>
>>>>         
>>> Not much as far as I can see - there's going to be a one off
>>> initialisation cost and after that it's a fast path with a single
>>> reference check and a return. I can't think of much that's less
>>> compute intensive and thus lower contention.
>>>
>>> I think you'd have to be running some very trivial code that called
>>> this method many many times whilst it didn't do much for it to turn up
>>> as high cost.
>>>
>>>       
>> That's what I thought as well, true on today's hardware.
>>
>> The other thing that bothers me is it's synchronized on the
>> java.security.Policy class monitor, a very effective denial of service
>> attack is to obtain the policy class lock, no permission is required, then
>> all permission checks block.  Still there are other DOS attacks that can be
>> performed on the jvm, like memory errors, although I have found it possible
>> to create an executor that can recover safely from that state.
>>
>> I'm not so sure about Tomorrow, with future processors exploiting die
>> shrinks by increasing core count.  Most of the concurrent software we write
>> today, is only scalable to about 8 cores.
>>
>> By removing the cache from the ConcurrentPolicyFile, it becomes almost
>> entirely immutable.
>>
>> The trick to scalability is to mutate in a single thread, then publish
>> immutable objects, creating non blocking code paths, so every thread can
>> proceed, which is how the new policy basically works.
>>
>> I haven't made any decisions, yet, it's just a smell that bothers me.
>>     
>
> I think this is lacking context - what kind of service would one write
> that needs this many cores and thrashes that particular lock so hard
> it matters as compared to all the other compute it's doing?
>
> I'd also observe that running multiple processes gets you out of this
> predicament.
>
> In essence, I'm not sure it's a problem worth worrying about until
> it's a real-world problem worth worrying about.
>   

I think I might just place a comment in the code with a possible 
solution if it ever becomes a problem. You're right, the added 
complexity isn't worth the hassle right now.

The really odd part is, I've removed the policy caches, instead of 
slowing down like I expected, the policies run faster, I've stripped the 
cache from DynamicPolicyProvider too, making it far simpler, will commit 
soon.

I've fixed up MergedPolicyProvider and AggregatePolicyProvider also.

Cheers,

Peter.


Mime
View raw message