ParallelGC issue: collector does only Full GC
Srinivas Ramakrishna
ysr1729 at gmail.com
Thu Oct 24 10:12:12 PDT 2013
I had called in this bug earlier this year -- the model can be easily
improved. I will try and dig up the email in which I had described the issue
and the suggested fix.
-- ramki
On Thu, Oct 24, 2013 at 5:00 AM, charlie hunt <charlesjhunt at gmail.com>wrote:
> I did a little experimenting with this ... I think Jon's hypothesis is
> right.
>
> I first reproduced the behavior as described by Andreas. Then, I set
> -XX:PromotedPadding=1 in the case where NewSize/MaxNewSize is at 1800m.
> That eliminated the issue Andreas observed at 1800m. But, as I suspected
> the threshold at which the change in behavior merely changed at a higher
> sizing of young gen. It now occurs at about 2300m, up from 1800m.
>
> So, it does look like there is an issue with the prediction model since
> PromotedPadding can influence the prediction model.
>
> The prediction model code does not look trivial, as I'm sure Jon knows. ;)
>
> hths,
>
> charlie ...
>
>
>
>
> On Wed, Oct 23, 2013 at 3:03 AM, Andreas Müller <
> Andreas.Mueller at mgm-tp.com> wrote:
>
>> Hi Jon,
>>
>> thanks for the hint to Java 8.
>> I have verified with jdk1.8.0-ea-b112 (from October 17): behavior remains
>> as described
>>
>> Best regards
>> Andreas
>>
>> ----------------------------------------------------------------------
>>
>> Date: Mon, 21 Oct 2013 15:29:10 -0700
>> From: Jon Masamitsu <jon.masamitsu at oracle.com>
>> Subject: Re: ParallelGC issue: collector does only Full GC by default
>> and above NewSize=1800m
>> To: hotspot-gc-use at openjdk.java.net
>> Message-ID: <5265AAB6.1050700 at oracle.com>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> Andreas,
>>
>> There was a bug fixed in jdk8 that had similar symptoms. If you can try
>> a jdk8 build that might tell us something.
>>
>> If jdk8 doesn't help it's likely that the prediction model thinks that
>> there is not enough
>> free space in the old gen to support a young collection. We've been
>> working on 7098155 to
>> fix that.
>>
>> Jon
>>
>>
>> On 10/21/2013 10:09 AM, Andreas M?ller wrote:
>> > Hi all,
>> >
>> > while experimenting a bit with different Garbage Collectors and
>> > applying them to my homegrown micro benchmarks I stumbled into the
>> following problem:
>> > I run the below sample with the following command line (using Java
>> 1.7.0_40 on Windows and probably others):
>> > java -Xms6g -Xmx6g -XX:+UseParallelGC -
>> > de.am.gc.benchmarks.MixedRandomList 100 8 12500000
>> >
>> > The Default and proven ParallelGC collector does mostly Full GCs and
>> shows only poor out-of-the-box performance, more than a factor 10 lower
>> than the ParNew collector.
>> > More tests adding the -XX:NewSize=<xyz>m and -XX:MaxNewSize=<xyz>m
>> reveal that the problem occurs as soon as the NewSize rises beyond 1800m
>> which it obviously does by default.
>> > Below that threshold ParallelGC performance is similar to ParNewGC (in
>> the range of 7500 MB/s on my i7-2500MHz notebook), but at NewSize=2000m is
>> as low as 600 MB/s.
>> >
>> > Any ideas why this might happen?
>> >
>> > Note that the sample is constructed such that the live heap is always
>> around 3GB. If any I would expect a problem only at around NewSize=3GB,
>> when Old Gen shrinks to less than the live heap size. As a matter of fact,
>> ParNewGC can do >7000 MB/s from NewSize=400m to NewSize=3500m with little
>> variation around a maximum of 7600 MB/s at NewSize=2000m.
>> >
>> > I also provide source, gc.log and a plot of the NewSize dependency to
>> anyone interested in that problem.
>> >
>> > Regards
>> > Andreas
>> >
>> > -------------------------------------------------------MixedRandomList
>> > .java-----------------------------------------------------------------
>> > -------------------------------------------------------
>> > package de.am.gc.benchmarks;
>> >
>> > import java.util.ArrayList;
>> > import java.util.List;
>> >
>> > /**
>> > * GC benchmark producing a mix of lifetime=0 and lifetime>0 objects
>> which are kept in randomly updated lists.
>> > *
>> > * @author Andreas Mueller
>> > */
>> > public class MixedRandomList {
>> > private static final int DEFAULT_NUMBEROFTHREADS=1;
>> > // object size in bytes
>> > private static final int DEFAULT_OBJECTSIZE=100;
>> >
>> > private static int numberOfThreads=DEFAULT_NUMBEROFTHREADS;
>> > private static int objectSize=DEFAULT_OBJECTSIZE;
>> > // number of objects to fill half of the available memory with
>> (permanent) live objects
>> > private static long numLive =
>> > (Runtime.getRuntime().maxMemory()/objectSize/5);
>> >
>> > /**
>> > * @param args the command line arguments
>> > */
>> > public static void main(String[] args) {
>> > if( args.length>0 ) {
>> > // first, optional argument is the size of the objects
>> > objectSize = Integer.parseInt(args[0]);
>> > // second, optional argument is the number of live objects
>> > if( args.length>1 ) {
>> > numberOfThreads = Integer.parseInt(args[1]);
>> > // third, optional argument is the number of live
>> objects
>> > if( args.length>2 ) {
>> > numLive = Long.parseLong(args[2]);
>> > }
>> > }
>> > }
>> > for( int i=0; i<numberOfThreads; i++ ) {
>> > // run several GarbageProducer threads, each with its own
>> mix of lifetime=0 and higher lifetime objects
>> > new Thread(new
>> GarbageProducer((int)Math.pow(50.0,(double)(i+1)),
>> numLive/numberOfThreads)).start();
>> > }
>> > try {
>> > Thread.sleep(1200000);
>> > } catch( InterruptedException iexc) {
>> > iexc.printStackTrace();
>> > }
>> > System.exit(0);
>> > }
>> >
>> > private static char[] getCharArray(int length) {
>> > char[] retVal = new char[length];
>> > for(int i=0; i<length; i++ ) {
>> > retVal[i] = 'a';
>> > }
>> > return retVal;
>> > }
>> >
>> > public static class GarbageProducer implements Runnable {
>> >
>> > // the fraction of newly created objects that do not become
>> garbage immediately but are stored in the liveList
>> > int fractionLive;
>> > // the size of the liveList
>> > long myNumLive;
>> >
>> > /**
>> > * Each GarbageProducer creates objects that become garbage
>> immediately (lifetime=0) and
>> > * objects that become garbage only after a lifetime>0 which
>> is distributed about an average lifetime.
>> > * This average lifetime is a function of fractionLive and
>> numLive
>> > *
>> > * @param fractionLive
>> > * @param numLive
>> > */
>> > public GarbageProducer(int fractionLive, long numLive) {
>> > this.fractionLive = fractionLive;
>> > this.myNumLive = numLive;
>> > }
>> >
>> > @Override
>> > public void run() {
>> > int osize = objectSize;
>> > char[] chars = getCharArray(objectSize);
>> > List<String> liveList = new
>> ArrayList<String>((int)myNumLive);
>> > // initially, the lifeList is filled
>> > for(int i=0; i<myNumLive; i++) {
>> > liveList.add(new String(chars));
>> > }
>> > while(true) {
>> > // create the majority of objects as garbage
>> > for(int i=0; i<fractionLive; i++) {
>> > String garbageObject = new String(chars);
>> > }
>> > // keep the fraction of objects live by placing them
>> in the list (at a random index)
>> > int index = (int)(Math.random()*myNumLive);
>> > liveList.set(index, new String(chars));
>> > }
>> > }
>> > }
>> > }
>> > ----------------------------------------------------------------------
>> > ----------------------------------------------------------------------
>> > ---------------------------------------------------------------------
>> >
>> > Andreas M?ller
>> >
>> > mgm technology partners GmbH
>> > Frankfurter Ring 105a
>> > 80807 M?nchen
>> > Tel. +49 (89) 35 86 80-633
>> > Fax +49 (89) 35 86 80-288
>> > E-Mail Andreas.Mueller at mgm-tp.com<mailto:Andreas.Mueller at mgm-tp.com>
>> > Innovation Implemented.
>> > Sitz der Gesellschaft: M?nchen
>> > Gesch?ftsf?hrer: Hamarz Mehmanesh
>> > Handelsregister: AG M?nchen HRB 105068
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > hotspot-gc-use mailing list
>> > hotspot-gc-use at openjdk.java.net
>> > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>> http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20131021/62d044c7/attachment-0001.html
>>
>> ------------------------------
>>
>> _______________________________________________
>> hotspot-gc-use mailing list
>> hotspot-gc-use at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>>
>>
>> End of hotspot-gc-use Digest, Vol 68, Issue 5
>> *********************************************
>> _______________________________________________
>> hotspot-gc-use mailing list
>> hotspot-gc-use at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>>
>
>
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20131024/6cf4203d/attachment-0001.html
More information about the hotspot-gc-use
mailing list