ghc-in-ghci memory usage
matthewtpickering at gmail.com
Wed Oct 31 20:54:46 UTC 2018
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.
On Wed, Oct 31, 2018 at 7:53 PM Michael Sloan <mgsloan at gmail.com> 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.
> 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
More information about the ghc-devs