ghc-in-ghci memory usage

[Michael Sloan]

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 gmail.com> 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/run.sh -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 haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs