On Tue, Dec 20, 2011 at 12:01 PM, Yoko Harada <yoko...@gmail.com> wrote:
> AbstractRubyHash looks good. Once this implementation comes in,
> MapJavaProxy class can have much simpler implementation.
Yeah, I think it would literally have *just* the abstract methods and
perfom as well as Hash or the underlying Map.
> More than that, how do you think about changing RubyHashEntry class
>
> public static final class RubyHashEntry implements Map.Entry {
> ...
> }
>
> to ConcurrentLikedQueue<Map.Entry> or other classes of concurrent
> package? I can't say anything about performance at this moment, but at
> least thread safety will get better.
I'm not super eager to make Hash thread-safe, but if we could do it
without perf issues I'd be all for it. If we can't, I want us to be
able to provide a solid alternative, which is where the
AbstractRubyHash stuff comes in.
The biggest down side to ConcurrentHashMap, other than a bit of a perf
hit, is that it takes an enormous amount of memory compared to a
normal HashMap. If you aren't explicitly telling it to give you low
concurrency (like 1 or 2 threads expected) you'll get the full-on
16-way CHM, which splits its backing store into 16 chunks to improve
concurrency (and eat a lot more memory).
For Rubinius, Brian Ford has been interested in porting the fancy new
"Concurrent Hash Array Mapped Trie" implementation that Scala's using.
That would be an *excellent* project for someone to write a Java
version, or to help finish any incomplete Java version that's out
there, and we could look at how it performs compared to our current
Hash.
Beyond that...I'd like to see the AbstractRubyHash change land at some
point, but it's not on my list of things to work on. Help is wanted :)
- Charlie
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
