1

Beside the discussion about huge heap size GC challenges, is JVM immediately grab all the -Xms512G if set? ( 512G just symbolize a huge heap, suppose another huge value if it helps)

It seems it would takes time consuming on start, isn't it? Can anyone clarify JVM's behavior in such cases on the start?

How about -Xmx?

Edit: all I wanna know: whether the -Xms512G parametrized program has any delay on start against the same program but -Xms512m parametrized

Edit How does XX:+AlwaysPreTouch impact on this?

J.J. Beam
  • 2,612
  • 2
  • 26
  • 55
  • `huge heap size flaws` - I mean just GC problems, which is out of the question scope. Ok, so do you mean JVM immediately mark (or what ever word instead of `grab`) the whole 512G? – J.J. Beam Apr 07 '21 at 09:13
  • 1
    Then, don’t mention anything that “is out of the question scope”. When you specify the `Xms` option, the JVM will allocate the specified amount of memory right at the start, as that’s the purpose of this option. The implications of allocations are operating system dependent, but normally, they do not imply a time consuming operation that would take longer with larger heaps. – Holger Apr 07 '21 at 09:22
  • `Xms` makes the JVM ask the OS for that amount of heap memory. That much memory will be allocated to the JVM. But whether or not that is backed by actual physical memory (and other users will be evicted) or not is up to the OS. Most modern OS will only "require" physical memory the first time a given page is actually touched (google overcommit). – Generous Badger Apr 07 '21 at 09:34
  • 1
    Also: it's a bit unclear what you're asking. If you're not interested in "huge heap size flaws", then why pick a huge size in the first place? It seems your question is independent of the magnitude of the memory request. `-Xms2G` doesn't fundamentally differ from `-Xms512G` in any qualitative way. – Generous Badger Apr 07 '21 at 09:35
  • `huge heap size flaws` ok I will rename it into `huge heap size GC challenges` – J.J. Beam Apr 07 '21 at 10:46
  • 1
    @J.J.Beam: it's not about the phrasing, but you argue that you're not *interested in that part*, so why does it matter if the size is huge or not? The answer to your question (whatever it may actually be) is independent of size, if you want to ignore the parts caused by huge sizes, right? – Joachim Sauer Apr 07 '21 at 10:53
  • yes, for the moment all I wanna know: whether the -Xms512G parametrized program has any delay on start against the same program but -Xms512m parametrized – J.J. Beam Apr 07 '21 at 10:59

1 Answers1

1

There is a difference between -Xmx and -Xms. Xmx reserves virtual memory (which you have plenty of). So for example some code like this (same numbers on Mac OSX and a few versions of linux):

public class DeleteMe {

    public static void main(String[] args) {
       LockSupport.parkNanos(TimeUnit.SECONDS.toNanos(1));
       System.out.println("done");
    }

}

run with time java -Xmx5120g DeleteMe.java and time java -Xmx50 DeleteMe.java shows almost the same times. Reserving 5120 GB and 50MB of virtual memory has no difference, time wise.

On the other hand -Xms commits this memory to the process, and that is more expensive. So running:

time java -Xms5120g DeleteMe.java

Shows around 9 and 10 seconds, while :

time java -Xms50m DeleteMe.java

Shows around one second only.

So yes there is some delay for those calls. Whether you can go above your physical RAM when requesting memory, depends on the vm.overcommit_memory flag for linux. I do not know what settings governs this on Windows, though.

Testing your exact scenario with -Xms512g and -Xms512m, still reveals at least 1 second delay in the times. As noted in the comment it is worth mentioning the -XX:+AlwaysPreTouch flag also. It will pre-touch all committed memory, so up to -Xms, this obviously means that with such a flag and a big size of -Xms (as long as you have that much physical memory), start-up will be a lot slower.

Eugene
  • 117,005
  • 15
  • 201
  • 306