00:07
jnap joined
00:46
colomon joined
01:08
jnap joined
02:07
colomon joined
02:09
jnap joined
02:21
ggoebel118 joined
02:28
retupmoc1 joined
03:14
cognominal joined
04:11
jnap joined
05:11
jnap joined
06:12
jnap joined
07:13
jnap joined
08:01
FROGGS[mobile] joined
08:12
FROGGS[mobile] joined
08:14
jnap joined
08:17
FROGGS[mobile] joined
10:15
jnap joined
11:16
jnap joined
11:51
colomon joined
12:17
jnap joined
13:17
jnap joined
13:58
lue joined
14:18
jnap joined
15:19
jnap joined
15:20
lue joined
15:39
jnap joined
17:04
FROGGS[mobile] joined
17:56
FROGGS[mobile] joined
17:58
ssutch joined
18:21
colomon joined
18:39
colomon joined
18:48
FROGGS[mobile] joined
18:51
ssutch joined
19:24
colomon joined
20:00
colomon joined
|
|||
nwc10 | .tell jnthn I think that if an MVMCompUnitBody gets promoted to the 2nd gen, it can end up with elements of scs[] still being in the nursery, and hence not properly marked at the next nursery-only sweep | 20:34 | |
mmm, that didn't work. | |||
FROGGS | preflex: tell nwc10 That should do. | 20:35 | |
ahh, no preflex here :/ | 20:36 | ||
nwc10 | test (please ignore) | ||
FROGGS | preflex is in #perl6 | ||
nwc10 | and via privmesg as tell | ||
FROGGS | k | 20:37 | |
nwc10 | anyway, I have a stinker of a GC bug where the value 0x6 ends up as a pointer in scs[4] for a frame, which crashes gc_mark in MVMCompUnit | ||
and it seems to be a pointer to memory in tospace which has become re-used as part of an array | 20:38 | ||
and then that bit of memory gets misinterpreted as the forwarder address during a GC sweep, so somethign else gets updated | |||
er, scs[4] gets update because the sweeper thinks that it's pointing to fromspace, and the fromspace has a forwarder to 0x6 | 20:39 | ||
so I think that an even number of GC runs have happened (maybe just 2) | |||
during which whatever scs[4] was pointing to got into fromspace, but scs[4] never got updated. Or the thing pointed to was never marked | 20:40 | ||
oh, if all else fails, let's RTFM | |||
nwc10 makes RTFMing noises | |||
FROGGS | I am not sure what the solution is... the addresses of scs[4] need either temp_push'd or ASSIGN_REF'd I guess | 20:42 | |
timotimo | don't we allocate a whole new tospace every time? | 21:57 | |
(maybe we should) | |||
FROGGS | no, we allocate that fromspace/tospace area just once | 21:58 | |
we could change that for debugging reasons perhaps | 21:59 | ||
22:38
colomon joined
22:39
FROGGS[mobile] joined
22:49
FROGGS[mobile] joined
23:04
cognominal__ joined
23:08
FROGGS[mobile] joined
|