[Java]Répercuter une erreur "OutOfMemory" de la JVM

Répercuter une erreur "OutOfMemory" de la JVM [Java] - Java - Programmation

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.

Reply

Marsh Posté le 18-04-2003 à 13:59:59   

Reply

Marsh Posté le 18-04-2003 à 14:38:47    

candide2 a écrit :

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.


 
ben try catch... je vois pas le problème...  :??:

Reply

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...


Message édité par deltaden le 18-04-2003 à 17:38:11

---------------
"La Terre est le berceau de l'humanité, mais on ne passe pas toute sa vie au berceau." - Konstantine Tsiolkovski
Reply

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.

Reply

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 :
  1. char[] bouffeMem = new char[1>>32];


 
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.

Reply

Marsh Posté le 18-04-2003 à 22:09:22    

1>>32
 
pourquoi pas ~0
 
edit:oops: saloperie de types signés


Message édité par Taz le 18-04-2003 à 22:12:30
Reply

Marsh Posté le 19-04-2003 à 17:07:25    

deltaden a écrit :

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...


 
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...

Reply

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 :


public class Exception
extends Throwable
 
The class Exception and its subclasses are a form of Throwable that indicates conditions that a reasonable application might want to catch.  


Citation :


public class Error
extends Throwable
 
An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch. Most such errors are abnormal conditions. The ThreadDeath error, though a "normal" condition, is also a subclass of Error because most applications should not try to catch it.
 
A method is not required to declare in its throws clause any subclasses of Error that might be thrown during the execution of the method but not caught, since these errors are abnormal conditions that should never occur.  


c'est pas moi qui l'ai dit :o


---------------
"La Terre est le berceau de l'humanité, mais on ne passe pas toute sa vie au berceau." - Konstantine Tsiolkovski
Reply

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.


Message édité par nraynaud le 19-04-2003 à 19:03:29
Reply

Marsh Posté le 19-04-2003 à 19:13:28    

nraynaud a écrit :


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.


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.


---------------
"La Terre est le berceau de l'humanité, mais on ne passe pas toute sa vie au berceau." - Konstantine Tsiolkovski
Reply

Marsh Posté le 19-04-2003 à 19:13:28   

Reply

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.


Message édité par BifaceMcLeOD le 22-04-2003 à 10:18:54
Reply

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 :jap:


---------------
Just because you feel good does not make you right
Reply

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 :

  • quand le programme charge un fichier sur demande de l'utilisateur, il arrête et il reprend le programme là il en était avant que l'utilisateur fasse cette demande.
  • Dans un serveur basé sur des servlets, on arrête la servlet et on libère les ressources qu'elle a prises (les autres servlets continuent de tourner comme si de rien n'était).


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.

Reply

Marsh Posté le 22-04-2003 à 12:36:35    

BifaceMcLeOD a écrit :


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.


Ok, il reste une quantité "minimale" de mémoire pour pouvoir traiter le problème alors.
Merci pour l'info  :jap:


---------------
"La Terre est le berceau de l'humanité, mais on ne passe pas toute sa vie au berceau." - Konstantine Tsiolkovski
Reply

Marsh Posté le 22-04-2003 à 15:02:50    


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.

Reply

Marsh Posté le 21-05-2003 à 10:36:32    

et sinon comment vous faites pour augmenter la taille mémoire allouer par la JVM :??:

Reply

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.

Reply

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.

Reply

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 ????   :heink:  
 
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...


Message édité par senternal le 21-05-2003 à 15:30:32
Reply

Marsh Posté le 21-05-2003 à 23:55:00    

merci on va essayer ca  :jap:

Reply

Marsh Posté le 22-05-2003 à 15:38:22    

senternal a écrit :


 
Et a ton avis Tomcat il a sa propre JVM ????   :heink:  


J'au rais répondu un poil différemment...
"Et a ton avis Tomcat c'est pas un exécutable, peut-être ? :heink:"
 
;)

Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed