Discussion :

[tchize_]

le point n'est pas la, le GC explicite est inutile puisque la jvm lors de la tentative d'allocation va tout faire pour trouver la mémoire dont tu as besoin.

De toutes facons, tu ignore ou a eu lieu le Out of memory, ca peut etre dans l'allocation d'un buffer pour une socket par exemple, auquel cas tu as peut etre perdu des données dans le meilleurs des cas ou tu a rendu ta socket inutilisable dans le pire des cas. Vouloir retomber sur ses patte est stupide dans 99.9% des cas.

Quand à la spec, ouvre la, elle fait des tonnes de pages, cherche la partie sur allocation de mémoire et tu verra qu'elle fait tout pour trouver ta mémoire et qu'elle lance elle meme le gc, donc un gc explicite est inutile. System.gc() n'est pas une commande magique qui va tout faire fonctionner. On l'utilise très rarement et uniquement quand nécessaire pour des raison de performances. Exemple fictif: tu sais que tu va avoir besoin de faire 10 allocations en file et que t'asbesoin d'etre trèsréactif pendant ces 10 allocations. Dans ce cas tu lance le gc avant pour "limiter" les risque qu'il tourne pendant!

[Uther]

Vouloir retomber sur ses patte est stupide dans 99.9% des cas.

Je ne suis pas tout a fait d'accord.

On peut anticiper un problème de mémoire quand on fait de grosses allocations. Par exemple, l'allocation d'un gros buffer pour faire un traitement sur une image.
Si on catch les OutOfMemoryException précisément sur l'allocation de ce buffer, on doit pouvoir afficher un message, d'erreur disant que l'opération nécessite plus de mémoire et continuer.

[adiGuba]

Dans le cas d'une application il ya des objets (références) qui ne sont plus atteignable et que le gc peut récupérer. Si à un instant T on veut allouer une quantité de mémoire raisonnable (pas comme dans ton code) alors peut être le fait d'attendre un peu le GC ça peut aider à récupérer un peu de mémoire et du coup ça peut fonctionner..

Non le GC va tout faire pour libérer la mémoire avant de générer l'OutOfMemoryError... donc l'appel à System.gc() est inutile.

Quel que soit la quantité de mémoire que tu alloues (raisonnable ou pas), si une OutOfMemoryError se produit tu ne pourrais pas l'empêcher avec un appel explicite à System.gc()...


Par contre System.gc() risque de provoquer un FullGC très couteux en temps et inutile (car rien ne te permet de savoir si c'est nécessaire ou pas).


Sur le forum je n'ai jamais vu d'exemple où System.gc() était utile. Au contraire bien souvent cela se révèle catastrophique en terme de performance

Si on catch les OutOfMemoryException précisément sur l'allocation de ce buffer, on doit pouvoir afficher un message, d'erreur disant que l'opération nécessite plus de mémoire et continuer.

En mono-thread c'est tout à fait possible... mais en multi-thread ce n'est pas forcément évident car l'erreur ne va pas survenir forcément dans la méthode consommatrice de mémoire.

Donc ce n'est pas si évident que cela à traiter...


a++

[Auteur]

J'aurai peut-être dû le dire dès le début
L'erreur "java.lang.OutOfMemoryError: Java heap space" se produit lorsque je remplis un JTextPane. Il arrive un moment où je ne peux plus écrire dans le composant car l'application ne dispose pas de mémoire suffisante.

Si tu es en Java 5.0 il est préférables d'utiliser les UncaughtExceptionHandler, qui te permettent de traiter les exceptions qui ne sont pas traitées :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
	Thread.setDefaultUncaughtExceptionHandler(new Thread.UncaughtExceptionHandler() {
		@Override
		public void uncaughtException(Thread t, Throwable ex) {
			try {
				JOptionPane.showMessageDialog(this, ex.getMessage(), "Critical Error.", JOptionPane.ERROR_MESSAGE);
				Logger.getLogger(MonProjet.class.getName()).log(Level.SEVERE, null, ex);
			} finally {
				System.exit(1);
			}
		}
	});

Ce bout de code m'intéresse bien Mais est-t-il possible de filtrer les exceptions qui seront gérées par ce thread ?
En effet, la boite dialogue s'affiche et le programme quitte à la moindre exception levée ou non gérée (c'est le but me direz vous). Mais est-il possible de ne traiter que l'erreur Java Heap Space ?

[adiGuba]

Il doit être énorme ton JTextPane

Ce bout de code m'intéresse bien Mais est-t-il possible de filtrer les exceptions qui seront gérées par ce thread ?

Tu peux "thrower" l'exception pour la recatcher

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
	Thread.setDefaultUncaughtExceptionHandler(new Thread.UncaughtExceptionHandler() {
		@Override
		public void uncaughtException(Thread t, Throwable ex) {
			try {
				throw ex;
			} catch(OutOfMemoryError e) {
				// traitement OutOfMemoryError
			} catch (Throwable t) {
				// Autre traitement
			}
		}
	});

Par contre les autres exceptions qui arrive ici sont des erreurs inattendus, donc il n'y a pas vraiment de raison que tu les ignores. Cela pourrait même être "dangereux" en générant de plus en plus d'erreurs incompréhensible...


a++

[Auteur]

Il doit être énorme ton JTextPane

euh..... oui et non
Je l'utilise pour loguer des événements, et là je teste sa capacité maximale (test de performance on va dire). Même si cela a peu de chance de se produire, je préfère prévenir

Par contre les autres exceptions qui arrive ici sont des erreurs inattendus, donc il n'y a pas vraiment de raison que tu les ignores. Cela pourrait même être "dangereux" en générant de plus en plus d'erreurs incompréhensible...

Le cas se produit par exemple si je charge un fichier qui n'existe pas. Pourtant il me semble bien gérer l'exception :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
    public void openFile(File fileName) throws FileNotFoundException
    {
        try
        {           
            this.monFichier = new DataInputStream(new FileInputStream(fileName));
        }
        catch (IOException ex)
        {
            Logger.getLogger(ClasseFichiers.class.getName()).log(Level.SEVERE, null, ex);
        }
 
    }

puis dans la classe principale :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
        if (fc.showOpenDialog(this)==JFileChooser.APPROVE_OPTION)
        {
            file = fc.getSelectedFile();
            try
            {
                // lecture du fichier....
                fichier.openFile(file);
            }
            catch (FileNotFoundException ex)
            {
                Logger.getLogger(MonProjet.class.getName()).log(Level.SEVERE, null, ex);
                Err = true;
            }
            if (Err)
                return;
 
			//... suite du code....
        }

Si le fichier passé en paramètre de openFile() n'existe pas j'ai un FileNotFoundException qui est déclenché. Pourtant, il me semble bien la gérer.
Je m'y prends mal ?

[edit]

Bon j'ai résolu le problème évoqué ci-dessus (les exceptions levées avec ma fonction openFile()).
Déjà IOException passe avant FileNotFoundException, du coup FileNotFoundException ne sert plus à grand chose
Ensuite il y a ma variable fileName, il faut que je teste si fileName.exists() est vrai avant le new FileInputStream(fileName)).
Enfin, le Logger qui lui affichait dans la console l'exception retournée.

[/edit]

[hibour]

Envoyé par adiGuba
Non le GC va tout faire pour libérer la mémoire avant de générer l'OutOfMemoryError... donc l'appel à System.gc() est inutile.

Ok dans ce cas j'avoue que je suis bien d'accord que c'est inutile le System.gc(). Pourquoi ne pas rendre cette méthode deprecated tout simplement ou mieux mettre une implémentation vide puisque la JVM est si parfaite

[tchize_]

en fait, rien n'empeche la jvm de fournir une implémentation vide de System.gc()

A la question du pourquoi c'est pas fait, c'est pas à nous de répondre mais à sun

[adiGuba]

en fait, rien n'empeche la jvm de fournir une implémentation vide de System.gc()

+1 c'est au libre choix de la JVM de de son implémentation !

Raison de plus de s'en méfier : lorsqu'ils sont ignorés on ne se rend pas forcément compte des problèmes de performance que cela peut engendrer, et le changement de JVM peut s'avérer catastrophique s'ils se retrouvent pris en comtpe...

Quelques exemples de problèmes liés à des appels explicites à System.gc() :

• jre 1.5, tomcat 6.0 et multi processeurs
• Difference de performances Unix/Windows d'un programme?

A noter que la plupart des JVM permettent de désactiver ces appels explicites via des options de la ligne de commande (-XX:+DisableExplicitGC pour la JVM de Sun).

Pourquoi ne pas rendre cette méthode deprecated tout simplement ou mieux mettre une implémentation vide puisque la JVM est si parfaite

Je n'ai pas dit que la JVM était parfaite

Maintenant ce n'est pas parce que la méthode n'est pas deprecated qu'il faut obligatoirement l'utiliser...

a++

[Auteur]

je constate que je vais devoir gérer le problème de manière plus subtile :
en effet quand l'exception se produit, la jvm tarde à reprendre la main, mon interface devient noire (le programme ne répond plus) et la boite de dialogue affichant l'erreur de s'affiche pas.


Mon erreur se déclenche dans une boucle. Donc je me dis que je devrais vérifier à chaque itération la mémoire utilisée par l'application et déclencher manuellement l'exception avant d'atteindre la saturation. Je pense que de cette manière :
1- mon application ne sera pas bloquée
2- ma boite de dialogue pourra s'afficher
3- mon application pourra se fermer plus rapidement

Mais, la question que je me pose est à partir de quelle limite je peux considérer que je n'ai plus assez de mémoire pour que l'application puisse fonctionner normalement ??

[tchize_]

la question que tu dois surtout te poser: peux-t-on savoir combien de mémoire il reste de libre réellement pour la jvm (c'est à dire mémoire vive + ce qui est garbage collectable)?

(indice: la réponse est non)

[Auteur]

la question que tu dois surtout te poser: peux-t-on savoir combien de mémoire il reste de libre réellement pour la jvm (c'est à dire mémoire vive + ce qui est garbage collectable)?

(indice: la réponse est non)

euh là je ne comprends plus
D'après la FAQ :

Ensuite, il suffit d'utiliser la méthode getHeapMemoryUsage() qui retournera un objet MemoryUsage contenant le détail de la mémoire utilisé par votre application. Il contient ainsi les informations suivantes :
* init : La taille initiale de la mémoire utilisé par l'application (généralement 0, sauf si l'on a utilisé l'option -Xms de la JVM).
* used : La quantité de mémoire qui est réellement utilisée par votre application.
* committed : La quantité de mémoire qui a été réservée auprès du système d'exploitation.
* max : La quantité maximale que la JVM est authorisée à réserver auprès du système d'exploitation (modifiable avec l'option -Xmx de la JVM). Si l'application utilise plus de mémoire cela générera une OutOfMemoryError.

Si je fais (max-used) j'ai bien la quantité de mémoire qui me reste non ?

Pour mon application, je n'utilise ni l'option -Xmx ni l'option -Xms.

[tchize_]

non, si tu alloue un objet de 50M, disons, et que tu supprime toutes ses référence. Le GC n'est pas encore passé dessus, mais il compte dans le used, car jusqu'à p^reuve du contraire, il est utilisé. Mais, il est libérable, juste pas encore libéré. Comme il est libérable, il doit etre compté comme du "free", mais il est toujours dans le used, paradoxal mais bon. Bref, le seul moyen de connaitre la mémoire dispos, ce serai "max - used + récupérable par GC", et le dernier terme n'est pas mesurable ....

[adiGuba]

Quel est la quantité de mémoire utilisée ? Que fait ta boucle ?
Quel est la portée des objets consommateurs de mémoire ?
Est-ce normal pour ton application d'utiliser "autant" de mémoire ?

a++

[Auteur]

non, si tu alloue un objet de 50M, disons, et que tu supprime toutes ses référence. Le GC n'est pas encore passé dessus, mais il compte dans le used, car jusqu'à p^reuve du contraire, il est utilisé. Mais, il est libérable, juste pas encore libéré. Comme il est libérable, il doit etre compté comme du "free", mais il est toujours dans le used, paradoxal mais bon. Bref, le seul moyen de connaitre la mémoire dispos, ce serai "max - used + récupérable par GC", et le dernier terme n'est pas mesurable ....

Si j'ai bien compris si je fais un (max - used) je surévalue la quantité de mémoire restante ? A la limite, je dirais que ça ne me gène pas trop : je préfère ça qu'un plantage pur et simple

Quel est la quantité de mémoire utilisée ? Que fait ta boucle ?
Quel est la portée des objets consommateurs de mémoire ?
Est-ce normal pour ton application d'utiliser "autant" de mémoire ?

a++

Je cherche simplement les limites d'utilisation du programme. Donc je cherche tous les éléments qui sont susceptibles de provoquer des erreurs, des plantages etc.

Cette boucle remplit un StringBuffer, puis j'écris le contenu de ce buffer dans un JTextPane.

L'application va loguer dans ce JTextPane toute une série d'événements et de données. A priori, je ne connais pas la quantité d'informations que contiendra le fichier RTF qui sera généré à partir de ce JTextPane.

L'outil profiler de Netbeans montre bien que pendant cette phase, la mémoire consommée monte en flèche Il suffit que je vide le JTextPane pour que la mémoire consommée retombe à un niveau normal.


D'après mes premiers tests, l'exception Java Heap Space a peu de chance de se produire, mais je préfère la gérer plutôt que d'avoir une application qui plante sans prévenir

[adiGuba]

Si j'ai bien compris si je fais un (max - used) je surévalue la quantité de mémoire restante ? A la limite, je dirais que ça ne me gène pas trop : je préfère ça qu'un plantage pur et simple

Non tu la sous-évalues...

Le "used" peut contenir des objets libérables.

Je cherche simplement les limites d'utilisation du programme. Donc je cherche tous les éléments qui sont susceptibles de provoquer des erreurs, des plantages etc.

Le problème c'est qu'on ne connait rien de ton programme ni de ses objectifs, donc difficile de t'aider concrètement.

Sans info sur ton programme, on ne pourra te donner que quelques vagues pistes ou quelques précisions. Rien de plus...


a++

[tchize_]

tu peux travailler autrement. Si tu a un algo X consommateur de mémoire et que tu peux +- évaluer la mémoire dont il aura besoin. Tu peux faire ceci

if ( (max - <ce que consomme en général mon prog sans l'algo>) < ce que risque de consommer l'algo)
alors: warning 'etes vous sur?'

[Auteur]

Le problème c'est qu'on ne connait rien de ton programme ni de ses objectifs, donc difficile de t'aider concrètement.

Ce programme transmet par TCP/IP des paquets de données à un PC client et pour garder une trace sur les informations envoyées, elles sont écrites dans ce JTextPane avant d'être enregistrées dans un fichier. C'est l'utilisateur qui provoque l'envoi des données en cliquant sur un bouton "Submit".

A l'origine je m'intéressais à la quantité d'informations que peut contenir le JTextPane. Donc pour le test, je réalise une boucle qui simule un nombre important de clics sur le bouton "Submit". Et à chaque clic simulé, je remplis le JTextPane... jusqu'à atteindre la limite et provoquer cette exception.

D'après les résultats, je peux placer 1 million de caractères ce qui revient à réaliser plus de 1000 envois.

Dans la réalité, il est très peu probable que cette limite soit atteinte.

non, si tu alloue un objet de 50M, disons, et que tu supprime toutes ses référence. Le GC n'est pas encore passé dessus, mais il compte dans le used, car jusqu'à p^reuve du contraire, il est utilisé. Mais, il est libérable, juste pas encore libéré. Comme il est libérable, il doit etre compté comme du "free", mais il est toujours dans le used, paradoxal mais bon. Bref, le seul moyen de connaitre la mémoire dispos, ce serai "max - used + récupérable par GC", et le dernier terme n'est pas mesurable ....

Non tu la sous-évalues...

Le "used" peut contenir des objets libérables.

En effet, je sous-évalue la quantité de mémoire restante. Ensuite je ne vois pas trop comment je peux calculer la mémoire consommée.


Est-ce que cette méthode qui consiste à vérifier à chaque itération la quantité de mémoire utilisée (même si celle-ci contient des objets libérables) par rapport à une limite que j'aurai fixée vous semble correcte ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
 
MemoryMXBean memoryBean = ManagementFactory.getMemoryMXBean();
int i, max;
long quantiteMemoireMax;
 
 
// instructions
 
try
{
	for (i=0; i<max; i++)
	{
		// instructions
		// écriture dans le  JTextPane
 
		if (memoryBean.getHeapMemoryUsage().getUsed() > quantiteMemoireMax)
			throw new OutOfMemoryError(); 
 
	}
}
catch (OutOfMemoryError ex)
{
	try
	{
		JOptionPane.showMessageDialog(this, ex.getMessage(), "Erreur...", JOptionPane.ERROR_MESSAGE);
		Logger.getLogger(monProjet.class.getName()).log(Level.SEVERE, null, ex);
	}
	finally
	{
		//this.dispose();
		System.exit(2);
	}
}

[tchize_]

pour ton cas précis (jTextPane), ce qui devrait être fait

1) probablement ta propre implémentation de Document qui supporte mieux les ajouts que celle par défaut (qui va faire copie / ajout / remplacement, donc double consommation de mémoire, si je me souviens bien)

2) Limiter volontairement (par une config de ton programme) la quantité de mémoire utilisée par ton textpane. Exemple: limiter à 50M le textpane, ce qui reviens à dire +-, le limiter à un Document sans mise en forme de 50 millions de caractères


Le point 2, c'est ce que font des logiciels comme eclipse pour gérer la console.

[Auteur]

pour ton cas précis (jTextPane), ce qui devrait être fait

1) probablement ta propre implémentation de Document qui supporte mieux les ajouts que celle par défaut (qui va faire copie / ajout / remplacement, donc double consommation de mémoire, si je me souviens bien)

Les premiers temps j'appelais insertString dans la boucle, et je me suis aperçu que cela prenait trop de temps.

Du coup dans ma boucle, je remplis un StringBuffer et à la sortie j'écris le contenu dans le JTextPane.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
 
StringBuffer buf = new StringBuffer();
String str = new String();
 
//....
 
try
{
	buf.setLength(0);
 
	while(i<nLignes)
	{
		for (j=0; j<nColonnes; j++)
		{
			str = (String)this.table.getModel().getValueAt(i, j);
			buf.append(str);
			buf.append("\t");
		}
		buf.append("\n");
	}
 
	monTextPane.getDocument().insertString(rtfStyledDoc.getLength(), buf.substring(0), attrs);
	buf.setLength(0);
	buf = null;
}
catch (OutOfMemoryError ex)
{
 
}

2) Limiter volontairement (par une config de ton programme) la quantité de mémoire utilisée par ton textpane. Exemple: limiter à 50M le textpane, ce qui reviens à dire +-, le limiter à un Document sans mise en forme de 50 millions de caractères


Le point 2, c'est ce que font des logiciels comme eclipse pour gérer la console.

Je peux limiter la mémoire pour 1 composant en particulier ?
Comment faire ?
Dans mon cas le document a une mise en forme (couleur, taille des caractères, police utilisée), j'utilise le RTFEditorKit.