RFR: 8146523: Incorrect memory tracker used by os::unmap_memory()

Ioi Lam ioi.lam at oracle.com
Thu Jan 7 23:30:23 UTC 2016


Oops, please ignore most of what I said here. I just realized that 
os::map_memory/unmap_memory is called only by CDS.

- Ioi


On 1/7/16 3:12 PM, Ioi Lam wrote:
> On 1/7/16 1:30 PM, Jiangli Zhou wrote:
>>
>>>>
>>>> On 1/7/16 2:34 PM, Ioi Lam wrote:
>>>>> Hi Jiangli,
>>>>>
>>>>> I looked at the implementatiion of os::pd_unmap_memory on windows 
>>>>> but I can't figure out how it would affect the memory tracker:
>>>>>
>>>>> os.cpp:
>>>>>
>>>>>      bool os::unmap_memory(char *addr, size_t bytes) {
>>>>>        bool result;
>>>>>        if (MemTracker::tracking_level() > NMT_minimal) {
>>>>>   + #ifndef _WINDOWS
>>>>>   +     Tracker tkr = 
>>>>> MemTracker::get_virtual_memory_uncommit_tracker();
>>>>>   + #else
>>>>>   +     // Windows pd_unmap_memory also does memory release, so use
>>>>>   +     // the virtual_memory_release_tracker for windows
>>>>>          Tracker tkr = 
>>>>> MemTracker::get_virtual_memory_release_tracker();
>>>>>   + #endif
>>>>>
>> Could you please explain why the comment is wrong? On linux/unix 
>> platforms, we have extra code to do explicit memory ‘reserve’ and 
>> ‘release’, which calls NMT to track the reserve and release of the 
>> related memory region. Mapping and unmaping are performed on the 
>> memory regions that are already ‘reserved’ on those platform.
>> On windows, there are no explicit calls to do memory ‘reserve’ before 
>> mapping and ‘release’ after unmapping.
> This is not true. There's platform-independent code in virtualspace.cpp:
>
>     ReservedSpace::initialize -> os::reserve_memory -> 
> os::pd_reserve_memory.
>
> There's no #ifdef WINDOWS on this path and os::pd_reserve_memory() is 
> actually implemented in os_windows.cpp
>
> What you said may be true for CDS:
>
>    bool MetaspaceShared::map_shared_spaces(FileMapInfo* mapinfo) {
>    #ifndef _WINDOWS
>       // Map in the shared memory and then map the regions on top of it.
>       // On Windows, don't map the memory here because it will cause the
>       // mappings of the regions to fail.
>       ReservedSpace shared_rs = mapinfo->reserve_shared_memory();
>
> but that's not true in general. There are plenty of ReservedSpace used 
> in platform-independent GC code.
>> So the memory mapping/unmapping APIs have the implicit 
>> ‘reserve’/‘release’ behaviors. That’s why for windows the 
>> release_tracker is used to reflect the behavior of unmapping with 
>> implicit ‘release’, and the linux/unix only needs the uncommit_tracker.
> Also the comment implies that pd_unmap_memory always calls 
> pd_release_memory, but this is not true:
>
>    bool os::pd_unmap_memory(char* addr, size_t bytes) {
>       ...
>       if (mem_info.Protect == PAGE_EXECUTE_READ ||
>           mem_info.Protect == PAGE_EXECUTE_READWRITE) {
>         return pd_release_memory(addr, bytes);
>       }
>       ...
>    }
>
> Even on Windows, won't we eventually call os::release_memory(), which 
> would properly record the removal using 
> get_virtual_memory_release_tracker? Yes, CDS is an exception, but that 
> should be dealt with in the CDS code, not in the generic os.cpp code. 
> And, I am not particularly worried about the CDS case, since it 
> happens only when mapping of some of the CDS regions has failed.
>
> Are you sure we need the special case for Windows here? Have you 
> tested NMT on Windows without the #ifdef?
>
> The NMT code is quite messy. I don't want to make it worse by adding 
> more #ifdefs with comments that are only partially true.
>
> Thanks
> - Ioi
>



More information about the hotspot-runtime-dev mailing list