To be clear, in enterprise (non-embedded / non-mobile) programming, this is fine. Money (RAM) isn't the issue. Programmers with domain knowledge are much more expensive than adding more hosts or RAM. I am talking about the general case; I know HN loves to focus on "high performance / low latency", but that is less than 1% in "Enterprise Real World".

I don't know if there is a typical heap size.

My TXR Lisp is garbage collected. When I blow away all the compiled files of the standard library and run a rebuild, in a separate window running top, I do not ever see a snapshot of any txr process using more than 27 megs of RAM:

This is close to the worst-case observed:

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
  19467 kaz       20   0   27364  24924   3112 R 100.0  1.2   0:30.55 txr

When this is happening, the library code is being interpreted as it compiles itself, it by bit. E.g. when stdlib/optimize.tl is being compiled, I see this 27 megs usage. But after the entire library is compiled, if I just "touch stdlib/optimize.tl" to force that to rebuild, it's a lot leaner; I see it hit about 16 megs.

Sitting at a REPL prompt, compared to some bash processes, using ps -aux:

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND     
  USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
  kaz       2433  0.0  0.0   8904  1900 pts/0    Ss   Feb22   0:00 -bash
  kaz       6179  0.0  0.2   9072  4212 pts/1    Ss+  Apr22   0:01 -bash
  kaz      18551  0.0  0.1  11152  3932 pts/2    Ss+  Feb22   1:32 -bash
  kaz      18836  0.0  0.1   9064  2196 pts/5    Ss+  Apr13   0:02 -bash
  kaz      19079  0.0  0.2  13464  4880 pts/3    Ss   Mar01   0:40 -bash

  kaz      19849  0.1  0.2   9360  6024 pts/4    S+   23:45   0:00 txr

Oh, and that's the regular build of TXR. If that's too bloated, you can try CONFIG_SMALL_MEM.

Large is as large does.

Garbage collection was once used on systems in which most of today's software would not fit.

Garbage collection does have waste. You allocate more than you need, and keep it.

Precise, manual memory management does the same thing. Firstly, the technique of keeping around memory is practiced under manual memory management. E.g. C programs keep objects on recycle lists instead of calling free. And free itself, will not release memory to the OS, except in certain circumstances. Then there is internal fragmentation. Generally, programs that "get fat" during some peak workload will stay that way.

If you see some garbage collected system need hundreds of megabytes of RAM just for a base image, it may not be the GC that's to blame, or not entirely: it's all the bloated crap they are pulling into the image. Or it could also be that the GC was tuned by someone under thirty who doesn't think it's weird for a browser with three tabs open to be taking 500 megs. GC can be tuned as badly as you want; you can program it not to collect anything until the VM footprint is past the physical RAM available.

"it may not be the GC that's to blame, or not entirely: it's all the bloated crap they are pulling into the image"

Again, you keep waving your hands in the air and saying if you don't do that, you'll be fine.