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

Jump to bottom

runtime: don't pass *Type to new #8886

Open
dvyukov opened this issue Oct 7, 2014 · 4 comments
Open

runtime: don't pass *Type to new #8886

dvyukov opened this issue Oct 7, 2014 · 4 comments
Labels
Performance
Milestone
Unplanned

Comments

@dvyukov
Copy link
Member

dvyukov commented Oct 7, 2014 

Currently we pass a pointer to Type descriptor to new. It preserves alive all methods of
allocated types, as Type contains Method array. So linker can't strip them.
We should pass a special object that contains only necessary information to new:
1. size
2. size class (needs to be ignored for arrays with more than one element)
2. name string
3. embed GC pointer bitmask or a pointer to satellite GC bitmask (if both are zero, then
it's noptr type)
@rsc
Copy link
Contributor

rsc commented Oct 7, 2014

Comment 1:

I intend to do this once the toolchain is converted to Go.

Labels changed: added release-go1.5, removed release-none.

@bradfitz bradfitz modified the milestone: Go1.5 Dec 16, 2014
@rsc rsc removed accepted labels Apr 14, 2015
@rsc rsc modified the milestones: Go1.6, Go1.5 May 19, 2015
@rsc rsc modified the milestones: Unplanned, Go1.6 Nov 5, 2015
@quasilyte
Copy link
Contributor

The linker looks smart enough not to keep the unused methods.
Unless there is another reason to avoid passing a type to the newobject, this issue could probably be closed.

@ianlancetaylor
Copy link
Contributor

Thanks. This would likely still be a useful optimization.

@josharian
Copy link
Contributor

We've tended to minimize the number of arguments we pass to runtime functions, to minimize binary size. I think it'd be reasonable to call mallocgc directly (three args instead of one, IIRC), but extracting the full suite of info on the caller side is probably not a win. But I might be wrong. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Performance
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
6 participants
@bradfitz @josharian @rsc @dvyukov @ianlancetaylor @quasilyte