Java <-> C

[Stephen Weeks]

>   -- Multiple Java threads shared the same C stack. 

I guess we will do this for starters.  I assume though, that a single thread
knows that it has the lock and can do mutual recursion between C and Java ad
infinitum.

>   -- Before a Java thread makes a C call, its stub records the current C
> stack top as
>      part of the information kept on the frame.
>     
>      When an exception is raised, the frame containing the handler resets
> the C stack
>      accordingly.

This seems pretty scary, since all the C stuff misses its chance to do cleanup.
I'd rather stick with return values for exceptional conditions (the C way) for
now.

> 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.

Keeping them live is not enough, since the GC may move them.  You have to do
what Henry says, unless the GC is non-moving:

> I guess that if all the C code is required to always refer to
> the objects through a global indirection table (so the C compiler can see
> that its entries could change after calls to Java functions) then you would be
> safe.