20:25 <strmpnk> I'm trying to uncover the intention behind `ISize`. I get that `USize` is `size_t`, but both have usize and isize methods respectively which aren't marked partial. I assume negative `ISize` would reinterpret two's comp, or would it clamp to 0? Likewise for `USize` above `ISize.max_value()` though that might be a bit contrived for platforms with 64bit `size_t`.

21:30 <dgcaccam> static const uint32_t sizeclass_empty[HEAP_SIZECLASSES] = { 0xFFFFFFFF, 0x55555555, 0x11111111, 0x01010101, 0x00010001 }; static const uint32_t sizeclass_init[HEAP_SIZECLASSES] = { 0xFFFFFFFE, 0x55555554, 0x11111110, 0x01010100, 0x00010000 };

21:32 <dgcaccam> Whoops, was trying to format that nicer... I have been looking at the garbage collection and in the function ponyint_heap_startgc these values are being used to (presumably) clear memory chunks. Can anyone tell me the exact purpose and why these particular bytes?

21:35 <strmpnk> Sometimes known bit patterns can make debugging problems with cleared memory easier post-facto. Just a guess.