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: support explicit delete in golang #46429

Closed
stupidjohn opened this issue May 28, 2021 · 4 comments
Closed

Proposal: support explicit delete in golang #46429

stupidjohn opened this issue May 28, 2021 · 4 comments
Labels
Milestone

Comments

@stupidjohn
Copy link

  1. first case
func do(x SomeInterface) {...}
func outer() {
  var x = new(A)
  do(x)
  markDelete(x) // explicit delete x if we know x's lifetime end here
}

if we know in advance that x's lifetime will finish when outer end. can we mark delete x. and the compiler can safely alloc x on stack.

  1. second case
func loop(ch <-chan *A) {
  for x := range ch {
    use(x)
    markDelete(x)
  }
}

most times, we know which objects could safely be deallocated just like in lang without gc, could we delete them immediately to relief gc pressure ?

proposal:
support markDelete in golang to tell compiler to alloc on stack or immediately dealloc object.
add check code in markDelete to detect false delete in runtime just like how raceenable works.

@gopherbot gopherbot added this to the Proposal milestone May 28, 2021
@ianlancetaylor
Copy link
Member

Dup of #43582 (and possibly others). We aren't going to do this. Sorry.

@stupidjohn
Copy link
Author

Dup of #43582 (and possibly others). We aren't going to do this. Sorry.

hello, i think support explicit delete exceed the need.
how about 1. support hint to tell compiler object are safe to alloc on stack for the first case; and 2. support unique pointer(which are not able to copy) that when it ended it's life time, the object it reference could be dealloc immediately.

ok, after i say these words, i found already it is very different from golang
sorry to ask these unrealistic requirement, forgive me just want program to run faster

@davecheney
Copy link
Contributor

how about 1. support hint to tell compiler object are safe to alloc on stack for the first case;

The compiler already does stack allocate objects that can be proven not to escape. If the compiler cannot prove they do not escape, then adding an override would create a memory safety issue. The better path would be to fix the compiler, or use the //go:noescape annotation.

@shuidaan
Copy link

shuidaan commented Oct 7, 2021

Especially now many people use tinygo to run on the MCU (singlechip). When the memory is used up, it will be released immediately, which is a little important.

Just like today's cars, they generally have automatic and manual gears, which can also be called automated manual transmission (AMT), which can be selected according to the needs of users. Improve user experience.

???

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

No branches or pull requests

5 participants