
<div dir="auto"><div dir="ltr"><div dir="auto"><div dir="ltr"><div dir="auto"><div dir="ltr"><div style="font-family:verdana,sans-serif;color:rgb(7,55,99)" class="gmail_default"></div><div dir="auto"><div dir="ltr"><div style="font-family:verdana,sans-serif;color:rgb(7,55,99)" class="gmail_default"></div><div style="font-family:verdana,sans-serif;color:rgb(7,55,99)" class="gmail_default"></div><div style="font-family:verdana,sans-serif;color:rgb(7,55,99)" class="gmail_default"></div><div class="gmail_default" style="font-family:verdana,sans-serif;color:#073763" dir="auto">Hello,</div><div class="gmail_default" style="font-family:verdana,sans-serif;color:#073763" dir="auto"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;color:#073763" dir="auto"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;color:#073763">I would like to bring to your consideration the following set of observations and user-model suggestions as I am hopeful they will be useful in the context of the Valhalla project.</div><div class="gmail_default" style="font-family:verdana,sans-serif;color:#073763"><b><br></b></div><div class="gmail_default" style="font-family:verdana,sans-serif;color:#073763" dir="auto"><b><br></b></div><div class="gmail_default" style="font-family:verdana,sans-serif;color:#073763"><b>Definition</b></div><div class="gmail_default" style="font-family:verdana,sans-serif;color:#073763"></div><div class="gmail_default" style="font-family:verdana,sans-serif;color:#073763"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;color:#073763"><u>shared-mutable</u> - a variable that is mutable (non-final) and can be shared between threads; shared-mutables are the non-final subset of the shared-variables (Â§17.4.1.)</div><div class="gmail_default" style="font-family:verdana,sans-serif;color:#073763"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;color:#073763"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;color:#073763"><b>Observations</b></div><div class="gmail_default" style="font-family:verdana,sans-serif;color:#073763"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;color:#073763">Shared-mutables are the only variablesÂ that have these two apparently independent properties:<br><ol><li>

lack definite-assignment (Â§16.) - 

the variable is initialized with a default-value if not definitely assigned (Â§4.12.5.)<br></li><li>allow data-races - the variable may be 

read/written


while being written by another thread, with both events happening with an unpredictable order (Â§17.4.5.)<br></li></ol>Property 1 and 2 share a unique characteristic: the external behavior of the variable is automatically alteredÂ when, respectively, the nullability and the representation mode (inlined/reference) of the variable is changed:</div><div class="gmail_default" style="font-family:verdana,sans-serif;color:#073763"><ol><li>

if not 

<span>definitely-assigned</span>,


the variable is initialized with:</li><ul><li>if nullable: 

the null value, regardless of the variable's type</li><li>if not nullable: 

the zero_value of the variable's type


</li></ul><li>

in a data-race, the value 

read/written:</li><ul><li>if reference: has unpredictable origin in <u>one</u> of the various writes</li><li>if inlined, either:</li><ul><li>has unpredictable origin in one of the various writes<br></li><li>is

teared i.e. has distinct internal parts with separate unpredictable origins in <u>more than one</u>Â of the various writes (Â§17.7.)</li></ul></ul></ol><div dir="auto"><span style="font-size:12.8px"><br></span></div></div><div style="font-family:verdana,sans-serif;color:rgb(7,55,99)" class="gmail_default"><div class="gmail_default" style="font-family:verdana,sans-serif;color:rgb(7,55,99)"><div dir="auto"><div class="gmail_default" style="font-family:verdana,sans-serif;color:rgb(7,55,99)">These are the 3 kinds of shared-mutable variables (Â§4.12.3.):</div><div class="gmail_default" style="font-family:verdana,sans-serif;color:rgb(7,55,99)"><ul><li>non-final class variables</li><li>non-final instance variables</li><li>array components</li></ul></div></div><div dir="auto">The remaining kinds of variables don't have any of the above properties:</div></div></div><div><div style="font-family:verdana,sans-serif;color:rgb(7,55,99)" class="gmail_default"><ul><li>final class variables</li><li>final instance variables</li><li>method parameters</li><li>constructor parameters</li><li>lambda parameters</li><li>exception parameters</li><li>local variables</li></ul><div><b><br></b></div><div><b>User-model</b></div><div dir="auto"><br></div><div dir="auto">For class-authors:</div><div dir="auto"><ul><li><u>value-knob</u> to reject identity - Applicable on class declarations, if used by a class-author to indicate that the class instances don't require identity (a value-class), the runtime will be free to copy these instances and swap between referenceÂ and inlinedÂ representations everywhere except in shared-mutables, as doing so does not introduce any changes to the external behavior of the program.</li><li><u>atomicity-knob</u>Â to forbid tearing - Applicable on value-class declarations, may be used by the class-author to ensure tearing cannot happen on shared-mutables in order to preserve constructor invariants that may be useful for class-users to rely upon. The runtime is free to implement this through a reference representation or by ensuring inlined-write atomicity.</li><li><u>noDefault-knob</u>Â forbids the zero-value being used as a default-value - Aplicable on value-class declarations, may be used by the class-author to force shared-mutables of this class to either be definitely-assigned or nullable. (Actually, I don't believeÂ this knob will be useful, since I thinkÂ all zero-values are equally bad. Moving across the spectrum from useful to useless to out-of-domain default-values is moving from hidden to noticeable to obvious missed-initialization-bugs. Ex:Â  false -> 0.0 -> Jan 1, 1970 -> 0/0 -> null)</li></ul><div dir="auto">For class-users:</div><ul><li><u>nullable-knob</u>Â includes null in the value-set of a variableÂ - Applicable on any variable declaration, in either mode of representation. The runtime is free to choose the encoding for the extra bit of information required to represent null. In shared-mutables that are not definitely-assigned, controls the default-value: either null or the zero_value of the value-type. Since identity-types lack a default-value, any non-nullable shared-mutable of an identity-type must be definitely-assigned.</li><li><u>atomic-knob</u> to avoid tearing - Applicable on shared-mutable declarations, may be used by the class-user to ensure tearing does not happen. The runtime is free to implement this through a reference representation or by ensuring inlined-write atomicity.</li></ul></div><div dir="auto">If, for compatibility, the representation modes must remain complected with nullability, the nullable-knob and the atomic-knob above can be replaced with:</div><div dir="auto"><ul><li><u>inline-knob</u>Â to require inlined/reference representation - Applicable on shared-mutable declarations with a value-class type, gives the class-user control over the tradeoffs between performance, footprint, nullability and implied default-values, and if/how to manually avoid tearing.</li></ul></div><div dir="auto"><br></div><div dir="auto">Kind regards,</div><div dir="auto">JoÃ£o MendonÃ§a</div></div></div></div></div>

</div></div>

</div></div>

</div></div>