You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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.
@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
@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)
@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
from https://groups.google.com/d/topic/scala-internals/ysNnBpYQwCY/discussion
when a constant pattern is statically known to have a synthetic equals method that simply calls
eq
, do not perform a null check and calleq
directly.similarly, an instanceof check implies non-nullness, so don't re-check null
#6508
Yes, or instanceof. - Martin
The text was updated successfully, but these errors were encountered: