2012-03-14 2 views
9

Je suis confus au sujet de deux paramètres qui peuvent contrôler lorsque les coups de pied de collection CMS dans:Garbage collector CMS - quand fonctionne-t-il?

MaxHeapFreeRatio (70% par défaut)

CMSInitiatingOccupancyFraction (plus de 90% par défaut)

Qu'est-ce que chacun de ces paramètres signifient, exactement? Quand le collecteur commence-t-il (la phase de marquage), et recueille-t-il (la phase de balayage)?

Répondre

11

CMSInitiatingOccupancyFraction détermine quand le CMS intervient (pour que cette option soit effective, vous devez également définir XX: + UseCMSInitiatingOccupancyOnly). MaxHeapFreeRatio est une option pour dimensionner les espaces générationnels.

Voir par exemple ...

http://java.sun.com/docs/hotspot/gc1.4.2/faq.html

La collection concurrente ne peut généralement pas être accéléré, mais il peut être démarré plus tôt. Une collection simultanée commence à s'exécuter lorsque le pourcentage d'espace alloué dans l'ancienne génération franchit un seuil. Ce seuil est calculé en fonction de l'expérience générale avec le collecteur concurrent. Si des collectes complètes se produisent, les collections simultanées peuvent devoir être démarrées plus tôt. L'indicateur de ligne de commande CMSInitiatingOccupancyFraction peut être utilisé pour définir le niveau auquel la collecte est démarrée. Sa valeur par défaut est d'environ 68%. La ligne de commande pour ajuster la valeur est -XX: CMSInitiatingOccupancyFraction =

http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html

Par défaut, la machine virtuelle grossit ou diminue le tas à chaque collection pour essayer de garder la proportion d'espace libre pour vivre des objets à chaque collection dans une gamme spécifique. Cette plage cible est définie en pourcentage par les paramètres -XX: MinHeapFreeRatio = et -XX: MaxHeapFreeRatio =, et la taille totale est limitée ci-dessous par -Xms et au-dessus par -Xmx. Les paramètres par défaut du sont indiqués dans ce tableau du système d'exploitation Solaris 32 bits (SPARC Platform Edition):

.. ou ..

http://www.petefreitag.com/articles/gctuning/

-XX: MaxHeapFreeRatio - lorsque le pourcentage de libre l'espace dans une génération a dépassé cette valeur, la génération va diminuer pour atteindre cette valeur. La valeur par défaut est 70

EDIT: J'ai exécuté quelques simulations avec un programme de test qui crée aléatoirement des cartes de tableaux d'octets et les copie. J'ai remarqué que a) la valeur de la fraction n'a pas été respectée - en particulier avec une valeur conservatrice (disons 50) l'étape initiale de la marque CMS a dépassé de 50% l'occupation, généralement autour de 70-80% et b) stade initial se produire plus tôt (programme utilisé -Xmx1536m -Xmx1536m -XX: NewSize = 512m -XX: + UseConcMarkSweepGC + exploitation forestière gc et les deux paramètres de test)

J'ai aussi trouvé un vieux rapport de bogue à ce sujet: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6486089

+3

'CMSInitiatingOccupancyFraction' est utilisé uniquement pour la 1ère collection sauf si' -XX: + UseCMSInitiatingOccupancyOnly' est activé. Si vous ne définissez pas ce dernier commutateur, après le premier, les heuristiques habituelles (basées sur les statistiques d'allocation collectées pendant l'exécution) sont utilisées pour déterminer quand le CMS démarre. – Matt

+0

Merci Matt, j'ai ajouté ça. – moodywoody

+0

D'après certaines observations, il semble qu'après quelques heures de faible utilisation, il ne soit pas entré en jeu avant d'atteindre plus de 90% (CMSInitiatingOccupancy), mais pendant la journée, il ne semble pas attendre plus longtemps. Cela semble correspondre à ce que dit @Matt, mais dans ce cas je voudrais savoir quelles sont les "heuristiques habituelles" et combien de temps un temps de paix le rend dormant et attend le seuil de> 90% –