Is JVM ARGS '-Xms1024m -Xmx2048m' still useful in Java 8?

Question

I have a Java 7 application using JVM ARGS: -Xms1024m -Xmx2048m, and it runs pretty well.

After I upgrade to Java 8, it runs in error state with Exception:

Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceeded
    at org.hibernate.engine.StatefulPersistenceContext.addEntry(StatefulPersistenceContext.java:466)
    at org.hibernate.engine.TwoPhaseLoad.postHydrate(TwoPhaseLoad.java:80)
    at org.hibernate.loader.Loader.loadFromResultSet(Loader.java:1439)
    at org.hibernate.loader.Loader.instanceNotYetLoaded(Loader.java:1332)
    at org.hibernate.loader.Loader.getRow(Loader.java:1230)
    at org.hibernate.loader.Loader.getRowFromResultSet(Loader.java:603)
    at org.hibernate.loader.Loader.doQuery(Loader.java:724)
    at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:259)
    at org.hibernate.loader.Loader.doList(Loader.java:2228)
    at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2125)
    at org.hibernate.loader.Loader.list(Loader.java:2120)
    at org.hibernate.loader.criteria.CriteriaLoader.list(CriteriaLoader.java:118)
    at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1596)
    at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:306)

I'm wondering whether JVM ARGS -Xms1024m -Xmx2048m is still working?

Since Java 8 has removed Perm Generation: http://www.infoq.com/articles/Java-PERMGEN-Removed, I think the different GC strategy/memory management between Java 7 and Java 8 may be the root cause. Is there any suggestion?

@AnkurAnand I have updated the question to avoid the unclear-logic description. — coderz, May 07 '15 at 08:33

score 31 · Accepted Answer · answered May 07 '15 at 08:07

31

Due to PermGen removal some options were removed (like -XX:MaxPermSize), but options -Xms and -Xmx work in Java 8. It's possible that under Java 8 your application simply needs somewhat more memory. Try to increase -Xmx value. Alternatively you can try to switch to G1 garbage collector using -XX:+UseG1GC.

Note that if you use any option which was removed in Java 8, you will see a warning upon application start:

$ java -XX:MaxPermSize=128M -version
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=128M; support was removed in 8.0
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b18)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)

answered May 07 '15 at 08:07

Tagir Valeev

97,161
19
222
334

5

What's the benefit of G1 garbage collector? – coderz May 13 '15 at 08:40
5

In this particular case: unlike CMS it does not have two survivor spaces one of which is not accessible. In practice with the same Xmx value G1 collector provides more memory for the application. If you want more details about G1, ask the separate question, this commentary field is too short for such discussion. – Tagir Valeev May 13 '15 at 09:01
Questions which ask subjective questions are often overlooked and downvoted so the question seems perfectly valid here. Since it's being offered as a replacement to the long-running `-Xms|-Xmx` flags, the solution deserves a bit more context. :) – tresf Sep 09 '20 at 13:26

score 2 · Answer 2 · answered May 07 '15 at 08:12

What I know is one reason when “GC overhead limit exceeded” error is thrown when 2% of the memory is freed after several GC cycles

By this error your JVM is signalling that your application is spending too much time in garbage collection. so the little amount GC was able to clean will be quickly filled again thus forcing GC to restart the cleaning process again.

You should try changing the value of -Xmx and -Xms.

Is JVM ARGS '-Xms1024m -Xmx2048m' still useful in Java 8?

2 Answers2

Linked