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

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

[Stefan Monnier]

Thanks, it's getting there.

> + ((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 USED-STRING-BYTES FREE-STRING)
> +  (VECTOR INTERNAL-SIZE USED-VECTORS USED-VECTOR-BYTES FREE-VECTOR-BYTES)
> +  (FLOAT INTERNAL-SIZE USED-FLOATS FREE-FLOATS)
> +  (INTERVAL INTERNAL-SIZE USED-INTERVALS FREE-INTERVALS)
> +  (BUFFER INTERNAL-SIZE USED-BUFFERS))

That's not regular enough.  Every entry in the list should have the
same shape (NAME SIZE USED FREE).  For buffers, (buffers SIZE USED) is OK
because that's like having FREE set to nil, but for strings (STRING
INTERNAL-SIZE USED-STRINGS USED-STRING-BYTES FREE-STRING) is not good,
we want instead to have 2 entries:

  (strings SIZE USED FREE)
and
  (string-bytes 1 USED FREE)

same for vectors, where we need one entry for vectors and another for
vector slots (and BTW, please keep it vector slots rather than vector
bytes: the SIZE part is there specifically so that code that requires
byte counts can do the conversion later).

And please add one last entry for the malloc data.


        Stefan

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

[Dmitry Antipov]

On 07/18/2012 10:33 AM, Stefan Monnier wrote:

> That's not regular enough.  Every entry in the list should have the
> same shape (NAME SIZE USED FREE).  For buffers, (buffers SIZE USED) is OK
> because that's like having FREE set to nil, but for strings (STRING
> INTERNAL-SIZE USED-STRINGS USED-STRING-BYTES FREE-STRING) is not good,
> we want instead to have 2 entries:
>
>    (strings SIZE USED FREE)
> and
>    (string-bytes 1 USED FREE)

IIUC, FREE is always between 0 and SBLOCK_BYTES after compacting sblocks,
so I don't see too much sense here.

> same for vectors, where we need one entry for vectors and another for
> vector slots (and BTW, please keep it vector slots rather than vector
> bytes: the SIZE part is there specifically so that code that requires
> byte counts can do the conversion later).

IMHO counting vector slots is poor idea because:
  1) vectors are of different length, so, having just a number of vector
     slots, we don't know how much of struct vectorlike_header we have
     (and they eats memory too);
  2) this doesn't count extra space beyond Lisp_Objects in pseudovectors
     and doesn't count space used by bool vectors.

Dmitry

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

[Stefan Monnier]

>> (strings SIZE USED FREE)
>> and
>> (string-bytes 1 USED FREE)

> IIUC, FREE is always between 0 and SBLOCK_BYTES after compacting sblocks,
> so I don't see too much sense here.

That's fine: use (string-bytes 1 USED) then.  The important part is to
use the same form for all entries.

An alternative is to define the format of entries to be not
(NAME SIZE USED FREE) but
(NAME SIZE USED FREE SLOTS-SIZE SLOTS-USED SLOTS-FREE)

where all entries except for strings and vectors will have nil in the
last 3 positions (and (nil nil nil) can be represented more compactly by
just nil).

> IMHO counting vector slots is poor idea because:
>  1) vectors are of different length, so, having just a number of vector
>     slots, we don't know how much of struct vectorlike_header we have
>     (and they eats memory too);

Just like for strings (tho for slightly different reasons), we want to
have `vectors' and `vector-slots', yes.

>  2) this doesn't count extra space beyond Lisp_Objects in pseudovectors
>     and doesn't count space used by bool vectors.

AFAIK these pseudo-vectors have sizes which are (pretty much always)
a multiple of slots, so we can still count them as "slots" even if some
of those bytes aren't Lisp_Object fields.


        Stefan

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

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

[Stefan Monnier]

> So, IIUC, you would like to see it as:
[...]

That sounds OK, yes.

> With this, we will have subtle issue with FREE-VECTOR-SLOTS.

That's not a problem.  The only intention is to give an idea about where
the memory is.


        Stefan