Re: Make GC tuning parameters adjustable at runtime

[Zack Weinberg <zack at codesourcery dot com>]

On Sun, Nov 10, 2002 at 06:33:41PM -0800, Mark Mitchell wrote:
> >Both GC implementations have a couple of tuning parameters which are
> >currently only adjustable at compile time.  This patch makes them both
> >accessible through the --param mechanism.
>
> Have you measure the effect, if any, on compile-time performance merely
> by making these things dynamic?
>
> I fully agree with your desire to make them dynamic, but if it slows down
> GC a lot, that would make me think twice.

I haven't measured it, but I doubt there is a measurable difference.
The change affects primarily the if statement at the beginning of
ggc_collect() that decides whether or not to do anything this time.

Formerly:

#ifndef GGC_ALWAYS_COLLECT
  if (G.allocated < GGC_MIN_EXPAND_FOR_GC * G.allocated_last_gc)
    return;
#endif

where GGC_MIN_EXPAND_FOR_GC is a #define for the floating point
constant 1.3.

After:

  size_t allocated_last_gc =
    MAX (G.allocated_last_gc, (size_t)PARAM_VALUE (GGC_MIN_HEAPSIZE) * 1024);

  size_t min_expand = allocated_last_gc * PARAM_VALUE (GGC_MIN_EXPAND) / 100;

  if (G.allocated < allocated_last_gc + min_expand)
    return;

The variables are just notational convenience.  This computes the
exact same function that the older logic did, except that (a)
multiplication by a floating-point constant has been replaced by a
memory fetch followed by an integer multiply, then an integer divide
by a constant; (b) the MAX() calculation has been moved from the end
of the function to the beginning.

Looking at assembly dumps suggests that the difference should be in
the tens of cycles per call, if that.

(old)
           push   %ebp
<+1>       xor    %edx,%edx
<+3>       mov    %esp,%ebp
<+5>       sub    $0x18,%esp
<+8>       mov    0x84725c8,%eax
<+13>      push   %edx
<+14>      xor    %edx,%edx
<+16>      push   %eax
<+17>      mov    0x84725cc,%eax
<+22>      fildll (%esp,1)
<+25>      add    $0x8,%esp
<+28>      push   %edx
<+29>      push   %eax
<+30>      fildll (%esp,1)
<+33>      add    $0x8,%esp
<+36>      fmull  0x83aa0e0
<+42>      fucompp
<+44>      fnstsw %ax
<+46>      sahf
<+47>      jbe    0x82acb25 <+53>
<+49>      mov    %ebp,%esp
<+51>      pop    %ebp
<+52>      ret

(new)
           push   %ebp
<+1>       mov    %esp,%ebp
<+3>       sub    $0x18,%esp
<+6>       mov    0x83b7de8,%edx
<+12>      mov    0x844604c,%eax
<+17>      mov    0xe8(%edx),%ecx
<+23>      shl    $0xa,%ecx
<+26>      cmp    %eax,%ecx
<+28>      jae    0x828d960 <+32>
<+30>      mov    %eax,%ecx
<+32>      mov    %ecx,%eax
<+34>      imul   0xdc(%edx),%eax
<+41>      mov    %eax,%edx
<+43>      mov    $0x51eb851f,%eax
<+48>      mul    %edx
<+50>      shr    $0x5,%edx
<+53>      lea    (%edx,%ecx,1),%edx
<+56>      cmp    %edx,0x8446048
<+62>      jae    0x828d984 <+68>
<+64>      mov    %ebp,%esp
<+66>      pop    %ebp
<+67>      ret

It's longer, but that's because the MAX() calculation has been moved.
(I would have liked not to move it, but that ran me into a order-of-
operations problem: I wasn't sure it was safe to move init_ggc after
parse_options_and_default_flags.

zw