[Haskell-cafe] [ANNOUNCE] GHC 8.4.3 released

[Ben Gamari]

Viktor Dukhovni <ietf-dane at dukhovni.org> writes:

> On Tue, May 29, 2018 at 04:07:23PM -0400, Ben Gamari wrote:
>
>> The GHC team is pleased to announce the availability of GHC 8.4.3. The
>> source distribution, binary distributions, and documentation for this
>> release are available at
>> 
>>     https://downloads.haskell.org/~ghc/8.4.3
>
Indeed. I have had quite some difficulty finding a toolchain on FreeBSD
that works. I found that depending upon which FreeBSD version I use
(10.3 or 11) I either encounter linker crashes or very high numbers of
crashing tests. I didn't spend much time on the issue as no one raised
the issue.

> While there's no binary distribution for FreeBSD at haskell.org,
> as of June 30 there's a FreeBSD ghc-8.4.3 port.  
>
>     https://svnweb.freebsd.org/ports/head/lang/ghc/Makefile?view=log
>
Ahh, great! Thanks for doing this. I'll try to replicate this while
doing the builds for 8.6.

> FWIW, while building it I saw a compiler warning:
>
>     libraries/Cabal/Cabal/Distribution/Simple/Program/Builtin.hs:62:1: warning: [-Wunused-imports]
> 	The import of ‘System.FilePath’ is redundant
> 	  except perhaps to import instances from ‘System.FilePath’
> 	To import instances alone, use: import System.FilePath()
>        |
>     62 | import System.FilePath (takeDirectory)
>        | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
Indeed this is expected.

> one thing that puzzles me is that on MacOS/X and Linux running
> Haskell code has a fixed virtual size of 1TB, while on FreeBSD the
> "vsz" reported by "ps", "top", ... is rought what you'd expect given
> the actual memory usage of the program plus overhead from generational
> GC.
>
> I am curious as to why the process memory model is platform-dependent
> in this manner.  It seems as though on many platforms the RTS gives
> the process a large virtul address space, and then allocates memory
> by fauliting-in previously unused pages, whereas on FreeBSD brk(2)
> (via sbrk() or malloc(), ...) is used to extend the process virtual
> size on demand.
>
We use a much different memory allocation strategy on FreeBSD which
(AFAIK) does not allow one to reserve address space without also
committing. On Linux we ask up-front for a single 1TB address space
mapping and lazily commit it as we need it. This allows out heap check
to be extremely efficient as we know the heap is contiguous. On
platforms that don't support this we need to use a slower check. This
behavior can be switched off on Linux using the
--disable-large-address-space configure flag.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20180705/df19b65e/attachment.sig>