5 ms·

Performant memory safety is not that big of a feature. GCs are fast enough unless you have real time constraints. If have real time constraints, you probably d

Performant memory safety is not that big of a feature. GCs are fast enough unless you have real time constraints. If have real time constraints, you probably do not care about memory safety that much, unless your system is safety critical. If your system is safety critical, you are using lots of tooling for validation beyond memory safety - and probably some form of model based code generation. That tooling just does not exist for newcomer languages.

eru 6y ago
Where do you have real time constraints but don't care about things blowing up? I guess there's lots of places that have soft real time constraints like in games and other entertainment? But hard real time usually means you do care about not blowing up.
- gridlockd 6y ago
  You answered your own question.
fauigerzigerk 6y ago
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.

eru 6y ago

Where do you have real time constraints but don't care about things blowing up? I guess there's lots of places that have soft real time constraints like in games and other entertainment? But hard real time usually means you do care about not blowing up.

gridlockd 6y ago
You answered your own question.

fauigerzigerk 6y ago

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.