[foreign] road to posix

[John Rose]

On May 30, 2018, at 4:09 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> Thanks for the writeup John.

There's one very wrong thing in my write-up, which I hope we
can get past:  I actually said "machine code snippets" to refer
to the tactic of associating small fragments of object code
with bindable API points.  But "machine code snippets" refers
to an excellent existing project (now on hold) with a different
goal.  I must study to increase my vocabulary.

I should have said "code resources", "object code resources",
or something like that.  And that's without prejudice to the
occasional need to package code as low-level ("cc -E" output)
C source code or maybe even LLVM bitcode, which is a detail
we'll work out when we start prototyping.

(Samuel, what do you call these small fragments of code in
your system?  I'm looking for a nice term.)

The important thing is that jextract can set up a bunch of small
subroutines which the binder can locate and connect to Java
API points, as if they were first-class library entry points, already
present in the C library which is being bound.  The contents of
each entry point is ad hoc, and may be specified explicitly by
the jextract operator in some auxiliary side file, or may be
generated implicitly by jextract in response to some pattern
it sees (a C macro definition or intrinsic function, a C++ inline
function or virtual dispatch or template instance, …).  The
names of these little code resources should be kept as private
as possible, between the jextract run and the binder, and
mediated via annotations in the jar.  In the case of an
explicit (user-defined) code resource, the name could be
taken directly from the user-supplied source code, but
the usual case will eventually be lots of auto-generated
names for lots of tiny code resources.  Perhaps the auto
generated names will cleverly translate directly to some
name in an extracted Java API, but in some cases they
won't, and in any case they should be bound privately
in the VM-loaded code (as statics if possible), to avoid
interactions with the system dynamic linker.

Maurizio, you pointed out that this requires a new kind of
information flow between jextract and the binder; I agree.

I hope we can prototype something soon.  Bits needed:
An envelope for code resources (JAR element next to
class file, perhaps), a way to organize them by non-public
(qualified?) name or index or other identifier, a place in API
annotations to pass these identifiers, and to a way for the
binder to look them up and bind them to their correct type.
The simplest identifier to use would be a short name scoped
locally to the jextract run (e.g., "jx_cr42"), but this interacts
with the system's ability to provide "dlsym" access to a name
while keeping it private.   Worst case is each jextract code
resource bundle supplies a standard entry point "jx_lookup"
which takes an index or short string, and returns the selected
static (i.e., file-private) function.

— John