News for hackers. Stuff that matters.
Re:Treadmill garbage collector by H. Baker by ulrikrasmussen on Tuesday July 26, 2022 @02:02AM (#32234838)
I don't know a lot about GC and didn't know about this before I saw this on HN, but I think it is super elegant. One thing I didn't understand: Are all objects assumed to be exactly the same size? Since allocation is just the move of a pointer, that appears to be the case. But how would that work if one would want to implement Treadmill for a language like Java where object sizes vary?
Re:Treadmill garbage collector by H. Baker by oecumena on Tuesday July 26, 2022 @02:14AM (#32234928)
Variable size objects are addressed at the very end of the post: "Support for variable-sized objects requires a separate cyclic list for each size...".
Re:Treadmill garbage collector by H. Baker by ErikCorry on Tuesday July 26, 2022 @04:29AM (#32235747)
That implies that you have to divide up the memory ahead of time into an area for each size? If you get the proportions wrong you will waste memory.

Languages with only one object size are not exactly in vogue at the moment, so this is a major limitation.

Re:Treadmill garbage collector by H. Baker by vidarh on Tuesday July 26, 2022 @07:20AM (#32236810)
> That implies that you have to divide up the memory ahead of time into an area for each size?

No, it doesn't, as it maintains linked lists of objects, so you can use any underlying allocator to feed you objects to add to the different linked lists.

Re:Treadmill garbage collector by H. Baker by thesz on Wednesday July 27, 2022 @01:41AM (#32247231)
You can extend or shrink circular list on the go, depending on needs. You can plan to divide memory ahead of time, but you don't have to.
Re:Treadmill garbage collector by H. Baker by ulrikrasmussen on Tuesday July 26, 2022 @02:56AM (#32235210)
Thanks, I somehow missed that line.