- User Since
- Jun 9 2014, 9:36 AM (154 w, 1 d)
Aug 30 2016
Moving comment over here from trac -- isn't this overkill because it should only apply to some architectures?
Dec 15 2015
Ok, I'm happy to treat this as a tech preview for people to kick the tires and get used to the API.
Dec 12 2015
What's left on this one? Is it going to make the GHC 8.0 feature freeze? (Which... doesn't seem to have an exact hour and minute atm?)
Dec 11 2015
Oh, and to be clear I'm talking about the scenario where compactAppend remains nondestructive on the from space while GC worker threads are destructive, inserting forwarding pointers.
Well, I think the compacting thread needs to act much like a GC worker. GC can start without the compacting thread, but GC probably shouldn't finish until compacting thread(s) also finish.
@simonmar : what about if we just take any thread currently doing a compaction out of the set that will participate in GC, and let the other threads pass the barrier to enter GC without the compacting thread? The GC is already set up to tolerate parallel workers. Since the compacting thread is just copying, it looks very much like another parallel GC thread racing to walk the heap. It shouldn't matter if it reads any heap object from the to or from space.
Dec 10 2015
Maybe a simple approach is for compaction processes to poll to see if the system is trying to GC and just abort the compaction if it is.
@Yuras -- thanks, that looks like a bug. If the space given when creating the compact is too small it should just grow.
Dec 1 2015
Yes, @tibbe is working with us on this. The Wiki page needs some updates.
Nov 10 2015
I can speak to the second bullet.
Nov 9 2015
Ok. I was just trying to understand what "can't cope with" means.
If the silly/impossible constraints are purely local (and on code that's never executed), what's the problem with type-checking those expressions assuming, e.g., Int ~ Bool?
For test case T8392a at least it looks like the answer is that it should in fact just be a warning, and the test suite just needs to be updated to not expect an error, right?
Nov 5 2015
Oct 1 2015
My understanding was the same as @gcampax: that the compact library doesn't have significant interesting and separate functionality that would justify independent releases. It just exposes to Haskell what's in the RTS changes.