Minor GC difference Java 7 vs Java 8

[Peter B. Kessler]

Are the -XX:+PrintGCDetails "[Times: user=0.01 sys=0.00, real=0.03 secs]" reports for the long pauses different from the short pauses?  I'm hoping for some anomalous sys time, or user/real ratio, that would indicate it was something happening on the machine that is interfering with the collector.  But you'd think that would show up as occasional 15ms blips in your message processing latency outside of when the collector goes off.

Does -XX:+PrintHeapAtGC show anything anomalous about the space occupancy after the long pauses?  E.g., more objects getting copied to the survivor space, or promoted to the old generation?  You could infer the numbers from -XX:+PrintGCDetails output if you didn't want to deal with the volume produced by -XX:+PrintHeapAtGC.

You don't say how large or how stable your old generation size is.  If you have to get new pages from the OS to expand the old generation, or give pages back to the OS because the old generation can shrink, that's extra work.  You can infer this traffic from -XX:+PrintHeapAtGC output by looking at the "committed" values for the generations.  E.g., in "ParOldGen       total 43008K, used 226K [0xba400000, 0xbce00000, 0xe4e00000)" those three hex numbers are the start address for the generation, the end of the committed memory for that generation, and the end of the reserved memory for that generation.  There's a similar report for the young generation.  Running with -Xms equal to -Xmx should prevent pages from being acquired from or returned to the OS during the run.

Are you running with -XX:+AlwaysPreTouch?  Even if you've reserved and committed the address space, the first time you touch new pages the OS wants to zero them, which takes time.  That flags forces all the zeroing at initialization.  If you know your page size, you should be able to see the generations (mostly the old generation) crossing a page boundary for the first time in the -XX:+PrintHeapAtGC output.

Or it could be some change in the collector between JDK-6 and JDK-7.

Posting some log snippets might let sharper eyes see something.

			... peter

On 04/30/14 07:58, Chris Hurst wrote:
> Hi,
>
>   Has anyone seen anything similar to this ...
>
> On java 6 (range of versions 32bit Solaris) application , using parallel old gc, non adapative.  Using a very heavy test performance load we see minor GC's around the 5ms mark and some very rare say 3or4 ish instances in 12 hours say 20ms pauses the number of pauses is random (though always few compares with the total number of GC's) and large ~20ms (this value appears the same for all such points.) We have a large number of minor GC's in our runs, only a  full GC at startup. These freak GC's can be bunched or spread out and we can run for many hours without one (though doing minor GC's).
>
> What's odd is that if I use Java 7 (range of versions 32bit) the result is very close but the spikes (1 or 2 arguably less) are now 30-40ms (depends on run arguably even rarer). Has anyone experienced anything similar why would Java 7 up to double a minor GC / The GC throughput is approximately the same arguably 7 is better throughput just but that freak minor GC makes it usable due to latency.
>
> In terms of the change in spike height (20 (J6)vs40(J7)) this is very reproducible though the number of points and when they occur varies slightly. The over all GC graph , throughput is similar otherwise as is the resultant memory dump at the end. The test should be constant load, multiple clients just doing the same thing over and over.
>
> Has anyone seen anything similar, I was hoping someone might have seen a change in defaults, thread timeout, default data structure size change that would account for this. I was hoping the marked increase might be a give away to someone as its way off our average minor GC time.
>
> We have looked at gclogs, heap dumps, processor activity, background processes, amount of disc access, safepoints etc etc. , we trace message rate into out of the application for variation, compare heap dumps at end etc. nothing stands out so far.
>
> Chris
>
>
>
>
>
>
>
>
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>