Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2013-12-26

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:07 jnap joined #moarvm
00:46 colomon joined #moarvm
01:08 jnap joined #moarvm
02:07 colomon joined #moarvm
02:09 jnap joined #moarvm
02:21 ggoebel118 joined #moarvm
02:28 retupmoc1 joined #moarvm
03:14 cognominal joined #moarvm
04:11 jnap joined #moarvm
05:11 jnap joined #moarvm
06:12 jnap joined #moarvm
07:13 jnap joined #moarvm
08:01 FROGGS[mobile] joined #moarvm
08:12 FROGGS[mobile] joined #moarvm
08:14 jnap joined #moarvm
08:17 FROGGS[mobile] joined #moarvm
10:15 jnap joined #moarvm
11:16 jnap joined #moarvm
11:51 colomon joined #moarvm
12:17 jnap joined #moarvm
13:17 jnap joined #moarvm
13:58 lue joined #moarvm
14:18 jnap joined #moarvm
15:19 jnap joined #moarvm
15:20 lue joined #moarvm
15:39 jnap joined #moarvm
17:04 FROGGS[mobile] joined #moarvm
17:56 FROGGS[mobile] joined #moarvm
17:58 ssutch joined #moarvm
18:21 colomon joined #moarvm
18:39 colomon joined #moarvm
18:48 FROGGS[mobile] joined #moarvm
18:51 ssutch joined #moarvm
19:24 colomon joined #moarvm
20:00 colomon joined #moarvm
20:34 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 nwc10 mmm, that didn't work.
20:35 FROGGS preflex: tell nwc10 That should do.
20:36 FROGGS ahh, no preflex here :/
20:36 nwc10 test (please ignore)
20:36 FROGGS preflex is in #perl6
20:36 nwc10 and via privmesg as tell
20:37 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
20:38 nwc10 and it seems to be a pointer to memory in tospace which has become re-used as part of an array
20:38 nwc10 and then that bit of memory gets misinterpreted as the forwarder address during a GC sweep, so somethign else gets updated
20:39 nwc10 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 nwc10 so I think that an even number of GC runs have happened (maybe just 2)
20:40 nwc10 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 nwc10 oh, if all else fails, let's RTFM
20:40 * nwc10 makes RTFMing noises
20:42 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
21:57 timotimo don't we allocate a whole new tospace every time?
21:57 timotimo (maybe we should)
21:58 FROGGS no, we allocate that fromspace/tospace area just once
21:59 FROGGS we could change that for debugging reasons perhaps
22:38 colomon joined #moarvm
22:39 FROGGS[mobile] joined #moarvm
22:49 FROGGS[mobile] joined #moarvm
23:04 cognominal__ joined #moarvm
23:08 FROGGS[mobile] joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary