Updates to ThreadLocalVar

[jdantonio]

This PR included two updates, both of which warrant discussion.

1. Change implementation from fiber-local to thread-local as suggested by @schmurfy here
2. Returns the JRuby-specific implementation that was removed in f073cac.

In my benchmark tests the JRuby version performs significantly worse. The advantage, however, is that it leverages the JVM directly rather than using our Ruby implementation. In our experience, JRuby interop is significantly slower than pure-Java wrappers. Thus we've begun creating pure-Java implementations for some abstraction. It's possible that a pure-Java wrapper--which could be added at any time--will perform significantly better.

My preference is to use the JRuby version since it leveraged the JVM directly, but my feelings aren't strong. I could be convinced otherwise. If memory serves, @pitr-ch echoed this sentiment, but I can't find the comment. I may be wrong on that.

// @alexdowad

[alexdowad]

In benchmarking, I found that a significant amount of performance was lost from calling #value= -> #bind -> #set, rather than just putting the class-specific storage implementation in #value=. You may want to try and see how much of a difference it makes. Personally, I think a noticeable boost in performance is worth duplicating perhaps 10 lines of code.

[jdantonio]

That makes sense. Especially after looking at the code again. Initially I copied the code from prior to your new implementation. But then I optimized away those function calls in the Ruby version. The base class methods aren't really necessary any more.

I'll make that update today.

[jdantonio]

Updated with suggestion from @alexdowad.