je sais que le Java ne permet pas la désallocation explicite.
Néanmoins je voudrais savoir si il y a un moyen de la "forcer".
Ce que je veux dire par là, c'est est-ce qu'il existe des classes
de "haut-niveau", haut-niveau dans le sens ou elles permettent de faire
ds choses vraiment intéressantes et que le "programmeur de base"
n'utilise pas forcément tous les jours (comme les classes de
java.lang.reflect ou le chargement à chaud de plugin), qui permettraient
de faire ça ?
Si non, y-a-t il des projets indépendants de Sun et qui font ça ?
Si la réponse est non là aussi, qu'elle devrait être l' "astuce" pour
réaliser cela ? Est-ce qu'on peut le faire d'une manière pas très
catholique, mais relativement "facilement", est-ce que ça nécessiterai
de créer une JVM, etc .... ?
Sur quels parametres peut on jouer et comment se font ces reglages ?
en plus les GC modernes sont "concurents" et "incrémentaux", et gênen assez peu l'exécution... le seul soucis c'est qu'il faut savoir les régler (taille des zones d'objets permanents, ancien ou jeunes)
-- Cordialement,
Patrice Trognon http://wwW.javadevel.com
Sur quels parametres peut on jouer et comment se font ces reglages ?
en plus les GC modernes sont "concurents" et "incrémentaux", et gênen
assez peu l'exécution... le seul soucis c'est qu'il faut savoir les
régler (taille des zones d'objets permanents, ancien ou jeunes)
Sur quels parametres peut on jouer et comment se font ces reglages ?
en plus les GC modernes sont "concurents" et "incrémentaux", et gênen assez peu l'exécution... le seul soucis c'est qu'il faut savoir les régler (taille des zones d'objets permanents, ancien ou jeunes)
-- Cordialement,
Patrice Trognon http://wwW.javadevel.com
Alain
je ne les connais pas beaucoup. sur la JVM sun pour une config weblogic j'ai pompé un script et joué, en plus du -Xmx habituel sur un attribut contenant "Permanent" qui fixait la taille de la zone des blocs permanents...
je me suis rendu compte que en fait l'activité du serveur se traduisait par de la consomation mémoire propotionele à la charne ,jusqu'a un seuil ou le GC renverse la vapeur rapidement jusqu'a un autre seuil (probablement le seuil de la zone persistent) et ca repartait
en fait il faudrat trouver 1- une bonne JVM pour ton problème... celle de SUN, celle d'IBM (GC assez diférent), peut être jRockit (BEA ou Borland je sais pas)
2- une doc sur le paramétrage
sinon pour comprendre comment fonctionne les GC générationels il doit y avoir de très bons articles (sur Smalltalk ou lisp éventuellement)
Trognon Patrice wrote:
Sur quels parametres peut on jouer et comment se font ces reglages ?
en plus les GC modernes sont "concurents" et "incrémentaux", et gênen assez peu l'exécution... le seul soucis c'est qu'il faut savoir les régler (taille des zones d'objets permanents, ancien ou jeunes)
je ne les connais pas beaucoup.
sur la JVM sun pour une config weblogic j'ai pompé
un script et joué, en plus du -Xmx habituel
sur un attribut contenant "Permanent" qui fixait la taille de la zone
des blocs permanents...
je me suis rendu compte que en fait l'activité du serveur se traduisait
par de la consomation mémoire propotionele à la charne ,jusqu'a un seuil
ou le GC renverse la vapeur rapidement jusqu'a un autre seuil
(probablement le seuil de la zone persistent) et ca repartait
en fait il faudrat trouver
1- une bonne JVM pour ton problème...
celle de SUN, celle d'IBM (GC assez diférent), peut être jRockit (BEA ou
Borland je sais pas)
2- une doc sur le paramétrage
sinon pour comprendre comment fonctionne les GC générationels il doit y
avoir de très bons articles (sur Smalltalk ou lisp éventuellement)
Trognon Patrice wrote:
Sur quels parametres peut on jouer et comment se font ces reglages ?
en plus les GC modernes sont "concurents" et "incrémentaux", et gênen
assez peu l'exécution... le seul soucis c'est qu'il faut savoir les
régler (taille des zones d'objets permanents, ancien ou jeunes)
je ne les connais pas beaucoup. sur la JVM sun pour une config weblogic j'ai pompé un script et joué, en plus du -Xmx habituel sur un attribut contenant "Permanent" qui fixait la taille de la zone des blocs permanents...
je me suis rendu compte que en fait l'activité du serveur se traduisait par de la consomation mémoire propotionele à la charne ,jusqu'a un seuil ou le GC renverse la vapeur rapidement jusqu'a un autre seuil (probablement le seuil de la zone persistent) et ca repartait
en fait il faudrat trouver 1- une bonne JVM pour ton problème... celle de SUN, celle d'IBM (GC assez diférent), peut être jRockit (BEA ou Borland je sais pas)
2- une doc sur le paramétrage
sinon pour comprendre comment fonctionne les GC générationels il doit y avoir de très bons articles (sur Smalltalk ou lisp éventuellement)
Trognon Patrice wrote:
Sur quels parametres peut on jouer et comment se font ces reglages ?
en plus les GC modernes sont "concurents" et "incrémentaux", et gênen assez peu l'exécution... le seul soucis c'est qu'il faut savoir les régler (taille des zones d'objets permanents, ancien ou jeunes)
no.bcausse.spam
Trognon Patrice wrote:
Sur quels parametres peut on jouer et comment se font ces reglages ?
en plus les GC modernes sont "concurents" et "incrémentaux", et gênen assez peu l'exécution... le seul soucis c'est qu'il faut savoir les régler (taille des zones d'objets permanents, ancien ou jeunes)
ici
http://java.sun.com/docs/hotspot/gc1.4.2/ -- bruno Causse http://perso.wanadoo.fr/othello
Sur quels parametres peut on jouer et comment se font ces reglages ?
en plus les GC modernes sont "concurents" et "incrémentaux", et gênen
assez peu l'exécution... le seul soucis c'est qu'il faut savoir les
régler (taille des zones d'objets permanents, ancien ou jeunes)
ici
http://java.sun.com/docs/hotspot/gc1.4.2/
--
bruno Causse
http://perso.wanadoo.fr/othello
Sur quels parametres peut on jouer et comment se font ces reglages ?
en plus les GC modernes sont "concurents" et "incrémentaux", et gênen assez peu l'exécution... le seul soucis c'est qu'il faut savoir les régler (taille des zones d'objets permanents, ancien ou jeunes)
ici
http://java.sun.com/docs/hotspot/gc1.4.2/ -- bruno Causse http://perso.wanadoo.fr/othello
Vincent Cantin
=> ici
http://java.sun.com/docs/hotspot/gc1.4.2/
Wow ! C'est cool leur technologies ! J'aurais jamais cru que ca aille si loin. Maintenant, je pense que j'hesiterais moins a allouer comme un sauvage de la POO. Le GC, c'est le top ! ^_^
Vincent
=> ici
http://java.sun.com/docs/hotspot/gc1.4.2/
Wow ! C'est cool leur technologies ! J'aurais jamais cru que ca aille si
loin. Maintenant, je pense que j'hesiterais moins a allouer comme un sauvage
de la POO. Le GC, c'est le top ! ^_^
Wow ! C'est cool leur technologies ! J'aurais jamais cru que ca aille si loin. Maintenant, je pense que j'hesiterais moins a allouer comme un sauvage de la POO. Le GC, c'est le top ! ^_^
Vincent
no.bcausse.spam
Vincent Cantin wrote:
Wow ! C'est cool leur technologies ! J'aurais jamais cru que ca aille si loin. Maintenant, je pense que j'hesiterais moins a allouer comme un sauvage de la POO. Le GC, c'est le top ! ^_^
l'ideal c'est quand meme le "pool d'objets" (reutilisation) -- bruno Causse http://perso.wanadoo.fr/othello
Vincent Cantin <Pere.Noel@lutin.fr> wrote:
Wow ! C'est cool leur technologies ! J'aurais jamais cru que ca aille si
loin. Maintenant, je pense que j'hesiterais moins a allouer comme un sauvage
de la POO. Le GC, c'est le top ! ^_^
l'ideal c'est quand meme le "pool d'objets" (reutilisation)
--
bruno Causse
http://perso.wanadoo.fr/othello
Wow ! C'est cool leur technologies ! J'aurais jamais cru que ca aille si loin. Maintenant, je pense que j'hesiterais moins a allouer comme un sauvage de la POO. Le GC, c'est le top ! ^_^
l'ideal c'est quand meme le "pool d'objets" (reutilisation) -- bruno Causse http://perso.wanadoo.fr/othello
