Fwd: JEP 303: Intrinsics for the LDC and INVOKEDYNAMIC Instructions

[Brian Goetz]

The following was received through the valhalla-spec-comments mailbox.


-------- Forwarded Message --------
Subject: 	JEP 303: Intrinsics for the LDC and INVOKEDYNAMIC Instructions
Date: 	Wed, 26 Apr 2017 23:24:40 +0200
From: 	Jeremy Barrow <jeremy.a.barrow at gmail.com>
To: 	valhalla-spec-comments at openjdk.java.net



I'll preface this with:
I know that making a language construct for this has already been set as an
explicit non-goal.
If you're 100% set on that, then you can probably skip this email, but if
you're interested in the opinions of some random who had a free afternoon,
then read on.

For the same reason that collection literals are a bad idea within the
language; compiler intrinsics are a bad idea within the library.

Assuming a class gets added to the standard library, how would other
languages react to that?
Are they going to have to implement some support for it, or instead explain
to their userbase that some portion of the library is redundant, more so if
the language already supports language level intrinsics.

This would be the perfect time to finally use "const".

const MethodType type = ...;

(Side-note: this might start dipping into ConstantDynamic (condyn)
territory, but bear with me.)

The idea would allow the programmer to declare a field or a local variable
with the const modifier.
When the programmer does this, it should be treated as a compile time
constant.

As such, it doesn't make sense to be able to be able to declare a const
field, as a static final const field.
This might affect readability, and should probably be reviewed, but
semantically, it makes sense.
If the field/variable is used in a non-const context, then it should be
treated as if it was written there. (Excluding some types, such as strings,
classes, etc)

Because it's a compile time constant, it raises some questions:


Should the source code contain something that won't be present in the final
runtime class?

I think it makes sense, as it's not the only thing that java can omit from
the runtime class.
Annotations can have a non-runtime retention, so I don't think the concept
is a shock to java programmers, and arguably, a field/local variable with
const is easier to spot than a non-runtime annotation (because you have to
inspect the annotation's class).

I was originally going to also suggest maybe having support for const
methods as well, and variables and parameters can only be const, etc, but I
think that's far too much for this simple API, and would play very well
into condyn's implementation.


Should the compiler be intrinsically aware of the type, or be able to be
made aware? (Intrinsic types or some way to communicate to the compiler how
to convert a type into a constant)

This is dangerously close to condyn, but I felt the need to bring it up
just to show how well the two could go together.

With this API, I think, initially, intrinsic types are perfect.
Higher level types that can be known to the compiler, such as MethodType,
Class, String, are more or less perfect for it.


Now, the main problem:
You can't declare a method with those constants without an intrinsic type,
or if you could, it might not be too readable.
That being said, I may have overlooked a nice way to declare methods with
constants.

The first solution that came to mind was representing MethodHandle as a
const.
Currently, there's no explicit creation mechanism, outside of the Lookup
system itself, for obvious reasons.

Should there be a const factory method for MethodHandles, that can only
accept const parameters?

We have method references, could we use them?

I spent some time thinking about this, and it almost always boiled down to
an intrinsic class.
As even if we can define a MethodHandle in a const manner, we still have to
deal with the compiler needing to be aware of the point where it needs to
emit the invokedynamic instruction.

In effect, const is a way to define the constants, not the instructions.

I think that was the shortcoming, and having something at the language
level for bytecode specific instructions is a potentially toxic idea.

Now, all that being said, and the final result is in more or less the exact
same position as before, I have suggested using const.
Which means we can declare new semantics.

What if we could define classes that _have_ to be entirely constant?
What if we could attach a @Retention to it, or define a RetentionPolicy for
it?
This means the JVM could toss the class, much like it does annotations.

This could make the way for a whole section of programmable constants later
on with condyn.

I will admit, this got much bigger than I originally planned, but
hopefully, I got across my point, if I failed, I at least hope that I gave
someone a good idea to work it.

Thanks for reading this wall of text.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20170426/2152ea16/attachment.html>