State of javac support for lworld-values.

[Srikanth]

Hi Karen,

For value arrays, I don't think there is anything that expressly needs 
to be handled by javac. I will double check.

For nullability, my understanding is that expectations are different for 
javac and the VM. That javac should regardless of the flattenable/array 
element status, forbid injection of nulls.

I will for wait comments to trickle through and raise tickets to follow 
up on them beginning next week.

Thanks
Srikanth


On Wednesday 14 March 2018 03:34 AM, Karen Kinnear wrote:
> 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 
>> <mailto: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
>