« 約411年前のある日 | トップページ | プレゼン資料掲載しました »

2013年11月15日 (金)

メモリ管理の話の続き

先日の記事の最後の部分に書いた、Java VM がネイティブヒープも管理するという話の続き。

Javaからネイティブコードを呼び出すときにはjniという仕組みを使う。

jniでは、呼ばれる側(ネイティブコード側)が、Javaからjniで呼ばれるということを全力で意識したコーディングが必要になる。ただそれは入り口だけで、内部の処理は普通のC++(または、C++から呼べる任意の言語)のライブラリとしてコーディングすればいい。メモリ管理の仕組みも普通のC++と全く同じだ。

Sun (Oracle) のJVM用にjni用ネイティブコードを開発するときには、コンパイラとかCライブラリとかは、特にJavaを意識していない、普通のCコンパイラ、普通のCライブラリを使う。だから、メモリ管理の実装(例えばmallocの内部処理)は、JVMとは無関係なものになる。

でも、Androidの場合は、Android用のC/C++開発環境というのは、AndroidのJVM (Dalvik) から呼び出されるjniネイティブコードを作る専用の環境だ(よね?)だから、そこで提供するCライブラリは、APIは普通のCライブラリと互換でも、内部の処理が普通のCライブラリと同じである必要はないと思うのだ。例えば、malloc() という関数が、内部で Dalvik のAPI を呼んだりしても一向に構わない。

そういう仕組みにすれば、ネイティブコードが使うネイティブヒープの利用状況を、Dalvik が正確に把握することができて、ネイティブコードが malloc() を呼んだときにネイティブヒープが不足していたら malloc() がすぐにNULLを返さずに Dalvik が GC する、なんてことも可能だろうと思ったのだ。

本当にそうなっているのかどうか、Dalvik も NDKのCライブラリも、たぶんソースが公開されているんだろうから、自分で調べればわかると思うのだが、調べていない。単に妄想しているだけなのだけれども。

あと、.NET の CLR はやっている、と書いたのは、上に書いたような malloc がGCを起動する、というものとは別の仕組みだが、memory pressure のことを意識していた。

JVMに比べると、.NET の GC は、非常にたくさんの(それなりにヤヤコシくて使うのが難しい)APIを公開しているのだが、その中に memory pressure という機能がある。これは、ネイティブヒープの利用状況を、GC に教える仕組みだ。

.NET ではネイティブコードの呼び出しは P/Invoke という仕掛けで行う。これは、jniと違い、呼ばれる側(ネイティブコード側)は.NET からの呼び出しであることを一切意識せず、逆に呼び出す側(マネジドコード側)がネイティブコードの呼び出しを意識することになっている。このため普通は、jniではネイティブ側に書くいわゆるグルーコードは、P/Invoke では .NET 側で書く。

このとき、P/Invoke でネイティブコードを呼び出す直前とか戻った直後とかに、ネイティブ側で割り当てたメモリの量をGCに教えるのだ。新たに割り当てたときには AddMemoryPressure、解放したときには RemoveMemoryPressure というメソッドを呼ぶことになっている。両メッソドが適切に呼ばれていれば、CLRはネイティブメモリ利用状況を把握することができて、適当な上限値を越えるとGCを動かす、ような処理を行う、らしい。(実は、この辺り、正確な記述をみつけていないのだが。断片的な情報を組み合わせると、こんなところだと思う。)

この手法は、さきほど妄想した「ネイティブコードはmallocを呼ぶだけでOK」に比べると、余計な手間がかかるし、正確性にも劣るが、それでも、Sun JVMの「ネイティブヒープの使用量には一切関知しません。以上。」みたいなスタンスよりは大分いい。

« 約411年前のある日 | トップページ | プレゼン資料掲載しました »

コメント

コメントを書く

(ウェブ上には掲載しません)

トラックバック

この記事のトラックバックURL:
http://app.f.cocolog-nifty.com/t/trackback/285638/53940101

この記事へのトラックバック一覧です: メモリ管理の話の続き:

« 約411年前のある日 | トップページ | プレゼン資料掲載しました »