[PATCH] Slightly better way to __USE_MALLOC

[Loren James Rittle]

In article <20021017152730.M14862@infointeractive.com>,
Brad Spencer<spencer@infointeractive.com> writes:

> I think this is an excellent patch!  I've been testing a couple of
> slight variations and seeing how it performs against the gcc-3.2
> release.  I agree with your criticism of my previous patches.

OK, we will start with my patch as the baseline for improvements to
mainline (let's cross that bridge first).

Yes, please hack on it further if you have time.

> Not at all!  You and others have been encouraging and supportive.  I
> didn't expect to rewrite stl_alloc.h properly on my first try ;)

We have tried many times before.  This e-mail exchange was the first
time I saw clearly "one true way" to fix it. ;-)

>> [...] perhaps for small embedded targets we really do need to
>> merge in something like Brad's configuration-time style as well (but I
>> have the reservations listed above).

> Presumably this would require the symbol mismatching I included.
> Would these extra statics per object themselves be problematic for
> embedded targets?

That solution was innovative but when we don't violate the
one-definition-rule, we shant need symbol mismatching to catch
errors. ;-)  I was referring more to the need to be able to lockdown an
allocation style at gcc configuration time in very special cases;
i.e. no UNIX system should need it unless disabling the cache is a
clear win for every possible C++ applications--threaded or not (as it
appear to be on FreeBSD - but this is the only system I've found where
the system malloc beats libstdc++-v3's internal cache architecture).
I remember some recent reports that embedded system guys couldn't
easily use the caching allocator in libstdc++-v3 since the memory
space was so small.  I just removed their only way out (however, with
full intention to give back a better form when done). Which leads to
[...2]

> By checking the environment variable in both allocate() and
> deallocate() (for any given instance of the class template), are we
> setting up for someone to change it in between the first calls to
> those methods?  Now, granted, that would be evil, but perhaps making
> it a class static constant is better?  Given the hint that this is a
> performance boost, too, perhaps it's worthwhile.  I've attached a
> cumulative patch for stl_alloc.h that includes your changes but makes
> this change.  

Yup, something like this would be an improvement for the reason you
state.  We really don't want the failure mode ala __USE_MALLOC.
However, you may not move the init point from within ::allocate.  The
issue is initialization order.  If someone were to allocate memory for
an STL element in a global object, we can't predict/force that to come
after the init of your new static (we could if we used a certain g++
feature not available on all targets/lds).

> I don't understand why the class-static version so greatly affects the
> GLIBCPP_FORCE_NEW time.  Perhaps the test routine is simply too naive.

I wouldn't worry about that unless you have a way to study it.  People
will not use GLIBCPP_FORCE_NEW unless they are debugging, etc.  I will
add a version of your update to the patch in my tree. (I will try to
figure out how to move the init point back into ::allocate yet share
the result with ::deallocate, but again this is tricky due to race
conditions related to thread cases.)

> For the application to select the allocation scheme explicitly at
> runtime, it would have to ensure it called putenv() before any use of
> std::allocator.  Is this possible?  I'm not certain it's a desirable
> feature, but perhaps someone would want to release a certain
> application that performs better one way or the other and they want to
> hardwire it that way.  This wouldn't be a property of the target as
> much as it is of the application itself?

I see what you want, I can't offer to do it, but FYI:

For the java FE, they actually take special command line arguments in
order to build some code (and data?) on the fly just before an
application link.  I wonder, if that technique wouldn't be a way to
enforce library properties without consulting environment variables
(of which global memory allocation policy for std::allocator is one
such), ala:

g++ --allocator=pool <args> <objects>
g++ --allocator=new <args> <objects>
g++ --allocator=malloc (if needed, however I think new yields the same
visibility into per-allocation/deallocation events as malloc allocator)

> Regardless, this is going to be a joy to use! :)

Well, give it some time.  Everything looks great until you beat on it.
I need another libstdc++-v3 maintainer to weight in on this before I
would consider committing it.

Regards,
Loren