timotimo (well, the first 2 gc runs actually left 17% in there and the third one left 10% in there, but that was probably due to stuff being compiled and stuff) 00:10
00:12 ventica joined
japhb I think you're basically confirming that our allocation and lifetime patterns match the generational hypothesis. :-) 00:50
timotimo yup. 01:02
dalek arVM: f4536ef | TimToady++ | src/ (3 files):
instrument dynvar lookup for logging
 01:13
TimToady initial analysis of dynvars: gist.github.com/anonymous/ea75f8c3c12022fd9c39 01:16
first section is with no caching, second section is jnthn's current code
a large part of the problem currently is collisions with other names, since we populate the cache too much 01:17
so for instance, while $*W has an average frame depth of 44 without the cache, the cache only cuts that down to 29 on average 01:18
so yeah, I think we can do much better
dalek arVM: 4151c4f | TimToady++ | tools/dynvarcost:
add dynvarcost script
 01:20
japhb * Only Sept 16-18 have scheduled activities, 15th and 19th are dedicated for travel
* Only non-stop flights are on Aer Lingus, SFO ā†”ļøŽ DUB
* Not all days are available
* Best I found was leave SFO Sunday the 14th, return Friday the 19th, $1412 round trip
D'oh
Damn paste buffer 01:21
TimToady irssi can stop that...
timotimo as can weechat 01:22
TimToady dinner &
timotimo japhb: i'm yearning for some feature that'll show me what checkouts have commits from what date, or at least sort by commit date or something 01:23
(for perl6-bench)
japhb History view already sorts by commit date, but I'm guessing you mean for compare view? 01:24
timotimo more like for "list" view 01:25
right now i'm unsure what commit to include between the current nqp head and 2014.07
japhb Isn't there a `bench list-tags` with dates? I thought I did that. 01:26
timotimo oh?
yikes!
this command is *very* unhappy :)
japhb Oh dear. I'll take a look on the bus. 01:27
timotimo fatal: ambiguous argument 'MadMongers^{commit}': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
1970-01-01 MadMongers
japhb japhb.move-to($bus-stop);
timotimo it outputs this for every single commit of everything forever
i guess i want list-checkouts to also show the date of the revision 01:28
japhb timotimo: What version of git do you have? 01:35
timotimo git version 1.9.3 01:36
this is what i ended up doing btw: for path in *; cd $path; git lg | head -1; cd ..; end
gist.github.com/timo/b733145ba7e73ef0d2b8
01:38 FROGGS__ joined
timotimo t.h8.lv/p6bench/2014-08-06-with_new_match.html - jnthn, this compares a revision before and after the new implementation for nqp Match object creation and the latest release 01:38
only the json benchmarks are very interesting, i'd thinsk
japhb timotimo: What is 'git lg'? I'm assuming it's an alias, but defined as what? 01:40
timotimo `git lg' is aliased to `log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %Cblue<%an>%Creset' --abbrev-commit --date=relative'
i wish i remembered where i picked up this beauty 01:41
japhb Oh now that is nice. 01:45
timotimo aye
japhb And here's a very simple bash helper I like: gpr () { cur=`git rev-parse HEAD`; git pull; git log -p --reverse $cur...; }
gpr here standing for 'Git Pull and Review'
01:47 ilbot3 joined
timotimo in case you don't get mails delivered to your bus, i opened a few issues on perl6-bench to track my feature requests 01:47
o/
02:03 ventica joined
japhb timotimo: Hmm, my git is a 2.0; perhaps ^{commit} only came in the 2.0 series? 02:03
If so, I'd like to find a backwards-compatible variant. 02:04
03:11 cognome joined 03:35 egrep joined
egrep wonders if this is an error given by moarvm... sprunge.us/OOdK 03:38
I actually have a lot more output, though, if it helps: gist.github.com/egrepnix/ecf20c44365e26afbf2e and gist.github.com/egrepnix/a90a9a29040f2c8bd5a9 03:54
05:57 ventica joined
sergot o/ 06:23
06:25 brrt joined 06:40 ventica joined
brrt \o 07:22
ok, i've inspectedthe use of MMV_args_get_pos_* 07:27
and there are two things people want from that function
functions 07:28
a): the value b): the existence
mostly the value, though 07:29
07:32 btyler joined 07:43 cognome joined
dalek arVM: 37d4ac6 | TimToady++ | src/core/frame.c:
use better dynvar cache
 07:53
TimToady that saves nearly another second
brrt \o/ 07:54
TimToady latest dynvar stats at: gist.github.com/anonymous/8db7bdfb5f3ac4c79bd3 07:59
07:59 btyler joined
TimToady gets the average search down from 11 frames to 5 frames (no cache was 17 frames average) 08:00
nwc10 brrt: ASAN gets SEGV on setting build 08:03
08:03 synopsebot joined
nwc10 #0 0x7f6d1a6bf2da in MVM_coerce_istrue src/core/coerce.c:43 08:03
brrt ASAN knows why?
hmmm
nwc10 ==20917==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000050 (pc 0x7f6d1a6bf2db sp 0x7fffe83f9650 bp 0x7fffe83f96b0 T0)
that would look like a NULL pointer deference
brrt very much
question
TimToady could be my fault 08:04
brrt why's that a NULL pointer
unlikely TimToady, unless you work on moar-jit :-)
nwc10 TimToady: I'm not sure because ... what he said
dalek arVM: 4ed81a1 | TimToady++ | src/core/frame.c:
make sure 'from' isn't null
 08:05
TimToady okay, well, just fixed my potential problem anyway
08:13 daxim_ joined
dalek arVM: a86dd6a | TimToady++ | src/core/frame.c:
be slightly more desperate on high icost
 08:22
TimToady zzz & 08:30
jnthn TimToady++ 08:31
brrt sleep well TimToady 08:37
++ indeed
bbiab 08:38
dalek arVM: 24fab9a | jnthn++ | src/core/frame.c:
Tabs -> spaces, for consistency.
 08:50
arVM: 3ddf3ce | jnthn++ | src/core/frame.c:
Re-ordering to fix MSVC build.
08:52 ggoebel1111110 joined 08:53 btyler joined 08:54 sergot joined, ashleydev joined 08:55 lue joined
jnthn gets his first Rakudo build in under 65s, and first NQP build in under 35s, with the TimToady++ patch 09:00
09:09 brrt joined
brrt back 09:10
jnthn morrning, brrt 09:12
brrt morning jnthn :-)
jnthn So, what's the latest explosion status? :)
brrt still exploding 09:13
depends on decont, findmeth, box_s, elemt, getattr_i, , bind_pos_i
still no idea why :-(
i'm also at some point of frustration with regards to the args refactor thingy
jnthn args refactor? 09:14
brrt i.e. returning structs as MVM_args_get_(pos|named)_(int|str|num|obj) is not really well specified, and rather depends on the size of the struct, the compiler, and the phase of the moon
sometimes they're returned using a passed-pointer to pre-allocated stack space 09:15
sometimes they're returned in two registers
ABI specs don't really tell which
so, i really need only two things: the value of the arg, and the existence
jnthn ah 09:16
Might be better switching to two out parameters...
brrt hmm
that'd be ok, i guess 09:17
jnthn Seems the JIT gets a decent bit further into CORE.setting now... 09:19
jnthn is waiting for it to explode
brrt really?
:-o
brrt doesn't believe it
jnthn uh. It failed to explode here.
Like, it completed a CORE.setting build 09:20
brrt ok, what
do you have findmeth commented
jnthn oh, I'm just at HEAD on moar-jit 09:21
I thought we uncommented it after the last fix?
brrt no, haven't 09:22
sorry about that
jnthn findmeth and findmeth_s don't seem commented in jraph.c
*graph
And I've no local diffs
Oh, but sp_findmeth is commented still 09:23
nwc10 Stage parse : 189.589
that's with ASAN
I've not seen it that low before
jnthn Setting limbo!
masak .oO( how lo' can you go ) 09:24
jnthn Exactly :P
brrt :-) 09:26
bbiab
jnthn brrt: Evening uncommetning sp_findmeth in graph.c doesn't get me any errors
nwc10 that may well mean now that MoarVM built with debug + ASAN is as fast as optimised parrot
jnthn Now building with moar-jit and a 32kb nursery to try and hit a GC issue 09:32
Failed so far :(
It's in stage mast and failed to fail. Hmm. 09:42
Yup, completed. 09:45
09:58 brrt joined
brrt :-o jnthn your computer must be broken 09:59
or, you don't have JIT enabled?
jnthn I'm fairly sure I did... 10:00
I checked MVM_JIT_DISABLE was cleared in my env too
brrt i'm building from clean scratch now
ok
MVM_JIT_LOG gives you a real log file even?
jnthn I didn't try that 10:01
And I'm working back in another branch now...
brrt well, i'm retrying anyway
:-)
10:01 FROGGS[mobile] joined
brrt still blows up for me 10:03
jnthn You agree HEAD has findmeth and findmeth_s uncommented, though? 10:04
So it's just sp_findmeth that is commented?
brrt i agree 10:05
jnthn OK
And it's sp_findmeth that breaks things nowadays?
brrt no
it's still breaks with only findmeth and findmeth_s for me :-(
but, maybe it breaks differently? 10:10
nwc10 m: say 5.7776e+01/5.8165e+01; say 5.7776e+01/6.597e+01
camelia rakudo-moar 3f3abe: OUTPUTĀ«0.993312129287372ā¤0.875792026678793ā¤Ā»
nwc10 so a bit faster still since the last time that I measured it, and quite a lot faster than the first time I remembered to measure it
(and also ASAN is happy) 10:11
brrt exact same crash as yesterday 10:12
in the decont of some value
$*LEFTSIGIL, how is that looked up? 10:15
jnthn getlexdyn
or getdynlex
can never remember which way around it goes :)
brrt hmm 10:16
getdynlex isn't quite implemented
also
MVM_SPESH_DISABLE_INLINE=1 .... fixes my problems
fuuuuuu
jnthn That may be because without inlining you don't JIT certain frames? 10:19
Also it's MVM_SPESH_INLINE_DISABLE ? 10:20
10:20 jimmyz_ joined
jnthn Also it's MVM_SPESH_OSR_DISABLE ? 10:20
opos
d/Also it's/Did you try/
jimmyz_ Stage parse : 33.332, before ~34.3s, Stage mast : 10.960, before ~12.3s
since yesterday 10:21
brrt OSR_DISABLE makes no difference
very nice
and yeah, i did INLINE_DISABLE
possible, but weird, and unexpected; inlining would make frames bigger, thus less likely to be compiled 10:22
jnthn True 10:25
brrt it's very likely one of those Very Big Frames 11:13
but, i've some good news as well i think 11:35
there are only five of these 11:36
so what i can do is pinpoint-disable them by inserting an unjittable op (callercode or something weird like that)
and... see what that does
jnthn Sounds good 11:38
brrt ok, disabling MARKER in nqp/src/HLL/Grammar.nqp has sufficient effect 11:46
i'm wondering if my isnull check is correct
jnthn That wouldn't easily explain junk... 11:52
brrt no
and... disabling _ws /also/ makes it work 11:54
wow, disabling any of them makes it work 11:59
:-(
oh, my bad 12:12
12:18 cognome joined
jnthn grr, I musta done something wrong when I built this morning 12:36
jnthn gets NQP fine but a JIT setting build crash now too
12:43 jnap joined
jnthn wtf...if I turn on MVM_JIT_LOG it fails to crash?! 12:47
13:06 brrt joined
brrt what 13:07
jnthn yes, my thought exactly 13:09
brrt :-(
jnthn If I try to dereference the thing in getdynlex it does crash there 13:10
is bindlexdyn JITted? 13:11
Seems not 13:14
brrt: Update: 13:21
If it is $*LEFTSIGIL then we can look at what binds it that we could JIT 13:22
brrt bindlexdyn is not JITted
jnthn And there's only one place that accesses it directly as a lexical
Right, I found that
brrt and that is?
jnthn method EXPR in src/Perl6/Grammar.pm
We never JIT that
However, it gets inlined. 13:23
brrt yes
in modifier_expr
jnthn And arglist
brrt which is the /single/ frame that i can conclusively show to break
arglist i cannot 13:24
13:26 woolfy left
brrt gist.github.com/bdw/3bd68be793514c2f7ddb is the breaking frame 13:30
jnthn Concur it seems to be modifier_expr
Oh...darn.
How do I check if we're in JITted code in an MVMFrame? 13:31
brrt if you disable it in src/Perl6/Grammar.nqp:1578 by adding an effectless line to nqp::callercode(), and it unbreaks
:-)
jnthn Or, were before we left it?
oh, I guess spesh_cand and jitcode are set...
brrt basically, if we've been invoked from a JITted frame, somewhere along the caller chaing, spesh_cand and jitcode should be said
i've not had great effect with that, but it's possible 13:32
s/said/set/
if we've returned a value from the jitcode, you're out of luck 13:33
jnthn ->return_address is not valid when we're called from jitted code?
brrt it should be valid, yes 13:35
but it should always refer to the MAGIC_BYTECODE variable
jnthn Certainly can reproduce modifer_expr issue 13:38
brrt \o/ 13:39
that's something
the only good bugs are reproducable and isolated :-) 13:40
brrt bbiab :-)
jnthn The code I think is guilty is in MVM_frame_find_contextual_by_name 13:43
Of note, the inlines searching bit
dalek arVM/moar-jit: dded577 | jnthn++ | src/jit/emit_win32_x64.c:
Updated win32 JIT emitter.
 14:19
arVM/moar-jit: 02e2e41 | jnthn++ | src/core/frame.c:
NULL the return_address in new frames.

Otherwise, we might invalidly end up considering us inside of some kind of inline because we see a return address from a prior use of the frame.
arVM/moar-jit: 5595f46 | jnthn++ | src/core/frame.c:
Disable dynlex-in-inline caching for now.

  See comment in code for why; exposes something that needs changes for
JIT. (The same issue exists for deopt_all, and the same solution can cover both of these: building JITted extent lists of machine code addresses for the inlines. Very similar to what's needed for the exception handler regions too.)
jnthn brrt: No SEGV, no cry... 14:20
timotimo how far do we get now? sanity tests and spectests?
jnthn Sanity tests pass
jnthn kicks off a spectest run 14:21
timotimo nice! :)
jnthn Into S03 with no fails so far
timotimo without latest master merged in, we ought to expect a segfault in the threads.t thingie 14:23
jnthn spectest looks pretty good 14:27
Bunch of thread fails that are likely due to the thing you jsut mentioned
timotimo that sounds very good
jnthn aye 14:29
timotimo i'm glad
does that mean we have all the ops uncommented now?
jnthn I didn't uncomment sp_findmeth 14:30
But it likely can be.
14:47 brrt joined 14:51 ventica joined 14:53 ventica2 joined
brrt :-o jnthn++ very much 14:55
brrt is now testing on his own system
omg it works! 14:58
ok, so the main thing to do, it seems, is to compute the 'machine code borders' of the inline? 14:59
and i suppose the deopt_point_inline annotation determines where that border is? 15:00
jnthn Yes
It's basically the same problem as for exception hander regions
Those too being marked out by annotations 15:01
brrt very well
i'll argue that exception handlers are a wee bit more complex 15:02
because you also have a 'exception handler goto point'
and.. i suppose that's just the point you jump to after you've 'caught' a handler between two borders?
jnthn Yes, you're right 15:03
brrt ok.. so how is a single handler constructed?
sp_findmeth basically passes with colours
timotimo our bytecode has colors? 15:04
jnthn Well, handlers are kinda interesting
brrt do tell :-) 15:05
jnthn The key is .action
Some handlers simply one you to goto a certain position. Those are the easy ones.
The other case is that they want to invoke a block
And the block then does the handling 15:06
The block runs on the stack top before any kind of unwinding.
brrt ok
jnthn But that's basically invokey behavior
Just need to be aware that there'll be an unwind afterwards unless it does a resume. 15:07
timotimo i wonder what kind of introspecty things we could offer to users of MVM-based languages
like, can we offer a function that'd make mvm dump the bytecode of a given callable, for exampae?
jnthn So I think you don't need to do too much special for the invokey handlers. 15:08
timotimo from within a repl session, for example
jnthn Though the unwind after them is more interesting
So in that case goto is still interesting
But "afterwards"
brrt hmm 15:10
ok, i'll read though the source and determine a course of action 15:14
much jnthn++ by the way for resolving the bug :-)
jnthn np :) 15:17
BTW, given --enable-jit is needed to actually enable a build with JIT, and that things do basically work now, we may want to consider the merge to master.
timotimo i would like that 15:18
it would make running stuff with the perl6-bench tools easier
jnthn It's nice to have it done ahead of the soft pencils down date, I think. :)
brrt yes, i agree
timotimo aye, they recommend to do things like documentation between soft and hard pencils down 15:19
brrt we have something, if not everything, now
bugfixes are allowed, too :-)
timotimo right
you can even do more stuff, but it won't be considered for the gsoc, right?
brrt hmmm.... that depends on who judges, i think 15:20
and i have no idea of that
who judges the code or on what criteria 15:21
i'm off preparing dinner 15:22
(i seem to live two hours earlier than the rest of you, even though we're in the same time zone. weird)
timotimo heh. :) 15:23
15:23 brrt left
nwc10 JIT still gets to the end of spectest with ASAN 15:26
jnthn nwc10: You are configuring the build with --enable-jit ?
nwc10 t/spec/S32-str/encode.rakudo.moar still fails, but that's a #perl6
jnthn The encode.rakudo.moar is a Moar regression actually :(
nwc10 yes. More importantly, I'm then using that moarvm, and not a JIT-free one :-)
jnthn OK :) 15:27
nwc10 This is MoarVM version 2014.07-301-g5595f46
timotimo is that the "iteration past end of grapheme iterator" explosion?
jnthn No
It's an icky fallout of the lazy deserialization stuff
timotimo OK 15:28
jnthn It has a subtle reliance on deserializing everything in the order it showed up in the SC.
Which we no longer do.
timotimo oh, that's not good 15:29
who knew i never knew how to mvm :) 16:18
i have to root root!
tbh, i never grokked how the parameters to MVM_ASSIGN_REF work ... 16:19
how come i see no MVMROOT usages in other initialize methods? 16:25
jnthn They don't allocate?
Except KnowHOWREPR maybe
timotimo knowhowrepr pushes the root temporarily
so i guess that's all right
jnthn Yeah
MVMROOT is sugar for that
It came later
timotimo righto 16:26
jnthn: do we already do something in spesh for the action methods when parsing stuff? 16:27
since the action class is unlikely to be switched out in the middle?
dalek arVM: 7cb553a | (Timo Paulssen)++ | src/6model/reprs/MVMCompUnit.c:
need to root root and assign ref in MVMCompUnit::initialize
 16:31
jnthn timotimo: No, 'cus the action methods aren't, sadly, called directly from the rules 16:38
16:39 FROGGS[mobile] joined 16:40 itz joined
dalek arVM: 5fc5a59 | jnthn++ | / (8 files):
Stub async process control ops.
 17:10
arVM/moar-jit: 0e369b3 | (Bart Wiegmans)++ | src/jit/emit_ (3 files):
Simplified some ops implementations
 17:36
arVM/moar-jit: 99f3c37 | (Bart Wiegmans)++ | src/jit/graph.c:
Re-enable sp_findmeth

  jnthn++'s change fixed the problems for sp_findmeth as
well as the regular findmeth.
17:36 brrt joined
brrt \o 17:36
brrt is excited about renewing progress
for those who are interested, i'm building moar without gcc optimizations - this moves the time for building core.setting up to 50 s - but JIT with sp_findmeth reduces that to 46 s 17:38
can we implement getdynlex, or will that pose a problem? 17:41
oh, i think it will 17:42
for the same reasons as before 17:46
:-)
jnthn I think the inliner refuses to directly inline getdynlex 17:49
The bug isn't about getdynlex itself, it occurs when the lexicals are declared in frames that get inlined.
So I don't think it'll be a problem, off hand.
brrt: Any objections to me having a crack at extops JIT this evening? 17:50
brrt no, not at all
:-)
jnthn OK. Fine if I merge latest master in too?
brrt sure
i'm not sure how you would want to do it, but i would have started with adding a special node 17:51
that node would contain the function pointer, the ins info (invokish etc), and the argument array
the argument array.. i was hoping we could let the spesh codegen do most of that - i.e. i see little reason to replicate it in jit/graph.c or something lik ethat 17:52
and what i was hoping even more is to simply use the encoded arguments of the spesh cand's bytecode, i.e. take a pointer into that array 17:53
then, assuming the speshed bytecode won't move afterwards, you can embed the pointer directly
otherwise, you'd need to manage an array of encoded arguments in the JitCode and JitGraph structures, and i hardly feel for that 17:54
anyway, it's up to you, i'll probably be busy dealing with handlers and afterwards with dynlex 17:55
one more thing that you've probably already seen but is relevant anyway: if you're storing pointers directly, beware that - because of dynasm function signatures - they are passed in two pieces (upper and lower 32 bits), so you'll have to use the special mov64 opcode and cast the pointer to an integer type of sorts 17:58
nwc10 brrt: JIT build fail 17:59
Too many positional parameters passed; got 2 but expected 1 at gen/moar/stage1/NQPHLL.nqp:2072 (gen/moar/stage1/NQPHLL.moarvm::107)
brrt what 18:00
oh
hmm
..... fuuuu 18:01
that's with sp_findmeth only, right? 18:02
nwc10 yes, that most recent commit
clean build
brrt bloody... 18:03
jnthn nwc10: And the commit immediately before it was clean? 18:06
nwc10 All tests successful.
yes
jnthn If it's calling the wrong method, it could be that it's a mistake in validating whether we should use the cached thing 18:08
dinner; bbiab
brrt yeah... or maybe the invokish test isn't very good 18:10
and.. that's not it, either 18:11
this is by the way, the undebuggable bug from earlier :-( 18:14
jnthn back 18:36
nwc10 JIT build good all the way to spectest at 0e369b3a31c74381678e047cbfe73db0e520c044
fail on HEAD is for 18:38
/home/nicholas/Sandpit/moar-g-jit/bin/moar
--libpath=src/vm/moar/stage0 src/vm/moar/stage0/nqp.moarvm --bootstrap --module-path=gen/moar/stage1 --setting-path=gen/moar/stage1 --setting=NQPCOR
E --no-regex-lib --target=mbc --output=gen/moar/stage1/QAST.moarvm g
en/moar/stage1/QAST.nqp
valgrind finds nothing wrong
I can't see how to help further. And all I can really say is that it's not undefined behaviour. Something in the code is wrong. 18:39
brrt basically, there's an error that creeps in during the compilation of NQPHLL.nqp 18:43
that error then breaks the compilation of QAST.nqp
why should this be so? well, no idea, really
nwc10 it's a stage 1 error 18:44
brrt it also happens in stage2 :-)
nwc10 sure, but a clean build doesn't get that far
brrt you can work arround it by disabling jit in the compilation of NQPHLL
nwc10 is it possible to diff the outputs of stage 0 for JIT and not-JIT?
I infer that the divergent behaviour is happening at runtime of stage 0 18:45
while stage 0 is compiling stage 1
brrt yeah, i think that's possible
although
how to interpret the difference?
nwc10 stop asking sensible questions :-) 18:46
I think, if you can identify which stage1 output file(s) have differences
you can then start to figure out which bit of code running at stage0 is differing 18:47
brrt that... seems like sensible even if not entirely feasible 18:48
jnthn I can reproduce the issue on Windows too, fwiw
Looking at the backtrace, it happens while loading NQPHLL 18:50
brrt :-( 18:51
brrt bbiab
dalek arVM/moar-jit: a9906fa | jnthn++ | src/mast/compiler.c:
Don't hunt for outer frame index if it's cached.

This was, curiously enough, one of the biggest time sinks in the entire assembly of large things like CORE.setting. 3bad756 | jnthn++ | src/core/bytecodedump.c: Unbust bytecode dump after lazy frame loading opt.
18:52 dalek joined
jnthn That brings in latest stuff from master 18:53
The call to new_type in: 18:58
my $knowhow := nqp::knowhow().new_type(:repr("P6bigint"));
Is being compiled as:
00103 prepargs Callsite_5
00104 arg_o 0, loc_15_obj
00105 arg_s 1, loc_16_str
00106 invoke_o loc_15_obj, loc_17_obj
Which means it really does have a positional arg there instead of a named one in the compiled output 18:59
FROGGS too bad, the commit is 3bad 19:06
jnthn I think I can imagine what's going wrong here 19:15
When we attach a named arg to something, it mixes in
Mixing in does deopt_all
But we don't know how to deopt JITted frames yet
cannot deopt from jitted frame named 19:16
cannot deopt from jitted frame colonpair
timotimo good catch 19:17
jnthn (if I put in a line to note the times we fail)
So yeah, it's a known todo.
timotimo that's definitely good to know 19:21
19:26 brrt joined
timotimo there's certainly a lot of mysteries around the whole jit topic 19:28
brrt jnthn++ for brilliance :-o
am i correct in assuming that if and when we have the extent-list-for-JIT-inlines-and-handlers (ahum) 19:30
then we can fix this?
timotimo the elfiah? 19:32
jnthn It's related, yeah...
brrt elfiah? 19:42
timotimo the Extent List For Inlines and Handlers
vendethiel
.oO( the elvish trees have spoken )
brrt likes that 19:43
ugh, complexity is greater than assumed 19:56
although the deopt stuff seems like it should be doable if it can be started correctly, like in deopt_one 20:05
20:10 odc` joined 20:16 klaas-janstol joined 20:29 jnap1 joined 21:09 ventica joined 21:34 lizmat joined 21:44 woolfy joined 21:55 woolfy joined 22:25 klaas-janstol joined
dalek arVM/moar-jit: aafb3aa | jnthn++ | src/ (6 files):
Fix deopt_all under JIT compilation.

This records the JIT labels that map to each deopt all index, so we can turn a jit_entry_label into a deopt index at the time we need to deopt all. Fixes the crash in the NQP build under the JIT due to the named parameter QAST construction mixing in and triggering deopt_all. This is Fisher Price My First JIT Patch (TM); review suggested.		 22:32
jnthn suspects brrt++ will be happy to see this in the morning. :) 22:33
Hope it works on Not My Machine too... :)
timotimo i can try it :) 22:34
japhb imagines a Happy Fun Ball style spoof commercial for My First JIT Patch
timotimo was able to build nqp from scratch 22:36
(well, from scratch is wrong of course. i didn't create the universe first)
jnthn timotimo: yay 22:37
timotimo parse is at 34 seconds right now, but my computer is quite busy with other stuff
jnthn That was quite a fiddly one to write. But all deopt-related patches have been...
timotimo even sanity tests work fine! 22:38
jnthn Rakudo ones too :) 22:43
timotimo the rakudo tests, yes
jnthn oh, yeah, for some unknown reason I thought you meant the NQP ones 22:44
timotimo the beginning of the spectest looks good
oh well 22:46
===( 20312;143 8/10 1/9 1/6 )=====================================*** Error in `/home/timo/perl6/rakudo/../install/bin/moar': munmap_chunk(): invalid pointer: 0x00007f0336559ebe ***
oh, hold on, do we have master merged in now? 22:47
jnthn What test?
Yes
timotimo t/spec/S17-promise/start.t it seems
jnthn But there's still at lesat one race I know of...
timotimo no, i think times.t is it
Unhandled exception: Contextual name cannot be null and Unhandled exception: Cannot assign to a readonly variable or a value 22:48
this is races caused by the jit or races caused by our recent optimizations to making stuff lazily vivified? 22:51
jnthn The latter, I think 22:52
timotimo OK, so if i want to develop something on moar with multithreaded stuff i ought to go back to 2014.07
well, that's fine
jnthn Was pondering patching it tonight, but ended up doing the jit deopt patch instead 22:54
timotimo that'll allow brrt to continue tomorrow morning
i think the decision was good.
jnthn aye 22:55
I know deopt can be horrible, and didn't really want him to lose another day to it
timotimo yeah, far too many bug hunts of his have ended somewhere that was way out of his range 22:56
jnthn Well, a JIT can only be so much of an isolated thing. 23:02
timotimo definitely true
23:06 klaas-janstol joined 23:07 ventica joined
dalek arVM/jit-extops: 16bde9a | jnthn++ | src/jit/graph.c:
An initial sketch of JITting extops calls.

Doesn't yet fully work, most probably because it JITs some that are invokey without handling that, or that mess with interpreter state
  (and so need a mechanism to flag them "don't JIT me").		 23:32
jnthn That's all I've got energy for today... Mebbe I'll be able to finish that up tomorrow. :) 23:33
timotimo wouldn't "don't jit me" just be another flag on the op? 23:34
jnthn yeah, it's not that it's hard, it's just that I'm tired :)
I already added ext op flags 23:35
timotimo right
japhb jnthn: When you're less tired: I added the --min-time option for you to tune the noise thresholding
timotimo good night, then :)
jnthn japhb: Ah, cool. I'll have to do another benchmark run here soon. Hopefully with the JIT on to see how it handles things :)
23:35 oetiker joined
japhb :-) 23:35
jnthn Really need exception handlers to work for that, though, since loops emit them. 23:36
brrt++ was looking at that today though, so maybe we get them in the not too distant future :)
japhb: Weren't you working on some concurrency stuff that spawned various scripts at one point, ooc?
Or spawned various other things, anyway.... 23:37
Anyway, if so, I started working on a Proc::Async today, which should allow rather more efficient handling of such things (e.g. without blocking up a thread per process you spawn) :)
Anyways, yes, good night :) o/ 23:38
japhb jnthn: Oh yay! Yes, I did have a couple variations on a script that would spawn a lot of children, and pretty much eat up the thread pool with that. Will your async spawning include being able to capture (or otherwise attach to) the child's standard handles? 23:42
Oh, in case it wasn't clear ... the --min-time flag is a flag for the analysis phases, and acts as a filter on the timing data. The timing data files always include all the collected info, so you needn't do new benchmark runs just to play with that particular knob. 23:44
timotimo japhb: should we teach perl6-bench to build multiple components in parallel? 23:45
japhb timotimo: I had initially *not* done that because multiple rakudos building at once could OOM a box. But maybe it's time to consider a flag or env var for that. 23:46
timotimo hah 23:47
aye
japhb Let me put it this way ... I'm happy to test async spawn functionality in r-m by implementing parallel checkout builds in p6-b. :-) 23:49
timotimo i'm off for tonight 23:53
o/
japhb o/ 23:55

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!