But even allowing for the JVM abstraction; to use ...
# compose-desktopd
darkmoon_uk
12/03/2021, 4:23 AMBut even allowing for the JVM abstraction; to use 300MB, for the functionality afforded, feels like it can be significantly optimised.
a
Aru
12/03/2021, 4:36 AMCan you set the
-Xmx128md
darkmoon_uk
12/03/2021, 4:37 AMKeen 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.
👍 1
darkmoon_uk
12/03/2021, 4:39 AMI 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
malloca
Aru
12/03/2021, 4:41 AMActually 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➕ 2
Aru
12/03/2021, 4:42 AMI'm curious to know how the NativeImage conversion to native code by Graal will behave in terms of allocation.
d
darkmoon_uk
12/03/2021, 5:08 AMSo 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?
o
olonho
12/03/2021, 5:27 AMThis is reserved, but not committed memory.
d
darkmoon_uk
12/03/2021, 5:28 AMThis 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
12/03/2021, 5:37 AMReserved or Committed... is still unusable by other processes though.
Best that can be said about Reserved is 'unlikely to grow further'.
o
olonho
12/03/2021, 7:15 AMNope, that’s not how virtual memory works, see https://en.m.wikipedia.org/wiki/Virtual_memory
d
darkmoon_uk
12/03/2021, 9:42 AMHappy to learn more about this, I'll read into it, thanks.