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

[Coleen Phillimore]

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.

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
>
>   
>