[Gc] providing memory information
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
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
> 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
> 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
More information about the Gc