RFR(xxxs) (jdk10): 8168542: os::realloc should return a valid pointer for input size=0
kim.barrett at oracle.com
Mon Mar 6 18:01:58 UTC 2017
> 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
>>> then -1, or some other value should have been chosen to mean "use
>> I agree that this is not obvious to understand. I created JDK-
> 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.
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.
More information about the hotspot-runtime-dev