Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109131: Return more descriptive data from Fgarbage_collect.

[Dmitry Antipov]

So, IIUC, you would like to see it as:

((CONS INTERNAL-SIZE USED-CONSES FREE-CONSES)
  (SYMBOL INTERNAL-SIZE USED-SYMBOLS FREE-SYMBOLS)
  (MISC INTERNAL-SIZE USED-MISCS FREE-MISCS)
  (STRING INTERNAL-SIZE USED-STRINGS FREE-STRING)
  (STRING-BYTES 1 USED-STRING-BYTES)                     ;; Always 1 means 
sizeof (char), no 'free' value
  (VECTOR INTERNAL-SIZE USED-VECTORS)
  (VECTOR-SLOTS x USED-VECTOR-SLOTS FREE-VECTOR-SLOTS)   ;; 'x' is always equal 
to sizeof (Lisp_Object)
  (FLOAT INTERNAL-SIZE USED-FLOATS FREE-FLOATS)
  (INTERVAL INTERNAL-SIZE USED-INTERVALS FREE-INTERVALS)
  (BUFFER INTERNAL-SIZE USED-BUFFERS))

With this, we will have subtle issue with FREE-VECTOR-SLOTS. Since block
allocator coalesces the regions within blocks, sweep_vectors may create,
for example, 100 regions of 128 bytes each. On a 64-bit system with
sizeof (vectorlike_header) == 16, this space is enough to create 100
vectors of 14 slots each, which means 1400 free slots. But this doesn't
mean that this space is enough for 1400/6 = ~230 6-slot vectors: it's
enough only for 200 6-slot vectors. Thus, FREE-VECTOR-SLOTS is ambiguous
since it depends from future allocation requests - we can't predict
how much of the free space will be used for vectorlike_headers and
how much will be used to hold vector data.

Dmitry