JVM avec pas de collecte des ordures
J'ai lu dans de nombreux threads qu'il est impossible de désactiver la collecte des ordures sur Sun JVM. Toutefois, pour les besoins de notre projet de recherche nous avons besoin de cette fonctionnalité. Quelqu'un peut-il recommander une JVM qui n'a pas de collecte des ordures ou de qui permet de l'éteindre? Merci.
- Java sans la collecte des ordures, c'est comme, bien C/C++ !!!
- Selon forums.java.net/jive/thread.jspa?messageID=208939&tstart=0 le gc peut être désactivé dans les versions antérieures de Java, mais il n'est plus possible.
- De blé, pas de. c'est loin en C++, il n'y a pas de dépassements de tampon, et peu ou pas de comportement indéfini.
- sur
- Il n'y a également aucun souvenir de remise en état sans GC, donc, si vous voulez fuite comme un fou.
- Je ne peux pas trouver quelque chose où j'en aurais besoin pour désactiver la cg. Pour quoi avez-vous besoin?
- eh bien, il sonne comme il veut juste tester les performances sans GC généraux, il serait probablement faire beaucoup plus de sens de faire cela avec l'ajout explicite supprime de la langue et des tests de code de la modification de la langue... :/
- Comme je l'ai dit ci-dessous, je commence un projet de recherche et je vais essayer de trouver un simple moyen rapide pour une première preuve de concept pour garder tous les objets en mémoire
- Garder tous les objets en mémoire est une autre question que celle de la désactivation de la GC. Vous pouvez garder tous les objets en mémoire, en conservant les références. Si vous avez besoin de le faire avec chaque objet, vous pourriez être en mesure de mettre en œuvre certaines instrumentation de ressusciter les objets dans leur outil de finalisation par la création d'une nouvelle, accessible, une forte référence à
this
ou peut-être tout simplement interdire le finaliseur à jamais complète en appelantThread.yield()
. - Java sans gc est à peu près impossible. Chaque petite fonction en Java alloue quelque chose, que ce soit le tableau de la
main
méthode ou de Chaînes de caractères. À ce point, pourquoi ne pas choisir un plus approprié de la langue?
Vous devez vous connecter pour publier un commentaire.
Le moyen simple de faire cela est de lancer la JVM avec un tas qui est si grand que le GC n'a jamais besoin de courir. Définir la
-Xmx
et-Xms
options pour une grande valeur, et tourner sur GC journalisation pour confirmer que le GC ne fonctionne pas pour la durée de votre test.Ce sera plus rapide et plus simple que la modification de la JVM.
(avec le recul, cela peut ne pas fonctionner. J'ai vaguement souvenir avoir vu des éléments de preuve qui implique que la JVM ne pas toujours respecter les
-Xms
paramètre, surtout si elle était vraiment grand. Toutefois, cette approche est la peine d'essayer avant d'essayer certains beaucoup plus difficile d'approche ... comme la modification de la JVM.)Aussi, tout cela me semble inutile (voire contre-productif) pour ce que vous êtes en train d'essayer de réaliser. Le GC ne vais pas jeter des objets à moins qu'ils sont des ordures. Et si ils sont des ordures, vous ne serez pas en mesure de les utiliser. Et les performances d'un système avec GC désactivé /niée ne va pas révélateur de la façon dont un réel application fonctionnera.
En fonction de vos besoins, cela pourrait peut-être travailler:
À l'aide de l'-Xbootclasspath option, vous pouvez spécifier votre propre mise en œuvre des classes de l'API. Vous pouvez par exemple remplacer la mise en œuvre de l'Objet, et ajoutez-y le constructeur, un
globalList.add(this)
pour empêcher les objets de ces ordures. C'est un hack pour vous, mais pour la simple étude de cas, c'est peut-être suffisant.Une autre option est de prendre une source ouverte jvm et commentez les pièces de lancer la collecte des ordures. Je suppose qu'il n'est pas si compliqué que ça.
De Sun JVM a pas une telle option. Autant que je sache, aucun autre JVM a cette option soit.
Vous n'avez pas ce que c'est que vous êtes exactement essaie de l'atteindre, mais vous avez l'une des deux options: soit utiliser un générateur de profils et de voir exactement ce que le GC est en train de faire, de cette façon, vous pouvez prendre de ses effets en considération. L'autre est de compiler une des machines virtuelles à partir de la source, et de désactiver GC à partir de là.
Peut-être que vous pourriez essayer de faire de votre VM est disponible de la mémoire suffisante pour la GC ne jamais être exécuté.
Mon (allbeit limitée) expérience m'amène à suggérer que la VM est, par défaut, très paresseux et très réticents à exécuter GC.
donnant -Xmx 16384M (ou d'autres) et de faire en sorte que votre sujet de recherche reste bien en-dessous de cette limite, il pourrait vous donner de l'environnement que vous souhaitez obtenir, cependant, même alors, il sera bien évidemment pas être garanti.
Vous pouvez désactiver uniquement la GC si elle n'est pas réellement nécessaire (sinon, votre demande de manquer de mémoire) et si vous n'avez pas besoin de GC, il ne faut pas courir de toute façon.
L'option la plus simple serait de ne pas jeter des objets, cela permettra d'éviter la GC en cours (Et de définir le max de mémoire très haut afin de ne pas en manquer).
Vous pouvez trouver que vous obtenez GCs au démarrage et vous pouvez envisager un no-GC lors de l'exécution acceptable.
Il existe réellement un sale hack pour interrompre temporairement la lecture de GC. D'abord créer un mannequin tableau en Java. Puis, dans JNI, utilisez GetPrimitiveArrayCritical fonction pour obtenir le pointeur vers le tableau. La JVM de Sun va désactiver GC pour s'assurer que le tableau n'est jamais déplacé et que le pointeur reste valide. Pour réactiver la GC, vous pouvez appeler la ReleasePrimitiveArrayCritical fonction sur le pointeur. Mais c'est très mise en œuvre spécifique, puisque les autres VM impl peut épingler l'objet au lieu de désactiver GC entièrement. (Testé à travailler sur Oracle Jdk 7 & 8)
Prendre un coup d'oeil à Oracle JRockit JVM. J'ai vu de très bons quasi-déterministe de la performance sur plate-forme Intel avec cette JVM et vous pouvez prod et pousser le moteur d'exécution à l'aide de la Mission De Contrôle utilitaire pour voir comment c'est la scène.
Si vous ne pouvez pas tourner GC complètement, je crois que vous pouvez utiliser le -Xnoclassgc option pour désactiver la collecte de classes. Le GC peut être réglé pour réduire le temps de latence au détriment de laisser la mémoire de la consommation de croître. Vous pouvez avoir besoin d'une licence pour drop les temps de latence aussi faible que vous avez besoin si vous allez dans cette voie.
Il est également en temps réel version de la JRockit JVM disponible mais je ne pense pas qu'il y est un free-to-développeurs de la version de cette disposition.
Pouvez-vous obtenir de l'open source de la JVM et de désactiver ses GC, par exemple Du soleil Hotspot?
Si il n'y avait pas de Collecte des Ordures qu'attendez-vous pour être la sémantique de ce type de code?
En l'absence de GC n'importe quel élément newed et avec une pile étendue de référence ne pourrait jamais être récupérée. Même si vos propres classes pourraient décider de ne pas utiliser des variables locales comme ceci, ou de n'utiliser que les types primitifs je ne vois pas comment vous pouvez l'utiliser en toute sécurité de n'importe quel standard de Java bibliothèque.
Je serais intéressé d'entendre plus au sujet de votre scénario d'utilisation.
la question est vieux, mais pour ceux qui pourraient être intéressés, il y a une proposition de
JEP projet: Epsilon GC: La Arbitrairement Faible charge Poubelle (Non-)Collecteur
Si j'ai eu ce problème, je voudrais obtenir IBM Jikes La Recherche De La Machine Virtuelle parce que:
Vous ne pouvez pas désactiver la GC pour toujours, parce que les programmes Java ne allouer et à la fin vous serez à court de mémoire, mais c'est tout à fait possible que vous pouvez différer le GC pour la durée de votre expérience, en disant à la JVM de ne pas commencer à collecter jusqu'à ce que le tas devient vraiment grand. (Cette astuce peut travailler sur d'autres machines virtuelles ainsi, mais je ne sais pas où trouver les boutons pour démarrer virevoltant.)