RFR: Add NMT support for Java heap

Erik Österlund erik.osterlund at oracle.com
Thu Dec 14 15:45:26 UTC 2017


Hi Per,

I agree.

Thanks,
/Erik

On 2017-12-14 16:22, Per Liden wrote:
> Hi,
>
> On 2017-12-12 14:29, Erik Österlund wrote:
>> Hi Per,
>>
>> I suppose this does indeed depend on how you view things. To me, when
>> there are different interpretations what should be reported, I try to
>> understand why we are reporting it. If we report a number, then there
>> should be some kind of question to which the reported number provides an
>> answer.
>>
>> The number you propose now is accurate in terms of what is called by
>> mmap, but I do not know what useful question it answers. It will
>> seemingly report ~17 TB always regardless of potentially interesting
>> things such as, e.g. how close we are to hitting the roof of max memory
>> that may be committed. In other words, I am not sure what useful
>> question there is to which the answer is how much virtual address space
>> has been reserved by the Java heap.
>
> Given how NMT records/displays data, especially in "detail" mode where 
> it's not just one number but a ranges of reserved and committed, I 
> think we have two options here:
>
> 1) Register all heap views as reserved.
> 2) Register only one heap view as reserved.
>
> Only registering "max heap size" as reserved wouldn't really work, 
> again, since it's a range and we don't necessarily later commit memory 
> within that reserved range.
>
> None of the alternatives above are optimal, but at this time I think 
> #1 is slightly better, since at least it can answer two questions 
> truthfully (the usefulness of those questions is debatable):
>
> 1) What part of the address spaces does the GC actually reserve for 
> the Java heap. Could be useful to know if you want to e.g. set VA 
> limits (think ulimit -v).
> 2) And, as I mentioned before, how does this or that line in 
> /proc/.../maps correlate to the JVM memory usage?
>
> So, I'll suggest we do #1 for now. We'll change it if we find a good 
> reason to do so.
>
> cheers,
> Per
>
>>
>> Thanks,
>> /Erik
>>
>> On 2017-12-12 12:20, Per Liden wrote:
>>> On 2017-12-12 11:50, Aleksey Shipilev wrote:
>>>> On 12/12/2017 11:42 AM, Per Liden wrote:
>>>>> As Aleksey noticed, we don't register the Java heap with the native
>>>>> memory tracker. Here's a patch
>>>>> to do that.
>>>>>
>>>>> http://cr.openjdk.java.net/~pliden/zgc/nmt_java_heap/webrev.0/
>>>>
>>>> Patch looks good, but the NMT "reserved" data is off the charts:
>>>>
>>>> Total: reserved=17180280855KB, committed=17143487KB
>>>> -                 Java Heap (reserved=17179869184KB,
>>>> committed=16777216KB)
>>>>                             (mmap: reserved=17179869184KB,
>>>> committed=16777216KB)
>>>>
>>>> I guess this should not pass ZAddressSpaceSize, and instead tell the
>>>> reserved space of the first
>>>> mapping?
>>>>
>>>> +  // Register address space with native memory tracker
>>>> +  nmt_reserve(ZAddressSpaceStart, ZAddressSpaceSize);
>>>
>>> I think this is correct actually. But it depends on how one views
>>> things I guess. As I see it, I want to be able to look in
>>> /proc/../maps and with NMT see what the different mappings correlate
>>> to. If we only registered the first heap view, then there would be a
>>> big mysterious reservation that would go unaccounted. That doesn't
>>> sound right to me, but I'm open for hearing other opinions on this.
>>> The big number there covers all addresses for all heap views/mappings
>>> (i.e. the actual address space that is reserved). It should be noted
>>> that, in ZGC, the heap address space doesn't have a 1:1 relation with
>>> max heap size.
>>>
>>> cheers,
>>> Per
>>>
>>>>
>>>> Thanks,
>>>> -Aleksey
>>>>
>>



More information about the zgc-dev mailing list