-5

I'm totally fed up and disgusted of having to guess a good value for the -Xmx command-line option, having my applications crash with OutOfMemoryException, having to modify the -Xmx value and having to restart my applications all the time.

Is there a way to make JVM act normal so that it wouldn't require a -Xmx option, and would allocate and free memory directly from the OS just as any normal application would? Is there some GC which is more efficient, aggressively returning memory to the OS when objects are freed?

If I remember correctly, Java has its roots in embedded environments, but has long past grown in popularity and spread to all kinds of systems. Surely there must be a way to do this in the 21st century? There are many use-cases where an application may require anywhere from a few kilobytes to several terabytes of memory, and the cumbersome -Xmx is really getting in the way.

(Reminder to self: Since there are no good answers iteratively try out some other GC-s and random command line options in cargo cult fashion)

Community
  • 1
  • 1
mceo
  • 1,221
  • 11
  • 18
  • 1
    Okay. Don't specify a `-Xmx` (**or** a `-Xms`) argument. – Elliott Frisch May 03 '16 at 12:31
  • 1
    @ElliottFrisch But doesn't the JVM have a default `-Xmx` value set? – mceo May 03 '16 at 12:33
  • 1
    @ElliottFrisch But it doesn't release the memory back to the OS at runtime? – mceo May 03 '16 at 12:36
  • 4
    I suggest you do a [*little* research](http://stackoverflow.com/a/675647/2970947) into that. – Elliott Frisch May 03 '16 at 12:38
  • 1
    Use a different VM that supports your use case. (Azul comes to mind) You may want to use a jdk9 ea build, afaik they have a gc that provides what you are asking for. – Thomas May 03 '16 at 12:39
  • Specifying large max heap size is -almost- harmless. It does increase the size of your references, so you end up using more memory for you objects, but otherwise it will be used only when you accumulate live objects. Make sure you don't have unlimited memory growth, though - even large heap can be exhausted. –  May 03 '16 at 12:49
  • 1
    @ElliottFrisch At least in HotSpot JVM 8 there is a default maximum: http://stackoverflow.com/questions/2915276/what-is-the-default-maximum-heap-size-for-suns-jvm-from-java-se-6 –  May 03 '16 at 12:52
  • If there's little memory available and the application needs more, there's not much to do. If you're running OOM even with large heaps, probably you're having a leak somewhere (in you application). – gusto2 May 03 '16 at 12:54
  • @Arkadiy It appears to vary by implementation (how could it not) but 64-bit JRE 6 server defaulted to 32 gigabytes (which was rather a lot of memory at that time). – Elliott Frisch May 03 '16 at 12:57
  • *The* JVM? Surely you must have done your research and realized that there is more than one. And yet you did not specify which one. – the8472 May 03 '16 at 13:54

2 Answers2

2

Is there a way to make JVM act normal so that it wouldn't require a -Xmx option, and would allocate and free memory directly from the OS just as any normal application would?

That is what it does by default. You only need to set the maximum heap size to indicate at what point you would rather it get an error than use more memory.

Is there some GC which is more efficient, aggressively returning memory to the OS when objects are freed?

I believe the G1 collector in the Oracle JVM is better at this (because it is newer ??)

If I remember correctly, Java has its roots in embedded environments,

It's root was in Java applets. J2ME was used in embedded systems and this is a different release and code base.

the cumbersome -Xmx is really getting in the way.

I usually don't set it myself. When you have 128 GB or more it defaults to 32 GB.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
  • 1
    No. Java has its' roots in [Oak](https://en.wikipedia.org/wiki/Oak_%28programming_language%29) and it was initially designed for [set-top boxes](https://en.wikipedia.org/wiki/Set-top_box). When publicly released, popular *use cases* included applets (but I was doing an AWT application with the public beta that had nothing to do with applets). – Elliott Frisch May 03 '16 at 14:57
  • 1
    Fair enough, but the wikipedia entry includes this quote *Their first attempt, demonstrated on September 3, 1992, focused on building a PDA device named Star7[1] which had a graphical interface and a smart agent called "Duke" to assist the user.* A PDA in 1992 would constitute an embedded system (to me). – Elliott Frisch May 03 '16 at 15:04
  • @ElliottFrisch by the time they were releasing the Java Micro Edition, the Java Standard Edition was clearly not targeting embedded systems. A lot of people think of JSE when they talk about Java. – Peter Lawrey May 03 '16 at 15:08
0

Since there are no good answers iteratively try out some other GC-s and random command line options in cargo cult fashion

An alternative approach is learning how the GCs work and what their performance tradeoffs are and how those various parameters affect them and then choosing them based on that information instead of randomly.

There is extensive documentation on that topic.

Of course you can still use SO answers as a starting point to find options that are likely to result in the outcome you desire, but there's nothing stopping you from then studying up on why they achieve those results.

No need to worship the planes.

the8472
  • 40,999
  • 5
  • 70
  • 122