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

[David Holmes]

On 7/03/2017 4:01 AM, Kim Barrett wrote:
>> On Mar 6, 2017, at 7:57 AM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
>>>> It is very bad form to have 0 as a default mean one thing, and 0 as
>>>> an explicit value meaning something else IMHO. If 0 is a legal
>>>> value
>>>> then -1, or some other value should have been chosen to mean "use
>>>> ergonomics".
>>>   I agree that this is not obvious to understand. I created JDK-
>>> 8176211.
>>
>>  actually there is precedent for different behavior depending on
>> setting something explicitly to the same value vs. not setting it, i.e.
>> for the marking threads.
>>
>> CMS also has the same policy for threads like for forever (default
>> ConcGCThreads=0 means "use ergonomics", explicit ConcGCThreads=0 means
>> something different).
>
> I think this is the wrong way think about the semantics. The right way
> is an explicit value means use that value. If no explicit value, then
> default using ergonomics. The initial default value is a meaningless
> implementation artifact; we don't have a direct way to say "does not
> have a value, and an access attempt is an error", nor do we have a way
> to leave an option uninitialized.

Except sometimes 0 means use the system default, even if set explicitly. 
But I see your point this is not as clear cut as I would have hoped.

Any way we're hijacking, or at least side-tracking, this thread :)

Thanks,
David

> Using a bogus sentinel value as the "uninitialized" value has the
> usual typing problems.  For example, these thread count options have
> an unsigned type, which is incompatible with a -1 sentinel value.
> Making the count variable have a signed type has other problems.
> What one needs in a case like this is a separate "has a value" flag,
> and an access protocol that checks it.  Using bare global variables
> for options and direct references to access them doesn't let us do
> that sort of thing.
>