Set stack size to 16M

[AdRiley]

Pull Request Description

This PR attempts to fix the SQLServer tests which seem to be right on the limit of the default stack size.

Before this change

runEngineDistribution --run C:/Code/enso/test/Microsoft_Tests/src/SQLServer_Spec.enso shown.in.the.doc.example

would stack overflow indeterministically.

If I make this change -Xss512k then that test always stack overflows.

I'm not quite sure why I need to add this change here as .jvmopts looks to already attempts to set the stack size to 16M.

Important Notes

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

• The documentation has been updated, if necessary.
• Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
• All code follows the
  Scala,
  Java,
  TypeScript,
  and
  Rust
  style guides. In case you are using a language not listed above, follow the Rust style guide.
• Unit tests have been written where possible.

[JaroslavTulach]

@AdRiley you haven't increased the size of stack when launched from project-manager - e.g. when used in the IDE the stack size will still default to Java default.

[JaroslavTulach]

I'm not quite sure why I need to add this change here as .jvmopts looks to already attempts to set the stack size to 16M.

Are you talking about this .jvmopts file. I guess it is only good for sbt - at least that the impression I get from the blame output. CCing @Akirathan

[JaroslavTulach]

Why have you decided to set the stack value to 16M when the experiments I have seen indicate that 2M would be enough?

[AdRiley]

@AdRiley you haven't increased the size of stack when launched from project-manager - e.g. when used in the IDE the stack size will still default to Java default.

@radeusgd indicated distribution/manifest.template.yaml would do this. Is there another spot?

[AdRiley]

Why have you decided to set the stack value to 16M when the experiments I have seen indicate that 2M would be enough?

There were existing other places in our codebase where we set it to 16M so given I was making up a number I copied those for consistency. I'm happy to change this to something smaller if you think that is better?

[JaroslavTulach]

Alternative suggestion to increasing stack size would be

• Convert Array_Like_Helpers.map to a builtin to reduce stack size #11329

that would lower the amount of Java stack elements by ten to twenty per each map. @AdRiley are you using map? Is there many map & co. invocations in your stacktrace.

[JaroslavTulach]

There were existing other places in our codebase where we set it to 16M

.jvmopts? That's completely unrelated.

[AdRiley]

Alternative suggestion to increasing stack size would be

• Convert Array_Like_Helpers.map to a builtin to reduce stack size #11329

that would lower the amount of Java stack elements by ten to twenty per each map. @AdRiley are you using map? Is there many map & co. invocations in your stacktrace.

I think there was 3. One in the test framework and 2 in my code.

[JaroslavTulach]

I think there was 3. One in the test framework and 2 in my code.

That's very little. Btw. can you share the stacktrace (Java as well as Enso) somewhere? Maybe we can find other places which might benefit from an optimization (Boolean.if_then_else comes to my mind first).