e_dub has joined #jruby
camlow325 has joined #jruby
_elia has quit [Quit: Computer has gone to sleep.]
camlow325 has quit [Remote host closed the connection]
elia has joined #jruby
camlow325 has joined #jruby
skade has quit [Quit: Textual IRC Client: www.textualapp.com]
elia has quit [Quit: Computer has gone to sleep.]
colinsurprenant has quit [Ping timeout: 240 seconds]
mrmargolis has quit [Remote host closed the connection]
subbu is now known as subbu|shovelling
enebo has quit [Quit: enebo]
elia has joined #jruby
pgokeeffe has quit [Quit: pgokeeffe]
baroquebobcat has quit [Quit: baroquebobcat]
camlow3__ has joined #jruby
camlow325 has quit [Ping timeout: 244 seconds]
e_dub has quit [Quit: e_dub]
camlow3__ has quit [Remote host closed the connection]
subbu|shovelling is now known as subbu
camlow325 has joined #jruby
mitchellhenke has joined #jruby
calavera has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
elia has quit [Quit: Computer has gone to sleep.]
elia has joined #jruby
subbu is now known as subbu|away
Hobogrammer has joined #jruby
Hobogrammer has quit [Client Quit]
pietr0 has quit [Quit: pietr0]
mitchellhenke has quit [Quit: Computer has gone to sleep.]
pgokeeffe has joined #jruby
mitchellhenke has joined #jruby
Hobogrammer has joined #jruby
elux has joined #jruby
marr has quit [Ping timeout: 245 seconds]
kaawee has quit [Quit: Konversation terminated!]
mitchellhenke has quit [Quit: Computer has gone to sleep.]
e_dub has joined #jruby
camlow325 has quit []
subbu|away has quit [Ping timeout: 244 seconds]
e_dub has quit [Read error: Connection reset by peer]
pgokeeffe has quit [Quit: pgokeeffe]
e_dub has joined #jruby
elia has quit [Quit: Computer has gone to sleep.]
nanoyak has quit [Quit: Computer has gone to sleep.]
travis-ci has joined #jruby
<travis-ci> jruby/jruby (master:b63047d by Kevin Menard): The build was broken. (http://travis-ci.org/jruby/jruby/builds/46380886)
travis-ci has left #jruby [#jruby]
<Antiarc> brocktimus: I actually am really happy for that change. The inability to get times in the timezone I parsed them from was a constant annoyance
<Antiarc> That said, UTC all the things.
x1337807x has quit [Ping timeout: 245 seconds]
Neomex_ has quit [Read error: Connection reset by peer]
x1337807x has joined #jruby
<headius> yeah I always thought that was weird
elux has quit [Quit: Bye!]
towski has joined #jruby
mrmargolis has joined #jruby
towski has quit [Read error: Connection reset by peer]
towski has joined #jruby
towski has quit [Read error: Connection reset by peer]
x1337807x has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
mrmargolis has quit [Remote host closed the connection]
jmimi has quit [Quit: Leaving.]
pgokeeffe has joined #jruby
pgokeeffe has quit [Ping timeout: 245 seconds]
calavera has joined #jruby
nanoyak has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub> [jruby] headius force-pushed new_yield from fa745e7 to e2cbd3d: http://git.io/E-q6Zw
<JRubyGithub> jruby/new_yield e2cbd3d Charles Oliver Nutter: Modify yield logic to be aware of the on-stack block....
JRubyGithub has left #jruby [#jruby]
jeremyevans has quit [Quit: leaving]
<headius> zing
havenwood has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub> [jruby] Who828 opened pull request #2443: Follow MRI implementation for RubyArray hash (master...master) http://git.io/5Y6O_A
JRubyGithub has left #jruby [#jruby]
subbu|away has joined #jruby
subbu|away is now known as subbu
jeremyevans has joined #jruby
nirvdrum has quit [Ping timeout: 264 seconds]
calavera has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
calavera has joined #jruby
kfpratt has quit [Remote host closed the connection]
mrmargolis has joined #jruby
nanoyak has quit [Read error: Connection reset by peer]
nanoyak has joined #jruby
nanoyak has quit [Max SendQ exceeded]
nanoyak has joined #jruby
nanoyak has quit [Read error: Connection reset by peer]
mrmargolis has quit [Ping timeout: 264 seconds]
nanoyak has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub> [jruby] headius pushed 1 new commit to master: http://git.io/xtUuFA
<JRubyGithub> jruby/master f17a736 Charles Oliver Nutter: Modify yield logic to be aware of the on-stack block....
JRubyGithub has left #jruby [#jruby]
<headius> finally
kares has joined #jruby
travis-ci has joined #jruby
<travis-ci> jruby/jruby (master:f17a736 by Charles Oliver Nutter): The build was broken. (http://travis-ci.org/jruby/jruby/builds/46407528)
travis-ci has left #jruby [#jruby]
<headius> hah
<headius> after all my testing with MRI suite and RubySpec, I break the compiler spec
nanoyak has quit [Read error: Connection reset by peer]
nanoyak_ has joined #jruby
<headius> hmm, I think I need to talk to subbu or enebo about this one
subbu has quit [Ping timeout: 256 seconds]
jimbaker has quit [Ping timeout: 244 seconds]
calavera has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
deobalds has joined #jruby
x1337807x has joined #jruby
x1337807x has quit [Max SendQ exceeded]
x1337807x has joined #jruby
x1337807x has quit [Max SendQ exceeded]
x1337807x has joined #jruby
<projectodd-ci> Project jruby-master-spec-compiler build #324: FAILURE in 18 min: https://projectodd.ci.cloudbees.com/job/jruby-master-spec-compiler/324/
rsim has joined #jruby
rsim has quit [Client Quit]
<headius> yes yes
<headius> if singleton class bodies weren't so freakyweird
donV has quit [Quit: donV]
yfeldblum has quit [Remote host closed the connection]
JRubyGithub has joined #jruby
<JRubyGithub> [jruby] headius pushed 1 new commit to master: http://git.io/2z__-Q
<JRubyGithub> jruby/master bf71e56 Charles Oliver Nutter: Temporarily disable DCE (again) because of closure var issues.
JRubyGithub has left #jruby [#jruby]
<headius> fingers crossed
<headius> ttfn
x1337807x has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
jimbaker has joined #jruby
donV has joined #jruby
jimbaker has quit [Changing host]
jimbaker has joined #jruby
mrmargolis has joined #jruby
noop has joined #jruby
mrmargolis has quit [Ping timeout: 244 seconds]
towski has joined #jruby
<projectodd-ci> Yippie, build fixed!
<projectodd-ci> Project jruby-master-spec-compiler build #325: FIXED in 20 min: https://projectodd.ci.cloudbees.com/job/jruby-master-spec-compiler/325/
travis-ci has joined #jruby
<travis-ci> jruby/jruby (master:bf71e56 by Charles Oliver Nutter): The build was fixed. (http://travis-ci.org/jruby/jruby/builds/46411323)
travis-ci has left #jruby [#jruby]
dabradley has quit [Ping timeout: 256 seconds]
deobalds has quit [Quit: Computer has gone to sleep.]
rsim has joined #jruby
dabradley has joined #jruby
tenderlove has quit [Remote host closed the connection]
tenderlove has joined #jruby
erikhatcher has quit [Ping timeout: 264 seconds]
erikhatcher has joined #jruby
kfpratt has joined #jruby
kfpratt has quit [Ping timeout: 244 seconds]
JohnBat26 has joined #jruby
vtunka has joined #jruby
elia has joined #jruby
mrmargolis has joined #jruby
mrmargolis has quit [Ping timeout: 244 seconds]
Hobogrammer has quit [Ping timeout: 240 seconds]
skade has joined #jruby
thsig has joined #jruby
thsig has quit [Remote host closed the connection]
thsig has joined #jruby
deobalds has joined #jruby
benlovell has joined #jruby
drbobbeaty has joined #jruby
thsig has quit [Ping timeout: 265 seconds]
marr has joined #jruby
e_dub has quit [Quit: e_dub]
SynrG has quit [Remote host closed the connection]
JohnBat26 has quit [Ping timeout: 252 seconds]
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
havenwood has quit [Remote host closed the connection]
nanoyak_ has quit [Quit: Computer has gone to sleep.]
mrmargolis has joined #jruby
e_dub has joined #jruby
e_dub has quit [Client Quit]
mrmargolis has quit [Ping timeout: 244 seconds]
deobalds has quit [Ping timeout: 264 seconds]
deobalds has joined #jruby
shellac has joined #jruby
drbobbeaty has joined #jruby
Xzyx987X has quit [Quit: Leaving]
thsig has joined #jruby
thsig has quit [Remote host closed the connection]
thsig has joined #jruby
Xzyx987X has joined #jruby
thsig_ has joined #jruby
mrmargolis has joined #jruby
thsig has quit [Ping timeout: 252 seconds]
mrmargolis has quit [Ping timeout: 244 seconds]
benlovell has quit [Ping timeout: 264 seconds]
SynrG has joined #jruby
kares has quit [Ping timeout: 264 seconds]
SynrG has quit [Remote host closed the connection]
dabradley has quit [Ping timeout: 240 seconds]
nirvdrum has joined #jruby
deobalds has quit [Quit: Computer has gone to sleep.]
bbrowning_away is now known as bbrowning
rcvalle has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub> [jruby] Allanon29 opened issue #2444: Gem::LoadError: can't activate jruby-openssl-0.9.6-java, already activated jruby-openssl-0.9.5-java http://git.io/aYtUyw
JRubyGithub has left #jruby [#jruby]
donV has quit [Quit: donV]
SynrG has joined #jruby
dabradley has joined #jruby
e_dub has joined #jruby
benlovell has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub> [jruby] eregon pushed 1 new commit to master: http://git.io/a4Szdw
<JRubyGithub> jruby/master 83b4dba Benoit Daloze: [Truffle] JT: allow arbitrary paths for `jt test`....
JRubyGithub has left #jruby [#jruby]
colinsurprenant has joined #jruby
colinsurprenant has quit [Client Quit]
colinsurprenant has joined #jruby
yopp has quit [Ping timeout: 264 seconds]
yopp has joined #jruby
tcrawley-away is now known as tcrawley
skade has quit [Remote host closed the connection]
deobalds has joined #jruby
skade has joined #jruby
<headius> what magic shall we conduct today?
<lopex> numbers
<headius> numbers!
<headius> we aren't quite faster than 9k for yield yet, so that's an opportunity
<lopex> headius: my superduper framework appears to be working on 9k
<lopex> headius: but bundler fails in windows
<headius> most things should fail in Windows
<brocktimus> So whats the goal for 9k? Compatability with MRI and then when you have it optimizations ahoy?
<headius> that's the ticket
<lopex> I'd prefer numbers
<headius> we reward ourselves with a little optimization work once in a while, like my excursion into yield yesterday
<chrisseaton> headius: have you guys started making a release todo list? things like the website could do with an update with the new version (it says 1.8 and 1.9 compat and things like that)
<chrisseaton> headius: the reason I ask is I was thinking about a one sentence statement on the status of Truffle for release for the release notes
<headius> yeah I know...I was going to open a bug for release notes and release task gathering
<headius> yeah cool
<headius> do you have any approaching milestone that could align with a preview release, or is any snapshot ok?
AckZ has joined #jruby
<chrisseaton> headius: the good news is we should be able to say 'supports basically all of the language, around 1/4 of core lib; don't try and run any applications but feel free to experiment if you're an expert'
<chrisseaton> snapshot is fine, but give me 24 hours notice and I'll freeze double check some stuff
<brocktimus> chrisseaton: core lib => stdlib?
<chrisseaton> no sorry, core lib
<chrisseaton> as in the bit written in C normally
<chrisseaton> Array, Hash, String etc
<brocktimus> Oh right
<chrisseaton> we do run some stdlib, but we're not usually experimenting with it. It should just work with a fuller core library, theoretically
<brocktimus> I've noticed you've been importing some stuff from rbx, are you using that to save time instead of writing it all in Java now?
<brocktimus> I'm finding the 9k development fascinating to watch :P
JRubyGithub has joined #jruby
<JRubyGithub> [jruby] headius opened issue #2445: Release 9k Preview http://git.io/LOZREg
JRubyGithub has left #jruby [#jruby]
<headius> chrisseaton: you'll have at least 24 hours
skade has quit [Remote host closed the connection]
<headius> chrisseaton: clarify something for me...does the design of truffle prevent *all* Java code from inlining? Is that what necessitates lifting core class behaviors to truffle nodes?
<headius> (and using Ruby impls where possible)
<nirvdrum> brocktimus: The idea is that when compiled with Graal the resulting machine code is identical whether we write the methods in Ruby or Java.
<chrisseaton> headius: we're using Ruby (it's not important that it's Rbx) because when we write Java we have to add things like branch profiles ourselves, when we use Ruby we get those for free
<nirvdrum> And some of this stuff is just a hell of a lot easier to write in Ruby (and it's already been written).
<chrisseaton> headius: Truffle doesn't like having some quite specific Java patterns inlined - things like StringBuilder are problematic, but the key reason for using Ruby is when you add all our profiling and things it's a lot less code
<chrisseaton> headius: I'll blog about this at some point and include some concrete examples of the difference it makes
<nirvdrum> chrisseaton: I think you need to be targeting brocktimus on those ;-)
<headius> nirvdrum: well I did ask at the same time...I'm a troublemaker
<brocktimus> Im reading anyways :D
<nirvdrum> Oh, I guess I'm the jerk then.
<headius> chrisseaton: ok, just trying to keep my understanding of the relative differences between both approaches
<chrisseaton> I'll dig up some examples... one minute
kares has joined #jruby
<headius> indy manages to inline Java-based core class methods pretty well, which makes moving them to Ruby less of a win
<brocktimus> So when you're writing Java you're writing the "low level Ruby" as Truffle ASTs, then its compiled by Graal to machine code
<brocktimus> The talks I've watched have me a bit confused because of Truffle + Graal + Invoke Dynamic
<headius> Ruby would inline too, but we're sacrificing easily-optimized code for nicer code
<lopex> chrisseaton: what is specific about those patterns truffle doesnt like ?
<chrisseaton> lopex: we can't 'partially evaluate' unbounded recursion - and for some reason StringBuilder does that
<headius> brocktimus: important to point out first that the truffle runtime and the normal JVM runtime are entirely separate
donV has joined #jruby
<headius> we're working on sharing more of the core class implementations but the two approaches are very different
<chrisseaton> this conversation is getting a bit complicated...
<brocktimus> is 9k all just truffle'd then?
skade has joined #jruby
<headius> 9k will have a JVM runtime and a (still experimental) Truffle runtime
<chrisseaton> headius: this is Array#map when the array is an int[] https://github.com/jruby/jruby/blob/master/core/src/main/java/org/jruby/truffle/nodes/core/ArrayNodes.java#L2312-L2332. An example of the complexity of writing in Java is where we have to report loop counts back to the compiler. In Ruby code we get that for free as our Ruby loop constructs already do
<chrisseaton> that.
<headius> as far as language features both will be similar I suspect, but jruby+truffle has a lot more work filling out core classes
<chrisseaton> brocktimus: you shouldn't expect to be using Truffle any time this year
<brocktimus> right
<headius> chrisseaton: so I imagine this is a problem with graal's IR not matching hotspot's, and hotspot's generated profiling probes not being easy to correlate back to graal IR
<nirvdrum> But we can run a subset of ERB now!
<headius> it is after all two different JITs sorta cooperating and sorta not
<lopex> nirvdrum: how much of String impl is already shared now ?
<chrisseaton> headius: I don't know much about HotSpot's profiling, but I don't think it's as capable as these explicit guards
<nirvdrum> lopex: Only a handful of methods. I'm working on that still.
<headius> chrisseaton: I know bits and pieces
<nirvdrum> lopex: We have other String methods we wrote previously for expediency, but they're not encoding aware so they all need to be redone anyway.
<headius> of course it does branch and type profiling
<lopex> nirvdrum: in the past we thought some StringSupport impls should go into jcodings (now, since it can be a breaking change)
<headius> chrisseaton: what I didn't understand is why the truffle and java sides wouldn't meet nicely at graal IR...since they both have to pass through it
<headius> profiling happening below graal IR, even on a graal-enabled VM, helps explain that
<headius> you need graal metrics for graal, and by the time hotspot starts running and profiling it you're too far away
<nirvdrum> lopex: Cool. I'm making a bit of a mess right now hoping more common patterns emerge and then I'll clean up afterwards. I've done some of that already.
<nirvdrum> lopex: One positive is RubyString is getting much slimmer. It'll basically just be @JRubyMethods when done. But StringSupport is getting massive.
<lopex> so graal doesnt use hotspot profile even as an additional info ?
<headius> yeah, there's a ton of stuff that belongs in jcodings
<headius> lopex: well, it is probably meaningless to graal
<chrisseaton> lopex: Graal doesn't use hotspot after the interpreter phase
<headius> chrisseaton: I thought that graal's IR fed into hotspot at some level
<lopex> chrisseaton: jvm interpreter ?
<chrisseaton> headius: talking about hotspot profiles doesn't make much sense anyway, as when we write out interpreters we don't know anything about hotspot
<chrisseaton> headius: no Graal emits raw machine code bytes and just hands them to hotspot
<headius> chrisseaton: sure, that's a much bigger gap...truffle's doing its own profiling too
<headius> chrisseaton: on a graal openjdk, is Java going through graal too or still using hotspot?
<lopex> ah, and the rest is too java specific ?
<chrisseaton> headius: I'm going to do a demo at FOSDEM where I will show a Ruby Fixnum#+ and follow it all the way down to the add and jo instruction bytes
<headius> Ithought it was the former
subbu has joined #jruby
<chrisseaton> headius: it you can use Graal for non-Truffle, or you can let HotSpot do that bit
deobalds has quit [Quit: Computer has gone to sleep.]
<lopex> chrisseaton: and some IR graphs would be cool too :)
<chrisseaton> Oh I've got a presentation I can make public about IR graphs: https://www.dropbox.com/s/29t5hdo8f7j4ly7/igv-for-truffle.pdf?dl=0
<headius> chrisseaton: yeah, but I mean is there ever an opportunity for truffle's resulting graal IR and plain Java code's graal IR can meet
<chrisseaton> headius: only through a Java method call interface
<chrisseaton> they can call each other's generated code
<headius> but they remain pretty separate
<headius> ok
<lopex> so that's why substratevm can exist ?
eroot has joined #jruby
<chrisseaton> yeah, svm has nothing of hotspot in it
<headius> I wish I'd had more time to play with maxine
Aethenelle has quit [Quit: Aethenelle]
eroot is now known as Aethenelle
<headius> chrisseaton: so that's one place where there will remain some differentiation
<chrisseaton> some people at the group at Manchester are keeping it alive and back porting Graal into it (back where it came from I guess)
<headius> JRuby's java integration can often inline too, so whether code's in Ruby or Java doesn't really impact how hotspot inlines
mrmargolis has joined #jruby
<headius> or rather, doesn't really impact how <current JVM's JIT> inlines
<headius> java, scala, clojure, whatever
<chrisseaton> the other thing with bringing Ruby code from Rbx in is that this is code we haven't written in Java yet, so it's Ruby code we don't have to write vs Java code we do have to write. We will probably implement some of it in Java again when we find what's hot.
fidothe__ is now known as fidothe
<chrisseaton> headius: if you run Graal as your JVM (not using Truffle, just normal IR on 9k) you can see the Graal graphs in that slide deck for your own code
<brocktimus> chrisseaton: So JRuby Truffle will somewhat be akin to "Ruby written in Ruby of Rbx", but the Kernel / hot spots will be Java Truffle as opposed to C++
<headius> I would like to explore why graal is still slower for normal JVM jruby
<headius> at some point :-\
<chrisseaton> brocktimus: yes that's one way to look at it - I wouldn't chose to brand it quite like that - we're part of JRuby and do things the JRuby way
<chrisseaton> headius: I think it's still missing some basic optimisations that haven't been interesting to implement yet - an artefact of being a research project
<headius> yeah, and there's nothing stopping the JVM runtime from using the pure-Ruby core classes once we've verified they're as complete as native ones
<chrisseaton> headius: it's faster for Scala I know
<headius> chrisseaton: I was hoping to magically see partial escape analysis
<Aethenelle> shiny new machine...
<headius> I still believe if we had really good partial escape analysis we could get indy-based JRuby to be competitive with jruby+truffle
<headius> allocation is our 99% problem for performance
<chrisseaton> in a benchmark like mandelbrot do you still box floats, even in the new IR?
metadave has joined #jruby
<headius> subbu's unboxing prototype is still in there, and when I last played with it, it was about 50% jruby+truffle
<chrisseaton> mandelbrot is the one to compare with - Nashorn with indy is faster than V8 on that I think - it's good because it's very simple code so if there's a problem it should be obvious, and you should be able to be faster than V8 due to just better instruction selection and register allocation in V8
<headius> it did not unbox fixnums used in the algorithm though, so there's more to improve
<headius> right, nashorn has gone all the way to type specialization already...we'll be able to do that at a more relaxed pace, because we have an interpreter to bail out to
<headius> it won't be a big thing for us to try out specializations and back off
<chrisseaton> what you need to petition the JVM people for is first class access to the stack
metadave has quit [Client Quit]
<chrisseaton> in truffle I can pull out the nth method on the stack and read/write it's local variables if I want to
<headius> that would be lovely
<headius> in theory though we could eliminate all scope allocation by maintaining a big per-thread IRubyObject[]
<chrisseaton> because isn't everything on the heap when you're in a block? and most Ruby code executed is probably in a block - due to loops
<chrisseaton> headius: but then everything will escape won't it?
<headius> only what has to go in there
noop has quit [Ping timeout: 240 seconds]
<headius> but yes, that would impact inlining through blocks
<headius> that's why subbu also explored inlining in IR, so we can get a head start on hotspot
<headius> IR is much more of a VM-on-top-of-a-VM than our 1.7 runtime
<headius> we have a lot of runway to do cool things with IR without losing cross-JVM compat
<subbu> good morning.
<brocktimus> headius: Easier question, best talk to watch for contrasting how 1.7 worked v upcoming 9k IR implementation (if thats proper term) ?
<headius> hmmm
<headius> probably our talk from rubyconf 2014
<headius> and that is the proper terminology
<subbu> ya .. unboxing is in there but that needs work .. firstly more thorough testing and bug fixes .. plus adding guards in some places and then figuring out when to apply it.
<headius> yesterday's work cleared up a lot of questions for me
<subbu> but, overall, the one thing that bogs down doing aggressive things here is how easy it is to de-opt .. that is where i've been stuck since 2009 .. but now that this first pass is done, we can start looking at that again.
<subbu> i think graal makes it much easier to deopt if i understand correctly.
<headius> subbu: in my head, as long as we know variable liveness and IPC we should be able to branch directly into interpreter
<brocktimus> headius: most important question I just remembered. Why aren't you wearing red hats at confs now? :-D
<headius> brocktimus: the largest one I can get from the company store is too small for my head?
<subbu> headius, you still need to be able to maintain enough state to be able to reconstruct interp state from wherever you are in jit.
<headius> wide-brimmed fedoras aren't really my style either though...maybe I should get a more hipsterish had but in red
<headius> had=hat
<subbu> but, looking at your commit from y'day .. why are you adding both implicit-block-load and frame-block-load to all scopoes?
mrbrdo has joined #jruby
<headius> subbu: because I didn't want to write a pass to know which of them would be needed
<headius> if they're not used they'll disappear anyway
<subbu> where would a frame scope load be needed in a method scope?
<subbu> s/where/when
<headius> hmmm...I don't *think* I'm doing that
<subbu> i see .. i didn't look carefully then :)
<mrbrdo> is therubyrhino still the way to go for assets compilation on jruby? I remember headius you were talking at some point that you guys are working on something new due to some problems in Rhino
<headius> I thought I was just populating both possible closure variables everywhere, even if they came from the same place
<headius> method bodies should just load passed block... blocks will load both passed block and frame block
<headius> mrbrdo: it's pretty slow :-\
<mrbrdo> yeah that’s why I remembered to check up on this. but is there an alternative?
<chrisseaton> Shame there's no rubynashorn yet
<subbu> headius, actually you are .. prepareImplicitState in IRBuilder
<headius> there was a patch I made to rhino that allows using its compiler all the time, but I don't know if that got released, and if it did I don't know if therubyrhino picked it up
<subbu> it is called for all scopes including methods.
<headius> main reason therubyrhino is slow is because they had to be conservative and turn off the compiler
<subbu> and i see both being added there.
<subbu> ah .. actually let me take that back.
<subbu> you are adding a load of implicit-block into 2 diff varas.
<mrbrdo> we don’t have an alternative right? is there something under development
<headius> subbu: right
<headius> because it was necessary to distinguish passed block from frame block for some scopes
<headius> well, passed block from the "yieldable" block
<subbu> for yield?
<headius> right
<subbu> rruby snippet?
<headius> in method, implicit block (used for block arg) = passed block, yield block = passed block
<headius> sure
<headius> def foo; bar {|&b| b.call; yield}; end; foo { }
<mrbrdo> headius: also, will the encoding fixes you made for me be in the next release of 1.7 ?
<headius> the block passed to bar has two different blocks available to it
enebo has joined #jruby
<headius> enebo: 'gmornin
<headius> mrbrdo: sadly not...it may be possible to backport some of it but it's a big job
<subbu> headius, but the yield will still yield to th eblock passed to foo right?
<headius> subbu: right
<enebo> headius: morning!
<headius> so in a closure, yield block = frame block, arg block = passed block
<subbu> so, that is still the same block that comes from frame-load
<mrbrdo> headius: but the fix was applied onto the 1.7 codebase right, not 9k? (since it already worked on 9k)
<headius> arg block actually always comes from passed block, so we could simplify that a bit
<subbu> i.e. %blk = load_implicit/load_frame block; b = reify(%blk); .. yield %blk
<subbu> so, it is always a single var
<headius> subbu: the &b block is a different block though
<nirvdrum> mrbrdo: You're better off using node to compile if you can.
<subbu> ah, right. :)
<headius> I didn't write bar... but it would be like def bar(&b); b.call { }; end
<nirvdrum> mrbrdo: Install node and set the env var EXECJS_RUNTIME=Node
<nirvdrum> Sprockets will then use that.
<headius> mrbrdo: oh! you're talking about a specific fix
<mrbrdo> oh?? whoa I did not know it was that easy
<headius> which one?
<mrbrdo> headius: let me link you the issue 1 sec
<headius> subbu, enebo: hey, you'll like this
<headius> I hit a wall when I got to metaclass bodies since they inherit a yieldable block
<headius> BUT
<headius> they always inherit the yield block of the immediate surrounding scope
<headius> so I just made it pass through on JVM stack...voila, yield in metaclass works and no frame needed
<mrbrdo> nirvdrum: so I can just remove therubyrhino and set that env var, and it will just work?
<enebo> sclasses in theory can be nested? Does that work?
<headius> it will still work fine because the yield block from outer will pass through to inner
<nirvdrum> You might still need it to satisfy a require statement. I don't recall. But it will pick up Node and things will be much, much faster.
<nirvdrum> TIAS.
<headius> I bet it does work
<enebo> ah so it will just keep getting from last one
<headius> right
<enebo> ok
<headius> down the line
<headius> now the problem that finally broke me
<headius> DCE is removing my closure loads
<headius> I have no idea why
<enebo> headius: so is it still broken
<mrbrdo> nirvdrum: require of what?
<headius> I didn't notice it right away because our JIT is so nice about failing quietly
<headius> enebo: I'll show you an example
<nirvdrum> mrbrdo: Ostensibly something loads the gem.
metadave has joined #jruby
<subbu> headius, but, back to the 2 var issue .. can't you look at block ast arg node ot figure out when a scope has a |&b| and only then insert the two loads?
<mrbrdo> nirvdrum: I am confused, which gem? I thought sprockets will just use the node binary
<headius> POOF, they're gone like Keyser Soze
<mrbrdo> headius: https://github.com/jruby/jruby/issues/2419 so this, will it be in the next release of 1.7?
<mrbrdo> lol
<nirvdrum> mrbrdo: Try it and see. I really don't recall. But Sprockets may very well try to require something that therubyrhino provides. It depends on how eagerly it loads things.
<headius> and %v_1 is obviously not dead
<mrbrdo> nirvdrum: oh okay. yeah sure will try it, thanks for the tip
<nirvdrum> It can still require therubyrhino be present to get some basic class definitions and not use it for compilation.
<enebo> headius: which code is this for?
<subbu> headius, but, %v0 and %v1 aren't being used there though.
<nirvdrum> I don't recall.
<subbu> so, dce is correct in blowing them out.
Aethenelle has quit [Quit: Aethenelle]
JRubyGithub has joined #jruby
<JRubyGithub> [jruby] headius pushed 1 new commit to jruby-1_7: http://git.io/qf9gEQ
<JRubyGithub> jruby/jruby-1_7 01f3945 Charles Oliver Nutter: Merge branch 'test-fix-2419' into jruby-1_7
JRubyGithub has left #jruby [#jruby]
<headius> mrbrdo: it will now ^
<enebo> Oh this is also why subbu us asking about two loads
<mrbrdo> headius: good thing I asked :) thanks
<headius> enebo: right, I can explain the design
<enebo> I agree if there is no explicit &-arg we should just emit the one since it is a known thing at build time
<headius> mrbrdo: thanks for reminding me
JRubyGithub has joined #jruby
<JRubyGithub> [jruby] headius deleted test-fix-2419 at ff54579: http://git.io/VbBhAA
JRubyGithub has left #jruby [#jruby]
<mrbrdo> headius: I specifically didn’t close the GH issue myself so you will see it, but then someone else closed it instead of you :)
<enebo> mostly lines 14,15 confuse me. 16,17 I think is just covering the bases of your two block typesright?
mitchellhenke has joined #jruby
<mrbrdo> well enebo did, anyway :P
<headius> I don't know why there's two recv_self
<headius> there's some oddities in preamble code in IRBuilder
<enebo> ok
<headius> subbu: I'm sorry, this is the wrong snippit
<headius> I have one where %v_1 is used later
<headius> gimme a sec to revert DCE change and I'll do it again
<enebo> I am fairly certain I know why your two instrs are getting wiped out but the temps not being used also would make that happen
thsig_ has quit [Ping timeout: 256 seconds]
<headius> yeah ignore that snippit, I effed up
<headius> too much shit in my buffer
iamjarvo has joined #jruby
<headius> DCE should see variable liveness across basic blocks, right?
<headius> nevermind, of course it does
<subbu> yes, across blocks even.
<headius> the case I could not fix was actually still a metaclass
<headius> class << self; end at toplevel
<mrbrdo> nirvdrum: FYI, it seems it works without therubyrhino. and it’s indeed so much faster it’s ridiculous. this should be more known, I’ve never heard this is possible :)
JRubyGithub has joined #jruby
<JRubyGithub> [jruby] subbuss pushed 1 new commit to master: http://git.io/5x73GA
<JRubyGithub> jruby/master bfd1366 Subramanya Sastry: Fix typo: IMPLICT -> IMPLICIT
JRubyGithub has left #jruby [#jruby]
<nirvdrum> mrbrdo: Awesome. And you get to drop a dependency.
<mrbrdo> nirvdrum: this should be the default :)
<nirvdrum> mrbrdo: I suppose because you need to install node, it isn't.
<mrbrdo> right. it could be mentioned in therubyrhino readme I guess
<headius> subbu, enebo: updated same gist
<headius> now I can say it...POOF
<headius> oh hell, and I bet I know why
<headius> shite.
<mrbrdo> nirvdrum: btw, is this any different than using therubyracer on MRI? or does it make sense to do this on MRI too, if you know node is installed on the target
JRubyGithub has joined #jruby
<JRubyGithub> [jruby] subbuss pushed 1 new commit to master: http://git.io/t7p-Eg
<JRubyGithub> jruby/master 4d6732c Subramanya Sastry: Remove duplicate receive_self in methods
JRubyGithub has left #jruby [#jruby]
<headius> amazing what a good three hours of sleep can do for the mind
<headius> subbu: oh thanks, I missed that one
<headius> crap, it WAS my bug
<headius> textbook stupid
<subbu> ah, you probably forgot ot add that to operands in process_module_body?
<headius> you got it
JRubyGithub has joined #jruby
<JRubyGithub> [jruby] headius pushed 2 new commits to master: http://git.io/VisRCA
<JRubyGithub> jruby/master fd9ab76 Charles Oliver Nutter: Revert "Temporarily disable DCE (again) because of closure var issues."...
<JRubyGithub> jruby/master b3dacaa Charles Oliver Nutter: Add block operand to operands this instr consumes. Fixes DCE.
<subbu> k
JRubyGithub has left #jruby [#jruby]
<headius> I did that for every node I modified in turn
<headius> and wondered why stuff was going away
<headius> it's a bit error prone but I don't have a better suggestion
<headius> ok!
<headius> so then no problems
<headius> does the design makes sense to everyone?
<headius> enebo: I think you missed the meat of my description
<subbu> ok .. the last fix to do would be to introduce the second load based on information in IR builder .. unless i missed something there.
<headius> subbu: so I guess this is a strategy question
<headius> better to add instrs and let them go away or be smart about it
<subbu> if you have static information at IR build time, use it .. rather than more work later.
<headius> in this case I can just look at scope's args and know if it will need a block arg
<enebo> headius: ah yeah
skade has quit [Quit: Computer has gone to sleep.]
<headius> also...how do we feel about DCE for interpreter?
<headius> it's not doing it now
<enebo> I mean it is clear you can go to far with static info as well
<subbu> yes, that is one of the reasons i said .. use static info in ir builder ..
<enebo> headius: DCE slows startup time down currently
<enebo> headius: It does not pay for itself
<headius> ahh, I see
<headius> it might start to
<headius> now that interpreter is using ACP there's potential for code to shrink
<headius> anyway...I will fix the block-arg load to be conditional on block arg
<enebo> headius: This has been an evolving realization in IR. IR was originally for a compiler and for Java for that matter. The interpreter’s considerations are at odds with the design if you ask me
<enebo> headius: aweseome. I would like to fix this to make it a specialially named but still an ordinary temp var so we can read intent in the IR output
JohnBat26 has joined #jruby
<enebo> headius: from these snippets unless they are used you cannot tell which is which
<headius> enebo: yeah I didn't see how to do that, but it would be nice to have a readable name
<enebo> headius: yeah I think it will take some changes too allocation methods
<enebo> to
diegoviola has joined #jruby
<subbu> alright .. i'm going to get some breakfast now ..
<enebo> I am removing some no longer needed stuff
<headius> all told I'm happy with the changes
<subbu> and the switch into parsoid land.
<headius> subbu: have fun
<subbu> headius, yes .. looks good .. cleaned out a lot of ugly code.
<enebo> headius: This is really nice. The change has eliminated some special case stuff in IR
<headius> :-D
subbu is now known as subbu|breakfast
donV has quit [Quit: donV]
<enebo> Always weird when speeding something up ends up simplifying it at same time
<headius> it worked out very neatly
<brocktimus> less code is faster code, didnt tenderlove do a talk of ruby homeopathy :-D
<enebo> although this added more code in a sense
<headius> hmm...trying to figure out the best way to determine if there's a block arg
<enebo> more IR meant less tweaky Java logic I guess
<headius> doesn't appear to be a flag fo rit
<headius> for it
<enebo> and this will possibly slow down interp a tiny bit in cases where &b exists and is not used since we do not DCE
<subbu|breakfast> and before i forget .. if we can now get enebo to start writing more descriptive commit messages with a 80-char commit heading .. ;)
<headius> oh I see it
<enebo> subbu|breakfast: I have started
<enebo> subbu|breakfast: but I only do it for ones I think deserve it…although I guess I can enter reeducation
e_dub has quit [Read error: Connection reset by peer]
e_dub has joined #jruby
mrbrdo has quit [Quit: mrbrdo]
<brocktimus> headius: rewatched talk. So 9k takes ruby, turns it into JRuby defined IR which can be run through your interpreter "directly". Can also run it through your JIT which produces JVM bytecode. Then JVM can (and does) JITs JVM bytecode to native machine code as req'd. Sound about right?
<headius> brocktimus: all correct
<brocktimus> headius: Big change was defining your own Internal Representation which is easier to deal with as opposed to making everything work with ASTs ?
<headius> we can also do optimizations similar to the JVM *before* we make JVM bytecode, since we know more about how ruby works than hotspot
<brocktimus> You "wrote" internal language to suite JRuby and thus everything surrounding it is easier
<headius> that's right
<headius> the IR is designed for Ruby and more of a traditional optimizing compiler design
<brocktimus> So as you find out more about how JVM works you can alter the optimizations you do in the JIT so its faster, all layers above completely unaffected
<tenderlove> :D
<tenderlove> headius: heelllllpppp
<headius> tenderlove: morning!
<headius> brocktimus: that's right
<tenderlove> hey!
<headius> like my big commit last night...restructured IR instructions relating to yield
<headius> JIT only required minor changes then
<tenderlove> I'm trying to get the JRuby psych branch to build
<tenderlove> but I get errors
<headius> tenderlove: ok
<tenderlove> ext/java/PsychParser.java:58: error: cannot find symbol
<tenderlove> import org.jruby.util.unsafe.UnsafeFactory;
<tenderlove> maybe it's fixed in JRuby?
<headius> hmm
<tenderlove> I seem to remember hitting this
<headius> ah
<tenderlove> waiiiit
<tenderlove> I think you fixed this once
<headius> we had two such utilities
<headius> that one lost
<headius> it's UnsafeHolder now, same package
<tenderlove> argh
<tenderlove> psych has a jruby branch, but it has more errors
<headius> UnsafeHolder.U => Unsafe object or null
<headius> yeah we need to update from jruby master
<headius> I did a pass recently to catch up a bit
<headius> tenderlove: which branch are you looking at?
<headius> is there just the atambo one?
<headius> ok
<tenderlove> I'm not sure which we need to use
<tenderlove> this branch or atambo's
<headius> neither are recent
<tenderlove> :(
<tenderlove> headius: can you make it compile for me?
<headius> yeah let me see what I can do quick
lanceball is now known as lance|afk
<tenderlove> or at least tell me which branch I should look at
<tenderlove> I can probably make it compile
<headius> I really really want to get psych out of our codebase and get a -java gem
<tenderlove> After all, I used to be a Java programmer. #secret
<headius> tenderlove: I'm going to update it first
JRubyGithub has joined #jruby
<JRubyGithub> [jruby] enebo pushed 2 new commits to master: http://git.io/isSMDw
<JRubyGithub> jruby/master aa5f27c Thomas E. Enebo: Trivial remove unused method and have flip use proper add method
<JRubyGithub> jruby/master 2a9e7a8 Thomas E. Enebo: Now with new block handling instruction this logic for preserving an instr if its...
JRubyGithub has left #jruby [#jruby]
colinsurprenant has quit [Quit: colinsurprenant]
<headius> tenderlove: may I have push rights so I can just push this branch?
<tenderlove> I think you have them
mattwildig has joined #jruby
<headius> oh ok
<tenderlove> headius: you're on the psych core team
<tenderlove> lol
<headius> sweet
<subbu|breakfast> enebo, yup, only for those that are tricky and makes sense .. but, 80-char makes github summary prettier ... but not a big deal about the latter .. at wmf > 80 char commit heading is seriously frowned upon :)
<enebo> subbu|breakfast: yeah I used to write all things at 80 chars until someone wondered why I bothered in emails anymore since you can resize window to # of cols you want
elfuego has joined #jruby
<enebo> subbu|breakfast: but I cannot apply everything through a single lens I guess
<headius> I hate the 80 char thing but it does force you to condense thoughts
<headius> should have been 100 or 120 in this modern era
<enebo> headius: but you can have as many lines as you want too I guess that first line needs to be terse though
<enebo> 1000-12000
subbu|breakfast is now known as subbu
<headius> yeah I know
<enebo> like reading a novel in scroll form
<headius> I just end up condensing too much sometimes because I don't feel like it warrants two lines
<enebo> how many meters are you into war and peace?
<subbu> :)
<nirvdrum> GitHub's truncation is the worst change they've ever made. It's way too in your face and oftentimes the truncated message ends up longer than the original one.
<nirvdrum> All so the designers can have fixed height elements in the commit listing.
* nirvdrum ends rant
e_dub has quit [Quit: e_dub]
skade has joined #jruby
diegoviola has quit [Ping timeout: 255 seconds]
<subbu> i've been re-educated.
<headius> tenderlove: done
<headius> rake compile should compile it now and jruby -Ilib appears to pick up the gem libs and work right
<brocktimus> headius: It changed CPL -> EPL as well. Is that fine?
<brocktimus> I deal with licensing a bit so stuff like that sticks out...
<headius> CPL has an upgrade clause
<headius> I'm glad you noticed though :-) That was the first thing that struck me when I checked the diff
<brocktimus> Mostly closed source company who is scared of OSS :-P, I see a lot of license and even need to try decoding MS ones
<headius> yeah we've had to deal with those headache a lot too
colinsurprenant has joined #jruby
<headius> the CPL to EPL thing was brought to our attention by the chairman of the Eclipse Foundation, so I think we're good
<brocktimus> Its now saturday so I'm off, ciao all. Keep all being awesome and helpful :-D.
Hobogrammer has joined #jruby
<headius> brocktimus: have a nice night!
skade has quit [Quit: Computer has gone to sleep.]
<nirvdrum> General ruby question. Is there a way to get the yielded, but uncaptured, values to a block from within the block body?
<nirvdrum> I don't think there is, but I'm hoping I'm wrong.
<chrisseaton> The captured values are often munged up by the block destructure semantics anyway
camlow325 has joined #jruby
<chrisseaton> Is this for a Rubinius thing?
<headius> nirvdrum: not in standard ruby
travis-ci has joined #jruby
<travis-ci> jruby/jruby (master:4d6732c by Subramanya Sastry): The build has errored. (http://travis-ci.org/jruby/jruby/builds/46454099)
travis-ci has left #jruby [#jruby]
<nirvdrum> brb
diegoviola has joined #jruby
mattwildig has quit []
erikhatcher has quit [Quit: erikhatcher]
elia has quit [Quit: Computer has gone to sleep.]
donV has joined #jruby
<nirvdrum> chrisseaton: This Rubinius.single_block_arg thing is an AST transformer but our AST doesn't have the info it needs. The runtime should have it. But if I can't access the uncaptured block args from pure Ruby, I need to mangle our block calling a bit.
kfpratt has joined #jruby
<chrisseaton> You could write a new method Truffle::Primitive::arguments that reads the senders arguments
baroquebobcat has joined #jruby
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<nirvdrum> Unless I'm missing something obvious, there aren't any. It looks like: each { Rubinius.single_block_arg } and that implicitly gets whatever's yielded to the block.
<nirvdrum> And as best as I can tell, we don't materialize yielded arguments if we don't need to.
iamjarvo has joined #jruby
e_dub has joined #jruby
<brixen> nirvdrum: that was introduced to deal with 1.8 and 1.9 block semantics in the same VM
<brixen> nirvdrum: it's probably possible to discard it now that we don't have a multi-version VM
<nirvdrum> brixen: That would certainly make things a lot easier :-)
skade has joined #jruby
<brixen> nirvdrum: I could also be wrong about that
<brixen> pretty sure at one point I found that MRI was special-casing the block destructuring semantics on *some* yields
<nirvdrum> brixen: The comments suggest that's what it's for. But a lot of Enumerable seems to be written expecting this method to return the extracted argument.
<brixen> anyway, PDI
<nirvdrum> PDI?
<brixen> heh please do investigate :)
<nirvdrum> Ahh.
skade has quit [Client Quit]
travis-ci has joined #jruby
<travis-ci> jruby/jruby (master:b3dacaa by Charles Oliver Nutter): The build has errored. (http://travis-ci.org/jruby/jruby/builds/46454507)
travis-ci has left #jruby [#jruby]
camlow32_ has joined #jruby
havenwood has joined #jruby
camlow325 has quit [Ping timeout: 252 seconds]
camlow32_ has quit [Remote host closed the connection]
brocktimus has quit [Ping timeout: 272 seconds]
rsim1 has joined #jruby
pietr0 has joined #jruby
rsim has quit [Ping timeout: 265 seconds]
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
subbu is now known as subbu|away
Hobogrammer has quit [Ping timeout: 245 seconds]
colinsurprenant has quit [Quit: colinsurprenant]
colinsurprenant has joined #jruby
benlovell has quit [Ping timeout: 244 seconds]
colinsurprenant has quit [Ping timeout: 245 seconds]
x1337807x has joined #jruby
vtunka has quit [Quit: Leaving]
pietr0 has quit [Quit: pietr0]
x1337807x has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
shellac has quit [Quit: Ex-Chat]
<JRubyGithub> [jruby] kares opened issue #2446: ConcurrentModificationException from ThreadGroup.list http://git.io/fGeS-g
JRubyGithub has joined #jruby
JRubyGithub has left #jruby [#jruby]
x1337807x has joined #jruby
x1337807x has quit [Max SendQ exceeded]
x1337807x has joined #jruby
x1337807x has quit [Max SendQ exceeded]
travis-ci has joined #jruby
<travis-ci> jruby/jruby (master:2a9e7a8 by Thomas E. Enebo): The build has errored. (http://travis-ci.org/jruby/jruby/builds/46457684)
travis-ci has left #jruby [#jruby]
dling has quit []
x1337807x has joined #jruby
<tarcieri> _____ ____ ___ ____ _ __ ___ _ _
<tarcieri> | ___| _ \|_ _| _ \ / \\ \ / / | | |
<tarcieri> | |_ | |_) || || | | |/ _ \\ V /| | | |
<tarcieri> | _| | _ < | || |_| / ___ \| | |_|_|_|
<tarcieri> |_| |_| \_\___|____/_/ \_\_| (_|_|_)
<tarcieri>
dfas has joined #jruby
dfas is now known as dling
x1337807x has quit [Remote host closed the connection]
x1337807x has joined #jruby
x1337807x has quit [Max SendQ exceeded]
x1337807x has joined #jruby
iamjarvo has joined #jruby
<headius> woohoo
x1337807x has quit [Ping timeout: 252 seconds]
subbu|away is now known as subbu
x1337807x has joined #jruby
camlow325 has joined #jruby
x1337807x has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
camlow325 has quit [Read error: Connection reset by peer]
camlow325 has joined #jruby
x1337807x has joined #jruby
nanoyak has joined #jruby
<Antiarc> So I have a process that is using the Stanford NLP libraries, and I periodically have things blow up with java.lang.OutOfMemoryError - is it valid to rescue this and eliminate references which I know to be holding a lot of heap?
<Antiarc> Or is that basically "nope, restart the process"
<Antiarc> (I'm allocating an awful lot of heap, but I think the libs have a memory leak somewhere that I have to address by throwing away and reallocating some stuff)
e_dub has quit [Quit: e_dub]
JRubyGithub has joined #jruby
<JRubyGithub> [jruby] headius pushed 2 new commits to master: http://git.io/mtoJGg
<JRubyGithub> jruby/master 3f74052 Charles Oliver Nutter: Elimiante duplicate closure loads.
<JRubyGithub> jruby/master 2f39f3e Charles Oliver Nutter: Only load implicit var for block arg if we have block arg....
JRubyGithub has left #jruby [#jruby]
<headius> subbu: so in making the reify_closure stuff smart I *had to* implement simplifyOperands, though the javadocs say I shouldn't have to
<subbu> yes, that is a bug.
<headius> we had %v_3 = load_implicit_closure; ... xxx = reify_closure(%v_3)
<subbu> docs
<subbu> i think ew use that same method for implementing variable renaming across the board.
<headius> v_3 got renamed to v_1 but without simplifyOperands I never updated
<subbu> and it happens during cloning/inlining/opt-tmp-vars pass/...
<headius> ok, so the optional part is incorrect?
<headius> that's a good answer to me
<subbu> yes, i think so, i was just asking enebo to verify my claim and update docs, etc.
<headius> ok
<headius> I am going to turn both closure loads into operands btw, and preparing them will just be copy
<enebo> well it is a bad answer to me in as much as the name implies it is optional
<headius> it will be less code because implicit doesn't have to be pre-loaded anymore
<enebo> we can rename
<subbu> rename method as wel.
rsim1 has quit [Quit: Leaving.]
<enebo> yeah ok
<enebo> what name? :)
<subbu> simplifyOperands.
<enebo> fixOperands
<subbu> oh .. you mean new name.
<subbu> no not fix.
<subbu> rewriteOperands perhaps
<subbu> it originally started as simplification for local opts.
<enebo> well I would like to fix it if that is reasonable since it would allow us to verify pre-simplify whether IR works
<subbu> but got repurposed for more things .. to rename vars during cloning, etc.
<subbu> so, the generic thing is it can replace operands with different ones .. or replaceOperands.
<subbu> rewrite/replace Operands seems better.
pietr0 has joined #jruby
<enebo> hmmm headius and I were talking and I wonder if I should do something more radical
<enebo> like make all operands live as primitive array in Instr
<subbu> and other thing to do is add docs about what to do when an instr is added/modified:
<subbu> getOperands/simplifyOperands/clone/cloneForInlining/interpreter/jit/persistence all need fixes/updates for that instr.
<enebo> This would make forgetting getOperands and simplifyOperands no longer be something which needs to get added for new instrs
<enebo> IT would make all accesses go through primitive array access
<subbu> but, simplification/replacement is instr dependent sometimes.
<enebo> but it would remove a whole bunch of analysis GC churn
<enebo> subbu: then we override those few places
<subbu> ok.
<enebo> subbu: but generally it is not right?
<enebo> not special
jmimi has joined #jruby
<enebo> I remember trying this before and not liking it
<enebo> but when I see opttempvars run it makes an amazing number of new lists/arrays
<enebo> and I bet all our passes do
<subbu> enebo, headius actually hold on ...
<subbu> there is a renameVars in in Instr already.
<enebo> heh
<enebo> yeah
<subbu> ah, but it calls simplifyOperands to rename its operands ;-)
<subbu> so, that is where that doc comment breaks down.
mitchellhenke has quit [Quit: Computer has gone to sleep.]
<enebo> subbu: of course it does not need to
<subbu> anyway .. yes, rename, move it up, as appropriate.
travis-ci has joined #jruby
<travis-ci> jruby/jruby (master:2f39f3e by Charles Oliver Nutter): The build has errored. (http://travis-ci.org/jruby/jruby/builds/46479074)
travis-ci has left #jruby [#jruby]
<enebo> subbu: we could impl renameVars through a different path if this is only reason the doc. breaks?
<enebo> I have no idea about tht though
mitchellhenke has joined #jruby
<subbu> you cannot without reimplementing simplifyOperands basically.
<subbu> so, rename to replaceOperands and fixing docs for starters is a good first step.
<subbu> and you can then refactor / raise to make sure new instrs that don't implement this fail right away.
<enebo> hmm
<enebo> renameVars could just make a getOperands[] loop and call rename on each operand?
<enebo> or is the concern there is extra knowledge is individul simplifyOperands not allowing some stuff to get renamed
<subbu> getSimplifiedOperand, yes .. but, that just kicks the can tooperands.
<enebo> yeah
<enebo> ok
<headius> ahhh that explains it then
<subbu> anyway, thi sis all from old memory .. take a look and fix as appropriate :)
<headius> then we should make it abstract in Instr
<headius> if there's anything all instrs need to implement
<enebo> headius: well I am wondering about just pushing all operands down to instr
<subbu> yes. simplifyOperands should have been fixed to be abstract/raise exc when renameVars was implemented.
<enebo> headius: then the default impl will be right nearly always and only overridden if the instr is special which is the uncommon case
<enebo> headius: This would reduce allocation quite a bit and remove needing to impl getOperands[] and a few other methods
<subbu> that is going to be a big refactoring. fyi. given # of instrs.
<enebo> headius: I swear we had this at one time
<enebo> subbu: yeah I am not sure it will be very complicated though
subbu is now known as subbu|lunch
<subbu|lunch> lunch time for me ..
<enebo> but it also implies we will always box contents of all instrs
<enebo> but we basically re-box multiple times per instr
<headius> enebo: I like pushing operands down and making instrs a lot smaller
<headius> I mean, if we assume getOperands is going to get called anyway, we're not saving an array
<enebo> headius: yeah I think I do as well but I can see some ugliness from it
<headius> and if there's no operands it will be a singleton empty array
<enebo> headius: yeah that is my main thing I want to solve with the change
<headius> I think it's a win
<enebo> the fact it can solve simplifyOperands and possibly a few other (toString is another)
erikhatcher has joined #jruby
<headius> I wish Java had modules... module ResultInstr
<headius> that would remove even more
<enebo> headius: ok well 2+ people think this is reasonable
<enebo> headius: I wish it had super efficient closures in Java 7
<headius> result impl stuff could move up to Instr too
<headius> most instrs have results
<headius> the ones that don't, don't implement ifc
<enebo> internalized iteration would be my preferred mechanism
<headius> that's for sure
<headius> 9k requires Java 8? :-D
<enebo> heh
<enebo> not sure if it would be as fast as dealing with primitive lists and walking
<enebo> Even if we made the lists
<headius> I'm going to do the operand flip
<enebo> What?
<headius> for closure loads
<headius> so I will be multiplexing attention :-)
<enebo> ok I will take a quick stab at operand[] ni instr
<headius> then I will go back to bug triage a bit
<enebo> I don’t think this will take more than a couple of hours?
<headius> oh enebo I filed a bug for preview release
<headius> to start gathering notes, tasks, etc
<enebo> yeah for non-issue related tasks right
<headius> right
<headius> issue-related if they're things we're going to say aren't done
<enebo> yeah
e_dub has joined #jruby
kfpratt has quit []
<headius> enebo: there's a lot of overridden methods we could eliminate with some type checks or flags
<headius> like a ton of operands override the same four or five methods the same way
<enebo> yeah my first pass will just remove without using flags
<headius> can copy propagate = yes, clone for inlining = this, etc
<headius> it would be slick to get all operands and instrs down to just the meat
<enebo> I don’t like flags if they make it difficult to read intent of an indiviual instr
<headius> oh hahah I remember now why they're instrs!!!
<enebo> but yeah perhaps we will end up with some tiny declarative def for many
<headius> Operand#retrieve does not receive the passed block
<headius> neither does Instr#interpret though
<headius> I had to make the instrs special cases in interpreter as a result
<headius> so I will have to do the same for operand
<enebo> headius: yeah you can add if you need it
<headius> I'm considering it
<headius> touches a lot of code
<enebo> headius: another lesser option is to just add to retrieve and then just impl the instr in Interpreter.java
<enebo> headius: long term not what we want but 2-3 other recv instrs are that way now
<enebo> headius: since they also do not get the args they need
<headius> yeah, that's the other option
<headius> I will do that for initial commit and then look at retrieve fixity
<headius> bleh yeah
<headius> PassedBlock operand would be five lines of code if I didn't have to impl the other methods
Felystirra has joined #jruby
x1337807x has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
x1337807x has joined #jruby
jrgarcia has joined #jruby
mitchellhenke has quit [Quit: Computer has gone to sleep.]
yfeldblum has joined #jruby
multibot_ has quit [Remote host closed the connection]
Felystirra has quit []
multibot_ has joined #jruby
mitchellhenke has joined #jruby
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
iamjarvo has joined #jruby
iamjarvo has quit [Max SendQ exceeded]
<headius> enebo: I'm just going to add block
<headius> erg
<headius> but I'll have to add it to interpret too
iamjarvo has joined #jruby
<headius> shite
subbu|lunch is now known as subbu
<enebo> heh
<headius> crap this ends up forcing block to be passed in hundreds of places
<headius> anywhere that would run an instruction or operand
<headius> enebo: I can't make this an operand without doing that
<headius> there's just no way
<enebo> headius: yeah IDE can do it though
<subbu> i haven't followed this .. but what are you doing with block?
<headius> right, but I have to fix all the callers and make sure they're passing the right block in
<headius> subbu: Instr#interpret and Operand#receive need to take current scope's incoming block or I can't make PassedBlock an operand
<subbu> what is PassedBlock? ;)
<headius> Operand#retrieve is called within CallBase downstream from interpret, far away from the block passed in
<headius> PassedBlock = LoadImplicitClosure
<headius> as an operand
<subbu> ah, ok. instead of from frame?
<headius> right
<subbu> so that you can remove it, you mean?
<subbu> got it.
nanoyak has quit [Quit: Computer has gone to sleep.]
<headius> enebo: I'm not going to make this change on top of yours, it will be an enormous nightmare to merge
<headius> literally hundreds of changes
<enebo> headius: hmm that is a good point
<enebo> Although I wonder how bad it will merge
<headius> I have the operands working except for zsuper
<headius> it needs to evaluate PassedBlock operand and can't
<enebo> it will be retrieve and interpret methods getting a new param and their callers
<headius> right
<headius> the callers is the bigger hit
<headius> that causes it to propagate through utility methods all over the interpreter
<headius> there is an alternative
<headius> I could restore the temp var
<enebo> use temp vars? :)
<headius> right
<headius> but it may end up optimizing back to direct access?
<headius> %v_1 = passed_block ... unresolved_super(... %v_1)
<enebo> It does solve it and it probably will get propagated like I showed you earlier when I did that one copy
<headius> could that turn back into passed_block as a direct operand?
<enebo> So long as def is copy and single use local opt pass willl just move it to where it should be
<enebo> subbu: ^ correct?
<headius> then it will break again
<headius> because it will attempt to call retrieve
<enebo> hah
<subbu> within the same basic block, yes.
x1337807x has quit [Ping timeout: 244 seconds]
<enebo> headius: yeah you are back to instr as the fix then
<enebo> headius: perhaps we are polishing the diamond at this point. We could open up an issue to move this to an operand later
<headius> it isn't going to change behavior any
<headius> I can box up the patch I have thusfar and open an issue
<enebo> headius: for interp I really would like all values to interpret’able and retrieve’able but it is a huge amount of lines changes
<enebo> headius: So each time I work towards it I stop and think it is too big a change for the purity of interpret/retrieve
<enebo> headius: but if we do push all values neccesary to make interpret and retriev perhaps that is the point to retry this?
rcvalle has quit [Quit: rcvalle]
skade has joined #jruby
erikhatcher_ has joined #jruby
jrgarcia has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
rsim has joined #jruby
jmimi has quit [Ping timeout: 245 seconds]
JRubyGithub has joined #jruby
<JRubyGithub> [jruby] headius opened issue #2447: Switch closure-loading instructions to be operands http://git.io/jWTxRg
JRubyGithub has left #jruby [#jruby]
cultureulterio-1 has joined #jruby
erikhatcher has quit [Read error: Connection reset by peer]
erikhatcher_ is now known as erikhatcher
cultureulterior1 has quit [Ping timeout: 240 seconds]
<headius> enebo: yeah I agree with the pattern
<headius> so we'll leave them instrs for now
<headius> I'm going to do one more profiling pass for yield and see what's left to make it as fast as 1.7
<enebo> Man doing some refactorings makes you realize how poorly Java fares by not having class methods
jmimi has joined #jruby
<headius> yeah
<headius> and modules
<headius> or traits
<enebo> return object == null ? new Operand[] {startingScope} : new Operand[] {startingScope, object};
<enebo> This stuff is lultastic too
jrgarcia has joined #jruby
benlovell has joined #jruby
elia has joined #jruby
<headius> yeah ick :-(
eroot has joined #jruby
<headius> I didn't want another null check, which is why I introduced NullBlock operand
eroot is now known as Aethenelle
<headius> if we need Block.NULL anywhere, you should use it
Aethenelle is now known as Athenelle
benlovell has quit [Ping timeout: 252 seconds]
nanoyak has joined #jruby
x1337807x has joined #jruby
x1337807x has quit [Max SendQ exceeded]
x1337807x has joined #jruby
x1337807x has quit [Max SendQ exceeded]
x1337807x has joined #jruby
Aethenelle has joined #jruby
Aethenelle has quit [Client Quit]
skade has quit [Quit: Computer has gone to sleep.]
Athenelle is now known as Aethenelle
jrgarcia has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
benlovell has joined #jruby
havenwood has quit [Remote host closed the connection]
benlovell has quit [Ping timeout: 244 seconds]
x1337807x has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
e_dub has quit [Quit: e_dub]
bbrowning is now known as bbrowning_away
x1337807x has joined #jruby
x1337807x has quit [Max SendQ exceeded]
x1337807x has joined #jruby
x1337807x has quit [Max SendQ exceeded]
x1337807x has joined #jruby
nanoyak has quit [Quit: Computer has gone to sleep.]
rsim has quit [Quit: Leaving.]
mrmargolis has quit [Remote host closed the connection]
rsim has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub> [jruby] headius pushed 1 new commit to master: http://git.io/GBEKBA
<JRubyGithub> jruby/master 7e01a86 Charles Oliver Nutter: No need to preserve BacktraceElement object in Binding....
JRubyGithub has left #jruby [#jruby]
elia has quit [Quit: Computer has gone to sleep.]
<subbu> headius, enebo i am here for another week before i take off again .. to sf for 2 weeks.
<subbu> in case any f2f meeting is required for preview/final.
<enebo> subbu: I would like to meet next week (hell this last week, but it was so cold out)
<subbu> once in sf ... i'll get sucked into wmf work, meetings, etc. so, will not be as responsive.
<subbu> except some nights and evenings.
jrgarcia has joined #jruby
<subbu> ok .. tuesday past 2:30 pm or thursday afternoon or friday anything will work.
jrgarcia has quit [Client Quit]
<subbu> monday and wednesday are code deploy afternoons 3pm cst .. but, i coul dmeet in the mornings those days.
<enebo> ok well I talk to you daily so I will ping you unless the three of us want to meet together and then we should pick day/time
<subbu> k
<subbu> but, since I work out of coffee shops most afternoons, i can come hangout and do my work and chit-chat jruby stuff in between most days independent of focused discussion involving all of us .. that requires picking a time so i can keep that slot clear.
<headius> I can meet almost any day
<headius> supposed to be warmer next week
<headius> hmm
<headius> that might be all I can squeeze out of yield until we start inlining through blocks
elfuego has quit [Quit: elfuego]
<subbu> oops, i have a call 3:30 pm tuesday aft. so, scratch that. tue morning will work however.
<headius> tue morning is the only time I can't meet :-)
<subbu> ok, mon morning (10am-2pm), wed morning (10 am -2pm), thursday anytime, friday anytime.
elia has joined #jruby
<headius> hmm
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
iamjarvo has joined #jruby
iamjarvo has quit [Ping timeout: 256 seconds]
baroquebobcat has quit [Quit: baroquebobcat]
camlow32_ has joined #jruby
tcrawley is now known as tcrawley-away
camlow32_ has quit [Remote host closed the connection]
JohnBat26 has quit [Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/]
camlow325 has quit [Ping timeout: 255 seconds]
elia has quit [Quit: Computer has gone to sleep.]
skade has joined #jruby
mitchellhenke has quit [Quit: Computer has gone to sleep.]
elia has joined #jruby
mitchellhenke has joined #jruby
kares has quit [Quit: Ex-Chat]
elia has quit [Client Quit]
travis-ci has joined #jruby
travis-ci has left #jruby [#jruby]
<travis-ci> jruby/jruby (master:7e01a86 by Charles Oliver Nutter): The build passed. (http://travis-ci.org/jruby/jruby/builds/46498403)
elia has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub> [jruby] chrisseaton pushed 1 new commit to master: http://git.io/AlUwdg
<JRubyGithub> jruby/master bb62232 Chris Seaton: Revert "[Truffle] Use declarative guards for checking classes in the IC."...
JRubyGithub has left #jruby [#jruby]
x1337807x has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
dfas has joined #jruby
dling has quit [Ping timeout: 240 seconds]
elfuego has joined #jruby
skade has quit [Quit: Textual IRC Client: www.textualapp.com]
baroquebobcat has joined #jruby
dling has joined #jruby
mitchellhenke has quit [Quit: Computer has gone to sleep.]
dfas has quit [Ping timeout: 264 seconds]
mitchellhenke has joined #jruby
x1337807x has joined #jruby
e_dub has joined #jruby
rsim has quit [Quit: Leaving.]
metadave has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
nanoyak has joined #jruby
havenwood has joined #jruby
erikhatcher has quit [Quit: erikhatcher]
mitchellhenke has quit [Quit: Computer has gone to sleep.]
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
camlow325 has joined #jruby
mitchell_ has joined #jruby
mitchell_ has quit [Client Quit]
mitchellhenke has joined #jruby
mitchellhenke has quit [Client Quit]
zeroecco has joined #jruby
yfeldblu_ has joined #jruby
yfeldblum has quit [Ping timeout: 244 seconds]
baroquebobcat has quit [Quit: baroquebobcat]
mitchellhenke has joined #jruby
e_dub has quit [Quit: e_dub]
mitchellhenke has quit [Client Quit]
<enebo> ok done for tonight but my operands patch seems to be working
<enebo> I need to fix debug output from the change and look at call instr memory overhead since I increased memory usage
<enebo> 5800 lines!
<subbu> ide ftw.
<enebo> I wish
<nirvdrum> enebo: How's memory looking in general now?
<enebo> I could not automate any of it
<enebo> nirvdrum: well I have just been using Rails console of an empty app
<nirvdrum> enebo: When I ran mogotest through it a few weeks ago, permgen was a sticking point.
<enebo> nirvdrum: For interp we are about 108M vs ~58M in interp in 1.7
<nirvdrum> Ahh.
<enebo> It was like 184M a few weeks ago
<nirvdrum> Wow.
<nirvdrum> Bigger objects? Or have allocations shot up too?
<enebo> and I have not started doing icky things like removing LVA data
<enebo> I think instrs vs ast nodes is a not a huge difference but once you add in CFG, LVA and some other data it makes IR heavier
<enebo> nirvdrum: we can get 6-7% back immediately if we stop cloning every instr when we start to interp
<nirvdrum> Then do that! ;-)
<enebo> nirvdrum: I have been working towards that going away. That should get us close to 100M
<enebo> or more maybe
<nirvdrum> Nice.
<nirvdrum> Well, that's a pretty steady reduction over the past month.
<enebo> nirvdrum: yeah I think we can get that down more so I am not overly concerned…just concerned :)
<enebo> gotta log
enebo has quit [Quit: enebo]
elia has quit [Read error: Connection reset by peer]
elia has joined #jruby
x1337807x has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
_elia has joined #jruby
erikhatcher has joined #jruby
elia has quit [Ping timeout: 264 seconds]
x1337807x has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub> [jruby] headius pushed 1 new commit to master: http://git.io/2Yj1jA
<JRubyGithub> jruby/master 2dd881b Charles Oliver Nutter: Do not allocate "TZ" string for every new Time object.
JRubyGithub has left #jruby [#jruby]
yfeldblu_ has quit [Remote host closed the connection]
yfeldblum has joined #jruby
diegovio1 has joined #jruby
diegoviola has quit [Ping timeout: 255 seconds]
diegovio1 is now known as diegoviola
subbu has quit [Ping timeout: 265 seconds]
imperator has joined #jruby
brocktimus has joined #jruby
brocktimus has quit [Client Quit]
brocktimus has joined #jruby
zeroecco has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]