When user does not supply -Xms, ergonomics guesses the initial heap size, based on InitialRAMPercentage (IRAMP), currently set at 1/64 of physical RAM. The initial heap size drives the startup times, because GCs need to initialize their internal data structures, e.g. remsets, card tables, or even heap memory itself for the initial heap.

AFAICS, the 1/64 guess had not changed since the initial load in 2007. Unfortunately, today machines easily come with lots of physical memory, which drives the default initial heap size very high. On my 128G desktop, for example, this ergonomics sets 2G initial heap, even when application has no need for this amount of memory.

With worst case in G1, this easily eats roughly half of the entire start up, see JDK-8348270. With worst case in ZGC, initial heap commit can take entire seconds to complete, JDK-8348267.

I think we should consider trimming the default initial heap size to recover some of the startup costs on modern machines. It looks like dropping the guess to something like 1/512 of RAM works fine at recuperating the startup costs, see attached helloworld-vs-Xmx.png. Note that with only Xmx supplied, on smaller heap sizes we would effectively have Xms = Xmx up until Xmx=2G on 128G machine. It means with large IRAMP and small heap sizes, user-supplied Xmx drives ergonomically selected Xms, which drives startup time.

I expect most performance sensitive configurations are already supplying Xms, and they would not be affected by changing the IRAMP defaults.