FTA: “Heap allocations made by the function are erased as soon as the garbage collector decides they are no longer reachable”
I think that means this proposal adds a very specific form of finalisers to go.
How is that implemented efficiently? I can think of doing something akin to NSAutoReleasePool (https://developer.apple.com/documentation/foundation/nsautor...), with all allocations inside a `secret.Do` block going into a separate section of the heap (like a new generation), and, on exit of the block, the runtime doing a GC cycle, collecting and clearing every now inaccessible object in that section of the heap.
It can’t do that, though, because the article also says:
“Heap allocations are only erased if the program drops all references to them, and then the garbage collector notices that those references are gone. The program controls the first part, but the second part depends on when the runtime decides to act”
and I think what I am thinking of will guarantee that the garbage collector will eagerly erase any heap allocations that can be freed.
Also, the requirement “ the program drops all references to them” means this is not a 100% free lunch. You can’t simply wrap your code in a `secret.Do` and expect your code to be free of leaking secrets.
My guess is that the GC will eagerly wipe+free "secret" memory first and completely on the pass as opposed to deferring to the next GC cycle as is the normal use that may otherwise happen on longer GC cycles to keep overall performance characteristics happy.
This is just my own speculation, I don't know the internals of Go beyond a few articles I've read over the years. Somewhat more familiar with C#, JS and Rust, and even then I'll sometimes confuse certain features between them.
I think that means this proposal adds a very specific form of finalisers to go.
How is that implemented efficiently? I can think of doing something akin to NSAutoReleasePool (https://developer.apple.com/documentation/foundation/nsautor...), with all allocations inside a `secret.Do` block going into a separate section of the heap (like a new generation), and, on exit of the block, the runtime doing a GC cycle, collecting and clearing every now inaccessible object in that section of the heap.
It can’t do that, though, because the article also says:
“Heap allocations are only erased if the program drops all references to them, and then the garbage collector notices that those references are gone. The program controls the first part, but the second part depends on when the runtime decides to act”
and I think what I am thinking of will guarantee that the garbage collector will eagerly erase any heap allocations that can be freed.
Also, the requirement “ the program drops all references to them” means this is not a 100% free lunch. You can’t simply wrap your code in a `secret.Do` and expect your code to be free of leaking secrets.