runtime: mallocgc does not seem to need to call publicationBarrier when allocating noscan objects

[wbyao]

I'm doing some performance analysis of go1.20 on arm64 platform, and I found that the DMB instruction in mallocgc consumes a lot of time.

I found some CLs：

• CL11083: In go1.5, publicationBarrier was added when allocating scan objects.
• CL23043: In go1.7, publicationBarrier is was added when allocating noscan objects because of the heapBitsSetTypeNoScan.
• CL41253: However, publicationBarrier is still called when allocating noscan objects after heapBitsSetTypeNoScan is deleted.

I tried to find the reason why publicationBarrier was called when allocating noscan objects, but I couldn't find it.

Knowing from the comments of source code, publicationBarrier in mallocgc ensure that the stores above that initialize x to type-safe memory and set the heap bits occur before the caller can make x observable to the GC. publicationBarrier in allocSpan make sure the newly allocated span will be observed by the GC before pointers into the span are published.

My question is, GC don't scan noscan object, why is publicationBarrier required when allocating noscan objects in mallocgc?

Thank you in advance for your help.

[mauri870]

I think you might be right, given the comments and CL description the publication barrier for noscan was only there to protect the heap bitmap.

[ianlancetaylor]

CC @golang/runtime

[mknyszek]

I also think you might be right, but such changes are risky. We could try removing it for noscan objects early next development cycle and watch CI closely to see if anything breaks.

[RLH]

The memory model no longer allows out of thin air values, even in racy programs. This means there needs to be a publication barrier somewhere between when the object is initialized to 0 and when it is returned (published) by the GC. When the memory model was weaker we were not concerned with racy programs seeing out of thin air values except when it broke the GC. I suppose the zeroing and therefore the publication barrier could be done eagerly, at least for noscan. There are other reasons to do eager zeroing and any numbers showing that eager zeroing is a performance win would be interesting.

[mknyszek]

@RLH I think I follow but I'd like to confirm. Is this the kind of situation you're describing?

(1) Thread 1 on CPU 1 allocates an object at address X without a publication barrier.
(2) Thread 1 on CPU 1 places address X in a globally accessible location Y.
(3) Thread 2 on CPU 2 accesses Y using a load without a barrier. Y is not in the cache. It goes to LLC or main memory and it finds X there.
(4) Thread 2 on CPU 2 accesses X without synchronization.

In step (4) we expect thread 2 to see zeroed memory, but if CPU 2 happens to get a hit in the cache at that address then it might not appear to be zero.

There is a race in this scenario, but one could imagine a program that's OK with the race. And it would be surprising that one is able to observe the memory at X as not zeroed.

[RLH]

GoTheLanguage (GoLan) and GoTheImplementation (GoImp) shouldn't be conflated. But yes if Thread 1 (aka goroutine 1) is allowed to reorder the initialization stores of X and the store of the address of X then racy goroutines may (will) see out of thin air values from previous collected objects that were allocated at that address. The compiler, the runtime, and the HW must all conspire so that GoImp provides GoLan's memory model.

See 1 for more discussion.

[mknyszek]

GoTheLanguage (GoLan) and GoTheImplementation (GoImp) shouldn't be conflated.

Sure, just trying to wrap my head around a concrete example. Thanks for confirming! I agree that a simple change to remove the publication barrier for noscan objects would be violation of the memory model.

I reread https://go.dev/ref/mem and I believe it's clear that this sort of thing is explicitly disallowed by the following line that discusses rules around racy programs: "Additionally, observation of acausal and “out of thin air” writes is disallowed." Apologies for the too-quick conclusion. I had only considered non-racy programs earlier.

I suppose the zeroing and therefore the publication barrier could be done eagerly, at least for noscan. There are other reasons to do eager zeroing and any numbers showing that eager zeroing is a performance win would be interesting.

We generally haven't been thinking about eager zeroing lately, just because it's hard to decide when the right time to do it is.

We could theoretically drop the barrier in cases where the memory is already zeroed (for instance, by the page allocator, or by the OS) or when the caller explicitly asks for non-zeroed memory, but I wonder if those cases are popular enough to actually make a difference.

Also, special-casing the publication barrier at all is also going to introduce more fragility to the mallocgc path which I'm not a fan of. It's not inconceivable that it's even more load-bearing.

What do other allocators do on arm?

[mknyszek]

Oh, another question I have is whether atomics on @wbyao's arm platform are implemented in the kernel. That might slow things down a lot. Disclaimer: I haven't looked at the implementation of publicationBarrier on arm in a while.

[wbyao]

Oh, another question I have is whether atomics on @wbyao's arm platform are implemented in the kernel. That might slow things down a lot. Disclaimer: I haven't looked at the implementation of publicationBarrier on arm in a while.

Thanks for your reply, and there is some information I did not describe correctly, my environment is arm64 not arm.
I got that if the noscan objects is accessed by another thread before the memory is cleared, it may lead to unexpected results.
There's another question, the changes in CL270943 make noscan's large objects seems to violate the memory model as well, how noscan's large objects avoid out of thin air values?

[mknyszek]

Thanks for your reply, and there is some information I did not describe correctly, my environment is arm64 not arm.

Thanks for the clarification! My point about kernel-implemented atomics is moot then.

There's another question, the changes in CL270943 make noscan's large objects seems to violate the memory model as well, how noscan's large objects avoid out of thin air values?

That's a good point, I think you're right. There's no barrier in memclrNoHeapPointersChunked either.

I believe the right thing to do here is to add a second publication barrier. (I'm trying to convince myself that we can just move it, but I keep going back and forth. This case is kind of special because the GC will observe that the span for this large object is noscan, and the allocation of that span has its own publication barrier for the GC.) It should probably be OK performance-wise because the cost of zeroing here should make the second barrier rare enough that it doesn't impact performance too much.

[wbyao]

I believe the right thing to do here is to add a second publication barrier.

I think it's a nice fix.
In addition to memclrNoHeapPointersChunked, is it correct to protect the bitmap using publication barrier only when gcphase!=off, just like this (This will add more branches, but there may be better implementations.)

	if (needzero && span.needzero != 0 && !delayedZeroing) || (gcphase != _GCoff && !noscan) {
		publicationBarrier()
	}