RFR(S): 8058251 - assert(_count > 0) failed: Negative counter when running runtime/NMT/MallocTrackingVerify.java

Coleen Phillimore coleen.phillimore at oracle.com
Mon Oct 20 17:41:37 UTC 2014


On 10/11/14, 11:32 AM, Coleen Phillimore wrote:
>
> Hi Christian,
>
> This is a good cleanup.  As we were talking about, I suspect that the 
> tracking level was in the header for startup so that it could be 
> increased, which is something that isn't used.
>
> We should write a test that explicitly overflows the malloc site table 
> buckets though, if we don't have one already.
>
> But this code looks good and we should file another bug for the malloc 
> site table overflows and poor hashing.

For the record, I think we should do these two things in a different 
RFE, and check in the bug fix.

Thanks,
Coleen

>
> Thanks,
> Coleen
>
> On 10/10/14, 7:54 PM, Christian Tornqvist wrote:
>> Hi everyone,
>>
>>
>> Fairly small change which fixes one of the instances of assert(count 
>> > 0),
>> the issue was that the mallocSiteTable became full, NMT changed from 
>> detail
>> to summary but never updated the tracking level field in the malloc 
>> header.
>> Since the malloc was never inserted into the mallocSiteTable we didn't
>> update the bucket and position in the malloc header and when we later 
>> on was
>> trying to free that memory block we found tracking level == detailed and
>> used the never initialized fields for bucket and position indexes.
>>
>>
>> The only place that looked at the level field in the header was
>> MallocHeader::release and it could check the global level state 
>> instead. So
>> I removed the 2bit level  field from the malloc headers and this 
>> enabled me
>> to get rid of the 30bit malloc limitation on 32bit systems.
>>
>>
>> Also fixed a sign conversion issue on 32bit platforms in WB API
>> NMTMallocWithPseudoStack.
>>
>>
>> Note that this fix doesn't solve all the sources for the assert and 
>> I'm not
>> going to enable the test at this point as we continue to track down the
>> additional issues.
>>
>>
>> The fix has been tested using jprt and aurora adhoc with NMT.
>>
>>
>> Webrev:
>>
>> http://cr.openjdk.java.net/~ctornqvi/webrev/8058251/webrev.00/
>>
>>
>> Bug:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8058251
>>
>>
>> Thanks,
>>
>> Christian
>>
>>
>



More information about the hotspot-runtime-dev mailing list