From: Charles Oliver Nutter <headius@...>
Date: 2011-05-02T13:01:57+09:00
Subject: Re: Hash Surprises with Fixnum, #hash, and #eql?

On Sat, Apr 30, 2011 at 2:45 AM, Clifford Heath <no@spam.please.net> wrote:
> Ouch. No wonder it hurts. I hadn't looked into the internals of JRuby,
> but I assumed that you had some native C (JNI or whatever) in there,
> which could make this feasible.
>
> I can totally understand you not wanting any native extensions though!

None of the JRuby runtime is native code, and obviously that's how
we'd like to keep it. Even if we were to do it in C, we would still
need to do some object-walking, since JRuby supports having multiple
JRuby instances in the same process (that's how a single JRuby process
can serve many different applications at the same time).

> It seems that a collection of such flags at known offsets inside a
> singleton instance could make this a lot quicker. There's a finite
> need for such things, so it's not as though it would pervade all of
> the interpreter.

Such a singleton would still need to be rooted to a specific JRuby
instance. The logic as it stands now is pretty much a
JRuby-instance-global flag.

> Your argument (from a previous response) that cross-thread effects of
> monkey-patching was "somewhat undefined" was my thinking also, but
> contrary to John's accusation, thought it could be (mostly?) hidden
> under the existing synchronisation around method definition.

The JVM memory model allows for the JVM to optimize non-volatile
memory accesses away if it can prove the memory location is never
modified by the same thread. Only when specifing volatility will it
guarantee the memory access is always performed with full CPU cache
semantics.

> I think the argument that "folk don't do it, therefore they wouldn't"
> isn't a strong one. Look for example at Rail's HashWithIndifferentAccess,
> which makes string and symbol keys interchangeable. I merely want to
> do the same thing with Fixnums and Floats.

Certainly...but at the moment no implementations agree on what is
correct. Your vision might be correct, but until it's "standard" we
would probably not implement it.

> If you can't make it quicker (than you outlined), best to drop it I
> guess. I've mostly worked around the need for my current library.

It's probably possible to reduce the cost under Java 7, which includes
capabilities to have nearly guard-free dynamic invocation. But there's
no way I know of to make this completely cost-free under Java 6, which
we still support.

- Charlie