use --no-server and set Xmx to a higher value when invoking native-image #370
Conversation
| @@ -132,6 +132,8 @@ public boolean compile(String cp) throws IOException, InterruptedException { | |||
| } | |||
| compileRunner.addArg("--report-unsupported-elements-at-runtime"); | |||
| compileRunner.addArg("-Djdk.internal.lambda.eagerlyInitialize=false"); | |||
| compileRunner.addArg("--no-server"); | |||
| compileRunner.addArg("-J-Xmx24G"); | |||
There was a problem hiding this comment.
why 24G? Wouldn't it depend on the user's machine? Maybe we need some system property to set it?
There was a problem hiding this comment.
I'm ok with a system property that, if set, can overrule this value. But we still need a default.
@lazar-mitrovic do you think 24G is an ok default?
There was a problem hiding this comment.
I had issues when building on older llvm with graalpython included, where I had to bump it to > 40G (with swap enabled).
If you look at SubstrateVM's source it is clamped down to 80% of user memory, so maybe bumping this up to something crazy high like 128G wouldn't be a bad idea.
There was a problem hiding this comment.
Or omitting Xmx since docs state that using only --no-server would:
If you run with --no-server option, you will get the whole 80% of what is reported as physical RAM as the baseline. This mode respects -Xmx arguments additionally.
|
Ok, I removed that Xmx option. It can always be added via a property in the mvn client |
…age (gluonhq#370) * use --no-server and set Xmx to a higher value when invoking native-image Fixes gluonhq#369 and gluonhq#362 * don't specify xmx
Fixes #369 and #362