<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">I'll add that another place where mutation occurs is when demanding an unevaluated thunk (this acts like a read barrier). This once-written property of thunk objects is handled specially by the garbage collector [1].</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">[1] <a href="https://www.microsoft.com/en-us/research/wp-content/uploads/2008/06/par-gc-ismm08.pdf" class="">https://www.microsoft.com/en-us/research/wp-content/uploads/2008/06/par-gc-ismm08.pdf</a> (I believe this is current version in GHC's master branch)</div><div class=""><br class=""></div><div style=""><br class=""><blockquote type="cite" class=""><div class="">On Mar 10, 2018, at 12:42 PM, Ben Gamari <<a href="mailto:ben@smart-cactus.org" class="">ben@smart-cactus.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Xuanrui Qi <<a href="mailto:me@xuanruiqi.com" class="">me@xuanruiqi.com</a>> writes:<br class=""><br class=""><blockquote type="cite" class="">Hi all,<br class=""><br class=""></blockquote>Hi,<br class=""><br class=""><blockquote type="cite" class="">I have a few questions about heap-allocated memory pointers in GHC.<br class="">Both code and data live in the heap, and both can have pointers to<br class="">other objects. However, according to my understanding, most<br class="">heap-allocated objects would be immutable. Moreover even if objects<br class="">might be mutated, most pointers should not be updated. I have heard<br class="">that the runtime system might implement several features by updating<br class="">pointers, but I am not sure which features are they.<br class=""><br class=""></blockquote>Code generally doesn't live on the dynamically-allocated heap. Rather,<br class="">it is mmap'd immutably into the process's address space. However,<br class="">closures, which can live in the heap, generally contain pointers to<br class="">code and can indeed be mutated.<br class=""><br class=""><blockquote type="cite" class="">My question is thus: (1) is there a way to trace mutations of heap<br class="">objects (for instance by modifying the GC system code) [I don't need<br class="">to know what is the change, all I want to know is what has been<br class="">changed],<br class=""></blockquote><br class="">Indeed it is possible. The RTS already tracks most mutations via a write<br class="">barrier to ensure safety of its generational GC. See the recordMutable<br class="">macro defined in Cmm.h.<br class=""><br class=""><blockquote type="cite" class="">and (2) is there a way where I could trace pointer updates<br class="">[in this case I'd like to know both the old and objects, preferably by<br class="">name]? More specifically, are these possible by annotating/changing<br class="">the runtime system only (i.e. not touching code generation)?<br class=""><br class=""></blockquote>This will be a fair bit harder, requiring modification of the RTS's<br class="">mutation operations (see PrimOps.cmm and Updates.cmm) at very least.<br class=""><br class="">Cheers,<br class=""><br class="">- Ben<br class="">_______________________________________________<br class="">ghc-devs mailing list<br class=""><a href="mailto:ghc-devs@haskell.org" class="">ghc-devs@haskell.org</a><br class="">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<br class=""></div></div></blockquote></div><br class=""></body></html>