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

Jon Masamitsu jon.masamitsu at oracle.com
Tue Feb 26 18:49:26 UTC 2013



On 02/24/13 01: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.
>
> From this initial run, what do you think? Do you think the numbers 
> warrants further benchmarking or looking into an alternative solution?

I think my concern here with GC times will be addressed
by 8008966 so I think we're good here.

Jon

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



More information about the hotspot-gc-dev mailing list