5 ms·

I don't get why people are scared of GC. After working in embedded software, using mostly C, it was evident from profiling that C programs spend a lot of time a

I don't get why people are scared of GC. After working in embedded software, using mostly C, it was evident from profiling that C programs spend a lot of time allocating and releasing memory. And those programs usually release memory in place, unlike GC languages where the release is deferred, done in parallel, and with time-boxed pauses. Most "systems" programs use worse memory management strategies than what a modern GC actually offers. Sure, some devices require using static memory allocations or are quite restricted. But a lot of other "system programming" targets far more capable machines.

flohofwoe 2y ago
> that C programs spend a lot of time allocating and releasing memory ...then this code didn't get the point of manual memory management, which is to minimize allocations and move them out of the hot path. Unfortunately a lot of C and C++ code is still stuck in a 1990's OOP model where each individual object is explicitly constructed and destroyed, and each construction and destruction is linked to an alloc/free call. If you do this (or reach for reference counting, which isn't much better), a GC is indeed the better choice.
- estebarb 2y ago
  Moving out the allocations/releases out the hot path seems too much like a GC. Also, not all programs can be easily optimized moving the allocations: databases are an example, usually you don't know how much rows are you going to touch until you process the query.
  - flohofwoe 2y ago
    Tigerbeetle is famously a database that doesn't do dynamic memory allocation at all (after startup): https://tigerbeetle.com/blog/a-database-without-dynamic-memory https://tigerbeetle.com/blog/a-database-without-dynamic-memo...
  - Nevermark 2y ago
    Technically, GC can be part of manual memory management. The "manual" doesn't mean any algorithm is ruled out - it just means the developer mindfully chooses the right algorithm for the right situation. As apposed to the language, compiler or system always making those decisions.
  - pjc50 2y ago
    > Moving out the allocations/releases out the hot path seems too much like a GC Absolutely not. It just requires a certain amount of planning and puts work on the callers to ensure that they prepare a suitable allocation somewhere, which may be on the stack or inside some structure or array that already exists. The limit case is the common embedded style of statically allocating everything. Often combined with a ban on recursion and (manually or automatically enforced) limits on stack size. If you don't have a lot of bytes you can plan your usage of each of them individually. MISRA rule 20.4 just plainly states "Dynamic heap memory allocation shall not be used." The very opposite of GC. https://wwwfiles.iar.com/superh/guides/EW_MISRAC2004Reference.pdf https://wwwfiles.iar.com/superh/guides/EW_MISRAC2004Referenc...
refulgentis 2y ago
I was stunned how many engineers I met at Google who didn't know memory allocation takes a ton of time, didn't fundamentally believe it when you told them, and just sort of politely demurred on taking patches for it - first get me data, then walk me through the data, then show me how to get the data myself, then silence, because profiling ain't trivial. There's a 3x speedup sitting in a library because it's in a sea of carefully optimized functions manipulating floats, and someone made a change to extract a function that returned an array. It was such a good Chesterton fence: change seemed straightforward and obvious, better readability. But, it had cascading effects that essentially led to 9 on-demand array allocations in the midst of about 80 LOC of pure math. In my experience, there's hangover from two concepts: - Android does garbage collection and Android is slower than iOS - You can always trade CPU time for memory and vice versa (ex. we can cache function results, which uses more memory, but less CPU)
- pjmlp 2y ago
  > Android does garbage collection and Android is slower than iOS Thing is, not only has Android runtime witness several JIT and GC refactorings since Darwin was created, originally worse than Sony and Nokia's J2ME implementations regardless of Google's marketing otherwise, there are so many factors contributing to Android's perceived slowness from bad coded UIs, sloppy programing, cheapstakes OEMs with low performance chips, and so on. On the other hand on iOS side, due to lack of GC and OS paging, when memory goes bad, applications just die.
- toast0 2y ago
  > Android does garbage collection and Android is slower than iOS There's a lot of things going on that make this the case. Android was built with unrestrained multitasking; there's a lot of restraint now, but there's probably still a ton of stuff going on from unrelated processes while your foreground app is chugging along. iOS locks down background execution, and I suspect system apps have limited background execution as well. Less task switching and less cache pollution help a lot. iOS only runs on premium phones. Even Apple's lower priced phones are premium phones. Android isn't necessarily quick on premium phones, but it can be much worse on phones designed to a $50 price point. IMHO, A large issue is that the official UI toolkits are terribly slow. I'm more of a backend person, but I put together a terrible weather app, and first paint is very slow, even though it starts with placeholder data (or serialized data from a previous run); using an HTML view was much faster because it only makes one toolkit objeft and more capable because css layout lets you wrap text around an image nicely. Maybe there's some trick I'm not aware of to make 'native ui' not terrible on Android... but that experience helped me understand why everything is so slow to start.
pjmlp 2y ago
It is the consequence of urban performance myths being propagated by gut feeling.
kbolino 2y ago
If a "systems" program can afford GC, then I would consider it mischaracterized. The whole premise of "systems" programming IMO is that you need the code to behave exactly in the way specified, without unexpected preemption (i.e., preemption can only occur at controlled locations and/or for controlled durations). I think a lot of "embedded" software really isn't "systems" software, though the two get conflated a lot. Note that GC cannot possibly promise "time-boxed pauses" in the general case; either allocations are allowed to outpace collections, in which case a longer collection pause will eventually be required to avoid memory exhaustion, or else allocations must be throttled, which just pushes an unbounded pause forward to allocation time.
- pjmlp 2y ago
  Xerox PARC, ETHZ, DEC Olivetti, Microsoft Research, Genera, and even Bell Labs had another understanding of systems programming.
  - kbolino 2y ago
    Do tell
    - pjmlp 2y ago
      Xerox PARC => Smalltalk, Mesa/Cedar, Interlisp-D ETHZ => Oberon, Oberon-2, Active Oberon, Component Pascal (via Oberon Systems, a startup spinoff out of ETHZ), Oberon-07. DEC Olivetti => Modula-2+, Modula-3 Microsoft Research => Singularity, Midori Genera and TI => Lisp Machines Bell Labs => C@+ (really confusing name, one of the few sources are a couple of DDJ articles), Limbo
      - kbolino 2y ago
        I am quite ignorant about how these systems actually worked. I have heard of Lisp Machines before; the Alto and Lilith seem similar in that they're purpose-built hardware focused on running particular languages (or families of languages). The others are kind of hard to find relevant information about. My cursory understanding of these environments is that the hardware did a lot "more" than modern micros and so the system software could enjoy many luxuries that a typical modern operating system has to build for itself. They also didn't work well with languages they weren't designed for.

flohofwoe 2y ago

> that C programs spend a lot of time allocating and releasing memory ...then this code didn't get the point of manual memory management, which is to minimize allocations and move them out of the hot path. Unfortunately a lot of C and C++ code is still stuck in a 1990's OOP model where each individual object is explicitly constructed and destroyed, and each construction and destruction is linked to an alloc/free call. If you do this (or reach for reference counting, which isn't much better), a GC is indeed the better choice.

estebarb 2y ago
Moving out the allocations/releases out the hot path seems too much like a GC. Also, not all programs can be easily optimized moving the allocations: databases are an example, usually you don't know how much rows are you going to touch until you process the query.
- flohofwoe 2y ago
  Tigerbeetle is famously a database that doesn't do dynamic memory allocation at all (after startup): https://tigerbeetle.com/blog/a-database-without-dynamic-memory https://tigerbeetle.com/blog/a-database-without-dynamic-memo...
- Nevermark 2y ago
  Technically, GC can be part of manual memory management. The "manual" doesn't mean any algorithm is ruled out - it just means the developer mindfully chooses the right algorithm for the right situation. As apposed to the language, compiler or system always making those decisions.
- pjc50 2y ago
  > Moving out the allocations/releases out the hot path seems too much like a GC Absolutely not. It just requires a certain amount of planning and puts work on the callers to ensure that they prepare a suitable allocation somewhere, which may be on the stack or inside some structure or array that already exists. The limit case is the common embedded style of statically allocating everything. Often combined with a ban on recursion and (manually or automatically enforced) limits on stack size. If you don't have a lot of bytes you can plan your usage of each of them individually. MISRA rule 20.4 just plainly states "Dynamic heap memory allocation shall not be used." The very opposite of GC. https://wwwfiles.iar.com/superh/guides/EW_MISRAC2004Reference.pdf https://wwwfiles.iar.com/superh/guides/EW_MISRAC2004Referenc...

refulgentis 2y ago

I was stunned how many engineers I met at Google who didn't know memory allocation takes a ton of time, didn't fundamentally believe it when you told them, and just sort of politely demurred on taking patches for it - first get me data, then walk me through the data, then show me how to get the data myself, then silence, because profiling ain't trivial. There's a 3x speedup sitting in a library because it's in a sea of carefully optimized functions manipulating floats, and someone made a change to extract a function that returned an array. It was such a good Chesterton fence: change seemed straightforward and obvious, better readability. But, it had cascading effects that essentially led to 9 on-demand array allocations in the midst of about 80 LOC of pure math. In my experience, there's hangover from two concepts: - Android does garbage collection and Android is slower than iOS - You can always trade CPU time for memory and vice versa (ex. we can cache function results, which uses more memory, but less CPU)

pjmlp 2y ago
> Android does garbage collection and Android is slower than iOS Thing is, not only has Android runtime witness several JIT and GC refactorings since Darwin was created, originally worse than Sony and Nokia's J2ME implementations regardless of Google's marketing otherwise, there are so many factors contributing to Android's perceived slowness from bad coded UIs, sloppy programing, cheapstakes OEMs with low performance chips, and so on. On the other hand on iOS side, due to lack of GC and OS paging, when memory goes bad, applications just die.
toast0 2y ago
> Android does garbage collection and Android is slower than iOS There's a lot of things going on that make this the case. Android was built with unrestrained multitasking; there's a lot of restraint now, but there's probably still a ton of stuff going on from unrelated processes while your foreground app is chugging along. iOS locks down background execution, and I suspect system apps have limited background execution as well. Less task switching and less cache pollution help a lot. iOS only runs on premium phones. Even Apple's lower priced phones are premium phones. Android isn't necessarily quick on premium phones, but it can be much worse on phones designed to a $50 price point. IMHO, A large issue is that the official UI toolkits are terribly slow. I'm more of a backend person, but I put together a terrible weather app, and first paint is very slow, even though it starts with placeholder data (or serialized data from a previous run); using an HTML view was much faster because it only makes one toolkit objeft and more capable because css layout lets you wrap text around an image nicely. Maybe there's some trick I'm not aware of to make 'native ui' not terrible on Android... but that experience helped me understand why everything is so slow to start.

pjmlp 2y ago

It is the consequence of urban performance myths being propagated by gut feeling.

kbolino 2y ago

If a "systems" program can afford GC, then I would consider it mischaracterized. The whole premise of "systems" programming IMO is that you need the code to behave exactly in the way specified, without unexpected preemption (i.e., preemption can only occur at controlled locations and/or for controlled durations). I think a lot of "embedded" software really isn't "systems" software, though the two get conflated a lot. Note that GC cannot possibly promise "time-boxed pauses" in the general case; either allocations are allowed to outpace collections, in which case a longer collection pause will eventually be required to avoid memory exhaustion, or else allocations must be throttled, which just pushes an unbounded pause forward to allocation time.

pjmlp 2y ago
Xerox PARC, ETHZ, DEC Olivetti, Microsoft Research, Genera, and even Bell Labs had another understanding of systems programming.
- kbolino 2y ago
  Do tell
  - pjmlp 2y ago
    Xerox PARC => Smalltalk, Mesa/Cedar, Interlisp-D ETHZ => Oberon, Oberon-2, Active Oberon, Component Pascal (via Oberon Systems, a startup spinoff out of ETHZ), Oberon-07. DEC Olivetti => Modula-2+, Modula-3 Microsoft Research => Singularity, Midori Genera and TI => Lisp Machines Bell Labs => C@+ (really confusing name, one of the few sources are a couple of DDJ articles), Limbo
    - kbolino 2y ago
      I am quite ignorant about how these systems actually worked. I have heard of Lisp Machines before; the Alto and Lilith seem similar in that they're purpose-built hardware focused on running particular languages (or families of languages). The others are kind of hard to find relevant information about. My cursory understanding of these environments is that the hardware did a lot "more" than modern micros and so the system software could enjoy many luxuries that a typical modern operating system has to build for itself. They also didn't work well with languages they weren't designed for.