I think it's more likely this is scavenger related. Specifically, I think it's going to be related to #49411.

I'm somewhat worried about this. If debug.FreeOSMemory isn't working as expected, that can be a significant regression.

OK, I think I know the problem. It's fairly benign. Previously debug.FreeOSMemory would block the whole runtime from doing anything with allocation, but now it doesn't. So, the background scavenger is just getting to the memory before debug.FreeOSMemory is, because a GC is forced and it gets woken up. I think the fix here might be to just set GOMAXPROCS=1, so it doesn't really get a chance.

This test is more of a problem on mips64 and ppc64 because the page sizes are much bigger, so the scavenger can do a whole lot more bytes of work before going to sleep. Not really any issue on usually small page size architectures like amd64 and arm64.

As for a fix... I'm not sure. The goal here is to test debug.FreeOSMemory. Ideally, we could just turn off the background scavenger for this, but that's difficult to do from the runtime/debug tests. GOMAXPROCS=1 might be good enough? debug.FreeOSMemory is not preemptible. Raising the amount that's available to be scavenged would also help, because the test just checks if it gets something, not necessarily everything. It probably should check that, but I don't think it'll be able to do that from the runtime/debug package.

Unfortunately GOMAXPROCS=1 didn't work. Moving the test into runtime isn't great, though, and I'd rather not add hooks to disable the background scavenger. Though, maybe a GODEBUG mode that disables the background scavenger would be reasonable?

I got inspiration from my fix to #49411: we can make a test that's robust to the background scavenger if we recognize that we don't care if the test occasionally passes because the background scavenger stepped up. Currently this test is fragile because it can be perturbed by the background scavenger -- it does work the test expects that debug.FreeOSMemory does. We just care that we have a test that mostly fails if the tested mechanism isn't there.

So, my fix is to read HeapReleased before the allocation is freed. Then, check to make sure at least that much has been returned to the OS. Nothing else is going on in the test, so all the background mechanisms should only ever make HeapReleased go up. If it goes up more, who cares! It just needs to go up at least by that much.

CL incoming.

Change https://golang.org/cl/363414 mentions this issue: runtime/debug: make TestFreeOSMemory more robust