De nombreux démons Gnome 3.28 utilisent plus de 100 Go de VIRT. Pourquoi?

J'ai récemment mis à jour cet ordinateur portable vers Fedora 28 Beta et avec lui Gnome 3.28. Les choses sont généralement bonnes.

Mais certaines choses sont étranges. Cela ne pose pas de problème car il s'agit uniquement de mémoire virtuelle.

Mais pourquoi ces démons allouent-ils plus de 100 Go de mémoire virtuelle?

0  1000  2012  1719  20   0 101649024 32904 SyS_po Sl ?         0:00 /usr/libexec/goa-daemon
0  1000  1983  1719  20   0 101704260 46416 SyS_po Sl ?         0:00 /usr/libexec/gnome-shell-calendar-server
0  1000  2210  1765  20   0 101736292 33656 SyS_po Sl+ tty2     0:00 /usr/libexec/deja-dup/deja-dup-monitor
0  1000  2452  1719  20   0 101927808 45988 SyS_po Ssl ?        0:00 /usr/libexec/evolution-addressbook-factory
0  1000  2240  1765  20   0 102007840 57328 SyS_po Sl+ tty2     0:00 /usr/libexec/evolution/evolution-alarm-notify
0  1000  2415  2288  20   0 102356528 47216 SyS_po Sl ?         0:00 /usr/libexec/evolution-calendar-factory-subprocess --factory all --bus-name org.gnome.evolution.dataserver.Subprocess.Backend.Calendarx2288x2 --own-path /org/gnome/evolution/dataserver/Subprocess/Backend/Calendar/2288/2
0  1000  2021  1719  20   0 102405692 46532 SyS_po Ssl ?        0:00 /usr/libexec/evolution-source-registry
0  1000  2288  1719  20   0 118711416 46164 SyS_po Ssl ?        0:00 /usr/libexec/evolution-calendar-factory
0  1000  2518  2452  20   0 119163652 49648 SyS_po Sl ?         0:00 /usr/libexec/evolution-addressbook-factory-subprocess --factory all --bus-name org.gnome.evolution.dataserver.Subprocess.Backend.AddressBookx2452x2 --own-path /org/gnome/evolution/dataserver/Subprocess/Backend/AddressBook/2452/2

Tous ces démons utilisent WebKit (principalement pour afficher les invites de connexion oauth2), et WebKit a récemment introduit des gigacages pour isoler le tas utilisé par leur implémentation JS. L'allocation pour un gigacage est suffisamment importante pour que tout accès à un décalage 32 bits arbitraire non signé atterrisse toujours dans le gigacage, ce qui entraîne ces énormes allocations. Voir cet article de blog pour plus de détails sur les gigacages: https://labs.mwrinfosecurity.com/blog/some-brief-notes-on-webkit-heap-hardening/