Le cache est vraiment chaud à partir de 3 itérations du même code (cela se voit si on trace une courbe de temps vs numéro d'itération), un cache froid est obtenu en manipulant une grande quantité de donné qui n'a rien à voir avec le 1er code (il faudrait aussi tenir compte d'une grande quantité de code pour les miss du cache instructions).
C'est vrai et ça dépend aussi de la politique de « Garbage Collection » et de l'architecture matérielle, mais globalement il me semble que le « G1 » introduit avec le jdk 7 fait l'unanimité. J'ai entendu un dev java, qui fait le backend d'un site Web à gros trafic, parler de 2/3 heures de transition pour le « chauffage » des caches Java. J'étais un peu surpris, mais apparemment sans ce « pré-chauffage » les machines tombent tout simplement sous la charge en production, alors qu'elles tiennent cette charge avec un cache « chaud ». Aussi je pense qu'on est à plus que 3 itérations dans ce cas précis qui, je pense, fait intervenir plusieurs niveaux de gros caches. Ce qui conforte ton point de vue :)
[^] # Re: attention au microbenchmark
Posté par vlamy . En réponse au journal OpenJDK 8, JEP 142 & False Sharing. Évalué à 3.
C'est vrai et ça dépend aussi de la politique de « Garbage Collection » et de l'architecture matérielle, mais globalement il me semble que le « G1 » introduit avec le jdk 7 fait l'unanimité. J'ai entendu un dev java, qui fait le backend d'un site Web à gros trafic, parler de 2/3 heures de transition pour le « chauffage » des caches Java. J'étais un peu surpris, mais apparemment sans ce « pré-chauffage » les machines tombent tout simplement sous la charge en production, alors qu'elles tiennent cette charge avec un cache « chaud ». Aussi je pense qu'on est à plus que 3 itérations dans ce cas précis qui, je pense, fait intervenir plusieurs niveaux de gros caches. Ce qui conforte ton point de vue :)