深夜のAndroidメモリ管理TL

ひょろも @hyoromo

あれ、ヒープサイズの出し方あってるのかな。何で2枚合計サイズが増えてるのに2.2端末だと使用ヒープサイズが減ったんだろう。

ひょろも @hyoromo

@youten_redo JavaVM上でなるの？

ようてん @youten_redo

@hyoromo なるよー。GCしてもCompaction（デフラグ）ないらしいから空き容量とOOMの因果はとってもおっかけにくい。

mhidaka@技術書典 @mhidaka

JavaVMが初期値2MBで立ち上がる、そのあと足りなくなったら都度メモリ確保するけどその際にLinux管理部分が断片化してる、はあり得るかも。

ひょろも @hyoromo

@youten_redo あうあうあー

mhidaka@技術書典 @mhidaka

む。自分のためにまとめておこう。

ひょろも @hyoromo

ヒツジ神たま！

mhidaka@技術書典 @mhidaka

JavaVMはGCあり。Compactionは未実装、初期ヒープ2MB、最大24MB(標準)まで拡張される。たしかmmapで確保

ようてん @youten_redo

@mhidaka linux管理側のプロセスヒープはLowMemoryKillerにひっかかりやすくなるだけちゃいますかねー。OOMにはならん気がします。

こんそめ @consomme72

でかい画像読み込んだ後は強制的にSystem.gcしてるけど邪道なのかしら…

ひょろも @hyoromo

bitmapデータ作成 → recycleしてnull → またbitmapデータ作成 を合計2MBの画像データでやってるとOOMになってりするのは何でだろう。これも断片化とかなのかしら。

mhidaka@技術書典 @mhidaka

空きHeap自体はOS管理。取れない時点でOOMKillerが発動。動作中にメモリ不足な雰囲気が出てきたらActivityManagerあたりがLowMemoryKiller発動。

mhidaka@技術書典 @mhidaka

@youten_redo linux管理側のプロセスヒープも結局mmapで確保してるだけなので、断片化してしまうとVMHeapを拡張するタイミングでOOMじゃないでしょーか？

mhidaka@技術書典 @mhidaka

メモリ管理ェ…

ようてん @youten_redo

@mhidaka あれ、ヒープ拡張ってmmapなんですね…最初に24M vmallocとかする…？

mhidaka@技術書典 @mhidaka

GDDでクリスと話したときはVMHeap？24MBまで使い切れるよ、うん。ってすんなり言われて驚いた記憶あるからなんかテクニックあるはず。

mhidaka@技術書典 @mhidaka

@youten_redo Dalvikさんは最初に2MBだけ確保してたとおもいます。足りないタイミングで都度確保かと。vmallocだったかは記憶にないれす…。

ARIYAMA Keiji @keiji_ariyama

@mhidaka 最初から２４MB使って、後は自分で管理とかだよ。きっと。。。！

Takao Sumitomo @cattaka_net

業務系で24時間動作するアプリとか作ったらネックになりそうだなぁ RT @mhidaka JavaVMはGCあり。Compactionは未実装、初期ヒープ2MB、最大24MB(標準)まで拡張される。たしかmmapで確保

ひょろも @hyoromo

ループさせてみようかなあ

ARIYAMA Keiji @keiji_ariyama

@mhidaka kMinHeapStartSize (1*1024*1024) これかな。 kMinHeapSize (2*1024*1024)となにがちがうんだろ

ひょろも @hyoromo

100回くらいbitmap生成→解放を繰り返してみたけど変動はほとんど無いな。俺の組み方が悪いのか...

mhidaka@技術書典 @mhidaka

メモリ確保はdlmallocまかせっぽいな。

mhidaka@技術書典 @mhidaka

同じ動作の繰り返しで変動が少ないのは下回りが旨く作られてる証拠みたいです。

mhidaka@技術書典 @mhidaka

dlmallocってBSD出身だっけ。