Hmm. What about heap checks? If a join point `j` does heap allocations, where do we do the heap-overflow check? Maybe we should absorb the heap allocation into the jump site (as if the code was inlined)? That could avoid doing two heap checks where only one is needed. (Would only work for non-recursive join points.)
Also I'm unclear about how we save live variables around a GC call at
#15560: Full laziness destroys opportunities for join points -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (CodeGen) | Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14287 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Replying to [comment:6 simonpj]: the start of a join point. (On function entry we use the function's info table; on a case return point we use its info table.) I was under the impression that join points never allocate and that they rather re-use the closure of their enclosing scope. Also, currently full laziness will never float join points (or any other binding) that closes over local variables to top-level, so we can probably disregard heap overflow checks. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15560#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler