How much can stl_alloc.h be changed?

[Phil Edwards <pedwards at disaster dot jaj dot com>]

I've been tracking down the various carnal minglings of __USE_MALLOC,
__STL_THREADS, _NOTHREADS, etc, mainly with regards to the "default node
allocator," which is the name SGI gave to the high-speed memory pool.
There are some more SGI-isms which can be removed, and I've factored out
_NOTHREADS so that the macro chain is more easily readable, all in one
location, etc.

Since we've already changed the ABI for 3.1+, there are some things I'd
like permission to do:

1)  Increase _MAX_BYTES to 256 for now.

1a) This should be made more user-configurable eventually.  (Perhaps nothing
more than "if not defined, define it, end if" and open this up to the user.)
To make this work, the initialization of the free lists array can no longer
be hardcoded ('prox line 617) to a bunch of zeros.

2)  Add an unconditional typedef for malloc_alloc.  Existing code refers
to "malloc_alloc" as the name for the allocator which just wraps malloc.
Many comments do also.  Our own web documentation and recommended
examples for "alternatives to defining __USE_MALLOC" told users to write
"std::malloc_alloc" up until ten days ago!  This is one place where
IMHO we should be more lenient and allow a non-standard name to remain
for backwards-compat reasons (like bit_vector).

3)  At the top of stl_alloc.h, we conditionally define a macro which does

        if (param) { create a mutex lock }

The macro is then used later in the node allocator.  The param referred
to is a template bool parameter, i.e., unchanging.  We presently rely on
constant propogation and dead code elimination to remove the 'if' (and the
body as well if param is false), but only when optimizations are turned on
(and working correctly).

We can use a tiny type-traits-ish wrapper to make this decision once, at
compile time, instead of repeatedly testing it at runtime.  Then we don't
have to depend on optimizations.  We can also make use of the _STL_auto_lock
like the comment around line 395 says, since that comment is no longer fully
true, and the need to test for threads would be [re]moved to compile time.


I've already done (1) and (2) locally as part of the remaining uglification;
they've been surviving several testsuite runs for a while now.

When did (1a), the runtime loader correctly initializes them all to zeros
automatically (they were done that way explicitly to pander to some ancient
Sun compiler that didn't perform zero-initialization correctly, but I've
already removed that comment).  However, this means that _S_free_list
changes from a weak symbol to an uninitialized symbol.

Looking for feedback on (3) before I go any further.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams