This is the mail archive of the
mailing list for the libstdc++ project.
Re: Rewriting bitmap_allocator
- From: Dhruv Matani <dhruvbird at gmail dot com>
- To: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- Cc: Benjamin Kosnik <bkoz at redhat dot com>, "libstdc++" <libstdc++ at gcc dot gnu dot org>
- Date: Sun, 28 Apr 2013 17:36:55 -0700
- Subject: Re: Rewriting bitmap_allocator
- References: <CAOG+gn2uvg-tfhj8rbo9dP1TY_iOTKXN7fyYdLj_YiR=2HWzDg at mail dot gmail dot com> <20120625154511 dot 2da206f7 at adair> <CAOG+gn1JJD7N3WssVeuQ2vavwB1P6UOmRop6TB3BuYebjbgU-A at mail dot gmail dot com> <20120626132507 dot 23889470 at adair> <CAH6eHdSL7WpRsQme0qEOZ3V64DU4Fbcgrr743O2MN4FrQkTfKA at mail dot gmail dot com> <CAOG+gn26EUbgrXdHkuGPBRF=nUtQ3_4WiXFK7SYGfPj2ofVoKw at mail dot gmail dot com> <CAH6eHdS1wSU=S1M8TYHwrj_YL9OV8dqd-dAxX=jHWOXTpmE2iw at mail dot gmail dot com> <CAOG+gn2+KAv7MFxYbDAhsEwMsqrFx_doPsQTUEB6mKNEKv3EFQ at mail dot gmail dot com>
So I've been able to get bitmap_allocator to compile with the build
process on the latest (on svn: rev 198365) gcc.
However, I have some test failures in "make check-target-libstdc++-v3".
Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
as tool-and-target-specific interface file.
FAIL: 17_intro/headers/c++200x/all_pedantic_errors.cc (test for excess errors)
^Cgot a INT signal, interrupted by user
=== libstdc++ Summary ===
# of expected passes 2234
# of unexpected failures 2
# of expected failures 6
# of unsupported tests 285
Any idea what I'm missing here, and how to fix it. I can send a diff
if that helps.
On Thu, Jul 26, 2012 at 8:33 PM, Dhruv Matani <email@example.com> wrote:
> Hello Jonathan,
> On Thu, Jul 26, 2012 at 2:10 AM, Jonathan Wakely <firstname.lastname@example.org> wrote:
>> There's no need to check anything else. If bitmap_allocator is
>> supposed to be a drop-in replacement for std::allocator then it needs
>> to be stateless, and the default behaviour provided by
>> allocator_traits is correct for that case, except that it should
>> define propagate_on_container_move_assignment to true, see
> I've added this - std::true_type from the link mentioned above.
>>> (which happens to be
>>> available only post 4.6.2) right?
>> 4.7.0 onwards, but I would expect any changes to bitmap_allocator to
>> only be done on trunk (4.8) anyway.
> Makes sense.
> I've tested this with valgrind, and it seems to be working okay. Made
> some more changes to make the cost of allocation/deallocation O(1) on
> the average - the trick is somewhat similar to the one used in the
> argument used to show that traversing a std::map<> is O(n).
> I'm happier with this implementation even though it is a tad slower
> than the older one (see the link below) simply because it's much
> smaller in size and is easier to explain.
> Here are some numbers for the tests included in test.cpp:
> The only thing that I am not able to figure out is why new_allocator
> is causing dramatically fewer minor page faults compared to the older
> bitmap_allocator in the test that uses std::list<> even though their
> RSS is comparable. Any idea on that? I don't have VSZ numbers - that
> may explain it.
> Current list of todos:
> * Add mutexes
> * Handle the case when deallocate(NULL, 1) is passed in
> * Some fixes that involve using size_type instead of size_t - is this required?
> Do let me know if there's any other corner case that you are aware of.
> -Dhruv Matani.
> "What's the simplest thing that could possibly work?"
> -- Ward Cunningham
"What's the simplest thing that could possibly work?"
-- Ward Cunningham