False, True (which is why the first is false; they're not equivalent), False, False. (because) In the 80s optimizers were shit.
Conversation
Both provide memory-safety, but GC also provides fully automated object lifetime management at a high cost in either memory overhead or performance or both, and mostly (entirely?) precludes realtime.
1
I have. It's laughable. They call tens of ms bound on latency "realtime".
1
Let's start with the definition of "hard realtime" here. "hard realtime" means that there is an upper bound on the execution of an operation. It says nothing about the absolute latency.
malloc() in C is a good example. It's usually pretty quick, but it is not realtime.
2
You can easily get hard bounds on malloc latency something like 4us in practice, independent of currently allocated amount, assuming a working realtime scheduler etc.
1
Replying to
Which malloc implementation was that again that doesn't traverse linked lists?
1
Replying to
None of the typical ones "traverse" lists. They simply add or remove an entry in a list, which is constant-time independent of the current size of the list.
1
1
Replying to
They all traverse a list of free chunks to find the next one that's big enough to satisfy the allocation.
I once was paid to write the realtime control software for an atomic force microscope. I know that stuff well enough.
2
Modern allocators are almost always O(1) with dedicated size classes for small allocations. For larger allocations, they're either O(1) with approximate best-fit via buckets of free space sizes (more fragmentation) or O(log n) for precise address ordered best-fit. No traversals.
1
2
The jemalloc approach is a mix of O(1) and O(log n) address ordered best-fit via bitmaps (for slabs) and red-black trees (for larger spans) ordered by (size, addr). They layer O(1) free lists on top as caching, and then small thread-local arrays as local caches on top of that.