why not support explicit delete in golang?

[cheng dong]

1. first case

```go

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.

2. second case

```go

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 ?

[cheng dong]

to avoid false delete object, we could add some checking code in markDelete just like what we do with raceenable. 
one complicate case is internal pointer, we could recursively mark delete or mark delete internal pointer by hand ?

[Kurtis Rader]

I hope your proposal is never implemented. Manual memory management is the cause of far too many bugs. And I say that as someone who started programming in the mid 1970's (more than forty years ago). If you want manual memory management there are plenty of languages which provide it.

As a data point I spent a couple of years recently trying to modernize the Korn shell (ksh) source code. When I finally replaced the AST Vmalloc subsystem with the platform/compiler malloc implementation that allowed using tools like Valgrind and Address Sanitizer (asan). Those tools identified multiple bugs in the ksh implementation. Including use after free, double free, and returning a pointer to a stack allocated var that survived the termination of the function. And that was for a mature project that was (is?) widely used.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/dd5aba59-512c-4b9b-b365-2b509edd74e7n%40googlegroups.com.

--

Kurtis Rader

Caretaker of the exceptional canines Junior and Hank

[Jesse McNelis]

On Fri, May 28, 2021 at 12:56 PM cheng dong <qq451...@gmail.com> wrote:

to avoid false delete object, we could add some checking code in markDelete just like what we do with raceenable. 
one complicate case is internal pointer, we could recursively mark delete or mark delete internal pointer by hand ?

This idea has come up many times over the past 10 yrs. The problem comes down to:

1. If we know that the markDelete is doing the delete in a memory safe way, then we also know the life time of the object and can do the job of markDelete automatically.

2. If we don't know that the markDelete is doing the delete in a memory safe way then we lose memory safety.

Regards,

Jesse

[cheng dong]

problem is compiler often don't known how programs organize objects, or, some memory pattern could not be known at compile time. 
and sometimes, delete point is very obvious in some programming models.
finally i think developer should take their risk taking some unsafe operations by himself (like rust lang?)

Regards,

cheng

[Kurtis Rader]

On Thu, May 27, 2021 at 9:27 PM cheng dong <qq451...@gmail.com> wrote:

problem is compiler often don't known how programs organize objects, or, some memory pattern could not be known at compile time. 
and sometimes, delete point is very obvious in some programming models.
finally i think developer should take their risk taking some unsafe operations by himself (like rust lang?)

You are proposing the introduction of a "HCF" (Halt, Catch Fire) instruction.

You also wrote "delete point is very obvious in some programming models." For those cases it should be equally obvious to the Go compiler. It shouldn't be necessary for the programmer to annotate the object in that case.

I also fail to see what your first point has to do with your proposal. There is no way, other than for a hypothetical computer language I have never seen, for the compiler to know about the dynamic memory allocation pattern when the program runs. Your proposal does not address that problem.

[cheng dong]

Thank you for the clarification.
sorry to break the general rule, i'm new to golang-nuts

as to the question, i figured out i used wrong words, what i need in fact is1. a hint to tell compiler that some object are safe to alloc on stack(in case that we use it as interface so it escape from stack) 2. some concept like unique ptr that when it end it's life time, the object referenced can be deallocated immediately.

sorry to disturb you, and thanks for answer my question

On Fri, May 28, 2021 at 1:55 PM Kurtis Rader <kra...@skepticism.us> wrote:

On Thu, May 27, 2021 at 10:36 PM cheng dong <qq451...@gmail.com> wrote:

ok, i realized that it is unrealistic to add free operation in go.
i think i lack some knowledge of how gc works. may i have a question, if it is obvious to go compiler when a object got no reference why go only collect memory in gc steps instead of collect immediately after object got no reference? 

You only replied to me, not the golang-nuts mailing list. As a general rule you should not do that.

If it is obvious to the Go compiler "a object got no reference" the compiler will place the object on the goroutine stack rather than in the heap. Assuming, of course, that the object has a size reasonable for placement on the stack. Therefore not requiring the intervention of the Go garbage collector.

[Jesse McNelis]

On Fri, May 28, 2021 at 4:51 PM cheng dong <qq451...@gmail.com> wrote:

Thank you for the clarification.
sorry to break the general rule, i'm new to golang-nuts

as to the question, i figured out i used wrong words, what i need in fact is1. a hint to tell compiler that some object are safe to alloc on stack(in case that we use it as interface so it escape from stack) 2. some concept like unique ptr that when it end it's life time, the object referenced can be deallocated immediately.

For Go to be memory safe the compiler can't trust your hint because you could be wrong either by a mistake or by changes to future code invalidating some assumption you had.

A feature like Rust's unique pointers (and thus also borrowing and lifetimes) would require large changes to the language and completely change what Go is.

If you want the features of Rust then use Rust.

[cheng dong]

yes, i immediately got the point(it is far different from golang ) after i type these words.
so sorry to disturb 

[Robert Glonek]

To be very exact, this case would actually cause a fault, and is a good example of why manual management here is best not allowed:

```go

func loop(someSlice []int) {

  for _, x := range someSlice {

    use(x)

    markDelete(x)

  }

}

```

Even though you specified for x := range ..., inside the for loop, x is reused. It gets allocated once, when we enter the for loop and reused (with just another value assigned) as we iterate through it. Got me by surprise since it's := and I was trying to use its pointer &x to find I was reusing the same pointer.