Questions about pointers in GHC

[Kavon Farvardin]

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].


[1] https://www.microsoft.com/en-us/research/wp-content/uploads/2008/06/par-gc-ismm08.pdf <https://www.microsoft.com/en-us/research/wp-content/uploads/2008/06/par-gc-ismm08.pdf>  (I believe this is current version in GHC's master branch)


> On Mar 10, 2018, at 12:42 PM, Ben Gamari <ben at smart-cactus.org> wrote:
> 
> Xuanrui Qi <me at xuanruiqi.com> writes:
> 
>> Hi all,
>> 
> Hi,
> 
>> I have a few questions about heap-allocated memory pointers in GHC.
>> Both code and data live in the heap, and both can have pointers to
>> other objects. However, according to my understanding, most
>> heap-allocated objects would be immutable. Moreover even if objects
>> might be mutated, most pointers should not be updated. I have heard
>> that the runtime system might implement several features by updating
>> pointers, but I am not sure which features are they.
>> 
> Code generally doesn't live on the dynamically-allocated heap. Rather,
> it is mmap'd immutably into the process's address space. However,
> closures, which can live in the heap, generally contain pointers to
> code and can indeed be mutated.
> 
>> My question is thus: (1) is there a way to trace mutations of heap
>> objects (for instance by modifying the GC system code) [I don't need
>> to know what is the change, all I want to know is what has been
>> changed],
> 
> Indeed it is possible. The RTS already tracks most mutations via a write
> barrier to ensure safety of its generational GC. See the recordMutable
> macro defined in Cmm.h.
> 
>> and (2) is there a way where I could trace pointer updates
>> [in this case I'd like to know both the old and objects, preferably by
>> name]? More specifically, are these possible by annotating/changing
>> the runtime system only (i.e. not touching code generation)?
>> 
> This will be a fair bit harder, requiring modification of the RTS's
> mutation operations (see PrimOps.cmm and Updates.cmm) at very least.
> 
> Cheers,
> 
> - Ben
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20180310/63444f1b/attachment.html>