[Matthew Fluet]

> I don't understand how the C code copes with the GC.  If the C code gets passed
> some Java object, it will now store pointers to it in various places (including
> ones you don't know about like C-compiler generated temporaries).  If the C
> code now calls some Java code, and that code triggers a GC, how can you know
> what needs re-location in the C world?  Most of the interfaces that I know
> about end up using non-moving GC's just to avoid this problem.

Suresh said that the generated stubs for C procedures register GC-able
values with the GC and pass these values through an indirection table.
Presumably, the indirection table is also registered in some way with the
GC, so that when the GC moves an object, it updates the table for the C
code.  I guess the unstated invariant is that after a C procedure
terminates, it shouldn't have saved any values it got through the table.
I.e., Java objects can't be part of the saved C state between calling of C
procedures.  It seems that you could get around this by stating that a C
procedure does hold Java objects in its state, and then one would need to
always keep the objects reachable from the indirection table live.