Le ramasse-miette suffit dans beaucoup de cas, mais il apporte d'autres problemes tels que: avec un ramasse miette "stop-the-world", il est impossible de faire du temps reel ou de garantir un temps de reponse.
Et c'est un probleme qui grossit avec la taille de la memoire. Java a ces ennuis. Le ramasse-miette G1 etait sense apporter des solutions a ces problemes, mais ces promesses tardent a se materialiser. Plus recemment, j'ai vu la JVM Azul qui permet un passage a l'echelle du ramasse miette sur plusieus dizaines voire centaines de Go de memoire. Le mecanisme utilise (invalidation de pages memoire et mise a jour des references lors d'acces memoire vers les page invalidees) etant un brin avant gardiste, linux ne sais pas bien le gerer et ils ont cree un patch noyau hyper invasif qui ne sera jamais integre upstream tel quel. Il y a bien sur un gros surcout memoire pour cette fonctionnalite.
Le probleme du ramasse-miette dans Java et lie au fait que n'importe quel thread puisse voir absolumment toute la memoire du processus. Comme indique dans la depeche, Rust contourne ce probleme en:
1- fournissant et encourageant l'utilisation par defaut d'autres mecanisme de gestion de la memoire que le seul ramasse-miette
2- faisant en sorte que chaque thread ne puisse voir qu'une portion de la memoire qui lui est dediee, et pas celle des autres threads. D'ou l'absence du "stop-the-world". J'imagine qu'un cas pathologique pourrait etre equivalent a un stop the world (programme mono thread, uniquement code avec le ramasse-miette), mais je pense que les mecanismes mis en place devraient empecher pas mal de programmes d'en arriver la.
[^] # Re: De la complexité de la gestion de la mémoire et d'autres
Posté par djano . En réponse à la dépêche Présentation de Rust 0.8. Évalué à 4.
Le ramasse-miette suffit dans beaucoup de cas, mais il apporte d'autres problemes tels que: avec un ramasse miette "stop-the-world", il est impossible de faire du temps reel ou de garantir un temps de reponse.
Et c'est un probleme qui grossit avec la taille de la memoire. Java a ces ennuis. Le ramasse-miette G1 etait sense apporter des solutions a ces problemes, mais ces promesses tardent a se materialiser. Plus recemment, j'ai vu la JVM Azul qui permet un passage a l'echelle du ramasse miette sur plusieus dizaines voire centaines de Go de memoire. Le mecanisme utilise (invalidation de pages memoire et mise a jour des references lors d'acces memoire vers les page invalidees) etant un brin avant gardiste, linux ne sais pas bien le gerer et ils ont cree un patch noyau hyper invasif qui ne sera jamais integre upstream tel quel. Il y a bien sur un gros surcout memoire pour cette fonctionnalite.
Le probleme du ramasse-miette dans Java et lie au fait que n'importe quel thread puisse voir absolumment toute la memoire du processus. Comme indique dans la depeche, Rust contourne ce probleme en:
1- fournissant et encourageant l'utilisation par defaut d'autres mecanisme de gestion de la memoire que le seul ramasse-miette
2- faisant en sorte que chaque thread ne puisse voir qu'une portion de la memoire qui lui est dediee, et pas celle des autres threads. D'ou l'absence du "stop-the-world". J'imagine qu'un cas pathologique pourrait etre equivalent a un stop the world (programme mono thread, uniquement code avec le ramasse-miette), mais je pense que les mecanismes mis en place devraient empecher pas mal de programmes d'en arriver la.