3 ms·

Tracing GCs are only fast and predictable enough if you devote roughly half of your memory and a significant share of CPU/battery to them. And of course garbag

Tracing GCs are only fast and predictable enough if you devote roughly half of your memory and a significant share of CPU/battery to them. And of course garbage collection is only part of what's needed for memory safety.

gridlockd 6y ago
I don't think the CPU overhead is that significant. The memory storage overhead is significant, but that's "solved" by just requiring more memory. I guess we can all thank Java for keeping the DRAM business in good shape. I'm not talking about what's optimal or efficient, I'm talking about what's evidently "good enough" in the real world.
- fauigerzigerk 6y ago
  All GC overheads obviously depend a lot of the specific workload, but if I'm provisioning for a varied workload I would assume 20% CPU overhead and 100% extra memory. Whether or not that's good enough depends on the task as well as on your margins, business model and competition. The cost of hosting grows roughly in proportion with memory capacity (Yes I know it's more complex and nuanced than that). If you deploy on user provisioned hardware (such as on mobile devices or existing/aging PCs), using half as much memory and significantly less CPU/battery than your competitors may give you a competitive edge.
thu2111 6y ago
That's not been true for a while. GCs like ZGC can handle tiny heaps with no pauses, pretty minimal heap wastage and a ~10% throughput hit vs a more middle of the road GC. You're thinking of the Go GC and assuming they must be all like that.
- fauigerzigerk 6y ago
  I'll be very happy once claims about improved GC performance turn into actual reality for my workloads. What is "pretty minimal heap wastage"? As far as I can see, ZGC (which is currently marked as experimental) doesn't give any specific performance guarantees. It'll be interesting to try. "How much headroom is needed very much depends on the allocation rate and the live-set size of the application. In general, the more memory you give to ZGC the better." https://docs.oracle.com/en/java/javase/13/gctuning/z-garbage-collector1.html#GUID-A5A42691-095E-47BA-B6DC-FB4E5FAA43D0 https://docs.oracle.com/en/java/javase/13/gctuning/z-garbage...
  - thu2111 6y ago
    Heap wastage is tunable vs CPU time, but it's less than the 100% go uses. If you have spare RAM your app will run faster, is the usual tradeoff.

gridlockd 6y ago

I don't think the CPU overhead is that significant. The memory storage overhead is significant, but that's "solved" by just requiring more memory. I guess we can all thank Java for keeping the DRAM business in good shape. I'm not talking about what's optimal or efficient, I'm talking about what's evidently "good enough" in the real world.

fauigerzigerk 6y ago
All GC overheads obviously depend a lot of the specific workload, but if I'm provisioning for a varied workload I would assume 20% CPU overhead and 100% extra memory. Whether or not that's good enough depends on the task as well as on your margins, business model and competition. The cost of hosting grows roughly in proportion with memory capacity (Yes I know it's more complex and nuanced than that). If you deploy on user provisioned hardware (such as on mobile devices or existing/aging PCs), using half as much memory and significantly less CPU/battery than your competitors may give you a competitive edge.

thu2111 6y ago

That's not been true for a while. GCs like ZGC can handle tiny heaps with no pauses, pretty minimal heap wastage and a ~10% throughput hit vs a more middle of the road GC. You're thinking of the Go GC and assuming they must be all like that.

fauigerzigerk 6y ago
I'll be very happy once claims about improved GC performance turn into actual reality for my workloads. What is "pretty minimal heap wastage"? As far as I can see, ZGC (which is currently marked as experimental) doesn't give any specific performance guarantees. It'll be interesting to try. "How much headroom is needed very much depends on the allocation rate and the live-set size of the application. In general, the more memory you give to ZGC the better." https://docs.oracle.com/en/java/javase/13/gctuning/z-garbage-collector1.html#GUID-A5A42691-095E-47BA-B6DC-FB4E5FAA43D0 https://docs.oracle.com/en/java/javase/13/gctuning/z-garbage...
- thu2111 6y ago
  Heap wastage is tunable vs CPU time, but it's less than the 100% go uses. If you have spare RAM your app will run faster, is the usual tradeoff.