[gambit-list] Does "time" report an accurate count of the number of bytes allocated?

Marc Feeley feeley at iro.umontreal.ca
Fri Dec 21 09:20:06 EST 2012


The "space allocated" reported by "time" takes into account the total amount of address space that is consumed by an allocation.  What you see as a factor of 2 overestimation of the space allocated is simply due to the fact that the memory manager is based on a Cheney style collector which performs the copy phase using a fromspace and a tospace.  When X bytes are reserved for an object in the fromspace there is implicitly X bytes in the tospace that are reserved for copying the object to the tospace (in the eventuality that the object survives the next collection cycle).  It is debatable whether this is the "correct" way of reporting the amount of storage allocated.  I think it is correct because it takes into account the implementation of the memory manager (including unused space allocated for alignment reasons, size of the header, the fromspace/tospace strategy).  It is also possible to see when a object is allocated as a "still" object managed by the mark-sweep collector (this occurs for example for large objects) :

> (define dummy (time (make-u8vector 1000)))
(time (make-u8vector 1000))
    0 ms real time
    0 ms cpu time (0 user, 0 system)
    no collections
    2008 bytes allocated
    1 minor fault
    1 major fault
> (define dummy (time (make-u8vector 1000000)))
(time (make-u8vector 1000000))
    2 ms real time
    1 ms cpu time (1 user, 0 system)
    1 collection accounting for 0 ms real time (0 user, 0 system)
    1000024 bytes allocated
    248 minor faults
    no major faults

The first call to make-u8vector allocates in the fromspace of the copying collector a u8vector of length 1000 bytes.  It shows up as 2008 bytes allocated because there is a 4 byte header, and the same space is reserved in the tospace.

The second call to make-u8vector creates a large object.  It allocates a u8vector of length 1000000 as a "still" object in the heap managed by the mark-sweep collector.  In this case the u8vector has a 24 byte header (6 machine 32 bit words) followed by 1000000 bytes containing the elements of the u8vector.

Marc

On 2012-12-21, at 12:50 AM, Bradley Lucier <lucier at math.purdue.edu> wrote:

> On my 64-bit Mac, I get
> 
>> (time (##make-vector 8))
> (time (##make-vector 8))
>    0 ms real time
>    0 ms cpu time (0 user, 0 system)
>    no collections
>    144 bytes allocated
>    1 minor fault
>    no major faults
> #(0 0 0 0 0 0 0 0)
> 
> I'd figure this allocates only 8 (header) + 8 (words) * 8 (bytes/word) = 72 bytes, but time is reporting 144.
> 
> Similarly (and what led me to this),
> 
>> (time (##bignum.make 2 #f #f))
> (time (##bignum.make 2 #f #f))
>    0 ms real time
>    0 ms cpu time (0 user, 0 system)
>    no collections
>    48 bytes allocated
>    no minor faults
>    no major faults
> 
> (don't do this at home!), which I expect allocates 8 (header) + 2 (adigits) * 8 (bytes/adigit) = 24 bytes.
> 
> What am I not understanding?
> 
> More generally, can the number of bytes reported be confused by stack manipulation?  I.e., if things go on the stack, but then the stack is unwound, does "time" report any allocation?
> 
> Thanks.
> 
> Brad




More information about the Gambit-list mailing list