J'ai vu des gens commenter sur la mémoire de tas de Java étant contiguë et les gens disent le contraire. Est-ce que quelqu'un peut me donner une réponse finale et expliquer cette question? En outre, existe-t-il une sorte de structure de données dans le tas Java car il y a dans la pile Java?
3 Réponses :
La vraie réponse est, vous ne savez pas et ne vous en souciez pas. Il y a différents JVMS, et personne ne fait de la promesse sur rien que des spécifications.
Il est important de savoir; Cependant, vous devriez supposer que ce n'est pas contigu et planifie en conséquence. Cela signifie moins de petits objets et des objets / classes compacts plus importants pour réduire les erreurs de cache et les recherches de mémoire étendues. Les petits objets sont le fléau de la performance de la mémoire et des misses de cache.
citant depuis le Spec JVM : la mémoire du tas n'a pas besoin d'être contiguës. Votre code ne devrait donc pas faire des hypothèses sur la continuité du tas.
La mémoire du tas n'a pas besoin d'être contiguë? Qu'est-ce que ça veut dire ? Cela signifie que pour remplir la spécification, vous n'avez pas besoin d'avoir un tas contigu. Cela ne dit pas que le tas ne devrait pas être contigu. Heapot Heap (Sun / Oracle JVM) est contigu, j'ai effectué des tests qui l'ont confirmé. BTW, cette phrase est là pour d'autres fournisseurs, tels que IBM, qui ont divisé le tas en parties, la plupart sont non contiguës, certains sont.
Si votre intention est d'écrire un code Java qui fonctionnera sur n'importe quel JVM, pas seulement le Sun / Oracle JVM, vous ne devriez pas faire des hypothèses sur la continuité du tas. En outre, vos tests ne démontrent que le soleil / oracle JVM actuellement a un tas contigu. Les futures versions pourraient adopter l'approche IBM et rompre n'importe quel code qui suppose un tas contigu.
En effet, dès que je passe au G1 GC, il n'est plus contigu. Je dis simplement, par défaut, il utilise un tas contigu, probablement pour la compatibilité arriérée. Voir Javabook.compuware.com/content/memory/the-three-jvms .aspx et Javarevisited.blogspot .fr / 2013/01 / ...
Cela dépend de la JVM mais n'est définitivement pas garanti d'être contiguës. Hotspot utilise un tas de génération que IBM JDK et JRockit ne le font pas. Je crois que les processus de collecte des ordures IBM et JROCKIT utilisent un algorithme de balayage / compresse qui, en pratique, devrait entraîner un tas contigu.
> Je pense que les processus de collecte des ordures IBM et JROCKIT utilisent un algorithme de balayage / compresse qui, en pratique, devrait entraîner un tas contigu. Il est légèrement plus complexe que cela. Voir Publib.Boulder.ibm.com/infocenter/realTime/v2r0/... Il y a un doc sur Oracle à propos de JRockit et du tas non continu, je ne peux pas trouver maintenant, ne pas avoir le temps.