bon beh voilà... une génération de documents de base XML un peu trop violente apparemment...
 
alors, j'ai trouvé avec java -X les options avancées de la JVM mais... pour augmenter la taille du heap avec -Xmx<size> il faudrait p-ê connaître la taille par défaut.
 
qq'un a une idée pour connaître le taille par défaut du heap ?

beuh ?

Holà, les questions compliquées ... Je ne sais vraiment pas !! Enfin en ce qui concerne les appli sur lesquelles je bosse, les JVM sont configurées en -mx64 pour 64 Mo ;o)

c'est bon, je l'ai  
c'est -Xmx128M (pour mon prog)
   
mais c'est mon code qui est pourri, j'ai une fuite mémoire... mais où...  

[edtdd]--Message édité par TBone--[/edtdd]

Pour le profiling tu peux utiliser un produit qui s'appelle Optimize It qui m'a permis de faire le ménage. Il est téléchargeable en version d'éval sur le net !!

TBone a écrit a écrit : c'est bon, je l'ai mais c'est mon code qui est pourri, j'ai une fuite mémoire... mais où...

 
Peut-etre que tu as force un peu trop sur la recursion ?
 
A+
LEGREG

Y'a aussi que la JVM a un mécanisme de nettoyage (le garbage collector) qui, en théorie, fais le propre à notre place.
Tout ceci est bien beau mais c'est pas toujours le cas et il est tout de meme bon de faire sois même la suppression des références hisoire que ce mécanisme joue un partie du jeu pour lequel il est prévu !!

C'est sur que si tu supprimes pas les réfrences vers tes objets, le garbage collector fera pas grand chose

oups. un peu absent  
 
en fait c'est une récursivité un peu longue qui m'a fait découvrir l'erreur. je stockais dans une hashtable globale des objects locaux. et comme je ne les virais pas de ma table globale, ils restaient en mémoire alors que j'étais persuadé qu'ils étaient passés à la trappe.  
 
  'le referai pu.

En ce qui concerne le garbage, si tu ne le chatouille pas ou si tu ne fais pas un minimum de propre il se peut qu'il ne fasse pas grand chose !!