Tu t'énerves beaucoup, donc c'est durde savoir de quoi tu parles exactement, mais quand je lit ca:
Mettre à NULL aide le GC a ne jamais arriver au stade de faire une passe entière sur tout le graphe de flot de donnée.
Je me demande bien de quoi tu parles. Si tu parles du GC java, tu viens d'écrire une gigantesque connerie. Si tu parles de n'importe quel GC mark and sweep en fait, tu viens d'écrire une monumentale connerie (et j'espère bien que plus personne n'écrit de GC a retain count).
Si ta variable est locale et que tu ne t'en sert plus jusqu'a la fin de ton scope et que le JIT ne l'a pas deja optimised out (ca commence a faire pas mal de et la quand meme), certes, tu vas permettre a une potentielle passe du GC de la trouver avant la fin du scope.
Si tant est que le GC fait sa pause entre le moment ou tu penses avoir assigne ta variable a NULL et le moment ou le scope se serait fini et ou ton pointeur devient garbageable.
Oui, je dit "pense avoir assigne ta variable", parce que tu n'es pas sans savoir que le compile peut decider que c'est une idée a la con d'assigner NULL a une variable locale et virer l'instruction (et entre nous, c'est difficile de lui en vouloir de penser ca).
Si ta variable n'est pas locale, i.e. un membre vu que c'est un peu le seul moyen d'avoir une variable non locale en java, ben soit tu viens de fixer une leak gentillette (= vaguement equivalent a un malloc non balance par un free en c), en d'autre termes, un bug, soit tu viens de modifier le comportement de ton programme (i.e tu viens de créer un bug).
Bref, t'avoueras qu'au final le gain est maigre et vraiment hypothétique.
Sinon je veux bien que tu m'expliques en quoi le GC java va skipper les structures récursives ou profondément linkees (et surtout j'aimerais bien savoir ce qu'est une structure profondément linkee), sachant qu'il fonctionne surtout par generation, et qu'il va donc parcourir toute la heap appartenant a une generation.
Ensuite, le "on the fly progressif", comme tu dit, ca ne garantit pas de tout libérer, effectivement, et ca tombe bien, c'est le but. Le fait est que les jeunes generations meurent très jeunes et les vieilles ne meurent souvent jamais. En gros, des gens plus malin que toi se sont rendus compte que l'immense majorité des objets meurent soit très très vite, soit jamais.
Donc effectivement, tu ne libères pas tout en faisant une passe sur ta jeune generation, tu libères quasiment tout, et c'est bien le but.
En arriver à devoir du tuning aussi bas niveau que https://confluence.atlassian.com/display/DOC/Garbage+Collector+Performance+Issues (premier lien en cherchant garbage collector performance dans google, je n'ai pas sélectionné, hein) est ridicule quand le but affiché du GC est de ne plus gérer la mémoire. C'est plus de travail de tuning qu'une allocation manuelle et tes moyens d'actions sont très limités.
Oui, parce qu'évidemment, gérer une heap de 8+GB avec du c++, c'est trivial, hein? D'ailleurs, FF n'a jamais eu de problèmes de fragmentation de heap qui gonflait en permanence son occupation mémoire, c'est bien connu!
[^] # Re: la réponse est évidente
Posté par groumly . En réponse au journal [Trolldi] Le langage plus approprié pour écrire des applications graphiques multiplateformes. Évalué à 5.
Tu t'énerves beaucoup, donc c'est durde savoir de quoi tu parles exactement, mais quand je lit ca:
Je me demande bien de quoi tu parles. Si tu parles du GC java, tu viens d'écrire une gigantesque connerie. Si tu parles de n'importe quel GC mark and sweep en fait, tu viens d'écrire une monumentale connerie (et j'espère bien que plus personne n'écrit de GC a retain count).
Si ta variable est locale et que tu ne t'en sert plus jusqu'a la fin de ton scope et que le JIT ne l'a pas deja optimised out (ca commence a faire pas mal de et la quand meme), certes, tu vas permettre a une potentielle passe du GC de la trouver avant la fin du scope.
Si tant est que le GC fait sa pause entre le moment ou tu penses avoir assigne ta variable a NULL et le moment ou le scope se serait fini et ou ton pointeur devient garbageable.
Oui, je dit "pense avoir assigne ta variable", parce que tu n'es pas sans savoir que le compile peut decider que c'est une idée a la con d'assigner NULL a une variable locale et virer l'instruction (et entre nous, c'est difficile de lui en vouloir de penser ca).
Si ta variable n'est pas locale, i.e. un membre vu que c'est un peu le seul moyen d'avoir une variable non locale en java, ben soit tu viens de fixer une leak gentillette (= vaguement equivalent a un malloc non balance par un free en c), en d'autre termes, un bug, soit tu viens de modifier le comportement de ton programme (i.e tu viens de créer un bug).
Bref, t'avoueras qu'au final le gain est maigre et vraiment hypothétique.
Sinon je veux bien que tu m'expliques en quoi le GC java va skipper les structures récursives ou profondément linkees (et surtout j'aimerais bien savoir ce qu'est une structure profondément linkee), sachant qu'il fonctionne surtout par generation, et qu'il va donc parcourir toute la heap appartenant a une generation.
Ensuite, le "on the fly progressif", comme tu dit, ca ne garantit pas de tout libérer, effectivement, et ca tombe bien, c'est le but. Le fait est que les jeunes generations meurent très jeunes et les vieilles ne meurent souvent jamais. En gros, des gens plus malin que toi se sont rendus compte que l'immense majorité des objets meurent soit très très vite, soit jamais.
Donc effectivement, tu ne libères pas tout en faisant une passe sur ta jeune generation, tu libères quasiment tout, et c'est bien le but.
Oui, parce qu'évidemment, gérer une heap de 8+GB avec du c++, c'est trivial, hein? D'ailleurs, FF n'a jamais eu de problèmes de fragmentation de heap qui gonflait en permanence son occupation mémoire, c'est bien connu!