<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]
<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.
<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:
<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%
<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
<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
<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
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 ?
<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?
<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…]
<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]
<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
<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>
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
<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