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

[Erik Helin]

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.

 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
>>>
>>