Pour quel type d'applications le garbage collector peut-il devenir un problème?

Question

En raison de leur efficacité, la plupart des algorithmes Garbage Collector sont inoffensifs dans beaucoup d'applications. La "collection" d'objets nécessite cependant un faible coût pour analyser la pile et libérer l'objet non référencé du tas.

Je sais qu'une partie de la réponse est "cela dépend". Cependant, je voudrais savoir le type de projets sur lesquels vous avez travaillé, dans tout langage de programmation prenant en charge l'allocation automatique de mémoire de tas, pour lequel le garbage collector n'était pas une option ou est devenu un problème.

Answer 1

J'utilise professionnellement les langues collectées depuis plus de 15 ans (et la programmation depuis 30 ans). Mes projets industriels ont varié d'un logiciel regroupant des données de 8 000 transducteurs à travers un champ pétrolifère à un logiciel de visualisation en temps réel (doux) et de trading d'algo à faible latence. J'ai trouvé que la collecte des ordures était utile dans tous les cas. J'avais des réserves sur la latence de la collecte des ordures dans deux projets majeurs: le logiciel de visualisation (en OCaml) et le logiciel de trading d'algo (en F #). Cependant, mes inquiétudes se sont révélées injustifiées car les solutions collectées pour les déchets présentaient en réalité de meilleures caractéristiques de latence que les solutions non-collectées dans les deux cas. En particulier, la traduction des logiciels de visualisation de C++ en OCaml a amélioré les cas les plus défavorables. Les stalles du code C++ étaient dues à des collections tombées hors de portée et des comptes de référence provoquant des avalanches de destructeurs appelant des destructeurs. Nous avions déployé des efforts considérables pour essayer de résoudre ce problème en écrivant des allocateurs personnalisés qui rendraient la destruction incrémentielle mais jamais réussie. De plus, nous avons constaté que les structures de données purement fonctionnelles présentent souvent d'excellentes caractéristiques de latence et qu'elles sont fondamentalement insolubles sans un garbage collector. Les seules exceptions notables à mes «éboueurs sont bonnes» sont les éboueurs pauvres comme le comptage des références et les éboueurs conservateurs comme GC de Boehm. Je ne les toucherais pas avec un bâton de péniche dans un contexte professionnel.

Answer 2

Je travaille actuellement sur un programme dans Haskell, qui crée un graphe Direct-Acyclic-Graph (DAG) en utilisant 16 fichiers de traces d'une simulation MPSoCs. chaque fichier a plus de 115 Mo et en fait ma solution nécessite de stocker tous ces fichiers dans la mémoire sous forme de liste, afin de construire des DAG,

Je pense que dans cette situation Garbage collector sera un très bon partenaire pour améliorer l'efficacité de mon programme, car en fait j'ai vraiment besoin de stocker ces fichiers en mémoire