Commentaires sur : GC générationnels traditionnels (jdk6) VS GC Garbage First (jdk7) http://blog.xebia.fr/2008/03/12/gc-generationnels-traditionnels-jdk6-vs-gc-garbage-first-jdk7/ J2EE, Agilité et SOA Fri, 10 Feb 2012 09:50:25 +0000 hourly 1 http://wordpress.org/?v= Par : pierrehttp://blog.xebia.fr/2008/03/12/gc-generationnels-traditionnels-jdk6-vs-gc-garbage-first-jdk7/#comment-102855 pierre Tue, 13 Dec 2011 13:17:20 +0000 http://blog.xebia.fr/2008/03/12/gc-generationnels-traditionnels-jdk6-vs-gc-garbage-first-jdk7/#comment-102855 Une très bonne intro aux GC (en anglais): http://www.infoq.com/presentations/Understanding-Java-Garbage-Collection Une très bonne intro aux GC (en anglais): http://www.infoq.com/presentations/Understanding-Java-Garbage-Collection

]]> Par : Hassanhttp://blog.xebia.fr/2008/03/12/gc-generationnels-traditionnels-jdk6-vs-gc-garbage-first-jdk7/#comment-65526 Hassan Tue, 19 Jul 2011 14:51:29 +0000 http://blog.xebia.fr/2008/03/12/gc-generationnels-traditionnels-jdk6-vs-gc-garbage-first-jdk7/#comment-65526 Bonjour, Merci pour cet article. J'ai quelques petites remarques que j'aimerais partager avec vous sur les GC générationnels : - "On peut fixer deux catégories d’objectifs lorsque l’on optimise le GC : réduire les pauses ou augmenter le débit" >> Il n'y a pas que ça, voici les métriques qu'il faut prendre en compte pour le tuning de la jvm : le temps de pause, le throughput, le GC overhead, la fréquence des collections, le footprint - "De la même manière, cette zone n’étant jamais nettoyée" (En parlant de la perm) >> Attention, la perm gen est nettoyé aussi. Rien n'échappe au full GC. - "« tenured » (3). Il s’agit d’un emplacement permettant de stocker les objets les plus anciens" >> Les plus gros aussi, car il y a des objets qui seront placés directement dans la old génération sans faire le passage eden-> survivor - "(Taille Heap Min (-Xms) > Pour info, ce paramétrage fortement déconseillée Xms doit être égale à Xmx. - "Plusieurs algo disponibles : Mark&Sweep, Concurrent Mark&Sweep, Incremental/train" >> Il n'est plus disponible depuis la 1.4.2 >> Voici en résumé les algorithme de la young generation : - copying collector (Par défaut) - parallel copying collector (-XX:+UseParNewGC) - parallel scavenge collector (-XX:UseParallelGC) Et ceux de la old generation : - mark-sweep collector (Par défaut) - concurrent collector ou CMS (-XX:+UseConcMarkSweepGC) - incremental collector (-Xincgc) (Il n'est plus disponible depuis la 1.4.2) Et voici un lien pour lire sur le Garbage First Collector : http://download.java.net/jdk7/docs/technotes/guides/vm/G1.html Bonjour,
Merci pour cet article.
J’ai quelques petites remarques que j’aimerais partager avec vous sur les GC générationnels :

- « On peut fixer deux catégories d’objectifs lorsque l’on optimise le GC : réduire les pauses ou augmenter le débit »
>> Il n’y a pas que ça, voici les métriques qu’il faut prendre en compte pour le tuning de la jvm : le temps de pause, le throughput, le GC overhead, la fréquence des collections, le footprint

- « De la même manière, cette zone n’étant jamais nettoyée » (En parlant de la perm)
>> Attention, la perm gen est nettoyé aussi. Rien n’échappe au full GC.

- « « tenured » (3). Il s’agit d’un emplacement permettant de stocker les objets les plus anciens »
>> Les plus gros aussi, car il y a des objets qui seront placés directement dans la old génération sans faire le passage eden-> survivor

- « (Taille Heap Min (-Xms) > Pour info, ce paramétrage fortement déconseillée Xms doit être égale à Xmx.

- « Plusieurs algo disponibles : Mark&Sweep, Concurrent Mark&Sweep, Incremental/train »
>> Il n’est plus disponible depuis la 1.4.2

>> Voici en résumé les algorithme de la young generation :
- copying collector (Par défaut)
- parallel copying collector (-XX:+UseParNewGC)
- parallel scavenge collector (-XX:UseParallelGC)

Et ceux de la old generation :
- mark-sweep collector (Par défaut)
- concurrent collector ou CMS (-XX:+UseConcMarkSweepGC)
- incremental collector (-Xincgc) (Il n’est plus disponible depuis la 1.4.2)

Et voici un lien pour lire sur le Garbage First Collector :
http://download.java.net/jdk7/docs/technotes/guides/vm/G1.html

]]> Par : Jeanhttp://blog.xebia.fr/2008/03/12/gc-generationnels-traditionnels-jdk6-vs-gc-garbage-first-jdk7/#comment-28071 Jean Tue, 06 Jul 2010 09:15:20 +0000 http://blog.xebia.fr/2008/03/12/gc-generationnels-traditionnels-jdk6-vs-gc-garbage-first-jdk7/#comment-28071 Bonjour, J'ai une application qui tourne sur tomcat( sur eclipse) J'obtiens le message d'erreur suivant à chaque rechargement du server. Pouvez vous m'aider à corriger cet erreur. Merci d'avance [CODE] 10:19:57,980 INFO SessionFactoryImpl:379 - Checking 0 named queries Exception in thread "Timer-0" java.lang.NullPointerException at com.mchange.v2.log.log4j.Log4jMLog$Log4jMLogger.isLoggable(Log4jMLog.java:257) at com.mchange.v2.resourcepool.BasicResourcePool$CullTask.run(BasicResourcePool.java:1934) at java.util.TimerThread.mainLoop(Timer.java:512) at java.util.TimerThread.run(Timer.java:462) [/CODE] Bonjour,

J’ai une application qui tourne sur tomcat( sur eclipse)
J’obtiens le message d’erreur suivant à chaque rechargement du server.
Pouvez vous m’aider à corriger cet erreur.

Merci d’avance

[CODE]
10:19:57,980 INFO SessionFactoryImpl:379 – Checking 0 named queries
Exception in thread « Timer-0″ java.lang.NullPointerException
at com.mchange.v2.log.log4j.Log4jMLog$Log4jMLogger.isLoggable(Log4jMLog.java:257)
at com.mchange.v2.resourcepool.BasicResourcePool$CullTask.run(BasicResourcePool.java:1934)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
[/CODE]

]]> Par : Cedric Lucashttp://blog.xebia.fr/2008/03/12/gc-generationnels-traditionnels-jdk6-vs-gc-garbage-first-jdk7/#comment-13434 Cedric Lucas Thu, 25 Jun 2009 09:02:50 +0000 http://blog.xebia.fr/2008/03/12/gc-generationnels-traditionnels-jdk6-vs-gc-garbage-first-jdk7/#comment-13434 Merci pour cet article!! Par contre, je ne comprends pas comment le GC utilise "les spécificités des environnements multiprocesseurs". Ca voudrait dire que le GC tourne en parallèle de l'application? Pourquoi lui spécifier une fraction de temps maximale dans ce cas? Merci pour cet article!!
Par contre, je ne comprends pas comment le GC utilise « les spécificités des environnements multiprocesseurs ». Ca voudrait dire que le GC tourne en parallèle de l’application? Pourquoi lui spécifier une fraction de temps maximale dans ce cas?

]]> Par : Cédric Vidalhttp://blog.xebia.fr/2008/03/12/gc-generationnels-traditionnels-jdk6-vs-gc-garbage-first-jdk7/#comment-13113 Cédric Vidal Wed, 03 Jun 2009 20:47:07 +0000 http://blog.xebia.fr/2008/03/12/gc-generationnels-traditionnels-jdk6-vs-gc-garbage-first-jdk7/#comment-13113 Bonjour Erwan, Félicitations pour cet article, il est vraiment très clair ! Cédric Bonjour Erwan,

Félicitations pour cet article, il est vraiment très clair !

Cédric

]]> Par : Julien Wajsberghttp://blog.xebia.fr/2008/03/12/gc-generationnels-traditionnels-jdk6-vs-gc-garbage-first-jdk7/#comment-10009 Julien Wajsberg Fri, 16 Jan 2009 09:20:59 +0000 http://blog.xebia.fr/2008/03/12/gc-generationnels-traditionnels-jdk6-vs-gc-garbage-first-jdk7/#comment-10009 Pour répondre à : > Mais comment se fait le partage entre la Young Tenured et Perm pour un Xmx=Xms=2G ? En fait, c'est simple: la taille de la Perm n'est pas comprise dans les zones définies par Xmx et Xms. C'est une zone "en plus", et elle est définie par un "-XX:MaxPermSize=256m". Pour répondre à :
> Mais comment se fait le partage entre la Young Tenured et Perm pour un Xmx=Xms=2G ?

En fait, c’est simple: la taille de la Perm n’est pas comprise dans les zones définies par Xmx et Xms. C’est une zone « en plus », et elle est définie par un « -XX:MaxPermSize=256m ».

]]> Par : Blog Xebia France - Revue de Presse Xebiahttp://blog.xebia.fr/2008/03/12/gc-generationnels-traditionnels-jdk6-vs-gc-garbage-first-jdk7/#comment-8847 Blog Xebia France - Revue de Presse Xebia Mon, 17 Nov 2008 18:04:54 +0000 http://blog.xebia.fr/2008/03/12/gc-generationnels-traditionnels-jdk6-vs-gc-garbage-first-jdk7/#comment-8847 [...] Danny Coward, dont nous avons déjà parlé à plusieurs reprises, a publié cette semaine sur son blog un billet annonçant la disponibilité du nouvel algorithme pour le ramasse-miettes Java sur le dernier build du JDK 7 (bon courage pour l’installer …). Trois saisons ont passé depuis la publication sur notre blog d’un article présentant le fonctionnement de celui-ci. Son principe n’a pas changé, vous pouvez donc toujours vous y référer si le sujet vous intéresse : GC générationnels traditionnels (JDK 6) VS Garbage First (JDK 7). [...] [...] Danny Coward, dont nous avons déjà parlé à plusieurs reprises, a publié cette semaine sur son blog un billet annonçant la disponibilité du nouvel algorithme pour le ramasse-miettes Java sur le dernier build du JDK 7 (bon courage pour l’installer …). Trois saisons ont passé depuis la publication sur notre blog d’un article présentant le fonctionnement de celui-ci. Son principe n’a pas changé, vous pouvez donc toujours vous y référer si le sujet vous intéresse : GC générationnels traditionnels (JDK 6) VS Garbage First (JDK 7). [...]

]]> Par : Blog Xebia France - Revue de Presse Xebiahttp://blog.xebia.fr/2008/03/12/gc-generationnels-traditionnels-jdk6-vs-gc-garbage-first-jdk7/#comment-7268 Blog Xebia France - Revue de Presse Xebia Mon, 22 Sep 2008 16:51:03 +0000 http://blog.xebia.fr/2008/03/12/gc-generationnels-traditionnels-jdk6-vs-gc-garbage-first-jdk7/#comment-7268 [...] la description des différents algorithmes de Garbage Collection se trouve relativement facilement sur le Web, peu décrivent comment ceux-ci gèrent la fragmentation de la heap. Même si la durée de vie des [...] [...] la description des différents algorithmes de Garbage Collection se trouve relativement facilement sur le Web, peu décrivent comment ceux-ci gèrent la fragmentation de la heap. Même si la durée de vie des [...]

]]> Par : HanLeehttp://blog.xebia.fr/2008/03/12/gc-generationnels-traditionnels-jdk6-vs-gc-garbage-first-jdk7/#comment-5881 HanLee Mon, 16 Jun 2008 19:30:12 +0000 http://blog.xebia.fr/2008/03/12/gc-generationnels-traditionnels-jdk6-vs-gc-garbage-first-jdk7/#comment-5881 Salut, Petite remarque sémantique : "Ces objectifs sont en général orthogonaux (la réduction de la durée des pauses se fait au détriment du débit, et vice-versa)" Justement non, s'ils sont orthogonaux, c'est qu'ils sont libres/indépendants l'un par rapport à l'autre, cf l'analogie avec les produits scalaires. Tu devrais plutôt dire "opposé", "antinomiques". A part ça, intéressant. J'aimerais savoir ce qu'il faut face à celui d'OCaml. Salut,

Petite remarque sémantique : « Ces objectifs sont en général orthogonaux (la réduction de la durée des pauses se fait au détriment du débit, et vice-versa) »

Justement non, s’ils sont orthogonaux, c’est qu’ils sont libres/indépendants l’un par rapport à l’autre, cf l’analogie avec les produits scalaires.

Tu devrais plutôt dire « opposé », « antinomiques ».

A part ça, intéressant. J’aimerais savoir ce qu’il faut face à celui d’OCaml.

]]> Par : Thierryhttp://blog.xebia.fr/2008/03/12/gc-generationnels-traditionnels-jdk6-vs-gc-garbage-first-jdk7/#comment-5801 Thierry Sat, 07 Jun 2008 09:14:29 +0000 http://blog.xebia.fr/2008/03/12/gc-generationnels-traditionnels-jdk6-vs-gc-garbage-first-jdk7/#comment-5801 Article très instructif. Ce genre d'article se fait très rare, surtout en français. Bravo et merci ! Article très instructif.
Ce genre d’article se fait très rare, surtout en français.
Bravo et merci !

]]> Par : Christophehttp://blog.xebia.fr/2008/03/12/gc-generationnels-traditionnels-jdk6-vs-gc-garbage-first-jdk7/#comment-5490 Christophe Mon, 05 May 2008 14:50:36 +0000 http://blog.xebia.fr/2008/03/12/gc-generationnels-traditionnels-jdk6-vs-gc-garbage-first-jdk7/#comment-5490 bonjour erwan, J'ai gardé l'option par défaut d'un serveur (soit 2) Je suis donc à 1/3 et 2/3 Mon problème est que la mémoire tenured explose malgré le full GC et que les hrpof généré ne sont pas lisible (trop gros) que faire ?? bonjour erwan,
J’ai gardé l’option par défaut d’un serveur (soit 2)
Je suis donc à 1/3 et 2/3
Mon problème est que la mémoire tenured explose malgré le full GC et que les hrpof généré ne sont pas lisible (trop gros)
que faire ??

]]> Par : Erwan Alliaumehttp://blog.xebia.fr/2008/03/12/gc-generationnels-traditionnels-jdk6-vs-gc-garbage-first-jdk7/#comment-5439 Erwan Alliaume Mon, 28 Apr 2008 21:54:51 +0000 http://blog.xebia.fr/2008/03/12/gc-generationnels-traditionnels-jdk6-vs-gc-garbage-first-jdk7/#comment-5439 Bonjour Christophe, Le sizing des différentes générations peut s'effectuer grâce à des ratios. Ceux-ci sont configurables par l'intermédiaire <a href="http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp" rel="nofollow">d'options spécifiques</a>. Par exemple, l'option -XX:NewRatio=3 permet de définir le ratio entre la jeune et l'ancienne génération de 3 pour 1 : soit pour un tas à 2go, un young à 512mo et une tenured à 1536mo. Dans la plupart des cas, la valeur par défaut pour cette option est "8". De ce fait, les objets sont (trop ?) rapidement promus dans la seconde génération. Sur le même principe, l'option -XX:SurvivorRatio=6 permet de définir le ratio entre l'eden et les survivors. Pour un tas de 2 go, cela nous fait 384mo pour l'eden, et 64mo pour chaque survivor (1/8 de la young génération). En espérant avoir été clair. Erwan Bonjour Christophe,

Le sizing des différentes générations peut s’effectuer grâce à des ratios. Ceux-ci sont configurables par l’intermédiaire d’options spécifiques.

Par exemple, l’option -XX:NewRatio=3 permet de définir le ratio entre la jeune et l’ancienne génération de 3 pour 1 : soit pour un tas à 2go, un young à 512mo et une tenured à 1536mo. Dans la plupart des cas, la valeur par défaut pour cette option est « 8″. De ce fait, les objets sont (trop ?) rapidement promus dans la seconde génération.

Sur le même principe, l’option -XX:SurvivorRatio=6 permet de définir le ratio entre l’eden et les survivors. Pour un tas de 2 go, cela nous fait 384mo pour l’eden, et 64mo pour chaque survivor (1/8 de la young génération).

En espérant avoir été clair.

Erwan

]]> Par : Christophehttp://blog.xebia.fr/2008/03/12/gc-generationnels-traditionnels-jdk6-vs-gc-garbage-first-jdk7/#comment-5438 Christophe Mon, 28 Apr 2008 18:54:55 +0000 http://blog.xebia.fr/2008/03/12/gc-generationnels-traditionnels-jdk6-vs-gc-garbage-first-jdk7/#comment-5438 Merci pour l'article Mais comment se fait le partage entre la Young Tenured et Perm pour un Xmx=Xms=2G ? Merci pour l’article
Mais comment se fait le partage entre la Young Tenured et Perm pour un Xmx=Xms=2G ?

]]> Par : Nicolashttp://blog.xebia.fr/2008/03/12/gc-generationnels-traditionnels-jdk6-vs-gc-garbage-first-jdk7/#comment-4816 Nicolas Fri, 14 Mar 2008 09:02:22 +0000 http://blog.xebia.fr/2008/03/12/gc-generationnels-traditionnels-jdk6-vs-gc-garbage-first-jdk7/#comment-4816 Article très intéressant. Bravo ! Nicolas Article très intéressant. Bravo !
Nicolas

]]> Par : Christianhttp://blog.xebia.fr/2008/03/12/gc-generationnels-traditionnels-jdk6-vs-gc-garbage-first-jdk7/#comment-4795 Christian Wed, 12 Mar 2008 19:33:23 +0000 http://blog.xebia.fr/2008/03/12/gc-generationnels-traditionnels-jdk6-vs-gc-garbage-first-jdk7/#comment-4795 Excellent article, merci ! Excellent article, merci !

]]>