Should we always inline newByteArray#?

[Simon Marlow]

On 13/03/14 20:39, Johan Tibell wrote:
> Hi all,
>
> After some refactoring of the StgCmmPrim, it's now possible to have both
> an inline and an out-of-line (in PrimOps.cmm) version of the same
> primop. Very soon (#8876) we'll have both an inline and an out-of-line
> version of newByteArray#. The inline version is used when the array size
> is statically known and commons up the allocation with the normal heap
> check.
>
> The reason to have both versions is that we don't want to increase code
> size to much (by inlining a primop which implementation is large) unless
> we know that there's a benefit in doing so. However, the newByteArray#
> implementation is one function call (to allocate) followed by three
> stores (to the closure header). Perhaps, that's small enough to always
> inline? It would save one function call for each call to newByteArray#.
>
> Anyone have any thoughts on whether always inlining would be a good idea?

It's a bad idea for large arrays (>= 3k), because when allocated via 
allocate() these arrays get a blocked marked with BF_LARGE that doesn't 
get copied during GC.

It might be a good idea for arrays less than this size (including the 
header).  It's a bad idea if the size isn't statically known, though.

Cheers,
Simon