libera/#sbcl - IRC Chatlog
Search
23:27:54
stassats
so for run-time generated code it might be better to look at the return values of COMPILE
23:35:16
hayley
Hm. There's a part of the gencgc logic that I don't understand, which is where it decides what generations to collect. For one not-very-generational test I get most of the heap promoted to gen2 and 3 and then those generations never get collected, since they don't seem to "age" enough before SBCL runs out memory. I added another backup case, which was to force collection if more than 80% of the heap is used, which works but doesn't come off as a
23:42:08
hayley
When I was doing more or less full collections before, this program would happily run in a 512MB heap, so I think it is just SBCL not collecting aggressively enough. Now it runs with a 768MB heap with this non-moving GC, which is a regression, but not a very concerning one.
23:45:40
hayley
.oO( Run GC every two minutes, that way it'll be webscale and we can annoy Discord engineers too )
23:46:56
hayley
Sounds like a good idea though. But I think it'd be more appreciated if it's concurrent GC, since now we're not pausing when the user thought they were safe. But then they could just disable the background GC, perhaps.
23:48:20
stassats
for UI application it would be interesting to run the GC in the remaining frame time
23:49:30
hayley
Oh well, I still haven't even achieved my initial goal of parallelising, and this GC still doesn't compact at all yet. Concurrency can come later, hopefully much later, so I can avoid inflicting writing a write barrier on myself.
23:52:02
hayley
One question. I mark the start of each object in a bitmap when allocating, so that it's possible to traverse the heap. On x86 I use the BTS instruction, though it can be unsynchronised because threads can't touch the same bitmap words, due to the size of allocation buffers. How finnicky is it to set a bit in ARM? Guess there probably is a VOP for (SETF BIT) or some such I could check.
23:57:15
hayley
I kinda want to do without immobile space, since this GC doesn't move at all and so another space is more stuff to (probably fail to) parallelise, but I understand it's used to get 32-bit addresses for objects.
0:02:24
hayley
But then I probably would want a large-object space if I'm not compacting very much, so it's not really like this is making anything simpler.
0:17:23
hayley
w.r.t pseudo-atomic; I'm guessing the alternative is safepoints? Those would also be good, since I don't know what to think of putting pseudo-atomic around every pointer store (or coming up with some way to deal with the race in a write barrier for concurrent GC), but getting those working nicely seems hard.
0:19:48
hayley
Pointer writes would need to be "atomic" with the write barrier, too. But I guess there are "sticky" card marks now, to dodge the problem for card marking.