-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
New lazy vals implementation #15296
New lazy vals implementation #15296
Conversation
@odersky Created this as a new PR with source branch at |
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.
It looks overall good to me but I was not able to check details for lack of time. Can someone else give it a thorough go-over? If this is going to be the new implementation of LazyVals, it would be good to get one more person to know in detail what it does.
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.
Overall, this looks good. I have some suggestions here and there.
What would it take to leave the old implementation available under a Java system property? In the past in Scala 2, performance-risky changes like this had a fallback on the old implementation that could be enabled with a Java system property (or a compiler flag). I think this is a situation that would benefit from such an escape hatch.
test performance please |
1 similar comment
test performance please |
performance test scheduled: 7 job(s) in queue, 1 running. |
Performance test finished successfully: Visit https://dotty-bench.epfl.ch/15296/ to see the changes. Benchmarks is based on merging with main (89c3c10) |
test performance please |
performance test scheduled: 6 job(s) in queue, 1 running. |
A few years ago, I wrote micro-benchmarks for Dotty lazy val implementations: https://github.com/allanrenucci/dotty-benchmark/tree/lazy-vals-v2 You may be interested in running these benchmarks against the new implementation. |
@allanrenucci thanks, I will use it |
Performance test finished successfully: Visit https://dotty-bench.epfl.ch/15296/ to see the changes. Benchmarks is based on merging with main (3ddb21c) |
@@ -43,22 +45,21 @@ object LazyVals { | |||
* evaluated and of which other threads await the result. | |||
*/ | |||
final class Waiting: | |||
private var done = false | |||
private val countDownLatch: CountDownLatch = new CountDownLatch(1) |
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.
Any reason to use a field instead of extends CountDownLatch(1)
? The field adds one extra level of pointer-chasing.
e94d78c
to
71c7747
Compare
test performance please |
performance test scheduled: 1 job(s) in queue, 1 running. |
Performance test finished successfully: Visit https://dotty-bench.epfl.ch/15296/ to see the changes. Benchmarks is based on merging with main (e71fe80) |
@allanrenucc I think that some files may be missing on this branch - |
I don't fully remember what these objects refer to. |
4cbce0d
to
dbdf38f
Compare
@sjrd I responded to / applied all of your comments. Could you take a look? |
dbdf38f
to
28abd42
Compare
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.
Looks great, thanks! I only have very minor comment-related comments left.
Could you also rebase on main
so that there is no merge commit appearing in the PR? In fact, it looks like it would be better to squash all the commits of this PR anyway, at this point.
* else if result.eq(NullValue) then | ||
* null // possible unboxing applied here | ||
* else | ||
* return x_compute() // possible unboxing applied here |
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.
* return x_compute() // possible unboxing applied here | |
* x_compute() // possible unboxing applied here |
* else | ||
* return x_compute() // possible unboxing applied here | ||
* | ||
* private def x_compute() = |
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.
* private def x_compute() = | |
* private def x_compute(): AnyRef = |
so that we don't have to guess?
* current.asInstanceOf[Waiting].await() | ||
* else return null | ||
* else | ||
* return current.asInstanceOf[A] |
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.
* return current.asInstanceOf[A] | |
* return current |
Block(ValDef(resSymb, nullLiteral) :: ValDef(resSymbNullable, nullLiteral) :: evaluate :: Nil, // var result: AnyRef = null | ||
Return(ref(resSymbNullable), lazyInitMethodSymbol)), // try ... finally ... |
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.
The comments on the right do not match up anymore.
dedf464
to
c791c55
Compare
Pre-review lazy vals adjustments
c791c55
to
955c0be
Compare
955c0be
to
f62ffd8
Compare
@sjrd I applied your suggestions, squashed some of the commits (I kept the most important "pieces" but squashed all the smaller adjustments). I also rebased on the main. |
Congrats on landing this! 🎉 Curious... is the PR description for #6979 still the best place for users to read about what this change is and what implications it might have for their libraries and applications? (Or are we confident there aren't any implications for users?) |
Based on #14545
Implementing the new lazy vals scheme mentioned in #6979, fixing #7140
New PR to avoid force pushing to main branch of the previous contributor.
Fixes #15149 as well
Applied #14780