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

[Thomas Schatzl]

Hi again,

On Mon, 2017-03-06 at 13:48 +0100, Thomas Schatzl wrote:
> Hi David,
> 
> On Mon, 2017-03-06 at 21:38 +1000, David Holmes wrote:
> > 
> > Hi Thomas,
> > 
> > 
> [...]
> > 
> > - the code currently passes through the 0 as the number of
> > > 
> > > > 
> > > > threads!
> > > No. Explicitly setting it to zero means zero refinement threads
> > > as
> > > of
> > > current.
> > > 
> > > Refinement is an optimization, as in "G1 does not absolutely need
> > > refinement threads for operation", and this switch is part of the
> > > incantation to disable them. The mutators will do the refinement
> > > themselves.
> > > 
> > > There may be an inconsistency with the meaning of "0" when set
> > > explicitly for this kind of threads compared to others.
> > 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 there are a few of the heap sizing options where similar
behavior happens.

Not that this changes the problem, but it may be hard to change this
now.

Thanks,
  Thomas