-
Notifications
You must be signed in to change notification settings - Fork 17.6k
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: Go 2: Add Automatic Free Block #63671
Comments
Unless I'm missing something, this is backwards compatible. We're adding a feature that makes it possible to avoid GC. The previous GC functionality would still be available though. |
|
I write backwards incompatibility because I can't think of a method that allows AutoFree to have special semantics and is also compatible with variables or other symbols previously written with AutoFree.
…---Original---
From: ***@***.***>
Date: Sun, Oct 22, 2023 22:44 PM
To: ***@***.***>;
Cc: ***@***.******@***.***>;
Subject: Re: [golang/go] proposal: Go 2: Add Automatic Free Block (Issue#63671)
Unless I'm missing something, this is backwards compatible. We're adding a feature that makes it possible to avoid GC. The previous GC functionality would still be available though.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
Yeah so you are introducing a dangerous class of bugs that doesn't exist in Go today (excluding cgo and such).
There's no synchronization. You are just going to randomly release the goroutine's heap memory in the middle of its execution? The short of it is that this proposal seems incompatible with every library that exists, both standard and third-party. It would be so limiting that I cannot see how this feature could possibly provide any value. |
I assume that the program has not started to use memory at a certain time node, called A1; At a certain time node, called A2, memory is used; At a certain time node, called A3, the program no longer uses memory. Programmers only need to write AutoFree block before A2 and then write} after A3, so they can use heap memory safely. This is my design idea. But I admit that this is not as safe as GC, because the programmer may write the wrong location of the AutoFree block.
…---Original---
From: ***@***.***>
Date: Mon, Oct 23, 2023 06:41 AM
To: ***@***.***>;
Cc: ***@***.******@***.***>;
Subject: Re: [golang/go] proposal: Go 2: Add Automatic Free Block (Issue#63671)
As soon as the AutoFree block ends, the heap allocation inside should be immediately Free. Only when pointers within a block survive outside the block can use-after-free occur.
Yeah so you are introducing a dangerous class of bugs that doesn't exist in Go today (excluding cgo and such).
Creating goroutine in AutoFree blocks has the same semantics.
There's no synchronization. You are just going to randomly release the goroutine's heap memory in the middle of its execution?
The short of it is that this proposal seems incompatible with every library that exists, both standard and third-party. It would be so limiting that I cannot see how this feature could possibly provide any value.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Again, the problem here is that if you call some library function, you would have to deeply inspect its code (and the code of its transitive dependencies) to draw any conclusion about when it is safe to free the memory. And you would have to repeat this exhaustive exercise any time you upgrade anything. In the meantime, I suggest you look at the arenas experiment (emphasis on experiment!) described in #51317, which seems similar to what you've proposed, but with more safety nets. |
I have already read proposal #51317 and it requires manual New and Free. It cannot be used from multiple goroutines yet, that's why I wrote this proposal!
…---Original---
From: ***@***.***>
Date: Mon, Oct 23, 2023 07:07 AM
To: ***@***.***>;
Cc: ***@***.******@***.***>;
Subject: Re: [golang/go] proposal: Go 2: Add Automatic Free Block (Issue#63671)
But I admit that this is not as safe as GC, because the programmer may write the wrong location of the AutoFree block.
Again, the problem here is that if you call some library function, you would have to deeply inspect its code (and the code of its transitive dependencies) to draw any conclusion about when it is safe to free the memory. And you would have to repeat this exhaustive exercise any time you upgrade anything.
In the meantime, I suggest you look at the arenas experiment (emphasis on experiment!) described in #51317, which seems similar to what you've proposed, but with more safety nets.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Adding any API that could introduce a silent use-after-free bug is a non-starter. The arena package is explicitly designed to ensure that it is not silent about use-after-free bugs. And even then, we're not sure we want to go down that road by promoting it to non-experimental.
It requires |
A guess, can the Go compiler detect saving intra block pointers outside the block and reporting errors? Perhaps by using a memory pool similar to arena, but with concurrency security. Is this proposal as safe as Arena?
What I mean is that Arena's New manually allocates one go object each time, and then manually calls Free only once to release all allocated go objects. The N of this proposed AutoFree is different from Arena's New, as N is only the number of bytes that the memory pool is ready to wait for Alloc. |
Per @randall77's comment, this is a non-starter. Therefore, this is a likely decline. Leaving open for four weeks for final comments. |
This is a good idea, but there may be some issues with the grammar design |
What are the issues with grammar design?
…---Original---
From: ***@***.***>
Date: Thu, Nov 9, 2023 12:45 PM
To: ***@***.***>;
Cc: ***@***.******@***.***>;
Subject: Re: [golang/go] proposal: Go 2: Add Automatic Free Block (Issue#63671)
This is a good idea, but there may be some issues with the grammar design
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
I've thought of an implementation that won't be silent about use-after-free bugs! |
Maybe you don't need to add any keywords
for example:
|
No change in consensus. |
Author background
Experienced Go Programmer
C.
Related proposals
I don't know.
no.
no.
Proposal
Add automatic Free blocks to go language.
People who require zero GC or do not have STW.
The syntax is:
N is the number of memory bytes that the memory pool is prepared to wait for Alloc.
Semantic refers to the memory allocated on the heap, which will automatically be free after the end of the block.
I don't quite understand how to write the Go language specification for EBNF.
By using automatic Free blocks, heap allocation within the block can be automatically released after the block ends.
N is the number of bytes waiting for Alloc to be pre allocated by the memory pool.
When all heap allocations are in the automatic Free block, GOGC=0 can be used to turn off GC to avoid STW
The syntax is:
no.
Breaking the Go 1 compatibility guarantee is a large cost and requires a large benefit.
Show example code before and after the change.
Before
GC is required.
After
GC can be turned off because heap allocation can be automatically released.
I don't know.
yes.
Can eliminate the need for GC, STW disappears.
I don't know.
Costs
It's even harder because of the new features.
I don't know.
I don't know.
I don't know.
I don't know.
AutoFree N {is rewritten to create a memory pool,} is rewritten to free memory in the memory pool, and the heap allocation between {and} is allocated in the memory pool.
There is no prototype for GO, there are prototypes in other languages, but the document is not written in English.
The text was updated successfully, but these errors were encountered: