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:18:17 GMT
Looks like we don't need to be concerned, they've fixed it in Java 8.

*Votes* 0
*Synopsis* Reduce synchronization in java.security.Policy.getPolicyNoCheck *
Category* java:classes_security
*Reported Against* *Release Fixed* 8(b15) *
State* 10-Fix Delivered, bug *Priority:* 2-High *Related Bugs* *Submit 
Date* 20-SEP-2011 *Description*

java.security.Policy.getPolicyNoCheck() is synchronized which causes some thread contention.
Posted Date : 2011-09-20 23:44:03.0

*Work Around*



The fix involved adding an initialized flag to indicate when the system-wide
policy has been initialized and storing both the flag and the Policy object in
an AtomicReference. Then, I also used the double-check locking idiom to avoid
locking the Policy class when the Policy had already been initialized.

Changeset: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1945abeb82a0
Posted Date : 2011-11-22 15:15:14.0

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.
>> Regards,
>> Peter.

View raw message