Il y a Plusieurs langues de programmation informatique à l'aide de JVM Bytecode comme, disons, langage cible pour leur interprète / compilateurs. Il me semble que de nombreuses nouvelles langues de programmation (moins de 15 ans) sont exécutées sur JVM et je me demandent si la répartition explicite de la mémoire est interdite pour toutes:
est-il possible d'allouer explicitement-annoncer la mémoire en utilisant en bytecode à travers des instructions? Est, au contraire, le collecteur des ordures toujours réparatifs pour la libération de la mémoire?
3 Réponses :
Le JVM résume toute la gestion de la mémoire. Il n'y a pas de bytecode pour la répartition de la mémoire, tout comme il n'y a pas de bytecode pour une allocation de mémoire ou un accès direct de la mémoire. Si vous voulez faire cela, vous devez utiliser du code natif, directement ou indirectement.
Oui. Vous pouvez le confirmer en regardant l'ensemble complet des instructions bytecode docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html
Il y a quelques instructions comme «nouvelles» ou «Newarray» qui implicitement alloc. Je comprends de vos réponses et des instructions de bytecode Définissez des inscriptions qu'il n'y a pas une chose comme "Del". Est-il possible de mettre en œuvre quelque chose comme des instructions «DEL» dans le code natif, puis appelez-le sous forme de bytecode? De cette façon, vous pouvez compiler une instruction de transaction de mémoire de la mémoire de programmation hypothétique à ByTecode + votre petit code natif.
Pas de manière utile. La mise en œuvre de «nouveaux», etc. est dépendante de la mise en œuvre, de sorte que même si vous pouviez écrire un «del» qui pique dans le tas, il ne serait pas stable ou portable. Il y a des compilateurs de bytecode. Ils simulent Malloc, libre, arithmétique de pointeur, etc. à l'aide de tableaux Java.
@Pablo Le JVM n'est même pas garanti d'allouer de la mémoire pour NOUVEAU ou NewArray, sans parler de créer un objet de tas réel. C'est juste une abstraction.
L'un des principes absolus de la JVM est que les objets sont absolument positivement garantis pour durer au moins aussi longtemps que toutes les références. Si les objets d'un groupe détiennent de fortes références les unes aux autres, mais les seules les références à l'extérieur du groupe sont encapsulées dans les objets faim , puis tous les objets du groupe, et toutes les références à elles, cesseront Pour exister, simultanément (les objets Une conséquence est que la mémoire d'un objet ne peut être réutilisée à moins que ou jusqu'à ce que le JVM puisse être certain qu'aucune référence à celle-ci n'existe. Parce qu'il faudrait juste aussi longtemps pour que aucune référence n'existait à un objet particulier, car il faudrait pour effectuer une collection de déchets sur tous les objets qui étaient à peu près au même âge ou plus récent, il n'y a vraiment aucun avantage à essayer de recycler la mémoire plus tôt . Ceci est particulièrement vrai si on considère que le GC fonctionne lorsque la mémoire est nécessaire. Jusqu'à ce que la mémoire soit nécessaire, il n'y a aucun avantage de le libérer. faim peuvent continuer à exister, mais ils ne tiennent plus des références à rien).
Je reviens à cette question, après deux ans, lorsque je viens de trouver que le Project Tungsten dans Apache Spark utilise une sorte de piratage pour allouer et désaffecter la mémoire dans le tas à l'aide de la JVM.
Ce n'est pas nouveau , donc il était possible de faire. Vous pouvez trouver plus de détails ici D'où j'ai obtenu l'exemple suivant: P>
public DirectIntArray(long size) {
startIndex = unsafe.allocateMemory(size * INT_SIZE_IN_BYTES);
unsafe.setMemory(startIndex, size * INT_SIZE_IN_BYTES, (byte) 0);
}
}
public void setValue(long index, int value) {
unsafe.putInt(index(index), value);
}
public int getValue(long index) {
return unsafe.getInt(index(index));
}
private long index(long offset) {
return startIndex + offset * INT_SIZE_IN_BYTES;
}
public void destroy() {
unsafe.freeMemory(startIndex);
}