RFR (s) 8059100: SIGSEGV VirtualMemoryTracker::remove_released_region

Coleen Phillimore coleen.phillimore at oracle.com
Fri Oct 10 18:33:59 UTC 2014


On 10/10/14, 1:39 PM, harold seigel wrote:
> Hi Coleen,
>
> Should MemTracker::transition_to(), in memTracker.cpp, assert if 
> current_level < level?

Harold, Thank you for looking at the code.

No, I don't want it to assert of level increases, I want it to ignore 
it.   Some other code in NMT tries to downgrade the tracking level to 
summary but it shouldn't have any effect if the tracking level was 
already set to minimal.  The execution is still valid.


> (Also, "courser locks" should be "coarser locks")

Fixed it, thanks!
>
> Does test ChangeTrackingLevel.java need an @bug 8059100 tag?

Yes, I fixed that too.

Thanks!
Coleen

>
> Thanks, Harold
>
>
> On 10/10/2014 10:16 AM, Coleen Phillimore wrote:
>> Summary: Disallow increasing native memory tracking level
>>
>> There was support in the code for increasing NMT reporting level, 
>> which causes inconsistencies when called by multiple threads. There 
>> was also a shutdown() call in final_report() which turned NMT off 
>> while other threads could be running.  The final_report() function 
>> modified the running baseline in place but other threads calling NMT 
>> while it is running could see the wrong data.
>>
>> Made final_report() snapshot a baseline which is safe enough during 
>> error handling and not call shutdown().  Removed the reset() function 
>> because it's unnecessary at best, and at worst, dangerous to do to 
>> the running baseline.
>>
>> Also if final_report calls shutdown() it can hang getting the malloc 
>> site table lock if the error reported is in the malloc site table, 
>> while holding the lock.
>>
>> Tested with an aurora ad-hoc (thanks George) and linux-x64 testbase, 
>> jck and jtreg tests.  All with nmt=detail and PrintNMTStatistics.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8059100/
>> bug link https://bugs.openjdk.java.net/browse/JDK-8059100
>>
>> Thanks,
>> Coleen
>>
>



More information about the hotspot-runtime-dev mailing list