> Je vais redire ce qu'il y a sur wikipedia car j'aime bien mon clavier bépo
Le problème c'est que tu as du t'arrêter à la section "basic algorithms"... Les GC de prod, c'est un tantinet moins con et plus optimisé que ça.
Tu crois vraiment qu'un GC passe son temps à scanner toute la mémoire ? Tu as entendu parlé des GC générationels ? Tu as déjà monitoré un vraie application pour avoir les stats des générations et constater combien de fois on scanner la mémoire en pratique ? Quels étaient les bouts de code pathologique contre un GC ? Comme écrire son application pour aider le GC ( http://developers.sun.com/learning/javaoneonline/j1sessn.jsp(...) ) ?
Tu sais qu'on peut faire tout ca de manière concurrente ? Qu'on est pas obligé de faire un stop-the-world pour marquer ni pour contacter ? Qu'on est pas obligé de scanner toute la mémoire modulo un petit overhead mémoire ? Qu'on peut faire du GC en temps réel soft et collaborer avec le GC pour minimiser le jitter ( http://qconlondon.com/london-2008/file?path=/qcon-london-200(...) ) ?
Est ce que tu as compris que le problème d'un GC, c'est simplement qu'en général il ne va pas réclamer la mémoire dans les veilles générations sauf si il est à cours à mémoire. C'est aussi simple que ca ! C'est pas génant pour certaines applis, pour d'autres si.
De même tu as beau faire tes jolis malloc/free à la main. Si ton tas devient fragmenté le système ne récupéra pas la mémoire non plus, et bon courage pour compacter à la main...
Après j'ai donné tout les exemples en Java par ce que tu aimes bien dire n'importe quoi sur Java, mais on peut prendre d'autres exemples.
# Comme d'habitude avec yellowiscool
Posté par ckyl . En réponse au journal Encore une histoire de récupérateur de mémoire. Évalué à 10.
Le problème c'est que tu as du t'arrêter à la section "basic algorithms"... Les GC de prod, c'est un tantinet moins con et plus optimisé que ça.
Tu crois vraiment qu'un GC passe son temps à scanner toute la mémoire ? Tu as entendu parlé des GC générationels ? Tu as déjà monitoré un vraie application pour avoir les stats des générations et constater combien de fois on scanner la mémoire en pratique ? Quels étaient les bouts de code pathologique contre un GC ? Comme écrire son application pour aider le GC ( http://developers.sun.com/learning/javaoneonline/j1sessn.jsp(...) ) ?
Tu sais qu'on peut faire tout ca de manière concurrente ? Qu'on est pas obligé de faire un stop-the-world pour marquer ni pour contacter ? Qu'on est pas obligé de scanner toute la mémoire modulo un petit overhead mémoire ? Qu'on peut faire du GC en temps réel soft et collaborer avec le GC pour minimiser le jitter ( http://qconlondon.com/london-2008/file?path=/qcon-london-200(...) ) ?
Présentation d'un GC moderne, aka G1:
slides, http://developers.sun.com/learning/javaoneonline/2008/pdf/TS(...)
papier, http://research.sun.com/jtech/pubs/04-g1-paper-ismm.pdf
Est ce que tu as compris que le problème d'un GC, c'est simplement qu'en général il ne va pas réclamer la mémoire dans les veilles générations sauf si il est à cours à mémoire. C'est aussi simple que ca ! C'est pas génant pour certaines applis, pour d'autres si.
De même tu as beau faire tes jolis malloc/free à la main. Si ton tas devient fragmenté le système ne récupéra pas la mémoire non plus, et bon courage pour compacter à la main...
Après j'ai donné tout les exemples en Java par ce que tu aimes bien dire n'importe quoi sur Java, mais on peut prendre d'autres exemples.