Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-12-16

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

All times shown according to UTC.

Time Nick Message
01:19 MasterDuke joined #moarvm
01:57 colomon joined #moarvm
02:58 ilbot3 joined #moarvm
02:58 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:09 colomon joined #moarvm
04:27 colomon joined #moarvm
07:50 TimToady joined #moarvm
08:13 domidumont joined #moarvm
08:20 domidumont joined #moarvm
08:54 TimToady joined #moarvm
13:04 MasterDuke joined #moarvm
13:25 Voldenet joined #moarvm
13:25 Voldenet joined #moarvm
13:26 brrt joined #moarvm
13:26 brrt good * #moarvm
13:29 brrt i can't compile rakudo on linux with --asan because we're leaking memory from spesh / jit etc
13:43 brrt which makes total sense
14:11 dogbert17 o/ brrt
14:11 dogbert17 does it leak so much that the compile fails?
14:15 MasterDuke joined #moarvm
14:18 brrt with ASAN it does
14:22 dogbert17 hmm, haven't seen that (hav 7 Gigs)
14:22 dogbert17 *have
14:29 dogbert17 were you using ASAN_OPTIONS=detect_leaks=0 ?
14:30 MasterDuke_ joined #moarvm
15:19 MasterDuke joined #moarvm
15:51 geospeck joined #moarvm
17:17 brrt joined #moarvm
17:21 brrt the point of ASAN is that it exits your program with a failure condition and a report if you've leaked memory or done something else you shouldn't
17:22 brrt it's super useful so i'd really prefer if we could build rakudo with it *on*
17:26 brrt anyway.... i may, i hope, have a fix
17:27 brrt .ask jnthn what is our current policy with regards to process cleanup, because i think we leak memory if we shutdown moarvm before the spesh worker is done, and that angers ASAN
17:27 yoleaux brrt: I'll pass your message to jnthn.
17:34 Geth ¦ MoarVM/memory-leak-fixes: 25dda671d4 | (Bart Wiegmans)++ | src/core/args.c
17:34 Geth ¦ MoarVM/memory-leak-fixes: Fix leak when args bind error would unwind rather than return
17:34 Geth ¦ MoarVM/memory-leak-fixes:
17:34 Geth ¦ MoarVM/memory-leak-fixes: The args bind error handler would setup a special-return function and
17:34 Geth ¦ MoarVM/memory-leak-fixes: allocate a register for storage, but did not setup an unwind
17:34 Geth ¦ MoarVM/memory-leak-fixes: handler. Whenever the frame was then unwound (rather than
17:34 Geth ¦ MoarVM/memory-leak-fixes: returned-from), that register would leak. ASAN LeakSanitizer doesn't
17:34 Geth ¦ MoarVM/memory-leak-fixes: like that very much.
17:34 Geth ¦ MoarVM/memory-leak-fixes: review: https://github.com/MoarVM/MoarVM/commit/25dda671d4
17:36 dogbert17 brrt++ are there any leaks left?
17:45 Zoffix joined #moarvm
18:15 MasterDuke joined #moarvm
18:28 Zoffix Are there any docs for this "register" stuff? GET_REG(cur_op, 10).o GET_REG(cur_op, 2).s GET_REG(cur_op, 0).u64  what are those 10, 2, 0 numbers (register numbers? how to know which one is where the value I want is at?) and what are those .o, .s, .u64
18:28 Zoffix guessing .object, .string .uint64, but where do those get set?
18:29 MasterDuke i think 0 is the first and they go up by two
18:30 MasterDuke ugh, no i think 0 is the destination
18:43 timotimo those are offsets in bytes or something
18:44 timotimo GET_REG(cur_op, 0) is "what register is set for the first argument"
18:44 timotimo and most ops have their first argument be their "return value"
18:44 timotimo though there are plenty that don't return at all
18:45 timotimo GET_REG indexes into the bytecode to see what each parameter specifies as the register it uses - that's what the number is for - and then it uses that as offset into the stack frame (the pointer is likely called "work")
18:45 timotimo hope that helps
18:45 timotimo BBL
18:45 Zoffix Ah. Thanks
19:00 geospeck joined #moarvm
19:05 zakharyas joined #moarvm
19:47 brrt joined #moarvm
19:57 greppable6 joined #moarvm
20:04 MasterDuke joined #moarvm
20:47 Geth ¦ MoarVM: 0b9f8090a4 | (Zoffix Znet)++ | src/jit/graph.c
20:47 Geth ¦ MoarVM: Revert JITting MVM_OP_throwpayloadlexcaller
20:47 Geth ¦ MoarVM:
20:47 Geth ¦ MoarVM: Doing it causes a segfault when running:
20:47 Geth ¦ MoarVM:
20:47 Geth ¦ MoarVM:     for ^1000 { EVAL('sub { shift->() }', :lang<Perl5>)({;}) }
20:47 Geth ¦ MoarVM:
20:47 Geth ¦ MoarVM: After some debugging[^1], it was suggested[^2] we revert the jitting,
20:47 Geth ¦ MoarVM: to unblock release, and figure out what the problem is with it after.
20:47 Geth ¦ MoarVM:
20:48 Geth ¦ MoarVM: [1] https://github.com/rakudo/rakudo/issues/1308
20:48 Geth ¦ MoarVM: [2] https://irclog.perlgeek.de/perl6-dev/2017-12-16#i_15588477
20:48 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/0b9f8090a4
20:57 committable6 joined #moarvm
20:58 releasable6 joined #moarvm
20:58 benchable6 joined #moarvm
20:58 quotable6 joined #moarvm
20:58 bloatable6 joined #moarvm
20:58 evalable6 joined #moarvm
20:58 coverable6 joined #moarvm
20:58 reportable6 joined #moarvm
20:58 nativecallable6 joined #moarvm
20:58 bisectable6 joined #moarvm
20:58 unicodable6 joined #moarvm
20:58 squashable6 joined #moarvm
20:58 statisfiable6 joined #moarvm
21:04 Zoffix left #moarvm
21:28 dogbert17 is this something to worry about?
21:28 dogbert17 src/spesh/inline.c: In function ‘merge_graph’:
21:28 dogbert17 src/spesh/inline.c:549:5: warning: this decimal constant is unsigned only in ISO C90 [enabled by default]
21:28 dogbert17 inliner->handlers[*inline_boundary_handler].category_mask = MVM_EX_INLINE_BOUNDARY;
21:28 dogbert17 ^
21:30 brrt joined #moarvm
22:44 MasterDuke joined #moarvm
23:47 MasterDuke joined #moarvm
23:48 AlexDani` joined #moarvm
23:55 avar joined #moarvm
23:55 avar joined #moarvm

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