Bug in G1GC it performs Full GC when code cache is full resulting in overkill

[Martin Makundi]

Hi!

> To use your analogy, would you put diesel fuel in your gasoline powered
> vehicle when the label at the pump says "diesel fuel"?

Well, eh.. to use your analogy, we are like the old lady who
distinguishes cars by color only =) You are looking down on us from a
high tower...was it 12 years JVM tuning? ..huh..we are yet just
toddlers... ;)

> You may need some additional swap, or you'll need additional memory for
> backing reserved space even though the application may not use it.

We had memory fixed so swapping should not be an issue if the problem
is inside jvm..which seems to be.

We have free memory on linux side so physical memory as such is not a problem.

>> We had this class unloading problem several times per day like half a
>> year ago, and fixed it with noclasssgc, that was a no-brainer, single
>> parameter that made the difference.
>
> Ok, if you're convinced it fixes your issue, then use it. :-)  Usually class
> unloading issues generally implies perm gen size needs increases, or initial
> perm gen size could use increasing as an alternative.

Also permgen was measured at that time and it was not an issue, there
was plenty of permgen space, but probably some unreferenced loaded
classes. I read somewhere that if your  code uses lots of reflection
it might generate some moss...anyways, works now so I quit guessing =)

> -XX:ReservedCodeCacheSize=48, that is the default for 7u21.  You might
> consider setting it higher if you have the available space, and more
> importantly if you think you're running out of code space.
>
> For our sun jvm linux 64bit 48m is maximum, jvm won't start if higher value.
>
>
> If you can't go larger than -XX:ReservedCodeCacheSize=48m, that may suggest
> you have memory constraints and may also suggest you don't have enough swap
> space defined, and you may be experiencing swapping during JVM execution.
> I've got a Linux system that has 32 GB of RAM, I can set
> ReservedCodeCacheSize=256m with no issues, even with -Xms30g and -Xms30g.
>
>
> It is also documented that 48m is maximum
>
> http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html
>
> "maximum code cache size. [Solaris 64-bit, amd64, and -server x86:
>
> 48m"
>
>
>
> The documentation means that the command line option sets the maximum code
> cache size, not that it is the absolute maximum you can set.  Rather it sets
> the default maximum code cache size.  It's not any different than setting
> -Xmx, there is a default -Xmx value if you don't set one, and you can
> specify a larger one using -Xmx.
>
> Fwiw, here's the output from 7u21 on my Linux x64 system with 32 GB of RAM,
> notice I also specified +AlwaysPreTouch which forces every page to be
> touched as part of the command execution to illustrate the memory has been
> reserved, committed and touched:
> $  java -Xmx26g -Xms26g -XX:+AlwaysPreTouch -XX:ReservedCodeCacheSize=256m
> -version
> java version "1.7.0_21"
> Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
> Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode)

Ok, you are right, it seems to work. What do you recommend for code
cache size or how to find a good value for it?

**
Martin


>
>
>
>
>
> On May 26, 2013, at 10:20 AM, Martin Makundi wrote:
>
>
> Sorry, forgot to mention, using:
>
>
> java version "1.7.0_21"
>
> Java(TM) SE Runtime Environment (build 1.7.0_21-b11)
>
> Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode)
>
>
> Linux version 3.0.1.stk64 (dfn at localhost.localdomain) (gcc version
>
> 4.5.1 20100924 (Red Hat 4.5.1-4) (GCC) ) #1 SMP Sat Aug 13 12:53:46
>
> EDT 2011
>
>
> -Dclassworlds.conf=/usr/share/maven/maven/bin/m2.conf
>
> -Dmaven.home=/usr/share/maven/maven
>
> -Duser.timezone=EET
>
> -XX:+AggressiveOpts
>
> -XX:+DisableExplicitGC
>
> -XX:+ParallelRefProcEnabled
>
> -XX:+PrintGCDateStamps
>
> -XX:+PrintGCDetails
>
> -XX:+PrintHeapAtGC
>
> -XX:+UseAdaptiveSizePolicy
>
> -XX:+UseCompressedOops
>
> -XX:+UseFastAccessorMethods
>
> -XX:+UseG1GC
>
> -XX:+UseGCOverheadLimit
>
> -XX:+UseNUMA
>
> -XX:+UseStringCache
>
> -XX:CMSInitiatingOccupancyFraction=70
>
> -XX:GCPauseIntervalMillis=10000
>
> -XX:InitiatingHeapOccupancyPercent=0
>
> -XX:MaxGCPauseMillis=500
>
> -XX:MaxPermSize=512m
>
> -XX:PermSize=512m
>
> -XX:ReservedCodeCacheSize=48m
>
> -Xloggc:gc.log
>
> -Xmaxf1
>
> -Xms30G
>
> -Xmx30G
>
> -Xnoclassgc
>
> -Xss4096k
>
>
>
> **
>
> Martin
>
>
> 2013/5/26 Charlie Hunt <chunt at salesforce.com>:
>
> Which version of the JDK/JRE are you using?
>
>
> One of the links you referenced below was using JDK 6, where there is no
> official support for G1. The other link suggests it could have been RMI DGC
> or a System.gc().
>
>
>
>
> Sent from my iPhone
>
>
> On May 25, 2013, at 11:43 PM, "Martin Makundi"
> <martin.makundi at koodaripalvelut.com> wrote:
>
>
> it occurs daily.
>
>
>
>
>
>
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>