Re-implement lazy vals.

[odersky]

• Do a prototype implementation of lazy vals along the lines of Test a new scheme to implement lazy vals #6979.
• Validate its correctness.
• Benchmark its performance.

[liufengyun]

Once this is implemented, we should address one TODO in the following PR:

https://github.com/lampepfl/dotty/pull/9181/files#diff-8dc5ee2dbf11efaad4326519edfa4e45R132

The problem is that the current encoding assumes bitmap fields are non-static, thus in #9181 we cannot mark all fields of module classes as static.

[olsdavis]

Hi, I'm currently working on this, assuming the latest scheme is in this file, in the heading comment. Implementing it, I have realized I would need to sort a few things out (I will be referring to lines in the code I linked):

• in case Evaluating, why is the CAS performed on x instead of _x? I guess it's a small typo;
• in case current: Waiting, why is _x assigned to current.awaitRelease(), given that the latter returns Unit? I believe this is a trace of the first version of the new scheme;
• in case null, how to assign the special value NULL to result, given it is of type A? I have assumed that Evaluating and NULL could be represented as runtime objects, leveraging the AnyRef type of _x like the class Waiting does; but maybe there is a better way to represent these states. If using objects isn't an issue, then maybe we could/should change result to an AnyRef.

[olsdavis]

Hi, I've also noticed that PatternMatcher comes before LazyVals, so I guess I will have to express it directly with if s.

[olsdavis]

I'm having some trouble with the following:

Unsafe's compareAndSwapObject seems to be much more adapted for object fields: its first argument must be the instance containing the field to perform the CAS on. It seems that passing the class object (i.e. TheClass.class in Java) as a first argument works in order to update a static field (that isn't of a primitive type); however, this answer suggests that an extra Object obtained by calling staticFieldBase should be used to safely access a static field when using CAS. (It also points out the issue that some Unsafe methods have been replaced since Java 9, which creates another problem for maintainability.)

Therefore, should an extra field be created to store this extra Object for static lazy vals? Or maybe a static field can be avoided in the first place?

[odersky]

You mean for local lazy vals? I think we might need to box them, which means we have an enclosing object for them. Note that the current lazyvals implementation does the same thing.