[Openmcl-devel] Calling Java from OpenMCL

[Gary Byers]

--On Friday, April 23, 2004 12:04 PM -0400 Gary King <gwking at cs.umass.edu> 
wrote:

> I know that a lot of work is going into calling Objective C and COCOA
> from OpenMCL. Does this work also make it possible to call Java? If not,
> is there any way to call Java from OpenMCL or any pointers as to how to
> make this possible.
>
> Thanks,
> --
> Gary Warren King, Lab Manager
> EKSL East, University of Massachusetts * 413 577 0176
>
> A short memory is a great boon to self esteem.
>    -- Steve Chapman, columnist
>

I looked into this a bit a year or so ago.  Somewhere or other, I have some
code that connects to the JNI (Java Native Interface), instantiates a JVM,
and asks for (and receives) the JNI version number.

At one point, I wanted to go a bit further with this (I suppose that I still
do ...).  The stumbling block under OSX is kind of complicated; I -think- 
that
there's a low-level solution in the current 0.14.x code, but it hasn't been
exercised much.

Under Mach, each thread can have its own exception handler, and OpenMCL uses
this mechanism fairly extensively.  There are several layers of 
exception-handling
in OSX; OpenMCL uses this very low layer, primarily because programs that 
use
higher layers confuse GDB.  Every time a lisp thread is created (or a 
"foreign"
thread first calls back into lisp code), OpenMCL does some low-level Mach 
stuff
to allow some of its code to gain control when an exception occurs on that 
thread.

When a thread first calls into the JNI and "instantiates a JVM", the JNI 
establishes
low-level Mach exception handling for that thread.  As of the time that I 
last
looked at this, the JNI doesn't "do the right thing" (save and restore the 
thread's
existing exception handler, so that the Java exception handler is only in 
effect
while running Java); it instead blindly clobbers the thread's current 
exception handler.
This means that after a lisp thread connects to the JNI, any lisp-related 
exception on
that thread is "handled" by the Java exception handler (which has no idea 
of how to
handle that "properly"), and those lisp exceptions suddenly become fatal.

It's possible to make every foreign function call (and callback) save and 
restore
the thread's exception handling information; this adds measurable overhead 
and doesn't
seem like a desirable approach.   What I wound up doing is to create 
variants of some
of the low-level FFI primitives that do this extra saving and restoring of 
exception
state; I never came up with higher-level syntax for this stuff, but things 
like
DEFCALLBACK and FF-CALL accept some extra keyword arguments that're 
supposed to trigger
the use of these exception-state-saving primitives.

There's been about a year and a half of bitrot since.  Some of the effort 
expended
elsewhere during that period involved getting native threads to play nice 
with the GC
(and that in turn involved occasional redefinition of what "playing nice 
with the GC"
means.)  If this old execption-state-aware FFI code still works in general, 
it may not
interact with the GC properly ...

After wrestling with this for a few days, I basically got distracted.  If 
anyone's
interested in exploring this issue further, I can try to locate the code 
that I was
playing with and try to explain a few things in greater detail.   At this 
point, getting
good Java-OpenMCL integration doesn't seem like a high priority; as always, 
I could be
convinced otherwise.  (At the moment, waving a large handful of cash around 
is one way
of being persuasive ...)