A quick rundown of the current state of LW401

[Brian Goetz]

Yes, it would be great to update the documents, now that the design has settled.  

My mental model here is that this project has been like the “Spanish Inquisition” sketch by Monty Python:

The main impediment to flattening is identity.  

The two main impediments are Identity and Nullity.  

Identity, Nullity, and implicit constructibility.  

AMONGST the impediments to flattening, are identity, nullity, implicit constructibility, and atomicity….

Each of these impediments maps to a programming language construct, that gives up unused degrees of freedom:

 - value types give up identity
 - null-restricted variables give up nullability
 - value types with implicit constructors give up the requirement that all creation go through constructors
 - non-atomic / LooselyCoherentValue give up the requirement that loads and stores be atomic with respect to each other

The more you give up, the more flattening you enable.  



> On Mar 9, 2024, at 11:52 AM, liangchenblue at gmail.com wrote:
> 
> Hi valhalla community,
> Since the introduction of the idea of null restriction, the valhalla model has undergone a huge brainstorm and become much simpler and more backward-compatible in the new lw401; however, valhalla-docs is now outdated, especially part 3, the JVM model, and there is no good single source of truth to look at for our current status.
> 
> Here are the most significant changes from the existing documents per my understanding:
> 1. Primitive/Inlined classes become special storage of value classes with default instance and non-atomicity, removing the artificial primitive-value split and the Q descriptors, leaving just right information for VM to choose to inline; now we are looking at checked types, but it is still up to debate (ASM visitor compatibility concerns from Rémi).
> 2. Value class construction now reuses new-dup-init sequence (shout out to John Rose for his innovations), with larval-stage and final semantics guaranteed by writing before super calls.
> 3. Identity becomes a feature, valueness is determined by ACC_IDENTITY (old ACC_SUPER), previous ACC_VALUE and ACC_PERMITS_VALUE gone; abstract classes can become value yet can be extended by identity classes. Uses custom handling of Object class (construction, superclass rule) to preserve compatibility and removed marker interfaces
> 4. Legacy primitives still somewhat differ from the wrappers, such as == for double vs Double raw bits, whether Double/Long should tear (currently they don't, but their primitives do) but this is more of long-term consideration
> 5. VM implementation will consider the compatibility with lilliput, as we seem to require 4 bits in the header. (value, larval, flattened array, null-free array)
> 
> Am I missing anything important here? I wish we can update the notes somewhere so that we don't have to dig through the mailing list.
> 
> Regards,
> Chen Liang