4

I'm wondering why a GraalVM (SubstrateVM) native image of a Java application makes it run where the runtime behavior will consume much less memory, yet if run normally, it will consume a lot more memory?

And why can't the normal JIT be made to similarly consume a small amount of memory?

Didier A.
  • 4,609
  • 2
  • 43
  • 45

1 Answers1

5

GraalVM native images don't include the JIT compiler or the related infrastructure -- so there's no need to allocate memory for JIT, for the internal representation of the program to JIT it (for example a control flow graph), no need to store some of the class metadata, etc.

So it's unlikely that a JIT which actually does useful work can be implemented with the same zero overhead.

It could be possible to create an economic implementation of the virtual machine that will perhaps use less memory than HotSpot. Especially if you only want to measure the default configuration without comparing the setups where you control the amounts of memory the JVM is allowed to use. However, one needs to realize that it'll either be an incremental improvement on the existing implementations or picking a different option for some trade-off, because the existing JVM implementations are actually really-really good.

Oleg Šelajev
  • 3,530
  • 1
  • 17
  • 25
  • Interesting, so would there be a tipping point? Like if a certain application used a lot of memory, you'd only notice a marginal difference as the JIT memory overhead becomes only a small fraction of the total memory use? – Didier A. Apr 07 '20 at 10:03
  • 1
    Yes, the memory your application allocates doesn't magically become smaller or not needed by using native images. So if your memory usage is dominated by the data you're holding at runtime - the benefits will be relatively smaller. For request based software it often is not the case -- memory is allocated for processing a request and released making the slice that JIT would take much more relevant. – Oleg Šelajev Apr 07 '20 at 10:41
  • Ok, one last question, does that mean that the memory overhead of the JIT is a constant? I understand it could grow with code size, because it needs class metadata and some control flow graph, but is there anything at runtime that the JIT would keep adding overhead with it, like say extra per new object, things like that? – Didier A. Apr 08 '20 at 03:15
  • 1
    it depends on the JIT implementation, doesn't it? I don't know, but you should be able to think about it as a constant at a certain point, after all the amount of code (think classes and methods) is more or less finite, the info about code paths and data at various is finite. – Oleg Šelajev Apr 08 '20 at 16:12