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

Boehm, Hans hans.boehm at hp.com
Tue Nov 10 11:34:33 PST 2009

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.


> -----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.
> 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 
> >
> 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
> https://www.hpl.hp.com/hosted/linux/mail-archives/gc/

More information about the Gc mailing list