<headius>
I spent some time with the Azul folks talking about their JIT and startup work, and I will pull aside the J9 guys to talk about their AOT tomorrow. I think they'll both be including JRuby as part of their test/stress suite
adam_ has joined #jruby
adam_ has quit [Client Quit]
adam_ has joined #jruby
adam_ is now known as adam12_
adam12 has quit [Remote host closed the connection]
adam12_ is now known as adam12
cremes has joined #jruby
cremes has quit [Client Quit]
michael_mbp has quit [Ping timeout: 240 seconds]
michael_mbp has joined #jruby
cremes has joined #jruby
cremes has quit [Quit: cremes]
cremes has joined #jruby
akp has joined #jruby
akp has quit [Client Quit]
Liothen has quit [Remote host closed the connection]
Liothen has joined #jruby
Liothen has quit [Quit: The Dogmatic Law of Shadowsong]
Liothen has joined #jruby
Puffball has joined #jruby
cremes_ has joined #jruby
cremes has quit [Ping timeout: 268 seconds]
cremes_ is now known as cremes
claudiuinberlin has joined #jruby
shellac has joined #jruby
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
drbobbeaty has joined #jruby
drbobbeaty has quit [Ping timeout: 260 seconds]
drbobbeaty has joined #jruby
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Ha-Sch has joined #jruby
<Ha-Sch>
Hi - i have a problem with JRuby 9.1.15 and warbler 2.0.4
<Ha-Sch>
on windows 10
<Ha-Sch>
I set the config.compile_gems to true in the warble.rb
<Ha-Sch>
if i run warble then i get the following error:
<headius>
Ha-Sch: hello
<Ha-Sch>
IOError: Cannot run program "cmd.exe" (in directory "C:\Hagen\apps\leaman"): CreateProcess error=206, Der Dateiname oder die Erweiterung ist zu lang
Puffball has quit [Read error: Connection reset by peer]
qmx has quit []
qmx has joined #jruby
<kares>
headius: enebo: any chance we can (as in 1.7) start mixing (arg0) + (args[]) @JRuby methods?
<kares>
trying to implement Date.new natively which is a lot of code in one but when broken down to pieces most methods are pretty simple
<kares>
got as far as civil(ThreadContext context, IRubyObject self, IRubyObject year, IRubyObject month, IRubyObject mday) but than it also allows for a 4-th arg :)
<headius>
kares: only limiting factor is doing the work to implement it
<kares>
ooh noo :)
<headius>
we have a LOT of call paths and they only know about 0-3 plus []
<kares>
yeah but 0-3 + [] used to work together right?
<kares>
I mean for the same method
<headius>
but on the other hand, only the JIT really needs to be able to do this, so that reduces it to indy logic and CallSite* logic
<headius>
0-3 + [] never worked
<headius>
it will error during build
<headius>
well, 1-3 + []
<kares>
hmm I recall it did in 1.7
<headius>
I certainly didn't take it out...if it worked it was accidental
<kares>
not 100% but there was a piece similar to what I am trying to do now
<headius>
I have never written logic to partially box arg list
<enebo>
kares: [] is required in 9k due to IR limitation we never fixed
<enebo>
kares: but I thought you could mix specific with catchall
<headius>
you can try it yourself...just throw another IRubyObect[] on the end of that decl and try to compile it
<enebo>
kares: in 9k you can for sure
<headius>
you can have multiple yes
<kares>
okay thanks enebo ... will double check the issue
<headius>
but not specific and [] in same signature
<enebo>
oh in same signature
<kares>
well that is what I am after :)
<enebo>
sorry I did not read that
<enebo>
kares: you know headius and I have discussed boiling the arg ocean many times
<kares>
so its not complete non-sense?
<enebo>
kares: in addition to being more flexible we always wanted to annotate type coercion into the anno
<headius>
specific and variable arity in same signature, yeah, I have wanted that too
<headius>
better would be simply dropping the specific arity limit or making it suitably large using code generation
<kares>
> enebo: annotate type coercion into the anno
<enebo>
kares: I think IRubyObject one, IRubyObject[] rest is pretty reasonable but that invoker logic will get a bit more complicated
<headius>
like up to ten or something
<kares>
not sure I got it?
<kares>
maybe a simple example would help what you mean
<GitHub155>
[jruby] dersar00 opened issue #5033: How to connect to mysql? https://git.io/vAe1Z
<enebo>
static final IRubyObejct capitalize(ThreadContext context, RubyString self)
<headius>
that one actually works already
<enebo>
headius: I thought you ran into an issue?
<kares>
aaah that @Coerce goes quite far
<headius>
but I only did that one
<enebo>
oh only string?
<headius>
not really an issue, just combinatorial complexity in the generation
<headius>
I didn't keep going with it at the time
<enebo>
ok I just remember the experiment ending but not that it landed :)
<headius>
I'm not sure any of our existing signatures use it
<enebo>
well I know I have not used it
<enebo>
In truth we need multimethod or pattern matching Java does not have
<enebo>
Many methods are RubyFixnum or RubyNil
<headius>
yeah
<enebo>
So we should have two method defs for those two types
<enebo>
I guess that is possible with @JRubyMethod
<headius>
there's potential perf gain from auto-coercing too: if there's no need to coerce it will pass straight through from call site to method as a non-interface type
<enebo>
but as you say verifying complete agreement and combinatorial complexity would make that icky
<headius>
but that requires JIT plumbing
<enebo>
and since we do a lot of startup we don't want slow
<enebo>
headius: ah yeah true just asking if it is available and we practically have poor man truffle (not ast but method boundary)
<headius>
kares: the place to start would be in JavaMethod* (the DynamicMethod ones, not the JI ones) and InvocationMethodFactory
<headius>
on the call side, we have a hard requirement that the [] version always work, so adding 4, 5, 6 arg signatures would initially just fall into those paths
<headius>
but once we have them generating, we can start calling them
<enebo>
did someone ask for higher arity?
<headius>
oh! and Ruby methods already spread all fixed-arity forms in the JIT
<headius>
enebo: yeah kares said he needed four above
<enebo>
we did a histogram and I think only like date was weird
<headius>
or 3 + []
<headius>
and it is date too :-)
<kares>
interestingly my special case works when I run a single test but not the whole suite
<enebo>
hahaha
<enebo>
when I said "only" I was not being literal but that one method is up to arity 13 or something now :)
<kares>
have (), (arg1), (arg1, arg2), (arg1, 2, 3), (args[]) for the same method
<headius>
I'd rather not manually add lots more arities if we can punt it to codegen, like DynamicScope and the specialized RubyObject fields
<headius>
kares: that should be fine
<headius>
that will be a JavaMethodZeroOrOneOrTwoOrThreeOrN
<enebo>
yeah as someone how has been manually messing with String to ByteList RubySymbol in callsites and *Method objects I concur :)
<kares>
okey - recall we did some changes in AR-JDBC when 9K was released as it did not work
<enebo>
I did not end up doing it but we have way too much manual code
<kares>
(there was a similar case as the one I am hitting)
<enebo>
not that I think AOT generated code is the way to s9olve that
<enebo>
we have tried that several times
<headius>
kares: enebo and I were actually just discussing overhead of IRubyObject[]...this would help start eliminating that
<headius>
we also need to finally sort out the Block call paths because they're wack
<headius>
I can't indify them which means even if I force a Ruby receiver to inline they won't optimize right
<enebo>
block is still confusing but I drastically simplified the two main IR paths
<kares>
ah there's Block in the end - guess that's another level of combinatorics :)
<headius>
well can't = there's too much logic in Block.call/yield to stuff into method handles
<enebo>
although the path to those two code paths is like 60
<headius>
need to push more arg fiddling down into IR
<enebo>
yeah
<headius>
and split out lambda vs proc call paths
<enebo>
that prelude arg stuff
<headius>
that's the big hassle right now
<enebo>
I was thinking about that prelude stuff the other day for no reason
<headius>
kares: what problem are you having with that binding?
<enebo>
I wondered why we did not think about making n methods which all call to the same method on bytecode side
<enebo>
each n is for each combo of args to prelude setup
<enebo>
IR body itself would just be ordinary
<enebo>
if things only called through one then JVM would inline all that nicely
<enebo>
assuming it is small
<kares>
the Block form none
<enebo>
On IR side the solution is inlining
<kares>
as I mentioned - Date.new runs fine when I run a single test
<kares>
but the whole suite gets me into: ArgumentError: wrong number of arguments (3 for 4)
<enebo>
but inlining on IR will be limited in how often it can happen so seems like JVM JIT friendliness is pretty important
<enebo>
anyways I am not helping with this talk
<headius>
enebo: you mean for optional args?
<headius>
fixed-arity methods already are expanded to args in the jIT
<headius>
JIT
<headius>
up to 255 or whatever
<enebo>
headius: I mean for generating binding value logic for blocks
<headius>
binding value?
<enebo>
headius: right now we do it in one place and all paths flow through it
<enebo>
setupArgs or something in IRBlocckBofy
<headius>
oh like frame stuff?
<headius>
oh right ok
<headius>
yeah
<headius>
I think it has something to do with lambda vs proc too...we don't split those paths so when it comes to arg logic we have to check every time
<enebo>
yeah we talked about generating code per so we can let that potentially inline or maybe even reason about it other ways (like escaping something)
<headius>
which is easier if it's just [] all the time
<enebo>
oh well lambda/proc is maybe part of that as well but that is a huge issue in IR as well
<enebo>
since we don't know statically we generate for worst case
<headius>
if we had separate lambda and proc call paths, plus separate *lazy* code generation for both types of call, we could wipe out some of that boxing
<enebo>
which adds some overhead to things like returns
<enebo>
which is very noticeable in simple blocks
<headius>
99% of blocks would use the proc logic and never generate lambda logic
<enebo>
yeah
<headius>
code generation solves everything
<headius>
it's just painful to write :-)
<enebo>
fuck it we will trace the whole APP
<enebo>
subbu: moving to tracing JIT
<enebo>
too early for jokes like that
<enebo>
but yeah code generation definitely allows making an optimal amount of code but besides being painful we can only generate so much code
<enebo>
Seems like the JVM does not love having 100k classes
xardion has quit [Remote host closed the connection]
xardion has joined #jruby
<headius>
yeah, that's another fun issue altogether
<headius>
we don't want to compile the world either
<headius>
much fun ahead...combine all this with jruby-graal, startup time and AOT features from various JVMs, continuations in the JVM...