skade has quit [Quit: Computer has gone to sleep.]
vtunka has joined #jruby
skade has joined #jruby
rsim has quit [Quit: Leaving.]
yfeldblum has quit [Ping timeout: 260 seconds]
pawnbox has quit [Remote host closed the connection]
intuxicated has quit [Ping timeout: 240 seconds]
bbrowning_away is now known as bbrowning
intuxicated has joined #jruby
intuxicated has quit [Changing host]
intuxicated has joined #jruby
pawnbox has joined #jruby
rsim has joined #jruby
pawnbox has quit [Ping timeout: 246 seconds]
pawnbox has joined #jruby
skade has quit [Quit: Computer has gone to sleep.]
brauliobo has quit [Remote host closed the connection]
brauliobo has joined #jruby
nateberkopec has joined #jruby
skade has joined #jruby
temporal_ has joined #jruby
temporalfox has quit [Ping timeout: 265 seconds]
nateberkopec has quit [Read error: Connection reset by peer]
gaustin has quit [Read error: Connection reset by peer]
gaustin has joined #jruby
<headius>
good morning!
vtunka has quit [Ping timeout: 260 seconds]
<headius>
lopex: I can spin jcodings release if you need
vtunka has joined #jruby
brauliobo_ has joined #jruby
brauliobo has quit [Ping timeout: 256 seconds]
brauliobo has joined #jruby
brauliobo_ has quit [Ping timeout: 255 seconds]
kares has quit [Ping timeout: 272 seconds]
ITXpander has joined #jruby
Aethenelle has joined #jruby
<headius>
subbu: you around today?
<headius>
I have a theory on the JIT issues...I think it's not pushing a scope for blocks that contain def
<headius>
I see it reusing parent scope for Class.new do ... inside a method body, which would make it impossible for the Class.new class_eval to find the right target for the def
<subbu>
I am around for a little bit now.
<subbu>
ugh .. it is sleeting out there.
<headius>
yeah it's pretty gross out
<headius>
I was going to go coffee shop work today but now I dunno
<headius>
DefineInstanceMethodInstr does say it requires dynscope but I'm seeing reuse of parent
<headius>
bytecode shows reuseParent = true when it calls "push scope if necessary" so it would be reusing x's scope
<headius>
trying to see if it's different in interp
<subbu>
i am sure it is buggy in interp as well.
<headius>
it works there at least but interp has more cases where it will create a scope, right?
<headius>
perhaps not
temporal_ has quit [Remote host closed the connection]
temporalfox has joined #jruby
<subbu>
I think what is going on is that this is always executing in startup interp .. and default there is push-scope because it runs without any passes run.
<subbu>
and i cannot force a compile because it happens in the background in a task .. so, it is a bit difficult to orchestrate this to have all passes run for purposes of debugging :)
<headius>
hmmm
<headius>
yeah the -1 should also turn off background compilation
<headius>
I made 0 do it but not -1
<headius>
-Xjit.background=false
<headius>
that should do it sync
<headius>
you may be right
<headius>
I can never remember the combination of flags to get full build
<headius>
enebo should have just added a new property :-P
<headius>
background property probably isn't needed there
<subbu>
i cannot remember either :-)
<subbu>
the combo of flags.
<headius>
yeah
<headius>
well that fails so that's good
<headius>
so nice that interp can run the same optimized instrs
<subbu>
yup.
thedarkone2 has joined #jruby
<subbu>
headius, anyway, so the bug is in optimizeDynScopes .. which looks like is just using scope flags.
<subbu>
// Cannot run this on scopes that require dynamic scopes
<subbu>
if (scope.getFlags().contains(IRFlags.REQUIRES_DYNSCOPE)) {
<subbu>
return null;
<subbu>
}
<subbu>
so, if you fix that computation, everything else show line up.
<subbu>
*should
<headius>
oh hah
<headius>
ok
<headius>
I read right past that
<headius>
I was poking around in there though...do not see yet why it fails to see the def
<subbu>
hmm .. yes, that is weird.
<subbu>
headius, i have to be afk for a little while .. then around for about 10 odd mins and i am off for the next 4 hours.
<headius>
no problem, I'll keep poking
<headius>
it's here somewhere
<headius>
woah
<headius>
I don't even see it get into FullInterpreterContext.calculateFlags
<headius>
computeScopeFlagsFromInstructions
Aethenelle has quit [Quit: Aethenelle]
<headius>
ah-ha
<headius>
it computes the flags based on simple context and sets them into that context...but then it later creates the full context and never calculates flags for that one
skade has quit [Quit: Computer has gone to sleep.]
<headius>
flagsComputed should probably live on the context
<subbu>
that is strange ... why aren't methods that get call protocol affected by this?
skade has joined #jruby
skade has quit [Client Quit]
shellac has quit [Quit: Ex-Chat]
brauliobo has quit [Ping timeout: 272 seconds]
kares has joined #jruby
<headius>
well here's one problem... with threshold 0 we build and use FullInterpreterContext in the block, but we're already inside the non-protocol yield logic at that point
<headius>
so it runs the manual protocol and then proceeds to interpreter full IC which has calculated protocol
<headius>
ah, and then Full IC pushes its own scope using block body's evalType, which has been reset to NONE
<headius>
so it doesn't do module_eval protocol
<headius>
subbu: this may be an issue propagating block's evalType with call protocol
pawnbox has quit [Ping timeout: 260 seconds]
Aethenelle has joined #jruby
<headius>
harumph...ok
<headius>
so I think scope isn't needed for this case since it's a module_eval...it can just use self.getMetaClass
<headius>
but the logic for findInstanceMethodContainer only looks at DynamicScope for evalType
<subbu>
headius, heading out in 5 mins .. but, quick comments.
<headius>
so, it can't find the right eval type
<subbu>
so, looks like there are multiple things going on ..
<headius>
it looks at parent's scope because reuse
nateberkopec has joined #jruby
rsim has quit [Quit: Leaving.]
<subbu>
independent of the eval type business ... it should have picked up the right flags for new/reuse/no dynscope .. is that still broken?
<headius>
I'm not certain it is broken now
<subbu>
ah, ok.
<headius>
the findInstanceMethodContainer stuff doesn't need dynscope to get the proper target...but it uses dynscope to know evaltype so that it can not use dynscope :-\
<subbu>
yes .. i had to stuff eval type in dynscope
<subbu>
and dynscope is needed for that reason even though it is not needed for anything else.
<headius>
right...if it were passed along call into block this would be no problem
<headius>
I am still confused about it not pushing a scope because there's def though
<subbu>
yes. .. so, that looks like a bug.
<headius>
if it were doing that I think this would also be ok because it would get evalType from the BlockBody
<subbu>
independent of whether we could pass info in block or dynscope.
<subbu>
exactly.
<headius>
but the lifecycle of evalType is problematic
<headius>
it lives too many places
<headius>
hmm
<subbu>
it only lives on dynscope .. and it had to be passed through block because of all the runtime hoops i had to jump through to get it where it was needed in the old runtime withotu breaking anything else :)
<subbu>
but now that it is gone, it could be cleaned up.
<headius>
yeah
<headius>
open questions:
<headius>
Do we always need to push dynscope for def?
<subbu>
ok, i have to run .. but i am not usre why interp/jit is not getting the right flag for pushing dynscope.
<headius>
yeah
<headius>
ok...I'll see if I can find a way to patch around this for now
<subbu>
yes, because of having to look up evaltype
<headius>
right, but if we could get evalType some other way, we might not need it
<headius>
for now I'll focus on fixing the flag calculation
<headius>
it's...weird
<subbu>
sure .. but, the qn. is if the missing flag business we are seeing now is a separate bug that will bit us elsewhere.
<subbu>
yes, that would be good to figure out what is happeneing there.
hobodave has joined #jruby
<subbu>
later. :)
<headius>
the full IC transition is a separate issue so I'll focus on JIT lifecycle
<headius>
seeya
<headius>
I wish enebo wasn't in JST for the next three weeks
tcrawley is now known as tcrawley-away
bbrowning has quit [Ping timeout: 244 seconds]
brauliobo has joined #jruby
brauliobo has quit [Ping timeout: 240 seconds]
bbrowning has joined #jruby
camlow325 has joined #jruby
camlow325 has quit [Remote host closed the connection]
camlow325 has joined #jruby
<GitHub179>
[jruby] eregon pushed 2 new commits to truffle-head: http://git.io/v01tk
<GitHub179>
jruby/truffle-head 53f6c8f Benoit Daloze: [Truffle] No need to fill an array if the default is 0.
<GitHub179>
jruby/truffle-head 8d328aa Benoit Daloze: [Truffle] Lazily allocate the call node in ToProcNode.
camlow325 has quit [Client Quit]
camlow325 has joined #jruby
vtunka has quit [Quit: Leaving]
pawnbox has joined #jruby
<headius>
subbu: found it...it was my hack to insert ACP instructions at beginning of entryBB causing it
AntKnee has joined #jruby
ITXpander has quit [Quit: Leaving.]
bb010g has quit [Quit: Connection closed for inactivity]
nateberkopec has quit [Quit: Leaving...]
ianderse has joined #jruby
atamb0 has joined #jruby
atambo has quit [Read error: Connection reset by peer]
<GitHub142>
[jruby] chrisseaton pushed 3 new commits to master: http://git.io/v01QL
<GitHub142>
jruby/master 7e07288 Chris Seaton: [Truffle] Fix source when running -e
<GitHub142>
jruby/master 824c7da Chris Seaton: [Truffle] Handle null paths in sources for coverage.
<GitHub142>
jruby/master ff2143c Chris Seaton: [Truffle] Handle null sources....
bbrowning is now known as bbrowning_away
camlow32_ has joined #jruby
<GitHub88>
[jruby] chrisseaton pushed 1 new commit to truffle-head: http://git.io/v01bk
<GitHub88>
jruby/truffle-head a6c404b Chris Seaton: Merge branch 'master' into truffle-head...
camlow3__ has joined #jruby
camlow32_ has quit [Read error: Connection reset by peer]
bbrowning_away has quit [Ping timeout: 244 seconds]
camlow325 has quit [Ping timeout: 255 seconds]
<GitHub88>
[jruby] chrisseaton pushed 1 new commit to truffle-new-instrumentation: http://git.io/v01N4
<GitHub88>
jruby/truffle-new-instrumentation 877da98 Chris Seaton: Merge branch 'truffle-head' into truffle-new-instrumentation
nateberkopec has joined #jruby
hobodave has quit [Quit: Computer has gone to sleep.]
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
bbrowning_away has joined #jruby
pawnbox has quit [Ping timeout: 246 seconds]
knowtheory has quit [Read error: Connection reset by peer]
<pglombardo>
Sorry to bug. What's the preferred debugger method/tool for jruby 9k? Google shows results from 2013 and the Wiki debugger page is also from 2013.
<pglombardo>
We could really improve on this bit to make it easier for new users.
hobodave has quit [Quit: Computer has gone to sleep.]
skade has quit [Quit: Computer has gone to sleep.]
pawnbox has joined #jruby
pawnbox has quit [Ping timeout: 246 seconds]
hobodave has joined #jruby
skade has joined #jruby
<headius>
pglombardo: there had been folks maintaining ruby-debug etc but I think it has bitrotted :-\
<headius>
subbu: I'm closer anyway
pawnbox has joined #jruby
yfeldblum has joined #jruby
yfeldblum has quit [Remote host closed the connection]
yfeldblum has joined #jruby
pawnbox has quit [Ping timeout: 255 seconds]
<subbu>
headius, okay.
tjohnson has joined #jruby
bbrowning has quit [Quit: Leaving]
<headius>
subbu: ok, new issues is visibility not being restored properly in JIT
<headius>
I have it reduced though
<subbu>
is that specific to JIT?
kares has quit [Ping timeout: 240 seconds]
<headius>
does not appear to be
<headius>
-X-C -Xjit.threshold=0 -e "require 'date'; p Date.private_instance_methods.grep(:start)"
<headius>
that method should be public
<headius>
in date.rb there's a Module.new block that sets private
<headius>
binding.setVisibility does not reset the frame's visibility
<headius>
so private sets the visibility on the binding's frame but nobody puts it back
<subbu>
but, unless I missed semantics when i convered to IR instructions, why is this different when done in instructions vs. in the runtime code?
<headius>
going to look at manual protocol to see
<headius>
heh
<headius>
manual protocol sets and resets visibility in frame, not binding
<subbu>
ah .. yes, there is a difference, i missed it.
<headius>
so we just implemented it wrong
<subbu>
binding.getFrame().setVisibility(oldVis);
<subbu>
vs.
<headius>
yeah, I'll add this to my current patchset
<subbu>
block.getBinding().setVisibility(oldVis) -- in he IR instr.
<subbu>
wow .. how the hell did all tests pass in interp mode? :)
pglombardo has quit []
<headius>
interp mode only runs simple
<headius>
we need to fix that
<subbu>
yes!
<subbu>
i assume it will do full build for the hot methods.
<headius>
at the very list the runs we do jit mode should also do full build mode
<subbu>
but, i think yes, we should run tests in full build mode.
<subbu>
rather that just the hot methods.
<headius>
tiered compilation is hard
<subbu>
yes .. requirements of testing. vs production.
<headius>
ok, full and jit both work right now on my repros
<headius>
I need to convince enebo that full and simple build comprise different compile modes
<headius>
having them both be hidden faces of interp keeps biting me
<subbu>
you mean we need two different flags for them?
<subbu>
or something more than that?
<headius>
since we intend for code to run in full build before it goes to jit, at least once we start profiling regularly, I think it should be treated as its own tier at all levels
<headius>
like, maybe we should just have TieredIRMethod that can start at and progress through any tiers
<headius>
oh great, random NPE in jit run now
<headius>
all over
brauliobo has quit [Ping timeout: 256 seconds]
n00bdev has quit []
<headius>
closer I guess :-P
<subbu>
ah i see ... I think of full build as only a debugging / development feature .. as an easier way to test / debug JIT.
<subbu>
not something that will be used in production .. i.e. startup interp -> full build interp -> JIT is not something that I think is very useful.
<subbu>
the perf diff between startup interp -> full build interp for cold methods is not going to be worth the extra work done to do it probably.
<headius>
subbu: so profiling will also happen only in jit?
<subbu>
good qn. it can happen in startup interp as well .. but, i haven't paid attention to the profiling stuff that enebo has been working on.
<subbu>
on and off we have had scattered conversations, but i have been too busy to be able to focus on some of these details.
<subbu>
i had proposed we should probably catch up once you were all in town to resolve these next steps.
bb010g has quit [Quit: Connection closed for inactivity]