Offer optimistic locking for lazy vals

[puffnfresh]

Lazy vals use double-locking to ensure they are evaluated and evaluated only once. This imposes a small cost on every subsequent access, so there is a cumulative performance gain to be had. We should provide the option of avoiding the second lock, at the risk of incurring multiple evaluations.

I think the current behavior (correctness/predictability) should remain the default, and single-locking (performance) should be an opt-in, using an annotation, for example something like:

@optimistic lazy val x = { /* evaluate */ }

Any thoughts?

[jdegoes]

What about a @pure annotation which would be more broadly applicable? Compiler has a lot more optimization options if it knows something is pure -- optimistic locking is just one example.

[puffnfresh]

@jdegoes that's a sensible idea.

[paulp]

The real winner with lazy vals would be to rescue the 90+% of lazy vals which are not intended to be lazy from paying synchronization costs on every access until the end of time. It's pretty nuts if you think about it.

Very few of the lazy vals I have seen in the wild (and I have seen a lot of them) are lazy because it's relevant that the evaluation is delayed. They are lazy to avoid NPEs and cycles. The two major brands of problem which you would encounter if there were no lazy vals are inter-file (mixin composition) and intra-file, as in e.g. Definitions.scala, any nontrivial parser combinator, etc etc.

The first one is probably hard, but the second one isn't. The compiler can do the dependency analysis of what needs to come before what and then just order them. All you need is a way for the user to indicate it.

[propensive]

@paulp Good point, though is the dependency analysis genuinely easy? What if a val calls a virtual method whose implementation isn't known at compile time, and refers to something else in the dependency graph?

[paulp]

@propensive It's easy because it's impossible for the compiler to do anything with that, so you won't be surprised to find the burden is on you. It's the kind of thing you'd opt into and which would come with warning labels (and it could tell you useful things like the set of unknown method implementations to which you are vulnerable.)

[propensive]

@paulp Seems reasonable. So we'd replace all the lazy vals with @reorderable vals (or something like that), and the compiler would give us a load of warnings whenever we refer to something it can't analyze? Apart from my unverified suspicion that you just wouldn't be able to do anything useful most of the time with such a constraint, I'm very much in favor of it as a solution.

[propensive]

@jdegoes @puffnfresh I'd love a @pure annotation too if we could actually make use of it. But purity analysis is nontrivial (though could be framed as a dependent-typing problem, maybe?) and I'm tempted to believe it wouldn't be useful most of the time. Nevertheless, I really think it should be explored.

[jdegoes]

@propensive A @pure annotation wouldn't be checked, that's too hard, it would just be a promise the value is pure which would enable the compiler to perform optimistic locking on lazy vals, memoization on def'd vals, duplicate expression elimination, etc.

[paulp]

In that case I already implemented it: scala#2416

[propensive]

@jdegoes I wouldn't want to rule out the possibility of a checked @pure annotation until I'd tried it. Purity guarantees would be so valuable that it could be worth the effort and the risk of failure.

[propensive]

See @odersky's comments on plans for (@volatile) lazy vals in Scala Don Giovanni on #20

[aryairani]

+1 (are +1's helpful? I know they're not as helpful as pull requests...)

[milessabin]

To resurrect this issue, please rework it as an issue/PR against Lightbend Scala (ie. scala/scala).