There are two issues here: 1. *"I'm done with this and I want to free it now."* It seems helpful as a programmer to say such things. I wanted that once. The problem with it is that the runtime can't trust you if you say it. At best it can put the address on a list to be examined, but only a GC pass will be able to prove that the region is unreferenced.
2. *"It is still referenced but I'm done with it forever."* This is good in spirit: it is a kind of program-level pointer liveness analysis as is done in register allocation. It could be proven by the compiler that at line N+1 of code...some things from lines 0..N will no longer be referenced. This could be done automatically by inserting "set never to be referenced pointers to nil" code during compilation after each provable last reference. On Tue, Apr 16, 2019 at 10:22 PM Ian Lance Taylor <[email protected]> wrote: > On Tue, Apr 16, 2019 at 9:53 PM <[email protected]> wrote: > > > > In a compiler, say during the lexing and parsing phases, memory might be > allocated > > that won't be needed after those phases are complete. The memory is > still referenced, > > so the GC won't free it, but conceptually it actually could be freed. In > other words, > > the fact that memory is referenced isn't the final word on whether it > could be freed. > > If the memory is still referenced, it can still be used, so it won't > be freed. If the memory will not longer be used, then don't reference > it. > > > > You're saying to modify all the pointers that point to this memory. I'm > guessing > > that this could be a lot of work, Plus, let's say this memory is > organized as > > a linked list. Would it be sufficient to just modify the pointer that > points to the > > head of the list, or would I have to go through the list from tail to > head, modifying > > the pointers in each list element? > > As Robert said, just stop referencing the head. The only references > that count are the ones from global and local variables. If it can't > be reached by following pointers from a variable, then it is no longer > referenced. > > > > And to answer Robert Engels question - no, I'm not concerned with the > > GC's performance because the memory I'm thinking about won't be seen > > by the GC since it's still referenced. And yes, I'm wondering whether > there's > > a way to create a region-like entity so that all the memory that was > allocated > > in the region could be freed in one swell foop. > > My earlier answer still stands: such a region is unlikely to make a > significant difference in a GC system. > > Ian > > -- > 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 [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- *Michael T. [email protected] <[email protected]>* -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
