GC et heap space monitoring

Bonjour,

Je suis en train de modifier un code pour réduire sa consommation mémoire. J'utilise JVM Monitor sous Eclipse pour surveiller la heap space et la mémoire utilisée par classe d'objet. En l'occurence, la classe double[] est celle qui prend de loin le plus de place.

En regardant l'espace pris par les double[], mon patch a l'air efficace (réduction de moitié). Par contre lorsque je regarde la heap space, je ne vois qu'un gain infime.

Du coup, je me demande comment expliquer cette écart:
* Les autres classes (autres que double[]) ne sont pas négligeables, mais je ne vois vraiment pas comment elles pourraient compenser le gain que je fais sur les double[].
* Est ce que le GC a tendance à tourner moins souvent lorsque l'occupation mémoire est faible ?
* Est-ce que la mémoire occupée par classe que JVM Monitor me donne inclus la partie stack ?

Merci d'avance pour vos réactions.

Lorsque je demande à JVMM de run le GC, je vois la memory space chuter d'un coup ! Je favorise donc la 2e explication pour l'instant.

Le GC est automatiquement appelé lorsque la mémoire est saturée et qu'un appel à new est fait. Donc oui, lorsque la mémoire est très utilisée, le GC tourne plus souvent. C'est d'ailleurs pourquoi il faut toujours prévoir plus de mémoire que necessaire. Dans des applis à forte consommation mémoire, le temps d'execution du GC peut devenir non négligeable et visible pour l'utilisateur.

Merci Hwoarang !

Ok lorsque la mémoire est saturée, mais est-ce aussi le cas dans la zone de non-saturation ?
Y'a-t'il par exemple une vraie différence dans la fréquence du GC lorsque la saturation passe de 20% à 50% ?

tu as plusieurs process pour les nettoyage de la mémoire.

un process de nettoyage de ce qui n'a pas pu fuir de ton appel de méthode. Normalement la jvm se débrouille pour allouer ce qui ne fuis pas sur la stack
un process de nettoyage en background, tu le vois en regardant ta heap space, normalement elle monte et descend régulièrement
un process de nettoyage au besoin qui se déclenche lorsque tu arrive à court de mémoire, parce que le new ne peux pas réussir ne l'état, mais avant de lancer un outofmemory, il faut s'assurer qu'on ne peux vraiment rien récupérer.

Chaque algo cherche différement.

Pour résumer, il est normal que ta mémoire garde des objets inusité pendant une longue période