>The particular problem is that malloc/free is not free of charge. [...] The problem with this paper is it assumes that malloc/free is cost-free and instantaneous,
I think I get that you're trying to explain how GC overhead is overstated and malloc()/free() is understated but your angle about "malloc not being free of charge" it isn't really the evidence you want to use.
As analogy, we can see that a Lamborghini is faster than a Hyundai. Let's say we state that the performance comparison is flawed because it it still takes the Lamborghini a non-zero amount of time to accelerate to 60 mph (or 100 km/hr) and Lamborghini is still consuming gasoline. While the cost datapoints are true, it still doesn't change the macro observation that the Hyundai is slower.
Also, you're misrepresenting the 2nd paper you cited. The authors do mention "overhead" of malloc. They do not assume that malloc is "cost-free" on page 4:
>3.2 malloc Overhead - When using allocators implemented in C, the oracular memory manager invokes allocation and deallocation functions through the Jikes VM SysCall foreign function call interface. While not free, these calls do not incur as much overhead as JNI invocations. Their total cost is just 11 instructions: six loads and stores, three registerto-register moves, one load-immediate, and one jump. This cost is similar to that of invoking memory operations in C and C++, where malloc and free are functions defined in an external library (e.g., libc.so).
In other words, even if malloc/free is not instantaneous and not cost-free, it can still be faster than GC. Neither paper's conclusions depend on malloc/free taking zero amounts of time or zero cpu instructions. If the papers are flawed, you have to explain it using different logic.
> >3.2 malloc Overhead - When using allocators implemented in C...
That's not even about malloc overhead, it's about the overhead of just calling C malloc. So actual malloc overhead is on top of that.
Malloc and free have pretty unpredictable runtime over time, once a lot of allocations and deallocations have been performed. That's why you don't use either in latency sensitive code, like with realtime requirements.
> In other words, even if malloc/free is not instantaneous and not cost-free, it can still be faster than GC.
Whoah, faster than GC in what regard? GC will probably win the throughput race, or average latency. Manual allocation will likely win the jitter race, lower latency standard deviation.
(I write low level code in C/C++, including kernel drivers and bare metal firmware with hard realtime requirements. Hopefully in the future in Rust or some other memory and concurrency safe language.)
>Malloc and free have pretty unpredictable runtime over time,
Yes, that's another true statement about malloc but it also doesn't matter to the particular point I'm making. To continue your correct & true statements of malloc, we can add:
- malloc has to search the freelist; GC can be just a bump allocation which is faster
- malloc leads to fragmented memory; GC can reorganize and reconsolidate
- malloc doesn't have extra intelligence to assign pointers to shared memory structures (e.g. Java string pool stores identical strings only once based on hashes)
- ... a dozen other true statements about malloc
All those true statements (which most can agree on) isn't the misunderstanding. The issue is misusing those true statements as some type of convincing evidence to explain the papers' flaws. For example:
>Whoah, faster than GC in what regard?
Well, we can just use the total runtime of the the 2 papers benchmarks where there were lots of memory operations. (In other words, we can acknowledge that performance has multiple dimensions/axis but we can also look at the simple measurement of total wall clock time of benchmark code that doesn't do database access or floating point calculations.)
The C/C++ programs ran faster and took up less memory.
Ok, were there flaws in the benchmarks? Then lets explain the specific flaws.
Yes, I can say "malloc runtime is unpredictable" but that true statement doesn't actually explain anything about GC running slower than malloc/free in the papers. We can also say that "malloc is not cost free" as another true statement -- but that also doesn't actually explain the GC's longer elapsed time.
See the problem with those attempted explanations? They're all non-sequiturs.
> Well, we can just use the total runtime of the the 2 papers benchmarks where there were lots of memory operations. (In other words, we can acknowledge that performance has multiple dimensions/axis but we can also look at the simple measurement of total wall clock time of benchmark code that doesn't do database access or floating point calculations.)
...
> See the problem with those attempted explanations? They're all non-sequiturs.
I'm comparing GC vs manual memory management.
You (or the papers) are comparing different implementations of programs in different languages. That might be great for practical considerations for choosing implementation language, but is pointless when comparing those two different memory management strategies. Apples and oranges.
EDIT: I feel "Quantifying the Performance of Garbage Collection vs. Explicit Memory Management" paper is a bit dishonest. From the paper:
> The culprit here is garbage collection activity, which visits far more pages than the application itself [61]. As allocation intensity increases, the number of major garbage collections also increases. Since each garbage collection is likely to visit pages that have been evicted, the performance gap between the garbage collectors and explicit memory managers grows as the number of major collections increases.
Pages got evicted – so their heap ran out of physical RAM and started swapping to disk. Wow.
Yeah, GC uses much more RAM, that's a well known downside. Setting the benchmark up in such a way that causes the system to start swapping is not a fair way to compare GC and manual allocation throughput.
>You (or the papers) are comparing different implementations of programs in different languages.
Fyi... the 2nd paper is using the same language of Java. It just compares different allocation strategies: explicit vs GC. (I think that paper is written in a confusing way.)
My original point back to op (rwmj) was that the computer scientists were quite aware that malloc had a non-zero cost. And pointing that out really doesn't challenge the paper's findings.
Yet several companies on the tourism world circuit happen to use semi-automatic gear boxes that outperform any human driving with manual, so much for the typical car comparisasions.
I think I get that you're trying to explain how GC overhead is overstated and malloc()/free() is understated but your angle about "malloc not being free of charge" it isn't really the evidence you want to use.
As analogy, we can see that a Lamborghini is faster than a Hyundai. Let's say we state that the performance comparison is flawed because it it still takes the Lamborghini a non-zero amount of time to accelerate to 60 mph (or 100 km/hr) and Lamborghini is still consuming gasoline. While the cost datapoints are true, it still doesn't change the macro observation that the Hyundai is slower.
Also, you're misrepresenting the 2nd paper you cited. The authors do mention "overhead" of malloc. They do not assume that malloc is "cost-free" on page 4:
>3.2 malloc Overhead - When using allocators implemented in C, the oracular memory manager invokes allocation and deallocation functions through the Jikes VM SysCall foreign function call interface. While not free, these calls do not incur as much overhead as JNI invocations. Their total cost is just 11 instructions: six loads and stores, three registerto-register moves, one load-immediate, and one jump. This cost is similar to that of invoking memory operations in C and C++, where malloc and free are functions defined in an external library (e.g., libc.so).
In other words, even if malloc/free is not instantaneous and not cost-free, it can still be faster than GC. Neither paper's conclusions depend on malloc/free taking zero amounts of time or zero cpu instructions. If the papers are flawed, you have to explain it using different logic.