RFR: 8000754: NPG: Implement a MemoryPool MXBean for Metaspace

[Mikael Gerdin]

Erik,

On 2013-02-24 10:46, Erik Helin wrote:
> Jon,
>
> On 02/21/2013 09:14 PM, Jon Masamitsu wrote:
>> On 02/21/13 07:57, Erik Helin wrote:
>>> Jon,
>>>
>>> thanks for the review!
>>>
>>> On 02/21/2013 05:22 AM, Jon Masamitsu wrote:
>>>> Erik,
>>>>
>>>> These changes look good.
>>>
>>> Thanks!
>>>
>>> On 02/21/2013 05:22 AM, Jon Masamitsu wrote:
>>>> used_in_bytes() and capacity_in_bytes() do run
>>>> over the classloader data graph and as such
>>>> are not free to call.  I generally think to use them
>>>> in assertion checking or where I don't expect
>>>> them to be executed much.  Here I expect they
>>>> are executed in response to some type of
>>>> intermittent query.  If you think they will be
>>>> executed continuously, we should talk about
>>>> the alternatives.
>>>
>>> Thanks, I didn't know that used_in_bytes() and capacity_in_bytes() were
>>> expensive. I looked at the consumers of the
>>> MetaspacePoolBase::get_memory_usage()
>>> and it is executed due to a couple of reasons:
>>> - From Java:
>>>   - MemoryMXBean.getHeapMemoryUsage()
>>>   - MemoryMXBean.getNonHeapMemoryUsage()
>>>   - MemoryPoolMXBean.getUsage()
>>
>> These should be OK since they are on demand.
>>
>>> - From the VM:
>>>   - At the start and end of GC to provide different *MXBeans with the
>>>     memory usage before and after a GC.
>>>   - Bookkeeping to support the *MXBeans with low memory detection as
>>>     well as peak memory usage.
>>
>> We should measure GC times and see if we can see any difference.
>> Some benchmark that has lots of class loaders would be interesting.
>> Maybe the runtime/ParallelClassLoading tests.  When I run those in
>> ute, I use
>>
>> ute -test runtime/ParallelClassLoading
>
> I run "ute -test runtime/ParallelClassLoading" for both hotspot-gc and
> hotspot-gc + the memory pools patch. The results were the following:
>
> hotspot-gc + memory pools patch:
> real    207m36.299s
> user    216m50.797s
> sys     5m41.913s
>
> hotspot-gc:
> real    207m14.067s
> user    216m50.229s
> sys     6m0.571s
>
> So, from this one-time run, it the memory pool patch is 22.162 seconds
> slower.

I don't think the total run time is that interesting since the tests are 
supposed to be time limited.
I think Jon was asking for GC times parsed out of +PrintGCDetails output 
so we can compare how long the actual GC pauses were.

/Mikael

>
>  From this initial run, what do you think? Do you think the numbers
> warrants further benchmarking or looking into an alternative solution?
>
> Thanks,
> Erik
>
>> Jon
>>>
>>> Do you think that they methods are too expensive for this kind of usage?
>>>
>>> Thanks,
>>> Erik
>>>
>>>> Jon
>>>>
>>>>
>>>>
>>>> On 2/20/2013 3:02 AM, Erik Helin wrote:
>>>>> Hi,
>>>>>
>>>>> this change implements a new MemoryManagerMXBean, MetaspaceManager, as
>>>>> well as two new MemoryPoolMXBeans: Metaspace and Class Metaspace. I
>>>>> have
>>>>> also written a tests that tests the new beans.
>>>>>
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~ehelin/8000754/webrev.01/
>>>>>
>>>>> Bug:
>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8000754
>>>>>
>>>>> Testing:
>>>>> JPRT
>>>>> New jtreg test
>>>>>
>>>>> Thanks,
>>>>> Erik
>>>>
>>>
>