From: shudoh@muraoka.info.waseda.ac.jp (SHUDOH Kazuyuki )

To: java-house-brewers@center.nitech.ac.jp

Message-ID: <199710190538.OAA00913@kokoro.olu.info.waseda.ac.jp>

Date: Sun, 19 Oct 97 14:52:58 JST

[JavaHouse-Brewers:13314] JNI cannot be implemented through RNI

首藤です。

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 <dickh@pipeline.com>
>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@muraoka.info.waseda.ac.jp

Follow-ups:

013327 kino@psrc.isac.co.jp (Nobukuni Kino)