La première version des sources du JEP 189, le projet Shenandoah, visant à créer un garbage collector (GC) quasi sans pause pour OpenJDK a été publiée. Le projet Shenandoah a été annoncé en juin 2013 par Roman Kennke, Ingénieur chez Red Hat. Son objectif est de contourner les limitations des GC existants dans OpenJDK avec les heap de plusieurs dizaines de Go. En effet, parmi les différents GC proposés par OpenJDK, tous vont, à un moment, soit à chaque collection majeure, soit uniquement dans leurs cas extrêmes, stopper l'application durant une période dépendant du nombre de références à scanner. Pour compacter la mémoire, il est nécessaire de parcourir toutes les références et les faire pointer vers le nouvel emplacement de l'objet référencé. Avec des heap de plusieurs Go voire dizaines de Go, et leur nombre d'objets important, les pauses peuvent devenir trop longues pour respecter les SLA.
Un serveur moderne, même d'entrée de gamme, peut posséder des dizaines de Go de RAM, la JVM est donc un facteur limitant pour l'utilisation des capacités des serveurs, les applications doivent donc êtres capables de passer à l'échelle horizontalement, ce qui augmente les coûts et contraintes d'architecture et de développement.
La JVM Zing, développée par Azul Systems et nécessitant une licence, peut gérer des heap de très grande taille sans souffrir de longues pauses. Les pauses de Zing se mesurent en millisecondes quelle que soit la taille de la heap grâce à un algorithme de garbage collection complètement concurrent, même pour la phase de compaction. Des explications détaillées sont disponibles ici, en Anglais.
L'objectif de Shenandoah est de pouvoir gérer des heap mesurées en teraoctets avec des pauses de l'ordre de 10 ms. Pour atteindre cet objectif, Shenandoah doit être capable de réaliser l'évacuation et la compaction de façon concurrente à l'application et indépendamment de la taille de la heap. Pour cela, Shenandoah va découper la heap en plusieurs régions et produire des statistiques sur leur proportion de garbage pour choisir celles à collecter. Il va aussi mettre à contribution les threads applicatifs pour déplacer et corriger les références accédées dans les régions cibles du garbage collector.
En l'état actuel des sources, les bases de ce nouveau garbage collectors sont posées, mais il reste beaucoup de travail, en particuler pour supporter le compilateur JIT C2 (le mode -server d'OpenJDK) et améliorer les performances.