Ramasse-miette pour les applications avec forte utilisation de la mémoire sur architectures NUMA

Afin de maximiser la localité des accès mémoire pendant la phase de collection, un thread GC évite d’accéder un autre noeud mémoire en notifiant à la place un thread GC distant avec un message. Néanmoins, NumaGiC évite les inconvénients d’un design complètement distribué qui tend à diminuer le parallélisme et augmenter le déséquilibre des accès mémoire en permettant aux threads de voler depuis les autres noeuds quand ceux-ci sont inactifs. NumaGiC fait son possible pour trouver un équilibre parfait entre les accès distant, le déséquilibre des accès mémoire et le parallélisme. Dans ce travail, nous comparons NumaGiC avec Parallel Scavenge et certaines de ses variantes améliorées de façon incrémentale sur deux architectures ccNUMA en utilisant la machine virtuelle Hotspot d’OpenJDK 7. Sur Spark et Neo4j, deux applications d’informatique décisionnelle de niveau industriel, avec une taille de tas allant de 160 GB à 350 GB, et sur SPECjbb2013 et SPECjbb2005, NumaGiC améliore la performance globale jusqu’à 94% par rapport à Parallel Scavenge et améliore la performance du collecteur lui-même jusqu’à 5,4times par rapport à Parallel Scavenge. En terme de passage à l’échelle du débit du GC en augmentant le nombre de noeuds NUMA, NumaGiC passe à l’échelle beaucoup mieux qu’avec Parallel Scavenge pour toutes les applications. Dans le cas de SPECjbb2005, où les références inter-objets sont les moins nombreuses parmi toutes les applications, NumaGiC passe à l’échelle quasiment linéairement.Large-scale multicore architectures create new challenges for garbage collectors (GCs). On con-temporary cache-coherent Non-Uniform Memory Access (ccNUMA) architectures, applications with a large memory footprint suffer from the cost of the garbage collector (GC), because, as the GC scans the reference graph, it makes many remote memory accesses, saturating the interconnect between memory nodes. In this thesis, we address this problem with NumaGiC, a GC with a mostly-distributed design. In order to maximise memory access locality during collection, a GC thread avoids accessing a different memory node, instead notifying a remote GC thread with a message; nonetheless, NumaGiC avoids the drawbacks of a pure distributed design, which tends to decrease parallelism and increase memory access imbalance, by allowing threads to steal from other nodes when they are idle. NumaGiC strives to find a perfect balance between local access, memory access balance, and parallelism. In this work, we compare NumaGiC with Parallel Scavenge and some of its incrementally improved variants on two different ccNUMA architectures running on the Hotspot Java Virtual Machine of OpenJDK 7. On Spark and Neo4j, two industry-strength analytics applications, with heap sizes ranging from 160 GB to 350 GB, and on SPECjbb2013 and SPECjbb2005, NumaGiC improves overall performance by up to 94% over Parallel Scavenge, and increases the performance of the collector itself by up to 5.4× over Parallel Scavenge. In terms of scalability of GC throughput with increasing number of NUMA nodes, NumaGiC scales substantially better than Parallel Scavenge for all the applications. In fact in case of SPECjbb2005, where inter-node object references are the least among all, NumaGiC scales almost linearly