3 ms·

Is anyone still using transporting (copying) collectors these days? Without forwarding pointers you can only do it via stop and copy. I’m not sure I’d want to

by gumby 3y ago

Is anyone still using transporting (copying) collectors these days? Without forwarding pointers you can only do it via stop and copy. I’m not sure I’d want to implement forwarding pointers without hardware support for transparency.

monocasa 3y ago
Yeah, because you need a copying collector to be generational and to compact. You do have to stop, but you don't have to stop normal execution threads for very long (under a millisecond for ZGC, and the time doesn't scale with heap size).
kryptiskt 3y ago
It's quite common with generational GCs, The nursery is small and many objects die early, so not a lot has to copied in minor collections. I've never seen one without forwarding pointers, it seems to me that they are necessary for updating all references.
- hayley-patton 3y ago
  For what it's worth, compaction with my mark-region GC for SBCL follows "An algorithm for parallel incremental compaction" <https://dl.acm.org/doi/10.1145/773039.512442 https://dl.acm.org/doi/10.1145/773039.512442> which instead logs all references to the objects we want to move while tracing, rather than using forwarding pointers. Well, not quite - the runtime likes to eagerly copy lists to get them contiguous after copying, and so we still use forwarding pointers to avoid copying cons cells twice. (The mutator also won't ever see forwarding pointers regardless, if you have a STW GC. And if that GC works.)
chubot 3y ago
??? Just about all high performance GCs use moving GCs for the young/fast generation, to get bump allocation Examples: The whole v8 lineage of VMs, and SpiderMonkey followed shortly thereafter Java Hotspot and most fast alternatives Femtolisp used to bootstrap Julia is a moving GC with no generations Forwarding is not really a problem, the algorithm is well known Rooting is a difficult problem in many contexts — both C and webassembly. You need precise rooting to implement moving GC, that’s the main implementation issue (On my phone, sorry no links)
- sph 3y ago
  If you find the time to share links, it would be much appreciated. Thanks for the pointers (heh) anyway.
  - chubot 3y ago
    Sure, most of the links are in the posts I wrote about it: https://www.oilshell.org/blog/2022/10/garbage-collector.html https://www.oilshell.org/blog/2022/10/garbage-collector.html https://www.oilshell.org/blog/2023/01/garbage-collector.html https://www.oilshell.org/blog/2023/01/garbage-collector.html AFAIK, the Cheney algorithm is the only way to do copying/moving GC. It's tiny and elegant, and I took a picture of it for a contributor: https://app.oilshell.org/picdir/resize?name=193n849__4477C231-A723-4D13-A4EC-5904428ADECE.jpeg&max-width=1000&rotation=1 https://app.oilshell.org/picdir/resize?name=193n849__4477C23... The GC handbook explanation was better than anything I found online, including in wikipedia. But GC handbook is also not engineering-focused (see blog posts). It surprisingly difficult to write a GC -- I have new respect for this problem! As mentioned, we ended up going to a non-moving collector, mainly because debugging is harder, it breaks tools, and it involves even more rooting. And rooting problem is hard, especially in C/C++. The GCs in C++ like v8 and SpiderMonkey are a bit hard to read -- it is almost like a special dialect of C++. I found the plain C femtolisp and es shell easier to read. And some toy examples on Github, but many of them (even from engineers I know to be great) were VERY incomplete, and not designed in context. Don't trust an example GC that hasn't been used in production! It probably has bugs or a bad API for rooting! femtolisp is probably the closest thing to "small" and "used in production" that I found (since it's used to bootstrap Julia)
- mananaysiempre 3y ago
  > Forwarding is not really a problem, the algorithm is well known I understand it’s not a problem to make forwarding work, but making it not suck doesn’t seem easy. My impression from the literature was that a moving collector requires either an O(heap) pause + write barrier (to rewrite all pointers at once), or a read barrier (to catch stale pointers on the fly), and neither of these options is all that pleasant—read barriers in particular are often decried as expensive. On the other hand, the articles doing the decrying are usually using a SPARC or the like as their reference point for up-to-date powerful hardware, so I’ve no idea how true any of this is in today’s superscalar world.
aardvark179 3y ago
A lot of engineering has gone into GCs over the years to avoid the need to stop the world when copying objects around, and no hardware support is needed for the pointer chasing. You do need support for atomic swaps and sometimes some MMU tricks but other than that you’re good.
rurban 3y ago
I'm using copying with forwarding pointers. Compacting and no stop-the world mess.

by gumby 3y ago

monocasa 3y ago

Yeah, because you need a copying collector to be generational and to compact. You do have to stop, but you don't have to stop normal execution threads for very long (under a millisecond for ZGC, and the time doesn't scale with heap size).

kryptiskt 3y ago

It's quite common with generational GCs, The nursery is small and many objects die early, so not a lot has to copied in minor collections. I've never seen one without forwarding pointers, it seems to me that they are necessary for updating all references.

hayley-patton 3y ago
For what it's worth, compaction with my mark-region GC for SBCL follows "An algorithm for parallel incremental compaction" <https://dl.acm.org/doi/10.1145/773039.512442 https://dl.acm.org/doi/10.1145/773039.512442> which instead logs all references to the objects we want to move while tracing, rather than using forwarding pointers. Well, not quite - the runtime likes to eagerly copy lists to get them contiguous after copying, and so we still use forwarding pointers to avoid copying cons cells twice. (The mutator also won't ever see forwarding pointers regardless, if you have a STW GC. And if that GC works.)

chubot 3y ago

??? Just about all high performance GCs use moving GCs for the young/fast generation, to get bump allocation Examples: The whole v8 lineage of VMs, and SpiderMonkey followed shortly thereafter Java Hotspot and most fast alternatives Femtolisp used to bootstrap Julia is a moving GC with no generations Forwarding is not really a problem, the algorithm is well known Rooting is a difficult problem in many contexts — both C and webassembly. You need precise rooting to implement moving GC, that’s the main implementation issue (On my phone, sorry no links)

sph 3y ago
If you find the time to share links, it would be much appreciated. Thanks for the pointers (heh) anyway.
- chubot 3y ago
  Sure, most of the links are in the posts I wrote about it: https://www.oilshell.org/blog/2022/10/garbage-collector.html https://www.oilshell.org/blog/2022/10/garbage-collector.html https://www.oilshell.org/blog/2023/01/garbage-collector.html https://www.oilshell.org/blog/2023/01/garbage-collector.html AFAIK, the Cheney algorithm is the only way to do copying/moving GC. It's tiny and elegant, and I took a picture of it for a contributor: https://app.oilshell.org/picdir/resize?name=193n849__4477C231-A723-4D13-A4EC-5904428ADECE.jpeg&max-width=1000&rotation=1 https://app.oilshell.org/picdir/resize?name=193n849__4477C23... The GC handbook explanation was better than anything I found online, including in wikipedia. But GC handbook is also not engineering-focused (see blog posts). It surprisingly difficult to write a GC -- I have new respect for this problem! As mentioned, we ended up going to a non-moving collector, mainly because debugging is harder, it breaks tools, and it involves even more rooting. And rooting problem is hard, especially in C/C++. The GCs in C++ like v8 and SpiderMonkey are a bit hard to read -- it is almost like a special dialect of C++. I found the plain C femtolisp and es shell easier to read. And some toy examples on Github, but many of them (even from engineers I know to be great) were VERY incomplete, and not designed in context. Don't trust an example GC that hasn't been used in production! It probably has bugs or a bad API for rooting! femtolisp is probably the closest thing to "small" and "used in production" that I found (since it's used to bootstrap Julia)
mananaysiempre 3y ago
> Forwarding is not really a problem, the algorithm is well known I understand it’s not a problem to make forwarding work, but making it not suck doesn’t seem easy. My impression from the literature was that a moving collector requires either an O(heap) pause + write barrier (to rewrite all pointers at once), or a read barrier (to catch stale pointers on the fly), and neither of these options is all that pleasant—read barriers in particular are often decried as expensive. On the other hand, the articles doing the decrying are usually using a SPARC or the like as their reference point for up-to-date powerful hardware, so I’ve no idea how true any of this is in today’s superscalar world.

aardvark179 3y ago

A lot of engineering has gone into GCs over the years to avoid the need to stop the world when copying objects around, and no hardware support is needed for the pointer chasing. You do need support for atomic swaps and sometimes some MMU tricks but other than that you’re good.

rurban 3y ago

I'm using copying with forwarding pointers. Compacting and no stop-the world mess.