Viele Gnome 3.28-Daemons verwenden über 100 GB VIRT. Warum?

Ich habe diesen Laptop kürzlich auf Fedora 28 Beta und damit Gnome 3.28 aktualisiert. Die Dinge sind meistens gut.

Aber manche Dinge sind komisch. Dies verursacht keine Probleme, da dies der gesamte virtuelle Speicher ist.

Aber warum weisen diese Dämonen mehr als 100 GB virtuellen Speicher zu?

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

Alle diese Daemons verwenden WebKit (hauptsächlich, um oauth2-Anmeldeaufforderungen anzuzeigen), und WebKit hat kürzlich Gigacages eingeführt, um den von ihrer JS-Implementierung verwendeten Heap zu isolieren. Die Zuweisung für einen Gigacage ist groß genug, damit jeder Zugriff auf einen beliebigen vorzeichenlosen 32-Bit-Offset immer noch im Gigacage landet, was zu diesen enormen Zuweisungen führt. Weitere Informationen zu Gigacages finden Sie in diesem Blog-Beitrag: https://labs.mwrinfosecurity.com/blog/some-brief-notes-on-webkit-heap-hardening/