Skip to content
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

Merged
merged 7 commits into from
Oct 28, 2022
Merged

Conversation

szymon-rd
Copy link
Contributor

@szymon-rd szymon-rd commented May 26, 2022

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

@szymon-rd
Copy link
Contributor Author

szymon-rd commented May 26, 2022

@odersky Created this as a new PR with source branch at dotty-staging so you can edit it.

@szymon-rd szymon-rd self-assigned this May 26, 2022
Copy link
Contributor

@odersky odersky left a 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.

@Kordyjan Kordyjan assigned sjrd and unassigned szymon-rd May 26, 2022
Copy link
Member

@sjrd sjrd left a 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.

@prolativ
Copy link
Contributor

prolativ commented Jun 1, 2022

test performance please

1 similar comment
@bishabosha
Copy link
Member

test performance please

@dottybot
Copy link
Member

dottybot commented Jun 1, 2022

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

@dottybot
Copy link
Member

dottybot commented Jun 1, 2022

Performance test finished successfully:

Visit https://dotty-bench.epfl.ch/15296/ to see the changes.

Benchmarks is based on merging with main (89c3c10)

@szymon-rd
Copy link
Contributor Author

test performance please

@dottybot
Copy link
Member

dottybot commented Jun 1, 2022

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

@allanrenucci
Copy link
Contributor

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.

@szymon-rd
Copy link
Contributor Author

@allanrenucci thanks, I will use it

@dottybot
Copy link
Member

dottybot commented Jun 1, 2022

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)
Copy link
Member

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.

@szymon-rd szymon-rd force-pushed the new-lazy-vals branch 2 times, most recently from e94d78c to 71c7747 Compare June 6, 2022 14:23
@szymon-rd
Copy link
Contributor Author

test performance please

@dottybot
Copy link
Member

dottybot commented Jun 6, 2022

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

@dottybot
Copy link
Member

dottybot commented Jun 6, 2022

Performance test finished successfully:

Visit https://dotty-bench.epfl.ch/15296/ to see the changes.

Benchmarks is based on merging with main (e71fe80)

@szymon-rd
Copy link
Contributor Author

szymon-rd commented Jun 8, 2022

@allanrenucc I think that some files may be missing on this branch - LazyVolatile and LazySimCellWithPublicBitmap are not there. Do you happen to know where to find them?

@allanrenucci
Copy link
Contributor

I don't fully remember what these objects refer to. LazyVolatile looks very similar to scala.runtime.LazyVals. Not sure about LazySimCellWithPublicBitmap .

@szymon-rd
Copy link
Contributor Author

@sjrd I responded to / applied all of your comments. Could you take a look?

Copy link
Member

@sjrd sjrd left a 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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* 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() =
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* 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]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
* return current.asInstanceOf[A]
* return current

Comment on lines 413 to 414
Block(ValDef(resSymb, nullLiteral) :: ValDef(resSymbNullable, nullLiteral) :: evaluate :: Nil, // var result: AnyRef = null
Return(ref(resSymbNullable), lazyInitMethodSymbol)), // try ... finally ...
Copy link
Member

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.

@szymon-rd szymon-rd force-pushed the new-lazy-vals branch 5 times, most recently from dedf464 to c791c55 Compare October 28, 2022 13:40
@szymon-rd
Copy link
Contributor Author

@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.

@szymon-rd szymon-rd merged commit 5bd67bb into scala:main Oct 28, 2022
@szymon-rd szymon-rd deleted the new-lazy-vals branch October 28, 2022 15:58
@SethTisue
Copy link
Member

SethTisue commented Oct 28, 2022

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?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

@transient lazy val does not get marked as ACC_TRANSIENT