<enebo>
lopex: we have always wanted to replace native with ruby but I just thought I would do a dirty impl and it worked in like 10 minutes
<lopex>
enebo: so like an intrinsic ?
<enebo>
lopex: no I would not say that
<enebo>
lopex: and second logical representation of the same thing
<lopex>
enebo: so general inlining
<enebo>
lopex: yeah that just uses a ruby impl once we discover it is a valid inline candidate
<enebo>
lopex: second time it checks to inline it can because it is ruby -> ruby
<enebo>
lopex: but it is not an ideal impl because it ends up being global
<lopex>
fixable right ?
<enebo>
lopex: if we discover this case and there is ruby impl we will make some code which loads it at that point and then inlines at same time
<enebo>
lopex: so unimportant times sites (times was the experiement) would still continue to use native version of times
<enebo>
The other neat thing not mentioned in that commit is this version of the inliner is not capable of deopt'ing so it basically has an if/else in it to callback to full call
<lopex>
enebo: so in theory you could also parse the bytecode and make a graph for it ? :P
<enebo>
once that is eliminated these methods should optimize a bit better...or least they might
<enebo>
a Ruby IR graph for it?
<lopex>
java bytecode
<enebo>
well our inliner knows how to inline Ruby IR so no
<lopex>
like reuse gaal component or something
<lopex>
enebo: but traversing that graph and finding jruby api calls would be a start ?
<enebo>
you mean write and entirely different backend than we have so we can inline Java->Java because hotspot cannot do it?
<lopex>
well, then transform it to jruby IR
<lopex>
wild idea
<enebo>
transform Java bytecode to Ruby bytecode
<lopex>
effectively yes, but having it jruby api calls aware
<enebo>
I don't know...we certainly probably could extend our instr set for that but that would be a lot of work
<enebo>
also our IR is register-based so some transformation would be needed
<enebo>
lopex: at this point my main goal is only to optimize methods with callsites which have blocks on them
<enebo>
It is possible we can do more than that but that particular use case is what current JVMs don't do well with for us
<lopex>
enebo: also, why do we checks for block given internally ?
<lopex>
passing a block is statically known
<enebo>
lopex: you need to be more specific
<lopex>
foo{}, foo &proc etc
<lopex>
it's known at parse time always
<lopex>
right ?
<enebo>
well we do know in IR
<enebo>
public boolean hasLiteralClosure()
<enebo>
in CallBase
<lopex>
so we could split to block/non block impls
<enebo>
in a sense the inliner work is doing that for callsites
<enebo>
we make a different callsite for methods with literal closures
<lopex>
I meant core native methods
<enebo>
oh well we can
<enebo>
I am surprised we haven't in places
<enebo>
but if you mean @JRubyMethod I think it is just a matter of no one wanting to work on it
<lopex>
yeah
<enebo>
The other really obvious improvement to @JRubyMethod would be using actual types when we can like RubyArray instead of always using IRubyObject
<lopex>
yeah, it's very old idea
<enebo>
lopex: and keywords
<enebo>
keywords would be most feel good in sense it is the ickiest arg processing code
drbobbeaty has quit [Read error: Connection reset by peer]