github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
Set by moderator on 13 May 2018.
01:01 AlexDani` joined 01:29 zakharyas joined 01:57 ilbot3 joined
moderator github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
05:31 domidumont joined 05:37 domidumont joined 06:22 domidumont joined 06:50 Ven`` joined 07:18 robertle joined 09:04 nwc10 joined 09:54 Ven`` joined 10:05 AlexDaniel joined
dogbert2_ hmm, MoarVM panic: Collectable 0xb330df9c in fromspace accessed 11:07
the code fails here, github.com/MoarVM/MoarVM/blob/mast...erp.c#L32, when running t/spec/integration/eval-and-threads.t 11:15
MVM_GC_DEBUG=1 and the nursery has been made smaller 11:16
jnthn, timotimo: should I report this ^^ or is it a known problem? gist.github.com/dogbert17/7b4c0161...0238fe8f29 11:29
11:56 Ven`` joined 12:03 Ven`` joined
jnthn dogbert2_: Not known tome 12:07
*to me
Please file an issue
dogbert2_ jnthn: txh for looking, will create an issue 12:20
13:03 Ven`` joined
Geth MoarVM/master: 5 commits pushed by (Bart Wiegmans)++, (Elizabeth Mattijsen)++ 13:13
13:15 domidumont joined 13:25 zakharyas joined 14:12 Ven`` joined 14:38 Ven`` joined 15:41 Voldenet joined
timotimo jnthn: if "ensure_uninstrumented" for the instrumented profiler became a no-op, we'd be wasting some performance after profiling is ended, but we'd otherwise have to have some indirection somewhere for the bytecode we're running in a frame, and do some kind of lazy deletion for bytecode segments, too ... 16:09
alternatively, at least in the profiler instrumentation case, we could go through all frames on the heap (need to consider ones that aren't on the stack) and just count how many profiling instructions come before the instruction pointer and subtract that amount when switching to the original bytecode 16:11
but that's also meh
jnthn timotimo: hmm, yes :S 16:13
Not to mention JIT 16:14
timotimo aye
the profiler ops are, thankfully, completely harmless when called while profiling is turned off
16:26 domidumont joined
[Coke] (diff tool for windows) I am very happy with beyond compare for windows & mac 16:29
yoleaux 12 May 2018 03:13Z <Zoffix> [Coke]: are you in contact with Mark at TPF? The link to "his blog for April" in last grant update links to SO, not the blog: news.perlfoundation.org/2018/05/gra...l#comments (P.S.: I still have no idea who's *my* grant manager :|)
Geth MoarVM: dd2d7f9edb | (Timo Paulssen)++ | 2 files
don't uninstrument any more

the instrumentation level barrier can be hit by one thread while another is currently running the bytecode, which causes it to reach a semi-random place in the bytecode and start interpreting values as instructions.
17:24
lizmat wow 18:04
timotimo hmm? 18:06
lizmat well, I just read the last commit message 18:07
"start interpreting values as instructions"
timotimo yeah 18:08
that's where "const_iX NYI" came from
lizmat aha, so would it make sense to bump MoarVM over this ?
timotimo we could do that
lizmat ok, I will then 18:09
but after I get back from being afk for a few hours& 18:14
Geth MoarVM: eebc4620e6 | (Timo Paulssen)++ | src/profiler/instrument.c
profile: extract recursion loop for smaller stack frames

dumping call graphs used to put 144 bytes onto the stack for every slice of recursion, now it'll deposit just 64 bytes for every slice and put a 128 byte frame on top to do most of the actual work.
18:33
timotimo it just so happens that the script i was randomly running to get profiler output has a little stack depth problem ... 18:34
20:15 committable6 joined, squashable6 joined
lizmat And another Perl 6 Weekly hits The Net: p6weekly.wordpress.com/2018/05/14/...ough-time/ 22:23
timotimo lizmat: the regex speed increase is actually for interpolating regexes into regexes 22:25
lizmat aaahh ok 22:26
timotimo oh, what did i fix in moarvm that was related to gc?
lizmat eefd9a436285bd ? 22:28
timotimo ooh 22:30
right, that just fixes a small bug in the gc tab in the profiler output, but that's good to have of course
22:32 greppable6 joined