Opened 7 years ago

Last modified 4 years ago

#7300 new feature request

Allow CAFs kept reachable by FFI to be forcibly made unreachable for GC

Reported by: absence Owned by:
Priority: normal Milestone:
Component: Compiler (FFI) Version: 7.4.1
Keywords: unsafe caf gc Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Runtime performance bug Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

CAFs used by a foreign exported function are kept reachable the entire session because GHC can't know when the function will be called from C. If such a CAF is an evolving expression, like an FRP network, a space leak occurs because (I'm guessing) the thunks that build up during iteration go all the way back to the initial CAF, and the GC can't start collecting because it considers the CAF reachable. According to JaffaCake on the #haskell IRC channel, the runtime is capable of sovling this problem, it just needs a function that tells it to consider the specific CAF unreachable. It is then the responsibility of the user to not call the foreign exported function after the CAF is forced unreachable.

Change History (8)

comment:1 Changed 7 years ago by simonmar

difficulty: Unknown
Milestone: 7.8.1
Priority: normalhigh

Thanks for making a ticket.

What I had in mind (to remind myself) is that we expose a C API from the RTS that would revert all the live CAFs. This would have to be done at the same time as a major GC, because that is the only time that we can visit all the live CAFs.

comment:2 Changed 7 years ago by ezyang

Of course, revertCAFs only works when the linker sets up CAFs with newDynCAF...

comment:3 in reply to:  2 Changed 7 years ago by simonmar

Replying to ezyang:

Of course, revertCAFs only works when the linker sets up CAFs with newDynCAF...

Spot on.

comment:4 Changed 5 years ago by thoughtpolice

Milestone: 7.8.37.10.1

Bumping priority down (these tickets haven't been closely followed or fixed in 7.4), and moving out to 7.10 and out of 7.8.3.

comment:5 Changed 5 years ago by thoughtpolice

Priority: highnormal

Actually dropping priority. :)

comment:6 Changed 5 years ago by thoughtpolice

Milestone: 7.10.17.12.1

Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone.

comment:7 Changed 4 years ago by thoughtpolice

Milestone: 7.12.18.0.1

Milestone renamed

comment:8 Changed 4 years ago by thomie

Milestone: 8.0.1
Note: See TracTickets for help on using tickets.