[Git][ghc/ghc][wip/ghci-leaks-fix] 3 commits: Force more in NFData Name instance

[Matthew Pickering (@mpickering)]

Matthew Pickering pushed to branch wip/ghci-leaks-fix at Glasgow Haskell Compiler / GHC


Commits:
0517eea9 by Matthew Pickering at 2023-01-25T16:05:30+00:00
Force more in NFData Name instance

Doesn't force the lazy `OccName` field (#19619) which is already known
as a really bad source of leaks.

When we slam the hammer storing Names on disk (in interface files or the
like), all this should be forced as otherwise a `Name` can easily retain
an `Id` and hence the entire world.

Fixes #22833

- - - - -
f9f413bd by Matthew Pickering at 2023-01-25T16:05:34+00:00
Force OccName in tidyTopName

This occname has just been derived from an `Id`, so need to force it
promptly so we can release the Id back to the world.

Another symptom of the bug caused by #19619

- - - - -
44c95dc5 by Matthew Pickering at 2023-01-25T16:05:38+00:00
Strict fields in ModNodeKey (otherwise retains HomeModInfo)

Towards #22530

- - - - -


3 changed files:

- compiler/GHC/Iface/Tidy.hs
- compiler/GHC/Types/Name.hs
- compiler/GHC/Unit/Module/Graph.hs


Changes:

=====================================
compiler/GHC/Iface/Tidy.hs
=====================================
@@ -1077,7 +1077,8 @@ tidyTopName mod name_cache maybe_ref occ_env id
   -- we have to update the name cache in a nice atomic fashion
 
   | local  && internal = do uniq <- takeUniqFromNameCache name_cache
-                            let new_local_name = mkInternalName uniq occ' loc
+                            -- See #19619
+                            let new_local_name = occ' `seq` mkInternalName uniq occ' loc
                             return (occ_env', new_local_name)
         -- Even local, internal names must get a unique occurrence, because
         -- if we do -split-objs we externalise the name later, in the code generator


=====================================
compiler/GHC/Types/Name.hs
=====================================
@@ -155,7 +155,7 @@ instance Outputable NameSort where
   ppr  System         = text "system"
 
 instance NFData Name where
-  rnf Name{..} = rnf n_sort
+  rnf Name{..} = rnf n_sort `seq` rnf n_occ `seq` n_uniq `seq` rnf n_loc
 
 instance NFData NameSort where
   rnf (External m) = rnf m


=====================================
compiler/GHC/Unit/Module/Graph.hs
=====================================
@@ -131,8 +131,8 @@ nodeKeyModName :: NodeKey -> Maybe ModuleName
 nodeKeyModName (NodeKey_Module mk) = Just (gwib_mod $ mnkModuleName mk)
 nodeKeyModName _ = Nothing
 
-data ModNodeKeyWithUid = ModNodeKeyWithUid { mnkModuleName :: ModuleNameWithIsBoot
-                                           , mnkUnitId     :: UnitId } deriving (Eq, Ord)
+data ModNodeKeyWithUid = ModNodeKeyWithUid { mnkModuleName :: !ModuleNameWithIsBoot
+                                           , mnkUnitId     :: !UnitId } deriving (Eq, Ord)
 
 instance Outputable ModNodeKeyWithUid where
   ppr (ModNodeKeyWithUid mnwib uid) = ppr uid <> colon <> ppr mnwib



View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/a08831e750d1149a8b4f6ce9afcc601833ed9229...44c95dc55cbab0fee99b14ebf988e08a4fb5a18d

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/a08831e750d1149a8b4f6ce9afcc601833ed9229...44c95dc55cbab0fee99b14ebf988e08a4fb5a18d
You're receiving this email because of your account on gitlab.haskell.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20230125/90bcd343/attachment-0001.html>