|
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 | |
| this | |||
| we cmp ref with 0x0 | |||
| and then | |||
| we proceed to dereference it anyway | |||
| wtf | |||
| 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 | ||
| o_O | |||
| 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:09 | |
|
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:28 | |
|
18:31
dalek joined
19:25
zakharyas joined
|
|||
| dalek | arVM: 4aa9c76 | timotimo++ | tools/graph_spesh.p6: spesh_graph: colored BBs |
20:26 | |
| 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. |
21:14 | |
| 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 |
22:32 | ||
