scala-arm や clojure.java.io が例外安全じゃない？

りらっくみゃー @rirakkumya

@kmizu OutOfMemoryはメモリーリークかそもそもVMへのメモリー割り当てが間違っている障害なので、即終了してリカバリはしないですね。

kmizu @kmizu

@rirakkumya 普通はそうだと思います。でも、特殊な分野でVM dependentでなんとかしなければいけない場合も世の中にはあって…

りらっくみゃー @rirakkumya

@kmizu 組み込み系とかですか？

kmizu @kmizu

@rirakkumya そですね。組み込み系といっていいかと。ただ、VMはメモリ管理のための特別な機能があるVMじゃくて、細かいメモリ管理はそれほど得意でない(あまり詳細言うと迷惑かけそうな人もいるのでこの辺で)。

kmizu @kmizu

どういう話かちょっとぼかして書くと、あるVMで条件Xが満たされたときに、OOMEが発生して、そうでないときはOOMEが発生しない、というテストをJavaコードとして書かないといけなかった。このとき、テストの途(cont) http://t.co/ONqOBOf6

kmizu @kmizu

じゃあ、テストのために必要な分以外ではnew書かなければ大丈夫かというとそう単純な話ではなく。

kmizu @kmizu

たとえば、テストの途中で、テスト開始前にアクセスしてなかったクラスにアクセスすると、そこでOOMEが発生する可能性がある。オブジェクトのあるメソッドに初めてアクセスするときもOOMEの可能性がある。中でnewしてる可能性があるメソッドは使えない。他にも制限がたくさん。

りらっくみゃー @rirakkumya

@kmizu 仕様としてOOMEが出るパターンを考慮しなくてはいけないんですか。javaでやるのは辛いですね。

kmizu @kmizu

で、それを回避するために、テストの前にテストで使うクラスは全部ロードしておく、使うメソッドも一度呼び出しておく、static節で、後でデバッグprintするための文字列をbyte[]にあらかじめ変換して保存しておく。n

kmizu @kmizu

newされるオブジェクトのサイズはVMの実装をみてテスト前に計算しておく。これはもちろんOracle JVMとは異なる実装の話ですが、Oracle JVMでも通常ユーザが意識しない箇所で色々なallocationが起きてるのはほとんど確実。

kmizu @kmizu

@rirakkumya ただまあ、これ、Java(言語)でやらないとまずいんですよ。「OOMEという例外が条件Xの元で発生する」テストなので、たとえばCでJNIでテスト書いたとしてもテストにならない。

kmizu @kmizu

@jagd5168 なるほど。まあ、現在の状況では、そういうのはさすがに普通必要ないですけど、本当にprecise(正確)なリソース管理をしようとすると(実際にはOracle JVMをそういう用途に使うのが間違いと思いますが)、そういう実装詳細も把握しないといけないですよね。

kmizu @kmizu

ところで、当たり前ですが別に haruyama さんに何か含むところがあるわけじゃないです。ただ、JVM外のリソースはともかく、JVM内でのpreciseなリソース管理については甘く見積もってるのではないか、という疑問です。