camlow32_ has joined #jruby
camlow32_ has quit [Read error: Connection reset by peer]
camlow32_ has joined #jruby
baroquebobcat has quit [Quit: baroquebobcat]
camlow325 has quit [Ping timeout: 255 seconds]
subbu has joined #jruby
<rtyler> my kingdom for a 9000 preview on central!
* rtyler cries
DrShoggoth has quit [Quit: Leaving]
donV has joined #jruby
<donV> Hi all!
camlow32_ has quit [Remote host closed the connection]
<donV> chrisseaton: Hi! you on?
<chrisseaton> donV: try me in 30 mins if you can
<donV> Well, going to bed in a second. Just wanted to warn about the nightly builds.
<donV> chrisseaton: http://lafo.ssw.uni-linz.ac.at/graalvm/ there are some extra jars in the jruby-jars.gem
<donV> Breaks my build…no hurry…going to sleep :)
<donV> jruby-jars-9.0.0.0.pre1.gem 20-Jan-2015 04:00 43M
<donV> Used to be half of that.
<donV> Night all! See you tomorrow!
iamjarvo has joined #jruby
elia has quit [Quit: Computer has gone to sleep.]
elia has joined #jruby
mister_solo has joined #jruby
elia has quit [Ping timeout: 256 seconds]
slyphon has joined #jruby
mister_solo has quit [Ping timeout: 245 seconds]
mitchellhenke has joined #jruby
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
calavera has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
pietr0 has quit [Quit: pietr0]
camlow325 has joined #jruby
rcvalle has quit [Quit: rcvalle]
pgokeeffe has quit [Quit: pgokeeffe]
iamjarvo has joined #jruby
josh-k_ has quit [Remote host closed the connection]
multibot_ has quit [Ping timeout: 245 seconds]
multibot_ has joined #jruby
yfeldblu_ has joined #jruby
yfeldblum has quit [Ping timeout: 276 seconds]
calavera has joined #jruby
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
yfeldblu_ has quit [Remote host closed the connection]
yfeldblum has joined #jruby
camlow325 has quit [Remote host closed the connection]
erikhatcher has quit [Quit: erikhatcher]
nirvdrum has quit [Ping timeout: 255 seconds]
mitchellhenke has quit [Quit: Computer has gone to sleep.]
Hobogrammer_ has joined #jruby
Hobogrammer has quit [Ping timeout: 245 seconds]
mitchellhenke has joined #jruby
mitchellhenke has quit [Client Quit]
pgokeeffe has joined #jruby
zorak8 has quit [Ping timeout: 246 seconds]
mrmargolis has joined #jruby
calavera has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
iamjarvo has joined #jruby
mitchellhenke has joined #jruby
DomKM has joined #jruby
mitchellhenke has quit [Quit: Computer has gone to sleep.]
subbu has quit [Ping timeout: 264 seconds]
kl__ has quit [Ping timeout: 265 seconds]
mrmargolis has quit [Remote host closed the connection]
pgokeeffe has quit [Quit: pgokeeffe]
pgokeeffe has joined #jruby
jc00ke has quit [Ping timeout: 245 seconds]
mjc_ has quit [Ping timeout: 244 seconds]
fidothe has quit [Ping timeout: 276 seconds]
Who has joined #jruby
Who has quit [Read error: Connection reset by peer]
pgokeeffe has quit [Quit: pgokeeffe]
zorak8 has joined #jruby
pgokeeffe has joined #jruby
metadave has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
mjc_ has joined #jruby
fidothe has joined #jruby
Who has joined #jruby
mjc_ has quit [Ping timeout: 245 seconds]
fidothe has quit [Read error: Connection reset by peer]
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
pgokeeffe has quit [Quit: pgokeeffe]
Who has quit [Ping timeout: 240 seconds]
jc00ke has joined #jruby
fidothe has joined #jruby
anaeem1_ has joined #jruby
mjc_ has joined #jruby
pgokeeffe has joined #jruby
yfeldblum has quit [Remote host closed the connection]
towski has quit [Ping timeout: 246 seconds]
anaeem1_ has quit [Read error: Connection reset by peer]
anaeem1_ has joined #jruby
yfeldblum has joined #jruby
yfeldblu_ has joined #jruby
johnmuhl has quit [Quit: Connection closed for inactivity]
yfeldblum has quit [Ping timeout: 245 seconds]
yfeldblu_ has quit [Remote host closed the connection]
yfeldblum has joined #jruby
Aethenelle has joined #jruby
calavera has joined #jruby
towski has joined #jruby
calavera has quit [Client Quit]
calavera has joined #jruby
zorak8 has quit [Ping timeout: 245 seconds]
havenwood has joined #jruby
e_dub has joined #jruby
Who has joined #jruby
colinsurprenant has joined #jruby
colinsurprenant has quit [Client Quit]
kl has joined #jruby
mrmargolis has joined #jruby
colinsurprenant has joined #jruby
colinsurprenant has quit [Client Quit]
kl has quit [Ping timeout: 264 seconds]
mrmargolis has quit [Ping timeout: 246 seconds]
baroquebobcat has joined #jruby
Hobogrammer_ has quit [Ping timeout: 264 seconds]
subbu has joined #jruby
Hobogrammer has joined #jruby
Who has quit [Ping timeout: 256 seconds]
dhinojosa has quit [Ping timeout: 255 seconds]
JRubyGithub has joined #jruby
<JRubyGithub> [jruby] blanquer opened issue #2489: Proc.parameters return an empty array http://git.io/8f1tow
JRubyGithub has left #jruby [#jruby]
subbu has quit [Quit: Ex-Chat]
enebo has quit [Read error: Connection reset by peer]
enebo has joined #jruby
baroquebobcat has quit [Quit: baroquebobcat]
calavera has quit [Quit: Textual IRC Client: www.textualapp.com]
pgokeeffe has quit [Quit: pgokeeffe]
skade has joined #jruby
donV has quit [Quit: donV]
skade has quit [Quit: Computer has gone to sleep.]
noop has joined #jruby
mysteriouspants has joined #jruby
skade has joined #jruby
skade has quit [Quit: Computer has gone to sleep.]
donV has joined #jruby
djellemah has joined #jruby
havenwood has quit [Remote host closed the connection]
temporalfox has joined #jruby
josh-k has joined #jruby
josh-k has quit [Read error: Connection reset by peer]
josh-k has joined #jruby
nirvdrum has joined #jruby
slyphon has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
vyorkin has joined #jruby
kares has joined #jruby
multibot_ has quit [Read error: Connection reset by peer]
multibot_ has joined #jruby
rsim has joined #jruby
josh-k has quit [Remote host closed the connection]
mister_solo has joined #jruby
djellemah has quit [Ping timeout: 252 seconds]
Specialist has joined #jruby
elia has joined #jruby
pchalupa has joined #jruby
djellemah has joined #jruby
JohnBat26 has joined #jruby
vyorkin has quit [Quit: WeeChat 1.0.1]
yfeldblum has quit [Ping timeout: 264 seconds]
JohnBat26 has quit [Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/]
josh-k has joined #jruby
benlovell has joined #jruby
djellemah has quit [Ping timeout: 265 seconds]
nirvdrum has quit [Ping timeout: 240 seconds]
marr has joined #jruby
zorak8 has joined #jruby
nirvdrum has joined #jruby
rsim1 has joined #jruby
rsim has quit [Read error: Connection reset by peer]
djellemah has joined #jruby
nirvdrum has quit [Ping timeout: 276 seconds]
kl__ has joined #jruby
Hobogrammer has quit [Ping timeout: 244 seconds]
kl__ has quit [Ping timeout: 256 seconds]
kl__ has joined #jruby
kl__ has quit [Ping timeout: 256 seconds]
djellemah has quit [Ping timeout: 245 seconds]
kl__ has joined #jruby
nirvdrum has joined #jruby
JohnBat26 has joined #jruby
vtunka has joined #jruby
nirvdrum_ has joined #jruby
nirvdrum has quit [Ping timeout: 245 seconds]
zorak8 has quit [Ping timeout: 256 seconds]
beawesomeinstead has quit [Quit: Connection closed for inactivity]
yfeldblum has joined #jruby
nirvdrum__ has joined #jruby
nirvdrum_ has quit [Read error: Connection reset by peer]
yfeldblu_ has joined #jruby
yfeldblum has quit [Ping timeout: 240 seconds]
vyorkin has joined #jruby
shellac has joined #jruby
paulswil_ has joined #jruby
nirvdrum__ has quit [Ping timeout: 256 seconds]
djellemah has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub> [jruby] eregon pushed 31 new commits to master: http://git.io/u6H1ZA
<JRubyGithub> jruby/master 65f9eb8 Benoit Daloze: [Truffle] Do an explicit SafepointManager.poll() when interrupted.
<JRubyGithub> jruby/master eb7bb6d Benoit Daloze: [Truffle] Reduce duplication in Kernel#exit.
<JRubyGithub> jruby/master a61ea6d Benoit Daloze: [Truffle] Explicitly mentions the Specialization throws an ArithmeticException....
JRubyGithub has left #jruby [#jruby]
djellemah has quit [Ping timeout: 255 seconds]
paulswi__ has joined #jruby
paulswil_ has quit [Ping timeout: 244 seconds]
paulswi__ has quit [Quit: Textual IRC Client: www.textualapp.com]
djellemah has joined #jruby
noop has quit [Quit: Leaving]
vyorkin has quit [Ping timeout: 245 seconds]
elia has quit [Quit: Computer has gone to sleep.]
vyorkin has joined #jruby
benlovell has quit [Ping timeout: 252 seconds]
nirvdrum__ has joined #jruby
Jamo has joined #jruby
kotk_ has joined #jruby
yfeldblu_ has quit [Ping timeout: 245 seconds]
kotk has quit [Ping timeout: 245 seconds]
mister_solo has quit [Ping timeout: 240 seconds]
yfeldblum has joined #jruby
benlovell has joined #jruby
rsim1 has quit [Quit: Leaving.]
Aethenelle has quit [Quit: Aethenelle]
elia has joined #jruby
nirvdrum__ has quit [Ping timeout: 265 seconds]
kl__ has quit [Ping timeout: 244 seconds]
kares has quit [Ping timeout: 264 seconds]
drbobbeaty has joined #jruby
iamjarvo_ has joined #jruby
elia has quit [Quit: Computer has gone to sleep.]
iamjarvo_ has quit [Max SendQ exceeded]
iamjarvo_ has joined #jruby
elia has joined #jruby
mister_solo has joined #jruby
anaeem1_ has quit [Remote host closed the connection]
JRubyGithub has joined #jruby
<JRubyGithub> [jruby] eregon opened issue #2490: Cleanup tags http://git.io/vcfzzA
JRubyGithub has left #jruby [#jruby]
metadave has joined #jruby
benlovell has quit [Ping timeout: 244 seconds]
elia has quit [Quit: (IRC Client: textualapp.com)]
bbrowning_away is now known as bbrowning
kl has joined #jruby
mister_solo has quit [Ping timeout: 256 seconds]
nirvdrum__ has joined #jruby
rsim1 has joined #jruby
tcrawley-away is now known as tcrawley
benlovell has joined #jruby
rcvalle has joined #jruby
johnmuhl has joined #jruby
nateberkopec has joined #jruby
iamjarvo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
elia has joined #jruby
yfeldblum has quit [Ping timeout: 265 seconds]
mitchellhenke has joined #jruby
elia has quit [Quit: Computer has gone to sleep.]
nirvdrum__ has quit [Quit: Leaving]
nirvdrum has joined #jruby
elia has joined #jruby
<nirvdrum> headius, chrisseaton: I don't know if you guys frequent /r/ruby, but if you do, this might be a comment worth responding to: https://www.reddit.com/r/ruby/comments/2t3up1/jruby_9000pre1_released/cnvw6hc
kares has joined #jruby
elia has quit [Quit: Computer has gone to sleep.]
erikhatcher has joined #jruby
asuka_ is now known as asuka
rsim1 has quit [Read error: Connection reset by peer]
e_dub has quit [Quit: e_dub]
viking has joined #jruby
viking has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub> [jruby] eregon pushed 3 new commits to master: http://git.io/-ST54w
<JRubyGithub> jruby/master 02ccb29 Benoit Daloze: [Truffle] Remove duplication between ClassNode and Kernel's version....
<JRubyGithub> jruby/master 9f7835a Benoit Daloze: [Truffle] Rename primitive properly.
<JRubyGithub> jruby/master 5854672 Benoit Daloze: [Truffle] Re-organize primitive classes: use the first word in the primitive....
JRubyGithub has left #jruby [#jruby]
mrmargolis has joined #jruby
mitchellhenke has quit [Quit: Computer has gone to sleep.]
donV has quit [Quit: donV]
elia has joined #jruby
vyorkin has quit [Quit: WeeChat 1.0.1]
erikhatcher has quit [Quit: erikhatcher]
JRubyGithub has joined #jruby
<JRubyGithub> [jruby] lephyrius opened issue #2491: Minitest rails not working on 9000 http://git.io/K2KESw
JRubyGithub has left #jruby [#jruby]
colinsurprenant has joined #jruby
yfeldblum has joined #jruby
yfeldblum has quit [Ping timeout: 244 seconds]
vtunka has quit [Quit: Leaving]
vtunka has joined #jruby
vtunka has quit [Client Quit]
vtunka has joined #jruby
mitchellhenke has joined #jruby
rsim has joined #jruby
<asarih> enebo: headius: congrats on 9.0.0.0.pre1!!!!!!!!1!!!!11111
triple_b has joined #jruby
<enebo> asarih: yeah thanks. So far not massive flames so that is good
<enebo> asarih: no problems yet?
<asarih> haven't heard any
vtunka has quit [Client Quit]
vtunka has joined #jruby
<enebo> only two reported issues so far and one was known and the other is vague :)
Hobogrammer has joined #jruby
gregorsc5 has joined #jruby
<nirvdrum> Woo hoo.
iamjarvo has joined #jruby
gregorsc5 has quit [Quit: Leaving.]
gregorsc5 has joined #jruby
e_dub has joined #jruby
calavera has joined #jruby
joast has quit [Quit: Leaving.]
calavera has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
vtunka has quit [Quit: Leaving]
<dfr|work> woooo!
<dfr|work> congrats on 9.0.0.0.pre1 indeed!
<dfr|work> :D
<cremes> headius: i’ll do some JRuby9pre1 testing on Windows to put the WIN32OLE stuff through its paces. I’ll file bugs if I find any. Give me a week.
diegoviola has joined #jruby
shellac has quit [Quit: Ex-Chat]
calavera has joined #jruby
johnmuhl has quit [Quit: Connection closed for inactivity]
<dfr|work> enebo, does 9k keep 1.8 support or no?
slyphon has joined #jruby
<kares> dfr|work: it's 2.2 only
triple_b has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<dfr|work> kares, cool, thanks for verifying. :)
* dfr|work wishes he didn't have to get all of his company upgraded to latest joda_time to use 1.9+ jruby :(
<kares> dfr|work: class-loader magic can probably help ...
<dfr|work> kares, huh?
<dfr|work> kares, as in have half of the company use one version and half the other? :)
<kares> dfr|work: have jruby use it's own while java stuff any it wishes ...
<dfr|work> kares, we have a company policy to have only one version of a dependency at the same time, at least for extended amount of duration
<dfr|work> and tbh, I agree with that policy, it's just when you need something new the work needed to upgrade the whole codebase is a bit tricky
<dfr|work> and joda_time is pretty central to a lot of projects.
<kares> dfr|work: well than your wish can not come true :) !
<dfr|work> kares, :D
<dfr|work> either way, excited about 9k. Maybe that'll force me to upgrade joda time after all :)
<kares> but in jruby it's an impl detail ... thus I would try to isolate it (if possible) to not impact what I'm using when it's a dependency
Aethenelle has joined #jruby
tenderlove has joined #jruby
calavera has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
yfeldblum has joined #jruby
pchalupa has quit [Quit: Leaving]
camlow325 has joined #jruby
erikhatcher has joined #jruby
joast has joined #jruby
yfeldblum has quit [Ping timeout: 252 seconds]
djellemah has quit [Ping timeout: 265 seconds]
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
havenwood has joined #jruby
djellemah has joined #jruby
kl has quit [Ping timeout: 240 seconds]
xandrews has quit [Remote host closed the connection]
baroquebobcat has joined #jruby
triple_b has joined #jruby
diegoviola has quit [Quit: WeeChat 1.0.1]
nirvdrum has quit [Ping timeout: 264 seconds]
JohnBat26 has quit [Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/]
<headius> g'day :-)
<headius> dfr|work: pretty sure master is on same joda as 1.7, so at least that doesn't change
skade has joined #jruby
colinsurprenant has quit [Ping timeout: 264 seconds]
benlovell has quit [Ping timeout: 256 seconds]
djellemah has quit [Quit: Leaving]
djellemah has joined #jruby
benlovell has joined #jruby
<dfr|work> headius, yes, but 1.8 doesn't make calls to joda_time 2.3 method calls ;)
<dfr|work> [and I'm talking about the 1.8 ruby stdlib]
<headius> oh I see
skade has quit [Quit: Computer has gone to sleep.]
JRubyGithub has joined #jruby
<JRubyGithub> [jruby] eregon pushed 8 new commits to master: http://git.io/3AroDw
<JRubyGithub> jruby/master 4cf525a Benoit Daloze: [Truffle] Make a clearer load order....
<JRubyGithub> jruby/master 0b5c39f Benoit Daloze: [Truffle] Add other aliases of hash#key? and remove shim.
<JRubyGithub> jruby/master 4a0e292 Benoit Daloze: [Truffle] Import Numeric#eql? from Rubinius.
JRubyGithub has left #jruby [#jruby]
benlovell has quit [Ping timeout: 244 seconds]
Hobogrammer has quit [Ping timeout: 276 seconds]
<flavorjones> I was planning on dropping Nokogiri 1.6.6 today, and want to support JRuby 9000, since it's likely the last 1.6 release ... but we have some broken tests related to #to_s behavior that we have been working around in "interesting" ways.
gregorsc5 has quit [Quit: Leaving.]
<flavorjones> If anyone has a few minutes to peek at the code and perhaps advise me on how to proceed, I've got an issue open at https://github.com/sparklemotion/nokogiri/issues/1228
<headius> flavorjones: ahh ok
<headius> what's the workload? just this issue?
<flavorjones> That's the only thing that's broken, and it's probably our fault.
<headius> oh, you say only thing there...that's amazing :-)
<flavorjones> INORITE!?
<headius> ah
<headius> ok
<headius> this is the sort of thing I expected to see
<headius> because 9k is 2.2 only we got rid of most of the bifurcation of methods
<flavorjones> Right, I assumed that our version-specific workaround would need to be worked-around. I just don't know enough to move quickly on it.
anaeem1_ has joined #jruby
<headius> right ok
Felystirra has joined #jruby
<headius> hah
<headius> yeah fun one
Felystirra has quit [Client Quit]
<headius> when we de-bifurcated the methods, some of them were modified to be like yours, with the real body in the 1.8 versions, and the old 1.9 versions calling the 1.8 versions
<headius> flavorjones: simple fix: copy body from to_s to to_s19
iamjarvo has joined #jruby
<headius> is the 1_9 version getting bound?
<flavorjones> OK, let me try it right now
<headius> oh I bet it isn't getting bound so it's just hitting your to_s19 because it overrides
<headius> because exception does bind it
<headius> yeah we should have fixed more of these split methods to always use the non "19" version as the master
<headius> it was a hard migration to make since we knew we were making methods taht used to do 1.8 behavior do 1.9
<flavorjones> OK, so still getting infinite recursion:
<flavorjones> nokogiri.XmlSyntaxError.to_s19(XmlSyntaxError.java:136)
<flavorjones> org.jruby.RubyException.to_s(RubyException.java:136)
<flavorjones> nokogiri.XmlSyntaxError.to_s19(XmlSyntaxError.java:136)
anaeem1_ has quit [Ping timeout: 276 seconds]
<headius> right, because to_s19 is calling super.to_s, which then calls to_s19
<headius> the relationship in 9k is that RubyException#to_s calls to_s19
anaeem1_ has joined #jruby
<headius> that's probably the wrong direction and we should fix them all to go the other way
<headius> flavorjones: make your to_s19 have the same content as to_s but call super.to_s19
<flavorjones> Oh, I see.
<headius> then all paths lead to the right place even if we fix this post-pre
<flavorjones> Rock, Works For Me™
<flavorjones> Thanks for the assist.
<headius> no problem
<headius> I'm thrilled this is the only failure you've seen :-)
elia has quit [Quit: Computer has gone to sleep.]
skade has joined #jruby
calavera has joined #jruby
benlovell has joined #jruby
<Antiarc> headius: I have a few failures for you, though I'm still narrowing them down
<Antiarc> I run Not-Rails-Apps on jruby, though :)
<headius> excellent
anaeem1_ has quit [Ping timeout: 240 seconds]
<Antiarc> Not sure what it's all about, but boilerpipe is a jar I use. Anyhow, I'm going to set up a totally pristine env and replicate it from the ground up later today
skade has quit [Quit: Computer has gone to sleep.]
<headius> Antiarc: are you using nokogiri too?
<Antiarc> I have it in place because one of my deps requires it, but I'm not actively using it
<Antiarc> I use jsoup rather than nokogiri
<Antiarc> but yes, it has been required in this codepath
<headius> if it's getting loaded then we're probably loading its copy of xerces
<headius> and then other code is seeing a different version via a different classloader
<Antiarc> Oh, okay. Interesting. Why would that break between 1.7. and 9k?
<headius> because 9k changed the classloader precedence in ways that worried me
<Antiarc> aha
<headius> I think we're going to have to revert that
<Antiarc> I had other issues with joda-time
<headius> file an issue with whatever you have please
<headius> it's probably a similar issue
<Antiarc> But I worked around them by monkeypatching jbundler to never load a not-jruby joda-time
<Antiarc> Will do
<Antiarc> Gonna see if I can come up with a simple repro case. I can't reproduce the issue in irb, oddly.
dhinojosa has joined #jruby
<Antiarc> So there's something not quite obvious happening
<headius> it's going to be squirrelly because it will depend on order those classes are accessed
erikhatcher has quit [Quit: erikhatcher]
<Antiarc> Okay, that gives me a good starting point
<Antiarc> I should be able to come up with an approximation to repro it then
skade has joined #jruby
<Antiarc> Have to do Real Work this morning but I'll get a repro case ticketed ASAP
<headius> excellent, thanks
<headius> asarih: what should folks specify for 9k preview on travis? same as rvm with "jruby-9.0.0.0.pre1"?
robbyoconnor has quit [Ping timeout: 264 seconds]
pietr0 has joined #jruby
erikhatcher has joined #jruby
brettporter has joined #jruby
calavera has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
benlovell has quit [Quit: leaving]
donV has joined #jruby
calavera has joined #jruby
<headius> mpapis: jruby-9.0.0.0 and jruby-9000 both still install master head...is there a reason for that?
anaeem1 has joined #jruby
<headius> several people are asking for something they can specify that's just "9k latest release"
mje113__ has joined #jruby
<Antiarc> Oh, also - is there something special I need to do to make jruby consoles work properly with readline (or equivalent)? Console behavior is quirky for me - ie, if I ctrl-c to break a line, the console doesn't go to the next line until I press return, and then it's indented
<headius> is that new behavior?
<headius> readline has barely changed between 1.7 and 9k
<headius> IO has changed drastically
<Antiarc> It's slightly regressed from 1.7 in a few minor ways, but no, the behavior's there in 1.7 too
<Antiarc> I just never bothered to ask
<Antiarc> I did run into an IO change yesterday, but I assumed it was just me using socket timeouts incorrectly. I'll throw the exception up here anyhow - sec
<headius> our readline is hackariffic
<headius> we're using jline and it has never been 100%
<Antiarc> http://i.imgur.com/hzs3vBQ.png - that doesn't go to the next prompt line until I hit "enter"
<Antiarc> And even then it tries to execute the previous line
<Antiarc> That's after pressing return
<headius> ahh, indeed
<headius> somethign about how it's trapping INT and what readline/irb are supposed to do then
<headius> probably same fix for both 1.7 and master, whatever it is
<Antiarc> MRI by comparisonm
<Antiarc> I realize that's a really awful way to make a bug report
<Antiarc> Just not sure how to else describe it, heh
<headius> yeah, I guess I've seen this too and never bothered to investigate
<headius> Antiarc: I've recorded screencasts for bugs before :-)
<headius> sometimes you need to see it live
<Antiarc> Anyhow, it's a minor thing, but I'll bet fixing it would improve the experience of people coming from MRI :)
<headius> yeah I agree
<mje113__> are there any new 9k specific tunings in jrubyrc that I should be aware of?
<Antiarc> http://i.imgur.com/Hs25VyM.png - there's 1.7. So there was a change in 9k where it is executing the interrupted line when you hit return that wasn't there in 1.7
<Antiarc> Which sounds potentially nasty
yfeldblum has joined #jruby
robbyoconnor has joined #jruby
<headius> huh, interesting
<mje113__> I just started running 9k in local tests and benchmarks and noticed some deviation (in performance) from 1.7.18 and figure it would be worth it to exhaust tweaking properties before I really dig in.
<headius> that could boil down to differences in irb between 1.9.3 and 2.2
<headius> mje113__: maybe, maybe not...there's a lot of one-off optimizations in 1.7 we haven't done yet for 9k
<headius> no specific tunings, no...if you're seeing lower perf it's something for us to improve
mkristian has joined #jruby
brettporter has left #jruby [#jruby]
<headius> best way to help would be to narrow down to specific things that are slower, if possible
<mje113__> headius: ok, how would it be best to report it? this specific benchmark is heavily regex dependent so that was the first thing I was going to look at
yfeldblum has quit [Ping timeout: 245 seconds]
<headius> mje113__: if you can give us a reproducible case, that's the way to start
<headius> reduced as much as possible
<headius> otherwise open a bug showing the perf difference and we'll work with you to profile on your end
<headius> --profile may help, and there's JVM-level profiling we can try too
<Antiarc> mje113__: If you have the option, attach with jvisualvm and use the CPU sampler
<Antiarc> If you can exercise the slow code over and over it should pop to the top of the sampling results pretty quickly
<mje113__> headius: great, I'll get to work on that. Antiarc: good idea, I'll try that as well
<Antiarc> If it's a remote process you can attach via jmx, though it's a little hairy to set up. Happy to help with it if that's the case.
<mje113__> thanks, though I can reproduce locally
<Antiarc> (remote attaching to prod instances and profiling them is easily one of my favorite features of jruby)
<headius> mje113__: you could try passing -Xcompile.invokedynamic=true too
<headius> I'm looking at the non-indy JIT and realizing I never cache literal regexp instances
<headius> bunch of little things like that yet to be added to JIT
<mje113__> cool
mister_solo has joined #jruby
<donV> Hi all!
<mje113__> wow, with invokedynamic on things are really all over the map. A lot improved but one in particular got crushed. That's only benching a few methods so should be easy to track down
<donV> chrisseaton: Hi! Di you have a look at the size of jruby-jars-9.0.0.0.pre1.gem at http://lafo.ssw.uni-linz.ac.at/graalvm/ ?
<enebo> donV: In regards to the size of complete the largest addition is maven stuff
anaeem1 has quit [Ping timeout: 244 seconds]
anaeem___ has joined #jruby
<headius> I hate that Callable.call throws exception
<enebo> donV: mkristian is working towards reducing that size ~20MB of stuff atm
<headius> mje113__: very interesting!
<mkristian> enebo, hmm - jruby-complete has no maven stuff ? some for the jruby-jars gem
<mkristian> some = same
<headius> mje113__: indy does have a longer warmup tail
<donV> enebo: I think there is something more serious going on
<enebo> mkristian: yeah that is what I am talking about
<enebo> mkristian: I think exploded it is about 20M ignoring dep gems you pull in
<donV> enebo mkristian : it is 46M
<headius> compressed it's probably 20M too
<headius> because it's 20M plus of .gem + jars
<donV> I think there are some extra copies of core in there.
kl__ has joined #jruby
<enebo> donV: I am saying mvn support stuff is 20M of the 46M
<headius> oh, but in complete it should only be 10M, unless the cached .gem is in there too
<headius> donV: crack it open and have a look
<mje113__> headius: yeah--I run about 100k iterations before entering a Benchmark.ips block--which also does it's own warmup. but that still doesn't explain what I'm seeing
<mkristian> enebo, donV you are talking about jruby-dist ? or jruby-jars ? or jruby-complete ?
<headius> mje113__: that should be good
<enebo> mkristian: well they are all larger but let me see which one I was looking at
<donV> mkristian: jruby-complete-9.0.0.0.pre1.jar
<headius> mje113__: -J-XX:+PrintGCDetails will show you if it's chewing through memory too fast
<headius> JVM flag
<headius> most perf issues are allocation, like the regex thing
anaeem___ has quit [Remote host closed the connection]
anaeem1 has joined #jruby
<enebo> ah ok well something I just found
<enebo> -rw-rw-rw- 2309 20-Jan-2015 14:36:20 META-INF/jruby.home/lib/ruby/stdlib/org/jruby/jruby/1.7.11/jruby-1.7.11.jar
<enebo> and stdlib
<headius> woohoo
<headius> double your jruby, double your fun
<mkristian> enebo, the jruby-complete jar I build yesterday was 28MB - not sure where this extra stuff is coming from
<mje113__> headius: I'll do more comparisons but does a line like: [GC (Allocation Failure) [PSYoungGen: 27264K->160K(33792K)]... mean bad things?
<headius> maybe we need to find out from truffle folks how they're building that
<headius> mje113__: that just means it filled up young gen and needed to collect
<headius> I know failure sounds bad
<enebo> mkristian: me neither since I always do a shallow clone in a brand new directory
<mje113__> ah yeah, gotcha
<headius> mje113__: your concern should be excessive young gen lines or ANY full GC lines
<enebo> mkristian: but I will say I do not see maven-tools in jruby-complete so I think I was looking in a different file
<headius> most tight-loop benchmarks should not hit old gen and should not trigger full GC
<mkristian> enebo, OK - I will look in this.
<enebo> mkristian: I basically do: cd .. && rm -rf release && git clone jruby release && cd release
<enebo> mvn clean deploy -Psonatype-oss-release -Prelease
skade has quit [Quit: Computer has gone to sleep.]
<enebo> mkristian: but this time around I also added -Pext
<mje113__> headius: yeah, there's a few full GCs in there--both for indy and non... and just to clarify, as I started bencing 9k vs. 1.7.18, I'm not focusing on the difference in 9k between indy and non.
<enebo> since we wanted readline resolved
<mje113__> not=now
<enebo> mkristian: and I think that might explain it
<mkristian> yes, I am afraid one of those profiles did mess up things again - like we had in jruby-1.7.x once
<headius> mje113__: yeah GC shouldn't be signficantly different if we're doing things right in 9k...if they are different, 9k is culprit
<enebo> mkristian: I think headius added a dep to readline against 1.7 and maybe that pulled it in?
<headius> then we can look at allocation traces etc
<mkristian> yes,
<headius> I'm also going to get some caching into the non-indy JIT so we can at least exclude that
anaeem1 has quit [Ping timeout: 240 seconds]
<headius> enebo: that dep was already there...I tried to make to make it depend on 9k but that messed with the build
<headius> as an external repo it would be fine
<enebo> mkristian: ok so the issue of reducing ruby-maven tooling has nothing to do with jruby-complete since I cannot find it in there
<mkristian> possible. anyways I need to cleanup truffle and readline. what about ripper ? does ripper go back into the main tree.
<headius> as long as it doesn't pull in pre1 jar for pre2 complete :-)
<mje113__> headius: so for this one specific bench it's about 1k ips with invoke dynamic ON, and over 7k ips with it OFF
<headius> mkristian: up to enebo
<enebo> headius: ok so you reverted that back to how it was but since we never did -Pext in a dist it added it to jruby-complete
<enebo> mkristian: I think it should go back into tree
<headius> mje113__: nice...sounds like something's not caching on indy side, probably rebinding a call site over and over
<mkristian> enebo, I looked into the tar-ball issue we discussed yesterday a bit.
<headius> mje113__: this is good stuff...maybe we should start by opening a general "mje113 performance findings" bug
<headius> we can link specific issues as we isolate them
<mje113__> heh, can do... going into back to back meetings in a bit so might be until tomorrow before I can make enough progress to open something
<headius> no problem...we'll be here
<headius> I will try to patch up the non-indy JIT a bit for you
<enebo> It might be nice to open them as independent issues (or we should upon realization of perf issues) so next release can show it has been fixed
e_dub has quit [Quit: e_dub]
skade has joined #jruby
<mje113__> headius: it's something with URI (stdlib)
<mje113__> but I'll get you more details in a bit
e_dub has joined #jruby
dhinojosa has quit [Ping timeout: 245 seconds]
<mkristian> enebo, jruby-complete-9.0.0.0.pre1.jar has nicely embedded jruby-1.7.11 and its dependencies ;)
<headius> mkristian: sweet
<headius> mje113__: excellent...I'll have a commit adding more caching in a moment
<mkristian> same for jruby-stdlib and of course those dist archives since they just use each after to build them
<Antiarc> mkristian: This may be related to that classpath bug I was discussing a bit ago, but I'm using jbundler to manage the stanford-core-nlp libs, which specify joda-time 2.1 as a dependency. This causes jruby 9k to barf itself because it ships its own copy of joda-time. It seems like jbundler could use a facility to warn to or ignore when you try to load a jar that'll conflict with jruby's core jars. Does that sound sane?
<chrisseaton> donV: can you start again? are you saying that the gem I'm hosting is corrupt or something else?
<Antiarc> I fixed it in my app by monkeypatching JBundler::ClasspathFile#require_classpath to never load joda-time, but that is a super nasty hack
<headius> mkristian: this is the issues I mentioned in gitter
<headius> I'm worried we need to undo the classloader change...we keep getting reports about it
rsim has quit [Quit: Leaving.]
mister_solo has quit [Ping timeout: 272 seconds]
<headius> chrisseaton: it appears our complete jar is including more than it should...probably not specific to your builds
anaeem1 has joined #jruby
<mkristian> Antiarc, so your using jbundler to load the jars or does it go via warbler ?
<chrisseaton> ok, i'll let the dust settle
<Antiarc> mkristian: jbundler
<Antiarc> That's how everything gets loaded up
<Antiarc> Even specifying joda-time-2.5 as an explicit dep in the jarfile, I get conflicts, presumably because it's just two copies of the jar, and jruby's reflection fails when it hits the jbundler version
<Antiarc> (2.5 being the version that jruby bundles)
<donV> chrisseaton: Sorry, I’ve got to go, but enebo and mkristian can fill you in, I think.
<chrisseaton> donV: they think it's a general problem, not related to my builds, so I'll see if they can fix it first
<lumeet> I love my Snowflake, she is freakin' crazy!
<lumeet> whoops.. sorry :)
<mkristian> Antiarc, hmm - I see.
<enebo> chrisseaton: donV is concerned about size but we found a much bigger size problem than anything truffle related
<mkristian> you can exclude those joda-time jars from standford-core-nlp
<mpapis> headius, what version of rvm does install the master version?
<Antiarc> mkristian: How? I didn't see anything documented to that effect
<headius> mpapis: rvm install jruby-9000 or jruby-9.0.0.0 both appear to pull HEAD and build
<Antiarc> mkristian: I'll see if I can produce a full gemfile/jarfile/bootstrap case in a bit, but the net effect is that jruby ends up reflecting on the second copy of joda-time and everything goes sideways
<mpapis> headius, trying now
<mpapis> headius, is 9k released?
<headius> 9.0.0.0.pre1 is out
<mpapis> ah, they need to use full string, when do you plan the full release?
<mkristian> Antiarc, ```jar 'standford-core-nlp', :exclusions => [ 'joda-time:joda-time' ]```
<Antiarc> mkristian: Awesome, thanks. Is that documented somewhere, and if not, can I recommend that it be done? :)
<Antiarc> I still think that some kind of warning-on-conflict mechanism would be useful, because the error jruby gives is non-intuitive, and other folks will get stuck on it
<mkristian> Antiarc, not sure it this is documented, but I know it is tested and just fixed a bug here last week
<enebo> mpapis: The final release date is not known yet
<mkristian> Antiarc, jbundler can check on dependencies coming from jruby itself - to some extend
robbyoconnor has quit [Ping timeout: 245 seconds]
<mkristian> Antiarc, more difficult is the xerces which comes from parent app-server container or so
<headius> mpapis: but you have aliases for jruby-1.7 that install latest release
<Antiarc> mkristian: I'm running into another issue where boilerpipe depends on xerces:xercesImpl, which conflicts with the shipped stuff
<Antiarc> yeah
<headius> can we make 9000 or 9 or whatever do that?
<headius> I just hate to ask people to add pre1 to travis and have to change it again later
<Antiarc> something as simple as during jbundle install, "Warning: foo:bar (a dependency of baz:bin) conflicts with Jruby's bundled foo:bar. Here's how to exclude it from your Jarfile"
<mje113__> headius: does this line make any sense to you?: Users.mike.$_dot_rvm.gems.jruby_minus_head.gems.rack_minus_test_minus_0_dot_6_dot_3.lib.rack.test.__script__()
<mkristian> Antiarc, yes during jbundle install and the jruby dependencies. xerces is more difficult.
nirvdrum has joined #jruby
anaeem1 has quit [Remote host closed the connection]
anaeem1 has joined #jruby
anaeem1__ has joined #jruby
anaeem1 has quit [Read error: Connection reset by peer]
<mpapis> headius, I will check what I can do, for sure 9... can be mapped to jruby-9.0.0.0.pre1 - but then travis might need redeploy for full release
<mpapis> enebo, ^
e_dub has quit [Quit: e_dub]
<headius> mpapis: yeah probably
<headius> no worries
<headius> jruby-head is ok for folks to use right now
<mpapis> ok then, will add 9k.pre1 in few and push release soon
<enebo> mpapis: thanks buddy!
<mpapis> :)
anaeem1_ has joined #jruby
anaeem1__ has quit [Read error: Connection reset by peer]
kl__ has quit [Ping timeout: 252 seconds]
<lumeet> in test/mri/excludes there seems to be a bunch of excluded tests that no longer fail as far as I can tell. I think I could do some cleanup in case it's considered worth it.
josh-k has quit [Remote host closed the connection]
<enebo> lumeet: yeah PRs would be great
<lumeet> enebo: ok, you can expect me to submit one this week.
<enebo> lumeet: great. I did notice some that were working yesterday but did not try and figure out the working ones because we were releasing
gregorsc5 has joined #jruby
jeff__ has joined #jruby
<mkristian> headius, was pounding on these classloader issues. the Xerces/SAXParser seems to be common with other frameworks. when all jars are loaded via jbundler and jar-dependenices then such "exclusions" are possible.
<mkristian> what about to reversing the classloader hierarchy on demand ? and keeping the old behaviour
<mkristian> on demand I mean via property/option
triple_b_ has joined #jruby
anaeem1__ has joined #jruby
anaeem1_ has quit [Read error: Connection reset by peer]
triple_b has quit [Ping timeout: 276 seconds]
anaeem1 has joined #jruby
anaeem1__ has quit [Ping timeout: 264 seconds]
mkristian has quit [Ping timeout: 245 seconds]
JRubyGithub has joined #jruby
<JRubyGithub> [jruby] Who828 opened pull request #2492: Implemented support for keyword and keywordrest proc /lambda parameters (master...2489_fix) http://git.io/elhnIg
JRubyGithub has left #jruby [#jruby]
<headius> oops lost mkristian
rsim has joined #jruby
gregorsc5 has quit [Quit: Leaving.]
gregorsc5 has joined #jruby
<asarih> headius: Should be jruby-9.0.0.0.pre1 for on-demand installation. I haven't tested it.
<headius> asarih: ok, figured
<headius> a few folks have used that already and it works
<asarih> Might make sense to have some alias, say jruby-9000 to point to the latest version.
<asarih> That will require new build env.
<headius> asarih: yeah mpapis is on it I think
<headius> mpapis: looks like jruby-9 does master HEAD right now...so I may recommend that to people as the alias to use
<headius> when we get all the bits out there to alias it to 9k latest release it will just work
<headius> mpapis: oh nevermind, it tries to use that as a branch name
<headius> er, well, git refid nae
<headius> name
JRubyGithub has joined #jruby
<JRubyGithub> [jruby] headius pushed 4 new commits to master: http://git.io/wL1tGw
<JRubyGithub> jruby/master c4a55ac Charles Oliver Nutter: Improvements to sleep and executeTask....
<JRubyGithub> jruby/master b1731ad Charles Oliver Nutter: Eliminate dependency between to_s/to_s19 and prefer the former....
<JRubyGithub> jruby/master 1c09a50 Charles Oliver Nutter: Share field-based literal caching logic and cache Float and Fixnum
JRubyGithub has left #jruby [#jruby]
<headius> mje113__: ^^ that push has more literal caching
triple_b_ has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<headius> regexp in particular
<mje113__> headius: thanks! I'll check it out.
triple_b has joined #jruby
elux has joined #jruby
Who has joined #jruby
<mje113__> headius: anything jump out for accessing a constant on self like here (with invokedynamic on)? https://github.com/jruby/jruby/blob/master/lib/ruby/stdlib/uri/generic.rb#L30
<mje113__> I think my 55s benchmark is spending 25s calling that method
skade has quit [Quit: Computer has gone to sleep.]
mkristian has joined #jruby
dhinojosa has joined #jruby
nirvdrum has quit [Ping timeout: 245 seconds]
<jeff__> question for the devs: is the 1.7.x line of development dead, now that jruby-9k is getting ready to ship?
JRubyGithub has joined #jruby
<JRubyGithub> [jruby] headius closed pull request #2492: Implemented support for keyword and keywordrest proc /lambda parameters (master...2489_fix) http://git.io/elhnIg
JRubyGithub has left #jruby [#jruby]
<mje113__> and... changing self::DEFAULT_PORT to just DEFAULT_PORT removes that bottleneck
<mje113__> I'll try to isolate that in a simple bench and open an issue
<Antiarc> jeff__: I can't speak authoritatively, but my observation has been that 1.7 still gets relevant bugfixes and security patches, though that may change once 9k is officially gold
<Antiarc> Most of the forward effort is on 9k though
JRubyGithub has joined #jruby
<JRubyGithub> [jruby] eregon pushed 2 new commits to master: http://git.io/tPU6yA
<JRubyGithub> jruby/master f5544c3 Benoit Daloze: [Truffle] Fix copyright years.
<JRubyGithub> jruby/master ac0d512 Benoit Daloze: [Truffle] Generalize a bit truffle paths.
JRubyGithub has left #jruby [#jruby]
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
erikhatcher has quit [Quit: erikhatcher]
<jeff__> Antiarc: thanks. I'm specifically hoping that there will be a 1.7x release that includes jruby-openssl 0.9.6
anaeem___ has joined #jruby
<jeff__> I wonder what would happen if I just take the latest 1_7 branch and update the pom.xml and pom.rb and build. I may try that.
anaeem1 has quit [Ping timeout: 252 seconds]
kwando has joined #jruby
<mkristian> jeff__, that will work. but do a mvn clean package after this
baroquebobcat has quit [Quit: baroquebobcat]
baroquebobcat has joined #jruby
cultureulterio-1 has joined #jruby
Who has quit [Quit: Who]
skade has joined #jruby
cultureulterior1 has quit [Ping timeout: 240 seconds]
bbrowning is now known as bbrowning_away
djellemah has quit [Ping timeout: 244 seconds]
<jeff__> mkristian: ok, thanks for the tip :)
iamjarvo has joined #jruby
e_dub has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub> [jruby] enebo pushed 1 new commit to master: http://git.io/DDAK5w
<JRubyGithub> jruby/master 0a27740 Thomas E. Enebo: Remove unused field
JRubyGithub has left #jruby [#jruby]
erikhatcher has joined #jruby
yfeldblum has joined #jruby
<mpapis> headius, enebo, asarih: rvm get head && rvm install jruby9k
JRubyGithub has joined #jruby
<JRubyGithub> [jruby] mje113 opened issue #2493: Performance issue with invokedynamic + Rack + URI http://git.io/s4iwmA
JRubyGithub has left #jruby [#jruby]
<enebo> suweet
<mje113__> headius: ^^^ that's what I've been able to figure out so far!
metadave_ has joined #jruby
<Antiarc> what the hell is URI::Generic.default_port doing?
<mje113__> that's what I haven't been able to find out
<mje113__> the method just returns
<mje113__> self::DEFAULT_PORT
<mje113__> and changing it to return DEFAULT_PORT seems to fix that... guess I should have mentioned that in the issue
anaeem___ has quit [Remote host closed the connection]
<Antiarc> URI::Generic#initialize is pretty slow in your non-invokedynamic version too
<Antiarc> is that on 9k?
metadave has quit [Ping timeout: 265 seconds]
<mje113__> URI in general is kinda a mess
<mje113__> yeah
<mje113__> btw, I can't replicate this outside of Rack
drbobbeaty has quit [Read error: Connection reset by peer]
drbobbeaty has joined #jruby
<rtyler> enebo: finally see 9kp1 in maven central
* rtyler cheers
<Antiarc> https://www.dropbox.com/s/kiv4v539s5bc4gl/racksnap.nps?dl=0 is what I get from jvisualvm running that in a loop
kares has quit [Ping timeout: 252 seconds]
<Antiarc> So yeah, definitely something with regexps being slow
multibot_ has quit [Read error: Connection reset by peer]
multibot_ has joined #jruby
drbobbeaty has quit [Read error: Connection reset by peer]
<Antiarc> Interesting that CachingCallSite.getClass() is eating so much time though
drbobbeaty has joined #jruby
<enebo> Antiarc: whoops
<enebo> Antiarc: In a comment I made a week or two I removed some weird cast and I just realize that it was intentionally there to work around hotspot not opting getClass
calavera has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<Antiarc> Hah
<enebo> Antiarc: I know you can build our source so let me commit that back in and see if it fixes the issue
<Antiarc> If you'll point me at the commit I can revert it and re-test
<Antiarc> Yup
temporalfox has quit [Quit: Textual IRC Client: www.textualapp.com]
<Antiarc> Looks like it should be return ((RubyBasicObject)self).getMetaClass();
<enebo> Antiarc: IDE’s highlight stuff like this :)
<enebo> I nuked it as I was nuking some dead code
<Antiarc> hehe, yeah
<enebo> Antiarc: this code is extra special too since getClass was a non-static method at one point too :)
JRubyGithub has joined #jruby
<JRubyGithub> [jruby] enebo pushed 1 new commit to master: http://git.io/eXQ_Pg
<JRubyGithub> jruby/master cbd3d7b Thomas E. Enebo: Re-add a 'special' cast
JRubyGithub has left #jruby [#jruby]
<Antiarc> building now
<enebo> It probably would be worth inlining that in place of getClass everywhere since it does not use inheritance anymore anyways but I guess then the IDE would report like 12 unneeded casts :)
<Antiarc> Sampling profile is at least a lot different now
<Antiarc> org.jruby.RubyModule.searchWithCache() is top of the stack now
<Antiarc> Now org.jruby.RubyModule.fetchConstant()
<Antiarc> mje113__: Try with that latest commit if you can, I'm curious what that'll do for you
<Antiarc> Probably fixes the invokedynamic issue too
camlow325 has quit []
<Antiarc> That didn't substantially change the runtime of 100k iterations for me
camlow325 has joined #jruby
camlow325 has quit [Client Quit]
mitchellhenke has quit [Quit: Computer has gone to sleep.]
camlow325 has joined #jruby
<Antiarc> java.lang.invoke.LambdaForm$MH.1429880200.linkToCallSite() is dominating with invokedynamic on
<Antiarc> which I guess makes sense, heh
mkristian has quit [Ping timeout: 245 seconds]
triple_b has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<mje113__> Antiarc: I will as soon as I have a chance (on a train now)
metadave_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
metadave has joined #jruby
baroquebobcat_ has joined #jruby
baroquebobcat has quit [Ping timeout: 240 seconds]
baroquebobcat_ is now known as baroquebobcat
<Antiarc> So, running with --dev, 33% of the program's runtime is java.lang.Thread.interrupted(). That seems...unusual.
<Antiarc> Which is because RubyRegexp.matcherSearch executes a SearchMatchTask via thread.executeBlockingTask
<Antiarc> Is that expected?
jeff__ has quit [Quit: Page closed]
<chrisseaton> it does kind of make sense - matching is an operation that could take a long time - maybe MRI sees it as almost like running a C extension, so marks the thread as running a blocking operation
<Antiarc> What I'm wondering is if this is an inherent problem in regexp performance which is being masked by the JIT somehow
<Antiarc> since Thread.interrupted is going to be a native call that isn't going to be eligible for jit, but if it's this slow I'd expect that issue to show up even with jit on
<chrisseaton> no eligible for JIR?
<chrisseaton> JIT?
<Antiarc> Native implementations are beyond the scope of JIT, aren't they?
<Antiarc> (Perhaps my assumptions are simply wrong)
<chrisseaton> no they're usually better for JIT because they can be replaced with a snippet of code without a call boundary
<Antiarc> I am still quite the newb WRT JVM internals :)
<Antiarc> Ahhh. Okay.
<chrisseaton> the JIT knows what they do, so it's not a black box and all the JIT logic can take into account what it actually does
<Antiarc> That makes sense.
erikhatcher has quit [Quit: erikhatcher]
<Antiarc> http://i.imgur.com/L1SDf4K.png - 31x the time spent checking interrupted() than in actually running the task
<Antiarc> Not a problem if it's a dev-only issue, but yowza.
<chrisseaton> Antiarc: I went looking for MRI making match a blocking operation but it doesn't seem to do so
<Antiarc> chrisseaton: I think it's because of joni's implementation
Specialist has quit [Ping timeout: 265 seconds]
<Antiarc> Joni's Matcher has a matchInterruptible throws InterruptedException which RubyRegexp uses
<Antiarc> Oh, I think I see why this is done - matcherMatch is a static method, and that gets it executing on the current Ruby thread
<headius> hello again
<headius> Antiarc, chrisseaton: the interruptibility of joni is our addition
<headius> joni does not verify characters as it executes, so bad input can cause infinite loops if a character is messed up
<Antiarc> ahh
<headius> we tried to reduce the overhead of checking interrupted, but we know it still adds a bit
<headius> I believe jordansissel did the patch for us...they needed it for something in logstsh
<Antiarc> It's basically the entire call time there
<Antiarc> That's without --dev
havenwood has quit [Remote host closed the connection]
<Antiarc> I kiiiiinda suspect that's responsible for a lot of the performance problem with regexp
<headius> I don't see any regexp stuff in that trace
<headius> we also do this polling to check for Ruby thread interrupts
<Antiarc> It's in there, it's just being hidden. I'll show you the same code path with --dev
<headius> ok
<Antiarc> Basically, that's URI::Generic accepting query=, fragment=, etc. It performs gsub! on them with a regexp, which fires off that matcherSearch which invokes executeBlockingTask when spends most of its time checking for interrupts
<Antiarc> https://gist.github.com/mje113/988f065369dd5693dffb is the script being run here
<Antiarc> I just replaced the 100k with an infinite loop for profiling purposes
bbrowning_away is now known as bbrowning
<Antiarc> The entire sampled portion of that gsub_bang19 call was in Thread.interrupted()
<headius> chrisseaton: I'm going to merge in mkristian's change to move truffle stuff to a separate module
<headius> Antiarc: ahh, this is different than the joni interrupt I was talking about
camlow32_ has joined #jruby
<headius> this is done on every entry into and exit from a blocking operation to check for cross-thread events
<headius> so yeah I guess it's relate
<headius> because we wnt to be able to interrupt joni and so it needs to go in a blocking task
<headius> this isn't a change from 1.7
<Antiarc> http://i.imgur.com/GLC6oBQ.png - same thing after it's run for a bit. 7300ms checking interrupted(), 403ms actually spent running the task
<Antiarc> Okay
<headius> the executeTask stuff is a little different but not much
<headius> it certainly could still be excess overhead, but no more than in 1.7 I think :-)
<headius> you may be getting odd profiles here too because I believe the interrupt check has some native code in JVM
<Antiarc> I just ran down this bunny trail when looking at mje113__'s benchmark. No idea if it's useful or not, but it smells hot
<Antiarc> Yeah, it's a native implementation
camlow325 has quit [Ping timeout: 252 seconds]
<headius> did you do this against current head? I fixed logic where it was re-compiling and re-constructing literal regexp every time
<headius> that was probably the lion's share of his perf
<Antiarc> yes, this is running on current head, after your change
<headius> ok
<headius> I'll give it a try here too
mister_solo has joined #jruby
zorak8 has joined #jruby
<mje113__> headius, Antiarc thanks for looking into this, I'm unfortunately not going to have access to a computer for a while
<headius> jeff__: we plan to support 1.7 for another year
<headius> that may be reduced if 9k is just super awesome out of the gate
<headius> mje113__: no problem...the self::CONSTANT case will be an interesting one to look at
<mje113__> Yeah, equally interesting why this happens within rack only, maybe rack just adds a lot of calls itself
tcrawley is now known as tcrawley-away
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bbrowning is now known as bbrowning_away
<headius> yeah I'm not sure
<Antiarc> ByteCodeMachine.matchAt() also shows up as a hotspot, and it also checks Thread.interrupted()
<headius> Antiarc: yah that's the joni interrupt
<Antiarc> yup
<Antiarc> that could probably be alleviated by only checking the interrupt every X cycles rather than every cycle, no?
<Antiarc> Though it doesn't fix the upstream issue
<headius> I think we may actually do that
<headius> I don't remember
<Antiarc> Nope, it's every loop
<headius> hmmm ok
<headius> we talked about it, but I guess we never did it
<headius> so that could be improved
mister_solo has quit [Ping timeout: 245 seconds]
<Antiarc> Oh you know what, hm
viking has quit [Remote host closed the connection]
<Antiarc> joni-2.1.1 had a check every INTERRUPT_CHECK_EVERY cycles
<Antiarc> head has it every cycle
<headius> hmmm, maybe we removed it for a reason
<headius> I don't remember...enebo and jordansissel iterated on this
Specialist has joined #jruby
<projectodd-ci> Project jruby-master-test-jruby build #424: ABORTED in 8 hr 0 min: https://projectodd.ci.cloudbees.com/job/jruby-master-test-jruby/424/
<headius> chrisseaton: so there's a small issue merging this right now
<chrisseaton> headius: yeah?
Aethenelle has quit [Quit: Aethenelle]
<headius> test suites run fine with the split module, but since it doesn't go in jruby.jar it isn't available at jruby command line without additional flags
<headius> we can merge it and fix it on master or I can push back to branch and work with mkristian to improve that first
codefinger has joined #jruby
<chrisseaton> headius: so the launcher would see the -X+T and add the Truffle jar to the classpath?
<headius> that or we shade it into lib/jruby/jar
<headius> the split module was to break it out of e.g. complete jar, and it does that much ok
<chrisseaton> our of the complete jar? do you mean the core jar?
<headius> core, yeah sorry
<codefinger> jruby 9k.pre1 is ready to go on Heroku https://twitter.com/codefinger/status/558034989288525826
<headius> codefinger: excellent!
<chrisseaton> i'm a bit lost with all these jars and shadings - not sure how to help really
<headius> chrisseaton: I just need to know how inconvenient it would be to have -X+T broken for a day or so on master
<headius> I'd like to get rid of the branch and PR
<projectodd-ci> Project jruby-master-test-slow_suites build #411: ABORTED in 8 hr 0 min: https://projectodd.ci.cloudbees.com/job/jruby-master-test-slow_suites/411/
drbobbeaty has quit [Read error: Connection reset by peer]
drbobbeaty_ has joined #jruby
<projectodd-ci> Project jruby-master-spec-compiler build #413: ABORTED in 8 hr 0 min: https://projectodd.ci.cloudbees.com/job/jruby-master-spec-compiler/413/
<chrisseaton> headius: yeah go ahead - I guess we can work around
<chrisseaton> headius: maybe we can use JRUBY_OPTS to manually add truffle to the classpath
<chrisseaton> I'll see how it's all working after you've merged anyway
mrmargolis has quit [Remote host closed the connection]
<enebo> chrisseaton: jruby-launcher can add things too if it cannot be done once Java is bootstrapped
<headius> chrisseaton: VERIFY_JRUBY=1 jruby -J-cp truffle/target/jruby-truffle-9.0.0.0.pre1.jar -X+T -e 1
<headius> that's how I got it to run
<headius> verify keeps jruby out of bootclasspath
<chrisseaton> why does that make a difference?
enebo has quit [Quit: enebo]
camlow32_ has quit [Remote host closed the connection]
zorak8 has quit [Read error: Connection reset by peer]
zorak8 has joined #jruby
camlow325 has joined #jruby
<tarcieri> does JRuby 9.0.0.0.pre1 cache the IR yet when it (re)loads an unchanged file?
elia has joined #jruby
gregorsc5 has quit [Quit: Leaving.]
<chrisseaton> tarcieri: I don't think it does
<tarcieri> mmmkay
camlow325 has quit [Remote host closed the connection]
slyphon has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Specialist has quit [Remote host closed the connection]
<headius> tarcieri: we have that logic partially implemented but it's unfinished
elux has quit [Quit: Bye!]
<headius> chrisseaton: truffle stuff is loaded reflectively without any classloader tricks, so if JRuby proper is in boot, truffle needs to be in boot
<headius> launcher puts jruby.jar in boot, so doing -X+T classpath juggling in launcher seems appropriate
<chrisseaton> why do you use the bootclasspath for JRuby?
<headius> avoid JVM verification costs on boot
<headius> it's substantial for the amount of bytecode we load
<chrisseaton> is jruby.jar actually jruby-core.jar then?
<headius> I don't rememeber which artifacts shade what, but mostly yes
<headius> it's a separate build step to shade jruby core jar + runtime deps into lib/jruby.jar
<headius> so if we went the shading route for truffle, that's where it would happen
<headius> chrisseaton: tell ya what...I'll just push this back to the PR branch for now
camlow325 has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub> [jruby] headius pushed 2 new commits to test-truffle-modular: http://git.io/BjavbQ
<JRubyGithub> jruby/test-truffle-modular 3251c4c Charles Oliver Nutter: Merge remote-tracking branch 'origin/test-truffle-modular'...
<JRubyGithub> jruby/test-truffle-modular 72c824d Charles Oliver Nutter: Additional tweaks to separate truffle into a separate module....
JRubyGithub has left #jruby [#jruby]
<headius> codefinger: retweeted!
camlow325 has quit [Remote host closed the connection]
ryez has joined #jruby
camlow325 has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub> [jruby] philr opened issue #2494: Open3 fails with varying signals on 9.0.0.0.pre1 http://git.io/792KDA
JRubyGithub has left #jruby [#jruby]
JRubyGithub has joined #jruby
<JRubyGithub> [jruby] headius force-pushed test-truffle-modular from 72c824d to 0dc42dc: http://git.io/urmdAg
<JRubyGithub> jruby/test-truffle-modular f53957c Christian Meier: factored out the truffle part into its own maven module...
<JRubyGithub> jruby/test-truffle-modular 0dc42dc Charles Oliver Nutter: Additional tweaks to separate truffle into a separate module....
JRubyGithub has left #jruby [#jruby]
<headius> better
<chrisseaton> headius: this all looks fine - I'd help more if I could get my head around it but let me know if you need anything
<chrisseaton> headius: if you can get bin/jruby -X+T to work then great, let's do it like this
<chrisseaton> headius: it looks like core still depends on truffle though? in core/pom.rb
slyphon has joined #jruby
skade has quit [Quit: Computer has gone to sleep.]
elia has quit [Quit: Computer has gone to sleep.]
erikhatcher has joined #jruby
<headius> oh forgot to fix pom.r
JRubyGithub has joined #jruby
<JRubyGithub> [jruby] headius pushed 1 new commit to test-truffle-modular: http://git.io/Ovz4bQ
<JRubyGithub> jruby/test-truffle-modular 514b33a Charles Oliver Nutter: Also remove truffle from core/pom.rb.
JRubyGithub has left #jruby [#jruby]
<headius> chrisseaton: thanks for keeping up with the reddit post
<headius> I was too burned out last night to pay attention
triple_b has joined #jruby