Note that (from the spec)

deferred functions are invoked immediately before the surrounding function returns

so runtime.KeepAlive(o) is not called before the runtime.GC() call, but after when it's "too late".*

*edited

@ALTree Isn't that the idea? You want to call runtime.KeepAlive at the last point where you want the object to be live.

at the last point

@cespare I see your point. But I wonder if a defer argument qualifies as a "physical point" in the code or at that point it's already "too late". I don't know if this makes sense.

EDIT: nevermind, I just noticed it happens without defer too.

I think I see what is going on here. Replace defer runtime.KeepAlive(o) with defer f(o) with various fs.

func f1(x *Test) {}
func f2(x *Test) { _ = x }
func f3(x *Test) { _ = x.data }

The finalizer runs early with f1 and f2, but not f3.
It all comes down to how the garbage collector scans a defer. It basically uses the live map for the entry point for the deferred function. In f1 and f2 (and runtime.KeepAlive), the input argument is dead at entry, so the input argument is not live, so the input can get GCd early. In f3, we use x in a nil pointer check, so it is live at entry, so x gets retained.

This all looks correct for these fs. We just need to introduce enough use of its argument in runtime.KeepAlive to convince the compiler that its argument is live at entry.

Change https://golang.org/cl/55150 mentions this issue: runtime: add a use of runtime.KeepAlive's argument

I don't think this should be a release blocker.
The bug is also in 1.7 and 1.8, and there is an easy workaround.

I'm marking it a release-blocker for 1.10.