<mrbrdo>
this seems to only happen with jruby, at least for me, and I don’t really have any clue why it does, but it’s not random, I can always reproduce it on this computer. however I know that some time ago, it worked fine
<headius>
mrbrdo: I am
<mrbrdo>
basically it just keeps outputting the same thing over and over, while it should actually output different things.. however the arrows in that output are colored, it might have something to do with it
<headius>
mrbrdo: first of all... 1.7.6?
<mrbrdo>
cool! and a happy new year in advance :)
<headius>
this looks like a case of a string's shared backing store getting modified
<mrbrdo>
yeah I got stuck on that version because I had some issues up to 1.7.11, then I didn’t take time to try anymore
<headius>
what is that "Creating a" logging?
<mrbrdo>
it’s probably fine now, I will have to upgrade soon
<mrbrdo>
this is an example from MRI of some of the output
<headius>
chrisseaton_: optimization_barrier was an interesting idea...in your last comment, I guess you meant that even if optimization_barrier doesn't optimize, the compilers will still see constant-enough value to optimize a loop away?
<pazustep>
Hello, guys. Has anyone heard about trouble running jruby-1.7.18 on a DigitalOcean Ubuntu VPS?
<pazustep>
I'm having this really weird problem where `bundle install` freezes… I'm not sure what happened but it eventually worked; now `rails s -b 0.0.0` never binds the listening socket (it seems to work at first, but I can't connect to the server and `netstat -l` doesn't show the listening socket)
baroquebobcat has quit [Quit: baroquebobcat]
zorak_ has quit [Ping timeout: 245 seconds]
baroquebobcat has joined #jruby
calavera has joined #jruby
skade has quit [Quit: Computer has gone to sleep.]
rjnienaber has quit [Quit: Page closed]
calavera has quit [Client Quit]
triple_b has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
calavera has joined #jruby
capitalfellow has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<pazustep>
that's on Ubuntu 14.04 and OpenJDK 1.7.0_65
<chrisseaton_>
headius: yeah, we have a value profile that looks at arguments, and if it only ever sees one value it will turn it into a constant with a single guard at the entry point of the compiled code
towski has joined #jruby
triple_b has joined #jruby
mattwildig has quit [Remote host closed the connection]
<headius>
_ko10: around?
chrisseaton_ is now known as chrisseaton
tlarevo has joined #jruby
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
towski has quit [Ping timeout: 272 seconds]
towski has joined #jruby
mattwildig has joined #jruby
yfeldblum has joined #jruby
rjnienaber has joined #jruby
yfeldblum has quit [Ping timeout: 244 seconds]
<rjnienaber>
00:05 <headius> oh, missed him
<rjnienaber>
headius: were you talking about me ?
e_dub has joined #jruby
<headius>
no, I was just going to thank you :-)
<rjnienaber>
okay, cool np :)
<headius>
and reply about closing the JIRA issues...I'll handle it
e_dub has quit [Read error: Connection reset by peer]
e_dub has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] nirvdrum pushed 1 new commit to master: http://git.io/V0u68A
<JRubyGithub>
jruby/master fb9199f Kevin Menard: [Truffle] Fixed directory globbing on Windows.
JRubyGithub has left #jruby [#jruby]
<nirvdrum>
headius: FYI, stdio is busted on Windows.
<headius>
yay!
towski has quit [Remote host closed the connection]
<headius>
probably just needs to not use native IO
<nirvdrum>
Oddly, it works in Truffle, so it's probably some weird bootstrapping issue.
<headius>
yeah I assume you have a different IO
<headius>
or not?
<headius>
I don't know what we share and what we don't right now
iamjarvo has joined #jruby
<nirvdrum>
I have no idea. I just have been pecking away at making things work in Windows.
<headius>
that's excellent
<headius>
I'm going to hop on VPN and see if Red Hat IT has seen fit to give me my Windows licenses
<chrisseaton>
what exactly is stdio? Do you just mean puts and things? We send that to the stdout stream that JRuby uses - so not a JRuby File object, but the same underlying stream
<headius>
chrisseaton: do you disable native or anything like that?
<nirvdrum>
Yeah. Just stdout, stderr, stdin.
<headius>
I think it may unconditionally use native IO for stdio when native is enabled
<headius>
checking tha tnow
subbu|afk is now known as subbu
<chrisseaton>
headius: the stream we get is a OutputStream I think
<chrisseaton>
no idea what backs it
<headius>
you might be getting JDK's stdio
<nirvdrum>
headius: Things do work when I disable native.
<subbu>
nirvdrum, you mean the "BUG: Got exception org.jruby.exceptions.RaiseException: (TypeError) `to_a' did not return Array but instr return(*<x(0:0)>) is not supposed to be raising exceptions!"
<subbu>
I've known about those for a while and ignored them, but I should get around to it one of these days soon.
<headius>
array coercion certainly can throw errors
yfeldblum has joined #jruby
<subbu>
ya, there are some scenarios i've to distinguish internally ... i've forgotten the details ... but wil come back when I look at that code.
mattwildig has quit [Remote host closed the connection]
<nirvdrum>
subbu: That's the one.
<nirvdrum>
If you know about it, great. It just seemed to be a spurious failure.
yfeldblum has quit [Ping timeout: 240 seconds]
iamjarvo has joined #jruby
<headius>
IT asked me how many licenses...so perhaps I'll have some Windows copies in the next week
<nirvdrum>
Great.
<nirvdrum>
I'll help out where I can, but you guys would know better. As it stands, you wouldn't be able to ship 9k for Windows :-/
mattwildig has joined #jruby
<headius>
yeah, that dog won't hunt
<headius>
I'll get IO fixed up as soon as I have a license
<headius>
it will probably involve additional tags/excludes for Windows
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<nirvdrum>
Is there a revised release plan for pre1?
<headius>
kinda playing it by ear, but we'll actually pull folks together in here Monday to chat about it
<headius>
it could really be any time if it's largely functional, so mostly we need to decide if it's functional enough
<headius>
a number of folks have tested out nontrivial apps without problems, and others have found minor bugs
<headius>
releasing sucks...it's like giving up
<nirvdrum>
I don't suppose you got anywhere with that C1 crasher?
<headius>
gotta do it though
<headius>
no, unfortunately not...I pinged the right people but holdays and all
<nirvdrum>
Ahh, right.
<headius>
did we open a jruby issue for it, just to track progress?
<headius>
can't remember if we had one
<nirvdrum>
I went into the Burlington office yesterday and that place was dead.
mcclurmc has joined #jruby
<nirvdrum>
I assume CA is similar or worse.
e_dub has quit [Quit: e_dub]
iamjarvo has joined #jruby
iamjarvo has quit [Max SendQ exceeded]
iamjarvo has joined #jruby
diegoviola has quit [Remote host closed the connection]
<headius>
Oracle Burlington?
<headius>
which I believe used to be a Sun facility
<headius>
I never got out there
<headius>
Santa Clara campus is pretty active still though
<headius>
that's where labs is based
<headius>
Menlo Park was cool...now it's stupid Facebook
<chrisseaton>
Labs HQ is Redwood Shores now - but I think there might be a couple of people in Santa Clara
<headius>
Mario must be there
<headius>
I suppose anyone left from Sun Labs is potentially in SC
<headius>
Redwood Shores is too damn far from everything
<headius>
except the airport
<chrisseaton>
Mario and everyone I know are at Redwood Shores
<chrisseaton>
I think they moved a lot of the hardware people into SC
<chrisseaton>
as in non-labs hardware people - networking gear and things
capitalf_ has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
tlarevo has quit [Ping timeout: 240 seconds]
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<JRubyGithub>
[jruby] headius opened issue #2400: File.join generates corrupted Windows-31J String on Windows http://git.io/gYXJ3A
JRubyGithub has left #jruby [#jruby]
<headius>
chrisseaton: ahh ok
<Antiarc>
out of curiosity, how much tuning has been done on the lexer code? I'm still poking at improving startup time, and am mostly wondering how much this path has been tread before it
<Antiarc>
before me*
<headius>
chrisseaton: probably not long before JVMLS moves there too
iamjarvo has joined #jruby
<headius>
maybe not...the SC facility is pretty nice
<Antiarc>
I'm not seeing any particular inefficiencies, but an awful lot of startup time is spent in lexing code, I'm just wondering if there might be shortcuts that could be taken there
<headius>
Antiarc: enebo has done a lot of tweaking and has more to come
capitalfellow has joined #jruby
<headius>
you definitely want to sync up with him first
<Antiarc>
Also, is there any reason the .rb files bundled in jruby.jar aren't precompiled to class files?
<Antiarc>
Okay, cool
<Antiarc>
For the stuff that gets shipped in the jar, it seems like it'd make sense to just go ahead and precompile them, so there isn't the whole lex-and-parse step on every bootup
<headius>
precompiling to class files in 1.7 and lower actually hurts perf because the JVM has to verify all that bytecode, plus it still has to be loaded, parsed, linked, etc
<Antiarc>
Ooh. Okay.
<headius>
it might be better in 9k
<headius>
no AOT yet in 9k
<nirvdrum>
headius: Yeah, the old Sun campus out in Burlington.
<nirvdrum>
I head in one day a week usually. I don't actually work with anyone out of that office, but it's good to see other humans.
<nirvdrum>
There are a few labs groups out of there.
pazustep has quit [Remote host closed the connection]
<headius>
cool
calavera has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
yfeldblum has joined #jruby
<nirvdrum>
Antiarc: Load service and jruby-openssl are probably still the largest contributors to start-up time.
<nirvdrum>
Load service should be fairly straightforward, if not annoying.
<Antiarc>
Hm, okay, neither of those showed up in my profiling
<Antiarc>
But I'll take a look at 'em
<nirvdrum>
Were you profiling a real app?
<nirvdrum>
Or just a base start-up time?
<headius>
profiling startup is really hard
<headius>
I know one of the biggest things for base boot time is all the Java class proxy generation
<Antiarc>
Just base startup time, -e "require 'active_support/all'"
<headius>
there's a ton of reflective class-walking and method gathering
<headius>
more than there needs to be but it's a complicated algorithm
<headius>
for app startup, the big items are still AST parsing and IR compilation
<Antiarc>
startup time is still the single largest pain point I have, so if I can at all help improve that, I'll be quite happy :)
<nirvdrum>
We cut out 2/4 of the suffixes, so the total number of filesystem requests dropped substantially. But requiring a file is still O(n), where n = $LOAD_PATH.size
yfeldblum has quit [Ping timeout: 240 seconds]
<nirvdrum>
In my Rails app, there were ~125 load path entries and ~27K required files.
<Antiarc>
Yeah, I've played around with various solutions to that on MRI for years, but it's just hairy
<Antiarc>
Ruby's require semantics are just not conducive to faster-than-linear operations there
<nirvdrum>
And you end up in a weird situation where the first time a file from a gem is required, the gem is appended to the end of the LOAD_PATH, but you almost certainly are requiring more than one file from that gem and each of those requires ends up walking the full list.
<nirvdrum>
So it's truly worst-case O(n).
<Antiarc>
I've toyed with walking the load paths and preloading the whole thing into RAM to be invalidated when the load path changes, which produced some speedup, but it broke things in ways that I didn't understand at the time
<nirvdrum>
I had it pretty much constant time by caching directory entries as they were visited and doing a cache lookup with fallback when a file was required. A filesystem watcher selectively invalidated the cache.
mcclurmc has quit [Remote host closed the connection]
<nirvdrum>
But this was before dfr|work refactored the whole thing, so it went stale.
<Antiarc>
It seems like the kind of case that should be able to be accomplished in log time if you have the file list in memory, since you could just walk a tree to find the file(s) you're interested in, then test those
tlarevo has joined #jruby
<nirvdrum>
The other problem I never got around to addressing is the FS watcher API is 7+ and wouldn't load on Android. Also, MacOS X doesn't have a native FS watcher implementation, so it'd have to be polled.
<nirvdrum>
That aside, I think it demonstrates that something can be done in this area.
<nirvdrum>
On the jruby-openssl front, I think lazily instantiating things would help markedly. But that was something I was less comfortable changing.
<chrisseaton>
655 open bugs - wow
<chrisseaton>
I wonder if we can triage this a bit more
<nirvdrum>
Requiring 'openssl' takes > 700ms.
<chrisseaton>
perhaps we need a 'confirmed' tag
<nirvdrum>
Even if you never use anything from it.
<Antiarc>
tbh, the linear growth of require times is probably a bigger concern; jruby being 900ms to boot up vs 50ms from MRI or whatever is less of a concern to me than rake taking 9 seconds to boot and load the app before it starts doing anything.
<nirvdrum>
Yeah, both suck.
SunnyDMess has joined #jruby
tlarevo has quit [Ping timeout: 272 seconds]
<nirvdrum>
The openssl issue was almost entirely the performance difference in "bundle exec" vs using binstubs.
<Antiarc>
interesting,.
<nirvdrum>
But I got bundler to lazy require a while ago.
<nirvdrum>
But, if anything else along the way requires openssl, you'll hit the same wall.
<nirvdrum>
According to the issue I filed, I was seeing 3s to require openssl on a VM.
triple_b has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
tlarevo has joined #jruby
<chrisseaton>
I guess I'll have to host my Ruby bibliography somewhere else - Brian asked me to move it to rubyspec.org for the benefit of the community, and now it's gone with everything else
calavera has joined #jruby
triple_b has joined #jruby
triple_b has quit [Ping timeout: 250 seconds]
tlarevo has quit [Ping timeout: 256 seconds]
<brixen>
chrisseaton: it's archived
<brixen>
chrisseaton: hopefully you'll find a better place for it
<chrisseaton>
I've bought rubybib.org - I'll set up a GH org and put a site up soon
<brixen>
sounds good
<brixen>
hopefully more academics will take an interest
<brixen>
github pages sure makes it easy to put stuff up
<brixen>
which is awesome
<headius>
Antiarc: as you work, make sure you're testing with --dev as well so we can see best-case
<Antiarc>
Noted, will do
<headius>
nirvdrum: thank goodness it's all OSS, eh?
<Antiarc>
Right now I'm mostly just combing through looking for algorithmic inefficiencies, once I've completed my survey I'll start with the microoptimizations :)
<headius>
Antiarc: excellent
<headius>
if you can figure out any other good tools for profiling startup, that would always be welcome
<Antiarc>
I'm just using hprof cpu=times right now
<headius>
it's very difficult to get a clear picture without the profiling itself getting in the way
<Antiarc>
Which is slow as hell but gives very complete results :)
<headius>
yeah, it does
<headius>
tracking allocations can help too...look for exceptions being thrown or massive amounts of other objects
yfeldblum has joined #jruby
<Antiarc>
ah, good idea
<nirvdrum>
headius: Did you take care of the CDFNE at startup?
<headius>
yeah that's in
<headius>
you mean the ones from *Service loading?
<nirvdrum>
Yeap.
yfeldblum has quit [Ping timeout: 250 seconds]
<headius>
yeah, that actually got into 1.7.18 as well, to work around a RubyGems bug
<nirvdrum>
Interesting. I guess I missed that.
<headius>
we ended up backtracking on the RG update but the fix stayed
capitalfellow has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
capitalfellow has joined #jruby
mattwildig has quit []
<Antiarc>
I've more or less entirely avoided the rubyspec politicizing, but it's bringing up some interesting reading.
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
atambo has quit [Quit: yarr]
atambo has joined #jruby
mattwildig has joined #jruby
mbj has quit [Ping timeout: 240 seconds]
diegoviola has joined #jruby
yfeldblum has quit [Ping timeout: 265 seconds]
<headius>
hmm
<Antiarc>
I had Joda 2.1 being loaded due to a bad pom in a gem ext. Fixed that, but I'm not sure why it just started breaking.
<Antiarc>
Maybe some change in load orders?
<headius>
looks ok
<headius>
I mean the signatures should have matched
<Antiarc>
Right
<headius>
signature selection is sometimes non-deterministic but it didn't find *anything*
<headius>
if it was a version mismatch it could be classloader sequence etc
<headius>
like running in maven might have classpath ordered differently
<headius>
you got that running something locally?
<Antiarc>
I've got it all sorted for now, but that feels like a timebomb waiting to happen
<Antiarc>
Yeah
<Antiarc>
I have a gem which had caliper in its ext pom, which depends on joda-time-2.1
<Antiarc>
So joda-time 2.1 was being loaded, which caused that problem
<Antiarc>
Though I still can't repro it in IRB even explicitly loading 2.1
<Antiarc>
Gotta be a load order thing somewhere.
digitalextremist has joined #jruby
digitalextremist has quit [Remote host closed the connection]
yfeldblum has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] cprice404 opened pull request #2402: (MAINT) fix jnr-constants version in pom (jruby-1_7...maint/jruby-1_7/fix-jnr-constants-version-in-pom) http://git.io/3MQsnQ