Différence allocation Mémoire entre JDK5 et (JD6 et ultérieur)

Bonjour

Auriez-vous une explication sur ce comportement?
Je créé une boucle infini jusqu'à saturation de la mémoire.

Or cette saturation n'arrive pas au même moment selon la version du jdk utilisée...

le code tout simple:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

Map<Integer, int[][]> mapInt = new HashMap<Integer, int[][]>(); int tailleTableauX = 500;   try { for (int i = 0; i < 10000; i++) {   mapInt.put(i,new int[tailleTableauX][1000]); } } catch (OutOfMemoryError e) { System.out.println("Sortie OutOfMemory error Test (Map de tableau de taille " + tailleTableauX + "x1000) à l'index : " + i ); } finally { mapInt = null; }

---

Or si je compile ('javac *.java') et exécute('java -classpath . -Xmx2000m Test') en jdk5 , je sors à un certain index.
Si je compile et exécute en JDK6 ou 7, je sors à un index inférieur. Donc moins d'objets créés.

Il y a une différence d'à peu près 20% du nombre d'objets alloués, quelle que soit la taille du tas (valeurs comprises entre 100m et 2600m)

Avez-vous une explication?

Merci

PS: les versions des jdk sont des versions 32 bits tournant sous linux
jdk-1_5_0_17-linux-i586
jdk-6u45-linux-i586
jdk-7u45-linux-i586

Je ne sais pas mais je propose quelques idées:
- le class loader et autre classes 'system' sont plus grosses,
- la repartition entre les différentes mémoires (permgem, heap...) est différente
- l'implémentation de la classe HashMap a changé

Merci pour tes idées

Effectivement c'etait de bonnes pistes, surtout celle concernant la répartition.
J'ai donc rajouté un paramètre dans le lancement qui est la taille de l'eden

java -classpath . -Xmx100m -XX:MaxNewSize=16m TestSize 10000 500

Malheureusement, j'obtiens le même résultat d'une différence de 20%

Pour les 2 autres=
- les classes : je ne pense pas vu que le % ne varie pas quel que soit la taille du tas.
- la map: non plus vu que j'ai aussi fait le test avec une liste toute bête et que j'ai aussi le même résultat...

Sinon, j'ai posé la question sur un forum Oracle et la réponse est assez surprenante : on s'en fout...
Les vendeurs de VM peuvent changer leur façon de stocker la mémoire d'une version à l'autre sans pour autant le mettre dans les spécifications.

Dans l'absolu, effectivement, on s'en fou, ça ne fais pas partie de la spec.

Mais en pratique, ce n'est pas acceptable d'avoir une nouvelle version de la JVM qui consomme systématiquement 20% de plus. C'est ce qui peut faire basculer un programme de la section "limite" à la section "ne marche plus".

Maintenant, sur le pourquoi, je vois plusieurs paramètres qui entrent en compte

-> Plus fragmentation de mémoire sur le nouveau modèle, qui peut être lié au nouveau modèle GC => On se retrouve plus rapidement sans un espace continu de 500k libre
-> Des structures plus grandes, est-ce que tu utilise un java 32 ou 64?
-> Des changement de stratégies sur le jit
-> Des changements d'algorithmes dans la HashMap.


Maintenant, ce bout de code ne veux rien dire. Je ne vois aucun usage de ton code, ce n'est pas une structure qu'on utilise réellement. Il faut voir comment se comporte ton programme réel et, si il utilise réellement plus de mémoire (20%) de l'ancien. Si oui, je te dirais d'éplucher chaque release note qui sépare ces deux version (ceci inclue toutes les release mineures).

Si tu es sur une java 64, il y a aussi des paramètres comme les compressed object pointers qui peuvent t'aider à réduire ;)

Merci pour cette réponse (et désolé pour le retard)

Et merci de me conforter dans l'idée qu'une tel augmentation sans être signalée est quand même plus qu'étrange. Je me suis d'ailleurs demandé si ce n'était pas moi qui faisait une erreur dans mon expérience ou mon interprétation.
D'ailleurs est ce quelqu'un le reproduit?

Sinon toutes les VM testées étaient des 32 bits. Les machines étaient des 64 bits et les tests ont été fait sur des OS 32 et 64 bits.

Je retiens la piste de la fragmentation de la mémoire. Il faudrait que j'essaie de faire avec des tableaux plus petits et instancier plus d'objets.

Sinon pour la stratégie du JIT, je vois pas en quoi cela joue sur la mémoire. Non pas que je ne crois pas en cette option mais c'est que je n'ai aucune idée de son fonctionnement. Je vais me renseigner.

Merci

Sinon pour l'utilité réelle du code, c'est sûr que cela n'a aucune valeur. C'était juste un test pour essayer de comprendre pourquoi entre le jdk5 et le jdk6, des ralentissements se faisaient plus sentir car le GC passait beaucoup plus souvent

changement de stratégie implique code qui se comporte un peu différement, implique garbage collector qui ne tourne plus exactement de la même manière, implique une disposition mémoire différente, implique ds stratégies d'allocation différentes, implique une fragmentation différente :)

encore une fois, problème de base: tu exige dans ton test de grandes zones continues de presque 10M ;)