Molti demoni di Gnome 3.28 utilizzano oltre 100 GB di VIRT. Perché?

Di recente ho aggiornato questo laptop a Fedora 28 Beta e con esso Gnome 3.28. Le cose sono per lo più buone.

Ma alcune cose sono strane. Ciò non sta causando problemi perché si tratta di tutta la memoria virtuale.

Ma perché questi demoni stanno allocando oltre 100 GB di memoria virtuale?

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

Tutti questi demoni usano WebKit (principalmente per mostrare i prompt di login di oauth2) e WebKit ha recentemente introdotto gigacages per isolare l'heap utilizzato dalla loro implementazione JS. L'allocazione per un gigacage è abbastanza grande che qualsiasi accesso a un offset arbitrario a 32 bit senza segno sarebbe comunque atterrato nel gigacage, risultando in queste enormi allocazioni. Vedi questo post del blog per maggiori dettagli sui gigacages: https://labs.mwrinfosecurity.com/blog/some-brief-notes-on-webkit-heap-hardening/