{'fraction_non_alphanumeric': 0.018306636155606407, 'fraction_numerical': 0.0007627765064836003, 'mean_word_length': 5.626262626262626, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Automatic vs. Explicit Memory Management: Settling the Performance Debate

While garbage collection’s software engineering benefits are indisputable, its performance impact remains controversial. Garbage collection proponents argue that its benefits outweigh its costs, but it is widely believed that garbage collection imposes an unacceptably high runtime and space performance penalty. This paper aims to settle this debate. We present the first empirical comparison of the performance costs of automatic versus explicit memory management in a garbage-collected language. Using a tracing and simulation based oracular memory manager, we execute unaltered Java programs as if they used explicit memory management. We examine the runtime, space consumption and virtual memory footprint of Java benchmarks across a range of general-purpose allocators and both copying and non-copying garbage collectors. We show that, at large heap sizes and under no memory pressure, the runtime performance of some garbage collection algorithms is competitive with the Lea memory allocator and occasionally outperforms it by up to 4%. However, our results confirm that garbage collection requires six times the physical memory to achieve this performance and suffers order-of-magnitude performance penalties when paging occurs.