<nirvdrum>
I was getting started around 7:30, but given the freezing temp. and my Quixotic quest to lose weight, I'm starting a bit later these days.
pgokeeffe has joined #jruby
mrmargolis has joined #jruby
benlovell has joined #jruby
shellac has joined #jruby
<headius>
my start varies between 8AM and 10AM depending on whether I or the missus get our eldest off to school
thsig has quit [Ping timeout: 244 seconds]
<nirvdrum>
I like getting my day going earlier. But also, chrisseaton is 5 hours ahead of me and eregon is 6 hours ahead, so starting earlier means more overlap with them.
skade has quit [Remote host closed the connection]
pgokeeffe has quit [Quit: pgokeeffe]
<benlovell>
i'm looking into what it takes to get jruby and rbx included
donV has quit [Quit: donV]
skade has joined #jruby
<nirvdrum>
brocktimus: I envy whatever your weather is right now.
skade has quit [Remote host closed the connection]
<Aethenelle>
i'm not sure anyone in EST gets to complain about temps unless they grow crops
<brocktimus>
nirvdrum: 44C on monday was not fun. But the rest of the week has been awesome at ~30C max.
<headius>
benlovell: hey neat
<nirvdrum>
Aethenelle: Where are you? Chicago/
<Aethenelle>
right now it's a balmy -6F
<Aethenelle>
yes
<headius>
brocktimus: where are you?
<headius>
in AU
<brocktimus>
headius: Perth
<brocktimus>
most isolated capital city in the world!
<brocktimus>
4 hours flight to another city
<headius>
Ahh neato, I haven't been there yet
<brocktimus>
we have a lot of space
<headius>
toyed with the idea of doing RailsCamp Perth but it's a long trip
<nirvdrum>
We're a bit north of that. It was 4F minus windchill this morning. But it's always windy so that's a virtually useless value.
<Aethenelle>
of course someone from canada or MN is going to chime in and call me a wuss...
<brocktimus>
Are you heading to Red Dot Ruby this year?
vtunka has quit [Ping timeout: 240 seconds]
<nirvdrum>
The northeast is a far cry from Florida.
<brocktimus>
I want to go to a Ruby conf this year, but all are quite far away and RubyConfAU is already sold out
<Aethenelle>
nirvdrum: that -6 isn't windchill... windchill's like -25 or -30
<headius>
Aethenelle: Hmm, it's above 0 here since I got up today
<headius>
but I heard there's warmer weather coming in...we were awful earlier this week so you have that now
<headius>
some of the schools were out Monday because of that -30WC
<Aethenelle>
headius: you in MN?
<headius>
yeah, in the shadow of Minneapolis
<nirvdrum>
Aethenelle: Once a year or so we get some crazy wind effect coming down from Montreal and everyone wants to die.
<Aethenelle>
yeah, we were closed yesterday and today
<brocktimus>
If those temperatures are all farenheit thats crazy, also I can't spell that word
skade has joined #jruby
<Aethenelle>
also have license to WFH tomorrow
<Aethenelle>
dunno yet about schools tomorrow
<headius>
brocktimus: -10 to -15C I think
<headius>
my head conversion isn't very good
<brocktimus>
-6F => -20C or so google said
<headius>
ok, even worse
<brocktimus>
20C here right now ;-)
<Aethenelle>
those windchills are low enough it doesn't matter F or C really
<headius>
yeah :-)
<headius>
brocktimus: you Aussies know you're spoiled for weather
<brocktimus>
those windchills are nearly at the best temperature, -32
<headius>
that's the price you pay to live on the edges of a giant desert
<brocktimus>
Yeah, we just get the brutal summers fairly regularly
<brocktimus>
I spent a christmas in Germany, my family had a week of >40C
<brocktimus>
"Oh australia its so warm!" "You have no idea what warm is!"
<headius>
summers stay pretty mild here
<Aethenelle>
yes but it's dry isn't it?
<headius>
unusual to get above 35C
<brocktimus>
its not tropical humid by any means if thats what youre asking, but at those temperatures you just can't do things
<Aethenelle>
we get 40c at 80% or so humidity
<brocktimus>
YURGH
<brocktimus>
otherwise known as a spa...?
<nirvdrum>
Aethenelle: Sounds like Boston area weather isn't far off.
<headius>
I think Chicago gets hotter because it's more concrete and further south
<nirvdrum>
The humidity on the eastern seaboard sucks.
<Aethenelle>
i've been in arizona in summer before 110F isn't too bad if it's not that humid
<headius>
my area is definitely a heat island...you can see weather go around the cities
<nirvdrum>
But, I don't have to worry much about earthquakes, tornadoes, or even hurricanes (they get up here, but usually weaken a fair bit by then).
<chrisseaton>
everyone complains about British weather being cold and damp, but I love the winy, rainy welsh mountains near me, feels wild and free
<Aethenelle>
headius: mostly it's the further south... the lake does help moderate things a bit
<brocktimus>
chrisseaton: you're welsh!?
<chrisseaton>
after living in CA for six months, I was ready for some storms
<headius>
brocktimus: I've been along east coast... M/S/B
<chrisseaton>
brocktimus: I live in Cheshire, near north wales, only about an hour from Snowdonia
<brocktimus>
headius: yeah if someone is coming to AU its what I'd assume they'd do
<nirvdrum>
headius: M/S/B?
<headius>
chrisseaton: I couldn't live in the bay area
<brocktimus>
Melbourne + Sydney + Brisbane
<chrisseaton>
brocktimus: I can get to the Black Mountains for a long weekend as well
<nirvdrum>
Oh.
erikhatcher has quit [Ping timeout: 240 seconds]
<nirvdrum>
I missed he meant Australia.
<nirvdrum>
I'd like to visit, but I'd probably murder someone on a flight that long.
<headius>
chrisseaton: You notice nobody in the bay area spends any time outside...they're bored with it
<headius>
Sun had these beautiful campuses with inner courtyards, and nobody ever went out there
<headius>
neatly groomed gardens, fountains, shade trees and bushes...like a ghost town
<Aethenelle>
headius: it was kind of funny last time i was there... ~60f ... local kids were practically in parkas... mine didn't have coats on ... kinda surprised we didn't get funny looks
<headius>
Aethenelle: yeah, it's true what they say about getting soft there
thsig has joined #jruby
<brocktimus>
Urgh, flying places is so expensive
<brocktimus>
Was just thinking about trying to head to any confs
erikhatcher has joined #jruby
<brocktimus>
How did you all find RubyConf2014?
vtunka has joined #jruby
<brocktimus>
I watched headius + chrisseaton talks
<headius>
brocktimus: it was fun, but it has started to feel a little big
<headius>
last year was in a hotel so most people stayed there...that helps it feel more cozy
<headius>
when it's in a separate conference center most people leave after the conf to go to dinner, etc, and never come back (or can't come back)
<brocktimus>
Any updates on the MRI testing / rubyspec maintenance / migration front?
<Aethenelle>
i can now say solaris 11 is a definite improvement over 10...
skade has quit [Remote host closed the connection]
<headius>
brocktimus: not much to report yet
enebo has joined #jruby
<brocktimus>
OK I'm going to go crash, night all
<headius>
brocktimus: goodnight!
noop has quit [Ping timeout: 256 seconds]
<chrisseaton>
I think it could have benefited from all the day's speakers having a 1 minute pitch on stage after the keynote
<chrisseaton>
We often do that at academic conferences - helps makes sense of all the abstracts
colinsurprenant has joined #jruby
vtunka has quit [Ping timeout: 264 seconds]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] headius opened issue #2442: yield is slower than MRI in 9k http://git.io/w-2QQw
JRubyGithub has left #jruby [#jruby]
<headius>
chrisseaton: that's a really good idea
<headius>
though with three tracks of talks maybe that's too many
skade has joined #jruby
mitchellhenke has joined #jruby
vtunka has joined #jruby
subbu is now known as subbu|afk
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] eregon pushed 5 new commits to master: http://git.io/xXn8_A
<JRubyGithub>
jruby/master 09af835 Benoit Daloze: [Truffle] Check visibility only in AddMethodNode, not in MethodDefinitionNode....
<JRubyGithub>
jruby/master 4182c8c Benoit Daloze: [Truffle] Prefer SetMethodDeclarationContext to SetFrameVisibilityNode....
<treehau55>
I have an issue where I am using an imported Java lib in jruby that has certain methods available to me when developing, but then when I package it into a jar with warbler, the methods seemingly dont exist anymore. Is this an artifact of jruby or warbler? For example, I am using guava's hash multimap. If i insspect the object by asking it its methods it states entry_iterator is one of them, but when I package the jar, and run the
benlovell has quit [Read error: Connection reset by peer]
elia has quit [Ping timeout: 252 seconds]
benlovell has joined #jruby
<dfr|work>
treehau55, maaaybe something else in warble has an older version of guava?
<dfr|work>
treehau55, if you include different jar versions of same library, depending what's earlier in classpath will get loaded first.
<treehau55>
dfr|work: thats a good thing to look at, I overlooked that because our mvn clean package updates the classpath then warbles
<treehau55>
dfr|work: they match -- guava 17 is packaged in the jar
<treehau55>
thats the same version I am using
yfeldblum has joined #jruby
<treehau55>
entry_iterator is not some sort of convience method that jruby adds? I don't know what to think at this point
<dfr|work>
treehau55, can you gist the code that fails as well as failure message?
<dfr|work>
[the ruby code]
<headius>
it sounds like you may not have the object in hand you expect to
<headius>
when running in warbler
<headius>
or the library otherwise doesn't load right
_elia has quit [Read error: Connection reset by peer]
<treehau55>
headius: I check the type, I am guessing the latter
<treehau55>
as you see in this example, I was trying the camel cased version of the method, entryIterator -- I tried both entry_iterator as well as entryIterator
<treehau55>
but res.methods does not print entryIterator as an available method (in jar land, not development)
<dfr|work>
treehau55, what kind of object does res.get_non_ldap_tokens return?
thsig_ has joined #jruby
<treehau55>
HashMultimap
thsig has quit [Read error: Connection reset by peer]
thsig has joined #jruby
<headius>
treehau55: what does puts obj.class.java_class display?
<headius>
do some inspection of the class and prove it at least claims to be the right one
benlovell has quit [Read error: Connection reset by peer]
benlovell has joined #jruby
thsig_ has quit [Ping timeout: 245 seconds]
<headius>
subbu: I'm working on a perf bug relating to block yield and proc call
<headius>
the first part of fixing it was in the JIT, but the next part is an IR change I need to talk through
<JRubyGithub>
jruby/master 70086fa Benoit Daloze: [Truffle] JT: Allow arbitrary extra args for MSpec....
JRubyGithub has left #jruby [#jruby]
skade has quit [Quit: Computer has gone to sleep.]
<subbu>
headius, ok .. done skimming the issue and comments.
<headius>
so
<headius>
recv_closure always creates a Proc
<headius>
and that's the last mile for exceeding 1.7 perf for yielding to a literal block
<headius>
it does so because it stores it in the dynamic scope in the interpreter
<headius>
rather than in a temporary
<headius>
I believe it should go in a temporary unless it is explicitly captured
<headius>
like any other var
<subbu>
i see .. because dynamic scope can only store IRubyObject?
<headius>
right
<subbu>
I thought you had a patch at one point where you changed that in DynamicScope?
<subbu>
iirc, for just this thing?
<subbu>
maybe you backed it out becuase it broke 1.7?
<headius>
yeah, it's not there...I thought I dreamed doing that
<subbu>
i think yo uhad it but it broke 1.7since you had done this before the 9k branch off.
<headius>
that's possible
<treehau55>
headius: the output is com.google.common.collect.HashMultimap, I am fairly certain it is the correct class
<headius>
either way this would still need IR changes, because it we store a Block in there and consuming code still needs a Proc, we're in the same boat
<treehau55>
or object
<subbu>
headius, sure.
<headius>
I'm not sure whether recv_closure results ever *have to* be a proc though, other than to appease typing
<headius>
they're not easily trackable because it's part of preamble code in a method
<subbu>
i vaguely remember that the reason I introduced recv_closure in all cases (independent of whether there was an explicit &blk or not) was to surface the implicit block for yield explicitly in case it was useful for something else.
vtunka has quit [Quit: Leaving]
<subbu>
at that time, i focused on getting all implicit info. into explicit form.
<headius>
right, and I think that's ok
<subbu>
so, the implicit block need not be converted to a proc
<headius>
it folds away in dce if we don't use it, I'm pretty sure
<subbu>
but the explicit one should be to comply with ruby semantics.
<subbu>
so perhaps all it needs is a instruction-split or a flag in recv_closure.
<headius>
ok, then I'll approach it that way for now...change it to block and do some hackery to see if that is acceptable to other code
<subbu>
enebo might have an opinion on that as well.
<subbu>
s/on/about
<headius>
if this really only needs to be a block once we're in JIT, then I may be able to just use it as a block
<headius>
otherwise we'll need a way to stick it in the scope
<headius>
or more complex changes to lazily reify it only if captured
<subbu>
i think implicit blocks that only get used by yield/super need not be procs.
<headius>
the cases I expect to fail are def foo; 1.times { yield }; end
<subbu>
but explicit blocks will be.
<headius>
right
<headius>
&b and such
<headius>
that much I'd expect
<subbu>
and for the 1.times { yield }; end yes, you won't be able to get away with a tmp.
<headius>
with my first fix, at least, Proc#call form is as fast as 1.7
<headius>
subbu: so going down that path a bit... if I did go the tmp route, I'd need to add logic to AddLoadStore to reify the closure into the scope?
<subbu>
so, one option is to ignore the explicit recv_closure for implicit blocks and continue to fetch block from the stack as you've continued to do since that continues to be pushed onto the stack .. but, i am not convinced that is a good solution since we might be able to eliminate the push onto stack for blocks in the longer term.
<headius>
I could certainyl implement yield that way
<subbu>
if you implemented yield that way, the problem completely goes away.
<headius>
hmm
<subbu>
you just get rid of the implicit recv_closure instr. in IR Builder .. and fix the interp too.
<headius>
that requires hacky bits though since right now yield just receives the var result of recv_closure
<headius>
do you mean implement yield like that everywhere?
<subbu>
yes. which is how it was in ast interp/1.7
<headius>
oh, can't everywhere because of closure case
<headius>
hmm
<headius>
1.7 stored block on Frame
<subbu>
which it is even now.
<headius>
ok
<subbu>
that hasn't gone away unless i have forgotten the code ..
<headius>
so if I make yield have implicit argument from frame, recv_closure should dce away and we're good
<subbu>
as for add-store-logic .. no, it doesn't need any change.
<subbu>
headius, yes.
<headius>
ok
<subbu>
as long as you remove the operand from yield, it will dce away.
<subbu>
that is an ir builder fix.
<enebo>
So I was out putting antifreeze in my car :)
<enebo>
recv_closure should not be unconditionally creating a proc is one fact everyone agrees on
<enebo>
getting from frame is a simple fix instead of special var but I think longterm that is not what we want
<enebo>
so if we do that now we need to make sure we circle back around to handling this properly
pchalupa has joined #jruby
<subbu>
i think we can go with the simple fix for now since it is minimally invasive.
<subbu>
and gets all the perf back for yields.
<enebo>
subbu: we can no-op recv_closure in interp + JIT but leave it too for analysis
mje113__ has joined #jruby
<subbu>
you cannot no-op unconditionally .. since you still have the &blk form .. unless the vars are different in the implicit/explicit scenarios.
<enebo>
any %block usage is just frame retrival
<enebo>
subbu: yeah although I wonder why in explicit we don’t use blk and for implicit we use %block?
<subbu>
it is amazing how many of the details are now fuzzy in my mind ... i used to know these originally IR details a bit more clearly at one point.
<enebo>
Or perhaps if explicit we don’t use %block at all
benlovell has quit [Ping timeout: 264 seconds]
<subbu>
but, i can run tests to see what IR is generated.
<enebo>
unless %block is used like a flag
<subbu>
we might be using a non-%block var for explicit since it is present in ruby source.
<enebo>
headius: interestingly enough you complained about this like 7-8 months ago as well
<enebo>
headius: I think we all forgot about it
<enebo>
(making a proc all the time)
<headius>
I remember it but I forgot we never fixed it :-)
<headius>
and I didn't understand IR as well then to remember why we were doing it
<enebo>
subbu: so you yuou have def foo(&b); yield; end; should yield instr be yield &b?
<headius>
would you both prefer I just modify YieldInstr structure rather than creating an operand for the frame block?
<headius>
it doesn't matter to me either way
<enebo>
headius: This is one of those few concepts where I think it worked around special var not allowing non-IRubyObject
<headius>
yeah
<subbu>
blk(0:0) = recv_closure; for the explicit case and %block(0:0) = recv_closure for the implicit case
<enebo>
subbu: yeah blackPassnode should be enough in IRBuilder to know this
<subbu>
headius, yes, go with fetching the block from the frame for now (and remove/suppress the operand from YieldInstr)
<headius>
on my way
<enebo>
subbu: but it may be easier to add a flag to scope
<subbu>
or even pass a Undefined/Nil in IRBuilder
<subbu>
so, the operand is around as is in Yield and we can revive it later easily.
colinsurprenant has quit [Quit: colinsurprenant]
<subbu>
enebo, headius did make a change to dynamic scope to accept non-IRubyObject but backe dout because it broke 1.7 code iirc.
<enebo>
subbu: is there significance to recv_closure as an instr if it is explicit?
<headius>
it's used to create a heap-storable closure object
<headius>
a Proc
<subbu>
yes. what headius said
<headius>
that's the remaining significance
<headius>
it really should be reify_closure in that case
<headius>
because receiving it is done implicitly via call stack or artificial frame
<headius>
(which is also a call stack)
<subbu>
ya, maybe we need 2 separate instrs for the 2 cases.
<headius>
mmm
<enebo>
should a blockpass unconditionally convert to a proc if not used?
<subbu>
recv_implicit_block; reify_closure ..
<enebo>
(this is really a question of whether it is semantically important or an impl detail
<headius>
hmm
<headius>
I don't believe there's any visibility into the reification of a block
<headius>
no Ruby-visible side effects I mean
<enebo>
I mean if no yield and block_pass then I see no reason it cannot be DCE’d and I think we do but it made me wonder
<headius>
there's some binding cloning and object construction, that's about it
<subbu>
yield always uses result of recv_implicit_block as far as i can tell.
<subbu>
reified closure just becomes a normal object passed around
<enebo>
subbu: but if you do not use that variable then you do not need to reify?
<subbu>
but, becuase of def foo; 1.times { yield }; end .. you still have the problem of having to record the block in a dyn-scope for that yield there.
<enebo>
I guess since to_proc can be called on arbitrary objects it must be done
<enebo>
unless it is in fact already the correct type
<subbu>
or maybe not actually .. the { yield } also has a recv_implicit_block instr.
<headius>
it shouldn't need to become a proc except when there's a block pass argument
<headius>
for any case
<enebo>
headius: yeah I am asking about that case specifically
<headius>
I mean, physically, it doesn't need to...runtime plumbing may force it right now
<subbu>
ok, so, if you split the current recv_closure into recv_implicit_block and reify_closure .. that will take care of it as well.
<headius>
Proc == block behaviorally and sideffectly
<enebo>
headius: for implicit I am less sure it matters but implicit has no to_proc behavior
<subbu>
since we are still passing blocks into scopes via frame stack.
<headius>
if there's an explicit block pass argument that's referenced, then we need it
<headius>
referenced or captured
<subbu>
headius, but for that there is a variable in ruby code.
<enebo>
headius: I just meant declared but not consumed
<subbu>
and a reify_closure instr.
<headius>
subbu: right
<subbu>
enebo, in that case, dce will kill it.
erikhatcher has quit [Quit: erikhatcher]
<enebo>
subbu: ok but do we to_proc before we enter the method?
<headius>
I think we all agree the def foo(&b) case should be a reify_closure with a dce-able variable
<subbu>
enebo, no.
<enebo>
subbu: so it to_proc has a side-effect and we DCE it then it won’t happen
<subbu>
it is done in the current recv_closure instr and to be changed reify_closure instr.
<headius>
the implicit case could either have an implicit_closure that loads from frame or nothing at all, since you can only access implicit closure via yield anyway (Proc.new notwithstanding)
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] chrisseaton pushed 11 new commits to master: http://git.io/nyKfpg
<JRubyGithub>
jruby/master a18c46a Chris Seaton: [Truffle] Some work on bad hashes.
<JRubyGithub>
jruby/master eeb8846 Chris Seaton: [Truffle] The RubyException within a RaiseException needs to be transient.
<JRubyGithub>
jruby/master 8d79092 Chris Seaton: [Truffle] Ignore findbugs System.exit() warnings.
JRubyGithub has left #jruby [#jruby]
<subbu>
right implicit case always loads from frame.
<headius>
and Proc.new is just stupid and should be removed
colinsurprenant has joined #jruby
<subbu>
in future, it might be picked up from the incoming block from calls (and the frame push can be removed)
<enebo>
headius: we may cheat on that one in IRBuilder
<subbu>
what is the problme with proc.new here?
<enebo>
subbu: just not statically detectable
<enebo>
Proc.new will use implicit block to create a proc instance
<subbu>
no, that is fine .. but, i mean .. how does proc.new affect the discussion.
<subbu>
oh .. i see.
<enebo>
I don’t know :) I am still not sure why we need two instrs at this point
<enebo>
one to make a real proc I get
<headius>
Proc.new or MyStupidClassThatExtendsProc.new
<enebo>
one to say we may be dealing with a block but we don’t want to make it a proc until later?
<headius>
we don't support the latter because it's an ugly impl artifact from 1.8 and prior
<subbu>
enebo, well, you can do with the current recv_closure instr. by examining the result variable as well .. or split into 2 instrs ..
<enebo>
Line 1002 of IRBuilder has us cheat detect Proc.new case
<subbu>
I imagine Proc.new implementation anyways looks at the frame to fetch the block?
<subbu>
this becomes an issue only if we start trying to eliminate the push of block onto a frame.
<headius>
subbu: that's exactly what it does
<subbu>
and used for computeRequiresCallersFrameFlag
<enebo>
I would think whether %block contains a Block or a RubyProc would perhaps be enough
<enebo>
but that means changing DynScope to accept Object
<subbu>
ok, so the ir-builder hack is to make sure we don't remove the frame.
<headius>
in MRI it just happened to be there because the current frame was just a bunch of globals, and with no block passed in the value still pointed at the previous call's block
<subbu>
enebo, another advantage of 2 instrs is that recv_implicit_block can write to a tmp
<headius>
their frame was more like store/load of register values
<headius>
call protocol
<subbu>
and reify_closure can write to a local as required.
<headius>
that's looking better with implicit yield
<subbu>
anyway, (a) implicit yield now (b) later, split recv_closure into 2 instrs perhaps (c) think of eliminating block push onto frame?
<enebo>
subbu: do you mean also that blockpass will recieve_implicit_block and if used will reify_closure?
<subbu>
whatis blockpass?
<enebo>
&b
<subbu>
that is reify_closure
<subbu>
always
<headius>
hmm
<headius>
blast
<subbu>
as far as i can tell.
<headius>
I need two instrs
viking has quit [Remote host closed the connection]
<headius>
for yield when the block is passed to current body, it's going to be in a differnt place than yield from a closure
<enebo>
but that means we unconditionally make a proc per $&b param which was my first question about side-effects and :to_proc coercion
<headius>
the latter case has to get it from the call stack
<headius>
or rather, from outside current logical frame
<subbu>
enebo, in "def foo(&b); .. b unused .. end", the "b = reify_closure" instr. will get DCE-ed.
<subbu>
so, there is no to_proc that happens
<subbu>
to_proc always happens in reify_closure instr
<enebo>
subbu: yeah but if incoming b = Foo.new where Foo has def to_proc; side_effect; return proc; end?
<subbu>
i don't understand that ruby code.
* subbu
has forgotten a lot of things clearly
<enebo>
hmmm I think the callsite does the passing
<enebo>
so it probably calls to_proc before the method is invoke
<enebo>
subbu: anything can be &blah’d at callsite and it will try and call to_proc on it
<enebo>
subbu: I think I am confused when it happens
<subbu>
ah, yes .. so, yes, that should happen on the call side.
<enebo>
subbu: yeah and I think that is right and I remove the question
<subbu>
ok.
<enebo>
So at param side &b will be a block
<enebo>
well a proc
<subbu>
headius, i didn't understand what happened with your 'blast' .. ruby code?
<enebo>
hmmm weird case in my head for some reason
<subbu>
enebo, yes. doesn't affect the callee.
<headius>
well, is yield inside a closure constructed any differently?
<headius>
def x; y { yield }; end
<subbu>
shouldn't be.
<enebo>
since foo(&bar) is already reified by we pass as block and not reified proc
<headius>
if it's not, then it's going to be looking in the wrong place for the closure
<headius>
or I'm going to have to have a frame for all methods
<headius>
obviously we don't want that
<headius>
so def foo; yield; end needs to be implicit and def foo; x { yield }; end needs to be explicit
<subbu>
but, in this case, x will have a frame, won't it?
<subbu>
always
<headius>
right, it will, but the first case in my last msg won't
<headius>
because we eliminate it
nanoyak has joined #jruby
<headius>
we could make yield force a frame but that would be a shame
<headius>
it doesn't need it
<subbu>
how do you handle it in 1.7? def x; y { yield; }; end without forcing a frame for method x?
<headius>
yield from within a closure body compiler does something different
<headius>
I don't have such a distinction at the moment
<headius>
JVMVisitor.YieldInstr doesn't know if it comes from a method body or a closure body
<subbu>
right.
<subbu>
i am trying ot figure out why it should know.
<headius>
and we don't want per-scope hacks in the JIT anyway
baroquebobcat has quit [Quit: baroquebobcat]
<subbu>
agreed
colinsurprenant has quit [Ping timeout: 252 seconds]
<headius>
it could be built differently but it would need to have an implicit/explicit flag or a different yield that takes an operand, or the same yield that takes an operand and we add an ImplicitClosure
nanoyak has quit [Remote host closed the connection]
<headius>
so I'm back to that now
<subbu>
i lost you again :)
<headius>
if both forms are the same instruction, they need to differentiate how they get block using operands
<headius>
or they can be different instructions
<headius>
either way I think we have to add something
<enebo>
oh god I decdided to look at output of that example and forgot we eliminate block scope when no vars present fixup depth to use outer scope block
<subbu>
if they are getting from the current frame on stack, it can always be the same instr without knowledge of scope.
<headius>
subbu: right, but JIT bifurcates that case by eliminating frame in flat methods
<headius>
interpreter could always go back to frame for the block, but JIT can't
<subbu>
what is a flat method?
baroquebobcat has joined #jruby
<headius>
no capture
<headius>
eval, binding, nested closures
<subbu>
so, yo uare saying in "def x; y { yield; }; end" x doesn't capture the block?
<headius>
I'm saying in that case it's fine because we have to have a frame
<headius>
but in def x; yield; end we don't
<headius>
because in JIT I can just get it from JVM args
<headius>
but I have no way to differentiate the two cases by the time we get to JIT
<subbu>
ah, ok .. so, now i undertand.
<subbu>
i had said: anyway, (a) implicit yield now (b) later, split recv_closure into 2 instrs perhaps (c) think of eliminating block push onto frame? .. because i thought (c) hadn't been done yet :)
<subbu>
but, you are saying in the JIT you have a version of (c) already.
<subbu>
now, it makes sense.
<enebo>
we should be doing c in IR though right?
<subbu>
so, headius wants an explicit yield operand for the def x; yield; end case
AckZ has joined #jruby
<headius>
subbu: AddCallProcotol does this for me
<subbu>
right. i had forgotten about it.
<enebo>
heh so did I
<headius>
ACP could rewrite yields I suppose
<headius>
but I still need a way to differentiate the two form
<subbu>
got it.
<subbu>
so, maybe you need solution (b) .. just bite the bullet and split recv_closure into implicit/explicit forms. and it hsould solve it.
<headius>
I think I have to do that to get (a)
<enebo>
seems like adding reify sooner than later would deal with this
<enebo>
heh
<headius>
because there's no no separate explicit yield
<subbu>
ok, so, here is my proposal
<headius>
I'm happy to do all of this, I think I know where the bits go
<headius>
just looking for input on path forward
<subbu>
split recv_closure into the two forms .. %block = recv_implicit_block; and b = reify_closure
<subbu>
that would be in IRBuilder
<headius>
reify_closure consuming implicit block
<headius>
ok
<subbu>
and convert %block into a tmp
<headius>
right
<subbu>
and implement those two instrs.
<subbu>
which are both simple .. recv_implicit_block is the current recv_closure but without the to_proc conversion
<enebo>
so %block is now just a regular temp now though
<headius>
def x; y { yield }; end would need to compile using the recv_closure result var then
<headius>
but I can do that
<subbu>
and reify_closure will just get its block from the call args and call to_proc on it
<subbu>
or rather .. %block = recv_implicit_block; b = reify_closure %block if you want to be very clear
<enebo>
definitely that
<subbu>
so, %block= recv_implicit_block is always added in all scopes
<subbu>
and yield will always use %block
<headius>
right
<subbu>
and b = reify_closure %block will take care of the &b case
<subbu>
and it will get DCE-ed if b is not used anywhere.
<headius>
yield can't use %block always
<subbu>
what is the scneario where that won't work?
<headius>
y { yield } needs its operand to load from heap
<headius>
its block operand
<subbu>
no. there is a recv_implicit_block added to the closure as well.
<headius>
hmmm
<subbu>
and recv_implicit_block when it executes will load it from the frame.
<headius>
that's true...blocks don't get implicit closure arg
<subbu>
so, it will get passed along just fine.
<headius>
it has to be explicit
<enebo>
right now we always fixup depth in IRBuilder
<headius>
or it has to know to go to frame and I'm back to being unable to differentiate
<enebo>
headius: but isn’t that up to the block yiedl/call to figure that out
<subbu>
and the call to y will push the %block onto the frame
<headius>
subbu: right, and what does implicit_block do there?
<headius>
where does it get the block?
<enebo>
headius: whatever is Block block in the tield path is what that gets as implicit
<subbu>
recv_implcit_block will either get from call-args or from the frame.
<headius>
it can't be the one passed into interpret becase that's the block's block
<headius>
not the method's block
<subbu>
depending on scope type
<headius>
ahhh
<headius>
there's what I was missing
<subbu>
for methods, always call args
<headius>
so it differentiates based on scope type
<subbu>
for blocks, always frame
<subbu>
yes, it would have to.
<headius>
right
<headius>
well, it wouldn't have to if we used getImplicitBlockArg, but I understand the value in eliminating that :-)
<headius>
this will also fix reifying for y { yield } case, so it's obviously better
<enebo>
I am happy to see this depth fixing going away. It was painful to debug
<subbu>
yes, i think we should get rid of that hack.
<headius>
we are ok with instructions that behave differently depending on which *type* of scope they're in?
<headius>
we don't have many of those, to be sure
<enebo>
Interesting to me in how over time IR gets cleaner and not messier
<subbu>
i guess in htis case, it is inevitable.
<subbu>
of distinguishing between scope types
<headius>
it's not inevitable if we compily y { yield } as %block = frame_block
<subbu>
true.
<subbu>
a new instr.
<headius>
versus %block = implicit_block
<subbu>
hmm .. :)
<enebo>
headius: I am cool with that idea but it is more instrs
<headius>
see my conundrum
<subbu>
i like the new instr idea :)
<headius>
right, that's something we haven't discussed...can we have too many?
<headius>
this case seems pretty different
<headius>
the two yields have drastically different ways of finding the block
<subbu>
but, yield behavior is not changing either way
<headius>
stack_block and frame_block
<headius>
right, it's just the locating the block
<subbu>
either %block = implicit_block will either use scope-type or we will use different instrs (implicit_block, frame_block)
<headius>
this also starts to move toward being more explicit about JVM-level loads/stores of implicit state
<enebo>
a conditional in runtime is not something we want if we can eliminate it through more specialized instr
<subbu>
and yield %block will just look at value of %block.
<enebo>
At least for JIT
<headius>
which are temp loads/stores in IR
<headius>
subbu: right
<headius>
it would essentially be our first instr to explicitly box up a frame field
<subbu>
i am inclined to use diff. instrs
<headius>
which I think we agreed we'd need to do at some point anyway
<enebo>
Ok I am on the two instrs to simplify the impl code
<headius>
ok
<headius>
I can do that
<headius>
I need to revert my deleting the additional instr :-)
<headius>
and this is an instr not an operand, right?
<subbu>
or rather 3 instrs ;-) recv_closure splits into recv_implicit_block, recv_frame_block, reify_closure
<enebo>
My only caveat to more instrs is mostly splitting more complicated instrs into a series of smaller ones
<enebo>
This has to be balanced against whether interp will be impacted by more
<subbu>
the usual tradeoff .. good for JIT, bad for interp ;-)
<enebo>
subbu: minor for interp in this case if you consider being able to eliminate the reification
<headius>
subbu: I could make it more... recv_implicit_block; store_frame_block; load_frame_block
<subbu>
enebo, true.
<headius>
hmm
<headius>
yeah I think I have the various scenarios in my head
<enebo>
subbu: it is +1 instr being interp’d but if you are standning up a proc it probably is nothing more than noise
<headius>
I will make a judgment call how explicit to make the frame load/store
<subbu>
i didn't get the store_frame_block part, but i think you mean at call site to make it explicit?
<headius>
if we can get to a point where all implicit frame load/store operations are in IR we can start to break frame into smaller hits
<subbu>
enebo, true, i forgot that part.
<enebo>
I think we only have three instrs from one
<enebo>
ah and subbu mentioned them above
<headius>
subbu: JVM body needs to know it has to save the block into the frame somewhere
<enebo>
headius: do you think there is more than that needed?
<subbu>
ok . in this case, 3 heads proved better than 1 at getting a solution faster :)
<headius>
that is basically recv_closure now because it goes into the scope
<headius>
I have the picture in my head...we can iterate after a POC
<headius>
if I don't need a store instr I won't do it
<subbu>
ya, for now, you can let existing call-site code be as is where it does the push implicitly .. we can do another pass over surfacing it into ir.
<headius>
ok
<subbu>
but, it is getitng there slowly where frame is breaking up from a monolith
<enebo>
hmmm so %block will also become a temp now right?
<subbu>
yes.
<enebo>
otherwis dynscope would need to change
<enebo>
but the good news is that this should make ACP not need as many 1+ dynscopes
<subbu>
alright .. overall looks like a good resolution.. lunch time for me.
<enebo>
yeah I am starving as well
<subbu>
it is very late for enebo not to have had lunch yet!
<enebo>
I was going to say something but I think it will be a 20 minute conversation so I will hold off :)
<subbu>
i am actually eating earlier than my usual time :)
<subbu>
ha ha .. ok.
subbu is now known as subbu|lunch
<headius>
I'm wondering if load/store_frame_closure could be treated as operands
marr has quit [Read error: Connection reset by peer]
colinsurprenant has joined #jruby
<headius>
store is obviously an instr so load should be too...I just thought I could eliminate the temp var in the latter case
<headius>
frame_closure instead of load_frame_closure
<enebo>
headius: If it cannot throw or have side-effects it can be an operand
<headius>
it can't, so it shall be
pietr0 has joined #jruby
<headius>
this kinda gets quagmirey because I want to make push_frame have a result variable that I use for load/store instr and which can then DCE when not used
<headius>
but I'll find a simpler way for now :-)
mrmargolis has quit [Remote host closed the connection]
mattwildig has joined #jruby
<enebo>
headius: so if you make frame_closure an operand then load store are just copy instr
<headius>
oh, I don't need StoreFrameClosure because PushFrame implicitly does that
<headius>
I don't need it until we start to break PushFrame apart
<enebo>
headius: but if you do need to change the value it can just be a copy
<headius>
yeah I think I can skip store for now
<headius>
I still need load for the closure yield
<headius>
in-closure yield
<headius>
push_frame will turn into a set of frame stores at some point
<enebo>
Absense of the operand after DCE can also tell us we don’t need to alloc it once frame is destroyed
<headius>
consuming a prepare_frame that will DCE away if unnecessary
<headius>
yeah
<headius>
ok
<enebo>
I am hoping we consider not having frame even in the vocab at some future point
<headius>
it's a balance between having IR explicitly know about runtime structures and having it be hidden I suppose
<headius>
if it knows that there's a "frame push" of some kind, then it can optimize around it
<enebo>
headius: yeah I guess it depends on how much data is all or nothing
<enebo>
headius: just dealing in terms of what is in a frame means we can still make a frame behind the scenes if the same 3-4 things always exist there
colinsurprenant_ has joined #jruby
<enebo>
headius: but I think things like visibility only referred to by something mentioning visibility probably will end up its own datastructure like the old spaghetti stacks
<headius>
sure, I suppose we treat each "frame field" like its own special entity and deal with it appropriately elsewhere
colinsurprenant has quit [Ping timeout: 264 seconds]
colinsurprenant_ is now known as colinsurprenant
<enebo>
headius: the only downside is # of instrs for interp but I think we are starting to converge on interp being simple and not having this level of granularity
<enebo>
but we cannot add the world on the first JIT pass so there is some compromise
<headius>
most of the frame instrs would not have to show up in interpreted code if the interpreted version of all instrs just know how to go to frame
<headius>
but yeah, I agree we're converging
<enebo>
yeah they are all noops (or not there period) if we assume implicit structure for interp
<headius>
enebo: can't be an operand because operands don't receive block
<headius>
just got that far :-)
e_dub has quit [Read error: Connection reset by peer]
e_dub has joined #jruby
<enebo>
you can add to retreieve
<enebo>
we I think only added params we knew were used
multibot_ has quit [Read error: Connection reset by peer]
multibot_ has joined #jruby
thsig has quit [Remote host closed the connection]
e_dub has quit [Read error: Connection reset by peer]
e_dub has joined #jruby
<headius>
where can I get at the %block variable?
<headius>
I assume it has been declared implicitly for me when I get to YieldNode in IRBuilder
x1337807x has joined #jruby
<headius>
enebo, subbu|lunch: ^
<enebo>
headius: %block as a variable can just extend temporary variable or even just become one
<headius>
but the IR needs one instance of it somewhere, right? How do I find that instance or where do I put it?
<headius>
wait, I will ook at ReceiveClosure logic
<enebo>
I believe just assign the block as a proc to %block in recieve_closure
<enebo>
That obviously still works for method although your question does imply needing a instr since it is a local in our call chain
<enebo>
yeah I guess it makes sense recv_implicit_block (from local in method) and recv_frame_block (for closure) to have result of block but as a temp var
<treehau55>
I have since iterated a different way, but I am still curious where that method came from
subbu|lunch is now known as subbu
<enebo>
unless you mean how do you keep track of this new temp var
<subbu>
headius, enebo won't a new operand that extends TemporaryVraiable do it? ... any old tmp var would do it .. but you just need to know what itis when ou get to yield.
<subbu>
hnece a special operand type which makes that easy by eliminating the bookkeeping during ir building
<enebo>
subbu: yeah I think any will do unless we want to be able to nicely see it
<subbu>
right.
<headius>
I'm just going to create it as a plain temp var and store it as state for current scope in IRBuilder
<headius>
so I can use it to load elsewhere
<headius>
is that ok?
x1337807x has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<headius>
so we can have all access of block just be the same var
<subbu>
sure. that will work.
<enebo>
hmm
<subbu>
i think i hve a mild preference to use a specially named var for IR readability .. but, not a big deal since it eliminates a new type in IR operands.
<enebo>
yeah I agree with that for those weird cases where we push it as an operand to the wrong place
<enebo>
headius: I would extend it from temporary variable and use a single instance
<enebo>
headius: then we can have a nice toString on it
<headius>
hmm ok
<enebo>
hmm
<enebo>
but it probably needs an offset
<enebo>
I guess it doesn’t neccesarily
<enebo>
gah
<enebo>
headius: you might need both things
havenwood has quit [Remote host closed the connection]
<nirvdrum>
Not to interrupt, but since you're all here, it'd be great to get that to_a IR exception cleaned up.
<enebo>
headius: IRMethod and IRClosure (or IRScope if you feel lazy) can store it as an operand but that operand type would be nice if it was an instance of something where toString printed it out nicely
mattwildig has quit []
<enebo>
ah actually no new type ‘new TemporayLocalVariable(“block”, next offset from scope for temp vars)
e_dub has quit [Read error: Connection reset by peer]
<enebo>
it might be slightly more complicated than that but IRScope can make it and then return the same one over and over and then it does not require a special offset
<enebo>
subbu: ^
e_dub has joined #jruby
<subbu>
sure .. i am lazy/unfocused right now to think through all these different options .. but yes .. that would work as well.
<subbu>
nirvdrum, what is the to_a issue?
<subbu>
i thought i cleaned it up?
<subbu>
you mean the wwarning during rubyspec runs?
<JRubyGithub>
[jruby] chrisseaton pushed 1 new commit to master: http://git.io/C7pKvg
JRubyGithub has left #jruby [#jruby]
<JRubyGithub>
jruby/master f2b1582 Chris Seaton: [Truffle] Use declarative guards for checking classes in the IC.
mitchellhenke has joined #jruby
<headius>
hah, I'm learning
<headius>
forgot to add the new closure var to new/modified instrs operands, so it DCE'ed away :-)d
rsim has joined #jruby
<headius>
hmm
<headius>
maybe that's not it
AckZ has quit [Quit: Connection closed for inactivity]
<headius>
hmm
metadave_ has joined #jruby
metadave has quit [Ping timeout: 240 seconds]
mje113__ has joined #jruby
baroquebobcat_ has joined #jruby
baroquebobcat has quit [Ping timeout: 240 seconds]
baroquebobcat_ is now known as baroquebobcat
<headius>
enebo: my instr seems to be disappearing
<headius>
but the yield does report its result var as one of its operands
<headius>
is there something else I need to do?
<enebo>
headius: sorry in a middle of making coffee bbiaSEC
<headius>
boo
<enebo>
heh
<enebo>
espresso machine takes time to get going
<enebo>
headius: did you pretty much copy RECV_CLOSURE
ahadding1 has quit [Quit: Leaving]
pchalupa has quit [Quit: Leaving]
<enebo>
headius: Assuming it is the same operand I think LVA should have not marked your instr as dead
<enebo>
AHA
<enebo>
headius: Variable.isBlock() is looking for a name of %block exactly
<enebo>
headius: Thati s not nearly as clear as it should be but because it does not think it is a block the underlying instr thinks it can be deleted
<headius>
RECV_CLOSURE was refactored to take the implicit block temp as a source
<headius>
I'm not using isBlock for anything
<headius>
this is just a plain temp var
<headius>
allocated one, lazily, from IRScope
<headius>
one=once
<headius>
enebo: I will push what I have...it's close
<headius>
to a branch
<enebo>
headius: If you want to solve withotu really solving....
<enebo>
headius: override canBeDeleted() on your new instr and return false
<headius>
I'll try that and make sure it works
<headius>
seriously intellij, if I put an @Override annotation on a method I'm writing, you could give me a list of names I can override
<headius>
I don't understand why it does not do that
<enebo>
headius: I don’t like the whole generate menu in general either
<headius>
I can do it through generate but that's the super heavy GUI version
<headius>
I wand to type @Override public boolean can<COMPLETE> and get a list
<enebo>
headius: me too
<headius>
I found it
<headius>
receiveClosureArg was only called if there's a block arg
<headius>
so it wasn't doing my always-on implicit loads
<enebo>
yeah that was why I mentioned Variable.isBlock
<headius>
different thing
<enebo>
oh yeah?
<enebo>
Did you change that too?
<headius>
it was looking getBlockArg to know whether to call it
<headius>
in receveBlockArg, which called receiveClosureArg :-)
<headius>
I unified them
<headius>
oooo, close
<headius>
almost booted that time
<enebo>
I think you will still get a problem from what I am mentioning
<enebo>
Instr.canDeleteInstr basically looks at name of result to see if it is a block and deletes if it isn't
<headius>
oh actually it did boot, got into benchmark/ips lib
<enebo>
well it is more complicated than that but you get what I mean
<headius>
but if the variable is in use it won't, right?
elia has joined #jruby
<headius>
this is a plain temp variable...same object used throughout the method
<enebo>
look at instr.canDeleteInstr
<enebo>
headius: well you might be right
<headius>
right, but that's not used unless it determines the result is never used elsewhere
<enebo>
headius: if you are then we can delete some code
<headius>
this is just checking side effects etc
<headius>
and these have none
<enebo>
recv_closure did not either
yfeldblum has quit [Ping timeout: 265 seconds]
<enebo>
and I am unsure where this would have come into play otherwise
<subbu>
i just glanced at this .. and the block-name use in can-be-deleted is used in scenarios where there is no evident use of the %block operand .. but it shouldn't be deleted because of evals in the scope.
<enebo>
what other instr sets block as the lhs/result?
<subbu>
that doesn't apply for normal use cases.
<subbu>
and evals can contain yields for example.
<enebo>
subbu: so should this instr unconditionally not DCE?
<headius>
enebo: reify
<headius>
or yield
<headius>
oh wait
<enebo>
as result?
<headius>
no
<headius>
and this doesn't either
<headius>
I'm not using %block
elia has quit [Read error: Connection reset by peer]
<headius>
I'm using a plain temp variable :-)
<subbu>
enebo, only if the scope is known to contain evals etc.
elia has joined #jruby
<subbu>
otherwise i tis okay to kill that instr.
<enebo>
subbu: ok so we should still update this code then
<subbu>
yes.
<enebo>
but just the block identification part right?
<headius>
I don't think block needs a special var anymore since we have instrs to prepare it
<enebo>
Variable.isBlock
<headius>
it's just like any other temp now
<enebo>
subbu: so how do evals see this now?
<enebo>
I modified your comment from a while back there but is this still true:
<enebo>
// %block must stay if this scope or nested scope has an eval which might yield. Safe, but conservative.
<enebo>
Since eval will have it’s own recv_implicit_closure now?
<enebo>
It will have to now right?
<subbu>
not sure if blocks are pushed when eval is called.
_elia has joined #jruby
<subbu>
if they are pushed then, yes, evals would need its own recv_implicit_block.
<enebo>
headius: you tracking this? do evals get their own recv_implicit_block now
<subbu>
in that case, that check in Instr.java is not necessary.
calavera has joined #jruby
<enebo>
subbu: yeah I am hoping that will be true
robbyoconnor has quit [Quit: Konversation terminated!]
elia has quit [Ping timeout: 264 seconds]
<headius>
I'm multiplexing
<headius>
block for eval should be in the frame
<headius>
they would need to have a LoadFrameClosureInstr
<headius>
I'm trying to avoid adding this to every scope's build path though
calavera_ has joined #jruby
<enebo>
well SClass, Method, Closure, and Eval are the only possibilities
<enebo>
fucking SClass + closures ;)
<enebo>
that one perhaps is just getting it from above scope
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] chrisseaton pushed 1 new commit to master: http://git.io/Se75Sg
<JRubyGithub>
jruby/master fb4b3b8 Chris Seaton: [Truffle] CallDispatchHeadNode and DoesRespondDispatchHeadNode.
JRubyGithub has left #jruby [#jruby]
mattwildig has joined #jruby
<enebo>
Actually it is type of retrieval
<enebo>
hmm ignore that sentence
<enebo>
don’t even know what I was going to say
calavera has quit [Ping timeout: 255 seconds]
<subbu>
headius, just add it where needed. it eliminates these one-off special cases like the isBlock check in Instr.java
<subbu>
and the extra instr in eval is not a big deal anyway.
<enebo>
headius: I would prefer each scope to get this that can use it since it kills off our weirder variable depth code to find the thing
<enebo>
subbu: It feels like this change is killing lots of requires explanation/comments sort of logic
<enebo>
which is nice :)
<enebo>
subbu: LiveVariableNode:297 is extremely unclear what is going on
<subbu>
ya .. when i started i didn't clearly understand the semantics for these two uses of blocks very well.
<enebo>
subbu: mostly from line 301
<subbu>
let me see.
<enebo>
I mean 297 does make a lot of sense until you see line 301
<enebo>
In fact I feel like that is a bug
rsim has quit [Quit: Leaving.]
<headius>
subbu: yeah, I've created IRBuilder.prepareImplicitState that does ReceiveSelf, LoadImplicitClosure, etc
<headius>
sweet, it runs
<headius>
woah
<headius>
yield is fast
<enebo>
DARK MATTER?
<headius>
well, I'm trying to beat 1.7 :-)
<subbu>
yes, that flag can be removed from there now as well .. i dont see it being used.
<headius>
ok, much closer to 1.7 on yield now
<headius>
7.88M ips versus 9.52
<enebo>
what was it before?
<headius>
1.8M
<enebo>
heh
<enebo>
nice
<headius>
well before this IR work it was 6.5ish
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] nirvdrum pushed 1 new commit to master: http://git.io/_tpwEA
<JRubyGithub>
jruby/master 1a36da4 Kevin Menard: [Truffle] Fixed bad implementation of MatchData#captures.
JRubyGithub has left #jruby [#jruby]
<headius>
block.call is 6.38 versus 5.82 though
<headius>
better in 9k with today's changes
<headius>
the remaining perf of yield may be argument overhead, I have to see
<subbu>
you should run tests to see how this changes perf on benchmarks
<enebo>
headius: and you fixed interp at same time on this?
<enebo>
headius: I guess you must have
rsim has joined #jruby
dyer|away is now known as dyer
<headius>
yeah, interp and jit
<headius>
working out remaining glitches
robbyoconnor has joined #jruby
robbyoconnor has joined #jruby
robbyoconnor has quit [Changing host]
<headius>
bleh, rubyspec doesn't even boot
rsim has quit [Quit: Leaving.]
rsim has joined #jruby
rsim has quit [Client Quit]
zorak8 has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] chrisseaton pushed 1 new commit to master: http://git.io/GGX8Rg
<JRubyGithub>
jruby/master 02ebbe7 Chris Seaton: [Truffle] Merge PredicateDispatchHeadNode into CallDispatchHeadNode.
JRubyGithub has left #jruby [#jruby]
calavera_ has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
rsim has joined #jruby
<headius>
enebo: ok, I'm almost there
<headius>
I think this is failing because I'm continuing to hold a reference to the initially-allocated temp var but vars have been reorganized
<headius>
so I'm not doing that right
<headius>
I added a TemporaryVariable field to IRScope that holds the temp for the block
calavera has joined #jruby
<headius>
what's the right way?
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] nirvdrum pushed 1 new commit to master: http://git.io/aPDgNw
<JRubyGithub>
jruby/master 3dec080 Kevin Menard: [Truffle] Implemented MatchData#inspect.
JRubyGithub has left #jruby [#jruby]
<headius>
basically I need to set it up during body preamble and then use the same var for all accesses in the body
<enebo>
headius: I think that is fine but it probably is only used for the duration of building and should not be used after that
<headius>
it isn't liking something though :-\
<enebo>
Does it require that it is the exact same instance to work?
<headius>
I'm getting other code stuffing someting into my block variable
<headius>
I don't know, does it?
<enebo>
hahah
<enebo>
I would not think so no
<headius>
so how do I access it if I don't hold a reference?
<enebo>
only Labels require that (unfortunately)
<headius>
i.e. I set it up in preamble, and then way down the build process I need to load it
<enebo>
headius: just so I understand...
<enebo>
headius: once it is a temp it does not matter for JIT or interp right?
<headius>
addInstr(s, new LoadFrameClosureInstr(s.getImplicitClosureVariable()));
<enebo>
headius: it is only for the maknig of the preamble that you want to store the block for JIT?
<headius>
store yes
<headius>
then I need to be able to load
<headius>
the block object goes into a temp, and then yield loads from that temp
<headius>
how do I use the same temp :-)
<enebo>
but load frame contains the temp you load it to so this is just for making this instr impl
<enebo>
They are are the same offset
<enebo>
It should access from the same temp slot
<enebo>
however you alloc those
<headius>
excellent, how do I do that
<enebo>
it is a localtempvar instance right?
<headius>
getImplicitClosureVariable does createTemporaryVariable();
<enebo>
ah ok so how do you allocate temp variables now?
<headius>
moi?
<enebo>
unless each getImplicitClosureVar is making a new one
<headius>
in the past if I needed a temp var I used it in the same method
<headius>
same compiler/IRbuilder metho
<enebo>
yeah
<headius>
in this case I have state from preamble that I needed later in build, so I stored it in IRScope
<enebo>
that should still be the case if you added these instrs to each scope
<headius>
I'm confused why my var is getting clobbered then
<enebo>
you sneaky bastard: if (s instanceof IRMethod || blockArg != null) if (blockArg != null) {
<enebo>
:)
<headius>
that's not my line...
<headius>
or if it is that's a mistake :-)
<headius>
see v_0 there is used for load_implicit_closure, and then used for yield...and then stepped on by a subsequent call
<headius>
I don't know why
<headius>
oh I'll add the code
<enebo>
headius: we reuse temp vars but is that a loop?
<headius>
added
<headius>
yeah it's a loop
<enebo>
headius: It is a bug in our reuse temp vars logic maybe
<headius>
a while loop with a yield in it
<enebo>
headius: Try removing that pass and see what happens
<enebo>
headius: yeah that looks pretty broken
<subbu>
headius, enebo a good reason to use a special operand actually ..
tcrawley is now known as tcrawley-away
<subbu>
i am sure it is opt tmp vars pass.
<enebo>
subbu: yeah looks like it must be
<enebo>
subbu: but I see no reason why we shouldn’t just fix this to remove any special checks
<enebo>
subbu: code will probably be simpler
<headius>
I have not seen this behavior before but this is a pretty long-lived temp var
<headius>
used across flow-control
iamjarvo has joined #jruby
<subbu>
ya .. see opt-tmp-vars pass is kind of a "hack" that exploits information about how ir builder uses tmps only for instr chains and this recv_block --> yield breaks that assumption.
kaawee has joined #jruby
<subbu>
so, using a special operand type just gets around that.
<subbu>
since opt-tmp-vars won't reuse it.
<subbu>
sorry i forgot about it.
<headius>
removign temp var pass does work
<headius>
is there a flag I can set on a temp var to say "never reuse this" in lieu of fixing the pass?
<subbu>
that said, there are special checks in opt-tmp-vars pass .. hold on .. let me look.
<headius>
yeah I see it now
<headius>
I can add a flag to TemporaryVariable that makes it a permenent temporary
<headius>
permanent
<headius>
non-reusable
<subbu>
headius, line 218 in OptimizeTempVarsPass
<subbu>
add an entry for the block var there and it should fix it.
<subbu>
actually outside the s.hasLoops() check.
<headius>
oh there's the magic sauce
<subbu>
it just extends the live range to the end of scope.
<enebo>
sort of fits better to be in the pass since another pass could be able to change something and then whatever name was chosen for that flag would not seem to make sense
<headius>
yeah no problem
<subbu>
yes, let us not add a flag.
<headius>
this is a good fix
<headius>
good enough :-)
<headius>
zang, works
<enebo>
I guess ultimately this pass will change eventually since this could be even more agressive (in addition to being a little more general)
<headius>
I will resume testing
<enebo>
subbu: although didn’t we talk about having IRBuilder just be agressive in reuse at least for these expr chain cases?
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] nirvdrum pushed 1 new commit to master: http://git.io/GZGocA
<JRubyGithub>
jruby/master 2e55827 Kevin Menard: [Truffle] Implemented Regexp.last_match.
JRubyGithub has left #jruby [#jruby]
<headius>
it's not really a temporary variable but local variables have heap implications currently, right?
<headius>
temp variables are really just invisible variables
<subbu>
headius, while you are tromping through the code base .. remove that HAS_UNUSED_IMPLICIT_BLOCK_ARG thingie from flags and its uses.
<headius>
sure
<subbu>
enebo, yes, we talked about doing it during ir-building itself rather than as a post-pass since we aren't really exploiting the single-use scenario much really and in any case at this stage, most of the code is all tons of calls.
<headius>
rubyspec passed before this change but MRI suite still has a number of failures
<subbu>
again a holdover form early IR work.
<enebo>
subbu: Some times I think I have dreamt conversations about this stuff :)
mattwildig has quit []
<headius>
58
<headius>
oops
<enebo>
58!
<subbu>
not too bad for a largish IR change :)
<subbu>
but, zero failures would have been wonderful, of course.
<headius>
yeah, it's almost there
<headius>
when it passes I will have finally graduated from IR school
x1337807x has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<headius>
enebo: ahh, that line was from a refactoring
<headius>
inlined some logic
<enebo>
we create a map for each 1:1 use-def in opt temp vars and it always contains a single operand pair.
<enebo>
subbu: ^ was the idea to generalize that?
<subbu>
generalize what?
<headius>
down to 6F1E in MRI suite
colinsurprenant has quit [Quit: colinsurprenant]
<enebo>
copyMap at 136 in OptTempVars
bbrowning is now known as bbrowning_away
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] nirvdrum pushed 1 new commit to master: http://git.io/yGauew
<JRubyGithub>
jruby/master b63047d Kevin Menard: [Truffle] Don't destroy the last regular expression match when we reach the end of searching in String#scan.
JRubyGithub has left #jruby [#jruby]
treehau55 has quit [Ping timeout: 246 seconds]
<subbu>
enebo, because simplifyOperands expects a map
<subbu>
of operan d-> operand
<enebo>
subbu: ah and we use it for multiple things
<enebo>
subbu: heh
<subbu>
yes.
<enebo>
tunnel vision
<enebo>
so weird suddenly I can no longer compile RubyLexer and the line is just weird
<enebo>
I am somewhat excited to see how much yield is used in cold perf
<enebo>
I would not think this would have much impact on cold perf but I am still hoping for it :)
_2_marleni has joined #jruby
<headius>
it's going to be mostly allocation improvements which may not show up as much cold
<headius>
allocation is massively overshadowed by cold interp/jvm
<enebo>
headius: yeah I really don’t expect to see it in interp at all unless it is a tiny loop bench
<headius>
I bet, anyway
<enebo>
blocky loop sort of thing
mitchellhenke has quit [Quit: Computer has gone to sleep.]
x1337807x has joined #jruby
x1337807x has quit [Max SendQ exceeded]
x1337807x has joined #jruby
<headius>
so awesome to see interp and JIT fail exactly the same way, so I can chose the mode that's easier to debug
<enebo>
headius: yeah I was just thinking I was going to add a section on the improved ability to debug optimizations based on ease of debugging it in interpreter
<enebo>
headius: to why IR slides
<subbu>
but, that just means we don't opt aggressively enough yet ;-)
_2_marleni has quit [Remote host closed the connection]
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<subbu>
but yes, when you are debugigng ir design and correctness, that is true.
<enebo>
subbu: well it removed a large class of opts from being, oh shit what generated this bytecode
<subbu>
true
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] nirvdrum pushed 2 new commits to master: http://git.io/0YZt8g
<JRubyGithub>
jruby/master 819c265 Kevin Menard: Removed RubyMatchData#begin19.
<JRubyGithub>
jruby/master 200de99 Kevin Menard: Removed RubyMatchData#end19.
JRubyGithub has left #jruby [#jruby]
<nirvdrum>
enebo: More cleanup for you!
<headius>
enebo: yeah
yfeldblum has joined #jruby
<headius>
enebo: you mean "oh shit, headius is the only one who knows how this bytecode is generated"
nateberkopec has quit [Quit: Leaving...]
<enebo>
nirvdrum: nice
<enebo>
headius: and even then :)
<nirvdrum>
I got to inline some common methods too.
pgokeeffe has joined #jruby
<headius>
I think I found my last issue
<headius>
ReifyClosure must *always* come from implicit block, not frame
<headius>
so I had to add one more temporary
<headius>
now there's getYieldClosureVariable (loaded from either implicit or frame) and getBlockArgClosureVariable (always implicit)
<enebo>
on IRScope?
<headius>
yes
<headius>
I'm sure this isn't the right place to keep it
<headius>
it's temporary during building that I need to hold the reference
<headius>
after that I don't care
<headius>
yeah, looks like this will be green
<headius>
awesome...that's not a bad turnaround for a big change
<enebo>
headius: this is a failing of our IRBuilder since we leverage IRScope but really if we can throw away the knowledge after build time we should not have it on IRScop
<headius>
is IRBuilder instance 1:1 with a scope?
<headius>
I could just add a field there if so
<headius>
this is scope-scoped :-D
<headius>
all I saw there were stacks that scared me
<enebo>
well IRBuilders are made one per scope with maybe exception of BEGN/END block cloning
<enebo>
and those stacks are really scary :)
<headius>
it is the exceptions that concern me :-)
<headius>
this will work ok though
<enebo>
but these vars do not need to live past IRBuild time so really we should change our design a bit
<enebo>
I don’t think this is the only thing on IRScope which should be dead once build is done though
<headius>
enebo: did you do any opto to reuse temp var operands?
<enebo>
So it is more a future project at this point
<enebo>
headius: I am looking at it. I can reuse some hashmaps
<headius>
they're all $v_#### so in theory we only need as many as the largest method
<headius>
and they're immutable
<enebo>
but it is pretty alloc heavy. Who knows if it matters though
<enebo>
but I also want a single %v_0 in non-closure non-flow control simple methods
<enebo>
that I think means later we can make a no-temp expr change in interp
<headius>
right
<enebo>
change chain
<headius>
sure, that works too
<enebo>
:)
<headius>
badass...test:mri passed
<enebo>
nice
<headius>
double checking spec:fast and then I'll push to master
thsig_ has quit [Remote host closed the connection]
<headius>
not a moment too soon either, I need to leave in 20 minutes
<headius>
this was fun, thanks
<enebo>
Actually this 1:1 use def temp algo could be improved by storing a single value instead of a uses array
<headius>
I feel empowered
<enebo>
It is either 0,1,or fuckit
<enebo>
{null, obj, FUCK_IT}
<headius>
yeah just reusing first 5-10 temps would save 99% of waste
<headius>
oops, now one failure in rubyspec :-D
<enebo>
I did that the other week
<headius>
2 steps forward
<enebo>
for actual alloc of temps
<headius>
oh ok
<enebo>
for several types
<headius>
that's what I was wondering about
<enebo>
but doing this at IRBuild would be way better
<enebo>
for saving temp allocs
<enebo>
I am just sharing the allocs
<enebo>
but not preventing them in the first place
<enebo>
{a: b, ……. big } is a zillion temp vars
<headius>
oh, one last fix
<headius>
I forgot singleton class bodies can yield to containing method
<headius>
which is totally wack
<enebo>
yeah
rsim has quit [Quit: Leaving.]
<headius>
someone should file a bug to remove that behavior
<headius>
there's no logical reason for it
<subbu>
awesome . looks like a good bunch of code cleanup and perf. improvement on top of it.
<subbu>
i think with your ir graduation dates, my retirement age is getting closer :)
<enebo>
hah
<enebo>
headius: hmmm I think I found one the other month when I stumbled over it but now I cannot remember
<enebo>
I think maybe so you can define_method for class method from a def?
<subbu>
what was supposed to be a .. "here i have this ssa code .. take this and do what you want with it ..turned into a 5+ year oss work. :)"
<enebo>
not sure why you should use the outer block sent to the def though
pgokeeffe has quit [Quit: pgokeeffe]
<enebo>
subbu: lifestyle choice
colinsurprenant has joined #jruby
<subbu>
;)
<headius>
ahhh
<headius>
singleton class is not triggering frame
<headius>
that's why the block is getting lose
<headius>
lost
pgokeeffe has joined #jruby
<headius>
grrr...I have to half-ass the fix
<headius>
ideally it would not force a frame unless it yields
<enebo>
hmm uses and defs are now use and def and single Instr value instead of an ArrayList of them
camlow32_ has joined #jruby
camlow32_ has quit [Read error: Connection reset by peer]
camlow32_ has joined #jruby
camlow32_ has quit [Remote host closed the connection]
<headius>
bleah I can't use frame either
camlow325 has quit [Ping timeout: 244 seconds]
<headius>
sclass pushes a frame
<headius>
you know what, I'm just going to pass it as the JVM block arg...that's not being used for anything right now anyway
camlow325 has joined #jruby
subbu has quit [Ping timeout: 255 seconds]
skade has joined #jruby
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
subbu has joined #jruby
<brocktimus>
People getting into public flamewars is just embarrassing, didn't everyone learn to not do that early in careers. (Woke up and reading drama about Time::parse).
pgokeeffe has quit [Quit: pgokeeffe]
<headius>
yeah, I won't get to finish this right now...bbl