OS_Heap changes to blocksizes

I noticed that recent changes to OS_Heap changed heap block allocation to
remove the limitation that all free and allocated blocks must be a multiple
of 8 bytes in length. Now the only requirements are that blocks must be
multiples of 4 bytes in length, at 4 byte alignment, with a minimum length of
8 bytes.

In my Reporter module v2.66 the *ReportHeap command displays information
about any heap, optionally listing all the blocks, and can even display some
or all of the data in each block. While it is doing this Reporter validates
the Heap as much as it can, including checking all lengths are a multiple of
8.

I have changed Reporter to check only for length multiples of 4, and a new
version will be generally available soon, or earlier by specific request to
me.

As part of the testing of this change, I wondered if the OS_Heap change had
made any difference to the space used by the RMA, which is probably the
largest Heap with nearly 2,000 blocks. Much to my suprise, on RO5.19 it made
no difference whatsoever! However, I found that although OS_Heap will now
allocate blocks in multiples of 4 bytes, OS_Module,6 rounds sizes in a more
aggressive (and undocumented) way than OS_Heap did, as it ‘forces size to
32*n-4 so heap manager always has 8-word aligned blocks’ (in Kernel.s.ModHand
@ RMAClaim_Chunk). This explains why about 55% of the RMA blocks are for 32,
64 or 96 bytes with no intervening sizes.

Is this rounding to 32 still required for the RMA?

If it could be removed, the space usage for the RMA may be reduced by a
useful amount.

But there is probably some good reason why it has to be there!?
If so, the rounding should be added to the documentation for OS_Module.

Is this rounding to 32 still required for the RMA?

I suspect this is a crude attempt to reduce fragmentation, by helping to ensure that any holes left by freed blocks are likely to be exactly the right size for some incoming claim, rather than a few bytes too big (fragmentation) or too small (slowing allocation down).

I suspect this is a crude attempt to reduce fragmentation

I have a feeling it could be that as well. Either that or someone got confused between bytes and words.

If (a) OS_Heap is a poor choice of heap manager for the RMA, and (b) it isn’t publicly documented that the RMA is just an ordinary OS_Heap, then we could easily change the RMA to be managed by a different, more appropriate heap manager. However we’d have to check that both (a) and (b) are true before making any changes.

If 55% of 2000 blocks are wasting (up to) 32 bytes then that would only be 32K of memory being wasted, which isn’t something to get too worried about. I’ll probably build a ROM or two with that rounding code disabled and see how much of a difference it really makes. It also wouldn’t surprise me if that rounding up is also hiding quite a few buffer overflow bugs.

I’ll probably build a ROM or two with that rounding code disabled and see how much of a difference it really makes.

Would certainly help to identify if there was any specific reason why it is rounded. Fragmentation is a possibility, but it would be good to know!

I have changed Reporter to check only for length multiples of 4, and a new
version will be generally available soon, or earlier by specific request to
me.

There is now a new version of Reporter, v2.66d, available on my website for anyone who uses *ReportHeap and wants to avoid heap validation errors when using RO5.18 or later.

In ye olde days of MEMC and RISC OS 2, RMA allocations were rounded such that they were guaranteed to start on a 16-byte boundary. There were slight timing differences in memory access on MEMC which could be exploited to fractionally speed up time-critical code (I think ADFS used this)

OK, a pedant writes – at a guaranteed offset (+4) from a 16-byte boundary…

8 byte alignment is required for ARM double word load and store instructions.