<GitHub125>
[jruby] headius closed issue #3685: java.lang.NoSuchMethodError: org.jruby.RubyIO.flush()Lorg/jruby/RubyIO when using Net::HTTP with openssl on jruby 9.0.3.0 https://git.io/vgjSX
tcrawley-away is now known as tcrawley
tcrawley is now known as tcrawley-away
mattwildig has quit [Remote host closed the connection]
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
skade has joined #jruby
skade has quit [Client Quit]
tomjoro has quit [Remote host closed the connection]
thedarkone2 has quit [Quit: thedarkone2]
nirvdrum has quit [Ping timeout: 250 seconds]
rsim has joined #jruby
mattwildig has joined #jruby
mattwildig has quit [Ping timeout: 276 seconds]
jensnockert has joined #jruby
tomjoro has joined #jruby
jensnockert has quit [Ping timeout: 250 seconds]
rsim has quit [Quit: Leaving.]
rsim has joined #jruby
jensnockert has joined #jruby
yfeldblum has quit [Ping timeout: 240 seconds]
<GitHub100>
[jruby] kares commented on commit 3806de1: used to work without `-Djruby.home` or did it not? wondered if its not a regression as it came up in IT tests... https://git.io/v23vM
brauliobo_ has quit [Remote host closed the connection]
vtunka has joined #jruby
elia has joined #jruby
blaxter has joined #jruby
skade has quit [Quit: Computer has gone to sleep.]
skade has joined #jruby
vtunka has quit [Quit: Leaving]
rsim has joined #jruby
joast has quit [Ping timeout: 255 seconds]
vtunka has joined #jruby
shellac has joined #jruby
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
drbobbeaty has joined #jruby
pawnbox has quit [Remote host closed the connection]
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
pawnbox has joined #jruby
skade has quit [Quit: Computer has gone to sleep.]
<GitHub8>
[jruby] mkristian commented on commit 3806de1: @kares looking through the test. it runs using lib/jruby.jar and with this you need to set jruby.home.... https://git.io/v23EZ
mattwildig has joined #jruby
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
<GitHub2>
[jruby] eregon commented on commit 574f975: Yes, it's on purpose so the AST of a module body is not included in the surrounding scope (module or top-level). One way to make this clearer would be to pass the definitionMethod as a `Calltarget` as we do for normal methods. https://git.io/v23uq
<GitHub160>
[jruby] eregon commented on commit 574f975: The current code seems fine, since the definition node does not include the body in its `@Child` but as a CallTarget. https://git.io/v23gG
tjohnson has quit [Quit: Connection closed for inactivity]
<rsim>
lopex: As I see you did a lot of refactoring and changes in joni version 2.1.6
<lopex>
rsim: hey there, yeah, but I have no idea which one might be the culprit
<lopex>
rsim: the slow case insensitive search was always broken though
<rsim>
lopex: I cannot reproduce the problem in JRuby 1.7.23 so I assume that either joni or jcodings version update is causing this
<lopex>
rsim: maybe it might be worth to check joni against older versions of jruby
<lopex>
rsim: even changes in threading on jruby side might affect things
<lopex>
doubt it though
<rsim>
lopex: Or maybe it would be worth to try to to use joni version 2.13 with JRuby 1.7.24. Can I just update all org.joni.* classes in jruby-complete jar?
<lopex>
rsim: the public api shouldnt have changed, so I guess yes
<lopex>
oh, there might be some changes in jcodings though
<lopex>
rsim: the only idea I can come up now with is that this slow IC isnt used there in older versions
<lopex>
but that didnt change for a long time as well
<lopex>
rsim: anyways, replacing the classes for joni alone should work
<rsim>
lopex: ok, will try now
<lopex>
looking through the commits
jensnockert has quit [Remote host closed the connection]
<rsim>
lopex: updated jruby-complete-1.7.24.jar joni from jruby-complete-1.7.23.jar and I cannot reproduce the issue. So it seems that you need to look for case in the joni commits after version 2.1.3
<rsim>
for cause
<lopex>
rsim: thanks!, will do, still confused though :)
<lopex>
rsim: also, havent been able to reproduce that with master after the fix
<rsim>
lopex: Due to the problem we downgraded our application to JRuby 1.7.23. I assume that JRuby 1.7.25 where this could be fixed will not be released very soon?
<rsim>
lopex: Or is it safe to use patched JRuby 1.7.24 with joni from 1.7.23?
<GitHub99>
[jruby] chrisseaton commented on commit 9a13953: Did you fix anything or just re-enable it? It still seems to fail on Travis. https://git.io/v2sKE
camlow325 has joined #jruby
<GitHub62>
[jruby] chrisseaton pushed 1 new commit to master: https://git.io/v2s63
<GitHub62>
jruby/master cea55fb Chris Seaton: [Truffle] Exclude failing MRI Class test.
<GitHub153>
[jruby] headius pushed 3 new commits to ruby-2.3: https://git.io/v2s5D
<GitHub153>
jruby/ruby-2.3 b1652d9 Charles Oliver Nutter: Unbreak num2dbl by rejecting non-numerics.
<GitHub153>
jruby/ruby-2.3 26e4325 Charles Oliver Nutter: Guard nils from format hash.
<GitHub153>
jruby/ruby-2.3 484ccc3 Charles Oliver Nutter: Unbreak String#reverse MBC VALID path.
blandflakes has joined #jruby
donV has quit [Quit: donV]
<lopex>
rsim: no idea, these havent been tested together
<rsim>
lopex: ok, therefore we are downgrading to 1.7.23 and will wait for 1.7.25
<rsim>
lopex: it would be good to put a note in 1.7.24 and 9.0.5 release notes that there is this regexp problem when using multiple threads - as this problem most probably will not be detected by application test suites
rcvalle has joined #jruby
<lopex>
rsim: yes
<lopex>
headius ^^
headius2 has joined #jruby
pawnbox has quit [Read error: Connection reset by peer]
pawnbox has joined #jruby
skade has quit [Quit: Computer has gone to sleep.]
camlow325 has quit [Read error: Connection reset by peer]
camlow325 has joined #jruby
<koochdog>
Anyone know why JVM is slowing to a crawl after doing a 20k inserts something like 20000.times do { ActiveRecord::base.connection.execute("INSERT INTO some_table....") }
<koochdog>
Trinidad, ARJDBC, and MySQL
<koochdog>
Or any flags that might help me debug it
<koochdog>
Eventually java.lang.OutOfMemoryError: Java heap space
<eregon>
It failed already 4 builds consecutively so I would call that reproducible, even though locally it does not of course
<eregon>
or maybe a way to skip gem installation since it's not useful for that particular job
<chrisseaton>
koochdog: what is the size of your heap?
<koochdog>
chrisseaton: the default of 512
<chrisseaton>
Maybe just try larger - 1G
<koochdog>
chrisseaton: will do also going to dump the heap. The thing that is a bit strange is it will get through that loop successfuly once, the second it will finish but slowly, 3rd time it will fail
<chrisseaton>
koochdog: could be the compiler taking up space as it goes through the second and third loop
jensnockert has quit [Remote host closed the connection]
ITXpander has quit [Quit: Leaving.]
d-snp has quit [Ping timeout: 268 seconds]
<koochdog>
headius2: chrisseaton: The larger heap seems to have fixed the issue, is there a simple explanation for why it would run a few times on the smaller size before running out of heap? It seems like if it could go through the loop once or twice it would be able to GC enough every time to keep doing it.
<chrisseaton>
The compiler running, for example
<chrisseaton>
Caches being populated
<chrisseaton>
Lots of things
<chrisseaton>
Do the second and third loops run faster? The memory has been used to do that
<koochdog>
It seems like the larger heap actually just greatly delayed my issue
<koochdog>
It's running slow now but it has taken probably 10 - 12 loops to do
<chrisseaton>
koochdog: Can you give us some more info from scratch - what version of JRuby is this?
<lopex>
in the second one optimize: EXACT_IC is used
<lopex>
after the onigmo catch up it is no longer as eager building alternatives on ast
<GitHub7>
[jruby] chrisseaton deleted truffle-om-dsl at d3efd79: https://git.io/v2GuC
<GitHub20>
[jruby] chrisseaton created truffle-om-dsl (+3 new commits): https://git.io/v2GuW
<GitHub20>
jruby/truffle-om-dsl b179b13 Chris Seaton: [Truffle] Adopt the OM DSL.
<GitHub20>
jruby/truffle-om-dsl 11af570 Chris Seaton: Merge branch 'truffle-head' into truffle-om-dsl
<GitHub20>
jruby/truffle-om-dsl 0bf6f7a Chris Seaton: [Truffle] Don't use fully qualified interface name.
<lopex>
rsim: so that bug was always there waiting to show up at any point
mattwildig has quit [Remote host closed the connection]
<rsim>
lopex: ok, it's good that you finally found it :)
<lopex>
rsim: whoops that's the first one, swapped links
<lopex>
rsim: I always had mixed feelings with these things, like having an IC bytecode or use alternatives
<lopex>
wrt performance
<chrisseaton>
koochdog: maybe retry with latest JRuby 1.7.x and JRuby 9.x
<chrisseaton>
koochdog: if you still see problems, please file an issue with as much info as you can
<koochdog>
chrisseaton: will do, going to look into a few more things like development mode vs prod, trinidad vs creating war and running on tomcat etc
<chrisseaton>
Also try with 2G, 4G etc - if it's still running out of memory at that point (after extra time of course) then it's almost certainly a leak
skade has quit [Quit: Computer has gone to sleep.]
<chrisseaton>
And see if the app works on MRI - if it fails there as well then the problem may be yours
<chrisseaton>
(your app may simply try to allocate that much memory)
<koochdog>
Yeah, if it still keeps failing I'll put together a simple demo to try to reproduce maybe just a script with the AR and ARJDBC gems
<lopex>
chrisseaton: no idea, at this point it would be better to support existing fast implementation
<lopex>
chrisseaton: btw zippy seems to have stagnated now a bit ?
<chrisseaton>
lopex: it was being worked on an by a group of academics who moved onto other things after doing the research they wanted
<chrisseaton>
it was never a project on the same level as JS or Ruby
<lopex>
chrisseaton: I also remember fijal saying that it has worse warmup times than pypy
<lopex>
ok
<lopex>
yeah, I kind of felt that's the case
pawnbox has joined #jruby
elia has joined #jruby
<chrisseaton>
lopex: it probably does warmup slower than PyPy, but the fact that a couple of them could beat PyPy's performance without a huge investment in an ongoing project is fantastic
pawnbox has quit [Ping timeout: 244 seconds]
HalcyonicStorm has joined #jruby
<thedarkone2>
going by his comments on the post, right now he seems to know nothing (maybe because he just thought about it for 5 minutes, while writing that blogpost), that's why he's guessing it is viable…
<chrisseaton>
Yes, clearly everyone else who has invested decades of time into trying to optimise Python is missing some unique piece of wisdom that is totally obvious to him
<thedarkone2>
I don't think it's the python that is the problem, I think he could have identical comments about Ruby
<thedarkone2>
I think he just doesn't know enough about llvm ...
jensnock_ has quit [Remote host closed the connection]
<chrisseaton>
Anyone who knows LLVM will tell you immediately that you need a whole optimising compiler and IR on top of it to handle a dynamic language
<thedarkone2>
btw I remember that in some video lecture he said, he would never do VM (or maybe JIT) in non-managed lang, so clearly he needs to pick up Graal :)
<thedarkone2>
yeah, isn't it that if you want to use LLVM for a dyn lang, it is pretty much equivalent to using (even dynamic) source to C/C++ translation
<chrisseaton>
thedarkone2: did you see we're running Rails on Truffle?
<thedarkone2>
no, without AR?
<thedarkone2>
AR = DB
<chrisseaton>
It's just the model and view layers, on top of Webrick
<thedarkone2>
and router, right?
<chrisseaton>
Yeah
<chrisseaton>
It's hello world, basically - renders a template and some stuff like that
<thedarkone2>
that is kinda cool, wonder if it fully JITs
camlow32_ has quit [Remote host closed the connection]
<chrisseaton>
it does JIT, but we haven't looked into what JITs and if that's the right stuff etc
<chrisseaton>
Our IO layer is the one of the biggest messes we have - lots and lots of copying, so we need to tighten that up - aiming at benchmarking and tuning simple webrick server performance first
e_dub has quit [Read error: Connection reset by peer]
e_dub has joined #jruby
<thedarkone2>
so, this is it, your job is done, you can now retire :)
camlow325 has quit [Remote host closed the connection]
<chrisseaton>
thedarkone2: this was our goal for the calendar year!
<chrisseaton>
we'll get a database app working now, start testing gems, get infrastructure like rack and gems working
<thedarkone2>
chrisseaton: geee, time flies fast
<chrisseaton>
rake I mean
<lopex>
considering the behemoth rails is now it might be a bigger step than jruby had before
<lopex>
chrisseaton: by bailout you mean a total bailout ?
<thedarkone2>
yeah, I bet its like 4x loc
<chrisseaton>
any bailout I think
<chrisseaton>
I think we probably could have been running it a bit earlier - it didn't take more than a few days to get Rails running when we really sat down and tried - maybe we've focused too much on specs and corner cases
<lopex>
chrisseaton: but inbetween it can bailout to specialize with less specialized versions right ?
<chrisseaton>
lopex: if the JIT is running then ideally everything has already specialised as much as its going to
<lopex>
chrisseaton: so in steady state right ?
<chrisseaton>
yeah
<lopex>
ok
<chrisseaton>
every time the AST changes we back off from compilation for a little longer
<thedarkone2>
lopex: bailout is the code that truffle graal wouldn't able to JIT at all
<lopex>
thedarkone2: but it can have too specialized versions in the midst of loading
<lopex>
it will have to bailout potentially many times
<lopex>
when loading
lupine has left #jruby [#jruby]
<koochdog>
chrisseaton: headius2: Regarding the slow down on the mass-inserts if I do it on a new thread the issues are gone
whitby has joined #jruby
<chrisseaton>
lopex: but if it's still specialising it won't start compiling
<thedarkone2>
lopex: no, that would be a "deoptimize", "bailout" is an error during JITing
<lopex>
chrisseaton: are the reprofiling heuristics much more different than in hotspot ?
<chrisseaton>
lopex: I don't know HS well enough to comment, sorry
<lopex>
chrisseaton: yeah, graph with timelines per method might show something interesting
<lopex>
adaptive heuristics is another story right ?
<chrisseaton>
yes it's a big multi-dimensional problem and very hard to visualise
<chrisseaton>
at some point we need to do a study varying all our heuristics running real apps and figure out best defaults
camlow325 has joined #jruby
camlow325 has quit [Remote host closed the connection]
<lopex>
thedarkone2: right, no idea why I mixed these two
<thedarkone2>
chrisseaton: ohh, maybe he forgot that he doesn't want to do it? :)
<lopex>
thedarkone2: like the plaguing mehtod too big one
<lopex>
thedarkone2: was there sometimg like method too complex ?
<chrisseaton>
yes that's a bailout
<thedarkone2>
lopex: yeah, or just a bug in jruby+truffle or truffle or graal, so it could run Rails in interpreter, but would fail to JIT some methods...
<chrisseaton>
a deoptimisation is something you want to happen (when needed), a bailout is either a bug or a limitation that you'd rather not have
<lopex>
thedarkone2: yes, I was talking about deopt
<lopex>
chrisseaton: so insufficient specialization in truffle might be one, is there reporting/logging for that too ?
<chrisseaton>
-J-G:+TraceTruffleCompilation will show you both bailouts and deopts
<chrisseaton>
If you write some code using some crazy core library methods or maybe regexes or something you may be able to trigger a bailout as we haven't tested those with compilation in all cases
<chrisseaton>
We call deopt 'transfer to interpreter' and bailout 'opt fail' which may make them clearer