In the example you cite, in a properly written compiler that memory would no longer be referenced (unless it was needed later) - no need to manually clear all pointers - just the root references.
I think you need more understanding of how to properly manage memory in a GC environment. > On Apr 16, 2019, at 11:53 PM, jlforr...@berkeley.edu 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. > > 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> 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> 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. -- 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.
