<JRubyGithub>
[jruby] nirvdrum pushed 1 new commit to truffle-head: http://git.io/v3pfP
JRubyGithub has left #jruby [#jruby]
<JRubyGithub>
jruby/truffle-head 17a5cf8 Kevin Menard: [Truffle] Fixed a typo.
drbobbeaty has quit [Read error: Connection reset by peer]
drbobbeaty has joined #jruby
bbrowning is now known as bbrowning_away
<rtyler>
moinmoin
<nirvdrum>
Howdy.
<rtyler>
I was watching a presentation from goruco last night and I NOTICED THAT THE PROFILING STORY FOR MRI HAS GOTTEN MUCH BETTER
<rtyler>
GAK
<rtyler>
sorry, thinkpad double-tap of shift turns on caps lock
<rtyler>
stackprof and allocationprof both look pretty decent despite their poor UI
AnoHito has quit [Ping timeout: 250 seconds]
<rtyler>
makes me curious about the current state of profiling and monitoring jruby apps
pitr-ch has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
dinfuehr has joined #jruby
dinfuehr has quit [Ping timeout: 244 seconds]
colinsurprenant has joined #jruby
colinsurprenant has quit [Client Quit]
colinsurprenant has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] nirvdrum pushed 1 new commit to truffle-head: http://git.io/v3pZ5
<JRubyGithub>
jruby/truffle-head 6d1ed38 Kevin Menard: [Truffle] Added an option to selectively enable whether core file callers (e.g., Rubinius internal calls) should appear in set_trace_func.
JRubyGithub has left #jruby [#jruby]
<nirvdrum>
rtyler: I think standard JVM tools are still quite helpful. Granted you need to learn how to read them since you have name munging. And you probably should enable reification of class names. But otherwise you get some really good tooling.
<rtyler>
nirvdrum: yeah, the biggest challenge I've had in the past is determining one method call from another when dealing with cpu profiling
<rtyler>
then in the object allocation profiling, RubyString$$ is totally useless :P
lance|afk is now known as lanceball
<nirvdrum>
You can inspect the object. Looking at the byte[] and cross-referencing with your source usually helps narrow down.
<nirvdrum>
I don't know what the new MRI tooling looks like on that front.
<rtyler>
wel, th eproblem isn't just with ruby strings
<rtyler>
ruby objects in general are exceptionally tedius to track down in the jvm-bsaed tooling
<rtyler>
I wish there was omething like sourcemaps for javascript that allowed you to inform the tools of what your code looks like
<rtyler>
chrisseaton: i'll check out that link when I get off the bus
<rtyler>
degraded bandwidth situation here :P
enebo has joined #jruby
dinfuehr has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] chrisseaton pushed 1 new commit to truffle-om-dsl: http://git.io/v3pKE
<JRubyGithub>
jruby/truffle-om-dsl 6b43197 Chris Seaton: [Truffle] Un-share the allocator in OM DLS.
JRubyGithub has left #jruby [#jruby]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] chrisseaton closed pull request #3258: [Truffle] Use the OM more efficiently and create a DSL to help us do that (master...truffle-om-dsl) http://git.io/v3bN3
JRubyGithub has left #jruby [#jruby]
colinsurprenant has quit [Quit: colinsurprenant]
dinfuehr has quit [Ping timeout: 244 seconds]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] nirvdrum pushed 4 new commits to truffle-head: http://git.io/v3pXZ
<JRubyGithub>
jruby/truffle-head cdb43d4 Kevin Menard: [Truffle] Removed unnecessary AST probe check for instrumentation.
<JRubyGithub>
jruby/truffle-head 1389bdf Kevin Menard: [Truffle] Handle :class events for set_trace_func.
<JRubyGithub>
jruby/truffle-head 940632e Kevin Menard: [Truffle] Don't trigger the :call event in set_trace_func when creating a class.
JRubyGithub has left #jruby [#jruby]
bbrowning_away is now known as bbrowning
<chamila>
Hi all, I'm trying to install jruby-9.0.0 using rvm "rvm install jruby-9.0.0", then I what downloaded is "jruby-9.0.0.0.pre1", is this the correct latest release that should be downloaded?
<mberg>
Ah, thanks. I've been wanting to catch up on conference videos, but have had no spare time lately. (Renovating my old house to put on market. Which should happen approximately today.)
dinfuehr has joined #jruby
dinfuehr has quit [Ping timeout: 260 seconds]
donV has joined #jruby
<Antiarc>
headius: what's outstanding on 9.0.1?
<headius>
I was hoping I could get refinements in but not sure if we have time...already a few weeks since 9.0
<headius>
and I have not audited bugs...they've come fast and furious since the release
<Antiarc>
I'll see if I can sneak some time in to do some bugpunching! :D
<headius>
do it!
<headius>
ok, I have to stop watching twitch plays dark souls...hilarious
<headius>
I should look at that...jit issue causing concurrency problems
dinfuehr has joined #jruby
<enebo>
hmmm weird
<headius>
I think I know the problem...1.7 JIT treates "while true" as loop forever and probably does it wrong
<headius>
rather than re-evaluating condition every time
<enebo>
oh
<enebo>
for the conc JIT bug?
<headius>
peephole
<headius>
yeah
<enebo>
ah I see
<headius>
ok...I'm going to look at this and then other 1.7.22 bugs then
<headius>
anything that looks noncritical and puntable I'll punt
<chrisseaton>
What is the issue with treating while true as an infinite loop?
<enebo>
headius: oh actually look at #3189 for 9k soon if possible
<headius>
chrisseaton: possible thread event polling
<enebo>
headius: I think that is one we want confirmation on
<headius>
if it doesn't evaluate true that's one poll missing
<enebo>
headius: and a regression from 1.7 with new IO layer
<headius>
I'm just hand waving
<headius>
enebo: ok
<headius>
yeah
<chrisseaton>
Ah so an empty wile true would never poll?
<headius>
I'll get windows up and see what I can do, after this JIT issue
<headius>
chrisseaton: right
<enebo>
I did return some of the threadpolls in 9k I removed earlier but we do way less than in 1.7
<headius>
1.7 polled like MRI 1.8.7, at particular node types like true
<headius>
1.9 does it on method entry and backedge
<headius>
er 9k
<enebo>
but threadpoll is easier to reason with in IR
<chrisseaton>
We reuse GC safe points for polling
<headius>
9k does too with indy
<headius>
well, inserts safe points here and there with SwitchPoint, but they should get coarsened
<enebo>
assuming we emit the instrs in the right place :)
dinfuehr has quit [Ping timeout: 246 seconds]
<chrisseaton>
headius: I don't think they get coarseness, but using switch point doesn't actually add any more so it's fine
<headius>
I need to look at the asm to see how many safepoints get emitted
<chrisseaton>
Did you read our ICOOLPS paper on safepoints? We learned some stuff ourselves writing that and most of it applies to SwitchPoint as well
<enebo>
headius: #3169 is another fixer for 1.7.x for sure since I think this is another loadservice regression since 1.7.14
baroquebobcat has quit [Quit: baroquebobcat]
<headius>
chrisseaton: I'll have to read through it
<enebo>
not that we didn’t have it working for 7+ releases
<headius>
ok
<headius>
I'm taking these down
baroquebobcat has joined #jruby
baroquebobcat has quit [Client Quit]
baroquebobcat has joined #jruby
yfeldblum has joined #jruby
djbkd has joined #jruby
<nirvdrum>
If my vote counts, I'd just make it 9.0.1.0. If the version numbers aren't supposed to be decimal, then "" and ".0" aren't the same thing *shrug*
<headius>
yeah
<headius>
oracle java is moving to a semantic version in 9 also
<headius>
rather than the confusing update versions they have in 8
<chrisseaton>
semantic versioning doesn't work when people are irrationally scared of changing the major number - that's what holds it back I think
<headius>
for us, the major version will signal long term support of a branch...so that's the main thing that will hold us back
<chrisseaton>
like if you had to tweak your interface a tiny but but breaking it twice in a week then that's two majors - which is fine - but nobody would do that
dfr|work has quit [Ping timeout: 244 seconds]
<nirvdrum>
It doesn't particularly work when the previous versions all become unsupported as well. Or when there's no guarantee of compatibility between N and N+1.
<headius>
we won't bump to 10 until we feel like it's sufficiently different to keep 9 maintained
<chrisseaton>
do you remember the insanity of MRI's stated approach to semantic versioning?
<nirvdrum>
chrisseaton: Chrome & Firefox are the only two I know that do it. But they've tied it to security updates and forced it on everyone. So they just constantly break their respective APIs and say "well, it's okay because we bumped the major version."
<nirvdrum>
I'm happy I no longer have to deal with that inanity.
<chrisseaton>
there's also the question of whether your public API includes semantics - so if you change behaviour to fix a bug, but don't actually change a signature, then should you change the major?
<chrisseaton>
also, what is the major number for in an end-user application with no-api? who knows
<nirvdrum>
I tried to get namespacing to be an official recommendation in the semantic versioning spec, but that was deemed to be too implementation-specific somehow.
<nirvdrum>
The world would have been much better off if it were there, I believe.
<nirvdrum>
It's not a terribly popular opinion, but I think Microsoft is about the only one that gets versioning right.
<chrisseaton>
Windows 10?
<nirvdrum>
Bump a number at the end of the interface name. Symbolic name to the latest interface. Don't break compatibility.
<nirvdrum>
I mean for their APIs.
<nirvdrum>
DirectX 12 doesn't break the 11 versions that came before it.
<chrisseaton>
ah
<nirvdrum>
With the exception of one tweak to HWND hierarchy because IE 7 introduced tabbed browsing, the same browser plugin I had written for Mogotest worked on IE 6 - 10.
<nirvdrum>
I couldn't get a Firefox add-on to work for more than 6 weeks at a time. I just eventually gave up on that one.
<enebo>
nirvdrum: but hey FF 40.0 fixes all that :P
<enebo>
I kid…it is still not fixed :)
<nirvdrum>
Heh.
<enebo>
Well unless you consider saying every release is major as fixed
<headius>
does FF use xpcom?
<enebo>
nirvdrum: our flaky two number thing is more about expectations for how we expect people to upgrade
<nirvdrum>
I had colleagues at Mozilla that would complain about people complaining about the rapid version numbers. Fine, but don't keep breaking the APIs and saying it's okay because you bumped version numbers.
<enebo>
if we go from 2.2 MRI support to 2.3 we will not consider that a major version (unless they add mandotory static typing or something craz)
<enebo>
3.0 might be a major version if we assume their will be breaking changes
<nirvdrum>
enebo: Well, my original point is there are two camps on what happens when you get to a ".9". For a while, the next patch release after x.y.9 was x.y+1.0, not x.y.10. The latter seems to have won and people just accept it's not quite decimal. Fair enough, but then going from x.y to x.y.1 doesn't make much sense. You can't argue it's not decimal and then say ".0" is implied.
<enebo>
but honestly I do not see Ruby evolving a lot any more past endless proliferation of more instance methods on Array and String
<cpuguy83>
lol
<enebo>
nirvdrum: yeah I can see your argument…that why we used more numbers than anyone on the planet
<enebo>
again I kid but we do have .0 for explict securty releases at least
<nirvdrum>
headius: I thought they were moving away from xpcom. But I'm not sure.
<headius>
I haven't looked into mozilla/ff plugins in a long time
<enebo>
FF moved from xpcom for a majority of stuff in likw 2001
<headius>
heh ok, so it has been a really long time
<nirvdrum>
And Chrome dropped NPAPI.
<enebo>
the firefox takeover got rid of lots of XPCOM interfaces
<nirvdrum>
Which cascaded into Opera.
<enebo>
it was much too heavy to be used everywhere
<nirvdrum>
Closing Mogotest wasn't the worst decision I've ever made :-)
<enebo>
I don’t kow if they completely abandoned it or not
<headius>
COM is still one of the few models I've seen for C++ component interop
<enebo>
yeah
dfr|work has joined #jruby
<enebo>
beside interop/versioning they made all the automation stuff via IDispatch and IUnknown which is also quite cool (even if it is a virus writers paradise)
<enebo>
which I guess is not COM but I don’t think it would have existed without COM
<nirvdrum>
So, I'd like to try my hand at an ImmutableByteList, but ByteList is a final, concrete class. Was that done for safety or just performance?
<enebo>
heh
<enebo>
ByteList is the Corvair of Java classes
<enebo>
It is unsafe at any speed
<nirvdrum>
Heh.
<enebo>
nirvdrum: we do lots of field access stlll of bytelist don’t we?
<enebo>
nirvdrum: I know we have public methods to grab fields too but the lack of abstraction might make your goal more difficult
<nirvdrum>
I don't think that many.
<headius>
nirvdrum: I don't remember the reason
<headius>
might have been misguided attempt to help JVM JIT
<enebo>
we used to do lots of microopts which behaved well in java 1.4
tcrawley is now known as tcrawley-away
<enebo>
The marketers of that commercial could not come up with unusual car for unusual people
<enebo>
well they did come up with that I mean nothing better than that
<enebo>
I would try, “hey buy this cool new car…fin”
<enebo>
I sure Top Gear would love that car if they were reviewing it
<enebo>
They never seem to give good reviews to cars which stay on the track
subbu|lunch is now known as subbu
rsim has joined #jruby
havenwood has joined #jruby
<nirvdrum>
enebo: I'm actually not seeing any direct field access.
<enebo>
nirvdrum: cool. so that has been fixed over time
<headius>
heh, IR does so many things better
<headius>
realized for this bug that 1.7 compiler forced heap scope for simple things like a while with a return in it
<enebo>
headius: a bit more generic right?
<headius>
definitely more generic, but also better analysis of code
<enebo>
headius: that was one thing which has struck me is we get similar optimizations but much less targetted
<headius>
much better than my old compiler
<nirvdrum>
enebo: So... a new bytelist release that makes those fields private and removes the 'final'? :-)
<headius>
nirvdrum: I think that's appropriate
<headius>
they've been deprecated for years awaiting this moment
<enebo>
nirvdrum: how many version numbers?
<nirvdrum>
Heh. Arguably it should be a major version bump.
<enebo>
nirvdrum: we should major version it
<nirvdrum>
Dunno how many people out there are using bytelist outside of JRuby.
<enebo>
nirvdrum: we have not ever broke the API in all these years
<enebo>
nirvdrum: so I think we have some political good will on changing it
<nirvdrum>
headius: I was looking in Options today. There are quite a few indy options that are never used.
<headius>
nirvdrum: yeah I need to tidy them up or use them
<headius>
many are for features that early indy did not optimize well
baroquebobcat has quit [Quit: baroquebobcat]
baroquebobcat has joined #jruby
<nirvdrum>
enebo: Are you going to do it or want me to do a PR? I don't believe I have permissions on the repo directly.
<enebo>
nirvdrum: PR it or I can give you access
<enebo>
your choice
<enebo>
nirvdrum: although I would be interested at some point in seeing how you plan on utilizing mimutable bytelist too
<enebo>
nirvdrum: the other week you also mentioned ROPES
<nirvdrum>
I'll do the PR so you can double-check it.
<enebo>
ok
<nirvdrum>
I'm starting to look at some of the stuff we've been talking about on-and-off for the past 6 months.
<enebo>
nirvdrum: I imagine ROPS-like will be above it made of immutable bytelists?
<enebo>
AggregateBytelist
<nirvdrum>
ImmutableByteList would be more to keep things final across the board, support light-weight pooling, and mostly to ensure I don't mess stuff up.
<headius>
rebooting to Windows, bbiab
pitr-ch has joined #jruby
headius2 has joined #jruby
dinfuehr has joined #jruby
<headius2>
for great justice
<nirvdrum>
Why not just use a VM?
<headius2>
I can't stand the lag of a VM usually
<nirvdrum>
Need to install the binary tools or whatever.
<headius2>
I do
<nirvdrum>
Assuming you're on an SSD.
<headius2>
still pretty laggy
<headius2>
I need a newer machine
<nirvdrum>
Weird. I run almost exclusively in a VM now.
pitr-ch has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
pitr-ch has joined #jruby
skade has joined #jruby
AnoHito has joined #jruby
<atamb0>
github is down?
<enebo>
atamb0: my comment to your issue must have killed it
<atamb0>
enebo: when I searched past issues I saw similar stack traces
<atamb0>
enebo: but not in getValue()
<enebo>
atamb0: we had this issue I think on 9k recently (last month or two) and I don’t remember why but it looks like your shutdown hooks are running after main has finished and nothing is around any more
<enebo>
headius: do you remember what this was? ^
<headius2>
enebo: swing event thread stuff I think
<enebo>
It is driving me crazy…like I can almost remember why :)
<headius2>
swing event thread continued to try to use runtime after main, but things had been shut down
<enebo>
headius2: ah but we had a second issue related with the same general cause
<enebo>
headius2: I was thinking it was due to a change of some kind
<headius2>
hmm
<headius2>
perhaps 9k shutting down stdio streams where 1.7 did not?
<enebo>
atamb0: but if you have a thread in a shutdown hook or it executes from a java thread
<enebo>
headius2: yeah and this is on 1.7.x
<atamb0>
I'm thinking it has to do with using puma to run my rspec feature tests
<atamb0>
that is something I changed recently
<enebo>
hmm
<enebo>
atamb0: well I guess we can only give you the clue that the runtime has fnished and exit hooks are trying to invoke after that point
<enebo>
atamb0: which might be us or might not…but the only place where I think we were in the right was the swing example where main thread finished and swing ui thread then executed some ruby code...boom
<enebo>
Freeky: try JRUBY_OPTS=—dev and see if it ever happns
<enebo>
Freeky: well it might…in that it has been JIT'd
<Freeky>
will try that, should find out quickly enough
<Freeky>
after the minute it takes to start ;)
<enebo>
Freeky: but that does not mean it won’t with —dev since —dev force interp mode but will promote to a second interpreter
Freeky is now known as Freaky
<enebo>
Freeky: but it will never JIT. So if it happens with —dev then we have a generic IR bug if not then it may be a bytecode generation problem
dinfuehr has quit [Ping timeout: 250 seconds]
<Freaky>
yeah, looks like that fixes it
<enebo>
Freaky: ok then change to JRUBY_OPTS=-Xjit.threshold=0 and see if it happens immediately
<enebo>
Oh also add -Xjit.background=false
<enebo>
Freaky: open an issue…I need to go afk a while
enebo has quit [Quit: enebo]
<nirvdrum>
He's gone?!?!
<Freaky>
that does it, guess next step is a minimal test case, because this whacky great big sprawling pile of crap isn't really something I can include in an issue ;)
kfpratt has joined #jruby
elia has joined #jruby
subbu has quit [Ping timeout: 252 seconds]
skade has quit [Quit: Computer has gone to sleep.]
elia has quit [Quit: Computer has gone to sleep.]
elia has joined #jruby
subbu has joined #jruby
camlow32_ has joined #jruby
camlow32_ has quit [Remote host closed the connection]
camlow32_ has joined #jruby
bbrowning is now known as bbrowning_away
camlow32_ has quit [Remote host closed the connection]
camlow32_ has joined #jruby
camlow325 has quit [Ping timeout: 255 seconds]
camlow325 has joined #jruby
camlow32_ has quit [Read error: Connection reset by peer]
camlow32_ has joined #jruby
camlow325 has quit [Read error: Connection reset by peer]
headius2 has left #jruby [#jruby]
dinfuehr has joined #jruby
dinfuehr has quit [Ping timeout: 246 seconds]
skade has joined #jruby
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
elia has quit [Quit: Computer has gone to sleep.]
elia has joined #jruby
samphippen has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
colinsurprenant has joined #jruby
skade has quit [Quit: Computer has gone to sleep.]
camlow32_ has quit [Remote host closed the connection]
colinsurprenant has quit [Quit: colinsurprenant]
camlow325 has joined #jruby
skade has joined #jruby
lanceball is now known as lance|afk
djbkd has quit [Remote host closed the connection]
djbkd has joined #jruby
djbkd has quit [Read error: Connection reset by peer]
camlow325 has quit [Remote host closed the connection]
camlow325 has joined #jruby
dinfuehr has joined #jruby
dinfuehr has quit [Ping timeout: 250 seconds]
djbkd has joined #jruby
pitr-ch has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]