You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Provide an option (through GODEBUG or a linker flag?) to force exported method dead-code elimination despite presence of reflect Method or (non-constant) MethodByName in the code. When enabled, the resulting executable would have its reflection APIs return only methods that are otherwise referenced.
For edge cases, the user could force a reference e.g. by adding a dummy MethodByName
The user will trade a compatibility promise (could break packages in unpredictable ways) for faster build times and smaller binaries (can be dramatic when importing some excessively large packages).
It's not practical for a user to achieve this otherwise, e.g. through being intentional in the choice of imported packages, in anything but the smallest of codebases. While ensuring that no dependency calls those functions, the user will soon realize that:
even the ever-ubiquitous text/template package calls reflect's MethodByName
curation of all packages today could be foiled by any package changing tomorrow
often method reflection is not actually required (e.g. provided data has only fields but text/template trying to find a method before trying it as a field), and the linker's choice to disable DCE stems from caution rather than an educated guess
ikonst
changed the title
proposal: cmd/link: optionally ignore ReflectMethod
proposal: cmd/link: option to force DCE when reflect Method is present
Mar 16, 2025
In order to use such an option you would have to know that it worked for every single call to MethodByName in your program. Given the widespread use of text/template and similar packages in the Go ecosystem, that only seems possible for very restricted programs. So this seems like a configuration knob that would have to be maintained and tested, but that almost nobody would be able to use. The benefit does not seem worth the cost.
Thanks for the feedback @ianlancetaylor, I agree with your rationale. Similarly to avoiding MethodByName working only for the smallest codebases, so is being certain that such flag would be safe to use.
I'm retracting this proposal. Members of the community (e.g. Uber here) do appear interested in maintaining DCE in large codebases and finding a practical approach, so I think it was good to put this up as a straw-man proposal (to capture what isn't practical).
Proposal Details
Summary
Provide an option (through GODEBUG or a linker flag?) to force exported method dead-code elimination despite presence of reflect
Method
or (non-constant)MethodByName
in the code. When enabled, the resulting executable would have its reflection APIs return only methods that are otherwise referenced.For edge cases, the user could force a reference e.g. by adding a dummy
MethodByName
Motivation
The user will trade a compatibility promise (could break packages in unpredictable ways) for faster build times and smaller binaries (can be dramatic when importing some excessively large packages).
It's not practical for a user to achieve this otherwise, e.g. through being intentional in the choice of imported packages, in anything but the smallest of codebases. While ensuring that no dependency calls those functions, the user will soon realize that:
MethodByName
data
has only fields but text/template trying to find a method before trying it as a field), and the linker's choice to disable DCE stems from caution rather than an educated guessP.S.
This very proposal was implemented in https://go-review.googlesource.com/c/go/+/488575 but wasn't meant to be submitted.
The text was updated successfully, but these errors were encountered: