From david.r.chase at oracle.com  Mon Sep 29 16:57:46 2014
From: david.r.chase at oracle.com (David Chase)
Date: Mon, 29 Sep 2014 12:57:46 -0400
Subject: Ping/hello.
Message-ID: <81818BB2-8C2D-4910-A83F-D03BB7B0AB49@oracle.com>

Hello IBM guys, are you guys around or otherwise occupied with JavaOne? (I?m not at J1, John and Brian are, I think)
John reminded me that we needed to get moving on the Layout stuff.  I?ve been whacking on Arrays instead
(so far, prototypes are entirely library-land, and run in jdk8 just fine) but thought I would try to get going.

Last I remember, both of us were planning for something that at the bottom (ignoring the tools at the top)
would be based on spinning bytecodes including unsafe code to implement an interface (or abstract class?),
and that we would have some sort of a tiny language to describe field locations, size, alignments.

The things that I remember as being not necessarily resolved were

1) how the factories were exposed; I think Angela?s plan had went directly from thing-specification
to allocated instance of thing, where the prototype I had put together map thing-specification to
thing-factory, and the factory (which was a lot like a ?type?) could then allocate instances of thing.

2) I?m a little nervous about bytecode spinning in the context of ahead-of-time compilation.  There are
plausible platforms are strongly biased towards ahead-of-time, and we might want a plan that allows us to
not handicap Java execution on those platforms.  I think this might mean some form a naming scheme for
the generated classes, so that if they are found on the classpath already they need not be generated.
This might also be useful to assist in debugging

3) I spent some time experimenting with the relationship between a so-called ?Ref? type and a so-called
?Value? type, thought I had some answers, but after whacking on the array code for a while I am no longer
quite so sure.  To be semi concrete, a sample hierarchy for a ?Subtype? hierarchy might look like this

  interface ComplexValue // get fields
     class Complex // plain old Java
     interface ComplexRef  // set(ComplexValue), set( re, im )  BUT NOT setRe(x), setIm(x).
         class GeneratedComplexProxy // implements CX Ref and Value w/ unsafe on top of native storage.

In a ?Separate? hierarchy, ComplexValue and ComplexRef are completely unrelated, though a ComplexRef
has methods that allow you to change its contents with a ComplexValue or return its contents as a
ComplexValue, as well as the field getters.

I *think* my plan was that the Subtype hierarchy would allow for more ?natural? code from the POV of 
a C programmer, but that the Separate hierarchy should make it easier (more reliable) for the JIT to provide
good performance; the ComplexRef interface would have only one implementer, therefore class hierarchy
analysis is guaranteed to win everywhere, inlining and optimization will occur, and there will be much
rejoicing.  I?m also not entirely convinced that catering too slavishly to the tastes of C programmers is
a good thing.

4) I think we had different-but-isomorphic ideas about the little language for specifying layout.

5) I think, from the POV of giving C programmers what they expect, that any specification
that relies on fields being concatenated in order should conform to native expectations, and
not do network-byte-order everywhere.  I?m calling this out explicitly because I?m pretty sure there
will be disagreement, and I want to be sure that nobody naively assumes that there isn?t.  I
assume that people using this ? if they see the little language at all ? will be working with
local byte order header files and will be happiest if things read in the same order in the Java/
layout version of their header files.

We might want an option that explicitly does NBO layout so that people working from 
protocol specifications (instead of local header files) can work in a natural style.

6) I know we have at least two use cases.  You guys have database guys in mind (I think
we do, too), we also have the numeric and C-interoperation crowds in mind.  Others?
Can we come up with a set of motivating examples?

I hope this is enough to chew on for a little while.

David