<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....
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
<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 :)
<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>
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
<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
<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>
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>
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.
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.
<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 :-)