From: D Yuniskis on
Hi,

When I write a memory manager, I typically refer to the
alignment requirements as the "width" of the heap. :<
This is obviously a misnomer. But, I've never been
able to come up with a nice, terse term to express this.
Since *I* know what I mean, I've been lazy and not
expended much effort trying to find a better term.

But, much of the work I am doing now will be released
as open source so I have to be a bit more considerate
of others "down the road" ;-)

Suggestions? "Alignment" seems almost as ambiguous as
"width" :-/

Thanks,
--don
From: Thad Smith on
D Yuniskis wrote:

> When I write a memory manager, I typically refer to the
> alignment requirements as the "width" of the heap. :<
> This is obviously a misnomer. But, I've never been
> able to come up with a nice, terse term to express this.
> Since *I* know what I mean, I've been lazy and not
> expended much effort trying to find a better term.
>
> But, much of the work I am doing now will be released
> as open source so I have to be a bit more considerate
> of others "down the road" ;-)
>
> Suggestions? "Alignment" seems almost as ambiguous as
> "width" :-/

Use a few more words: The allocated block is aligned on an 8-byte boundary, or
similar. If you want something short for a constant name, perhaps
BLOCK_ALIGNMENT, with a suitable comment.

--
Thad
From: D Yuniskis on
Hi Thad,

Thad Smith wrote:
> D Yuniskis wrote:
>
>> When I write a memory manager, I typically refer to the
>> alignment requirements as the "width" of the heap. :<
>> This is obviously a misnomer. But, I've never been
>> able to come up with a nice, terse term to express this.
>> Since *I* know what I mean, I've been lazy and not
>> expended much effort trying to find a better term.
>>
>> But, much of the work I am doing now will be released
>> as open source so I have to be a bit more considerate
>> of others "down the road" ;-)
>>
>> Suggestions? "Alignment" seems almost as ambiguous as
>> "width" :-/
>
> Use a few more words: The allocated block is aligned on an 8-byte

I was looking for a term that would be suitable for use in
the code (e.g., a variable's name) as well as the commentary
(short and sweet :> )

> boundary, or similar. If you want something short for a constant name,
> perhaps BLOCK_ALIGNMENT, with a suitable comment.

In another conversation (off list), the term "granularity" was
offered. In a sense, this actually defines how the quantity
is applied so I think I like it!

I.e., pools/partitions deal with fixed size buffers.
The heap differs in that it allows "fine grained" allocations.
However, alignment issues effectively limit the caller's
choices resulting in a certain "granularity" to the heap
itself.

Capisc?
From: Chris Burrows on
"D Yuniskis" <not.going.to.be(a)seen.com> wrote in message
news:hm9ulq$m3d$1(a)speranza.aioe.org...
>>
>> Use a few more words: The allocated block is aligned on an 8-byte
>
> I was looking for a term that would be suitable for use in
> the code (e.g., a variable's name) as well as the commentary
> (short and sweet :> )
>

The term actually has three components:

qualifier: e.g. smallest, minimum
noun: e.g. unit, chunk, block
attribute: e.g. size, length, width

That might result in variable names like 'minChunkSize' but 'minChunk' might
be sufficiently unambiguous depending on the context.

--
Chris Burrows
CFB Software
Armaide: ARM Oberon-07 Development System
http://www.armaide.com


From: D Yuniskis on
Hi Chris,

Chris Burrows wrote:
> "D Yuniskis" <not.going.to.be(a)seen.com> wrote in message
> news:hm9ulq$m3d$1(a)speranza.aioe.org...
>>> Use a few more words: The allocated block is aligned on an 8-byte
>> I was looking for a term that would be suitable for use in
>> the code (e.g., a variable's name) as well as the commentary
>> (short and sweet :> )
>
> The term actually has three components:
>
> qualifier: e.g. smallest, minimum
> noun: e.g. unit, chunk, block
> attribute: e.g. size, length, width
>
> That might result in variable names like 'minChunkSize' but 'minChunk' might
> be sufficiently unambiguous depending on the context.

But these are misleading. Note that you can (conceivably)
request less memory than this "granularity" (e.g., you
can request *one* byte even though the processor might
require 8 byte alignments).

And, the size of the chunk (fragment) that is allocated may
be quite different than the request *and* the "granularity".
E.g., if there are 8 bytes of (hidden) "overhead" tacked
onto each request, the user requests 2 bytes and the processor
imposes a 4-byte alignment (i.e., he ends up with a >= 10 byte
fragment). minChunk would suggest a minimum fragment size
dictated by the overhead (e.g., a request of 0 costs the heap
8 bytes = minChunk despite a "granularity" of 4).

I think granularity probably comes closest to the concept
at issue, here. It describes how finely you can "slice"
the heap without involving other issues (like overhead).