Répercuter une erreur "OutOfMemory" de la JVM [Java] - Java - Programmation
Marsh Posté le 18-04-2003 à 14:38:47
candide2 a écrit : Bonjour, |
ben try catch... je vois pas le problème...
Marsh Posté le 18-04-2003 à 17:37:53
d'habitude les try catch servent à catcher les exceptions.
Un outOfMemory est une erreur. En java, les erreurs sont "normalement" fatales et synonymes d'arret du programme...
Marsh Posté le 18-04-2003 à 18:09:57
je dirais surtout qu'il va falloir allouer l'exception, ce qui me parraît difficile au vu de l'erreur.
Marsh Posté le 18-04-2003 à 22:08:28
nraynaud a écrit : je dirais surtout qu'il va falloir allouer l'exception, ce qui me parraît difficile au vu de l'erreur. |
ca peut arriver genre en faisant
Code :
|
ce qui ne vas sans doute pas marcher, mais l'error sera quand même allouée, puisque bouffeMem n'aura pas été alloué ds le tas.
Marsh Posté le 18-04-2003 à 22:09:22
1>>32
pourquoi pas ~0
edit:oops: saloperie de types signés
Marsh Posté le 19-04-2003 à 17:07:25
deltaden a écrit : d'habitude les try catch servent à catcher les exceptions. |
hmm, j'ai fait un truc comme ca en java y'a pas longtemps et il me semblait que le OutofMemory se recuperait dans un catch... enfin je peux me tromper...
Marsh Posté le 19-04-2003 à 17:40:39
je n'ai ps dis qu'on savait pas catcher une erreur, je n'en sais rien et n'ai jamais essayé. ce que je voulais dire, c'est que la "philosophie" du langage est que les erreurs sont "habituellement" fatales. mais c'est vrai que dans ce cas ci, il est sans doute nécessaire de la catcher.
De l'API java:
Citation : |
Citation : |
c'est pas moi qui l'ai dit
Marsh Posté le 19-04-2003 à 19:02:34
Nan, mais la c'est juste catche pour mettre en forme l'erreur, ca reste dans l'esprit. Par contre, il va falloir trouver de la place pour mettre les objets en memoire. Si effectivement, c'est l'allocation d'un gros truc qui a echoué c'est jouable, si c'est celle d'un petit truc (plus probable), c'est mort.
Marsh Posté le 19-04-2003 à 19:13:28
nraynaud a écrit : |
c'est pour ca que d'habitude on ne catche pas les erreurs, c'est parce que on ne sait pas toujours dans quel état se trouve la JVM après. C'est pas toujours facile de retourner à un fonctionnement normal.
Marsh Posté le 22-04-2003 à 10:16:07
N'empêche. Ce qu'attend un catch en Java, c'est un Throwable, pas une Exception. On peut donc attraper une OutOfMemoryError sans aucun problème.
Bien sûr, reste ensuite au programmeur la lourde tâche de savoir comment gérer la délicate reprise sur cette erreur très particulière.
deltaden> Pour ton information, l'exception est lancée quand l'erreur est sur le point d'arriver, pas une fois qu'elle est arrivée. Alors c'est sûr qu'il vaut mieux éviter de créer plein d'objets sur OutOfMemmoryError, car l'exception risque d'être lancée une nouvelle fois, mais sinon, la JVM est dans un état tout à fait stable lorsqu'elle jette ce type d'exception.
Marsh Posté le 22-04-2003 à 10:19:51
nraynaud a écrit : je dirais surtout qu'il va falloir allouer l'exception, ce qui me parraît difficile au vu de l'erreur. |
bien vu
Marsh Posté le 22-04-2003 à 10:59:26
Par expérience, je n'ai jamais constaté de problème de mémoire après une OutOfMemoryError, tant que la première chose que fait l'appli, c'est libérer des ressources. Exemples :
Par contre, dans un programme totalement autonome, sans intervant extérieur qui déclenche des actions du programme, je reconnais, la décision de "où repartir" est beaucoup plus délicate.
Marsh Posté le 22-04-2003 à 12:36:35
BifaceMcLeOD a écrit : |
Ok, il reste une quantité "minimale" de mémoire pour pouvoir traiter le problème alors.
Merci pour l'info
Marsh Posté le 22-04-2003 à 15:02:50
DarkLord a écrit : |
Pas tant que ça, en fait ça peut être une exception pré-allouée (genre pool pré-alloué). J'y ai pensé en le tappant.
Marsh Posté le 21-05-2003 à 10:36:32
et sinon comment vous faites pour augmenter la taille mémoire allouer par la JVM
Marsh Posté le 21-05-2003 à 11:14:46
Par les options en ligne de commande de l'exécutable java :
-Xms<size> set initial Java heap size
-Xmx<size> set maximum Java heap size
Avec un -Xmx128m (128 mégaoctets), ça laisse de la marge.
Maintenant, si ta question est "dynamiquement, comment on change la qualtité de mémoire allouée par Java ?", la réponse est : à ma connaissance, c'est impossible. En deça de la taille maxi autorisée pour le tas (option -Xmx), Java se débrouille tout seul pour l'augmenter, et au-delà, a priori, c'est interdit.
Marsh Posté le 21-05-2003 à 11:35:36
euh c pas un executable donc je lance jamais rien moi. c'est une appli web (une servlet) qui tourne sous tomcat.
Marsh Posté le 21-05-2003 à 15:30:00
ToxicAvenger a écrit : euh c pas un executable donc je lance jamais rien moi. c'est une appli web (une servlet) qui tourne sous tomcat. |
Et a ton avis Tomcat il a sa propre JVM ????
Sous WIN2k par ex, Aller dans %TOMCAT_HOME%/bin
Tu peux modifier par ex catalina.bat
set _EXECJAVA=%_RUNJAVA%
devient
set _EXECJAVA="%_RUNJAVA% -Xmx256m -Xms128m"
Sous Linux/Unix, c'est dans tomcat.sh que ca se passe...
Marsh Posté le 22-05-2003 à 15:38:22
senternal a écrit : |
J'au rais répondu un poil différemment...
"Et a ton avis Tomcat c'est pas un exécutable, peut-être ? "
Marsh Posté le 18-04-2003 à 13:59:59
Bonjour,
j'ai une appli qui lit des fichiers plus ou moins gros.
Elle peut se lancer sous windows en double-cliquant sur le .JAR avec une JVM "standard" au niveau de la mémoire allouée.
Mais dans ce cas je me demande comment récupérer une erreur "OutOfMemory" de la JVM pour le signaler dans mon appli et éviter que l'utilisateur ne reste en attente devant l'écran.