<byteit101[m]>
headius: Just merged out my branch to pick up kares's changes. I expect it may fail
<byteit101[m]>
All fails. Drat, was hoping for an easy merge
<byteit101[m]>
kares: I see you made JavaConstructor's ctor package vs public. That is intentional?
ur5us has quit [Ping timeout: 276 seconds]
ur5us has joined #jruby
ur5us has quit [Ping timeout: 250 seconds]
ur5us has joined #jruby
ur5us has quit [Ping timeout: 250 seconds]
ur5us has joined #jruby
<kares[m]>
byteit101: was initially hiding those since on the Ruby side we 'dropped' JavaClass and friends (includes JavaField, JavaMethod and JavaConstructor)
<kares[m]>
feel free to change the ctor as needed, I think the JI parts just use the factory method but no hard preference there (as long as you do not need it exposed in Ruby)
<kares[m]>
but I kind of forgot and later realized JavaConstructor and JavaMethod are used within Java integration's dispatch so they're likely to stay.
ur5us has quit [Ping timeout: 245 seconds]
<headius[m]>
byteit101: we should exclude the few remaining questionable failures and merge once it is nearly green I think
<headius[m]>
kares: dunno how you feel but I think we need to land this and finish up 9.3 now
<headius[m]>
enebo: so looking over other construction of ByteList with a size, most of them are either a fixed size or some string plus a few bytes, like for quoting or escaping
<headius[m]>
these all could be routed through a single allocation path that would check for max array size and raise a Ruby error, but it is a much larger diff for 9.2 to do that
<headius[m]>
and I have not looked at hash or array yet
<headius[m]>
the ensure path (growing existing) and the String#* path will raise nice Ruby errors now
<enebo[m]>
hahah escaping a MAX_INT sized string
<enebo[m]>
I wonder
<headius[m]>
yeah that sort of thing
<headius[m]>
or hex dumping some giant Bignum
<enebo[m]>
so for the sake of 9.2 perhaps just do the small set of changes and maybe boil the ocean on 9.3 if you plan on addressing it
<headius[m]>
I am leaning toward doing a ByteList allocation helper that checks sizes only on master for 9.3, or even post 9.3
<enebo[m]>
yeah that makes sense
<headius[m]>
it is not like these other cases won't raise error, it will just be the ugly OutOfMemoryError "max array size requested exceeds VM whatever" instead of a Ruby error
<headius[m]>
that is really all this is fixing
<headius[m]>
I will audit a few more ByteList construction paths and do a quick pass over Array and Hash for 9.2 and then land this
<headius[m]>
enebo: I think I will skip Hash for now since you'd have to have a tremendous number of pairs to blow out the bucket array size
<enebo[m]>
sexabyte heaps
<headius[m]>
conservatively speaking, 1B * hash entry objects would be somewhere in the neighborhood of 100GB
<enebo[m]>
lol exabyte
<headius[m]>
and it would need to be bigger than that to get bucket size above 2B
<headius[m]>
this is not counting the actual keys and values either
<headius[m]>
we will need to revisit this if we go to a direct-addressed hash at some point
<headius[m]>
those will grow much faster and have no entry objects
joast has quit [Ping timeout: 252 seconds]
<headius[m]>
I just pushed some array guards and will merge once that is green
<headius[m]>
chrisseaton: do you know why concurrent-ruby does not ship a 'java' platform gem anymore?
<headius[m]>
seems like perhaps just a simplification, as the jar is still shipped, but we have had a perf regression reported that might indicate the Java extension is not loading properly: https://github.com/jruby/jruby/issues/6665
<byteit101[m]>
headius: Sounds good, I'll get it building again this evening and let you know. Note there is still one outstanding question for kares & enebo: do you like the ruby-side api?