Object unloading confusion

Hi Simon, I'm looking at object unloading code in CheckUnload.c. My understanding of how unloading works is: - When unloading of an object is requested the object is added to `unloaded_objects`. - When `unloaded_objects` is not empty, after GC, we scan the heap for any references to

Re: Object unloading confusion

break; ... if (!prim) { checkAddress(addrs,info, s_indices); } Would be good to know why it's fine to not check MVARs and other kinds of objects that we skip in that code. Ömer Ömer Sinan Ağacan , 15 Nis 2020 Çar, 12:35 tarihinde şunu yazdı: > > Hi Simon, > > I'm looking at obj

Recompilation avoidance questions

Hi all, I'm currently reading the "recompilation avoidance" wiki page [1], and I have a few questions about the current design. The wiki page says (in the paragraph "Suppose the change to D ...") if a module B re-exports x from module D, changing x in D does not cause any changes in B's

Re: Roadmap to compacting ModIface

How is ModIface used by IDEs exactly? I'd expect IDEs to use ModDetails, not ModIface. They're basically two different representations of the same thing (a module interface), but ModIface is more focused on serialization and deseriazliation (the type is designed to make that easy) and ModDetails

"Extensible interface files" work and ANN pragmas

The "extensible interface files" [1, 2] work has been discussed at GHC calls a few times and the conclusion was we were going to document why current annotation mechanism (ANN pragmas) are insufficient and we need yet another way to put stuff into interfaces. Unfortunately the MR was merged

Re: Recompilation avoidance questions

ing re-export paths should be enough. So maybe this is not too bad. Ömer Simon Marlow , 22 Nis 2020 Çar, 12:02 tarihinde şunu yazdı: > > On Tue, 21 Apr 2020 at 11:38, Ömer Sinan Ağacan wrote: >> >> Hi all, >> >> I'm currently reading the "recompilation avoidanc

Re: [RFC] Compiler pipeline timings visualization

Hi, While better representation/visualization of the pipeline might be useful, my opinion is that it might not be as useful as you might expect. The problem is lazy evaluation: it assigns the blame to incorrect places. For example, in GHC if I update a record field in pass 1 and use it in pass

Potential improvement in compacting GC

Hello, I recently implemented the algorithm used by GHC's compacting GC in another project. The algorithm (after marking) makes two passes over the heap /generation. In GHC, these passes are implemented in [1] and in the next function. In my implementation I tried 3 ways of implementing these

Re: Potential improvement in compacting GC

/rts/sm/Compact.c#L844-L848 Ömer Sinan Ağacan , 14 Tem 2021 Çar, 09:27 tarihinde şunu yazdı: > > Two other ideas that should improve GHC's compacting GC much more > significantly. I've implemented both of these in another project and the > results were great. In a GC benchmark (mutator

Re: Potential improvement in compacting GC

didn't have to debug it more once the tests passed. It's really unfortunate that GHC's RTS makes this kind of thing difficult.. Ömer Ömer Sinan Ağacan , 7 Oca 2021 Per, 20:42 tarihinde şunu yazdı: > > Hello, > > I recently implemented the algorithm used by GHC's compacting GC in

<    1   2   3   4