2

Java documentation says:

Small utility applications that run only for a short time may suffer a performance hit if the JVM and Java application startup time is long.

I wonder if it's possible to keep the JVM (not its "state") in memory between application launches to avoid the startup delay?

EDIT I don't think the 2 people who voted to close this question even read it. The JVM and the JVM state are two different things. I asked about keeping the JVM in memory, not saving the JVM state to a file, like the other question. The goal of the former is to save startup time. The latter doesn't do that at all.

MWB
  • 11,740
  • 6
  • 46
  • 91
  • This is not “Java documentation”, but the documentation of JRockit, a particular JVM implementation, which is *not* the one you can download from [here](http://www.oracle.com/technetwork/java/javase/downloads/index.html), by the way. So… did you notice the “**if**” in the statement? – Holger Sep 19 '16 at 17:50
  • Even if you kept the JVM in memory, it would be useless because its state was changed by the application. HotSpot is already heavily optimized to quickly come into the initial state that was saved to disk on the first startup. – Marko Topolnik Sep 19 '16 at 17:56
  • This might be of interest: https://docs.oracle.com/javase/8/docs/technotes/guides/vm/class-data-sharing.html – Marko Topolnik Sep 19 '16 at 18:04
  • I just measured the time to fully execute a `System.out.println("Hello, world!");` program, it's 90 milliseconds. – Marko Topolnik Sep 19 '16 at 18:20
  • @MarkoTopolnik it's about right, but for example Lua "hello world" takes ~100x less time. – MWB Sep 19 '16 at 19:02
  • @MaxB Of course. And ruby, and python, and perl, and... – Marko Topolnik Sep 19 '16 at 19:04
  • how about using memory disk? – Rockie Yang Sep 20 '16 at 03:11
  • A workaround that comes in mind when reading you question is an application that runs to keep JVM active and loads your classes on demand. Just like most java containers (e.g. Tomcat). – Aleksandr Erokhin Sep 20 '16 at 09:22
  • Do you have an actual goal in milli- or microseconds that it fails to meet? – the8472 Sep 20 '16 at 13:33

2 Answers2

1

Note that the cited sentence is only a conditional (having an “if” in-between) and, omitting technical terms, basically says:

… that run only for a short time may suffer … if … startup time is long.

Obviously, this statement is so fundamental (true but trivial), that you could apply it to everything, including your car or TV. Back in the times when switching on the TV implied heating up the tubes, watching a short may suffer from the long startup time.

At no point, this statement says that there is such a problem. So you are not only drawing the false conclusion that there was such a problem, by asking whether “it’s possible to keep the JVM in memory” you are implying that this problem (if it existed) is caused by the JVM not being kept in memory, without any support for this assumption.

“The JVM” consists of several components. The native code, usually delivered as native shared libraries, is loaded and kept in memory by the operating system. The classes of the JRE are stored in a shared archive which will be memory mapped, hence, shared between JVM instances and kept in memory similar to the native libraries that make up the JVM, if the operating system decides that there is enough unused memory for that.

Other resources and the application’s code are read in using conventional I/O, still, the operating system layer will utilize unused memory for buffering. The difference to the memory mapped libraries and shared class data is that there will be a necessary copying step when reading from an already cached file. But, of course, this is still faster than actually reading from a hard drive.

All in all, “keeping the JVM in memory” is already a fact, regarding those parts that can be kept and reused, and the improvement potential is low. You can easily verify it by starting a small application (e.g. hello world) on a freshly booted computer, then run the same app again using the same JVM and you will notice a significant reduction of the startup time on the second run.

You might consider the startup time of the second run still high compared to a hello world using, e.g. a scripting language, but that’s not an issue of keeping or not keeping JVM components in memory. It’s also highly subjective, which startup time to consider long enough to consider the application suffering from it.

Holger
  • 285,553
  • 42
  • 434
  • 765
0

This depends how you want to use the JVM. If last JVM job finishes and no data there needed, you can reuse JVM for next or future jobs. This has been deployed in big data applications to shorten JVM startup delay (e.g. Hadoop or Spark), and you can refer to this for more information.

JQian
  • 226
  • 2
  • 9