Apple silicon has 128 byte alignment so fix our defines to match

[gbaraldi]

julia/base/lock.jl

Lines 33 to 50 in 8a69745

	mutable struct ReentrantLock <: AbstractLock
	# offset = 16
	@atomic locked_by::Union{Task, Nothing}
	# offset32 = 20, offset64 = 24
	reentrancy_cnt::UInt32
	# offset32 = 24, offset64 = 28
	@atomic havelock::UInt8 # 0x0 = none, 0x1 = lock, 0x2 = conflict
	# offset32 = 28, offset64 = 32
	cond_wait::ThreadSynchronizer # 2 words
	# offset32 = 36, offset64 = 48
	# sizeof32 = 20, sizeof64 = 32
	# now add padding to make this a full cache line to minimize false sharing between objects
	_::NTuple{Int === Int32 ? 2 : 3, Int}
	# offset32 = 44, offset64 = 72 == sizeof+offset
	# sizeof32 = 28, sizeof64 = 56
	ReentrantLock() = new(nothing, 0x0000_0000, 0x00, ThreadSynchronizer())
	end

this probably also needs a fix, and maybe other places as well

[vtjnash]

Should we also review the uses of malloc_cache_align? This particular field seems to be intended to be the largest sized value that can be loaded in a single instruction, or at least whatever alignment is most optimal for that (in bytes)?

[gbaraldi]

I guess we should review these things overall. I'm not sure if it has anything to do with specific instructions because both 64 byte alignment and loads are way to large to matter to instructions and seem to do with caches.

[gbaraldi]

I think the goal with malloc_cache_align is to make sure that different mallocs don't end up in the same cache line, so the large alignment asked here makes some sense.

[d-netto]

Will probably be useful for #52994.

Can we prioritize merging it and backporting it to 1.10?

Thanks.

[d-netto]

Some versions of PPC apparently also have a cache line size of 128 bytes: https://reviews.llvm.org/D33656.

I don't know what's the status of supporting PPC, but it might be a good idea to adjust it as well.

[vchuravy]

We only support PPC8+ so yeah wes should adjust for that as well l.