Speaking for the Rick Hudson Fan Club, thank you for your wonderful, amazing work on the Go GC...
https://blog.golang.org/ismmkeynote ...and for this reminder that we don't want programming practice to preclude continuing innovations. On Wed, Dec 4, 2019 at 9:52 AM Rick Hudson <r...@golang.org> wrote: > Breaking the Go CGO pointer rules comes up periodically and the rules > have not changed. Applications have lived with the rules simply > because breaking them results in revisiting the application code > every time a new Go release comes out. Did the compiler improve and > some object is now allocated on the stack instead of the heap? Did the > runtime borrow some MESH [1] virtual memory page fragmentation > techniques but improve them for Go by updating pointers to reducing > TLB pressure? Is there value in moving objects from NVRAM to DRAM > and updating pointers? And so forth and so on. Nobody knows if any of > this will ever happen but the Go CGO pointer rules leave open the > possibility. > > > [1] Bobby Powers, David Tench, Emery D. Berger, and Andrew McGregor. 2019. > Mesh: Compacting Memory Management for C/C++ Applications. In > Proceedings of the 40th ACM SIGPLAN Conference on Programming Language > Design and Implementation (PLDI ’19), June 22ś26, 2019, Phoenix, AZ, USA. > ACM, New York, NY, USA, 14 pages. https://doi.org/10.1145/3314221.3314582 > > > On Wednesday, December 4, 2019 at 11:14:17 AM UTC-5, Ian Lance Taylor > wrote: >> >> On Wed, Dec 4, 2019 at 6:48 AM Robert Johnstone <r.w.j...@gmail.com> >> wrote: >> > >> > Thanks for the quick reply. I had not considered the write barriers, >> but if the Go objects are "live" longer than the held in C, it would work. >> >> The write barriers do not look only at the pointer being stored, they >> also look at the contents of memory being stored into. That is why C >> code must never store a Go pointer into Go memory. >> >> >> > I definitely agree that there are risks associated with this approach. >> We are giving up some of the safety of Go. Unfortunately, we are using cgo >> for more than some computation, so we have live objects in C as well, and >> so we cannot completely escape the manual memory management required. >> > >> > What is the state of plans for a moving garbage collector? This would >> definitely wreck havoc if any pointers to Go memory were held in C. >> >> There are no current plans for a moving garbage collector. >> >> I cannot promise that no other changes will break this approach. >> Obviously we won't consider bug reports for code that breaks the cgo >> rules. >> >> 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/23885bd0-4802-40c7-b4c9-52541e92029f%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/23885bd0-4802-40c7-b4c9-52541e92029f%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- *Michael T. jonesmichael.jo...@gmail.com <michael.jo...@gmail.com>* -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CALoEmQwZiyh7wjL5OokVKoPkw-8tjdm-uu7zJt75z%2B_H-9AwjA%40mail.gmail.com.
