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

no null-check and straight to eq when matching on constant pattern with synthetic equals #6508

Closed
scabug opened this issue Oct 10, 2012 · 5 comments

Comments

@scabug
Copy link

scabug commented Oct 10, 2012

from https://groups.google.com/d/topic/scala-internals/ysNnBpYQwCY/discussion

   We can special-treat some common patterns however. If the scrutinee is a List and the
   pattern is a Nil then we know that we can get by with an instanceof or eq comparison.
   Same for None in Option. Same again for any case object that gets the synthesized
   equals instead of a user-defined one.
   Because these cases should be quite common it's probably worth to do it.

when a constant pattern is statically known to have a synthetic equals method that simply calls eq, do not perform a null check and call eq directly.

similarly, an instanceof check implies non-nullness, so don't re-check null

#6508

Yes, or instanceof. - Martin

@scabug
Copy link
Author

scabug commented Oct 10, 2012

Imported From: https://issues.scala-lang.org/browse/SI-6508?orig=1
Reporter: @odersky

@scabug
Copy link
Author

scabug commented Oct 10, 2012

@adriaanm said:
however, https://wikis.oracle.com/display/HotSpotInternals/PerformanceTechniques

Low-level safety checks
Null checks are cheap. They usually fold straight into a related memory access instruction, and use the CPU bus logic to catch nulls. (Deoptimization follows, with regenerated code containing an explicit check.)
User-written null checks are in most cases functionally identical to those inserted by the JVM.
Null checks can be hoisted manually, and suppress implicit null checks in dominated blocks.
Similar points can be made about other simple predicates, like class checks and range checks.
All such checks, whether implicit or manually written, are aggressively folded to constants.

@scabug
Copy link
Author

scabug commented Oct 10, 2012

@adriaanm said:
Greg rightfully points out that we should still try to reduce the amount of bytecode we emit
also, cutting extraneous checks means the JIT doesn't have to spend time optimizing them

@scabug
Copy link
Author

scabug commented Oct 24, 2012

@adriaanm said:
note that we must still test outer pointers, so this optimization probably does not make sense for nested objects (that appear as constant patterns)

@scabug
Copy link
Author

scabug commented Jan 30, 2013

@adriaanm said:
unfortunately, I can't reproduce without the original source code

I've been looking at possible inefficiencies and the only one I could find (without changing the spec)
is reported in #6941, so I'm going to close this one as a duplicate unless evidence appears it's something else

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

No branches or pull requests

2 participants