RFR: 8178495: Bug in the align_size_up_ macro

Robbin Ehn robbin.ehn at oracle.com
Wed Jun 28 20:00:39 UTC 2017


Looks good.

Is there a problem with always widen it to ULL ?

E.g.
~((alignment) - 1ULL)

Your widen_to_type_of is obliviously much cleaner.

Thanks for fixing!

/Robbin

On 06/28/2017 05:08 PM, Stefan Karlsson wrote:
> Hi all,
> 
> Please review this patch to fix a bug in the align_size_up_ macro.
> 
> http://cr.openjdk.java.net/~stefank/8178495/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8178495
> 
> The following:
>   align_size_up_((uintptr_t)0x512345678ULL, (int8_t) 16);
>   align_size_up_((uintptr_t)0x512345678ULL, (int16_t) 16);
>   align_size_up_((uintptr_t)0x512345678ULL, (int32_t) 16);
>   align_size_up_((uintptr_t)0x512345678ULL, (int64_t) 16);
> 
>   align_size_up_((uintptr_t)0x512345678ULL, (uint8_t) 16);
>   align_size_up_((uintptr_t)0x512345678ULL, (uint16_t)16);
>   align_size_up_((uintptr_t)0x512345678ULL, (uint32_t)16);
>   align_size_up_((uintptr_t)0x512345678ULL, (uint64_t)16);
> 
> Gives this output:
>   0x512345680
>   0x512345680
>   0x512345680
>   0x512345680
> 
>   0x512345680
>   0x512345680
>    0x12345680
>   0x512345680
> 
> So, align_size_up_((uintptr_t)0x512345678ULL, (uint32_t)16) returns an unexpected, truncated value.
> 
> This happens because in this macro:
> #define align_size_up_(size, alignment) (((size) + ((alignment) - 1)) & ~((alignment) - 1))
> 
> ~((alignment) - 1) returns 0x00000000FFFFFFF0 instead of 0xFFFFFFFFFFFFFFF0
> 
> This isn't a problem for the 64-bit types, and maybe more non-obvious is that it doesn't happen for types 8-bit and 16-bit types.
> 
> For the 8-bit and 16-bit types, the (alignment - 1) is promoted to a signed int, when it later is used in the & expression it is signed extended into a signed 64-bit value.
> 
> When the type is an unsigned 32-bit integer, it isn't promoted to a signed int, and therefore it is not singed extended to 64 bits, but instead zero extended to 64 bits.
> 
> This bug is currently not affecting the code base, since the inline align functions promote all integers to intptr_t, before passing them down to the align macros. However, 
> when/if JDK-8178489 <https://bugs.openjdk.java.net/browse/JDK-8178489> is pushed the macro is actually used with 32 bits unsigned ints.
> 
> Tested with the unit test and JPRT with and without patches for JDK-8178489 <https://bugs.openjdk.java.net/browse/JDK-8178489>.
> 
> Thanks,
> StefanK


More information about the hotspot-dev mailing list