Je n'ai pas dit que ça doit résoudre tous les problèmes. Mais je pense qu'il n'y a pas d'incompatibilité en général entre l'utilisation d'un Garbage Collector et l'embarqué. Il faut juste un GC qui convient. Celui d'Erlang qui convient dans pas mal de cas. Azul est une autre solution.
Sauf que tous les workloads ne sont pas partitionables
Les workloads qui ne sont pas partitionnables, ça reste une cas très spécifique.
Un autre argument contre les garbage collectors donne par Linus est la perte de localite de reference: lorsque le GC decide de faire une collection, tu te retrouves avec un cache pollue par les objets collectes.
Je ne vois pas trop ce que cet argument vient faire ici. Oui, la fragmentation de la mémoire est un problème, pour les GC comme pour la gestion de la mémoire manuelle. En l'occurrence, l'utilisation de fibres/goroutines/processus Erlang aide justement pas mal.
D'une part, quand un processus Erlang finit, sa stack et sa heap sont entièrement supprimées. Et c'est de cette façon qu'une bonne partie de la mémoire est libérée. D'autre part, le GC est générationnel : il recopie les objets récents encore utilisés de l'espace réservé aux objets nouvellement créés vers un autre espace. Ainsi, il y a peu de "trous" et on évite une partie de la fragmentation de la mémoire.
[^] # Re: Destructeurs
Posté par Bruno Michel (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 4.
Je n'ai pas dit que ça doit résoudre tous les problèmes. Mais je pense qu'il n'y a pas d'incompatibilité en général entre l'utilisation d'un Garbage Collector et l'embarqué. Il faut juste un GC qui convient. Celui d'Erlang qui convient dans pas mal de cas. Azul est une autre solution.
Les workloads qui ne sont pas partitionnables, ça reste une cas très spécifique.
Je ne vois pas trop ce que cet argument vient faire ici. Oui, la fragmentation de la mémoire est un problème, pour les GC comme pour la gestion de la mémoire manuelle. En l'occurrence, l'utilisation de fibres/goroutines/processus Erlang aide justement pas mal.
D'une part, quand un processus Erlang finit, sa stack et sa heap sont entièrement supprimées. Et c'est de cette façon qu'une bonne partie de la mémoire est libérée. D'autre part, le GC est générationnel : il recopie les objets récents encore utilisés de l'espace réservé aux objets nouvellement créés vers un autre espace. Ainsi, il y a peu de "trous" et on évite une partie de la fragmentation de la mémoire.