(Probably a terrible microbenchmark as those bytes are likely to never even escape eden!)
Cas 
(Probably a terrible microbenchmark as those bytes are likely to never even escape eden!)
Cas 
Um, yeah it was
(sorry 'bout that)
Having it adapted to a more âreal worldlyâ test, I see the behaviour we all know and hate (and what I actually expected in the first place): The heap hardly shrinking and the VM taking a huge multitudes of whatâs actually needed by the app. Itâs the price of a performant GC I supposeâŚ
Lowering -XX:MinHeapFreeRatio and -XX:MaxHeapFreeRatio will make that behaviour a bit better, but of course that has a price too.
What I also realized is that Runtime.getRuntime().freeMemory() doesnât seem to actually return the amount of memory you could allocate, but that uncollected garbage isnât part of it.
I think now probably wouldnât be the right time to ditch -Xmx, but maybe there should first be some kind of solution for tuning the GC for (especially desktop-) applications to become more memory efficient (while still keeping responsive)?
Like an option in the (concurrent) collector to (concurrently, in a low prio thread) actively try to collect and shrink the heap during idle time.
No idea how feasible that would be or what the implications of that are though (just thinking out loud).