Le carnet du grincheux

J'utilise Solaris depuis très longtemps. Malgré cette longue pratique, je n'arrive toujours pas à comprendre comment ce système d'exploitation gère sa mémoire. Outre le fait que ce système se mette à utiliser la mémoire virtuelle alors qu'il reste plusieurs gigaoctets de disponibles en mémoire vive, les mécanismes d'allocation et de libération de la mémoire laissent sérieusement à désirer.

Selon les utilisations, j'ai le choix entre la libmalloc, la libmtmalloc, la libumem, la libbsdmalloc et certainement d'autres que j'oublie. Toutes ces implantations de malloc() utilisent l'appel système sbrk() même pour de grands blocs de données. Ce n'est pas grave en tant que tel, mais il ne faut pas oublier que pour d'obscures raisons de compatibilité, sbrk() n'aime pas les arguments négatifs. La conséquence immédiate est que malloc() alloue de la mémoire généralement depuis le tas et que le free() correspondant ne rend pas la mémoire au système d'exploitation en réduisant la taille du tas, mais renvoie cette mémoire à l'application. Pourquoi pas, après tout ? C'est un choix qui en vaut un autre. Le problème est surtout que les allocateurs de Solaris sont des allocateurs first fit et non best fit, officiellement pour des raisons de performance, ce qui revient à dire que ce système de renvoi de la mémoire à l'application est une aberration.

En effet, lors d'allocations et de libérations de blocs de tailles différentes, ce système concourt à une fragmentation excessive de la mémoire et à une explosion de la taille du processus, la mémoire de celui-ci ressemblant plus à un emmenthal qu'à un gruyère (tout le monde devrait savoir que le gruyère est lainé et ne comporte que très peu de trous). Les différents allocateurs du système se comportent différemment, mais aucun ne donne entière satisfaction. La solution est simple, embarquer dans ses programmes un allocateur externe best fit qui sera capable d'utiliser sbrk() avec des arguments signés et surtout mmap() et munmap() pour des blocs de grande taille. Une bibliothèque comme libptmalloc3 répond à ces critères.

J'ai peine à croire que les personnes qui ont spécifié les appels système de Solaris soient de mauvais développeurs. Sachant qu'il y a de plus en plus de Java dans Solaris — je me demande d'ailleurs bien pourquoi — et que la gestion de la mémoire par Java est notoirement scabreuse, comment peuvent-ils laisser ces fonctions de gestion de la mémoire dans l'état actuel ?

Lorsqu'on voit que SunOS 4.1.2 était à l'aise avec 8 Mo de mémoire sur une SS2, que Solaris 2.5 tournait parfaitement avec 32 Mo de mémoire sur une SS20 et qu'il faut aujourd'hui au minimum 512 Mo de mémoire pour booter un Solaris 10, je me demande si les développeurs d'Oracle n'auraient pas par hasard des accointances avec des fabricants de mémoire.