[BEAM-6104] Use a very large stack for compiling Beam

[kennknowles]

This seems to alleviate occasional pain from stack overflows in javac when compiling generated SQL parsing code. I had assumed it was an accidental infinite recursion, but it is actually just extremely deep nesting in the generated code, which has 500+ deep nested conditionals.

On OSX the default size is 1024k so I just 10x it.

---

Follow this checklist to help us incorporate your contribution quickly and easily:

• Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
• If this contribution is large, please file an Apache Individual Contributor License Agreement.

It will help us expedite review of your Pull Request if you tag someone (e.g. @username) to look at it.

Post-Commit Tests Status (on master branch)

Lang	SDK	Apex	Dataflow	Flink	Gearpump	Samza	Spark
Go		---	---	---	---	---	---
Java
Python		---			---	---	---

[kennknowles]

R: @akedin @apilloud @xumingmin @amaliujia

Some of you may have hit this issue?

CC: @lukecwik

This could be scoped to just the SQL module, since it is the output of the parser generator. I didn't try to look up any gradle-fu to do this, since it seems fine to just use a big stack for compiling.

[amaliujia]

LGTM

[akedin]

Lgtm.

I mostly see this error on osx, but I use osx most of the time. I may be wrong, but I believe others have seen this on other platforms as well. And I've only seen this in relation to sql and don't remember people complaining about it for other modules.

My only question is why does it ever compile in this case, why not 100% repro?

[mingmxu]

LGTM

It happens quite often in SQL module in my OSX, so I have this change locally everytime. Btw, it's duplicated with https://issues.apache.org/jira/browse/BEAM-6025.

[mingmxu]

@akedin the build does pass with a pre clean step. I guess that's why CI jobs pass mostly.

The cmd is another option I use:
./gradlew clean; ./gradlew -p sdks/java/extensions/sql check;

[lukecwik]

nit: Should this be -Xss since -XX:flags are JVM implementation dependent?

[amaliujia]

quote from https://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html:

Options that are specified with -XX are not stable and are subject to change without notice

[kennknowles]

Ah, OK I will change it. I chose the long form just to be super clear, but stability & portability are more important.

[lukecwik]

Doesn't seem to make sense to limit this to just SQL.

[kennknowles]

@akedin FWIW once I get it to happen, I do have 100% repro and I get blocked. That is why I found the time to try to fix :-). I don't know why a clean helps, but that is good to know too.