GC problem (finalisers) & comments

[Robert S. Thau]

Tim Wilkinson writes:
 > What I would propose therefore is to define the GC interface so another 
 > GC can be easily dropped in instead of the Kaffe default - this is 
 > something I'm working towards anyhow.  However, I would expect this to 
 > have implications on the threads too (since GC's usually hang on these 
 > too) and I'm nowhere near getting that abstraction done yet - but it is 
 > in the works.

FWIW, Sun's perhaps-to-be-standard Java Native Interface does impose
some constraints here which you wouldn't have without it, though
they've tried to keep them fairly light.  In particular, the JNI has a
few defined interfaces for obtaining a "pinned down" copy of some
range of the elements of an array, so that native code can hop around
in that array by just doing address arithmetic, without worrying about
having the whole array moved by a copying GC behind its back.  (These
are intended particularly for, e.g., native FFT routines and the
like).

For Kaffe's current GC, or the Boehm GC, these are effectively no-ops,
of course, since those GCs wouldn't move the elements of a live array
regardless.  However, for a copying GC, the recommended strategy is
copy-out/copy-back from an area of special "pinned" memory; that, in
turn, would require some negotiation between the GC and the VM code
proper about the location and properties of those pinned areas, which
an architected interface between the two would have to support.

FWIW, the JNI table of contents is at:

 http://www.javasoft.com/products/jdk/1.1/docs/guide/jni/spec/jniTOC.doc.html

The rationale for the array-handling business is in the "Accessing
Primitive Arrays" section of ch. 2; the functions themselves are the
{Get,Release}.*ArrayElements routines of ch. 4; and there are a few
other GC-related bits of lesser import elsewhere in the document
(particularly the Global/Local reference stuff in both the same
chapters). 

rst