State of javac support for lworld-values.

[Karen Kinnear]

Srikanth,

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.

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.

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>, here is a summary of a new proposal:

   Value type arrays are always flattenable, and therefore not 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

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

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.

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)
>     - 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.


thanks,
Karen


> On Mar 13, 2018, at 7:46 AM, Srikanth <srikanth.adayapalam at oracle.com> wrote:
> 
> 
> Hello Frederic, Karen and list,
> 
> I have taken stock of and reviewed the changes made so far to javac to support lworld values and I think the work looks complete as far as I can tell (except for https://bugs.openjdk.java.net/browse/JDK-8198749: Role of constructors and <init> methods for value classes - which is still under discussion)
> 
> I would be happy to follow up on any errors of omission and/or commission or to accommodate any new requirements that emerge as the prototype work evolves.
> 
> Here is an inventory of features, constructs and behaviors already pushed to lworld branch tip:
> 
>     - A class declaration may be tagged as being a value type by using the `__ByValue' modifier
>     - This feature is allowed as of now, at source level >= JDK11
>     - Only a class may be tagged as being a value type - interfaces, annotation types, enums cannot be.
>     - Top level, inner, nested, local classes may be tagged as __ByValue.
>     - Value classes must be declared to be final and so abstract classes or interfaces cannot be value types.
>     - Akin to enums, annotation types and interfaces, value types may not declare an explicit super class (not even j.l.O). All value types implicitly extend j.l.O. They may declare explicit super interfaces.
>     - Value types can be type arguments in generic type parameterizations.
>     - Value types can be explicit type witnesses in generic method invocations
>     - Value types can be wildcard bounds (even if only with limited utility on account of being final classes - a la String)
>     - Value types can be intersection (cast) type components (FWIW),
>     - Value instances can be enclosing instances in instance creation expressions.
>     - At the class file, a value class is signalled by the class flag ACC_VALUE(0x100). Javac will ignore this flag *from* class files when compiling for a source level that does not recognize value classes as such.
>     - All instance fields of a value class must be declared to be final.
>     - Value instances are created with __MakeDefault. `new' cannot be used with value classes and likewise __MakeDefault cannot be used with non-value reference types.
>     - __MakeDefault does not accept any parameters. No constructor invocation - not even the no-arg constructor invocation - is involved.
>     - Values have no instance lock and so may not be synchronized upon.
>     - Values have no identity and consequently the method java.lang.System.identityHashCode may not be invoked on them
>     - The following methods from j.l.O are not allowed on value receivers:
>         clone(), finalize(), wait(), wait(long), wait(long, int), notify(), notifyAll()
>     - Value instances may not be compared with == or !=. == and != cannot have any value operand(s)
>     - instance methods of value types do not have a monitor associated with their this and so cannot be declared as synchronized
>     - 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 may not be a cycle that passes through fields tagged as being Flattenable.
>     - With the compiler option -XDrejectValueMembershipCycles, javac will not allow a value type to declare fields of its own type either directly or indirectly (flattenable or otherwise)
>     - An instance field of a value class may be updated via the __WithField "operator". This does not update the original value instance, but produces an updated copy.
>     - The first operand of the __WithField operator must be an instance field of a value class, while the second operand is of suitable type that is assignable to the the first operand field.
>     - __WithField may be used to update an instance field of a value type only from, but anywhere from the same nest.
>     - __Withfield may not be used to update a value field with null.
>     - There is no implicit write back - the result of the __WithField operator must be assigned to a suitable *writeable* handle - There is no relaxation of the rules around finality when it comes to value types. So final variables cannot be written to. Nor can `this`
>     - (non-blank) final *instance* fields of value types that are initialized with compile time constants are not treated as constant expressions and do not take part in constant propagation/folding. Each read of such a field would result in a fresh getField and the ConstantValue attribute would be missing in the class file.
>     - The compiler will insert a null check when an object or interface type is cast into a value class.
>     - Two new opcodes: defaultvalue(203) and withfield(204)
>     - Byte code library has been brought up to date
>     - Tests for all the above.
> 
> Thanks!
> Srikanth