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

runtime: malloc flags should be subsumed by the type information provided to mallogc #6237

Closed
lexprfuncall opened this issue Aug 23, 2013 · 3 comments

Comments

@lexprfuncall
Copy link

Today, we pass flags to malloc to help it decide what constraints are required on the
storage allocated for an object.  However, all of this information can be derrived from
the type of an object.

For example, instead of passing the "not pointers" flag mallocgc can do a
"no pointers" allocation whenever it is passed a type which contains no point
values.

There are some flags which cannot be subsumed by the type information, this includes the
zeroing flag (sometimes we know we are going to initialize an object and do not need
zeroing) and the no invoke gc flag.  The "no gc" flag is a gray area, in
theory types could encode this information (for example, mspans, stacks) but today those
kinds of allocation have no type.  Maybe they should.
@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 1:

Labels changed: added release-none, removed go1.3maybe.

@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 2:

Labels changed: added repo-main.

@rsc rsc added this to the Unplanned milestone Apr 10, 2015
@martisch
Copy link
Contributor

Current runtime malloc takes a type and derives the pointer or no-pointer properties from the type.

func mallocgc(size uintptr, typ *_type, needzero bool) unsafe.Pointer {

This issue seems to have therefore been adressed sometime in the last 5+ years and can be closed.

@golang golang locked and limited conversation to collaborators Oct 14, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants