RFR(xs): 8168542: os::realloc should return a valid pointer for input size=0

[Thomas Stüfe]

Hi Chris,

thank you for the review! I'll put this on the growing pile of jdk10 fixes
and hope we will have a repo soon to fix this in.

Kind Regards, Thomas

On Tue, Oct 25, 2016 at 10:19 PM, Chris Plummer <chris.plummer at oracle.com>
wrote:

> Hi Thomas,
>
> I don't exactly like the behavior our current os::malloc() and
> os::realloc() is attempting, which is to hide the native malloc and realloc
> inconsistencies with size 0 by always making it size 1. Like David said, it
> should be considered a caller bug when this happens. But since it already
> seems to be baked in, and fixing all callers is way outside the scope of
> this bug, your fix seems to be the best approach.
>
> You could actually move your fix inside the #ifndef ASSERT, since it will
> be redundant for the ASSERT case (it's already handled in os::malloc).
> However, it's probably cleaner before the #ifndef ASSERT, and makes it
> clear that no matter what the size is set to 1.
>
> BTW, you can't push this to 9 since it's a p4. It looks like the Fix
> Version is already set to 10, so I assume that's where it is going.
>
> cheers,
>
> Chris
>
>
> On 10/24/16 6:12 AM, Thomas Stüfe wrote:
>
>> Dear all,
>>
>> please check this tiny bug fix.
>>
>> Bug report:
>> https://bugs.openjdk.java.net/browse/JDK-8168542
>>
>> Webrev:
>> http://cr.openjdk.java.net/~stuefe/webrevs/8168542-os_reallo
>> c_size_0/webrev.00/webrev/
>>
>> In short, this fixes a corner case for os::realloc() which currently
>> returns NULL if input size is zero.
>>
>> But as we have coding which interprets a return value of NULL as OOM (See
>> ReallocateHeap()), this is not a good solution. It is also inconsistent
>> with how os::malloc() deals with the same situation and potentially with
>> the way the native C-Runtime deals with it (currently, in a debug build we
>> will return NULL in case of size=0 whereas in the release build we just
>> call the native ::realloc() and return whatever it returns.)
>>
>> Thank you,
>>
>> Thomas
>>
>
>
>
>