fix excess array object padding

[JeffBezanson]

We seem to be wasting space currently by excessively padding Array objects. Even though array data is only aligned to 16 bytes, we for some reason align the object size to 64 bytes, then add more (un-aligned) space anyway. Hence the smallest array object is 80 bytes when it could be 48 (or 96 -> 64 when there are some elements). I can't think of a reason to do that, but maybe I'm missing something.

before:

julia> f() = for _ in 1:10^6; []; end

julia> @btime f()
  19.540 ms (1000000 allocations: 76.29 MiB)

after:

julia> @btime f()
  18.020 ms (1000000 allocations: 45.78 MiB)

[yuyichao]

There does seem to be some extra alignments (there should be only one alignment per branch) but it is added intentionally in #15139. The default allocated arrays are meant to actually have 64byte alignment.

[JeffBezanson]

I see. That PR mentions only doing it for large objects, but it actually aligns to 64 unconditionally. Is there a size cutoff we could use?

[JeffBezanson]

Ah, currently we only actually get 64 alignment if the object is not pool-allocated, or if the data is bigger than ARRAY_INLINE_NBYTES.

[JeffBezanson]

Ok I think this is right.

[KristofferC]

🎉

[oscardssmith]

Why is this backport elgible?

[JeffBezanson]

It just saves memory 🤷

[quinnj]

Yeah, I'd be pretty concerned if code was relying on the exact array object representation itself (i.e. jl_array_t) in memory. Though I won't deny having considered such code myself..... 😅

[JeffBezanson]

The plot thickens! This also reduces the size of the system image by a little over 3%, about 5Mb 🎉

[JeffBezanson]

Found a broken test as well. Storing to a Ptr{Union{Int8,UInt8}} actually writes a reference to a boxed object. We should perhaps change that to match unboxed union layouts.

[JeffBezanson]

Ok trying a simpler version where there is just a threshold for when to use larger alignment.