Re: Faster compilation speed

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

In article <20020809.181251.63969530.davem@redhat.com> David S. Miller writes:

> For example, I'm convinced that teaching all the RTL code "how to
> count" and thus obviating garbage collection all together, would be
> the biggest win ever.  (I'm saying RTL should have reference counts,
> if someone didn't catch what I meant)

Hi David,

(This message is in the interest of brainstorming ways to improve
 compilation speed, even if we can't volunteer to implement, as Mike
 requested.)

In general, comparing RC-GC to scan-GC, I often thought along the
quoted lines as well.  However, I had no systematic data and my
opinion softened somewhat after reading Boehm's papers.  Then, for
non-modern hardware, I once did compare the performance of a
scan-GC-based system (using boehm-gc) verses that of an equivalent
explicit-free-based system (along with all the application-level RC
code).  I was truly surprised at how little overhead there was for
using the boehm-gc technique (off-hand, I think it was under 1% for my
system, but I do doubt this study applies to modern HW and/or gcc's
memory usage pattern) and, more importantly, how much code complexity
was reduced.  I believe that reduction in code complexity is what
drove gcc switching to scan-GC RTL.  If you hand-coded RC back in, how
is that different than the complexity that was once removed with the
introduction of scan-GC?  If I recall correctly, subtle object
lifetime bugs came and went with the pre-scan-GC code due to
complexity (perhaps it was never formally RC'd and if that is your
answer, I'd buy it ;-).

Now, if I understand it right, the scan-GC technique used in gcc is
not as elegant (some explicit marking is required) or high-performance
(gcc's implementation doesn't use hardware dirty bits, etc.) as that
used in boehm-gc.  Has anyone ever tested gcc with its own GC disabled
but boehm-gc enabled?  OK, this is a red herring question.  Even if
performance was greater, portability concerns are what caused the
decision to build a new custom scan-GC verses reusing boehm-gc...
Assuming your (application-level) RC-GC test pans out in terms of
speedup, perhaps adding explicit code to maintain counts is not the
best approach to keeping the reins on complexity.

This might be what you meant, but: Wouldn't it be neater if gcc itself
could generally reference count underlying memory which supports C
pointers (as a language extension)?  According to published papers,
the compiler for Inferno could do it (I read them years ago when
looking at the classic Java GC model verses other VM technology thus
no cite here; I think it is interesting that the latest Java JIT
compilers support RC-GC now).

Perhaps it is impossible to add generic RC support to C and expose it
to all users (for instance, there is the classic pointer escape/ABI
problem).  But it seems that we could mark structs whose pointers and
underlying memory representations are to be handled specially upon
pointer copy/invalidation (i.e. due to failing off the end of a scope)
and then rigorously check usage against whatever model we use to avoid
pointer escape.  GCC's use of pointers in this area is regular and I
see no reason the RC extension couldn't be modeled off the exact needs
of the RTL usage (just as scan-GC was not exposed to compiler users,
this RC-GC support could be tuned for compiler implementation).

How to handle bootstrap since we'd want to use the new technique to
replace gcc's current scan-GC?  The current GC is only slightly
intrusive and could be retained to build the stage1 compiler with
support for the new RC-pointer handler (and related support for struct
marking in source).  Current scan-GC would be disabled for stage2 and
3; the new RC-pointer handler would be enabled.

Regards,
Loren