Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #1767

Re: reference count size

Show all headers | View raw

On 6/8/2012 10:52 AM, BartC wrote:
> "BGB" <cr88192@hotmail.com> wrote in message
> news:jqs0nl$4fv$1@news.albasani.net...
>> On 6/7/2012 11:23 AM, BartC wrote:
>
>>> Reference counts are typically used with heap-allocated objects, which
>>> may already have overheads beyond the size of the object, might have a
>>> minimum size anyway, and are generally used for objects bigger then
>>> 32-bits. So the few extra bytes is usually not significant.
>
>> but, doing stuff this way results in considerable memory savings for
>> objects < 100 bytes or so (albeit costs are still a bit steep for
>> objects <=16 bytes).
>>
>> efficiently allocating lots of 4-16 byte objects would likely require
>> some sort of slab allocator though.
>
> For years, I've used 16 bytes as the minimum block size for heap
> allocations.
>

in my case, for normal objects, likewise.
or at least they are allocated in terms of 16-byte "cells".
there are also cons cells, which may be 8 or 16 bytes depending on target.


> But, I don't use any header (the actual size of the memory requested is
> not recorded, and I don't use a GC, nor reference counting).
>

in my case, I use a GC which records both the size and type of the 
memory object. currently the size is 32 bits, but theoretically a modulo 
size could also be used, or the size could be made smaller (say, 
16-bits) with an alternate means of storing the size used for large objects.


> Also, I tend not to use the heap for allocating individual integer or
> float values; small requests are typically associated with short strings.
>

this is presently a downside for how my VM manages value-types:
a lot of integers and floats still end up on the heap.

as-is, the int/long/float/double types would end up taking up a single 
cell (so, 16 bytes to store an integer or a double).

16-byte vectors, int128, ..., would end up needing 32-bytes.

some sort of generalized slab optimization could make sense (allocating 
these objects as a larger lump internally, but giving the appearance of 
individual objects), but I have yet to decide on an exact mechanism.

what happens in this case, at present, is that some special case logic 
outside of the GC implements slab allocation for particular types 
(int/long/float/double), and dedicated free-lists for others (int128, 
float128, vector types, boxed pointer-objects 1, ...).

1: the "pointers" available within the VM are actually boxed objects, 
which besides giving the pointer itself, give information about the 
type, step-size, and (optionally) the valid range of the pointed-to memory.


> And how many allocations would there be altogether? If there are
> millions of int values to store, usually they are grouped into arrays or
> blocks. Setting up a 32-bit pointer to point to a 32-bit value seems
> silly anyway...
>

partly in my case, some of this is due to the VM implementation.
the "static types" optimization ended up representing all of these types 
as heap-allocated boxed objects (although, this is also how early 
versions of the VM/language had worked), mostly so that they could still 
be type-checked if needed (not all of the VM operations support static 
types as of yet, and it seemed preferable to fall back to a less 
efficient case than to an entirely incompatible case).

as-is, statically-typed logic using boxed integers is slightly faster 
than dynamically-typed logic using fixnums (fixnums remain the default 
for variant types), but not by a large amount (note that 
dynamically-typed logic with boxed values is considerably slower).


> (This scheme is within the context of a language that uses 16-byte
> variant values anyway; other memory usage patterns might be different.)
>

in my case, I use raw pointers.

the reason was mostly that the system largely developed in use with a 
lot of C code as well, and anything not a "raw untagged pointer" is 
considerably more of a pain to work with in C.

FWIW, reference-counting actually ended up as a rarely used feature 
anyways (it is optional), mostly because it is a pain to keep things 
sufficiently controlled to where the reference counts are always updated 
correctly, which is mandatory for correct operation of ref-counting 
schemes (also, the operation is kind-of expensive).

instead, the current VM tries to figure out where it can explicitly free 
things (and "value types" have explicit life-span rules to help out here).

Back to comp.programming | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

reference count size bob <bob@coolfone.comze.com> - 2012-06-07 08:42 -0700
  Re: reference count size "BartC" <bc@freeuk.com> - 2012-06-07 17:23 +0100
    Re: reference count size BGB <cr88192@hotmail.com> - 2012-06-07 23:55 -0500
      Re: reference count size "BartC" <bc@freeuk.com> - 2012-06-08 16:52 +0100
        Re: reference count size BGB <cr88192@hotmail.com> - 2012-06-09 09:11 -0500
  Re: reference count size Robert Wessel <robertwessel2@yahoo.com> - 2012-06-07 11:32 -0500
    Re: reference count size "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-06-09 10:29 +0100
      Re: reference count size Ian Collins <ian-news@hotmail.com> - 2012-06-09 21:43 +1200
  Re: reference count size JJ <jaejunks@googlemail.com> - 2012-06-08 01:46 +0700
    Re: reference count size Willem <willem@toad.stack.nl> - 2012-06-07 18:52 +0000

csiph-web