Inlined code shouldn't forget null-check on the original receiver #5850
Comments
Imported From: https://issues.scala-lang.org/browse/SI-5850?orig=1 |
@magarciaEPFL said:
I'm favoring the second alternative. Just for the record, the snippets for each alternative: / /Addition_to_Inliners.scala
val NPEClass = definitions.NullPointerExceptionClass
val nwNPE = NEW(REFERENCE(NPEClass))
val npeInit = definitions.getMember(NPEClass, nme.CONSTRUCTOR).suchThat(_.paramss == List(Nil))
assert(npeInit != NoSymbol, "Couldn't find the no-args constructor of NullPointerException.")
val cmNPEInit = CALL_METHOD(npeInit, Static(true))
nwNPE.init = cmNPEInit
val npeBlock = newBlock()
npeBlock.emit(nwNPE, instr.pos)
npeBlock.emit(DUP(REFERENCE(NPEClass)), instr.pos)
npeBlock.emit(cmNPEInit, instr.pos)
npeBlock.emit(THROW(NPEClass), instr.pos)
npeBlock.close() // Addition_to_ScalaRunTime.scala
def nullCheck(x: AnyRef) {
if (x == null) throw new NullPointerException
} |
@magarciaEPFL said: |
@ijuma said: |
@magarciaEPFL said: The type-flow analysis should track non-nullness. I was planning to update the TFA anyway (to also track whether a type is exact, ie after new). Only then can this bug be closed. |
@ijuma said: In theory, null checks are free, but there is the added bytecode size. See: "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.) https://wikis.oracle.com/display/HotSpotInternals/PerformanceTechniques |
@magarciaEPFL said: |
@ijuma said: |
@JamesIry said: |
the println doesn't run in 2.12 |
Running the program below should result in NPE, however under
-optimize
theprintln
statement is executed.@VladUreche, watch out for a similar situation when rewriting tail calls.
The text was updated successfully, but these errors were encountered: