I have no idea about JVM and the details of how the GC is done, but my guess is with lower limit, even though it doesn’t crash, it would be slower due to it having to perform more GC.
Would it be a good idea to dynamically set/configure this at installation time so that -Xmx is set to max(786m, min(4gb, 1/4 of total RAM))? This way, for people with 4GB RAM, they’ll get 1gb, and for 8GB RAM, they’ll get 2gb limit. This is still very conservative but at least more than 786m.
Chances are, most openhabian users will never touch this, and if we can make things to perform better for them, it would make for a better overall impression of openHAB.
But I defer to your experience and others who are actually using openhabian on rpi.
No. Note this isn’t the process size, it is only about the heap size.
Increasing it does not have any positive effect, but a number of downsides.
The impact of garbage collection is negligible. Remember, OH isn’t data mining.
Increased paging. Even slower startup due to that.
More competition for memory with other processes.
Actually, when there’s ever-recurring issues like a (sometimes newly introduced) OH code mem leak, your system state slowly deteriorates towards a halt, with ever more paging.
But that can take long and often goes unnoticed for a while.
The intentional low settings in openHABian will enforce an immediate openhab restart in these cases, getting OH back to work as fast as possible rather than tolerate any half-dead OH instance causing hard-to-track, impossible-to-reproduce problems in smart home operations.
So in fact the optimum is a -Xmx that is sufficiently large to run OH but also as low as possible.
