[Gc] providing memory information

Boehm, Hans hans.boehm at hp.com
Fri Apr 2 16:07:03 PST 2004

That's an interesting idea, but I think it's hard to do efficiently and
completely correctly.

GC_in_heap is easy, using GC_base() or GC_find_header().

GC_on_stack is problematic, because thread stacks can appear and disappear.
The collector keeps track of the stack bases, but not the current stack
pointers.  And it doesn't keep them in a data structure that would allow
quick lookup by address.

GC_is_static() has similar issues with dlopen().  GC_is_static_root() is
a good approximation, though it can miss recently added dynamic libraries.


> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com]On Behalf Of Sean Middleditch
> Sent: Friday, April 02, 2004 11:35 AM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] providing memory information
> One of the libraries I'm working on currently is an attempt to provide
> maximum efficiency for handling strings.  Namely, for 
> applications that
> just store/compare/display a lot of strings from a myriad of sources
> (string literals, GCd string memory, non-GCd string memory,
> stack-allocated buffers, etc) and want to avoid excessive unnecessary
> copying.
> I have said library working quite well, with the exception of some
> fragile platform-specific code.  Code which, I might note, is already
> used in the GC, of course.  I was hoping that perhaps some simple
> functions could be added to utilize this information for 
> libraries/apps
> like mine that try to be intelligent with different memory "sources."
> Namely, I'd like to see something like:
> GC_API int GC_on_stack GC_PROTO((GC_PTR));
> GC_API int GC_is_static GC_PROTO((GC_PTR));
> GC_API int GC_in_heap GC_PROTO((GC_PTR));
> Each of these would return 1 (true) if the pointer points to the
> specified memory location (stack, static segment(s), and GC managed
> heap, respectively), or 0 otherwise.
> The general idea is that some apps need to handle objects in each
> location slightly differently.  For example, objects on the 
> stack or in
> the non-collected (system malloc() allocated) heap have to be 
> copied vs
> just passing around a pointer since you can't control the lifetime. 
> (Especially important when the pointer comes from code you 
> can't modify
> to be more GC friendly.)  Or, put another way, you can simply know you
> never need to make a copy of data in the static segment or 
> the collected
> heap, since the information will never disappear under you.
> -- 
> Sean Middleditch <elanthis at awesomeplay.com>
> AwesomePlay Productions, Inc.
> _______________________________________________
> 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