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 > <javascript:>> 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.
