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 

I've fixed up MergedPolicyProvider and AggregatePolicyProvider also.



View raw message