Je crois que j'ai dit une connerie là, tu parlais de contraintes sur la mémoire, pas sur le temps.
Pour les contraintes sur la mémoire, un mark-and-sweep de base consome peu.
Le comptage de référence est une fausse-bonne idée (un antipattern ? :-) ) car il faut lui ajouter un détecteur de cylces qui est souvent (tout le temps, flemme de réfléchir) un marqueur, donc autant tout faire avec le marqueur. On peut prévoir le marquage dans les objets, ainsi, on alloue pas de table de marquage.
PocketSmalltalk, pour pas se faire chier, utilise une table d'objets et un mark-and-compact brutal, en changant le pointeur dans la table d'objets après le déplacement de l'objet. Un ami m'a dit que'un simple Baker (mémoire coupée en 2) avec pointeurs directs prenait moins de place (car la table des objets bouffe une tonne de mémoire) mais j'ai pas testé.
[^] # Re: GC temps-réel
Posté par Dugland Bob . En réponse à la dépêche SmallEiffel devient SmartEiffel. Évalué à 1.
Pour les contraintes sur la mémoire, un mark-and-sweep de base consome peu.
Le comptage de référence est une fausse-bonne idée (un antipattern ? :-) ) car il faut lui ajouter un détecteur de cylces qui est souvent (tout le temps, flemme de réfléchir) un marqueur, donc autant tout faire avec le marqueur. On peut prévoir le marquage dans les objets, ainsi, on alloue pas de table de marquage.
PocketSmalltalk, pour pas se faire chier, utilise une table d'objets et un mark-and-compact brutal, en changant le pointeur dans la table d'objets après le déplacement de l'objet. Un ami m'a dit que'un simple Baker (mémoire coupée en 2) avec pointeurs directs prenait moins de place (car la table des objets bouffe une tonne de mémoire) mais j'ai pas testé.