[gclist] Cost of gc

[Hans Boehm]

On Dec 18,  8:23pm, Olivier Lefevre wrote:
> Subject: Re: [gclist] Cost of gc
>
> But, concretely, since the problem does exist, how do you "keep your
> data from being garbage collected while you are working on it", as
> he puts it? What are such techniques?
There is a moderately complex protocol that has to be followed by the C code in
order to keep the garbage collector informed of any pointers that it retains,
etc.  You can read about Sun's version (JNI) at

http://java.sun.com/products/jdk/1.2/docs/guide/jni/index.html.

The Microsoft version (RNI) is at

http://www.microsoft.com/java/sdk/20/jnative/rni.htm

The two approaches are quite different.  If I understand correctly, the Sun one
allows collections at all times, at the expense of lots of calls into the JVM
in order to accomplish any manipulation of Java data structures from C code,
and a fair amount of extra bookkeeping in the JVM.  It appears to be a heavy
weight mechanism that makes any native call rather expensive.

Microsoft's approach relies on disabling collections during short native calls
and informing the collector of pointer locations if you want to reallow
collections.

Both JNI and RNI come in 2 versions each.  I believe in the Microsoft case, the
second is not upward compatible with the first, i.e. code needs to be
significantly modified to comply with the second version.  (I think the first
was lacking write barrier support, which was added by the second.)

>
> By the way, if SUN adopts the Great Circle collector for its JVM
> will that alleviate the problem or is it intrinsic to the definition
> of the JVM?
>

If you can rely on the presence of a (partially) conservative collector like
the Great Circle one, that mostly solves the problem.  You still need some
minimal set of non-GC-related conventions for interpreting Java data structures
from C, etc.  (To get things really right, you still need to make sure that
your C compiler doesn't "hide" pointers, and that your code doesn't "hide"
pointers somewhere (e.g. in files) where the collector can't see them.  Neither
tends to be a real issue in practice.  Large bodies of normally compiled code
just work.)

The problem is that currently none of the big players endorses this style of
native calls in Java, though it's similar to Sun's original approach (which is
very different from either of the JNI versions).  There are third party
products that allow very easy intercallability, presumably with yet another set
of simpler conventions.  But these will tie you into exactly one VM.

Standard disclaimer ...



-- 
Hans-Juergen Boehm
boehm@mti.sgi.com