<div dir="auto">Hi Tim,<div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Thank you very much for all your excellent explanations. The main take away for me was:</div><div dir="auto"><br></div><div dir="auto">It's gonna be next to impossible to guarantee that illigal zero-values are kept hidden.</div><div dir="auto"><br></div><div dir="auto">But, if I understood you correctly, for no-zero types, the compiler can still enforce definite-assignment as it does for final-fields and locals, if it determines, albeit in a limited way,  that the shared-mutable (non-final field or array) is used before initialization. Did I get this right?</div><div dir="auto"><br></div><div dir="auto">So here is another, parhaps dumb, question: why is it so bad that sensless zero-values may be leaked?</div><div dir="auto">If the language cannot guarantee  that illegal zero-values won't be seen, then Java users will need to keep one rule in mind when creating/reading a value-class:</div><div dir="auto"><br></div><div dir="auto"><b>No invariant can exclude the zero-value.</b></div><div dir="auto"><b><br></b></div><div dir="auto">For example: if the constructor of Rational throws on a zero denominator, that is not an invariant. It's just a fail-fast that works for most situations. This is certainly not ideal, but is it a big problem? Or is there something else that I'm still missing?</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Now, here's the main question:</div><div dir="auto">Why can't shared-mutables be inlined by the runtime in an opaque/automatic way? I.e. when encountering a shared-mutable, why can't the runtime decide the encoding-mode based on something similar to this ternary expression:</div><div dir="auto"><br></div><div dir="auto">var encodingMode =</div><div dir="auto">        hasIdentity(varType) ? reference </div><div dir="auto">    :   tooBig(varType.bitSize) ? reference </div><div dir="auto">    :   atomicWrite(varType.bitSize) ? inline</div><div dir="auto">    :   atomicClass(varType) ? reference </div><div dir="auto">    :   inline;</div><div dir="auto"> </div><div dir="auto">With varType.bitSize depending on nullability I.e. a nullable Rational would be less likely to be inlined than a non-nullable Rational!, simply due to the extra bits required to also represent null. The predicates tooBig and atomicWrite would depend on the hardware specs.</div><div dir="auto"><br></div><div dir="auto">If this could be done, users would not have to know about ref-projections or val-projections or about inlining or references. The only Valhalla related concepts that would matter for users would be:</div><div dir="auto"><br></div><div dir="auto">- object identity</div><div dir="auto">- variable nullability</div><div dir="auto">- object write atomicity</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">João</div></div>