RFR: 8033440: jmap reports unexpected used/free size of concurrent mark-sweep generation

Dmitry Samersoff dmitry.samersoff at oracle.com
Fri Feb 14 07:12:49 PST 2014


Looks good for me.


On 2014-02-14 18:45, Stefan Johansson wrote:
> Thanks Coleen!
> Yes, as you and Mikael said, the code is needed to calculate the used
> and free amount for the CMS generation and this is used by jmap. I guess
> the types I removed had been put there to prepare for some other SA
> feature that never came around.
> Cheers,
> Stefan
> On 2014-02-14 15:29, Coleen Phillimore wrote:
>> This cleanup looks good.  To answer my own question (which you wrote
>> earlier), it looks like jmap uses this code and I assume the work on
>> SA.NEXT will address the duplication.
>> Thanks,
>> Coleen
>> On 2/14/14 8:47 AM, Stefan Johansson wrote:
>>> Hi,
>>> Please review this change to fix:
>>> https://bugs.openjdk.java.net/browse/JDK-8033440
>>> Webrev:
>>> http://cr.openjdk.java.net/~sjohanss/8033440/webrev.00/
>>> Summary:
>>> The compactibleFreeListSpace has been updated to use an
>>> AdaptiveFreeList instead of a FreeList. This change has not been done
>>> for the SA and it leads to using a too small element size when
>>> walking through the list. When fixing this I realized that
>>> FreeList<FreeChunk> and some other type declarations associated with
>>> it weren't used by the SA, so I went ahead and removed them. I (or
>>> Eclipse) also changed the Java *-imports to be specific ones.
>>> Testing:
>>> * JPRT for build and sanity.
>>> * UTE run for tests listed in bug.
>>> * Aurora run for tmtools.testlist.
>>> Thanks,
>>> Stefan

Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

More information about the hotspot-dev mailing list