Android PF have kill alive process when heigher priority process need heap.
This report explain that produce Low Memory Killer situation on purpose
You think it so simple. just to make application to consume many heap.
but, it difficult that your thinking way.
following problem
- A. Android PF restrict application java heap per one process.
- B. heap comsuming application is killed by Android PF.
This report introduce KyoroStress 's solution.
[KyoroStress solution]
Kyoro Stress done following approach.
- 1. Booting many service in the process of differing respectively.
- 2. Each Service consumes a lot of heaps.
The problem of A is solved by booting many process, and B too,
alive heap is more consume instead of kill service's heap
[BigEater(consuming heap service) 's senario]
- 1. consume the specified heap.
if retry is true, then consuming heap is repeated repeatedly until the specified heap is consumed
- 2. recovery killed service
if retry is true, then repeated repeatedly until killing this working thread.
- 3. END
you think. if ALL Service is killed by PF, when this senario is failed.
but no problem. PF revcovery Killed service.
so, keeping to consuming heap situation.
[KyoroStressV2 's manual]
# start
start consuming heap.
# stop
stop consuming heap. and release.
# num of big eater
booting process num.
# eatup java heap size
consuming heap size per one process.
# is retry
retry option
# show notification
if true, consume notification.
# lowMoemory
if true, mean low memory state
# availMemory
available memory,
# threshold
boundary low memory state.
# dalvik.vm.heapsize
if android:largeHeap="true" 's application available heap size.
# dalvik.vm.heapgrowthlimit
if android:largeHeap="false" 's application available heap size.
# lahalito
now consuming java heap
# kadorto
now recovery another killed process.
# done all task
all task is end.
[Output]
There is apk and source is following site
https://github.com/kyorohiro/KyoroStressV2
Google Play address is following
https://play.google.com/store/apps/details?id=info.kyorohiro.helloworld.stressv2
2013年2月20日水曜日
Inside KyoroStress -1- Create Low Memory Killer situation on purpose!!
2013年2月17日日曜日
KyoroStressの技術 -1- Low Memory Killer を意図的に発生させたい
[課題] Low Memory Killer を意図的に発生させたい
Androidには、ヒープが涸渇すると使われていないアプリをKillする機能があります。
この記事では、意図的にヒープを枯渇させて、この状態をつくる方法について説明します。
単純にヒープを大量に消費するアプリを作成すれば良いように思えます。
しかし、これだけでは上手くいきません。
-A ひとつのアプリで消費できるヒープが制限されているため、ひとつのアプリで端末のヒープが涸渇している状態をつくれない。
-B ヒープを涸渇しているアプリがPFにKILLされる場合がある。
といった問題があります。
KyoroStressV2での解決方法を紹介します。
[KyoroStressでの解決方法]
Kyoro Stress では、以下のような方法をとりました。
- 1. 複数のServiceを、各々異なるプロセスで起動する。
- 2. 各々Serviceで大量のヒープを消費する。
複数のプロセスを立ち上げれば、PFのヒープを枯渇させることができます。これで、(A)の問題が解決できました。
また、Bについては、「生きているプロセス」が「KILLされたプロセス」の分もヒープを消費すれば上手くいけそうです。
[BigEater(ヒープ消費サービス)の動作]
KyoroStressV2で、ヒープを消費するサービスは以下のシナリオで動作しています。
- 1. 指定されたヒープを取得する。
is retry が true の時、指定されたヒープを取得できるまで、1を何度も繰り返す。
- 2. KILLされたサービスを復活させる。
is retry が true の時、Threadが死ぬまで、何度も2を繰り返す。
- 3. 終了
といった感じです。
このままでは、すべてのServiceがPFにKILLされたら上手くいかないように思うかも知れません。
しかし、時間がたつと(数秒)、PFはKILLしたServiceを再起動します。
このため、ServiceがすべてKILLされても、ヒープを大量に消費しようとする状態は保持されます。
[使い方]
KyoroStressV2の操作方法について説明します。
# start
ヒープの消費を開始します。
ヒープの消費率監視を開始する。
# stop
ヒープの消費を終了する。そして、開放する。
# num of big eater
起動するプロセスの数
# eatup java heap size
ひとつのプロセスが消費するヒープサイズ
# is retry
オンならば、ヒープを確保できるまで、何度もトライする。
# show notification
オンならば、Notificaiotn表示をする。
# lowMoemory
true ならば、 ロウメモリー状態
# availMemory
使用可能なメモリ
# threshold
この値よりも低い場合は、ロウメモリー状態
# dalvik.vm.heapsize
ひとつのプロセスがandroid:largeHeap="true"の時に使用可能なJavaヒープ
# dalvik.vm.heapgrowthlimit
android:largeHeap="false"の時に使用可能なJavaヒープ
# lahalito
指定されたヒープを取得しにいっている状態
# kadorto
PFのKILLされたサービスを再起動させようとしている状態
# done all task
Serviceはすべての作業を完了した。そのため、もう何もすることはない状態
[成果物]
以下の場所にソースとAPKがあります。
https://github.com/kyorohiro/KyoroStressV2
Google Playでも公開しています。
https://play.google.com/store/apps/details?id=info.kyorohiro.helloworld.stressv2
[次回]
より、詳細な仕組みは別の記事で解説します。
- Serviceごとに、別プロセスにする方法は?
- アプリが使用可能なヒープを調べる方法は?
- Low Memory 状態を取得する方法は?
- 制限を越えてヒープを取得する方法?
-------
kyorohiro work
kyorohiro.strikingly.com
登録:
投稿 (Atom)
Game Boy の VGM から JavaScript への変換後に、 生成AIの補正が有効だった事について
Game Boy の VGM から JavaScript への変換後に、 生成AIの補正が有効だった事について Tetorica FM2612 Playground には GameBoy や Genesis の VGM ファイル から JavaScript へ変換する機能を持って...
-
[課題] Low Memory Killer を意図的に発生させたい Androidには、ヒープが涸渇すると使われていないアプリをKillする機能があります。 この記事では、意図的にヒープを枯渇させて、この状態をつくる方法について説明します。 単純にヒープを大...
-
Emscripten と OpenGLを使ってゲームを作ろうと思いたって、 まずは、SDL2の基本的な使い方を試していた。 しかし、今の所は、SDL 1系 の方が、良いと思いました。 SDL2があるのに、SDL1 を選ぶのはなぜか? # 201...
-
Dart の Native Extensions を利用して、 SDL を用いたマルチプラットフォームのゲーム開発環境を作れるか検証してみた。 結論からいくと、 「Mac 上で動作する SDL x Dart の アプリは動作させることが難しいよ」 と言うことです。 Wind...