On Friday, September 8, 2017 at 6:00:31 AM UTC+2, Nils Bruin wrote: > > On Thursday, September 7, 2017 at 9:49:33 AM UTC-7, Volker Braun wrote: >> >> First question: The GAP garbage collector might delete objects, or it >> might move existing objects around in memory (it is a compacting garbage >> collector). If your code contains C pointers to GAP objects, bad things >> will happen after that. Not every libGAP_* function can invoke the garbage >> collector, and for those that do it will not always run a collection cycle. >> But there are no documented guarantees that any particular libGAP_* >> function does not run garbage collection, or may be changed to run garbage >> collection in the future. >> > > Ouch. Gap indeed uses a compactifying garbage collector. But are you > saying it will adjust the *stack*, for which the garbage collector doesn't > know the exact layout? Then, if I have an integer on the stack that happens > to coincide in bit pattern with a pointer to a moved Gap object, this > integer could get changed. That's a low probability event, but not the kind > of thing that mathematical software can take chances with. Are you sure it > does that? (it seems it would have to ...) >
A mis-identified stack pointer will just keep the pointed-to GAP blob alive (even though it is actually dead). The libGAP_ C pointer is really a pointer to a GAP-internal pointer table, pointing to the memory blob. The table is not compactified, but the blobs are. So collection doesn't mutate anything on the stack. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
