[PATCH] Reduce GC overhead of the C++ lexer buffer

[Richard Guenther]

On Mon, 19 Jun 2006, Mark Mitchell wrote:

> Richard Guenther wrote:
> 
> > CP_LEXER_BUFFER_SIZE is the number of elements in the cp_token GGC vector:
> > 
> >   /* Create the buffer.  */
> >   alloc = CP_LEXER_BUFFER_SIZE;
> >   buffer = GGC_NEWVEC (cp_token, alloc);
> > 
> > to reduce the GC overhead (the unused part at the end of a GC page), the
> > amount of memory allocated needs to be (close to) a power of two.  Thus
> > the division by sizeof(cp_token).  The number 262144 was chosen to be
> > a reasonable compromise between 32bits (20 bytes per cp_token) and 64bits
> > (larger), so that the number of initial tokens is around the original
> > value 10000.  But I can easily halve this number, if requested.
> 
> I think the value (8K) is OK, but I still don't understand the division.
>  Why not say 8K?  You're taking a power of two and dividing it by
> something; that's only going to end up being a power of two if the think
> you're dividing by is also a power of two.  In this case, it is (on my
> machine cp_token has size 32), but that won't necessarily be true in future?

CP_LEXER_BUFFER_SIZE does not need to be power-of-two, but sizeof (struct 
cp_token) * CP_LEXER_BUFFER_SIZE should be close to (slightly below or 
equal) power-of-two, as this is the amount of memory GGC_NEWVEC will
allocate.  So, ((256 * 1024) / sizeof (struct cp_token)) * sizeof (struct 
cp_token) will be at most sizeof (struct cp_token) - 1 less than 256 * 
1024 - and sizeof (struct cp_token) - 1 will be the new GC overhead here.

Richard.

--
Richard Guenther <rguenther@suse.de>
Novell / SUSE Labs