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

[Chris Plummer]

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