Codecov Report

Attention: Patch coverage is 84.88372% with 39 lines in your changes missing coverage. Please review.

Project coverage is 61.19%. Comparing base (5444859) to head (8325344).
Report is 85 commits behind head on master.

@@            Coverage Diff             @@
##           master    #2735      +/-   ##
==========================================
+ Coverage   61.10%   61.19%   +0.09%     
==========================================
  Files         564      566       +2     
  Lines       75355    75643     +288     
==========================================
+ Hits        46045    46293     +248     
- Misses      25946    25978      +32     
- Partials     3364     3372       +8     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

package main

func foo() {
	s := []int{1, 2, 3}
}
func main() {
	foo()
	s1 := []int{4, 5, 6}
}

in this one, should we also deallocate the underlying array as well?

I think the issue with this PR is that it's not "observable", there lacks some necessary tests. there should be a way to track what’s being allocated and deallocated, IMHO.

I think the issue with this PR is that it's not "observable", there lacks some necessary tests. there should be a way to track what’s being allocated and deallocated, IMHO.

What do you mean? Can you be more specific?
The GC managed objects have a field called marked, which is used to track that on the GC side.
On the allocator side, the user code that owns that allocation knows.

I think the issue with this PR is that it's not "observable", there lacks some necessary tests. there should be a way to track what’s being allocated and deallocated, IMHO.

What do you mean? Can you be more specific?

The current test focuses on gc.go, but it’s insufficient to reveal what’s happening under the hood when dealing with specific code. e.g.

package main

func foo() {
	s := []int{1, 2, 3}
}
func main() {
	foo()
	s1 := []int{4, 5, 6}
}

While the gc behavior is deterministic, it should be more observable. For instance, we could expose details like the current state of the allocator, metrics before and after memory allocation/deallocation, and more. What do you think?

I think the issue with this PR is that it's not "observable", there lacks some necessary tests. there should be a way to track what’s being allocated and deallocated, IMHO.

What do you mean? Can you be more specific?

The current test focuses on gc.go, but it’s insufficient to reveal what’s happening under the hood when dealing with specific code. e.g.

package main

func foo() {
	s := []int{1, 2, 3}
}
func main() {
	foo()
	s1 := []int{4, 5, 6}
}

While the gc behavior is deterministic, it should be more observable. For instance, we could expose details like the current state of the allocator, metrics before and after memory allocation/deallocation, and more. What do you think?

The only way i could see this being viable is if its behind a debug flag.

This approach was not approved by Jae so this PR is to be closed.