[Gc] Patches for C++ to support throw() declarations, and that throw std::bad_alloc on OOM.

Talbot, George Gtalbot at ansarisbio.com
Tue Nov 10 12:10:50 PST 2009


I agree with you in both cases.  I'm not sure that I understand the build system for libgccpp well enough to generate the two different versions, though I could take a look tomorrow.

For the STL, I'm running on x86_64 Linux, which also appears to not do chunk allocation, so it's not biting me right now.  If it were doing chunk allocation, I'm not sure that I'd know precisely what to do about that.

Does it make sense to split this into two patches?  One that cleans up the throw() declarations and adds GC_CPP_INIT() for standards-compliant OOM behavior, and a second patch that supports some mechanism for defaulting operator new to GC_MALLOC()?  I could do that tomorrow also.

For things that do malloc() and friends, does the automatic redirection work at this point, or is that still problematic?

Thanks for looking at this.

--
George T. Talbot
<gtalbot at ansarisbio.com>

________________________________________
From: gc-bounces at napali.hpl.hp.com [gc-bounces at napali.hpl.hp.com] On Behalf Of Boehm, Hans [hans.boehm at hp.com]
Sent: Tuesday, November 10, 2009 2:34 PM
To: Talbot, George; gc at linux.hpl.hp.com
Subject: RE: [Gc]  Patches for C++ to support throw() declarations, and that    throw std::bad_alloc on OOM.

Unfortunately, I don't believe this portably solves the allocator problem in either case.  The default allocator may allocate memory in chunks using operator new.  The original HP STL did this, and I think a number of implementations still do.  The one on my Itanium Linux box does not, but that decision seems to depend on platform-specific files in gcc.  Implementations that do chunk allocations may sort of appear to work with the collector, but not very well, in that they will retain a lot of garbage.  Thus you also need a non-portable mechanism for turning off chunk allocation in the STL.

It probably still makes sense to have this configurable.  I'm torn between making this
a dynamic switch and an alternate version of libgccpp, which contains gc_cpp.cc.  Since it has to be an app-wide decision either way, and the dynamic test would probably end up on a hot path, Ithink the alternate library is marginally better.  It could be generated from the same source code.

Hans

> -----Original Message-----
> From: Talbot, George [mailto:Gtalbot at ansarisbio.com]
> Sent: Tuesday, November 10, 2009 4:19 AM
> To: Boehm, Hans; gc at linux.hpl.hp.com
> Subject: RE: [Gc] Patches for C++ to support throw()
> declarations, and that throw std::bad_alloc on OOM.
>
> Correct...OOM handling doesn't change unless you call
> gc_cpp_init().  I'll change that to a macro as suggested by
> Ivan when I have the chance on Wednesday.
>
> As far as the GC_MALLOC() vs. GC_MALLOC_UNCOLLECTABLE(), I
> can understand where you're coming from.  My problem is the
> STL...if I leave this as GC_MALLOC_UNCOLLECTABLE(), then I
> have to use a custom allocator for any STL code that I use in
> my program.  This is really painful; the data types change
> (i.e. std::vector<int> becomes std::vector<int,
> gc_stl_allocator>, etc.) making interfacing bits together
> somewhere between difficult to impossible.  I tried going
> this way in my relatively decent sized program that uses the
> GC, and it was way too invasive.
>
> I could add a function to the public interface to make this
> switchable through a function pointer called within operator
> new/new[].  Would that be better?
>
> --
> George T. Talbot
> <gtalbot at ansarisbio.com>
> ________________________________________
> From: gc-bounces at napali.hpl.hp.com
> [gc-bounces at napali.hpl.hp.com] On Behalf Of Boehm, Hans
> [hans.boehm at hp.com]
> Sent: Tuesday, November 10, 2009 1:28 AM
> To: Talbot, George; gc at linux.hpl.hp.com
> Subject: RE: [Gc]  Patches for C++ to support throw()
> declarations, and that    throw std::bad_alloc on OOM.
>
> > Slightly more controversially:
> >
> > *  The standard operator new that gc_cpp.h and gc_cpp.cc provides
> > allocates memory with GC_MALLOC() instead of
> > GC_MALLOC_UNCOLLECTABLE().
> >
> Thanks.
>
> Unfortunately, I'm still concerned about this.  The problem
> is that this significantly changes the behavior of an
> interface that's been around for a while.  The original idea
> behind this interface was to use garbage-colelcted allocation
> only where it was requested.  Right or wrong, this would
> change that design decision retroactively.
>
> I guess out-of-memory handling doesn't change visibly unless
> you call gc_cpp_init()?  Thus the behavior is backward compatible?
>
> Can this be solved by just providing an alternate gc_cpp.cc
> to get the alternate behavior?
>
> Hans
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
>
_______________________________________________
Gc mailing list
Gc at linux.hpl.hp.com
http://www.hpl.hp.com/hosted/linux/mail-archives/gc/



More information about the Gc mailing list