Le projet d'amélioration du JDK - JDK Enhancement Proposal - (JEP) intitulé « Throughput post-write barrier for G1 » lancé par la communauté OpenJDK permettrait au ramasse-miettes d’optimiser le débit quand le raffinement simultané est désactivé pour obtenir un meilleur débit au détriment la latence pour certaines charges de travail indifférentes à cette latence.
Le projet pourrait être implémenté à l’aide d'un nouvel indicateur JVM, -XX:-G1UseConcRefinement, qui désactiverait le raffinement simultané et permettrait à G1 d'utiliser une « barrière post-écriture de débit » ou « post-write barrier ». Selon la proposition, G1UseConcRefinement serait activé par défaut, et l'utilisation de -XX:-G1UseConcRefinement augmenterait le débit de G1 et réduirait l'utilisation du CPU.
Traitements simultanés
La barrière d'écriture ou « write barrier » simplifiée serait beaucoup plus courte en longueur, ce qui améliorerait le taux de réponse du cache. Ce mode réduirait la charge de travail de compilation et de traitement des « dirty cards » par les compilateurs JIT. De plus, ce mode diminuerait l'empreinte mémoire en réduisant le nombre de sets mémorisés et en n'utilisant pas de files d'attente par fil de discussion pour les « dirty cards » créées par le code Java.
G1 a actuellement une barrière d'écriture post-référence plus complexe que les « write barriers » des ramasse-miettes plus traditionnels comme le collecteur Concurrent Mark Sweep. Cette complexité est due en grande partie à la prise en charge du traitement simultané, qui transfère une partie du travail de scan pendant la pause de la collecte vers le travail de l'application. Le mécanisme subit des dommages perceptibles pendant l'exécution.
La proposition ne permettrait pas à la machine virtuelle Java de déterminer quand désactiver le raffinement simultané et à quel moment optimiser les barrières. La proposition ne limiterait pas non plus la disponibilité d'autres fonctions G1 comme la déduplication des chaînes quand le raffinement simultané est désactivé.