Certes, l'overcommit te facilite la vie en tant que programmeur. Mais il casse une garantie fondamentale : quand j'alloue de la mémoire, je m'attends à ce qu'elle soit accessible sans provoquer d'erreur (sauf cas extrême, genre barrette mémoire défectueuse ou secteur défectueux dans la partition de swap, mais on n'attend pas des programmes qu'ils soient capables de gérer ce genre de choses normalement). Sur un système avec l'overcommit activé, ce n'est pas le cas, et mon programme peut planter par manque de mémoire de manière imprévisible. Du point de vue déterminisme, c'est inacceptable.
Je reste convaincu que ce mécanisme devrait être désactivé par défaut, et activé uniquement si l'application le demande explicitement. Idéalement via deux fonctions différentes : un malloc() classique qui garantit que la mémoire allouée est accessible, et un "malloc_overcommit()" qui est plus laxiste mais n'a pas cette garantie. Après tout, une même application peut avoir besoin des deux types de comportement.
spectras > rien à voir. Le 386 rend possible la mémoire virtuelle (possible en fait dès le 286, mais avec des limitations), mais ça n'implique pas pour autant de faire de l'overcommit, c'est un choix de conception de l'OS. (et 1985, c'était il y a 30 ans
)