2016-06-17 1 views
1

J'ai un programme de pipeline multithread qui comporte un seul élément du pipeline qui prend plusieurs heures à calculer pour les données longues.Le programme Java est tombé en panne pendant 6 heures, erreur de vidage mémoire

Cela fonctionne correctement pour des quantités relativement faibles de données, mais pour les données volumineuses, il s'est bloqué après 6 heures. J'ai cette erreur:

# A fatal error has been detected by the Java Runtime Environment: 
# 
# Internal Error (safepoint.cpp:310), pid=47713, tid=11267 
# guarantee(PageArmed == 0) failed: invariant 
# 
# JRE version: Java(TM) SE Runtime Environment (8.0_65-b17) (build 1.8.0_65-b17) 
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.65-b01 mixed mode bsd-amd64 compressed oops) 
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again 
# 
# An error report file with more information is saved as: 
# DIR/hs_err_pid47713.log 
# 
# If you would like to submit a bug report, please visit: 
# http://bugreport.java.com/bugreport/crash.jsp 
# 
Abort trap: 6 
DOMAIN$ unlimit -c unlimited 
-bash: unlimit: command not found 

Il ne semble pas y avoir de moyen de le faire sur mac. Toutes les idées pourquoi mon plantage du programme,

+0

DIR/hs_err_pid47713.log .. affiche ce fichier. –

+0

Notez que la commande est 'ulimit', pas' unlimit'. – nasukkin

+0

La sortie indique unlimit ... DOMAIN: $ unlimited -c unlimited -bash: unlimited: commande introuvable – Icepick

Répondre

0

Si vous recherchez Google, ces types de guarantee(PageArmed == 0) failed: invariant accidents JVM ont été autour dans les versions JDK Oracle 6, 7 et 8.

Un couple de « facile » des choses que vous pouvez essayer Pour contourner ce problème:

1) Modifiez la version du JRE que vous utilisez, par exemple essayez de passer à une version plus récente que 1.8.0_65;

2) Mettez à niveau votre système d'exploitation, par ex. utilisez-vous une ancienne version de Linux?

3) Vous indiquez que cela se produit pour de grandes quantités de données. Avez-vous envisagé d'utiliser un profileur tel que YourKit pour étudier l'utilisation de la mémoire de thread et de tas dans la JVM afin de les éliminer comme étant un problème?

+0

Je suis sur un mac, et je n'ai pas ce genre d'accès. Je sais précisément quel fil est le problème, car c'est un goulot d'étranglement pour les calculs. – Icepick

0

Ce numéro du compilateur JVM, Erreur interne (safepoint.cpp: 310), pid = 47713, tid = 11267

garantie (PageArmed == 0) a échoué: invariant

suggèrent qu'un du fil n'a pas pu atteindre à safepoint. Lorsqu'un safepoint est en attente, le VMThread attendra que tous les threads _thread_in_Java passent dans un autre état, où ils sont déjà sécurisés (_thread_blocked, _thread_in_native) ou entreront dans une négociation avec le VMThread pour se mettre en sécurité (_thread_in_VM La cause la plus probable est une boucle du compilateur non comptée qui n'a aucun sondage safepoint généré Vous devez signaler à http://bugreport.java.com/ avec le scénario de test pour reproduire ce problème.