[01:48] *** ilbot3 joined [04:55] jnthn: there's an extremely efficient algo in zfs for doing that shared space stuff, since it's the main thing behind the dmu [07:32] *** domidumont joined [07:37] *** domidumont joined [07:53] *** lizmat joined [08:06] also... https://github.com/lovasko/bc_thesis [08:31] *** Ven joined [10:16] and... https://queue.acm.org/detail.cfm?id=2492433 [10:52] which leads to... http://concurrencykit.org/ [11:07] *** diakopter joined [11:26] *** zakharyas joined [11:29] *** Ven joined [11:55] *** Util joined [12:01] *** brrt joined [12:08] ehm, i'm looking for something, and i can't explain why this has never crashed before [12:08] oh my :) [12:09] https://github.com/MoarVM/MoarVM/blob/master/src/jit/emit_x64.dasc#L162 [12:09] this [12:09] we cmp ref with 0x0 [12:09] and then [12:09] we proceed to dereference it anyway [12:09] wtf [12:11] this has been here for over 2 years [12:13] maybe we never reach that code ? [12:15] we reach it, it's just never zero [12:16] it's supposed to be the same as https://github.com/MoarVM/MoarVM/blob/master/src/gc/wb.h#L8 [12:16] but it's not shortcircuiting [12:16] maybe because we make sure to have VMNull everywhere? [12:16] and never use nulled out objects registers unless we explicitly handle it in the code itself? [12:19] probably [12:19] this value comes from getdynlex [12:19] anyway, will investigate later [12:19] 'k [12:19] (it's reframe-jit speciifc afaik) [12:38] is there much use of COW semantics in GCs? [12:39] in general, you mean? [12:44] yeah [12:44] i bet there's some papers on that already. no clue about implementations "in the wild", though [12:49] seems to me like an implementation similar to how the ZFS DMU does COW and it's GC would be very fitting for memory and GC in dynamic languages [13:11] huh... and i just thought of a cheap way of doing GC with COW semantics [13:17] konobi: PR's are accepted by jnthn on a regular basis :-) [13:19] i'm not sure file systems have to deal with as much traffic from little files as a dynamic language's memory management would [13:19] but i'd gladly be corrected :) [13:51] *** brrt joined [14:14] fairly sure this is probably a case of a missing MVMROOT... :-( [14:15] or, write barrier check somewher [14:16] you haven't told us yet what exactly you're hunting [14:20] i'm getting a SEGV on running rakudo tools/build/install-core-dist.pl under reframe-jit [14:21] i'm also getting a 'cannot invoke this type' error on building CORE.setting [14:21] i'm kind of hoping the former is easier to find than the latter [14:21] you should merge the newest moar commits that give you more info for the "cannot invoke this type" error [14:55] *** dalek joined [15:17] hmm, maybe, but i imagine jnthn will want to merge that too, and i try to base off reframe [15:27] OK, but you can also just merge it temporarily locally-only :) [15:27] just to make your life easier for finding this problem out [15:32] true.. [15:32] also possible that it is just a NULL pointer error [15:34] you mean a VMNull? [15:42] hmm, yeah, the think we're looking at is VMNull [15:42] so why [15:47] theory; jit_entry_label is borked [15:50] it's not moving right? [16:29] well, it's a negative offset from the function entry [16:29] that's weird, yeah [16:31] https://gist.github.com/timo/5843f49fe287e1edd2276e78743e6d0c - do you see this shit? %) [16:32] what's bad about it? [16:33] boxing an int, just to unbox it again in order to box it into an int again [16:34] ah, the last parts [16:34] how difficult would it be to eliminate that using spesh? [16:34] it's the lost parts, yeah [16:34] this particular thing should be quite doable [16:35] better theory [16:35] (you can look at decont, and see if it's source input is a boxing op?) [16:36] we're in the wrong frame altogether [16:36] we're not looking at the right frame [16:36] how even [16:36] we have a "known box source" fact [16:36] o_O [16:37] this particular part of the whole thing isn't interesting for performance, though ... this is right before the return, it seems like [16:37] we are somehow, jumping into this frame, with the wrong jit_entry_label set [16:43] boy am i glad p6bool doesn't allocate %) [16:44] i don't think we actually have an op that does the same as unboxing a bool that got boxed from an int [16:44] we can't just use the int, because that may have any value :$ [16:44] we'd have to +& 1 basically [16:48] ah, so every instance of me using rand is followed up by a p6box_n usually followed shortly by a decont_n [16:52] *** Ven joined [17:09] MoarVM: 6559c2c | timotimo++ | tools/graph_spesh.p6: [17:09] MoarVM: spesh graph: rescue a few missing writer-reader arrows [17:09] MoarVM: [17:09] MoarVM: by waiting until the end of the file to find if a given [17:09] MoarVM: register's writer is anywhere to be found. [17:09] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/6559c2c034 [17:47] *** zakharyas joined [18:11] *** zakharyas joined [18:28] MoarVM: b69f894 | timotimo++ | tools/graph_spesh.p6: [18:28] MoarVM: fix extops not getting their args pointed at [18:28] MoarVM: [18:28] MoarVM: a GLR regression lying in hiding for a loooong time [18:28] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/b69f89405a [18:31] *** dalek joined [19:25] *** zakharyas joined [20:26] MoarVM: 4aa9c76 | timotimo++ | tools/graph_spesh.p6: [20:26] MoarVM: spesh_graph: colored BBs [20:26] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/4aa9c76d62 [20:26] MoarVM: 818f485 | timotimo++ | tools/graph_spesh.p6: [20:26] MoarVM: graph_spesh: a little "mini map" for dominance and CFG [20:26] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/818f485435 [20:27] m) [20:27] the tool changes its name every commit [20:29] talk about agile development! [20:30] excellent turn-around [20:32] i think i need a optipng version that uses multiple CPU cores ... [20:32] 6768x25391 pixels, 4x8 bits/pixel, RGB+alpha [20:32] this might not actually be a very good candidate for getting optipngd [20:57] http://t.h8.lv/fully_operational.png - look at all the pretty lights! [20:59] hmmm.. my browser only shows this too small or too large :-( [21:00] yeah, you'll have to be panning around a lot [21:00] but at the top right there's a little "mini-map" :) [21:00] i could just export it as SVG instead, which should work much better [21:01] http://t.h8.lv/fully_operational.svg [21:02] scales better, but not really good yet :-( [21:03] :\ [21:03] well, it is a huge crapton of content ... :\ [21:07] i wish i could make things sensibly clickable there so that navigation becomes possible [21:08] i put the "mini maps" on the top left now. reuploading ... [21:14] MoarVM: 4b23cc7 | timotimo++ | tools/graph_spesh.p6: [21:14] MoarVM: graph_spesh: expect debugnames sometimes [21:14] MoarVM: [21:14] MoarVM: like when we have a wval instruction. [21:14] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/4b23cc74fe [21:14] MoarVM: c3e8bef | timotimo++ | tools/graph_spesh.p6: [21:14] MoarVM: move mini maps to the left [21:14] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/c3e8bef104 [22:32] MoarVM: 592cbb4 | timotimo++ | tools/graph_spesh.p6: [22:32] MoarVM: graph spesh: vary saturation as well as hue [22:32] MoarVM: review: https://github.com/MoarVM/MoarVM/commit/592cbb4df5