Java <-> C

[Jagannathan, Suresh]

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

Yes.


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

I'm curious why you think this might cause problems.  There's an implicit
assumption here that the C code is reasonable in its use of globals.  The
issue of malloc'ed data is more problematic.  I suppose it would be possible
for the Java/C interface to somehow communicate how much heap-allocated data
was generated by C (e.g., when C calls back to Java) so that the handler can
free this space prior to return, but I don't think we do this.


> 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 think Henry's point was the C compilers may perform optimizations that
depend on an object's address where the object is an internal structure
rooted at a Java object passed to C.  I should look at how the stub
generator works to see how it solves this problem.  One way would be for it
to flatten these objects supplying the flattened representation to the C
code.  This may not be such a big deal for Java since objects don't tend to
be deeply nested, but I'm not sure if this is what happens currently.  I
agree that for simplicity simply returning an exceptional value works,
although it isn't particulary elegant and causes ML code to behave (or be
written) differently depending upon whether it's called from C or not.


-- Suresh