[Gc] RE: A few higher level collector questions.

[Boehm, Hans]

> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com 
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Talbot, George
> Sent: Tuesday, May 12, 2009 7:14 AM
> To: gc at linux.hpl.hp.com
> Subject: [Gc] A few higher level collector questions.
> 
> Hey folks,
> 
> I have a few "higher level" questions about the collector.
> 
> * How does this collector figure into the eventual addition 
> of GC to a future C++ language standard?  Is anyone working 
> on that right now?
The C++0x draft goes out of its way to allow, but not require, a garbage collected implementation, at least for objects allocated with ::new.  The discussion about doing more than that was essentially tabled until the committee is done with C++0x.

The C++0x draft requires some library functionality that's a bit different from what's currently in the collector.  I have initial implementations that I would like to check in, but I would really like to get a stable 7.2 out before that.  Checking these in is not likely to improve stability, since the changes touch some existing data structures.

> 
> * Does anyone have any interest or experience in using what 
> will be the eventual GCC plugin architecture to emit the 
> necessary type information for the collector to use the type 
> interface automatically for C++ programs?
That would be interesting.  It would probably require language extensions to C++0x (possibly similar to what the committee considered before the current compromise solution), since C++0x still allows undisguised pointers to be stored in things like char arrays.  You probably want a static annotation to tell the compiler you're not doing that.  (C++0x provides a dynamic declare_no_pointers call, which constitutes most of the implementation challenge.  Mike Spertus and I have an upcomming ISMM 09 paper on this.)

Also not that gcj basically already does this, so gcc already has much of the required code.

> 
> * I like the GC_generate_random_backtrace() a lot.  One of 
> the things I thought might be interesting would be a version 
> that generates a large amount of backtraces and can output 
> perhaps a histogram of memory usage based on call site in the 
> calling program and possibly some sort of aggregate 
> dependency graphs of how particular call sites' memory are 
> referenced.  Has anyone already done something like this, 
> before I go and try to do it?
There is a fairly substantial research literature inthis area.  You might look at the Cork paper by Jump and McKinley in POPL 07 and start looking at references from there.  Manuel Serrano and I had a closely related paper in ICFP 2000.

Hans
> 
> --
> George T. Talbot
> <gtalbot at locuspharma.com>
> 
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> https://www.hpl.hp.com/hosted/linux/mail-archives/gc/
>