# value bytes of error codes

Pavel Curtis (pavel@parc.xerox.com)
Fri, 29 Mar 1996 09:45:36 PST

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    slayer@kaiwan.com writes:
    > I was just wondering why something like value_bytes(E_PERM) returns 0. Do
    > error values take up any space in the database? If so, how much?

    The most reasonable way to measure memory on the MOO is in terms of the
    *excess* required over what's already allocated for the space holding the
    value.  For example, if you have an object with 3 properties, then it has to
    have space allocated for holding three MOO values, regardless of what those
    values are.  Thus, object_bytes() counts 3 * (space to hold one MOO value) plus
    (extra space needed to hold any of the specific values in the properties).

    As others have pointed out, all MOO values are held in the same kinds of
    `slots', each of which has room for a type code (4 bytes) and a reference to
    the value itself (also 4 bytes), for a total of 8 bytes.  For integers, errors,
    and object numbers, the `reference' is the value itself.  For lists, strings,
    and floating-point numbers, the `reference' is a pointer to some more memory
    where the actual value is stored.  This representation allows most of the
    server code to pass around these fixed-size MOO values freely without having to
    have different amounts of memory for holding different types.

    The value_bytes() function, then, is easy to understand: it's returning the
    number of *extra* bytes of memory used to represent the value, that is the
    number of bytes pointed to by the reference, if the reference is a pointer.

    Now, it's arguable that this approach is more confusing to users and not
    particularly strongly rooted in formal or technical considerations.  In fact,
    in the process of researching this answer, I found a bug in object_bytes()
    where it's slightly undercounting the space required to represent a given MOO
    verb program, and the undercount is arguably due to value_bytes() having this
    somewhat odd definition.

    Perhaps I will change the definition of value_bytes() to be more intuitive in
    1.8.0p3, by adding 8 to all values it returns.  Of course, I will also make the
    corresponding change in object_bytes() to make sure no byte of memory is
    double-charged.

    Would this cause compatibility problems for anyone?

    	Pavel