On m'a dit précédemment que certaines applications présentaient une fuite de mémoire, à savoir kernel_taskune empreinte mémoire importante, généralement de l'ordre du gigaoctet. Si un problème apparaissait kextcausait cette utilisation de la mémoire, nous nous attendrions à voir une différence entre la mémoire allouée et celles qui devraient être allouées, c'est-à-dire

diff <(kextstat|tr -s ' ' | cut -d ' ' -f 5) <(kextstat| tr -s ' ' | cut -d ' ' -f 6) 

renverrait autre chose que les mots "Wired" et "Name".

Lors de la rédaction de ma thèse, j’ai constaté que le fait de modifier un fichier PDF pendant qu’il est ouvert dans Preview entraînait souvent de graves problèmes: parfois, l’utilisation de la mémoire kernel_taskpeut atteindre environ huit gigaoctets, voire davantage. Si je tue l'aperçu, il revient instantanément à la normale . Il est donc évident que quelque chose ne va pas - et Preview perd de la mémoire dans ces conditions.

Ma question est donc la suivante: si je sais qu’un processus a perdu de sa vigueur grâce à une augmentation soudaine et inattendue de l’empreinte de kernel_task, pourquoi OS X ne peut-il pas savoir que quelque chose ne va pas. Si kill Preview restaure ma malloc()mémoire manquante , pourquoi Darwin ne collecte- t- il pas automatiquement les ordures pour moi?

Ai-je un malentendu fondamental sur le fonctionnement de la gestion de la mémoire?

EDIT: (15/9/15)

Voici une démonstration de ce dont je parle. Tout d’abord, je remarque une utilisation importante de la mémoire par kernel_task(remarque, l’aperçu est ouvert, mais visible au bas de Activity Monitor, avec 333 Mio de RAM):

Après les remarques utiles de Ashley ci-dessous, voyons combien chaque kext utilise:

$ kextstat | awk 'NR==1{ printf "%10s %s\n", $5, $6; } NR!=1{ printf "%10d %s\n", $5, $6; }' | sort -n

...
...
...
   1249280 com.apple.driver.DspFuncLib
   1769472 com.apple.nvidia.driver.NVDAGK100Hal
   2629632 com.apple.nvidia.driver.NVDAResman
   6184960 com.apple.driver.AirPort.Brcm4360
$

Donc pas beaucoup. Ma machine a des GPU discrets et intégrés. leurs conducteurs utilisent seulement quelques Mo de RAM câblé. Sur mon intuition, éliminons Preview et voyons ce qu'il advient de l'empreinte mémoire de kernel_task:

La prévisualisation a disparu et l'encombrement mémoire du noyau a considérablement diminué. Il n'y a toujours aucune preuve d'un changement dans l'utilisation de kext: le résultat de la commande ci-dessus reste inchangé.

Edit : Bug signalé sous le N ° 22701036. J'attends toujours une réponse d'Apple. Il n'y a rien de particulièrement intéressant si vous inspectez le processus dans ActivityMonitor, mais il me manque peut-être quelque chose.

Le noyau d’OS X n’est pas récupéré; Le libkern C ++ Runtime d'IOKit exige des développeurs qu'ils gèrent leur propre mémoire.

Gestion de la mémoire Mac

De Comment fonctionne la gestion de la mémoire sous Mac OS X?

Apple documente assez bien les niveaux les plus bas du noyau Mach et du sous-système de mémoire virtuelle sur le Web, en tant que partie de la documentation destinée aux développeurs.

• Guide de programmation du noyau: mémoire et mémoire virtuelle

Depuis que ce noyau a été développé par l'Université Carnegie Mellon , vous pouvez trouver des dizaines d' articles le décrivant assez facilement.

Autres sources

• Wikipedia aborde la gestion de la mémoire Mac OS .

• Note d'assistance d'Apple: Utilisez Activity Monitor pour lire la mémoire système et déterminer la quantité de RAM utilisée

Collecte des ordures

La récupération de place existe au niveau de l'utilisateur ou de l'application. Même au niveau de cette couche, la récupération de place n'aide que si l'application a libéré toutes les revendications dans la mémoire. Une dépendance circulaire peut vaincre la récupération de place. La collecte des ordures ménagères est en soi un domaine de recherche en pleine évolution et difficile à maîtriser .

Signaler des bugs et des fuites de mémoire

Les bogues dans OS X perdront de la mémoire. Compte tenu de la taille de la base de code, c'est presque certain.

Veuillez signaler les bogues reproductibles directement à Apple . Chaque rapport de bogue aide et peut-être que votre exemple sera celui qui aide les ingénieurs d’Apple à cerner la cause.

Voici ma supposition, en supposant que votre Mac possède un GPU intégré (par exemple, Intel Iris Graphics).

Lorsque vous avez ouvert votre thèse dans Aperçu, la mémoire de la carte graphique est utilisée pour contenir l’image ("texture") de la fenêtre d’aperçu, et peut-être aussi des pages de la thèse hors écran mais décodées.

Avec une carte graphique intégrée, la mémoire vidéo est en fait (partiellement?) Située dans la mémoire vive du système, qui est partagée entre le processeur et le processeur graphique. Sur certaines cartes graphiques intégrées, la quantité de RAM système utilisée est allouée de manière dynamique (voir Apple HT204349 ).

J'imagine que vous remarquez par intermittence un bogue dans le pilote de carte graphique et / ou dans Preview, qui ne libère pas correctement la mémoire système lorsque Preview recharge le PDF de votre thèse. (Cependant, ce bogue est atténué par OS X / le pilote libérant correctement la mémoire lorsque la prévisualisation se ferme.)

Vous pouvez essayer de regarder le résultat de kextstatet voir si les chiffres dans la Sizecolonne augmentent lorsque vous rencontrez le problème. Ma théorie est que l'augmentation de 8 Go dont vous avez parlé sera due au pilote de la carte graphique.

La commande suivante (à partir d'un commentaire sur cette réponse intéressante et liée ) trie la sortie de kextstatafin de voir plus facilement quel kext utilise le plus de mémoire (bien que notez ceci trie par Wiredcolonne ... il y a une incantation similaire, plus simple, dans cette répondez avec une explication si vous souhaitez modifier cela).

kextstat | awk 'NR==1{ printf "%10s %s\n", $5, $6; } NR!=1{ printf "%10d %s\n", $5, $6; }' | sort -n