-
Notifications
You must be signed in to change notification settings - Fork 3.1k
More elegant holders for local lazy vals. #5374
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
LGTM! |
LGTM |
|
||
class LazyRef[T] { | ||
var value: T = _ | ||
@volatile var initialized: Boolean = false | ||
@volatile private[this] var _initialized: Boolean = _ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this @volatile btw?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Quoting @retronym:
In double checked locking, the write to the value is in a synchronized block
the fast path (already initialized) just needs to volatile read on the initialized field. if that is set, we know the value was safely published
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apologies, I guess what threw me of course is that this class (or rather these classes) are public, and non-final, classes which cannot be used properly without sprinkling of "magic"/macros. Are these intended to be possible to use directly by users?
There was a problem hiding this comment.
Choose a 10000 reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True, the runtime package is not meant for public consumption. Good point
that they should likely be final. They have to be public though, as they
are referenced from compiler-generated code.
Reduce the amount of code generated for local lazy val by moving some of the generated code to the runtime library. This is a port of scala/scala#5374
Reduce the amount of code generated for local lazy val by moving some of the generated code to the runtime library. This is a port of scala/scala#5374
Reduce the amount of code generated for local lazy val by moving some of the generated code to the runtime library. This is a port of scala/scala#5374
Reduce the amount of code generated for local lazy val by moving some of the generated code to the runtime library. This is a port of scala/scala#5374
Reduce the amount of code generated for local lazy val by moving some of the generated code to the runtime library. This is a port of scala/scala#5374
Reduce the amount of code generated for local lazy val by moving some of the generated code to the runtime library. This is a port of scala/scala#5374
Reduce the amount of code generated for local lazy val by moving some of the generated code to the runtime library. This is a port of scala/scala#5374
Reduce the amount of code generated for local lazy val by moving some of the generated code to the runtime library. This is a port of scala/scala#5374
Reduce the amount of code generated for local lazy val by moving some of the generated code to the runtime library. This is a port of scala/scala#5374
Reduce the amount of code generated for local lazy val by moving some of the generated code to the runtime library. This is a port of scala/scala#5374
Follow up for #5294 based on @retronym's feedback.
I'm going to defer teaching the optimizer about stack allocating the lazy holders: scala/scala-dev#215