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
Is your feature request related to a problem? Please describe.
We ship a command line tool with GraalVM Native Image. Sometimes, we want to execute a very quick operation and exit; other times, the operation is a long-running one, involving server activity. It can be difficult in this case to pick an optimal GC strategy. Serial or even epsilon GCs work best for short executions and startup time, but serial or G1GC is best for server modes and epsilon is definitely not an option.
Describe the solution you'd like.
If there were a way to opt-out of GC for an execution of the binary (at runtime), or build in support for multiple GC strategies and set one early at runtime, we could achieve the best of both worlds: no GC pauses or activity at all for quick-running executions which are expected to be reaped by the OS, and also long-running executions which need some GC and benefit greatly from advanced GC strategies like G1.
Describe who do you think will benefit the most.
Native Image targets like command line tools which sometimes execute quickly and other times execute for a long amount of time.
Describe alternatives you've considered.
We have considered tuning GC to avoid "kicking in" until it is clear a longer execution is needed. Maybe a parameter could be introduced that defers any GCs for a certain wall-clock time, where epsilon applies for, say, the first second of execution and G1 GC afterward.
Additional context.
N/A
Express whether you'd like to help contributing this feature
If you'd like to contribute, please read the contribution guide.
I'd be happy to help however I can.
The text was updated successfully, but these errors were encountered:
sgammon
changed the title
Ability to opt-out of GC
Ability to opt-out of GC / multiple GC strategies
Apr 2, 2025
sgammon
changed the title
Ability to opt-out of GC / multiple GC strategies
[Native Image] Ability to opt-out of GC / multiple GC strategies
Apr 2, 2025
oubidar-Abderrahim
changed the title
[Native Image] Ability to opt-out of GC / multiple GC strategies
[Native Image][GR-64079] Ability to opt-out of GC / multiple GC strategies
Apr 8, 2025
thanks for that request. This is a feature we are actively developing at the moment. I hope we can still bring it to our Java 25 release, but in any case, it should arrive sooner or later.
I.e. you will be able to select with GC to use at runtime - at the cost of including all potential GCs into the image (increasing image size).
Is your feature request related to a problem? Please describe.
We ship a command line tool with GraalVM Native Image. Sometimes, we want to execute a very quick operation and exit; other times, the operation is a long-running one, involving server activity. It can be difficult in this case to pick an optimal GC strategy. Serial or even epsilon GCs work best for short executions and startup time, but serial or G1GC is best for server modes and epsilon is definitely not an option.
Describe the solution you'd like.
If there were a way to opt-out of GC for an execution of the binary (at runtime), or build in support for multiple GC strategies and set one early at runtime, we could achieve the best of both worlds: no GC pauses or activity at all for quick-running executions which are expected to be reaped by the OS, and also long-running executions which need some GC and benefit greatly from advanced GC strategies like G1.
Describe who do you think will benefit the most.
Native Image targets like command line tools which sometimes execute quickly and other times execute for a long amount of time.
Describe alternatives you've considered.
We have considered tuning GC to avoid "kicking in" until it is clear a longer execution is needed. Maybe a parameter could be introduced that defers any GCs for a certain wall-clock time, where epsilon applies for, say, the first second of execution and G1 GC afterward.
Additional context.
N/A
Express whether you'd like to help contributing this feature
If you'd like to contribute, please read the contribution guide.
I'd be happy to help however I can.
The text was updated successfully, but these errors were encountered: