State of javac support for lworld-values.

[John Rose]

On Mar 13, 2018, at 3:04 PM, Karen Kinnear <karen.kinnear at oracle.com> wrote:
> 
> Many thanks for all of the work, thoughtful questions and flexibility. And extra thanks on working through withfield handling.
> 
> Your timing could not have been better. I was just reviewing all of what you have changed to see where things have evolved since we spoke, and which issues are still under discussion. And
> your latest notes cleared up most of my questions.

Wow, Srikanth has really bulldozed through a lot of issues!

> 1. Frederic made a good point - a value type can not have an inner class, i.e. a non-static nested class, since it does not have identity.

Putting on my Mr. Inner Classes hat, I say, not so fast!

Inner-ness is a scoping relation, not an identity relation.
There's nothing about value classes that keeps them from
being either inner or outer.  Let's not be hasty to find reasons
that values don't "code like a class" everywhere it makes sense.

(Strong heuristic:  If a value-based class can do X, then a
value type can do X, 99% probability.  That applies here.)

At the VM level, an inner class has a this$0 reference to the
outer instance.  For a value outer class, the this$0 is a flattenable
copy of the outer instance.  We could be clever and make it
not flat, but I think that's taking a legitimate decision away
from the user.

I grant you that, given an object class and a value class to nest
together, the object class should usually be the outer and the
value the inner.  But it's a user decision, not a VM or language
decision, which goes in which.

> 2. Arrays extract from EG minutes: - which I just typed in Friday night
> 
> - I don’t think you have had time to make the value array changes yet?
> 
> Based on emails this week between Mr Simms, Remi, John on valhalla-dev at openjdk.java.net <mailto:valhalla-dev at openjdk.java.net> <mailto:valhalla-dev at openjdk.java.net <mailto:valhalla-dev at openjdk.java.net>>, here is a summary of a new proposal:
> 
>   Value type arrays are always flattenable, and therefore not nullable

Yes, their elements are flat, thus not nullable.  Just to make sure:
The arrays are proper object types and their references are nullable.

>   If the end user wants non-flattenable/nullable they can use Object[] or Interface[] or maybe a future reflective API if needed that creates a reference array - but for now let us assume that value type arrays are always flattenable, prototype that and then we can assess what the cost might be if we need dynamic checking.
> 
>    As with fields, implementation determines if the component is actually flattened.
> 
>   bytecode implications:
>      aaload - returns default from default initialized value type component
>      aastore - throws NPE if attempt to store null. Must store default value for component
>      anewarray/multianewarray - if the component is a value type, create a value type array

Thanks for writing that down, Karen.

> 
> I believe there are two major open issues:
> 1. you identified one - which is the discussion around <init>, which I think also includes
> handling of __MakeDefault

Yes, we haven't touched <init> yet.  I think the language folks need to
decide what value constructors look like before we can start to talk
translation strategy.  My crystal ball tells me that <init> will be irrelevant
to value types, even though at the source level constructors will be
important.  ("Codes like a class…")  The JVM rules around <init> are
just relentlessly pointer-oriented, so we'll probably break new ground
for value factories.  (If we win big, then that ground will serve for
factories on object classes and interfaces too, but that's just my
hunch for now.)

> 2. I think we are still working through nullability of a value type issues
> I know you and John exchanged a number of emails over the past few weeks.
> I also believe that last Wednesday at both the Valhalla-vm and valhalla EG meetings
> we discussed again nullability relative to value type fields.

I hope we don't find any important use cases for nullable values, in
which case such fields will be relegated to the JVM puzzler list
and maybe JLS chapter 13 (binary compatibility).

> Value type fields:
>  I would like to have a follow-up discussion about nullability of value types based on ACC_FLATTENABLE, 
> and how to handle migration.
> 
> The key points below that I want us to revisit are:
>>    - Value instances may not be compared with == or !=. == and != cannot have any value operand(s)

This is a conservative choice.  We could assign x.equals(y) as the meaning
of x==y for x, y values.  That's a language team choice, and I don't see
a decision on that coming soon.  I recommend filing a tracking issue.

>>    - Null cannot be assigned to value types
>>    - Null cannot be casted to or compared with value types.
>>    - Fields may be flagged as being__Flattenable. This results in the ACC_FLATTENABLE(0x100) field flag bit being set in the class file. Besides setting this flag bit, the compiler does not use this flag.

There are three more places where I'd like to see more work soon-ish:

1. Flip the default on __Flattenable, making another temporary modifier
__NotFlattened and having the compiler start to issue ACC_FLATTENABLE
by default when it sees that a field is a value type.  This is tricky and may
require additional preloading in javac.  (Not in the VM.)  It's where we want
to get to; eventually removing both pseudo-modifiers (if possible) except
maybe for test code (or just use jcod).

2. Flip the default on 'final', in the sense that javac doesn't care whether
a value class's instance field is declared final or not.  We want to reserve
the distinction for potential uses, TBD.

3. Allow the __Atomic modifier (or the "volatile" modifier if Brian OKs it)
on value classes, with an ACC_VOLATILE on the class, and appropriate
processing in the classfile parser to unflatten, as I outlined elsewhere.

If (as I think) constructors will translate to factory methods not <init>,
then there's nothing for us tools and VM folks to do until the language
folks hash out more details about value class constructors.

Thanks!

— John