[Gc] My old suggested minor changes

Boehm, Hans hans.boehm at hp.com
Mon Nov 10 14:55:01 PST 2008


Thanks.

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.

Opinions?

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.

Hans

> -----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
>
> Hi!
>
> 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).
>
> Bye.
>



More information about the Gc mailing list