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.
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? 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. Thanks, Jon On Tuesday, April 16, 2019 at 9:31:46 PM UTC-7, Ian Lance Taylor wrote: > > > > I'm not clear on what the problem is. If the memory is still > referenced, then it can't be freed. If the memory can be freed, then > there shouldn't be any references to it. So, at the point where you > would explicitly free memory, just clear the pointers that point to > it. Then the GC will free the memory. > > Ian > On Tuesday, April 16, 2019 at 9:31:46 PM UTC-7, Ian Lance Taylor wrote: > > On Tue, Apr 16, 2019 at 8:46 PM <jlfo...@berkeley.edu <javascript:>> > wrote: > > > > Go's garbage collector is very nice, and solves many problems that come > up in C programs. > > > > However, one thing I've been wondering about is explicitly freeing > memory. I know it can't be done > > now, and that the GC takes care of everything. > > > > But I was thinking about multi-pass programs like compilers, that do a > bunch of work in one pass. > > Once the pass is complete then most of the memory used by the pass could > be freed. But that > > will never happen because the memory appears to the GC as still in use. > There are probably > > other examples of such program structure. > > > > What's the current thinking on this problem? > > I'm not clear on what the problem is. If the memory is still > referenced, then it can't be freed. If the memory can be freed, then > there shouldn't be any references to it. So, at the point where you > would explicitly free memory, just clear the pointers that point to > it. Then the GC will free the memory. > > Ian > On Tuesday, April 16, 2019 at 9:31:46 PM UTC-7, Ian Lance Taylor wrote: > > On Tue, Apr 16, 2019 at 8:46 PM <jlfo...@berkeley.edu <javascript:>> > wrote: > > > > Go's garbage collector is very nice, and solves many problems that come > up in C programs. > > > > However, one thing I've been wondering about is explicitly freeing > memory. I know it can't be done > > now, and that the GC takes care of everything. > > > > But I was thinking about multi-pass programs like compilers, that do a > bunch of work in one pass. > > Once the pass is complete then most of the memory used by the pass could > be freed. But that > > will never happen because the memory appears to the GC as still in use. > There are probably > > other examples of such program structure. > > > > What's the current thinking on this problem? > > I'm not clear on what the problem is. If the memory is still > referenced, then it can't be freed. If the memory can be freed, then > there shouldn't be any references to it. So, at the point where you > would explicitly free memory, just clear the pointers that point to > it. Then the GC will free the memory. > > 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 golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
