RFR: 8062870: src/share/vm/services/mallocTracker.hpp:64 assert(_count > 0) failed: Negative ,counter
Coleen Phillimore
coleen.phillimore at oracle.com
Tue Nov 11 02:06:17 UTC 2014
You are right! I didn't get 256 because my fix didn't compile on 64 bit
due to the extra parenthesis I added around 1<<40.
I'm changing it to use right_n_bits(40), 16 and 8. Nothing good ever
comes from C shifts.
Thanks!
Coleen
On 11/10/14, 7:21 PM, John Rose wrote:
> I think on many LP64 platforms the value of (1<<40) is 256, same as (1<<8). It will seldom be the intended value of (int64_t)1<<40.
>
> The C "<<" operator is notoriously devious (not to say shifty).
>
> For shift/mask arithmetic we should be continuing to use macros from globalDefinitions.hpp.
> They are far more reliable than C expressions.
>
> — John
>
> On Nov 10, 2014, at 9:21 AM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
>
>> Summary: Signed bitfield size y can only have (1 << y)-1 values.
>>
>> We were overflowing the the _pos index and reusing the 0th element in the MallocSiteTable for two different stack traces which caused the assert for deallocation.
>>
>> Tested with nsk.quick.testlist and jtreg runtime tests with -XX:NativeMemoryTracking=detail.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8062870/
>> bug link https://bugs.openjdk.java.net/browse/JDK-8062870
>>
>> Thanks,
>> Coleen
More information about the hotspot-runtime-dev
mailing list