Conversation

Even leaving Rust aside, by choosing a memory-unsafe language, you're saying that the small delta in performance between GC and no-GC is worth more to your app than massive unavoidable-in-practice security problems. Seems extremely dubious.

471

Patrick Walton

@pcwalton

May 10

I wonder what fraction of programmers are aware that any GC technique exists other than mark and sweep and naive reference counting.

111

Replying to

the most common complaint about GC i hear isn't the small delta in performance, but the large delta in worst-case latency that makes even soft real-time applications hard to develop

Replying to

and

I thought that fixed in recent years with more latency sensitive algorithms (which some modern languages always use and in case of java you can opt into using)?

Replying to

and

I've never seen them effective in practice. In the real world it seems like with GC you can *maybe* pick one of memory usage, CPU usage, or performance consistency

Replying to

Some of this is hard separate out because GC implementations generally come attached to VMs, etc Pretty sure Java's GC outperforms Go's on many metrics but it's hard to tell because of JIT overheads

Replying to

OpenJDK design choices are very focused on long running server applications. Design choices for the Android Runtime are far different. Has equally modern concurrent compacting GC with a focus on latency for apps in foreground and memory usage in the background, not throughput.

Replying to

Android's JIT compiler is extremely primitive compared to v8 or OpenJDK but that's intentional to preserve battery life and because the focus is on AOT compilation driven by profiles produced by the JIT / interpreter. They distribute those now too:

android-developers.googleblog.com

Improving App Performance with Baseline Profiles

Replying to

Android 5 switched to full AOT compilation for everything other than one-time initialization code because JIT compilation is horrible for memory usage and battery life. Android 6 moved to current hybrid JIT/interpreter/AOT approach where most code used at runtime is AOT compiled.

Replying to

Code run with the interpreter / JIT compiler gets recorded in JIT profiles and then that guides AOT compilation. Over time, you end up with AOT compiled code based on how you use apps. Interpreting the one-time init and cold code makes hot code faster and reduces memory usage.

Replying to

JIT compilation in v8 and OpenJDK uses a ton of resources and a ton of memory. v8 has started focusing more on having a fast interpreter and they actually do cache code for reuse later on but they can't do that aggressively since web sites are so much less predictable than apps.

11:41 PM · May 10, 2022Twitter Web App

Replying to

If you look at an Android app's memory, the GC heap is always in the lower 32-bit in order to use 32-bit pointers and apps have a small heap unless they're badly written and need to enable a large one. There's also special concurrent GC for bitmaps, etc. Special cases help a lot.

Replying to

Simply knowing which apps are in the foreground vs. foreground services vs. background vs. idle/frozen helps a lot with GC. It can be latency focused for the foreground, more throughput focused in the background and heavily compact the heap of the idle apps with frozen threads.

Show replies