ghc-in-ghci memory usage

Alp Mestanogullari alp at
Wed Oct 31 21:01:06 UTC 2018

Hadrian has the `--freeze1` flag, whose description is: freeze Stage1 
GHC, i.e. do not rebuild it even if some of its source files are 
out-of-date. This allows to significantly reduce the rebuild time when 
you are working on a feature that affects both Stage1 and Stage2 
compilers, but may lead to incorrect build results. To unfreeze Stage1 
GHC simply drop the|--freeze1|flag and Hadrian will rebuild all 
out-of-date files.


On 31/10/2018 21:54, Matthew Pickering wrote:
> The information about freezing stage2 is in the first paragraph after
> the basics on the newcomers page. So it is already very prominent.
> That being said, this will all change when hadrian is the default and
> I'm not sure how to achieve this with Hadrian. I'm sure this will have
> been accounted for.
> Cheers,
> Matt
> On Wed, Oct 31, 2018 at 7:53 PM Michael Sloan <mgsloan at> wrote:
>> Great, I'm glad it's working well for you!
>> I've realized that when working on ghc-in-ghci, I didn't know about
>> freezing stage 1 to speed up GHC builds.  For me the primary
>> motivation was that otherwise builds took quite long.  Of course,
>> ghc-in-ghci is still quite useful, due to being able to use the repl,
>> avoiding static link times, etc.
>> I'm not sure what the best way would be to effectively communicate
>> with newcomers about freezing stage 1, but it seems important for
>> build times.  It may be easy to get dissuaded if every development
>> iteration involves a ton of waiting for the build.  Perhaps hadrian
>> can be more intelligent about avoiding stage 1 rebuilds?  I realize
>> that's likely to be tricky from a correctness perspective.
>> One thing I'm keen on for ghc-in-ghci is getting it to load without
>> -fobject-code.  This would often mean a much longer initial start (no
>> use of stored object files), but should make reloads quite a lot
>> faster, since it's generating bytecode instead.  The main tricky bit
>> there is the use of unboxed tuples, since ghci cannot bytecode-compile
>> code that uses them.  So, this either means adding support for unboxed
>> tuples to bytecode, which seems quite challenging, or having something
>> clever that only uses object-code compilation where needed.
>> -Michael
>> On Tue, Oct 30, 2018 at 7:56 AM Matthew Pickering
>> <matthewtpickering at> wrote:
>>> I just tried using the ghc-in-ghci script again and it appears that
>>> the memory usage problems have been resolved. Probably thanks to Simon
>>> Marlow who fixed a lot of space leaks in ghc.
>>> A reminder of how to use it:
>>> ./utils/ghc-in-ghci/ -j<n>
>>> will load ghc into ghci so you can `:r` to recompile when you make a change.
>>> Cheers,
>>> Matt
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at

Alp Mestanogullari, Haskell Consultant
Well-Typed LLP,

Registered in England and Wales, OC335890
118 Wymering Mansions, Wymering Road, London, W9 2NF, England

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ghc-devs mailing list