Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: conclude field tracking experiment #42712

Closed
nightlyone opened this issue Nov 19, 2020 · 5 comments
Closed

proposal: conclude field tracking experiment #42712

nightlyone opened this issue Nov 19, 2020 · 5 comments
Labels
Projects
Milestone

Comments

@nightlyone
Copy link
Contributor

@nightlyone nightlyone commented Nov 19, 2020

I propose to decide whether field tracking becomes an official feature and is available by default or can be removed.

Background

The field tracking experiment (activated via GOEXPERIMENT=fieldtrack runs since about 10 years now and leads to quite some special cases in the compilers (go and gccgo) as well as unique bugs like #42686. Usefulness and shape didn't change much. It looks more like an obscure feature to me at the moment than a real experiment where someone is active collecting data and analysing the impacts of it.

Maybe it is time to wrap it up, document the results and make a decision of whether Go should have this feature or not and act on that decision.

@gopherbot gopherbot added this to the Proposal milestone Nov 19, 2020
@gopherbot gopherbot added the Proposal label Nov 19, 2020
@beoran
Copy link

@beoran beoran commented Nov 19, 2020

This feature seems to be obscure and not well documented. What was it intended to do?

@ianlancetaylor ianlancetaylor changed the title Proposal: Conclude field tracking experiment proposal: conclude field tracking experiment Nov 19, 2020
@ianlancetaylor ianlancetaylor added this to Incoming in Proposals Nov 19, 2020
@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Nov 19, 2020

The best docs for GOEXPERIMENT=fieldtrack are probably still the CL that introduced it: https://codereview.appspot.com/6749064.

It's used within Google for large scale handling of protobufs, which is why people keep reporting bugs about it. Any other large scale user of protobufs could use it too if they wanted, and for all I know some do; there is some support for it in the google.golang.org/protobuf package. So I don't think it's going to go away.

But we could discuss ways of moving it out of GOEXPERIMENT. See also #42681.

@mdempsky
Copy link
Member

@mdempsky mdempsky commented Nov 20, 2020

I think the way forward is to simply have better regression tests for fieldtrack. We are interested in continuing to support its existing users, but I don't think we want to make it a more generally supported feature than that. E.g., I think we'd still like the flexibility to be able to change its semantics if necessary.

@rsc
Copy link
Contributor

@rsc rsc commented Dec 2, 2020

This mode is available for users who want it, much like dev.boringcrypto is.
Google uses both of them.
But neither is appropriate for Go proper, and neither is going to be enabled in the main Go distribution by default.

@rsc rsc closed this Dec 2, 2020
@mdempsky
Copy link
Member

@mdempsky mdempsky commented Dec 6, 2020

FWIW, a couple days I worked on https://go-review.googlesource.com/c/go/+/275034, and I would have accidentally broken fieldtracking again; except it was caught by the (super basic) test case I previously added in https://go-review.googlesource.com/c/go/+/271217.

So I already have a lot more confidence that field tracking should cause less maintenance pain going forward.

@rsc rsc moved this from Incoming to Declined in Proposals Dec 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Proposals
Declined
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants