RFR: 8234331: Add robust and optimized utility for rounding up to next power of two+

[Erik Österlund]

Hi Claes,

Sure. Looks good!

Thanks,
/Erik

> On 5 Dec 2019, at 23:24, Claes Redestad <claes.redestad at oracle.com> wrote:
> 
> 
> 
>> On 2019-12-05 19:04, Claes Redestad wrote:
>>> On 2019-12-05 18:49, Erik Österlund wrote:
>>> Hi Claes,
>>> 
>>> I wonder what issue you ran into with std::numeric_limit on Solaris. I would personally like to understand that
>>> before dismissing its use and rolling our own function instead.
>>> Note that std::numeric_limit does not accept CV qualified types - perhaps that is what you ran into.
>> slowdebug failed to build with the following:
>> [2019-12-05T01:34:22,502Z] Undefined            first referenced
>> [2019-12-05T01:34:22,502Z]  symbol                  in file
>> [2019-12-05T01:34:22,502Z] unsigned
>> std::_Integer_limits<unsigned,0U,4294967295U,-1,true>::max()
>>> 
>>> Perhaps if you pass in RemoveCv<T>::type instead of T to that trait, things will work properly.
>>> If you really want to note use numeric_limit, then you might have to stick in some more sanity checks in
>>> that functions, such as checking that the input is integral, etc. And dynamically calculating the limit
>>> does seem unfortunate. In that case I'd rather we rolled our own numeric limit trait, but I would be
>>> surprised if that is indeed necessary.
>> I can try the RemoveCv<T> trick. This "private" max_value utility is not
>> performance critical since it's only used for an assert and in tests,
>> but yes it'd be much preferable if we could use std::numeric_limits<..>
> 
> This doesn't fix the slowdebug build failure on Solaris.
> 
> Ok if I file a follow-up bug to examine this in depth, and move ahead with the version here (open.05)?
> 
> /Claes