[foreign] road to posix

[Samuel Audet]

I'm afraid I'm not so great with words. I try to stick with existing names,
of closely related concepts if possible. Since I'm using JNI, I just use
what's in Sheng Liang's book about JNI. So, those are basically JNI wrapper
functions or "stubs", often as part of "peer classes", either for native
C++ functions or member variables. I haven't had a need to distinguish them
further...

Samuel

2018年6月1日(金) 4:08 John Rose <john.r.rose at oracle.com>:

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