You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
fniephaus
changed the title
Native: Introduce flag to favor build time improvements at the cost of using more resources and vice versa
[GR-52400] Native: Introduce flag to favor build time improvements at the cost of using more resources and vice versa
Feb 29, 2024
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.
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.
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.
The text was updated successfully, but these errors were encountered: