Re: [RFC] Patch: RAM-based heuristics for ggc-min-heapsize and ggc-min-expand

[Richard Earnshaw <rearnsha at arm dot com>]

> >  > I will withdraw my objection if you can guarantee that specifying memory 
> >  > limits on the command line rather than using inbuilt heuristics will 
> >  > guarantee not to alter the address at which any data object is allocated.  
> >  > The guarantee must hold for all host platforms.
> >  > 
> >  > I suspect that in order to do this you must in effect run the heuristic 
> >  > (it might somehow end up calling malloc) and then discard the result if 
> >  > the command line overrides it.
> > 
> > If I understand you correctly, that's exactly what happens in the
> > original patch.  I.e. the heuristic value is calculated when cc1
> > initializes itself and setup right before argument processing.  If the
> > appropriate -param argument was supplied, the heuristic value is
> > discarded and the user's value is substituted.
> > 
> > Sound ok?
> 
> The thing is, that won't meet Richard's objection.  For instance, I bet
> the addresses of all stack allocated objects will change, because argv
> will be longer.
> 
> If we want guaranteed reproducibility, I really think it has to be in
> the driver.

That is quite possibly true, but I think I'd be prepared concede that 
particular instance.  The really important thing is that all objects 
allocated with either malloc or the GC allocation strategies should not 
put objects at different addresses.

I once had to debug a memory problem where adding -da to the compiler 
options caused the problem to vanish -- the (mental) scars are obviously 
still visible...

R.