Pour une fois, Google n'est pas mon ami Il me semblait que c'etait "-nogc", mais c'est pas ca ...

c'est possile ?

benou a écrit a écrit : c'est possile ?

En effet ca me parait assez dangereux comme truc...  
Si c'est pour accélèrer l'execution d'un endroit critique, en génèral il faut faire une garbage collect juste avant de rentrer dedans... mais désactiver le garbage collector pas une bonne idée à mon avis (et je crois que ce n'est même pas possible...)

non ce n'est pas possible. Enfin c'est pas standard en tout cas (tu pourrais très bien écrire une JVM qui offre cette option pourquoi pas)

-noasyncgc  "don't allow asynchronous garbage collection"
-noclassgc  "disable class garbage collection"
 
Mais n'aller pas me demander ce que ça signifie exactement... Et apparemment ça n'existe plus à partir du JDK1.2

 
>> disable class garbage collection
ca doit vouloir dire qu'il ne grabage plus les Class (il n'oublie plus les .class qu'il a déjà chargé). enfin peut être ...

de toutes façons ça n'existe plus, j'ai trouvé ça par hasard sur une machine unix qui en est encore au jdk1.1
et sur mon poste avec le 1.3 cette option n'existe plus...

Ben "-noclassgc" ca marche encore sur ma 1.3.1 ... de toutes facons, pas de panique, c'est juste pour voir la consommation memoire totale d'une mthode que je ne peux pas inpecter autrement :
 
- je force le GC
- je note la memoire libre
- je tourne ma methode
- je note la memoire libre
 
Le fait de desacitver le GC me garantit que la soustraction des 2 nombres me donne la memoire utilisee (directement et indirectement) par ma methode.

c'est débile ce que tu fais. Appeller System.gc() n'est en aucun cas synchrone et tu n'as aucune garantie qu'il est lancé immédiatement ...

forcer le gc comme tu dis ca n'existe pas ...

 
meme s'il ne garantit pas le resultat (best effort), l'action de system.gc() est au moins synchrone si j'en crois la doc.
 
LeGreg

 
non. System.gc() n'est pas synchrone. J'en suis presque sûr

en fait j'ai un peu l'impression que ca depend  
de la JVM utilisée.
 
Trouvé sur le site d'IBM:
http://www-106.ibm.com/developerwo [...] 0117b.html
 
LeGreg

 
Ca par contre je te suis à 100%

j'ai appris qqch ajd cool
 

El Scorcho a écrit:

Dans le 1.4:
F:\javawork\src>java -X
    -Xnoclassgc       disable class garbage collection
    -Xincgc           enable incremental garbage collection
    -Xloggc:<file>    log GC status to a file with time stamps
 
à noter que:
The -X options are non-standard and subject to change without notice.
 
K.

De toute façon, ça ne sert à rien de vouloir activer/desactiver/lancer le GC à la main (le GC est non predictible)...
 
Le meilleur moyen de tuner une appli est de definir un heap bien ajusté.

 
honnetement, si tu veux controler la memoire utilisée par tes methodes passe a un autre langage que java.
il est totalement fait pour que le programmeur
ne puisse avoir aucun controle la dessus.
si ce n'est par la creation de variables, c'est la seule
chose que tu peux controler (le nombre de variables que tu  
crees par new !).
 
LeGreg

 
exactement. Utilise un profiler pour voir ce qui arrive...
JProbe par exemple est tres bien...si t'as de la thune!!!