Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-09-15

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:13 tokuhiro_ joined #moarvm
00:24 colomon joined #moarvm
03:09 orbus joined #moarvm
03:15 colomon joined #moarvm
06:21 FROGGS joined #moarvm
06:42 brrt joined #moarvm
07:05 zakharyas joined #moarvm
07:20 ShimmerFairy joined #moarvm
08:14 brrt joined #moarvm
08:56 dalek MoarVM: fbe6033 | jnthn++ | src/mast/compiler.c:
08:56 dalek MoarVM: Add missing ensure_space when writing label reg.
08:56 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/fbe60337bb
08:57 FROGGS ups
08:58 jnthn valgrind++ made that one easy to find
08:58 jnthn What's a little concerning is that valgrind is still very noisy
08:58 jnthn Oh I see why
09:02 dalek MoarVM: 553fa58 | jnthn++ | src/core/frame.c:
09:02 dalek MoarVM: Make sure refd_by_object is initialized.
09:02 dalek MoarVM:
09:02 dalek MoarVM: So frames that should be cheap to free will be. Also quiets valgrind
09:02 dalek MoarVM: warnings about jump on uninitialized memory.
09:02 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/553fa584ac
09:03 FROGGS valgrind++ :o)
09:04 jnthn Indeed
09:04 FROGGS jnthn: you said you are giving a talk today?
09:04 jnthn But...I still get one write past end of buffer in the same place as before o.O
09:04 jnthn FROGGS: Thursday
09:04 FROGGS or at leasting preparing one?
09:05 FROGGS Perl 6 related?
09:05 jnthn Yeah, I figured I'd do some debugging to get me properly woken up
09:05 jnthn No
09:05 jnthn Well, actually Perl 6 will get a mention
09:05 FROGGS ahh, k, I won't bug you any longer :o)
09:05 jnthn http://www.communityday.se/
09:06 FROGGS ohh nice
09:06 FROGGS so, OO stands for "Ohh, Oops"? :D
09:06 jnthn :D
09:07 jnthn Actually on my slides I wrote the title as "Oh, OOPs" :P
09:07 FROGGS ahh
09:07 jnthn But both puns work for me :)
09:07 FROGGS aye
09:08 jnthn But yeah, we still write past a label register over the end of the buffer. wtf.
09:11 jnthn Actually, it's the label itself
09:14 jnthn ohh
09:15 FROGGS O.o
09:15 jnthn Apparently I should have done slides first, then fix memory errors when awaker :P
09:15 FROGGS *g*
09:15 FROGGS but I also enjoy a nice bug hunt now and then
09:16 FROGGS slides not so much
09:16 nwc10 is there something wrong with your coffee supply?
09:16 nwc10 good decaf, #moarvm :-)
09:17 dalek MoarVM: bfb2236 | jnthn++ | src/mast/compiler.c:
09:17 dalek MoarVM: A more correct fix to handler table writing.
09:17 dalek MoarVM:
09:17 dalek MoarVM: Since we dynamically allocate more inside the loop, we need the basic
09:17 dalek MoarVM: handler size ensure_space inside the loop too.
09:17 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/bfb22361b7
09:18 jnthn And Valgrind smiles on us again :)
09:20 jnthn nwc10: It's nearly empty in fact, but there's enough for one more cup :)
09:20 jnthn Though trying not to drink too much coffee, since it's apparently it aggravates anxiety...
09:56 JimmyZ joined #moarvm
10:00 JimmyZ FROGGS: I upated dyncall and the sync wiki :)
10:01 FROGGS JimmyZ++
10:01 JimmyZ jnthn: https://github.com/MoarVM/MoarVM/issues/234 # valgrind one maybe? :P
10:03 dalek joined #moarvm
10:04 jnthn JimmyZ: It may give clues, aye
10:09 jnthn Seems that the Perl 6 compiler itself ain't threadsafe, even though there's little reason for it not to be
10:10 jnthn The cross thread write log looks highly dubious, however.
10:10 jnthn So I'm suspecting some code-gen bugs
10:45 jnthn Think I've worked out that SEGV that can happen in the STable GC
10:45 jnthn In multi-threaded programs
10:45 timotimo oh, is that one i stumbled upon multiple months ago?
10:45 jnthn Maybe
10:46 timotimo ISTR something like that
10:46 jnthn It crops up now and then
10:46 timotimo but i have forgotten the context
10:46 jnthn MVM_gc_collect_free_stables was in the backtrace near the top
11:19 dalek MoarVM: 7eb097a | jnthn++ | src/gc/orchestrate.c:
11:19 dalek MoarVM: Free STables in a safer place.
11:19 dalek MoarVM:
11:19 dalek MoarVM: We do finalization asynchronously after the stop-the-world phase of
11:19 dalek MoarVM: parallel GC. Freed STables must stay around until all threads have
11:19 dalek MoarVM: completed their finalization, since they contain information that is
11:19 dalek MoarVM: needed for object finalization. Thus, freeing STables after the thread
11:19 dalek MoarVM: that triggered GC is done with its finalization can cause them to get
11:19 dalek MoarVM: freed to early, leading to memory corruption. Instead do it in the
11:19 dalek MoarVM: next GC run, at the start of the world-stopped phase. No difference to
11:19 dalek MoarVM: throughput of single-threaded programs, and should fix an occasional
11:19 dalek MoarVM: crash in multi-threaded programs (though it was tough to reproduce).
11:21 timotimo oh!
11:21 timotimo so that's how
11:21 jnthn Seems so.
11:22 timotimo and for some reason dalek didn't fully report
11:22 timotimo oh well. didn't get kicked at least
11:22 jnthn It only missed the GitHub link
11:22 jnthn Anyways, another concurrency bug down, hopefully. :)
11:22 jnthn We still have some, alas.
11:23 timotimo mhm
11:23 timotimo oh, eew
11:23 timotimo my num ($a, $b, $c, $d); generates code "deep down" that allocates a whole register for the whole frame
11:24 timotimo none of those seem to be re-used for anything afterwards
11:24 jnthn Well, lexicals may be closed over
11:25 timotimo so we have a nan, then a bindlex for each of these lexicals, but the register could totally be re-used
11:25 timotimo but why keep the register around for the whole frame?
11:26 jnthn Oh, you mean a register on top of the storage for the lexical?
11:26 timotimo yes
11:26 jnthn That's worth looking into :)
11:26 jnthn I don't know why, but sounds overkill
11:26 timotimo mayhaps we want to generate these QAST::Var nodes inside their own Stmts node?
11:26 timotimo Stmts is the one that marks used registers as unused afterwards, right?
11:27 jnthn Stmt, but that's about explicit locals, not temporaries
11:27 jnthn Plus various things rely on the QAST::Var nodes being top level
11:27 timotimo or should we have a special handling for the first child of a QAST::Block?
11:27 timotimo hmm.
11:27 jnthn Don't think so, sounds like a more generic issue to me.
11:28 timotimo well, the Var isn't top-level to begin with, as its parent is a Op(bind)
11:28 timotimo but we likely have that handled in the code explicitly
11:28 jnthn *nod*
11:28 timotimo the work area of a frame gets allocated with the fixed-size-allocator, doesn't it? so improving this won't give fewer GCs?
11:28 jnthn Work area is not GC-able
11:29 timotimo thought so
11:29 jnthn It will lead to less memory use
11:29 jnthn But not fewer GCs
11:29 timotimo and more cache-friendlyness
11:29 jnthn Right
11:29 timotimo marking the frame is not likely faster, as native registers don't have to be skipped "purposefully", right?
11:30 jnthn Can't remember exactly how it is, but it may be a bit faster
11:31 jnthn Using less registers has small nice consequences all over
11:31 timotimo sure
11:31 jnthn Lunch time here, and then back to my slides, now I've fixed a few things. :)
11:31 timotimo 'k :)
11:31 timotimo good lunch!
11:41 timotimo huh. the simplest approach i could think of ... and nqp and rakudo still compile?!
11:42 timotimo (just releasing the register used for the $*BINDVAL of a lexical inside compile_var)
11:42 timotimo ah, now things blow up :)
11:44 jnthn Wsa gonna say, that sounded a bit too simple ;)
11:47 timotimo :)
11:47 timotimo might just be a my $want := $MVM_reg_void; instead of my $want; at the right spot
11:47 timotimo oh, that's also not right
11:48 timotimo Void return not allowed to context requiring a return value
11:54 timotimo wat
11:54 timotimo This representation (Null) does not support elems
11:54 timotimo how did i get to this? :D
12:00 timotimo not yet reaching something workable, maybe a different approach is needed
12:00 timotimo (different from compiling the first child of a block differently from the rest of the block)
12:19 timotimo seems like i'm getting a tiny bit further, but now an INIT block that sets up the %cclass_code inside nqp's QAST.nqp is stumbling over a little problem
12:19 timotimo seems like this approach is pretty brittle
13:11 timotimo i would have expected releasing the result register of the bindval if the current want is void would be all right
13:12 timotimo but it doesn't seem to be, and the problem is in some generated code and shows up in execution, so i don't really have the QAST dump that goes with that handy ...
13:18 * timotimo just dumps the whole ast of the core setting ...
13:19 timotimo oh yikes
13:19 timotimo KnowHOW methods must be called on object instance with REPR KnowHOWREPR
13:19 timotimo at gen/moar/stage2/QASTNode.nqp:401  (/home/timo/perl6/rakudo/../install/share/nqp/lib/QASTNode.moarvm:dump_extra_node_info:0)
13:19 timotimo that's not so good, eh?
13:38 timotimo seems like it wasn't my changes that cause this problem, it also happens with a clean nqp + rakudo
13:58 zakharyas joined #moarvm
14:31 vendethiel joined #moarvm
14:36 synbot6 joined #moarvm
15:16 tokuhiro_ joined #moarvm
15:19 timotimo with the simple addition of a try in dump_extra_node_info, i can get a full dump of the core setting again
15:20 timotimo from the qast it looks like there's a stmts where the result of a p6scalarfromdesc is bound to a lexical and the return value of this stmts is supposed to go into p6bindattrinvres, but it seems like my change of the mast compiler throws that result away instead
15:23 TimToady joined #moarvm
15:24 timotimo now why would it be that the compiler thinks the want is void in that case?
15:25 timotimo i know so little about the mast compiler's innards :|
16:18 tokuhiro_ joined #moarvm
16:46 nwc10 jnthn: ASAN barfage http://paste.scsys.co.uk/498726 t/spec/S15-nfg/many-threads.t
16:46 nwc10 it's a race. often is works
16:51 TimToady joined #moarvm
16:53 jnthn nwc10: Wow, nice find!
16:54 nwc10 I just took an educated guess that a failure of "planned 4, ran 0" is an abort, and then ran the test in a loop until the bug revealed itself
16:54 nwc10 I have no idea *why* it's a failure
17:25 arnsholt That's how debugging generally works, isn't it?
17:25 arnsholt "Last time something like this happened, it was X, so it's probably that."
17:26 nwc10 the educated guesswork here was more about whether I decided to even dig into a failure
17:27 nwc10 in that, I was suspicious that the 1 line summary from Test::Harness was caused by an ASAN abort
17:27 nwc10 but yes, I think you're right about the more general approach
17:47 ShimmerFairy joined #moarvm
18:19 tokuhiro_ joined #moarvm
19:35 FROGGS joined #moarvm
19:57 * timotimo returns
19:58 timotimo i had to leave in a hurry before
20:20 tokuhiro_ joined #moarvm
20:34 Peter_R joined #moarvm
21:05 lizmat joined #moarvm
21:37 colomon joined #moarvm
21:56 camelia joined #moarvm
22:04 dalek MoarVM: 3bf9ede | FROGGS++ | src/6model/reprs/CStruct.c:
22:04 dalek MoarVM: fix non-sensical alignment of inlined structs/unions
22:04 dalek MoarVM:
22:04 dalek MoarVM: Implementing structures of libxml2 via NativeCall showed that inlined
22:04 dalek MoarVM: structures are just aligned at byte boundaries. The code before was
22:04 dalek MoarVM: most likely just a thinko.
22:04 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/3bf9edefeb
22:08 FROGGS I'm slightly proud of this one: https://github.com/FROGGS/p6-XML-LibXML/commit/a1d3a6cbfeaa7babd22ab8585d508a5366b75cd0
22:10 lizmat FROGGS++  # rightly so, from what I can determine  :-)
22:10 FROGGS :o)
22:12 FROGGS it is nice to make progress in different areas
23:57 tokuhiro_ joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary