Free space calculation of heap

[Damon Hart-Davis]

Please note that at least in my embedded application there is only one CPU, so parallel GC is not necessarily the right thing to do!

Rgds

Damon


On 3 Jun 2012, at 04:38, Srinivas Ramakrishna wrote:

> Ah, I see... But is there much use of (i?)cms in the embedded world? I thpught parallel gc's pauses would
> generally be tolerable for the usually small heaps used there. (But i guess may be the
> processors are much slower too, so perhaps icms still has a bit of a market there?)
> 
> If it's worthwhile for the "embedded" area, perhaps have this fixed in "embedded" SE  first
> and push the changes into SE hotspot from there?
> 
> http://hg.openjdk.java.net/hsx/hotspot-emb/hotspot
> 
> -- ramki
> 
> 
> On Sat, Jun 2, 2012 at 12:10 AM, Damon Hart-Davis <dhd at exnet.com> wrote:
> Some of us running 'embedded' might still quite like it, eg as space for an extra thread's stack!  B^>
> 
> Rgds
> 
> Damon
> 
> 
> On 2 Jun 2012, at 02:44, Srinivas Ramakrishna wrote:
> 
> >
> >
> > On Fri, Jun 1, 2012 at 12:10 PM, Srinivas Ramakrishna <ysr1729 at gmail.com> wrote:
> > ...
> >
> > Free in BTD: 546527717
> > Free in IFL:       1221215
> >                      -----------------
> > Total Free:    547748932  heap words =  (547748932 * 8 /1024) KB = 4279289 KB
> >
> > As reported in PrintHeapAtGC: total 4476928K, used 197511K
> > From above line, computed free space = (4476928 - 197511) KB = 4279417 KB
> >
> > "Lost" free space = (4279417 - 4279289) KB = 128 KB
> >
> > OK, given that i arrived at the number you reported as missing, I guess I understood yr question correctly.
> >
> > This is interesting. It's been a great while since I looked at this code, but I know that CMS uses
> > part of the old gen space to store certain book-keeping structures associated
> > with promotion ("promo info" and certain header word "spooling buffers") in the old gen heap. It allocates these
> > buffers out of the old gen eagerly and doesn't return them unless we completely run out of space. (This policy
> > should probably be revised, so it lazily returns free buffers.) However, it was my understanding that these
> > buffers are reported as part of the used space. May be the book-keeping for space used doesn't take these
> > into account, in which case I am surprised. Probably worth poking around in the code to see what's going on.
> > I'll try and do that if I get some time, unless someone from the JVM team gets to it sooner, especially
> > those who may have poked around in that code recently may be...
> >
> >
> > An offline exchange with Jon and a quick browse of the code revealed that the space was in a linear allocation
> > block that sits in the old gen. Not quite sure if or when it's used for allocation. Quite possibly a vestige from earlier
> > experiments that may not have gotten deleted. So may be the result of this discussion is a new bonus of 128 KB
> > in the old gen, if we can somehow neutralize the lab refilling.Given that it's hump change for usually large
> > CMS sizes, probably not worth the effort.
> >
> > -- ramki
> >
> > _______________________________________________
> > hotspot-gc-use mailing list
> > hotspot-gc-use at openjdk.java.net
> > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
> 
>