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?

Philps

Does Xms got to do anything with perm Size ? – Survivor

@AnkurAnand Xms has nothing with perm size. – Philps

than why wonder about it with perm generation ? – Survivor

@AnkurAnand I have updated the question to avoid the unclear-logic description. – Philps

Answer 1

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)

Squeteague

What's the benefit of G1 garbage collector? – Philps

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. – Squeteague

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. :) – Double

Answer 2

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.

Survivor