Re: [PATCH olang] arena: optimization: make arena 8 bits aligned

["Carlos Maniero" <carlos@maniero.me>]

There is a lot that I learned since I started this patch. First of all,
this patch has a bug.

> +    arena->offset += size + (size % 8);

Let's say the offset is zero and the size is one, we would expect the
new offset to be 8 after the *arena_alloc*, but this code was producing
1 as the new offset.

Furthermore, 8 is not the right memory alignment for x86_64
architectures according Intel's manual:

> 4.1.1 Alignment of Words, Doublewords, Quadwords, and Double Quadwords
> 
> Words, doublewords, and quadwords do not need to be aligned in memory on
> natural boundaries. The natural boundaries for words, doublewords, and
> quadwords are even-numbered addresses, addresses evenly divisible by
> four, and addresses evenly divisible by eight, respectively. However, to
> improve the performance of programs, data structures (especially stacks)
> should be aligned on natural boundaries whenever possible. The reason
> for this is that the processor requires two memory accesses to make an
> unaligned memory access; aligned accesses require only one memory
> access. A word or doubleword operand that crosses a 4-byte boundary or a
> quadword operand that crosses an 8-byte boundary is considered unaligned
> and requires two separate memory bus cycles for access.
> 
> Some instructions that operate on double quadwords require memory
> operands to be aligned on a natural boundary. These instructions
> generate a general-protection exception (#GP) if an unaligned operand is
> specified. A natural boundary for a double quadword is any address
> evenly divisible by 16. Other instructions that operate on double
> quadwords permit unaligned access (without generating a
> general-protection exception). However, additional memory bus cycles
> are required to access unaligned data from memory.

https://cdrdv2.intel.com/v1/dl/getContent/671200

So ideally we must align arena on 16 bits.

I'll send a v3 with theses two things fixed.