libffi: closures for sparc

Jeff Sturm jsturm@one-point.com
Wed Jul 17 14:33:00 GMT 2002


On Wed, 17 Jul 2002, Kresten Krab Thorup wrote:
> I'm out of the loop now, but it should be known that the "raw" api was
> thought as an optimized version of the general ffi api which would make
> sense exactly on architectures where the interpreter's stack (i.e. the
> union of jint, jchar, etc.) is very similar to the layout of arguments
> in the host environment's ABI.  As such, it is indeed ugly; and relies
> on all kinds of assumptions...

I remember the discussion... the x86 interpreter is efficient because of
the raw API, which I believe is a good thing, portable or not.

The plain closure API is fairly portable but realistically is too much
overhead for an efficient bytecode interpreter.  This may be one of those
areas we abandon portability.

Specifically for java_raw_api.c, I'm tempted to pull that layer into
libgcj where it can operate directly on _Jv_word and perhaps use a
simpler, more direct interface into libffi.  Perhaps loading argument
registers directly from the java stack.  But I haven't thought this
through yet.

Good to hear from you, Kresten.

Jeff



More information about the Java-patches mailing list