00:13 tokuhiro_ joined 00:24 colomon joined 03:09 orbus joined 03:15 colomon joined 06:21 FROGGS joined 06:42 brrt joined 07:05 zakharyas joined 07:20 ShimmerFairy joined 08:14 brrt joined
dalek arVM: fbe6033 | jnthn++ | src/mast/compiler.c:
Add missing ensure_space when writing label reg.
 08:56
FROGGS ups 08:57
jnthn valgrind++ made that one easy to find 08:58
What's a little concerning is that valgrind is still very noisy
Oh I see why
dalek arVM: 553fa58 | jnthn++ | src/core/frame.c:
Make sure refd_by_object is initialized.

So frames that should be cheap to free will be. Also quiets valgrind warnings about jump on uninitialized memory.		 09:02
FROGGS valgrind++ :o) 09:03
jnthn Indeed 09:04
FROGGS jnthn: you said you are giving a talk today?
jnthn But...I still get one write past end of buffer in the same place as before o.O
FROGGS: Thursday
FROGGS or at leasting preparing one?
Perl 6 related? 09:05
jnthn Yeah, I figured I'd do some debugging to get me properly woken up
No
Well, actually Perl 6 will get a mention
FROGGS ahh, k, I won't bug you any longer :o)
jnthn www.communityday.se/
FROGGS ohh nice 09:06
so, OO stands for "Ohh, Oops"? :D
jnthn :D
Actually on my slides I wrote the title as "Oh, OOPs" :P 09:07
FROGGS ahh
jnthn But both puns work for me :)
FROGGS aye
jnthn But yeah, we still write past a label register over the end of the buffer. wtf. 09:08
Actually, it's the label itself 09:11
ohh 09:14
FROGGS O.o 09:15
jnthn Apparently I should have done slides first, then fix memory errors when awaker :P
FROGGS *g*
but I also enjoy a nice bug hunt now and then
slides not so much 09:16
nwc10 is there something wrong with your coffee supply?
good decaf, #moarvm :-)
dalek arVM: bfb2236 | jnthn++ | src/mast/compiler.c:
A more correct fix to handler table writing.

Since we dynamically allocate more inside the loop, we need the basic handler size ensure_space inside the loop too.		 09:17
jnthn And Valgrind smiles on us again :) 09:18
nwc10: It's nearly empty in fact, but there's enough for one more cup :) 09:20
Though trying not to drink too much coffee, since it's apparently it aggravates anxiety...
09:56 JimmyZ joined
JimmyZ FROGGS: I upated dyncall and the sync wiki :) 10:00
FROGGS JimmyZ++ 10:01
JimmyZ jnthn: github.com/MoarVM/MoarVM/issues/234 # valgrind one maybe? :P
10:03 dalek joined
jnthn JimmyZ: It may give clues, aye 10:04
Seems that the Perl 6 compiler itself ain't threadsafe, even though there's little reason for it not to be 10:09
The cross thread write log looks highly dubious, however. 10:10
So I'm suspecting some code-gen bugs
Think I've worked out that SEGV that can happen in the STable GC 10:45
In multi-threaded programs
timotimo oh, is that one i stumbled upon multiple months ago?
jnthn Maybe
timotimo ISTR something like that 10:46
jnthn It crops up now and then
timotimo but i have forgotten the context
jnthn MVM_gc_collect_free_stables was in the backtrace near the top
dalek arVM: 7eb097a | jnthn++ | src/gc/orchestrate.c:
Free STables in a safer place.

We do finalization asynchronously after the stop-the-world phase of parallel GC. Freed STables must stay around until all threads have completed their finalization, since they contain information that is needed for object finalization. Thus, freeing STables after the thread that triggered GC is done with its finalization can cause them to get freed to early, leading to memory corruption. Instead do it in the next GC run, at the start of the world-stopped phase. No difference to throughput of single-threaded programs, and should fix an occasional crash in multi-threaded programs (though it was tough to reproduce). 3bf9ede | FROGGS++ | src/6model/reprs/CStruct.c: fix non-sensical alignment of inlined structs/unions
Implementing structures of libxml2 via NativeCall showed that inlined structures are just aligned at byte boundaries. The code before was most likely just a thinko.		 11:19
timotimo oh! 11:21
so that's how
jnthn Seems so.
timotimo and for some reason dalek didn't fully report 11:22
oh well. didn't get kicked at least
jnthn It only missed the GitHub link
Anyways, another concurrency bug down, hopefully. :)
We still have some, alas.
timotimo mhm 11:23
oh, eew
my num ($a, $b, $c, $d); generates code "deep down" that allocates a whole register for the whole frame
none of those seem to be re-used for anything afterwards 11:24
jnthn Well, lexicals may be closed over
timotimo so we have a nan, then a bindlex for each of these lexicals, but the register could totally be re-used 11:25
but why keep the register around for the whole frame?
jnthn Oh, you mean a register on top of the storage for the lexical? 11:26
timotimo yes
jnthn That's worth looking into :)
I don't know why, but sounds overkill
timotimo mayhaps we want to generate these QAST::Var nodes inside their own Stmts node?
Stmts is the one that marks used registers as unused afterwards, right?
jnthn Stmt, but that's about explicit locals, not temporaries 11:27
Plus various things rely on the QAST::Var nodes being top level
timotimo or should we have a special handling for the first child of a QAST::Block?
hmm.
jnthn Don't think so, sounds like a more generic issue to me.
timotimo well, the Var isn't top-level to begin with, as its parent is a Op(bind) 11:28
but we likely have that handled in the code explicitly
jnthn *nod*
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?
jnthn Work area is not GC-able
timotimo thought so 11:29
jnthn It will lead to less memory use
But not fewer GCs
timotimo and more cache-friendlyness
jnthn Right
timotimo marking the frame is not likely faster, as native registers don't have to be skipped "purposefully", right?
jnthn Can't remember exactly how it is, but it may be a bit faster 11:30
Using less registers has small nice consequences all over 11:31
timotimo sure
jnthn Lunch time here, and then back to my slides, now I've fixed a few things. :)
timotimo 'k :)
good lunch!
huh. the simplest approach i could think of ... and nqp and rakudo still compile?! 11:41
(just releasing the register used for the $*BINDVAL of a lexical inside compile_var) 11:42
ah, now things blow up :)
jnthn Wsa gonna say, that sounded a bit too simple ;) 11:44
timotimo :) 11:47
might just be a my $want := $MVM_reg_void; instead of my $want; at the right spot
oh, that's also not right
Void return not allowed to context requiring a return value 11:48
wat 11:54
This representation (Null) does not support elems
how did i get to this? :D
not yet reaching something workable, maybe a different approach is needed 12:00
(different from compiling the first child of a block differently from the rest of the block)
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
seems like this approach is pretty brittle
i would have expected releasing the result register of the bindval if the current want is void would be all right 13:11
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:12
timotimo just dumps the whole ast of the core setting ... 13:18
oh yikes 13:19
KnowHOW methods must be called on object instance with REPR KnowHOWREPR
at gen/moar/stage2/QASTNode.nqp:401 (/home/timo/perl6/rakudo/../install/share/nqp/lib/QASTNode.moarvm:dump_extra_node_info:0)
that's not so good, eh?
seems like it wasn't my changes that cause this problem, it also happens with a clean nqp + rakudo 13:38
13:58 zakharyas joined 14:31 vendethiel joined 14:36 synbot6 joined 15:16 tokuhiro_ joined
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:19
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:20
15:23 TimToady joined
timotimo now why would it be that the compiler thinks the want is void in that case? 15:24
i know so little about the mast compiler's innards :| 15:25
16:18 tokuhiro_ joined
nwc10 jnthn: ASAN barfage paste.scsys.co.uk/498726 t/spec/S15-nfg/many-threads.t 16:46
it's a race. often is works
16:51 TimToady joined
jnthn nwc10: Wow, nice find! 16:53
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
I have no idea *why* it's a failure
arnsholt That's how debugging generally works, isn't it? 17:25
"Last time something like this happened, it was X, so it's probably that."
nwc10 the educated guesswork here was more about whether I decided to even dig into a failure 17:26
in that, I was suspicious that the 1 line summary from Test::Harness was caused by an ASAN abort 17:27
but yes, I think you're right about the more general approach
17:47 ShimmerFairy joined 18:19 tokuhiro_ joined 19:35 FROGGS joined
timotimo returns 19:57
i had to leave in a hurry before 19:58
20:20 tokuhiro_ joined 20:34 Peter_R joined 21:05 lizmat joined 21:37 colomon joined 21:56 camelia joined
FROGGS I'm slightly proud of this one: github.com/FROGGS/p6-XML-LibXML/co...5366b75cd0 22:08
lizmat FROGGS++ # rightly so, from what I can determine :-) 22:10
FROGGS :o)
it is nice to make progress in different areas 22:12
23:57 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!