{'fraction_non_alphanumeric': 0.0228310502283105, 'fraction_numerical': 0.002609262883235486, 'mean_word_length': 5.445378151260504, '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}}
Thinking Inside the Box: Compartmentalized Garbage Collection

The web browser is the “new desktop.” Not only do many users spend most of their time using the browser, the browser has also become host to rich and dynamic applications that were previously tailored to each individual operating system. The lingua franca of web scripting, JavaScript, was pivotal in this development.
 Imagine that all desktop applications allocated memory from a single heap managed by the operating system. To reclaim memory upon application shutdown, all processes would then be garbage collected—not just the one being quit. While operating systems improved upon this approach long ago, this was how browsers managed memory until recently.
 This article explores compartmentalized memory management, an approach tailored specifically to web browsers. The idea is to partition the JavaScript heap into compartments and allocate objects to compartments based on their origin. All objects in the same compartment reference each other direct, whereas cross-origin references go through wrapper objects.
 We carefully evaluate our techniques using Mozilla’s Firefox browser—which now ships with our enhancements—and demonstrate the benefits of collecting each compartment independently. This simultaneously improves runtime performance (up to 36%) and reduces garbage collection pause times (up to 75%) as well as the memory footprint of the browser. In addition, enforcing the same-origin security policy becomes simple and efficient with compartments.