Merci Victor pour les précisions. J'ai écrit la partie Python de mémoire ayant suivit vos échanges il y a longtemps et mes connaissances du câblage interne de Python sont beaucoup plus approximatives.
Pour la partie surconsommation mémoire des AVL, la technique d'OpenJDK semble réussir à contourner le problème en ne faisant la conversion que quand c'est nécessaire et sans pouvoir introduire de régression de perf sur le cas nominal. Ils n'ont pas réussi a y arriver avec toutes les structures de données reposant sur un hash cependant.
Perso, je garde un goût amer de toutes ces discussions sur les fonctions de hash. Pour moi, c'est bidon. Je trouve les attaques algorithmes très compliquées, comparativement à la facilité d'un DoS classique
Je partage en parti ton avis, et je trouve l'histoire engineering beaucoup plus intéressante que l'histoire sécurité. On pourrait aussi dire que vu que les services web sont les plus exposés à ça, il pourrait leur revenir de gérer la chose plutôt que de le gérer dans les collections. C'était d'ailleurs la réponse initiale d'Oracle qui avait répondu "Won't fix". Au final ils ont décider d'essayer de fermer la porte à ce genre de choses dans les collections de base.
Mais en dehors du DoS bête et méchant, ça me semble intéressant de réduire la complexité au pire cas et mieux supporter les collisions. Ce qui est en soit une bonne chose si c'est faisable avec une implémentation raisonnable.
[^] # Re: Python
Posté par ckyl . En réponse à la dépêche OpenJDK JEP 180: HashMap, collisions & attaques par la complexité. Évalué à 8. Dernière modification le 07 mai 2014 à 00:04.
Merci Victor pour les précisions. J'ai écrit la partie Python de mémoire ayant suivit vos échanges il y a longtemps et mes connaissances du câblage interne de Python sont beaucoup plus approximatives.
Pour la partie surconsommation mémoire des AVL, la technique d'OpenJDK semble réussir à contourner le problème en ne faisant la conversion que quand c'est nécessaire et sans pouvoir introduire de régression de perf sur le cas nominal. Ils n'ont pas réussi a y arriver avec toutes les structures de données reposant sur un hash cependant.
Je partage en parti ton avis, et je trouve l'histoire engineering beaucoup plus intéressante que l'histoire sécurité. On pourrait aussi dire que vu que les services web sont les plus exposés à ça, il pourrait leur revenir de gérer la chose plutôt que de le gérer dans les collections. C'était d'ailleurs la réponse initiale d'Oracle qui avait répondu "Won't fix". Au final ils ont décider d'essayer de fermer la porte à ce genre de choses dans les collections de base.
Mais en dehors du DoS bête et méchant, ça me semble intéressant de réduire la complexité au pire cas et mieux supporter les collisions. Ce qui est en soit une bonne chose si c'est faisable avec une implémentation raisonnable.