static vs. global in gc.c

[Stephen Weeks]

> You never answered my question about why so many functions in gc.c are extern
> (instead of static)?  What exactly is the outside interface to  gc.c? 

I've looked at all the nonstatic functions in gc.c.

Of them, the following two should be static.
	getFrameLayout
	stackNeedsReserved

The rest appear in gc.h.  Here's a chart to show where they are used.

X = appears in ccodegen.h
Y = appears in GC_size.c
Z = appears in GC_world.c

  Z	GC_computeHeapSize
X	GC_copyThread
X	GC_copyThreadShrink
X	GC_createStrings
  Z	GC_doGC
	GC_done			basis/MLton/exit.c
  Z	GC_enter
X	GC_finishHandler
  Z	GC_foreachGlobal
 Y	GC_foreachPointerInObject
  Z	GC_foreachPointerInRange
  Z	GC_fromSpace
X	GC_gc
	GC_handler		Posix/Signal/Signal.c
	GC_init			libmlton.c
  Z	GC_initCounters
  Z	GC_loadWorld		libmlton.c
  Z	GC_mutatorInvariant
 Y	GC_objectSize
X	GC_saveWorld
  Z	GC_setHeapParams
  Z	GC_setStack
	GC_size			basis/MLton/size.c
 YZ	GC_toSpace

A lot of the bloat is due to GC_size and GC_{load,save}World being split into
separate files.  So, if you move those back into gc.c (which I have nothing
against), I'd say that the absolutely essential interface consists of:

	GC_copyThread
	GC_copyThreadShrink
	GC_createStrings
	GC_done
	GC_finishHandler
	GC_handler
	GC_init
	GC_gc
	GC_loadWorld
	GC_saveWorld
	GC_size

> I  am
> thinking  of  re-writing  it,  but  perhaps  that should wait until after the
> release since I would be nervous of not having enough  time  really  test  it
> out.

Definitely after the release, although I am willing to see more hacks that speed
stuff up by 27%.  If you're gonna do a rewrite, maybe it would be best to go
ahead and do the generational gc.