一部のアプリケーションでメモリリークが発生している兆候kernel_taskは、メモリフットプリントが大きく、一般にギガバイトのオーダーであるということです。異常kextがこのメモリ使用量を引き起こしている場合、割り当てられたメモリと割り当てられると予想されるメモリとの間に矛盾があることが予想されます。

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

「Wired」および「Name」という単語以外の何かを返します。

論文を書いている間、プレビューで開いているPDFを変更すると、しばしば悪いことが起こることに気づきました：時折、メモリ使用量がkernel_task約8ギガバイト以上になることがあります。プレビューを強制終了すると、すぐに通常の状態に戻ります。したがって、明らかに何かが間違っています-そして、プレビューはこれらの条件下でメモリをリークしています。

だから、私の質問は次のとおりです：のフットプリントの突然の予期しない増加を介してプロセスがラムをリークしたことを知っている場合kernel_task、なぜOS Xは何かが間違っていることを知ることができません。プレビューを削除すると、失われたmalloc()「d」メモリが復元される場合、ダーウィンがガーベッジコレクションを自動的に行わないのはなぜですか？

メモリ管理の仕組みについて根本的な誤解はありますか？

編集：（15/9/15）

これが私が話していることのデモンストレーションです。まず、メモリ使用量が高いことに気付きますkernel_task（プレビューは開いており、アクティビティモニターの下部に表示されます。333MiBのRAMを使用しています）。

以下のアシュリーによる有益な発言に続いて、各kextの使用量を調べてみましょう。

$ 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
$

だから、大量ではありません。私のマシンにはディスクリートGPUと統合GPUの両方があります。彼らのドライバーは、わずか数MiBの有線RAMを使用しています。私の考えでは、プレビューを終了して、のメモリフットプリントがどうなるか見てみましょうkernel_task。

プレビューはなくなり、カーネルのメモリフットプリントは劇的に低下しました。kextの使用法に変更の証拠はまだありません。上記のコマンドの出力は変更されていません。

編集：No。22701036として報告されたバグ。私はまだアップルからの応答を待っています。ActivityMonitorでプロセスを検査する場合、特に興味深いことはありませんが、何かが足りない可能性があります。

OS Xのコアはガベージコレクションではありません。IOKitのlibkern C ++ランタイムでは、開発者が独自のメモリを管理する必要があります。

Macメモリ管理

どのようにMac OS Xのメモリ管理の仕事をしますか？

Appleは、開発者向けドキュメントの一部として、Mach Kernelの最低レベルと仮想メモリサブシステムをWeb上でかなり適切に文書化しています。

• カーネルプログラミングガイド：メモリと仮想メモリ

そのカーネルはカーネギーメロン大学によって開発されたので、それを説明する何十もの論文を非常に簡単に見つけることができます。

その他のソース

• ウィキペディアでは、Mac OSのメモリ管理について説明しています。

• Appleのサポートノート：アクティビティモニターを使用してシステムメモリを読み取り、使用されているRAMの量を判断します

ガベージコレクション

ガベージコレクションは、ユーザーまたはアプリケーション層に存在します。この層でも、ガベージコレクションは、アプリケーションがメモリに対するすべての要求を解放した場合にのみ役立ちます。循環依存は、ガベージコレクションを無効にする可能性があります。ガベージコレクション自体は研究の進化しているエリアであり、正しくなるのは難しいです。

バグとメモリリークを報告する

OS X内のバグによりメモリがリークします。コードベースのサイズを考えると、これはほぼ確実です。

再現可能なバグをAppleに直接報告してください。すべてのバグレポートが役立ち、おそらくあなたの例が、Appleのエンジニアが原因を突き止めるのに役立つものになるでしょう。

Macに統合GPU（Intel Iris Graphicsなど）が搭載されていると仮定すると、これは私の推測です。

プレビューで論文を開くと、グラフィックカードのメモリを使用して、プレビューウィンドウの画像（「テクスチャ」）を保持します。

統合グラフィックカードでは、ビデオメモリは実際には（部分的に？）システムRAMに配置され、CPUとGPUの間で共有されます。一部の統合グラフィックスカードでは、使用されるシステムRAMの量が動的に割り当てられます（Apple HT204349を参照）。

グラフィックカードドライバーやプレビューに断続的にバグが表示されていると思いますが、プレビューで論文PDFを再読み込みするとシステムメモリが正しく解放されません。（ただし、このバグはOS Xによって軽減されます。プレビューが終了すると、ドライバーがメモリを正しく解放します。）

問題の発生時に列kextstatの数値がSize増加するかどうかの出力を調べてみてください。私の理論では、あなたが言及した8GBの増加はグラフィックスカードドライバーによるものだということです。

次のコマンド（この関連する興味深い回答に対するコメントから）は、出力を並べ替えて、kextstatどのkextが最もメモリを使用しているかを簡単に確認できるようにします（ただし、この並べ替えはWired列で並べ替えられています...これには、同様の単純な呪文があります）これを微調整したい場合は、説明で答えてください）。

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