[Gc] RE: A few higher level collector questions.
Boehm, Hans
hans.boehm at hp.com
Fri May 15 13:52:43 PDT 2009
> -----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/
>
More information about the Gc
mailing list