EG meeting, 2020-07-15

[Dan Smith]

Notes from the discussion:

> On Jul 15, 2020, at 12:01 AM, Dan Smith <daniel.smith at oracle.com> wrote:
> 
> The next EG Zoom meeting is tomorrow, 4pm UTC (9am PDT, 12pm EDT).
> 
> Recent threads to discuss:
> 
> - "JEP draft: Identity Warnings for Inline Class Candidates": I drafted a JEP that lists candidates for inline class migration and describes the compiler and runtime warnings needed to prepare for their migration

Remi wondered whether changing the semantics of '==' for wrapper classes will be a problem. Answer: constructors will be deprecated; for the small integers (-128 to 127?) produced by 'valueOf', == will have the same behavior; for the large integers produced by 'valueOf', behavior of == is currently unspecified, so we're fine to change behavior.

There's a consensus that we should probably track the inline class candidates (or maybe all value-based classes?) with an annotation.

> 
> - "Revisiting default values": I described use cases for different treatments of inline types' default values, and then summarized various strategies for supporting some of the nontrivial use cases

General agreement that the "Bucket #3" group (classes without a natural default) is what we should focus on, not the "Bucket #2" group (classes that want a nontrivial default).

We talked through various "Bucket #3" approaches. The preferred approaches seem to be:

- Guards on member access, either compiler-generated or JVM-enforced. Fields and default methods require special attention. (May involve making the invalid default equivalent to "null", but there are complexity concerns.)

- Tracking uninitialized fields/arrays in the JVM. There's concern about performance of array reads, best optimization might be adding a boolean "isInitialized" flag to each flattened value. There's also concern about tearing producing unexpected default values in corner cases, possibly mitigated with our story for atomicity.

- Bucket #3 classes must be reference-default, and fields/arrays of their inline type are illegal outside of the declaring class. The declaring class can provide a flat array factory if it wants to. (A new idea from Tobi, he'll write it up for the thread.)