Calling GC time "additional overhead" is not entirely correct, imo. Non-GC languages often spend plenty of time dealing with malloc/free, and I consider both GC and malloc/free to be "memory management". Both are non-trivial!

GC usually also comes in "copying" variants, which can have advantages like reducing memory fragmentation.

Granted, malloc/free isn't totally free. But malloc/free languages always seem to be faster than Java in benchmarks, at least the ones I've read and referenced already in the comments around this article. GC also, even if it were faster, comes at the expense of eating RAM like mad, at least if judged by the RAM Java likes to eat. Usually, Java software just consumes 50% of your RAM until the first GC pause. And even before that GC pause, it's dog slow.

Memory fragmentation can more easily be reduced by pooled allocators. For long-running server processes, it can also be possible to just kill the worker processes/threads from time to time. And I've never seen memory fragmentation in manually allocated languages lead to more memory consumption or worse performance than in Java.