Skip to content

Fix #2563: Unconditionally emit mixin forwarders #6081

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

Merged
merged 3 commits into from
Mar 18, 2019

Conversation

smarter
Copy link
Member

@smarter smarter commented Mar 12, 2019

This PR is a draft because it depends on #6079, only the last three commits are new.

@smarter smarter force-pushed the mixin-force-forwarders-2 branch from ab689a4 to 2b27e3e Compare March 12, 2019 13:59
@smarter smarter requested a review from odersky March 12, 2019 14:37
@smarter smarter marked this pull request as ready for review March 12, 2019 15:18
@smarter
Copy link
Member Author

smarter commented Mar 12, 2019

test performance please

@dottybot
Copy link
Member

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

@dottybot
Copy link
Member

Performance test finished successfully:

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

Benchmarks is based on merging with master (3c9935f)

@odersky odersky assigned smarter and unassigned odersky Mar 17, 2019
@smarter smarter force-pushed the mixin-force-forwarders-2 branch from 2b27e3e to e70b6e4 Compare March 18, 2019 14:04
smarter added 3 commits March 18, 2019 15:49
This controls when mixin forwarders are generated like the homonymous
flag in scalac, for now we default to "junit" to keep our existing
behavior, next commit will change it to "true" to match scalac.
This is what Scala 2.12+ does for cold performance reasons (see scala#5928
for more details) and we should align ourselves with them when possible.

About two years ago in scala#2563, Dmitry objected that we may not need to do
that if we found another way to get performance back, or if newer JDKs
improved the performance of default method resolution. It doesn't look
like these things have happened so far (but there's some recent glimmer
of hope here: https://bugs.openjdk.java.net/browse/JDK-8036580).

Dmitry also said "I don't recall triggering bugs by emitting more
forwarders rather then less.", but in fact since then I've found one
case where the standard library failed to compile with extra forwarders
causing name clashes, requiring a non-binary-compatible change:
scala/scala@e3ef657.
As of scala#6079 this is no longer a problem since we now emit mixin
forwarders after erasure like scalac, but it still seems prudent to emit
as many forwarders as scalac to catch potential name clash issues.
Now that -Xmixin-force-forwarders defaults to true, tests that showcase
some behavior of mixin forwarders can be simplified since we need less
indirections to generate them.
@smarter smarter force-pushed the mixin-force-forwarders-2 branch from e70b6e4 to 22db0c0 Compare March 18, 2019 14:50
@smarter smarter merged commit b13c235 into scala:master Mar 18, 2019
@allanrenucci allanrenucci deleted the mixin-force-forwarders-2 branch March 18, 2019 16:44
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.

3 participants