[foreign] road to posix

[Samuel Audet]

Hi, John,

That sounds great! But could you elaborate on how you are designing this 
to be useful for "computation graphs" is the accepted terminology I 
believe? That's not "stuff not invented yet", but as far as I can see, 
Oracle and the Java community in general is completely ignoring this! 
This is basically what TensorFlow is all about. FYI, here is a nice blog 
post that explains how this all fits with more traditional toolchains:
http://blog.christianperone.com/2016/08/jit-native-code-generation-for-tensorflow-computation-graphs-using-python-and-llvm/

BTW, Google is currently exploring integrating TensorFlow into Swift:
     https://github.com/tensorflow/swift
Could we do the same with Java? That would be awesome. If not, could you 
elaborate on why this doesn't this fit into Java's roadmap? (and thus 
why we should all switch to Swift :)

Samuel

On 06/02/2018 07:11 AM, John Rose wrote:
> On Jun 1, 2018, at 10:40 AM, Florian Weimer <fweimer at redhat.com> wrote:
>>
>> please come to libc-alpha and ask us to provide something that is digested more easily
> 
> That sounds good.  FTR, Panama is not just about C headers.
> It is about building a framework in which any data+function schema
> of APIs can be efficiently plugged into the JVM.  So it's not just C or
> C++ but protocol specs and persistent memory structures and on-disk
> formats and stuff not invented yet.  We've been relentless about designing
> the framework down to essential functionality (memory access and
> procedure calls), not just our (second-)favorite language or compiler.
> 
> The important deliverable of Panama is therefore not Posix bindings,
> but rather a language-neutral memory layout-and-access mechanism,
> plus a language-neutral (initially ABI-compliant) subroutine invocation
> mechanism.  The jextract tool grovels over ANSI C (soon C++) schemas
> and translates to the layouts and function calls, bound helpfully to
> Java APIs with unsurprising names.  But the jextract tool is just the
> first plugin of many.
> 
> We do look forward to building more plugins for more metadata formats
> outside the Java ecosystem, such as what you are building.
> 
> In fact, I expect that, in the long run, we will not build all of the
> plugins, but that people who invent new data schemas (or even
> data+function schemas or languages) will consider using our
> tools (layouts, binder, metadata annotations) to integrate with
> Java, instead of the standard technique, which is to write a
> set of Java native functions from scratch, or (if you are very
> clever) with tooling.  The binder pattern, in particular, seems
> to be a great way to spin repetitive code for accessing data
> structures of all sorts, not just C or Java.  I hope it will be used,
> eventually, in preference to static protocol compilers.  The
> JVM is very good at on-line optimization, even of freshly
> spun code, so it is a natural framework for building a binder.
> 
> (Also, since the binder hides its operations behind interfaces,
> it is also possible to engineer ahead-of-time versions of the
> binder, to use at AOT time or when a JAR is required.  Thus,
> the binder can subsume the old static generation techniques
> for protocol stubs.)
> 
> All that said, we have to do the first couple of plugins ourselves,
> just to shake out the backend (layout, binder, etc.) and make
> it more likely to succeed with third-party efforts.
> 
> Thanks for inviting us into the libc-alpha conversation!  I look
> forward to someday parsing whatever modern metadata C
> invents to manage its modules, whether that is booted through
> an old-C DLL of stubs, or via a binder plugin which can directly
> read the modules.
> 
> — John
>