01:48 ilbot3 joined
konobi jnthn: there's an extremely efficient algo in zfs for doing that shared space stuff, since it's the main thing behind the dmu 04:55
07:32 domidumont joined 07:37 domidumont joined 07:53 lizmat joined
konobi also... github.com/lovasko/bc_thesis 08:06
08:31 Ven joined
konobi and... queue.acm.org/detail.cfm?id=2492433 10:16
which leads to... concurrencykit.org/ 10:52
11:07 diakopter joined 11:26 zakharyas joined 11:29 Ven joined 11:55 Util joined 12:01 brrt joined
brrt ehm, i'm looking for something, and i can't explain why this has never crashed before 12:08
timotimo oh my :)
brrt github.com/MoarVM/MoarVM/blob/mast....dasc#L162 12:09
we cmp ref with 0x0
and then
we proceed to dereference it anyway
this has been here for over 2 years 12:11
lizmat maybe we never reach that code ? 12:13
brrt we reach it, it's just never zero 12:15
it's supposed to be the same as github.com/MoarVM/MoarVM/blob/mast...gc/wb.h#L8 12:16
but it's not shortcircuiting
timotimo maybe because we make sure to have VMNull everywhere?
and never use nulled out objects registers unless we explicitly handle it in the code itself?
brrt probably 12:19
this value comes from getdynlex
anyway, will investigate later
timotimo 'k
brrt (it's reframe-jit speciifc afaik)
konobi is there much use of COW semantics in GCs? 12:38
timotimo in general, you mean? 12:39
konobi yeah 12:44
timotimo i bet there's some papers on that already. no clue about implementations "in the wild", though
konobi 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 12:49
huh... and i just thought of a cheap way of doing GC with COW semantics 13:11
lizmat konobi: PR's are accepted by jnthn on a regular basis :-) 13:17
timotimo 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
brrt fairly sure this is probably a case of a missing MVMROOT... :-( 14:14
or, write barrier check somewher 14:15
timotimo you haven't told us yet what exactly you're hunting 14:16
brrt i'm getting a SEGV on running rakudo tools/build/install-core-dist.pl under reframe-jit 14:20
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
timotimo you should merge the newest moar commits that give you more info for the "cannot invoke this type" error
14:55 dalek joined
brrt hmm, maybe, but i imagine jnthn will want to merge that too, and i try to base off reframe 15:17
timotimo OK, but you can also just merge it temporarily locally-only :) 15:27
just to make your life easier for finding this problem out
brrt true.. 15:32
also possible that it is just a NULL pointer error
timotimo you mean a VMNull? 15:34
brrt hmm, yeah, the think we're looking at is VMNull 15:42
so why
theory; jit_entry_label is borked 15:47
timotimo it's not moving right? 15:50
brrt well, it's a negative offset from the function entry 16:29
timotimo that's weird, yeah
gist.github.com/timo/5843f49fe287e...78743e6d0c - do you see this shit? %) 16:31
brrt what's bad about it? 16:32
timotimo boxing an int, just to unbox it again in order to box it into an int again 16:33
brrt ah, the last parts 16:34
how difficult would it be to eliminate that using spesh?
timotimo it's the lost parts, yeah
this particular thing should be quite doable
brrt better theory 16:35
(you can look at decont, and see if it's source input is a boxing op?)
we're in the wrong frame altogether 16:36
we're not looking at the right frame
how even
timotimo we have a "known box source" fact
this particular part of the whole thing isn't interesting for performance, though ... this is right before the return, it seems like 16:37
brrt we are somehow, jumping into this frame, with the wrong jit_entry_label set
timotimo boy am i glad p6bool doesn't allocate %) 16:43
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 :$
we'd have to +& 1 basically
ah, so every instance of me using rand is followed up by a p6box_n usually followed shortly by a decont_n 16:48
16:52 Ven joined
dalek arVM: 6559c2c | timotimo++ | tools/graph_spesh.p6:
spesh graph: rescue a few missing writer-reader arrows

by waiting until the end of the file to find if a given register's writer is anywhere to be found.
17:47 zakharyas joined 18:11 zakharyas joined
dalek arVM: b69f894 | timotimo++ | tools/graph_spesh.p6:
fix extops not getting their args pointed at

a GLR regression lying in hiding for a loooong time
18:31 dalek joined 19:25 zakharyas joined
dalek arVM: 4aa9c76 | timotimo++ | tools/graph_spesh.p6:
spesh_graph: colored BBs
arVM: 818f485 | timotimo++ | tools/graph_spesh.p6:
graph_spesh: a little "mini map" for dominance and CFG
timotimo m) 20:27
the tool changes its name every commit
masak talk about agile development! 20:29
timotimo excellent turn-around 20:30
i think i need a optipng version that uses multiple CPU cores ... 20:32
6768x25391 pixels, 4x8 bits/pixel, RGB+alpha
this might not actually be a very good candidate for getting optipngd
t.h8.lv/fully_operational.png - look at all the pretty lights! 20:57
lizmat hmmm.. my browser only shows this too small or too large :-( 20:59
timotimo yeah, you'll have to be panning around a lot 21:00
but at the top right there's a little "mini-map" :)
i could just export it as SVG instead, which should work much better
t.h8.lv/fully_operational.svg 21:01
lizmat scales better, but not really good yet :-( 21:02
timotimo :\ 21:03
well, it is a huge crapton of content ... :\
i wish i could make things sensibly clickable there so that navigation becomes possible 21:07
i put the "mini maps" on the top left now. reuploading ... 21:08
dalek arVM: 4b23cc7 | timotimo++ | tools/graph_spesh.p6:
graph_spesh: expect debugnames sometimes

like when we have a wval instruction.
arVM: c3e8bef | timotimo++ | tools/graph_spesh.p6:
move mini maps to the left
arVM: 592cbb4 | timotimo++ | tools/graph_spesh.p6:
graph spesh: vary saturation as well as hue