01:02 colomon joined 02:15 zakharyas joined 02:31 tokuhiro_ joined 05:25 sivoais joined 05:33 Ven joined 05:35 sivoais joined 05:45 sivoais joined 06:14 FROGGS[mobile] joined 06:25 aiacob joined 06:36 FROGGS joined 06:42 cognominal joined 06:50 Ven joined 07:17 Ven joined 07:22 Ven joined 07:46 brrt joined 07:50 Ven joined 08:22 Ven joined 08:36 Ven joined 08:51 Ven joined
jnthn Gee, the inline/JIT bug *is* really strange. 09:46
It can't be that it mis-inlines the multi candidate for new because, well, for one that code isn't hot, but for two you can see it actually has the proto on the call stack 09:47
brrt the proto? 09:49
hmmm
jnthn proto method new 09:50
brrt aha
jnthn Well, just ruling out things
A mis-compile under JIT is, like, also hard to argue
brrt it's nearly impossible
jnthn Simply because the code is in a pre-comp'd module
brrt i've compiled panda to mast with and without JIT, and save for identifiers (which you can s/[\d_]+//g away), there is no difference whatever 09:51
jnthn Well, but there's the thing
If I have a panda built
brrt i'm listening
jnthn And I run "panda install Grammar::Debugger"
Then App::Panda is pre-compiled
And things do work with JIT or inline off 09:52
But we're running the same compiled App::Panda either way
So it can't be anything wrong with the compilation of the callsite
brrt agreed 09:53
seems like a desparately unlikely bug at any rate 09:54
do you agree the interaction between JIT and inlines is pretty small
jnthn yes
OK, if I --profile panda install Grammar::Debugger, it's kinda interesting 09:55
I can tell, for example, that we don't pull a result out of the multi dispatch cache at all 09:59
Because we do enter the multi-dispatcher 10:01
10:01 Ven joined
jnthn Now, it's *possible* that we do some inlining of some sort inside the multi-dispatcher itself that causes the mis-compile 10:01
But none of this explains why the "return" affects things
brrt ahah...
well, return is an exception innit 10:02
brrt goes to lunch &
jnthn yeah but in the crash case we never make it as far as the return
brrt that is kind of true
brrt has vanishingly little knowledge of dispatcher inner workings
see you in a bit over an hour :-) 10:03
jnthn I can clearly see from the profiler that the multi-dispatcher is one huge call frame that only calls one thing (add_to_cache) and is not JITted in any way and there's nothing to inline 10:07
Add to cache is spesh'd but also a terminal frame
10:47 FROGGS_ joined
jnthn has tried various things as is now down to binary searching his way to the frame whose inlining busts things 10:49
11:01 aiacob joined 11:11 brrt joined
brrt jnthn++. i wonder how you do such a binary search? 11:12
that's much less crude than my exhaustive search methods
jnthn brrt: Just keep a static int in inline.c :) 11:13
So far
// 475 good, 481 bad
// 476 good, 478 bad 11:16
OK, if we refuse to inline the 478th frame that we're asked to do so, things work :) 11:20
brrt oh, wow 11:22
well, which frame is that
and which frame is the inliner
jnthn Just been confirming either side of that have no influence; they don't 11:28
Guilty: inlining EXPR (cuid_577_1443021743.859) into arglist (cuid_494_1443021743.859)
brrt aha 11:30
can we haz look at which those are
reduntdant jnthn++ :-) 11:31
jnthn Yeah, am looking at le spesh log at the moment 11:35
I see we have 3 inlines in the bad/crashing case, and 2 in the good case where I stop it doing the one that causes issues
brrt uhuh
jnthn And it's the first of the inlines 11:36
11:38 Ven joined
jnthn Well, wow 11:39
Here is the EXPR method that we inline
method EXPR(str $preclim = '') {
# Override this so we can set $*LEFTSIGIL.
my $*LEFTSIGIL := '';
my $*IN_RETURN := 0;
nqp::findmethod(HLL::Grammar, 'EXPR')(self, $preclim, :noinfix($preclim eq 'y='));
}
Note the $*IN_RETURN
This prevents promotion of colonpairs to nameds
And failing to clear it would thus cause problems 11:40
The next question is: how does dynamic variable lookup with inlined frames intersect with JIT?
brrt aha
good... question
dynamic variable lookup, i suspect, is handled by.. getdynlex? 11:41
jnthn I suspect MVM_frame_find_contextual_by_name is where to look
brrt :-)
jnthn Yeah, the ops for doing it converge on that function I noted
It's not simply that it is unaware of JITtedness though
if (cand && cand->num_inlines) {
if (cand->jitcode) {
brrt oh, lord, did i touch that code 11:42
brrt apologizes for that code
jnthn It's not worse than the non-JIT case though 11:43
I mean, in theory it's doing an extent list search
brrt uhuh
two possiblities; a) the jit return label isn't set correctly 11:46
b): the inlines table isn't built correctly
jnthn It's odd how hard it is to reproduce 11:51
oh wait
lizmat
.oO( the tension is building )
 11:52
jnthn I still didn't manage a small reproduction of it. 11:58
m: class C::C { }; EVAL 'sub foo() { return C::C.new(a => 1, b => 2) }; foo()' for ^100 12:03
camelia ( no output )
jnthn m: class C::C { }; EVAL 'sub foo() { return C::C.new(a => 1, b => 2) }; foo()' for ^500
camelia rakudo-moar f89dc2: OUTPUTĀ«Default constructor for 'C::C' only takes named argumentsā¤ in sub foo at EVAL_104:1ā¤ in block <unit> at EVAL_104:1ā¤ in block <unit> at /tmp/C2xdzB3Egh:1ā¤ā¤Ā»
jnthn There you go 12:04
brrt oh wow 12:07
brrt is going to add just that test to the jit-test-repo
jnthn Think it's lunch time here :) 12:08
brrt well deserved too :-)
jnthn brrt: Dunno if you want to explore this from here? I can dig back in again if not.
brrt i want to explore, but i can't guarantee timeliness in that regard :-) 12:09
brrt wonders why the EVAL is necessary? 12:10
jnthn brrt: Because we need to get the *compiler* hot
It *is* a mis-compile after all 12:11
brrt aha....
jnthn I forgot panda no longer does pre-comp.
brrt aw, that hurts
cognominal what is pre-comp? 12:39
[Coke] pre-compilation. 12:40
taking a .pm file and compiling it to bytecode, then running the bytecode later instead of the .pm
cognominal Makes sense. So why panda does not do it? 12:42
[Coke] because perl6 should be doing it.
and no one was making perl6 do it because panda was doing it. (panda can only do it in very limited cases, whereas perl6 could do it as a matter of course) 12:43
cognominal ok
thx
brrt jnthn: github.com/bdw/jit-test fwiw :-) 12:45
seems very sensitive to adding 'say's before and after
as in
crashes quite differently in other cases
jnthn back 12:51
brrt \o 12:52
i haven't gotten arround to debugging it, by the way 12:58
jnthn np
I'll leave it for somebody else to debug the JIT labels for now, and look again tomorrow if nobody figures it 12:59
brrt very well :-) we have at least a reliable testcase 13:00
13:01 Ven joined 13:36 Ven joined 13:43 FROGGS joined 13:55 TimToady joined 14:17 Ven joined 14:34 Ven joined 14:43 tokuhiro_ joined
hoelzro o/ #moarvm 15:02
15:44 tokuhiro_ joined 15:53 Ven joined
hoelzro if the program break of a program running on MVM is steadly increasing over time, there's probably a memory leak, right? 16:28
I think I found a memory leak when calling a sub that uses subsignatures, but I want to confirm my suspicions here before blowing smoke 16:30
17:20 cognominal joined 17:23 Peter_R joined 17:46 tokuhiro_ joined 18:03 FROGGS joined 18:21 tokuhiro_ joined 18:22 vendethiel joined
masak hoelzro: sounds likely, yes. 18:34
hoelzro alright, this should be a fun RT to write then =) 18:39
jnthn valgrind's memcheck may help pint out what's leaking 18:58
uh, point
lizmat cheers! 18:59
FROGGS skol!
jnthn :D
hoelzro jnthn: I looked at memcheck last night; it gave me a lot of hits, though 19:07
jnthn Yeah. You can maybe get a few less by running Moar and asking it to try and clean up
I forget the name of the flag.
hoelzro and the weird thing was that I have two versions of the program, one with and one without the supposed leak
ahhh
I'll try that
I suspect the binder, but that's more a hunch 19:08
19:51 lizmat_ joined 20:04 lizmat_ joined 20:22 tokuhiro_ joined 21:24 TimToady joined 22:24 tokuhiro_ joined 23:25 tokuhiro_ joined

Powered by Cro and the RakuĀ® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!