Date: Sun, 19 Oct 97 14:52:58 JST From: SHUDOH Kazuyuki Subject: [JavaHouse-Brewers:13314] JNI cannot be implemented through RNI To: java-house-brewers at center.nitech.ac.jp (JavaHouse Brewers ML) Message-Id: <199710190538.OAA00913@kokoro.olu.info.waseda.ac.jp> 首藤です。 JNATIVE-L という ML の記事に、興味深いものがありました。 元は comp.lang.java.advocacy の記事です。末尾に付けます。 Microsoft が、自分達の JavaVM に JNI を用意できない理由です。 推測とはいえ、文章を書いている Dick という人は JavaVM 作っているようですし、うなづける内容です。 Sun の決めた Java Native Interface (JNI) と Microsoft の Raw Native Interface (RNI)、 それぞれにおける garbage collection (GC) の扱いについてです。 背景として、native methods で作ったオブジェクトを GC の ときにどう扱うかという問題があります。 GC ではどんな方式であれ、回収するオブジェクト、しないオ ブジェクトの区別をつける必要があります。native method に ついて何も考慮しないと、native method 中で作られたオブジェ クトは無条件に回収されてしまいます。さすがにこれはまずいです。 JNI: native method のフレームごとに local references (の表) を用意、 local references から辿れるオブジェクトは回収しない。 RNI: native method に入るスレッドに、VM が GC lock を与える。 JNI の方法だと、native method 実行中のスレッドがあっても、 それとは非同期に別スレッドにて GC を実行できます。 RNI の方法は、Dick が "I think .." と書いているので 実験に基づく Dick の推測なのでしょう。 GC lock を与えるというのがどういうことなのか、はっきりわかりません。 VM による GC を一切禁止するのだと推測しています。 native method 中で作られたオブジェクトの回収を防ぐために は、local references のように表でも作らない限りは、VM に よる GC を一切禁止する他に手はないと思うので。 Dick は RNI の方法には多くの問題がある。 JavaVM 全体が deadlock する状況もある。 と続けています。 ここでもうひとつ疑問が湧きます。JIT コンパイラによって 生成されたプロセッサ native なコード実行中に GC は起こるのか? RNI では JIT コンパイラが作った native code 実行中も GC が 起こらないのではないかと考えてしまいます。どうなのでしょう。 Microsoft が自らの JavaVM で JNI をサポートするためには 多くの作業が必要のようです。native code 中で生成したオブ ジェクトは表に登録しなけりゃいけないし、するとおそらく JIT コンパイラの native code 生成部も要変更でしょう。 また、MS Internet Explorer の売りのひとつである JavaVM のパフォーマンスも犠牲になるかもしれません。 技術者の視点から見ると、Microsoft はいつも醜いですね。 またか…と思ったひとときでした。 >From dickh@pipeline.com Sat Oct 18 14:31:10 PDT 1997 >From: DickH >Newsgroups: comp.lang.java.advocacy >Subject: Re: Can JNI be implemented thru RNI? >Date: Fri, 17 Oct 1997 23:09:19 -0500 >Message-ID: <3448366F.53E8@pipeline.com> > >Patrick Taylor wrote: >> >> Richard M. Smith wrote: >> > >> > Does anyone of any technical reasons why JNI cannot be >> > implemented on top >> > of RNI? >> >> I read that one of the critical issues is garbage collection. >> To support JNI, Microsoft would have to redesign their garbage >> collector and effectively reimplement their whole VM. > > >Indeed, JNI requires separate cache's of "local references", one for >each native method frame. These local references allow the native >method to run without having to own the "GC lock". > >This in turn means that JNI allows an incremental GC, such as that used >in Mach J, to continue to run asynchronously (on another thread) whilst >the native method is running. This is true because the GC lock is not >held by the native method. > >I believe Microsoft's approach is to give control (as to whether the GC >lock is held by the native method) to the native method programmer, *** >and the default behavior I think is for the VM to give the GC lock to >the thread about to enter the native method, just before calling the >native method, and to release the GC lock upon return from the native >method. There are lots of problem's with this scheme. If the native >method doesn't release the GC lock and stays indefinitely in C code, say >as some kind of native daemon, then the next time any other threads run >to the point of requestion the GC lock, then the whole JVM will >deadlock. I've even responded to postings on the comp.lang.java.* >groups where this happened. The GC lock is too important an issue to >turn over to [novice] native method coders. > >JNI is a far more elegant scheme, and the expense of the local reference >caches is not necessarily a big performance hit for the value received, >if implemented efficiently. > >I'm just making this all up, of course. (Would you believe I read it on >the back of some cracker jack box.) > > >Dick > >-- >http://www.machj.com Mach J, a clean room Java Virtual Machine SHUDOH Kazuyuki/首藤一幸 私をたばねないで あらせいとうの花のように shudoh at muraoka.info.waseda.ac.jp