RFR(xs) 8223336: Assert in VirtualMemoryTracker::remove_released_region when running the SharedArchiveConsistency.java test with -XX:NativeMemoryTracking=detail

Calvin Cheung calvin.cheung at oracle.com
Thu May 30 22:17:38 UTC 2019


Hi Jiangli,

Thanks for taking a look.

On 5/30/19, 1:36 PM, Jiangli Zhou wrote:
> Hi Calvin,
>
> There is a known bug in NMT that causes mapped shared spaces not being
> tracked as 'committed':
> https://bugs.openjdk.java.net/browse/JDK-8146637. The bug is closed,
> but not fixed. Could you please check if that's related?
I don't think they are related. JDK-8146637 seems to indicate that 
although MemTracker::record_virtual_memory_reserve_and_commit() is 
called, the memory is not being recorded as "reserved" and "committed". 
For this bug, it is clear that the call to 
MemTracker::record_virtual_memory_reserve() is missing on Windows.

I adjusted the fix a little by calling 
MemTracker::record_virtual_memory_reserve() right before 
release_memory(). This would avoid 
VirtualMemoryTracker::add_reserved_region() being called twice in case 
the function returns normally.

updated webrev: http://cr.openjdk.java.net/~ccheung/8223336/webrev.01/

thanks,
Calvin
>
> Best regards,
> Jiangli
>
> On Thu, May 30, 2019 at 1:05 PM Calvin Cheung<calvin.cheung at oracle.com>  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