Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
zakkak opened this issue Feb 28, 2024 · 2 comments

Comments

@zakkak
Copy link
Collaborator

zakkak commented Feb 28, 2024

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.

@zakkak zakkak added the feature label Feb 28, 2024
@fniephaus 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
@fniephaus
Copy link
Member

fniephaus commented Mar 1, 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.

What do you think?

@zakkak
Copy link
Collaborator Author

zakkak commented Mar 7, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants