ParallelGC issue: collector does only Full GC
Peter B. Kessler
Peter.B.Kessler at Oracle.COM
Thu Oct 24 11:09:42 PDT 2013
Pack-rat that I am*, I have your original message including the attachments (two charts: BetterPredictionFilter_time.tiff and BetterPredictionFilter_time_start.tiff). If you have trouble finding them I can send them back to you. If you have trouble uploading them to the bug report, maybe I can do that.
... peter
* I don't need a garbage collector, I just need a lot of memory. :-)
On 10/24/13 10:50, Srinivas Ramakrishna wrote:
>
> The email I had in mind was this one:-
>
> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2013-May/007092.html
>
> It appears as though the attachments I had sent were scrubbed, so folks on the list may not have seen the
> attachments. I'll see if I can dig them up and reconstruct it again. I also couldn't find the email in which I promised to
> send the fix I had in mind, although that can pretty much be constructed from the email description.
>
> I'll see if I can find the relevant attachments and upload them into a bug report of this. I have only been
> half-following this exchange, so it's possible that it's somewhat tangentially related, but definitely
> related to the prediction model for how much gets promoted.
>
> -- ramki
>
>
>
> On Thu, Oct 24, 2013 at 10:12 AM, Srinivas Ramakrishna <ysr1729 at gmail.com <mailto:ysr1729 at gmail.com>> wrote:
>
> 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 <mailto: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 <mailto: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 <mailto: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 <mailto:hotspot-gc-use at openjdk.java.net>
> Message-ID: <5265AAB6.1050700 at oracle.com <mailto: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 <tel:%2B49%20%2889%29%2035%2086%2080-633>
> > Fax+49 (89) 35 86 80-288 <tel:%2B49%20%2889%29%2035%2086%2080-288>
> > E-MailAndreas.Mueller at mgm-tp.com <mailto:Andreas.Mueller at mgm-tp.com><mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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
>
More information about the hotspot-gc-use
mailing list