Tas divisé (Windows uniquement, obsolète)

De nombreuses charges de travail d'application Java™ dépendent de la taille de segment de mémoire Java. Le SDK peut utiliser un segment de mémoire partagé pour contourner les restrictions dans l'espace mémoire Windows 32 bits et fournir une taille de segment de mémoire maximale supérieure. Cette fonction peut être utile pour les applications qui doivent s'exécuter sur la machine virtuelle Java 32 bits (par exemple, en raison de bibliothèques JNI 32 bits, d'un système d'exploitation 32 bits ou d'un matériel 32 bits) mais qui ont besoin de grands segments de mémoire Java.

Remarque: L'option de ligne de commande -Xgc:splitheap est devenue obsolète dans la version 8 et sera supprimée des versions futures du SDK IBM .

Une rupture dans l'espace adresse Windows limite le segment de mémoire Java à moins de 2 Go. Utilisez un segment de mémoire partagé pour permettre au segment de mémoire Java d'exister de part et d'autre de la rupture dans l'espace adresse. Il est alors possible d'allouer un tas plus grand que ne le permettrait l'utilisation d'une zone de mémoire contiguë. Avec un tas plus grand, vous pouvez allouer plus d'objets avant le déclenchement d'une récupération de place. Vous augmentez aussi le nombre d'objets actifs qui peuvent être utilisés avant qu'une exception OutOfMemoryError ne se produise.

Utilisez l'option de ligne de commande -Xgc:splitheap (disponible uniquement sur la machine virtuelle Java Windows 32 bits) pour activer le segment de mémoire partagé. Lorsque vous utilisez cette option, le comportement suivant est également activé :
  • Le récupérateur de place est forcé d'utiliser la politique de récupération de place gencon (generational concurrent, générationnelle simultanée).
  • Les zones nouvelles et anciennes du segment de mémoire Java générationnel sont allouées dans des zones de mémoire distinctes.
  • Le redimensionnement des zones de mémoire nouvelle et ancienne est désactivé.
Il n'est pas recommandé d'utiliser un tas divisé si l'application :
  • fonctionne mal (mauvaises performances) avec la politique de récupération de place gencon ;
  • charge un très grand nombre de classes ;
  • Utilise de grandes quantités de mémoire système native dans les bibliothèques JNI ; la taille accrue du segment de mémoire Java peut réserver une trop grande partie de l'espace adresse de l'application.
Restriction: Un processus Windows 32 bits est limité à un espace adresse de 2 Go sauf si l'option /3GB est spécifiée dans le fichier boot.ini . Pour plus d'informations, voir Windows 32-bit large address aware support dans le guide d'utilisation du SDK .

Avec un segment de mémoire partagé, l'ancienne zone est validée à sa taille maximale (définie avec -Xmox) dans une région inférieure de mémoire et la nouvelle zone est validée à sa taille maximale (définie avec -Xmnx) dans une région de mémoire supérieure.

Echecs d'allocation

Avec un tas divisé, il est possible que la JVM ne démarre pas pour plusieurs raisons. Les messages suivants sont générés à la suite d'un échec d'allocation d'un tas divisé :
JVMJ9GC064 Failed to allocate old space
Il n'y a pas suffisamment d'espace libre dans la région de mémoire inférieure pour allouer la zone des anciens objets. Pour résoudre le problème, réduisez -Xmox.
JVMJ9GC065 Failed to allocate new space
Il n'y a pas suffisamment d'espace libre dans la région de mémoire supérieure pour allouer la zone des nouveaux objets. Pour résoudre le problème, réduisez -Xmnx.
JVMJ9GC066 Required split heap memory geometry could not be allocated
La zone des nouveaux objets a été allouée plus bas que la zone des anciens objets. Pour résoudre le problème, réduisez -Xmx.

Tailles maximales de tas

Les tailles maximales de tas sont les suivantes :

Windows 7 32 bits sur du matériel 32 bits utilisant la machine virtuelle Java 32–bit
Zone des anciens objets de 1800 Mio et zone des nouveaux objets de 1000 Mio.
-Xgc:splitheap -Xmx2800m -Xmox1800m
Windows 7 64 bits sur matériel 64 bits à l'aide de la machine virtuelle Java 32–bit
Zone des anciens objets de 1700 Mio et zone des nouveaux objets de 2000 Mio.
-Xgc:splitheap -Xmx3700m -Xmox1700m

Les applications ont des limites plus basses si elles chargent un grand nombre de classes ou un grand nombre de bibliothèques natives ou si elles démarrent plusieurs unités d'exécution.