RFR(xs) 8223336: Assert in VirtualMemoryTracker::remove_released_region when running the SharedArchiveConsistency.java test with -XX:NativeMemoryTracking=detail
Zhengyu Gu
zgu at redhat.com
Fri May 31 19:42:36 UTC 2019
Looks good.
-Zhengyu
On 5/31/19 3:36 PM, Calvin Cheung wrote:
>
>
> On 5/31/19, 4:54 AM, Zhengyu Gu wrote:
>>
>>
>> On 5/31/19 12:37 AM, Calvin Cheung wrote:
>>> Hi Zhengyu,
>>>
>>> On 5/30/19, 5:18 PM, Zhengyu Gu wrote:
>>>> Sorry. I think MemTracker::record_virtual_memory_reserve() should be
>>>> called before ReadFile() call, so it has a record for succeeded case.
>>> My first version of webrev does what you're suggesting. (I can add
>>> the comment as you listed below.)
>>> http://cr.openjdk.java.net/~ccheung/8223336/webrev.00/
>>
>> Yes. Please change Line #4912 to
>> MemTracker::record_virtual_memory_reserve_and_commit((address)addr,
>> bytes, CALLER_PC);
>>
>> I made copy-past error in early reply.
> Just for the record, updated webrev:
> http://cr.openjdk.java.net/~ccheung/8223336/webrev.03/
>
> I also ran all NMT tests via mach5 and they all passed.
>>
>>>
>>> The reason I moved the function call right before release_memory() is
>>> that the caller will call record_virtual_memory_reserve_and_commit()
>>> on a successful return. In that case, the
>>> VirtualMemoryTracker::add_reserved_region() will be called twice.
>>> After reading the code, add_reserved_region() will try to search the
>>> region from _reserved_regions. If the region exists, it won't be
>>> added. So I think it's fine to go with webrev.00.
>> Right, this is known problem:
>> https://bugs.openjdk.java.net/browse/JDK-8198226
> Thanks for the pointer to RFE.
>
> thanks,
> Calvin
>>
>> Thanks,
>>
>> -Zhengyu
>>
>>>
>>> thanks,
>>> Calvin
>>>>
>>>> E.g.
>>>> if (base == NULL) {
>>>> log_info(os)("VirtualAlloc() failed: GetLastError->%ld.",
>>>> GetLastError());
>>>> CloseHandle(hFile);
>>>> return NULL;
>>>> }
>>>>
>>>> // Record virtual memory allocation
>>>> MemTracker::record_virtual_memory_reserve((address)addr, bytes,
>>>> CALLER_PC);
>>>>
>>>> DWORD bytes_read;
>>>> OVERLAPPED overlapped;
>>>> overlapped.Offset = (DWORD)file_offset;
>>>> overlapped.OffsetHigh = 0;
>>>> overlapped.hEvent = NULL;
>>>> // ReadFile guarantees that if the return value is true, the
>>>> requested
>>>> // number of bytes were read before returning.
>>>> bool res = ReadFile(hFile, base, (DWORD)bytes, &bytes_read,
>>>> &overlapped) != 0;
>>>> if (!res) {
>>>> log_info(os)("ReadFile() failed: GetLastError->%ld.",
>>>> GetLastError());
>>>> release_memory(base, bytes);
>>>> CloseHandle(hFile);
>>>> return NULL;
>>>> }
>>>>
>>>>
>>>> -Zhengyu
>>>>
>>>>
>>>> On 5/30/19 7:52 PM, Calvin Cheung wrote:
>>>>> Hi Zhengyu,
>>>>>
>>>>> Thanks for your review.
>>>>>
>>>>> Here's an updated webrev with your suggested change:
>>>>> http://cr.openjdk.java.net/~ccheung/8223336/webrev.02/
>>>>>
>>>>> thanks,
>>>>> Calvin
>>>>>
>>>>> On 5/30/19, 4:25 PM, Zhengyu Gu wrote:
>>>>>> Hi Calvin,
>>>>>>
>>>>>> Thanks for fixing it.
>>>>>>
>>>>>> Since VirtualAlloc call has MEM_COMMIT flag set, I think it should
>>>>>> be tracked as committed memory, e.g.
>>>>>>
>>>>>> MemTracker::record_virtual_memory_reserve_and_commit((address)addr, bytes,
>>>>>> CALLER_PC);
>>>>>>
>>>>>> -Zhengyu
>>>>>>
>>>>>> On 5/30/19 4:04 PM, Calvin Cheung wrote:
>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8223336
>>>>>>>
>>>>>>> webrev: http://cr.openjdk.java.net/~ccheung/8223336/webrev.00/
>>>>>>>
>>>>>>> A simple fix is adding the missing call to
>>>>>>> MemTracker::record_virtual_memory_reserve() in the Windows
>>>>>>> version of os::pd_map_memory().
>>>>>>> On platforms other than Windows, the os::pd_map_memory() doesn't
>>>>>>> call release_memory() and the caller (os::map_memory()) calls
>>>>>>> MemTracker::record_virtual_memory_reserve() if the returned value
>>>>>>> from os::pd_map_memory() is non-NULL. That's why this bug
>>>>>>> reproduces only on Windows.
>>>>>>>
>>>>>>> Testing: ran SharedArchiveConsistency.java with
>>>>>>> -XX:NativeMemoryTracking=detail on Windows;
>>>>>>> ran all runtime/NMT tests on Windows.
>>>>>>>
>>>>>>> thanks,
>>>>>>> Calvin
More information about the hotspot-runtime-dev
mailing list