RFR(S) 8156156: Add module specific NMT MemoryType

[Lois Foltan]

On 5/20/2016 10:59 AM, harold seigel wrote:
> Thanks Lois.
>
> Why do you think Hashtable<... mtModule> and HashtableEntry<... 
> mtModule> are needed.  There are no such entries for mtCode or 
> mtInternal.

I think it is best practice to explicitly instantiate the types you know 
the JVM is going to use/need.  And there seems to be a precedence for 
doing so in hashtable.cpp.
Lois

>
> Thanks, Harold
>
>
> On 5/20/2016 10:49 AM, Lois Foltan wrote:
>>
>> On 5/19/2016 4:00 PM, harold seigel wrote:
>>> Hi Lois,
>>>
>>> Thanks for the suggestions.  I added the allocations that you listed 
>>> below.
>>>
>>> Please see updated webrev: 
>>> http://cr.openjdk.java.net/~hseigel/bug_8156156.1/
>>
>> Thanks Harold for making this change!  Looks great, I think 
>> hashtable.cpp also needs a
>>
>>     Hashtable<Symbol*, mtModule>
>>     HashtableEntry<Symbol*, mtModule>
>>
>> I don't need to see another webrev.
>>
>> Lois
>>
>>>
>>> Thanks! Harold
>>>
>>>
>>> On 5/19/2016 10:40 AM, Lois Foltan wrote:
>>>>
>>>> On 5/19/2016 9:05 AM, harold seigel wrote:
>>>>> Hi,
>>>>>
>>>>> Please review this small change to add a module specific memory 
>>>>> type to hotspot native memory tracking (NMT).
>>>>>
>>>>> Open webrev: http://cr.openjdk.java.net/~hseigel/bug_8156156/
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8156156
>>>>>
>>>>> The change was tested with an RBT nightly test run, JCK lang and 
>>>>> VM tests, and UTE non-colocated quick tests.
>>>>
>>>> Hi Harold,
>>>>
>>>> This looks good.  Should we consider changing the 
>>>> fixup_module_field_list and ClassLoader's _xpatch_entries, 
>>>> _boot_modules_array and _platform_modules_array as well?
>>>>
>>>> Thanks,
>>>> Lois
>>>>
>>>>>
>>>>> Thanks, Harold
>>>>>
>>>>
>>>
>>
>