[concurrency-interest] RFC -- Java7 java.util.concurrent plans

Jason T. Greene jason.greene at redhat.com
Tue Dec 16 17:18:40 EST 2008


Bob Lee wrote:
> On Fri, Dec 12, 2008 at 2:46 PM, Jason T. Greene 
> <jason.greene at redhat.com <mailto:jason.greene at redhat.com>> wrote:
> 
>     I am not so sure about this one. Once there are ephemerons the value
>     reference would be cleaned up with the key. If ephemerons aren't
>     available, it could be possible to have eager value collection where
>     a cleanup thread nullifies the value reference. The only garbage
>     that would remain in that case would be a Entry object. Writes would
>     then just replace the "tombstoned" entries (potentially cleaning up
>     others).
> 
> 
> Good point about ephemerons. Here's a question: does it make sense to 
> bother with a non-concurrent version at all given that the performance 
> difference (in the uncontended and read-only cases) is almost indiscernible?

This is definitely not an easy question to answer.

The memory overhead will be higher, especially if they take the default 
concurrency-level. Write performance would definitely be impacted from 
all of the unnecessary fences, as well as the chain rebuilding that's 
not necessary in a non-concurrent algorithm. Read performance is 
impacted on platforms that require load barriers.

Although, to your point, reference tables do tend to have low write to 
read ratios, and a number of cpus today don't need load barriers. So it 
could very well be that the difference is small for the majority of 
scenarios. This could change in the future, depending on the direction 
hardware takes.

-- 
Jason T. Greene
JBoss, a division of Red Hat


More information about the Concurrency-interest mailing list