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