<headius[m]>
enebo: kares I think this person wants to be able to call the static methods of a Java class against the java.lang.Class object (or the java_class, which will be the same thing in 9.3)
<headius[m]>
I responded that we don't do that because the java.lang.Class is already a large set of methods and doesn't really represent the metaclass for e.g. java.lang.String, but it occurs to me now we have no direct way to get from the java.lang.Class (or java_class) back to the proxy metaclass, do we?
<headius[m]>
He suggests Class#ruby_class later in the thread and it seems like a good idea to me
nonlandi[m] has quit [*.net *.split]
MattPattersonGit has quit [*.net *.split]
rdubya[m] has quit [*.net *.split]
CharlesOliverNut has quit [*.net *.split]
headius[m] has quit [*.net *.split]
knu has quit [*.net *.split]
vext01 has quit [*.net *.split]
havenwood has quit [*.net *.split]
kares[m] has quit [*.net *.split]
cyberarm has quit [*.net *.split]
johnphillips3141 has quit [*.net *.split]
fzakaria1 has quit [*.net *.split]
lopex[m] has quit [*.net *.split]
jswenson[m] has quit [*.net *.split]
byteit101[m] has quit [*.net *.split]
knu has joined #jruby
havenwood has joined #jruby
havenwood has joined #jruby
havenwood has quit [Changing host]
vext01 has joined #jruby
caleb_land[m] has quit [*.net *.split]
KarolBucekGitter has quit [*.net *.split]
RomainManni-Buca has quit [*.net *.split]
enebo[m] has quit [*.net *.split]
kalenp[m] has quit [*.net *.split]
yaasky[m] has quit [*.net *.split]
FlorianDoubletGi has quit [Ping timeout: 240 seconds]
TimGitter[m] has quit [Ping timeout: 240 seconds]
kai[m]1 has quit [Ping timeout: 258 seconds]
TimGitter[m]1 has quit [Ping timeout: 240 seconds]
ChrisSeatonGitte has quit [Ping timeout: 240 seconds]
souravgoswami[m] has quit [Ping timeout: 240 seconds]
ahorek[m] has quit [Ping timeout: 240 seconds]
daveg_lookout[m] has quit [Ping timeout: 244 seconds]
MarcinMielyskiGi has quit [Ping timeout: 244 seconds]
UweKuboschGitter has quit [Ping timeout: 244 seconds]
liamwhiteGitter[ has quit [Ping timeout: 258 seconds]
chrisseaton[m] has quit [Ping timeout: 244 seconds]
JesseChavezGitte has quit [Ping timeout: 244 seconds]
JulesIvanicGitte has quit [Ping timeout: 240 seconds]
OlleJonssonGitte has quit [Ping timeout: 240 seconds]
BlaneDabneyGitte has quit [Ping timeout: 240 seconds]
slonopotamus[m] has quit [Ping timeout: 244 seconds]
XavierNoriaGitte has quit [Ping timeout: 258 seconds]
knu has quit [*.net *.split]
jeremyevans has quit [*.net *.split]
lanceball has quit [*.net *.split]
satyanash has quit [*.net *.split]
michael_mbp has quit [*.net *.split]
Antiarc has quit [*.net *.split]
justinmcp has quit [*.net *.split]
satyanash_alt has joined #jruby
lanceball has joined #jruby
knu has joined #jruby
Antiarc has joined #jruby
justinmcp has joined #jruby
Liothen has quit [Ping timeout: 272 seconds]
jeremyevans has joined #jruby
Liothen has joined #jruby
headius[m] has joined #jruby
<headius[m]>
another observation: dig is not arity-split
<headius[m]>
ary.dig(0) should just be ary.at(0) and no args array
michael_mbp has joined #jruby
caleb_land[m] has joined #jruby
_whitelogger has joined #jruby
den_d has joined #jruby
lopex has joined #jruby
enebo[m] has joined #jruby
<enebo[m]>
headius: yeah although that is also subject to it JITing
<headius[m]>
what is?
<enebo[m]>
Oh maybe call1O in interp does unbox call
<enebo[m]>
ah yeah OneFixnumArgNoBlock will call direct too
<enebo[m]>
I get confused by this because we have the issue that generic call will require a boxed args to work but that does not mean others will not call unboxed paths
<headius[m]>
the indy slowdown may be in boxing arg array
<enebo[m]>
heh
<headius[m]>
I am using indy primitives to collect N args into arg[] rather than utility methods
<enebo[m]>
Pretty easy to make a single arg version on Array and Hash
<enebo[m]>
So I guess you could argue if we examined who calls dig we could just unbox up to 3 or 4 and eliminate that boxing for all of them
<headius[m]>
right we can go up to three with just overloads
Freaky has quit [*.net *.split]
Iambchop has quit [*.net *.split]
victori has quit [*.net *.split]
Freaky has joined #jruby
<headius[m]>
might as well do three because the code for each is very small
<headius[m]>
val = dig(self, arg0); val = dig(val, arg1); ...
victori has joined #jruby
Iambchop has joined #jruby
victori has quit [Max SendQ exceeded]
victori has joined #jruby
Iambchop has quit [*.net *.split]
<headius[m]>
just manually unrolled loops
<enebo[m]>
heh dig(one); dig(one, two); dig(one)&.dig(two); end
Liothen has quit [*.net *.split]
Liothen has joined #jruby
Iambchop has joined #jruby
<headius[m]>
yeah boxing is a huge part of the overhead in this thing
<headius[m]>
I have 1 and 2 arity paths now and numbers just keep going up
<enebo[m]>
What was the issue with pushing populators to support more arity splits? Having to have methods match?
<enebo[m]>
It is the most obvious one
<headius[m]>
mostly just the hand-stitching of all the additional paths through e.g. org.jruby.runtime.methods.JavaMethod*
<headius[m]>
we have a lot of places that hardcode 3 as max specific arity and many would have to change (the ones that don't would just fall into [] so that cuts down some work initially)
<headius[m]>
I would love to have up to 5 these days
<enebo[m]>
I don't actually know if we have reached a new future yet but kwargs may make us consider some methods have gotten +1
<headius[m]>
ten is a stretch goal but it would have to involve more code generation so we aren't maintaining 10 paths through all call plumbing
<headius[m]>
ah yeah that is true
<headius[m]>
we also still have no unboxed kwargs path
<headius[m]>
or even an kwarg[] kwargs path
<enebo[m]>
yeah I was thinking about kwargs when I fixed **{}
<headius[m]>
like [sym, val, sym, val] would still be way cheaper than making a hash
<enebo[m]>
I even wrote something up in that issue but I feel it is a 9.4 goal at best
<headius[m]>
oh definitely not 9.3
<headius[m]>
9.4 maybe if we can focus on perf and plumbing more
<enebo[m]>
I keep feeling there is a positional strategy as well since the site itself can always constant [a:, c:] and then whereever those values of the site as passed is just 1, 2 somewhere
vext01 has quit [*.net *.split]
havenwood has quit [*.net *.split]
headius[m] has quit [*.net *.split]
jeremyevans has quit [*.net *.split]
drbobbeaty has quit [*.net *.split]
jeremyevans has joined #jruby
vext01 has joined #jruby
drbobbeaty has joined #jruby
havenwood has joined #jruby
havenwood has joined #jruby
havenwood has quit [Changing host]
<enebo[m]>
binding means binding from mapping [a: c:] to method itself but the site itself would not actually make any arrays after the site was created (for the static kwarg bits anyways)
headius[m] has joined #jruby
<enebo[m]>
It still should be plumable through native method impls too
<headius[m]>
core classes would be able to overload like (context, arg0, arg1, kwsym0, kwval0, kwsym1, kwval1, ...)
<headius[m]>
or kwargs[] with pairs for anything outside supported "kwargs arity"
<headius[m]>
Ruby compiled methods would have a specific number of kwargs so they would just compile as the expanded version with an unboxing shim
<headius[m]>
indy calls from ruby to ruby or ruby to native would just push the kwargs in alpha order as args, or box into kwargs[]
<headius[m]>
if a hash is eventually needed we just make it then
<headius[m]>
for 3.0 this will be easier because of the separation of kwargs from normal hash argument passing
<headius[m]>
but it is all doable
<enebo[m]>
so static kwargs to static kwargs is nothing more than a positional call so long as nothing changes
<headius[m]>
enebo: so this is with arity 1 added to Array#dig
caleb_land[m] has quit [Ping timeout: 258 seconds]
enebo[m] has quit [Ping timeout: 245 seconds]
headius[m] has quit [Ping timeout: 252 seconds]
joast has joined #jruby
caleb_land[m] has joined #jruby
enebo[m] has joined #jruby
kai[m]1 has joined #jruby
fzakaria1 has joined #jruby
FlorianDoubletGi has joined #jruby
MattPattersonGit has joined #jruby
KarolBucekGitter has joined #jruby
kalenp[m] has joined #jruby
ahorek[m] has joined #jruby
yaasky[m] has joined #jruby
liamwhiteGitter[ has joined #jruby
JesseChavezGitte has joined #jruby
UweKuboschGitter has joined #jruby
nonlandi[m] has joined #jruby
TimGitter[m] has joined #jruby
MarcinMielyskiGi has joined #jruby
jswenson[m] has joined #jruby
RomainManni-Buca has joined #jruby
kares[m] has joined #jruby
johnphillips3141 has joined #jruby
XavierNoriaGitte has joined #jruby
OlleJonssonGitte has joined #jruby
ChrisSeatonGitte has joined #jruby
rdubya[m] has joined #jruby
daveg_lookout[m] has joined #jruby
BlaneDabneyGitte has joined #jruby
JulesIvanicGitte has joined #jruby
CharlesOliverNut has joined #jruby
slonopotamus[m] has joined #jruby
TimGitter[m]1 has joined #jruby
chrisseaton[m] has joined #jruby
souravgoswami[m] has joined #jruby
byteit101[m] has joined #jruby
headius[m] has joined #jruby
<headius[m]>
ok ick
<headius[m]>
if I am reading this right the collector logic for a typed array (i.e. not Object[]) uses Arrays.newInstance to create it... that may be the difference
<headius[m]>
when we do it ourselves we go straight to new IRubyObject[] rather than a downcall into an intrinsic that has to determine the type and then construct it
<headius[m]>
I think I can add an enhancement to my binder logic to take an optional array constructor handle
<headius[m]>
that may help
cyberarm has joined #jruby
<headius[m]>
target and combiner types must match: (String[],String,String,String)String[] != (String[],String,String,String)String[]
<headius[m]>
🙄
<headius[m]>
method handle errors are sometimes inscrutable
ur5us_ has joined #jruby
ur5us_ has quit [Quit: Leaving]
ur5us has joined #jruby
<chrisseaton[m]>
Interested in what is the underlying explanation for that? Or do you not know yourself?
<headius[m]>
reason for what?
<chrisseaton[m]>
The method handle error being inscutable?
<headius[m]>
I think they added a new version of fold that puts the result value at the position you specify but did not update the error message for that logic
<headius[m]>
so it should really be (String, String[], String, String)String[] for one of those
<headius[m]>
I was using the API wrong but having misleading error messages doesn't help
<headius[m]>
I wish we could find a decent way to implement ObjectSpace without our own tracker, even if it was just as slow
<headius[m]>
each_object I mean
<chrisseaton[m]>
We use a stack-walking API to do that in TruffleRuby
<headius[m]>
hard to do without such an API in JDK
ur5us_ has joined #jruby
ur5us has quit [Remote host closed the connection]
<headius[m]>
well it looks like at least part of this is that the indy logic allocates two arrays
<headius[m]>
first it collects args into Object[] and then populates a new IRubyObject[] off of that
<headius[m]>
and this does not seem to elide, at least in 8
<headius[m]>
I need to hook up igv rather than scrolling through asm
ur5us_ has quit [Ping timeout: 240 seconds]
<chrisseaton[m]>
Also try Seafoam if you want! It can do assembly as well now, and if it's missing things that would be useful to you I'd like to fix that.