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
Reduce allocations of AsSeenFromMap / FindMember / SubstSymMap #498
Comments
Here's what I've got in mind. scala/scala@9766d5d...retronym:faster/one-elem-cache |
I've taken a look at what would be needed to have the VM do this for us, with inlining and escape analysis. One can use JITWatch: object Test {
val g = new scala.tools.nsc.Global(new scala.tools.nsc.Settings)
g.settings.usejavacp.value = true
import g._
def main(args: Array[String]) {
new Run()
while (true) {
test()
}
}
def test() {
typeOf[String].members
typeOf[String].member(TermName("charAt"))
typeOf[String].hasNonPrivateMember(TermName("charAt"))
}
}
For escape analysis to kick in, we need With default VM options, we find this doesn't happen. Typically the reason in "already compiled into a big method". This means that a helper method within We can force inlining with a compiler control hint: scala -J-XX:CompileCommand='inline scala.reflect.internal.tpe.FindMembers$FindMemberBase::*' ... In which case we eventually can see escape analysis kick in: (The Graal EE does a bit better at getting inlining some, but not all of these instances. Currently, HotSpot's profiling doesn't gather data about how much an allocation site contributes to the allocation rate of short lived objects. If it did, Graal could conceivably try harder to inline the allocation away. |
Even after 30+ iterations, I was unable to get the JIT to eliminate these allocations. Add in the single-element cache that could be used for scala/scala-dev#498.
Even after 30+ iterations, I was unable to get the JIT to eliminate these allocations. Add in the single-element cache that could be used for scala/scala-dev#498.
Even after 30+ iterations, I was unable to get the JIT to eliminate these allocations. Add in the single-element cache that could be used for scala/scala-dev#498.
Even after 30+ iterations, I was unable to get the JIT to eliminate these allocations. Add in the single-element cache that could be used for scala/scala-dev#498.
I feel like I've seen PRs and 2.12/2.13 differences around this (from @diesalbla and @hrhino's handiwork?). Is this done / happy to close it now? |
@dwijnand So, here are some Pull Requests done to reduce the number of objects created:
One last open Pull Request, scala/scala#9039, should further reduce the number of |
It might be worth having a one-element cache in
Global
for each of these. We'd need to make them reusable (ie, the fields become vars and we add areset
method to assign new values).The code in these can re-enter, at least through lazy type completers, so we either need to keep a stack of reusable ones, or simply just allocate for the re-entrant cases.
The text was updated successfully, but these errors were encountered: