[GHC] #8255: GC Less Operation

[GHC]

#8255: GC Less Operation
-------------------------------------+-------------------------------------
        Reporter:  sirinath          |            Owner:
            Type:  feature request   |           Status:  closed
        Priority:  lowest            |        Milestone:  _|_
       Component:  Compiler          |          Version:  7.7
      Resolution:  invalid           |         Keywords:
Operating System:  Unknown/Multiple  |     Architecture:  Unknown/Multiple
 Type of failure:  Runtime           |       Difficulty:  Project (more
  performance bug                    |  than a week)
       Test Case:                    |       Blocked By:
        Blocking:                    |  Related Tickets:
-------------------------------------+-------------------------------------

Comment (by sirinath):

 I am not saying you can get it right in one bang. Until you get it right
 you need a GC as a fall back.

 Lets take a simple case.

 In a function evocation which takes simple parameters and has closure on
 simple variable we can divide that what data came from the surrounding
 context (both closure and parameters), what actually is used in the local
 evaluation, and what needs to survive the function (return values, local
 created parameters which closures in locally defined function, etc.) This
 can translate to what memory needed to be allocated, what can de de
 allocated and what needs to be retained. This can be mapped into a set
 holding these symbols.

 For each function you maintain this information. If a function, a list of
 function etc. is passed to a function then these sets will hold some
 production of sets of the above 3.

 In the parent context functional application and closures will define what
 needs to survive this context if a function is returned.

 Based on this the compiler can build a region map on what needs allocating
 and when as well as when it can be freed. Some memory requirements sizes
 may not be know (e.g. input dependent) but allocation and de allocations
 can be inferred. Even if this is not globally optimised this requirement
 can be inferred in the functions context.

 When implementing something new like this it will not be perfect to handle
 all cases. Stating point may be 20% of the use cases which matter the most
 or used in a programme 80% of the time. In the rest fall back to GC as the
 safety net. Gradually can add more cases and some point you might not need
 the GC.

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8255#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler