Reproducing this conversation from IRC for those who might not have
seen it there. Seems like it could be a nice simple project for
someone to take their minds off of complicated things. :)
> <foom2> So why is pseudo-atomic needed in SBCL x86/x86-64; why not
> just a sequence like: store raw pointer to proto-obj in a register
> (thus implicitly pin), incr alloc pointer, fill in object one word
> at a time: header, then length, then fields.
> <foom2> Because of the pinning from stack conservatism, if the GC
> hits in the middle, the object can't move. Scavenging needs to
> work...but that shouldn't be a problem since the memory is zero-
> <Fare> pseudo-atomic is probably needed in other cases, but yes,
> might not be needed for object allocation when using a stack-
> conservative GC
> <foom2> It's also used by TLS-slot alloc. And it's certainly not
> superfluous for the alloc slow-path when acquiring more pages.
> <jsnell> store pointer, interrupt, in lisp-side interrupt handler
> allocate, store pointer, increment pointer, return from interrupt,
> increment pointer
> <foom2> hm, yes, okay, so it's not GC that's the problem, it's other
> allocations that's the problem. interrupt call into lisp could set
> up a new allocation region to work around that problem.
> <jsnell> ooh, that's a nice idea
> <pkhuong> foom: actually, with XADD or CMPXCHG, we can make
> allocation reentrant.