On Tue, Apr 16, 2019 at 9: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.
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 golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
