RFR(xxs): 8210314: [aix] NMT does not show "Safepoint" memory type

[Thomas Stüfe]

Hi Martin,

On Mon, Sep 3, 2018 at 2:36 PM, Doerr, Martin <martin.doerr at sap.com> wrote:
> Hi Thomas,
>
> thanks for explaining. I think using "record_virtual_memory_reserve_and_commit" makes sense because it combines "reserve" and "commit" which matches what the implementation does.
>

Yes, that was what I was thinking. Save that we do not really commit
on AIX, we just think we do. But still slightly more correct than the
no-commit version.

> The change looks good to me.

Thanks. I already pushed, so I cannot add your name to the reviewers
list, sorry.

..Thomas

>
> Thanks,
> Martin
>
>
> -----Original Message-----
> From: ppc-aix-port-dev <ppc-aix-port-dev-bounces at openjdk.java.net> On Behalf Of Thomas Stüfe
> Sent: Montag, 3. September 2018 13:27
> To: Baesken, Matthias <matthias.baesken at sap.com>
> Cc: ppc-aix-port-dev at openjdk.java.net; Hotspot dev runtime <hotspot-runtime-dev at openjdk.java.net>
> Subject: Re: RFR(xxs): 8210314: [aix] NMT does not show "Safepoint" memory type
>
> Hi Matthias,
>
> thanks for the review.
>
>
> On Mon, Sep 3, 2018 at 12:29 PM, Baesken, Matthias
> <matthias.baesken at sap.com> wrote:
>> Hi Thomas, looks good  to me ( not a Reviewer however).
>>
>>
>> One other small difference I noticed  when comparing   AIX  to other UNIX implementations (e.g. linux / bsd ) :
>>
>> In  perfMemory_aix.cpp  /  mmap_create_shared   and  mmap_attach_shared     we call
>>
>>      MemTracker::record_virtual_memory_reserve(...)
>>
>> While  in   perfMemory_linux.cpp  (bsd  and solaris as well)   we call
>>
>>     MemTracker::record_virtual_memory_reserve_and_commit(...)
>>
>>
>> Is there  really  a need  for different call on  AIX ?
>>
>>
>
> In short, record_virtual_memory_reserve() should only be used
> whereever mmap( ... MAP_NORESERVE ...) is used. So,
> MemTracker::record_virtual_memory_reserve_and_commit(...) would be
> more correct.
>
> However, on AIX we have no explicit commit (os::commit()) is a noop,
> and there is no MAP_NORESERVE - the system just provides swapping
> space by default as needed. So, this aspect of NMT - the "committed"
> numbers for virtual memory - is right now broken, just a rough
> estimate, and right now I have absolutely no clue how to fix it.
>
> Best Regards, Thomas
>
>>
>> And   the z GC code base   ( jdk/src/hotspot/os_cpu/linux_x86/gc/z/)     contains also  a couple of mmap calls , wonder where those are recorded .
>>
>>
>> Best regards, Matthias
>>
>>
>>> -----Original Message-----
>>> From: ppc-aix-port-dev <ppc-aix-port-dev-bounces at openjdk.java.net> On
>>> Behalf Of Thomas Stüfe
>>> Sent: Montag, 3. September 2018 11:46
>>> To: Hotspot dev runtime <hotspot-runtime-dev at openjdk.java.net>; ppc-
>>> aix-port-dev at openjdk.java.net
>>> Subject: RFR(xxs): 8210314: [aix] NMT does not show "Safepoint" memory
>>> type
>>>
>>> Hi all,
>>>
>>> may I please have reviews for this small, AIX-only change.
>>>
>>> cr: http://cr.openjdk.java.net/~stuefe/webrevs/8210314-aix-NMT-does-
>>> not-show-safepoint-memory/webrev.00/webrev/
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8210314
>>>
>>> On AIX, we have our own initialization for the safepoint mechanism. We
>>> missed registering the polling page with NMT, which the generic code
>>> path did. This patch adds that.
>>>
>>> Side note:
>>>
>>> We are different for two reasons. One, on ppc we use per default
>>> SIGTRAP for safepoint signalling, which can be switched off though.
>>> Second, on AIX, we cannot use os::reserve_memory() to obtain a polling
>>> page since that memory may not protectable (if it uses sysV shmat).
>>> Hence, the AIX specific coding.
>>>
>>> Best Regards, Thomas