Make lazy vals thread-safe by default

[smarter]

Previously this required using @volatile but that would not be
consistent with Scala 2. The old behavior of non-volatile lazy vals can
be recovered by using the newly-introduced @threadUnsafe.

[smarter]

test performance please

[dottybot]

performance test scheduled: 2 job(s) in queue, 1 running.

[dottybot]

Performance test finished successfully:

Visit http://dotty-bench.epfl.ch/6579/ to see the changes.

Benchmarks is based on merging with master (6ede814)

[odersky]

test performance please

[dottybot]

performance test scheduled: 3 job(s) in queue, 1 running.

[dottybot]

Performance test finished successfully:

Visit http://dotty-bench.epfl.ch/6579/ to see the changes.

Benchmarks is based on merging with master (2984e57)

[odersky]

I am still concerned that the compile time trend here is upwards. If lazy vals in Definitions are not the problem, where else would they be one?

[odersky]

My first suspect would be

    lazy val typeParams: List[LambdaParam] =
      paramNames.indices.toList.map(new LambdaParam(this, _))

in Types.scala. Then the lazy vals in Applications.scala and Implicits.scala, as well as the lazy vals defined in the Backend. Maybe make all of these @ThreadUnsafe as well?

[odersky]

The changes look good to me, but let's try to tweak performance a bit more before merging.

[odersky]

test performance please

[dottybot]

performance test scheduled: 1 job(s) in queue, 0 running.

[dottybot]

Performance test finished successfully:

Visit http://dotty-bench.epfl.ch/6579/ to see the changes.

Benchmarks is based on merging with master (c165638)

[nafg]

It seems unfortunate to allocate a general-sounding name like threadUnsafe exclusively for use on lazy vals. What about something more specific, like simpleLazy or unsafeLazy?

[smarter]

Nothing prevents us from reusing it to work on other things than lazy vals. It's documented as only working on lazy vals since it's the only place where it does something currently.

[nafg]

Interesting -- do you have any examples in mind?

…

On Sun, Jun 2, 2019, 5:24 PM Guillaume Martres ***@***.***> wrote: Nothing prevents us from reusing it to work on other things than lazy vals. It's documented as only working on lazy vals since it's the only place where it does something currently. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#6579>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAYAUHB6IQESMWFGKPGBHTPYQ27ZANCNFSM4HQE5LHA> .

[smarter]

Nope

[smarter]

@odersky OK to merge ?

[odersky]

@smarter It's OK to merge. I still would have liked to go to the bottom of the performance regressions. E.g. Re2 is clearly worse. I wonder where that could come from. But it's not urgent, we can do it later