Skip to content

Conversation

@gatorsmile
Copy link
Member

What changes were proposed in this pull request?

We should make codegen fallback of expressions configurable. So far, it is always on. We might hide it when our codegen have compilation bugs. Thus, we should also disable the codegen fallback when running test cases.

How was this patch tested?

Added test cases

GeneratePredicate.generate(expression, inputSchema)
} catch {
case e @ (_: JaninoRuntimeException | _: CompileException)
if sqlContext == null || sqlContext.conf.wholeStageFallback =>
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because sqlContext is always null when running it in executors, and thus, this always return true.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removing the null check here makes sense although this means existing spark jobs that were previously switching to the non-codegen version even with sqlContext.conf.wholeStageFallback = false will now start failing at runtime (perhaps, rightly so). Might be worth calling this out in the 2.3 release notes and/or the migration guide.

"TestSQLContext",
new SparkConf()
.set("spark.sql.test", "")
.set(SQLConf.CODEGEN_FALLBACK.key, "false")
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Turn it false to ensure it does not hide the actual bugs of our expression codegen that causes compilation falure.

@gatorsmile
Copy link
Member Author

cc @kiszk @cloud-fan @zsxwing

final val sqlContext = SparkSession.getActiveSession.map(_.sqlContext).orNull

// whether we should fallback when hitting compilation errors caused by codegen
private val codeGenFallBack = sqlContext == null || sqlContext.conf.codegenFallback
Copy link
Member

@kiszk kiszk Aug 27, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it better to add !Utils.isTesting && or to drop !Utils.isTesting && from WholeStageCodegenExec to make these conditions consistent?

Copy link
Member Author

@gatorsmile gatorsmile Aug 27, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Originally, I did it like what you said. However, if using that approach, I need to remove the test case. Then, I think we might just keep using the codegenFallback for controlling it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see

@SparkQA
Copy link

SparkQA commented Aug 27, 2017

Test build #81158 has finished for PR 19062 at commit 9f3a1cd.

  • This patch passes all tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

Copy link
Member

@dongjoon-hyun dongjoon-hyun left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, LGTM.

@heary-cao
Copy link
Contributor

heary-cao commented Aug 27, 2017

LGTM

1 similar comment
@maropu
Copy link
Member

maropu commented Aug 28, 2017

LGTM

// sqlContext will be null when we are being deserialized on the slaves. In this instance
// the value of subexpressionEliminationEnabled will be set by the deserializer after the
// constructor has run.
val subexpressionEliminationEnabled: Boolean = if (sqlContext != null) {
Copy link
Member Author

@gatorsmile gatorsmile Aug 29, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cc @marmbrus @cloud-fan Does this sound OK? Currently, our codebase does not check nullability in most places. This value will be always not null when we initialize the value.

@SparkQA
Copy link

SparkQA commented Aug 29, 2017

Test build #81229 has finished for PR 19062 at commit 26dcbd6.

  • This patch fails Spark unit tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@SparkQA
Copy link

SparkQA commented Aug 29, 2017

Test build #81230 has finished for PR 19062 at commit 4f39a52.

  • This patch passes all tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@gatorsmile
Copy link
Member Author

Thanks! Merging to master.

@asfgit asfgit closed this in 3d0e174 Aug 30, 2017
@srowen
Copy link
Member

srowen commented Aug 30, 2017

I think this makes the master build fail @gatorsmile :

https://amplab.cs.berkeley.edu/jenkins/view/Spark%20QA%20Test%20(Dashboard)/job/spark-master-test-maven-hadoop-2.7/

*** RUN ABORTED ***
  java.lang.RuntimeException: Unable to load a Suite class that was discovered in the runpath: org.apache.spark.sql.execution.PlannerSuite
  at org.scalatest.tools.DiscoverySuite$.getSuiteInstance(DiscoverySuite.scala:84)
  at org.scalatest.tools.DiscoverySuite$$anonfun$1.apply(DiscoverySuite.scala:38)
  at org.scalatest.tools.DiscoverySuite$$anonfun$1.apply(DiscoverySuite.scala:37)
  at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:234)
  at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:234)
  at scala.collection.Iterator$class.foreach(Iterator.scala:893)
  at scala.collection.AbstractIterator.foreach(Iterator.scala:1336)
  at scala.collection.IterableLike$class.foreach(IterableLike.scala:72)
  at scala.collection.AbstractIterable.foreach(Iterable.scala:54)
  at scala.collection.TraversableLike$class.map(TraversableLike.scala:234)
  ...
  Cause: java.lang.NullPointerException:
  at org.apache.spark.sql.execution.SparkPlan.<init>(SparkPlan.scala:60)
  at org.apache.spark.sql.execution.DummySparkPlan.<init>(PlannerSuite.scala:638)
  at org.apache.spark.sql.execution.PlannerSuite.<init>(PlannerSuite.scala:484)
  at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
  at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
  at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
  at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
  at java.lang.Class.newInstance(Class.java:442)
  at org.scalatest.tools.DiscoverySuite$.getSuiteInstance(DiscoverySuite.scala:69)
  at org.scalatest.tools.DiscoverySuite$$anonfun$1.apply(DiscoverySuite.scala:38)

@gatorsmile
Copy link
Member Author

Thanks! Let me first revert this PR.

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.

8 participants