[Pro/Con] [Opinion] [Feedback] native-image too greedy (in regards to memory consumpt / RAM / CPU usage)?

[rubyFeedback]

Hey there GraalVM folks, in particular all devs and everyone else involved, investing time, sweat and donuts (or whatever else you eat for making GraalVM better).

This is mostly an opinion, or perhaps not even that and more of a question. I will voice that question in a moment, but please let me first state here that I think GraalVM is awesome. I have been using it since several months at this time, mostly doing smaller things; my java-related code works too, which is fine.

So, having said that, one of the very few nitpicks I have with graalvm is in regards to native-image. And, mind you: I think native-image is AWESOME. It's really great. I could generate fast binaries and have them work on windows too (I work on linux mostly, but my windows laptop also has graalvm and I can just compile the java code into a standalone binary there, which is useful to distribute it to an elderly relative who needs help with computers in general, so a win-win situation for me).

I used to have one problem in the past in regards to the polyglot part - in particular when trying to use ruby too and have that work via the produced binary, I ran ... out of memory.

Others had no problem so perhaps something was wrong with my machine.

I just tried the new GraalVM release and the problem I had appears to have been fixed. So, this is also great.

I have not yet tested it thoroughly so ... perhaps a bit too early to say. Either way, this here is about something else.

Having remembered memory issues in the past, I was watching what happened in htop.

Here is one such snapshot:

https://i.imgur.com/vLybyMa.png

You can see that all my 4 cores are quite extensively working. htop reports even higher than 100% load which is a bit weird, but this usually indicates of native-image perhaps being super-eager - and super-greedy.

I am a bit worried that this might lead to a out-of-memory situation again. I have ~14GB on that machine here. Is native-image too greedy?

For people on a server station they probably don't even feel that, but for home users this may perhaps be a bit problematic? That's speculative but I am a bit worried.

I don't really mind longer build cycles, by the way, but any out-of-memory issue is a bit annoying since I don't have a simple work around for that (other than buying a better computer perhaps or using a server, but I'd ideally want to just have a solo-dev machine situation here).

So this is the first part - a question whether native-image may at times be too greedy.

This is admittedly not very useful to graalvm devs because I guess devs prefer something that is actionable. I get that.

This brings me to the second part of the suggestion here: could we perhaps get a bit more control over the analysis stage? In particular how much RAM is allocated or perhaps, if not via RAM specific, then some profile? Like: -cpu-usage=turtles (I am not suggeting that, but the idea is to be able to control this a bit better over the commandline flag).

This may not be the primary problem perhaps, since I only had that idea ever since I had issues in the past running out of memory leading to failure to produce a binary. But perhaps I am not the only one who encounters such issues, and perhaps it may be a good idea to, in that case, consider a bit over how much control devs can have over the build process - in particular solo devs in an environment that may not have as many resources available in the first place. (Just an average priced home desktop computer, e. g. that audience).

Anyway, please do feel free to close this issue here at any moment in time - it is mostly meant as a bit of feedback, provocative question and what not, to perhaps get more GraalVM devs to also think a bit about semi-resource constrained computer systems. I understand that everyone wants faster build times (I don't object to that), but I also don't mind letting it run in the background for, say, an hour or so at lower priority (not talking about nice/renice on Linux though, I really mean control via graalvm + native-image as such).

Thank you for reading though!

[rubyFeedback]

Huh - not sure why the bug label was added; should not be a bug, perhaps I misfiled it or the template here is a bit peculiar.

[oubidar-Abderrahim]

Hi, Thank you for your valuable feedback, we appreciate your input. Regarding your question. Building native images is a computationally intensive process that requires memory. We cannot currently reduce the memory consumption without heavily affecting the build process, but there're a few workarounds for building images in low memory machines: There was an example of a native image application built on Raspberry Pi 4 with only 4GB of RAM using Swap Partitions. also limiting the number of threads helps often, By default, the native-image tool uses up to 32 threads (but not more than the number of processors available), you can use the option -H:NumberOfThreads=... to change the default behavior. Finally, If peak performance is not critical, you can also try to run a quick build (-Ob), which will disable optimizations and thus reduce the resources needed for building, including memory.