3

If I start a Java application using jre 8u74 on Linux using -Xmx512m the memory is not allocated immediately, the memory is allocated if Java needs it. So it can stay below the 512 MB limit if not necessary. This is what I would expect.

On Java 8u111 I get another behavior, the 512 MB of memory is always allocated immediately to the process even if Java does not need it. This is annoying since this memory cannot be used by other processes, even if Java does not need it.

I looked trhough the release notes for the Java jre's starting with 8u74 till the currently newst 8u111 but I cannot find any reference to a change in the memory allocation strategy.

Can someone confirm this allocation strategy change within the Java 8 range? Is there an option to have the previous memory allocation behavior?

Edit 1 - -XX:+PrintFlagsFinal diff (as suggested by the8472)

diff java-info-8u111.txt java-info-8u74.txt 
161d160
<      bool CrashOnOutOfMemoryError                   = false                               {product}
199d197
<      bool ExitOnOutOfMemoryError                    = false                               {product}
636d633
<      bool UseCountedLoopSafepoints                  = false                               {C2 product}
666,668d662
<      bool UseMontgomeryMultiplyIntrinsic            = false                               {C2 product}
<      bool UseMontgomerySquareIntrinsic              = false                               {C2 product}
<      bool UseMulAddIntrinsic                        = false                               {C2 product}
698d691
<      bool UseSquareToLenIntrinsic                   = false                               {C2 product}
729,731c722,724
< java version "1.8.0_111"
< Java(TM) SE Runtime Environment (build 1.8.0_111-b14)
< Java HotSpot(TM) 64-Bit Server VM (build 25.111-b14, mixed mode)
---
> java version "1.8.0_74"
> Java(TM) SE Runtime Environment (build 1.8.0_74-b02)
> Java HotSpot(TM) 64-Bit Server VM (build 25.74-b02, mixed mode)

Edit 2 - Related Issues

Edit 3 - Solution

The problem is related to the combination Java8/9 and Jetty9. A workaround is to comment out the contents of the Jetty annotations.mod. See my complete answer to this related question.
Thanks for all suggestions and new debugging ideas.

Bruno Ranschaert
  • 7,428
  • 5
  • 36
  • 46
  • Maybe this link will be usefull to what you are trying: http://stackoverflow.com/questions/28277811/how-to-limit-total-memory-consumed-by-java-8-application – Francisco Valle Nov 25 '16 at 14:59
  • Have a look here: http://stackoverflow.com/questions/30095189/is-jvm-args-xms1024m-xmx2048m-still-useful-in-java-8 ... this posts suggests that XMX still is valid and perhaps your application needs that much memory. – Tim Biegeleisen Nov 25 '16 at 15:00
  • @Francisco Valle: No I do not want to limit the amount of memory for the application. I want Java to allocate the minimum that is necessary below the maximum. I expect the -Xmx to be a maximum limit (more or less) that should not be reached automatically by default. – Bruno Ranschaert Nov 25 '16 at 15:07
  • @Tim Biegelsiesen: No, the application does not need all memory, I tested this in 8u74 and also 8u112 and 8u111. It is about the different behaviour of the different jre's. – Bruno Ranschaert Nov 25 '16 at 15:09
  • How do you measure those numbers? Also, run the output of `-XX:+PrintFlagsFinal` for each JVM through diff to see if anything else changed – the8472 Nov 25 '16 at 17:41
  • @the8472: I looked at the RES memory in the Linux top command. I added the diff of the flags. It was a very good suggestion I did not know this option, but in this case it does not reveal more information. – Bruno Ranschaert Nov 25 '16 at 23:12
  • well, i meant appending to your actual command line, not java -version. anyway, another thing you can try is enabling GC logging with `-XX:+PringGCDetails -XX:+PrintAdaptiveSizePolicy -XX:+PrintHeapAtGC` that should show details about how the heap gets sized with each GC. – the8472 Nov 26 '16 at 02:45
  • @the8472: The version info is included for clarity so that you can see the exact versions being compared. – Bruno Ranschaert Nov 26 '16 at 17:30

0 Answers0