[Gc] My old suggested minor changes
hans.boehm at hp.com
Mon Nov 10 14:55:01 PST 2008
I was actually just looking at this last Friday. I'm not very happy with the way the "retrieve only" flag is currently being passed into the setter functions. Passing ~0 as an unsigned argument seems ugly. Passing (some_fn*)(-1) seems worse. And currently the function setters are not consistent, since GC_set_oom_fn recognizes a zero argument.
It would be marginally better to define macros for each of these special arguments. But I think that's ugly too, since there would be too many different ones. I don't know of a way to make this interface consistent and sufficiently memorable that it's not error-prone.
The more I think about this, the more I'd be inclined to just split the getter and setter functionality, with void returning setters. I think it's much cleaner. Currently none of these acquire a lock. Thus there is no real advantage to doing both in a single call. They at best provide a false illusion of atomicity.
I'll apply this patch for now, since it clearly gets us to a better state. But I think it's moving us away from the global optimum, and we really want to do something else. The second part seems fine. I'll add the necessary README.environment changes.
Fundamentally, I like the suggestion about moving auxiliary files to an "extra" subdirectory. However, getting it right seems a little tricky, since lots of odd Makefiles will need updating. I'd prefer a patch without the moved files themselves, plus directions as to what to move where.
> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Ivan Maidanski
> Sent: Sunday, November 09, 2008 5:24 AM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] My old suggested minor changes
> I've decided to re-send two my old (early Sept) minor
> suggested changes (they were originally sent to Boehm's mail,
> not this mailing list).
> First fix is for GC_set_free_space_divisor() comment ("gc.h" file):
> - passing -1 (or ~0, but not zero) to this func does not
> change old value (this is consistent with
> GC_set_java_finalization(), GC_set_dont_expand(),
> GC_set_no_dls(), GC_set_max_retries(), GC_set_dont_precollect()).
> The second thing is a suggestion of two env vas. To my
> opinion, the GC lacks two environment variables for better
> self tuning at run-time:
> - GC_FREE_SPACE_DIVISOR=<n>, where <n> is a positive value
> for GC_free_space_divisor to set at start-up;
> - GC_DISABLE_INCREMENTAL - to ignore explicit
> GC_enable_incremental() calls (useful when an application
> calls GC_enable_incremental() unconditionally (like test.c)).
> The attached patch is a diff against current CVS.
> Also another suggestion:
> there is a dozen of C files (add_gc_prefix.c, AmigaOS.c,
> gcname.c, if_mach.c, if_not_there.c, MacOS.c, msvc_dbg.c,
> setjmp_t.c, threadlibs.c) that are not a part of libgc.a (or
> gc.lib) - it would be convenient (eg, typing "*.c" for manual
> builds) to have these files moved to some other sub-folder
> (eg., "misc" or "extra"). In case of approval, I could make
> necessary patches for existing scripts (affected by such a movement).
More information about the Gc