codefinger has quit [Read error: Connection reset by peer]
drbobbeaty has joined #jruby
shellac has joined #jruby
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Puffball has joined #jruby
_whitelogger has joined #jruby
drbobbeaty has joined #jruby
jmalves has quit [Remote host closed the connection]
jmalves has joined #jruby
lucasb has joined #jruby
michael_mbp has quit [Ping timeout: 272 seconds]
michael_mbp has joined #jruby
<ChrisBr>
headius: enebo: happy new year, long time no see! How are things going? Is there any update regarding the new hash implementation?
shellac has quit [Quit: Computer has gone to sleep.]
<headius>
ChrisBr: I have played around with some experiments, some drastic (move your impl completely out to a separate class) but have not managed to find a path I really like
<headius>
I think a key concurrency issue is switching from linear to addressed
<headius>
the experiment I did split those into separate classes altogether and then RubyHash would switch from one to the other...but it adds a couple levels of abstraction
<headius>
Happy new year to you as well!
<headius>
it's tough to clean up concurrency edges because there's so many state changes
<headius>
I'm wondering if we should only use linear for hashes constructed from literal hash syntax, since in many (most?) cases they don't change size after that
shellac has joined #jruby
<headius>
well also for keyword args since they also tend to get packed and unpacked without being mutated
<ChrisBr>
hm, so having two different hash implementations?
<ChrisBr>
completely seperated
<ChrisBr>
not intermixed like it is currently?
<headius>
That was my experiment
<headius>
it worked reasonably well but I was still promoting it to open addressing when it got larger