Java Object [] et cache strading

Comme nous le savons, lorsque la mémoire est déplacée vers les caches L sur le processeur, elle est déplacée avec des cachelines, donc l'optimisation des performances de l'ensemble du cache...

Eh bien en java lorsque nous définissons un tableau, jmm garantit que la mémoire de chaque élément sera allouée séquentiellement. Cependant, si nous avons un tableau de références, ces références peuvent pointer aléatoirement vers différents endroits de la mémoire.

Ma question est la suivante: java alloue-t-il séquentiellement la mémoire des objets réels? Quelles optimisations avons nous sous le capot pour ça?

Par exemple, si nous déclarons int [], nous sommes convaincus que ceux-ci sont tous séquentiels en mémoire, mais si nous définissons un NewType (comme struct) qui contient deux champs int, et déclarons NewType [] java comprendra-t-il et conservera-t-il la mémoire réelle séquentiellement ou non?

Author: vach, 2015-06-27
Source

2 answers

Ma question est la suivante: java alloue-t-il séquentiellement la mémoire des objets réels?

Ce n'est pas garanti, mais la plupart du temps la JVM OpenJDK/Oracle le fait. De temps en temps il ne sont;

  • lorsque vous allouez un objet de grande taille dans un espace permanent,
  • votre TLAB est plein et vous devez en obtenir un autre.

Cependant, dans le TLAB, il alloue simplement séquentiellement en mémoire.

Declare NewType [] java va-t-il comprendre et garder mémoire réelle séquentiellement ou non?

Java ne comprend rien, ni ne sort de sa façon d'allouer des objets au hasard en mémoire. En général, chaque objet new sera immédiatement après le dernier.

 3
Author: Peter Lawrey, 2015-06-27 15:42:10

Mais si nous définissons un NewType (comme struct) qui a deux champs int, et déclarons NewType[] java comprendra-t-il et conservera-t-il la mémoire réelle séquentiellement ou non?

Dans ce scénario, java n'est pas très convivial pour le cache car, en dehors des types primitifs, les tableaux java ne sont pas des structures de données emballées, ce sont des tableaux de références pointant vers des objets alloués ailleurs dans la mémoire.

C'est-à-dire qu'il y aura au moins un niveau d'indirection du tableau vers l'objet lui-même. Ce problème est souvent appelé "poursuite de pointeur".

C'est-à-dire que la disposition de la mémoire ressemblera généralement à ceci: 

HlRRRRRRRRRRRRRRRRRRRRRRRRR0HR0iii0HR0iii0HR0iii0HR0iii0HR0iii0HR0iii0HR0iii0
         Array             | Obj  | Obj  | Obj  | Obj  | Obj  | Obj  | Obj  |

H = object header
l = array length
R = reference
i = int
0 = various types of padding

Vous pouvez utiliser jol inspecter la mémoire présentation des objets.

Les développeurs JDK travaillent sur Types de valeurdans le cadre du projet valhallaqui permettra éventuellement l'existence de tableaux emballés, ce qui peut être nécessaire dans le cadre du projet panama, mais cela est encore loin dans le futur.

En attendant il existe des projets tiers visant à fournir des fonctionnalités similaires:

D'autres projets utilisent un stockage hors tas (par exemple via sun.misc.Unsafe) ou des vues sur des tableaux ByteBuffer / byte[] pour créer des structures de données compactées et compatibles avec le cache au détriment d'API plus compliquées.

 1
Author: the8472, 2015-06-27 18:42:23