Re[7]: [Gc] RE: Abuse of collector...

Ivan Maidanski ivmai at mail.ru
Mon May 18 09:14:05 PDT 2009


Hi!

"Talbot, George" <Gtalbot at locuspharma.com> wrote:
> > -----Original Message-----
> > From: gc-bounces at napali.hpl.hp.com [mailto:gc-bounces at napali.hpl.hp.com]
> > On Behalf Of Ivan Maidanski
> >
> > ...
> >
> > Hmm... I observe that GC_ENABLE_INCREMENTAL is not working on Linux amd64
> > (unlike linux32 or SunOS on amd64, or Win32 where the printed number of
> > collection is smaller by somewhat 1/4...1/2 in the inc mode).
> > Further investigation is needed for Linux64...
> 
> Anything that I could help with that would help an expert diagnose what's going on?

Suppose You are running gctest and/or your app with GC_ENABLE_INCREMENTAL=1, GC_MARKERS=1, GC_PRINT_STATS=1 (also I assume that you dont change default warn_proc in your app), GC_LOG_FILE=mygclog (for convenience).

Do You ever observe in the log file (first, check whether these msg are present in your libgc.so (this seems to be present only if REDIRECT_MALLOC is used)):
1. "Incremental GC incompatible with /proc roots"?
2. "Caught ACCESS_VIOLATION in marker."?

Q3. Check whether UNPROTECT() is ever called inside GC_write_fault_handler()?

Enough for this moment...
At present, I'm trying to track what's going on with it in Win32 (if the same strategy (mprotect and catch SIGSEGV) as in Unix is used).

> 
> > Also, You could try GCJ-style allocations for partially ptr-containing
> > objects (I think only length-based descriptors could be potentially
> > increase collection speed for 64-bit arch where the probability of false
> > marking of an unreachable object is very low), but it's typically not an
> > easy task as you should reorder structs fields and add vtable ptr.
> 
> Would you have any example code?  This is not totally impractical for my main data structures...

#include "gc_gcj.h"
#include "gc_mark.h" /* only to import GC_DS_LENGTH */

struct my_object1_s {
 struct object_vtable * /* const */ vtable; /* this is assigned by GC_GCJ_MALLOC() */
 void *ptr2;
 ... // non-pointer types (and structural ones) are, of course, allowed here (if impossible to reorder)
 void *ptrN; // N > 0 otherwise use GC_malloc_atomic()
 non_ptr_type1 val1;
 ...
 non_ptr_typeM valM; // M > 0 otherwise use GC_malloc()
};

struct object_vtable_s {
 void *my_custom_ptr; // not used by GCJ
 GC_word gcj_descr; /* accessed internally during collection */
 ... // other custom fields, e.g "virtual" functions pointers.
};

struct object_vtable_s my_object1_vtable = {
 my_custom_ptr, /* eg. NULL */
 (offsetof(struct my_object1_s, ptrN) + sizeof(void *)) | GC_DS_LENGTH,
 ...
};

int main(void)
{
 struct my_object1_s *obj1;
 GC_INIT();
 GC_init_gcj_malloc(5, 0); /* magical 5 for mp=0 (as used in other projects on the web) */
 obj1 = GC_GCJ_MALLOC(sizeof(struct my_object1_s), &my_object1_vtable);
 ...
}

To ignore GCJ-style info at runtime (i.e. GCJ-allocated objects are fully scanned by the collector), eg. for debugging, use env GC_IGNORE_GCJ_INFO=1

> 
> Thanks with all your help with this.
> 
> --
> George T. Talbot
> <gtalbot at locuspharma.com>
> 

Bye.


More information about the Gc mailing list