But even allowing for the JVM abstraction; to use 300MB, for the functionality afforded, feels like ...

# compose-desktop

[darkmoon_uk]

But even allowing for the JVM abstraction; to use 300MB, for the functionality afforded, feels like it can be significantly optimised.

[Aru]

Can you set the -Xmx128m to limit the memory? Will it lead to OOM for ToolBox size app?

[darkmoon_uk]

Keen to try it @Aru. As you're suggesting, this is probably a more a question of how JVM Apps persuade you to claim memory in advance in general, rather than Toolbox specifically.

[darkmoon_uk]

I do wonder why JVM Apps are claiming so much memory far in advance though, it's not like the JVM runtime can't just ask the OS for more as needed, same as any other native App using malloc.

[Aru]

Actually it doesn't have to be that way. JVM can request more memory as it grows. You can start with a smaller initial memory with -Xms and go from there.

[Aru]

I'm curious to know how the NativeImage conversion to native code by Graal will behave in terms of allocation.

[darkmoon_uk]

So this being the case; my question becomes; why is the ToolBox distribution even configured to claim ~300MB up-front? Is it just what the packaging developer decided would be a 'reasonable maximum'? Why even start at 'maximum'? Wouldn't it be better to reduce this?

[olonho]

This is reserved, but not committed memory.

[darkmoon_uk]

This is more than 'annoying level of curiosity' on my part - I've seen memory usage levelled as a criticism of Toolbox and its tech-stack on other forums, so I'd like to defend it (and not defend the indefensible).

[darkmoon_uk]

Reserved or Committed... is still unusable by other processes though.
Best that can be said about Reserved is 'unlikely to grow further'.

[olonho]

Nope, that’s not how virtual memory works, see https://en.m.wikipedia.org/wiki/Virtual_memory

[darkmoon_uk]

Happy to learn more about this, I'll read into it, thanks.