<GitHub103>
jruby/master d1dfcb8 Charles Oliver Nutter: Set your sights higher.
iNeWeaBliN has joined #jruby
<iNeWeaBliN>
hi there, tl;dr: is jruby a flavor of java and can it be used instead of jre/jdk?
<GitHub79>
[jruby] headius opened issue #5246: Methods that do not bind directly with invokedynamic https://git.io/fNIj1
<havenwood>
iNeWeaBliN: It's the Ruby language on the JVM.
<havenwood>
iNeWeaBliN: It's not a flavor of Java. You run it on the JVM, not instead of the JVM.
<iNeWeaBliN>
oh
claudiuinberlin has joined #jruby
<eonwe>
enebo: by stracing the system calls, it seems that backticks create the new process by clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f01eb2949d0) which causes memory trouble whereas system() has CLONE_VM flag set
<ChrisBr>
if you have time, would be great to get feedback! The benchs look promising so far
<headius>
do you mean that numbers are looking good with this external map?
<ChrisBr>
jup
<ChrisBr>
headius: or do you think we should leave everything in RubyHash class?
<ChrisBr>
I just think if we want to have linearsearch and open addressing it is going to be really complicated
<headius>
hmmm
<headius>
are the numbers better with the external map? :-D
<ChrisBr>
not 100% sure
<headius>
yeah so thinking in my head if it were more like a C API, you'd still need to pass in a struct holding all the pieces, or pass in all the pieces every time, which would make it almost unusable
<ChrisBr>
so you would prefer to have everything in RubyHash if you could choose?
<ChrisBr>
headius: yep exactle, it would be still highly coupled to the hash
<headius>
I wonder about the indirection and if we are defeating some of the locality gains
<headius>
but I don't know how much this indirection hurts us versus the fields being on RubyHash itself
jeremyevans has quit [Ping timeout: 244 seconds]
<headius>
were there any benchmarks associated with this change in MRI?
<headius>
I mean, that showed some sort of improvement
<GitHub39>
jruby/master 7026bae Charles Oliver Nutter: Add indy + jit run of our small suite.
<headius>
ChrisBr: so it would be simpler to do it always or what?
<ChrisBr>
headius: yep, if we go with caching the hash I would do it always
<ChrisBr>
otherwise you have to iterate different which adds complexity
<headius>
hmm...ok, so I guess we should make some choices
<ChrisBr>
headius: yep :)
<headius>
lopex: what do you think about the whole hash being its own data struct at this point? Even in C it would be indirected through a struct, so all we are gaining is reusability for other stuff
<headius>
ChrisBr: if we alwatys have the hash cache I have a little bit more concern about it indirecting through another structure
<ChrisBr>
headius: another structure? That the array is bigger?
<headius>
well I just mean we have to dereference the second array, but I may be railing against locality issues Java just doesn't deal with well right now
<headius>
ok so I think I can do some benching and logging to see how this works out
<ChrisBr>
but we would store the cache in the same array?
<ChrisBr>
ok, so how should I go forward?
<headius>
we can't really because of the primitive/reference issue...second array is the best we have
<ChrisBr>
headius: hm, rioght
<headius>
ok can you update the PR with a list of the latest branch for the different versions of this, or however you have it organized?
<ChrisBr>
if we store it in a cache array, the complexity is not an issue as the entries array always has the same structure
<headius>
right
<headius>
I think that's going to be best and we'll just accept that Java doesn't handle homogeneous arrays so well
shellac has joined #jruby
<headius>
ideally having the second array only messes with cache a little bit
<headius>
we can look into deeper JVM cheats in the future
<ChrisBr>
ok, I haven't tried this approach yet! I only tried to store everyting in the same array (so we needed to box the int hash value)