Specialized primitive implementations after generics specialization

[John Rose]

We expect to upgrade the existing generics so that the
JVM can access enough information about types to
perform various customizations.  The details are hazy,
but we fully expect to be able to supply ad hoc methods
like sum.  Maybe even ad hoc protocols like Summable,
if we are lucky.  Hopefully also ad hoc fields, like an
“Optional::isPresent” field that is elided (typed as “void”
or some other unit or empty type) when the isPresent
logic can be derived from the main field of the Optional,
as today.

The basic insight here is that, if there is enough runtime
information to guide the customization of data structures
(as today’s primitive arrays and fields have layouts
customized to the primitives), then there is also enough
runtime information to perform the coordinated task
of customizing algorithms (think Arrays.sort, on flat
monomorphic inputs).

Then, given those two firm requirements, the JVM
surely also has enough information to drive the creation
of optional methods, especially if (as we hope) the
optional methods can be modeled as always-present
but sometimes-degenerate methods.

To take your example, List<X>::sum would do what
you want if X has a “summable” type.  (Where the
condition of “summability” is encoded by a type bound
or perhaps a type class; details to be worked out.)

Meanwhile, if X has some other random type, then
List::sum would still link but throw a suitable error
when called.  (The static compiler javac might report
a static error when it can prove that this is bound to
happen, for some static type X.)

This scheme, of degenerate methods and fields, plays
well with raw types and wildcards, where the decision
to throw that error would depend on the type of the
receiver object.

For our current thought on how to rewire the JVM
to pass around sufficient information about generics,
please see the Parametric VM manifesto:

https://github.com/openjdk/valhalla-docs/blob/main/site/design-notes/parametric-vm/parametric-vm.md

HTH

— John

On Aug 30, 2021, at 6:45 PM, Nir Lisker <nlisker at gmail.com> wrote:
> 
> Hi,
> 
> I have a question(s) about the need for primitive specialized
> implementations when type parameters will accept primitives.
> Today we need various specializations like IntFunction and IntStream.
> However, the difference between them is that IntStream brings with it
> methods that make sense on int, like sum(), while IntFunction does not.
> Does this mean that some specializations will still be needed, or will
> there be another way of doing it?
> (I'm not advocating to do anything with IntFunction or IntStream, just
> using them as examples.)
> 
> - Nir