[GR-52400] Native: Introduce flag to favor build time improvements at the cost of using more resources and vice versa

[zakkak]

Feature request

Introduce flag to favor build time improvements at the cost of using more resources and vice versa.
As discussed in quarkusio/quarkus#38968

Is your feature request related to a problem? Please describe.

In the past we have used GraalVM flags in Quarkus that result in worse build times for native executables in order to reduce the system resources used at build time, e.g. quarkusio/quarkus#21018.

I recently noticed that GraalVM is doing something similar when it comes to configuring the JVM that runs the native image generator, which leads to slower build times when using GraalVM for JDK 21 and GraalVM for JDK 17, in comparison to using the older GraalVM 22.3, in exchange to using less memory at build time.

Although this makes sense in some environments it's a waste of time and resources (as they just stay idle) in others, e.g. in GH runners were we run a single build per runner so we are OK with it using as much memory as possible.

Describe the solution you'd like.

Provide an option like --resource-usage=<dedicated|shared> (as suggested by @fniephaus) that will tell the native image generator how to utilize system resources.

Describe who do you think will benefit the most.

Everyone.

Describe alternatives you've considered.

The alternative we have considered (other than hand-tuning the native image generator) is to implement this in the frameworks (as proposed in quarkusio/quarkus#38968).

Additional context.

@fniephaus suggested discussing this in a Native Image Committer and Community Meeting.

Express whether you'd like to help contributing this feature

Yes.

[fniephaus]

Hey @zakkak, thanks for the request. I thought about this some more and I'm not sure --resource-usage=<dedicated|shared> is a good idea, considering:

• it's just another set of high-level heuristics, on top of the default heuristic, and as such will unlikely be better than setting values manually
• the build resource section makes clear what is available and how to change it manually
• NATIVE_IMAGE_OPTIONS can be set, for example in a Docker container, to set resource limits specifically for a machine

For number of threads, we provide --parallelism. For memory limits, you currently need to use -J-XX:MaxRAMPercentage=60.0 or -J-Xmx16g. We could simplify this for users a bit with an new option that accepts both a percentage or an absolute value to specify the memory limit of the builder.

What do you think?

[zakkak]

I think that's still pretty difficult for configuring the building of your application. Furthermore, even if users are familiar with setting the max heap size and the number of cores to be used, I am afraid they won't be able to go much further...

E.g. I expect most users to believe that -Xmx8g means that the build process will use up to 8g in total, not to mention options like GCTimeRatio etc.

Since GraalVM already tries to strike a balance between resource usage and build time performance by altering the JVM's default heuristics, I still believe it would be beneficial to offer users the option to choose between some more "policies". I think these policies can be good enough for most cases and thus most people won't need to worry about fine tuning.

[fniephaus]

Since this topic came up today, some additional thoughts:

1. We needed to move away from available to free memory because detecting container environments didn't work as expected. Fortunately, @jerboaa has addressed this some time ago in https://bugs.openjdk.org/browse/JDK-8261242. We should probably move back to available memory because free memory can get very low on many machines after some time.
2. --resource-usage seems too broad. At least, we should probably also adjust the number of threads somehow if set to shared and we don't have any numbers (or user complaints) about that yet.
3. Alternatively, we could call it something like --memory-usage. But wouldn't it be weird if it doesn't accept absolute and relative values, too? On the other hand, -XX:MaxRAMPercentage and -Xmx already exist and can be used to override the default behavior.
4. I'm not sure how useful --memory-usage=shared would be in practice. On my machine, I'd rather set a minimum Java heap limit than risking that build suddenly fail because I have too many browser tabs open.

Right now, I'm working on #10441 to address 1. I'd suggest we see whether available memory works better before adding another public API option for users.