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

[Martin Makundi]

Hi!

> Having free memory is one thing.  How much free memory do you have?  Do you
> have 2x more than your Java heap size, including -Xmx and what you're
> specifying for MaxPermSize?

Do we need 2x more (or just 2x) memory relative to java heap size?
Why? Currently we have 40gb ram and 26-30gb allocated to java (fixed
xm size). The rest is for system needs.

> Question is did you set both -XX:PermSize and -XX:MaxPermSize to the same
> value?  If not, if perm gen needs to expand from the initial size, or gets
> close to that initial size, the JVM may attempt to unload classes to free up
> space prior to expanding perm gen.

Yes, exactly for that reason we have set both equal.

> But, if you'd rather use -noclassgc, then go ahead. :-)

We had to use that too, permsize alone didn't do the job.

> -XX:ReservedCodeCacheSize=48, that is the default for 7u21.
>
> There's not magic number of what to increase it too.  It's probably more
> magical than suggesting a Java heap configuration size to use. We don't know
> how much code you've got and how much of it will be executed enough times to
> compile, or require a de-opt and re-opt.

Ok. We set it to 256m and code cache usage is now approximately 20-25%
for most of the time. Bit over-sized but luckily we aren't in 8bit
hardware anymore so we can afford it ;)

> However, you can monitor the occupancy of code cache in a couple different
> ways.  There's a JMX MBean for the code cache where you can get the
> occupancy and size of code cache.  There's also a plug-in for VisualVM that
> monitors code cache size and occupancy, you get a copy of the plug-in and
> install it into VisualVM. The web site for it is:
> https://java.net/projects/memorypoolview.  If you're monitoring code cache
> occupancy in production today, you should probably put it on your short
> list.

We have quite nice view to our server stats from new relic and
appdynamics monitors.

Will try 128m though...


**
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
>
>
>