[Gc] Why do replacement operator new/new[] use GC_MALLOC_UNCOLLECTABLE() instead of GC_MALLOC()?

Talbot, George Gtalbot at locuspharma.com
Fri Jun 5 09:36:38 PDT 2009


Hi Hans,

I can understand why you guys originally chose that model.

In general, one should use the gc_allocator<> everywhere one can in C++ code, as it selects between allocating pointer-free or not depending on the type.  The problem I end up having is that there are so many places in the Standard C++ Library that use the standard allocator that I can't reach.  Also, anywhere that's using new that I can't reach is a possible source for a leak.

If I wrote a patch to be able switch the behavior between uncollectible and collectible memory via a function call or something like that, would you accept it?

--
George T. Talbot
gtalbot at locuspharma.com<mailto:gtalbot at locuspharma.com>




-----Original Message-----
From: Boehm, Hans [mailto:hans.boehm at hp.com]
Sent: Thursday, June 04, 2009 2:13 PM
To: Talbot, George; gc at linux.hpl.hp.com
Subject: RE: [Gc] Why do replacement operator new/new[] use GC_MALLOC_UNCOLLECTABLE() instead of GC_MALLOC()?

The general model for gc_cpp.h is that garbage collectable memory is used only when explicitly requested, e.g. by inheriting from gc.  Thus by default ::new allocates uncollectable memory as before.  It doesn't use the system-provided allocator, since we do want to scan such memory.

This is clearly not always the right model.

Hans

________________________________
From: gc-bounces at napali.hpl.hp.com [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Talbot, George
Sent: Thursday, June 04, 2009 7:47 AM
To: gc at linux.hpl.hp.com
Subject: [Gc] Why do replacement operator new/new[] use GC_MALLOC_UNCOLLECTABLE() instead of GC_MALLOC()?
Hi all,

C++ and the collector question:  Why do the replacements for operator new[] use GC_MALLOC_UNCOLLECTABLE instead of GC_MALLOC()?

--
George T. Talbot
gtalbot at locuspharma.com<mailto:gtalbot at locuspharma.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://napali.hpl.hp.com/pipermail/gc/attachments/20090605/868bb1dc/attachment.htm


More information about the Gc mailing list