Free space calculation of heap

[Srinivas Ramakrishna]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20120602/f9831c51/attachment.html