DIscounting even garbage collector: is there any memory allocator anywhere that provides a facility to only return bytes at the start of an allocation to the manager? realloc() only lets you return bytes at the end, and most other allocators I've seen are based on that one's API... > On Oct 22, 2016, at 11:59 AM, Ian Lance Taylor <i...@golang.org> wrote: > > On Sat, Oct 22, 2016 at 2:01 AM, T L <tapir....@gmail.com > <mailto:tapir....@gmail.com>> wrote: >> >> On Saturday, October 22, 2016 at 4:57:52 PM UTC+8, T L wrote: >>> >>> >>> The string struct used internally is >>> >>> type stringStruct struct { >>> str unsafe.Pointer >>> len int >>> } >>> >>> When following f function is called and s is cleared, >>> how do go runtime knows the starting memory address of the old s.str is >>> "a" instead of "c"? >> >> >> I mean how do go runtime knows "abcdefg" instead of "cde" should be >> released. > > The garbage collector works in terms of allocated memory blocks. If > there is a pointer into the memory block, it is retained. If there > are no remaining pointers to the block, it is released. The fact that > the string points into the middle of the block only matters in that it > causes the block to be retained. Where the string points has no > effect on what is released when there are no remaining pointers to the > block. > > Note that this does mean that in the current GC implementation a > pointer into the middle of a string will cause the entire string to be > retained, even though if there are no pointers to other parts of the > string then there is no way to use that memory. In other words, > taking a small slice of a large string will cause the large string to > remain in memory as long as the small slice is live. I'm not aware of > any current plans to fix this (and I don't even know how it could be > fixed without significantly decreasing throughput). It's hard to know > how big a problem this is, as people are aware of it and write their > programs to avoid it. This is https://golang.org/issue/9618 > <https://golang.org/issue/9618>. > > 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 > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <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.
