Le code référencé dans cet article provient d'un exemple de code disponible sur le blog Oracle concernant Epsilon GC.

Dans cet article, nous explorons une option particulièrement intrigante de Java Garbage Collection (GC) connue sous le nom d'Epsilon GC. Cet algorithme de garbage collection se distingue par sa particularité : il n’effectue aucun garbage collection. Le garbage collector (GC) Epsilon a été inclus dans JDK 11.

Mais à quoi sert un ramasse-miettes s'il ne collecte pas ? (pigiste hein !!)

Non, c'est en fait très utile, un cas d'utilisation tel que celui fourni par le blog Oracle, que j'ai légèrement amélioré pour être plus utile.

Pour plus de détails, veuillez vous référer à l'article de blog original :
https://blogs.oracle.com/javamagazine/post/epsilon-the-jdks-do-nothing-garbage-collector

Le cas d'utilisation : Epsilon GC est bénéfique pour les développeurs qui ont besoin d'évaluer l'allocation de mémoire pour un segment particulier de code sans l'aide d'un outil de profilage.

Défi principal Les garbage collectors traditionnels peuvent masquer les mesures précises d'utilisation de la mémoire en effaçant continuellement les objets. Cette interférence rend difficile la détermination de la véritable consommation de mémoire de votre code.

Epsilon GC résout ce problème en agissant en tant que non-collecteur. Bien qu'il ne s'agisse pas d'un algorithme de garbage collection en soi, il sert d'outil pour comprendre l'allocation de mémoire en s'abstenant d'effectuer un garbage collection, fournissant ainsi une image claire de l'utilisation de la mémoire.

Remarque : Il est important de savoir que, étant donné qu'Epsilon GC ne récupère pas de mémoire, une allocation excessive peut entraîner une erreur OutOfMemoryError (OOM) dans la JVM.

Vous trouverez ci-dessous l'exemple de code qui sera utilisé pour démontrer l'efficacité d'Epsilon GC. :

public class EpsilonDemo {

    public static String formatSize(long v) {
        if (v 



Attente: 

Le code alloue 80 Mo d'objets de type octet. Nous devrions pouvoir observer la même chose avec les instructions print lorsque nous exécutons le code.

Maintenant, pour exécuter la version compilée avec/sans EpsilonGC :

Fonctionnement avec G1GC :

java -Xms100m -Xmx100m -XX: UseG1GC  EpsilonDemo
Starting allocations...
*** Free MEM = 102.2 MB
Completed successfully
*** Free MEM = 74.2 MB




Donc, avec G1GC, nous voyons une image d'allocation incorrecte de l'utilisation de 28 Mo

Fonctionner avec EpsilonGC :

java -Xms100m -Xmx100m -XX: UnlockExperimentalVMOptions -XX: UseEpsilonGC EpsilonDemo
[0.004s][warning][gc,init] Consider enabling -XX: AlwaysPreTouch to avoid memory commit hiccups
Starting allocations...
*** Free MEM = 99.4 MB
Completed successfully
*** Free MEM = 18.7 MB 




Ici, vous pouvez voir clairement l'utilisation de 80,7 Mo

 J'espère que cela vous aidera à voir comment EpsilonGC peut être très pratique pour repérer les modèles d'utilisation de la mémoire dans votre code. Acclamations! ?