Java est asymptotiquement plus efficace en gestion de la mémoire qu'une désallocation explicite (grace au GC).
Par-contre il bouffe au démarrage (surtout si t'es en JIT).
Tout ce que vous faites en désallocation explicite, le GC peut le faire (en général plus vite que vous) mais lui il sait faire des trucs que vous pouvez pas faire sans utiliser un ref_counter et un détecteur de cycles.
L'avantage du GC c'est qu'il n'utilise que l'infrastructure d'un détecteur de cycles (parcours du graphe et marquage) et pas une série de compteurs.
D'autre part tu peux régler le ratio bouffage de temps/bouffage de mémoire et jouer sur la durée de vie de la mémoire.
Même en temps réel, on commence à pourvoir controler le temps de réponse (avec des systèmes spéciaux).
Il faut vraiment étudier ls GC avant de pouvoir dire qu'on en a pas besoin.
[^] # Re: A quand un OS "INBUGABLE" ?
Posté par Dugland Bob . En réponse à la dépêche Interview de Bjarne Stroustrup. Évalué à 3.
Par-contre il bouffe au démarrage (surtout si t'es en JIT).
Tout ce que vous faites en désallocation explicite, le GC peut le faire (en général plus vite que vous) mais lui il sait faire des trucs que vous pouvez pas faire sans utiliser un ref_counter et un détecteur de cycles.
L'avantage du GC c'est qu'il n'utilise que l'infrastructure d'un détecteur de cycles (parcours du graphe et marquage) et pas une série de compteurs.
D'autre part tu peux régler le ratio bouffage de temps/bouffage de mémoire et jouer sur la durée de vie de la mémoire.
Même en temps réel, on commence à pourvoir controler le temps de réponse (avec des systèmes spéciaux).
Il faut vraiment étudier ls GC avant de pouvoir dire qu'on en a pas besoin.